CoAP

CoAP (Constrained Application Protocol) is a specialized application-layer protocol designed for use in resource-constrained IoT devices and networks. Unlike MQTT which follows a publish-subscribe model over TCP, CoAP follows a request-response model similar to HTTP but is built over UDP to minimize overhead. It is standardized in RFC 7252 and is specifically designed for machine-to-machine (M2M) communication in low-power, lossy networks (LLNs).

Core Concept Explanation

CoAP is designed to look and behave like HTTP from an application design perspective while consuming far fewer resources. It uses the same methods: GET, POST, PUT, and DELETE. Resources are identified by URIs such as coap://192.168.1.10/temperature. However, instead of TCP, CoAP uses UDP as the transport layer, reducing connection overhead dramatically.

To compensate for UDP's unreliability, CoAP introduces its own lightweight reliability mechanism. Messages classified as Confirmable (CON) must be acknowledged by the receiver. If no ACK is received within a timeout window, the sender retransmits with exponential back-off. Messages classified as Non-Confirmable (NON) are sent without expecting an ACK, suitable for periodic sensor data where an occasional lost packet is acceptable.

Every CoAP message carries a Message ID (MID) for deduplication and an optional Token to match responses to requests when multiple requests are in flight. The fixed header is exactly 4 bytes, compared to HTTP headers that run into hundreds of bytes.

CoAP vs HTTP vs MQTT

CoAP occupies a unique position in the IoT protocol landscape. Unlike HTTP which is too heavy for constrained nodes, and unlike MQTT which requires a broker infrastructure, CoAP allows direct client-to-server interaction without any intermediary. This makes CoAP suitable for deployments where devices interact directly with each other or with a local edge server without cloud dependency.

CoAP also includes an Observe extension (RFC 7641) that adds publish-subscribe-like behavior. A client can register to observe a resource, and the server sends notifications whenever the resource changes. This bridges the gap between CoAP and MQTT for event-driven scenarios.

Mathematical Expression

The retransmission timeout in CoAP uses exponential back-off:

timeout_n = ACK_TIMEOUT x 2^n x random_factor, where n = retransmission number

ACK_TIMEOUT is defined as 2 seconds in RFC 7252. With random_factor in range [1.0, 1.5], the initial timeout is 2–3 seconds. After 4 retransmissions (MAX_RETRANSMIT = 4), the message is considered failed. Total maximum wait before failure = 2 + 4 + 8 + 16 = 30 seconds approximately.

Practical Understanding

CoAP is particularly effective in 6LoWPAN networks — IPv6 over Low-Power Wireless Personal Area Networks. Zigbee or IEEE 802.15.4 radio links carry IPv6 packets compressed using 6LoWPAN, and CoAP runs directly over this stack. An entire smart building sensor network can operate without any gateway running a broker, with each room controller directly querying or observing sensor nodes via CoAP URIs.

Given:
CoAP CON message, ACK_TIMEOUT = 2s, random_factor = 1.0
MAX_RETRANSMIT = 4

Why this formula applies:
Exponential backoff controls retransmission intervals to avoid network congestion.

Formula:
timeout_n = ACK_TIMEOUT x 2^n

Calculation:
n=0: 2 x 2^0 = 2 s
n=1: 2 x 2^1 = 4 s
n=2: 2 x 2^2 = 8 s
n=3: 2 x 2^3 = 16 s

Total time before message failure:
2 + 4 + 8 + 16 = 30 s

Final Answer: A CON message is retransmitted 4 times over 30 seconds before being declared undelivered.

Exam Tip: CoAP uses UDP (not TCP), has a 4-byte fixed header, and runs on port 5683. It supports GET, POST, PUT, DELETE like HTTP. The Observe extension adds event-driven notifications. These distinctions frequently appear in GATE and university exam MCQs.

CoAP Message Types and Response Codes

• CON (Confirmable): reliable delivery with ACK required and exponential back-off retransmission.
• NON (Non-Confirmable): unreliable, no ACK, minimal overhead for periodic data.
• ACK: acknowledgment of a CON message. May carry a response (piggyback) or be empty.
• RST: reset, sent when a message is received that cannot be processed.
• Response codes follow the pattern class.detail (e.g., 2.05 = Content, 4.04 = Not Found).

Quick Revision

• CoAP is a REST-like protocol over UDP, designed for constrained IoT devices (RFC 7252).
• Uses HTTP-like methods: GET, POST, PUT, DELETE on URI-identified resources.
• Fixed header: 4 bytes. UDP port: 5683. Far lighter than HTTP.
• CON messages require ACK with exponential back-off; NON is fire-and-forget.
• Observe extension (RFC 7641) adds event-driven server push to CoAP.
• Works natively in 6LoWPAN / Zigbee networks without needing a message broker.
• Trap: CoAP is peer-to-peer (no broker). MQTT needs a central broker. Both are valid for IoT but serve different topologies.