Rajib Taid - Mobile Communications Systems Development

Figure 4.6 Illustration: encoding and transmission of air interface message.

The LTE and 5G NR air interface RLC layers provide the capability to exchange information between a UE and the LTE E‐UTRAN or between a UE and the 5G NG‐RAN in terms of the PDU. An RLC layer PDU facilitates transfer of higher‐layer data in Transparent (TM), Unacknowledged (UNACK) or Acknowledged (ACK) mode. A PDU consists of a header part that is further followed by the data part of the PDU.

PDU Description

An RLC PDU, ACK, and UNACK mode header consist of several fields with different lengths in bits. Thus, the encoding and decoding of each field are different. Nevertheless, the protocol header and the data part of RLC PDU are octet aligned and is described in a tabular format. The TM PDU of the RLC layer does not contain the header part and is used to transfer messages such as paging and system information messages. Neither the sending RLC nor the receiving RLC layer performs any operations on a TM PDU. There is another PDU called Control PDU, which is used by the receiving RLC layer to inform the sending RLC layer on the status, i.e. lost or successfully decoded, of a PDU being received.

Encoding of RLC PDU

Though the RLC PDU is described in a tabular format, the header and data part is encoded as bit strings where the leftmost bit of the first line of the table is considered as the most significant bit and the rightmost bit of the last line of the table is considered as the least significant bit. Depending on the length of Sequence Number ( SN ) used in an RLC header, the length of the RLC header may take 1 or 2 octets at the beginning of the table and is different for the ACK mode and UNACK mode of data transfers. The 5G NR air interface RLC layer and its PDU formats are described later in Chapter 19. For more information on the RLC layer protocol header, its different parameters, and their encoding requirements, refer to TS 38.322 [114] for 5G NR.

The LTE and 5G NR MAC layer facilitates the exchange of air interface Layer 2 information in terms of a PDU between a UE and LTE E‐UTRAN or between UE and 5G NG‐RAN. A MAC PDU consists of a MAC header and MAC SDU, which is received from the RLC layer. The method of description and encoding of the MAC layer PDU is similar to the method used by the LTE and NR RLC layers as described above. Similar to the RLC layer, the encoded bit strings of LTE or 5G NR MAC layer is an octet (8 bits) aligned.

Also, note that unlike the air interface Layer 3 message header, the MAC header and the MAC SDU are variable in size. For more information on the MAC layer protocol header, its different parameters, and their encoding requirements, refer to TS 36.321 [93] for LTE and TS 38.321 [113] for 5G NR. NR air interface MAC layer and its PDU formats are described later in Chapter 19.

The CSN.1 [10] notation method for describing, encoding, and decoding of air interface Layer 2 signaling messages are used by the GPRS RLC/MAC layer. It was described in Section 4.1.1that the air interface Layer 3 messages are encoded and decoded on the octet (8 bits) level in TLV format. However, using the CSN.1 notation, only the value, and not type or length, of the IEs of a signaling message are encoded and decoded on a bit level. This results in a compact bits stream for transmission over the GPRS air interface. A CSN.1 encoded signaling message contains a bits string having an ordered sequence of symbols, i.e. 0 and 1. The resulting bits string may not be multiple of 8, i.e. an octet. An example CSN.1 description of a message with two IEs of length 3 bits each is shown below:

:: = 11 { 1 < IE1 : bit(3)> | 0 }11

In the above CSN.1 description of the sample message, the vertical bar “|” represents a choice. If the third bit of the message is 1, then IE1 shall be encoded; if the third bit is 0, then IE2 shall be encoded. Both the IEs are illustrated with length = 3 bits. This is further followed by 11 bits, giving an overall bits stream of 8 bits.

The CSN.1 method is based on the Backus‐Naur Form ( BNF ) that contains various rules to be followed while describing a message. For more information on such rules of encoding and decoding of RLC/MAC layer signaling message using the CSN.1 method and its other aspects, refer to Annex‐B, TS 24.007 [44]. Example messages and their descriptions/structures using CSN.1 notation can be found in 3GPP TS 44.060 [131].

Reusable software modules/functions/procedures are required to be developed for CSN.1 encoding, at the sender end, and decoding, at the receiving end, of GPRS RLC/MAC signaling message. More about the implementation of encoding and decoding in the code is described in later sections.

The UMTS, LTE, and 5G NR air interface Layer 3 RRC protocol layer PDUs are described using the ASN.1 notation. Apart from these, the LTE/EPS S1‐AP, X2‐AP, 5G Core NG‐AP, Xn‐AP, and UMTS Radio Access Network Application Part (RANAP) protocol PDUs are also described using the ASN.1 notation. The ASN.1 describes the syntax of a message in an abstracted way as well as the method of encoding and decoding of message over a particular logical interface, e.g. air interface. ASN.1 notation is specified in ITU‐T Rec. X.691 [11].

Message Description and Its Compilation

The abstract description of a protocol layer message using the ASN.1 method is similar to a C‐Language‐like structure having data fields and its lengths. An example of an ASN.1 definition of a protocol message is shown below:

L3ProtocolMessage:: = SEQUENCE{ Header :: =L3Header, Data :: =L3IEs, } L3Header:: =SEQUENCE{ Protocol-Discriminator::= BITS STRING (SIZE(4)), Skip-Indicator::= BITS STRING (SIZE(4)), } L3IEs ::= OCTET STRING(SIZE(255))

Consider that the C‐Language is being used to develop the concerned protocol layer containing the above protocol header. From the above description of the protocol message, an ASN.1 compiler may produce the target C‐Language source code/header file as illustrated below:

typedef struct { unsigned char Protocol-Discriminator:4; unsigned char Skip-Indicator:4; unsigned char L3IEs[255]; } L3ProtocolMessage

Further, the C‐Language compiler will compile the ASN.1‐generated C‐header files along with the other C‐source files to produce an encoding/decoding module.

Encoding/Decoding Method

An ASN.1 description provides only the syntax of a message to be exchanged between two network elements. It does not define the actual method to be used for encoding and transfer of the concerned message. For encoding/decoding a signaling PDU or message and its transmission, the ASN.1 Packed Encoding Rule (PER ) is used, which is specified in ITU‐T Rec. X.691 [11]. This is also known as the Message Transfer Syntax in the ASN.1 paradigm. The encoded bits stream generated by the ASN.1 PER can be of two types as mentioned below:

Octet Unaligned, e.g. RRC layer protocol PDUs.

Octet Aligned, e.g. UMTS RANAP messages; LTE/EPS S1‐AP and X2‐AP; 5G NG‐AP; and Xn‐AP messages.

For more information on the aligned and unlighted encoding PER, refer to ITU‐T Rec. X.691 [11]. There are additional protocol layer‐specific encoding rules that are to be followed during the development of the concerned protocol layer. For more information on these additional rules, refer to TS 25.331 [50], TS 36.331 [94], and TS 38.331 [116].