View source for My 3GPP TS 24.007 Notes

== 4 Introduction § 4.1 General ==
Five models are defined for Layer 3, one model for non-GPRS services, one for GPRS services supporting Class C MSs only, one model for GPRS-services supporting Class A and Class B MSs, one model for EPS services and '''one model for 5GS services over either 3GPP access or over non-3GPP access'''.

...
 
The layer 3 for 5GS services is composed of three sublayers comprising:
* the 5GS radio resource management (5GRR) functions for NAS over 3GPP access or the non-3GPP access functions for NAS over non-3GPP access;
* the 5GS mobility management (5GMM) functions; and
* the 5GS connection management (5GCM) functions.

The 5GS mobility management (5GMM) sublayer is composed of a functional block for:
* the 5GS mobility management (5GMM) functions.

The 5GS connection management (5GCM) sublayer is composed of a functional block for:
* the 5GS session management (5GSM) functions.

:NOTE:	For NAS over non-3GPP access, the non-3GPP access functions can be supported through functionalities defined in IETF RFC 7296 [30].

...

== 4 Introduction § 4.3	Technique of description ==

Layer 3 and its sub layers are specified by:
* their service specification, see clause 4.3.1;
* their protocol specification, see clause 4.3.3;
* the specification of functions, see clause 5.

=== 4.3.1 Service description ===

The services of signalling layer 3 and its sublayers are described in terms of:
* services provided to upper (sub )layers at the service access points;
* services assumed from lower (sub )layers at the service access points.
Layer 3 and its supporting lower layers provide the Mobile Network Signalling (MNS) Service and User Data Transfer (UDT) Service (for GPRS services only) to the upper layers.

The service provided/assumed at the service access points are described by means of abstract service primitives and parameters as recommended in ITU-T Recommendation X.200.

=== 4.3.3 Protocols and peer-to-peer communication ===
By use of the services provided by lower (sub )layers, peer entities in a (sub )layer in the MS and the network exchange information. Exchange of information between two peer entities is performed according to the corresponding (sub )layer protocols. A protocol is a set of rules and formats by which the information (control information and user data) is exchanged between the two peers. The information is exchanged by use of messages which are defined in the protocol. (Therefore, the messages are also called Protocol Data Units, PDUs).

There are several protocols of the RR sublayer, one protocol of the LLC sublayer, three protocols of the MM sublayer, and several protocols of the CM sublayer. For each functional block of the CM sublayer as defined in clause 4.1 there is one protocol. The CM protocols are specified in the Technical Specifications identified in clause 4.3.4.

In the model used in the present document, there are:

...
<ol type="1" start="5">
<li>for EPS services:
* one RR entity in the MS and one RR entity in the network;
* one EMM entity in the MS and one EMM entity in the network;
* for each functional block of the CM sublayer as defined in clause 4.1 which is supported in the MS (in the network), there are, depending on the protocol, one or more entities in the MS (in the network). Two different entities of the same functional block in the MS (in the network) are called parallel entities. The entities of the same functional block in the MS correspond in a one-to-one relation to the entities of the functional block in the network. The corresponding entities are called peer entities.</li>
<li>for 5GS services:
* one 5GRR entity in the MS and one 5GRR entity in the network for NAS over 3GPP access;
* one non-3GPP access management entity in the MS and one non-3GPP access interworking entity in the N3IWF for the NAS over non-3GPP access;
* one 5GMM entity in the MS and one 5GMM entity in the network;
* for each functional block of the 5GCM sublayer as defined in clause 4.1 which is supported in the MS (in the network), there are, depending on the protocol, one or more entities in the MS (in the network). Two different entities of the same functional block in the MS (in the network) are called parallel entities. The entities of the same functional block in the MS correspond in a one-to-one relation to the entities of the functional block in the network. The corresponding entities are called peer entities.</li>
</ol>

As each sub layer entity is specified by one and only one protocol, it is also called a protocol entity or protocol control entity.

For GPRS-services supporting Class A and Class B MSs, the MM entities of the MM-sublayer are able to exchange information by means of GMM PDUs as well as MM PDU's. This means if a mobile is GPRS attached, non-GPRS mobility management procedures may make use of GRPS mobility management messages.

When two peer protocol entities exchange PDUs, a transaction is said to be established (or: to be active; or: to exist). It depends from the protocol when exactly a protocol entity considers the transaction to be active, normally this is the case:
* from the moment when it has passed the first suitable message to lower (sub-) layers or received the first suitable message from its peer entity;
* up to the moment when it has released the transaction.

=== 4.3.4 Contents of layer 3 related Technical Specifications ===
<pre>
-	The Radio Resource (RR) management protocol is defined in 3GPP TS 44.018;
-	the Mobility Management (MM) protocol is defined in 3GPP TS 24.008;
-	the Session Management (SM) protocol is defined in 3GPP TS 24.008;
-	the Call Control (CC) protocol is defined in 3GPP TS 24.008;
-	the Supplementary Services (SS) protocol is defined in 3GPP TS 24.010, 3GPP TS 24.08x, 3GPP TS 24.09x, and 3GPP TS 24.030;
-	the Short Message Service (SMS) protocol is defined in 3GPP TS 24.011;
-	the Group Call Control (GCC) protocol is defined in 3GPP TS 44.068;
-	the Logical Link Control (LLC) protocol is defined in 3GPP TS 44.064;
-	the GPRS Radio Resource (GRR) protocol is defined in 3GPP TS 44.060 and 3GPP TS 24.008;
-	the CTS Radio Resource (CTS-RR) sub-protocol is defined in 3GPP TS 44.056;
-	the CTS Mobility Management (CTS-MM) sub-protocol is defined in 3GPP TS 44.056;
-	the CTS additions to the Call Control (CC) protocol are defined in 3GPP TS 44.056;
-	the Location Services (LCS) protocol for a type A LMU is defined in 3GPP TS 23.271 and 3GPP TS 44.071;
-	the EPS Radio Resource (RR) management protocol is defined in 3GPP TS 36.331;
-	the EPS Mobility Management (EMM) protocol is defined in 3GPP TS 24.301;
-	the EPS Session Management (ESM) protocol is defined in 3GPP TS 24.301;
-	the 5GS Radio Resource management (5GRR) protocol is defined in 3GPP TS 38.331;
-	the 5GS Mobility Management (5GMM) protocol is defined in 3GPP TS 24.501;
-	the 5GS Session Management (5GSM) protocol is defined in 3GPP TS 24.501;
-	the UE policy delivery service is defined in 3GPP TS 24.501;
-	the non-3GPP access management protocol is defined in 3GPP TS 24.502;
-	the PC5 signalling protocol is defined in 3GPP TS 24.587;
-	the Time-Sensitive Networking (TSN) Application Function (AF) to Device-Side TSN Translator (DS-TT) and Network-Side TSN Translator (NW-TT) protocol is defined in 3GPP TS 24.519;
-	the Performance Measurement Function (PMF) protocol is defined in 3GPP TS 24.193;
-	the PC3 and PC5 signalling protocol for Proximity-based Services (ProSe) are defined in 3GPP TS 24.334.
-	the PC3a and PC5 signalling protocol for 5G Proximity-based Services (ProSe) are defined in 3GPP TS 24.554.
-	the signalling protocol between the Application Client on the constrained UE and the MSGin5G Client on the MSGin5G Gateway UE for Enabling MSGin5G Service is defined in 3GPP TS 24.538.</pre>

== 5 Structure of layer 3 functions § 5.1 Basic groups of functions ==

Most functions of layer 3 and its sub layers are described by the service specifications and protocol specifications of the (sub )layers.

These functions are in the model realized by protocol control entities, see clause 4.3.3.

In addition, routing functions are contained in layer 3 which are related to the transport of messages, e.g. multiplexing and splitting. These routing functions are defined in the Radio Resource Management or in the 5GRR (for NAS over 3GPP access) or non-3GPP access management (for NAS over non-3GPP access) and Mobility Management or 5GMM sub layers.

# They have the task to pass the messages from upper (sub )layers to lower (sub )layers.
# They also have the task to pass messages provided by lower (sub-layers) to the appropriate sub-layer and, if applicable, entity.

The routing functions with task 2 make use of the protocol discriminator (PD) which is part of the message header.

A CM sublayer protocol may also define a transaction identifier (TI), procedure transaction identity (PTI) or EPS bearer identity as a part of the message header. This is at least the case if there are parallel entities of the same functional block, see clause 4.3.3. If they are a part of a message, the TI, PTI, EPS bearer identity, or both PTI and EPS bearer identity are also used by the routing functions.

* The MM-sublayer routing function passes the messages of the CM entities as well as of the MM, GMM and CTS-MM entities of its own sublayer to the service access point of RR, GRR, LLC or CTS-RR. Furthermore it multiplexes them in case of parallel transactions.
* The routing function of Radio Resource Management distributes the messages to be sent according to their message type and protocol discriminator (PD), to the actual channel configuration, and, if applicable, to further information received from upper sub-layers to the appropriate service access point of layer 2 (identified by SAPI and logical channel). Paging messages received from the PPCH are always routed to GMM, while paging messages received from the PCH are distributed to GMM or MM based on the temporary identifier (TMSI or TLL). For EPS services, the Paging messages received from the PCH are always routed to EMM.
* The messages provided at the different service access points of layer 2 are distributed by the RR sublayer routing function according to their protocol discriminator (PD). Messages with a PD equal to RR are passed to the RR entity of the own sublayer, all other messages are passed to the MM sublayer at the service access point RR-SAP.
* The routing function of MM-sublayer passes Standard L3 messages according to the protocol discriminator (PD) and, if applicable, the transaction identifier (TI) or the PDP address towards the MM entity or towards the CM entities via the various MM-SAP's. GPRS L3 messages are routed to mobility management or session management according to the protocol discriminator.
* For EPS services, the routing function of EPS NAS passes standard L3 messages according to the protocol discriminator (PD) and, if applicable, the procedure transaction identity (PTI) and/or EPS bearer identity towards the EMM entity or towards the CM (ESM) entities of the various EPS NAS SAP's.
* The routing function of LLC passes the messages according to the SAPIs to the MM sublayer or to the SNDCP entities.

For 5GS services, the routing functions with task 2 make use of the extended protocol discriminator (EPD) which is part of the message header, or PDU session identity.

A 5GCM sublayer protocol may also define a procedure transaction identity (PTI) as a part of the message header. This is at least the case if there are parallel entities of the same functional block, see clause 6.2.
* The 5GMM-sublayer routing function passes the messages of the 5GCM entities as well as of the 5GMM entities of its own sublayer to the service access point of 5GRR. Furthermore, it multiplexes them in case of parallel transactions.
* For NAS over 3GPP access, the NR or E-UTRA AS sublayer routing function distributes the messages to be sent according to their message type and extended protocol discriminator (EPD), to the actual channel configuration, and, if applicable, to further information received from upper sub-layers to the appropriate service access point of layer 2. Paging messages received from the PCH are always routed to 5GMM.
* For NAS over 3GPP access, the messages provided at the different service access points of layer 2 are distributed by the 5GRR sublayer routing function according to their extended protocol discriminator (EPD). Messages with a EPD equal to RR are passed to the 5GRR entity of the own sublayer, all other messages are passed to the 5GMM sublayer at the service access point 5GRR-SAP.
* For NAS over non-3GPP access:
** for initial registration, EAP-5G is used to transfer NAS messages between the peer entities of the 5GMM sublayers;
** after successful initial registration, IPSec transport mode and GRE will be used to encapsulate and un-encapsulate the NAS messages between the peer entities of the 5GMM sublayers.
* For 5GS services, the routing function of 5GS NAS passes standard L3 messages according to the protocol discriminator (PD) and, if applicable, the PDU session identity towards the 5GMM entity or towards the 5GSM entities of the various 5GS NAS SAPs.

The message (message header or other parts of the message) are neither changed nor removed by the RR routing function or non-3GPP access management or MM routing function or 5GMM routing function before passing it to the appropriate service access point.

== 5.2 Protocol architecture ==

See spec for details and visuals...

== 11 L3 Messages § 11.2 Standard L3 messages ==

See spec for details...

=== 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:
* <span style="color:blue">an information element identifier (IEI)</span>;
* <span style="color:blue">a length indicator (LI)</span>;
* <span style="color:blue">a value (V) part</span>.

A standard IE has one of the formats shown in table 11.1:

{| class="wikitable"
|+ 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:
;type 1:information elements of format V or TV with value part consisting of 1/2 octet
;type 2:information elements of format T with value part consisting of 0 octets
;type 3:information elements of format V or TV with value part that has fixed length of at least one octet
;type 4:information elements of format LV or TLV with value part consisting of zero, one or more octets and a maximum of 255 octets
;type 6: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. 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).

[[File:Type1 IE of format V.png|center|Figure 11.1 and 11.2 of Type 1 IE of format V]]

See spec for details...

==== 11.2.3.1 Standard L3 message header ====

...

For the 5GS protocols 5GMM and 5GSM, a standard L3 message can be <span style="color:red">either</span> <span style="color:red">a plain 5GS NAS message</span> or <span style="color:blue">a security protected 5GS NAS message</span>:
* <span style="color:red">The header of a plain 5GS NAS message</span> 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.
* <span style="color:blue">The header of a security protected 5GS NAS message</span> 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).

...

<center>[[Telecommunications info|To Telecommunications info]]</center>