38 Choosing the Right Network Type

38.2 Overview: Classify The Requirement, Not The Brand

Network classification is a shortcut for reasoning about reach, bandwidth, power, ownership, mobility, and failure boundaries. PAN, LAN, WAN, and LPWAN labels are useful only after the deployment requirement is bounded. A wearable badge, a PoE camera, a campus gateway, and a field soil sensor may all belong to one IoT system, but they should not use one network class.

The first decision is the communication job: how far the device must reach, how much data it sends, how often it wakes, whether it moves, who owns the infrastructure, and what happens when coverage is weak.

A class label is therefore an engineering filter, not a product category. PAN usually means the device can live close to a phone, reader, hub, or coordinator; LAN usually means the site can provide local infrastructure such as access points, switches, cabling, and power; WAN usually means the device or gateway must cross wider geography, operator networks, or remote backhaul; LPWAN narrows that wide-area problem for small payloads and long battery life. The useful question is not "which technology is best?" but "which class leaves the fewest unresolved assumptions for this device job?" A fixed camera, for example, may prefer Ethernet and PoE because power and predictable capacity matter more than mobility. A soil sensor may prefer LPWAN because reach and sleep time matter more than throughput. A wearable badge may prefer a PAN path because local readers keep the radio and battery budget small.

Read Figure 38.1 across a row rather than down a column, because the row is the requirement and the column is only a name for it.

+

Take the range row of Figure 38.1 first. It moves from something worn on a body, to something a building can cover, to something spanning a city or region. That is a statement about the deployment, not about a product. The row beneath it shows the named technologies that sit in each band, and it is deliberately plural: choosing a band does not choose a radio. The last row is the useful check. If the device job named there does not match the job in front of you, the band is wrong however attractive the technology sounds. Read the table this way and the class label stays an engineering filter, which is the habit the rest of the chapter depends on.

Use Figure 38.2 to compare coverage and bandwidth before adding power and ownership constraints.

+

Read the coverage axis against the bandwidth axis rather than treating either as a universal score. Short-range technologies can occupy the high-throughput region because distance, interference, and transmit energy are bounded. Long-range links often trade rate or duty cycle for reach, while cellular options add an operator and service plan. The sparse high-bandwidth, long-range corner is a warning that a requirement may need gateways, local processing, or more power. Classify the payload rhythm, latency, site control, and energy source before selecting a named radio from the chart.

38.3 Practitioner: Build A Classification Record

A useful network classification record is a small design artifact. It does not just say "use Wi-Fi" or "use LoRaWAN." It records the tier, the reason that tier fits, the boundary where traffic moves to another tier, and the evidence that proves the choice under real conditions.

Write the record so another engineer can challenge it. For each device type, name the class, the next boundary, the normal payload, the peak payload, the wake or mobility pattern, the owner of the infrastructure, and the field test that would falsify the choice. If a badge depends on doorway readers, the reader density is part of the classification record. If a camera depends on PoE, switch power and uplink capacity are part of the record. If a remote meter depends on an operator network, coverage evidence and subscription lifecycle are part of the record.

Before you write a tier into the record, check where that radio really sits. Figure 38.3 plots the usual options against reach and data rate.

+

Figure 38.3 puts data rate up the side and reach along the bottom, and the crowd falls into three broad regions. Short-range, high-rate Wi-Fi variants hold one end. The low-power families, including Bluetooth, Zigbee, 802.15.4 and near-field tags, hold a low-rate short-reach region. The illustrated LPWAN entries occupy a long-reach low-rate region, while cellular options vary by generation and configuration. The chart is a set of selected IoT examples, not a physical ban on long-distance high-rate links: fibre, microwave and some satellite services can provide both at different power and infrastructure costs. A classification record still has to add power, ownership, and a field test.

Use Figure 38.4 to treat PAN, LAN, MAN, and WAN as planning scopes rather than guaranteed distances.

+

Begin with the personal-area scope around one person or small device group. Then widen the view through local and city networks to the WAN. Each band points to a new owner, gateway, or backhaul line. It does not promise that a radio reaches the edge shown. Walls, land, antenna sites, other radios, and the receiver can make a named LAN fail within one building. Planned gateways can also turn a short radio link into a wide service. Record the real site path and its owner; a coverage class is not field proof.

38.4 Under The Hood: Each Class Hides A Boundary

Classification is not a protocol stack. It is a boundary model. A PAN device still needs local addressing, pairing, channel access, and a bridge to wider services. A LAN device still needs switch or access-point capacity, power, VLAN or security policy, and backhaul. A WAN device still depends on gateway density, operator coverage, spectrum rules, provisioning, and lifecycle continuity.

The hidden work is usually translation and ownership. A short-range device may speak Bluetooth LE, Zigbee, Thread, or another local protocol, but the enterprise system often expects IP topics, HTTP APIs, MQTT messages, or database records. The phone, hub, border router, or gateway that performs that handoff changes addressing, trust, timing, retry behavior, and failure visibility. When that boundary is not recorded, teams blame the "network class" even though the real problem is a pairing policy, gateway queue, credential rotation, backhaul outage, or missing device-to-cloud mapping.

The same pattern appears in LAN and WAN choices. Ethernet can remove radio uncertainty, but it introduces cable plant, PoE budget, switch-port, VLAN, and maintenance boundaries. Wi-Fi can reuse building infrastructure, but access-point placement, channel planning, roaming behavior, and client density decide whether the class is actually adequate. Cellular and LPWAN (LoRaWAN, Sigfox, NB-IoT, or a narrower option such as Weightless) can reach remote assets, but SIM provisioning, roaming policy, regional spectrum rules, gateway density, payload limits, and operator lifecycle become design dependencies. The classification is credible only when those dependencies are visible and testable, so boundary review becomes part of the architecture rather than a note for later.

Look for the single point every device depends on in Figure 38.5.

+

The phone sits in the middle as the central device, or coordinator. Four BLE links fan out from it to a watch, a beacon tag, a sensor and an actuator, and none of those four talk to each other. That shape is the personal area network, and it is also its boundary. Everything the peripherals report reaches the wider system only through the device in the middle. So the diagram at Figure 38.5 is really about ownership. Whoever controls the phone, reader, hub or coordinator controls pairing, trust, timing, and what the rest of the estate ever gets to see.

Read the link labels in Figure 38.6, because they carry more of the design than the boxes do.

+

One router and access point sits at the centre as the gateway. A PLC reaches it over Ethernet, a sensor over Wi-Fi, a camera over PoE, and an MQTT broker over IP. Four boxes, four different dependencies. The Ethernet device needs a cable run and a free switch port. The Wi-Fi device needs coverage and airtime. The camera needs power budget from the same switch that carries its data. Figure 38.6 shows why calling something a LAN device settles very little. The class is shared. The cable plant, power budget and coverage plan behind each link are not.

Follow Figure 38.7 to see which owners and links sit between a LoRa device and the application.

+

Start with sensor transmissions over LoRa to one or more gateways. The gateway does not complete the service; it forwards packets over IP backhaul to network services that deduplicate, authorize, and route them toward the application. Those handoffs may cross site, telecom, and cloud owners. A strong radio link can therefore coexist with a failed service when gateway power, backhaul, roaming, or platform routing is unavailable. The WAN record should name each boundary, its observable health, the data custody point, and what devices do while the next owner cannot accept traffic.