Mobile Communications Systems Development. Rajib Taid. Читать онлайн. Newlib. NEWLIB.NET

Автор: Rajib Taid
Издательство: John Wiley & Sons Limited
Серия:
Жанр произведения: Техническая литература
Год издания: 0
isbn: 9781119778707
Скачать книгу
shown below:

      <Message>:: = 11 { 1 < IE1 : bit(3)> | 0 <IE2: bit(3)> }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.

      4.1.5 ASN.1 Encoding/Decoding: UMTS, LTE, and 5G NR Layer 3 Protocol

      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:

      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].

       How Does ASN.1 Notation Result in a Compact Encoding

      It was described in Section 4.1.1 that the air interface Layer 3 messages are encoded and decoded on the octet (8 bits) level in TLV format. Depending on the IE type, it may be required to encode the type/IEI (T), length (L), and value (V) of an IE in a message. The overall length of the encoded message becomes larger. However, in the ASN.1 method,

       The type/IEI is never encoded and transmitted, and

       Encoding the length and value is also optional if both sender and receiver already know it.

      Because of these encoding rules, the size of the encoded message becomes compact in comparison to the TLV method encoding described above.

      From Figure 4.7, it is observed that the PER encoding method results only in 3 bits of the IE's value to be transmitted, in comparison to 24 bits in its TLV encoding format. This is because in the PER method, the Type is never used, and Length may not be used during encoding of an IE.

      4.1.6 Direct/Indirect Encoding Method

      The encoding and decoding methods of mobile communications systems and network messages as mentioned in the preceding sections apply, in general, to all the messages defined in a particular mobile communications system such as the GSM, GPRS, UMTS, LTE and 5G NR systems. There could be other encoding and decoding methods that are applicable to a particular message defined only in a particular mobile communications domain. Two such methods are Direct Encoding and Indirect Encoding. They are used in GSM Layer 3 Radio Resource Management layer's Immediate Assignment message while allocating a list of hopping radio frequencies from the BSC to the Mobile station.

Schematic illustration of TLV and PER encoding method.

      

      The LTE RRCConnectionRequest or the 5G NR RRCSetupRequest message is used by a UE toward the LTE eNodeB or 5G NG‐RAN to request the establishment of an RRC signaling connection. For the ASN.1 definition of the LTE RRCConnectionRequest or NR RRCSetupRequest message, refer to TS 36.331 [94] and TS 38.331 [116]. The RRCConnectionRequest or RRCSetupRequest message carries the following information to the eNodeB:

       Initial UE identity,

       Establishment cause/purpose of the connection request, e.g. emergency call, data, signaling, voice call, and so on, and

       A randomly generated reference value.

      4.1.7 Segmented Messages over the Air Interface

      It