6.2 General on elementary 5GSM procedures
24.5013GPPNon-Access-Stratum (NAS) protocol for 5G System (5GS)Release 18Stage 3TS
6.2.1 Principles of PTI handling for 5GSM procedures
When the UE or the network initiates a transaction related procedure (i.e. a procedure consisting of more than one message and the messages are related), it shall include a valid PTI value in the message header of the request message or of the command message.
If a response message is sent as result of a received request message or a received command message, the sending entity shall include in the response message the PTI value received within the request message or within the command message (see examples in figure 6.2.1.1, figure 6.2.1.2, and figure 6.2.1.3).
If a command message is sent as result of a received request message, the sending entity shall include in the command message the PTI value received with the request message (see examples in figure 6.2.1.3).
If a command message is not sent as result of a received request message, the sending entity shall include in the command message the PTI value set to "no procedure transaction identity assigned" (see examples in figure 6.2.1.4).
Figure 6.2.1.1: UE-requested transaction related procedure accepted by the network
Figure 6.2.1.2: UE-requested transaction related procedure rejected by the network
Figure 6.2.1.3: UE-requested transaction related procedure triggering a network-requested transaction related procedure
Figure 6.2.1.4: network-requested transaction related procedure not triggered by a UE-requested transaction related procedure
6.2.2 PDU session types
The following PDU Session types are supported:
a) IPv4;
b) IPv6;
c) IPv4v6;
d) Ethernet (EtherType as defined in IEEE Std 802.3 [31A]); and
e) Unstructured.
IP address allocation for IPv4, IPv6 and IPv4v6 PDU session types is described in subclause 6.2.4.
Neither a MAC nor an IP address is allocated by the 5GCN to the UE for Ethernet PDU session type.
6.2.3 PDU session management
The SMF is responsible for the session management functions to provide the PDU connectivity service to the UE via the 5GSM signalling between UE and SMF. The session management procedures includes:
a) the UE-requested PDU session establishment procedure;
b) the PDU session authentication and authorization procedure;
c) the UE-requested PDU session modification procedure;
d) the network-requested PDU session modification procedure;
e) the UE-requested PDU session release procedure; and
f) the network-requested PDU session release procedure.
A UE may establish multiple PDU sessions, to the same data network or to different data networks, via 3GPP and via and Non-3GPP access networks at the same time.
The session management messages between UE and SMF are transferred via AMF as specified in subclause 8.3.
6.2.4 IP address allocation
6.2.4.1 General
This clause specifies IP address allocation for the PDU session.
In this release of specification, PDU session can be initiated with one IP version, i.e. IPv4 PDU session type or IPv6 PDU session type, or with both IP versions, i.e. IPv4v6 PDU session type.
IP address allocation to the UE shall be performed by SMF based on one or both the selected IP versions and operator policies. If IPv4 PDU session type is selected, an IPv4 address is allocated to the UE. If IPv6 PDU session type is selected, an IPv6 prefix except when the SMF acts according to subclause 6.2.4.3, and an interface identifier for the IPv6 link local address are allocated to the UE. If IPv4v6 PDU session type is selected, an IPv4 address, an IPv6 prefix except when the SMF acts according to subclause 6.2.4.3 or 6.2.4.4, and an interface identifier for the IPv6 link local address are allocated to the UE. If IPv6 or IPv4v6 PDU session type is selected in a PDU session established by the W-AGF acting on behalf of the FN-RG and the PDU SESSION ESTABLISHMENT REQUEST message contains the Suggested interface identifier IE, the SMF shall allocate to the UE the interface identifier for the IPv6 link local address indicated in the Suggested interface identifier IE.
For IPv4 PDU session type and for IPv4v6 PDU session type, the UE:
a) shall obtain an IPv4 address via:
1) NAS signalling as specified in subclause 6.2.4.2; or
2) DHCPv4 as specified in IETF RFC 2131 [33E]; and
b) may obtain IPv4 configuration parameters (e.g. DNS server address) via DHCPv4 as specified in IETF RFC 2132 [33F] or may receive IPv4 configuration parameters (e.g. DNS server address) as specified in subclause 6.4.1 and subclause 6.3.2.
For IPv6 PDU session type and for IPv4v6 PDU session type, the UE:
a) shall build an IPv6 link local address based on the allocated interface identifier for the IPv6 link local address;
b) shall obtain /64 IPv6 prefix via IPv6 stateless address autoconfiguration as specified in 3GPP TS 23.501 [8] and IETF RFC 4862 [39], except when the 5G-RG or the W-AGF act according to subclause 6.2.4.3; and
c) may obtain IPv6 configuration parameters via stateless DHCPv6 as specified in IETF RFC 8415 [33D], except when the 5G-RG or the W-AGF act according to subclause 6.2.4.3, may receive IPv6 configuration parameters (e.g. DNS server address) as specified in subclause 6.4.1 and subclause 6.3.2, or may receive DNS server IPv6 addresses in a Router Advertisement Message as specified in IETF RFC 4861 [38B] with recursive DNS server option as specified in IETF RFC 8106 [52].
6.2.4.2 IP address allocation via NAS signalling
The UE shall set the PDU session type IE in the PDU SESSION ESTABLISHMENT REQUEST message, based on its IP stack capabilities if the UE requests IP connectivity as follows:
a) A UE:
1) which is IPv6 and IPv4 capable, shall set the PDU session type IE to IPv4, IPv6 or IPv4v6 according to UE configuration or received policy.
2) which is only IPv6 capable, shall set the PDU session type IE to IPv6.
3) which is only IPv4 capable, shall set the PDU session type IE to IPv4.
b) When the IP version capability of the UE is unknown in the UE (as in the case when the MT and TE are separated and the capability of the TE is not known in the MT), the UE shall set the PDU session type IE to IPv4v6.
If the UE wants to use DHCPv4 for IPv4 address assignment, it shall indicate that to the network within the Extended protocol configuration options IE in the PDU SESSION ESTABLISHMENT REQUEST.
On receipt of the PDU SESSION ESTABLISHMENT REQUEST message sent by the UE, the network when allocating an IP address shall take into account the PDU session type IE, the operator’s policies of the network, and the user’s subscription data and:
a) if the network sets the Selected PDU session type IE to IPv4, the network shall include an IPv4 address in the PDU address IE;
b) if the network sets the Selected PDU session type IE to IPv6, the network shall include an interface identifier for the IPv6 link local address in the PDU address IE; and
c) if the network sets the Selected PDU session type IE to IPv4v6, the network shall include an IPv4 address and an interface identifier for the IPv6 link local address in the PDU address IE.
6.2.4.3 Additional RG related requirements for IP address allocation
If IPv6 PDU session type or IPv4v6 PDU session type is selected, an IPv6 address, one or more IPv6 prefixes or both are allocated to the 5G-RG or the W-AGF acting on behalf of the FN-RG (or on behalf of the N5GC device).
If the 5G-RG or the W-AGF acting on behalf of the FN-RG (or on behalf of the N5GC device) receives a Router Advertisement Message as specified in IETF RFC 4861 [38B] with the "Managed address configuration" flag set to zero, the 5G-RG and the W-AGF acting on behalf of the FN-RG (or on behalf of the N5GC device):
a) shall obtain /64 IPv6 prefix via IPv6 stateless address autoconfiguration as specified in 3GPP TS 23.501 [8] and IETF RFC 4862 [39];
b) may obtain IPv6 configuration parameters via stateless DHCPv6 as specified in IETF RFC 8415 [33D]; and
c) may request additional IPv6 prefixes using DHCPv6. If the 5G-RG and the W-AGF acting on behalf of the FN-RG (or on behalf of the N5GC device) request IPv6 prefixes using DHCPv6, the 5G-RG and the W-AGF acting on behalf of the FN-RG (or on behalf of the N5GC device) shall act as a "Requesting Router" as described in IETF RFC 8415 [33D], shall obtain IPv6 prefixes using the DHCPv6 Identity association for prefix delegation option as specified in IETF RFC 8415 [33D], may include DHCPv6 Rapid commit option as specified in IETF RFC 8415 [33D] in a DHCP message, and may include DHCPv6 OPTION_ORO option with the OPTION_PD_EXCLUDE option code as specified in IETF RFC 6603 [40A] in the DHCP message.
If the 5G-RG or the W-AGF acting on behalf of the FN-RG (or on behalf of the N5GC device) receives a Router Advertisement Message as specified in IETF RFC 4861 [38B] with the "Managed address configuration" flag set to one, the 5G-RG and the W-AGF acting on behalf of the FN-RG (or on behalf of the N5GC device):
a) shall obtain an IPv6 address via DHCPv6 and the DHCPv6 Identity association for non-temporary addresses option as specified in IETF RFC 8415 [33D];
b) may obtain IPv6 configuration parameters via DHCPv6 as specified in IETF RFC 8415 [33D]; and
c) may request IPv6 prefixes using DHCPv6. If the 5G-RG and the W-AGF acting on behalf of the FN-RG (or on behalf of the N5GC device) requests IPv6 prefixes using DHCPv6, the 5G-RG and the W-AGF acting on behalf of the FN-RG (or on behalf of the N5GC device) shall act as a "Requesting Router" as described in IETF RFC 8415 [33D], shall obtain IPv6 prefixes using the DHCPv6 Identity association for prefix delegation option as specified in IETF RFC 8415 [33D], may include DHCPv6 Rapid commit option as specified in IETF RFC 8415 [33D] in a DHCP message, and may include DHCPv6 OPTION_ORO option with the OPTION_PD_EXCLUDE option code as specified in IETF RFC 6603 [40A] in the DHCP message.
NOTE: The 5G-RG and the W-AGF acting on behalf of the FN-RG (or on behalf of the N5GC device) can send multiple DHCPv6 requests with different DHCPv6 Identity association for non-temporary addresses options when the 5G-RG or the FN-RG acts as a DHCP relay for devices behind the 5G-RG or the FN-RG.
The 5G-RG may obtain ACS information via DHCP as specified in clause 3.1 of BBF TR-069 [49] or in BBF TR-369 [50] R-DIS.1 and R-DIS.2.
6.2.4.4 Additional requirements of the UE acting as 5G ProSe layer-3 UE-to-network relay UE for IP address allocation
If a UE acting as 5G ProSe layer-3 UE-to-network relay needs to indicate "IPv6 Router" or "DHCPv4 Server & IPv6 Router" in the IP address configuration IE as specified in 3GPP 24.554 [19E], the UE shall support acting as a "Requesting Router" as described in IETF RFC 8415 [33D] to request additional IPv6 prefixes (i.e. prefixes in addition to the /64 default prefix which was allocated via stateless IPv6 address autoconfiguration as specified in subclause 6.2.4.1) from the SMF as specified in subclause 5.5.2 of 3GPP TS 23.304 [6E].
When the UE acting as 5G ProSe layer-3 UE-to-network relay UE requests additional prefixes using DHCPv6, the UE:
a) shall include the OPTION_ORO option with the OPTION_PD_EXCLUDE option code as specified in IETF RFC 6603 [40A] in the DHCP message; and
b) may include the Rapid Commit Option as specified in IETF RFC 8415 [33D] in the DHCP message.
6.2.5 Quality of service
6.2.5.1 General
6.2.5.1.1 QoS rules
6.2.5.1.1.1 General
In a PDU session of IPv4, IPv6, IPv4v6 and Ethernet PDU session type, the NAS protocol enables different forwarding treatments of UL user data packets in one or more QoS flows based on signalled QoS rules, derived QoS rules or any combination of them.
In a PDU session of Unstructured PDU session type, all UL user data packets are associated with the same QoS flow.
6.2.5.1.1.2 Signalled QoS rules
The NAS protocol enables the network to provide the UE with signalled QoS rules associated with a PDU session.
The network can provide the UE with one or more signalled QoS rules associated with a PDU session at the PDU session establishment or at the PDU session modification.
Each signalled QoS rule contains:
a) an indication of whether the QoS rule is the default QoS rule;
b) a QoS rule identifier (QRI);
c) a QoS flow identifier (QFI);
d) optionally, a set of packet filters; and
e) a precedence value.
NOTE 1: The default QoS rule indication (DQR) of a signalled QoS rule cannot be changed.
For case d) above:
1) If the QoS rule is the default QoS rule of a PDU session of IPv4, IPv6, IPv4v6 or Ethernet PDU session type, the set of packet filters contains zero or more packet filters for DL direction, and may additionaly contain one of the following:
A) a match-all packet filter for UL direction;
B) a match-all packet filter for UL and DL directions;
C) zero or more packet filters for UL direction (other than the match-all packet filter for UL direction);
D) zero or more packet filters for UL and DL directions (other than the match-all packet filter for UL and DL directions); or
E) one or more packet filters for UL direction (other than the match-all packet filter for UL direction) and one or more packet filters for UL and DL directions (other than the match-all packet filter for UL and DL directions).
The set of packet filters for the default QoS rule shall not be empty. If the default QoS rule contains a match-all packet filter, then the highest precedence value shall be used for the default QoS rule.
NOTE 1a: Set of packet filters for the default QoS rule can contain only packet filters for DL direction e.g. for determination that local preconditions are met in an IMS session (see 3GPP TS 24.229 [14]) with a receive only media.
2) If the QoS rule is a QoS rule of a PDU session of IPv4, IPv6, IPv4v6 or Ethernet PDU session type and is not the default QoS rule, the set of packet filters contains zero or more packet filters for the DL direction, and may additionally contain one of the following:
A) zero or more packet filters for UL direction (other than the match-all packet filter for UL direction); and
B) zero or more packet filters for both UL and DL directions (other than the match-all packet filter for UL and DL directions).
The set of packet filters for a QoS rule which is not the default QoS rule shall not be empty.
NOTE 1b: Set of packet filters for a QoS rule which is not the default QoS rule can contain only packet filters for DL direction e.g. for determination that local preconditions are met in an IMS session (see 3GPP TS 24.229 [14]) with a receive only media.
3) For PDU session of unstructured PDU session type, there is only one QoS rule associated with it and the set of packet filters of that QoS rule is empty.
If the UE requests a new QoS rule, it shall assign a precedence value for the signalled QoS rule which is not in the range from 70 to 99 (decimal).
NOTE 2: In this release of the specification, there is no support for a match-all packet filter for DL direction.
NOTE 3: In order to support QoS differentiation in case of access to PLMN services via an SNPN, the UE, within the SNPN, can construct packet filters based on the destination IP address to reach the N3IWF in the PLMN and the security parameters index (SPI) for the IPsec SA.
NOTE 4: In order to support QoS differentiation in case of access to SNPN services via a PLMN, the UE, within the PLMN, can construct packet filters based on the destination IP address to reach the N3IWF in the SNPN and the security parameters index (SPI) for the IPsec SA.
NOTE 5: The above described condition of assigning a precedence value for the signalled QoS rule is applied to the UE when the UE requests a QoS rule for network to bind service data flows described by the QoS rule to a dedicated QoS flow by setting the segregation bit to 1.
In NB-N1 mode, there is only one QoS rule associated with a PDU session and that is the default QoS rule. As described in 3GPP TS 23.501 [8], when the SMF determines that the UE has:
a) moved from a tracking area in WB-N1 mode into a tracking area in NB-N1 mode;
b) moved from a tracking area in WB-S1 mode into a tracking area in NB-N1 mode; or
c) moved from a tracking area in NR connected to 5GCN into a tracking area in NB-N1 mode;
the SMF shall, for each PDU session that is kept active, initiate the PDU session modification procedure (see subclause 6.3.3.2) to delete every QoS rule that is not the default QoS rule, if any.
Within a PDU session:
a) each signalled QoS rule has a unique QRI;
b) there is at least one signalled QoS rule;
c) one signalled QoS rule is the default QoS rule; and
d) there can be zero, one or more signalled QoS rules associated with a given QFI.
6.2.5.1.1.3 Derived QoS rules
Derived QoS rules are applicable only for PDU session of IPv4, IPv6, IPv4v6 or Ethernet PDU session type.
The reflective QoS in the UE creates derived QoS rules associated with a PDU session based on DL user data packets received via the PDU session.
Each derived QoS rule contains:
a) a QoS flow identifier (QFI);
b) a packet filter for UL direction; and
c) a precedence value of 80 (decimal).
NOTE: On the network side, the corresponding QoS rule can be associated with a different precedence value in the range from 70 to 99 (decimal).
Within a PDU session:
a) there can be zero, one or more derived QoS rules associated with a given QFI; and
b) there can be up to one derived QoS rule associated with a given packet filter for UL direction.
In the UE, a timer T3583 runs for each derived QoS rule.
Reflective QoS is not supported in NB-N1 mode. Reflective QoS is not applicable for a PDU session with control plane only indication.
6.2.5.1.1.4 QoS flow descriptions
The network can also provide the UE with one or more QoS flow descriptions associated with a PDU session at the PDU session establishment or at the PDU session modification.
Each QoS flow description contains:
a) a QoS flow identifier (QFI);
b) if the flow is a GBR QoS flow:
1) Guaranteed flow bit rate (GFBR) for UL;
2) Guaranteed flow bit rate (GFBR) for DL;
3) Maximum flow bit rate (MFBR) for UL;
4) Maximum flow bit rate (MFBR) for DL; and
5) optionally averaging window, applicable for both UL and DL;
c) 5QI, if the QFI is not the same as the 5QI of the QoS flow identified by the QFI; and
d) optionally, an EPS bearer identity (EBI) if the QoS flow can be mapped to an EPS bearer as specified in subclause 4.11.1 of 3GPP TS 23.502 [9].
If the averaging window is not included in a QoS flow description for a GBR QoS flow with a 5QI indicated in 3GPP TS 23.501 [8] table 5.7.4-1, the averaging window associated with the 5QI in 3GPP TS 23.501 [8] table 5.7.4-1 applies for the averaging window.
If the averaging window is not included in a QoS flow description for a GBR QoS flow with a 5QI not indicated in 3GPP TS 23.501 [8] table 5.7.4-1, the standardized value of two seconds is used as the averaging window.
6.2.5.1.2 Session-AMBR
The NAS protocol enables the network to provide the UE with the session-AMBR associated with a PDU session.
The standardized value of two seconds is used as the averaging window for the UE’s enforcement of the UL rate limitation indicated by the session-AMBR.
6.2.5.1.2A Void
6.2.5.1.3 UL user data packet matching
For PDU session of IPv4, IPv6, IPv4v6 or Ethernet PDU session type, upon receiving an UL user data packet from the upper layers for transmission via a PDU session, the UE shall attempt to associate the UL user data packet with:
a) the QFI of a signalled QoS rule associated with the PDU session which has a set of packet filters containing a packet filter for UL direction matching the UL user data packet or containing a packet filter for both UL and DL directions matching the UL user data packet; or
b) the QFI of a derived QoS rule associated with the PDU session which has the packet filter for UL direction matching the UL user data packet;
by evaluating the QoS rules in increasing order of their precedence values until the UL user data packet is associated with a QFI or all QoS rules are evaluated.
For PDU session of unstructured PDU session type, upon receiving an UL user data packet from the upper layers for transmission via a PDU session, the UE shall associate the UL user data packet with the QFI of the default QoS rule associated with the PDU session.
If the UL user data packet is associated with a QFI, the UE shall pass the QFI along the UL user data packet to the lower layers for transmission.
NOTE: Marking of the UL user data packet with the QFI is performed by the lower layers.
If all QoS rules are evaluated and the UL user data packet is not associated with a QFI, the UE shall discard the UL user data packet.
6.2.5.1.4 Reflective QoS
6.2.5.1.4.1 General
The UE may support reflective QoS.
If the UE supports the reflective QoS, the UE shall support the procedures in the following subclauses.
The reflective QoS is applicable in a PDU session of IPv4, IPv6, IPv4v6 and Ethernet PDU session type. The reflective QoS is not applicable in a PDU session of Unstructured PDU session type. Reflective QoS is not applicable for a PDU session with control plane only indication.
The UE may request to revoke the usage of reflective QoS for an existing PDU session for which the UE had previously indicated support for reflective QoS.
6.2.5.1.4.2 Derivation of packet filter for UL direction from DL user data packet
If the UE needs to derive a packet filter for UL direction from the DL user data packet (see subclause 6.2.5.1.4.3 and 6.2.5.1.4.4), the UE shall proceed as follows:
a) if the received DL user data packet belongs to a PDU session of IPv4 or IPv4v6 PDU session type and is an IPv4 packet and:
1) the protocol field of the received DL user data packet indicates TCP as specified in IETF RFC 793 [33];
2) the protocol field of the received DL user data packet indicates UDP as specified in IETF RFC 768 [32]; or
3) the protocol field of the received DL user data packet indicates ESP as specified in IETF RFC 4303 [38] and an uplink IPSec SA corresponding to a downlink IPSec SA indicated in the security parameters index field of the received DL user data packet exists;
then the packet filter for UL direction contains the following packet filter components:
1) an IPv4 remote address component set to the value of the source address field of the received DL user data packet;
2) an IPv4 local address component set to the value of the destination address field of the received DL user data packet;
3) a protocol identifier/next header type component set to the value of the protocol field of the received DL user data packet;
4) if the protocol field of the received DL user data packet indicates TCP as specified in IETF RFC 793 [33] or UDP as specified in IETF RFC 768 [32]:
i) a single local port type component set to the value of the destination port field of the received DL user data packet; and
ii) a single remote port type component set to the value of the source port field of the received DL user data packet;
5) if the protocol field of the received DL user data packet indicates ESP as specified in IETF RFC 4303 [38], an uplink IPSec SA corresponding to a downlink IPSec SA of the SPI in the DL user data packet exists and the SPI of the uplink IPSec SA is known to the NAS layer:
i) a security parameter index type component set to the security parameters index of the uplink IPSec SA corresponding to the downlink IPSec SA indicated in the security parameters index field of the received DL user data packet; and
6) if the protocol field of the received DL user data packet indicates UDP and the received DL user data packet contains a UDP-encapsulated ESP header as specified in IETF RFC 3948 [55], an uplink IPSec SA corresponding to a downlink IPSec SA of the SPI in the DL user data packet exists and the SPI of the uplink IPSec SA is known to the NAS layer:
i) a security parameter index type component set to the security parameters index of the uplink IPSec SA corresponding to the downlink IPSec SA indicated in the security parameters index field of the ESP header field of the UDP-encapsulated ESP header as specified in IETF RFC 3948 [55] of the received DL user data packet;
otherwise it is not possible to derive a packet filter for UL direction from the DL user data packet;
b) if the received DL user data packet belongs to a PDU session of IPv6 or IPv4v6 PDU session type and is an IPv6 packet and:
1) the last next header field of the received DL user data packet indicates TCP as specified in IETF RFC 793 [33];
2) the last next header field of the received DL user data packet indicates UDP as specified in IETF RFC 768 [32]; or
3) the last next header field of the received DL user data packet indicates ESP as specified in IETF RFC 4303 [38] and an uplink IPSec SA corresponding to a downlink IPSec SA indicated in the security parameters index field of the received DL user data packet exists;
then the packet filter for UL direction contains the following packet filter components:
1) an IPv6 remote address/prefix length component set to the value of the source address field of the received DL user data packet;
2) an IPv6 local address/prefix length component set to the value of the destination address field of the received DL user data packet;
3) a protocol identifier/next header type component set to the value of the last next header field of the received DL user data packet;
4) if the last next header field of the received DL user data packet indicates TCP as specified in IETF RFC 793 [33] or UDP as specified in IETF RFC 768 [32]:
i) a single local port type component set to the value of the destination port field of the received DL user data packet; and
ii) a single remote port type component set to the value of the source port field of the received DL user data packet;
5) if the last next header field of the received DL user data packet indicates ESP as specified in IETF RFC 4303 [38], an uplink IPSec SA corresponding to a downlink IPSec SA of the SPI in the DL user data packet exists and the SPI of the uplink IPSec SA is known to the NAS layer:
i) a security parameter index type component set to the security parameters index of the uplink IPSec SA corresponding to the downlink IPSec SA indicated in the security parameters index field of the received DL user data packet; and
6) if the last next header field of the received DL user data packet indicates UDP, and the received DL user data packet contains a UDP-encapsulated ESP header as specified in IETF RFC 3948 [55], an uplink IPSec SA corresponding to a downlink IPSec SA of the SPI in the DL user data packet exists and the SPI of the uplink IPSec SA is known to the NAS layer:
i) a security parameter index type component set to the security parameters index of the uplink IPSec SA corresponding to the downlink IPSec SA indicated in the security parameters index field of the ESP header field of the UDP-encapsulated ESP header as specified in IETF RFC 3948 [55] of the received DL user data packet;
otherwise it is not possible to derive a packet filter for UL direction from the DL user data packet;
c) if the received DL user data packet belongs to a PDU session of Ethernet PDU session type, the packet filter for UL direction contains the following packet filter components:
1) a destination MAC address component set to the source MAC address of the received DL user data packet;
2) a source MAC address component set to the destination MAC address of the received DL user data packet;
3) if one or more 802.1Q C-TAG is included in the received DL user data packet, an 802.1Q C-TAG VID component set to the 802.1Q C-TAG VID of the received DL user data packet and an 802.1Q C-TAG PCP/DEI component set to the 802.1Q C-TAG PCP/DEI of the received DL user data packet;
4) if one or more 802.1Q S-TAG is included in the received DL user data packet, an 802.1Q S-TAG VID component set to the 802.1Q S-TAG VID of the received DL user data packet and an 802.1Q S-TAG PCP/DEI component set to the 802.1Q S-TAG PCP/DEI of the received DL user data packet;
5) If the Ethertype field of the received DL user data packet is set to a value of 1536 or above, an Ethertype component set to the Ethertype of the received DL user data packet;
6) if the Ethertype field of the Ethernet frame header indicates that the data carried in the Ethernet frame is IPv4 data, the UE shall also add to the packet filter for UL direction the IP-specific components based on the contents of the IP header of the received DL user data packet as described in bullet a) above; and
7) if the Ethertype field of the Ethernet frame header indicates that the data carried in the Ethernet frame is IPv6 data, the UE shall also add to the packet filter for UL direction the IP-specific components based on the contents of the IP header of the received DL user data packet as described in bullet b) above; and
d) if the received DL user data packet belongs to a PDU session of PDU session type other than Ethernet, IPv4, IPv6 and IPv4v6, it is not possible to derive a packet filter for UL direction from the DL user data packet.
6.2.5.1.4.3 Creating a derived QoS rule by reflective QoS in the UE
If the UE receives a DL user data packet marked with a QFI and an RQI, the DL user data packet belongs to a PDU session of IPv4, IPv6, IPv4v6 or Ethernet PDU session type, and the UE does not have a derived QoS rule with the same packet filter for UL direction as the packet filter for UL direction derived from the DL user data packet as specified in subclause 6.2.5.1.4.2, then the UE shall create a new derived QoS rule as follows:
a) the QFI of the derived QoS rule is set to the received QFI;
b) the precedence value of the derived QoS rule is set to 80 (decimal); and
c) the packet filter for UL direction of the derived QoS rule is set to the derived packet filter for UL direction;
and the UE shall start the timer T3583 associated with the derived QoS rule with the RQ timer value last received during the UE-requested PDU session establishment procedure of the PDU session (see subclause 6.4.1) or the network-requested PDU session modification procedure of the PDU session (see subclause 6.4.2). If the RQ timer value was received neither in the UE-requested PDU session establishment procedure of the PDU session nor in any network-requested PDU session modification procedure of the PDU session, the default standardized RQ timer value is used.
6.2.5.1.4.4 Updating a derived QoS rule by reflective QoS in the UE
If the UE receives a DL user data packet associated with a QFI and an RQI, the DL user data packet belongs to a PDU session of IPv4, IPv6, IPv4v6 or Ethernet PDU session type, and the UE has a derived QoS rule with the same packet filter for UL direction as the packet filter for UL direction derived from the DL user data packet as specified in subclause 6.2.5.1.4.2:
a) the UE shall re-start the timer T3583 associated with the derived QoS rule with the RQ timer value last received during the UE-requested PDU session establishment procedure of the PDU session (see subclause 6.4.1) or the network-requested PDU session modification procedure of the PDU session (see subclause 6.4.2). If the RQ timer value was received neither in the UE-requested PDU session establishment procedure of the PDU session nor in any network-requested PDU session modification procedure of the PDU session, the default standardized RQ timer value is used; and
b) if the QFI value associated with the DL user data packet is different from the QFI value stored for the derived QoS rule, the UE shall replace the QFI value stored for the derived QoS rule with the new QFI value for the derived QoS rule.
6.2.5.1.4.5 Deleting a derived QoS rule in the UE
Upon expiry of timer T3583 associated with a derived QoS rule, the UE shall remove the derived QoS rule.
Upon release of the PDU session, the UE shall remove the derived QoS rule(s) associated with the PDU session.
If the network accepts the request from the UE to revoke the usage of reflective QoS and sets the value of the RQ timer to "deactivated" or zero, the UE shall remove the derived QoS rule(s) associated with the PDU session.
Upon inter-system mobility from WB-N1 mode to NB-N1 mode or from NR connected to 5GCN to NB-N1 mode, the UE shall remove the derived QoS rule(s) associated with the PDU session that is kept active.
When a derived QoS rule is deleted, the timer T3583 associated with the derived QoS rule shall be stopped.
6.2.5.1.4.6 Ignoring RQI in the UE
If the UE receives a DL user data packet marked with a QFI and an RQI and it is not possible to derive a packet filter for UL direction from the DL user data packet as specified in subclause 6.2.5.1.4.2, the UE shall ignore the RQI and shall handle the received DL user data packet.
6.2.5.2 QoS in MA PDU session
In an MA PDU session, unless it :
a) is established over non-3GPP access; and
b) has a PDN connection as a user-plane resource;
the UE shall have one set of QoS rules, one set of QoS flow descriptions and one session-AMBR. The network can provide the set of QoS rules, the set of QoS flow descriptions and the session-AMBR of the MA PDU session via either access of the MA PDU session. In an MA PDU session, the UE shall support:-
– modification or deletion via an access of a QoS rule or a QoS flow description; and
– modification via an access of the session-AMBR;
of the MA PDU session created via the same or the other access.
In an MA PDU session:
a) established over non-3GPP access; and
b) with a PDN connection as a user-plane resource;
the UE shall have two sets of QoS rules, two sets of QoS flow descriptions and two session-AMBR values – one is maintained via non-3GPP access and the other is associated with EPS bearer contexts of the PDN connection and maintained via extended protocol configuration options IE parameters received via the PDN connection.
6.2.6 Local area data network (LADN)
The UE can receive the local area data network (LADN) information consisting of LADN DNNs and LADN service area information (a set of tracking areas that belong to the current registration area) during the registration procedure or the generic UE configuration update procedure (see subclause 5.5.1 and subclause 5.4.4).
If the UE is not operating in SNPN access operation mode, the UE considers the received LADN information to be valid only in the TAIs of the registered PLMN that are in the LADN service area information, and in the TAIs of the equivalent PLMNs if the LADN service area information includes TAIs for the equivalent PLMNs. When the AMF provides the UE with LADN service area information containing TAIs for the equivalent PLMNs, the AMF shall include these TAIs of the equivalent PLMNs in the UE’s registration area.
If the UE is operating in SNPN access operation mode, the UE considers the received LADN information to be valid only in the TAIs of the registered SNPN that are in the LADN service area information.
The LADN DNN(s) received by the UE is also considered as LADN DNN(s) in the equivalent PLMNs.
The UE shall consider itself to be located inside the LADN service area based on the LADN service area information. If the UE does not have a LADN service area information for the LADN DNN, the UE shall consider itself to be located outside the LADN service area.
When the UE is located in the LADN service area and the UE is in substate 5GMM-REGISTERED.NORMAL-SERVICE, the UE may initiate:
– the UE-requested PDU session establishment procedure with a LADN DNN to establish a PDU session for LADN;
– the UE-requested PDU session modification procedure to modify the PDU session for LADN; and
– the service request procedure to re-establish the user-plane resources for the PDU session for LADN.
NOTE 1: If both the Service area list IE and the LADN information IE were received by the UE, the Service area list IE is evaluated first.
When the UE is located outside the LADN service area, the UE is allowed:
– to initiate the UE-requested PDU session release procedure to release a PDU session for LADN; or
– to initiate the UE-requested PDU session modification procedure to indicate a change of 3GPP PS data off UE status.
If the UE has moved out of the LADN service area, the SMF shall:
a) release the PDU session for LADN; or
b) release the user-plane resources for the PDU session for LADN and maintain the PDU session for LADN;
according to operator’s policy.
In case b):
– if the UE has returned to the LADN service area, and the network has downlink user data pending, the network re-establishes the user-plane resources for the PDU session for LADN; and.
– if the UE has not returned to the LADN service area after a period of time according to operator’s policy, the SMF may release the PDU session for LADN.
When the UE moves to 5GMM-DEREGISTERED state, the UE shall delete the stored LADN information, if any.
NOTE 2: In this release, LADNs apply only to 3GPP access.
Upon inter-system change from N1 mode to S1 mode in EMM-IDLE mode, the UE shall not transfer a PDU session for LADN to EPS.
6.2.7 Handling of DNN based congestion control
The network may detect and start performing DNN based congestion control when one or more DNN congestion criteria as specified in 3GPP TS 23.501 [8] are met. If the UE does not provide a DNN for a non-emergency PDU session, then the network uses the selected DNN.
In the UE, 5GS session management timers T3396 for DNN based congestion control are started and stopped on a per DNN basis except for an LADN DNN in case of PLMN. For an LADN DNN, 5GS session management timers T3396 for DNN based congestion control is applied to the registered PLMN and its equivalent PLMNs. In case of SNPN, if the UE does not support access to an SNPN using credentials from a credentials holder, in the UE, 5GS session management timers T3396 for DNN based congestion control are started and stopped on a per DNN and SNPN basis. If the UE supports access to an SNPN using credentials from a credentials holder, in the UE 5GS session management timers T3396 for DNN based congestion control are started and stopped on a per DNN, SNPN and selected entry of the "list of subscriber data" or selected PLMN subscription basis. Upon receipt of a 5GMM message or 5GSM message from the network for which the UE needs to stop the running timers T3396 associated with an LADN DNN as specified in subclause 6.3.2.3, 6.3.3.3, 6.4.1.4.2 and 6.4.2.4.2, only the running timer T3396 which is associated with the PLMN and equivalent PLMNs where the timer was started is stopped.
The DNN associated with T3396 is the DNN provided by the UE during the PDU session establishment. If no DNN is provided by the UE along the PDU SESSION ESTABLISHMENT REQUEST, then T3396 is associated with no DNN. For this purpose, the UE shall memorize the DNN provided to the network during the PDU session establishment. The timer T3396 associated with no DNN will never be started due to any 5GSM procedure related to an emergency PDU session. If the timer T3396 associated with no DNN is running, it does not affect the ability of the UE to request an emergency PDU session.
If T3396 is running or is deactivated, then the UE is not allowed to initiate the:
a) PDU session establishment procedure;
b) PDU session modification procedure; or
c) NAS transport procedure for sending CIoT user data;
for the respective DNN or without a DNN unless the UE is a UE configured for high priority access in selected PLMN or SNPN or to report a change of 3GPP PS data off UE status.
6.2.8 Handling of S-NSSAI based congestion control
The network may detect and start performing S-NSSAI based congestion control when one or more S-NSSAI congestion criteria as specified in 3GPP TS 23.501 [8] are met. If the UE does not provide a DNN for a non-emergency PDU session, then the network uses the selected DNN. If the UE does not provide an S-NSSAI for a non-emergency PDU session, then the network uses the selected S-NSSAI.
In case of PLMN, in the UE, 5GS session management timers T3584 for the S-NSSAI based congestion control are started and stopped on a per S-NSSAI, DNN and PLMN basis. If the 5GSM congestion re-attempt indicator IE with the ABO bit set to "The back-off timer is applied in all PLMNs" is included in the 5GSM message with the 5GSM cause value #67 "insufficient resources for specific slice and DNN", then the UE applies the timer T3584 for all the PLMNs. Otherwise, the UE applies the timer T3584 for the registered PLMN. If the timer T3584 applies for all the PLMNs, the timer T3584 starts when the UE is registered in a VPLMN and the S-NSSAI is provided by the UE during the PDU session establishment, the timer T3584 is associated with the [mapped S-NSSAI, DNN] combination of the PDU session.
In case of PLMN, in the UE, 5GS session management timers T3585 for the S-NSSAI based congestion control are started and stopped on a per S-NSSAI and PLMN basis. If the 5GSM congestion re-attempt indicator IE with the ABO bit set to "The back-off timer is applied in all PLMNs" is included in the 5GSM message with the 5GSM cause value #69 "insufficient resources for specific slice", then the UE applies the timer T3585 for all the PLMNs. Otherwise, the UE applies the timer T3585 for the registered PLMN. If the timer T3585 applies for all the PLMNs, the timer T3585 starts when the UE is registered in a VPLMN and the S-NSSAI is provided by the UE during the PDU session establishment, the timer T3585 is associated with the mapped S-NSSAI of the PDU session. Additionally, if the 5GSM congestion re-attempt indicator IE with the CATBO bit set to "The back-off timer is applied in the current access type" is included in the 5GSM message with the 5GSM cause value #69 "insufficient resources for specific slice", then the UE applies the timer T3585 for the current access type. Otherwise, the UE applies the timer T3585 for both 3GPP access type and non-3GPP access type and the UE shall stop any running timer T3585 for the applied PLMN and for the access different from the access from which the message is received.
In case of SNPN, if the UE does not support access to an SNPN using credentials from a credentials holder, in the UE 5GS session management timers T3584 for the S-NSSAI based congestion control are started and stopped on a per S-NSSAI, DNN and SNPN basis. If the UE supports access to an SNPN using credentials from a credentials holder, in the UE 5GS session management timers T3584 for the S-NSSAI based congestion control are started and stopped on a per S-NSSAI, DNN, SNPN and selected entry of the "list of subscriber data" or selected PLMN subscription basis.
In case of SNPN, if the UE does not support access to an SNPN using credentials from a credentials holder, in the UE 5GS session management timers T3585 for the S-NSSAI based congestion control are started and stopped on a per S-NSSAI and SNPN basis. If the UE supports access to an SNPN using credentials from a credentials holder, in the UE 5GS session management timers T3585 for the S-NSSAI based congestion control are started and stopped on a per S-NSSAI, SNPN and selected entry of the "list of subscriber data" or selected PLMN subscription basis.
The 5GSM congestion re-attempt indicator IE shall not be applicable in an SNPN.
If the timer T3584 or timer T3585 was provided during the PDU session establishment procedure, the S-NSSAI associated with T3584 or T3585, respectively is the S-NSSAI, including no S-NSSAI, provided by the UE during the PDU session establishment.
If the timer T3584 is provided during the PDU session modification or PDU session release procedure, the UE behaves as follows: The DNN associated with T3584 is the DNN provided by the UE during the PDU session establishment. If no S-NSSAI but DNN is provided by the UE along the PDU SESSION ESTABLISHMENT REQUEST message, then T3584 is associated with no S-NSSAI and the DNN provided to the network during the PDU session establishment. If the PDN connection was established when in the S1 mode, then T3584 is associated with no S-NSSAI. If no DNN but S-NSSAI is provided by the UE along the PDU SESSION ESTABLISHMENT REQUEST message, then T3584 is associated with no DNN and the S-NSSAI of the PDU session. If no DNN and no S-NSSAI is provided by the UE along the PDU SESSION ESTABLISHMENT REQUEST message, then T3584 is associated with no DNN and no S-NSSAI. For this purpose, the UE shall memorize the DNN and the S-NSSAI provided to the network during the PDU session establishment. The timer T3584 associated with no DNN and an S-NSSAI will never be started due to any 5GSM procedure related to an emergency PDU session. If the timer T3584 associated with no DNN and an S-NSSAI is running, it does not affect the ability of the UE to request an emergency PDU session.
If the timer T3585 was provided during the PDU session modification or PDU session release procedure, the UE behaves as follows: if an S-NSSAI was provided by the UE during the PDU session establishment, then T3585 is associated with the S-NSSAI of the PDU session. If no S-NSSAI is provided by the UE along the PDU SESSION ESTABLISHMENT REQUEST message, then T3585 is associated with no S-NSSAI. If the PDN connection was established when in the S1 mode, then T3585 is associated with no S-NSSAI.
If T3584 is running or is deactivated, then the UE is not allowed to initiate the:
a) PDU session establishment procedure;
b) PDU session modification procedure; or
c) NAS transport procedure for sending CIoT user data;
for the respective [S-NSSAI, no DNN] or [S-NSSAI, DNN] combination unless the UE is a UE configured for high priority access in selected PLMN or SNPN or to report a change of 3GPP PS data off UE status.
If the timer T3584 is running or is deactivated for all the PLMNs and is associated with an S-NSSAI other than no S-NSSAI, then
a) the UE registered in the HPLMN is not allowed to initiate the:
1) PDU session establishment procedure;
2) PDU session modification procedure; or
3) NAS transport procedure for sending CIoT user data;
when the [S-NSSAI, no DNN] or [S-NSSAI, DNN] combination provided by the UE during the PDU session establishment is the same as the [S-NSSAI, no DNN] or [S-NSSAI, DNN] combination associated with the timer T3584 unless the UE is a UE configured for high priority access in selected PLMN or to report a change of 3GPP PS data off UE status; and
b) the UE registered in a VPLMN is not allowed to initiate the:
1) PDU session establishment procedure;
2) PDU session modification procedure; or
3) NAS transport procedure for sending CIoT user data;
when the [mapped S-NSSAI, no DNN] or [mapped S-NSSAI, DNN] combination provided by the UE during the PDU session establishment is the same as the [S-NSSAI, no DNN] or [S-NSSAI, DNN] combination associated with the timer T3584 unless the UE is a UE configured for high priority access in selected PLMN or to report a change of 3GPP PS data off UE status.
If the timer T3584 is running or is deactivated for all the PLMNs and is associated with [no S-NSSAI, no DNN] or [no S-NSSAI, DNN] combination, then the UE is not allowed to initiate the:
a) PDU session establishment procedure;
b) PDU session modification procedure; or
c) NAS transport procedure for sending CIoT user data;
for [no S-NSSAI, no DNN] or [no S-NSSAI, DNN] combination in any PLMN unless the UE is a UE configured for high priority access in selected PLMN or to report a change of 3GPP PS data off UE status.
If T3585 is running or is deactivated, then the UE is neither allowed to initiate the PDU session establishment procedure nor the PDU session modification procedure for the respective S-NSSAI unless the UE is a UE configured for high priority access in selected PLMN or SNPN or to report a change of 3GPP PS data off UE status.
If the timer T3585 is running or is deactivated for all the PLMNs and is associated with an S-NSSAI other than no S-NSSAI, then
a) the UE registered in the HPLMN is not allowed to initiate the:
1) PDU session establishment procedure;
2) PDU session modification procedure; or
3) NAS transport procedure for sending CIoT user data;
when the S-NSSAI provided by the UE during the PDU session establishment is the same as the S-NSSAI associated with timer T3585 unless the UE is a UE configured for high priority access in selected PLMNs or to report a change of 3GPP PS data off UE status; and
b) the UE registered in a VPLMN is not allowed to initiate the:
1) PDU session establishment procedure;
2) PDU session modification procedure; or
3) NAS transport procedure for sending CIoT user data;
when the mapped S-NSSAI provided by the UE during the PDU session establishment is the same as the S-NSSAI associated the timer T3585 unless the UE is a UE configured for high priority access in selected PLMN or to report a change of 3GPP PS data off UE status.
If the timer T3585 is running or is deactivated for all the PLMNs and is associated with no S-NSSAI, then the UE is not allowed to initiate the:
a) PDU session establishment procedure;
b) PDU session modification procedure;
c) NAS transport procedure for sending CIoT user data;
for no S-NSSAI in any PLMN unless the UE is a UE configured for high priority access in selected PLMN or SNPN or to report a change of 3GPP PS data off UE status.
6.2.9 Interaction with upper layers
6.2.9.1 General
A 5GSM entity may interact with upper layers. Subclause 6.2.9.2 describes how the 5GSM entity interacts with upper layers with respect to the URSP. Subclause 6.2.9.3 describes how the 5GSM entity interacts with upper layers with respect to the ProSeP.
6.2.9.2 URSP
The URSP requires interaction between upper layers and the 5GSM entities in the UE (see 3GPP TS 24.526 [19] for further details). Each of the 5GSM entities in the UE shall indicate attributes (e.g. PDU session identity, SSC mode, S-NSSAI, DNN, PDU session type, access type, PDU address) of a newly established PDU session to the upper layers. If a PDU session is released, the 5GSM entity handling the PDU session shall inform the PDU session identity of the released PDU session to the upper layers. The upper layers may request a 5GSM entity:
a) to establish a PDU session indicating one or more PDU session attributes;
b) to release an existing PDU session; or
c) to establish a PDU session indicating one or more PDU session attributes, and to release an existing PDU session.
6.2.9.3 ProSeP
The ProSeP requires interaction between upper layers and the 5GSM entities in the UE acting as a 5G ProSe layer-3 UE-to-network relay UE (see 3GPP TS 24.554 [19E] for further details). The upper layers may request the 5GSM entity:
a) to establish a PDU session indicating one or more PDU session attributes; or
b) to release the existing PDU session; or
c) to establish a PDU session indicating one or more PDU session attributes, and to release the existing PDU session.
Each of the 5GSM entities in the UE acting as a 5G ProSe layer-3 UE-to-network relay UE shall indicate attributes (e.g. PDU session identity, SSC mode, S-NSSAI, DNN, PDU session type, access type, PDU address) of the newly established PDU session to the upper layers. If the PDU session is released, the 5GSM entity handling the PDU session shall inform the PDU session identity of the released PDU session to the upper layers.
6.2.10 Handling of 3GPP PS data off
In case of PLMN, a UE, which supports 3GPP PS data off (see 3GPP TS 23.501 [8]), can be configured with up to two lists of 3GPP PS data off exempt services as specified in 3GPP TS 24.368 [17] or in the EF3GPPPSDATAOFF USIM file as specified in 3GPP TS 31.102 [22]:
a) a list of 3GPP PS data off exempt services to be used in the HPLMN or EHPLMN; and
b) a list of 3GPP PS data off exempt services to be used in the VPLMN.
If only the list of 3GPP PS data off exempt services to be used in the HPLMN or EHPLMN is configured at the UE, this list shall be also used in the VPLMN.
In case of SNPN, a UE, which supports 3GPP PS data off (see 3GPP TS 23.501 [8]), can be configured with:
a) up to two lists of 3GPP PS data off exempt services as specified in 3GPP TS 24.368 [17] for each subscribed SNPN whose entry exists in the "list of subscriber data":
1) a list of 3GPP PS data off exempt services to be used in the subscribed SNPN; and
2) a list of 3GPP PS data off exempt services to be used in the non-subscribed SNPN; and
b) one list of 3GPP PS data off exempt services as specified in 3GPP TS 24.368 [17] for PLMN subscription:
1) a list of 3GPP PS data off exempt services to be used in the non-subscribed SNPN.
If only the list of 3GPP PS data off exempt services to be used in the subscribed SNPN is configured for the selected entry of "list of subscriber data", this list shall be also used in the non-subscribed SNPN.
If the UE supports 3GPP PS data off, the UE shall provide the 3GPP PS data off UE status in the Extended protocol configuration options IE during UE-requested PDU session establishment procedure except for the transfer of a PDU session from non-3GPP access to 3GPP access and except for the establishment of user plane resources on the other access for the MA PDU session(see subclause 6.4.1), and during UE-requested PDU session modification procedure (see subclause 6.4.2), regardless of associated access type of the PDU session. If the UE requests a PDU session establishment procedure in order to transfer a PDU session from non-3GPP access to 3GPP access, or in order to establish user plane resources on the other access for the MA PDU session over 3GPP access or non-3GPP access, and:
a) if the 3GPP PS data off UE status has changed since the last providing to the network, the UE shall provide the 3GPP PS data off UE status in the Extended protocol configuration options IE; or
b) if the 3GPP PS data off UE status has not changed since the last providing to the network, the UE need not provide the 3GPP PS data off UE status.
The network shall support of 3GPP PS data off.
The UE shall indicate change of the 3GPP PS data off UE status for the PDU session by using the UE-requested PDU session modification procedure as specified in subclause 6.4.2.
When the 3GPP PS data off UE status is "activated":
a) the UE does not send uplink IP packets via 3GPP access except:
1) for those services indicated in the list of 3GPP PS data off exempt services to be used in the HPLMN or EHPLMN as specified in 3GPP TS 24.368 [17] when the UE is in its HPLMN or EHPLMN;
2) for those services indicated in the list of 3GPP PS data off exempt services to be used in the subscribed SNPN, configured for the selected entry of "list of subscriber data", as specified in 3GPP TS 24.368 [17] when the UE is in the subscribed SNPN;
3) for those services indicated in the list of 3GPP PS data off exempt services to be used in the HPLMN or EHPLMN when the UE is in the VPLMN, if only the list of 3GPP PS data off exempt services to be used in the HPLMN or EHPLMN is configured to the UE as specified in 3GPP TS 24.368 [17];
4) for those services indicated in the list of 3GPP PS data off exempt services to be used in the subscribed SNPN, configured for the selected entry of "list of subscriber data", when the UE is in a non-subscribed SNPN and only the list of 3GPP PS data off exempt services to be used in the subscribed SNPN is configured for the selected entry of "list of subscriber data" as specified in 3GPP TS 24.368 [17];
5) for those services indicated in the list of 3GPP PS data off exempt services to be used in the VPLMN when the UE is in the VPLMN, if the list of 3GPP PS data off exempt services to be used in the VPLMN is configured to the UE as specified in 3GPP TS 24.368 [17];
6) for those services indicated in the list of 3GPP PS data off exempt services to be used in the non-subscribed SNPN, configured for the selected entry of "list of subscriber data", when the UE is in a non-subscribed SNPN and the list of 3GPP PS data off exempt services to be used in the non-subscribed SNPN is configured for the selected entry of "list of subscriber data" as specified in 3GPP TS 24.368 [17];
7) for those services indicated in the list of 3GPP PS data off exempt services to be used in the non-subscribed SNPN, configured for the selected PLMN subscription, when the UE is in the non-subscribed SNPN and the list of 3GPP PS data off exempt services to be used in the non-subscribed SNPN is configured for the selected PLMN subscription as specified in 3GPP TS 24.368 [17];
8) for those services indicated in the EF3GPPPSDATAOFF USIM file as specified in 3GPP TS 31.102 [22];
9) any uplink traffic due to procedures specified in 3GPP TS 24.229 [14]; and
10) any uplink traffic due to procedures specified in 3GPP TS 24.623 [20];
b) the UE does not send uplink Ethernet user data packets via 3GPP access; and
c) the UE does not send uplink Unstructured user data packets via 3GPP access.
Otherwise the UE sends uplink user data packets without restriction.
NOTE: If the UE supports 3GPP PS data off, uplink IP packets are filtered as specified in 3GPP TS 24.229 [14] in U.3.1.5.
3GPP PS data off does not restrict sending of uplink user data packets via non-3GPP access of a single access PDU session or an MA PDU session.
6.2.11 Multi-homed IPv6 PDU session
The UE supporting IPv6 may support multi-homed IPv6 PDU session.
If the UE supports the multi-homed IPv6 PDU session:
a) the UE shall support acting as a type C host as specified in IETF RFC 4191 [36]; and
b) the UE indicates support of the multi-homed IPv6 PDU session:
1) during the UE-requested PDU session establishment of a PDU session of "IPv6" or "IPv4v6" PDU session type; and
2) during the UE-requested PDU session modification performed after an inter-system change from S1 mode to N1 mode, for a PDU session associated with a PDN connection established when in S1 mode, if the UE is a UE operating in single-registration mode in a network supporting N26 interface, the PDU session is of "IPv6" or "IPv4v6" PDU session type, and the UE has not previously successfully performed the UE-requested PDU session modification to provide this indication.
6.2.12 Handling of network rejection not due to congestion control
The network may include a back-off timer value in a 5GS session management reject message to regulate the time interval at which the UE may retry the same procedure for 5GSM cause values other than #26 "insufficient resources", #28 "unknown PDU session type", #39 "reactivation requested", #46 "out of LADN service area", #50 "PDU session type IPv4 only allowed", #51 "PDU session type IPv6 only allowed", #54 "PDU session does not exist", #57 "PDU session type IPv4v6 only allowed", #58 "PDU session type Unstructured only allowed", #61 "PDU session type Ethernet only allowed", #67 "insufficient resources for specific slice and DNN", #68 "not supported SSC mode" and #69 "insufficient resources for specific slice". For 5GSM cause values other than #26 "insufficient resources", #28 "unknown PDU session type", #39 "reactivation requested", #46 "out of LADN service area", #54 "PDU session does not exist", #67 "insufficient resources for specific slice and DNN", #68 "not supported SSC mode", and #69 "insufficient resources for specific slice", and #86 "UAS services not allowed", the network may also include the re-attempt indicator to indicate whether the UE is allowed to re-attempt the corresponding session management procedure for the same DNN in S1 mode after inter-system change.
NOTE 1: In a PLMN, if the network includes this back-off timer value for 5GSM cause values other than #27 "missing or unknown DNN", then the UE is blocked from sending another 5GSM request for the same procedure for the same [PLMN, DNN, S-NSSAI], [PLMN, DNN, no S-NSSAI], [PLMN, no DNN, S-NSSAI], or [PLMN, no DNN, no S-NSSAI] combination for the specified duration. If the network includes this back-off timer value for 5GSM cause value #27 "missing or unknown DNN", then the UE is blocked from sending another 5GSM request for the same procedure for the same [PLMN, DNN], or [PLMN, no DNN] combination for the specified duration. In an SNPN, if the network includes this back-off timer value for 5GSM cause values other than #27 "missing or unknown DNN", then the UE is blocked from sending another 5GSM request for the same procedure for the same [SNPN, DNN, S-NSSAI], [SNPN, DNN, no S-NSSAI], [SNPN, no DNN, S-NSSAI], or [SNPN, no DNN, no S-NSSAI] combination for the specified duration if the UE does not support access to an SNPN using credentials from a credentials holder, and the UE is blocked from sending another 5GSM request for the same procedure for the same [SNPN, selected entry of the "list of subscriber data" or selected PLMN subcription, DNN, S-NSSAI], [SNPN, selected entry of the "list of subscriber data" or selected PLMN subcription, DNN, no S-NSSAI], [SNPN, selected entry of the "list of subscriber data" or selected PLMN subcription, no DNN, S-NSSAI], or [SNPN, selected entry of the "list of subscriber data" or selected PLMN subcription, no DNN, no S-NSSAI] combination for the specified duration if the UE supports access to an SNPN using credentials from a credentials holder . If the network includes this back-off timer value for 5GSM cause value #27 "missing or unknown DNN", then the UE is blocked from sending another 5GSM request for the same procedure for the same [SNPN, DNN], or [SNPN, no DNN] combination for the specified duration if the UE does not support access to an SNPN using credentials from a credentials holder, and the UE is blocked from sending another 5GSM request for the same procedure for the same [SNPN, selected entry of the "list of subscriber data" or selected PLMN subcription, DNN], or [SNPN, selected entry of the "list of subscriber data" or selected PLMN subcription, no DNN] combination for the specified duration if the UE supports access to an SNPN using credentials from a credentials holder. Therefore, the operator needs to exercise caution in determining the use of this timer value.
NOTE 2: If the re-attempt indicator is not provided by the network, a UE registered in its HPLMN or in an EHPLMN can use the configured SM_RetryAtRATChange value specified in the NAS configuration MO or in the USIM NASCONFIG file to derive the re-attempt indicator as specified in subclauses 6.4.1.4.3 and 6.4.2.4.3.
If re-attempt in S1 mode is allowed for 5GSM cause values other than #27 "missing or unknown DNN", the UE shall consider the back-off timer to be applicable only to the 5GS session management in N1 mode for the rejected 5GS session management procedure and the given [PLMN, DNN, S-NSSAI], [PLMN, DNN, no S-NSSAI], [PLMN, no DNN, S-NSSAI], or [PLMN, no DNN, no S-NSSAI] combination. If re-attempt in S1 mode is allowed for 5GSM cause value #27 "missing or unknown DNN", the UE shall consider the back-off timer to be applicable only to the 5GS session management in N1 mode for the rejected 5GS session management procedure and the given [PLMN, DNN], or [PLMN, no DNN] combination.If re-attempt in S1 mode is not allowed, the UE shall consider the back-off timer to be applicable to both NAS protocols, i.e. applicable to the 5GS session management in N1 mode for the rejected 5GS session management procedure and to the EPS session management in S1 mode for the corresponding session management procedure and the given [PLMN, DNN] or [PLMN, no DNN] combination.
NOTE 3: In the present subclause the terms DNN and APN are referring to the same parameter.
In a PLMN, if the back-off timer was provided during the PDU session establishment procedure, the UE behaves as follows: for 5GSM cause values other than #27 "missing or unknown DNN", when the UE is registered in a HPLMN, the DNN and the S-NSSAI of the [PLMN, DNN, S-NSSAI] combination associated with the back-off timer is the DNN and the S-NSSAI provided by the UE when the PDU session is established. When the UE is registered in a VPLMN, the DNN and the S-NSSAI of the [PLMN, DNN, S-NSSAI] combination associated with the back-off timer is the DNN and the mapped S-NSSAI provided by the UE when the PDU session is established. For 5GSM cause value #27 "missing or unknown DNN", the DNN of the [PLMN, DNN] combination associated with the back-off timer is the DNN provided by the UE when the PDU session is established. If no DNN or no S-NSSAI was provided to the network during the PDU session establishment, then the back-off timer is associated with the [PLMN, DNN, no S-NSSAI], [PLMN, no DNN, S-NSSAI], or [PLMN, no DNN, no S-NSSAI] combination, dependent on which parameters were provided for 5GSM cause values other than #27 "missing or unknown DNN". If no DNN was provided to the network during the PDU session establishment, then the back-off timer is associated with the [PLMN, no DNN] combination for 5GSM cause value #27 "missing or unknown DNN". For this purpose, the UE shall memorize the DNN and the S-NSSAI provided to the network during the PDU session establishment.
In a PLMN, if the back-off timer was provided during the PDU session modification procedure, the UE behaves as follows: the DNN associated with the back-off timer is the DNN, including no DNN, provided by the UE when the PDU session is established. If an S-NSSAI was provided by the UE during the PDU session establishment, when the UE is registered in a HPLMN, then the S-NSSAI associated with the back-off timer is the S-NSSAI of the PDU session. If an S-NSSAI was provided by the UE during the PDU session establishment, when the UE is registered in a VPLMN, then the S-NSSAI associated with the back-off timer is the mapped S-NSSAI of the PDU session. If no S-NSSAI was provided by the UE during the PDU session establishment, then the back-off timer is associated with no S-NSSAI. For this purpose, the UE shall memorize the DNN and the S-NSSAI provided to the network during the PDU session establishment.
In a PLMN, the back-off timer associated with the [PLMN, no DNN, no S-NSSAI], or [PLMN, no DNN] combination will never be started due to any 5GSM procedure related to an emergency PDU session. If the back-off timer associated with the [PLMN, no DNN, no S-NSSAI], or [PLMN, no DNN] combination is running, it does not affect the ability of the UE to request an emergency PDU session.
In an SNPN, the back-off timer associated with the [SNPN, no DNN, no S-NSSAI], or [SNPN, no DNN] combination if the UE does not support access to an SNPN using credentials from a credentials holder, or the back-off timer associated with the [SNPN, selected entry of the "list of subscriber data" or selected PLMN subscription, no DNN, no S-NSSAI], or [SNPN, selected entry of the "list of subscriber data" or selected PLMN subscription, no DNN] combination if the UE supports access to an SNPN using credentials from a credentials holder, will never be started due to any 5GSM procedure related to an emergency PDU session. If the back-off timer associated with the [SNPN, no DNN, no S-NSSAI], or [SNPN, no DNN] combination if the UE does not support access to an SNPN using credentials from a credentials holder, or the back-off timer associated with the [SNPN, selected entry of the "list of subscriber data" or selected PLMN subscription, no DNN, no S-NSSAI], or [SNPN, selected entry of the "list of subscriber data" or selected PLMN subscription, no DNN] combination if the UE supports access to an SNPN using credentials from a credentials holder is running, it does not affect the ability of the UE to request an emergency PDU session.
In a PLMN, the network may additionally indicate in the re-attempt indicator that a command to back-off is applicable not only for the PLMN in which the UE received the 5GS session management reject message, but for each PLMN included in the equivalent PLMN list at the time when the 5GS session management reject message was received.
In a PLMN, if the back-off timer is running or is deactivated for a given [PLMN, DNN, S-NSSAI], [PLMN, DNN, no S-NSSAI], [PLMN, no DNN, S-NSSAI], [PLMN, no DNN, no S-NSSAI] , [PLMN, DNN], or [PLMN, no DNN] combination, and the UE is a UE configured for high priority access in selected PLMN, then the UE is allowed to initiate 5GSM procedures for the [PLMN, DNN, S-NSSAI], [PLMN, DNN, no S-NSSAI], [PLMN, no DNN, S-NSSAI], [PLMN, no DNN, no S-NSSAI] , [PLMN, DNN], or [PLMN, no DNN] combination.
In an SNPN, if the back-off timer is running or is deactivated for a given [SNPN, DNN, S-NSSAI], [SNPN, DNN, no S-NSSAI], [SNPN, no DNN, S-NSSAI], [SNPN, no DNN, no S-NSSAI] , [SNPN, DNN], or [SNPN, no DNN] combination if the UE does not support access to an SNPN using credentials from a credentials holder, or the back-off timer is running or is deactivated for a given [SNPN, selected entry of the "list of subscriber data" or selected PLMN subcription, DNN, S-NSSAI], [SNPN, selected entry of the "list of subscriber data" or selected PLMN subcription, DNN, no S-NSSAI], [SNPN, selected entry of the "list of subscriber data" or selected PLMN subcription, no DNN, S-NSSAI], [SNPN, selected entry of the "list of subscriber data" or selected PLMN subcription, no DNN, no S-NSSAI] , [SNPN, selected entry of the "list of subscriber data" or selected PLMN subcription, DNN], or [SNPN, selected entry of the "list of subscriber data" or selected PLMN subcription, no DNN] combination if the UE supports access to an SNPN using credentials from a credentials holder, and the UE is a UE configured for high priority access in selected SNPN, then the UE is allowed to initiate 5GSM procedures for the [SNPN, DNN, S-NSSAI], [SNPN, DNN, no S-NSSAI], [SNPN, no DNN, S-NSSAI], [SNPN, no DNN, no S-NSSAI] , [SNPN, DNN], or [SNPN, no DNN] combination if the UE does not support access to an SNPN using credentials from a credentials holder, or the UE is allowed to initiate 5GSM procedures for the [SNPN, selected entry of the "list of subscriber data" or selected PLMN subcription, DNN, S-NSSAI], [SNPN, selected entry of the "list of subscriber data" or selected PLMN subcription, DNN, no S-NSSAI], [SNPN, selected entry of the "list of subscriber data" or selected PLMN subcription, no DNN, S-NSSAI], [SNPN, selected entry of the "list of subscriber data" or selected PLMN subcription, no DNN, no S-NSSAI] , [SNPN, selected entry of the "list of subscriber data" or selected PLMN subcription, DNN], or [SNPN, selected entry of the "list of subscriber data" or selected PLMN subcription, no DNN] combination if the UE supports access to an SNPN using credentials from a credentials holder.
Neither the re-attempt indicator IE nor re-attempt indicator derivation shall be applicable in an SNPN.
6.2.13 Handling of Small data rate control
Small data rate control is applicable only to NB-N1 mode and WB-N1 mode.
Small data rate control controls the maximum number of uplink user data messages including uplink exception data reporting sent by the UE in a time interval for the PDU session in accordance with 3GPP TS 23.501 [8]. The UE shall limit the rate at which it generates uplink user data messages to comply with the small data rate control policy. The NAS shall provide the indicated rates to upper layers for enforcement. The indicated rates in a NAS procedure applies to the PDU session the NAS procedure corresponds to, and the indicated rates are valid until a new value is indicated or the PDU session is released.
If the UE indicates support for CIoT 5GS optimizations, the network may provide the small data rate control parameters to the UE and may provide the small data rate control parameters for exception data to the UE if and only if the small data rate control parameters is provided to the UE. Small data rate control parameters and small data rate control parameters for exception data can also be provided to the UE in S1 mode as specified in 3GPP TS 24.301 [15].
If an allowed indication of additional exception reports is provided with the small data rate control parameters and:
– the additional small data rate control parameters for exception data is provided and the limit for additional rate for exception data reporting is not reached; or
– the additional small data rate control parameters for exception data is not provided,
the UE is allowed to send uplink exception reports even if the limit for the small data rate control has been reached.
During a PDU session release procedure, if the small data rate control was applied to the PDU session that is being released, the network may store the small data rate control status for the released PDU session as specified in 3GPP TS 23.501 [8].
If:
a) the UE indicates support for CIoT 5GS optimizations; and
b) the small data rate control status was stored for the PDU session and is still valid,
the network may provide the remaining small data rate control status as initial small data rate control parameters to the UE and initial small data rate control parameters for exception data to the UE during a subsequent PDU session establishment procedure.
If received during the establishment of a PDU session, the UE shall apply the initial small data rate control parameters and the initial small data rate control parameters for exception data for the duration of the validity period. When the validity period expires the small data rate control parameters and the small data rate control parameters for exception data shall be applied (see 3GPP TS 23.501 [8]).
NOTE 1: The HPLMN can discard or delay user data that exceeds the limit provided for small data rate control.
Upon inter-system change from N1 mode to S1 mode, the UE shall store the current small data rate control status for PDU sessions to be transferred from N1 mode to S1 mode as specified in 3GPP TS 23.501 [8].
NOTE 2: How long the UE stores the current small data rate control status is implementation specific.
Upon inter-system change from S1 mode to N1 mode, the UE shall use the stored small data rate control status, if any, to comply with the small data rate control policy for PDU sessions transferred from S1 mode to N1 mode as specified in 3GPP TS 23.501 [8], if the validity period of the stored small data rate control status has not expired.
6.2.14 Handling of Serving PLMN rate control
Serving PLMN rate control is applicable only for PDU sessions established for control plane CIoT 5GS optimization.
Serving PLMN rate control protect its AMF from the load generated by user data over control plane.
The SMF can inform the UE of any local serving PLMN rate control during the PDU session establishment procedure (see subclause 6.4.1) or the PDU session modification procedure (see subclause 6.4.2). If serving PLMN rate control is enabled, the SMF shall start the serving PLMN rate control for the PDU session when the first control plane user data is received over the PDU session.The UE shall limit the rate at which it generates uplink control plane user data to comply with the serving PLMN policy provided by the network. The indicated rate in a NAS procedure applies to the PDU session the NAS procedure corresponds to, and the indicated rate is valid until the PDU session is released.
Any Serving PLMN rate control information provided by the network to the UE is only applicable for the PLMN which provided this information. This serving PLMN rate control information shall be discarded when the UE successfully registers to another PLMN.
NOTE: The serving PLMN can discard or delay control plane user data that exceed the limit provided for Serving PLMN rate control.
6.2.15 Handling of Reliable Data Service
If the UE supports Reliable Data Service (see 3GPP TS 23.501 [8] and 3GPP TS 24.250 [14A]), the UE may request data transfer using Reliable Data Service for a PDU session in the Extended protocol configuration options IE during UE-requested PDU session establishment procedure (see subclause 6.4.1).
The Reliable Data Service may only be used with PDU sessions for which the "Control Plane CIoT 5GS Optimisation" indicator is set or with PDU sessions using the control plane CIoT 5GS optimization when the AMF does not move such PDU sessions to the user plane.
The network shall inform the UE about the acceptance of UE’s request for Reliable Data Service usage during the PDU session establishment procedure (see subclause 6.4.1) in the Extended protocol configuration options IE.
If the network accepts the use of Reliable Data Service to transfer data for the specified PDU session, the UE shall use this PDU session exclusively for data transfer using Reliable Data Service; otherwise the UE shall not use this PDU session for data transfer using Reliable Data Service.
6.2.16 Handling of header compression for control plane CIoT optimizations
The UE and the SMF may use:
– IP header compression for PDU sessions of "IPv4", "IPv6" or "IPv4v6" PDU session type; and
– Ethernet header compression for PDU sessions of "Ethernet" PDU session type.
Both the UE and the AMF indicate whether header compression for control plane CIoT 5GS optimization is supported during registration procedures (see subclause 5.5.1). If both the UE and the network support header compression, the header compression configuration for each PDU session is negotiated during the PDU session establishment procedure and PDU session modification procedure as specified in subclauses 6.3.2, 6.4.1 and 6.4.2.
For IP header compression, ROHC protocol specified in IETF RFC 5795 [39B] is used. The IP header compression configuration used for IP header compression is (re-)negotiated between the UE and the SMF using the IP header compression configuration IE as specified in subclauses 6.3.2.2, 6.4.1.2, 6.4.1.3 and 6.4.2.2, respectively.
For Ethernet header compression, Ethernet Header Compression (EHC) protocol specified in 3GPP TS 38.323 [29] is used. The Ethernet header compression configuration used for Ethernet header compression is (re-)negotiated between the UE and the SMF using the Ethernet header compression configuration IE as specified in subclauses 6.3.2.2, 6.4.1.2, 6.4.1.3 and 6.4.2.2, respectively.
6.2.17 Handling of edge computing enhancements
EAS discovery, EAS rediscovery and ECS address provisioning provide enhanced edge computing support in 5GS (see 3GPP TS 23.548 [10A]).
If the network supports the session breakout connectivity model or distributed anchor connectivity model to enable edge computing enhancements and the UE generated DNS message is to be handled by an edge application server discovery function (EASDF) for EAS discovery as specified in 3GPP TS 23.548 [10A], the SMF selects the EASDF and it provides its IP address to the UE as the DNS server to be used for the PDU session in the Extended protocol configuration options IE during the UE-requested PDU session establishment procedure as described in subclause 6.4.1.3.
NOTE 1: EASDF selection is outside the scope of the present document.
If the network supports the session breakout connectivity model to enable edge computing enhancements and the UE generated DNS message is to be handled by a local DNS server for EAS discovery as specified in 3GPP TS 23.548 [10A], the SMF selects the local DNS server, obtains its IP address and can provide the IP address of the local DNS server to the UE as the DNS server to be used for the PDU session in the Extended protocol configuration options IE during the UE-requested PDU session establishment procedure or the network-requested PDU session modification procedure as described in subclauses 6.4.1.3 and 6.3.2.2, respectively.
NOTE 2: Local DNS server selection and the acquisition of its IP address is outside the scope of the present document.
If the UE supports EAS rediscovery and the SMF decides to trigger the EAS rediscovery as specified in 3GPP TS 23.548 [10A], the SMF initiates a network-requested PDU session modification procedure to provide the EAS rediscovery information to the UE as described in subclauses 6.3.2.2. Upon receipt of the EAS rediscovery information, the UE provides the received information to the upper layers.
NOTE 3: The upper layers of the UE uses the EAS rediscovery information to trigger the EAS discovery procedure to get the new EAS information as specified in 3GPP TS 23.548 [10A].
If the UE supports ECS address provisioning over NAS as specified in 3GPP TS 23.548 [10A], the UE indicates its support of ECS configuration information provisioning over NAS in the Extended protocol configuration options IE either during the UE-requested PDU session establishment procedure as described in subclause 6.4.1.2 or while in S1 mode as described in 3GPP TS 24.301 [15], respectively.
If the UE indicated support of ECS configuration information address provisioning over NAS, the SMF can provide the ECS configuration information in the Extended protocol configuration options IE during the network-requested PDU session modification procedure, UE-requested PDU session establishment procedure or the UE-requested PDU session modification procedure as described in subclauses 6.3.2.2, 6.4.1.3 and 6.4.2.3, respectively.
NOTE 4: The SMF can obtain the ECS configuration information based on the local configuration, the UE’s location, and/or UE’s subscription information.
If the UE supports the edge DNS client (EDC) as specified in 3GPP TS 23.548 [10A], the UE indicates its support of EDC in the Extended protocol configuration options IE during the UE-requested PDU session establishment procedure as described in subclause 6.4.1.2 or the UE-requested PDU session modification procedure as described in subclause 6.4.2.2.
If the UE indicates support of EDC, the SMF can indicate in the Extended protocol configuration options IE during the UE-requested PDU session establishment procedure as described in subclause 6.4.1.3 or the network-requested PDU session modification procedure as described in subclause 6.3.2.2, that the network allows the use of EDC for the applications which are mapped onto the PDU session and explicitly requested the use of EDC, or that the network requires the use of EDC for all applications mapped onto the PDU session.
6.2.18 Support of redundant PDU sessions
The 5GSM sublayer may support establishment of redundant PDU sessions (see clause 5.33.2 of 3GPP TS 23.501 [8]).
In order to establish a set of two redundant PDU sessions, a UE can include a PDU session pair ID, an RSN, or both in a PDU SESSION ESTABLISHMENT REQUEST message for each of the two redundant PDU sessions (see subclause 6.4.1.2). The UE can set the PDU session pair ID, the RSN, or both according to URSP or UE local configuration (see 3GPP TS 24.526 [19]).
An SMF receiving a PDU session pair ID, an RSN, or both via a PDU SESSION ESTABLISHMENT REQUEST message operates as specified in clause 5.33.2 of 3GPP TS 23.501 [8]. In addition, an SMF can handle two PDU sessions as redundant even if the UE provides neither a PDU session pair ID nor an RSN in a PDU SESSION ESTABLISHMENT REQUEST message for each of the PDU sessions (see clause 5.33.2 of 3GPP TS 23.501 [8]).