Why LoRa Is Emerging as a Credible Protocol for Deployed UK Defence Sensor Systems
The UK’s Defence Technology Framework and the broader Defence and Security Equipment International (DSEI) agenda have both placed persistent battlefield awareness at the centre of future capability. Whether it is perimeter or soldier monitoring at a forward operating base, persistent surveillance of critical national infrastructure (CNI), or logistics tracking across dispersed supply chains, the requirement is consistent: reliable, low-power, long-range data transmission from sensors that cannot afford to fail or be detected – making Long Range or LoRa defence communications a promising, multi-purpose solution.
For much of the past decade, defence programmes have defaulted to proprietary radio protocols, cellular networks, or high-bandwidth satellite links. Each carries significant drawbacks in a deployed context: cost, power consumption, spectral visibility, security, and infrastructure dependency.
LoRa (Long Range, wireless radio frequency), and in some configurations, LoRaWAN (Long Range Wide Area Network), is attracting growing interest as an alternative physical layer for defence sensor networks, precisely because it was designed for the constraints that are inconvenient commercially and unavoidable militarily:
- Secure Off-Grid Communication: For emergency and tactical situations, bypassing traditional cellular networks.
- Perimeter Surveillance and Asset Tracking: Monitoring military installations, protecting critical infrastructure, and providing real-time data on potential intrusions in remote locations.
- Environmental Monitoring: To track environmental conditions in rugged terrain, which is essential for logistical planning and training in remote areas.
- Resilience and Security: Ensuring secure data transmission for military intelligence, surveillance, and reconnaissance applications.
- Low-Power and Long-Life: Some devices can operate on battery power for up to 15 years, making them ideal for deployment in interconnected defence systems spanning wide areas and reaching hard-to-reach locations.
This is the first in a series of posts focused on defence product design and engineering, where we’ll discuss everything from firmware security and power budgeting for tactical sensors to building rugged enclosures and choosing radios for defence deployments. This post examines where LoRa defence communications genuinely adds value in a UK context, where it falls short, and the engineering decisions that determine whether a LoRa-based sensor system becomes a reliable operational capability or a well-intentioned pilot that stalls at the field trial stage.
What is LoRa and why does it matter for defence sensor networks?
LoRa® is a proprietary spread-spectrum modulation technique developed by Semtech that operates in the unlicensed sub-GHz ISM bands (primarily 868 MHz in the UK and Europe). LoRaWAN is the network protocol and architecture built on top of the LoRa physical layer, providing MAC-level management, security, and device addressing.
The distinction matters in a defence context. LoRa can be operated at the physical layer in custom, non-LoRaWAN configurations, i.e., using private frequency plans, custom MAC layers, and proprietary encryption schemes, which gives defence engineers considerably more flexibility than the open LoRaWAN specification alone.
The core characteristics that make it relevant to defence sensor deployment are:
- Exceptional range: Line-of-sight ranges of 15–40 km have been demonstrated in field conditions. In semi-urban or woodland terrain, 2–5 km can be reliably achieved without infrastructure.
- Low power consumption: Sensor nodes operating in Class A LoRaWAN mode can sustain multi-year battery life on AA-format cells, reducing the logistics burden of battery resupply in austere environments.
- Low RF signature: Chirp Spread Spectrum (CSS) modulation distributes the signal across a wide frequency band at very low power levels. This makes LoRa transmissions difficult to detect and locate with conventional signals intelligence (SIGINT) equipment – a characteristic with direct tactical value.
- Sub-GHz penetration: 868 MHz signals propagate through foliage, building materials, and terrain features more effectively than 2.4 GHz alternatives, supporting sensors deployed in complex environments.
|
Related reading: Many of the network architecture principles discussed here (e.g., gateway placement, data pipeline design, and scalability trade-offs) are examined in detail in our post on LoRaWAN for remote energy monitoring, which explores the protocol’s behaviour in large-scale, infrastructure-constrained deployments. The engineering challenges are closely analogous. |
LoRa defence communications: Where the protocol genuinely fits
LoRa for Perimeter and Border Surveillance Sensors
Persistent ground surveillance is one of the clearest use cases for LoRa in a UK defence or security context. Buried seismic sensors, passive infrared (PIR) detection nodes, and acoustic sensors at a forward operating base or protected site need to transmit small alert packets, often less than 50 bytes, at irregular intervals. They need to do this for months without intervention, in conditions that preclude cabling or frequent battery changes. Additional use cases include:
- Intrusion detection: Low-power PIR (passive infrared) sensors and vibration sensors can detect unauthorised entry along fences, perimeters of military bases, or critical national infrastructure (CNI)
- Border Protection: Long-range sensors can detect activity in remote areas where traditional surveillance is challenging.
- Structural Health Monitoring: Sensors on critical infrastructure (tunnels, bridges) can monitor for structural collapse or tampering.
LoRa’s combination of long-range uplink, low power draw, and low spectral footprint aligns directly with this requirement. A single gateway at a protected site can cover a large sensor perimeter while remaining largely invisible to conventional RF monitoring.
|
🛠 Engineering Detail: Adaptive Spreading Factor for Perimeter Sensors LoRa’s Spreading Factor (SF) is the primary lever for trading data rate against range and sensitivity. SF7 offers the highest data rate (~5.5 kbps) at a shorter range; SF12 achieves maximum sensitivity (-137 dBm) at the cost of much lower data rate (~250 bps) and significantly longer time-on-air. For perimeter sensor applications, designers typically operate sensors at SF9–SF11, balancing adequate range coverage with duty cycle compliance. A key constraint in the UK 868 MHz band is the 1% duty cycle limit: a sensor transmitting a 50-byte packet at SF10 occupies the channel for approximately 370 ms, meaning it can only transmit around 9 packets per hour without violating regulatory limits. System architects must account for this when defining alert latency requirements. For high-priority detection events, Class B or Class C LoRaWAN modes, or a custom MAC layer, may be required. |
Personnel and Asset Tracking (Logistics) in Dispersed Supply Chains
UK defence logistics operations often span large geographic areas with inconsistent cellular coverage, particularly during exercises, humanitarian operations, or deployed scenarios. Monitoring the health of soldiers and military personnel, and tracking the location or condition of equipment, vehicles, and materiel in rural or remote areas using a cellular solution requires persistent network coverage that simply does not exist in many operational environments.
LoRa-based asset trackers paired with lightweight GNSS modules can report positions at configurable intervals via a private gateway network. Where a small number of vehicle-mounted gateways are deployed, the network becomes self-organising: sensors on dismounted equipment or containers report to the nearest gateway. This architecture requires no commercial network subscription and leaves no data footprint on third-party infrastructure.
Environmental and CBRN Monitoring at Fixed Sites
Persistent environmental monitoring at defence establishments which includes detecting chemical, biological, radiological, or nuclear (CBRN) contamination, monitoring air quality near sensitive facilities; or tracking structural integrity of infrastructure is another application well-suited to LoRa’s characteristics: using specialised sensors to provide real-time data on toxic agents, enabling first responders and military personnel to make rapid decisions to protect people, equipment, and critical infrastructure is essential. In these applications, sensor payloads are small, transmission intervals are measured in minutes rather than seconds, and the ability to power sensors with small batteries or energy harvesting significantly reduces the operational burden.
LoRa defence communications protocols are equally suited for localised building management for ‘smart’ military infrastructural environments, which require:
- Energy Management: Monitoring and controlling HVAC, street lighting, and water usage in barracks and offices.
- Room/Space Occupancy: Tracking secure room access or movement in sensitive facilities to improve security and efficiency.
LoRa Military Sensors for Covert or Remote Deployment: Battlefield and Operational Awareness
Temporary or semi-permanent sensor nodes deployed in denied or contested terrain (e.g., acoustic sensors, seismic monitors, trip-wire alerts) require a communications channel that does not betray their presence. This can include:
- Battlefield Sensor Networks: Deploying ‘smart battlefield’ sensors that detect environmental conditions or enemy movements, feeding data to automated systems or command and control units.
- Discreet Communication (xBand): Integrating LoRa defence communications with vibration-based notification systems allows soldiers to receive alerts silently in high-stress situations, ensuring stealth.
- Unmanned System Support: Connecting UAVs and UGVs (drones and ground robots) for reconnaissance and data collection, allowing them to operate remotely over long distances
LoRa’s sub-GHz CSS modulation is not undetectable by sophisticated adversaries with modern SIGINT capability, but it is substantially more difficult to detect and localise than conventional UHF/VHF narrowband or cellular transmissions. For lower-threat environments or against technically limited adversaries, this characteristic has clear value.
Where LoRa falls short: Limitations and challenges for defence applications
A credible assessment of LoRa for defence must address the protocol’s genuine limitations. Using LoRa where it is technically inappropriate is not a minor inconvenience: in a defence context, it’s a mission-critical risk.
Latency Is Not Controllable to Military Standards
LoRa is an asynchronous, ALOHA-based protocol. Sensors transmit when they have data; the network does not guarantee delivery timing. In the standard LoRaWAN Class A configuration, a device only opens downlink receive windows immediately after an uplink transmission. This means that latency, both from sensor to server and for any command sent back to the sensor, is inherently variable. For applications requiring deterministic, sub-second response (fire-control systems, time-critical command and control), LoRa is unsuitable. This is a structural limitation, not an implementation gap.
Bandwidth Constraints Preclude Rich Data Applications
LoRa is optimised for small packet sizes. Typical maximum payload sizes range from 51 to 222 bytes, depending on the spreading factor and regional configuration. Transmitting images, audio, or video, even low-resolution captures, is not feasible over LoRa. For sensor fusion applications in which a node aggregates data from multiple sensors and transmits a compound dataset, careful payload design is essential and remains bounded by these limits.
Lora’s Defence-Specific Challenges
Due to its reliance on unlicensed sub-GHz spectrum, low-power constraints, and specific architectural vulnerabilities, LoRa technology presents unique challenges in defence and military applications:
- Electronic Warfare (EW) and Jamming: Operating on unlicensed, shared frequencies makes LoRa susceptible to intentional jamming by adversaries. While Chirp Spread Spectrum (CSS) provides some resistance, it is not immune to sophisticated jamming.
- Security and Eavesdropping: Although LoRaWAN offers AES-128 encryption, the massive deployment of sensors in hostile environments presents a large attack surface. Risks include spoofing (impersonating devices), replay attacks, and unauthorised interception of tactical data.
- Network Vulnerability: In tactical scenarios where standard networks are destroyed, relying on a central gateway can create a single point of failure.
- Environmental Factors: Military operations often take place in harsh conditions that can affect battery performance, signal strength, and component durability, necessitating ruggedised hardware.
Operational and Integration Challenges
LoRa offers powerful, energy-efficient solutions for long-range IoMDT connectivity; however, practical deployment can also face significant operational and integration challenges – particularly regarding bandwidth, latency, security, and network management.
- Lack of Native Routing: Standard LoRaWAN operates in a star topology, which may not suit complex, mobile, or ad hoc military scenarios.
- Integration with Legacy Systems: Integrating new LoRaWAN devices with legacy military communication systems requires custom gateways and protocol translation.
- Device Management: Managing thousands of nodes across large, varied terrain presents logistics and security challenges.
|
⚠️ Critical Alert: Duty Cycle Compliance in UK ISM Band Operations Operation in the 868 MHz ISM band in the UK is governed by Ofcom regulations implementing ETSI EN 300 220, which imposes a 1% duty cycle limit on most sub-bands. This is a legal constraint, not a design suggestion. A sensor network that exceeds this limit during high-activity periods (for example, multiple simultaneous perimeter alerts) will violate spectrum regulations. For defence deployments on private or licensed spectrum, this constraint can be mitigated by operating outside the ISM band under appropriate licensing. This is a common approach for UK MoD programmes requiring higher transmit duty cycles. Engineers designing LoRa-based systems for defence must resolve the spectrum licensing question early in the programme, as it has material implications for hardware design, gateway configuration, and network capacity planning. |
LoRa’s Insufficient ‘Military’ Grade Encryption
The standard LoRaWAN security model uses AES-128 encryption at two layers: the network level (NwkSKey) and the application level (AppSKey). For commercial deployments, these security features are adequately robust. For defence applications handling data of any sensitivity classification, AES-128 applied over-the-air represents only one element of an end-to-end security architecture. Data at rest on gateways, transit from gateway to network server, and server-side storage all require independent security controls commensurate with the classification of the data.
A LoRa-based defence sensor system that is secure at the RF layer but transmits data to an unsecured cloud instance is not secure. This is an architectural problem, and one that is frequently underestimated in early-stage programme design. Thus, while the LoRaWAN standard is designed to be secure, it’s not inherently ‘military-grade’ without rigorous, professional implementation.
Taking all these factors and context into consideration can mean that while LoRa is effective for applications such as tracking assets or monitoring low-priority sensor data in remote areas, it often cannot replace high-bandwidth communication systems in combat situations.
|
🛠 Engineering Detail: Custom PHY Layer for Non-ISM Defence Deployments When operating under a licensed spectrum allocation (rather than the shared ISM band), LoRa’s physical layer can be reconfigured for frequencies outside the standard 868 MHz band. The Semtech SX1276/SX1278 family, for example, supports operation from 137–1020 MHz, enabling system designers to select frequencies that offer better propagation characteristics for specific terrain, reduced interference from commercial traffic, or alignment with existing programme spectrum allocations. In this configuration, a custom MAC layer replaces LoRaWAN. The designer retains LoRa’s CSS modulation and its associated range, power, and detectability characteristics while gaining full control over access protocols, encryption schemes (which can be upgraded beyond AES-128), and duty cycle management. This architecture is more complex to develop and validate but is appropriate for programmes where the LoRaWAN standard’s limitations (e.g., security, duty cycle, or frequency plan) cannot be accepted. |
Engineering a LoRa sensor network for defence: Key design decisions
Moving from protocol selection to deployed capability requires a disciplined approach to system architecture. Several design decisions have a disproportionate impact on operational performance.
Gateway Placement and RF Coverage Modelling
Coverage prediction in defence environments cannot rely on free-space path loss models. Woodland, undulating terrain, and man-made structures all attenuate sub-GHz signals in ways that differ materially from theoretical models. Gateway placement should be validated with RF propagation modelling tools calibrated to actual terrain data, followed by field surveys with representative sensor hardware. Deploying a gateway network without this step, and discovering coverage gaps during commissioning, is a common and expensive mistake.
Antenna Selection and Form Factor Constraints
The sensor node’s antenna is often the source of a performance compromise. A well-designed RF frontend coupled to a poor antenna installation will underperform a modest RF circuit with a well-matched, correctly positioned antenna. In embedded defence sensor designs, antenna placement is constrained by enclosure geometry, metallic components, and the need for environmental sealing. These constraints must be resolved through RF simulation and physical testing early in the hardware design process, not treated as an afterthought following enclosure design.
Power Budget and Battery Chemistry for Deployed Environments
Multi-year battery life in LoRa sensor nodes is achievable under controlled conditions. In the field, temperature extremes significantly affect battery performance: primary lithium (Li-SOCl₂) cells maintain capacity across a wider temperature range (-60°C to +85°C) than alkaline alternatives, making them the standard choice for deployed military sensors. Power budget modelling must account for the full duty cycle: active transmission, receive windows, MCU processing, and sensor excitation. Optimistic power budgets that assume nominal conditions will result in early field failures.
Network Resilience and Redundancy
A star-topology network, where all sensors report to a single gateway, presents an obvious single point of failure. In a defence deployment, gateway destruction or jamming would silence the entire sensor network. Resilient architectures deploy multiple overlapping gateways with automatic failover. Where weight and power budgets allow, relay nodes can extend coverage beyond direct gateway range. However, this introduces mesh-like complexity that needs careful management.
|
🛠 Engineering Detail: Anti-Jamming Considerations for LoRa Defence Sensor Networks LoRa’s Chirp Spread Spectrum modulation provides inherent resistance to narrowband interference. The signal is spread across a bandwidth of up to 500 kHz, meaning a narrowband jammer targeting a specific frequency will only partially disrupt the link. However, wideband noise jamming across the full ISM band will degrade performance. For higher-threat environments, frequency-hopping implementations, possible on the LoRa physical layer outside the standard LoRaWAN protocol, provide additional resilience against both narrowband and swept jamming. This is a non-trivial implementation challenge and requires specialist RF engineering capability, but the approach is well-established in the military radio domain. |
LoRa within a broader UK defence connectivity architecture
LoRa is not a replacement for tactical radio networks, military satellite communications, or the data links that carry command-and-control traffic. It occupies a specific niche: low-power, long-range, low-data-rate sensor connectivity, operating at the edge of the network where other connectivity options are too costly, too power-hungry, or too spectrally visible.
In a well-designed system, LoRa sensor networks feed data into tactical operations centres through a layered architecture: sensors transmit to a gateway; the gateway aggregates and encrypts the data before transmitting it via a higher-bandwidth backhaul (which may be a tactical satellite, tactical radio, or cellular, where available) to a processing and decision-support layer. The LoRa network handles the final few kilometres of sensor connectivity more efficiently than any other protocol.
This architectural pattern is analogous to what we described in our LoRaWAN for remote energy monitoring analysis (where the protocol sits at the data collection edge of a larger system, with more capable infrastructure handling aggregation and backhaul). The same principle applies in the defence domain, with the additional requirements of security architecture and resilience demanded by the operating environment.
For UK defence programme managers and senior engineers evaluating LoRa as part of a sensor network architecture, the framework question is not whether LoRa works (it demonstrably does, at scale, in demanding environments) but whether the programme has the engineering rigour to design, integrate, and validate the full system.
What does this mean for UK defence procurement and programme teams?
For decision-makers evaluating LoRa-based sensor systems, several considerations sit above the technical detail:
SWAP-C (Size, Weight, Power, and Cost) drives many capability decisions at the tactical edge. LoRa-based defence communications sensors offer a compelling profile on all four axes compared with alternatives. However, that profile depends on the system being correctly engineered. Poorly designed RF frontends, inadequate power budgets, or insufficient network redundancy rapidly erode the SWAP-C advantage.
Through-life cost is frequently underestimated in sensor network programmes. A network of several hundred sensors, each requiring battery replacement every 2 years, creates a sustained logistics burden. Correctly modelling and optimising power consumption at the design stage, not after initial prototype validation, is a significant cost-avoidance measure over a 10–15-year capability life.
As procurement managers increasingly focus on digital transformation, integrating AI, and securing sovereign technology, security and data governance for any system that touches classified or operationally sensitive data requires engagement with the programme’s security authority from day one. A LoRa sensor network that is technically sound but security-architected as an afterthought will face significant remediation costs before it can be cleared for operational use.
UK industrial base considerations are relevant as defence procurement policy continues to emphasise domestic sourcing. UK-based electronics design and manufacturing capability for LoRa-enabled sensor hardware exists and is well-established, reducing programme risk associated with supply chain concentration in non-allied territories for sensitive components.
Final Thoughts
LoRa’s characteristics (long range, low power, low spectral footprint, and infrastructure independence) align well with a genuine and growing set of UK defence sensor requirements. The protocol is not a cure-all, and its limitations in latency, bandwidth, and standard security architecture are real constraints that have to be engineered around rather than ignored.
The difference between a LoRa defence communications for a sensor-based programme that delivers operational capability and one that stalls at field trial is rarely the protocol itself. It’s the engineering depth and rigour applied to hardware design, RF planning, power budget, system architecture, and security integration. These are disciplines that require sustained investment and specialist experience, not bolt-ons that can be added once the connectivity question has been answered.
If your programme is evaluating LoRa for deployed sensor applications, the starting point is a clear-eyed assessment of your operational requirements against the protocol’s actual performance envelope, followed by a system architecture that places LoRa where it is strongest and pairs it with complementary technologies where it is not.
Our team works across the full stack of defence sensor system design: from RF hardware and firmware through to system architecture and product qualification. If you are working through these stages, get in touch to discuss your programme’s specific constraints.
