Chapter 5 — 5G Network Technologies and the Internet of Things

The fifth generation of cellular and the Internet of Things share the same chapter because they share the same business case. The unit economics of cellular for the last two decades came from billing human users for voice and data. The unit economics that 5G needs to justify the capital cost of its rollout come from billing things — sensors, vehicles, robots, smart meters, drones, medical devices — for connectivity. The IoT side of the chapter is the demand; the 5G side is the supply that 4G could not provide. Edge computing and cyber-physical systems are the architectural and application patterns that connect the two.

5.1 Definition, overview, applications, potential, and challenges

What 5G is

5G is the fifth-generation mobile network standard, defined by 3GPP starting with Release 15 (2018) and conforming to the ITU-R IMT-2020 requirements, designed to support three classes of service — enhanced Mobile Broadband (eMBB), Ultra-Reliable Low-Latency Communications (URLLC), and massive Machine-Type Communications (mMTC) — over a unified radio and core architecture.

This is the defining shift from 4G. Every generation up to 4G optimised for one workload — voice (1G–2G), then mobile data (3G–4G). 5G is the first generation designed for three workloads explicitly, which means a single network must simultaneously deliver gigabit downloads to a streaming user, sub-millisecond control loops to a factory robot, and ten-year-battery connectivity to a water meter. Network slicing (Section 5.4) is how a single 5G network presents itself as three different networks to three different customer types.

The IMT-2020 targets

ITU-R IMT-2020, published in 2017, lays out the performance targets 5G technologies must meet to qualify:

Capability	Target
Peak data rate	20 Gbps downlink, 10 Gbps uplink
User-experienced rate	100 Mbps downlink, 50 Mbps uplink
Spectral efficiency	3× IMT-Advanced (4G)
Mobility	Up to 500 km/h
Latency (radio)	1 ms for URLLC
Connection density	1 million devices per km²
Energy efficiency	100× improvement over 4G
Area traffic capacity	10 Mbps per m²

Real deployments rarely hit all of these targets simultaneously — they are upper bounds for specific configurations. A real 5G handset on a real Nepali network in 2026 might see a few hundred megabits down, not 20 Gbps.

The three service classes

eMBB (enhanced Mobile Broadband). What most consumers think of as 5G. Faster downloads, smoother high-definition video, lower latency for web browsing and gaming. Uses sub-6 GHz spectrum (the 3.5 GHz n78 band globally, the 2.6 GHz n41 band that NTC plans to use) for coverage, and millimetre wave spectrum (24 GHz, 28 GHz, 39 GHz) for capacity in dense areas.

URLLC (Ultra-Reliable Low-Latency Communications). Industrial automation, autonomous vehicles, remote surgery, electricity-grid protection. Targets 1 ms radio latency and 99.999% reliability for a single packet. Hard to achieve simultaneously — reliability typically requires retransmissions, which adds latency — so URLLC is the most demanding 5G class.

mMTC (massive Machine-Type Communications). Low-power IoT. Smart meters, environmental sensors, asset trackers. Each device may communicate only a few times per day with a few bytes per message. The challenge is supporting 10⁶ devices per km² without overloading the network. Narrowband IoT (NB-IoT) and LTE-M, technically 4G technologies that continue to be integrated into 5G, address most current mMTC use.

Applications

The application space is broad enough that any classification is incomplete. Common groupings:

Consumer. High-definition streaming, cloud gaming, AR/VR overlays in real-time, fixed wireless access (5G replacing fibre to the home in places where fibre is hard to deploy).

Industry 4.0. Factory automation, robotics, computer vision on the production line, augmented reality for maintenance workers, asset tracking inside the factory.

Smart cities. Traffic-light coordination, smart parking, air-quality monitoring, smart streetlights, video analytics for public safety. The Kathmandu Metropolitan City has explored smart-city pilots since 2020; load shedding and budget constraints have limited progress.

Healthcare. Remote patient monitoring, telemedicine with high-resolution video, ambulance pre-arrival diagnostics, hospital-internal IoT for patient tracking and equipment management.

Transport. Connected vehicles (V2X — vehicle-to-everything), railway signalling, fleet management, drone control beyond visual line of sight.

Energy. Smart-grid distribution automation, demand response, micro-grid coordination. The Nepal Electricity Authority's smart-meter rollout, started in 2022 in Kathmandu and Lalitpur, will eventually need 5G or LTE-M connectivity at scale.

Agriculture. Precision agriculture with soil and weather sensors, livestock tracking, automated irrigation. Tarai-region pilots have used LoRaWAN through the 2020s; 5G NB-IoT is the natural future.

Potential

The economic potential is the question every operator and regulator is asking. Estimates vary wildly. McKinsey projections (2025) put global 5G-enabled economic impact at USD 1.3 trillion by 2030; GSMA estimates around USD 1 trillion; sceptics put it lower. The honest position is that the consumer revenue from 5G alone — slightly faster mobile data — is unlikely to recover the deployment cost. The bet is that enterprise services (private 5G networks, network slicing for industry-specific SLAs, IoT connectivity at scale) will make up the gap.

For Nepal, the economic case is muted. As of mid-2026, neither NTC nor Ncell has commercially launched 5G. NTC conducted trials in Kathmandu starting February 2023 but full commercial rollout depends on NTA spectrum allocation that has not yet been completed. Ncell formally requested 5G trial spectrum (15 MHz in the 700 MHz band and 100 MHz in the 2600 MHz band) and CEO Michael Foley at the Kantipur Conclave 2026 said Ncell is ready to invest USD 200–250 million subject to its operating licence being extended beyond its 2029 expiry. Most industry observers expect commercial 5G in Nepal in late 2026 or 2027.

Challenges

The challenges are technical, economic, and regulatory.

Spectrum. 5G needs spectrum at multiple bands — sub-1-GHz for coverage, 1–6 GHz for capacity-coverage balance, and mmWave for high-density capacity. Each band needs to be cleared of incumbents, allocated to operators (auction or administrative process), and licensed under terms that allow deployment. Nepal's NTA has been slow on 5G spectrum auctions, which is the bottleneck industry watchers keep flagging.

Capital cost. A nationwide 5G network costs an operator hundreds of millions of dollars in capital — new radio hardware at every site, often densification with new sites, upgraded backhaul, new core network functions. For an operator like NTC, this is comparable to a year of operating profit. For Ncell, it depends on licence renewal — they will not invest USD 250 million if they have to exit in 2029.

Device ecosystem. 5G handsets exist at every price point now, but they have to actually be in users' hands. Smart meters, sensors, and other IoT devices with NB-IoT modules are a small fraction of the global IoT market.

Energy. A 5G base station consumes 2–3× the power of a 4G base station. For NTC, with thousands of base stations across mountainous terrain often running on diesel or solar, the energy footprint is significant. The 100× energy-efficiency-per-bit target is achievable in lab conditions but not always in field deployments.

Backhaul. 5G radio rates exceed what most existing fibre-to-the-tower links can carry. Many sites in Nepal still run on microwave links sized for 4G; upgrading them to 10 Gbps fibre or higher-capacity microwave is a multi-year capex programme.

Security. New surface area. 5G has a larger control plane than 4G, more virtualised components, new air-interface protocols, more API endpoints. Each addition is an opportunity for vulnerabilities. Chapter 6 returns to the security challenges of the latest networking environment.

Standalone (SA) vs Non-Standalone (NSA) confusion. NSA 5G uses 5G radio for capacity but keeps the 4G EPC for the core, faster to deploy but does not deliver the URLLC and slicing benefits. SA 5G uses a 5G New Radio and a 5G core, slower to deploy but delivers the full 5G feature set. Most early deployments globally were NSA; the migration to SA is the current phase.

Health and political opposition. A persistent low-level public concern about radio-frequency exposure from 5G, often amplified by misinformation, has caused deployment delays in some countries. WHO and most national health regulators continue to find no evidence of harm at exposure levels below the established ICNIRP limits, and 5G base stations operate well below those limits, but the political sensitivity is real.

5.2 5G evolution and applications

The cellular generational timeline

Generation	Decade	Defining technology	Key capability
1G	1980s	Analogue AMPS, NMT, TACS	Voice, no data
2G	1990s	GSM, CDMA (IS-95)	Digital voice, SMS, low-rate data (GPRS, EDGE)
3G	2000s	UMTS (WCDMA), CDMA2000	Mobile data (kbps to a few Mbps)
4G	2010s	LTE, LTE-Advanced	All-IP packet network, tens to hundreds of Mbps, VoLTE
5G	2020s	NR, 5G Core	eMBB / URLLC / mMTC, network slicing
6G	2030s (expected)	ITU-R IMT-2030, 3GPP Rel-21+	Integrated sensing + communication, sub-1ms latency

Within 5G — 3GPP releases

3GPP publishes 5G in releases:

Release	Frozen	Theme
Rel-15	2018	5G Phase 1: NR, NSA, basic SA
Rel-16	2020	5G Phase 2: URLLC enhancements, V2X, industrial IoT
Rel-17	2022	5G Advanced foundation, NB-IoT/LTE-M integration, NTN (non-terrestrial networks)
Rel-18	2024	5G Advanced (5G-A), early AI/ML in air interface
Rel-19	In progress 2025–26	Continued 5G-A, more sensing-and-communication, sustainability
Rel-20 onwards	Pre-6G study items

Most current operator deployments globally are on Rel-15 or Rel-16. Rel-17 enhancements are rolling in. 6G work is in the study-item phase.

Frequency bands

5G uses three main spectrum ranges, each with different trade-offs.

Low band (below 1 GHz). Travels far, penetrates walls well, but offers limited bandwidth. Used for coverage. Bands include n5 (850 MHz), n28 (700 MHz). Ncell's requested 700 MHz spectrum sits here.

Mid band (1–6 GHz). The workhorse of 5G. Balances coverage and capacity. The global flagship is n78 (3.5 GHz, sometimes called C-band) which most countries have allocated. n41 (2.6 GHz, NTC's planned band) is also mid-band. n77 (3.7 GHz) is used in the US.

High band / millimetre wave (24–100 GHz). Massive bandwidth — hundreds of MHz to GHz of contiguous spectrum — but extremely short range and easily blocked by walls, leaves, hands. Used for capacity in stadiums, malls, dense urban areas. Verizon and AT&T have deployed extensively in the US; most of Asia has been slower because mid-band gives a better economic return.

The hard part about 5G frequency planning is that no single band does everything. A real network needs a mix.

Applications, revisited

Applications fall along a maturity curve:

Mature and deployed. Enhanced mobile broadband to consumers; fixed wireless access to homes; private 5G networks in mines, ports, and manufacturing plants.

Emerging. Network slicing for enterprise customers; URLLC for industrial automation; NB-IoT for smart meters and asset tracking.

Future. Drone fleet management, autonomous vehicles, holographic communication, integrated sensing and communication.

For Nepal, the realistic 5G application set in the next 3–5 years is:

• Enhanced mobile broadband in urban areas (Kathmandu Valley, Pokhara, Biratnagar, Birgunj, Bhairahawa).
• Fixed wireless access as a faster-deployment alternative to FTTH in towns where fibre is expensive.
• NB-IoT for the NEA smart-meter rollout and water-utility sensors.
• Private 5G for industrial customers — major manufacturing, larger hospitals, possibly the upcoming Pokhara and Bhairahawa airports.

5.3 5G building blocks and architecture

The 5G architecture has two main parts — the Radio Access Network (RAN) that connects users to the network, and the Core that handles authentication, mobility, session management, and connection to external networks. Both are radically redesigned compared to 4G.

High-level architecture

+-----+         +--------+         +-------------+        +-----+
| UE  | <-----> |  gNB   | <-----> |  5G Core    | <----> | DN  |
| (UE)|  NR     |        |  N2/N3  | (5GC)       |  N6    |     |
+-----+         +--------+         +-------------+        +-----+
                                       |
                                       v
                                   +-------+
                                   |  MEC  |  (edge computing)
                                   +-------+

• UE (User Equipment) — the phone, sensor, vehicle, or other device.
• gNB (gNodeB) — the 5G base station, replacing the 4G eNodeB.
• 5GC (5G Core) — the cloud-native core network composed of service-based network functions.
• DN (Data Network) — the Internet, an enterprise network, or a service-specific network.
• MEC (Multi-access Edge Computing) — application servers physically close to the user.

The 5G Radio Access Network

The 5G RAN introduces several major changes from 4G:

New Radio (NR). NR (New Radio) is the 5G physical-layer radio interface, designed by 3GPP starting in Rel-15, supporting both sub-6 GHz and mmWave bands, scalable subcarrier spacings (15 kHz, 30 kHz, 60 kHz, 120 kHz, 240 kHz) to suit different latency and bandwidth requirements, and massive MIMO with hundreds of antenna elements at the base station. NR uses Cyclic-Prefix OFDM in downlink and either CP-OFDM or DFT-spread-OFDM in uplink. The numerology (subcarrier spacing, slot duration) is configurable, letting the same air interface serve eMBB (15 kHz, long slots, high spectral efficiency) and URLLC (60 kHz, short slots, low latency).

Massive MIMO and beamforming. A 5G base station can have 64, 128, or 256 antenna elements. The base station forms narrow beams aimed at individual users, increasing both signal strength and spatial reuse. This is critical at mmWave where the signal would otherwise not reach.

Disaggregated gNB — CU, DU, RU. The 4G eNodeB was a single physical unit. The 5G gNB is split into three:

• RU (Radio Unit) — the antenna and RF front-end at the cell site.
• DU (Distributed Unit) — physical and MAC layer processing, usually within a few kilometres of the RU.
• CU (Centralised Unit) — higher-layer processing, hosted in a regional data centre, serving many DUs.

The interfaces between them are open: F1 between DU and CU, eCPRI between RU and DU. The Open RAN movement standardises these interfaces further to enable multi-vendor deployments.

Open RAN. Open RAN (O-RAN) is the industry effort, led by the O-RAN Alliance, to open the previously proprietary interfaces inside the 5G RAN — between RU, DU, CU, and the RAN Intelligent Controller — so that operators can mix hardware and software from different vendors. Open RAN is in active deployment with operators like Vodafone (Europe), Rakuten (Japan), Reliance Jio (India). The promise is reduced cost and vendor lock-in; the reality has been more complicated, with maturity and integration challenges still working through.

The 5G Core (5GC)

The 5GC is the cloud-native rebuild of the 4G Evolved Packet Core. Instead of monolithic gateways (MME, SGW, PGW), the 5GC is built from a set of Network Functions (NFs) that communicate over a Service-Based Architecture (SBA) using HTTP/2 with JSON payloads — the same kind of REST APIs used in enterprise microservices.

Key network functions:

Function	Role
AMF (Access and Mobility Management Function)	Handles registration, authentication, mobility
SMF (Session Management Function)	Handles PDU sessions, IP address allocation
UPF (User Plane Function)	The data plane — forwards user packets to/from the DN
AUSF (Authentication Server Function)	Authentication of UE
UDM (Unified Data Management)	Subscriber data — subscription, security keys
UDR (Unified Data Repository)	Database backing UDM, PCF, NEF
PCF (Policy Control Function)	QoS and charging policy
NRF (NF Repository Function)	Service registry — lets NFs discover each other
NEF (Network Exposure Function)	Exposes services to external applications via APIs
NSSF (Network Slice Selection Function)	Selects the right slice for a UE
NWDAF (Network Data Analytics Function)	Collects data and produces analytics, often using ML

The Service-Based Architecture is a microservices design. Each NF exposes its capabilities as HTTP/2 REST APIs registered with the NRF. Other NFs discover and call those APIs. This is fundamentally different from 4G's point-to-point GTP signalling.

The split between control plane and user plane (CUPS — Control and User Plane Separation, started in 4G Rel-14) is fundamental to the 5GC. The UPF (data plane) can be placed anywhere — at the central data centre for normal traffic, at the edge for low-latency traffic, at a customer's premises for private networks.

Putting it together — a user session

When a 5G handset comes up on the network:

1. UE attaches via the gNB, which forwards the registration request to the AMF over the N2 interface.
2. AMF works with AUSF and UDM to authenticate the UE using the secret key stored in the SIM/USIM/eSIM.
3. UE requests a PDU session — IP connectivity. AMF picks an SMF.
4. SMF allocates an IP address (IPv4, IPv6, or both), picks a UPF for the user-plane traffic, and configures the UPF.
5. UE traffic now flows: UE → gNB → UPF → DN.

For a network slice, the NSSF determines which AMF, SMF, and UPF serve this UE in this slice, possibly different from the UE's default slice.

Standalone vs Non-Standalone

Non-Standalone (NSA, Option 3). 5G NR radio attached to the existing 4G EPC core. The UE registers with the 4G MME and gets data via either the 4G eNodeB or the 5G gNB (dual connectivity). NSA is faster to deploy because the operator does not need to build the 5G core, but it does not deliver URLLC, network slicing, or any of the 5GC-dependent benefits.

Standalone (SA, Option 2). 5G NR radio attached to a new 5G Core. Full 5G functionality. More expensive to deploy because of the core network build-out.

Most early commercial 5G deployments globally (China, Korea, USA) launched NSA and have been migrating to SA. As of 2026 a clear majority of operators have moved or are moving to SA. Nepali operators, when they launch commercially, will likely go directly to SA — they are late enough to skip the NSA phase.

5.4 5G network slicing

Network slicing is the 5G capability that lets a single physical 5G infrastructure be partitioned into multiple logical end-to-end networks (slices), each with its own QoS, security, and topology characteristics, presented to different customer types as if each had its own dedicated network.

Slicing is the architectural answer to the three-service-class problem. The same gNB, the same fibre backhaul, and the same 5GC must serve a smartphone user, a factory robot, and a smart meter — each with different latency, throughput, and reliability targets. A slice is a way of carving out the right resources and configuration for each.

What a slice is, technically

A slice is identified by an S-NSSAI (Single Network Slice Selection Assistance Information):

• SST (Slice/Service Type) — 8-bit value identifying the slice type. 3GPP defined standard values: 1 = eMBB, 2 = URLLC, 3 = mMTC, 4 = V2X.
• SD (Slice Differentiator) — 24-bit value identifying a specific customer or service within the slice type.

A UE can be allowed up to eight slices (eight S-NSSAIs) simultaneously, with one selected as default. The home network has a list of slices the UE may use; the serving network honours that subject to its own capabilities.

What a slice contains

End-to-end, a slice spans:

• Radio resources. A share of the gNB's spectrum and scheduling, possibly with reserved minimum bandwidth, scheduling priority, and specific PHY parameters (numerology suited to the slice's latency target).
• Transport. The backhaul and the metro/long-haul transport between the gNB and the 5GC. Slice traffic is identified — often by VLAN, by VXLAN, or by SRv6 segment — and treated according to slice QoS.
• Core network functions. Each slice has its own AMF (or shares one), its own SMF, its own UPF. The functions are instantiated for the slice with the right configuration. A URLLC slice might run its UPF at the edge close to the user; an mMTC slice runs the UPF centrally because latency is not a concern.
• External connectivity. Different slices may terminate at different external networks — one to the public Internet, another to a specific enterprise's VPN, another to a private application server in the operator's edge.

Slice provisioning

A slice is described by a template (a Network Slice Template, or NEST) that defines its required resources and SLA. The operator's orchestration layer — typically a network slice management function on top of NFV MANO — instantiates the slice by deploying the required network functions, configuring the radio and transport, and registering the slice with the NSSF.

Slicing in practice

By 2025–26 slicing has moved from concept demos to early commercial deployment. Examples:

• Deutsche Telekom and Verizon offer enterprise slices with specific QoS guarantees for customers like manufacturing plants and live broadcasting.
• China Mobile and China Telecom have deployed slices for industrial customers (mining operations, ports).
• Reliance Jio in India offers slicing for enterprise customers under the "Jio Business" portfolio.

For Nepal, slicing is a future capability that depends on full SA 5G deployment. When NTC and Ncell launch commercial 5G, the early offerings will be eMBB without slicing. Slicing will likely arrive 2–3 years after commercial launch, initially for enterprise customers like the larger banks, Daraz, and the Tribhuvan University Teaching Hospital.

Security implications of slicing

Slicing means the same physical equipment hosts traffic from different customers with different trust levels. The isolation between slices must be cryptographically and operationally sound. A vulnerability that lets traffic leak between slices defeats the entire point. The 3GPP security working group has produced specific specifications (TS 33.501) covering slice isolation, and it remains an active research and audit area.

5.5 IoT vision, paradigm, and core technologies — RFID and WSN

The IoT vision

The Internet of Things is the network of physical objects equipped with sensors, actuators, and connectivity that exchange data with each other and with networked applications, allowing them to be sensed and controlled remotely and to participate in larger automated processes.

The term was coined by Kevin Ashton at Procter & Gamble in 1999, in the context of using RFID tags to track inventory through a supply chain. The vision has expanded: from passive RFID tags to active sensors, from inventory to every category of physical object, from corporate supply chains to consumer devices, smart cities, and industrial automation.

The IoT paradigm rests on three principles:

1. Identification. Every thing has a unique identifier (a tag, an EPC, a serial number, an IPv6 address).
2. Sensing. The thing measures something about itself or its environment (temperature, location, motion, vibration, image, sound).
3. Communication. The thing exchanges data with the rest of the network, either continuously, periodically, or in response to events.

Devices in IoT differ from traditional computing endpoints along several axes:

• Power. Most IoT devices run on small batteries (years on AA cells, or coin cells), on harvested energy (solar, vibration), or — in the case of passive RFID — on the reader's RF energy. Every protocol choice trades off power.
• Compute. A typical IoT MCU has hundreds of kilobytes of flash and tens of kilobytes of RAM. TLS handshakes that a server does without thinking are expensive on these devices.
• Connectivity intermittence. Many devices sleep for hours and wake briefly to transmit.
• Lifetime. A smart meter is expected to operate for 10–20 years. The cryptography, the protocols, and the device-management story must all survive that long.
• Scale. Deployments of millions of devices are common. Operational practices (firmware updates, key rotation) must scale.

RFID

RFID (Radio-Frequency Identification) is the technology in which a small tag, powered either passively by the reader's radio signal or actively by its own battery, transmits a unique identifier and optionally additional data over a short-range radio link to a reader, enabling automatic identification of physical objects.

RFID has three main categories:

Passive RFID. No battery. The tag harvests energy from the reader's RF field and transmits using backscatter modulation. Common in inventory tags, library books, supply-chain tracking, e-passport chips, contactless access cards.

• LF (125–134 kHz) — animal tagging, car immobilisers. Range a few cm.
• HF (13.56 MHz) — NFC, library books, payment cards. Range up to 1 m.
• UHF (860–960 MHz) — supply chain, retail. Range up to 10 m.

Active RFID. Battery-powered tag, transmits at its own initiative. Used for high-value asset tracking, cargo containers, vehicle tracking. Range hundreds of metres.

Semi-passive (battery-assisted passive). Battery powers the tag's sensor and logic but not its transmission, which still uses backscatter. Useful for cold-chain monitoring (the tag's battery powers a temperature sensor that logs continuously).

EPC (Electronic Product Code). The standard data format for RFID tags in supply-chain use, managed by GS1. The EPC encodes a unique identifier that can be looked up in a global database to find the product's identity and history.

In Nepal, RFID is most visible in:

• E-passport chips at the Department of Passport.
• Contactless payment cards (Visa PayWave, Mastercard Contactless) at major retailers.
• Library books at major universities (Tribhuvan University, Kathmandu University).
• Vehicle access cards at gated communities and corporate parking lots.
• Inventory management at large pharmacy chains and warehouses.

Wireless Sensor Networks (WSN)

A WSN (Wireless Sensor Network) is a collection of spatially distributed, autonomous, battery-powered sensor nodes that cooperate over wireless links to monitor physical or environmental conditions and forward measurements to a central collection point or sink.

A typical WSN node has:

• A sensor (or several) — temperature, humidity, light, accelerometer, gas, sound.
• A microcontroller — often an 8-bit, 16-bit, or low-power 32-bit MCU.
• A radio — a short-range, low-power wireless transceiver.
• A battery (often non-rechargeable, sometimes harvested).

WSN radios commonly use:

IEEE 802.15.4. The PHY/MAC standard for low-power wireless. Operates in 868 MHz, 915 MHz, and 2.4 GHz bands. Throughput 20–250 kbps. The foundation for Zigbee, Thread, ISA100.11a, WirelessHART, 6LoWPAN.

Zigbee. A higher-layer stack on top of 802.15.4 standardised by the Connectivity Standards Alliance (formerly Zigbee Alliance). Used in smart-home devices (Philips Hue lights, Samsung SmartThings hubs) and industrial sensors. Mesh networking is built-in.

Thread. A more recent low-power mesh stack from the Thread Group, IPv6-native (uses 6LoWPAN), part of the Matter smart-home standard that consolidates Apple HomeKit, Google Home, and Amazon Alexa under a common protocol.

Bluetooth Low Energy (BLE). Lower-cost than Zigbee for short-range, point-to-point use cases. Now also supports mesh (Bluetooth Mesh).

LoRaWAN. A long-range, low-power wide-area technology operating in sub-GHz unlicensed bands. Range of several kilometres in line-of-sight conditions, kilometres in urban environments. Deployed for utility metering, agricultural sensing, asset tracking. Nepali deployments include several Tarai agriculture pilots from Practical Action and ICIMOD, and small smart-city sensor deployments in Pokhara and Lalitpur.

NB-IoT and LTE-M. Cellular IoT, integrated into 4G and 5G. Operates in licensed cellular spectrum. The operator provides the connectivity; the device subscriber pays a small monthly fee. Better device-management, better security, better deep-indoor penetration than LoRaWAN, at the cost of a paid SIM and slightly higher device power. NTC and Ncell support NB-IoT in principle but commercial offerings are limited.

WSN architecture and protocols

A typical WSN has:

• Sensor nodes at the leaves.
• Cluster heads or routers in the middle, aggregating data from leaf nodes.
• A sink (or gateway) that forwards the aggregated data to the wider Internet.

Routing protocols designed for WSN:

• AODV (Ad hoc On-Demand Distance Vector) — reactive, used in early sensor networks.
• RPL (Routing Protocol for Low-Power and Lossy Networks) — IETF standard (RFC 6550), the dominant WSN routing protocol now. Builds a DAG (Directed Acyclic Graph) rooted at the sink. Used by 6LoWPAN and Thread.

Application-layer protocols:

• CoAP (Constrained Application Protocol, RFC 7252) — a REST-like protocol for constrained devices. Like HTTP but over UDP, with smaller headers and binary encoding. Used in many sensor networks and in OMA Lightweight M2M (LwM2M).
• MQTT (Message Queuing Telemetry Transport) — a publish-subscribe protocol over TCP. Widely used in IoT cloud platforms (AWS IoT, Azure IoT Hub, Google Cloud IoT).
• MQTT-SN (MQTT for Sensor Networks) — a variant of MQTT for non-TCP networks.

5.6 IoT networking challenges

The challenges differ from the challenges of human-Internet networking, sometimes in degree and sometimes in kind.

Scale

A single utility's smart-meter deployment can be millions of devices. The Nepal Electricity Authority has over 6 million customers; full smart-meter rollout would mean 6 million IoT endpoints. A network designed for tens of thousands of subscribers per cell does not scale to thousands of static devices per cell — different MAC scheduling, different signalling, different identity infrastructure.

Power

A smart meter on the wall has no power constraint (it is connected to the meter), but a soil moisture sensor in a field of millet runs on a small battery for years. Every protocol choice — radio modulation, transmission interval, security overhead — has a power cost. The challenge is delivering useful function while keeping the per-day power budget at microwatts.

Heterogeneity

An IoT deployment combines many device classes, many radio technologies, and many software stacks. A smart-city deployment might have RFID tags at parking spots, LoRaWAN sensors at intersections, NB-IoT smart streetlights, and 5G-connected video cameras at major junctions — all delivering data to the same backend. Each needs its own gateway and its own integration.

Security

IoT devices are notoriously poorly secured. Common failures:

• Default credentials that no one changes. The Mirai botnet (2016) infected hundreds of thousands of IP cameras and DVRs by trying a list of default usernames and passwords, then used them to launch some of the largest DDoS attacks ever recorded.
• No update mechanism. A device sold in 2018 may have no way to receive a security patch in 2025.
• Hard-coded keys. Crypto keys baked into device firmware can be extracted by anyone with physical access to one device, breaking the whole fleet's security.
• Poor cryptographic hygiene. Weak random number generators, deprecated algorithms, missing certificate validation.
• Insecure default services. Telnet open, no authentication on management interfaces.

Defences are working their way through. The Matter standard for smart-home devices includes a strong commissioning protocol and a certificate-based identity. EU regulations (the Cyber Resilience Act, in force from 2027) will require IoT manufacturers to support security updates for a defined period. The US Cyber Trust Mark and similar schemes elsewhere are regulatory pushes in the same direction.

Naming and addressing

IPv4 cannot supply public addresses to billions of devices. IPv6 can. IoT deployments that use cellular connectivity (NB-IoT, LTE-M) generally get IPv6 addresses. Some constrained networks use shorter addresses (16-bit short addresses in 802.15.4) inside the local network and a gateway to translate to IPv6.

Interoperability

A long history of incompatible IoT platforms — each vendor with its own cloud, its own protocols, its own data formats — has made building cross-vendor systems painful. The Matter standard for smart-home, OPC UA for industrial, and the various Industrial Internet Consortium frameworks all try to standardise. Progress is slow.

Real-time constraints

A factory robot needs millisecond-scale control loops. A traffic-light controller needs reliable delivery of state updates within a second. An autonomous vehicle's local perception network needs sub-10 ms latency between sensors and the central processor. Building networks that consistently deliver these latencies — especially over wireless and especially when many devices share the medium — is hard.

Privacy

Every IoT sensor is a potential surveillance device. A smart meter reveals when you are home and what appliances you use. A connected vehicle reveals where you drive. A fitness tracker reveals your health and movement patterns. Privacy regulations (GDPR in the EU, sector-specific frameworks elsewhere) impose constraints, but the implementation gap in IoT deployments is large.

Lifecycle management

Provisioning a million devices, rotating their keys over a decade, replacing the dead ones, retiring the obsolete ones, decommissioning them securely when they leave service — all of this needs operational tooling at a scale IT operations rarely sees. The vendor cloud platforms (AWS IoT Device Management, Azure IoT Hub, Google Cloud IoT Core's successors) exist to address this, but the operational discipline lags the tooling.

5.7 Edge computing for IoT applications

Edge computing is the deployment model in which computation, storage, and networking resources are placed close to the data sources (IoT devices, end users), at the edge of the network rather than in a central cloud, in order to reduce latency, conserve bandwidth, improve resilience, and address data-sovereignty constraints.

Why edge

The cloud model assumes data travels to a central data centre, computation happens there, results return. For many use cases this is fine. For others it is wrong:

• Latency. A round trip from Kathmandu to AWS Mumbai is 30–60 ms. A factory robot's control loop needs 1 ms.
• Bandwidth. A video camera at a busy intersection produces tens of megabits per second of raw video. Sending all of it to the cloud is wasteful when only the events of interest matter.
• Resilience. A connected vehicle on a Karnali highway must not stop functioning when its cellular link drops.
• Privacy and sovereignty. Some data must not leave a building, a campus, or a country. The EU's GDPR and several national data-localisation laws make this concrete.

Edge computing moves part of the work to where the data is.

Edge tiers

There is no single "edge." Different deployments use different tiers:

+---------------+   millimetres
| Device edge   |   On the device itself
+---------------+
       |
       v
+---------------+   metres to kilometres
| Network edge  |   Gateway in the building
+---------------+   or at the cell site
       |
       v
+---------------+   tens of kilometres
| Regional edge |   Local data centre,
+---------------+   "mini-cloud"
       |
       v
+---------------+   thousands of kilometres
| Central cloud |   Hyperscale data centre
+---------------+

A connected-vehicle deployment might have:

• Object detection on the vehicle itself (device edge).
• Cooperative perception (sharing sensor data with nearby vehicles) at the cell-site MEC (network edge).
• Map updates and route planning at a regional edge in Kathmandu.
• Long-term analytics and model training in a central cloud anywhere.

MEC — Multi-access Edge Computing

MEC (Multi-access Edge Computing) is the ETSI-standardised edge-computing framework that places computation and storage at the cellular network's edge — typically at the base station, at the aggregation site, or at the central office — so that mobile applications can be served with low latency from a location close to the user.

MEC is the 5G operator's way to monetise edge. The operator provides:

• The physical edge infrastructure (servers in the cell-site shelter or the central office).
• Connectivity from the user's 5G session to the local edge.
• APIs that application developers can use to discover and use the edge.

The 5G core's User Plane Function (UPF) can be placed at the edge — this is local breakout, where the user's traffic exits to a local edge server without traversing the central core. The path from the UE to the edge server is short and direct.

Edge platforms

• AWS Wavelength — AWS edge zones at Verizon, Vodafone, KDDI, and other operator sites.
• Azure Edge Zones — Microsoft's parallel offering.
• Google Distributed Cloud — Google's edge-and-on-prem extension.
• KubeEdge, OpenYurt — open-source Kubernetes extensions for edge management.
• EdgeX Foundry — open-source framework for industrial IoT edge.

In Nepal, the FTTH-heavy deployment pattern of WorldLink and Subisu naturally creates regional points-of-presence that could serve as edge compute nodes; commercial edge offerings are not yet widely available, but the infrastructure exists.

Edge for IoT specifically

The IoT cases for edge include:

• Local aggregation. A field of LoRaWAN sensors reports to a gateway in the building, which aggregates and forwards only what matters.
• Local inference. A camera at a factory door runs face recognition locally; only "verified" or "unknown" events flow to the cloud.
• Resilience to backhaul loss. A retail point-of-sale system continues working when the WAN drops, syncing to the cloud later.
• Real-time control loops. A robot or a precision-agriculture irrigation system makes local decisions in milliseconds, with cloud-driven policies updated less frequently.
• Reduced cloud bills. Sending only a summary of each hour's sensor data, rather than every raw reading, can cut cloud ingest costs by an order of magnitude.

5.8 Overview of Industrial IoT (IIoT)

IIoT (Industrial Internet of Things) is the application of IoT technologies — sensors, connectivity, edge analytics, automation — to industrial environments such as manufacturing, energy, transportation, and infrastructure, with the goal of monitoring and optimising physical processes that produce economic output.

The distinction between consumer IoT and Industrial IoT is one of stakes and operational discipline:

	Consumer IoT	Industrial IoT
Examples	Smart bulbs, watches, voice assistants	Factory robots, smart-grid sensors, mine equipment
Failure cost	Inconvenience	Production loss, safety incidents
Lifetime expected	2–5 years	10–30 years
Security maturity	Often poor	Higher (but still uneven)
Standards	Many, fragmented	Industry-specific (IEC 61131, OPC UA, ISA-95)
Connectivity	Wi-Fi, BLE, Zigbee	Industrial Ethernet, NB-IoT, 5G, fieldbuses

IIoT architecture

A typical IIoT system has several layers:

+--------------------------+
|  Enterprise applications |   ERP, MES, business intelligence
+--------------------------+
|  Cloud / data lake       |   Long-term storage, analytics
+--------------------------+
|  Edge analytics          |   Inference, anomaly detection
+--------------------------+
|  Aggregation / gateway   |   Protocol translation, buffering
+--------------------------+
|  Field devices           |   Sensors, actuators, PLCs
+--------------------------+
|  Physical process        |   Production line, grid, plant
+--------------------------+

Connectivity in IIoT

Traditional industrial fieldbuses include Modbus, PROFIBUS, DeviceNet, and CAN. Industrial Ethernet variants include PROFINET, EtherCAT, and EtherNet/IP. Newer deployments are moving to:

• TSN (Time-Sensitive Networking) — IEEE 802.1 extensions to standard Ethernet for deterministic, bounded-latency communication, suitable for hard real-time industrial control.
• OPC UA over TSN — the emerging stack for vendor-neutral industrial communication.
• Private 5G — 5G in licensed or unlicensed spectrum, operated by the industrial customer themselves or by a partner.
• Wi-Fi 6/7 — for non-real-time industrial use.

IIoT in practice

The most-cited IIoT deployments globally include:

• Predictive maintenance. Vibration and temperature sensors on motors and bearings, with ML detecting failures before they happen. ABB, GE, Siemens, and Hitachi all offer platforms for this.
• Asset performance management. Monitoring large industrial assets — wind turbines, jet engines, oil platforms — in real time.
• Process optimisation. Continuous tuning of plant operating conditions based on real-time sensor data.
• Quality control. Computer vision on the production line catching defects in real time.
• Energy management. Demand response, peak shaving, efficiency optimisation at industrial sites.

For Nepal, the relevant IIoT cases are:

• The Nepal Electricity Authority smart-grid programme. Smart meters, distribution-network sensors, and SCADA modernisation at the substation level. NEA started smart-meter rollout in Kathmandu Valley pilot areas in 2022.
• The Khimti, Marsyangdi, and Upper Tamakoshi hydro stations running SCADA and increasingly modern condition-monitoring on turbines and generators.
• Cement and pharmaceutical plants in the Tarai with predictive-maintenance pilots.
• Tea and tobacco processing with quality-control sensing.

IIoT security

IIoT security is its own discipline. The fundamental tension is that industrial systems were designed for decades-long lifetimes in trusted networks, and many of them are now connected to the Internet. Defences include:

• Network segmentation. The Purdue model layered architecture, with strict firewalls between IT and OT (Operational Technology) zones.
• Zero trust for OT. Never trust based on network location, always authenticate.
• Patching and vulnerability management. Harder for OT than IT because patching may require plant downtime.
• Specialised IDS. Products like Claroty, Dragos, and Nozomi Networks that understand industrial protocols.

The Stuxnet attack on Iranian nuclear centrifuges (2010), the Ukraine power-grid attacks (2015 and 2016), the Triton/Trisis attack on a Saudi petrochemical plant (2017), and the Colonial Pipeline ransomware incident (2021) are the canonical demonstrations that IIoT/OT security matters at the national-security level.

5.9 Cyber-physical systems

A Cyber-Physical System (CPS) is an engineered system in which computation, networking, and physical processes are tightly integrated, with computers and networks monitoring and controlling the physical process and the physical process providing context and feedback to the computational layer.

The concept overlaps with IIoT but is broader. IIoT emphasises the technology stack — sensors, connectivity, analytics. CPS emphasises the engineering discipline of designing systems where computation and physics are co-designed.

Defining characteristics

A CPS has:

• Sensing of the physical world. Cameras, lidars, force sensors, chemical sensors, GPS receivers.
• Computation that processes that sensing. Often in real time, often with hard deadlines.
• Actuation that affects the physical world. Motors, valves, brakes, robot arms, pumps.
• Closed-loop feedback. The result of actuation feeds back into the sensing, completing the loop.
• Networking. Local networks among components, often wider networks for coordination.

A CPS is not just a computer that happens to interact with a physical process. The defining property is that the computation and physics are designed together — the computational model accounts for physical dynamics (mass, momentum, inertia, response times), and the physical design accounts for computational constraints (sample rate, processing latency, communication delays).

Examples

• Self-driving vehicles. Cameras, lidar, radar, and IMUs sense; perception, planning, and control compute; steering, throttle, and braking actuate.
• Smart grid. Sensors on substations and consumer meters; control algorithms balance generation and demand; switches and inverters actuate. The Nepal Electricity Authority's evolving grid, with new variable renewable generation from solar and small hydro plus interconnection with India, is increasingly a CPS at the national scale.
• Surgical robotics. Tactile and visual sensing; planning under sterile-field constraints; precise mechanical actuation in tissue.
• Drones. Continuous sensing of position, attitude, environment; flight-control loops at hundreds of Hz; motor and control-surface actuation.
• Building energy management systems. Sensors for temperature, occupancy, daylight; computation for HVAC scheduling; actuation through dampers, chillers, and lighting controls.
• Aircraft fly-by-wire. The single most demanding category of safety-critical CPS, with deterministic timing requirements, multiple-redundancy architectures, and decades of formal certification practice (DO-178C for software, DO-254 for hardware).

Engineering disciplines

Designing a CPS draws on multiple disciplines:

• Control theory for the closed-loop behaviour — stability, response time, robustness to disturbances.
• Real-time systems for the computation — scheduling, latency bounds, priority inversion.
• Networking for the communication — bounded latency, deterministic delivery, fault tolerance.
• Mechanical, electrical, or chemical engineering for the physical process — what the system actually does.
• Software engineering for the implementation — particularly safety-critical patterns, formal methods, testing.

The discipline did not have a single name until the early 2000s. The National Science Foundation (US) used "cyber-physical systems" as a programme name from 2006 onwards, and the term took root in academia. The IEC, ISO, and other standards bodies now use CPS as a coordinating concept across their industrial-automation work.

CPS challenges

The CPS field has several long-standing challenges:

Composability. A CPS is usually built from components — sensors from one vendor, actuators from another, computation platforms from a third, networking from a fourth. Knowing whether the composition will satisfy real-time and safety requirements is hard. Each component has its own specification; the system specification does not follow automatically.

Verification. Proving that a CPS will behave correctly in all conditions, including unusual ones, is fundamentally harder than verifying a software-only system. The state space includes physical variables. Hybrid systems theory (combining discrete and continuous dynamics) tries to make this tractable.

Resilience to attack. A successful attack on a CPS damages the physical world. Power outages, plant explosions, water-treatment failures, vehicle crashes. Designing for resilience — not just confidentiality and integrity, but recovery from compromise — is more demanding than IT security.

Human factors. CPS often interact with humans, sometimes in safety-critical ways (driver-assist systems, surgical robots, aircraft autopilots). Designing the interface and the handover of control between human and machine is a research field on its own.

Lifecycle and certification. A CPS in a regulated domain (aviation, medical devices, automotive, nuclear) must be certified. The certification regime in each domain has decades of accumulated practice, formal methods, and audit requirements. Adding new capabilities — machine learning, over-the-air updates, increased autonomy — requires extensions to the certification frameworks that the field is still working out.

The CPS concept ties together the threads of this chapter. 5G provides the connectivity. IoT provides the sensors and actuators. Edge computing provides the place for the time-critical computation. Industrial IoT provides the deployment context. CPS provides the engineering discipline that turns these into systems that change the physical world reliably, safely, and economically.