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 following more detailed conventions should be used:

• Bullets:
  • Capitals should be used in the same manner as in other parts of the procedural text i.e. in most cases no capital applies since the bullets are part of the sentence starting with 'The UE shall:'
  • All bullets, including the last one in a clause, should end with a semi-colon i.e. an ';'.
• Conditions:
  • Whenever multiple conditions apply, a semi-colon should be used at the end of each conditions with the exception of the last one, i.e. as in 'if cond1, or cond2'.

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.

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.

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