11.2 Standard L3 messages
24.0073GPPGeneral AspectsMobile radio interface signalling layer 3Release 17TS
11.2.1 Components of a standard L3 message
A standard L3 message consists of an imperative part, itself composed of a header and the rest of imperative part, followed by a non-imperative part. Both the non-header part of the imperative part and the non-imperative part are composed of successive parts referred as standard information elements.
11.2.1.1 Format of standard information elements
A standard IE may have the following parts, in that order:
– an information element identifier (IEI);
– a length indicator (LI);
– a value part.
A standard IE has one of the formats shown in table 11.1:
Table 11.1: Formats of information elements
|
Format |
Meaning |
IEI present |
LI present |
Value part present |
|
T |
Type only |
yes |
no |
no |
|
V |
Value only |
no |
no |
yes |
|
TV |
Type and Value |
yes |
no |
yes |
|
LV |
Length and Value |
no |
yes |
yes |
|
TLV |
Type, Length and Value |
yes |
yes |
yes |
|
LV-E |
Length and Value |
no |
yes |
yes |
|
TLV-E |
Type, Length and Value |
yes |
yes |
yes |
Some IEs may appear in the structure, but not in all instances of messages. An IE is then said to be present or not present in the message instance. If an IE is not present in a message instance, none of the three parts is present. Otherwise, parts must be present according to the IE format.
In the message structure, an IE that is allowed not to be present in all message instances is said not to be mandatory. Other IEs are said to be mandatory.
LV-E and TLV-E are used for 5GS Mobility Management (5GMM), 5GS Session Management (5GSM), EPS Mobility Management (EMM), EPS Session Management (ESM), GPRS Mobility Management (GMM) and GPRS Session Management (SM) only. In GPRS GMM and GPRS SM messages, IEs of format LV-E and TLV-E may be used only after MS and network have successfully negotiated support of such IEs.
11.2.1.1.1 Information element type and value part
Every standard IE has an information element type which determines the values possible for the value part of the IE, and the basic meaning of the information. The information element type describes only the value part. Standard IEs of the same information element type may appear with different formats. The format used for a given standard IE in a given message is specified within the description of the message.
The value part of a standard IE either consists of a half octet or one or more octets; the value part of a standard IE with format LV or TLV consists of an integral number of octets, between 0 and 255 inclusive; it then may be empty, i.e., consist of zero octets; if it consists of a half octet and has format TV, its IEI consists of a half octet, too. For LV-E and TLV-E, the value part of a standard IE consists of an integral number of octets, between 0 and 65535 inclusive. The value part of a standard IE may be further structured into parts, called fields.
11.2.1.1.2 Length indicator
For LV or TLV, the length indicator (LI) of a standard IE consists of one octet. For LV-E and TLV-E, the LI of a standard IE consists of two octets where bit 8 of octet n contains the most significant bit and bit 1 of octet n+1 contains the least significant bit (refer to figure 11.9 in clause 11.2.1.1.4 for the relative ordering of the 2 octets). The LI contains the binary encoding of the number of octets of the IE value part. The LI of a standard IE with empty value part indicates 0 octets. Standard IE of an information element type such that the possible values may have different values must be formatted with a length field, i.e., LV, TLV, LV-E or TLV-E.
11.2.1.1.3 Information element identifier
When present, the IEI of a standard IE consists of a half octet or one octet. A standard IE with IEI consisting of a half octet has format TV, and its value part consists of a half octet. The value of the IEI depends on the standard IE, not on its information element type. The IEI, if any, of a given standard IE in a given message is specified within the description of the message. In some protocol specifications, default IEI values can be indicated. They are to be used if not indicated in the message specification. Non mandatory standard IE in a given message, i.e., IE which may be not be present (formally, for which the null string is acceptable in the message), must be formatted with an IEI, i.e., with format T, TV, TLV or TLV-E.
11.2.1.1.4 Categories of IEs; order of occurrence of IEI, LI, and value part
Totally five categories of standard information elements are defined:
– information elements of format V or TV with value part consisting of 1/2 octet (type 1);
– information elements of format T with value part consisting of 0 octets (type 2);
– information elements of format V or TV with value part that has fixed length of at least one octet (type 3);
– information elements of format LV or TLV with value part consisting of zero, one or more octets and a maximum of 255 octets (type 4);
– information elements of format LV-E or TLV-E with value part consisting of zero, one or more octets and a maximum of 65535 octets (type 6). This category is used in 5GS, EPS and GPRS only.
Type 1 standard information elements of format V provide the value in bit positions 8, 7, 6, 5 of an octet (see figure 11.1) or bits 4, 3, 2, 1 of an octet (see figure 11.2).
Figure 11.1: Type 1 IE of format V
Figure 11.2: Type 1 IE of format V
Type 1 standard information elements of format TV have an IEI of a half octet length; they provide the IEI in bit positions 8, 7, 6, 5 of an octet and the value part in bit positions 4, 3, 2, 1 of the same octet, see figure 11.3.
Figure 11.3: Type 1 IE of format TV
A type 2 standard IE has format T; its IEI consists of one octet, its value part is empty, see figure 11.4.
Figure 11.4: Type 2 IE
A type 3 standard information element has format V or TV; if it has format TV, its IEI consists of one octet and precedes the value part in the IE. The value part consists of at least one octet. See figure 11.5 and figure 11.6.
Figure 11.5: Type 3 IE of format V (k = 0, 1, 2, …)
Figure 11.6: Type 3 IE of format TV (k = 1, 2, …)
A type 4 standard information element has format LV or TLV. Its LI has one octet and precedes the value part, which consists of zero, one, or up to 255 octets; if present, its IEI has one octet length and precedes the LI. See figure 11.7 and figure 11.8.
Figure 11.7: Type 4 IE of format LV (k = 0, 1, 2, …)
Figure 11.8: Type 4 IE of format TLV (k = 1, 2, …)
A type 6 standard information element has format LV-E or TLV-E. Its LI has 2 octets and precedes the value part, which consists of zero, one or up to 65535 octets; if present, its IEI has one octet length and precedes the LI. See figure 11.9 and figure 11.10.
Figure 11.9: Type 6 IE of format LV-E (k = 1, 2, …)
Figure 11. 10: Type 6 IE of format TLV-E (k = 1, 2, …)
11.2.2 Description methods for IE structure
Standard IEs can be further structured in parts called fields. Two description methods are recommended and described hereafter.
11.2.2.1 Tables
According to this description method, the IE is presented in its maximum format, i.e., T, TV, TLV or TLV-E, in a picture representing the bits in a table, each line representing an octet. Bits appear in the occidental order, i.e., from left of the page to right of the page, and from top of the page to bottom of the page.
Boxes so delimited contains typically the field name, possibly an indication of which bits in the field are in the box, and possibly a value (e.g., for spare bits).
A specific method can be used in the IE description to describe a branching structure, i.e., a structure variable according to the value of particular fields in the IE. This design is unusual outside type 4 and type 6 IEs, and as, a design rule, should be used only in type 4 and type 6 IEs.
a) The octet number of an octet within the IE is defined typically in the table. It consists of a positive integer, possibly of an additional letter, and possibly of an additional asterisk, see clause f). The positive integer identifies one octet or a group of octets.
b) Each octet group is a self contained entity. The internal structure of an octet group may be defined in alternative ways.
c) An octet group is formed by using some extension mechanism. The preferred extension mechanism is to extend an octet (N) through the next octet(s) (Na, Nb, etc.) by using bit 8 in each octet as an extension bit.
– The bit value "0" indicates that the octet group continues through to the next octet. The bit value "1" indicates that this octet is the last octet of the group. If one octet (Nb) is present, the preceding octets (N and Na) shall also be present.
– In the format descriptions of the individual information elements, bit 8 is marked "0/1 ext" if another octet follows. Bit 8 is marked "1 ext" if this is the last octet in the extension domain.
– Additional octets may be defined in later versions of the protocols ("1 ext" changed to "0/1 ext") and equipments shall be prepared to receive such additional octets; the contents of these octets shall be ignored. However the length indicated in the formal description of the messages and of the individual information elements only takes into account this version of the protocols.
d) In addition to the extension mechanism defined above, an octet (N) may be extended through the next octet(s) (N+1, N+2 etc.) by indications in bits 7-1 (of octet N).
e) The mechanisms in c) and d) may be combined.
f) Optional octets are marked with asterisks (*). As a design rule, the presence or absence of an optional octet should be determinable from information in the IE and preceding the optional octet. Care should be taken not to introduce ambiguities with optional octets.
g) At the end of the IE, additional octets may be added in later versions of the protocols also without using the mechanisms defined in c) and d). Equipments shall be prepared to receive such additional octets; the contents of these octets shall be ignored. However the length indicated in the formal description of the messages and of the individual information elements only takes into account this version of the protocols.
11.2.2.1.1 Compact notation
The compact notation described in Annex B can be used to describe the value part of a standard IE. This method is recommended for complex structures, or for a branching structure not respecting octet boundaries.
11.2.3 Imperative part of a standard L3 message
The imperative part of a standard L3 message is composed of a header possibly followed by mandatory standard IEs having the format V, LV or LV-E.
11.2.3.1 Standard L3 message header
For the MM, GMM, CC and SM protocols defined in 3GPP TS 24.008 [6], the header of a standard L3 message is composed of two octets, and structured in three main parts, the protocol discriminator (1/2 octet), a message type octet, and a half octet used in some cases as a Transaction Identifier, in some other cases as a sub-protocol discriminator, and called skip indicator otherwise.
For the EPS protocols EMM and ESM, a standard L3 message can be either a plain NAS message or a security protected NAS message:
– The header of a plain NAS message is composed of two or three octets, and structured in four main parts, the protocol discriminator (1/2 octet), a half octet used in some cases as security header type and in other cases as an EPS bearer identity (1/2 octet), a message type octet, and one octet included in some cases and used as a procedure transaction identity (PTI). If the procedure transaction identity is present, it is preceding the message type octet.
– The header of a security protected NAS message is composed of six octets, and structured in four main parts, the protocol discriminator (1/2 octet), a half octet used as security header type, a message authentication code of four octets, and a sequence number of one octet. This header is followed by a complete plain NAS message (i.e. including the header of this plain NAS message).
For the 5GS protocols 5GMM and 5GSM, a standard L3 message can be either a plain 5GS NAS message or a security protected 5GS NAS message:
– The header of a plain 5GS NAS message is composed of three octets for 5GMM NAS messages and composed of four octets for 5GSM NAS messages, and structured in four main parts, namely, the extended protocol discriminator (1 octet); an octet used as security header type (1/2 octet) plus a spare half octet in case of 5GMM NAS messages, and a PDU session identity of one octet in case of 5GSM NAS messages; an octet for procedure transaction identity (PTI) in case of 5GSM NAS messages; and one octet for message type. If the procedure transaction identity is present, it is preceding the message type octet.
– The header of a security protected 5GS NAS message is composed of seven octets, and structured in four main parts, the extended protocol discriminator (1 octet), an octet used as security header type (1/2 octet) plus a spare half octet, a message authentication code of four octets, and a sequence number of one octet. This header is followed by a complete plain 5GS NAS message (i.e. including the header of this plain 5GS NAS message).
11.2.3.1.1 Protocol discriminator
Bits 1 to 4 of the first octet of a standard L3 message contain the protocol discriminator (PD) information element. The PD (with exception of "extension of the PD to one octet length") identifies the L3 protocol to which the standard layer 3 message belongs. The correspondence between L3 protocols and PDs (with exception of "extension of the PD to one octet length") is one-to-one.
When the PD is set to "extension of the PD to one octet length", the first octet of a standard L3 message contains the extended protocol discriminator (EPD) information element as specified in clause 11.2.3.1.1A.
The PD can take the following values:
Table 11.2: Protocol discriminator values
|
bits 4 3 2 1 |
|||
|
0 0 0 0 |
group call control |
||
|
0 0 0 1 |
broadcast call control |
||
|
0 0 1 0 |
EPS session management messages |
||
|
0 0 1 1 |
call control; call related SS messages |
||
|
0 1 0 0 |
GPRS Transparent Transport Protocol (GTTP) |
||
|
0 1 0 1 |
mobility management messages |
||
|
0 1 1 0 |
radio resources management messages |
||
|
0 1 1 1 |
EPS mobility management messages |
||
|
1 0 0 0 |
GPRS mobility management messages |
||
|
1 0 0 1 |
SMS messages |
||
|
1 0 1 0 |
GPRS session management messages |
||
|
1 0 1 1 |
non call related SS messages |
||
|
1 1 0 0 |
Location services specified in 3GPP TS 44.071 [8a] |
||
|
1 1 1 0 |
extension of the PD to one octet length |
||
|
1 1 1 1 |
used by tests procedures described in 3GPP TS 44.014 [5a], 3GPP TS 34.109 [17a], 3GPP TS 36.509 [26] and 3GPP TS 38.509 [29]. |
||
If the network receives, on a SAP where it expects standard L3 messages, a message with a protocol discriminator different from those specified in table 11.2, the network may ignore the message or initiate the channel release procedure defined in 3GPP TS 44.018 [6b].
If the Mobile Station receives, on a SAP where it expects standard L3 messages, a standard L3 message with a protocol discriminator different from those specified in table 11.2, or for a protocol that it does not support, the Mobile Station shall ignore the message.
11.2.3.1.1A Extended protocol discriminator (EPD)
When the PD is set to "extension of the PD to one octet length" as specified in clause 11.2.3.1.1, bits 1 to 8 of the first octet of a standard L3 message contain the extended protocol discriminator (EPD) information element.
The EPD identifies the L3 protocol to which the standard layer 3 message belongs. The correspondence between L3 protocols and EPDs is one-to-one.
The EPD can take the values specified in table 11.2.3.1.1A.1.
Table 11.2.3.1.1A.1: EPD values
|
EPD value (octet 1, bit 1 to bit 8) |
||||||||
|
Bits |
||||||||
|
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
|
0 |
0 |
0 |
0 |
1 |
1 |
1 |
0 |
reserved |
|
0 |
0 |
0 |
1 |
1 |
1 |
1 |
0 |
reserved |
|
0 |
0 |
1 |
0 |
1 |
1 |
1 |
0 |
5GS session management messages |
|
0 |
0 |
1 |
1 |
1 |
1 |
1 |
0 |
reserved |
|
0 |
1 |
0 |
0 |
1 |
1 |
1 |
0 |
reserved |
|
0 |
1 |
0 |
1 |
1 |
1 |
1 |
0 |
reserved |
|
0 |
1 |
1 |
0 |
1 |
1 |
1 |
0 |
reserved |
|
0 |
1 |
1 |
1 |
1 |
1 |
1 |
0 |
5GS mobility management messages |
|
1 |
0 |
0 |
0 |
1 |
1 |
1 |
0 |
reserved |
|
1 |
0 |
0 |
1 |
1 |
1 |
1 |
0 |
reserved |
|
1 |
0 |
1 |
0 |
1 |
1 |
1 |
0 |
reserved |
|
1 |
0 |
1 |
1 |
1 |
1 |
1 |
0 |
reserved |
|
1 |
1 |
0 |
0 |
1 |
1 |
1 |
0 |
reserved |
|
1 |
1 |
0 |
1 |
1 |
1 |
1 |
0 |
reserved |
|
1 |
1 |
1 |
0 |
1 |
1 |
1 |
0 |
reserved |
|
1 |
1 |
1 |
1 |
1 |
1 |
1 |
0 |
reserved |
|
NOTE: Bits 4 to 1 of each EPD value contain "extension of the PD to one octet length" as specified in clause 11.2.3.1.1. |
||||||||
If the network receives, on a SAP where it expects standard L3 messages, a message with an EPD different from those specified in table 11.2.3.1.1A.1, the network may ignore the message, may initiate the RRC connection release procedure defined in 3GPP TS 36.331 [24], or may initiate the RRC connection release procedure defined in 3GPP TS 38.331 [28].
If the Mobile Station receives, on a SAP where it expects standard L3 messages, a standard L3 message with an EPD different from those specified in table 11.2.3.1.1A.1, or for a protocol that it does not support, the Mobile Station shall ignore the message.
11.2.3.1.2 Skip indicator
Bits 5 to 8 of octet 1 of a standard L3 message may be used differently, depending on the protocol and the SAP. The use of this half-octet is consistent for a given PD and SAP. One possibility is that this half-octet contains the skip indicator. Another possibility is that this half-octet is a part of EPD as specified in clause 11.2.3.1.1A. Unless otherwise specified in the protocol, the skip indicator IE is a spare field.
11.2.3.1.3 Transaction identifier
A L3 protocol may define that bits 5 to 8 of octet 1 of a standard L3 message of the protocol contains the transaction identifier (TI). The TI allows to distinguish up to 16 different bi-directional messages flows for a given PD and a given SAP. Such a message flow is called a transaction.
An extension mechanism for TI is also defined. This mechanism allows to distinguish up to 256 different bi-directional messages flows for a given PD and a given SAP. The extension mechanism shall not be used unless explicitly stated in the core specification(s) for the protocol. The TI IE is coded as shown in figure 11.9 and table 11.3. It is composed of the TI value and the TI flag.
The TI value and the TI flag occupy bits 5 – 7 and bit 8 of the first octet respectively.
The extended TI shall not be used unless TI values of 7 or greater are needed.
Where the extended TI is used, the TI IE includes a second octet. The TI value in the first octet is ignored, and the TI value is encoded in bits 7-1 of the second octet.
NOTE: In other specifications, in respect to error handling, there are references to TI value "111". This refers to the binary encoding of bits 5 –7 in octet 1. For protocols which do not use the extended TI this ‘111’ encoding is still handled as an error case.Transactions are dynamically created, and their TI value is assigned at creation time. TI values are assigned by the side of the interface initiating a transaction. At the beginning of a transaction a free TI value (i.e., a value not yet used for the given PD, the given SAP, and with the given initiator) is chosen and assigned to this transaction. It then remains fixed for the lifetime of the transaction. After a transaction ends, the associated TI value is free and may be reassigned to a later transaction.
Two identical TI values may be used when each value pertains to a transaction initiated by the different sides of the interface. In this case the TI flag shall avoid ambiguity. The transaction identifier flag can take the values "0" or "1". The TI flag is used to identify which side of the interface initiated the transaction. A message has a TI flag set to "0" when it belongs to transaction initiated by its sender, and to "1" otherwise.
Hence the TI flag identifies who allocated the TI value for this transaction and the only purpose of the TI flag is to resolve simultaneous attempts to allocate the same TI value.
The TI extension mechanism may in future evolution of the L3 protocols be further extended by setting the EXT flag in octet 2 to "0" (see figure 11.9).
|
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
||
|
TI flag |
TIO |
– |
– |
– |
– |
Octet 1 |
|||
|
1 EXT |
TIE |
Octet 2 * |
|||||||
Figure 11.9: Transaction identifier
Table 11.3: Transaction identifier
|
TI flag (octet 1) |
|
|
Bit |
|
|
8 |
|
|
0 |
The message is sent from the side that originates the TI |
|
1 |
The message is sent to the side that originates the TI |
|
TIO (octet 1) |
|
|
Bits |
|
|
7 6 5 |
|
|
0 0 0 |
TI value 0 |
|
0 0 1 |
‑ ‑ 1 |
|
0 1 0 |
‑ ‑ 2 |
|
0 1 1 |
‑ ‑ 3 |
|
1 0 0 |
‑ ‑ 4 |
|
1 0 1 |
‑ ‑ 5 |
|
1 1 0 |
‑ ‑ 6 |
|
1 1 1 |
The TI value is given by the TIE in octet 2 |
|
TIE (octet 2) |
|
|
Bits 7-1 |
|
|
0000000 0000001 0000010 0000011 0000100 0000101 0000110 |
Reserved. |
|
All other values |
The TI value is the binary representation of TIE Where bit 7 is the most significant bit And bit 1 is the least significant bit |
11.2.3.1.4 Sub-protocol discriminator
A L3 protocol may define that bits 5 to 8 of octet 1 of a standard L3 message of the protocol contains the sub-protocol discriminator (SPD). The SPD allows to distinguish between different protocols inside one sublayer.
Table 11.4: Sub-Protocol discriminator values
|
bits 8 7 6 5 |
|
|
0 0 0 0 |
Value used by the Skip Indicator (see 11.2.3.1.2) |
|
0 0 0 1 |
CTS sub-protocol |
|
0 0 1 0 |
\ |
|
To |
} all other values are reserved |
|
1 1 1 1 |
/ |
11.2.3.1.5 EPS bearer identity
A L3 protocol may define that bits 5 to 8 of octet 1 of a standard L3 message of the protocol contain the EPS bearer identity. The EPS bearer identity is used to identify a message flow.
|
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
||
|
EPS bearer identity value |
– |
– |
– |
– |
octet 1 |
||||
Figure 11.9a: EPS bearer identity
Table 11.5: EPS bearer identity
|
EPS bearer identity value (octet 1) |
||||
|
Bits |
||||
|
8 |
7 |
6 |
5 |
|
|
0 |
0 |
0 |
0 |
No EPS bearer identity assigned |
|
0 |
0 |
0 |
1 |
EPS bearer identity value 1 |
|
0 |
0 |
1 |
0 |
EPS bearer identity value 2 |
|
0 |
0 |
1 |
1 |
EPS bearer identity value 3 |
|
0 |
1 |
0 |
0 |
EPS bearer identity value 4 |
|
0 |
1 |
0 |
1 |
EPS bearer identity value 5 |
|
0 |
1 |
1 |
0 |
EPS bearer identity value 6 |
|
0 |
1 |
1 |
1 |
EPS bearer identity value 7 |
|
1 |
0 |
0 |
0 |
EPS bearer identity value 8 |
|
1 |
0 |
0 |
1 |
EPS bearer identity value 9 |
|
1 |
0 |
1 |
0 |
EPS bearer identity value 10 |
|
1 |
0 |
1 |
1 |
EPS bearer identity value 11 |
|
1 |
1 |
0 |
0 |
EPS bearer identity value 12 |
|
1 |
1 |
0 |
1 |
EPS bearer identity value 13 |
|
1 |
1 |
1 |
0 |
EPS bearer identity value 14 |
|
1 |
1 |
1 |
1 |
EPS bearer identity value 15 |
11.2.3.1.6 Security header type
For EPS protocols, a L3 protocol may define that bits 5 to 8 of octet 1 of a standard L3 message of the protocol contain the security header type.
For 5GS protocols, a L3 protocol may define that bits 1 to 4 of octet 2 of a standard L3 message of the protocol contain the security header type.
11.2.3.1a Procedure transaction identity
A L3 protocol may define that a standard L3 message of the protocol contains the procedure transaction identity (PTI). The PTI allows distinguishing up to 254 different bi-directional messages flows for a given PD and a given SAP. Such a message flow is called a transaction. The procedure transaction identity is released when the procedure is completed.
Table 11.6: Procedure transaction identity
|
Bits |
|||||||||
|
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
||
|
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
No procedure transaction identity assigned |
|
|
0 |
0 |
0 |
0 |
0 |
0 |
0 |
1 |
\ |
|
|
to |
} Procedure transaction identity value |
||||||||
|
1 |
1 |
1 |
1 |
1 |
1 |
1 |
0 |
/ |
|
|
1 |
1 |
1 |
1 |
1 |
1 |
1 |
1 |
Reserved |
|
11.2.3.1b PDU session identity
A L3 protocol may define that octet 2 of a standard L3 message of the protocol contains the PDU session identity. The PDU session identity is used to identify a PDU session.
The range of PDU session identity values indicated in table 11.2.3.1c.1 is shared between the PDU sessions over 3GPP access and the PDU sessions over non-3GPP access.
|
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
||
|
PDU session identity |
octet 1 |
||||||||
Figure 11.2.3.1c.1: PDU session identity
Table 11.2.3.1c.1: PDU session identity
|
PDU session identity value (octet 1, bit 1 to bit 8) |
||||||||
|
Bits |
||||||||
|
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
|
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
No PDU session identity assigned |
|
0 |
0 |
0 |
0 |
0 |
0 |
0 |
1 |
PDU session identity value 1 |
|
0 |
0 |
0 |
0 |
0 |
0 |
1 |
0 |
PDU session identity value 2 |
|
0 |
0 |
0 |
0 |
0 |
0 |
1 |
1 |
PDU session identity value 3 |
|
0 |
0 |
0 |
0 |
0 |
1 |
0 |
0 |
PDU session identity value 4 |
|
0 |
0 |
0 |
0 |
0 |
1 |
0 |
1 |
PDU session identity value 5 |
|
0 |
0 |
0 |
0 |
0 |
1 |
1 |
0 |
PDU session identity value 6 |
|
0 |
0 |
0 |
0 |
0 |
1 |
1 |
1 |
PDU session identity value 7 |
|
0 |
0 |
0 |
0 |
1 |
0 |
0 |
0 |
PDU session identity value 8 |
|
0 |
0 |
0 |
0 |
1 |
0 |
0 |
1 |
PDU session identity value 9 |
|
0 |
0 |
0 |
0 |
1 |
0 |
1 |
0 |
PDU session identity value 10 |
|
0 |
0 |
0 |
0 |
1 |
0 |
1 |
1 |
PDU session identity value 11 |
|
0 |
0 |
0 |
0 |
1 |
1 |
0 |
0 |
PDU session identity value 12 |
|
0 |
0 |
0 |
0 |
1 |
1 |
0 |
1 |
PDU session identity value 13 |
|
0 |
0 |
0 |
0 |
1 |
1 |
1 |
0 |
PDU session identity value 14 |
|
0 |
0 |
0 |
0 |
1 |
1 |
1 |
1 |
PDU session identity value 15 |
|
All other values are reserved (see NOTE). |
||||||||
|
NOTE: Values 64 up to and including 95 are used by the core network as specified in TS 29.571 [37] and are unavailable for future usage in NAS. |
||||||||
11.2.3.2 Message type octet
11.2.3.2.1 Message type octet (when accessing Release 98 and older networks only)
The message type octet is the second octet in a standard L3 message.
When a standard L3 message is expected, and a message is received that is less than 16 bit long, that message shall be ignored.
When the radio connection started with a core network node of a Release 98 or older network, the message type IE is coded as shown in figure 11.10a and 11.10x.
Bit 8 is encoded as "0"; value "1" is reserved for possible future use as an extension bit. A protocol entity expecting a standard L3 message, and receiving a message containing bit 8 of octet 2 encoded as "1" shall diagnose a " message not defined for the PD" error and treat the message accordingly.
In messages of MM, CC, SS (via CS domain), GCC and BCC protocol sent using the transmission functionality provided by the RR layer to upper layers, and sent from the mobile station or the LMU to the network, bit 7 of octet 2 is used for send sequence number, see clause 11.2.3.2.3.
In messages of the LCS protocol sent using the transmission functionality provided by the RR layer to upper layers, and sent from the type A LMU to the network, bit 7 of octet 2 is used for send sequence number, see clause 11.2.3.2.3.
In all other standard layer 3 messages, except for RR messages, bit 7 is set to a default value. A protocol entity expecting a standard L3 message, and not using the transmission functionality provided by the RR layer, and receiving a message containing bit 7 of octet 2 encoded different to the default value shall diagnose a "message not defined for the PD" error and treat the message accordingly.
The default value for bit 7 is 0 except for the SM protocol where the default value is 1. No default value for bit 7 is specified for RR protocol. For RR message types see 3GPP TS 44.018.
Figure 11.10a: Message type IE (MM, CC, SS, GCC, BCC and LCS)
Figure 11.10x: Message type IE (protocol other than MM, CC, SS, GCC, BCC and LCS)
For MM, CC, SS, GCC, BCC and LCS protocols bits 1 to 6 of octet 2 of standard L3 messages contain the message type. For all other L3 protocols bits 1 to 8 of octet 2 of standard L3 message contain the message type.
The message type determines the function of a message within a protocol in a given direction. The meaning of the message type is therefore dependent on the protocol (the same value may have different meanings in different protocols), and the direction (the same value may have different meanings in the same protocol, when sent from the Mobile Station to the network and when sent from the network to the Mobile Station).
Each protocol defines a list of allowed message types for each relevant SAP. A message received analysed as a standard L3 message, and with a message type not in the corresponding list leads to the diagnosis "message not defined for the PD". Some message types may correspond to a function not implemented by the receiver. They are then said to be not implemented by the receiver.
The reaction of a protocol entity expecting a standard L3 message and receiving a message with message type not defined for the PD or not implemented by the receiver and the reception conditions is defined in the relevant protocol specification. As a general rule, a protocol specification should not force the receiver to analyse the message further.
11.2.3.2.2 Message type octet (when accessing Release 99 and newer networks)
The message type octet is the second octet in a standard L3 message.
When a standard L3 message is expected, and a message is received that is less than 16 bit long, that message shall be ignored.
When the radio connection started with a core network node of a Release 99 or later network, the message type IE is coded dependent on the PD as shown in figures 11.10b, c and d.
In messages of MM, CC and SS (via CS domain) protocol sent using the transmission functionality provided by the RR and/or access stratum layer to upper layers, and sent from the mobile station or the LMU to the network, bits 7 and 8 of octet 2 are used for send sequence number, see clause 11.2.3.2.3.
In messages of GCC and BCC protocol sent using the transmission functionality provided by the RR layer to upper layers, and sent from the mobile station or the LMU to the network, only bit 7 of octet 2 is used for send sequence number. Bit 8 is set to the default value.
In messages of the LCS protocol sent using the transmission functionality provided by the RR layer to upper layers, and sent from the type A LMU to the network, only bit 7 of octet 2 is used for send sequence number. Bit 8 is set to the default value.
In all other standard layer 3 messages, except for RR messages, bits 7 and 8 are set to the default value. A protocol entity expecting a standard L3 message, and not using the transmission functionality provided by the RR and/or access stratum layer, and receiving a message containing bit 7 or bit 8 of octet 2 encoded different to the default value shall diagnose a "message not defined for the PD" error and treat the message accordingly.
In messages of the RR protocol entity, bit 8 of octet 2 is set to the default value. The other value is reserved for possible future use as an extension bit .If an RR protocol entity expecting a standard L3 message receives message containing bit 8 of octet 2 encoded different from the default value it shall diagnose a "message not defined for the PD" error and treat the message accordingly.
The default value for bit 8 is 0. The default value for bit 7 is 0 except for the SM protocol which has a default value of 1. No default value for bit 7 is specified for RR protocol. For RR message types see 3GPP TS 44.018.
For EPS; the default value for bit 7 is 1. The value for bit 8 is 0 for the EMM protocol and 1 for the ESM protocol.
For 5GS; the default value for bit 7 is 1. The value for bit 8 is 0 for the 5GMM protocol and 1 for the 5GSM protocol.
Figure 11.10b: Message type IE (MM, CC and SS)
Figure 11.10c: Message type IE (GCC, BCC and LCS)
Figure 11.10d: Message type IE (protocol other than MM, CC, SS, GCC, BCC and LCS)
For MM, CC, SS, GCC, BCC and LCS protocols bits 1 to 6 of octet 2 of standard L3 messages contain the message type. For all other L3 protocols bits 1 to 8 of octet 2 of standard L3 message contain the message type.
The message type determines the function of a message within a protocol in a given direction. The meaning of the message type is therefore dependent on the protocol (the same value may have different meanings in different protocols), and the direction (the same value may have different meanings in the same protocol, when sent from the Mobile Station to the network and when sent from the network to the Mobile Station).
Each protocol defines a list of allowed message types for each relevant SAP. A message received analysed as a standard L3 message, and with a message type not in the corresponding list leads to the diagnosis "message not defined for the PD". Some message types may correspond to a function not implemented by the receiver. They are then said to be not implemented by the receiver.
The reaction of a protocol entity expecting a standard L3 message and receiving a message with message type not defined for the PD or not implemented by the receiver and the reception conditions is defined in the relevant protocol specification. As a general rule, a protocol specification should not force the receiver to analyse the message further.
11.2.3.2.3 Sequenced message transfer operation
Upper layer messages sent using the RR sub-layer transport service from the mobile station to the network can be duplicated by the data link layer in at least the following cases:
– in A/Gb mode, when a channel change of dedicated channels is required (assignment or handover procedure) and the last layer 2 frame has not been acknowledged by the peer data link layer before the mobile station leaves the old channel;
– in Iu mode, when an RLC re-establishment occurs (e.g. due to relocation) and the RLC layer has not acknowledged the last one or more RLC PDUs before RLC re-establishment;
– an inter-system change from Iu mode to A/Gb mode is performed and the RLC layer has not acknowledged the last one or more RLC PDUs;
– an inter-system change from A/Gb mode to Iu mode is performed and the last layer 2 frame in A/Gb mode has not been acknowledged by the peer data link layer before the mobile station leaves the old channel.
In these cases, the mobile station does not know whether the network has received the messages correctly. Therefore, the mobile station has to send the messages again when the channel change is completed.
The network must be able to detect the duplicated received messages. Therefore, each concerned upper layer messages must be marked with a send sequence number.
To allow for different termination points in the infrastructure of the messages of different PDs, the sequence numbering is specific to each PD. For historical reasons, an exception is that messages sent with the CC, SS (via CS domain) and MM PDs share the same sequence numbering. In the following, the phrase upper layer message flow refers to a flow of messages sharing the same sequence numbering. The different upper layer flows are MM+CC+SS (via CS domain), GCC, BCC and LCS. The GMM, EMM, SM, ESM, SMS, SS (via PS domain) and TC (Test Control, see 3GPP TS 44.014 [5a], 3GPP TS 34.109 [17a] and 3GPP TS 36.509 [26]) protocols do not use layer 3 sequence numbering.
In a shared network with a MOCN configuration, Network Sharing non-supporting UEs can be redirected between CN operators (see 3GPP TS 23.251 [22]). When the redirection takes place, the CN node of the redirecting CN operator shall forward via the RAN the value of N(SD) of the last message received on the MM+CC+SS (via CS domain) message flow to the CN node of the next CN operator (3GPP TS 25.413 [23]).
11.2.3.2.3.1 Variables and sequence numbers
11.2.3.2.3.1.1 Send state variable V(SD)
The mobile station shall have one associated send state variable V(SD) ("Send Duplicated") for each upper layer message flow. The send state variable denotes the sequence number of the next in sequence numbered message in the flow to be transmitted. The value of the corresponding send state variable shall be incremented by one with each numbered message transmission.
For the MM+CC+SS (via CS domain) upper layer message flow:
– when the RR connection starts with a core network of Release 98 or earlier, arithmetic operations on V(SD) are performed modulo 2. The mobile station shall keep using modulo 2 for the duration of the RR connection;
– when the RR connection starts with a core network of Release 99 or later, arithmetic operations on V(SD) are performed modulo 4. The mobile station shall keep using modulo 4 for the duration of the RR connection;
– after successful completion of SRVCC handover (see 3GPP TS 23.216 [27]), the mobile station shall perform modulo 4 arithmetic operations on V(SD). The mobile station shall keep using modulo 4 until the release of the RR connection established at SRVCC handover.
NOTE 1: In A/Gb mode, the release supported by the core network is indicated in the MSCR bit and in the SGSNR bit in the system information broadcast (see 3GPP TS 44.018 [6b] and 3GPP TS 44.060 [10a]).
NOTE 2: During SRVCC handover the MSCR bit is not provided to the mobile station, and therefore the mobile station assumes to access to a Release 99 or later core network.
For the GCC, BCC, and LCS upper layer message flows, arithmetic operations on V(SD) are performed modulo 2.
11.2.3.2.3.1.2 Send sequence number N(SD)
At the time when such a message to be numbered is designated for transmission, the value of N(SD) for the message to be transferred is set equal to the value of the send state variable V(SD).
11.2.3.2.3.2 Procedures for the initiation, transfer execution and termination of the sequenced message transfer operation
11.2.3.2.3.2.1 Initiation
The sequenced message transfer operation is initiated by establishing a RR connection. The send state variables V(SD) are set to 0.
After successful completion of SRVCC handover (see 3GPP TS 23.216 [27]), the mobile station shall set the send state variable V(SD) to 0.
11.2.3.2.3.2.2 Transfer Execution
The core network shall compare the send sequence numbers of pairs of subsequent messages in the same upper layer messages flow.
For the GCC, BCC, and LCS upper layer message flows, in case the send sequence numbers of two subsequent messages in a flow are not identical, no duplication has occurred. In case the send sequence numbers are identical, the network must ignore the second one of the received messages.
For the MM+CC+SS (via CS domain) upper layer message flow:
– when accessed by a release 98 or earlier mobile station, in case the send sequence numbers of two subsequent messages in the flow are identical, the core network shall discard the second one of the received messages;
– when accessed by a release 99 or later mobile station, the core network shall discard any message whose N(SD) is not the increment by one (modulo 4) of the N(SD) of the last accepted message.
NOTE: The release supported by the mobile station is indicated by the revision level in the Mobile Station Classmark 1 or Mobile Station Classmark 2 information element, or by the revision level indicator in the MS network capability information element (see 3GPP TS 24.008, clause 10.5).
In a shared network with a MOCN configuration, the core network node to which the mobile station was redirected shall compare the send sequence number of the first message received after the redirection in the MM+CC+SS (via CS domain) message flow with the value of N(SD) received during the redirection procedure (see 3GPP TS 23.251 [22]):
– when accessed by a release 98 or earlier mobile station, if the two send sequence numbers are identical, the core network shall discard the received message from the mobile station;
– when accessed by a release 99 or later mobile station, the core network shall discard any message whose N(SD) is not the increment by one (modulo 4) of the N(SD) received during the redirection procedure.
11.2.3.2.3.2.3 Termination
The sequenced message transfer operation is terminated by the RR connection release procedure.
Inter system change from A/Gb mode to Iu mode or from Iu mode to A/Gb mode shall not terminate the sequenced message transfer. UMTS SRNC relocation shall not terminate the sequenced message transfer.
11.2.3.3 Standard information elements of the imperative part
The message type octet of a standard L3 message may be followed by mandatory standard IEs having the format V, LV or LV-E as specified in the message description in the relevant protocol specification.
As a design rule, octet boundaries must be respected. This implies that half-octet standard IEs (i.e., V formatted type 1 standard IEs) must appear by pair. The first half-octet IE occupies bits 1 to 4 of octet N, the second half-octet IE bits 5 to 8 of octet N, the third half-octet IE bits 1 to 4 of octet N + 1 etc. If the number of half-octet IEs is odd then bits 5 to 8 of the last octet occupied by these half-octet IEs contains a spare half-octet IE in format V.
If message is received as a standard L3 message, and that is too short to contain the complete imperative part as specified in the relevant protocol specification, an imperative message part error is diagnosed. (The same error may be diagnosed at detection of certain contents of the imperative part of a message; this is defined in the relevant protocol specification.) The treatment of an imperative message part error is defined in the relevant protocol specification.
11.2.4 Non-imperative part of a standard L3 message
The imperative part of a standard L3 message is followed by the (possibly empty) non-imperative part. The relevant protocol specification defines where the imperative part of a standard L3 message ends. The non-imperative part of a standard L3 message is composed of (zero, one, or several) standard IEs having the format T, TV, TLV or TLV-E. The receiver of a standard L3 message shall analyse the non imperative part as a succession of standard IEs each containing an IEI, and shall be prepared for the non-imperative part of the message to contain standard IEs that are not specified in the relevant protocol specification.
An IEI may be known in a message or unknown in a message. Each protocol specification lists, for each message (i.e., according to the message type, the direction and the lower layer SAP), the known standard IEs in the non-imperative part.
An IEI that is known in a message designates the IE type of the IE the first part of which the IEI is, as well as the use of the information. Which IE type it designates is specified in the relevant protocol specification. Within a message, different IEIs may designate the same IE type if that is defined in the relevant protocol specification.
Whether the second part of an IE with IEI known in a message is the length or not (in other words, whether the IEI is the first part of an IE formatted as TLV, TLV-E or not) is specified in the relevant protocol specification.
Unless otherwise specified in the protocol specification, the receiver shall assume that IE with unknown IEI are TV formatted type 1, T formatted type 2, TLV formatted type 4 or TLV-E formatted type 6 standard IEs. The IEI of unknown IEs together with, when applicable, the length indicator, enable the receiver to determine the total length of the IE, and then to skip unknown IEs. The receiver shall assume the following rule for IEs with unknown IEI:
Bit 8 of the IEI octet is set to "1" indicates a TV formatted type 1 standard IE or a T formatted type 2 IEs. Hence, a 1 valued bit 8 indicates that the whole IE is one octet long.
Furthermore, for the EPS protocols EMM and ESM:
Bit 8 of the IEI octet set to "0" and bits 7 to 4 set to "1" indicates a TLV-E formatted type 6 IE, i.e. the following two octets are length octets. Bit 8 of the IEI octet set to "0" and bit 7 to 4 set to any other bit combination indicates a TLV formatted type 4 IE, i.e. the following octet is a length octet.
Furthermore, for the 5GS protocols 5GMM and 5GSM:
Bit 8 of the IEI octet set to "0" and bits 7 to 5 set to "1" indicates a TLV-E formatted type 6 IE, i.e. the following two octets are length octets. Bit 8 of the IEI octet set to "0" and bit 7 to 5 set to any other bit combination indicates a TLV formatted type 4 IE, i.e. the following octet is a length octet.
IEI assignment in 3GPP TS 24.334 [36] shall comply with the above rule for the EPS protocols EMM and ESM.
IEI assignment in 3GPP TS 24.519 [33], 3GPP TS 24.587 [34], 3GPP TS 24.193 [35] and 3GPP TS 24.554 [38] shall comply with the above rule for the 5GS protocols 5GMM and 5GSM.
IEI assignment for UE policy delivery service in 3GPP TS 24.501 [31] shall comply with the above rule for the 5GS protocols 5GMM and 5GSM.
For all other protocols:
Bit 8 of the IEI octet set to "0" indicates a TLV formatted type 4 IE. Hence, the following octet is a length octet.
As a design rule, it is recommended that IEIs of any TV formatted type 1, T formatted type 2, TLV formatted type 4 or TLV-E formatted type 6 IE follow the rule, even if assumed to be known by all potential receivers.
As a design rule, it is recommended that no T formatted type 2 IE is added to the non-imperative part of a standard L3 message.
NOTE 1: Type 2 IEs restrict the number of possible type 1 IEs which can be used in a message and type 2 IEs cannot be extended or modified once introduced.
As a design rule, it is recommended that no new TV formatted type 3 IE is added to the non-imperative part of a standard L3 message except in the first release of a protocol specification which specifies the standard L3 message.
NOTE 2: For example, for the 5GS protocols 5GMM and 5GSM, Release 15 is the first release of a protocol specification for REGISTRATION REQUEST message.
A message may contain two or more IEs with equal IEI. Two IEs with the same IEI in a same message must have the same format, and, when of type 3, the same length. More generally, care should be taken not to introduce ambiguities by using an IEI for two purposes. Ambiguities appear in particular when two IEs potentially immediately successive have the same IEI but different meanings and when both are non-mandatory. As a recommended design rule, messages should contain a single IE of a given IEI.
Each protocol specification may put specific rules for the order of IEs in the non-imperative part. An IE known in the message, but at a position non compliant with these rules is said to be out of sequence. An out of sequence IE is decoded according to the format, and, when of type 3 the length, as defined in the message for its IEI.
11.2.5 Presence requirements of information elements
The relevant protocol specification may define three different presence requirements (M, C, or O) for a standard IE within a given standard L3 message:
– M ("Mandatory") means that the IE shall be included by the sending side, and that the receiver diagnoses a "missing mandatory IE" error when detecting that the IE is not present. An IE belonging to the imperative part of a message has presence requirement M. An IE belonging to the non-imperative part of a message may have presence requirement M;
– C ("Conditional") means:
* that inclusion of the IE by the sender depends on conditions specified in the relevant protocol specification;
* that there are conditions for the receiver to expect that the IE is present and/or conditions for the receiver to expect that the IE is not present in a received message of a given PD, SAP and message type; these conditions depend only on the content of the message itself, and not for instance on the state in which the message was received, or on the receiver characteristics; they are known as static conditions;
* that the receiver detecting that the IE is not present when sufficient static conditions are fulfilled for its presence, shall diagnose a "missing conditional IE" error;
* that the receiver detecting that the IE is present when sufficient static conditions are fulfilled for its non-presence, shall diagnose an "unexpected conditional IE" error.
– Only IEs belonging to the non-imperative part of a message may have presence requirement C;
– O ("Optional") means that the receiver shall never diagnose a "missing mandatory IE" error, a "missing conditional IE" error, or an "unexpected conditional IE" error because it detects that the IE is present or that the IE is not present. (There may however be conditions depending on the states, resources, etc. of the receiver to diagnose other errors.) Only IEs belonging to the non-imperative part of a message may have presence requirement O.
Unless otherwise specified the presence of a IE of unknown IEI or of an out of sequence IE shall not lead by itself to an error. An alternative specification is the ‘comprehension required’ scheme. A type 4 IE is encoded as ‘comprehension required’ if bits 5, 6, 7 and 8 of its IEI are set to zero. A type 6 IE is encoded as ‘comprehension required’ if bit 8 is set to zero and bits 2, 3, 4, 5, 6, and 7 of its IEI are set to one.
NOTE: In earlier versions of this specification, type 6 IEs with IEI values 7C and 7D were defined as ‘comprehension required’. I.e., dependent on the protocol, receipt of such an IE by a UE or network implemented according to an earlier version of this specification can result in detection of an "invalid mandatory information" error. Therefore, IEIs 7C and 7D can be used for type 6 IEs only if the sender of the message knows that the receiver does not treat these IEs as unknown ‘comprehension required’ IEs.
The ‘comprehension required’ scheme is to be applied if explicitly indicated in the protocol specification. The reaction on the reception of an unknown or out of sequence IE coded as ‘comprehension required’ is specified in the relevant protocol specification.
11.2.6 Description of standard L3 messages
This clause describes a generic description method for standard L3 messages, the tabular description. Protocol specification may follow other methods.
A standard L3 message is described by a table listing the header elements and the standard IEs in the message. For each element is given:
– if applicable the IEI, in hexadecimal representation (one digit followed by and hyphen for TV formatted type 1, and two digits for the other cases);
– the name of the IE (this is used in particular for the description of conditional presence rules);
– the type of the information element, with a reference of where the internal structure of the value part is specified;
– the format of the standard IE (T, V, TV, LV, TLV, LV-E or TLV-E); and
– the length, or the range of lengths, of the whole standard IE, including when applicable the T and L parts.
The list of elements is given in the table in the order they appear in the resulting bit string, with the exception of half‑octet elements in the imperative part: half octets in a pair are inverted. This applies in particular for the two first header elements: the protocol discriminator appears first in a table describing a standard L3 message.