8 Protocol data unit abstract syntax

38.3313GPPNRProtocol specificationRadio Resource Control (RRC)Release 17TS

8.1 General

The RRC PDU contents in clause 6 and clause 10 are described using abstract syntax notation one (ASN.1) as specified in ITU-T Rec. X.680 [6] and X.681 [7]. Transfer syntax for RRC PDUs is derived from their ASN.1 definitions by use of Packed Encoding Rules, unaligned as specified in ITU-T Rec. X.691 [8].

The following encoding rules apply in addition to what has been specified in X.691:

– When a bit string value is placed in a bit-field as specified in 15.6 to 15.11 in X.691, the leading bit of the bit string value shall be placed in the leading bit of the bit-field, and the trailing bit of the bit string value shall be placed in the trailing bit of the bit-field;

NOTE: The terms ‘leading bit’ and ‘trailing bit’ are defined in ITU-T Rec. X.680. When using the ‘bstring’ notation, the leading bit of the bit string value is on the left, and the trailing bit of the bit string value is on the right.

– When decoding types constrained with the ASN.1 Contents Constraint ("CONTAINING"), automatic decoding of the contained type should not be performed because errors in the decoding of the contained type should not cause the decoding of the entire RRC message PDU to fail. It is recommended that the decoder first decodes the outer PDU type that contains the OCTET STRING or BIT STRING with the Contents Constraint, and then decodes the contained type that is nested within the OCTET STRING or BIT STRING as a separate step;

– When decoding a) RRC message PDUs, b) BIT STRING constrained with a Contents Constraint, or c) OCTET STRING constrained with a Contents Constraint, PER decoders are required to never report an error if there are extraneous zero or non-zero bits at the end of the encoded RRC message PDU, BIT STRING or OCTET STRING.

8.2 Structure of encoded RRC messages

An RRC PDU, which is the bit string that is exchanged between peer entities/across the radio interface contains the basic production as defined in X.691.

RRC PDUs shall be mapped to and from PDCP SDUs (in case of DCCH) or RLC SDUs (in case of PCCH, BCCH or CCCH) upon transmission and reception as follows:

– when delivering an RRC PDU as an PDCP SDU to the PDCP layer for transmission, the first bit of the RRC PDU shall be represented as the first bit in the PDCP SDU and onwards; and

– when delivering an RRC PDU as an RLC SDU to the RLC layer for transmission, the first bit of the RRC PDU shall be represented as the first bit in the RLC SDU and onwards; and

– upon reception of an PDCP SDU from the PDCP layer, the first bit of the PDCP SDU shall represent the first bit of the RRC PDU and onwards; and

– upon reception of an RLC SDU from the RLC layer, the first bit of the RLC SDU shall represent the first bit of the RRC PDU and onwards.

8.3 Basic production

The ‘basic production’ is obtained by applying UNALIGNED PER to the abstract syntax value (the ASN.1 description) as specified in X.691. It always contains a multiple of 8 bits.

8.4 Extension

The following rules apply with respect to the use of protocol extensions:

– A transmitter compliant with this version of the specification shall, unless explicitly indicated otherwise on a PDU type basis, set the extension part empty. Transmitters compliant with a later version may send non-empty extensions;

– A transmitter compliant with this version of the specification shall set spare bits to zero.

8.5 Padding

If the encoded RRC message does not fill a transport block, the RRC layer shall add padding bits. This applies to PCCH and BCCH.

Padding bits shall be set to 0 and the number of padding bits is a multiple of 8.

Figure 8.5-1: RRC level padding