ayer service entity to guarantee that the byte strings that are being sup- pressed are constant from packet to packet for the duration of the active service flow. The operation of the PHS is illustrated in Figure 5-6. The format of the IP CS PDU is shown in Figure 5-7 for two cases: (1) when header suppression is enabled at the connection, but not applied to the CS PDU; or (2) with header suppression. In the case where PHS is not enabled, the PHSI field is omitted. The ROHC may be used instead of PHS to compress the IP headers. The MS and the BS signal the enabling and support of ROHC protocol by setting the seventh bit of Request/Transmission Policy parameter to zero (the value of this parameter would allow specification of certain attributes for the associated service flow). When ROHC is enabled for a service flow, the service flow constitutes that which in IETF RFC 3095 is referred to as a ROHC channel. Feedback sent on an ROHC channel consists of one or more concatenated feedback elements. When an ROHC compressor has transformed original packets into ROHC packets with compressed headers (see Figure 5-3), these ROHC packets are sent to the corresponding decompressor through a logical point-to-point connection dedicated to that traffic. Such a logical channel, which only has to carry data in this single direction from compressor to decompressor, is referred to as an ROHC channel. An ROHC compressor instance is a logical entity that performs header compression according to one or several ROHC profiles. There is a one-to-one CHAPTER 5 The IEEE 802.16m Convergence Sub-Layer Packet Arrives from PDU Arrives from MAC Upper Layer Classify Packet Retrieve PHSF, PHSI, PHSM, Identify CID (STID+FID) Extract PHSI PHSS, PHSV Retrieve PHSF, PHSM, Verify the Payload Header Before Suppression? Reconstruct Header Verify with PHSF together with PHSM Present Packet to CS Suppress with PHSM Set PHSI to 0 Set PHSI to Index Append PHSI to CS Send Packet to MAC FIGURE 5-6 Packet CS payload header suppression flow graph [1] PHSI=0 IP 