Internet of Things Architecture, Protocols and Smart City Apps
Module 1 – Introduction to IoT (ECT 458)
IoT: Global network of physical/virtual “things” with unique identities, exchanging data via interoperable protocols. Enables data sensing, collection, sharing, and intelligent actions with context awareness.
Characteristics
- Dynamic / Self-adapting — responds to context changes (e.g., day/night cameras).
- Self-configuring — automatic updates and network configuration.
- Interoperable protocols — supports multiple standards.
- Unique identity — IP, URI, or other unique identifiers.
- Integrated information networks — seamless data exchange.
Physical Design
Things: Devices with sensing, actuation, and monitoring capabilities.
IoT device block: Sensors / actuators + MCU / SoC + communication + power.
Link Layer
- Ethernet (802.3) — wired LAN (10 Mbps to 40 Gbps)
- Wi‑Fi (802.11a/b/g/n/ac/ax) — WLAN (11–600 Mbps)
- WiMAX (802.16) — wireless MAN (1.5 Mbps–1 Gbps)
- LR‑WPAN (802.15.4) — ZigBee, low power (40–250 kbps)
- 2G / 3G / 4G — GSM / CDMA / LTE (9 kbps–100 Mbps)
Network Layer
- IPv4 (32‑bit) & IPv6 (128‑bit) — addressing
- 6LoWPAN — IPv6 adaptation for low‑power devices
Transport Layer
- TCP — reliable, connection‑oriented, ordered delivery
- UDP — unreliable, fast, connectionless delivery
Application Layer
- HTTP — web protocol using request/response over TCP
- CoAP — lightweight HTTP‑like protocol for constrained devices over UDP
- WebSocket — persistent, full‑duplex TCP‑based protocol for real‑time bidirectional communication
- MQTT — lightweight publish/subscribe messaging via broker (low bandwidth, IoT optimized)
- XMPP — real‑time messaging via XML (chat, presence, control)
- DDS — data‑centric pub/sub, real‑time with QoS control
- AMQP — business messaging (queues + exchanges), supports pub/sub and peer‑to‑peer routing
Logical Design – Functional Blocks
Functional blocks include:
- Devices — sensors and actuators
- Communication — connectivity
- Services — device management, discovery, data services
- Management — configuration and monitoring
- Security — authentication, integrity, encryption
- Application — user interface and application logic
Communication Models
- Request‑Response: Client sends a request; server responds (stateless).
- Publish‑Subscribe: Publishers send to a broker; consumers receive from topics.
- Push‑Pull: Producers push to a queue; consumers pull (buffering supported).
- Exclusive Pair: Persistent stateful full‑duplex link (e.g., WebSocket).
Communication APIs
- REST API — stateless, resource‑oriented over HTTP (standard for web‑based communication).
- WebSocket API — full‑duplex TCP‑based, real‑time browser‑to‑server communication.
Enabling Technologies
- WSN — distributed sensor nodes collect and route data via a coordinator.
- Cloud computing — on‑demand compute and storage (IaaS, PaaS, SaaS).
- Big data analytics — high‑volume, high‑velocity, high‑variety datasets analyzed for insights.
- Embedded systems — dedicated microcontroller‑based systems for specific tasks.
- Communication protocols — enable reliable, ordered, secure data exchange.
IoT Levels
- L1: Single node, local processing (e.g., smart light).
- L2: Single node + cloud storage, local analysis (e.g., cloud irrigation).
- L3: Node + cloud analysis, large data handling (e.g., health apps).
- L4: Multi‑node with local/cloud, real‑time synchronization (e.g., industrial IoT).
- L5: WSN with coordinator and many end nodes (e.g., smart grid).
- L6: Multiple independent nodes + cloud‑based application + centralized control.
Module 2 – M2M, SDN, NFV, Smart Objects
Machine‑to‑Machine (M2M) Communication
M2M refers to the networking of machines for remote monitoring, control, and data exchange using embedded hardware modules.
M2M area networks consist of machines with sensing, actuation, and communication capabilities. Communication often uses proprietary or non‑IP protocols such as ZigBee, Bluetooth, and 6LoWPAN inside the M2M area.
M2M gateway bridges non‑IP M2M area networks with IP‑based networks by translating non‑IP protocols into IP for external communication.
Difference Between IoT and M2M
- M2M commonly uses proprietary or non‑IP communication protocols; IoT leverages global standards like HTTP and WebSockets.
- M2M focuses on hardware and embedded modules; IoT emphasizes software, data collection, and cloud integration.
- M2M involves homogeneous machines; IoT supports heterogeneous smart objects.
- In M2M, data is often stored locally (on‑premises); in IoT, data is frequently cloud‑based.
- M2M supports standalone local applications; IoT enables cloud‑integrated and cross‑domain applications.
Software‑Defined Networking (SDN)
SDN is a network model where the control plane (routing decisions) is separated from the data plane (data forwarding), allowing centralized and programmable network management.
In conventional networks, control and data planes are combined in the same device (e.g., traditional routers), which leads to complex reconfiguration for dynamic traffic, high management overhead, and poor scalability in large IoT deployments.
SDN architecture includes a centralized controller that dynamically manages network devices, programmable APIs for configuring the network, and a standard interface such as OpenFlow to control devices.
Network Function Virtualization (NFV)
NFV replaces dedicated hardware (routers, firewalls, load balancers) with software running on virtual machines. It separates network functions from physical hardware, enabling multiple services to share the same infrastructure. This reduces the need for specialized hardware and supports easy software upgrades without hardware changes.
Management and Orchestration (MANO) handles the lifecycle of virtualized network functions (VNFs), including deployment, operation, and updates.
Smart Objects in IoT
Smart objects are physical devices embedded with sensors, actuators, processing units, and communication interfaces that interact meaningfully with their environment. They can sense data, process it, act via actuators, and connect with other devices or the internet through wired or wireless channels. These objects are usually battery‑operated and designed to be power‑efficient. Trends include low‑power operation, intelligent behavior at the device level, and cooperative networking among smart devices.
Sensors
Sensors detect physical conditions (e.g., temperature, humidity) and convert them into digital signals for processing.
- Active sensors require external power (e.g., carbon microphone).
- Passive sensors are self‑powered (e.g., thermocouple, piezoelectric).
- Contact sensors (strain gauge, moisture sensor) require physical contact; non‑contact sensors (IR thermometer) do not.
- Invasive sensors (e.g., blood glucose sensor) are inserted into the measured system; non‑invasive sensors (ECG, EEG) are not.
- Absolute sensors (thermistors) measure values independently; relative sensors (thermocouples) compare values to a reference.
Actuators
Actuators convert control signals into physical effects such as motion, force, or energy. They can produce linear or rotary motion, and vary by power output (from high‑power to micro‑power). Binary actuators like relay switches have two stable states; continuous actuators like DC motors provide smooth output. Actuators may be powered electrically, hydraulically, or pneumatically.
MEMS (Micro‑Electro‑Mechanical Systems)
MEMS are tiny devices integrating mechanical components with electronics, sensors, and actuators on a microscopic scale. They are manufactured using microfabrication techniques similar to those used for integrated circuits. Examples include accelerometers, gyroscopes, and micropumps.
Wireless Sensor Networks (WSN)
WSNs consist of wireless sensor nodes that monitor physical or environmental conditions. Nodes collaborate to collect and transmit data and are typically resource‑constrained (memory, processing, battery). Communication patterns can be event‑driven (data sent when an event occurs) or periodic (data sent at regular intervals). Hierarchical models group nodes and aggregate data to reduce communication load and energy consumption. Disadvantages of WSNs include reduced security compared to wired systems, limited data rates, and vulnerability to environmental interference.
Module 3 – IoT Access Technologies
Access technologies in IoT include both wired and wireless types. Wired options include Ethernet and Power Line Communication (PLC). Wireless options are classified into cellular (2G, 3G, LTE, 5G) and non‑cellular (Wi‑Fi, ZigBee, LoRa, Bluetooth).
Common information set for IoT technologies
Standardization bodies like IEEE and 3GPP define communication standards. The physical layer specifies the medium and operating frequency (e.g., 2.4 GHz). The MAC layer governs media access control rules. Topology may be star, mesh, or peer‑to‑peer. Security includes encryption methods such as AES.
IEEE 802.15.4
IEEE 802.15.4 is a wireless standard for low‑power, low‑data‑rate personal area networks (WPANs), targeting battery‑operated devices. Examples include ZigBee and 6LoWPAN. The physical layer operates in the 2.4 GHz band with 16 channels and a 250 kbps data rate. Modulation techniques include BPSK (Binary Phase Shift Keying), OQPSK (Offset Quadrature PSK), and ASK. The PHY frame format consists of a preamble, PHY header, and PHY payload. The MAC layer provides access control to the PHY layer, manages frame scheduling and routing, supports network beaconing by PAN coordinators, and ensures reliable link communication. Frame types include data, beacon, acknowledgement, and MAC command frames. Security uses AES‑128 encryption with message integrity code (MIC) validation. Supported topologies are star, mesh, and peer‑to‑peer.
IEEE 802.15.4e and 802.15.4g
IEEE 802.15.4e enhances MAC reliability and addresses latency and multipath fading. It introduces Time‑Slotted Channel Hopping (TSCH), which combines TDMA and frequency hopping for robustness. It also adds Enhanced Beacons (EBs) and improved acknowledgement features.
IEEE 802.15.4g is optimized for smart utility networks such as smart grids. It introduces a new PHY layer supporting larger packet sizes (up to 2047 bytes compared to 127 bytes in standard 802.15.4) and frequency bands ranging from 169 MHz to 2.4 GHz. Modulation schemes include MR‑FSK, MR‑OFDM, and MR‑OQPSK.
Industrial and LPWAN Protocols
Modbus protocol is an industrial communication protocol developed in 1979. It uses a master‑slave model with request/response communication. It is widely used in PLC (Programmable Logic Controller) and SCADA (Supervisory Control and Data Acquisition) systems.
ZigBee is built on IEEE 802.15.4 PHY and MAC layers and adds network and application layer functions. It targets low‑power, low‑data‑rate applications. Supported topologies include mesh, star, and tree. ZigBee offers AES‑128 encryption at the network and application layers and uses AODV (Ad hoc On‑demand Distance Vector) for routing. Applications include home automation, industrial control, and smart energy systems.
LoRa and LoRaWAN are designed for long‑range, low‑power communication. LoRa uses chirp spread spectrum modulation for extended range and energy efficiency. LoRaWAN is the corresponding network architecture, structured in a star‑of‑stars topology where end devices communicate with multiple gateways. End devices are categorized as Class A (minimum power, ALOHA‑based), Class B (scheduled communication using beacons), and Class C (continuous listening). Security is provided through two‑layer AES encryption using a Network Session Key (NwkSKey) and an Application Session Key (AppSKey).
Cellular networks for IoT face challenges when using traditional GPRS, 3G, and LTE since they are not optimized for low‑power and small‑data devices.
LTE‑M (LTE for Machines) is based on LTE Release 12. It supports a 1.4 MHz bandwidth, lower data rates (~200 kbps), half‑duplex communication, and Enhanced Discontinuous Reception (eDRX) for power savings.
NB‑IoT (Narrowband IoT) is designed for low‑power, low‑data‑rate IoT. It can be deployed in standalone mode using GSM spectrum, in‑band mode within LTE carriers, or guard‑band mode between LTE channels. NB‑IoT uses OFDMA for downlink communication.
IP‑based Protocols and Optimization
IP‑based protocols for IoT offer benefits such as openness, standardization, versatility, wide deployment, security, manageability, and stability.
Adoption of IP involves fully replacing non‑IP protocols with IP‑based ones. Adaptation means translating non‑IP protocols into IP at gateways. The choice between adoption and adaptation depends on factors such as unidirectional versus bidirectional communication, tolerance to data overhead, and heterogeneity of network environments.
Optimizing IP for IoT is crucial due to limited resources in IoT devices.
6LoWPAN (IPv6 over Low Power Wireless Personal Area Networks) enables efficient IP communication over IEEE 802.15.4 networks. Features include header compression, fragmentation to handle small frame sizes (127 bytes), and mesh addressing for multi‑hop communication.
RPL (Routing Protocol for Low‑Power and Lossy Networks) is an IPv6‑based distance‑vector protocol that constructs Destination Oriented Directed Acyclic Graphs (DODAGs). It supports both storing and non‑storing modes to handle routing table management at different nodes.
RPL messages include DIO (DAG Information Object) to advertise routing information and DAO (Destination Advertisement Object) to support downward routing.
Routing metrics in RPL include ETX (Expected Transmission Count), hop count, latency, link quality, node energy, and throughput.
Module 4 – Data Collection, Storage & IoT Physical Devices
Conventional data collection methods include local storage via removable media like microSD cards, saving data on local device servers or coordinating nodes, distributed DBMS with local or remote storage, and using internet‑connected web servers or enterprise data centers.
Key Terms
Resource — any modifiable entity such as a file or application.
System resource — OS, memory, server, or software components.
Environment — platforms for programming and execution.
Platform — hardware + OS + network for deploying software.
Edge computing shifts computation to IoT data sources to reduce latency. Distributed computing uses multiple remote resources. A service is a software unit providing functionality via APIs. Web services are XML‑based, accessible via URLs (WSDL‑defined), exchanging data over the internet. Web computing utilizes web server resources. Grid computing pools interconnected systems. XaaS (Anything as a Service) enables flexible deployment via cloud using SOA principles.
Cloud Computing
Cloud computing delivers services over the internet using infrastructure such as data centers, grids, or web service networks—similar to electricity supply. It connects devices, data, apps, services, people, and businesses into a unified virtualized environment.
Virtualization
Virtualization abstracts storage (via DB interfaces or logical drives), networks (appearing as one), servers (access to many), and desktops (access across OS platforms). Applications need only internet access; the cloud platform handles OS independence.
Cloud Features and Models
Features of cloud computing include on‑demand self‑service, resource pooling in multi‑tenant environments, broad network access, elasticity, scalability, high availability, maintainability, resiliency, advanced security, and low‑cost pay‑per‑use models. Concerns include the need for constant internet, risk of data loss, varying APIs, and reduced user control in multi‑tenant environments.
Cloud deployment models include public (open use), private (internal organizational use), community (organizations with common needs), and hybrid (a mix of types with integrated apps/data).
Cloud service models include SaaS (cloud‑hosted apps like Gmail), PaaS (developer platforms like Google App Engine), IaaS (cloud infrastructure like AWS EC2), and DaaS (data‑as‑a‑service via on‑demand storage).
IoT Cloud Platforms
Xively and Nimbits are examples.
Xively (formerly owned by Google) is an open‑source IoT PaaS supporting REST, MQTT, and WebSocket. It provides real‑time data collection, visualization, alerting, and device connectivity. Key elements include users, feeds (device or location), data streams (sensor output), data points (values), and triggers (state‑based actions). It supports pull (from server) and push (to cloud) data modes.
Nimbits is an open‑source distributed PaaS for IoT, deployable on device nodes. It supports edge computing, rule‑based automation, data logging, visualization, and integration with Arduino, Raspberry Pi, JavaScript, and cloud platforms. It offers data relay, a rule engine for alerts, format flexibility (JSON, XML), noise filtering, geo/time‑stamping, and remote access. It is deployable on Google App Engine, J2EE, Amazon EC2, or Raspberry Pi.
Basic Building Blocks of IoT Devices
- Sensing — collecting data from the environment.
- Actuation — triggering physical actions (e.g., turning appliances on/off).
- Communication — exchanging data with other devices or the cloud.
- Processing — local data analysis and decision making.
Raspberry Pi
Raspberry Pi is a compact Linux‑based computer with GPIO pins for sensor and actuator interfacing. Raspberry Pi 2 Model B has a 700 MHz ARM CPU, 512 MB RAM, 2 USB 2.0 ports, Ethernet port, HDMI and composite video outputs, audio jack, GPIOs for SPI, I2C, UART, DSI for displays, CSI for cameras, 5 status LEDs, SD card slot (OS/storage), and micro‑USB power input.
Supported OS includes Raspbian (Debian), Pidora (Fedora), RaspBMC / OpenELEC (media), and RISC OS (compact).
Interfaces
UART: serial Tx / Rx for simple communication.
SPI: synchronous master‑slave protocol using MISO, MOSI, SCK, CE0, CE1.
I2C: two‑wire SDA / SCL for multi‑device communication (combines advantages of UART and SPI).
LED Control Example
The LED control example uses Python with the GPIO library. Setup includes configuring BCM mode, suppressing warnings, defining output pins, and toggling GPIO.HIGH / GPIO.LOW to blink an LED with time.sleep.
Other IoT Devices
pcDuino: Arduino‑compatible, 1 GHz ARM Cortex‑A8, runs Ubuntu / Android, supports HDMI, C / C++ / Java.
BeagleBone Black: More powerful than Raspberry Pi, 1 GHz Cortex‑A8, runs Linux / Android, supports HDMI, USB, Ethernet.
Cubieboard: Dual‑core Cortex‑A7 with USB, HDMI, SATA, IR, serial, and extended interface; supports Linux / Android.
Module 5 – IoT Security and Smart Cities
IoT Security
IoT security ensures protection of transmitted data, while privacy safeguards personal information from unauthorized exposure. IoT design must ensure trust, privacy, and security.
Key Concepts
- Message — a string exchanged between sender and receiver.
- Hash / Digest — a one‑way function for integrity checks.
- Encryption — secures data with a secret key.
- Decryption — restores original data.
- Use case — defines standard interactions between systems.
- Misuse case — shows reverse or threat scenarios.
- Firewall — a barrier between trusted and untrusted networks.
- Message privacy — restricts access to data by unrelated parties.
- Privacy policy — decides what data must remain fully or partially private.
IoT Vulnerabilities
Vulnerabilities arise from limited security in devices. Examples include eavesdropping, brute‑force attacks, and key cracking. OWASP lists top issues: insecure interfaces, poor authentication, unencrypted transport, privacy concerns, insecure cloud / mobile interfaces, lack of configuration, insecure firmware, and poor physical security.
Security Requirements
- Identity management — to recognize devices and users.
- Authentication — to verify identities.
- Authorization — to define access rights.
- Key management — to secure cryptographic operations.
- Trust and reputation — to establish entity reliability.
Threat Analysis
Threat analysis detects design flaws using STRIDE: spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege.
IoT Security Tomography
Maps vulnerabilities across layers:
- Layer 1 — link‑level AES encryption.
- Layer 2 — VLAN security, ARP inspection.
- Layer 3 — tamper‑resistant routing, packet filtering.
- Layer 4 — DTLS, SASL for secure transport.
- Layer 5–6 — HTTPS, digital signatures, content encryption.
Cisco’s security model provides role‑based security, anti‑tamper mechanisms, confidentiality, and IP protection across all layers.
Identity, Authentication and Authorization
Identity management involves managing device IDs, pseudonyms, and secure interactions.
Authentication uses hash functions (e.g., SHA‑256) that are one‑way, collision‑resistant, and secure against pre‑image attacks.
Authorization models include:
- ACL — access based on static lists.
- RBAC — access based on user roles.
- ABAC — access based on dynamic attributes (user, resource, action, environment).
Access control can be enforced via cloud‑based gateways or servers.
Message Integrity and Non‑Repudiation
Message integrity ensures data is unaltered during transit. Process example:
- Hash M0 with key K → h0
- Transmit h0 with the message
- At receiver, compute h1 from M1 and K
- If h1 = h0, the message is valid.
- Non‑repudiation uses digital signatures backed by trusted third‑party certification.
Message availability is threatened by DoS, ICMP flood, and SYN flood. Mitigations include firewalls and anti‑DoS systems.
Smart Cities and IoT
Urban Challenges and IoT Benefits
Challenges in urbanization include population growth, pollution, energy crises, traffic, housing shortages, and strained infrastructure. IoT solutions improve efficiency, reduce emissions, and enhance quality of life.
Smart city strategy integrates sensors, edge computing, and cloud to automate and optimize infrastructure services.
Smart City Verticals
- Smart buildings — energy‑efficient HVAC and automated systems.
- Smart parking — occupancy detection and reservation systems.
- Smart traffic — adaptive signals and vehicle detection.
- Water management — leak detection, real‑time usage monitoring, irrigation control.
- Energy monitoring — smart grid and renewable integration.
- Air quality — distributed real‑time pollution sensors.
Smart City Architecture
Street layer — devices, sensors, and controllers (e.g., magnetic parking sensors, air quality monitors, video analytics, lighting controllers). Sensors may be pole‑mounted or underground and must be durable, battery‑efficient, and rugged.
Communication — uses Wi‑Fi, ZigBee, LoRa, 802.15.4g with vendor‑agnostic gateways and edge analytics. Event‑driven systems reduce load and enable real‑time processing.
City layer — aggregates traffic and delay‑sensitive data via resilient Ethernet protocols, ensuring redundancy and reliable routing.
Data center layer — processes data in cloud or fog (local gateways). Supports scalable, elastic computing for analytics, real‑time insights, and adaptive services.
Services layer — hosts smart city applications serving city operations, law enforcement, and citizens. APIs enable cross‑domain benefits.
Smart City Security
- Sensor‑level — device ID, encryption, tamper detection.
- Network‑level — firewalls, VLANs, VPNs.
- Data‑level — encryption at rest and in transit, secure VPCs, dynamic perimeters.
- Modern protocols — mTLS and OAuth 2.0 for identity and trust management.
Smart City Use Cases
Connected street lighting — LEDs reduce energy costs, support remote scheduling and dimming, and adapt based on weather, location, or time. Lighting nodes use ZigBee, Wi‑Fi, LoRaWAN, etc. for communication and are managed via cloud applications.
Smart parking — reduces congestion, pollution, and fuel use. Sensors include magnetic, video, and radar, enabling real‑time updates and dynamic pricing.
Smart traffic control — uses crowd and vehicle detection, video analytics, and sensors to coordinate traffic lights, reroute traffic based on congestion, and detect wrong‑way driving or violations.
Air pollution monitoring — augments static stations with distributed sensors for hyper‑local real‑time tracking and supports cross‑domain response and visual dashboards.
Smart water management — monitors usage, detects leaks, and schedules irrigation to reduce waste and enhance compliance with civic restrictions.
Integration and ROI — combining verticals boosts livability and investment attractiveness. Fog / cloud processing helps balance cost and performance for real‑time city operations.
