1224  CoAP Message Types and Exchange Patterns

1224.1 CoAP Message Types

Four message types provide flexibility for different scenarios:

1224.1.1 Confirmable (CON)

Reliable transmission - requires acknowledgment:

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#7F8C8D', 'tertiaryColor': '#ECF0F1', 'fontSize': '13px'}}}%%
sequenceDiagram
    participant C as Client
    participant S as Server

    C->>S: CON GET /temp<br/>Message ID: 0x1234
    S->>C: ACK 2.05 Content<br/>Message ID: 0x1234<br/>Payload: 22.5°C

    Note over C,S: Reliable delivery guaranteed
    Note over C: If no ACK, retransmit

Figure 1224.1: CoAP Confirmable Message Exchange with Acknowledgment

Use when: - Critical data must arrive - Commands that trigger actions - Resource updates (PUT, POST, DELETE)

1224.1.2 Non-Confirmable (NON)

Unreliable transmission - no acknowledgment:

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#7F8C8D', 'tertiaryColor': '#ECF0F1', 'fontSize': '13px'}}}%%
sequenceDiagram
    participant C as Client
    participant S as Server

    C->>S: NON GET /temp<br/>Message ID: 0x5678
    S->>C: NON 2.05 Content<br/>Message ID: 0x9ABC<br/>Payload: 22.5°C

    Note over C,S: Fire-and-forget
    Note over C: No retransmission

Figure 1224.2: CoAP Non-Confirmable Fire-and-Forget Message Exchange

Use when: - Frequent sensor readings - Data loss acceptable - Minimizing network traffic - Battery conservation critical

{
  const container = document.getElementById('kc-coap-3');
  if (container && typeof InlineKnowledgeCheck !== 'undefined') {
    container.innerHTML = '';
    container.appendChild(InlineKnowledgeCheck.create({
      question: "A home security company deploys window sensors that send 'OPEN' or 'CLOSED' events. Each sensor runs on a CR2032 coin cell battery. The product manager wants both 3-year battery life AND guaranteed delivery of every door/window event. Which message type configuration best balances these requirements?",
      options: [
        {text: "Use NON for all messages to maximize battery life - occasional missed events are acceptable for security systems", correct: false, feedback: "Incorrect. For security systems, missed events are NOT acceptable. If a window opens and the event is lost, the homeowner won't be alerted to a potential break-in. NON messages provide no delivery guarantee."},
        {text: "Use CON for all messages to ensure every event is delivered - battery life is less important than security", correct: false, feedback: "Partially correct thinking, but not optimal. While CON guarantees delivery, using it for every message (including periodic 'still CLOSED' heartbeats) wastes battery. Smart design uses CON only for critical state changes."},
        {text: "Use CON for state changes (OPEN/CLOSED events) and NON for periodic heartbeats - this balances reliability and battery life", correct: true, feedback: "Correct! This hybrid approach uses CON messages for critical security events (guaranteeing delivery) while using NON for routine heartbeats (saving battery). State changes are rare (few times/day) while heartbeats are frequent (every 15 minutes). This achieves 3-year battery life while ensuring all security events are reliably delivered."},
        {text: "Use NON with application-level retries at the server - this provides reliability without CoAP overhead", correct: false, feedback: "Incorrect. If the sensor sends a NON message that's lost, how would the server know to request a retry? The server can't acknowledge what it never received. CON messages with their built-in ACK mechanism are the correct solution for reliable delivery."}
      ],
      difficulty: "medium",
      topic: "coap-message-types"
    }));
  }
}

TipCON vs NON: The Battery Life Trade-off

Choosing between Confirmable (CON) and Non-Confirmable (NON) messages dramatically impacts battery life:

CON (Confirmable): - Waits for ACK response (50-200ms typical) - Retransmits if no ACK (exponential backoff) - Radio stays on longer → drains battery - Use for: Critical commands, infrequent updates

NON (Non-Confirmable): - Fire-and-forget, no waiting - Radio on for <10ms - 5-10x better battery life than CON - Use for: Frequent sensor readings where occasional loss is acceptable

Example: Temperature sensor sending readings every 60 seconds - battery lasts 2 years with NON vs 3 months with CON. For battery-powered devices, default to NON and use CON only when absolutely necessary.

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#7F8C8D', 'fontSize': '12px'}}}%%
flowchart LR
    subgraph CON["Confirmable (CON)"]
        direction TB
        C1["Send Request"] --> C2{"ACK<br/>Received?"}
        C2 -->|"Yes"| C3["Success ✓"]
        C2 -->|"No (timeout)"| C4["Retransmit<br/>(2s, 4s, 8s...)"]
        C4 --> C2
        C4 -->|"Max retries"| C5["Fail ✗"]

        CM["Radio: ON 50-200ms<br/>Battery: 3 months<br/>Reliability: 99.9%"]
    end

    subgraph NON["Non-Confirmable (NON)"]
        direction TB
        N1["Send Request"] --> N2["Done<br/>(no waiting)"]

        NM["Radio: ON <10ms<br/>Battery: 2 years<br/>Reliability: 85-99%"]
    end

    subgraph Decision["When to Use"]
        D1["CON: Commands,<br/>config updates,<br/>critical alerts"]
        D2["NON: Periodic telemetry,<br/>frequent readings,<br/>battery devices"]
    end

    style C1 fill:#E67E22,stroke:#2C3E50,stroke-width:2px,color:#fff
    style C2 fill:#2C3E50,stroke:#16A085,stroke-width:2px,color:#fff
    style C3 fill:#16A085,stroke:#2C3E50,stroke-width:2px,color:#fff
    style C4 fill:#E67E22,stroke:#2C3E50,stroke-width:2px,color:#fff
    style C5 fill:#E74C3C,stroke:#2C3E50,stroke-width:2px,color:#fff
    style N1 fill:#16A085,stroke:#2C3E50,stroke-width:2px,color:#fff
    style N2 fill:#16A085,stroke:#2C3E50,stroke-width:2px,color:#fff
    style CM fill:#7F8C8D,stroke:#2C3E50,stroke-width:1px,color:#fff
    style NM fill:#7F8C8D,stroke:#2C3E50,stroke-width:1px,color:#fff
    style D1 fill:#E67E22,stroke:#2C3E50,stroke-width:1px,color:#fff
    style D2 fill:#16A085,stroke:#2C3E50,stroke-width:1px,color:#fff

Figure 1224.3: Alternative view: CoAP message type comparison showing the flow and resource usage differences between Confirmable (CON) and Non-Confirmable (NON) messages. CON provides reliability through retransmission but consumes 5-10x more battery, while NON offers fire-and-forget efficiency suitable for frequent sensor readings.

1224.1.3 Acknowledgment (ACK)

Confirms receipt of confirmable message:

• May include response (piggyback)
• Or just acknowledgment (response comes separately)

1224.1.4 Reset (RST)

Rejects invalid message: - Unknown message ID - Message cannot be processed - Server unavailable

1224.2 Message Exchange Patterns

1224.3 Videos

NoteApplication Protocols Overview (from slides)

Application Protocols Overview

From Lesson 4 — placing CoAP among MQTT/HTTP/AMQP; REST patterns and trade-offs.

NoteProtocols and REST in Practice

Protocols and REST in Practice

From Lesson 4 — practical layering and REST interactions relevant to CoAP.

1224.3.1 Piggyback Response

Server responds immediately within ACK:

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#7F8C8D', 'tertiaryColor': '#ECF0F1', 'fontSize': '13px'}}}%%
sequenceDiagram
    participant C as Client
    participant S as Server

    C->>S: CON GET /temp<br/>MID: 0x1234
    Note over S: Process immediately<br/>(< 2 seconds)
    S->>C: ACK 2.05 Content<br/>MID: 0x1234<br/>Payload: 22.5°C

    Note over C,S: Single round-trip

Figure 1224.4: CoAP Piggyback Response: Response Included in ACK Message

Advantage: Single round-trip, efficient

1224.3.2 Separate Response

Server needs time to process:

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#7F8C8D', 'tertiaryColor': '#ECF0F1', 'fontSize': '13px'}}}%%
sequenceDiagram
    participant C as Client
    participant S as Server

    C->>S: CON GET /data<br/>MID: 0x1234
    S->>C: ACK (empty)<br/>MID: 0x1234
    Note over S: Processing...<br/>(5 seconds)
    S->>C: CON 2.05 Content<br/>MID: 0x5678<br/>Payload: data
    C->>S: ACK<br/>MID: 0x5678

    Note over C,S: Two round-trips

Figure 1224.5: CoAP Separate Response: Empty ACK Followed by Delayed Response

Use when: Long processing time required

{
  const container = document.getElementById('kc-coap-4');
  if (container && typeof InlineKnowledgeCheck !== 'undefined') {
    container.innerHTML = '';
    container.appendChild(InlineKnowledgeCheck.create({
      question: "An industrial IoT gateway sends a CoAP CON request to a sensor asking for a complex diagnostic report. The sensor needs 8 seconds to collect data from multiple subsystems. What is the correct response pattern to avoid timeout issues?",
      options: [
        {text: "Send the full response after 8 seconds - CoAP will wait indefinitely for responses to CON messages", correct: false, feedback: "Incorrect. CoAP clients have default timeouts of 2-3 seconds for ACK responses. If no ACK arrives, the client will retransmit the request (exponential backoff: 2s, 4s, 8s...). This could result in duplicate requests overwhelming the sensor."},
        {text: "Send an empty ACK immediately, then send the diagnostic data as a separate CON response when ready", correct: true, feedback: "Correct! This is the 'separate response' pattern. The immediate empty ACK stops the client's retransmission timer. The server then takes as long as needed (8 seconds) to prepare the data, sending it as a new CON message with the original request's token. The client matches responses to requests using the token, not the message ID."},
        {text: "Increase the client's ACK_TIMEOUT to 10 seconds before sending the request", correct: false, feedback: "Partially correct but problematic. While this would prevent retransmissions for this specific request, changing protocol defaults is bad practice. It would also increase timeout for ALL requests, making the system less responsive when sensors are truly offline."},
        {text: "Split the 8-second operation into multiple smaller requests, each completing within the default timeout", correct: false, feedback: "Incorrect. While splitting requests might work, it adds complexity and doesn't address the fundamental problem. The separate response pattern is specifically designed for long-running operations and is the standard CoAP solution."}
      ],
      difficulty: "medium",
      topic: "coap-separate-response"
    }));
  }
}

Knowledge Check: CoAP Message Types & Patterns Test Your Understanding

1224.4 Knowledge Check

Test your understanding of CoAP message types and communication patterns.

Question 1: A battery-powered temperature sensor sends readings every minute to a server. Which message type should it use?

Explanation: Non-Confirmable (NON) messages are better for this use case. Reasons: 1) Battery conservation - NON requires no acknowledgment, saving power from radio transmission, 2) Frequent data - readings arrive every minute, so occasional loss is acceptable, 3) Reduced network overhead - no ACK messages, 4) Lower latency - no waiting for acknowledgments. Use CON only for critical data like alarms or configuration updates. Rule of thumb: NON for frequent redundant data, CON for important one-time events.

Question 2: What is the difference between a piggyback response and a separate response in CoAP?

Explanation: Piggyback response: Server responds immediately by including the response payload in the ACK message (1 round-trip). Example: CON GET /temp → ACK 2.05 Content "22.5°C". Separate response: Server acknowledges first (empty ACK), processes request, then sends response later as a new CON message requiring its own ACK (2 round-trips). Example: Database query taking 5 seconds. Use piggyback for fast responses (<2-3 seconds), separate for long processing to avoid ACK timeouts.

Question 3: A CoAP client sends a CON message with Message ID 0x1234, but receives an ACK with Message ID 0x5678. What should the client do?

Explanation: No, this is invalid - it indicates an error or a separate response pattern. In CoAP: ACK messages MUST have the same Message ID as the CON message they’re acknowledging. If IDs don’t match, it could be: 1) A separate response (server already sent ACK with 0x1234, now sending separate CON response with new ID 0x5678), or 2) A protocol error/bug. The client should reject mismatched IDs with an RST (Reset) message unless it’s expecting a separate response.

Question 4: When should a CoAP client send a Reset (RST) message?

Explanation: RST messages reject invalid or unexpected messages: 1) Unknown Message ID - received ACK for a CON you never sent, 2) Duplicate message - received the same confirmed message twice (duplicate detection failed), 3) Server unavailable - can’t process the request, 4) Protocol error - malformed message. Example: Client receives ACK MID:0x9999 but never sent CON MID:0x9999 → sends RST to inform server. RST tells the sender “stop, something’s wrong” and prevents retransmissions.

1224.5 What’s Next

Now that you understand CoAP message types and exchange patterns, the next chapter explores CoAP Methods and Features where you’ll learn about:

• RESTful methods (GET, POST, PUT, DELETE)
• Multicast support for group communication
• Resource discovery with .well-known/core
• Protocol comparisons (CoAP vs HTTP vs MQTT)