Unit 5: Messaging Queues and Publish/Subscribe Communications

I. Orientation — Messaging and Session Control in IoT

IoT communication requires both data exchange and session management. Publish/subscribe protocols such as MQTT and AMQP distribute messages through intermediaries, while session-initiation protocols establish, modify, and terminate communication relationships between constrained devices.

• Messaging model: Applications exchange discrete messages rather than sharing memory or maintaining tightly coupled procedure calls.
• Publish/subscribe convention: Publishers send data under named topics; subscribers express interest in topics; a broker performs distribution.
• Queueing convention: An intermediary may store messages until a consumer can process them, reducing dependence on simultaneous availability.
• Session: A logical communication relationship with identifiable participants, state, parameters, and a defined lifetime.
• Constrained environment: IoT nodes commonly have limited RAM, processing power, battery capacity, and network bandwidth.
• Transport assumption: MQTT normally uses TCP, AMQP 1.0 uses a reliable transport such as TCP, and constrained session protocols may use UDP to reduce overhead.
• Design priority: Protocol selection balances reliability, latency, interoperability, implementation complexity, and energy consumption.

II. MQTT — Lightweight Broker-Based Messaging

MQTT is a compact publish/subscribe application-layer protocol designed for telemetry and machine-to-machine communication over networks where bandwidth or device resources may be limited.

A. Message Queue Telemetry Transport

Message Queue Telemetry Transport, commonly called MQTT, separates message producers from consumers through an MQTT broker.

• Architecture:
  • Publisher: Sends a PUBLISH packet containing a topic and payload.
  • Broker: Receives, filters, and forwards publications.
  • Subscriber: Registers interest by sending a SUBSCRIBE packet.
• Topic structure: Topics are hierarchical UTF-8 strings such as factory/line1/temperature; / separates levels.
  • + matches one level, as in factory/+/temperature.
  • # matches all remaining levels, as in factory/#.
• Connection sequence: A client opens a TCP connection, sends CONNECT, and receives CONNACK; MQTT over TLS commonly uses TCP port 8883, while unencrypted MQTT commonly uses 1883.
• Quality of Service:
  1. QoS 0—at most once: One PUBLISH transmission with no application-layer acknowledgement; loss is possible.
  2. QoS 1—at least once: PUBLISH is acknowledged by PUBACK; duplicates are possible.
  3. QoS 2—exactly once: A four-part exchange—PUBLISH, PUBREC, PUBREL, PUBCOMP—prevents duplicate delivery at the MQTT protocol level.
• Retained message: With the RETAIN flag, the broker stores the latest retained publication for a topic and supplies it to new matching subscribers.
• Session state: MQTT can preserve subscriptions and undelivered QoS messages. MQTT 5 uses a Session Expiry Interval; MQTT 3.1.1 uses the Clean Session flag.
• Liveness detection: The Keep Alive value limits silence between client control packets; PINGREQ and PINGRESP verify that the connection remains active.
• Unexpected-disconnect reporting: A Will Message registered during CONNECT is published by the broker if the client disconnects abnormally.
• Payload neutrality: MQTT does not prescribe payload representation; JSON, CBOR, text, and binary sensor records can all be carried.
• Concrete example: A sensor publishing 21.6 to building/room7/temp at QoS 1 receives PUBACK; every client subscribed to that topic receives the publication according to its granted QoS.

III. MQTT and AMQP — Protocol Comparison

MQTT and AMQP both support broker-mediated messaging, but MQTT emphasizes lightweight telemetry whereas AMQP provides richer enterprise messaging semantics.

A. MQTT versus AMQP

The protocols differ principally in abstraction, routing capability, overhead, and intended deployment environment.

1. MQTT

   • Core abstraction: Clients publish to hierarchical topics, and the broker matches subscriptions through topic filters.
   • Protocol weight: The smallest MQTT control packet has a two-byte fixed header, making routine exchanges economical.
   • Delivery control: QoS levels 0, 1, and 2 define progressively stronger delivery handshakes.
   • Device suitability: Small libraries and simple broker interaction suit sensors, gateways, mobile links, and intermittent telemetry.
   • Limitation: MQTT does not standardize enterprise concepts such as transactions, complex queue policies, or routing exchanges.

2. AMQP

   • Core abstraction: AMQP 1.0 models nodes, links, sessions, and connections; messages travel over links between sending and receiving endpoints.
   • Messaging richness: It supports typed message sections, link credit for flow control, settlement outcomes, and sophisticated intermediary behavior.
   • Reliability: Delivery states and settlement determine whether responsibility for a transfer has moved between peers.
   • Enterprise suitability: Strong interoperability and detailed messaging semantics suit financial systems, back-end integration, and dependable work queues.
   • Cost: More protocol state, framing, and implementation complexity generally require greater memory and processing capacity.

• Explicit contrast: MQTT answers “which topic should receive this telemetry?”, while AMQP more fully describes “how should this message be routed, transferred, credited, and settled?”
• Selection rule: A battery-powered sensor sending periodic readings usually favors MQTT; a data-center workflow requiring controlled delivery and broker interoperability may favor AMQP.
• Security: Both can use TLS and authentication, but authorization remains broker-specific—for example, an access-control rule may permit publication to device/42/data but deny device/43/data.

IV. Publish/Subscribe Communications — Decoupled Distribution

The publish/subscribe model routes events according to declared interest rather than requiring a producer to address every receiver directly.

A. Advantages and disadvantages of the publish/subscribe model

Publish/subscribe improves scalability and flexibility, but introduces intermediary dependence and weaker end-to-end visibility.

1. Advantages

   • Space decoupling: A temperature sensor need not know the addresses of the dashboard, alarm service, or database.
   • Time decoupling: Persistent broker state can allow information to survive temporary subscriber disconnection.
   • One-to-many delivery: One publication can serve many subscribers without the publisher transmitting a separate copy to each.
   • Scalability: Topic filtering allows consumers to receive only relevant data, such as farm/field3/#.
   • Dynamic membership: Subscribers can join or leave without changing publisher code.
   • Fault isolation: A slow consumer does not necessarily block the producer because the broker can buffer or queue messages.
   • Extensibility: A new analytics service can subscribe to an existing topic without modifying deployed sensors.

2. Disadvantages

   • Broker dependency: A single broker can become a failure point or bottleneck unless clustering, replication, or failover is provided.
   • Added latency: Each message traverses an intermediary instead of following a direct producer-to-consumer path.
   • Ordering complexity: Global ordering is difficult across topics, publishers, broker nodes, and reconnecting sessions.
   • Duplicate or lost delivery: QoS 0 permits loss, while QoS 1 permits duplicates; applications may require message identifiers and idempotent processing.
   • Security concentration: A compromised broker may expose many topics, credentials, and retained messages.
   • Observability difficulty: Decoupling makes it harder to trace which publication triggered a later consumer action.
   • State growth: Persistent subscriptions, retained publications, and offline queues consume broker storage.

V. IoT Session Establishment — Constrained Signaling

Session signaling allows IoT endpoints to negotiate a temporary interaction, including participants, media or data formats, transport addresses, and operational parameters.

A. Session initiation for the Internet of Things

Session initiation provides explicit control where merely publishing isolated messages does not adequately describe an ongoing interaction.

• Purpose: It can establish a voice stream, video feed, actuator-control channel, or negotiated sensor-data stream.
• Negotiated information: Typical parameters include endpoint identifiers, IP addresses, ports, transport protocol, media type, encoding, timing, and security requirements.
• Signaling versus data: Control messages create the session, while actual data may subsequently travel over RTP, CoAP, UDP, TCP, or another protocol.
• SIP foundation: The Session Initiation Protocol uses request/response signaling and methods such as INVITE, ACK, BYE, and re-INVITE.
• IoT difficulty: Conventional SIP commonly carries verbose textual headers, which burden low-power radios and devices with small packet buffers.
• Reliability requirement: Session signaling must handle retransmissions, duplicate requests, unreachable nodes, and endpoints that sleep to conserve energy.

B. Lightweight Sessions in the IoT

Lightweight sessions retain necessary state and negotiation while minimizing bytes, round trips, processing, and radio-on time.

• Minimal state: Endpoints store only essential identifiers, sequence information, negotiated parameters, and timeout values.
• Compact representation: Binary encoding, abbreviated fields, or predefined profiles reduce the size of repeated headers.
• UDP suitability: UDP avoids TCP connection establishment but requires the signaling protocol to supply retransmission and duplicate detection where needed.
• Gateway support: A capable border gateway may maintain directory, translation, authentication, or proxy state for constrained nodes.
• Energy effect: Fewer packets reduce radio transmissions, which are often more energy-expensive than local computation.
• Trade-off: Excessive simplification can remove useful negotiation, error reporting, extensibility, or interoperability.

C. A protocol for constrained session initiation

A constrained session-initiation protocol adapts SIP-like lifecycle operations to resource-limited devices using compact messages and reduced signaling complexity.

• Common designation: CoSIP refers to constrained session-initiation approaches designed to preserve SIP-style operations with lower overhead.
• Core functions: The protocol identifies endpoints, proposes session parameters, accepts or rejects proposals, modifies active parameters, and terminates state.
• Proxy operation: A gateway can translate compact constrained signaling into conventional SIP when communicating with Internet or multimedia infrastructure.
• Message correlation: A session identifier and transaction identifier associate responses with requests and distinguish retransmissions.
• Reliability over UDP: Timers and retransmission rules compensate for packet loss; duplicate detection prevents repeated session creation.
• Security requirement: Authentication, authorization, integrity protection, and replay prevention are necessary when sessions control physical devices.

VI. Session Lifecycle — Establishment, Change, and Closure

A session follows a controlled lifecycle: initiation creates shared state, modification changes agreed parameters, and tear-down releases that state.

A. Session initiation

Session initiation negotiates a mutually acceptable set of communication parameters before application data exchange begins.

• Request: Initiator A sends a session proposal to responder B, directly or through a proxy.
• Description: The proposal may specify UDP, port 5004, a sensor format such as CBOR, and a sampling interval of 10 s.
• Response: B accepts, rejects, redirects, or returns alternative parameters.
• Confirmation: A final acknowledgement confirms that both endpoints recognize the established session.
• State transition: Conceptually, both parties move from IDLE through PENDING to ESTABLISHED.
• Failure handling: A timeout returns the initiator to IDLE; transaction identifiers ensure that a retransmitted proposal does not create a second session.

B. Session tear-down

Session tear-down explicitly terminates communication and releases resources at every participating endpoint.

• Termination request: Either endpoint may send a closure message analogous to SIP BYE.
• Acknowledgement: The peer confirms termination so both sides can remove matching session state.
• Resource release: Reserved ports, buffers, timers, security associations, and gateway mappings are released.
• Abnormal termination: Keep-alive failure, lease expiry, network loss, or device shutdown may trigger timeout-based cleanup.
• Idempotence: Repeated tear-down messages should produce the same final CLOSED state rather than an error or duplicated side effect.
• Security: A forged termination packet could disable an actuator or alarm stream, so the request should be authenticated and protected against replay.

C. Session modification

Session modification renegotiates selected parameters without discarding the entire established relationship.

• Changeable properties: Participants may alter sampling rate, destination port, codec, resolution, QoS expectation, or security parameters.
• Negotiation pattern: One endpoint proposes an updated description; the peer accepts it, rejects it, or supplies an alternative.
• Atomicity: Old parameters remain active until both endpoints agree, preventing one side from changing prematurely.
• Version control: A sequence number or session-version field distinguishes a current modification from a delayed earlier request.
• Concrete example: A camera session may change from 1080p at 30 frames/s to 720p at 15 frames/s when available bandwidth falls.
• Concurrency control: Simultaneous modification attempts require ordering or conflict-resolution rules to avoid inconsistent session state.