full Contents for  TS 23.501  Word version:   16.4.0

The 5GC supports a PDU Connectivity Service i.e. a service that provides exchange of PDUs between a UE and a data network identified by a DNN. The PDU Connectivity Service is supported via PDU Sessions that are established upon request from the UE. The Subscription Information for each S-NSSAI may contain a Subscribed DNN list and one default DNN. When the UE does not provide a DNN in a NAS Message containing PDU Session Establishment Request for a given S-NSSAI, the serving AMF determines the DNN for the requested PDU Session by selecting the default DNN for this S-NSSAI if a default DNN is present in the UE's Subscription Information; otherwise the serving AMF selects a locally configured DNN for this S-NSSAI. The expectation is that the URSP in the UE is always up to date using the procedure defined in TS 23.502, clause 4.16.12.2 and therefore the UE requested DNN will be up to date. In order to cover cases that UE operates using local configuration, but also other cases where operator policies can be used in order to replace an "up to date" UE requested DNN with another DNN used only internally in the network, during UE Registration procedure the PCF may indicate, to the AMF, the operator policies to be used at PDU Session Establishment for DNN replacement of a UE requested DNN. PCF may indicate a policy for DNN replacement of UE requested DNNs not supported by the network, and/or indicate a list of UE requested DNNs per S-NSSAI valid for the serving network, that are subject for replacement (details are described in TS 23.503). If the DNN provided by the UE is not supported by the network and AMF cannot select an SMF by querying NRF, the AMF shall reject the NAS Message containing PDU Session Establishment Request from the UE with a cause indicating that the DNN is not supported unless the PCF provided the policy to perform a DNN replacement of unsupported DNNs. If the DNN requested by the UE is indicated for replacement or the DNN provided by the UE is not supported by the network and the PCF provided the policy to perform DNN replacement of UE requested DNNs not supported by the network, the AMF shall interact with the PCF to perform a DNN replacement. During PDU Session Establishment procedure and as a result of DNN replacement, the PCF provides the selected DNN that is applicable for the S-NSSAI requested by the UE at the PDU Session Establishment. The AMF uses the selected DNN in the query towards the NRF for the SMF selection, as specified in clause 6.3.2, and provides both requested and selected DNN to the selected SMF. For PDU Session with Home-routed Roaming whether to perform DNN replacement is based on operator agreements. NOTE 1: Each PDU Session supports a single PDU Session type i.e. supports the exchange of a single type of PDU requested by the UE at the establishment of the PDU Session. The following PDU Session types are defined: IPv4, IPv6, IPv4v6, Ethernet, Unstructured. PDU Sessions are established (upon UE request), modified (upon UE and 5GC request) and released (upon UE and 5GC request) using NAS SM signalling exchanged over N1 between the UE and the SMF. Upon request from an Application Server, the 5GC is able to trigger a specific application in the UE. When receiving that trigger message, the UE shall pass it to the identified application in the UE. The identified application in the UE may establish a PDU Session to a specific DNN, see clause 4.4.5. SMF may support PDU Sessions for LADN where the access to a DN is only available in a specific LADN service area. This is further defined in clause 5.6.5. SMF may support PDU Sessions for a 5G VN group which offers a virtual data network capable of supporting 5G LAN-type service over the 5G system. This is further defined in clause 5.8.2.13. The SMF is responsible of checking whether the UE requests are compliant with the user subscription. For this purpose, it retrieves and requests to receive update notifications on SMF level subscription data from the UDM. Such data may indicate per DNN and per S-NSSAI of the HPLMN:

• The allowed PDU Session Types and the default PDU Session Type.
• The allowed SSC modes and the default SSC mode.
• QoS Information (refer to clause 5.7): the subscribed Session-AMBR, Default 5QI and Default ARP.
• The static IP address/prefix.
• The subscribed User Plane Security Policy.
• the Charging Characteristics to be associated with the PDU Session. Whether this information is provided by the UDM to a SMF in another PLMN (for PDU Sessions in LBO mode) is defined by operator policies in the UDM/UDR.

NOTE 2: A PDU Session may support:

1. a single-access PDU Connectivity Service, in which case the PDU Session is associated with a single access type at a given time, i.e. either 3GPP access or non-3GPP access; or
2. a multi-access PDU Connectivity Service, in which case the PDU Session is simultaneously associated with both 3GPP access and non-3GPP access and simultaneously associated with two independent N3/N9 tunnels between the PSA and RAN/AN.

A PDU Session supporting a single-access PDU Connectivity Service is also referred to as single-access PDU Session, while a PDU Session supporting a multi-access PDU Connectivity Service is referred to as Multi-Access PDU (MA PDU) Session and it is used to support the ATSSS feature (see clause 5.32 for details). A UE that is registered over multiple accesses chooses over which access to establish a PDU Session. As defined in TS 23.503, the HPLMN may send policies to the UE to guide the UE selection of the access over which to establish a PDU Session. NOTE 3: A UE may request to move a single-access PDU Session between 3GPP and Non 3GPP accesses. The decision to move single-access PDU Sessions between 3GPP access and Non 3GPP access is made on a per PDU Session basis, i.e. the UE may, at a given time, have some PDU Sessions using 3GPP access while other PDU Sessions are using Non 3GPP access. In a PDU Session Establishment Request message sent to the network, the UE shall provide a PDU Session ID. The PDU Session ID is unique per UE and is the identifier used to uniquely identify one of a UE's PDU Sessions. The PDU Session ID shall be stored in the UDM to support handover between 3GPP and non-3GPP access when different PLMNs are used for the two accesses. The UE also provides as described in TS 24.501:

1. PDU Session Type.
2. S-NSSAI of the HPLMN that matches the application (that is triggering the PDU Session Request) within the NSSP in the URSP rules or within the UE Local Configuration as defined in clause 6.1.2.2.1 of TS 23.503.
   NOTE 4:
   If the UE cannot determine any S-NSSAI after performing the association of the application to a PDU Session, then it does not indicate any S-NSSAI in the PDU Session Establishment procedure as defined in clause 5.15.5.3.
3. S-NSSAI of the Serving PLMN from the Allowed NSSAI, corresponding to the S-NSSAI of the HPLMN (b).
   NOTE 5:
   Generally, in non-roaming scenario the mapping of the Allowed NSSAI to HPLMN S-NSSAIs is not provided to the UE (because the S-NSSAI of the Serving PLMN (c) has the same value of the S-NSSAI of the HPLMN (b)), therefore the UE provides in the PDU Session Request only the S-NSSAI of the Serving PLMN (c). However, if the UE is provided with the mapping of the Allowed NSSAI to HPLMN S-NSSAIs even in non-roaming scenario, then the UE provides in the PDU Session Request both the S-NSSAI of the HPLMN (b) and the S-NSSAI from the Allowed NSSAI (c) that maps to the S-NSSAI of the HPLMN.
   NOTE 6:
   In roaming scenarios the UE provides in the PDU Session Request both the S-NSSAI of the HPLMN (b) and the S-NSSAI of the VPLMN from the Allowed NSSAI (c) that maps to the S-NSSAI of the HPLMN.
4. DNN (Data Network Name).
5. SSC mode (Service and Session Continuity mode defined in clause 5.6.9.2).

Additionally, if the UE supports ATSSS and wants to activate a MA PDU Session, the UE shall provide Request Type as "MA PDU Request" and shall indicate the supported ATSSS capabilities (see clause 5.32 for details).

Subscription Information may include a wildcard DNN per subscribed S-NSSAI: when a wildcard DNN is associated with a subscribed S-NSSAI, the subscription allows, for this S-NSSAI, the UE to establish a PDU Session using any DNN value. NOTE 7: 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. A UE may establish multiple PDU Sessions to the same Data Network and served by different UPF terminating N6. A UE with multiple established PDU Sessions may be served by different SMF. The SMF shall be registered and deregistered on a per PDU Session granularity in the UDM. The user plane paths of different PDU Sessions (to the same or to different DNN) belonging to the same UE may be completely disjoint between the AN and the UPF interfacing with the DN. When the SMF cannot control the UPF terminating the N3 interface used by a PDU Session and SSC mode 2/3 procedures are not applied to the PDU Session, an I-SMF is inserted between the SMF and the AMF and handling of PDU Session(s) is described in clause 5.34. NOTE 8: The SMF serving a PDU session (i.e. Anchor) does not change during lifetime of the PDU session.

The AMF and SMF are separate Network Functions. N1 related interaction with SMF is as follows:

• The single N1 termination point is located in AMF. The AMF forwards SM related NAS information to the SMF based on the PDU Session ID in the NAS message. Further SM NAS exchanges (e.g. SM NAS message responses) for N1 NAS signalling received by the AMF over an access (e.g. 3GPP access or non-3GPP access) are transported over the same access.
• The serving PLMN ensures that subsequent SM NAS exchanges (e.g. SM NAS message responses) for N1 NAS signalling received by the AMF over an access (e.g. 3GPP access or non-3GPP access) are transported over the same access.
• SMF handles the Session management part of NAS signalling exchanged with the UE.
• The UE shall only initiate PDU Session Establishment in RM-REGISTERED state.
• When a SMF has been selected to serve a specific PDU Session, AMF has to ensure that all NAS signalling related with this PDU Session is handled by the same SMF instance.
• Upon successful PDU Session Establishment, the AMF and SMF stores the Access Type that the PDU Session is associated.

N11 related interaction with SMF is as follows:

• The AMF reports the reachability of the UE based on a subscription from the SMF, including:
• The UE location information with respect to the area of interest indicated by the SMF.
• The SMF indicates to AMF when a PDU Session has been released.
• Upon successful PDU Session Establishment, AMF stores the identification of serving SMF of UE and SMF stores the identification of serving AMF of UE including the AMF set. When trying to reach the AMF serving the UE, the SMF may need to apply the behaviour described for "the other CP NFs" in clause 5.21.

N2 related interaction with SMF is as follows:

• Some N2 signalling (such as handover related signalling) may require the action of both AMF and SMF. In such case, the AMF is responsible to ensure the coordination between AMF and SMF. The AMF may forward the SM N2 signalling towards the corresponding SMF based on the PDU Session ID in N2 signalling.
• SMF shall provide PDU Session Type together with PDU Session ID to NG-RAN, in order to facilitate NG-RAN to apply suitable header compression mechanism to packet of different PDU type. Details refer to TS 38.413.

N3 related interaction with SMF is as follows:

• Selective activation and deactivation of UP connection of existing PDU Session is defined in clause 5.6.8.

N4 related interaction with SMF is as follows:

• When it is made aware by the UPF that some DL data has arrived for a UE without downlink N3 tunnel information, the SMF interacts with the AMF to initiate Network Triggered Service Request procedure. In this case, if the SMF is aware that the UE is unreachable or if the UE is reachable only for regulatory prioritized service and the PDU Session is not for regulatory prioritized service, then the SMF shall not inform DL data notification to the AMF

The AMF is responsible of selecting the SMF per procedures described in clause 6.3.2. For this purpose, it gets subscription data from the UDM that are defined in that clause. Furthermore, it retrieves the subscribed UE-AMBR from the UDM, and optionally dynamic serving network UE-AMBR from PCF based on operator local policy, and sends to the (R)AN as defined in clause 5.7.2 AMF-SMF interactions to support LADN are defined in clause 5.6.5. In order to support charging data collection and to fulfill regulatory requirement (in order to provide NPLI - Network Provided Location Information- as defined in TS 23.228) related with with the set-up, modification and release of IMS Voice calls or with SMS transfer the following applies

• At the time of the PDU Session Establishment, the AMF provides the SMF with the PEI of the UE if the PEI is available at the AMF.
• When it forwards UL NAS or N2 signalling to a peer NF (e.g. to SMF or to SMSF) or during the UP connection activation of a PDU Session, the AMF provides any User Location Information it has received from the 5G-AN as well as the Access Type (3GPP - Non 3GPP) of the AN over which it has received the UL NAS or N2 signalling. The AMF also provides the corresponding UE Time Zone. In addition, in order to fulfill regulatory requirement (i.e. providing Network Provided Location Information (NPLI), as defined in TS 23.228) when the access is non-3GPP, the AMF may also provide the last known 3GPP access User Location Information with its age, if the UE is still attached to the same AMF for 3GPP access (i.e. valid User Location Information).
The User Location Information, the access type and the UE Time Zone may be further provided by SMF to PCF. The PCF may get this information from the SMF in order to provide NPLI to applications (such as IMS) that have requested it.

The User Location Information may correspond to:

• In the case of 3GPP access: Cell-Id. The AMF includes only the Primary Cell-Id even if it had received also the Cell-Id of the Primary cell in the Secondary RAN node from NG-RAN.
• In the case of Untrusted non-3GPP access: a UE local IP address (used to reach the N3IWF) and optionally UDP or TCP source port number (if NAT is detected).
• In the case of Trusted non-3GPP access: TNAP/TWAP Identifier, a UE/N5CW device local IP address (used to reach the TNGF/TWIF) and optionally UDP or TCP source port number (if NAT is detected).
When the UE uses WLAN based on IEEE 802.11 technology to reach the TNGF, the TNAP Identifier shall include the SSID of the access point to which the UE is attached. The TNAP Identifier shall include at least one of the following elements, unless otherwise determined by the TWAN operator's policies:
• the BSSID (see IEEE Std 802.11-2012 [106]);
• civic address information of the TNAP to which the UE is attached.
The TWAP Identifier shall include the SSID of the access point to which the NC5W is attached. The TWAP Identifier shall also include at least one of the following elements, unless otherwise determined by the TWAN operator's policies:
• the BSSID (see IEEE Std 802.11-2012 [106]);
• civic address information of the TWAP to which the UE is attached.
NOTE 1:
The SSID can be the same for several TNAPs/TWAPs and SSID only cannot provide a location, but it might be sufficient for charging purposes.
NOTE 2:
the BSSID associated with a TNAP/TWAP is assumed to be static.
• In the case of W-5GAN access: The User Location Information for W-5GAN is defined in TS 23.316.

When the SMF receives a request to provide Access Network Information reporting while there is no action to carry out towards the 5G-AN or the UE (e.g. no QoS flow to create / Update / modify), the SMF may request User Location Information from the AMF. The interaction between AMF and SMF(s) for the case of a I-SMF insertion, relocation or removal for a PDU session is described in clause 5.34.

In the case of roaming the 5GC supports following possible deployments scenarios for a PDU Session:

• "Local Break Out" (LBO) where the SMF and all UPF(s) involved by the PDU Session are under control of the VPLMN.
• "Home Routed" (HR) where the PDU Session is supported by a SMF function under control of the HPLMN, by a SMF function under control of the VPLMN, by at least one UPF under control of the HPLMN and by at least one UPF under control of the VPLMN. In this case the SMF in HPLMN selects the UPF(s) in the HPLMN and the SMF in VPLMN selects the UPF(s) in the VPLMN. This is further described in clause 6.3.

NOTE 1: Different simultaneous PDU Sessions of an UE may use different modes: Home Routed and LBO. The HPLMN can control via subscription data per DNN and per S-NSSAI whether a PDU Session is to be set-up in HR or in LBO mode. In the case of PDU Sessions per Home Routed deployment:

• NAS SM terminates in the SMF in VPLMN.
• The SMF in VPLMN forwards to the SMF in the HPLMN SM related information.
• The SMF in the HPLMN receives the SUPI of the UE from the SMF in the VPLMN during the PDU Session Establishment procedure.
• The SMF in HPLMN is responsible to check the UE request with regard to the user subscription and to possibly reject the UE request in the case of mismatch. The SMF in HPLMN obtains subscription data directly from the UDM.
• The SMF in HPLMN may send QoS requirements associated with a PDU Session to the SMF in VPLMN. This may happen during the PDU Session Establishment procedure and after the PDU Session is established. The interface between SMF in HPLMN and SMF in VPLMN is also able to carry (N9) User Plane forwarding information exchanged between SMF in HPLMN and SMF in VPLMN. The SMF in the VPLMN may check QoS requests from the SMF in HPLMN with respect to roaming agreements.

In home routed roaming case, the AMF selects an SMF in the VPLMN and a SMF in the HPLMN as described in clause 6.3.2 and TS 23.502, clause 4.3.2.2.3.3, and provides the identifier of the selected SMF in the HPLMN to the selected SMF in the VPLMN. In roaming with LBO, the AMF selects a SMF in the VPLMN as described in clause 6.3.2 and TS 23.502, clause 4.3.2.2.3.2. In this case, when handling a PDU Session Establishment Request message, the SMF in the VPLMN may reject the N11 message (related with the PDU Session Establishment Request message) with a proper N11 cause. This triggers the AMF to select both a new SMF in the VPLMN and a SMF in the HPLMN in order to handle the PDU Session using home routed roaming.

The access to a DN via a PDU Session for a LADN is only available in a specific LADN service area. A LADN service area is a set of Tracking Areas. LADN is a service provided by the serving PLMN. It includes:

• LADN service applies only to 3GPP accesses and does not apply in Home Routed case.
• The usage of LADN DNN requires an explicit subscription to this DNN or subscription to a wildcard DNN.
• Whether a DNN corresponds to a LADN service is an attribute of a DNN and is per PLMN.

The UE is configured to know whether a DNN is a LADN DNN on a per-PLMN basis, and an association between application and LADN DNN. The configured association is considered to be a UE local configuration defined in TS 23.503. Alternatively, the UE gets the information whether a DNN is a LADN DNN from LADN Information during (re -)registration procedure as described in this clause. NOTE 1: NOTE 2: LADN service area and LADN DNN are configured in the AMF on a per DN basis, i.e. for different UEs accessing the same LADN, the configured LADN service area is the same regardless of other factors (e.g. UE's Registration Area or UE subscription). NOTE 3: LADN Information (i.e. LADN Service Area Information and LADN DNN) is provided by AMF to the UE during the Registration procedure or UE Configuration Update procedure. For each LADN DNN configured in the AMF, the corresponding LADN Service Area Information includes a set of Tracking Areas that belong to the Registration Area that the AMF assigns to the UE (i.e. the intersection of the LADN service area and the assigned Registration Area). The AMF shall not create Registration Area based on the availability of LADNs. NOTE 4: When the UE performs a successful (re-)registration procedure, the AMF may provide to the UE, based on local configuration (e.g. via OAM) about LADN, on UE location, and on UE subscription information received from the UDM about subscribed DNN(s), the LADN Information for the list of LADN available to the UE in that Registration Area in the Registration Accept message. The UE may provide either the LADN DNN(s) to retrieve the LADN Information for the indicated LADN DNN(s) or an indication of Requesting LADN Information to retrieve the LADN Information for all LADN(s) available in the current Registration Area. The list of LADN is determined as follows:

• If neither LADN DNN nor an indication of requesting LADN Information is provided in the Registration Request message, the list of LADN is the LADN DNN(s) in subscribed DNN list except for wildcard DNN.
• If the UE provides LADN DNN(s) in the Registration Request message, the list of LADN is LADN DNN(s) the UE requested if the UE subscribed DNN(s) includes the requested LADN DNN or if a wildcard DNN is included in the UE's subscription data.
NOTE 5:
It is assumed that an application can use only one LADN DNN at a time.
• If the UE provides an indication of requesting LADN Information in the Registration Request message, the list of LADN is all the LADN DNN(s) configured in the AMF if the wildcard DNN is subscribed, or the LADN DNN(s) which is in subscribed DNN list and no wildcard DNN is subscribed.

The UE considers the retrieved LADN Information valid only for the registered PLMN and the E-PLMN(s) if the LADN Service Area Information includes Tracking Areas that belong to E-PLMN(s). Additionally, an LADN DNN discovered by the UE via the retrieved LADN Information is considered an LADN DNN also in the E-PLMNs of the Registered PLMN, i.e. the UE can request LADN Information for the discovered LADN DNN in the E-PLMNs. During the subsequent Registration procedure, if the network does not provide LADN Information for a DNN, the UE deletes any LADN Information for that DNN. When the LADN Information for the UE in the 5GC is changed, the AMF shall update LADN Information to the UE through UE Configuration Update/Registration procedure as described in clause 4.2.4 and clause 4.2.2.2.2 in TS 23.502. When receiving PDU Session Establishment with LADN DNN or Service Request for the established PDU Session corresponding to LADN, the AMF determines UE presence in LADN service area and forwards it to the SMF if the requested DNN is configured at the AMF as a LADN DNN. Based on the LADN Service Area Information in the UE, the UE determines whether it is in or out of a LADN service area. If the UE does not have the LADN Service Area Information for a LADN DNN, the UE shall consider it is out of the LADN service area. The UE takes actions as follows:

1. When the UE is out of a LADN service area, the UE:
   • shall not request to activate UP connection of a PDU Session for this LADN DNN;
   • shall not establish/modify a PDU Session for this LADN DNN (except for PS Data Off status change reporting for an established PDU Session);
   • need not release any existing PDU Session for this LADN DNN unless UE receives explicit SM PDU Session Release Request message from the network.
2. When the UE is in a LADN service area, the UE:
   • may request a PDU Session Establishment/Modification for this LADN DNN;
   • may request to activate UP connection of the existing PDU Session for this LADN DNN.

The SMF supporting a DNN is configured with information about whether this DNN is a LADN DNN or not. When receiving SM request corresponding an LADN from the AMF, the SMF determines whether the UE is inside LADN service area based on the indication (i.e. UE Presence in LADN service area) received from the AMF. If the SMF does not receive the indication, the SMF considers that the UE is outside of the LADN service area. The SMF shall reject the request if the UE is outside of the LADN service area. When the SMF receives a request for PDU Session Establishment with the LADN DNN, it shall subscribe to "UE mobility event notification" for reporting UE presence in Area of Interest by providing LADN DNN to the AMF as described in clauses 5.6.11 and 5.3.4.4. Based on the notification about the UE presence in LADN service area notified by AMF (i.e. IN, OUT, or UNKNOWN), the SMF takes actions as follows based on operator's policy:

1. When SMF is informed that the UE presence in a LADN service area is OUT, the SMF shall:
   • release the PDU Session immediately; or
   • deactivate the user plane connection for the PDU Session with maintaining the PDU Session and ensure the Data Notification is disabled and the SMF may release the PDU Session if the SMF is not informed that the UE moves into the LADN service area after a period.
2. When SMF is informed that the UE presence a LADN service area is IN, the SMF shall:
   • ensure that Data Notification is enabled.
   • trigger the Network triggered Service Request procedure for a LADN PDU Session to active the UP connection when the SMF receives downlink data or Data Notification from UPF.
3. When the SMF is informed that the UE presence in a LADN service area is UNKNOWN, the SMF may:
   • ensure that Data Notification is enabled.
   • trigger the Network triggered Service Request procedure for a LADN PDU Session to active the UP connection when the SMF receives downlink data or Data Notification from UPF.

At PDU Session Establishment to a DN:

• The DN-specific identity (TS 33.501) of a UE may be authenticated/authorized by the DN.
NOTE 1:
the DN-AAA server may belong to the 5GC or to the DN.
• If the UE provides authentication/authorization information corresponding to a DN-specific identity during the Establishment of the PDU Session, and the SMF determines that Secondary authentication/authorization of the PDU Session Establishment is required based on the SMF policy associated with the DN, the SMF passes the authentication/authorization information of the UE to the DN-AAA server via the UPF if the DN-AAA server is located in the DN. If the SMF determines that Secondary authentication/authorization of the PDU Session Establishment is required but the UE has not provided a DN-specific identity as part of the PDU Session Establishment request, the SMF requests the UE to indicate a DN-specific identity using EAP procedures as described in TS 33.501. If the Secondary authentication/authorization of the PDU Session Establishment fails, the SMF rejects the PDU Session Establishment.
NOTE 2:
If the DN-AAA server is located in the 5GC and reachable directly, then the SMF may communicate with it directly without involving the UPF.
• The DN-AAA server may authenticate/authorize the PDU Session Establishment.
• When DN-AAA server authorizes the PDU Session Establishment, it may send DN Authorization Data for the established PDU Session to the SMF. The DN authorization data for the established PDU Session may include one or more of the following:
• A DN Authorization Profile Index which is a reference to authorization data for policy and charging control locally configured in the SMF or PCF.
• a list of allowed MAC addresses for the PDU Session; this shall apply only for PDU Session of Ethernet PDU type and is further described in clause 5.6.10.2.
• a list of allowed VIDs for the PDU Session; this shall apply only for PDU Session of Ethernet PDU type and is further described in clause 5.6.10.2.
• DN authorized Session AMBR for the PDU Session. The DN Authorized Session AMBR for the PDU Session takes precedence over the subscribed Session-AMBR received from the UDM.
• a list of Framed Routes (see clause 5.6.14) for the PDU Session.

SMF policies may require DN authorization without Secondary authentication/authorization. In that case, when contacting the DN-AAA server for authorization, the SMF provides the GPSI of the UE if available. Such Secondary authentication/authorization takes place for the purpose of PDU Session authorization in addition to:

• The 5GC access authentication handled by AMF and described in clause 5.2.
• The PDU Session authorization enforced by SMF with regard to subscription data retrieved from UDM.

Based on local policies the SMF may initiate Secondary authentication/authorization at PDU Session Establishment. The SMF provides the GPSI, if available, in the signalling exchanged with the DN-AAA during Secondary authentication/authorization. After the successful Secondary authentication/authorization, a session is kept between the SMF and the DN-AAA. The UE provides the authentication/authorization information required to support Secondary authentication/authorization by the DN over NAS SM. NOTE 3: When SMF adds a PDU Session Anchor (such as defined in clause 5.6.4) to a PDU Session Secondary authentication/authorization is not carried out, but SMF policies may require SMF to notify the DN when a new prefix or address has been added to or removed from a PDU Session or N6 traffic routing information has been changed for a PDU Session. When SMF gets notified from UPF with the addition or removal of MAC addresses to/from a PDU Session, the SMF policies may require SMF to notify the DN-AAA server. Indication of PDU Session Establishment rejection is transferred by SMF to the UE via NAS SM. If the DN-AAA sends DN Authorization Data for the authorized PDU Session to the SMF and dynamic PCC is deployed, the SMF sends the PCF the DN authorized Session AMBR and/or DN Authorization Profile Index in the DN Authorization Data for the established PDU Session. If the DN-AAA sends DN Authorization Profile Index in DN Authorization Data to the SMF and dynamic PCC is not deployed, the SMF uses the DN Authorization Profile Index to refer the locally configured information. NOTE 4: If the DN-AAA does not send DN Authorization Data for the established PDU Session, the SMF may use locally configured information. At any time, a DN-AAA server may revoke the authorization for a PDU Session or update DN Authorization Data for a PDU Session. According to the request from DN-AAA server, the SMF may release or update the PDU Session. At any time, a DN-AAA server or SMF may trigger Secondary Re-authentication procedure for a PDU Session established with Secondary Authentication as specified in clause 11.1.3 in TS 33.501. During Secondary Re-authentication/Re-authorization, if the SMF receives from DN-AAA the DN authorized Session AMBR and/or DN Authorization Profile Index, the SMF shall report the received value(s) to the PCF. The procedure for secondary authentication/authorization by a DN-AAA server during the establishment of a PDU Session is described in TS 23.502, clause 4.3.2.3.