12 Message transfer syntax
25.3313GPPProtocol specificationRadio Resource Control (RRC)Release 17TS
Transfer syntax for RRC PDUs is derived from their ASN.1 definitions by use of Packed Encoding Rules, unaligned as specified in X.691 [49], and with adapted final padding. If special encoding is used, it is indicated in the ECN module defined for each ASN.1 module. The use of special encoding is defined in [14].
The following encoding rules apply in addition to what has been specified in X.691 [49]:
– When a bit string value is placed in a bit-field as specified in 15.6 to 15.11 in [11], 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 | ISO/IEC 8824-1. 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.
12.1 Structure of encoded RRC messages
An RRC PDU, which is the bit string that is exchanged between peer entities/ across the radio interface, is the concatenation of a basic production, an extension and padding, in that order.
RRC PDUs shall be mapped to and from RLC SDUs upon transmission and reception as follows:
– 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 RLC SDU from the RLC layer, the first bit of the RLC SDU shall represent the first bit of the RRC PDU and onwards.
12.1.1 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, except for the 0 to 7 bits added at the end to produce a multiple of 8 bits. The basic production can have any positive number of bits, not necessarily a multiple of 8 bits.
12.1.2 Extension
Emitters compliant with this version of the specification of the protocol shall, unless indicated otherwise on a PDU type basis, set the extension part empty. Emitters compliant with a later version might send non-empty extensions.
12.1.3 Padding
Emitters compliant with this version of the specification of the protocol shall, unless indicated otherwise on a PDU type basis, pad the basic production with the smallest number of bits required to meet the size constraints of the lower layers. Padding bits shall be set to 0.
Receivers compliant with this version of the specification have no need to distinguish the extension and padding parts, and shall, unless indicated otherwise on a PDU type basis, accept RRC PDUs with any bit string in the extension and padding parts.
Figure 12.1.3-1: Padding
When using AM or UM mode, RLC requires that the RRC PDU length is a multiple of 8 bits.
When using Tr mode, RLC does neither impose size requirements nor perform padding. This implies that RRC has to take into account the transport format set defined for the transport channel across which the message is to be sent. RRC shall add the lowest number of padding bits required to fit the size specified for the selected transport format. In case of Enhanced Uplink in CELL_FACH state and Idle mode, when using Tr mode, RRC shall add the lowest number of padding bits to ensure octet alignment.
For paging type 1 messages, in case the PCCH is mapped on HS-DSCH, padding needs to apply only to ensure octet alignment.
For SYSTEM INFORMATION CHANGE INDICATION message, in case the BCCH is mapped on HS-DSCH, padding needs to apply only to ensure octet alignment.
For system information blocks, building the PDU involves two steps. The first step is the building of the System Information Blocks, in which step padding is not applied (the rules for extension apply). The second step is the building of the RRC PDUs, involving segmentation and concatenation of System Information Blocks, and then padding as described above for Tr mode if the BCCH carrying the System Information Blocks is mapped on BCH. The procedure is shown by means of an example as described in Figure 12.1.3-2. The example includes two System Information Blocks, SIBn and SIBn+1, of which only SIBn includes a protocol extension. The two System Information Blocks used in the example do not require segmentation and are concatenated into one SYSTEM INFORMATION message or one SYSTEM INFORMATION 2 message.
Figure 12.1.3-2: Padding for System Information
PCI: Protocol control information at SYSTEM INFORMATION message or SYSTEM INFORMATION 2 message level
SI: SYSTEM INFORMATION message or SYSTEM INFORMATION 2 message
For system information blocks, RRC may also add padding information at the end of IE "SIB data fixed", used both within IE "Last segment" and IE "Complete SIB". The IE "SIB data fixed" has a fixed length i.e. no length denominator used. In case the remaining amount of "SIB data" information is insufficient to fill the IE completely, RRC includes padding bits.
Since no length denominator is included, the receiving RRC cannot remove the padding added by the sender. However, since the padding used is the same as the padding added by the PER encoder to achieve octet alignment, the receiver can handle it.
NOTE 1 The mechanism described above implies that the PDU provided to the ASN.1 decoder may have more than 7 padding bits included. For a complete System Information Block of length 215 bits, 11 padding bits are added by RRC. Since the decoder requires an octet aligned input, 6 additional bits need to be added. In this (worst) case, a total of 17 padding bits is included.
NOTE 2 For the above cases, use of padding bits is possible and more efficient than including a length denominator.
When using the RRC padding described above, the segment has a fixed length, which completely fills the transport block. Therefore, in this case no RRC padding is added within the SYSTEM INFORMATION message or SYSTEM INFORMATION 2 message. This is illustrated by means of the following figure.
Figure 12.1.3-3: No RRC padding for System Information
12.2 ECN link module for RRC
RRC-ECN-Link-Module LINK-DEFINITIONS ::=
BEGIN
IMPORTS
RRC-encodings — Encoding objects for RRC messages
FROM RRC-Encoding-Definitions;
ENCODE Class-definitions
WITH RRC-encodings
COMPLETED BY PER-BASIC-UNALIGNED
ENCODE PDU-definitions
WITH RRC-encodings
COMPLETED BY PER-BASIC-UNALIGNED
ENCODE InformationElements
WITH RRC-encodings
COMPLETED BY PER-BASIC-UNALIGNED
ENCODE Internode-definitions
WITH RRC-encodings
COMPLETED BY PER-BASIC-UNALIGNED
END
12.3 ECN modules for RRC
The encoding definition module "RRC-Encoding-Definitions" contains definition of the encoding object set "RRC‑encodings". The encoding object set contains all the specialized encoding for RRC.
RRC-Encoding-Definitions ENCODING-DEFINITIONS ::=
BEGIN
EXPORTS
RRC-encodings;
RRC-encodings #ENCODINGS ::= {
— Trailing bits
outer-encoding
}
–**************************************************************
—
— The trailing bits in all RRC messages shall be ignored
— (including unknown message contents & unknown extensions).
— This overrides the default PER behaviour which pads the last
— octet with zero bits.
—
–**************************************************************
outer-encoding #OUTER ::= {
ENCODER-DECODER {
}
DECODE AS IF {
POST-PADDING encoder-option
}
}
END
Class-definitions-ECN-Module ENCODING-DEFINITIONS ::=
BEGIN
END
PDU-definitions-ECN-Module ENCODING-DEFINITIONS ::=
BEGIN
END
InformationElements-ECN-Module ENCODING-DEFINITIONS ::=
BEGIN
END
Internode-definitions-ECN-Module ENCODING-DEFINITIONS ::=
BEGIN
END
12.4 RRC messages encoded otherwise
NOTE: The messages included in this section are not specified by means of ASN.1.
12.4.1 Messages using tabular encoding specification
The encoding of the message is specified by means of a table listing the information elements known in the message and their order of their appearance in the message.
When a field extends over more than one octet, the order of bit values progressively decreases as the octet number increases. The least significant bit of the field is represented by the lowest numbered bit of the highest numbered octet of the field.
12.4.1.1 TRANSPORT FORMAT COMBINATION CONTROL using transparent DCCH
12.4.1.1.1 TRANSPORT FORMAT COMBINATION CONTROL, 3 bit format
The 3 bit format is as follows:
|
3 |
2 |
1 |
Transport Format Combination Set Identity value |
|
0 |
0 |
0 |
0 |
|
0 |
0 |
1 |
1 |
|
0 |
1 |
0 |
2 |
|
1 |
1 |
1 |
7 |