10.1 General
25.3313GPPProtocol specificationRadio Resource Control (RRC)Release 17TS
The function of each Radio Resource Control message together with message contents in the form of a list of information elements is defined in subclause 10.2.
Functional definitions of the information elements are then described in subclause 10.3.
Information elements are marked as either MP – Mandatory present, MD – Mandatory with default value, OP – Optional, CV – Conditional on value or CH – Conditional on history (see Table 10.1 with information extracted from [14]).
Table 10.1: Meaning of abbreviations used in RRC messages and information elements
|
Abbreviation |
Meaning |
|---|---|
|
MP |
Mandatory present A value for that information is always needed, and no information is provided about a particular default value. If ever the transfer syntax allows absence (e.g., due to extension), then absence leads to an error diagnosis. |
|
MD |
Mandatory with default value A value for that information is always needed, and a particular default value is mentioned (in the ‘Semantical information’ column). This opens the possibility for the transfer syntax to use absence or a special pattern to encode the default value. |
|
CV |
Conditional on value The need for a value for that information depends on the value of some other IE or IEs, and/or on the message flow (e.g., channel, SAP). The need is specified by means of a condition, the result of which may be that the information is mandatory present, mandatory with default value, not needed or optional. If one of the results of the condition is that the information is mandatory present, the transfer syntax must allow for the presence of the information. If in this case the information is absent an error is diagnosed. If one of the results of the condition is that the information is mandatory with default value, and a particular default value is mentioned (in the ‘Semantical information’ column), the transfer syntax may use absence or a special pattern to encode the default value. If one of the results of the condition is that the information is not needed, the transfer syntax must allow encoding the absence. If in this case the information is present, it will be ignored. In specific cases however, an error may be diagnosed instead. If one of the results of the condition is that the information is optional, the transfer syntax must allow for the presence of the information. In this case, neither absence nor presence of the information leads to an error diagnosis. |
|
CH |
Conditional on history The need for a value for that information depends on information obtained in the past (e.g., from messages received in the past from the peer). The need is specified by means of a condition, the result of which may be that the information is mandatory present, mandatory with default value, not needed or optional. The handling of the conditions is the same as described for CV. |
|
OP |
Optional The presence or absence is significant and modifies the behaviour of the receiver. However whether the information is present or not does not lead to an error diagnosis. |
10.1.1 Protocol extensions
RRC messages may be extended in future versions of this protocol, either by adding values for choices, enumerated and size constrained types or by adding information elements. An important aspect concerns the behaviour of a UE, conforming to this revision of the standard, upon receiving a not comprehended future extension. The details of this error handling behaviour are provided in clause 9.
NOTE 1: By avoiding the need for partial decoding (skipping uncomprehended IEs to continue decoding the remainder of the message), the RRC protocol extension mechanism also avoids the overhead of length determinants for extensions. "Variable length extension containers" (i.e. non critical extension containers that have their abstract syntax defined using the ASN.1 type "BIT STRING") have been defined to support the introduction of extensions to a release after the subsequent release is frozen (and UEs based on that subsequent release may appear). For this container a length determinant is used, which facilitates partial decoding of the container as well as the decoding of the extensions included after the container.
Two kinds of protocol extensions are distinguished: non-critical and critical extensions. In general, a receiver shall process a message including not comprehended non-critical extensions as if the extensions were absent. However, a receiver shall entirely reject a message including not comprehended critical extensions (there is no partial rejection) and notify the sender, as specified in clause 9.
The general mechanism for adding critical extensions is by defining a new version of the message, which is indicated at the beginning of the message.
The UE shall always comprehend the complete transfer syntax specified for the protocol version it supports; if the UE comprehends the transfer syntax defined within protocol version A for message 1, it shall also comprehend the transfer syntax defined within protocol version A for message 2.
The following table shows for which messages only non-critical extensions may be added, for which messages both critical and non-critical extensions may be added and for which messages neither critical nor non-critical extensions may be added.
NOTE 2: Critical extensions can only be added to certain downlink messages.
|
Extensions |
Message |
|---|---|
|
Critical and non-critical extensions |
ACTIVE SET UPDATE 10.2.1 ASSISTANCE DATA DELIVERY 10.2.4 CELL CHANGE ORDER FROM UTRAN 10.2.5 CELL UPDATE CONFIRM 10.2.8 COUNTER CHECK 10.2.9 DOWNLINK DIRECT TRANSFER 10.2.11 HANDOVER TO UTRAN COMMAND 10.2.16a HANDOVER FROM UTRAN COMMAND 10.2.15 LOGGING MEASUREMENT CONFIGURATION 10.2.16da MEASUREMENT CONTROL 10.2.17 PHYSICAL CHANNEL RECONFIGURATION 10.2.22 PHYSICAL SHARED CHANNEL ALLOCATION 10.2.25 RADIO BEARER RECONFIGURATION 10.2.27 RADIO BEARER RELEASE 10.2.30 RADIO BEARER SETUP 10.2.33 RRC CONNECTION REJECT 10.2.36 RRC CONNECTION RELEASE 10.2.37 RRC CONNECTION SETUP 10.2.40 SECURITY MODE COMMAND 10.2.43 SIGNALLING CONNECTION RELEASE 10.2.46 TRANSPORT CHANNEL RECONFIGURATION 10.2.50 UE CAPABILITY ENQUIRY 10.2.55 UE CAPABILITY INFORMATION CONFIRM 10.2.57 UE INFORMATION REQUEST 10.2.57a UPLINK PHYSICAL CHANNEL CONTROL 10.2.59 URA UPDATE CONFIRM 10.2.61 UTRAN MOBILITY INFORMATION 10.2.62 |
|
Non-critical extensions only |
ACTIVE SET UPDATE COMPLETE 10.2.2 ACTIVE SET UPDATE FAILURE 10.2.3 CELL CHANGE ORDER FROM UTRAN FAILURE 10.2.6 CELL UPDATE 10.2.7 COUNTER CHECK RESPONSE 10.2.10 ETWS PRIMARY NOTIFICATION WITH SECURITY 10.2.12a HANDOVER TO UTRAN COMPLETE 10.2.16b INITIAL DIRECT TRANSFER 10.2.16c HANDOVER FROM UTRAN FAILURE 10.2.16 MBMS Access Information 10.2.16e MBMS Common p-t-m rb Information 10.2.16f MBMS Current Cell p-t-m rb Information 10.2.16g MBMS General Information 10.2.16h MBMS Modification request 10.2.16i MBMS Modified services Information 10.2.16j MBMS Neighbouring Cell p-t-m rb Information 10.2.16k MBMS Scheduling Information 10.2.16L MBMS Unmodified services Information 10.2.16m MEASUREMENT CONTROL FAILURE 10.2.18 MEASUREMENT REPORT 10.2.19 PAGING TYPE 1 10.2.20 PAGING TYPE 2 10.2.21 PHYSICAL CHANNEL RECONFIGURATION COMPLETE 10.2.23 PHYSICAL CHANNEL RECONFIGURATION FAILURE 10.2.24 PUSCH CAPACITY REQUEST 10.2.26 RADIO BEARER RECONFIGURATION COMPLETE 10.2.28 RADIO BEARER RECONFIGURATION FAILURE 10.2.29 RADIO BEARER RELEASE COMPLETE 10.2.31 RADIO BEARER RELEASE FAILURE 10.2.32 RADIO BEARER SETUP COMPLETE 10.2.34 RADIO BEARER SETUP FAILURE 10.2.35 RRC CONNECTION RELEASE COMPLETE 10.2.38 RRC CONNECTION REQUEST 10.2.39 RRC CONNECTION SETUP COMPLETE 10.2.41 RRC STATUS 10.2.42 SECURITY MODE COMPLETE 10.2.44 SECURITY MODE FAILURE 10.2.45 SIGNALLING CONNECTION RELEASE INDICATION 10.2.47 Master Information Block 10.2.48.8.1 System Information Block type 1 to System Information Block type 25 10.2.48.8.4 to 10.2.48.8.28 SYSTEM INFORMATION CHANGE INDICATION 10.2.49 TRANSPORT CHANNEL RECONFIGURATION COMPLETE 10.2.51 TRANSPORT CHANNEL RECONFIGURATION FAILURE 10.2.52 TRANSPORT FORMAT COMBINATION CONTROL 10.2.53 TRANSPORT FORMAT COMBINATION CONTROL FAILURE 10.2.54 UE CAPABILITY INFORMATION 10.2.56 UE INFORMATION RESPONSE 10.2.57b UPLINK DIRECT TRANSFER 10.2.58 URA UPDATE 10.2.60 UTRAN MOBILITY INFORMATION CONFIRM 10.2.63 UTRAN MOBILITY INFORMATION FAILURE 10.2.64 |
|
No extensions |
CELL UPDATE FDD 10.2.7a SYSTEM INFORMATION 10.2.48 SYSTEM INFORMATION 2 10.2.48b First Segment 10.2.48.1 First Segment 2 10.2.48.1a Subsequent or last Segment 10.2.48.3 Subsequent Segment 2 10.2.48.3a or last Segment 2 10.2.48.4a Complete SIB 10.2.48.6 Complete SIB 2 10.2.48.6a |
NOTE 3: For the SYSTEM INFORMATION message protocol extensions are only possible at the level of system information blocks.
10.1.1.1 Non-critical extensions
10.1.1.1.1 Extension of an information element with additional values or choices
In future versions of this protocol, non-critical values may be added to choices, enumerated and size constrained types.
For choices, enumerated and size constrained types it is possible to indicate how many non-critical spare values need to be reserved for future extension. In this case, the tabular format should indicate the number of spare values that are needed. The value range defined in ASN.1 for the extensible IE should include the number of spares that are needed, since a value outside the range defined for this IE will result in a general ASN.1 violation error.
For downlink messages, spare values may be defined for non-critical information elements for which the need is specified to be MD or OP (or CV case leading to MD or OP). In this case, a receiver not comprehending the received spare value shall consider the information element to have the default value or consider it to be absent respectively.
For uplink messages spare values may be defined for all information elements, including those for which the need is specified to be MP (or CV case leading to MP).
In all cases at most one spare should be defined for choices. In this case, information elements applicable to the spare choices shall be added to the end of the message.
10.1.1.1.2 Extension of a message with additional information elements
In future versions of this protocol, non-critical information elements may be added to RRC messages. These additional information elements shall be normally appended at the end of the message; the transfer syntax specified in this revision of the standard facilitates this. A receiver conformant to this revision of the standard shall accept such extension, and proceed as if it was not included.
A transmitter conformant to this version of the standard shall not include an extension reserved for introducing non critical extensions in later versions of the standard; i.e. the corresponding parameter defined in the ASN.1 shall be absent.
NOTE: If an extension, reserved for future non-critical extensions, is included (even if it is empty), this may result in transfer syntax errors when received by an implementation conforming to a later version of the standard.
Extensions to a release that are introduced after the subsequent release is frozen may however be inserted prior to the end of the message. To facilitate this, "variable length extension containers" have been introduced in most messages.
10.1.1.2 Critical extensions
10.1.1.2.1 Extension of an information element with additional values or choices
In versions of this protocol, choices, enumerated and size constrained types may be extended with critical values. For extension with critical values the general critical extension mechanism is used, i.e. for this no spare values are reserved since backward compatibility is not required.
10.1.1.2.2 Extension of a message with additional information elements
In future versions of this protocol, RRC messages may be extended with new information elements. Since messages including critical extensions are rejected by receivers not comprehending them, these messages may be modified completely, e.g. IEs may be inserted at any place and IEs may be removed or redefined.