The 802.16 Frame Structure

The 802.16 Frame Structure

All MAC frames begin with a generic header. The header is followed by an optional payload and an optional checksum (CRC), as illustrated in Fig. 4-33. The payload is not needed in control frames, for example, those requesting channel slots. The checksum is (surprisingly) also optional, due to the error correction in the physical layer and the fact that no attempt is ever made to retransmit realtime frames. If no retransmissions will be attempted, why even bother with a checksum? But if there is a checksum, it is the standard IEEE 802 CRC, and acknowledgements and retransmissions are used for reliability.

A quick rundown of the header fields of Fig. 4-33(a) follows. The EC bit tells whether the payload is encrypted. The Type field identifies the frame type, mostly telling whether packing and fragmentation are present. The CI field indicates the presence or absence of the final checksum. The EK field tells which of the encryption keys is being used (if any). The Length field gives the complete length of the frame, including the header. The Connection identifier tells which connection this frame belongs to. Finally, the Header CRC field is a checksum over the header only, using the polynomial x ^₈ + x ² + x + 1.

The 802.16 protocol has many kinds of frames. An example of a different type of frame, one that is used to request bandwidth, is shown in Fig. 4-33(b). It starts with a 1 bit instead of a 0 bit and is otherwise similar to the generic header except that the second and third bytes form a 16-bit number telling how much bandwidth is needed to carry the specified number of bytes. Bandwidth request frames do not carry a payload or full-frame CRC.

A great deal more could be said about 802.16, but this is not the place to say it. For more information, please consult the IEEE 802.16-2009 standard itself.

Frequently Asked Questions