flowchart LR
B[Build packet<br/>type, length, sequence] --> C[Compute checksum]
C --> Q[Transmit or queue]
Q --> R[Receiver reads bytes]
R --> V{Checksum valid?}
V -- yes --> A[Accept and ACK]
V -- no --> N[Reject and NACK]
Q --> D[Delay or drop event]
D --> T[Trace timing and cause]
29 Lab: Network Packet Simulator
networking-core
net
packet
sim
29.1 Start With a Packet You Can Break Safely
A packet simulator lets you change headers, routes, losses, and timing without risking field devices. That makes invisible networking behavior visible enough to test before firmware or hardware hides the problem.
Use the simulation like a rehearsal. Predict what should happen, change one thing, observe the packet state, and explain the result before moving to the next variable.
29.3 Learning Objectives
By completing this lab, you will be able to:
- Construct a packet structure: Identify and explain the components of a network packet (header, payload, checksum) and build one in ESP32 C++ code
- Demonstrate transmission states: Apply LED indicators to represent distinct stages of packet transmission through a finite state machine
- Implement error detection: Calculate and verify checksums for data integrity using the ones’ complement algorithm (RFC 1071)
- Analyze packet communication: Apply serial output inspection to identify transmission errors and differentiate between corrupted and valid packets
- Calculate protocol overhead: Evaluate the trade-off between error detection strength (checksum vs CRC32) and bandwidth efficiency for constrained IoT links
Chapter Roadmap
Follow the packet-simulation lab from trace evidence to design judgment:
- First read a packet trace as evidence: source intent, type, length, sequence, checksum, timing, and receiver decision.
- Then vary payload size, packet rate, serial rate, and corruption before adding hardware.
- Next connect the optional ESP32 circuit and map each LED state to a packet lifecycle state.
- After that inspect the packet fields, sequence numbers, ACK/NACK behaviour, and checksum failures in the Serial Monitor.
- Finally compare 2-byte checksums with 4-byte CRC32 so the error-detection choice is backed by overhead and energy evidence.
Checkpoints recap each stage; collapsed sections and hidden code provide detail.
Overview: A Packet Trace Is Evidence
A packet simulator is useful when it makes the invisible path visible. The packet is not just a payload; it is a record with source intent, type, length, sequence, checksum, timing, delivery result, and receiver decision. In a physical deployment those facts are spread across device logs, gateway counters, packet captures, broker logs, and application telemetry. The lab puts the same ideas in one controlled place so learners can see how a packet becomes evidence.
In an IoT network, the same application message can be delayed by a queue, rejected by a checksum, repeated by a retry rule, duplicated by recovery logic, or delivered out of order. The lab matters because each state leaves a different trace that supports a different troubleshooting conclusion. A checksum failure is not a route failure. A late packet is not always a lost packet. A duplicate can be a sign of a retry rule working as designed, or it can be a sign that idempotency is missing at the receiver. The simulator should make those differences visible before students meet them in a real mesh or gateway deployment.
The overview lesson is that a simulator is not a toy version of the network; it is a controlled evidence generator. By changing only payload size, packet rate, corruption, or queue capacity, students can connect one cause to one observation. That discipline scales to real IoT systems: make one condition observable, change one variable, and record the receiver decision rather than assuming success because a send function returned without an error.
Practitioner: Build The Packet Trace Record
For each run, capture the packet type, payload size, sequence number, checksum result, send time, receive time, latency, loss or corruption event, ACK or NACK response, retry count, and final application decision. That record separates a packet-format error from a link-capacity problem. It also gives students a vocabulary for later labs: "the receiver rejected sequence 18 because checksum verification failed" is a different finding from "sequence 18 was accepted but arrived after the control deadline."
Vary one condition at a time. Change payload size to expose overhead, packet rate to expose queueing, corruption to test checksum handling, and sequence behavior to reveal lost, duplicate, or out-of-order packets. If payload size increases, the expected observation is a larger transmission time and lower payload efficiency. If packet rate increases beyond what the link model can carry, the expected observation is queue growth, rising latency, and eventually drops. If one byte is corrupted, the expected observation is a checksum mismatch and a receiver decision to reject or request retransmission. If sequence numbers skip, the expected observation is missing-message evidence rather than a generic timeout.
The practitioner record should include units and denominators. Packet loss should state the number lost over the number sent. Overhead should state overhead bytes over total packet bytes. Latency should state whether it is one-way simulator time, round-trip time, or application processing time. Goodput should state useful payload bytes per second, not total link bytes per second. Those details keep lab conclusions from becoming slogans such as "checksum fixed it" or "bandwidth is low" without a measurable boundary.
A useful extension is to make the receiver policy explicit. Some IoT commands should be rejected on checksum mismatch and retried. Some sensor streams can skip a bad sample and preserve the next valid reading. Some actuator commands must be idempotent so a duplicate retry does not apply the same physical action twice. The simulator should let students connect the packet trace to the application decision, because production reliability depends on both.
Under the Hood: Headers And Queues Shape What You See
Header fields tell the receiver how to interpret bytes before the payload is useful. A length field bounds the read, a type field selects the handling rule, a sequence field makes ordering visible, and a checksum decides whether the packet can be trusted. Without those fields the receiver can still receive bytes, but it cannot safely decide where a message ends, whether a duplicate has arrived, or whether a corrupted value should be passed to the application. This is why protocol overhead is not automatically waste; it buys structure, validation, and recovery evidence.
Queueing changes the timing story even when packet bytes are correct. When offered load rises above what the path can serve, packets wait, arrive late, or drop; retries then add more packets to the same path. A trace must include timing and state, not only success or failure. In a constrained IoT link, a small increase in offered load can create a feedback loop: more delay triggers retries, retries consume airtime, consumed airtime increases queueing, and queueing makes still more packets miss their deadline. The packet simulator is a safe place to observe that loop without damaging a real control process.
The checksum example also hides an important under-the-hood boundary. A simple checksum can catch many accidental changes, but it is not authentication and it is not a guarantee that the payload is semantically correct. A packet can pass checksum validation and still carry the wrong unit, stale sequence, bad timestamp, or unauthorized command. That distinction matters in IoT because packet integrity, message freshness, and command authorization may live in different layers. The lab should keep the checksum lesson precise: checksum evidence supports byte-level integrity for the simulated packet, while higher-layer checks decide whether the accepted bytes are meaningful and allowed.
Finally, sequence numbers turn a stream of packets into a reviewable history. A receiver can detect gaps, duplicates, late arrivals, and reordering only if the protocol exposes a stable ordering field. That is why the simulator should log sequence number alongside send time, receive time, and decision. The fields are small, but they let an operator distinguish "message never arrived" from "message arrived too late" and from "message arrived twice after a retry."
Checkpoint: Packet Trace Evidence
You now know:
- A useful packet trace records type, length, sequence, checksum, timing, delivery result, and receiver decision.
- Queueing, checksum rejection, retries, duplicates, and out-of-order delivery leave different evidence.
- The browser simulator is the safe first place to change one variable and explain one observation.
With trace evidence clear, begin with the browser activity before adding ESP32 hardware.
For Beginners: Network Packet Simulation
A network packet is a small chunk of data that travels across a network, like a postcard traveling through the postal system. Each packet carries an address (header), the message itself (payload), and a verification stamp (checksum) to make sure nothing was damaged in transit. In this lab, you will simulate sending packets between devices, watching LEDs indicate what is happening at each step. It is a hands-on way to understand what normally happens invisibly inside your Wi-Fi network.
29.4 Build and Break a Packet
Use this activity first. It teaches the same packet ideas without requiring an ESP32, breadboard, or external simulator. Change the payload size, packet rate, and corruption setting, then read how the header, payload, checksum, and link utilisation change.
Optional Hardware Build
Use this after the browser simulator if you want to connect LEDs to real packet states: transmitting, received, valid, and error.
| Component | Quantity | Purpose |
|---|---|---|
| ESP32 DevKit | 1 | Microcontroller for packet simulation |
| Red LED | 1 | Error indicator (checksum failure) |
| Green LED | 1 | Success indicator (valid packet) |
| Yellow LED | 1 | Transmission in progress |
| Blue LED | 1 | Packet received indicator |
| 220 ohm Resistors | 4 | Current limiting for LEDs |
| Breadboard | 1 | Circuit assembly |
| Jumper Wires | Several | Connections |
29.5 Circuit Diagram
29.6 Packet Overhead and Efficiency
Before diving into the code, consider how packet structure affects transmission efficiency. For a packet with a 4-byte header, a variable-length payload, and a 2-byte checksum, the overhead ratio depends on how much payload you send relative to the fixed header and checksum bytes.
Checkpoint: Packet Size And Link Load
You now know:
- The lab packet has a 4-byte header and a 2-byte checksum before any payload is counted.
- Payload settings from 1 to 32 bytes change both payload efficiency and total link utilisation.
- At 115200 bps, packet rate and total bytes decide whether the link can keep up.
The simulator has shown the packet math; the optional hardware path now turns the same states into LED and Serial Monitor evidence.
29.7 Optional ESP32 Implementation
Use the browser activity as the main lab. If you build the optional ESP32 version, implement the same behaviour in small pieces rather than pasting a long program at once.
| ESP32 piece | What to implement | How to verify it works |
|---|---|---|
| Packet fields | Version, type, length, sequence, payload, checksum | Serial output shows each field clearly |
| LED state machine | Yellow for transmit, blue for receive, green for valid, red for error | LEDs change state during each demo cycle |
| Checksum function | Recalculate a 16-bit checksum over header and payload bytes | Corrupted payloads are rejected |
| Demo cycle | Send valid data, sensor data, corrupted data, ping, and ACK packets | Each cycle produces the expected LED pattern |
29.8 Step-by-Step Instructions
29.8.1 Step 1: Set Up the Circuit
- Open your preferred ESP32 development environment
- Add an ESP32 DevKit to your workspace or breadboard
- Add 4 LEDs (red, green, yellow, blue) to the breadboard
- Add 4 x 220 ohm resistors for current limiting
- Connect each LED through its resistor to the specified GPIO pins:
- Red LED: GPIO 2
- Green LED: GPIO 4
- Yellow LED: GPIO 5
- Blue LED: GPIO 18
- Connect all LED cathodes (short legs) to GND
29.8.2 Step 2: Upload the Code
- Start from the behaviour map in the optional ESP32 section.
- Implement one piece at a time: packet fields, LED state changes, checksum calculation, then demo cycles.
- Compile after each piece so syntax errors are isolated.
- Run the browser simulator beside your ESP32 output and compare the packet size, checksum result, and success/error decision.
29.8.3 Step 3: Observe the Output
Watch the Serial Monitor for detailed packet information:
- Startup: All LEDs blink in sequence during self-test
- Transmission: Yellow LED lights during packet sending
- Reception: Blue LED indicates packet arrival
- Success: Green LED blinks 3 times for valid checksum
- Error: Red LED blinks 5 times for corrupted packets
29.8.4 Step 4: Understand the Packet Structure
Study the Serial Monitor output to identify:
| Packet field | Example value | What to learn |
|---|---|---|
| Version | 0x01 | Identifies the packet format so future versions can coexist |
| Type | DATA | Tells the receiver whether this is data, ACK, NACK, or ping |
| Length | 16 bytes | Tells the receiver how many payload bytes to read |
| Sequence | 0 | Helps detect lost, duplicate, or out-of-order packets |
| Payload | “Hello IoT World!” | The application data carried by the packet |
| Hex view | 48 65 6C 6C 6F … | The same payload represented as bytes |
| Checksum | 0xF8E2 | Error-detection value recomputed by the receiver |
29.8.5 Step 5: Experiment with Errors
The demo automatically shows a corrupted packet in cycle 3. Observe how:
- The checksum verification fails
- The red LED indicates an error
- A NACK (negative acknowledgment) would be sent in a real system
29.9 Expected Output
When running the simulation, your Serial Monitor should tell the same story as the LEDs:
| Stage | Serial monitor should show | LED meaning |
|---|---|---|
| Startup | LED test complete and pin role summary | All LEDs blink once during self-test |
| Packet created | Packet type, payload length, sequence number, and checksum | No LED yet; the packet is being prepared |
| Transmitting | Packet is being sent | Yellow LED on |
| Received | Packet arrived and checksum is being verified | Blue LED on briefly |
| Success | Checksum valid; packet accepted | Green LED blinks |
| Error cycle | Checksum invalid; retransmission would be requested | Red LED blinks |
| Next cycle | Wait period before repeating with a new packet type | All LEDs off between cycles |
Checkpoint: Hardware Evidence Loop
You now know:
- Red GPIO 2, green GPIO 4, yellow GPIO 5, and blue GPIO 18 each represent a different packet state.
- The sequence field helps detect lost, duplicate, and out-of-order packets instead of treating every timeout the same way.
- ACK/NACK handling connects byte-level validation to the receiver’s recovery action.
Once the basic demo is observable, use the challenges to decide which reliability behaviour should be explicit in the protocol.
29.10 Challenge Exercises
Challenge 1: Add Packet Acknowledgment
Modify the code to implement a complete ACK/NACK system:
- After receiving a valid packet, automatically create and send an ACK packet
- After receiving a corrupted packet, send a NACK packet requesting retransmission
- Add a retry counter that gives up after 3 failed attempts
Hint: Create a new function sendAcknowledgment(bool success, uint8_t seqNum) that creates and transmits the appropriate response.
Implement Sequence Number Checks
Network packets can arrive out of order. Add sequence number tracking:
- Keep track of the last received sequence number
- Detect and report out-of-order packets
- Detect and report duplicate packets
- Add a purple LED (GPIO 19) that blinks for sequence errors
Hint: Store lastReceivedSequence as a global variable and compare incoming packets against it.
Challenge 3: Create a Two-ESP32 Network
For advanced learners with two ESP32 boards:
- Connect two ESP32s via serial (TX1-RX2, RX1-TX2)
- One ESP32 acts as sender, one as receiver
- Implement actual packet transmission over the serial line
- Add a button to trigger manual packet sending
- Display received messages on an OLED screen
Hint: Use Serial2.begin(9600, SERIAL_8N1, RX_PIN, TX_PIN) for the second serial port.
29.11 Checksum Overhead Trade-offs
In resource-constrained IoT systems, every byte counts. Adding error detection increases packet size but prevents silent data corruption. The following worked example quantifies this trade-off.
Industrial IoT Checksum Overhead
Scenario: An industrial IoT sensor transmits 10-byte temperature readings every second over an IEEE 802.15.4 wireless link (250 kbps) with a 1% packet error rate.
Given:
- Payload: 10 bytes per packet
- Frequency: 1 packet/second = 86,400 packets/day
- Error rate: 1% (864 corrupted packets/day)
- Options: No checksum vs 2-byte checksum vs 4-byte CRC32
- Header without checksum: 4 bytes (version, type, length, sequence)
Analysis:
| Option | Overhead Bytes | Total Bytes | Overhead % | Errors Detected | Undetected Errors |
|---|---|---|---|---|---|
| No checksum | 4 | 14 | 28.6% | 0 | 864/day |
| 2-byte checksum | 6 | 16 | 37.5% | ~863/day | ~1/day |
| 4-byte CRC32 | 8 | 18 | 44.4% | ~864/day | ~0 |
Energy Cost (at 10 mW transmit power, 250 kbps data rate):
- Transmission time per byte: 8 bits / 250,000 bps = 0.032 ms/byte
- No checksum: 14 bytes x 0.032 ms = 0.448 ms at 10 mW = 0.00124 uWh per packet
- With 2-byte checksum: 16 bytes x 0.032 ms = 0.512 ms at 10 mW = 0.00142 uWh (+14.3%)
- With CRC32: 18 bytes x 0.032 ms = 0.576 ms at 10 mW = 0.00160 uWh (+28.6%)
Impact Over 1 Year:
- Undetected errors (no checksum): 315,360 corrupted readings
- Extra energy for 2-byte checksum: ~0.16 mWh/year (negligible)
- Trade-off: Spend a fraction of a percent more battery for 99.9% error detection
Decision: A 2-byte checksum is optimal for most IoT sensors – it catches nearly all errors with minimal overhead. CRC32 is only justified for safety-critical applications (medical devices, industrial control systems) where even a single undetected error per day is unacceptable.
Checkpoint: Error Detection Trade-off
You now know:
- With a 10-byte reading every second, the worked example uses 86,400 packets per day.
- A 2-byte checksum raises total packet size to 16 bytes and leaves about 1 undetected error per day in the scenario.
- A 4-byte CRC32 raises total packet size to 18 bytes, so safety-critical use must justify the extra overhead.
The remaining quizzes and concept table check whether the trace, overhead, and recovery ideas are connected.
29.12 Concept Relationships
How the packet networking concepts in this lab interconnect:
| Concept | Relates To | Key Insight |
|---|---|---|
| Packet Header | Protocol Metadata | Version, type, length, and sequence fields identify the packet and enable processing |
| Payload | Application Data | The actual sensor readings, commands, or messages being transmitted |
| Checksum | Error Detection | Mathematical verification that data was not corrupted during transmission |
| Sequence Numbers | Ordering and Loss Detection | Track packets across unreliable links, detect gaps and duplicates |
| ACK/NACK | Reliability | Confirm receipt or request retransmission to ensure delivery |
| Protocol Overhead | Efficiency | Headers and checksums consume bandwidth – minimize for constrained networks |
| LED State Machine | Visualization | Physical representation of transmission, reception, success, and error states |
29.13 Match the Concepts
29.14 Order the Process
Common Pitfalls
1. Running Only One Simulation Seed
A single simulation run produces one sample from a random process. Fix: run at least 30 independent runs with different random seeds and report the mean and 95% confidence interval.
Warm Up Simulations Before Metrics
Metrics collected during the initialisation period (when routing tables are forming) skew the results. Fix: discard the first 10–20% of simulation time as a warm-up period before recording metrics.
Avoid Optimistic Radio Models
The default free-space path loss model ignores walls, furniture, and interference. Fix: use a more realistic model (log-distance, Two-Ray Ground, or measured empirical values) and document which model was used.
Phoebe’s Field Notes: Why “Optimistic” Radio Models Lie
Phoebe’s Why
The default free-space model in most simulators assumes an isotropic transmitter spreading power evenly over a growing sphere, so received power falls as a clean \(1/d^2\) – true in open sky, and the best case any real link will ever see. Walls, furniture, and interference all make power fall faster than that, so free space is not a realistic model, it is a lower bound. Engineers capture the gap by replacing the exponent 2 with a measured exponent \(n\) that climbs as the environment gets busier, then reserve extra decibels – the fade margin – so the link still closes on a bad day, not just the average one. A simulator that only implements the \(n=2\) case is quietly promising more range and reliability than an industrial floor with metal shelving will ever deliver.
The Derivation
Free-space spreading over a sphere of radius \(d\) gives received power a \(1/d^2\) falloff, so free-space path loss is
\[\mathrm{FSPL} = \left(\frac{4\pi d}{\lambda}\right)^2\]
Real, obstructed environments replace the fixed exponent 2 with a measured path-loss exponent \(n\) referenced to a close-in distance \(d_0\):
\[\mathrm{PL}(d) = \mathrm{PL}(d_0) + 10n\log_{10}\!\left(\frac{d}{d_0}\right)\]
A link only closes if received power clears the receiver’s sensitivity by the fade margin \(M\):
\[M = P_t\mathrm{(dBm)} - \mathrm{PL}(d)\mathrm{(dB)} - P_{sens}\mathrm{(dBm)}\]
Worked Numbers: This Lab’s Radio Link
The lab fixes the transmit power at \(10\) mW \(= 10.0\) dBm but not a frequency or distance, so take standard, catalog-typical figures: the 2.4 GHz ISM band this PHY class commonly uses, a \(20\) m indoor hop, and the standard \(-85\) dBm receiver sensitivity commonly quoted for 250 kbps O-QPSK 802.15.4 radios.
- Free space: \(\mathrm{FSPL} = 20\log_{10}(4\pi\times20/\lambda) = 66.0666\ldots\) dB, i.e. 66.1 dB to 3 s.f. (\(\lambda = c/f = 0.125\) m at \(c=3.00\times10^{8}\) m/s).
- Free-space margin: \(M = 10.0 - 66.1 - (-85.0) = 28.9\) dB of headroom – looks very safe.
- Industrial log-distance (\(n=3\), a standard indoor/industrial exponent, versus free space \(n=2\)): the extra loss at 20 m is \(10(3-2)\log_{10}(20/1) = 13.0\) dB, cutting the margin to \(28.9 - 13.0 = \mathbf{15.9}\) dB – still positive, but the “optimistic” free-space number overstated the true margin by nearly half.
- Tie to battery/energy: recomputing the chapter’s own checksum-overhead numbers exactly – \(E = P\times t\) at 10 mW and \(0.032\) ms/byte – gives \(0.00124\ \mu\)Wh (no checksum), \(0.00142\ \mu\)Wh (2-byte checksum), and \(0.00160\ \mu\)Wh (CRC32) per packet, matching the chapter’s own figures. At the chapter’s 86,400 packets/day, that is \(39.2\), \(44.9\), and \(50.5\) mWh/year respectively – so the 2-byte checksum costs \(5.61\) mWh/year extra and CRC32 costs \(11.2\) mWh/year extra, a genuinely small but non-zero tax that a weak, high-\(n\) path (more retries, same per-byte cost) multiplies further.
29.15 Summary
This lab demonstrated essential packet networking concepts through hands-on simulation:
- Packet Structure: Header (version, type, length, sequence) + Payload + Checksum forms a complete self-describing data unit
- Transmission States: Visual feedback through LEDs shows the packet lifecycle from creation through verification
- Error Detection: Checksums catch data corruption during transmission, triggering retransmission requests
- Protocol Design: Version fields enable backward compatibility, sequence numbers detect lost packets, and ACK/NACK mechanisms enable reliable communication over unreliable links
29.16 Knowledge Check
29.17 What’s Next
| Topic | Chapter | Description |
|---|---|---|
| Network Performance | Network Performance Lab | Measure bandwidth, latency, and jitter with ESP32 experiments |
| Packet Journey Game | Packet Journey Game | Interactive adventure tying together all networking concepts through gamified learning |
| TCP/IP Protocol | TCP/IP Fundamentals | How real TCP protocols implement packet structure, flow control, and error handling |
| Error Detection | Error Detection Methods | CRC, checksums, and forward error correction techniques compared |
| Protocol Overhead | Transport Overhead Analysis | Minimising header waste in constrained IoT networks |
| Routing Structures | Network Topologies Fundamentals | How packets route through star, mesh, and tree network structures |
29.18 Key Takeaway
Packet simulation labs should expose routing, queueing, loss, retransmission, and timing behavior. The goal is to connect a packet trace to a network design decision.