8 Cellular Architecture for IoT
8.1 A Clear First Route
Imagine a moving tracker sends a small alarm through a mobile network and waits for a reply. The team must trace the alarm across each owner and system boundary. Firmware means software stored in a device. Latency means the wait from an event to a useful result. A payload is the useful data carried by a message.
This page starts with one job. Name the device, aerial, identity, radio site, core service, and app. Then note join state, movement, sleep, route, address, and downlink reach. Look for final-device tests, network state, send and receive logs, power, and owner records. Last, choose approve the tested path, narrow it, change a layer, or run a new field trial. Keep the limit in view. A tower icon hides many steps. A fault in any one step can look like a dead device at the app.
8.1.1 Follow One Decision
- What real event starts the case?
- Who needs the result?
- What action may follow?
- Which sign comes from the device?
- How old can that sign be?
- What can make it wrong?
- What must still work after a fault?
- Who owns the next check?
- What change will force a new test?
- What proof should the team keep?
A good record answers each point in plain words. It names the site and the people. It names the device and its state. It says when the event took place. It says when the result arrived. It marks doubt instead of hiding it. It also names the safe fallback. That makes the result useful without making it sound more sure than it is.
8.1.2 Know What This Route Leaves Out
This first route is a guide to the main choice. It does not model every field effect or rare fault. The Practitioner sections add radio and core roles, fit choices, fixed and moving cases, and the review record. Under the Hood adds control and user planes, state changes, small-data paths, mobility, and reachability. Those deeper parts add detail to this route. They do not reverse its main claim.
8.1.3 Read the Result Before You Act
Start with the source, not the final label. Check that the source belongs to this case. Check its time and state. Ask if a second source agrees. If two sources differ, keep that fact in the record. Do not force a clean answer just to fill a screen. A late result may be true about the past and still be unsafe now. A missing result is also useful news when the system shows it at once.
Next, link the result to one owned step. A person may inspect the site. A local rule may hold a safe state. A remote team may ask for more proof. The right step depends on the claim that was tested. It must not depend on a broad product label. Write down the reason for the step. Write down the time. Write down who may close the case.
8.1.4 Use a Calm Review at the Hard Moment
A sound design still has to work on a bad day. The user may be tired. The room may be loud or dark. A device may be low on power. A link may come and go. Two records may reach the screen in the wrong order. The first view should show what happened, when it happened, and what is known now. It should not make the user decode a long list before taking a safe step.
Use a short review. Is this the right device? Is this the right place? Is the time clear? Is the source healthy? Is the result within its stated range? Is a key input absent? Did an old rule shape the result? Can the user ask for help? Can the system fall back to a safe state? Will the record help a later review? Each answer should be easy to find.
8.1.5 Keep Trust Tied to Proof
Trust grows when the system admits its bounds. Show when a value is old. Show when a source is weak. Show when the system has changed modes. Keep raw proof long enough for the right review. Give people a way to correct a bad state. Test the hard path as well as the happy path. Retest after a change to the device, site, rule, link, or owner.
The simple story is not a claim that the work is simple. It is a way to place each hard fact in the right order. Start with the human need. Move through the source and the check. End with an owned act and a clear limit. Then use the deeper sections for the maths, rare faults, and design detail that the case needs.
8.2 Start With the Wireless Story
Cellular architecture matters when one packet crosses many ownership boundaries. Follow the device from radio access through identity, core network, mobility state, data path, and cloud reachability so the IoT service can explain where delays and failures may enter.
8.3 In 60 Seconds
Cellular IoT architecture is a chain of evidence, not just a tower diagram. A device must have a radio and antenna that fit the site, an identity or profile that the operator accepts, a radio access network that can hear it, a core network that can register and route it, and an application path that can carry the intended traffic.
The design review should answer:
- what device, antenna, enclosure, and power state are being reviewed
- what cellular service, operator, region, profile, and supported bands are in scope
- whether the device can register from the intended location
- whether uplink and downlink reachability match the application
- whether mobility, roaming, latency, payload size, and maintenance needs match the selected cellular profile
- what must be retested after firmware, SIM/profile, operator, antenna, enclosure, site, or application changes
The mathematical gist. A 17 dBi sector has 50.1 times the favoured-direction power density of an isotropic reference. Its idealised solid angle is sr, only 2.00% of the sphere, and its free-space range ratio is . Gain redirects power; good RSRP does not prove that identity, subscription, core, or application layers are healthy.
8.4 Learning Objectives
By the end of this review, you will be able to:
- trace IoT traffic from device through radio access, cellular core, and application services
- separate radio coverage, subscription, core registration, packet service, and application failures
- explain why power-saving and reachability decisions are architecture decisions
- evaluate cellular technology fit using evidence rather than fixed marketing claims
- document retest triggers for cellular architecture changes
8.5 Architecture Scope
Use this review when a cellular design must be accepted, compared, or repaired. It applies to LTE-M, NB-IoT, 5G IoT profiles, and other operator-managed cellular options, but the final decision always depends on regional service, operator support, module capability, antenna, enclosure, and application requirements.
The review should produce a record with:
- device evidence: module, firmware, antenna, enclosure, power state, and interface
- identity evidence: SIM, eSIM, profile, subscription, service activation, and operator context
- radio evidence: supported bands, site coverage, signal observations, and registration state
- core evidence: attach, authentication, packet data context, policy, and routing behavior
- application evidence: protocol path, payload pattern, downlink need, backhaul, and failure symptoms
- decision evidence: accepted architecture, accepted with limits, retest required, or redesign required
8.6 Cellular Traffic Path
Inspect Figure 8.1 when a cloud publish fails, because the traffic path shows exactly where radio, subscription, core, routing, power, and application evidence change ownership.
Follow Figure 8.1 from the device and radio access network into the cellular core, then across the data network to the application service. At each boundary, the next proof changes: modem and antenna state, registration and bearer state, addressing and route, then protocol and service response. That ordered walk connects the architecture to the chapter’s diagnostic rule: identify the first failing transition before changing hardware, service profiles, or cloud credentials.
8.7 Device And Radio Access Evidence
Start at the device, because many architecture failures are caused by assumptions made before the network is involved.
Record:
- module and firmware identity
- supported cellular profiles and bands
- antenna type, connector, cable, enclosure, and mounting state
- power source and any resets during attach or transmit attempts
- SIM, eSIM, or profile status
- location, site conditions, and whether the test is bench, pilot, or installed form
Radio access evidence should show whether the device can hear and be heard by a suitable cell from the intended location. A good record ties signal observations to the actual antenna, enclosure, and mounting position.
8.8 Core Network Evidence
After radio access, the core network decides whether the device identity, subscription, service, policy, and packet data path are allowed.
Common review questions:
- Does the SIM or profile match the intended service?
- Is the device registered, searching, denied, roaming, or unknown?
- Does the selected service allow packet data for the application?
- Is the APN or data profile correct for the operator and account?
- Does the core assign routing that reaches the application service?
- Does downlink delivery depend on device wake cycles, paging windows, or application polling?
Do not treat a serial OK response or a signal reading as proof of architecture readiness. Registration and packet-service evidence must be reviewed separately.
8.9 Power, Mobility, And Reachability
Power-saving behavior changes architecture behavior:
- A device in deep sleep may be efficient but not immediately reachable.
- A device that must receive commands quickly may need more frequent listening or a different service profile.
- A mobile asset may need handover and roaming behavior that a fixed sensor does not.
- A stationary buried or indoor device may prioritize coverage and wake-scheduled uplink over continuous reachability.
- Firmware updates, commands, alarms, and diagnostics can change the reachability requirement.
The review should record the required downlink timing, mobility pattern, payload size, and maintenance path before choosing a cellular profile.
8.10 Technology-Fit Review
Cellular options should be compared through evidence categories, not fixed universal rankings.
Before choosing a cellular IoT family, inspect Figure 8.2 to compare the service requirement with coverage, device, power, and operator evidence.
Read Figure 8.2 from workload and site constraints through technology capabilities to the bounded decision. The route connects architectural labels to deployment proof, so no technology is selected from headline range or data rate alone.
Use the map to structure the decision:
- Traffic pattern: small periodic uplink, event-driven alarm, command-response, firmware update, or higher-rate data stream
- Coverage evidence: installed location, antenna and enclosure state, supported bands, and operator service
- Mobility evidence: stationary, portable, moving asset, roaming region, and handover need
- Reachability evidence: how soon commands, updates, or alarms must reach the device
- Operations evidence: provisioning, profile management, monitoring, support process, and retest triggers
Spec sheets are where technology-fit reviews usually start — and where weak ones stop. To practise the difference, take the oldest spec card still haunting IoT deployments and read it the way this chapter reads everything else. Figure 8.3 does exactly that with GPRS.
Every left-hand card in Figure 8.3 is true, and none of it is evidence. The DATA RATE row is the sharpest example: 64–114 kbps is a per-cell headline shared by every attached device, so the review asks for per-device throughput at your sites, under load. The BUILT ON row hides a lifecycle trap — GPRS borrows GSM spectrum, so an operator’s refarming schedule, not your roadmap, decides when it disappears; the NAME row’s sunset question is already concrete in many countries. The same five questions transfer unchanged to any newer spec card: NB-IoT, LTE-M, and RedCap headlines all owe your record the identical site, load, and lifecycle numbers.
8.11 Decision Options
-
Check the device, site coverage, service plan, network, and application claim.
-
Retest with the installed antenna and case when bench results do not match.
-
Keep or change the profile from evidence, changing one part at a time.
- Keep the selected cellular profile when device, coverage, subscription, core, and application evidence all support the claim.
- Retest with installed antenna or enclosure when bench evidence differs from final form.
- Change service profile or operator setup when registration or packet service fails despite suitable radio evidence.
- Change antenna, placement, or enclosure when radio evidence fails before core registration can be judged.
- Change cellular technology when traffic, mobility, reachability, or coverage needs do not match the selected profile.
- Change application behavior when the device architecture is sound but the application assumes immediate downlink or continuous connectivity.
- Escalate to operator or account support when the evidence points to subscription, roaming, policy, or provisioning limits.
Change one architecture variable at a time during diagnosis whenever possible.
8.12 Review Record Template
For each cellular architecture review, record:
- device, module, firmware, antenna, enclosure, power state, and location
- operator, region, SIM/eSIM/profile, subscription, and service context
- supported bands and selected cellular technology
- signal and registration observations
- packet service or data context evidence
- APN, routing, policy, or account constraints, with secrets redacted
- application protocol, payload pattern, uplink and downlink needs
- mobility and roaming assumptions
- first failing layer, if any
- decision, limitation, next action, and retest trigger
8.13 Worked Review: Fixed Indoor Meter
Scenario: a fixed indoor meter sends small periodic readings and only needs delayed maintenance commands.
Good review sequence:
- Confirm the device, antenna, enclosure, mounting, and power state.
- Confirm operator, profile, subscription, supported bands, and service activation.
- Capture signal, registration, and packet-service evidence from the installed location.
- Check whether downlink commands can wait for the device’s scheduled wake or uplink behavior.
- Record whether the selected cellular profile supports the coverage and reachability claim.
Accepted answer: “The architecture decision depends on installed coverage, registration, packet service, and downlink timing evidence. A generic battery-life claim is not enough.”
8.14 Worked Review: Moving Asset Tracker
Scenario: a tracker moves through several regions and must report events while in motion.
Good review sequence:
- Record mobility route, roaming or operator context, and supported bands.
- Check whether the selected service supports the expected movement and regional coverage.
- Review registration behavior across representative locations.
- Review payload size, event timing, and downlink command needs.
- Record retest triggers for new region, antenna, enclosure, firmware, profile, or operator changes.
Accepted answer: “Mobility and regional service evidence are part of architecture fit. A stationary-device assumption cannot be reused for a moving asset without retest.”
8.15 Common Mistakes
- treating signal quality alone as proof that the cellular architecture is ready
- ignoring SIM, eSIM, profile, subscription, APN, or account policy evidence
- assuming one cellular technology is always best for every IoT workload
- using bench antenna evidence as final installed evidence
- choosing power-saving behavior before documenting downlink reachability needs
- ignoring mobility, roaming, and regional service requirements
- mixing radio, core, backhaul, and application failures into one vague “cellular problem”
- publishing secrets, subscriber identifiers, APNs, or credentials in review records
- omitting retest triggers after firmware, profile, operator, antenna, enclosure, site, or application changes
8.16 Knowledge Check: Cellular Architecture
8.17 Match The Architecture Evidence
8.18 Order The Cellular Architecture Review
8.19 Review Checklist
Before accepting the cellular architecture review, confirm that the record includes:
- device, module, firmware, antenna, enclosure, power state, and location
- operator, region, SIM/eSIM/profile, subscription, and service activation context
- supported bands and selected cellular technology
- signal, registration, and packet-service evidence
- APN, data profile, routing, policy, and account constraints with secrets redacted
- application protocol path, payload pattern, uplink and downlink needs
- mobility, roaming, and regional assumptions
- first failing layer for any failed test
- architecture decision and limitations
- retest triggers after firmware, SIM/profile, operator, antenna, enclosure, site, routing, or application changes
8.20 Base Station Plus Core, Split Into Two Planes
A cellular network has two halves: the radio access network (the base stations — an eNodeB in LTE, a gNB in 5G) and the core network behind it. The core does the work a device never sees: authenticating the SIM, tracking which cell the device is in, and routing its data to the internet.
The core separates a control plane (signalling: who you are, where you are, setting up connections) from a user plane (the actual data packets). In LTE the core is the EPC; in 5G it is the service-based 5G Core (5GC). For IoT, this split is the key to efficiency, because tiny messages should not pay the full price of user-plane setup.
That split also gives the review a clean failure order. First prove that the installed device can hear and be heard by the RAN with its real antenna, enclosure, and power state. Next prove that the control plane accepts the identity, location, mobility, and service request. Only after those two claims are true does a failed MQTT, CoAP, HTTPS, or private APN path become an application or routing problem rather than a vague cellular problem.
A useful architecture note therefore names the first missing proof. “Good RSRP but attach denied” points at identity, subscription, roaming, or policy. “Attached but no packet data context” points at APN, service profile, or core routing. “Packet data works but downlink commands arrive late” points at paging, sleep state, polling, or application timing. The diagram is a checklist for separating those claims.
Mental model: eNodeB/gNB = the radio; EPC/5GC = the brain, and the brain keeps “who/where” (control plane) separate from “the data” (user plane). A design is ready only when the review has evidence at each boundary, not just a signal bar.
8.20.1 Overview Knowledge Check
8.21 EPC Elements, 5GC Equivalents, and RRC States
The LTE EPC has a small cast, each mirrored by a 5GC network function:
| Role | LTE (EPC) | 5G (5GC) |
|---|---|---|
| Control: auth, mobility | MME | AMF |
| Session management | (part of MME/S-GW) | SMF |
| User-plane gateway | S-GW + P-GW | UPF |
| Subscriber database | HSS | UDM |
Older GSM and UMTS diagrams use different names, but the review habit is the same. A BSC or RNC controls radio resources at the base-station edge. An MSC handles circuit-switched mobility and call control. An SMSC stores and forwards text messages. The HLR and VLR are subscriber and visitor-location databases, and SS7 is the signalling fabric that lets those systems ask who the device is, where it is, and which service or billing state is allowed.
The source-era SMS example makes the store-and-forward boundary concrete. It records a 140-byte payload, a broadcast capability, and carrier economics in which trillions of penny-priced messages could still produce billions in revenue because the claimed markup was roughly 1000 times the underlying cost. Treat those figures as the source’s historical service record, not as a current tariff. For an IoT review, the durable questions are whether the payload fits, whether one-to-one or broadcast delivery is intended, which SMSC owns storage and retry, and how price at fleet scale changes the design.
For an IoT architecture review, those legacy boxes are not trivia. They are control-plane proof points: identity, location, roaming, service policy, prepaid or billing status, and message-store behavior must line up before the user-plane packet path, voice path, or application workflow can be trusted.
| Legacy cellular name | Review question it represents |
|---|---|
| BSC / RNC | Which radio controller owns handoff, channel, and base-station resource evidence? |
| MSC | Which switch or control function handles mobility, call setup, and service reachability? |
| SMSC | Where are short messages stored, retried, or dropped before the application sees them? |
| HLR / VLR | Which database proves subscriber identity, home service, visited location, and roaming state? |
| SS7 | Which signalling path carries identity, location, routing, and service-control requests? |
A device’s radio link has RRC states. In RRC_IDLE it has no active connection and is only paged for downlink; in RRC_CONNECTED it has a live radio connection for data. To see why the state model matters to short IoT transfers, inspect the transition paths and power ranges in Figure 8.4 before following a device wake-up.
Read Figure 8.4 by tracing the 3G ladder and its intermediate states first, then the simpler LTE connected-to-idle transition. Notice both transition delay and the indicative power range: preserving or releasing context changes how quickly traffic resumes and how long the radio remains costly or reachable. In a field record, do not collapse those states into “the network.” If packets move only after repeated wakes, RRC transition and paging evidence now connects the radio state machine to the service symptom.
The practical handoff is a small ledger: observed state, first failing transition, evidence source, and next variable to change. Example rows might be “IDLE to CONNECTED succeeds from installed enclosure,” “attach denied on the intended profile,” or “UPF or P-GW path reaches private endpoint but application authentication fails.” This style prevents expensive retests that change firmware, SIM profile, antenna placement, and cloud credentials at the same time.
Worked example. An LTE-M tracker wakes to send a position. It transitions IDLE → CONNECTED, the MME authenticates and sets up the path through S-GW/P-GW, data flows, then it returns to IDLE. For a smartphone streaming video this setup cost is negligible; for a tracker sending 20 bytes it is enormous overhead — which is the problem the IoT optimizations below solve.
8.21.1 Practitioner Knowledge Check
8.22 CIoT Optimizations for Small Data
Setting up a full user-plane path to move 20 bytes is wasteful, so 3GPP defined CIoT EPS optimizations. The Control-Plane optimization (mandatory for NB-IoT) carries the small payload inside control-plane signalling (NAS messages) to the MME, skipping data-radio-bearer setup entirely — ideal for rare, tiny messages. The User-Plane optimization instead lets the device suspend and resume its connection (keeping context, like RRC_INACTIVE), avoiding a full re-establishment for slightly larger or more frequent traffic.
A companion feature, Non-IP Data Delivery (NIDD), ships the payload without an IP header through the SCEF (Service Capability Exposure Function) straight to the application server. For a device whose whole message is a few bytes, an IP/UDP header would be pure overhead; NIDD removes it.
The design choice is a boundary decision, not a feature checklist. Control-plane small data is strongest when the payload is tiny, infrequent, tolerant of operator exposure functions, and not trying to behave like a normal IP session. User-plane resume is stronger when the device sends bursts, needs familiar IP transport, or must reuse a session without paying the full connection setup every time. NIDD is useful only if the operator path, application integration, security review, and support model all exist for that deployment; otherwise an ordinary IP path may be simpler even if it carries more header overhead.
Under-the-hood review should therefore record what overhead is being avoided and what new dependency is introduced. A water meter that sends a short reading every hour may reasonably trade direct IP visibility for lower signalling and energy. A tracker that sends event bursts, expects acknowledgements, or downloads configuration may need user-plane behavior despite the extra setup. If a later firmware release changes the payload size, acknowledgement pattern, encryption wrapper, or downlink timing, the optimization choice must be retested rather than inherited from the old architecture.
Worked example. An NB-IoT water meter sends 12 bytes once an hour. With Control-Plane optimization and NIDD, those 12 bytes ride NAS signalling to the MME and exit via the SCEF to the utility’s server — no data bearer set up, no IP header attached. Use Figure 8.5 to compare that route with the ordinary user-plane route before deciding which dependency the optimization removes and which operator dependency it introduces.
Trace Figure 8.5 from the UE through the CIoT RAN, then take each branch separately. The upper control-plane branch carries small data toward the MME and SCEF for NIDD; the lower user-plane branch uses SGW and PGW functions for a conventional packet path. Both reach services, but through different interfaces and operational owners. That comparison connects the saved bearer and header overhead to the chapter’s design boundary: payload pattern, IP needs, operator support, security, and downlink behavior determine the defensible route.
8.22.1 Under-the-Hood Knowledge Check
8.23 Summary
Cellular architecture review connects device evidence, radio evidence, identity evidence, core network evidence, and application evidence. The design is ready only when the whole path supports the deployment claim. Useful records avoid universal battery, cost, or range promises and instead show what was tested, what layer failed first, what decision follows, and what changes require retest.
8.24 Key Takeaway
Cellular Architecture for IoT should compare mobile wireless choices using coverage, capacity, spectrum rules, propagation, power, cost, resilience, and deployment evidence.
8.25 Concept Relationships
- Cellular spectrum explains why operator support, region, and supported bands shape architecture fit.
- Cellular modem labs provide the AT-command evidence used to prove registration and packet-service readiness.
- Coverage planning labs connect architecture assumptions to installed signal and site evidence.
- Propagation design explains why antenna, enclosure, and location change cellular results.
- Mobile wireless review compares cellular architecture evidence with Wi-Fi and other wireless options.
8.26 What’s Next
- Cellular Spectrum for IoT reviews cellular band and operator context.
- Lab: Cellular Modem Bring-Up shows how to collect registration and packet-service evidence.
- Lab: Coverage Planning connects cellular observations to site coverage decisions.
- Wireless Propagation and Design explains antenna, enclosure, and location effects.
- Mobile Wireless Comprehensive Review compares cellular architecture fit with other wireless options.