A.4 Extension of the PDU specifications

38.3313GPPNRProtocol specificationRadio Resource Control (RRC)Release 15TS

A.4.1 General principles to ensure compatibility

It is essential that extension of the protocol does not affect interoperability i.e. it is essential that implementations based on different versions of the RRC protocol are able to interoperate. In particular, this requirement applies for the following kind of protocol extensions:

– Introduction of new PDU types (i.e. these should not cause unexpected behaviour or damage).

– Introduction of additional fields in an extensible PDUs (i.e. it should be possible to ignore uncomprehended extensions without affecting the handling of the other parts of the message).

– Introduction of additional values of an extensible field of PDUs. If used, the behaviour upon reception of an uncomprehended value should be defined.

It should be noted that the PDU extension mechanism may depend on the logical channel used to transfer the message e.g. for some PDUs an implementation may be aware of the protocol version of the peer in which case selective ignoring of extensions may not be required.

The non-critical extension mechanism is the primary mechanism for introducing protocol extensions i.e. the critical extension mechanism is used merely when there is a need to introduce a ‘clean’ message version. Such a need appears when the last message version includes a large number of non-critical extensions, which results in issues like readability, overhead associated with the extension markers. The critical extension mechanism may also be considered when it is complicated to accommodate the extensions by means of non-critical extension mechanisms.

A.4.2 Critical extension of messages and fields

The mechanisms to critically extend a message are defined in A.3.3. There are both "outer branch" and "inner branch" mechanisms available. The "outer branch" consists of a CHOICE having the name criticalExtensions, with two values, c1 and criticalExtensionsFuture. The criticalExtensionsFuture branch consists of an empty SEQUENCE, while the c1 branch contains the "inner branch" mechanism.

The "inner branch" structure is a CHOICE with values of the form "MessageName-rX-IEs" (e.g., "RRCConnectionReconfiguration-r8-IEs") or "spareX", with the spare values having type NULL. The "-rX-IEs" structures contain the complete structure of the message IEs for the appropriate release; i.e., the critical extension branch for the Rel-10 version of a message includes all Rel-8 and Rel-9 fields (that are not obviated in the later version), rather than containing only the additional Rel-10 fields.

The following guidelines may be used when deciding which mechanism to introduce for a particular message, i.e. only an ‘outer branch’, or an ‘outer branch’ in combination with an ‘inner branch’ including a certain number of spares:

– For certain messages, e.g. initial uplink messages, messages transmitted on a broadcast channel, critical extension may not be applicable.

– An outer branch may be sufficient for messages not including any fields.

– The number of spares within inner branch should reflect the likelihood that the message will be critically extended in future releases (since each release with a critical extension for the message consumes one of the spare values). The estimation of the critical extension likelihood may be based on the number, size and changeability of the fields included in the message.

– In messages where an inner branch extension mechanism is available, all spare values of the inner branch should be used before any critical extensions are added using the outer branch.

The following example illustrates the use of the critical extension mechanism by showing the ASN.1 of the original and of a later release

— /example/ ASN1START — Original release

RRCMessage ::= SEQUENCE {

rrc-TransactionIdentifier RRC-TransactionIdentifier,

criticalExtensions CHOICE {

c1 CHOICE{

rrcMessage-r8 RRCMessage-r8-IEs,

spare3 NULL, spare2 NULL, spare1 NULL

},

criticalExtensionsFuture SEQUENCE {}

}

}

— ASN1STOP

— /example/ ASN1START — Later release

RRCMessage ::= SEQUENCE {

rrc-TransactionIdentifier RRC-TransactionIdentifier,

criticalExtensions CHOICE {

c1 CHOICE{

rrcMessage-r8 RRCMessage-r8-IEs,

rrcMessage-r10 RRCMessage-r10-IEs,

rrcMessage-r11 RRCMessage-r11-IEs,

rrcMessage-r14 RRCMessage-r14-IEs

},

later CHOICE {

c2 CHOICE{

rrcMessage-r16 RRCMessage-r16-IEs,

spare7 NULL, spare6 NULL, spare5 NULL, spare4 NULL,

spare3 NULL, spare2 NULL, spare1 NULL

},

criticalExtensionsFuture SEQUENCE {}

}

}

}

— ASN1STOP

It is important to note that critical extensions may also be used at the level of individual fields i.e. a field may be replaced by a critically extended version. When sending the extended version, the original version may also be included (e.g. original field is mandatory, E-UTRAN is unaware if UE supports the extended version). In such cases, a UE supporting both versions may be required to ignore the original field. The following example illustrates the use of the critical extension mechanism by showing the ASN.1 of the original and of a later release.

— /example/ ASN1START — Original release

RRCMessage ::= SEQUENCE {

rrc-TransactionIdentifier RRC-TransactionIdentifier,

criticalExtensions CHOICE {

c1 CHOICE{

rrcMessage-r8 RRCMessage-r8-IEs,

spare3 NULL, spare2 NULL, spare1 NULL

},

criticalExtensionsFuture SEQUENCE {}

}

}

RRCMessage-rN-IEs ::= SEQUENCE {

field1-rN ENUMERATED {

value1, value2, value3, value4} OPTIONAL, — Need N

field2-rN InformationElement2-rN OPTIONAL, — Need N

nonCriticalExtension RRCConnectionReconfiguration-vMxy-IEs OPTIONAL

}

RRCConnectionReconfiguration-vMxy-IEs ::= SEQUENCE {

field2-rM InformationElement2-rM OPTIONAL, — Cond NoField2rN

nonCriticalExtension SEQUENCE {} OPTIONAL

}

— ASN1STOP

Conditional presence

Explanation

NoField2rN

The field is optionally present, need N, if field2-rN is absent. Otherwise the field is absent

Finally, it is noted that a critical extension may be introduced in the same release as the one in which the original field was introduced e.g. to correct an essential ASN.1 error. In such cases a UE capability may be introduced, to assist the network in deciding whether or not to use the critical extension.

A.4.3 Non-critical extension of messages

A.4.3.1 General principles

The mechanisms to extend a message in a non-critical manner are defined in A.3.3. W.r.t. the use of extension markers, the following additional guidelines apply:

– When further non-critical extensions are added to a message that has been critically extended, the inclusion of these non-critical extensions in earlier critical branches of the message should be avoided when possible.

– The extension marker ("…") is the primary non-critical extension mechanism that is used but empty sequences may be used if length determinant is not required. Examples of cases where a length determinant is not required:

– at the end of a message;

– at the end of a structure contained in a BIT STRING or OCTET STRING.

– When an extension marker is available, non-critical extensions are preferably placed at the location (e.g. the IE) where the concerned parameter belongs from a logical/ functional perspective (referred to as the ‘default extension location‘).

– It is desirable to aggregate extensions of the same release or version of the specification into a group, which should be placed at the lowest possible level.

– In specific cases it may be preferable to place extensions elsewhere (referred to as the ‘actual extension location‘) e.g. when it is possible to aggregate several extensions in a group. In such a case, the group should be placed at the lowest suitable level in the message.

– In case placement at the default extension location affects earlier critical branches of the message, locating the extension at a following higher level in the message should be considered.

– In case an extension is not placed at the default extension location, an IE should be defined. The IE’s ASN.1 definition should be placed in the same ASN.1 section as the default extension location. In case there are intermediate levels in-between the actual and the default extension location, an IE may be defined for each level. Intermediate levels are primarily introduced for readability and overview. Hence intermediate levels need not always be introduced e.g. they may not be needed when the default and the actual extension location are within the same ASN.1 section.

A.4.3.2 Further guidelines

Further to the general principles defined in the previous section, the following additional guidelines apply regarding the use of extension markers:

– Extension markers within SEQUENCE:

– Extension markers are primarily, but not exclusively, introduced at the higher nesting levels.

– Extension markers are introduced for a SEQUENCE comprising several fields as well as for information elements whose extension would result in complex structures without it (e.g. re-introducing another list).

– Extension markers are introduced to make it possible to maintain important information structures e.g. parameters relevant for one particular RAT.

– Extension markers are also used for size critical messages (i.e. messages on BCCH, BR-BCCH, PCCH and CCCH), although introduced somewhat more carefully.

– The extension fields introduced (or frozen) in a specific version of the specification are grouped together using double brackets.

– Extension markers within ENUMERATED:

– Spare values may be used until the number of values reaches the next power of 2, while the extension marker caters for extension beyond that limit, given that the use of spare values in a later Release is possible without any error cases.

– A suffix of the form "vXYZ" is used for the identifier of each new value, e.g. "value-vXYZ".

– Extension markers within CHOICE:

– Extension markers are introduced when extension is foreseen and when comprehension is not required by the receiver i.e. behaviour is defined for the case where the receiver cannot comprehend the extended value (e.g. ignoring an optional CHOICE field). It should be noted that defining the behaviour of a receiver upon receiving a not comprehended choice value is not required if the sender is aware whether or not the receiver supports the extended value.

– A suffix of the form "vXYZ" is used for the identifier of each new choice value, e.g. "choice-vXYZ".

Non-critical extensions at the end of a message/ of a field contained in an OCTET or BIT STRING:

– When a nonCriticalExtension is actually used, a "Need" code should not be provided for the field, which always is a group including at least one extension and a field facilitating further possible extensions. For simplicity, it is recommended not to provide a "Need" code when the field is not actually used either.

Further, more general, guidelines:

– In case a need code is not provided for a group, a "Need" code is provided for all individual extension fields within the group i.e. including for fields that are not marked as OPTIONAL. The latter is to clarify the action upon absence of the whole group.

A.4.3.3 Typical example of evolution of IE with local extensions

The following example illustrates the use of the extension marker for a number of elementary cases (sequence, enumerated, choice). The example also illustrates how the IE may be revised in case the critical extension mechanism is used.

NOTE In case there is a need to support further extensions of release n while the ASN.1 of release (n+1) has been frozen, without requiring the release n receiver to support decoding of release (n+1) extensions, more advanced mechanisms are needed e.g. including multiple extension markers.

— /example/ ASN1START

InformationElement1 ::= SEQUENCE {

field1 ENUMERATED {

value1, value2, value3, value4-v880,

…, value5-v960 },

field2 CHOICE {

field2a BOOLEAN,

field2b InformationElement2b,

…,

field2c-v960 InformationElement2c-r9

},

…,

[[

field3-r9 InformationElement3-r9 OPTIONAL — Need R

]],

[[

field3-v9a0 InformationElement3-v9a0 OPTIONAL, — Need R

field4-r9 InformationElement4 OPTIONAL — Need R

]]

}

InformationElement1-r10 ::= SEQUENCE {

field1 ENUMERATED {

value1, value2, value3, value4-v880,

value5-v960, value6-v1170, spare2, spare1, … },

field2 CHOICE {

field2a BOOLEAN,

field2b InformationElement2b,

field2c-v960 InformationElement2c-r9,

…,

field2d-v12b0 INTEGER (0..63)

},

field3-r9 InformationElement3-r10 OPTIONAL, — Need R

field4-r9 InformationElement4 OPTIONAL, — Need R

field5-r10 BOOLEAN,

field6-r10 InformationElement6-r10 OPTIONAL, — Need R

…,

[[

field3-v1170 InformationElement3-v1170 OPTIONAL — Need R

]]

}

— ASN1STOP

Some remarks regarding the extensions of InformationElement1 as shown in the above example:

– The InformationElement1 is initially extended with a number of non-critical extensions. In release 10 however, a critical extension is introduced for the message using this IE. Consequently, a new version of the IE InformationElement1 (i.e. InformationElement1-r10) is defined in which the earlier non-critical extensions are incorporated by means of a revision of the original field.

– The value4-v880 is replacing a spare value defined in the original protocol version for field1. Likewise value6-v1170 replaces spare3 that was originally defined in the r10 version of field1.

– Within the critically extended release 10 version of InformationElement1, the names of the original fields/IEs are not changed, unless there is a real need to distinguish them from other fields/IEs. E.g. the field1 and InformationElement4 were defined in the original protocol version (release 8) and hence not tagged. Moreover, the field3-r9 is introduced in release 9 and not re-tagged; although, the InformationElement3 is also critically extended and therefore tagged InformationElement3-r10 in the release 10 version of InformationElement1.

A.4.3.4 Typical examples of non critical extension at the end of a message

The following example illustrates the use of 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 i.e. when an empty sequence is used.

— /example/ ASN1START

RRCMessage-r8-IEs ::= SEQUENCE {

field1 InformationElement1,

field2 InformationElement2,

field3 InformationElement3 OPTIONAL, — Need N

nonCriticalExtension RRCMessage-v860-IEs OPTIONAL

}

RRCMessage-v860-IEs ::= SEQUENCE {

field4-v860 InformationElement4 OPTIONAL, — Need S

field5-v860 BOOLEAN OPTIONAL, — Cond C54

nonCriticalExtension RRCMessage-v940-IEs OPTIONAL

}

RRCMessage-v940-IEs ::= SEQUENCE {

field6-v940 InformationElement6-r9 OPTIONAL, — Need R

nonCriticalExtensions SEQUENCE {} OPTIONAL

}

— ASN1STOP

Some remarks regarding the extensions shown in the above example:

– The InformationElement4 is introduced in the original version of the protocol (release 8) and hence no suffix is used.

A.4.3.5 Examples of non-critical extensions not placed at the default extension location

The following example illustrates the use of non-critical extensions in case an extension is not placed at the default extension location.

ParentIE-WithEM

The IE ParentIE-WithEMis an example of a high level IE including the extension marker (EM). The root encoding of this IE includes two lower level IEs ChildIE1-WithoutEM and ChildIE2-WithoutEM which not include the extension marker. Consequently, non-critical extensions of the Child-IEs have to be included at the level of the Parent-IE.

The example illustrates how the two extension IEs ChildIE1-WithoutEM-vNx0 and ChildIE2-WithoutEM-vNx0 (both in release N) are used to connect non-critical extensions with a default extension location in the lower level IEs to the actual extension location in this IE.

ParentIE-WithEM information element

— /example/ ASN1START

ParentIE-WithEM ::= SEQUENCE {

— Root encoding, including:

childIE1-WithoutEM ChildIE1-WithoutEM OPTIONAL, — Need N

childIE2-WithoutEM ChildIE2-WithoutEM OPTIONAL, — Need N

…,

[[

childIE1-WithoutEM-vNx0 ChildIE1-WithoutEM-vNx0 OPTIONAL, — Need N

childIE2-WithoutEM-vNx0 ChildIE2-WithoutEM-vNx0 OPTIONAL — Need N

]]

}

— ASN1STOP

Some remarks regarding the extensions shown in the above example:

– The fields childIEx-WithoutEM-vNx0 may not really need to be optional (depends on what is defined at the next lower level).

– In general, especially when there are several nesting levels, fields should be marked as optional only when there is a clear reason.

– ChildIE1-WithoutEM

The IE ChildIE1-WithoutEM is an example of a lower level IE, used to control certain radio configurations including a configurable feature which can be setup or released using the local IE ChIE1-ConfigurableFeature. The example illustrates how the new field chIE1-NewField is added in release N to the configuration of the configurable feature. The example is based on the following assumptions:

– When initially configuring as well as when modifying the new field, the original fields of the configurable feature have to be provided also i.e. as if the extended ones were present within the setup branch of this feature.

– When the configurable feature is released, the new field should be released also.

– When omitting the original fields of the configurable feature the UE continues using the existing values (which is used to optimise the signalling for features that typically continue unchanged upon handover).

– When omitting the new field of the configurable feature the UE releases the existing values and discontinues the associated functionality (which may be used to support release of unsupported functionality upon handover to an eNB supporting an earlier protocol version).

The above assumptions, which affect the use of conditions and need codes, may not always apply. Hence, the example should not be re-used blindly.

ChildIE1-WithoutEM information element

— /example/ ASN1START

ChildIE1-WithoutEM ::= SEQUENCE {

— Root encoding, including:

chIE1-ConfigurableFeature ChIE1-ConfigurableFeature OPTIONAL — Need N

}

ChildIE1-WithoutEM-vNx0 ::= SEQUENCE {

chIE1-ConfigurableFeature-vNx0 ChIE1-ConfigurableFeature-vNx0 OPTIONAL — Cond ConfigF

}

ChIE1-ConfigurableFeature ::= CHOICE {

release NULL,

setup SEQUENCE {

— Root encoding

}

}

ChIE1-ConfigurableFeature-vNx0 ::= SEQUENCE {

chIE1-NewField-rN INTEGER (0..31)

}

— ASN1STOP

Conditional presence

Explanation

ConfigF

The field is optional present, need R, in case of chIE1-ConfigurableFeature is included and set to "setup"; otherwise the field is absent and the UE shall delete any existing value for this field.

– ChildIE2-WithoutEM

The IE ChildIE2-WithoutEM is an example of a lower level IE, typically used to control certain radio configurations. The example illustrates how the new field chIE1-NewField is added in release N to the configuration of the configurable feature.

ChildIE2-WithoutEM information element

— /example/ ASN1START

ChildIE2-WithoutEM ::= CHOICE {

release NULL,

setup SEQUENCE {

— Root encoding

}

}

ChildIE2-WithoutEM-vNx0 ::= SEQUENCE {

chIE2-NewField-rN INTEGER (0..31) OPTIONAL — Cond ConfigF

}

— ASN1STOP

Conditional presence

Explanation

ConfigF

The field is optional present, need R, in case of chIE2-ConfigurableFeature is included and set to "setup"; otherwise the field is absent and the UE shall delete any existing value for this field.