The procedural specification provides an overall high level description regarding the UE behaviour in a particular scenario.
It should be noted that most of the UE behaviour associated with the reception of a particular field is covered by the applicable parts of the PDU specification. The procedural specification may also include specific details of the UE behaviour upon reception of a field, but typically this should be done only for cases that are not easy to capture in the PDU clause e.g. general actions, more complicated actions depending on the value of multiple fields.
Likewise, the procedural specification need not specify the UE requirements regarding the setting of fields within the messages that are sent to the network i.e. this may also be covered by the PDU specification.
The RRC PDU contents are formally and completely described using abstract syntax notation (ASN.1), see X.680 , X.681 .
The complete ASN.1 code is divided into a number of ASN.1 clauses in the specifications. In order to facilitate the extraction of the complete ASN.1 code from the specification, each ASN.1 clause begins with the following:
a first text paragraph consisting entirely of an ASN.1 start tag, which consists of a double hyphen followed by a single space and the text string "ASN1START" (in all upper case letters);
a second text paragraph consisting entirely of a block start tag is included, which consists of a double hyphen followed by a single space and the text string "TAG-NAME-START" (in all upper case letters), where the "NAME" refers to the main name of the paragraph (in all upper-case letters).
Similarly, each ASN.1 clause ends with the following:
a first text paragraph consisting entirely of a blockstop tag, which consists of a double hyphen followed by a single space and the text string "TAG-NAME-STOP" (in all upper-case letters), where the "NAME" refers to the main name of the paragraph (in all upper-case letters);
a second text paragraph consisting entirely of an ASN.1 stop tag, which consists of a double hyphen followed by a singlespace and the text "ASN1STOP" (in all upper case letters).
This results in the following tags:
The text paragraphs containing either of the start and stop tags should not contain any ASN.1 code significant for the complete description of the RRC PDU contents. The complete ASN.1 code may be extracted by copying all the text paragraphs between an ASN.1 start tag and the following ASN.1 stop tag in the order they appear, throughout the specification.
The naming of identifiers (i.e., the ASN.1 field and type identifiers) should be based on the following guidelines:
Message (PDU) identifiers should be ordinary mixed case without hyphenation. These identifiers, e.g., the RRCConnectionModificationCommand, should be used for reference in the procedure text. Abbreviations should be avoided in these identifiers and abbreviated forms of these identifiers should not be used.
Type identifiers other than PDU identifiers should be ordinary mixed case, with hyphenation used to set off acronyms only where an adjacent letter is a capital, e.g., EstablishmentCause, SelectedPLMN (not Selected-PLMN, since the "d" in "Selected" is lowercase), InitialUE-Identity and MeasSFN-SFN-TimeDifference.
Field identifiers shall start with a lowercase letter and use mixed case thereafter, e.g., establishmentCause. If a field identifier begins with an acronym (which would normally be in upper case), the entire acronym is lowercase (plmn-Identity, not pLMN-Identity). The acronym is set off with a hyphen (ue-Identity, not ueIdentity), in order to facilitate a consistent search pattern with corresponding type identifiers.
Identifiers should convey the meaning of the identifier and should avoid adding unnecessary postfixes (e.g. abstractions like 'Info') for the name.
Identifiers that are likely to be keywords of some language, especially widely used languages, such as C++ or Java, should be avoided to the extent possible.
Identifiers, other than PDU identifiers, longer than 25 characters should be avoided where possible. It is recommended to use abbreviations, which should be done in a consistent manner i.e. use 'Meas' instead of 'Measurement' for all occurrences. Examples of typical abbreviations are given in Table A.22.214.171.124-1 below.
For future extension: When an extension is introduced a suffix is added to the identifier of the concerned ASN.1 field and/or type. A suffix of the form "-rX" is used, with X indicating the release, for ASN.1 fields or types introduced in a later release (i.e. a release later than the original/first release of the protocol) as well as for ASN.1 fields or types for which a revision is introduced in a later release replacing a previous version, e.g., Foo-r9 for the Rel-9 version of the ASN.1 type Foo. A suffix of the form "-rXb" is used for the first revision of a field that it appears in the same release (X) as the original version of the field, "-rXc" for a second intra-release revision and so on. A suffix of the form "-vXYZ" is used for ASN.1 fields or types that only are an extension of a corresponding earlier field or type (see clause A.4), e.g., AnElement-v10b0 for the extension of the ASN.1 type AnElement introduced in version 10.11.0 of the specification. A number 0...9, 10, 11, etc. is used to represent the first part of the version number, indicating the release of the protocol. Lower case letters a, b, c, etc. are used to represent the second (and third) part of the version number if they are greater than 9. In the procedural specification, in field descriptions as well as in headings suffices are not used, unless there is a clear need to distinguish the extension from the original field.
More generally, in case there is a need to distinguish different variants of an ASN.1 field or IE, a suffix should be added at the end of the identifiers e.g. MeasObjectUTRA, ConfigCommon. When there is no particular need to distinguish the fields (e.g. because the field is included in different IEs), a common field identifier name may be used. This may be attractive e.g. in case the procedural specification is the same for the different variants.
It should be avoided to use field identifiers with the same name within the elements of a CHOICE, including using a CHOICE inside a SEQUENCE (to avoid certain compiler errors).
A text reference into the RRC PDU contents description from other parts of the specification is made using the ASN.1 field identifier of the referenced type. The ASN.1 field and type identifiers used in text references should be in the italic font style. The "do not check spelling and grammar" attribute in Word should be set. Quotation marks (i.e., "") should not be used around the ASN.1 field or type identifier.
A reference to an RRC PDU should be made using the corresponding ASN.1 field identifier followed by the word "message", e.g., a reference to the RRCRelease message.
A reference to a specific part of an RRC PDU, or to a specific part of any other ASN.1 type, should be made using the corresponding ASN.1 field identifier followed by the word "field", e.g., a reference to the prioritisedBitRate field in the example below.
A reference to a specific type of information element should be made using the corresponding ASN.1 type identifier preceded by the acronym "IE", e.g., a reference to the IE LogicalChannelConfig in the example above.
References to a specific type of information element should only be used when those are generic, i.e., without regard to the particular context wherein the specific type of information element is used. If the reference is related to a particular context, e.g., an RRC PDU type (message) wherein the information element is used, the corresponding field identifier in that context should be used in the text reference.
A reference to a specific value of an ASN.1 field should be made using the corresponding ASN.1 value without using quotation marks around the ASN.1 value, e.g., 'if the status field is set to value true'.
Within each logical channel type, the associated RRC PDU (message) types are alternatives within a CHOICE, as shown in the example below.
A nested two-level CHOICE structure is used, where the alternative PDU types are alternatives within the inner level c1 CHOICE.
Spare alternatives (i.e., spare1 in this case) may be included within the c1 CHOICE to facilitate future extension. The number of such spare alternatives should not extend the total number of alternatives beyond an integer-power-of-two number of alternatives (i.e., eight in this case).
Further extension of the number of alternative PDU types is facilitated using the messageClassExtension alternative in the outer level CHOICE.
Each PDU (message) type is specified in an ASN.1 clause similar to the one shown in the example below.
Hooks for critical and non-critical extension should normally be included in the PDU type specification. How these hooks are used is further described in clause A.4.
Critical extensions are characterised by a redefinition of the PDU contents and need to be governed by a mechanism for protocol version agreement between the encoder and the decoder of the PDU, such that the encoder is prevented from sending a critically extended version of the PDU type, which is not comprehended by the decoder.
Critical extension of a PDU type is facilitated by a two-level CHOICE structure, where the alternative PDU contents are alternatives within the inner level c1 CHOICE. Spare alternatives (i.e., spare3 down to spare1 in this case) may be included within the c1 CHOICE. The number of spare alternatives to be included in the original PDU specification should be decided case by case, based on the expected rate of critical extension in the future releases of the protocol.
Further critical extension, when the spare alternatives from the original specifications are used up, is facilitated using the criticalExtensionsFuture in the outer level CHOICE.
In PDU types where critical extension is not expected in the future releases of the protocol, the inner level c1 CHOICE and the spare alternatives may be excluded, as shown in the example below.
Non-critical extensions are characterised by the addition of new information to the original specification of the PDU type. If not comprehended, a non-critical extension may be skipped by the decoder, whilst the decoder is still able to complete the decoding of the comprehended parts of the PDU contents.
Non-critical extensions at locations other than the end of the message or other than at the end of a field contained in a BIT or OCTET STRING are facilitated by use of the ASN.1 extension marker "...". The original specification of a PDU type should normally include the extension marker at the end of the sequence of information elements contained.
Non-critical extensions at the end of the message or at the end of a field that is contained in a BIT or OCTET STRING may be facilitated by use of an empty sequence that is marked OPTIONAL e.g. as shown in the following example:
The ASN.1 clause specifying the contents of a PDU type may be followed by a field description table where a further description of, e.g., the semantic properties of the fields may be included. The general format of this table is shown in the example below. The field description table is absent in case there are no fields for which further description needs to be provided e.g. because the PDU does not include any fields, or because an IE is defined for each field while there is nothing specific regarding the use of this IE that needs to be specified.
%PDU-TypeIdentifier% field descriptions
The field description table has one column. The header row shall contain the ASN.1 type identifier of the PDU type.
The following rows are used to provide field descriptions. Each row shall include a first paragraph with a field identifier (in bold and italic font style) referring to the part of the PDU to which it applies. The following paragraphs at the same row may include (in regular font style), e.g., semantic description, references to other specifications and/or specification of value units, which are relevant for the particular part of the PDU.
The parts of the PDU contents that do not require a field description shall be omitted from the field description table.
Each IE (information element) type is specified in an ASN.1 clause similar to the one shown in the example below.
IEs should be introduced whenever there are multiple fields for which the same set of values apply. IEs may also be defined for other reasons e.g. to break down a ASN.1 definition in to smaller pieces.
A group of closely related IE type definitions, like the IEs PRACH-ConfigSIB and PRACH-Config in this example, are preferably placed together in a common ASN.1 clause. The IE type identifiers should in this case have a common base, defined as the generic type identifier. It may be complemented by a suffix to distinguish the different variants. The "PRACH-Config" is the generic type identifier in this example, and the "SIB" suffix is added to distinguish the variant. The clause heading and generic references to a group of closely related IEs defined in this way should use the generic type identifier.
The same principle should apply if a new version, or an extension version, of an existing IE is created for critical or non-critical extension of the protocol (see clause A.4). The new version, or the extension version, of the IE is included in the same ASN.1 clause defining the original. A suffix is added to the type identifier, using the naming conventions defined in clause A.3.1.2, indicating the release or version of the where the new version, or extension version, was introduced.
Local IE type definitions, like the IE PRACH-ConfigInfo in the example above, may be included in the ASN.1 clause and be referenced in the other IE types defined in the same ASN.1 clause. The use of locally defined IE types should be encouraged, as a tool to break up large and complex IE type definitions. It can improve the readability of the code. There may also be a benefit for the software implementation of the protocol end-points, as these IE types are typically provided by the ASN.1 compiler as independent data elements, to be used in the software implementation.
An IE type defined in a local context, like the IE PRACH-ConfigInfo, should not be referenced directly from other ASN.1 clauses in the RRC specification. An IE type which is referenced in more than one ASN.1 clause should be defined in a separate clause, with a separate heading and a separate ASN.1 clause (possibly as one in a set of closely related IE types, like the IEs PRACH-ConfigSIB and PRACH-Config in the example above). Such IE types are also referred to as 'global IEs'.
The ASN.1 clause specifying the contents of one or more IE types, like in the example above, may be followed by a field description table, where a further description of, e.g., the semantic properties of the fields of the information elements may be included. This table may be absent, similar as indicated in clause A.3.3 for the specification of the PDU type. The general format of the field description table is the same as shown in clause A.3.3 for the specification of the PDU type.
A field with optional presence may be declared with the keyword DEFAULT. It identifies a default value to be assumed, if the sender does not include a value for that field in the encoding:
Alternatively, a field with optional presence may be declared with the keyword OPTIONAL. It identifies a field for which a value can be omitted. The omission carries semantics, which is different from any normal value of the field:
The semantics of an optionally present field, in the case it is omitted, should be indicated at the end of the paragraph including the keyword OPTIONAL, using a short comment text with a need code. The need code includes the keyword "Need", followed by one of the predefined semantics tags (S, M, N or R) defined in clause 6.1. If the semantics tag S is used, the semantics of the absent field are further specified either in the field description table following the ASN.1 clause, or in procedure text.
The addition of OPTIONAL keywords for capability groups is based on the following guideline. If there is more than one field in the lower level IE, then OPTIONAL keyword is added at the group level. If there is only one field in the lower level IE, OPTIONAL keyword is not added at the group level.
A field with conditional presence is declared with the keyword OPTIONAL. In addition, a short comment text shall be included at the end of the paragraph including the keyword OPTIONAL. The comment text includes the keyword "Cond", followed by a condition tag associated with the field ("UL" in this example):
When conditionally present fields are included in an ASN.1 clause, the field description table after the ASN.1 clause shall be followed by a conditional presence table. The conditional presence table specifies the conditions for including the fields with conditional presence in the particular ASN.1 clause.
Specification of the conditions for including the field associated with the condition tag = "UL". Semantics in case of optional presence under certain conditions may also be specified.
The conditional presence table has two columns. The first column (heading: "Conditional presence") contains the condition tag (in italic font style), which links the fields with a condition tag in the ASN.1 clause to an entry in the table. The second column (heading: "Explanation") contains a text specification of the conditions and requirements for the presence of the field. The second column may also include semantics, in case of an optional presence of the field, under certain conditions i.e. using the same predefined tags as defined for optional fields in clause A.3.5.
Conditional presence should primarily be used when presence of a field depends on the presence and/or value of other fields within the same message. If the presence of a field depends on whether another feature/function has been configured, while this function can be configured independently e.g. by another message and/or at another point in time, the relation is best reflected by means of a statement in the field description table.
If the ASN.1 clause does not include any fields with conditional presence, the conditional presence table shall not be included.
Whenever a field is only applicable in specific cases e.g. TDD, use of conditional presence should be considered.
Where an information element has the form of a list (the SEQUENCE OF construct in ASN.1) with the type of the list elements being a SEQUENCE data type, an information element shall be defined for the list elements even if it would not otherwise be needed.
For example, a list of PLMN identities with reservation flags is defined as in the following example:
rather than as in the following (bad) example, which may cause generated code to contain types with unpredictable names:
The usage of the parameterised SetupRelease type is like a function call in programming languages where the element type parameter is passed as a parameter. The parameterised type only implies a textual change in abstract syntax where all references to the parameterised type are replaced by the compiler with the release/setup choice. Two examples of the usage are shown below:
The SetupRelease is always be used with only named IEs, i.e. the example below is not allowed:
If a field defined using the parameterized SetupRelease type requires procedural text, the field is referred to using the values defined for the type itself, namely, "setup" and "release". For example, procedural text for field-rX above could be as follows:
In order to benefit from delta signalling when modifying lists with many and/or large elements, so-called add/mod- and release- lists should be used. Instead of a single list containing all elements of the list, the ASN.1 provides two lists. One list is used to convey the actual elements that are to be added to the list or modified in the list. The second list conveys only the identities (IDs) of the list elements that are to be released from the list. In other words, the ASN.1 defines only means to signal modifications to a list maintained in the receiver (typically the UE). An example is provided below:
As can be seen, the elements of the list must contain an identity (INTEGER) that identifies the elements unambiguously upon addition, modification and removal. It is recommended to define an IE for that identifier (here ElementId) so that it can be used both for a field inside the element as well as in the elementsToReleaseList.
Both lists should be made OPTIONAL and flagged as "Need N". The need code reflects that the UE does not maintain the received lists as such but rather updates its configuration using the information therein. In other words, it is not possible to provide via delta signalling an update to a previously signalled elementsToAddModList or elementsToReleaseList (which Need M would imply). The update is always in relation to the UE's internal configuration.
Note that the release of a field (a list element as well as any other field) releases all its sub-fields (sub-fields configured by elementsToAddModList and any other sub-field).
If no procedural text is provided for a set of ToAddModList and ToReleaseList, the following generic procedure applies:
The UE shall:
As per clause 6.1.3, when using lists without the ToAddModList and ToReleaseList structure, the contents of the lists are always replaced. To illustrate this, an example is provided below:
As can be seen, the elementList list itself uses Need M, but each list entry Element contains mandatory, Need M and Need R fields. If the list is first signalled to UE with 3 entries, and subsequently again with 2 entries, UE shall retain only the latter list, i.e. the list with 2 elements will completely replace the list with 3 elements. That also means that the field aField will be treated as if it was newly created, i.e. network must include it if it wishes UE to utilize the field even if it was previously signalled. This also implies that the Need M field (aField) will be treated in the same way as the Need R field (anotherField), i.e. delta signalling is not applied and the network has to signal the field to ensure UE does not release the value (which is why Need M should not normally be used in the entries of these lists).