11.1 Handling of erroneous protocol data
3GPP44.060General Packet Radio Service (GPRS)Mobile Station (MS) - Base Station System (BSS) interfaceRadio Link Control / Medium Access Control (RLC/MAC) protocolRelease 17TS
This sub-clause specifies procedures for the handling of unknown and erroneous protocol data by the receiving entity.
These error-handling procedures are mandatory for the mobile station.
A message is defined to be syntactically incorrect if it violates rules of clauses 11 and 12, or if it contains at least one value defined as "reserved" in clauses 11 and 12. However, if the rules of clause 11 and 12 define a specific interpretation for a "reserved" value, the specified interpretation takes precedence and the considered field remains syntactically correct.
Decoding a received message based on its CSN.1 description yields the complete acceptance or rejection of the message. Error handling allows a message to be partially accepted even when some parts are erroneous.
Error detection mechanisms are introduced to identify which parts of a message to be protected against which kinds of errors.
11.1.1 Message classification
The packet data channel (PDCH) is a shared resource, i.e. all mobile stations assigned resources on a PDCH may receive a message sent by the network. The message type is identified by the MESSAGE_TYPE field contained in each message. The message type is used for classification and determining the message syntax.
Messages sent from the network to the mobile station on PDCH (A/Gb mode and Iu mode) or DBPSCH (Iu mode) are classified as either distribution messages or non-distribution messages.
Messages sent from the network to the mobile station exclusively on DBPSCH (Iu mode) are classified as DBPSCH messages.
11.1.1.1 Distribution messages
A distribution message is recognised by the most significant bit of the message type being set to bit ‘1’. The general format of a distribution message, except for distribution messages on the EC-PACCH, sent from the network to the mobile station is:
|
< Distribution message > ::= < MESSAGE_TYPE : 1 bit (5) > < Distribution contents > < padding bits > ; |
The general format of a distribution message sent on the EC-PACCH from the network to the mobile station is:
|
< Distribution message > ::= < MESSAGE_TYPE : 1 bit (4) > < Distribution contents > < padding bits > ; |
Any mobile stations may receive a distribution message. Depending on the protocol state of the mobile station, a distribution message shall be analysed as specified in sub-clauses 5, 6, 7, 8 and 9 of the present document.
The ‘Distribution contents’ of a distribution message contains Page Mode information and any specific distribution information according to the syntax defined for the message type. The ‘Distribution contents’ of a distribution message on the EC-PACCH contains Used DL Coverage Class information instead of the Page Mode information. The ‘padding bits’ of a distribution message can be reduced to the null string.
The general format of the ‘Distribution contents’, except for distribution messages sent on the EC-PACCH, is:
|
< Distribution contents > ::= < PAGE_MODE : bit (2) > < specific distribution information > ; |
The encoding of the Page Mode information is defined in sub-clause 12.20.
The general format of the ‘Distribution contents’ for distribution messages sent on the EC-PACCH is:
|
< Distribution contents > ::= < USED_DL_COVERAGE_CLASS : bit (2) > < specific distribution information > ; |
The encoding of the Used DL Coverage Class information is defined in sub-clause 12.71.
11.1.1.2 Non-distribution messages
A non-distribution message is recognised by the most significant bit of the message type being set to bit ‘0’. The general format of a message, except for non-distribution messages on the EC-PACCH, sent from the network to the mobile station is:
|
< Non-distribution message > ::= < MESSAGE_TYPE : 0 bit (5) > < Distribution contents > < Address information > < Non-distribution contents > < padding bits > ; |
The general format of a non-distribution message on the EC-PACCH sent from the network to the mobile station is:
|
< Non-distribution message > ::= < MESSAGE_TYPE : 0 bit (4) > < Distribution contents > < Address information > < Non-distribution contents > < padding bits > ; |
Any mobile station may receive a non-distribution message.
The ‘Distribution contents’ of a non-distribution message contains Page Mode information and any specific distribution information according to the syntax defined for the message type. The ‘Distribution contents’ of a non-distribution message on the EC-PACCH contains Used DL Coverage Class information instead of the Page Mode information. The general format of the ‘Distribution contents’ is defined in sub-clause 11.1.1.1. Depending on the protocol state of the mobile station, the ‘Distribution contents’ of a non‑distribution message shall be analysed as specified in clauses 5 and 7 of the present document.
The ‘Address information’ contained in a non-distribution message shall be analysed by a mobile station receiving the message. The ‘Non-distribution contents’ following the address information shall be ignored by any mobile station not identified by the address information. The allowed addressing options and the specific syntax of the ‘Non-distribution contents’ depend on the message type. The ‘padding bits’ of a non-distribution message can be reduced to the null string.
11.1.1.2.1 Format of the address information
The general format of the ‘Address information’ in a non-distribution message is:
|
< Address information > ::= 0 < Global TFI IE > | — see sub-clause 12.10 1 0 < TLLI / G-RNTI > | — see sub-clause 12.16 1 1 0 < TQI > | — see sub-clause 12.17 1 1 1 < Packet Request Reference IE > ; — see sub-clause 12.11 |
The description of a certain message type may specify a restricted set of addressing options being syntactically correct in the message. A message received with a disallowed addressing option shall be regarded as syntactically incorrect.
11.1.1.3 DBPSCH message (Iu mode only)
A DBPSCH message is sent exclusively on DBPSCH, from the network to the mobile station, in Iu mode. The general format of such a message is:
|
< DBPSCH message > ::= < DBPSCH message contents > < padding bits > ; |
The ‘padding bits’ of a DBPSCH message can be reduced to the null string.
The general format of the ‘DBPSCH message contents’ is:
|
< DBPSCH message contents > ::= < MESSAGE_TYPE : bit (6) > < specific DBPSCH message information > ; |
11.1.2 Error detection mechanism
The symbol ‘!’ indicates an error branch. It acts as a separator (similar to the ‘|’ choice symbol) where the choice on the right of the ‘!’ are to be considered as an ‘error’ branch. The symbol ‘!’ allows partial analysis of data in a received message, with some parts of the message to be ignored due to it being syntactically incorrect.
The description on the left of ‘!’ defines the set of syntactically correct data and shall be recognised correctly. Otherwise, the data associated shall be rejected and the description within the error branch shall be used.
The description within the error branch, on the right of ‘!’, shall accept any syntactically incorrect data. Therefore, according to the error label the relevant error handling procedure shall be implemented.
11.1.3 Error labels
There are different categories of error labels introduced in clauses 11 and 12 of the present document.
11.1.3.1 Generic error labels
Generic error labels are defined for syntactical errors ‘Unknown message type’, ‘Distribution part error’, ‘Address information part error’ and ‘Non-distribution part error’.
The general format of a distribution message (except for a distribution message on the EC-PACCH), including these error labels, is:
|
< Distribution message > ::= < MESSAGE_TYPE : 1 bit (5) > { < Distribution contents > < padding bits > ! < Distribution part error : bit (*) = < no string > > } ! < Unknown message type : bit (6) = < no string > < Default downlink message content > > ; |
The general format of a distribution message on the EC-PACCH, including these error labels, is:
|
< Distribution message > ::= < MESSAGE_TYPE : 1 bit (4) > { < Distribution contents > < padding bits > ! < Distribution part error : bit (*) = < no string > > } ! < Unknown message type : bit (5) = < no string > < Default downlink message content > > ; |
The general format of a non-distribution message (except for a non-distribution message on the EC-PACCH), including these error labels, is:
|
< Non-distribution message > ::= < MESSAGE_TYPE : 0 bit (5) > { < Distribution contents > { < Address information > { < Non-distribution contents > < padding bits > ! < Non-distribution part error : bit (*) = < no string > > } ! < Address information part error : bit (*) = < no string > > } ! < Distribution part error : bit (*) = < no string > > } ! < Unknown message type : bit (6) = < no string > < Default downlink message content > > ; |
The general format of a non-distribution message on the EC-PACCH, including these error labels, is:
|
< Non-distribution message > ::= < MESSAGE_TYPE : 0 bit (4) > { < Distribution contents > { < Address information > { < Non-distribution contents > < padding bits > ! < Non-distribution part error : bit (*) = < no string > > } ! < Address information part error : bit (*) = < no string > > } ! < Distribution part error : bit (*) = < no string > > } ! < Unknown message type : bit (5) = < no string > < Default downlink message content > > ; |
The general format of a DBPSCH message, including these error labels, is:
|
< DBPSCH message > ::= { < DBPSCH message contents > < padding bits > ! < DBPSCH message part error : bit (*) = < no string > > } ; |
These error labels allow ignoring a part of the message that is syntactically incorrect. Once an error is detected, the error branch is called. Except for the ‘Unknown message type’, the error branch is, followed by an unspecified bit string that expands to the end of the message. The corresponding data is ignored. In case of an ‘Unknown message type’, further treatment of the message is defined in sub-clause 11.1.4.1.
11.1.3.2 ‘Ignore’ error label
An ‘Ignore’ error label is used to ignore part of the message. The generic description is:
|
< content > ! < Ignore : bit (*) = < no string > > — Ignore by indefinite length |
Or
|
< content of fixed length n > ! < Ignore : bit (n) = < no string > > — Ignore by definite length |
An ‘Ignore’ error label shall be applied by the receiver of a downlink RLC/MAC control message when specified in the message description in clauses 11 and 12 of the present document. This error label allows ignoring a part of the message that is syntactically incorrect. Once the error is detected, the error branch ‘Ignore’ is called followed by an unspecified bit string.
When this error label is used with an indefinite length (bit (*) = < no string >), the unspecified bit string expands to the end of the message and the corresponding data is ignored.
NOTE: If this error label is used with the indefinite length within a structure or delimited description (i.e. within { } brackets), any description following the structure or delimited description must allow truncation, in order to be consistent with the CSN.1 description of the message.
When this error label is used with a definite length (bit (n) = < no string >), the unspecified bit string contains a defined number of bits. The corresponding data is ignored.
11.1.3.3 ‘Message escape’ error label
The ‘Message escape’ error label is used to provide an escape for, e.g. a future modification of the message syntax. The generic description is:
|
0 < Content > ! < Message escape : 1 bit (*) = < no string > > |
An ‘Message escape’ error label shall be applied by the receiver of a downlink RLC/MAC control message when specified in the message description in clauses 11 and 12 of the present document. The description on the left of the error branch needs to be correctly recognised. Otherwise, the error branch ‘Message escape’ is called and the remaining part of the message is ignored.
NOTE: Any description following a structure or delimited description (i.e. within { } brackets) including this error label must allow truncation. Otherwise, it is not consistent with the CSN.1 description of the message.
11.1.4 Error detection and order of precedence
A mobile station shall detect and process errors in the order in which they are defined in this sub-clause of the present document. (E.g. a message, which is not compatible with the current protocol state AND is syntactically incorrect, shall be treated as if it is not compatible with the current protocol state.)
At certain error events defined in this sub-clause, the PACKET TBF STATUS message shall be sent by the mobile station. In case of multiple error events, and, due to restrictions defined in sub-clauses 5, 6, 7, 8 and 9, the mobile station is not able to send a first status message until the occurrence of a subsequent event generating a second status message, the mobile station shall suppress the sending of the second and additional status messages until the first status message has been sent to the network.
11.1.4.1 Unknown message type
If a mobile station receives a message with message type either not defined or not implemented (generic error label: ‘Unknown message type’), the content of the bits representing the message type shall be ignored.
The remaining part of the message shall be analysed according to the syntax defined as the ‘Default downlink message content’ in sub-clause 11.2.0.1. The ‘Default downlink message content’ contains the Page Mode information. Depending on the protocol state of the mobile station, the Page Mode information shall be analysed as specified in clause 5 of the present document. The ‘Default downlink message content’ for a downlink message sent on the EC-PACCH contains the Used DL Coverage Class information instead of the Page Mode information.
11.1.4.2 Message not compatible with current protocol state
When a non-distribution message is received, which is not expected by the addressed receiver in its current protocol state, the mobile station shall follow the procedures that are described in sub-clauses 5, 6, 7, 8 and 9 of the present document.
If no such reaction is specified, the mobile station shall ignore the message. If in packet transfer mode, the mobile station, which is identified by the address information, shall return a status message (PACKET MOBILE TBF STATUS message) with TBF_CAUSE #4, "Message not compatible with current protocol state", unless the mobile station has an ongoing EC TBF.
Unexpected distribution messages are ignored.
11.1.4.3 Syntactically incorrect message
When a message containing a syntactically incorrect data is received, depending on the error detection mechanisms that may be defined in the CSN.1 description of the message, the message can be rejected or partially accepted.
NOTE: The order, in which the error labels mentioned in this sub-clause are detected and processed, depends on the nesting of error labels defined by the description of each message type in sub-clause 11.2 and clause 12. E.g. a message, which contains syntactically incorrect data in both the addressing information AND the non-distribution contents, is typically received with the error label ‘Address information part error’.
11.1.4.3.1 Messages with error label: ‘Distribution part error’
For syntactically incorrect messages received with generic error label: ‘Distribution part error’, data corresponding to the description following the error label shall be recognised as erroneous data and be ignored.
11.1.4.3.2 Messages with error label: ‘Address information part error’
For syntactically incorrect messages received with generic error label: ‘Address information part error’, data corresponding to the description following the error label shall be recognised as erroneous data and be ignored. The distribution contents preceding the error label may be analysed and treated as described in clause 5 and clause 7 of the present document.
11.1.4.3.3 Messages with error label: ‘Non-distribution part error’
For syntactically incorrect messages received with generic error label: ‘Non-distribution part error’, data corresponding to the description following the error label shall be recognised as erroneous data and be ignored.
The distribution contents preceding the error label may be analysed and treated as described in clause 5 and clause 7 of the present document.
The address information preceding the error label shall be analysed. In packet transfer mode, the mobile station identified by the address information shall return a PACKET MOBILE TBF STATUS message with TBF_CAUSE #2 "Syntactically incorrect message, non-distribution part error", unless the mobile station has an ongoing EC TBF.
11.1.4.3.4 Messages with error label: ‘Message escape’
For syntactically incorrect messages with error label: ‘Message escape’, data corresponding to the description following the error label shall be recognised as erroneously received mandatory data and be rejected.
The distribution contents preceding the error label may be analysed and treated as described in clause 5 of the present document.
If the address information proceeds the error label and it is received correctly, it shall be analysed. In packet transfer mode, the mobile station identified by the address information shall return a PACKET MOBILE TBF STATUS message with TBF_CAUSE #3 "Syntactically incorrect message, message escape", unless the mobile station has an ongoing EC TBF.
11.1.4.3.5 Messages with error label: ‘Ignore’
For syntactically incorrect messages with error label: ‘Ignore’, data corresponding to the description following the error label shall be recognised as unnecessary data. If a syntactically incorrect message with the ‘Ignore’ error label is received, depending on the length of the unspecified bit string associated with the error label (sub-clause 11.1.3.2), the corresponding data shall be ignored.
11.1.4.3.6 Messages with error label: "DBPSCH message part error"
For syntactically incorrect messages received with generic error label: ‘DBPSCH message part error’, data corresponding to the description following the error label shall be recognised as erroneous data and be ignored.
11.1.4.4 Syntactic error in truncated concatenation
Truncated concatenation is sequences of components encapsulated by the { } brackets followed by the symbol ‘//’. The concatenation is any of the concatenations starting with null and up to any number of components.
|
{ < a > < b > < c > } // |
The above set is equivalent to:
|
{ < a > < b > < c > } or { < a > < b > } or { < a > } or null |
Any syntactically incorrect component shall truncate the sequence. The correctly received components are accepted and the truncated components are ignored.
NOTE: If the ‘padding bits’ at the end of a message are included within the concatenation, truncation requires the resulting concatenation to fit exactly with the received message length. Otherwise, it is a syntactical error, which may cause rejection of the complete message or part thereof.