6.1 General

36.3313GPPEvolved Universal Terrestrial Radio Access (E-UTRA)Protocol specificationRadio Resource Control (RRC)Release 15TS

The contents of each RRC message is specified in clause 6.2 using ASN.1 to specify the message syntax and using tables when needed to provide further detailed information about the fields specified in the message syntax. The syntax of the information elements that are defined as stand-alone abstract types is further specified in a similar manner in clause 6.3.

The need for fields to be present in a message or an abstract type, i.e., the ASN.1 fields that are specified as OPTIONAL in the abstract notation (ASN.1), is specified by means of comment text tags attached to the OPTIONAL statement in the abstract syntax. All comment text tags are available for use in the downlink direction only. The meaning of each tag is specified in table 6.1-1.

Table 6.1-1: Meaning of abbreviations used to specify the need for fields to be present

Abbreviation

Meaning

Cond conditionTag

(Used in downlink only)

Conditionally present

A field for which the need is specified by means of conditions. For each conditionTag, the need is specified in a tabular form following the ASN.1 segment. In case, according to the conditions, a field is not present, the UE takes no action and where applicable shall continue to use the existing value (and/ or the associated functionality) unless explicitly stated otherwise (e.g. in the conditional presence table or in the description of the field itself).

Need OP

(Used in downlink only)

Optionally present

A field that is optional to signal. For downlink messages, the UE is not required to take any special action on absence of the field beyond what is specified in the procedural text or the field description table following the ASN.1 segment. The UE behaviour on absence should be captured either in the procedural text or in the field description.

Need ON

(Used in downlink only)

Optionally present, No action

A field that is optional to signal. If the message is received by the UE, and in case the field is absent, the UE takes no action and where applicable shall continue to use the existing value (and/ or the associated functionality).

Need OR

(Used in downlink only)

Optionally present, Release

A field that is optional to signal. If the message is received by the UE, and in case the field is absent, the UE shall discontinue/ stop using/ delete any existing value (and/ or the associated functionality).

Any field with Need ON in system information shall be interpreted as Need OR.

Need codes may not be specified for a parent extension field/ extension group, used in downlink, which includes one or more child extension fields. Upon absence of such a parent extension field/ extension group, the UE shall:

– For each individual child extension field, including extensions that are mandatory to include in the optional group, act in accordance with the need code that is defined for the extension;

– Apply this behaviour not only for child extension fields included directly within the optional parent extension field/ extension group, but also for extension fields defined at further nesting levels as long as for none of the fields in-between the concerned extension field and the parent extension field a need code is specified;

NOTE 1: The above applies for groups of non critical extensions using double brackets (referred to as extension groups), as well as non-critical extensions at the end of a message or at the end of a structure contained in a BIT STRING or OCTET STRING (referred to as parent extension fields).

Need codes, conditions and ASN.1 defaults specified for a particular (child) field only apply in case the (parent) field including the particular field is present. This rule does not apply for optional parent extension fields/ extension groups without need codes,

NOTE 2: The previous rule implies that E-UTRAN has to include such a parent extension field to release a child field that is either:

– Optional with need OR, or

– Conditional while the UE releases the child field when absent.

The handling of need codes as specified in the previous is illustrated by means of an example, as shown in the following ASN.1.

— /example/ ASN1START

RRCMessage-r8-IEs ::= SEQUENCE {

field1 InformationElement1,

field2 InformationElement2 OPTIONAL, — Need ON

nonCriticalExtension RRCMessage-v8a0-IEs OPTIONAL

}

RRCMessage-v8a0-IEs ::= SEQUENCE {

field3 InformationElement3 OPTIONAL, — Need ON

nonCriticalExtension RRCMessage-v940-IEs OPTIONAL

}

RRCMessage-v940-IEs ::= SEQUENCE {

field4 InformationElement4 OPTIONAL, — Need OR

nonCriticalExtension SEQUENCE {} OPTIONAL

}

InformationElement1 ::= SEQUENCE {

field11 InformationElement11 OPTIONAL, — Need ON

field12 InformationElement12 OPTIONAL, — Need OR

…,

[[ field13 InformationElement13 OPTIONAL, — Need OR

field14 InformationElement14 OPTIONAL — Need ON

]]

}

InformationElement2 ::= SEQUENCE {

field21 InformationElement11 OPTIONAL, — Need OR

}

— ASN1STOP

The handling of need codes as specified in the previous implies that:

– if field2 in RRCMessage-r8-IEs is absent, the UE does not modify field21;

– if field2 in RRCMessage-r8-IEs is present but does not include field21, the UE releases field21;

– if the extension group containing field13 is absent, the UE releases field13 and does not modify field14;

– if nonCriticalExtension defined by IE RRCMessage-v8a0-IEs is absent, the UE does not modify field3 and releases field4;

In the ASN.1 of this specification, the first bit of a bit string refers to the leftmost bit, unless stated otherwise.