57  CoAP Observe Patterns

In 60 Seconds

CoAP’s Observe extension enables server-push notifications that save 99% energy compared to HTTP polling: a client registers interest in a resource, and the server sends notifications only when the value changes. Key implementation details include sequence number ordering with 24-bit wraparound, conditional observe to suppress notifications below a threshold, and NAT timeout handling where clients must re-register before the NAT mapping expires.

57.1 Learning Objectives

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

  • Implement CoAP Observe: Set up server-push notifications for real-time sensor monitoring
  • Apply Sequence Number Algorithms: Correctly process notification ordering and 24-bit wraparound using modular arithmetic
  • Configure Observe Subscriptions: Register, maintain, and deregister Observe relationships on constrained devices
  • Calculate Energy Savings: Quantify and compare the power consumption of Observe versus polling strategies
  • Diagnose NAT Timeout Failures: Identify and resolve common firewall/NAT timeout problems in production deployments
  • Distinguish CON from NON Messages: Select the appropriate message type based on reliability and energy trade-offs
  • 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

57.2 For Beginners: CoAP Observe Patterns

The CoAP Observe extension lets a client subscribe to a resource and get automatic updates when its value changes, like following a social media account that notifies you of new posts. For IoT, this means a dashboard can automatically receive new temperature readings without constantly asking the sensor for updates.

57.3 Prerequisites

Required Reading:

Estimated Time: 25 minutes

This is Part 2 of the CoAP Comprehensive Review:

  1. Protocol Fundamentals - Message types, architecture, comparisons
  2. Observe Patterns (this chapter) - Push notifications, subscriptions
  3. Labs & Implementation - Hands-on ESP32 and Python
  4. Knowledge Assessment - Quizzes and scenario questions

57.4 CoAP Observe Mechanism - Push Notifications

The Observe pattern is CoAP’s killer feature for IoT, enabling server-push notifications without persistent connections. This provides 99% energy savings compared to HTTP polling:

CoAP Observe pattern
Figure 57.1: CoAP Observe server-push notifications with 99% energy savings

CoAP Observe mechanism demonstrating server-push notifications with 99% energy savings versus client polling. Phase 1 - Registration (one-time 3 mJ cost): Client sends single CON GET request with Observe: 0 option header to register interest in /temp resource. Server responds with ACK 2.05 Content containing initial temperature value (22C) and Observe sequence number 42. Subscription now established - client doesn’t send further requests. Phase 2 - Autonomous Notifications (2.5 mJ each): When sensor detects temperature change to 23C, server autonomously pushes CON notification with Observe: 43 and new value, without waiting for client request. Client sends ACK to confirm receipt. Server continues pushing notifications for each change (24C with Observe: 44), maintaining incrementing sequence numbers. Client compares sequence numbers to detect out-of-order delivery caused by network reordering - if received seq < last_seen_seq, discard as stale. Zero client polling overhead, zero network bandwidth waste, instant 0-latency updates when data changes. Phase 3 - Deregistration (clean termination): Client sends RST message in response to notification to explicitly stop subscription, or alternatively sends GET with Observe: 1 to formally deregister. Server removes observation from active list, stops sending notifications. Server also implements 24-hour timeout to automatically clean up stale observations if client disappears.

Figure 57.2

57.5 Observe Performance Analysis

Scenario: Temperature monitoring over 24 hours, sensor updates every 5 minutes (288 actual changes)

Approach Messages Energy Bandwidth Latency Notes
HTTP Polling (30s) 2,880 requests 86,400 mJ 464.1 KB 15s avg Client polls every 30s
CoAP NON Polling (30s) 2,880 requests 43,200 mJ 61.9 KB 15s avg CoAP without Observe
CoAP Observe 289 messages 723 mJ 7.4 KB 0s (instant) 1 register + 288 notifications
Conditional Observe 58 messages 145 mJ 1.5 KB 0s (instant) Only notify if change >0.5C

Key Benefits:

  1. Energy Efficiency: 99% reduction vs HTTP polling (723 mJ vs 86,400 mJ)
  2. Instant Updates: 0-second latency vs 15-second average staleness with polling
  3. Bandwidth Savings: 98.4% reduction (7.4 KB vs 464.1 KB)
  4. Server-Initiated: No client polling overhead - server pushes when data changes
  5. Scalability: 1 server can handle 1000+ concurrent observations efficiently
Quick Check: Observe Performance

Interactive Calculator: Conditional Observe Threshold

Conditional Observe only sends notifications when the value changes by more than a specified threshold. This dramatically reduces message overhead for noisy sensors or when small fluctuations don’t matter. Adjust the threshold to find the optimal balance between data fidelity and energy efficiency.

CoAP Observe’s energy advantage becomes critical for battery-powered sensors. Let’s calculate the impact:

HTTP polling scenario (30-second intervals, 24 hours): - Polls per day: \(\frac{24 \times 3600}{30} = 2{,}880\) requests - Each HTTP request: TCP handshake + request + response ≈ 30 mJ (includes TCP overhead and header processing) - Daily energy: \(2{,}880 \times 30 = 86{,}400\) mJ

CoAP Observe (temperature changes 288 times/day, CON notifications): - Registration: 1 CON GET with Observe: 0 = 3 mJ (once) - Each CON notification round-trip: server transmit (1.5 mJ) + client ACK (1.5 mJ) ÷ 2 parties ≈ 2.5 mJ system average per notification - Daily energy: \(3 + 288 \times 2.5 = 3 + 720 = 723\) mJ total system energy

Energy ratio (system-wide): \[\frac{86{,}400}{723} \approx 120\times \text{ improvement}\]

Battery life (CR2032, 225 mAh @ 3V = 2,430 J = 2,430,000 mJ):

Calculation: \(225 \text{ mAh} \times 3\text{ V} = 675 \text{ mWh} = 675 \times 3.6 \text{ J} = 2{,}430 \text{ J} = 2{,}430{,}000 \text{ mJ}\)

  • HTTP polling: \(\frac{2{,}430{,}000}{86{,}400} \approx 28\) days ≈ 1 month
  • CoAP Observe: \(\frac{2{,}430{,}000}{723} \approx 3{,}361\) days ≈ 9.2 years (limited by self-discharge, ~5 years realistic)

The math shows why Observe is essential for battery IoT: it delivers approximately 99% energy reduction versus HTTP polling.

Interactive Calculator: Observe Energy Savings

Adjust the polling interval and notification frequency above to see how CoAP Observe dramatically reduces energy consumption compared to CoAP CON polling. Note: HTTP polling costs even more (~30 mJ per request vs 3 mJ for CoAP CON) due to TCP connection setup and header overhead. Even against the more efficient CoAP CON baseline, Observe still achieves 99%+ energy savings when sensor updates are infrequent.

57.6 Common Pitfalls and Solutions

57.6.1 NAT/Firewall Timeout Issues

  • Problem: NAT/firewall closes UDP port after 60-120 seconds of inactivity
    • Solution: Client re-registers every 5 minutes to refresh port mapping
  • Problem: Notifications arrive out-of-order due to network reordering
    • Solution: Check Observe sequence numbers; discard if seq# < last_received
  • Problem: Server doesn’t know client lost power/restarted
    • Solution: Server implements 24-hour timeout; cleans up stale observations
  • Problem: Battery drains fast with frequent notifications
    • Solution: Use conditional observe (only notify on significant changes >0.5C)
Pitfall: Ignoring NAT/Firewall Timeouts with CoAP Observe

The Mistake: Developers implement CoAP Observe for real-time sensor monitoring but don’t account for NAT/firewall UDP session timeouts. After 60-300 seconds of inactivity, the NAT mapping expires and server notifications can no longer reach the client.

Why It Happens: Observe works perfectly in development (local network, no NAT), but fails in production when devices are behind home routers or enterprise firewalls. Developers assume the UDP “connection” stays open indefinitely like TCP.

The Fix: Implement Observe re-registration before NAT timeout:

# Re-register Observe every 5 minutes to refresh NAT mapping
OBSERVE_REFRESH_INTERVAL = 300  # seconds (5 minutes)

async def maintain_observe(uri):
    while True:
        # Send fresh GET with Observe:0 to re-register
        request = Message(code=GET, uri=uri)
        request.opt.observe = 0
        await protocol.request(request).response
        await asyncio.sleep(OBSERVE_REFRESH_INTERVAL)

Alternatively, use CON (Confirmable) notifications instead of NON - the bidirectional ACK traffic keeps NAT mappings alive.

Real Impact: A smart agriculture deployment lost 40% of sensor data because Observe notifications stopped arriving after NAT timeouts. The sensors were sending data, but packets were dropped at the farm’s router. Re-registration every 5 minutes restored 99.7% data delivery with minimal overhead (1 extra message every 5 minutes vs continuous polling).

Interactive Calculator: NAT Timeout Management

Calculate the optimal Observe re-registration interval based on your NAT/firewall timeout and notification frequency. If notifications are infrequent, periodic re-registration is needed to keep the NAT mapping alive. Adjust the safety margin to account for network jitter and timing uncertainty.

Pitfall: Using NON Messages for Critical Commands

The Mistake: Developers use Non-Confirmable (NON) messages for actuator commands like door locks, HVAC controls, or emergency stops because “CoAP is reliable enough” or to save energy.

Why It Happens: NON messages are simpler (no ACK handling) and use 50% less energy than CON. In testing with reliable networks, NON appears to work fine. The 5-15% packet loss in real wireless environments isn’t apparent until production.

The Fix: Always use CON (Confirmable) messages for commands that affect physical state:

# Bad: NON for actuator command
request = Message(code=PUT, uri='coap://lock/state', mtype=NON)
request.payload = b'{"locked": false}'
await protocol.request(request).response  # May never arrive!

# Good: CON for actuator command with retry
request = Message(code=PUT, uri='coap://lock/state', mtype=CON)
request.payload = b'{"locked": false}'
response = await protocol.request(request).response  # Retries automatically
if response.code == CHANGED:
    print("Door unlocked successfully")

Real Impact: A warehouse automation system used NON messages for forklift routing commands. During Wi-Fi congestion, 8% of commands were lost, causing forklifts to collide. After switching to CON messages, command delivery reached 99.99% with automatic retransmission. The 2x energy cost was negligible compared to collision damage costs. Rule of thumb: NON for sensors (temperature, humidity), CON for actuators (locks, motors, valves).

Try It: CON vs NON Message Type Analyzer

57.7 Worked Example: Observe Token and Sequence Number Management

Worked Example: Observe Token and Sequence Number Management

Scenario: A CoAP client monitors a temperature sensor using the Observe extension. You need to implement proper token matching and sequence number validation to handle out-of-order notifications and detect stale data.

Given:

  • Client token for observation: 0xA7B3 (2 bytes)
  • Initial response Observe sequence: 1000
  • Subsequent notifications arrive: seq=1002, seq=1001, seq=1003, seq=1005
  • Max Observe value: 2^24 - 1 = 16,777,215 (3-byte encoding)
  • Network reordering window: up to 128 seconds

Steps:

  1. Parse initial registration response:

    Response: 2.05 Content
Token: 0xA7B3 (matches request - accept)
Observe: 1000 (initial sequence)
Payload: {"temp": 22.5, "unit": "C"}

Client state:
- last_seq = 1000
- last_time = T0 (current timestamp)
- registered = true

  2. Process notification seq=1002:

    • Token matches: 0xA7B3 = 0xA7B3 (accept)
    • Sequence check: 1002 > 1000 (newer, accept)
    • Update state: last_seq = 1002, last_time = T1
    • Result: Accept notification

  3. Process notification seq=1001 (out-of-order):

    • Token matches: accept
    • Sequence check: 1001 < 1002 (older)
    • Time check: |T2 - T1| < 128 seconds (within window)
    • Fresher data already received
    • Result: Discard as stale

  4. Process notification seq=1003:

    • Token matches: accept
    • Sequence: 1003 > 1002 (newer)
    • Result: Accept, update last_seq = 1003

  5. Handle sequence wraparound (hypothetical: current=16,777,200, new=5):

    def is_fresh(new_seq, last_seq):
    MAX_SEQ = 2**24
    HALF_MAX = 2**23

    diff = (new_seq - last_seq) % MAX_SEQ

    # If diff < 2^23, new_seq is "ahead" (accounting for wrap)
    if diff < HALF_MAX:
        return True  # Fresh notification
    else:
        return False  # Stale (arrived late)

# Example: new=5, last=16,777,200
# diff = (5 - 16,777,200) % 16,777,216 = 21
# 21 < 8,388,608, so fresh = True (wrapped around)

Result: The client correctly processes notifications 1000, 1002, 1003, and 1005, while discarding the late-arriving 1001. The sequence number algorithm handles both normal ordering and 24-bit wraparound scenarios.

Key Insight: CoAP Observe uses a 24-bit sequence space that wraps around. Clients must implement modular arithmetic comparison (not simple <> comparison) to correctly detect fresh vs stale notifications. Always validate token first (security), then sequence number (freshness). Discard notifications with mismatched tokens - they may be spoofed or from a different observation.

Interactive Calculator: Sequence Number Wraparound

This calculator demonstrates RFC 7641’s modular arithmetic algorithm for detecting fresh vs stale notifications. The 24-bit sequence space wraps around every 16,777,216 notifications. Simple new > old comparison fails at the wraparound boundary, but the modular distance algorithm correctly handles all cases.

57.8 Understanding Check: Observe Patterns

Situation: Your smart building has three types of devices with different reliability requirements:

Device types:

  1. Temperature sensors: Report every 30 seconds
  2. Fire alarms: Critical alerts that MUST be received
  3. Occupancy counters: Periodic counts where occasional loss acceptable

Think about:

  1. What happens if a temperature sensor’s NON message is lost?
  2. What happens if a fire alarm’s NON message is lost?
  3. How does CON message reliability work without TCP?

Key Insight:

NON (Non-Confirmable):

  • Fire-and-forget: Send once, no acknowledgment
  • Energy: 1.5 mJ (transmit only, 25ms)
  • Reliability: ~85-95% (depends on network quality)
  • Use for: Replaceable data where next update supersedes previous

CON (Confirmable):

  • Wait for ACK: Server acknowledges receipt
  • Energy: 3.0 mJ (transmit + wait for ACK, 50ms)
  • Reliability: 99.99% (retries up to 4 times with exponential backoff)
  • Use for: Critical data that MUST arrive

Recommended mapping:

Temperature sensors -> NON (missing 1 reading OK, next arrives in 30s)
Fire alarms -> CON (MUST deliver, worth 2x energy cost)
Occupancy -> NON (periodic count, loss has minimal impact)

Energy impact over 24 hours:

  • Temp sensor (2880 readings/day): NON = 4.3Wh, CON = 8.6Wh (2x difference)
  • Fire alarm (2 alarms/year): Energy impact negligible, reliability critical
  • Occupancy (96 counts/day): NON appropriate
Try It: Device Message Type Planner

Situation: You’re choosing a protocol for a warehouse automation system with 200 temperature sensors and 50 automated forklifts.

Requirements:

  • Sensors: Report temperature to central monitoring (one-to-one)
  • Forklifts: Send location updates to multiple subscribers (dispatch, safety, analytics)

Think about:

  1. Which communication pattern does each device type need?
  2. Does CoAP support publish-subscribe like MQTT?
  3. How would you implement CoAP for the sensors vs MQTT for the forklifts?

Key Insight:

Architectural patterns:

CoAP (Request-Response):

Client -> Server pattern
Sensor: POST coap://server/warehouse/zone1/temp {"value": 24.5}
Server: ACK 2.04 Changed
  • Direct device-to-server communication
  • RESTful API (GET /temp, POST /temp)
  • No broker infrastructure needed
  • One publisher -> One subscriber

MQTT (Publish-Subscribe):

Publisher -> Broker -> Subscribers pattern
Forklift: PUBLISH forklift/42/location {"x": 125, "y": 340}
Broker: Routes to ALL subscribers of forklift/42/location
Subscribers: Dispatch system, safety monitor, analytics
  • Decoupled: Publishers don’t know subscribers
  • One publisher -> Many subscribers
  • Broker required (single point of management/failure)

Recommended architecture:

Temperature sensors (200) -> CoAP -> Central server
- Direct communication, no broker overhead
- RESTful endpoints: coap://server/temp/zone1, coap://server/temp/zone2
- Lower latency (no broker hop)
- Simpler infrastructure

Forklifts (50) -> MQTT -> Broker -> Multiple apps
- Dispatch needs location updates
- Safety system needs location updates
- Analytics needs location history
- MQTT naturally broadcasts to all subscribers

Hybrid benefits:

  • CoAP for one-to-one (sensors): Minimal overhead, RESTful API
  • MQTT for one-to-many (forklifts): Natural pub-sub pattern
  • Total cost: 1 MQTT broker + 1 CoAP server (vs 250 devices x broker overhead)
Try It: CoAP vs MQTT Protocol Selector

57.9 Visual Reference Gallery

CoAP Observe push updates

CoAP Observe showing push notifications

The Observe pattern is CoAP’s key feature for efficient IoT monitoring, enabling 99% bandwidth reduction compared to polling by only sending updates when sensor values actually change.

Scenario: Your CoAP client subscribes to a high-frequency sensor that sends Observe notifications every 100ms. The 24-bit sequence number will wrap around in about 19 days. You need to implement correct freshness detection that handles wraparound without discarding valid notifications.

Given:

  • Observe sequence number: 3 bytes (24 bits), range 0 to 16,777,215
  • Notification rate: 10 per second
  • Time to wraparound: 16,777,215 / 10 = 1,677,721.5 seconds ≈ 19.4 days
  • Network can reorder packets by up to 5 seconds
  • Current last_seq: 16,777,200 (near wraparound)
  • Incoming notifications: seq=16,777,210, seq=5, seq=16,777,205

Step 1: Implement naive comparison (WRONG)

# WRONG: Simple integer comparison fails at wraparound
def is_fresh_naive(new_seq, last_seq):
    return new_seq > last_seq

# Test with wraparound scenario
last_seq = 16_777_200
test_sequences = [16_777_210, 5, 16_777_205]

for seq in test_sequences:
    fresh = is_fresh_naive(seq, last_seq)
    print(f"seq={seq:,}: {'ACCEPT' if fresh else 'REJECT'}")

# Output:
# seq=16,777,210: ACCEPT  ✓ (correct)
# seq=5: REJECT            ✗ (WRONG - should accept, wrapped around)
# seq=16,777,205: ACCEPT  ✓ (correct)

Step 2: Implement RFC 7641 modular arithmetic (CORRECT)

def is_fresh_modular(new_seq, last_seq):
    """
    RFC 7641 Section 3.4 freshness algorithm
    Handles 24-bit wraparound using modular distance
    """
    MAX_SEQ = 2**24          # 16,777,216
    HALF_MAX = 2**23         # 8,388,608

    # Calculate circular distance
    distance = (new_seq - last_seq) % MAX_SEQ

    # If distance < half the sequence space, new_seq is "ahead"
    return distance < HALF_MAX

# Test with wraparound
last_seq = 16_777_200

seq = 16_777_210
distance = (seq - last_seq) % (2**24)  # = 10
print(f"seq={seq:,}: distance={distance}, fresh={distance < 2**23}")
# Output: seq=16,777,210: distance=10, fresh=True ✓

seq = 5  # Wrapped around
distance = (seq - last_seq) % (2**24)  # = 21
print(f"seq={seq:,}: distance={distance}, fresh={distance < 2**23}")
# Output: seq=5: distance=21, fresh=True ✓

seq = 16_777_205  # Reordered, arrived late
distance = (seq - last_seq) % (2**24)  # = 5
print(f"seq={seq:,}: distance={distance}, fresh={distance < 2**23}")
# Output: seq=16,777,205: distance=5, fresh=True ✓

Step 3: Add timestamp fallback for extreme reordering

import time

def is_notification_fresh(new_seq, last_seq, new_time, last_time):
    """
    Complete freshness check with timestamp fallback
    """
    MAX_SEQ = 2**24
    HALF_MAX = 2**23
    TIME_WINDOW = 128  # seconds (RFC 7641 recommendation)

    # Primary check: modular sequence comparison
    distance = (new_seq - last_seq) % MAX_SEQ
    seq_fresh = (distance < HALF_MAX)

    # Fallback: if timestamps within window, accept even if seq seems old
    time_fresh = (new_time - last_time) < TIME_WINDOW

    return seq_fresh or time_fresh

# Test edge case: notification arrives 10 seconds late
last_seq = 16_777_210
last_time = time.time()

# 50 notifications arrive in order (seq 16,777,211 to 16,777,260)
time.sleep(0.5)  # Simulate passage of time

# Old notification seq=16,777,205 arrives late
new_seq = 16_777_205
new_time = time.time()

distance = (new_seq - last_seq) % (2**24)
# = (16,777,205 - 16,777,260) % 16,777,216 = 16,777,161 (appears very old)

seq_fresh = (distance < 2**23)  # False (appears stale)
time_fresh = (new_time - last_time) < 128  # True (within 128s window)

fresh = seq_fresh or time_fresh  # True (fallback accepts it)
print(f"Late notification: seq_fresh={seq_fresh}, time_fresh={time_fresh}, final={fresh}")
# Output: Late notification: seq_fresh=False, time_fresh=True, final=True

Step 4: Complete client implementation

class ObserveClient:
    def __init__(self):
        self.last_seq = None
        self.last_time = None

    def process_notification(self, notification):
        new_seq = notification.opt.observe
        new_time = time.time()

        if self.last_seq is None:
            # First notification - always accept
            self.last_seq = new_seq
            self.last_time = new_time
            return True

        # Check freshness
        if self.is_notification_fresh(new_seq, self.last_seq,
                                       new_time, self.last_time):
            # Update state with newer notification
            self.last_seq = new_seq
            self.last_time = new_time
            return True
        else:
            # Discard stale notification
            return False

    def is_notification_fresh(self, new_seq, last_seq, new_time, last_time):
        MAX_SEQ = 2**24
        HALF_MAX = 2**23
        TIME_WINDOW = 128

        distance = (new_seq - last_seq) % MAX_SEQ
        seq_fresh = (distance < HALF_MAX)
        time_fresh = (new_time - last_time) < TIME_WINDOW

        return seq_fresh or time_fresh

Result: The client correctly handles all three test notifications: - seq=16,777,210: Accepted (in-order, distance=10) - seq=5: Accepted (wraparound, distance=21) - seq=16,777,205: Rejected (stale, arrived after fresher seq=16,777,210)

Key Insights:

  1. Never use simple new > old comparison - breaks at wraparound boundary
  2. 24-bit wraparound occurs every 19 days at 10 Hz notification rate
  3. Modular distance correctly measures “circular” sequence space
  4. Timestamp fallback handles extreme reordering (>8M sequence numbers apart)
  5. Client state must track both last_seq and last_time for complete freshness checking
Try It: Sequence Wraparound Timeline Calculator

57.10 Concept Relationships

How CoAP Observe patterns connect to IoT design concepts:

Observe Pattern Builds On:

  • Event-Driven Architecture - React to changes vs periodic polling
  • Publisher-Subscriber Model - Server-initiated updates
  • Stateful Connections - Server tracks active observers

Sequence Numbers Relate To:

  • Ordering Guarantees - Detecting out-of-order delivery
  • Modular Arithmetic - 24-bit wraparound handling
  • Replay Protection - Preventing stale data acceptance

NAT Timeout Issues Connect To:

  • UDP Session Management - Mapping expiration problems
  • Keepalive Strategies - Periodic re-registration
  • Firewall Traversal - Server-initiated vs client-initiated

Energy Savings Enable:

  • Battery-Powered Networks - 99% reduction vs polling
  • Smart Agriculture - Years of operation on coin cells
  • Industrial IoT - Wireless sensor networks

Compare to Alternatives:

  • MQTT Subscriptions - Topic-based vs URI-based observation
  • WebSocket Push - Full-duplex vs asymmetric
  • Long Polling - HTTP alternative mechanism

57.11 See Also

Review Series (4 Parts):

Core Observe Learning:

Protocol Comparisons:

  • MQTT vs CoAP Observe - Subscription mechanisms
  • Server-Sent Events - HTTP push alternative
  • gRPC Streaming - Modern RPC patterns

Implementation Resources:

Debugging & Tools:

Advanced Topics:

  • Conditional Observe - Change thresholds
  • Observer Scalability - 1000+ concurrent subscriptions
  • OSCORE with Observe - End-to-end encryption

Specifications:

57.12 What’s Next

Chapter Focus Why Read It
CoAP Review: Labs & Implementation ESP32 and Python hands-on coding Apply the Observe concepts from this chapter by building and testing a real CoAP server with push notifications
CoAP Review: Knowledge Assessment Scenario-based quizzes Assess your mastery of all CoAP Observe concepts with timed questions and worked solutions
CoAP Observe Extension Deep-dive implementation guide Explore advanced Observe features including batch notifications, conditional observe, and OSCORE encryption
CoAP Review: Protocol Fundamentals Message types and request/response model Reinforce the CON/NON/ACK/RST message foundation that Observe notifications are built upon
CoAP Fundamentals and Architecture Token management and resource model Understand how tokens secure Observe subscriptions and how CoAP’s URI model maps to observable resources
CoAP Practice Bandwidth and power calculations Practice the energy savings calculations introduced in this chapter with additional worked exercises