3GPP 24.501 v20.0.0 — the document's own text

6.4.1.3 UE-requested PDU session establishment procedure accepted by the network

Taught in 4. Inside TS 24.501, the document at the centre (CT1 — the group that writes what your phone says, overview).

If the connectivity with the requested DN is accepted by the network, the SMF shall create a PDU SESSION ESTABLISHMENT ACCEPT message.

If the UE requests establishing an emergency PDU session, the network shall not check for service area restrictions or subscription restrictions when processing the PDU SESSION ESTABLISHMENT REQUEST message.

The SMF shall set the Authorized QoS rules IE of the PDU SESSION ESTABLISHMENT ACCEPT message to the authorized QoS rules of the PDU session and may include the authorized QoS flow descriptions IE of the PDU SESSION ESTABLISHMENT ACCEPT message set to the authorized QoS flow descriptions of the PDU session.

NOTE 1: This is applicable also if the PDU session establishment procedure was initiated to perform handover of an existing PDU session between 3GPP access and non-3GPP access, and even if the authorized QoS rules and authorized QoS flow descriptions for source and target access of the handover are the same.

The SMF shall ensure that the number of the packet filters used in the authorized QoS rules of the PDU Session does not exceed the maximum number of packet filters supported by the UE for the PDU session. If the received request type is "initial emergency request", the SMF shall set the Authorized QoS flow descriptions IE according to the QoS parameters used for establishing emergency services as specified in clause 5.16.4 of 3GPP TS 23.501 [8].

SMF shall set the Authorized QoS flow descriptions IE to the authorized QoS flow descriptions of the PDU session, if:

the Authorized QoS rules IE contains at least one GBR QoS flow;
the QFI is not the same as the 5QI of the QoS flow identified by the QFI;
the QoS flow can be mapped to an EPS bearer as specified in clause 4.11.1 of 3GPP TS 23.502 [9]; or
the QoS flow is established for the PDU session used for relaying, as specified in clause 5.6.2.1 of 3GPP TS 23.304 [6E].

NOTE 2: In cases other than above listed cases, it is up to the SMF implementation to include the authorized QoS flow description for the QoS flow in the Authorized QoS flow descriptions IE of the PDU SESSION ESTABLISHMENT ACCEPT message.

If interworking with EPS is supported for the PDU session, the SMF shall set in the PDU SESSION ESTABLISHMENT ACCEPT message:

the Mapped EPS bearer contexts IE to the EPS bearer contexts mapped from one or more QoS flows of the PDU session; and
the EPS bearer identity parameter in the Authorized QoS flow descriptions IE to the EPS bearer identity corresponding to the QoS flow, for each QoS flow which can be transferred to EPS.

If the "Create new EPS bearer" operation code in the Mapped EPS bearer contexts IE was received, and there is no corresponding Authorized QoS flow descriptions IE in the PDU SESSION ESTABLISHMENT ACCEPT message, the UE shall send a PDU SESSION MODIFICATION REQUEST message including a Mapped EPS bearer contexts IE to delete the mapped EPS bearer context. If the EPS bearer identity parameter in the Authorized QoS flow descriptions IE was received, the operation code is "Create new QoS flow description" and there is no corresponding Mapped EPS bearer contexts IE in the PDU SESSION ESTABLISHMENT ACCEPT message, the UE shall not diagnose an error, and shall keep storing the association between the QoS flow and the corresponding EPS bearer identity.

Furthermore, the SMF shall store the association between the QoS flow and the mapped EPS bearer context, for each QoS flow which can be transferred to EPS.

The SMF shall set the selected SSC mode IE of the PDU SESSION ESTABLISHMENT ACCEPT message to:

the received SSC mode in the SSC mode IE included in the PDU SESSION ESTABLISHMENT REQUEST message based on one or more of the PDU session type, the subscription and the SMF configuration;
either the default SSC mode for the data network listed in the subscription or the SSC mode associated with the SMF configuration, if the SSC mode IE is not included in the PDU SESSION ESTABLISHMENT REQUEST message.

NOTE 3: For bullet b), to avoid issues for UEs not supporting all SSC modes, the network operator can, in the subscription data and local configuration, include at least SSC mode 1 in the allowed SSC modes, and set the default SSC mode to "SSC mode 1" as per 3GPP TS 23.501 [8].

If the PDU session is an emergency PDU session, the SMF shall set the Selected SSC mode IE of the PDU SESSION ESTABLISHMENT ACCEPT message to "SSC mode 1". If the PDU session is a non-emergency PDU session of "Ethernet" or "Unstructured" PDU session type, the SMF shall set the Selected SSC mode IE to "SSC mode 1" or "SSC mode 2". If the PDU session is a non-emergency PDU session of "IPv4", "IPv6" or "IPv4v6" PDU session type, the SMF shall set the selected SSC mode IE to "SSC mode 1", "SSC mode 2", or "SSC mode 3".

If the PDU session is a non-emergency PDU session and the UE is not registered for onboarding services in SNPN, the SMF shall set the S-NSSAI IE of the PDU SESSION ESTABLISHMENT ACCEPT message to:

the S-NSSAI of the PDU session; and
the mapped S-NSSAI (if mapped S-NSSAIs are provided as specified in clause 4.6.1).

The S-NSSAI or the mapped S-NSSAI (if included by the SMF) of the PDU session shall be the alternative S-NSSAI if the SMF has received an alternative S-NSSAI from the AMF.

The SMF shall set the Selected PDU session type IE of the PDU SESSION ESTABLISHMENT ACCEPT message to the selected PDU session type, i.e. the PDU session type of the PDU session.

If the PDU SESSION ESTABLISHMENT REQUEST message includes a PDU session type IE set to "IPv4v6", the SMF shall select "IPv4", "IPv6" or "IPv4v6" as the Selected PDU session type. If the subscription, the SMF configuration, or both, are limited to IPv4 only or IPv6 only for the DNN selected by the network, the SMF shall include the 5GSM cause value #50 "PDU session type IPv4 only allowed", or #51 "PDU session type IPv6 only allowed", respectively, in the 5GSM cause IE of the PDU SESSION ESTABLISHMENT ACCEPT message.

If the selected PDU session type is "IPv4", the SMF shall include the PDU address IE in the PDU SESSION ESTABLISHMENT ACCEPT message and shall set the PDU address IE to an IPv4 address is allocated to the UE in the PDU session.

If the selected PDU session type is "IPv6", the SMF shall include the PDU address IE in the PDU SESSION ESTABLISHMENT ACCEPT message and shall set the PDU address IE to an interface identifier for the IPv6 link local address allocated to the UE in the PDU session.

If the selected PDU session type is "IPv4v6", the SMF shall include the PDU address IE in the PDU SESSION ESTABLISHMENT ACCEPT message and shall set the PDU address IE to an IPv4 address and an interface identifier for the IPv6 link local address, allocated to the UE in the PDU session.

If the selected PDU session type of a PDU session established by the W-AGF acting on behalf of the FN-RG is "IPv4v6" or "IPv6", the SMF shall also indicate the SMF's IPv6 link local address in the PDU address IE of the PDU SESSION ESTABLISHMENT ACCEPT message.

If the PDU session is a non-emergency PDU session and the UE is not registered for onboarding services in SNPN, the SMF shall set the DNN IE of the PDU SESSION ESTABLISHMENT ACCEPT message to the DNN determined by the AMF of the PDU session.

The SMF shall set the Session-AMBR IE of the PDU SESSION ESTABLISHMENT ACCEPT message to the Session-AMBR of the PDU session.

If the selected PDU session type is "IPv4", "IPv6", "IPv4v6" or "Ethernet" and if the PDU SESSION ESTABLISHMENT REQUEST message includes a 5GSM capability IE with the RQoS bit set to "Reflective QoS supported", the SMF shall consider that reflective QoS is supported for QoS flows belonging to this PDU session and may include the RQ timer IE set to an RQ timer value in the PDU SESSION ESTABLISHMENT ACCEPT message.

If the selected PDU session type is "IPv4", "IPv6", "IPv4v6" or "Ethernet" and if the PDU SESSION ESTABLISHMENT REQUEST message includes a Maximum number of supported packet filters IE, the SMF shall consider this number as the maximum number of packet filters that can be supported by the UE for this PDU session. Otherwise the SMF considers that the UE supports 16 packet filters for this PDU session.

If the selected PDU session type is "Ethernet" and if the PDU SESSION ESTABLISHMENT REQUEST message includes a 5GSM capability IE with the E8PCPDEI bit set to "Extended 802.1Q C-TAG/S-TAG PCP/DEI packet filter component type supported", the SMF may include one or more QoS rules with the packet filters with packet filter component type identifier set to extended 802.1Q C-TAG PCP/DEI packet filter component type or extended 802.1Q S-TAG PCP/DEI packet filter component type in the PDU SESSION ESTABLISHMENT ACCEPT message.

The SMF shall consider that the maximum data rate per UE for user-plane integrity protection supported by the UE for uplink and the maximum data rate per UE for user-plane integrity protection supported by the UE for downlink are valid for the lifetime of the PDU session.

If the value of the RQ timer is set to "deactivated" or has a value of zero, the UE considers that RQoS is not applied for this PDU session.

NOTE 4: If the 5G core network determines that reflective QoS is to be used for a service data flow of a QoS flow, the SMF sends reflective QoS indication (RQI) to UPF to activate reflective QoS for this service data flow. If the QoS flow is established over 3GPP access, the SMF also includes reflective QoS Attribute (RQA) in QoS profile of the QoS flow during QoS flow establishment.

If the selected PDU session type is "IPv6" or "IPv4v6" and if the PDU SESSION ESTABLISHMENT REQUEST message includes a 5GSM capability IE with the MH6-PDU bit set to "Multi-homed IPv6 PDU session supported", the SMF shall consider that this PDU session is supported to use multiple IPv6 prefixes.

If the selected PDU session type is "Ethernet", the PDU SESSION ESTABLISHMENT REQUEST message includes a 5GSM capability IE with the EPT-S1 bit set to "Ethernet PDN type in S1 mode supported" and the network supports Ethernet PDN type in S1 mode, the SMF shall set the EPT-S1 bit of the 5GSM network feature support IE of the PDU SESSION ESTABLISHMENT ACCEPT message to "Ethernet PDN type in S1 mode supported".

If the AMF has indicated to the SMF that the UE supports the non-3GPP access path switching and the SMF supports the non-3GPP access path switching, the SMF shall set the NAPS bit of the 5GSM network feature support IE of the PDU SESSION ESTABLISHMENT ACCEPT message to "non-3GPP access path switching supported".

If the DN authentication of the UE was performed and completed successfully, the SMF shall set the EAP message IE of the PDU SESSION ESTABLISHMENT ACCEPT message to an EAP-success message as specified in IETF RFC 3748 [34], provided by the DN.

Based on local policies or configurations in the SMF and the Always-on PDU session requested IE in the PDU SESSION ESTABLISHMENT REQUEST message (if available), if the SMF determines that either:

the requested PDU session needs to be established as an always-on PDU session (e.g. because the PDU session is for time synchronization or TSC, for URLLC, or for both), the SMF shall include the Always-on PDU session indication IE in the PDU SESSION ESTABLISHMENT ACCEPT message and shall set the value to "Always-on PDU session required"; or
the requested PDU session shall not be established as an always-on PDU session and:

if the UE included the Always-on PDU session requested IE, the SMF shall include the Always-on PDU session indication IE in the PDU SESSION ESTABLISHMENT ACCEPT message and shall set the value to "Always-on PDU session not allowed"; or
if the UE did not include the Always-on PDU session requested IE, the SMF shall not include the Always-on PDU session indication IE in the PDU SESSION ESTABLISHMENT ACCEPT message.

If the PDU session is an MA PDU session, the SMF shall include the ATSSS container IE in the PDU SESSION ESTABLISHMENT ACCEPT message. The SMF shall set the content of the ATSSS container IE as specified in 3GPP TS 24.193 [13B]. If the UE requests to establish user plane resources over the second access of an MA PDU session which has already been established over the first access and the parameters associated with ATSSS previously provided to the UE are not to be updated, the "ATSSS container contents" shall not be included in the ATSSS container IE in the PDU SESSION ESTABLISHMENT ACCEPT message.

If the PDU session is a single access PDU session containing the MA PDU session information IE with the value set to "MA PDU session network upgrade is allowed" and:

if the SMF decides to establish a single access PDU session, the SMF shall not include the ATSSS container IE in the PDU SESSION ESTABLISHMENT ACCEPT message; or
if the SMF decides to establish an MA PDU session, the SMF shall include the ATSSS container IE in the PDU SESSION ESTABLISHMENT ACCEPT message, which indicates to the UE that the requested single access PDU session was established as an MA PDU Session.

If the network decides that the PDU session is only for control plane CIoT 5GS optimization, the SMF shall include the control plane only indication in the PDU SESSION ESTABLISHMENT ACCEPT message.

If:

the UE provided the IP header compression configuration IE in the PDU SESSION ESTABLISHMENT REQUEST message; and
the SMF supports IP header compression for control plane CIoT 5GS optimization;

the SMF shall include the IP header compression configuration IE in the PDU SESSION ESTABLISHMENT ACCEPT message.

If:

the UE provided the Ethernet header compression configuration IE in the PDU SESSION ESTABLISHMENT REQUEST message; and
the SMF supports Ethernet header compression for control plane CIoT 5GS optimization;

the SMF shall include the Ethernet header compression configuration IE in the PDU SESSION ESTABLISHMENT ACCEPT message.

If the PDU SESSION ESTABLISHMENT REQUEST included the Requested MBS container IE with the MBS operation set to "Join MBS session", the SMF:

shall include the TMGI for the multicast MBS session IDs that the UE is allowed to join, if any, in the Received MBS container IE, shall set the MBS decision to "MBS join is accepted" for each of those Received MBS information, may include the MBS start time to indicate the time when the multicast MBS session starts and shall include the MBS security container in each of those Received MBS information if security protection is applied for that multicast MBS session and the control plane security procedure is used as specified in clause W.4.1.2 in 3GPP TS 33.501 [24], and shall use separate QoS flows dedicated for multicast by including the Authorized QoS flow descriptions IE if no separate QoS flows dedicated for multicast exist or if the SMF wants to establish new QoS flows dedicated for multicast;

NOTE 5: The network determines whether security protection applies or not for the multicast MBS session as specified in 3GPP TS 33.501 [24].

shall include the TMGI for multicast MBS session IDs that the UE is not allowed to join, if any, in the Received MBS container IE, shall set the MBS decision to "MBS join is rejected" for each of those Received MBS information, shall set the Rejection cause for each of those Received MBS information with the reason of rejection, and if the Rejection cause is set to "multicast MBS session has not started or will not start soon", may include an MBS back-off timer value; and
may include in the Received MBS container IE the MBS service area for each multicast MBS session and include in it the MBS TAI list, the NR CGI list or both, that identify the service area(s) for the local MBS service

NOTE 6: For an multicast MBS session that has multiple MBS service areas, the MBS service areas are indicated to the UE using MBS service announcement as described in 3GPP TS 23.247 [53], which is out of scope of this specification.

in the PDU SESSION ESTABLISHMENT ACCEPT message. If the UE has set the Type of multicast MBS session ID to "Source specific IP multicast address" in the Requested multicast MBS container IE for certain MBS session(s) in the PDU SESSION ESTABLISHMENT REQUEST message, the SMF shall include the Source IP address information and Destination IP address information in the Received MBS information together with the TMGI for each of those multicast MBS sessions.

NOTE 7: Including the Source IP address information and Destination IP address information in the Received MBS information in that case is to allow the UE to perform the mapping between the requested multicast MBS session ID and the provided TMGI.

NOTE 8: In SNPN, TMGI is used together with NID to identify an MBS Session.

If the request type is "existing PDU session", the SMF shall not perform network slice admission control for the PDU session, except for the following cases:

when EPS counting is not required for the S-NSSAI of the PDU session for network slice admission control and the PDU session is established due to transfer the PDN connection from S1 mode to N1 mode in case of inter-system change; or
handover of an existing PDU session between 3GPP access and non-3GPP access is performed.

The SMF shall send the PDU SESSION ESTABLISHMENT ACCEPT message.

Upon receipt of a PDU SESSION ESTABLISHMENT ACCEPT message and a PDU session ID, using the NAS transport procedure as specified in clause 5.4.5, the UE shall stop timer T3580, shall release the allocated PTI value and shall consider that the PDU session was established.

If the PDU session establishment procedure was initiated to perform handover of an existing PDU session between 3GPP access and non-3GPP access, then upon receipt of the PDU SESSION ESTABLISHMENT ACCEPT message the UE shall locally delete any authorized QoS rules, authorized QoS flow descriptions, the session-AMBR and the parameters provided in the Protocol configuration options IE when in S1 mode or the Extended protocol configuration options IE stored for the PDU session before processing the new received authorized QoS rules, authorized QoS flow descriptions, the session-AMBR and the parameters provided in the Extended protocol configuration options IE, if any.

NOTE 9: For the case of handover from 3GPP access to non-3GPP access, deletion of the QoS flow descriptions implies deletion of the associated EPS bearer identities, if any, and according to clause 6.1.4.1 also deletion of the associated EPS bearer contexts. Regarding the reverse direction, for PDU sessions via non-3GPP access the network does not allocate associated EPS bearer identities (see 3GPP TS 23.502 [9], clause 4.11.1.4.1).

If the PDU session establishment procedure was initiated to perform handover of an existing PDU session from 3GPP access to non-3GPP access and that existing PDU session is associated with one or more multicast MBS sessions, the UE shall locally leave the associated multicast MBS sessions and the SMF shall consider the UE as removed from the associated multicast MBS sessions.

For an MA PDU session already established on a single access, except for all those MA PDU sessions with a PDN connection established as a user-plane resource, upon receipt of PDU SESSION ESTABLISHMENT ACCEPT message over the other access:

the UE shall delete the stored authorized QoS rules and the stored session-AMBR;
if the authorized QoS flow descriptions IE is included in the PDU SESSION ESTABLISHMENT ACCEPT message, the UE shall delete the stored authorized QoS flow descriptions; and
if the mapped EPS bearer contexts IE is included in the PDU SESSION ESTABLISHMENT ACCEPT message, the UE shall delete the stored mapped EPS bearer contexts.

If the UE supports network slice usage control and:

a PDU session is successfully established for the on-demand S-NSSAI, the UE shall stop and reset the slice deregistration inactivity timer for the on-demand S-NSSAI over corresponding access type, if running; and
an MA PDU session is successfully established for the on-demand S-NSSAI, the UE shall stop and reset the slice deregistration inactivity timer for the on-demand S-NSSAI over both 3GPP access and non-3GPP access, if running.

The UE shall store the authorized QoS rules, and the session-AMBR received in the PDU SESSION ESTABLISHMENT ACCEPT message for the PDU session. The UE shall also store the authorized QoS flow descriptions if it is included in the Authorized QoS flow descriptions IE of the PDU SESSION ESTABLISHMENT ACCEPT message for the PDU session.

If the number of the authorized QoS rules, the number of the packet filters, or the number of the authorized QoS flow descriptions associated with the PDU session have reached the maximum number supported by the UE upon receipt of a PDU SESSION ESTABLISHMENT ACCEPT message, then the UE may initiate the PDU session release procedure by sending a PDU SESSION RELEASE REQUEST message with 5GSM cause #26 "insufficient resources".

For a PDU session that is being established with the request type set to "initial request", "initial emergency request" or "MA PDU request", or a PDU session that is being transferred from EPS to 5GS and established with the request type set to "existing PDU session" or "existing emergency PDU session" or a PDU session that is being handed over between non-3GPP access and 3GPP access and established with the request type set to "existing PDU session" or "existing emergency PDU session ", the UE shall verify the authorized QoS rules and the authorized QoS flow descriptions provided in the PDU SESSION ESTABLISHMENT ACCEPT message for different types of errors as follows:

Semantic errors in QoS operations:

When the rule operation is "Create new QoS rule", and the DQR bit is set to "the QoS rule is the default QoS rule" when there's already a default QoS rule.
When the rule operation is "Create new QoS rule", and there is no rule with the DQR bit set to "the QoS rule is the default QoS rule".
When the rule operation is "Create new QoS rule" and two or more QoS rules associated with this PDU session would have identical precedence values.
When the rule operation is an operation other than "Create new QoS rule".
When the rule operation is "Create new QoS rule", the DQR bit is set to "the QoS rule is not the default QoS rule", and the UE is in NB-N1 mode.
When the rule operation is "Create new QoS rule" and there is already an existing QoS rule with the same QoS rule identifier.
When the rule operation is "Create new QoS rule", the DQR bit is set to "the QoS rule is not the default QoS rule", and the PDU session type of the PDU session is "Unstructured".
When the flow description operation is an operation other than "Create new QoS flow description".

8a) When the flow description operation is "Create new QoS flow description" and there is already an existing QoS flow description with the same QoS flow identifier.

When the flow description operation is "Create new QoS flow description", the QFI associated with the QoS flow description is not the same as the QFI of the default QoS rule and the UE is NB-N1 mode.
When the flow description operation is "Create new QoS flow description", the QFI associated with the QoS flow description is not the same as the QFI of the default QoS rule, and the PDU session type of the PDU session is "Unstructured".
When the rule operation is "Create new QoS rule" and the DQR bit is set to "the QoS rule is not the default QoS rule" and one match-all packet filter is to be associated with the QoS rule.

In case 4, case 5, or case 7 if the rule operation is for a non-default QoS rule, the UE shall send a PDU SESSION MODIFICATION REQUEST message to delete the QoS rule with 5GSM cause #83 "semantic error in the QoS operation".

In case 6, if the existing QoS rule is not the default QoS rule and the DQR bit of the new QoS rule is set to "the QoS rule is not the default QoS rule", the UE shall not diagnose an error, further process the create request and, if it was processed successfully, delete the old QoS rule (i.e. the QoS rule that existed when case 6 was detected). If the existing QoS rule is the default QoS rule or the DQR bit of the new QoS rule is set to "the QoS rule is the default QoS rule", the UE shall initiate a PDU session release procedure by sending a PDU SESSION RELEASE REQUEST message with 5GSM cause #83 "semantic error in the QoS operation".

In case 8, case 9, or case 10, the UE shall send a PDU SESSION MODIFICATION REQUEST message to delete the QoS flow description with 5GSM cause #83 "semantic error in the QoS operation".

In case 8a, the UE shall not diagnose an error, further process the create request and, if it was processed successfully, delete the old QoS flow description (i.e. the QoS flow description that existed when case 8a was detected).

Otherwise for all the cases above, the UE shall initiate a PDU session release procedure by sending a PDU SESSION RELEASE REQUEST message with 5GSM cause #83 "semantic error in the QoS operation".

Syntactical errors in QoS operations:

When the rule operation is "Create new QoS rule", the QoS rule is a QoS rule of a PDU session of IPv4, IPv6, IPv4v6 or Ethernet PDU session type, and the packet filter list in the QoS rule is empty.
When the rule operation is "Create new QoS rule", the DQR bit is set to "the QoS rule is the default QoS rule", the PDU session type of the PDU session is "Unstructured", and the packet filter list in the QoS rule is not empty.
When there are other types of syntactical errors in the coding of the Authorized QoS rules IE or the Authorized QoS flow descriptions IE, such as: a mismatch between the number of packet filters subfield and the number of packet filters in the packet filter list when the rule operation is create new QoS rule", or the number of packet filters subfield is larger than the maximum possible number of packet filters in the packet filter list (i.e. there is no QoS rule precedence subfield included in the QoS rule IE), the QoS Rule Identifier is set to "no QoS rule identifier assigned", or the QoS flow identifier is set to "no QoS flow identifier assigned".
When, the rule operation is "Create new QoS rule", there is no QoS flow description with a QFI corresponding to the QFI of the resulting QoS rule and the UE determines, by using the QoS rule’s QFI as the 5QI, that there is a resulting QoS rule for a GBR QoS flow (as described in 3GPP TS 23.501 [8] table 5.7.4-1).
When the flow description operation is "Create new QoS flow description", and the UE determines that there is a QoS flow description of a GBR QoS flow (as described in 3GPP TS 23.501 [8] table 5.7.4-1) which lacks at least one of the mandatory parameters (i.e. GFBR uplink, GFBR downlink, MFBR uplink and MFBR downlink). If the QoS flow description does not include a 5QI, the UE determines this by using the QFI as the 5QI.

In case 1, case 3 or case 4, if the QoS rule is the default QoS rule, the UE shall initiate a PDU session release procedure by sending a PDU SESSION RELEASE REQUEST message with 5GSM cause #84 "syntactical error in the QoS operation". Otherwise, the UE shall send a PDU SESSION MODIFICATION REQUEST message including a requested QoS rule IE, a requested QoS flow description IE or both to delete the QoS rule, the QoS flow description or both with 5GSM cause #84 "syntactical error in the QoS operation".

In case 2, if the QoS rule is the default QoS rule, the UE shall send a PDU SESSION MODIFICATION REQUEST message including a requested QoS rule IE to delete all the packet filters of the default QoS rule. The UE shall include the 5GSM cause #84 "syntactical error in the QoS operation".

In case 5, if the default QoS rule is associated with the QoS flow description which lacks at least one of the mandatory parameters, the UE shall initiate a PDU session release procedure by sending a PDU SESSION RELEASE REQUEST message with 5GSM cause #84 "syntactical error in the QoS operation". Otherwise, the UE shall send a PDU SESSION MODIFICATION REQUEST message to delete the QoS flow description which lacks at least one of the mandatory parameters and the associated QoS rule(s), if any, with 5GSM cause #84 "syntactical error in the QoS operation".

NOTE 10: It is not considered an error if the UE determines that after processing all QoS operations on QoS rules and QoS flow descriptions there is a QoS flow description that is not associated with any QoS rule and the UE is not in NB-N1 mode.

Semantic errors in packet filters:

When a packet filter consists of conflicting packet filter components which would render the packet filter ineffective, i.e. no IP packet will ever fit this packet filter. How the UE determines a semantic error in a packet filter is outside the scope of the present document.

If the QoS rule is the default QoS rule, the UE shall initiate a PDU session release procedure by sending a PDU SESSION RELEASE REQUEST message with 5GSM cause #44 "semantic error in packet filter(s)". Otherwise, the UE shall send a PDU SESSION MODIFICATION REQUEST message to delete the QoS rule with 5GSM cause #44 "semantic error in packet filter(s)".

Syntactical errors in packet filters:

When the rule operation is "Create new QoS rule" and two or more packet filters in the resultant QoS rule would have identical packet filter identifiers.
When there are other types of syntactical errors in the coding of packet filters, such as the use of a reserved value for a packet filter component identifier.

If the QoS rule is the default QoS rule, the UE shall initiate a PDU session release procedure by sending a PDU SESSION RELEASE REQUEST message with 5GSM cause #45 "syntactical errors in packet filter(s)". Otherwise, the UE shall send a PDU SESSION MODIFICATION REQUEST message to delete the QoS rule with 5GSM cause #45 "syntactical errors in packet filter(s)".

If the Always-on PDU session indication IE is included in the PDU SESSION ESTABLISHMENT ACCEPT message and:

the value of the IE is set to "Always-on PDU session required", the UE shall consider the established PDU session as an always-on PDU session; or
the value of the IE is set to "Always-on PDU session not allowed", the UE shall not consider the established PDU session as an always-on PDU session.

The UE shall not consider the established PDU session as an always-on PDU session if the UE does not receive the Always-on PDU session indication IE in the PDU SESSION ESTABLISHMENT ACCEPT message.

The UE shall store the mapped EPS bearer contexts, if received in the PDU SESSION ESTABLISHMENT ACCEPT message. Furthermore, the UE shall also store the association between the QoS flow and the mapped EPS bearer context, for each QoS flow which can be transferred to EPS, based on the received EPS bearer identity parameter in Authorized QoS flow descriptions IE and the mapped EPS bearer contexts. The UE shall check each mapped EPS bearer context for different types of errors as follows:

NOTE 11: An error detected in a mapped EPS bearer context does not cause the UE to discard the Authorized QoS rules IE and Authorized QoS flow descriptions IE included in the PDU SESSION ESTABLISHMENT ACCEPT, if any.

Semantic error in the mapped EPS bearer operation:

When the operation code is an operation code other than "Create new EPS bearer".
When the operation code is "Create new EPS bearer" and there is already an existing mapped EPS bearer context with the same EPS bearer identity associated with any PDU session.
When the operation code is "Create new EPS bearer" and the resulting mapped EPS bearer context has invalid mandatory parameters or missing mandatory parameters (e.g. mapped EPS QoS parameters or traffic flow template for a dedicated EPS bearer context).

In case 2, if the existing mapped EPS bearer context is associated with the PDU session that is being established, the UE shall not diagnose an error, further process the create request and, if it was process successfully, delete the old EPS bearer context.

Otherwise, the UE shall initiate a PDU session modification procedure by sending a PDU SESSION MODIFICATION REQUEST message to delete the mapped EPS bearer context with 5GSM cause #85 "Invalid mapped EPS bearer identity".

if the mapped EPS bearer context includes a traffic flow template, the UE shall check the traffic flow template for different types of TFT IE errors as follows:

Semantic errors in TFT operations:

When the TFT operation is an operation other than "Create new TFT"

The UE shall initiate a PDU session modification procedure by sending a PDU SESSION MODIFICATION REQUEST message to delete the mapped EPS bearer context with 5GSM cause #41 "semantic error in the TFT operation".

Syntactical errors in TFT operations:

When the TFT operation = "Create new TFT" and the packet filter list in the TFT IE is empty.
When there are other types of syntactical errors in the coding of the TFT IE, such as a mismatch between the number of packet filters subfield, and the number of packet filters in the packet filter list.

The UE shall initiate a PDU session modification procedure by sending a PDU SESSION MODIFICATION REQUEST message with to delete the mapped EPS bearer context 5GSM cause #42 "syntactical error in the TFT operation".

Semantic errors in packet filters:

When a packet filter consists of conflicting packet filter components which would render the packet filter ineffective, i.e. no IP packet will ever fit this packet filter. How the UE determines a semantic error in a packet filter is outside the scope of the present document.
When the resulting TFT, which is assigned to a dedicated EPS bearer context, does not contain any packet filter which applicable for the uplink direction.

The UE shall initiate a PDU session modification procedure by sending a PDU SESSION MODIFICATION REQUEST message to delete the mapped EPS bearer context with 5GSM cause #44 "semantic errors in packet filter(s)".

Syntactical errors in packet filters:

When the TFT operation = "Create new TFT" and two or more packet filters in the resultant TFT would have identical packet filter identifiers.
When the TFT operation = "Create new TFT" and two or more packet filters in all TFTs associated with this PDN connection would have identical packet filter precedence values.

iii) When there are other types of syntactical errors in the coding of packet filters, such as the use of a reserved value for a packet filter component identifier.

In case ii, if the old packet filters do not belong to the default EPS bearer context, the UE shall not diagnose an error and shall delete the old packet filters which have identical filter precedence values.

In case ii, if one or more old packet filters belong to the default EPS bearer context, the UE shall initiate a PDU session modification procedure by sending a PDU SESSION MODIFICATION REQUEST message to delete the mapped EPS bearer context with 5GSM cause #45 "syntactical errors in packet filter(s)".

In cases i and iii the UE shall initiate a PDU session modification procedure by sending a PDU SESSION MODIFICATION REQUEST message to delete the mapped EPS bearer context with 5GSM cause #45 "syntactical error in packet filter(s)".

If the UE detects different errors in the mapped EPS bearer contexts, QoS rules or QoS flow descriptions, the UE may send a single PDU SESSION MODIFICATION REQUEST message to delete the erroneous mapped EPS bearer contexts, QoS rules or QoS flow descriptions. In that case, the UE shall include a single 5GSM cause in the PDU SESSION MODIFICATION REQUEST message.

NOTE 12: The 5GSM cause to use cannot be different from: #41 "semantic error in the TFT operation", #42 "syntactical error in the TFT operation", #44 "semantic error in packet filter(s)", #45 "syntactical errors in packet filter(s)", #83 "semantic error in the QoS operation", #84 "syntactical error in the QoS operation", and #85 "Invalid mapped EPS bearer identity". The selection of a 5GSM cause is up to the UE implementation.

If there are mapped EPS bearer context(s) associated with a PDU session, but none of them is associated with the default QoS rule, the UE shall initiate a PDU session modification procedure by sending a PDU SESSION MODIFICATION REQUEST message to delete the mapped EPS bearer context(s) with 5GSM cause #85 "Invalid mapped EPS bearer identity" and shall locally delete the stored EPS bearer identity (EBI) in all the QoS flow descriptions of the PDU session, if any.

The UE shall only use the Control plane CIoT 5GS optimization for this PDU session if the Control plane only indication is included in the PDU SESSION ESTABLISHMENT ACCEPT message.

If the UE requests the PDU session type "IPv4v6" and:

the UE receives the selected PDU session type set to "IPv4" and does not receive the 5GSM cause value #50 "PDU session type IPv4 only allowed"; or
the UE receives the selected PDU session type set to "IPv6" and does not receive the 5GSM cause value #51 "PDU session type IPv6 only allowed";

the UE may subsequently request another PDU session for the other IP version using the UE-requested PDU session establishment procedure to the same DNN (or no DNN, if no DNN was indicated by the UE) and the same S-NSSAI associated with (if available) a mapped S-NSSAI (or no S-NSSAI, if no S-NSSAI was indicated by the UE) with a single address PDN type (IPv4 or IPv6) other than the one already activated.

If the UE requests the PDU session type "IPv4v6", receives the selected PDU session type set to "IPv4" and the 5GSM cause value #50 "PDU session type IPv4 only allowed", the UE shall not subsequently request another PDU session using the UE-requested PDU session establishment procedure to the same DNN (or no DNN, if no DNN was indicated by the UE) and the same S-NSSAI associated with (if available) a mapped S-NSSAI (or no S-NSSAI, if no S-NSSAI was indicated by the UE) to obtain a PDU session type different from the one allowed by the network until any of the following conditions is fulfilled:

the UE is registered to a new PLMN;
the UE is switched off;
the USIM is removed;
the entry in the "list of subscriber data" for the current SNPN is updated if the UE does not support access to an SNPN using credentials from a credentials holder and equivalent SNPNs; or
the selected entry of the "list of subscriber data" is updated or USIM is removed for the selected PLMN subscription, if the UE supports access to an SNPN using credentials from a credentials holder, equivalent SNPNs or both.

If the UE requests the PDU session type "IPv4v6", receives the selected PDU session type set to "IPv6" and the 5GSM cause value #51 "PDU session type IPv6 only allowed", the UE shall not subsequently request another PDU session using the UE-requested PDU session establishment procedure to the same DNN (or no DNN, if no DNN was indicated by the UE) and the same S-NSSAI associated with (if available) a mapped S-NSSAI (or no S-NSSAI, if no S-NSSAI was indicated by the UE) to obtain a PDU session type different from the one allowed by the network until any of the following conditions is fulfilled:

the UE is registered to a new PLMN;
the UE is switched off;
the USIM is removed
the entry in the "list of subscriber data" for the current SNPN is updated if the UE does not support access to an SNPN using credentials from a credentials holder and equivalent SNPNs; or
the selected entry of the "list of subscriber data" is updated or USIM is removed for the selected PLMN subscription, if the UE supports access to an SNPN using credentials from a credentials holder, equivalent SNPNs or both.

NOTE 13: For the 5GSM cause values #50 "PDU session type IPv4 only allowed", and #51 "PDU session type IPv6 only allowed", re-attempt in S1 mode for the same DNN (or no DNN, if no DNN was indicated by the UE) is only allowed using the PDU session type(s) indicated by the network.

If the selected PDU session type of the PDU session is "Unstructured" or "Ethernet", the UE supports inter-system change from N1 mode to S1 mode, the UE does not support establishment of a PDN connection for the PDN type set to "non-IP" in S1 mode, and the parameters list field of one or more authorized QoS flow descriptions received in the Authorized QoS flow descriptions IE of the PDU SESSION ESTABLISHMENT ACCEPT message contains an EPS bearer identity (EBI), then the UE shall locally remove the EPS bearer identity (EBI) from the parameters list field of such one or more authorized QoS flow descriptions. Additionally the UE shall also initiate a PDU session modification procedure by sending a PDU SESSION MODIFICATION REQUEST message to delete the mapped EPS bearer context with 5GSM cause #85 "Invalid mapped EPS bearer identity".

If the selected PDU session type of the PDU session is "Ethernet", the UE supports inter-system change from N1 mode to S1 mode, the UE does not support establishment of a PDN connection for the PDN type set to "non-IP" in S1 mode, the UE, the network or both of them do not support Ethernet PDN type in S1 mode, and the parameters list field of one or more authorized QoS flow descriptions received in the Authorized QoS flow descriptions IE of the PDU SESSION ESTABLISHMENT ACCEPT message contains an EPS bearer identity (EBI), then the UE shall locally remove the EPS bearer identity (EBI) from the parameters list field of such one or more authorized QoS flow descriptions. Additionally, the UE shall also initiate a PDU session modification procedure by sending a PDU SESSION MODIFICATION REQUEST message to delete the mapped EPS bearer context with 5GSM cause #85 "Invalid mapped EPS bearer identity".

For a UE which is registered for disaster roaming services and for a PDU session which is not a PDU session for emergency services:

if the parameters list field of one or more authorized QoS flow descriptions received in the Authorized QoS flow descriptions IE of the PDU SESSION ESTABLISHMENT ACCEPT message contains an EPS bearer identity (EBI), then the UE shall locally remove the EPS bearer identity (EBI) from the parameters list field of such one or more authorized QoS flow descriptions; and
the UE shall locally delete the contents of the Mapped EPS bearer contexts IE if it is received in the PDU SESSION ESTABLISHMENT ACCEPT message.

If the UE receives an IPv4 Link MTU parameter, an Ethernet Frame Payload MTU parameter, an Unstructured Link MTU parameter, or a Non-IP Link MTU parameter in the Extended protocol configuration options IE of the PDU SESSION ESTABLISHMENT ACCEPT message, the UE shall pass to the upper layer the received IPv4 link MTU size, the received Ethernet frame payload MTU size, the unstructured link MTU size, or the non-IP link MTU size.

NOTE 14: The IPv4 link MTU size corresponds to the maximum length of user data packet that can be sent either via the control plane or via N3 interface for a PDU session of the "IPv4" PDU session type.

NOTE 15: The Ethernet frame payload MTU size corresponds to the maximum length of a payload of an Ethernet frame that can be sent either via the control plane or via N3 interface for a PDU session of the "Ethernet" PDU session type.

NOTE 16: The unstructured link MTU size correspond to the maximum length of user data packet that can be sent either via the control plane or via N3 interface for a PDU session of the "Unstructured" PDU session type.

NOTE 17: A PDU session of "Ethernet" or "Unstructured" PDU session type can be transferred to a PDN connection of "non-IP" PDN type, thus the UE can request the non-IP link MTU parameter in the PDU session establishment procedure. The non-IP link MTU size corresponds to the maximum length of user data that can be sent either in the user data container in the ESM DATA TRANSPORT message or via S1-U interface as specified in 3GPP TS 24.301 [15].

If the 5G-RG receives an ACS information parameter in the Extended protocol configuration options IE of the PDU SESSION ESTABLISHMENT ACCEPT message, the 5G-RG shall pass the ACS URL in the received ACS information parameter to the upper layer.

If the UE has indicated support for CIoT 5GS optimizations and receives a small data rate control parameters container in the Extended protocol configuration options IE in the PDU SESSION ESTABLISHMENT ACCEPT message, the UE shall store the small data rate control parameters value and use the stored small data rate control parameters value as the maximum allowed limit of uplink user data for the PDU session in accordance with 3GPP TS 23.501 [8].

If the UE has indicated support for CIoT 5GS optimizations and receives an additional small data rate control parameters for exception data container in the Extended protocol configuration options IE in the PDU SESSION ESTABLISHMENT ACCEPT message, the UE shall store the additional small data rate control parameters for exception data value and use the stored additional small data rate control parameters for exception data value as the maximum allowed limit of uplink exception data for the PDU session in accordance with 3GPP TS 23.501 [8].

If the UE has indicated support for CIoT 5GS optimizations and receives an initial small data rate control parameters container or an initial additional small data rate control parameters for exception data container in the Extended protocol configuration options IE in the PDU SESSION ESTABLISHMENT ACCEPT message, the UE shall use these parameters for the newly established PDU Session. When the validity period of the initial parameters expire, the parameters received in a small data rate control parameters container or an additional small data rate control parameters for exception data container shall be used.

If the UE receives a Serving PLMN rate control IE in the PDU SESSION ESTABLISHMENT ACCEPT message, the UE shall store the Serving PLMN rate control IE value and use the stored serving PLMN rate control value as the maximum allowed limit of uplink control plane user data for the corresponding PDU session in accordance with 3GPP TS 23.501 [8].

If the UE receives an APN rate control parameters container or an additional APN rate control for exception data parameters container in the Extended protocol configuration options IE in the PDU SESSION ESTABLISHMENT ACCEPT message, the UE shall store these parameters and use them to limit the rate at which it generates uplink user data messages for the PDN connection corresponding to the PDU session if the PDU session is transferred to EPS upon inter-system change from N1 mode to S1 mode in accordance with 3GPP TS 24.301 [15]. The received APN rate control parameters and additional APN rate control for exception data parameters shall replace any previously stored APN rate control parameters and additional APN rate control for exception data parameters, respectively, for this PDN connection.

If the UE receives an initial APN rate control parameters container or an initial additional APN rate control for exception data parameters container in the Extended protocol configuration options IE in the PDU SESSION ESTABLISHMENT ACCEPT message, the UE shall store these parameters in the APN rate control status and use them to limit the rate at which it generates exception data messages for the PDN connection corresponding to the PDU session if the PDU session is transferred to EPS upon inter-system change from N1 mode to S1 mode in accordance with 3GPP TS 24.301 [15]. The received APN rate control status shall replace any previously stored APN rate control status for this PDN connection.

NOTE 18: In the PDU SESSION ESTABLISHMENT ACCEPT message, the SMF provides either APN rate control parameters container, or initial APN rate control parameters container, in the Extended protocol configuration options IE, but not both.

NOTE 19: In the PDU SESSION ESTABLISHMENT ACCEPT message, the SMF provides either additional APN rate control for exception data parameters container, or initial additional APN rate control for exception data parameters container, in the Extended protocol configuration options IE, but not both.

If the network accepts the use of Reliable Data Service to transfer data for the PDU session, the network shall include the Extended protocol configuration options IE in the PDU SESSION ESTABLISHMENT ACCEPT message and include the Reliable Data Service accepted indicator. The UE behaves as described in clause 6.2.15.

the UE indicates support of DNS over (D)TLS by providing DNS server security information indicator to the network;
optionally, the UE indicates which security protocol type(s) are supported by the UE, by providing the DNS server security protocol support to the network; and
the network wants to enforce the use of DNS over (D)TLS,

the network may include the Extended protocol configuration options IE in the PDU SESSION ESTABLISHMENT ACCEPT message and include the DNS server security information with length of two octets. Upon receiving the DNS server security information, the UE shall pass it to the upper layer. The UE shall use this information to send the DNS over (D)TLS (See 3GPP TS 33.501 [24]).

NOTE 20: Support of DNS over (D)TLS is based on the requirements as specified in 3GPP TS 33.501 [24] and it is implemented based on the operator requirement.

If the PDU SESSION ESTABLISHMENT REQUEST message includes the Service-level-AA container IE with the service-level device ID set to the CAA-level UAV ID, and the SMF is provided by the UAS-NF the successful UUAA-SM result and the CAA-level UAV ID, the SMF shall store the successful result together with the authorized CAA-level UAV ID and transmit the PDU SESSION ESTABLISHMENT ACCEPT message to the UE, where the PDU SESSION ESTABLISHMENT ACCEPT message shall include the Service-level-AA container IE containing:

the service-level-AA response, with the SLAR field set to "Service level authentication and authorization was successful";
the service-level device ID with the value set to the CAA-level UAV ID; and
if a payload is received from the UAS-NF,the service-level-AA payload, with the value set to the payload;
if a payload type associated with the payload is received from the UAS-NF, the service-level-AA payload type with the values set to the associated payload type.

NOTE 21: UAS security information can be included in the UUAA payload by the USS as specified in 3GPP TS 33.256 [24B].

NOTE 21A: A list of USS addresses, where each entry contains a USS address and a corresponding geographical area, can be included in the UUAA payload by the USS as specified in 3GPP TS 23.256 [6AB].

If the network accepts the request of the PDU session establishment for C2 communication, the network shall send the PDU SESSION ESTABLISHMENT ACCEPT message including the Service-level-AA container IE containing:

the service-level-AA response with the value of C2AR field set to the "C2 authorization was successful";
if a payload is provided from the UAS-NF, the service-level-AA payload with the value set to the payload;
if a payload type associated with the payload is provided from the UAS-NF, the service-level-AA payload type with the value set to the payload type; and
if the CAA-level UAV ID is provided from the UAS-NF, the service-level device ID with the value set to the CAA-level UAV ID.

NOTE 22:The C2 authorization payload in the service-level-AA payload can include one or both of the C2 session security information, and pairing information for direct C2 communication.

Upon receipt of the PDU SESSION ESTABLISHMENT ACCEPT message of the PDU session for C2 communication, if the Service-level-AA container IE is included, the UE shall forward the service-level-AA contents of the Service-level-AA container IE to the upper layers.

The SMF may be configured with one or more PVS IP addresses or PVS names or both associated with the DNN and S-NSSAI used for onboarding services in SNPN, for configuration of SNPN subscription parameters in PLMN via the user plane, or for configuration of a UE via the user plane with credentials for NSSAA or PDU session authentication and authorization procedure. If the PDU session was established for onboarding services in SNPN, or the PVS information request is included in the Extended protocol configuration options IE of the PDU SESSION ESTABLISHMENT REQUEST message establishing a PDU session providing connectivity for configuration of SNPN subscription parameters in PLMN via the user plane, the network may include the Extended protocol configuration options IE in the PDU SESSION ESTABLISHMENT ACCEPT message and include the PVS IP address(es) or the PVS name(s) or both associated with the DNN and S-NSSAI of the established PDU session, if available. If the PVS information request is included in the Extended protocol configuration options IE of the PDU SESSION ESTABLISHMENT REQUEST message establishing the PDU session providing connectivity for configuration of a UE via the user plane with credentials for PDU session authentication and authorization procedure, based on the subscribed DNN(s) and S-NSSAI(s) of the UE and the DNN and S-NSSAI of the established PDU session, the network should include the Extended protocol configuration options IE in the PDU SESSION ESTABLISHMENT ACCEPT message and include the PVS IP address(es) or the PVS name(s) or both, which are associated with the established PDU session and per subscribed DNN(s) and S-NSSAI(s) of the UE, if available. If the PVS information request is included in the Extended protocol configuration options IE of the PDU SESSION ESTABLISHMENT REQUEST message establishing the PDU session providing connectivity for configuration of a UE via the user plane with credentials for NSSAA, based on the subscribed S-NSSAI(s) of the UE and the S-NSSAI of the established PDU session, the network should include the Extended protocol configuration options IE in the PDU SESSION ESTABLISHMENT ACCEPT message and include the PVS IP address(es) or the PVS name(s) or both, which are associated with the established PDU session and per subscribed S-NSSAI(s) of the UE, if available.

NOTE 23: If the PVS information request is included in the Extended protocol configuration options IE of the PDU SESSION ESTABLISHMENT REQUEST message establishing a PDU session providing connectivity for configuration of SNPN subscription parameters in SNPN via the user plane by a UE which is not registered for onboarding services in SNPN, the SMF can include the PVS IP address(es) or the PVS name(s) or both, associated with the DNN and S-NSSAI of the established PDU session, if available, in the Extended protocol configuration options IE of the PDU SESSION ESTABLISHMENT ACCEPT message.

NOTE 24: The PVS IP address(es) or the PVS name(s) or both in the SMF can either be locally configured or provided by DCS. The SMF can send the PVS IP address(es) or the PVS name(s) or both that are available in the SMF as the PVS IP address(es) or the PVS name(s) or both to the UE, respectively. If the PDU session was established for onboarding services in SNPN not supporting localized services in SNPN, the PVS IP address(es) or the PVS name(s) or both provided by DCS takes precedence over the PVS IP address(es) or the PVS name(s) or both locally configured, respectively. If the PDU session was established for onboarding services in SNPN supporting localized services in SNPN, the SMF can include both the DCS provided PVS IP address(es) or the PVS name(s) or both associated with the DNN and S-NSSAI of the established PDU session and the locally configured PVS IP address(es) or the PVS name(s) or both associated with the DNN and S-NSSAI of the established PDU session, if available.

The UE upon receiving one or more PVS IP address(es), if any, one or more the PVS name(s), if any, or both shall pass them to the upper layers.

NOTE 25: If several PVS IP addresses, several PVS name(s), or one or more PVS IP addresses and one or more PVS name(s) are received, how the UE uses this information is up to UE implementation.

If the UE indicates support for ECS configuration information provisioning by providing the ECS configuration information provisioning support indicator in the Extended protocol configuration options IE of the PDU SESSION ESTABLISHMENT REQUEST message, then the SMF may include the Extended protocol configuration options IE in the PDU SESSION ESTABLISHMENT ACCEPT message with

at least one of ECS IPv4 Address(es), ECS IPv6 Address(es), and ECS FQDN(s);
at least one associated ECSP identifier;
optionally, spatial validity conditions associated with the ECS address;
optionally, ECS authentication methods associated with the ECS address; and
optionally, ECS supported PLMNs information list, including the associated ECSP information for which the EDN configuration information can be provided by the ECS.

The UE upon receiving one or more ECS IPv4 address(es), if any, ECS IPv6 address(es), if any, or ECS FQDN(s), if any, with the associated spatial validity condition, if any, the associated ECS authentication methods, if any, ECS supported PLMNs information list, if any and an ECSP identifier shall pass them to the upper layers.

NOTE 26: The IP address(es), FQDN(s), or both are associated with the ECSP identifier and replace previously provided ECS configuration information associated with the same ECSP identifier, if any.

If the SMF needs to provide DNS server address(es) to the UE and the UE has provided the DNS server IPv4 address request, the DNS server IPv6 address request or both of them, in the PDU SESSION ESTABLISHMENT REQUEST message, then the SMF shall include the Extended protocol configuration options IE in the PDU SESSION ESTABLISHMENT ACCEPT message with one or more DNS server IPv4 address(es), one or more DNS server IPv6 address(es) or both of them. If the UE supports receiving DNS server addresses in protocol configuration options and receives one or more DNS server IPv4 address(es), one or more DNS server IPv6 address(es) or both of them, in the Extended protocol configuration options IE of the PDU SESSION ESTABLISHMENT ACCEPT message, then the UE shall pass the received DNS server IPv4 address(es), if any, and the received DNS server IPv6 address(es), if any, to upper layers.

NOTE 27: The received DNS server address(es) replace previously provided DNS server address(es), if any.

If the PDU SESSION ESTABLISHMENT ACCEPT message includes the Received MBS container IE, for each of the Received MBS information:

if MBS decision is set to "MBS join is accepted", the UE shall consider that it has successfully joined the multicast MBS session. The UE shall store the received TMGI and shall use it for any further operation on that multicast MBS session. The UE shall store the received MBS service area associated with the received TMGI, if any, and provide the received TMGI to lower layers. The UE may provide the MBS start time if it is included in the Received MBS information to upper layers; or
if MBS decision is set to "MBS join is rejected", the UE shall consider the requested join as rejected. The UE shall store the received MBS service area associated with the received TMGI, if any. If the received Rejection cause is set to "User is outside of local MBS service area", the UE shall not request to join the same multicast MBS session if neither current TAI nor CGI of the current cell is part of the received MBS service area. If the received Rejection cause is set to "multicast MBS session has not started or will not start soon" and an MBS back-off timer value is included with value that indicates neither zero nor deactivated, the UE shall start a back-off timer T3587 with the value provided in the MBS back-off timer value for the received TMGI, and shall not attempt to join the multicast MBS session with the same TMGI until the expiry of T3587. If the MBS back-off timer value indicates that this timer is deactivated, the UE shall not attempt to join the multicast MBS session with the same TMGI, the Source IP address information of the TMGI, or the Destination IP address information of the TMGI until the UE is switched off, the USIM is removed, or the entry in the "list of subscriber data" for the current SNPN is updated. If the MBS back-off timer value indicates zero, the UE may attempt to join the multicast MBS session with the same TMGI.

If the UE is switched off when the timer T3587 is running, the UE may behave as follows when the UE is switched on and the USIM in the UE remains the same:

let t1 be the time remaining for T3587 timeout at switch off and let t be the time elapsed between switch off and switch on. If t1 is greater than t, then the timer shall be restarted with the value t1 – t. If t1 is equal to or less than t, then the timer need not be restarted.

If the PDU session is established for IMS signalling and the UE has requested P-CSCF IPv6 address or P-CSCF IPv4 address, the SMF shall include P-CSCF IP address(es) in the Extended protocol configuration options IE in the PDU SESSION ESTABLISHMENT ACCEPT message.

NOTE 28: The P-CSCF selection functionality is specified in clause 5.16.3.11 of 3GPP TS 23.501 [8].

Upon receipt of the PDU SESSION ESTABLISHMENT ACCEPT message, if the UE included the PDU session pair ID in the PDU SESSION ESTABLISHMENT REQUEST message, the UE shall associate the PDU session with the PDU session pair ID. If the UE included the RSN in the PDU SESSION ESTABLISHMENT REQUEST message, the UE shall associate the PDU session with the RSN.

If the PDU SESSION ESTABLISHMENT ACCEPT message include alternative S-NSSAI, the S-NSSAI for the established PDU session shall be the S-NSSAI to be replaced and the alternative S-NSSAI on the UE side.

If the UE supports EDC and the network allows the use of EDC, the SMF shall include the Extended protocol configuration options IE in the PDU SESSION ESTABLISHMENT ACCEPT message with the EDC usage allowed indicator. If the UE supports EDC and receives the EDC usage allowed indicator in the Extended protocol configuration options IE of the PDU SESSION ESTABLISHMENT ACCEPT message, the UE shall indicate to upper layers that network allows the use of EDC.

If the UE supports EDC and the network requires the use of EDC, the SMF shall include the Extended protocol configuration options IE in the PDU SESSION ESTABLISHMENT ACCEPT message with the EDC usage required indicator. If the UE supports EDC and receives the EDC usage required indicator in the Extended protocol configuration options IE of the PDU SESSION ESTABLISHMENT ACCEPT message, the UE shall indicate to upper layers that network requires the use of EDC.

If the PDU SESSION ESTABLISHMENT REQUEST message includes a MS support of MAC address range in 5GS indicator in the Extended protocol configuration options IE, the SMF:

shall consider that the UE supports a "destination MAC address range type" packet filter component and a "source MAC address range type" packet filter component; and
if the SMF supports a "destination MAC address range type" packet filter component and a "source MAC address range type" packet filter component and enables the UE to request QoS rules with a "destination MAC address range type" packet filter component and a "source MAC address range type" packet filter component, shall include the Extended protocol configuration options IE in the PDU SESSION ESTABLISHMENT ACCEPT message and shall include the Network support of MAC address range in 5GS indicator in the Extended protocol configuration options IE.

If the UE receives the 5GSM network feature support IE in the PDU SESSION ESTABLISHMENT ACCEPT message with the NAPS bit set to "non-3GPP access path switching supported" during the PDU session establishment procedure of any PDU session, the UE may include the NSONR bit with value set to "non-3GPP path switching while using old non-3GPP resources requested" in the Non-3GPP path switching information IE in the REGISTRATION REQUEST message while performing the registration procedure for mobility registration update for non-3GPP access path switching.

NOTE 29: If the UE is registered to different PLMNs over 3GPP and non-3GPP accesses, the UE uses the capability received over non-3GPP access to determine whether to initiate the registration procedure for mobility registration update for non-3GPP path switching.

NOTE 30: If the AMF selects an SMF not supporting non-3GPP access path switching, the non-3GPP access path switching can still be performed with the AMF triggering release of the old user plane resources before new user plane resources are established.

If the PDU SESSION ESTABLISHMENT ACCEPT message includes a Network support of MAC address range in 5GS indicator in the Extended protocol configuration options IE, the UE shall consider that the network supports a "destination MAC address range type" packet filter component and a "source MAC address range type" packet filter component.

NOTE 31: Handling of indication that network allows the use of EDC or that network requires the use of EDC is specified in 3GPP TS 23.548 [182].

If the SMF includes the authorized QoS flow descriptions and the SMF determines to provide the N3QAI to the UE, the SMF shall include the N3QAI IE in the PDU SESSION ESTABLISHMENT ACCEPT message.

If the SMF supports URSP provisioning in EPS and the URSP provisioning in EPS support indicator is included in the Extended protocol configuration options IE of the PDU SESSION ESTABLISHMENT REQUEST message, the SMF shall insert the URSP provisioning in EPS support indicator in the Extended protocol configuration options IE of the PDU SESSION ESTABLISHMENT ACCEPT message.

If the PDU session to be established is a single access PDU session with IP PDU session type and based on operator policy the SMF determines to provide the protocol description for UL PDU set based handling to the UE, the SMF may include the Protocol description IE in the PDU SESSION ESTABLISHMENT ACCEPT message.

If the PDU session was a single access PDU session established over wireline access with IP PDU session type and based on operator policy the SMF determines the ECN marking for L4S for the 5G-RG (see clause 4.17.2 of 3GPP TS 23.316 [6D]), the SMF may include the ECN marking for L4S indication IE in the PDU SESSION ESTABLISHMENT ACCEPT message.

If the UE has set the RTPMMII bit to "(S)RTP multiplexed media identification information supported" in the 5GSM capability IE of the PDU SESSION ESTABLISHMENT REQUEST message, the SMF may include the (S)RTP multiplexed media packet filter component in the packet filters of the QoS rules IE in the PDU SESSION ESTABLISHMENT ACCEPT message.

If the Protocol description IE is included in the PDU SESSION ESTABLISHMENT ACCEPT message, the UE shall, for each existing QoS rule, store the associated protocol description included in the Protocol description IE. The UE may use the protocol description information associated with the QoS rule(s) provided by the Protocol description IE to identify PDUs belonging to PDU sets for the uplink direction.

NOTE 32: Whether and how to use the protocol description information to identify PDU sets is up to the UE implementation.

If the ECN marking for L4S indication IE is included in the PDU SESSION ESTABLISHMENT ACCEPT message, the 5G-RG shall, for each existing QoS rule, store the associated ECN marking for L4S indication included in the ECN marking for L4S indication IE. The 5G-RG may perform the ECN marking for L4S for the corresponding QoS flow based on the ECN marking for L4S indication.

NOTE 33: How to perform the ECN marking for L4S for 5G-RG is out of the scope of this specification.