10 Generic error handling

38.3313GPPNRProtocol specificationRadio Resource Control (RRC)Release 17TS

10.1 General

The generic error handling defined in the subsequent clauses applies unless explicitly specified otherwise e.g. within the procedure specific error handling.

The UE shall consider a value as not comprehended when it is set:

– to an extended value that is not defined in the version of the transfer syntax supported by the UE;

– to a spare or reserved value unless the specification defines specific behaviour that the UE shall apply upon receiving the concerned spare/reserved value.

The UE shall consider a field as not comprehended when it is defined:

– as spare or reserved unless the specification defines specific behaviour that the UE shall apply upon receiving the concerned spare/reserved field.

10.2 ASN.1 violation or encoding error

The UE shall:

1> when receiving an RRC message on the BCCH, CCCH or PCCH or a PC5 RRC message on SBCCH for which the abstract syntax is invalid [6]:

2> ignore the message.

NOTE: This clause applies in case one or more fields is set to a value, other than a spare, reserved or extended value, not defined in this version of the transfer syntax. E.g. in the case the UE receives value 12 for a field defined as INTEGER (1..11). In cases like this, it may not be possible to reliably detect which field is in the error hence the error handling is at the message level.

10.3 Field set to a not comprehended value

The UE shall, when receiving an RRC message or PC5 RRC message on any logical channel:

1> if the message includes a field that has a value that the UE does not comprehend:

2> if a default value is defined for this field:

3> treat the message while using the default value defined for this field;

2> else if the concerned field is optional:

3> treat the message as if the field were absent and in accordance with the need code for absence of the concerned field;

2> else:

3> treat the message as if the field were absent and in accordance with clause 10.4.

10.4 Mandatory field missing

The UE shall:

1> if the message includes a field that is mandatory to include in the message (e.g. because conditions for mandatory presence are fulfilled) and that field is absent or treated as absent:

2> if the RRC message was not received on DCCH or CCCH; or

2> if the PC5 RRC message was not received on SCCH:

3> if the field concerns a (sub-field of) an entry of a list (i.e. a SEQUENCE OF):

4> treat the list as if the entry including the missing or not comprehended field was absent;

3> else if the field concerns a sub-field of another field, referred to as the ‘parent’ field i.e. the field that is one nesting level up compared to the erroneous field:

4> consider the ‘parent’ field to be set to a not comprehended value;

4> apply the generic error handling to the subsequent ‘parent’ field(s), until reaching the top nesting level i.e. the message level;

3> else (field at message level):

4> ignore the message.

NOTE 1: The error handling defined in these clauses implies that the UE ignores a message with the message type or version set to a not comprehended value.

NOTE 2: The nested error handling for messages received on logical channels other than DCCH, CCCH and SCCH applies for errors in extensions also, even for errors that can be regarded as invalid network operation e.g. the network not observing conditional presence.

NOTE 3: UE behaviour on receipt of an RRC message on DCCH or CCCH or a PC5 RRC message on SCCH that does not include a field that is mandatory (e.g. because conditions for mandatory presence are fulfilled) is unspecified.

The following ASN.1 further clarifies the levels applicable in case of nested error handling for errors in extension fields.

— /example/ ASN1START

— Example with extension addition group

ItemInfoList ::= SEQUENCE (SIZE (1..max)) OFItemInfo

ItemInfo ::= SEQUENCE {

itemIdentity INTEGER (1..max),

field1 Field1,

field2 Field2 OPTIONAL, — Need N

…

[[

field3-r9 Field3-r9 OPTIONAL, — Cond Cond1

field4-r9 Field4-r9 OPTIONAL — Need N

]]

}

— Example with traditional non-critical extension (empty sequence)

BroadcastInfoBlock1 ::= SEQUENCE {

itemIdentity INTEGER (1..max),

field1 Field1,

field2 Field2 OPTIONAL, — Need N

nonCriticalExtension BroadcastInfoBlock1-v940-IEs OPTIONAL

}

BroadcastInfoBlock1-v940-IEs::= SEQUENCE {

field3-r9 Field3-r9 OPTIONAL, — Cond Cond1

field4-r9 Field4-r9 OPTIONAL, — Need N

nonCriticalExtension SEQUENCE {} OPTIONAL — Need S

}

— ASN1STOP

The UE shall, apply the following principles regarding the levels applicable in case of nested error handling:

– an extension addition group is not regarded as a level on its own. E.g. in the ASN.1 extract in the previous, a error regarding the conditionality of field3 would result in the entire itemInfo entry to be ignored (rather than just the extension addition group containing field3 and field4);

– a traditional nonCriticalExtension is not regarded as a level on its own. E.g. in the ASN.1 extract in the previous, an error regarding the conditionality of field3 would result in the entire BroadcastInfoBlock1 to be ignored (rather than just the non-critical extension containing field3 and field4).

10.5 Not comprehended field

The UE shall, when receiving an RRC message on any logical channel:

1> if the message includes a field that the UE does not comprehend:

2> treat the rest of the message as if the field was absent.

NOTE: This clause does not apply to the case of an extension to the value range of a field. Such cases are addressed instead by the requirements in clause 10.3.