%%{init: {'theme': 'base', 'themeVariables': {'primaryColor':'#2C3E50','primaryTextColor':'#fff','primaryBorderColor':'#16A085','lineColor':'#16A085','secondaryColor':'#E67E22','tertiaryColor':'#ecf0f1','textColor':'#2C3E50','fontSize':'14px'}}}%%
graph LR
subgraph "Level 1: Device Characteristics"
D1["Battery-powered<br/>Low-cost sensor"]
D2["Mains-powered<br/>Smart appliance"]
D3["Industrial PLC<br/>with Ethernet"]
D4["Passive RFID tag<br/>No battery"]
end
subgraph "Level 2: Protocol Selection"
P1["LoRaWAN<br/>(Long range, low power)"]
P2["Wi-Fi<br/>(High bandwidth, AC power)"]
P3["Modbus TCP<br/>(Industrial standard)"]
P4["NFC<br/>(Passive, proximity)"]
end
D1 --> P1
D2 --> P2
D3 --> P3
D4 --> P4
style D1 fill:#E67E22,stroke:#2C3E50,color:#fff
style D2 fill:#E67E22,stroke:#2C3E50,color:#fff
style D3 fill:#E67E22,stroke:#2C3E50,color:#fff
style D4 fill:#E67E22,stroke:#2C3E50,color:#fff
style P1 fill:#16A085,stroke:#2C3E50,color:#fff
style P2 fill:#16A085,stroke:#2C3E50,color:#fff
style P3 fill:#16A085,stroke:#2C3E50,color:#fff
style P4 fill:#16A085,stroke:#2C3E50,color:#fff
786 IoT Network Design: Five Key Considerations
NoteLearning Objectives
By the end of this section, you will be able to:
- Evaluate device characteristics to determine connectivity requirements
- Analyze data characteristics to select appropriate protocols
- Design enterprise infrastructure for Levels 4-7 of the IoT reference model
- Create IP addressing schemes for massive IoT deployments
- Document logical and physical network topologies
786.1 Prerequisites
Before studying this chapter, review:
- IoT Network Design: Reference Model Framework: Understanding the Cisco 7-Level IoT Reference Model
- Protocol Selection Worked Examples: Spectrum allocation and cost analysis fundamentals
786.2 Five Key Design Considerations
786.2.1 (1) Consider the Devices
Once the scope and types of devices to be connected has been determined at Level 1, the interconnectivity requirements of Level 2 can be determined.
{fig-alt=“Device-to-protocol mapping showing how Level 1 device characteristics determine Level 2 connectivity choices. Battery-powered low-cost sensors pair with LoRaWAN for long range and low power, mains-powered smart appliances use Wi-Fi for high bandwidth, industrial PLCs connect via Modbus TCP over Ethernet, and passive RFID tags use NFC for proximity communication without battery. Orange device boxes connect to teal protocol boxes.”}
786.2.1.1 Device-Specific Protocol Decisions
Low power and passive devices may require the application of IoT-specific, and perhaps proprietary, communication protocols, especially if the device does not have software to operate and process protocols in the TCP/IP suite.
Communications decisions may include:
- LoRa: For devices across a wide area with low data rates
- NFC: For passive devices requiring proximity communication
- Wi-Fi or 4G/5G: If power sources and access points are available
- Zigbee/Thread: For mesh networking with battery-powered devices
Complex IoT deployments could include a combination of these media – the actual technologies being dependent on the devices used and the scale of the interconnections required.
TipDevice Selection Checklist
When selecting devices for your IoT deployment, consider:
- Power Requirements: Mains power, battery, energy harvesting?
- Processing Capability: Can it run TCP/IP stack?
- Physical Size: Space constraints for antennas/radios?
- Environmental Conditions: Temperature, humidity, vibration?
- Deployment Scale: Hundreds or millions of devices?
- Cost per Unit: Acceptable price point at scale?
786.2.2 (2) Consider the Data
The form of the data to be communicated will determine the protocols and network infrastructure required.
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor':'#2C3E50','primaryTextColor':'#fff','primaryBorderColor':'#16A085','lineColor':'#16A085','secondaryColor':'#E67E22','tertiaryColor':'#ecf0f1','textColor':'#2C3E50','fontSize':'14px'}}}%%
graph TB
subgraph "Data Characteristics"
DC1["Small packets<br/>(10-100 bytes)<br/>Infrequent"]
DC2["Medium data<br/>(1-10 KB)<br/>Periodic"]
DC3["Large streams<br/>(MB/s)<br/>Continuous"]
DC4["Real-time control<br/>(< 10ms latency)<br/>Critical"]
end
subgraph "Protocol Recommendations"
PR1["MQTT over NB-IoT/LoRa<br/>(Lightweight pub-sub)"]
PR2["CoAP over Wi-Fi<br/>(REST-like for IoT)"]
PR3["HTTP/RTSP over Ethernet<br/>(Video streaming)"]
PR4["Modbus TCP / OPC UA<br/>(Industrial real-time)"]
end
DC1 --> PR1
DC2 --> PR2
DC3 --> PR3
DC4 --> PR4
style DC1 fill:#E67E22,stroke:#2C3E50,color:#fff
style DC2 fill:#E67E22,stroke:#2C3E50,color:#fff
style DC3 fill:#E67E22,stroke:#2C3E50,color:#fff
style DC4 fill:#E67E22,stroke:#2C3E50,color:#fff
style PR1 fill:#16A085,stroke:#2C3E50,color:#fff
style PR2 fill:#16A085,stroke:#2C3E50,color:#fff
style PR3 fill:#16A085,stroke:#2C3E50,color:#fff
style PR4 fill:#16A085,stroke:#2C3E50,color:#fff
{fig-alt=“Data characteristics to protocol mapping showing how data volume, frequency, and latency requirements determine protocol selection. Small infrequent packets use MQTT over NB-IoT/LoRa, medium periodic data uses CoAP over Wi-Fi, large continuous streams use HTTP/RTSP over Ethernet for video, and real-time critical control uses Modbus TCP or OPC UA for sub-10ms latency. Orange data characteristic boxes connect to teal protocol recommendation boxes.”}
786.2.2.1 Data Protocol Decisions
The aggregation of data and Fog computing requirements, from Level 2 to Level 3 and onto Level 4 of the Reference Model, will mean that the operating systems of the devices at these levels will have to process IPv4 or IPv6 packets for network and Internet communications.
Key considerations:
- Non-TCP/IP capable devices will have to have data converted to comply with TCP/IP at this level
- Other devices may make use of MQTT, which runs on TCP/IP, to carry data but is not as complex as Application Layer protocols like HTTP
- These decisions all relate to the range and type of ‘things’, based on the design requirements of the IoT
NoteData Characteristics Impact Protocol Choice
| Data Type | Volume | Frequency | Recommended Protocol |
|---|---|---|---|
| Temperature readings | Small (few bytes) | Periodic (minutes) | MQTT, CoAP |
| Video streams | Large (MB/s) | Continuous | HTTP/RTSP over Wi-Fi/5G |
| Motion detection | Small (boolean) | Event-driven | MQTT, WebSocket |
| GPS tracking | Medium (tens of bytes) | Periodic (seconds) | MQTT, UDP |
| Industrial telemetry | Medium | High frequency (ms) | OPC UA, Modbus TCP |
786.2.3 (3) Consider Above Level 4
Processes in Level 4 and higher in the IoT reference model generally occur far from the devices at the edge of the IoT.
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor':'#2C3E50','primaryTextColor':'#fff','primaryBorderColor':'#16A085','lineColor':'#16A085','secondaryColor':'#E67E22','tertiaryColor':'#ecf0f1','textColor':'#2C3E50','fontSize':'14px'}}}%%
graph TB
subgraph "Levels 4-7: Cloud & Enterprise Infrastructure"
L7E["L7: Business Applications<br/>(ERP, CRM, BI dashboards)"]
L6E["L6: Analytics & Control<br/>(Machine learning, decision engines)"]
L5E["L5: Data Abstraction<br/>(Data warehouses, data lakes)"]
L4E["L4: Data Accumulation<br/>(Time-series DB, blob storage)"]
end
subgraph "Enterprise Network Infrastructure"
ENI1["Ethernet Switches<br/>(10G/40G/100G backplane)"]
ENI2["Core Routers<br/>(BGP, OSPF, redundant paths)"]
ENI3["Firewalls & Security<br/>(Network segmentation, IDS/IPS)"]
ENI4["Load Balancers<br/>(Distribute IoT traffic)"]
end
L4E --> ENI1
L5E --> ENI1
L6E --> ENI2
L7E --> ENI2
ENI1 --> ENI3
ENI2 --> ENI3
ENI3 --> ENI4
style L7E fill:#2C3E50,stroke:#16A085,color:#fff
style L6E fill:#2C3E50,stroke:#16A085,color:#fff
style L5E fill:#2C3E50,stroke:#16A085,color:#fff
style L4E fill:#2C3E50,stroke:#16A085,color:#fff
style ENI1 fill:#16A085,stroke:#2C3E50,color:#fff
style ENI2 fill:#16A085,stroke:#2C3E50,color:#fff
style ENI3 fill:#16A085,stroke:#2C3E50,color:#fff
style ENI4 fill:#16A085,stroke:#2C3E50,color:#fff
{fig-alt=“Levels 4-7 enterprise infrastructure showing how cloud and data center layers rely on standard enterprise networking equipment. Level 4 (Data Accumulation with time-series databases) and Level 5 (Data Abstraction with warehouses) connect through Ethernet switches, Level 6 (Analytics) and Level 7 (Business Applications) connect through core routers, all traffic flows through firewalls with network segmentation and load balancers. Navy application layer boxes connect to teal infrastructure boxes.”}
786.2.3.1 Enterprise Network Design Decisions
The network devices operating at these levels are the Ethernet switches, routers, and servers already in use in corporate data networks and the Internet, and would not usually require any specific adaptation for IoT data.
Network design decisions for these devices would be based on:
- Data Throughput: Bandwidth requirements for aggregated IoT data
- Quality of Service (QoS): Prioritization of critical IoT traffic
- Computing Requirements: CPU/memory for data volumes and analysis
- Redundancy: Link and router/switch redundancy for high availability
- Real-time Processing: Low-latency requirements for critical control systems
ImportantHigh Availability Considerations
For mission-critical IoT applications (industrial control, healthcare monitoring, autonomous vehicles), design must include:
- Redundant network links between critical infrastructure
- Multiple router paths with dynamic routing protocols
- Backup power systems (UPS, generators)
- Geographic distribution of data centers
- Failover mechanisms with automatic detection and switchover
786.2.4 (4) Consider Addressing
To manage the potentially large number of end devices in an IoT, design decisions will also include IP addressing schemes for those devices that can run TCP/IP.
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor':'#2C3E50','primaryTextColor':'#fff','primaryBorderColor':'#16A085','lineColor':'#16A085','secondaryColor':'#E67E22','tertiaryColor':'#ecf0f1','textColor':'#2C3E50','fontSize':'14px'}}}%%
graph TD
START{"How many<br/>IoT devices?"}
SMALL["< 1,000 devices"]
MEDIUM["1,000 - 100,000 devices"]
LARGE["> 100,000 devices"]
IPv4_STATIC["IPv4 Static<br/>(Simple, predictable)"]
IPv4_DHCP["IPv4 DHCP + NAT<br/>(Manageable, scalable)"]
IPv6["IPv6 with SLAAC<br/>(Unlimited scale, auto-config)"]
START --> |Small| SMALL
START --> |Medium| MEDIUM
START --> |Large| LARGE
SMALL --> IPv4_STATIC
MEDIUM --> IPv4_DHCP
LARGE --> IPv6
IPv4_STATIC --> NOTE1["Pros: No server needed<br/>Cons: Manual config, errors"]
IPv4_DHCP --> NOTE2["Pros: Centralized mgmt<br/>Cons: NAT complexity"]
IPv6 --> NOTE3["Pros: End-to-end, scalable<br/>Cons: Requires IPv6 support"]
style START fill:#2C3E50,stroke:#16A085,color:#fff
style SMALL fill:#E67E22,stroke:#2C3E50,color:#fff
style MEDIUM fill:#E67E22,stroke:#2C3E50,color:#fff
style LARGE fill:#E67E22,stroke:#2C3E50,color:#fff
style IPv4_STATIC fill:#16A085,stroke:#2C3E50,color:#fff
style IPv4_DHCP fill:#16A085,stroke:#2C3E50,color:#fff
style IPv6 fill:#16A085,stroke:#2C3E50,color:#fff
style NOTE1 fill:#ecf0f1,stroke:#7F8C8D,color:#2C3E50
style NOTE2 fill:#ecf0f1,stroke:#7F8C8D,color:#2C3E50
style NOTE3 fill:#ecf0f1,stroke:#7F8C8D,color:#2C3E50
{fig-alt=“IP addressing strategy decision tree based on device scale. Small deployments under 1,000 devices can use IPv4 static addressing (simple but manual), medium deployments 1,000-100,000 devices use IPv4 DHCP with NAT (centralized management but NAT complexity), large deployments over 100,000 devices require IPv6 with SLAAC (unlimited scalability and auto-configuration). Navy decision diamond, orange scale categories, teal protocol choices, gray notes boxes.”}
786.2.4.1 Addressing Scheme Decisions
These decisions would include:
- Private IPv4 address range: Which may require Network Address Translation (NAT) to also be included
- IPv6 addresses: Can provide end-to-end addressing without NAT
- Static IP addressing: Manual configuration for critical/fixed devices
- Dynamic addressing services: DHCP for flexible device management
NoteIPv4 vs IPv6 for IoT
| Aspect | IPv4 + NAT | IPv6 |
|---|---|---|
| Address Space | ~4 billion (limited) | 340 undecillion (unlimited) |
| Address Assignment | DHCP required | SLAAC auto-configuration |
| End-to-End | NAT breaks it | Native support |
| Header Complexity | More complex | Simplified |
| Deployment | Widely supported | Growing adoption |
| Best For | Small-medium IoT | Large-scale IoT |
Advantages and disadvantages of each method:
Static IP Addressing: - Pros: Predictable, no DHCP server needed, works offline - Cons: Manual configuration error-prone, doesn’t scale well
Dynamic IP Addressing (DHCP): - Pros: Centralized management, scales well, reduces errors - Cons: Requires DHCP server, temporary connectivity issues
IPv6 SLAAC: - Pros: Zero-configuration, automatic, scalable - Cons: Privacy concerns (MAC-based addresses), requires IPv6 infrastructure
786.2.5 (5) Consider Topology
As these decisions are being made, the design details need to be documented.
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor':'#2C3E50','primaryTextColor':'#fff','primaryBorderColor':'#16A085','lineColor':'#16A085','secondaryColor':'#E67E22','tertiaryColor':'#ecf0f1','textColor':'#2C3E50','fontSize':'14px'}}}%%
graph LR
subgraph "Logical Topology"
LT1["Device Types & Roles"]
LT2["Communication Flows"]
LT3["Protocol Relationships"]
LT4["IP Addressing Scheme"]
end
subgraph "Physical Topology"
PT1["Device Locations"]
PT2["Cabling & Connections"]
PT3["AP/Gateway Placement"]
PT4["Coverage Maps"]
end
DOC["Complete IoT<br/>Network Documentation"]
LT1 --> DOC
LT2 --> DOC
LT3 --> DOC
LT4 --> DOC
PT1 --> DOC
PT2 --> DOC
PT3 --> DOC
PT4 --> DOC
style LT1 fill:#16A085,stroke:#2C3E50,color:#fff
style LT2 fill:#16A085,stroke:#2C3E50,color:#fff
style LT3 fill:#16A085,stroke:#2C3E50,color:#fff
style LT4 fill:#16A085,stroke:#2C3E50,color:#fff
style PT1 fill:#E67E22,stroke:#2C3E50,color:#fff
style PT2 fill:#E67E22,stroke:#2C3E50,color:#fff
style PT3 fill:#E67E22,stroke:#2C3E50,color:#fff
style PT4 fill:#E67E22,stroke:#2C3E50,color:#fff
style DOC fill:#2C3E50,stroke:#16A085,color:#fff
{fig-alt=“IoT network documentation requirements showing logical topology elements (device types and roles, communication flows, protocol relationships, IP addressing scheme in teal) and physical topology elements (device locations, cabling and connections, access point and gateway placement, coverage maps in orange) all contributing to complete network documentation (navy center box). Documentation ensures comprehensive planning and deployment success.”}
786.2.5.1 Documentation Requirements
A logical topology will show: - The range and types of end devices - The communication flows between them - Labels and addressing used - Protocol relationships and data flow
A physical topology will be created to show: - Exactly where devices are to be installed - Connecting cabling (if not wireless) - Access point and gateway locations - Coverage areas and range limitations
786.3 Example: Smart Building IoT Topology
Logical Topology:
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor':'#2C3E50','primaryTextColor':'#fff','primaryBorderColor':'#16A085','lineColor':'#16A085','secondaryColor':'#E67E22','tertiaryColor':'#ecf0f1','textColor':'#2C3E50','fontSize':'14px'}}}%%
graph TB
subgraph "Smart Building Logical Topology"
CLOUD["Cloud Platform<br/>(2001:db8:cloud::1)"]
GW["Building Gateway<br/>(10.10.0.1 / 2001:db8:bldg::1)"]
subgraph "Floor Controllers"
FC1["Floor 1 Controller<br/>(10.10.1.10)"]
FC2["Floor 2 Controller<br/>(10.10.2.10)"]
end
subgraph "IoT Devices"
HVAC1["HVAC Sensors (Zigbee)<br/>(10.10.1.20-40)"]
LIGHT1["Lighting Controllers<br/>(10.10.1.50-60)"]
OCC1["Occupancy Sensors<br/>(10.10.1.70-80)"]
end
end
CLOUD -->|MQTT over TLS| GW
GW -->|Ethernet| FC1
GW -->|Ethernet| FC2
FC1 -->|Zigbee| HVAC1
FC1 -->|Zigbee| LIGHT1
FC1 -->|Zigbee| OCC1
style CLOUD fill:#2C3E50,stroke:#16A085,color:#fff
style GW fill:#16A085,stroke:#2C3E50,color:#fff
style FC1 fill:#16A085,stroke:#2C3E50,color:#fff
style FC2 fill:#16A085,stroke:#2C3E50,color:#fff
style HVAC1 fill:#E67E22,stroke:#2C3E50,color:#fff
style LIGHT1 fill:#E67E22,stroke:#2C3E50,color:#fff
style OCC1 fill:#E67E22,stroke:#2C3E50,color:#fff
{fig-alt=“Smart building logical topology showing cloud platform connecting to building gateway via MQTT over TLS, gateway connecting to floor controllers on each floor via Ethernet, and floor controllers managing IoT devices (HVAC sensors, lighting controllers, occupancy sensors) via Zigbee mesh network. IP addresses shown for each component including IPv4 for local devices and IPv6 for cloud connectivity. Navy cloud, teal infrastructure, orange sensors.”}
Physical Topology: - Floor controllers: One per floor, server room - HVAC sensors: Ceiling-mounted, 10m spacing - Lighting: One controller per 20 fixtures - Occupancy: Doorways and open areas - Gateway: Server room with redundant internet
786.4 Knowledge Check
Test your understanding of network design implications with these questions.
NoteRelated Chapters
Design Foundations: - IoT Network Design: Reference Model Framework - 7-Level model overview - Protocol Selection Worked Examples - Spectrum and cost analysis
Network Topologies: - Topologies Fundamentals - Star, mesh, tree structures - Networking Basics - Core networking principles
Addressing & Protocols: - IPv6 for IoT - IPv6 addressing strategies - IoT Protocols Fundamentals - Protocol characteristics
786.5 Summary
The five key design considerations form a comprehensive framework for IoT network planning:
- Devices: Power, processing, and physical constraints drive protocol selection
- Data: Volume, velocity, and latency requirements determine application protocols
- Levels 4-7: Enterprise infrastructure handles storage, analytics, and business applications
- Addressing: Scale determines IPv4 static, DHCP/NAT, or IPv6 SLAAC approach
- Topology: Both logical (data flows) and physical (device placement) documentation is essential
786.6 What’s Next?
Continue to Advanced Scenarios and Labs to apply these principles through industrial case studies, hands-on lab exercises, and detailed protocol selection scenarios.