5  CoAP Message Exchanges

In 60 Seconds

CoAP defines four message types: Confirmable (CON) requires acknowledgment for reliable delivery of critical commands, Non-Confirmable (NON) provides fire-and-forget efficiency for frequent sensor readings, Acknowledgment (ACK) confirms CON receipt and can piggyback the response payload, and Reset (RST) indicates the receiver cannot process the message. The CON vs NON choice directly trades reliability for energy – CON costs up to 16x the energy of NON (due to ACK wait and RX radio time) but achieves 99.99% delivery.

5.1 Start With the Delivery Choice

Picture one device sending two updates: a freezer-door alarm and a routine temperature sample. The alarm needs proof that someone received it; the sample may be replaced by the next reading in a few seconds. CoAP gives those two messages different envelopes instead of forcing one rule onto both.

Read CON, NON, ACK, and RST as delivery decisions. The rest of the chapter explains what each decision costs in delay, radio time, battery, and failure handling.

Phoebe’s Field Notes: The Microamps Behind This Chapter’s “~8 Years”

Phoebe’s Why

A milliamp-hour is a charge unit – the integral of current over time, \(Q=\int I\,dt\) – not an energy budget. Multiply by the cell’s terminal voltage and charge becomes energy, \(E \approx V\,Q\), but only while that voltage stays flat under load. The chapter’s own NON and CON figures (0.017 mAs and 0.272 mAs per message) are charge, computed the right way: current times time. The 16x ratio survives the jump to real energy only because a lithium primary cell barely sags at a few milliamps. Push the same charge math out to a chapter-length battery-life claim, though, and a second, silent current shows up: whatever the radio and MCU draw while doing nothing at all. That background current, not the transmit charge, is what actually decides whether “~8 years” is eight years.

The Derivation

Charge delivered by the cell:

\[Q = \int I \, dt\]

Energy, while terminal voltage stays roughly constant:

\[E \approx V \, Q\]

Terminal voltage sags under load by the internal-resistance drop:

\[V_{\text{load}} = V_{oc} - I \, R_{int}\]

A deployed sensor’s average current has an active part and an always-on part:

\[I_{avg} = I_{active} + I_{sleep}\]

Battery life follows from the whole average current, not the transmit current alone:

\[T = \frac{C_{batt}}{I_{avg}}\]

Worked Numbers: This Chapter’s Cold-Chain Sensor

• Charge to energy, at \(V=3.0\) V: NON \(= 0.0136\text{ mAh}\times3.0\text{ V} = 0.0408\) mWh/day; CON \(= 0.218\times3.0 = 0.653\) mWh/day – still a 16.0x ratio, because \(V\) is common to both.
• Voltage-sag check (catalog-typical \(R_{int}\approx0.5\,\Omega\) for a fresh CR123A): at the 8 mA TX pulse, sag \(=8\text{ mA}\times0.5\,\Omega=4.00\) mV, only 0.133% of 3.0 V; at the 5 mA ACK-wait pulse, sag \(=2.50\) mV. Both negligible – the chapter’s flat-voltage mAh arithmetic is valid at these currents.
• Where “~8 years” really comes from: active-only NON life is \(1000\text{ mAh}/0.0136\text{ mAh/day}=73{,}500\) days \(\approx 201\) years, yet the chapter states a practical life of ~8 years (2920 days). That implies an average draw of \(1000/2920=0.342\) mAh/day \(\approx 14.3\,\mu\)A, of which active TX/RX is only 0.0136 mAh/day (4.0%) – leaving \(\approx13.7\,\mu\)A of continuous sleep current unaccounted for by the transmit math.
• Cross-check against the CON row: active-only CON life is \(1000/0.218=4590\) days \(\approx 12.6\) years, but the chapter states ~5 years (1825 days), implying \(1000/1825=0.548\) mAh/day, of which active CON is 0.218 (39.8%) – leaving \(\approx13.8\,\mu\)A of background draw. That matches the NON-implied \(13.7\,\mu\)A to within 1%, confirming both “practical” rows share the same hidden sleep current.
• Why the window sensor needs the hybrid strategy: the intro’s CR2032 (catalog-typical 225 mAh \(\times\) 3.0 V \(= 0.675\) Wh) holds \(1000\times3.0/0.675=4.44\times\) less energy than this section’s CR123A (3.00 Wh) – the same 16x CON/NON ratio applies to both cells equally, but the smaller coin cell has far less margin to absorb it, which is exactly why that scenario needs CON reserved for rare state changes.

5.2 Learning Objectives

By the end of this chapter, you will be able to:

• Distinguish the four CoAP message types (CON, NON, ACK, RST) and their roles in the protocol
• Select the appropriate message type based on reliability requirements and battery constraints
• Explain piggyback vs separate response patterns and when each is used
• Calculate the energy trade-off between CON and NON messages for battery-powered devices

Chapter Roadmap

Use this path through the protocol:

1. First choose CON or NON by asking whether the next reading can replace this one.
2. Then price that choice with 20-byte readings, 52-byte packets, 50 ms ACK waits, and the 16x energy ratio.
3. Next separate ACK/RST protocol signals from application errors.
4. Finally compare piggyback, separate response, retransmission, and quiz scenarios.

Checkpoints recap the decision rules. Calculation audits and simulators are deeper support, optional on a first pass.

Key Concepts

• CoAP: Constrained Application Protocol — REST-style request/response protocol using UDP instead of TCP
• Confirmable Message (CON): Requires ACK from recipient — provides reliable delivery over UDP at the cost of one roundtrip
• Non-confirmable Message (NON): Fire-and-forget UDP datagram — lowest latency, no delivery guarantee
• Observe Option: CoAP extension enabling publish/subscribe: client registers to receive notifications on resource changes
• Block-wise Transfer: Fragmentation mechanism for transferring payloads larger than a single CoAP datagram
• Token: Client-generated value matching responses to requests — enables concurrent request/response pairing
• DTLS: Datagram TLS — CoAP’s security layer providing encryption and authentication over UDP

5.3 For Beginners: CoAP Message Types

CoAP uses four message types: Confirmable (requires acknowledgment), Non-confirmable (fire-and-forget), Acknowledgment (confirmation receipt), and Reset (error signal). Think of it like different ways to send a message – sometimes you need a read receipt, sometimes you just want to shout the news without waiting for a reply.

Sensor Squad: Four Ways to Send a Message

“I have four different ways to send my readings?” asked Sammy the Sensor, confused.

“Think of it like four types of mail!” said Max the Microcontroller. “Confirmable (CON) is like certified mail – you send it and wait for a signed receipt. If you don’t get one, you send it again. Perfect for important alerts like ‘the freezer door is open!’”

Lila the LED continued: “Non-confirmable (NON) is like dropping a flyer in someone’s mailbox – you don’t wait to see if they read it. Great for routine updates like ‘living room light is still on.’ If one update gets lost, another is coming in 10 seconds anyway.”

“Then there’s the Acknowledgment (ACK),” said Bella the Battery. “That’s the signed receipt itself – you’re saying ‘yep, I got your message!’ And Reset (RST) is like returning a letter stamped ‘wrong address’ – it means ‘I don’t understand what you’re asking for.’ Four simple types cover every situation, and they keep the protocol tiny!”

5.4 Continue: CoAP Message Reliability and Exchange Contracts

The main chapter below stays focused on CoAP message types, energy tradeoffs, and exchange patterns. For the deeper contract behind CON/NON/ACK/RST layering, named timers, ACK timeout/backoff, Message ID versus Token roles, piggybacked versus separate responses, duplicate suppression, and reset handling, continue to CoAP Message Reliability and Exchange Contracts.

5.5 CoAP Message Types

Four message types provide flexibility for different scenarios:

The first decision is consequence: if loss changes system state, start with CON; if the next sample replaces this one, start with NON.

5.5.1 Confirmable (CON)

Reliable transmission - requires acknowledgment:

Figure 5.1: CoAP Confirmable Message Exchange with Acknowledgment

Use when:

• Critical data must arrive
• Commands that trigger actions
• Resource updates (PUT, POST, DELETE)

5.5.2 Non-Confirmable (NON)

Unreliable transmission - no acknowledgment:

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

Use when:

• Frequent sensor readings
• Data loss acceptable
• Minimizing network traffic
• Battery conservation critical

CON 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.

Figure 5.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.

Checkpoint: CON or NON

• CON fits critical data, action-triggering commands, and resource updates such as PUT, POST, and DELETE.
• NON fits frequent sensor readings where loss is acceptable and battery conservation is critical.
• A 60-second temperature sensor example estimates 2 years with NON versus 3 months with CON.

5.5.3 Worked Example: CON vs NON Energy Budget for Cold Chain Monitoring

Scenario: A pharmaceutical warehouse uses 200 CoAP sensors monitoring freezer temperatures. Each sensor sends a 20-byte reading every 30 seconds. Sensors use 802.15.4 radios (250 Kbps) with 8 mA TX, 5 mA RX current at 3.0V. Battery: 1,000 mAh CR123A.

NON message energy per transmission:

• TX: 20-byte payload + 4-byte CoAP header + 8-byte UDP + 20-byte IPv6 = 52 bytes
• TX time: 52 x 8 / 250,000 = 1.66 ms at 8 mA = 0.013 mAs
• Radio startup: ~0.5 ms at 8 mA = 0.004 mAs
• Total per NON: 0.017 mAs

Putting Numbers to It: Energy Cost Formula for CON vs NON

The total energy per transmission depends on time-on-air and current draw:

\[ E_{\text{total}} = E_{\text{TX}} + E_{\text{RX}} + E_{\text{startup}} \]

For NON messages (no ACK wait): \[ E_{\text{NON}} = I_{\text{TX}} \cdot t_{\text{TX}} + I_{\text{startup}} \cdot t_{\text{startup}} \]

For CON messages (with ACK wait): \[ E_{\text{CON}} = E_{\text{NON}} + I_{\text{RX}} \cdot t_{\text{ACK\_wait}} + I_{\text{RX}} \cdot t_{\text{ACK\_RX}} \]

Where \(I_{\text{TX}} = 8\text{ mA}\), \(I_{\text{RX}} = 5\text{ mA}\) at \(V = 3.0\text{ V}\) for 802.15.4.

The energy ratio: \[ \frac{E_{\text{CON}}}{E_{\text{NON}}} = \frac{0.272}{0.017} \approx 16\times \]

This 16× multiplier directly translates to battery life reduction when switching from NON to CON for frequent sensor readings.

5.6 Ada’s Calculation Audit: ACK Wait Energy

Ada: Keep the time and current units visible. CON costs more than NON here because the sender must keep its receiver awake while it waits for the ACK, not because the payload bytes changed.

Check	Arithmetic	Result
CoAP datagram size	20-byte payload + 4-byte CoAP header + 8-byte UDP + 20-byte IPv6	52 bytes
TX time	52 bytes x 8 bits / 250,000 bits/s	0.001664 s = 1.66 ms
NON transmit energy	8 mA x 1.66 ms / 1000 + 8 mA x 0.5 ms / 1000	0.013 mAs + 0.004 mAs = 0.017 mAs
ACK wait energy	5 mA x 50 ms / 1000	0.250 mAs
ACK receive energy	32 bytes x 8 bits / 250,000 bits/s = 1.024 ms; 5 mA x 1.024 ms / 1000	0.005 mAs
CON total	0.017 + 0.250 + 0.005	0.272 mAs
CON/NON ratio	0.272 / 0.017	16.0x

Round only after the ledger is complete: the 16x statement comes from the full CON total divided by the NON total, not from rounding the ACK receive term first.

CON message energy per transmission:

• TX same as NON: 0.017 mAs
• Wait for ACK: radio in RX mode ~50 ms at 5 mA = 0.25 mAs (typical RTT on local network)
• ACK reception: 4-byte header + 8 UDP + 20 IPv6 = 32 bytes at 5 mA = 0.005 mAs
• Total per CON: 0.272 mAs (16x more than NON)

Battery lifetime comparison:

Metric	NON	CON
Energy per message	0.017 mAs	0.272 mAs
Messages per day	2,880	2,880
Daily consumption	49 mAs = 0.0136 mAh	784 mAs = 0.218 mAh
Battery lifetime	1,000 / 0.0136 = 73,529 days	1,000 / 0.218 = 4,587 days
Practical lifetime (with sleep current)	~8 years	~5 years

But what about reliability? With 5% packet loss on 802.15.4:

• NON: 5% of readings lost = 144 per day (but next reading arrives in 30 seconds)
• CON: 0.0025% loss after retransmission (5% x 5% = 0.25% after one retry)

Decision: Use NON for routine 30-second temperature readings (any loss is replaced in 30 seconds). Use CON only for threshold alerts (“Temperature exceeded -18C”) which happen rarely (~2 per day). This hybrid approach achieves ~8-year battery life while guaranteeing critical alerts are delivered.

Checkpoint: Energy Budget

• The cold-chain packet is 52 bytes: 20 payload + 4 CoAP + 8 UDP + 20 IPv6.
• At 250 Kbps, it takes 1.66 ms to transmit; with startup, NON costs 0.017 mAs.
• CON adds the 50 ms ACK wait and 32-byte ACK receive, reaching 0.272 mAs, about 16x NON.

5.7 Interactive: CoAP Message Energy Calculator

Explore how message type, transmission frequency, and network parameters affect battery life:

viewof payloadSize = Inputs.range([1, 1024], {
  value: 20,
  step: 1,
  label: "Payload size (bytes)"
})

viewof transmitInterval = Inputs.range([1, 300], {
  value: 30,
  step: 1,
  label: "Transmit interval (seconds)"
})

viewof messageType = Inputs.select(["NON", "CON", "Hybrid"], {
  value: "NON",
  label: "Message type"
})

viewof batteryCapacity = Inputs.range([100, 5000], {
  value: 1000,
  step: 100,
  label: "Battery capacity (mAh)"
})

viewof ackWaitTime = Inputs.range([10, 200], {
  value: 50,
  step: 10,
  label: "ACK wait time (ms)"
})

// Radio parameters (802.15.4 typical)
radioParams = ({
  txCurrent: 8,      // mA
  rxCurrent: 5,      // mA
  startupTime: 0.5,  // ms
  dataRate: 250000,  // bps
  voltage: 3.0       // V
})

// Calculate packet size (CoAP + UDP + IPv6 headers)
totalPacketSize = payloadSize + 4 + 8 + 20

// Calculate TX time in milliseconds
txTime = (totalPacketSize * 8) / radioParams.dataRate * 1000

// ACK reception is a 32-byte header-only response in this example
ackRxTime = (32 * 8) / radioParams.dataRate * 1000

// Energy calculations
energyNON = (
  radioParams.txCurrent * txTime +
  radioParams.txCurrent * radioParams.startupTime
) / 1000  // Convert to mAs

energyCON = (
  energyNON +
  radioParams.rxCurrent * ackWaitTime / 1000 +
  radioParams.rxCurrent * ackRxTime / 1000
)

// Messages per day
messagesPerDay = (24 * 3600) / transmitInterval

// Daily energy consumption
dailyEnergyNON = (energyNON * messagesPerDay) / 3600  // Convert mAs to mAh
dailyEnergyCON = (energyCON * messagesPerDay) / 3600

// Hybrid: 95% NON, 5% CON (typical for sensor with occasional alerts)
dailyEnergyHybrid = (0.95 * dailyEnergyNON) + (0.05 * dailyEnergyCON)

// Battery lifetime in days
lifetimeNON = batteryCapacity / dailyEnergyNON
lifetimeCON = batteryCapacity / dailyEnergyCON
lifetimeHybrid = batteryCapacity / dailyEnergyHybrid

// Determine which value to show based on message type
selectedDailyEnergy = messageType === "NON" ? dailyEnergyNON :
                      messageType === "CON" ? dailyEnergyCON :
                      dailyEnergyHybrid

selectedLifetime = messageType === "NON" ? lifetimeNON :
                   messageType === "CON" ? lifetimeCON :
                   lifetimeHybrid

html`<div style="font-family: Arial, sans-serif; max-width: 800px; margin: 20px 0;">
  <div style="background: linear-gradient(135deg, #2C3E50 0%, #3498DB 100%); color: white; padding: 20px; border-radius: 8px; margin-bottom: 20px;">
    <h3 style="margin: 0 0 10px 0; color: white;">CoAP Message Energy Analysis</h3>
    <div style="display: grid; grid-template-columns: repeat(2, 1fr); gap: 15px; margin-top: 15px;">
      <div style="background: rgba(255,255,255,0.1); padding: 15px; border-radius: 6px;">
        <div style="font-size: 12px; opacity: 0.9; margin-bottom: 5px;">Total Packet Size</div>
        <div style="font-size: 24px; font-weight: bold;">${totalPacketSize} bytes</div>
        <div style="font-size: 11px; opacity: 0.8; margin-top: 5px;">
          ${payloadSize} payload + 32 headers
        </div>
      </div>
      <div style="background: rgba(255,255,255,0.1); padding: 15px; border-radius: 6px;">
        <div style="font-size: 12px; opacity: 0.9; margin-bottom: 5px;">TX Time</div>
        <div style="font-size: 24px; font-weight: bold;">${txTime.toFixed(2)} ms</div>
        <div style="font-size: 11px; opacity: 0.8; margin-top: 5px;">
          at 250 Kbps data rate
        </div>
      </div>
      <div style="background: rgba(255,255,255,0.1); padding: 15px; border-radius: 6px;">
        <div style="font-size: 12px; opacity: 0.9; margin-bottom: 5px;">Messages/Day</div>
        <div style="font-size: 24px; font-weight: bold;">${messagesPerDay.toLocaleString()}</div>
        <div style="font-size: 11px; opacity: 0.8; margin-top: 5px;">
          every ${transmitInterval}s
        </div>
      </div>
      <div style="background: rgba(255,255,255,0.1); padding: 15px; border-radius: 6px;">
        <div style="font-size: 12px; opacity: 0.9; margin-bottom: 5px;">Daily Energy (${messageType})</div>
        <div style="font-size: 24px; font-weight: bold;">${selectedDailyEnergy.toFixed(3)} mAh</div>
        <div style="font-size: 11px; opacity: 0.8; margin-top: 5px;">
          ${(selectedDailyEnergy * 1000 / batteryCapacity).toFixed(2)}% of battery
        </div>
      </div>
    </div>
  </div>

  <div style="background: #f8f9fa; padding: 20px; border-radius: 8px; border-left: 4px solid #16A085;">
    <h4 style="margin: 0 0 15px 0; color: #2C3E50;">Battery Lifetime Estimate</h4>
    <div style="font-size: 36px; font-weight: bold; color: #16A085; margin-bottom: 10px;">
      ${selectedLifetime > 365 ?
        (selectedLifetime / 365).toFixed(1) + ' years' :
        Math.floor(selectedLifetime) + ' days'}
    </div>
    <div style="font-size: 14px; color: #7F8C8D; margin-bottom: 15px;">
      with ${batteryCapacity} mAh battery capacity
    </div>

    <div style="background: white; padding: 15px; border-radius: 6px; margin-top: 15px;">
      <div style="font-size: 13px; font-weight: 600; color: #2C3E50; margin-bottom: 10px;">Energy Comparison</div>
      <div style="display: grid; grid-template-columns: repeat(3, 1fr); gap: 10px; text-align: center;">
        <div>
          <div style="font-size: 11px; color: #7F8C8D; margin-bottom: 5px;">NON</div>
          <div style="font-size: 18px; font-weight: bold; color: #16A085;">
            ${(lifetimeNON / 365).toFixed(1)}y
          </div>
          <div style="font-size: 10px; color: #7F8C8D;">${dailyEnergyNON.toFixed(3)} mAh/day</div>
        </div>
        <div>
          <div style="font-size: 11px; color: #7F8C8D; margin-bottom: 5px;">CON</div>
          <div style="font-size: 18px; font-weight: bold; color: #E67E22;">
            ${(lifetimeCON / 365).toFixed(1)}y
          </div>
          <div style="font-size: 10px; color: #7F8C8D;">${dailyEnergyCON.toFixed(3)} mAh/day</div>
        </div>
        <div>
          <div style="font-size: 11px; color: #7F8C8D; margin-bottom: 5px;">Hybrid</div>
          <div style="font-size: 18px; font-weight: bold; color: #3498DB;">
            ${(lifetimeHybrid / 365).toFixed(1)}y
          </div>
          <div style="font-size: 10px; color: #7F8C8D;">${dailyEnergyHybrid.toFixed(3)} mAh/day</div>
        </div>
      </div>
    </div>

    <div style="margin-top: 15px; padding: 12px; background: #E8F5E9; border-radius: 6px; font-size: 13px; color: #2C3E50;">
      <strong>Tip:</strong> ${
        messageType === "NON" ?
          "NON messages maximize battery life but provide no delivery guarantee. Use for frequent sensor readings where occasional loss is acceptable." :
        messageType === "CON" ?
          "CON messages guarantee delivery but consume 16x more energy. Use sparingly for critical alerts only." :
          "Hybrid mode (95% NON, 5% CON) balances reliability and efficiency - use NON for routine readings and CON for important state changes."
      }
    </div>
  </div>
</div>`

5.7.1 Acknowledgment (ACK)

ACKs cost power, but their meaning is narrow: they confirm CON receipt. Application success still depends on the response code they carry.

Confirms receipt of confirmable message:

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

5.7.2 Reset (RST)

Rejects invalid message:

• Unknown message ID
• Message cannot be processed
• Server unavailable

Checkpoint: ACK and RST Semantics

• ACK confirms a valid CON and can piggyback a normal response such as 4.04 Not Found.
• RST rejects invalid, unexpected, or unprocessable protocol messages; it is not for ordinary missing resources.
• Ignoring CON causes client retries up to MAX_RETRANSMIT.

5.8 Message Exchange Patterns

After ACK and RST, choose response timing. Fast work can ride inside ACK; slow work needs an empty ACK first.

5.8.1 Piggyback Response

Server responds immediately within ACK:

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

Advantage: Single round-trip, efficient

5.8.2 Separate Response

Server needs time to process:

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

Use when: Long processing time required

5.9 Interactive: CoAP Retransmission Timeline

Visualize how CoAP’s exponential backoff algorithm affects retransmission timing and battery life:

viewof ackTimeout = Inputs.range([1, 10], {
  value: 2,
  step: 0.5,
  label: "ACK_TIMEOUT (seconds)"
})

viewof maxRetransmit = Inputs.range([1, 8], {
  value: 4,
  step: 1,
  label: "MAX_RETRANSMIT (attempts)"
})

viewof randomFactor = Inputs.range([1.0, 2.0], {
  value: 1.5,
  step: 0.1,
  label: "ACK random factor",
  width: 260
})

// Calculate retransmission schedule
retransmissionSchedule = {
  const schedule = [];
  let cumulativeTime = 0;
  let timeout = ackTimeout;

  // Initial transmission
  schedule.push({
    attempt: 0,
    timeout: 0,
    cumulativeTime: 0,
    label: "Initial TX"
  });

  // Retransmissions
  for (let i = 1; i <= maxRetransmit; i++) {
    // Add jitter to timeout
    const jitter = timeout * (1 + (randomFactor - 1) * Math.random());
    cumulativeTime += jitter;

    schedule.push({
      attempt: i,
      timeout: jitter,
      cumulativeTime: cumulativeTime,
      label: `Retry ${i}`
    });

    // Double timeout for next attempt (exponential backoff)
    timeout *= 2;
  }

  return schedule;
}

// Calculate total time and energy cost
maxTransmitSpan = retransmissionSchedule[retransmissionSchedule.length - 1].cumulativeTime

energyCostPerAttempt = 0.272  // mAs from earlier calculation
totalEnergyCost = energyCostPerAttempt * (maxRetransmit + 1)

html`<div style="font-family: Arial, sans-serif; max-width: 800px; margin: 20px 0;">
  <div style="background: linear-gradient(135deg, #E67E22 0%, #E74C3C 100%); color: white; padding: 20px; border-radius: 8px; margin-bottom: 20px;">
    <h3 style="margin: 0 0 10px 0; color: white;">CoAP Retransmission Timeline</h3>
    <div style="display: grid; grid-template-columns: repeat(3, 1fr); gap: 15px; margin-top: 15px;">
      <div style="background: rgba(255,255,255,0.1); padding: 15px; border-radius: 6px;">
        <div style="font-size: 12px; opacity: 0.9; margin-bottom: 5px;">Total Attempts</div>
        <div style="font-size: 24px; font-weight: bold;">${maxRetransmit + 1}</div>
        <div style="font-size: 11px; opacity: 0.8; margin-top: 5px;">
          1 initial + ${maxRetransmit} retries
        </div>
      </div>
      <div style="background: rgba(255,255,255,0.1); padding: 15px; border-radius: 6px;">
        <div style="font-size: 12px; opacity: 0.9; margin-bottom: 5px;">Total Time</div>
        <div style="font-size: 24px; font-weight: bold;">${maxTransmitSpan.toFixed(1)}s</div>
        <div style="font-size: 11px; opacity: 0.8; margin-top: 5px;">
          until final timeout
        </div>
      </div>
      <div style="background: rgba(255,255,255,0.1); padding: 15px; border-radius: 6px;">
        <div style="font-size: 12px; opacity: 0.9; margin-bottom: 5px;">Energy Cost</div>
        <div style="font-size: 24px; font-weight: bold;">${totalEnergyCost.toFixed(2)} mAs</div>
        <div style="font-size: 11px; opacity: 0.8; margin-top: 5px;">
          if all attempts fail
        </div>
      </div>
    </div>
  </div>

  <div style="background: #f8f9fa; padding: 20px; border-radius: 8px; border-left: 4px solid #E67E22;">
    <h4 style="margin: 0 0 15px 0; color: #2C3E50;">Transmission Schedule</h4>
    ${retransmissionSchedule.map((item, index) => {
      const barWidth = index === 0 ? 0 : (item.timeout / maxTransmitSpan * 100);
      const barColor = index === 0 ? '#16A085' :
                      index === maxRetransmit ? '#E74C3C' : '#E67E22';
      return `
        <div style="margin-bottom: 12px;">
          <div style="display: flex; justify-content: space-between; font-size: 12px; color: #2C3E50; margin-bottom: 4px;">
            <span><strong>${item.label}</strong></span>
            <span>t = ${item.cumulativeTime.toFixed(2)}s</span>
          </div>
          <div style="background: #e0e0e0; height: 24px; border-radius: 4px; position: relative; overflow: hidden;">
            <div style="background: ${barColor}; width: ${item.cumulativeTime / maxTransmitSpan * 100}%; height: 100%; border-radius: 4px; display: flex; align-items: center; padding: 0 8px; color: white; font-size: 11px; font-weight: 600;">
              ${index === 0 ? 'Send' : `Wait ${item.timeout.toFixed(2)}s`}
            </div>
          </div>
        </div>
      `;
    }).join('')}

    <div style="margin-top: 20px; padding: 12px; background: #FFF3E0; border-radius: 6px; font-size: 13px; color: #2C3E50;">
      <strong>Energy Impact:</strong> If all ${maxRetransmit + 1} attempts fail, you've spent ${totalEnergyCost.toFixed(2)} mAs = ${(totalEnergyCost / 0.017).toFixed(0)}x the energy of a successful NON message. This is why CON should be used sparingly for battery-powered devices!
    </div>

    <div style="margin-top: 10px; padding: 12px; background: #E3F2FD; border-radius: 6px; font-size: 13px; color: #2C3E50;">
      <strong>Exponential Backoff:</strong> Each retry doubles the timeout (with jitter from ACK_RANDOM_FACTOR=${randomFactor.toFixed(1)}). This prevents synchronized retransmissions from overwhelming the network when multiple devices timeout simultaneously.
    </div>
  </div>
</div>`

Quick Review: Match & Sequence

Test your recall before the detailed knowledge checks below.

Checkpoint: Exchange Patterns

• Piggyback response finishes a fast CON request in one round trip by carrying payload inside ACK.
• Separate response sends an empty ACK first, then later returns payload as a new CON for slower work such as an 8-second diagnostic report.
• Retransmission starts after ACK_TIMEOUT and uses exponential backoff plus ACK_RANDOM_FACTOR jitter.

5.10 Videos

Video

Application Protocols Overview

See where CoAP sits among MQTT, HTTP, and AMQP before diving into the exchange patterns in this chapter.

Open lesson video →

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

Video

Protocols and REST in Practice

Review practical protocol layering and REST interactions that map directly onto CoAP request, ACK, and response behavior.

Open lesson video →

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

5.11 Knowledge Check

Test your understanding of CoAP message types and communication patterns.

Label the Diagram

Code Challenge

5.12 See Also

• CoAP Fundamentals and Architecture: Review where message types fit in the client/server architecture.
• CoAP Message Reliability and Exchange Contracts: Go deeper on CON/NON/ACK/RST layering, named retransmission timers, Message ID versus Token roles, and duplicate handling.
• CoAP Methods and Features: Connect CON, NON, ACK, and RST behavior to GET, POST, PUT, DELETE, and resource discovery.
• CoAP Observe Extension: See how notifications use confirmable and non-confirmable messages over time.
• CoAP Security Applications: Relate message handling to DTLS, OSCORE, and constrained-device security choices.

5.13 Summary

CoAP message types separate transport reliability from application semantics. Confirmable and non-confirmable messages control acknowledgement behavior, while request methods and response codes describe the resource operation.

5.14 Key Takeaway

Choose the CoAP message type from the consequence of loss. Use confirmable messages for commands and state changes that must be acknowledged, and non-confirmable messages for replaceable telemetry where the next reading can supersede a lost one.