Audit the Payload-Share and Frame-Fit Arithmetic
Audit the Payload-Share and Frame-Fit Arithmetic
Ada re-derives payload share, the batching gain, and the frame-fit ceiling from the chapter’s own bytes
ADA · CALCULATION AUDIT
Audit the Payload-Share and Frame-Fit Arithmetic
A single 12-byte reading sent over UDP and IPv4 carries 28 bytes of header (8 for UDP, 20 for IPv4), so only 30% of the packet is useful payload. Batch ten readings and that share jumps to about 81% as the fixed header is paid once, but the batched packet now runs 148 bytes — past the 127-byte ceiling of an IEEE 802.15.4 frame. This audit re-derives the payload share, the batching gain, and that frame-fit limit to ask how far batching can go before the physical link says no.
Companion to the chapter Packet Protocol Overhead — every number here comes from that chapter.
The byte budget is just conservation of bytes: count what carries data, count what carries the protocol, and check whether the resulting packet still fits the physical link.
See the relationship before changing it
The figure reads from left to right. The blue card is application payload. The middle card applies this page's rule. The green card is packet payload efficiency. Walk the arrows once: set the input, apply the rule, then read the result with its unit.
The retained audit below checks several chapter fixtures. This model keeps those stated values fixed and changes only application payload, so the numeric fixture does not switch without explanation.
Derive the baseline in four named moves
- 1
Name the input. The chapter baseline is 12 bytes.
- 2
Name the relationship. efficiency = payload / (payload + 28-byte header) x 100
- 3
Substitute with units. 12 / (12 + 28) x 100 = 30.0%
- 4
Read the result. Keep the unit beside the value. Use it only inside the technical boundary on this page.
Predict, then change application payload
Try Predict the direction of efficiency = payload / (payload + 28-byte header) x 100. Test another application payload, then compare packet payload efficiency.
Observe A larger payload pays the fixed UDP and IPv4 header once, improving efficiency until frame limits intervene. Reset application payload to 12 and compare packet payload efficiency.
Explain A larger payload pays the fixed UDP and IPv4 header once, improving efficiency until frame limits intervene.
Check yourself
What should you do before trusting a moved-control result?
What does this small model leave out?
Ready: use the stated baseline inputs, then compare each displayed result.
1. One reading
The chapter's worked example uses a 12-byte sensor reading with UDP and IPv4 headers. The header total is fixed for this packet shape:
That leaves 28 / 40 = 70% of the transmitted bytes as protocol packaging before any link-layer framing is counted.
2. Ten readings as a batch
Batching ten readings changes the payload, not the UDP/IPv4 header in this simplified review:
| Case | Calculation | Result |
| Ten separate packets | 10 × (12 + 28) | 400 bytes total; 120 payload; 30% useful |
| One ten-reading batch | 120 + 28 | 148 bytes total; 120 payload; about 81% useful |
| Bytes not sent | 400 − 148 | 252 bytes saved before link framing |
3. The physical frame still gets a vote
A classic IEEE 802.15.4 frame is at most 127 bytes in total. If this same UDP/IPv4 batch had to fit one such constrained-radio frame, it would fail even before link addressing or security bytes were added:
What the mathematics buys you: batching improves useful-byte share, but the frame ceiling can turn an efficient-looking packet into a fragmentation risk. The review decision is therefore not "always batch"; it is "batch until freshness, loss exposure, and frame fit still pass."
Every number above is taken from this chapter's own worked example and re-derived step by step.