Unit 3: IoT-Design Requirements

I. Orientation: Designing Networked IoT Systems

Internet of Things (IoT) design connects physical objects containing sensors, processors, communication interfaces, and software to networks so that they can collect data, exchange messages, and perform actions. Effective design balances functionality with constraints such as energy, bandwidth, latency, cost, interoperability, scalability, reliability, privacy, and security.

• Connected object: An IoT device has a unique identity, sensing or actuation capability, processing logic, and a wired or wireless network interface.
• End-to-end system: A typical data path is sensor → edge device → gateway → network → cloud service → application.
• Resource constraints: Devices may have only kilobytes of RAM, low-rate radio links, and batteries expected to operate for months or years.
• Interoperability: Devices using different hardware, operating systems, and communication technologies need common data formats, APIs, and protocols.
• Scalability: The architecture must accommodate growth from a few devices to millions of endpoints without excessive congestion or management overhead.
• Quality attributes: Reliability, availability, latency, maintainability, safety, privacy, and security must be treated as design requirements rather than later additions.
• Layered architecture:
  • Perception layer: Sensors and actuators interact with the physical environment.
  • Network layer: Links, gateways, routing, and messaging move data.
  • Processing layer: Edge and cloud platforms store and analyse data.
  • Application layer: Services present information or control physical processes.

II. Device Messaging and Persistent Communication

A. Message communication protocols for connected devices

Message communication protocols define how connected devices format, address, transmit, acknowledge, and receive data across a network.

• MQTT: Message Queuing Telemetry Transport uses a lightweight publish–subscribe model over TCP.
  • A publisher sends a message to a named topic such as factory/line1/temperature.
  • A broker receives and distributes messages.
  • Subscribers receive messages for topics to which they subscribe.
• MQTT quality of service:
  • QoS 0: Delivered at most once, with no acknowledgement.
  • QoS 1: Delivered at least once, so duplicates are possible.
  • QoS 2: Delivered exactly once through additional exchanges.
• CoAP: Constrained Application Protocol uses a REST-like request–response model, normally over UDP. Methods such as GET, POST, PUT, and DELETE operate on device resources.
• HTTP/HTTPS: HTTP offers universal web compatibility and straightforward REST APIs, while HTTPS adds TLS confidentiality and authentication. Its headers and TCP exchanges may be costly for constrained devices.
• AMQP: Advanced Message Queuing Protocol supports reliable queues, routing, acknowledgements, and enterprise messaging, but generally requires more resources than MQTT or CoAP.
• Protocol selection: MQTT suits asynchronous telemetry, CoAP suits constrained resource access, and HTTP suits direct integration with conventional web systems.
• Concrete exchange: A temperature node can publish the payload below to an MQTT broker whenever its reading changes.

{"deviceId":"T17","temperature":24.6,"unit":"C"}

III. Full-Duplex Web Communication

A. WebSocket

WebSocket provides a persistent, bidirectional communication channel between a client and server over one TCP connection.

• Opening handshake: Communication begins with an HTTP request containing an Upgrade: websocket header; a successful server response switches the connection to WebSocket.
• Full-duplex operation: Client and server can send frames independently without creating a new request for each message.
• Reduced overhead: After the handshake, compact frames replace repeated HTTP request and response headers, benefiting frequent real-time updates.
• IoT use cases: Browser dashboards can receive live sensor readings, alarms, device status, and actuator acknowledgements without continuous polling.
• Connection path: A common architecture is device → MQTT broker → application server → WebSocket → browser dashboard.
• Control and data frames: Text and binary frames carry application data, while ping, pong, and close frames manage connection health.
• Limitations: Persistent TCP connections consume server resources, may be disrupted by mobile network changes, and require reconnection and heartbeat logic.
• Security: wss:// protects the connection with TLS; authentication and authorization are still required to determine which devices or topics a client may access.

IV. System Constraints and Operational Goals

A. Internet of Things requirements and challenges

IoT requirements specify the capabilities and quality conditions a system must satisfy, while challenges arise from physical, computational, and organisational constraints.

• Functional requirements: The system must define what is sensed, how often measurements occur, which events trigger actions, and how users control devices.
• Non-functional requirements: Latency, throughput, availability, battery life, accuracy, and cost must have measurable targets, such as alarm delivery within 200 ms.
• Scalability: Device registries, brokers, databases, and APIs must handle increasing endpoint and message counts.
• Energy efficiency: Radio transmission often consumes more energy than local computation, making sleep modes, batching, and edge filtering important.
• Reliability: Designers must address packet loss, sensor failure, gateway outages, duplicated messages, and intermittent connectivity.
• Heterogeneity: Wi-Fi, Bluetooth Low Energy, Zigbee, cellular, and low-power wide-area networks differ in range, rate, topology, and power consumption.
• Addressing and discovery: Unique identifiers, IPv6 addressing, and service discovery allow devices to be located and managed.
• Data management: High-volume time-series data requires validation, timestamps, retention rules, and suitable storage.
• Environmental challenge: Temperature, moisture, vibration, interference, and physical obstruction can reduce component life or radio performance.
• Lifecycle management: Secure provisioning, monitoring, configuration, firmware updates, key rotation, and decommissioning must work remotely.

V. Service Delivery and Application Domains

A. Internet of Things services and applications

IoT services transform sensed data and device control into useful outcomes for individuals, organisations, and public infrastructure.

• Monitoring service: Applications display measurements, trends, device health, and geographic status using dashboards and alerts.
• Control service: Commands operate actuators such as valves, relays, motors, locks, and heating systems.
• Automation service: Rules connect events to actions, for example, if soil moisture < 25%, open irrigation valve.
• Predictive service: Analytics detects abnormal vibration or temperature patterns before equipment failure.
• Smart homes: Connected lighting, security, energy meters, and environmental controls improve convenience and efficiency.
• Healthcare: Wearable sensors can report heart rate, blood oxygen, or activity, subject to strict privacy and clinical accuracy requirements.
• Industrial IoT: Machines, programmable controllers, and sensors support production monitoring, predictive maintenance, and asset tracking.
• Smart cities: Traffic sensing, parking systems, street lighting, water monitoring, and waste collection coordinate urban resources.
• Agriculture: Soil, weather, and livestock sensors enable precision irrigation and condition-based management.
• Application constraint: Safety-critical control requires deterministic response and local fallback; a delayed cloud command must not endanger machinery or patients.

VI. Physical Sensing and Radio Interfaces

A. Internet of Things sensors and antennas

Sensors convert physical conditions into electrical or digital data, while antennas transmit and receive the electromagnetic signals used for wireless communication.

• Sensor types: Temperature, humidity, pressure, light, motion, proximity, gas, accelerometer, gyroscope, and location sensors measure different physical variables.
• Measurement properties:
  • Range: Minimum and maximum measurable values.
  • Resolution: Smallest detectable change.
  • Accuracy: Closeness to the true value.
  • Sampling rate: Measurements collected per second, expressed in hertz.
• Signal chain: An analogue sensor may require amplification, filtering, and an analogue-to-digital converter before processing.
• Calibration: Comparison against a known reference corrects offset, gain, and drift errors.
• Actuators: Motors, pumps, speakers, heaters, and relays convert digital commands into physical actions.
• Antenna frequency: Antenna dimensions and design depend on operating bands such as 2.4 GHz for Wi-Fi, Bluetooth, and some Zigbee systems.
• Wavelength relationship:

λ = c / f

• Symbols: λ is wavelength in metres, c is propagation speed (approximately 3 × 10^8 m/s in free space), and f is frequency in hertz.
• Placement: Metal enclosures, ground planes, device orientation, and nearby human tissue can detune an antenna or block signals.
• Performance measures: Gain is measured in dBi, while radiation pattern describes how effectively energy is transmitted in different directions.

VII. Cloud-Based IoT Architecture

A. Cloud computing and Internet of Things

Cloud computing supplies elastic processing, storage, networking, and managed services for IoT systems through remote data centres.

• Data ingestion: Brokers and gateways receive telemetry from large device populations.
• Elastic resources: Compute and storage capacity can increase as message volume grows and decrease during quiet periods.
• Data processing: Stream processors handle live events, while batch systems analyse historical datasets.
• Device management: Cloud platforms maintain device identities, configuration, health, credentials, and firmware versions.
• Edge–cloud balance: Edge processing reduces latency and bandwidth use; cloud processing enables centralised analytics and large-scale coordination.
• Limitations: Cloud dependence introduces network latency, recurring cost, provider dependence, data-residency concerns, and loss of functionality during outages.

B. Software as a Service

Software as a Service (SaaS) delivers complete applications over a network, with the provider managing the underlying platform and infrastructure.

• User responsibility: Customers configure the application and manage users and data rather than servers or runtime software.
• IoT examples: Hosted dashboards, fleet-monitoring portals, alert systems, and asset-management applications are SaaS offerings.
• Benefits: Rapid deployment, browser access, subscription pricing, automatic updates, and reduced maintenance.
• Constraint: Customisation and low-level control are limited by the provider’s available features and APIs.

C. Platform as a Service

Platform as a Service (PaaS) provides managed runtimes, databases, messaging, analytics, and development tools on which IoT applications are built.

• Developer responsibility: The customer manages application code and data, while the provider manages servers, operating systems, and middleware.
• IoT capabilities: Device registries, rules engines, MQTT endpoints, serverless functions, and time-series databases accelerate development.
• Benefit: Teams focus on device logic and applications instead of provisioning and patching infrastructure.
• Constraint: Proprietary APIs may create vendor lock-in and complicate migration between platforms.

D. Infrastructure as a Service

Infrastructure as a Service (IaaS) supplies virtual machines, storage, and networks as configurable computing resources.

• Customer responsibility: The customer manages operating systems, middleware, applications, security configuration, and data.
• IoT use: An organisation can deploy its own MQTT broker, analytics cluster, database, and virtual network on rented infrastructure.
• Benefit: IaaS provides extensive control and supports specialised software or compliance requirements.
• Constraint: Greater control creates greater operational responsibility for patching, scaling, backups, and availability.
• Service-model comparison: SaaS offers the least infrastructure control, PaaS offers application-level control, and IaaS offers the greatest system-level control.

VIII. Protection of Connected Systems

A. Security issues in the Internet of Things

IoT security protects devices, communications, services, data, and physical processes throughout the complete device lifecycle.

• Weak authentication: Default or hard-coded passwords allow unauthorised access; each device should receive unique credentials during provisioning.
• Confidentiality: TLS or DTLS encryption prevents passive observers from reading telemetry and commands in transit.
• Integrity: Message authentication codes and digital signatures reveal unauthorised modification.
• Authorisation: Least-privilege policies restrict a device or user to necessary resources, commands, and MQTT topics.
• Insecure firmware: Secure boot verifies firmware before execution, while signed over-the-air updates prevent installation of malicious code.
• Physical attacks: Exposed debug ports, removable storage, and unattended outdoor devices can reveal keys or permit firmware extraction.
• Privacy: Location, occupancy, health, and behavioural data require minimisation, informed use, controlled retention, and access auditing.
• Availability: Denial-of-service attacks, radio jamming, battery-drain attacks, and broker overload can interrupt essential services.
• Botnets: Compromised devices may be remotely coordinated for scanning or distributed attacks, especially when patching mechanisms are absent.
• Lifecycle controls: Security includes manufacturing trust, credential rotation, vulnerability monitoring, incident response, secure reset, and credential deletion at decommissioning.
• Risk principle: Controls should reflect impact; compromise of a room-temperature sensor differs from compromise of a medical pump or industrial safety actuator.