7.5 Payload Header Suppression (PHS)

7.5 Payload Header Suppression (PHS)

The packets delivered to OSI model layer 2 may have very large headers, sometimes as long as 120 bytes. This is the case for some RTP/UDP/IPv6 packets (RTP, Real-Time Protocol, UDP, User Datagram Protocol). This is very often repetitive (redundant) information and so should not be transmitted on a scarce resource such as a radio channel, which should be used for useful information. This process is known as header compression and decompression in 3G-cellular systems ^[13]. In the 802.16 standard, the PHS process suppresses repetitive (redundant) parts of the payload header in the MAC SDU of the higher layer. The receiving entity restores the suppressed parts. Implementation of the PHS capability is optional.

Figure 7.7 shows the PHS mechanism at the sending entity. Suppression of parts of the header leads to a compressed header. The receiver has to restore the header before properly using the received packet (Figure 7.8).

Figure 7.7: Header suppression at the sending entity. Suppression of parts of the header leads to a compressed header. This allows the economy of a precious radio resource that would have been used for redundant information

Figure 7.8: Header suppression mechanism at the receiving entity. The receiver has to restore the header before properly using the received packet

To indicate whether the PHS is present or not, the PHS support field is used. This parameter indicates the level of PHS support. The PHS support field is a field in some MAC management messages, Registration Request and Registration Response, which will be seen later in Section 11.6.1. Table 7.2 shows the possible values of the PHS support field. The default value is 0 (no PHS).

Table 7.2: Possible values of the PHS support field
Open table as spreadsheet

Value	Description
0	No PHS support
1	ATM PHS
2	Packet PHS
3	ATM and Packet PHS

In the case of the ATM CS and in addition to the registration message, there is another possibility to indicate the PHS. In the DSA MAC management message, a field can implicitly signal the use of the PHS.

7.5.1 PHS Rules

PHS rules application and signalling are different for the two defined CS specifications: ATM CS and packet CS.

The ATM standard defines two modes: the VP-switched mode (Virtual Path) and the VC-switched mode (Virtual Channel). The same PHS operation is applied for the two modes; the only difference between them is the payload header size after suppression. When the PHS is turned off, no part of any ATM cell header including the Header Error Check (HEC) field is suppressed.

In the Packet CS mode, if the PHS is enabled at the MAC connection, each MAC SDU starts with a Payload Header Suppression Index (PHSI), an 8-bit field that references which Payload Header Suppression Field (PHSF) to suppress. Once a PHSF has been assigned to a PHSI, it cannot be changed. To change the value of a PHSF on a service flow, a new PHS rule must be defined. Figure 7.9 shows the operation of the PHS in a Packet CS.

Figure 7.9: Illustration of PHS operation. In the Packet CS mode and for each MAC SDU, the PHSI (Payload Header Suppression Index) references the suppressed PHSF (Payload Header Suppression Field)

It is the responsibility of the higher-layer service entity to generate a PHS rule that uniquely identifies the suppressed header within the service flow. It is also the responsibility of the higher-layer service entity to guarantee that the byte strings that are being suppressed are constant from packet to packet for the duration of the active service flow.

As already mentioned, the sending entity uses the classifier to map packets into a service flow. The classifier uniquely maps packets to the PHS rule associated with this service flow. The receiving entity uses the CID and the PHSI to restore the PHSF.

The PHS has a Payload Header Suppression Valid (PHSV) option to verify the payload header before suppressing it. It also has a Payload Header Suppression Mask (PHSM) option to allow the choice of bytes that cannot be suppressed.

The PHS rule provides PHSF, PHSI, PHSM, PHSS (Payload Header Suppression Size) and PHSV.

7.5.2 PHS Rules Signalling

PHS rules are created with DSA or Dynamic Service Change (DSC) MAC management messages. The BS defines the PHSI when the PHS rule is created. PHS rules are deleted with the DSC or Dynamic Service Deletion (DSD) MAC management messages. When a classifier is deleted, any associated PHS rule is also deleted.

Figure 7.10 shows the use of a DSC message to signal the creation of a PHS rule and whether this rule is initiated by the BS or the SS. In this figure, the use of the following DSC MAC management messages are introduced:

• DSC-REQ. A DSC-REQ is sent by an SS or BS to dynamically change the parameters of an existing service flow. It can be used to create PHS rules.

• DSC-RSP. A DSC-RSP is generated in response to a received DSC-REQ.

• DSC-ACK. A DSC-ACK is generated in response to a received DSC-RSP.

Figure 7.10: DSC MAC management message used for the signalling of a PHS rule. (From IEEE Std 802.16-2004 ^[1]. Copyright IEEE 2004, IEEE. All rights reserved.)

The main DSC message parameters are SFID (only for DSC-RSP and DSC-ACK), CID. service class name, CS specification, etc. (see Chapter 11 for dynamic Service management).

7.5.3 Header Compression in WiMAX

The PHS is a header suppression mechanism. There are also header compression algorithms that compress packet headers by other means than repetitive header suppression. The 802.16e amendment mentions that the Convergence Sublayer (CS) supports SDUs in two formats that facilitate robust compression of IP and higher-layer headers. These formats (corresponding to header compression algorithms) are:

• ROHC (RObust Header Compression), IETF RFC 3095 ^[14]. ROHC is also used in 3G UMTS cellular systems for header compression.

• ECRTP (Enhanced Compressed Real-Time Protocol) or Enhanced Compressed, RFC 3545 ^[15]. ECRTP is an evolution of CRTP, Compressed RTP, RFC 2508, defined for low data rate fixed line IP/UDP/RTP packet headers.

These two CS PDU formats defined in 802.16e are referred to as the IPheader-compression CS PDU format.

Compressed-IP-Header classifiers operate on the context fields of the ROHC and ECRTP compressed packets. 802.16e provides the service flow encodings that should be included in the CS packets for ROHC and ECRTP. 802.16e indicates that the compression function must not operate on the IEEE 802.3/Ethernet frame header so that the Ethernet frame header remains intact.

^[13]Holma, H. and Toksala, A., WCDMA for UMTS, 3rd edn, John Wiley & Sons, Ltd, 2004.

^[14]IETF RFC 3095, RObust Header Compression (ROHC): Framework and Four Profiles: RTP, UDP, ESP, and Uncompressed, C. Bormann et al., July 2001.

^[15]IETF RFC 3545, Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering, T. Koren et al., July 2003.