A.3 PDU specification

38.3313GPPNRProtocol specificationRadio Resource Control (RRC)Release 15TS

A.3.1 General principles

A.3.1.1 ASN.1 sections

The RRC PDU contents are formally and completely described using abstract syntax notation (ASN.1), see X.680 [6], X.681 [7].

The complete ASN.1 code is divided into a number of ASN.1 sections in the specifications. In order to facilitate the extraction of the complete ASN.1 code from the specification, each ASN.1 section 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 section 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:

— ASN1START

— TAG-NAME-START

— TAG-NAME-STOP

— ASN1STOP

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.

NOTE: A typical procedure for extraction of the complete ASN.1 code consists of a first step where the entire RRC PDU contents description (ultimately the entire specification) is saved into a plain text (ASCII) file format, followed by a second step where the actual extraction takes place, based on the occurrence of the ASN.1 start and stop tags.

A.3.1.2 ASN.1 identifier naming conventions

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

Table A.3.1.2-1: Examples of typical abbreviations used in ASN.1 identifiers

Abbreviation

Abbreviated word

Config

Configuration

DL

Downlink

Ext

Extension

Freq

Frequency

Id

Identity

Ind

Indication

Meas

Measurement

MIB

MasterInformationBlock

Neigh

Neighbour(ing)

Param(s)

Parameter(s)

Phys

Physical

PCI

Physical Cell Id

Proc

Process

Reconfig

Reconfiguration

Reest

Re-establishment

Req

Request

Rx

Reception

Sched

Scheduling

SIB

SystemInformationBlock

Sync

Synchronisation

Thr

Threshold

Tx

Transmission

UL

Uplink

NOTE: The table A.3.1.2.1-1 is not exhaustive. Additional abbreviations may be used in ASN.1 identifiers when needed.

A.3.1.3 Text references using ASN.1 identifiers

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.

— /example/ ASN1START

LogicalChannelConfig ::= SEQUENCE {

ul-SpecificParameters SEQUENCE {

priority Priority,

prioritisedBitRate PrioritisedBitRate,

bucketSizeDuration BucketSizeDuration,

logicalChannelGroup INTEGER (0..3)

} OPTIONAL

}

— ASN1STOP

NOTE: All the ASN.1 start tags in the ASN.1 sections, used as examples in this annex to the specification, are deliberately distorted, in order not to include them when the ASN.1 description of the RRC PDU contents is extracted from the specification.

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

A.3.2 High-level message structure

Within each logical channel type, the associated RRC PDU (message) types are alternatives within a CHOICE, as shown in the example below.

— /example/ ASN1START

DL-DCCH-Message ::= SEQUENCE {

message DL-DCCH-MessageType

}

DL-DCCH-MessageType ::= CHOICE {

c1 CHOICE {

dlInformationTransfer DLInformationTransfer,

handoverFromEUTRAPreparationRequest HandoverFromEUTRAPreparationRequest,

mobilityFromEUTRACommand MobilityFromEUTRACommand,

rrcConnectionReconfiguration RRCConnectionReconfiguration,

rrcConnectionRelease RRCConnectionRelease,

securityModeCommand SecurityModeCommand,

ueCapabilityEnquiry UECapabilityEnquiry,

spare1 NULL

},

messageClassExtension SEQUENCE {}

}

— ASN1STOP

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.

A.3.3 Message definition

Each PDU (message) type is specified in an ASN.1 section similar to the one shown in the example below.

— /example/ ASN1START

RRCConnectionReconfiguration ::= SEQUENCE {

rrc-TransactionIdentifier RRC-TransactionIdentifier,

criticalExtensions CHOICE {

c1 CHOICE{

rrcConnectionReconfiguration-r8 RRCConnectionReconfiguration-r8-IEs,

spare3 NULL, spare2 NULL, spare1 NULL

},

criticalExtensionsFuture SEQUENCE {}

}

}

RRCConnectionReconfiguration-r8-IEs ::= SEQUENCE {

— Enter the IEs here.

}

— ASN1STOP

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

— /example/ ASN1START

RRCConnectionReconfigurationComplete ::= SEQUENCE {

rrc-TransactionIdentifier RRC-TransactionIdentifier,

criticalExtensions CHOICE {

rrcConnectionReconfigurationComplete-r8

RRCConnectionReconfigurationComplete-r8-IEs,

criticalExtensionsFuture SEQUENCE {}

}

}

RRCConnectionReconfigurationComplete-r8-IEs ::= SEQUENCE {

— Enter the fields here.

}

— ASN1STOP

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:

— /example/ ASN1START

RRCMessage-r8-IEs ::= SEQUENCE {

field1 InformationElement1,

field2 InformationElement2,

nonCriticalExtension SEQUENCE {} OPTIONAL

}

— ASN1STOP

The ASN.1 section 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

%field identifier%

Field description.

%field identifier%

Field description.

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.

A.3.4 Information elements

Each IE (information element) type is specified in an ASN.1 section similar to the one shown in the example below.

— /example/ ASN1START

PRACH-ConfigSIB ::= SEQUENCE {

rootSequenceIndex INTEGER (0..1023),

prach-ConfigInfo PRACH-ConfigInfo

}

PRACH-Config ::= SEQUENCE {

rootSequenceIndex INTEGER (0..1023),

prach-ConfigInfo PRACH-ConfigInfo OPTIONAL — Need N

}

PRACH-ConfigInfo ::= SEQUENCE {

prach-ConfigIndex ENUMERATED {ffs},

highSpeedFlag ENUMERATED {ffs},

zeroCorrelationZoneConfig ENUMERATED {ffs}

}

— ASN1STOP

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 section. 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 sub-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 sub-clause A.4). The new version, or the extension version, of the IE is included in the same ASN.1 section defining the original. A suffix is added to the type identifier, using the naming conventions defined in sub-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 section and be referenced in the other IE types defined in the same ASN.1 section. 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 sections in the RRC specification. An IE type which is referenced in more than one ASN.1 section should be defined in a separate sub-clause, with a separate heading and a separate ASN.1 section (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’.

NOTE: Referring to an IE type, that is defined as a local IE type in the context of another ASN.1 section, does not generate an ASN.1 compilation error. Nevertheless, using a locally defined IE type in that way makes the IE type definition difficult to find, as it would not be visible at an outline level of the specification. It should be avoided.

The ASN.1 section 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 sub-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 sub-clause A.3.3 for the specification of the PDU type.

A.3.5 Fields with optional presence

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:

— /example/ ASN1START

PreambleInfo ::= SEQUENCE {

numberOfRA-Preambles INTEGER (1..64) DEFAULT 1,

}

— ASN1STOP

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:

— /example/ ASN1START

PRACH-Config ::= SEQUENCE {

rootSequenceIndex INTEGER (0..1023),

prach-ConfigInfo PRACH-ConfigInfo OPTIONAL — Need N

}

— ASN1STOP

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 sub-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 section, 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.3.6 Fields with conditional presence

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

— /example/ ASN1START

LogicalChannelConfig ::= SEQUENCE {

ul-SpecificParameters SEQUENCE {

priority INTEGER (0),

} OPTIONAL — Cond UL

}

— ASN1STOP

When conditionally present fields are included in an ASN.1 section, the field description table after the ASN.1 section 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 section.

Conditional presence

Explanation

UL

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

A.3.7 Guidelines on use of lists with elements of SEQUENCE type

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:

— /example/ ASN1START

PLMN-IdentityInfoList ::= SEQUENCE (SIZE (1..6)) OF PLMN-IdentityInfo

PLMN-IdentityInfo ::= SEQUENCE {

plmn-Identity PLMN-Identity,

cellReservedForOperatorUse ENUMERATED {reserved, notReserved}

}

— ASN1STOP

rather than as in the following (bad) example, which may cause generated code to contain types with unpredictable names:

— /bad example/ ASN1START

PLMN-IdentityList ::= SEQUENCE (SIZE (1..6)) OF SEQUENCE {

plmn-Identity PLMN-Identity,

cellReservedForOperatorUse ENUMERATED {reserved, notReserved}

}

— ASN1STOP

A.3.8 Guidelines on use of parameterised SetupRelease type

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:

— /example/ ASN1START

RRCMessage-rX-IEs ::= SEQUENCE {

field-rX SetupRelease { IE-rX } OPTIONAL, — Need M

}

RRCMessage-rX-IEs ::= SEQUENCE {

field-rX SetupRelease { Element-rX }

} OPTIONAL, — Need M

Element-rX ::= SEQUENCE {

field1-rX IE1-rX,

field2-rX IE2-rX OPTIONAL — Need N

} OPTIONAL, — Need M

— /example/ ASN1STOP

The SetupRelease is always be used with only named IEs, i.e. the example below is not allowed:

— /example/ ASN1START

RRCMessage-rX-IEs ::= SEQUENCE {

field-rX SetupRelease { SEQUENCE { — Unnamed SEQUENCEs are not allowed!

field1-rX IE1-rX,

field2-rX IE2-rX OPTIONAL — Need N

}

} OPTIONAL, — Need M

}

— /example/ ASN1STOP

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:

1> if field-rX is set to "setup":

2> do something;

1> else (field-rX is set to "release"):

2> release field-rX (if appropriate).

A.3.9 Guidelines on use of ToAddModList and ToReleaseList

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:

— /example/ ASN1START

AnExampleIE ::= SEQUENCE {

elementsToAddModList SEQUENCE (SIZE (1..maxNrofElements)) OF Element OPTIONAL, — Need N

elementsToReleaseList SEQUENCE (SIZE (1..maxNrofElements)) OF ElementId OPTIONAL, — Need N

}

Element ::= SEQUENCE {

elementId ElementId,

aField INTEG ER (0..16777215),

anotherField OCTET STRING,

}

ElementId ::= INTEGER (0..maxNrofElements-1)

maxNrofElements INTEGER ::= 50

maxNrofElements-1 INTEGER ::= 49

— /example/ ASN1STOP

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:

1> for each ElementId in the elementsToReleaseList,:

2> if the current UE configuration includes an Element with the given ElementId:

3> release the Element from the current UE configuration;

1> for each Element in the elementsToAddModList:

2> if the current UE configuration includes an Element with the given ElementId:

3> modify the configured Element in accordance with the received Element;

2> else:

3> add received Element to the UE configuration.

A.3.10 Guidelines on use of of lists (without ToAddModList and ToReleaseList)

As per subclause 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:

— /example/ ASN1START

— TAG_EXAMPLE_LISTS_START

AnExampleIE ::= SEQUENCE {

elementList SEQUENCE (SIZE (1..maxNrofElements)) OF Element OPTIONAL, — Need M

…,

[[

elementListExt-v2030 SEQUENCE (SIZE (1..maxNrofElementsExt)) OF Element OPTIONAL, — Need M

]]

}

Element ::= SEQUENCE {

useFeatureX BOOLEAN,

aField INTEGER (0..127) OPTIONAL, — Need M

anotherField INTEGER (0..127) OPTIONAL, — Need R

}

maxNrofElements INTEGER ::= 8

maxNrofElements-1 INTEGER ::= 7

maxNrofElementsExt INTEGER ::= 8

maxNrofElementsExt-1 INTEGER ::= 7

— TAG_EXAMPLE_LISTS_STOP

— /example/ ASN1STOP

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