P.1812 vs ITM: How to Pick the Right Propagation Model

When you select a propagation model for a LoRaWAN link analysis, the choice isn't just about accuracy — it's about which type of accuracy you need and which parameters you can actually provide. ITM and P.1812-6 are both serious engineering models with decades of field validation. They have different scopes, different inputs, and different failure modes.

FresnelPath implements both, wrapping the published reference engines (Py1812 for P.1812-6, itmlogic for ITM) rather than reimplementing the standards from scratch. The goal is standards-compliant output you can cite, not a novel interpretation of the physics.

The comparison at a glance

What "terrain-aware" means — differently — for each model

Both models use terrain elevation profiles, but they handle them differently. ITM is a statistical-empirical model: it characterises the terrain along the path by its roughness (Δh, the inter-decile height range) and derives propagation statistics from that characterisation. ITM does not trace individual diffraction events around specific ridges — it uses terrain roughness as a statistical predictor of path loss distribution.

P.1812-6 is path-specific: it computes diffraction loss directly from the terrain profile, accounting for individual ridges and obstacles. This is more accurate for a specific path but doesn't generalise to a statistical coverage prediction the way ITM does.

For a single high-priority link — a critical gateway-to-node path where you're trying to determine whether a specific installation will work — P.1812-6 is almost always the right choice. For bulk heatmap computation across thousands of paths where you need approximate coverage statistics, ITM is computationally faster and the statistical nature of its prediction is actually appropriate.

Time percentage and what it means for link planning

P.1812-6 accepts a time-percentage parameter between 1% and 50%. This is not a "confidence level" in the informal sense — it's the percentage of time that the path loss will be at or below the predicted value, under the assumption that atmospheric conditions vary.

At 50% time: the prediction corresponds to median atmospheric conditions. This is the most optimistic usable prediction — half the time, conditions will be worse.

At 1% time: the prediction includes worst-case atmospheric effects — ducting, troposcatter, multipath fading. Path loss at 1% time is typically much higher than at 50%. Planning to this value gives you a conservative estimate of when the link will be at its weakest.

For most LoRaWAN deployments, 50% is the right starting point: you want to know if the link closes under normal conditions. If you're planning a mission-critical link that must maintain connectivity even during adverse propagation conditions, planning to 10% or even 1% is appropriate, but you'll need more link margin to compensate.

ITM doesn't offer this parameterisation — it produces a median prediction for the given climate zone. This makes it simpler to use but less expressive for availability analysis.

Clutter: where P.1812-6 has ITM beat

Clutter refers to the buildings, vegetation, and structures near the transmitter and receiver that affect signal propagation over the last few hundred metres of a path. ITM has no clutter model — it treats the antenna as sitting in open terrain. P.1812-6 includes clutter loss via ITU-R P.2108-1 §3.1, which accounts for typical building density and vegetation in the vicinity of the transmitter and receiver.

FresnelPath also implements ITWOM 3.0 — ITM with the P.2108-1 clutter model applied additively. This gives ITM's terrain prediction the benefit of terminal clutter estimation. One tested invariant: setting clutter height to zero in ITWOM produces path loss numerically identical to plain ITM. The clutter component is genuinely additive, not baked into a coefficient.

For deployments in suburban or dense urban areas, the clutter term matters. An industrial gateway 10 m high surrounded by warehouses doesn't see open-terrain propagation near the antenna — the clutter loss can be 10–20 dB at short distances, which dominates the early part of the path loss budget.

A European Alps example: Brenner Pass corridor

Consider a path from a gateway installed at the Brenner Pass (1,374 m, 46.8°N, 11.5°E) connecting environmental monitoring sensors in the Inn Valley on the Austrian side. The valley floor sits around 800 m; the effective distance is 10–15 km.

At 868 MHz (EU868), this path has at most a few ridges. FresnelPath's auto-routing selects Bullington diffraction (2–4 obstacles). At this range and terrain complexity, ITM would predict a plausible median loss, but would not distinguish between a clear valley path and a path with a significant mid-path saddle that provides a secondary ridge obstruction.

P.1812-6 traces the actual profile. If that saddle creates a ridge within the Fresnel zone, P.1812-6 accounts for the diffraction loss it produces. ITM wouldn't see it.

For a regulatory submission — frequency coordination filing for the Austrian national regulator — P.1812-6 is the appropriate choice: it's the ITU-R standard for path-specific frequency coordination studies, and citing it by number carries weight with regulators who know what it means.

When to use ITM

Despite P.1812-6's superiority for single-path verification, there are legitimate reasons to use ITM:

• Frequency above 6 GHz: P.1812-6 is only specified to 6 GHz. For microwave backhaul links above that, ITM's 20 GHz upper limit is relevant.
• Bulk heatmap computation: When computing a coverage heatmap over thousands of points, ITM's statistical nature and faster computation make it practical. P.1812-6's path-specific approach doesn't scale as well to gridded area analysis.
• Climate-zone analysis: ITM's seven radio climate zones (equatorial, continental subtropical, maritime, desert, etc.) parameterise propagation over large geographic areas in a way that P.1812-6's path-specific approach doesn't address.
• No clutter data: If you have no information about the terminal environment, ITM's open-terrain assumption at least avoids inventing clutter estimates that may be wrong.

The reference-engine approach

FresnelPath wraps Py1812 (the Python implementation of P.1812-6 published by the standard's authors) and itmlogic (the ITM reference implementation from NTIA). This is a deliberate choice: rather than reimplementing the propagation physics from a textbook description, both models run the same code the standards bodies use for validation.

The consequence is that FresnelPath's P.1812-6 results match what you'd get from the ITU-R study group's own test vectors, and the ITM results match NTIA's reference implementation. When you cite a FresnelPath analysis in a submission, you're citing output from the reference engine, not an independent interpretation.

The decision rule

For most LoRaWAN link analyses at 868 MHz or 915 MHz: use P.1812-6. It accounts for clutter, allows time-percentage parameterisation, and gives you a path-specific prediction you can cite to a regulator or justify to a client.

Use ITM when you're above 6 GHz, running bulk coverage computation, or need the statistical-variability characterisation that ITM's climate-zone approach provides.

FresnelPath's auto-routing makes this selection automatically based on your terrain and frequency. You can override it manually from the Model tab if your situation warrants it.