The 127-Byte Frame Budget

The 127-Byte Frame Budget

Ada re-derives this chapter’s own numbers step by step, at full precision

foundations
math-foundations
calculation-audit
wifi-mobile
Ada ADA · CALCULATION AUDIT

The 127-Byte Frame Budget

An 802.15.4 data frame has a hard 127-byte cap: a compact in-PAN frame with short addresses leaves 116 payload bytes, but switching both endpoints to 64-bit addresses costs 12 bytes and enabling MAC security costs another 9, dropping the compact frame to 107 bytes. That is already under the “about 110 bytes” the chapter warns about, before any 6LoWPAN or routing header is added. This audit adds the header up byte by byte and asks whether the frame budget survives real addressing and security, or quietly goes over before the first capacity claim.

Companion to the chapter 802.15.4 Specifications and Roles — every number here comes from that chapter.

See the relationship before changing it

The figure reads from left to right. The blue card is mac and security overhead. The middle card applies this page's rule. The green card is remaining frame payload. 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 mac and security overhead, so the numeric fixture does not switch without explanation.

MAC and security overhead changes remaining frame payload An input card leads through the rule payload = 127-byte frame - overhead to the remaining frame payload result. INPUT PAGE INPUT APPLY THE RULE predict calculate check units OUTPUT RESULT
Walk the arrows. Every address or security byte consumes space before adaptation and routing headers arrive.

Derive the baseline in four named moves

  1. 1

    Name the input. The chapter baseline is 20 bytes.

  2. 2

    Name the relationship. payload = 127-byte frame - overhead

  3. 3

    Substitute with units. 127 - 20 = 107 bytes

  4. 4

    Read the result. Keep the unit beside the value. Use it only inside the technical boundary on this page.

Predict, then change mac and security overhead

Try Predict the direction of payload = 127-byte frame - overhead. Test another mac and security overhead, then compare remaining frame payload.

20 bytes
Chapter baseline
Remaining frame payload

Observe Every address or security byte consumes space before adaptation and routing headers arrive. Reset mac and security overhead to 20 and compare remaining frame payload.

Explain Every address or security byte consumes space before adaptation and routing headers arrive.

Check yourself

What should you do before trusting a moved-control result?
Answer: Predict its direction, apply the shown relationship, keep the units, and reset to the worked baseline.
What does this small model leave out?
Answer: Only mac and security overhead moves here. Field effects named in the technical boundary stay fixed.

Honesty note. This teaching model changes only mac and security overhead. It is not a field prediction.

Ada: The chapter says a compact in-PAN data frame leaves 116 payload bytes, that long addresses cost 12 of them, and that MAC security takes another 9. Let me add the header up byte by byte and check each figure against the 127-byte cap.

  • Compact overhead with PAN-ID compression and short addresses: FCF 2 + sequence 1 + dest PAN 2 + dest short 2 + source short 2 + FCS 2 = 11 bytes, so payload space is 127 - 11 = 116 bytes.
  • Switch both addresses to the 64-bit EUI-64 and each grows from 2 to 8 bytes: 11 + (8 - 2) x 2 = 11 + 12 = 23 bytes of overhead, leaving 127 - 23 = 104 bytes. Short addressing therefore recovers exactly 116 - 104 = 12 bytes per frame.
  • Enable MAC security with a 5-byte auxiliary header and a 4-byte message integrity code: 5 + 4 = 9 bytes, dropping the compact frame from 116 to 116 - 9 = 107 bytes.

Every number checks out, and the audit exposes the real squeeze: the compact frame starts at 116 bytes but security alone takes it to 107, so the “about 110 bytes” payload the chapter warns about is already over budget once a 6LoWPAN or routing header is added - which is exactly why the frame budget must be counted before any capacity claim.

Every number above is taken from the chapter’s own material and re-derived step by step.

TrySubtract each addressing and security field from the 127-byte PSDU cap.
ObserveShort addressing leaves 116 bytes; long addresses leave 104; compact security leaves 107.
ExplainPayload capacity is a byte ledger, so every adaptation or routing header must be charged before claiming fit.
Technical boundaries. The ledger uses the stated PAN-ID compression, address modes, auxiliary header, MIC, and FCS sizes. It does not model optional information elements, different security levels, 6LoWPAN headers, fragmentation, retransmissions, or vendor framing.
Audit result

The compact 11-byte overhead leaves 116 bytes; adding 9 security bytes leaves 107, before any higher-layer header.