10 Infrastructure-Denied IoT: Field Architecture
10.1 Start With the Situation
The radio family is selected, but remote operation still depends on weak-signal behavior, antennas, power, custody, and recovery. The team must join those parts into an architecture that can be tested away from normal infrastructure.
10.2 Overview
This route builds the field architecture and verifies weak-signal, antenna, power, and custody evidence.
This is part 2 of 2. Review Infrastructure-Denied IoT: Radio Options when you need the first route.
10.3 Learning Objectives
By the end of this chapter, you will be able to:
- explain HF and weak-signal telemetry limits
- design antenna and power architecture
- validate custody and recovery during outages
10.4 Chapter Roadmap
Follow the original sections below in order. They begin at the reviewed split boundary and keep every worked example, figure, check, and supporting banner with the section that owns it.
10.5 HF and NVIS as Background Knowledge
Most IoT courses focus on short-range wireless and LPWAN. Infrastructure-denied environments sometimes require students to understand a less common option: high-frequency radio.
10.5.1 HF Radio
HF means High Frequency, usually 3-30 MHz. Compared with common IoT bands, HF has long wavelengths: tens of metres rather than centimetres.
HF is not attractive for normal IoT because:
Antennas are physically larger. Data rates are usually low. Propagation varies by time of day and solar conditions. Licensing can be complex. Hardware and installation need radio expertise.
HF becomes interesting when the application needs:
Regional coverage. Very small messages. No cellular infrastructure. No tower network. No clear line-of-sight. No subscription operator. Delay-tolerant telemetry.
10.5.2 Ground Wave, Skywave, and NVIS
HF signals can travel in several ways:
| Mode | Description | IoT relevance |
|---|---|---|
| Ground wave | Signal follows the Earth’s surface | Useful at lower HF/MF over some terrains, but loss can be high |
| Conventional skywave | Signal leaves at a lower angle and returns far away | Good for long-distance communication, often skips over nearby receivers |
| NVIS | Signal leaves at a steep angle and is refracted back over a regional area | Useful when nearby regional coverage is needed without line-of-sight |
NVIS means Near-Vertical Incidence Skywave. The transmitter sends HF energy upward at a steep angle. The ionosphere bends part of the energy back toward Earth, creating regional coverage that can fill the usual “skip zone” of long-distance HF.
Typical NVIS use is not broadband. It is better suited to robust low-rate messages, emergency communication, regional coordination, and sparse telemetry.
10.5.3 When NVIS Enters Design
Do not ask “Can we use NVIS?” first. Ask whether the application has become difficult enough that normal IoT links are weak fits.
| Consider HF/NVIS when… | Prefer another option when… |
|---|---|
| The payload is tiny: status, alarms, location, battery, or compact sensor summaries | The system needs images, audio, firmware updates, dashboards with frequent refresh, or interactive control |
| The deployment needs regional coverage without towers, cellular service, or reliable line-of-sight | A private LoRaWAN gateway, cellular IoT modem, satellite modem, or mobile collector can meet the requirement simply |
| Delay of minutes or longer is acceptable | The application needs tight real-time control or low-latency command response |
| The organisation can handle licensing, antenna installation, propagation planning, and radio troubleshooting | The deployment must be maintained by non-specialists with minimal radio training |
| Field testing can be repeated across time of day, season, weather, and solar conditions | The project needs predictable performance from datasheets alone |
The useful mental model is: NVIS is a resilience and coverage tactic for unusual low-rate telemetry, not a replacement for mainstream IoT networking.
10.5.4 Ionospheric Layers
HF propagation depends on the ionosphere, which changes across the day and with solar activity.
| Layer/condition | Effect |
|---|---|
| D layer | Absorbs lower HF energy, especially during daytime |
| E layer | Can support some propagation paths but is variable |
| F layer | Main layer for many HF skywave paths |
| Nighttime | D-layer absorption reduces; lower frequencies may improve |
| Daytime | Higher absorption; usable frequency may shift upward |
| Solar storms | Can disrupt or alter propagation reliability |
Two practical concepts matter:
- MUF, Maximum Usable Frequency: above this, the ionosphere may not return the signal on the intended path.
- LUF, Lowest Usable Frequency: below this, absorption and noise may make the link unreliable.
The usable frequency lies between these limits, and that window changes over time.
10.6 Key Idea
HF/NVIS should not be taught as “better than LoRaWAN” or “better than satellite”. It is a different design point: lower data rate, larger antenna, more propagation uncertainty, but potentially useful when the site has no ground infrastructure and no reliable line-of-sight path.
10.7 Weak-Signal Digital Telemetry
When radio links are weak, engineers can trade speed for reliability.
Weak-signal telemetry uses combinations of:
- Narrow bandwidth
- Error-correcting codes
- Repetition
- Time synchronization
- Long symbol durations
- Carefully structured payloads
- Receiver-side signal processing
The result is that messages can sometimes be decoded even when the signal is near or below what a human listener would consider obvious.
10.7.1 Payload Design
Low-rate links force discipline. A good telemetry message carries only what is needed.
Example compact fields:
| Field | Purpose | Encoding idea |
|---|---|---|
| Device ID | Identify sender | Numeric index or short alphanumeric code |
| Message type | Status, alarm, test, health | 2-4 bits |
| Timestamp | Event time | Relative time or compressed epoch |
| Location | Position if needed | Quantised latitude/longitude or site index |
| Battery | Power health | 8-bit quantised voltage or percentage |
| Sensor value | Main reading | Quantised engineering value |
| Check bits | Detect corruption | CRC or protocol-level checksum |
The important question is not “how many bytes can I send?” It is “what decision can the receiver make from this message?”
10.7.2 Latency and Duty Cycle
Weak-signal and ultra-low-power systems often transmit on schedules. A message may wait until the next slot, repeat over several slots, or be acknowledged only when a gateway is available.
This is acceptable for many monitoring applications but unsuitable for tight real-time control. A system that reports a status within 15 minutes can be excellent for remote monitoring and unacceptable for machine safety.
Checkpoint: Weak-Signal Trade-Offs
You now know:
- HF usually means 3-30 MHz, with larger antennas and more variable propagation than common IoT bands.
- NVIS belongs only where tiny, delay-tolerant telemetry needs regional coverage without towers, cellular service, or line-of-sight.
- Weak-signal systems buy robustness with narrow bandwidth, coding, repetition, scheduling, and compact payloads.
10.8 Antennas in Remote Deployments
A link-budget gain value is credible only if the installed antenna preserves the assumed orientation, height, and feedline condition. Inspect Figure 10.1 before accepting that value: the radiating elements, mast clamps, exposed connector, and descending feedline turn an abstract gain entry into field evidence.
Read Figure 10.1 from the radiating elements down the mast and feedline. Their vertical orientation and height shape coverage, while clamps, cable routing, and exposed connectors introduce alignment, loss, weatherproofing, and service questions. The photograph therefore connects antenna theory to the deployment review: a catalog gain is credible only when mounting, surroundings, feedline condition, and safe access preserve it in the field.
Photo: David Jordan (derivative: Chetvorno), CC BY-SA 3.0
10.8.1 Antenna Size
A simple half-wave dipole has approximate total length:
Examples:
| Frequency | Half-wave dipole length |
|---|---|
| 5 MHz | about 28.6 m |
| 868 MHz | about 16.5 cm |
| 2.4 GHz | about 6.0 cm |
Lower frequencies can help with propagation but make installation harder because the antenna becomes a physical structure.
10.8.2 Antenna Placement
Important placement questions:
Can the antenna be installed safely by the field team? Is the antenna above ground clutter or intentionally low for the propagation mode? Will vegetation touch or detune it? Can animals, machinery, wind, or flooding damage it? Is strain relief provided? Are connectors waterproofed? Is the feedline loss acceptable? Is the antenna legal for the frequency and transmit power?
10.8.3 Matching and SWR
An antenna must be matched to the transmitter. Poor matching reflects power back toward the transmitter, reducing radiated power and potentially damaging hardware.
In field systems, matching can change due to:
- Wet vegetation
- Soil moisture
- Cable movement
- Corrosion
- Connector water ingress
- Broken insulation
- Nearby metal objects
Remote systems should report enough health information to detect radio degradation before total failure.
10.9 Power Architecture
Remote IoT power design is dominated by average current, not peak current alone.
Average current across a wake cycle is:
where and . Battery life is approximately:
where is battery capacity in mAh and is average current in mA.
10.9.1 Radio Energy Usually Dominates
For many battery-powered nodes, the radio is more expensive than the sensor reading. Optimisation usually focuses on:
Sleeping most of the time. Reducing connection setup time. Sending compact payloads. Avoiding unnecessary acknowledgements. Batching readings. Transmitting only on significant change. Using local storage when the link is unavailable. Selecting a communication technology that matches the payload.
10.9.2 Gateway Power Is a Separate Problem
Students often design low-power sensor nodes but forget the gateway. A gateway may need:
- Continuous receiver operation
- Larger battery capacity
- Solar panel sizing
- Local processing
- Backhaul connectivity
- Weatherproof enclosure
- Physical security
- Remote reboot capability
An end-to-end design fails if the sensor node lasts for years but the gateway fails after one cloudy week.
10.10 Architecture Patterns
Infrastructure-denied IoT systems are usually built around a few recurring patterns.
10.10.1 Pattern 1: Private Gateway
Sensors communicate to a privately installed gateway. The gateway uses whatever backhaul is available: cellular, satellite, wired internet, long-range Wi-Fi, or manual data collection.
Use when:
- Gateway installation is possible
- Many nodes are within radio range
- The site can support gateway power
- A private LPWAN or local mesh is practical
10.10.2 Pattern 2: Store-and-Forward
Nodes store readings locally and transmit when a link becomes available. The receiver may be fixed, mobile, aerial, or temporarily deployed.
Use when:
- Delay is acceptable
- Data loss is worse than late data
- Maintenance visits or mobile collectors are part of operations
10.10.3 Pattern 3: Event-First Telemetry
The node sends only important events immediately and stores detailed data locally for later retrieval.
Use when:
- Most data is routine
- Alarms matter more than continuous streams
- Radio bandwidth is scarce
10.10.4 Pattern 4: Multi-Tier Network
Low-power nodes send to local relays or cluster heads; those relays forward data using a different, longer-range technology.
Use when:
- Direct long-range links are too expensive
- Local aggregation reduces traffic
- Some nodes can support larger batteries or solar
10.10.5 Pattern 5: Alternate Propagation Path
The system uses a communication path that avoids the main obstruction problem, such as skywave instead of terrestrial line-of-sight.
Evaluate the alternate path from obstruction to operations. Identify why the primary terrestrial route fails, confirm that the proposed propagation mode can carry the small traffic volume within its latency bound, and then check antenna, spectrum, expertise, gateway power, and monitoring requirements. Finish by naming the fallback and retest condition. The pattern advances the chapter’s narrative only when it converts a physical-path limitation into an evidence-backed service route rather than treating unusual propagation as automatic resilience.
Use when:
- Terrain and vegetation block ground links
- Traffic is very small
- Latency can be relaxed
- Legal operation and radio expertise are available
Checkpoint: Architecture and Power
You now know:
- Node lifetime depends on average current across the full wake/sleep cycle, not only peak radio current.
- The gateway needs its own power budget; a sensor that lasts for years still fails if the gateway dies after one cloudy week.
- Private gateways, store-and-forward, event-first telemetry, multi-tier relays, and alternate propagation paths fail in different ways.
10.11 Field Validation
Evidence for Field Validation starts in Figure 10.2. Look at Connected vs Disconnected Networks beside CONNECTED before accepting Connected versus disconnected network paths.
Connected vs Disconnected Networks begins the visual in Figure 10.2 and identifies the measured path. Next, CONNECTED names a responsibility; finally, Connected path exists between all node pairs names a responsibility. Keeping Connected vs Disconnected Networks distinct from Connected path exists between all node pairs explains Connected versus disconnected network paths. That makes CONNECTED a checkable part of Field Validation.
| Custody layer | Evidence to collect | Failure response to test |
|---|---|---|
| Sensor node | Local log, event timestamp, battery margin, retry counter | Hold the record locally, retry within the energy budget, or age out with an explicit reason |
| Local mesh or relay path | Neighbor table, route changes, packet delivery ratio, received signal quality | Use an alternate path, degrade to event-only telemetry, or preserve evidence until contact returns |
| Gateway or mobile collector | Uptime, queue depth, visit record, local receive log | Store queued records until backhaul returns and reconcile duplicate or late messages |
| Backhaul and dashboard | Link status, last successful delivery time, stale-data indicator | Mark the dashboard stale, keep local copies, and avoid treating silence as a safe state |
Resilience comes from diversity, not from a magic single link. A field mesh, private LPWAN, satellite terminal, mobile collector, or delay-tolerant store-and-forward path can each fail in a different way. The evidence review should therefore include representative outages: pull the backhaul, disable a relay, delay the collector, or block one radio path, then confirm which records are preserved, which alarms age out, and which operator message appears.
10.12 Question: Proving Custody During Outages
10.12.1 What to Measure
| Metric | Why it matters |
|---|---|
| Packet delivery ratio | Basic reliability of the telemetry path |
| Received signal strength | Indicates link margin and fading patterns |
| Signal-to-noise ratio | Separates weak signal from noisy environment |
| Latency | Shows whether the application can act in time |
| Battery voltage/current | Confirms energy model under real duty cycle |
| Temperature/humidity | Explains electronics and enclosure stress |
| Retry count | Reveals hidden reliability cost |
| Missed wakeups | Indicates timing, firmware, or power faults |
| Gateway uptime | Separates node failure from infrastructure failure |
| Installation notes | Captures antenna height, orientation, and local obstructions |
10.12.2 Factorial Test Design
When several variables may matter, vary them deliberately rather than changing everything at once.
Common factors:
- Frequency band
- Transmit power
- Antenna type
- Antenna height
- Payload size
- Message interval
- Site location
- Time of day
- Weather condition
- Gateway placement
A simple test matrix can reveal whether failures are caused by power, band choice, site geometry, antenna installation, or environmental timing.
10.12.3 Failure Classification
Classify failed messages rather than counting them only as missing.
| Failure class | Evidence |
|---|---|
| Node did not transmit | No local log entry, low battery, firmware crash |
| Transmitted but not received | Node log exists, gateway has no packet |
| Received but corrupted | Gateway detects invalid checksum or partial decode |
| Gateway unavailable | Multiple nodes missing simultaneously |
| Backhaul failed | Gateway received locally but cloud did not update |
| Time synchronization failed | Slots, timestamps, or weak-signal decoding fail |
| Antenna degraded | SNR gradually falls, SWR worsens, weather correlation appears |
This separation prevents teams from blaming the wrong layer.
10.13 Technology Selection Framework
Use the following decision logic as a starting point.
10.13.1 Step 1: Is There Existing Coverage?
If reliable cellular or LPWAN operator coverage exists and subscriptions are acceptable, managed connectivity may be simpler than private infrastructure.
If not, ask whether a private gateway can be installed and powered.
10.13.2 Step 2: Is There a Clear Radio Path?
If a gateway can be placed high enough with acceptable line-of-sight or near-line-of-sight, private LoRaWAN or another LPWAN may be appropriate.
If vegetation, terrain, or access prevents a reliable terrestrial path, consider store-and-forward, mobile collection, satellite, or alternate propagation.
10.13.3 Step 3: Is the Sky Visible?
If the sky is visible, satellite IoT can be attractive for sparse remote telemetry.
If dense canopy, buildings, or valleys block sky view, satellite may require antenna relocation, long acquisition times, higher power, or may be impractical.
10.13.4 Tiny, Delay-Tolerant Payload?
If only compact status or event messages are required, very low-rate options become possible.
If the system needs images, audio, firmware updates, or interactive control, low-rate links should be paired with local storage or a second retrieval channel.
10.13.5 Can Operations Sustain It?
A technically elegant radio link is not enough. Ask:
Who installs antennas? Who checks spectrum licensing? Who replaces batteries? Who diagnoses failures? Who owns the gateway? Who pays subscriptions? Who receives alerts? Who responds when telemetry stops?
The correct IoT design is the one the organisation can sustain.
10.14 Remote Environmental Alert Node
Scenario: A protected wetland needs low-cost water-level alerts from five sites. There is no mains power and unreliable cellular coverage. Staff can visit once every three months. Each site needs to report only water level state, battery health, and a device health flag.
10.14.1 Requirement Summary
| Requirement | Value |
|---|---|
| Payload | Under 30 bytes |
| Message interval | Every 30 minutes, plus immediate threshold alert |
| Latency | 5-30 minutes acceptable |
| Lifetime | 3 months minimum without visit |
| Direction | Mostly uplink |
| Data type | Status and alert telemetry, not raw waveform |
10.14.2 Candidate Designs
| Design | Fit | Risk |
|---|---|---|
| Cellular node | Simple if coverage exists | Unreliable attach; high energy during retries |
| Private LoRaWAN gateway | Good if gateway can see sites | Gateway power and placement required |
| Satellite IoT | Wide coverage | Sky view, cost, power, antenna placement |
| Local logger only | Very robust locally | No timely alerts |
| HF/NVIS or another ultra-low-rate alternate radio | Good for tiny messages where ground paths, cellular, and satellite are weak fits | Requires specialist radio design, antenna planning, field validation, and legal checks |
10.14.3 Engineering Lesson
The application does not need high throughput. It needs dependable delivery of small messages. That means the design should prioritise:
- Link margin
- Gateway availability
- Power budget
- Health reporting
- Installability
- Operational response
10.15 Infrastructure-Denied Design
Use this checklist before committing to hardware.
10.15.1 Application
What decision will the data support? What is the smallest payload that supports that decision? What latency is actually required? What data can be stored locally instead of transmitted?
10.15.2 Radio
What is the link budget with conservative fade margin? What frequency bands are legal at the deployment site? What antenna can be installed safely and repeatedly? What happens after rain, vegetation growth, and connector aging? How will interference and noise floor be measured?
10.15.3 Power
What is average current across the full wake/sleep cycle? What is the worst-case current during retries? What happens during cloudy weeks or cold conditions? Does the gateway have an independent power budget?
10.15.4 Operations
Who installs and maintains each component? How often can the site be visited? What remote health telemetry is needed? How are failures classified and escalated? What is the replacement plan for damaged enclosures, cables, and batteries?
10.16 Knowledge Check
10.17 Choosing Connectivity Strategy
10.18 Question: Why Low Data Rate Can Help
10.19 Summary
Infrastructure-denied IoT is about sustaining a complete communication system under physical, energy, regulatory, and operational constraints. The main lesson is not that one technology is best. The lesson is that remote IoT requires disciplined requirement definition, link-budget thinking, power modelling, antenna planning, field validation, and operational ownership.
When the payload is small and latency can be relaxed, engineers gain design freedom. They can choose private LPWAN, satellite, store-and-forward, mobile collection, mesh, or specialist radio paths. The correct choice is the one that delivers the required decision-quality information with enough margin to survive the real deployment environment.
10.20 Key Takeaway
Infrastructure-Denied IoT Connectivity should treat people, delay, consent, data quality, custody, privacy, intermittent connectivity, and deployment evidence as part of the sensing architecture.
10.21 What to Read Next
| Next topic | Why it matters |
|---|---|
| LPWAN Link Budget and Range | Learn the quantitative range calculations behind low-power wide-area links |
| LPWAN Technology Selection | Compare LoRaWAN, Sigfox-style networks, NB-IoT, and LTE-M |
| WSN Deployment and Sizing | Convert coverage requirements into node, gateway, and cost estimates |
| WSN Energy Management | Model duty cycle, sleep current, and battery lifetime |
| Human-Centric Sensing and DTN Review | Understand store-and-forward operation when continuous connectivity is unavailable |
| Energy-Aware Case Studies | Study practical energy failures and optimisations |