5.6 Session Management

23.5013GPPRelease 18System architecture for the 5G System (5GS)TS

5.6.1 Overview

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 clause 4.16.12.2 of TS 23.502 [3] 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 [45]).

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: The selected DNN is determined based on operator preferences and can differ from subscribed DNNs. The matching of selected DNN to S-NSSAI is assumed to be based on network configuration.

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 IP Index information.

– 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: The content of the Charging Characteristics as well as the usage of the Charging Characteristics by the SMF are defined in TS 32.255 [68].

A PDU Session may support:

(a) 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

(b) 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 [45], 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: In this Release of the specification, at any given time, a PDU Session is routed over only a single access network, unless it is an MA PDU Session in which case it can be routed over one 3GPP access network and one Non 3GPP access network concurrently.

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.

If the UE is attempting to move a single-access PDU session from 3GPP access to non-3GPP access and the PDU session is associated with control plane only indication, then the AMF shall reject the PDU Session Establishment request as related CIoT 5GS optimisation features are not supported over non-3GPP access as described in clause 5.4.5.2.5 of TS 24.501 [47]. If the UE is attempting to move a single-access PDU session from non-3GPP access to NB-N1 mode of 3GPP access, the PDU Session Establishment request would also be rejected by AMF when the UP resources for the UE exceed the maximum number of supported UP resources as described in clause 5.4.5.2.4 of TS 24.501 [47].

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 [47]:

(a) PDU Session Type.

(b) 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 [45].

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.

(c) S-NSSAI of the Serving PLMN from the Allowed NSSAI, corresponding to the S-NSSAI of the HPLMN (b).

NOTE 5: 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).

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.

(d) DNN (Data Network Name).

(e) 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).

Table 5.6.1-1: Attributes of a PDU Session

PDU Session attribute	May be modified later during the lifetime of the PDU Session	Notes
S-NSSAI of the HPLMN	No	(Note 1) (Note 2)
S-NSSAI of the Serving PLMN	Yes	(Note 1) (Note 2) (Note 4)
DNN (Data Network Name)	No	(Note 1) (Note 2)
PDU Session Type	No	(Note 1)
SSC mode	No	(Note 2) The semantics of Service and Session Continuity mode is defined in clause 5.6.9.2
PDU Session Id	No
User Plane Security Enforcement information	No	(Note 3)
Multi-access PDU Connectivity Service	No	Indicates if the PDU Session provides multi-access PDU Connectivity Service or not.
NOTE 1: If it is not provided by the UE, the network determines the parameter based on default information received in user subscription. Subscription to different DNN(s) and S-NSSAI(s) may correspond to different default SSC modes and different default PDU Session Types NOTE 2: S-NSSAI(s) and DNN are used by AMF to select the SMF(s) to handle a new session. Refer to clause 6.3.2. NOTE 3: User Plane Security Enforcement information is defined in clause 5.10.3. NOTE 4: The S-NSSAI value of the Serving PLMN associated to a PDU Session can change whenever the UE moves to a different PLMN, while keeping that PDU Session.

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: The SMF is made aware whether the DNN of a PDU Session being established corresponds to an explicitly subscribed DNN or corresponds to a wildcard DNN. Thus, the SMF can reject a PDU Session establishment if the DNN of the PDU Session is not part of explicitly subscribed DNN(s) and local policies in the SMF require UE to have a subscription to this DNN.

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: User Plane resources for PDU Sessions of a UE, except for regulatory prioritized service like Emergency Services and MPS, can be deactivated by the SMF if the UE is only reachable for regulatory prioritized services.

The SMF serving a PDU session (i.e. Anchor) can be changed during lifetime of the PDU session either within the same SMF set or, if the Context Transfer Procedures as specified in clause 4.26 of TS 23.502 [3] are supported, between SMFs in different SMF sets.

5.6.2 Interaction between AMF and SMF

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 [34].

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 and to fulfil regulatory requirement (in order to provide NPLI (Network Provided Location Information) as defined in TS 23.228 [15]) related 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 fulfil regulatory requirement (i.e. providing Network Provided Location Information (NPLI), as defined in TS 23.228 [15]) 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: TAI, 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: TAI, the UE local IP address used to reach the N3IWF and optionally the UDP source port number if NAT is detected.

– In the case of Trusted non-3GPP access: TAI, TNAP/TWAP Identifier, the UE/N5CW device local IP address used to reach the TNGF/TWIF and optionally the UDP 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.

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 [84].

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.

5.6.3 Roaming

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: The use of an UPF in the VPLMN e.g. enables VPLMN charging, VPLMN LI and minimizes the impact on the HPLMN of the UE mobility within the VPLMN (e.g. for scenarios where SSC mode 1 applies).

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 in clause 4.3.2.2.3.3 of TS 23.502 [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 in clause 4.3.2.2.3.2 of TS 23.502 [3]. 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.

5.6.4 Single PDU Session with multiple PDU Session Anchors

5.6.4.1 General

In order to support selective traffic routing to the DN or to support SSC mode 3 as defined in clause 5.6.9.2.3, the SMF may control the data path of a PDU Session so that the PDU Session may simultaneously correspond to multiple N6 interfaces. The UPF that terminates each of these interfaces is said to support PDU Session Anchor functionality. Each PDU Session Anchor supporting a PDU Session provides a different access to the same DN. Further, the PDU Session Anchor assigned at PDU Session Establishment is associated with the SSC mode of the PDU Session and the additional PDU Session Anchor(s) assigned within the same PDU Session e.g. for selective traffic routing to the DN are independent of the SSC mode of the PDU Session. When a PCC rule including the AF influenced Traffic Steering Enforcement Control information defined in clause 6.3.1 of TS 23.503 [45] is provided to the SMF, the SMF can decide whether to apply traffic routing (by using UL Classifier functionality or IPv6 multi-homing) based on DNAI(s) included in the PCC rule.

NOTE 1: AF influenced Traffic Steering Enforcement Control information can be either determined by the PCF when requested by AF via NEF as described in clause 5.6.7.1 or statically pre-configured in the PCF.

NOTE 2: Selective traffic routing to the DN supports, for example, deployments where some selected traffic is forwarded on an N6 interface to the DN that is "close" to the AN serving the UE.

This may correspond to

– The Usage of UL Classifier functionality for a PDU Session defined in clause 5.6.4.2.

– The Usage of an IPv6 multi-homing for a PDU Session defined in clause 5.6.4.3.

SMF may also take decision to apply traffic routing (by using UL Classifier functionality or IPv6 multi-homing) in EAS Discovery with EASDF procedure described in TS 23.548 [130].

5.6.4.2 Usage of an UL Classifier for a PDU Session

In the case of PDU Sessions of type IPv4 or IPv6 or IPv4v6 or Ethernet, the SMF may decide to insert in the data path of a PDU Session an "UL CL" (Uplink classifier). The UL CL is a functionality supported by an UPF that aims at diverting (locally) some traffic matching traffic filters provided by the SMF. The insertion and removal of an UL CL is decided by the SMF and controlled by the SMF using generic N4 and UPF capabilities. The SMF may decide to insert in the data path of a PDU Session a UPF supporting the UL CL functionality during or after the PDU Session Establishment, or to remove from the data path of a PDU Session a UPF supporting the UL CL functionality after the PDU Session Establishment. The SMF may include more than one UPF supporting the UL CL functionality in the data path of a PDU Session.

The UE is unaware of the traffic diversion by the UL CL, and does not involve in both the insertion and the removal of UL CL. In the case of a PDU Session of IPv4 or IPv6 or IPv4v6 type, the UE associates the PDU Session with either a single IPv4 address or a single IPv6 Prefix or both of them allocated by the network.

When an UL CL functionality has been inserted in the data path of a PDU Session, there are multiple PDU Session Anchors for this PDU Session. These PDU Session Anchors provide different access to the same DN. In the case of a PDU Session of IPv4 or IPv6 or IPv4v6 type, only one IPv4 address and/or IPv6 prefix is provided to the UE. The SMF may be configured with local policies for some (DNN, S-NSSAI) combinations to release the PDU Session when there is a PSA associated with the IPv4 address allocated to the UE and this PSA has been removed.

NOTE 0: The use of only one IPv4 address and/or IPv6 prefix with multiple PDU Session Anchors assumes that when needed, appropriate mechanisms are in place to correctly forward packets on the N6 reference point. The mechanisms for packet forwarding on the N6 reference point between the PDU Session Anchor providing local access and the DN are outside the scope of this specification.

The UL CL provides forwarding of UL traffic towards different PDU Session Anchors and merge of DL traffic to the UE i.e. merging the traffic from the different PDU Session Anchors on the link towards the UE. This is based on traffic detection and traffic forwarding rules provided by the SMF.

The UL CL applies filtering rules (e.g. to examine the destination IP address/Prefix of UL IP packets sent by the UE) and determines how the packet should be routed. The UPF supporting an UL CL may also be controlled by the SMF to support traffic measurement for charging, traffic replication for LI and bit rate enforcement (Session-AMBR per PDU Session).

NOTE 1: When N9 forwarding tunnel exists between source ULCL and target ULCL, the Session-AMBR per PDU Session can be enforced by the source UL CL UPF.

NOTE 2: The UPF supporting an UL CL may also support a PDU Session Anchor for connectivity to the local access to the data network (including e.g. support of tunnelling or NAT on N6). This is controlled by the SMF.

Additional UL CLs (and thus additional PDU Session Anchors) can be inserted in the data path of a PDU Session to create new data paths for the same PDU Session. The way to organize the data path of all UL CLs in a PDU Session is up to operator configuration and SMF logic and there is only one UPF supporting UL CL connecting to the (R)AN via N3 interface, except when session continuity upon UL CL relocation is used.

The insertion of an ULCL in the data path of a PDU Session is depicted in Figure 5.6.4.2-1.

Figure 5.6.4.2-1: User plane Architecture for the Uplink Classifier

NOTE 3: It is possible for a given UPF to support both the UL CL and the PDU Session Anchor functionalities.

Due to UE mobility the network may need to relocate the UPF acting as UL CL and establish a new PSA for local access to the DN. To support session continuity during UL CL relocation the network may establish a temporary N9 forwarding tunnel between the source UL CL and target UL CL. The AF may influence the creation of the N9 forwarding tunnel as described in clause 5.6.7.1.

The N9 forwarding tunnel is maintained until:

– all active traffic flowing on it ceases to exist for:

– a configurable period of time; or

– a period of time indicated by the AF;

– until the AF informs the SMF that it can release the source PSA providing local access to the DN.

During the existence of the N9 forwarding tunnel the UPF acting as target UL CL is configured with packet filters that:

– force uplink traffic from existing data sessions between UE and the application in the source local part of the DN (as defined in TS 23.548 [130]) into the N9 forwarding tunnel towards the source UL CL.

– force any traffic related to the application in the target local part of the DN to go to the new local part of the DN via the target PSA.

SMF may send a Late Notification to AF to inform it about the DNAI change as described in clause 4.3.6.3 of TS 23.502 [3]. This notification can be used by the AF e.g. to trigger mechanisms in the source local part of the DN to redirect the ongoing traffic sessions towards an application in the target local part of the DN. SMF can also send late notification to the target AF instance if associated with this target local part of the DN.

The procedure for session continuity upon UL CL relocation is described in clause 4.3.5.7 of TS 23.502 [3].

When an I-SMF is inserted for a PDU Session, the details of UL CL insertion which is controlled by an I-SMF is described in clause 5.34.4.

5.6.4.3 Usage of IPv6 multi-homing for a PDU Session

A PDU Session may be associated with multiple IPv6 prefixes. This is referred to as multi-homed PDU Session. The multi-homed PDU Session provides access to the Data Network via more than one PDU Session Anchor. The different user plane paths leading to the different PDU Session Anchors branch out at a "common" UPF referred to as a UPF supporting "Branching Point" functionality. The Branching Point provides forwarding of UL traffic towards the different PDU Session Anchors and merge of DL traffic to the UE i.e. merging the traffic from the different PDU Session Anchors on the link towards the UE.

The UPF supporting a Branching Point functionality may also be controlled by the SMF to support traffic measurement for charging, traffic replication for LI and bit rate enforcement (Session-AMBR per PDU Session). The insertion and removal of a UPF supporting Branching Point is decided by the SMF and controlled by the SMF using generic N4 and UPF capabilities. The SMF may decide to insert in the data path of a PDU Session a UPF supporting the Branching Point functionality during or after the PDU Session Establishment, or to remove from the data path of a PDU Session a UPF supporting the Branching Point functionality after the PDU Session Establishment.

Multi homing of a PDU Session applies only for PDU Sessions of IPv6 type. When the UE requests a PDU Session of type "IPv4v6" or "IPv6" the UE also provides an indication to the network whether it supports a Multi-homed IPv6 PDU Session.

The use of multiple IPv6 prefixes in a PDU Session is characterised by the following:

– The UPF supporting a Branching Point functionality is configured by the SMF to spread UL traffic between the PDU Session Anchors based on the Source Prefix of the PDU (which may be selected by the UE based on routing information and preferences received from the network).

– IETF RFC 4191 [8] is used to configure routing information and preferences into the UE to influence the selection of the source Prefix.

NOTE 1: This corresponds to Scenario 1 defined in IETF RFC 7157 [7] "IPv6 Multi-homing without Network Address Translation". This allows to make the Branching Point unaware of the routing tables in the Data Network and to keep the first hop router function in the PDU Session Anchors.

– The multi-homed PDU Session may be used to support make-before-break service continuity to support SSC mode 3. This is illustrated in Figure 5.6.4.3-1.

– The multi-homed PDU Session may also be used to support cases where UE needs to access both a local service (e.g. local server) and a central service (e.g. the internet), illustrated in Figure 5.6.4.3-2.

– The UE shall use the method specified in clause 4.3.5.3 of TS 23.502 [3] to determine if a multi-homed PDU Session is used to support the service continuity case shown in Figure 5.6.4.3-1, or if it is used to support the local access to DN case shown in Figure 5.6.4.3-2.

Figure 5.6.4.3-1: Multi-homed PDU Session: service continuity case

NOTE 2: It is possible for a given UPF to support both the Branching Point and the PDU Session Anchor functionalities.

Figure 5.6.4.3-2: Multi-homed PDU Session: local access to same DN

NOTE 3: It is possible for a given UPF to support both the Branching Point and the PDU Session Anchor functionalities.

5.6.5 Support for Local Area Data Network

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 [45]. 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: No other procedure for configuring the UE to know whether a DNN is a LADN DNN is defined in this release of the specifications.

NOTE 2: The procedure for configuring the UE to know an association between application and LADN DNN is not defined in this release of the specifications.

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: If a LADN is not available in any TA of an AMF’s service area, the AMF is not required to be configured with any LADN related information for that DNN.

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: It is thus possible that the LADN Service Area Information sent by the AMF to the UE contains only a sub-set of the full LADN service area as the LADN service area can contain TA(s) outside of the registration area of the UE or outside of the area served by the AMF.

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 clauses 4.2.4 / 4.2.2.2.2 of TS 23.502 [3].

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:

a) 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.

b) 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.

NOTE 6: The evaluation of Service Area Restrictions will be performed before the evaluation of LADN service area, if the UE has overlapping areas between Service Area Restrictions and LADN service area.

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:

a) 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.

b) 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.

c) 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.

SMF may make use of UE mobility analytics provided by NWDAF, as described in clause 6.7.2 of TS 23.288 [86], to determine UE presence pattern in LADN service area and take a decision how to handle LADN PDN Session (e.g. release the PDU Session immediately, or deactivate the user plane connection for the PDU Session with maintaining the PDU Session).

5.6.6 Secondary authentication/authorization by a DN-AAA server during the establishment of a PDU Session

At PDU Session Establishment to a DN:

– The DN-specific identity (TS 33.501 [29]) 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 [29]. 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 VLAN tags 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.

– Framed Route information (see clause 5.6.14) for the PDU Session.

– L2TP information, such as LNS IP address and/or LNS host name, as described in TS 29.561 [132].

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 regards 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.

If a UE is configured with DNNs, which are subject to secondary authentication/authorization, the UE stores an association between the DNN and corresponding credentials for the secondary authentication/authorization.

NOTE 3: How the UE is aware that a DNN is subject to secondary authentication/authorization (e.g., based on local configuration) is out of scope of this specification.

The UE may support remote provisioning of credentials for secondary authentication/authorization, as specified in clause 5.39.

A UE that supports to be provisioned with the credentials used for secondary authentication/authorization over UP remote provisioning shall use connectivity over an S-NSSAI/DNN which can access the provisioning server to establish a PDU session for remote provisioning as defined in clause 5.39.

NOTE 4: The credentials for secondary authentication/authorization are not specified.

SMF policies or subscription information (such as defined in Table 5.2.3.3.1 of TS 23.502 [3]) may trigger the need for SMF to request the Secondary authentication/authorization and/or UE IP address / Prefix from the DN-AAA server.

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 5: DN Authorization Profile Index is assumed to be pre-negotiated between the operator and the administrator of DN-AAA server.

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. See clause 5.6.14 when the update involves Framed Route information.

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 of TS 33.501 [29].

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 clause 4.3.2.3 of TS 23.502 [3].

The support for L2TP on N6 is further specified in clause 5.8.2.16, and the procedure for establishment of L2TP tunnelling on N6 for a PDU Session is described in clause 4.3.2.4 of TS 23.502 [3].

NOTE 6: The L2TP Tunnel information sent to the SMF can, for example, be provisioned in the DN-AAA server per DNN/S-NSSAI or per SUPI or GPSI.

5.6.7 Application Function influence on traffic routing

5.6.7.1 General

The content of this clause applies to non-roaming and to LBO deployments i.e. to cases where the involved entities (AF, PCF, SMF, UPF) belong to the Serving PLMN or AF belongs to a third party with which the Serving PLMN has an agreement. AF influence on traffic routing does not apply in the case of Home Routed deployments. PCF shall not apply AF requests to influence traffic routing to PDU Sessions established in Home Routed mode.

An AF may send requests to influence SMF routeing decisions for traffic of PDU Session. The AF requests may influence UPF (re)selection and (I-)SMF (re)selection and allow routeing user traffic to a local access to a Data Network (identified by a DNAI).

The AF may issue requests on behalf of applications not owned by the PLMN serving the UE.

If the operator does not allow an AF to access the network directly, the AF shall use the NEF to interact with the 5GC, as described in clause 6.2.10.

The AF may be in charge of the (re)selection or relocation of the applications within the local part of the DN (as defined in TS 23.548 [130]). Such functionality is not defined. For this purpose, the AF may request to get notified about events related with PDU Sessions.

In the case of AF instance change, the AF may send request of AF relocation information.

The AF requests are sent to the PCF via N5 (in the case of requests targeting specific on-going PDU Sessions of individual UE(s), for an AF allowed to interact directly with the 5GC NFs) or via the NEF. The AF requests that target existing or future PDU Sessions of multiple UE(s) or of any UE are sent via the NEF and may target multiple PCF(s), as described in clause 6.3.7.2. The PCF(s) transform(s) the AF requests into policies that apply to PDU Sessions. When the AF has subscribed to UP path management event notifications from SMF(s) (including notifications on how to reach a GPSI over N6), such notifications are sent either directly to the AF or via an NEF (without involving the PCF). For AF interacting with PCF directly or via NEF, the AF requests may contain the information as described in the Table 5.6.7-1:

Table 5.6.7-1: Information element contained in AF request

Information Name	Applicable for PCF or NEF (NOTE 1)	Applicable for NEF only	Category
Traffic Description	Defines the target traffic to be influenced, represented by the combination of DNN and optionally S-NSSAI, and application identifier or traffic filtering information.	The target traffic can be represented by AF-Service-Identifier, instead of combination of DNN and optionally S-NSSAI.	Mandatory
Potential Locations of Applications	Indicates potential locations of applications, represented by a list of DNAI(s).	The potential locations of applications can be represented by AF-Service-Identifier.	Conditional (NOTE 2)
Target UE Identifier(s)	Indicates the UE(s) that the request is targeting, i.e. one or a list of individual UE(s), a group of UE represented by Internal Group Identifier (NOTE 3), or any UE accessing the combination of DNN, S-NSSAI and DNAI(s).	GPSI can be applied to identify the individual UE, or External Group Identifier can be applied to identify a group of UE.	Mandatory
Spatial Validity Condition	Indicates that the request applies only to the traffic of UE(s) located in the specified location, represented by areas of validity.	The specified location can be represented by geographical area.	Optional
AF transaction identifier	The AF transaction identifier refers to the AF request.	N/A	Mandatory
N6 Traffic Routing requirements	Routing profile ID and/or N6 traffic routing information corresponding to each DNAI and an optional indication of traffic correlation (NOTE 4).	N/A	Optional (NOTE 2)
Application Relocation Possibility	Indicates whether an application can be relocated once a location of the application is selected by the 5GC.	N/A	Optional
UE IP address preservation indication	Indicates UE IP address should be preserved.	N/A	Optional
Temporal Validity Condition	Time interval(s) or duration(s).	N/A	Optional
Information on AF subscription to corresponding SMF events	Indicates whether the AF subscribes to change of UP path of the PDU Session and the parameters of this subscription.	N/A	Optional
Information for EAS IP Replacement in 5GC	Indicates the Source EAS identifier and Target EAS identifier, (i.e. IP addresses and port numbers of the source and target EAS).	N/A	Optional
User Plane Latency Requirement	Indicates the user plane latency requirements	N/A	Optional
Information on AF change	N/A	Indicates the AF instance relocation and relocation information.	Optional
Indication for EAS Relocation	Indicates the EAS relocation of the application(s)	N/A	Optional
Indication for Simultaneous Connectivity over the source and target PSA at Edge Relocation	Indicates that simultaneous connectivity over the source and target PSA should be maintained at edge relocation and provides guidance to determine when the connectivity over the source PSA can be removed.	N/A	Optional
EAS Correlation indication	Indicates selecting a common EAS for the application identified by the Traffic Description for the set of UEs.		Optional
NOTE 1: When the AF request targets existing or future PDU Sessions of multiple UE(s) or of any UE and is sent via the NEF, as described in clause 6.3.7.2, the information is stored in the UDR by the NEF and notified to the PCF by the UDR. NOTE 2: The potential locations of applications and N6 traffic routing requirements may be absent only if the request is for subscription to notifications about UP path management events only. NOTE 3: Internal Group ID can only be used by an AF controlled by the operator and only towards PCF. NOTE 4: The indication of traffic correlation can be used for 5G VN groups as described in clause 5.29.

For each information element mentioned above in the AF request, the detailed description is as follows:

1) Information to identify the traffic. The traffic can be identified in the AF request by

– Either a DNN and possibly slicing information (S-NSSAI) or an AF-Service-Identifier

– When the AF provides an AF-Service-Identifier i.e. an identifier of the service on behalf of which the AF is issuing the request, the 5G Core maps this identifier into a target DNN and slicing information (S-NSSAI)

– When the NEF processes the AF request the AF-Service-Identifier may be used to authorize the AF request.

– An application identifier or traffic filtering information (e.g. IP 5 Tuple). The application identifier refers to an application handling UP traffic and is used by the UPF to detect the traffic of the application

When the AF request is for influencing SMF routing decisions, the information is to identify the traffic to be routed.

When the AF request is for subscription to notifications about UP path management events, the information is to identify the traffic that the events relate to.

2) Information about the N6 traffic routing requirements for traffic identified as defined in 1). This includes:

– Information about the N6 traffic routing requirements that is provided per DNAI: for each DNAI, the N6 traffic routing requirements may contain a routing profile ID and/or N6 traffic routing information.

– An optional indication of traffic correlation, when the information in 4) identifies a group of UEs. This implies the targeted PDU Sessions should be correlated by a common DNAI in the user plane for the traffic identified in 1). If this indication is provided by the AF, the 5GC should select a common DNAI for the target PDU Sessions from the list of DNAI(s) specified in 3).

NOTE 1: The N6 traffic routing requirements are related to the mechanism enabling traffic steering in the local access to the DN. The routing profile ID refers to a pre-agreed policy between the AF and the 5GC. This policy may refer to different steering policy ID(s) sent to SMF and e.g. based on time of the day etc.

NOTE 2: The mechanisms enabling traffic steering in the local access to the DN are not defined.

3) Potential locations of applications towards which the traffic routing should apply. The potential location of application is expressed as a list of DNAI(s). If the AF interacts with the PCF via the NEF, the NEF may map the AF-Service-Identifier information to a list of DNAI(s). The DNAI(s) may be used for UPF (re)selection and (I‑)SMF (re)selection.

4) Information on the set of target UE(s). This may correspond to:

– Individual UEs (i.e. one or a list of UEs) identified using GPSI, or an IP address/Prefix or a MAC address.

– Groups of UEs identified by an External Group Identifier as defined in TS 23.682 [36] when the AF interacts via the NEF, or Internal-Group Identifier (see clause 5.9.7) when the AF interacts directly with the PCF.

– Any UE accessing the combination of DNN, S-NSSAI and DNAI(s).

When the PDU Session type is IPv4 or IPv6 or IPv4v6, and the AF provides an IP address and/or an IP Prefix, or when the PDU Session type is Ethernet and the AF provides a MAC address, this allows the PCF to identify the PDU Session for which this request applies and the AF request applies only to that specific PDU Session of the UE. In this case, additional information such as the UE identity may also be provided to help the PCF to identify the correct PDU Session.

Otherwise the request targets multiple UE(s) and shall apply to any existing or future PDU Sessions that match the parameters in the AF request.

When the AF request targets an individual or a list of UE(s) and GPSI is provided within the AF request, the GPSI is mapped to SUPI according to the subscription information received from UDM.

When the AF request targets any UE or a group of UE, the AF request is likely to influence multiple PDU Sessions possibly served by multiple SMFs and PCFs.

When the AF request targets a group of UE it provides one or several group identifiers in its request. The group identifiers provided by the AF are mapped to Internal-Group identifiers. Members of the group have this Group Identifier in their subscription. The Internal-Group Identifier is stored in UDM, retrieved by SMF from UDM and passed by SMF to PCF at PDU Session set-up. The PCF can then map the AF requests with user subscription and determine whether an AF request targeting a Group of users applies to a PDU Session.

When the AF request is for influencing SMF routing decisions, the information is to identify UE(s) whose traffic is to be routed.

When the AF request is for subscription to notifications about UP path management events, the information is to identify UE(s) whose traffic the events relate to.

When the AF request is for traffic forwarding in a PDU Session serving for TSC, the MAC address used by the PDU Session is determined by the AF to identify UE whose traffic is to be routed according to the previously stored binding relationship of the 5GS Bridge and the port number of the traffic forwarding information received from TSN network.

5) Indication of application relocation possibility. This indicates whether an application can be relocated once a location of the application is selected by the 5GC. If application relocation is not possible, the 5GC shall ensure that for the traffic related with an application, no DNAI change takes place once selected for this application.

6) Temporal validity condition. This is provided in the form of time interval(s) or duration(s) during which the AF request is to be applied.

When the AF request is for influencing SMF routing decisions, the temporal validity condition indicates when the traffic routing is to apply.

When the AF request is for subscription to notifications about UP path management events, the temporal validity condition indicates when the notifications are to be generated.

7) Spatial validity condition on the UE(s) location. This is provided in the form of validity area(s). If the AF interacts with the PCF via the NEF, it may provide geographical area (e.g. a civic address or shapes) and the NEF maps the information to areas of validity based on pre-configuration. The PCF in turn determines area(s) of interest based on validity area(s).

When the AF request is for influencing SMF routing decisions, the spatial validity condition indicates that the request applies only to the traffic of UE(s) located in the specified location.

When the AF request is for subscription to notifications about UP path management events, the spatial validity condition indicates that the subscription applies only to the traffic of UE(s) located in the specified location.

8) Information on AF subscription to corresponding SMF events.

The AF may request to be subscribed to change of UP path associated with traffic identified in the bullet 1) above. The AF request contains:

– A type of subscription (subscription for Early and/or Late notifications).

The AF subscription can be for Early notifications and/or Late notifications. In the case of a subscription for Early notifications, the SMF sends the notifications before the (new) UP path is configured. In the case of a subscription for Late notifications, the SMF sends the notification after the (new) UP path has been configured.

– Notification target address for receiving event notification.

– Optionally, an indication of "AF acknowledgment to be expected".

The indication implies that the AF will provide a response to the notifications of UP path management events to the 5GC. The SMF may, according to this indication, determine to wait for a response from the AF before the SMF configures in the case of early notification, or activates in the case of late notification, the new UP path as described in clause 5.6.7.2.

The AF subscription can also request to receive information associating the GPSI of the UE with the IP address(es) of the UE and/or with actual N6 traffic routing to be used to reach the UE on the PDU Session; in this case the corresponding information is sent by the SMF regardless of whether a DNAI applies to the PDU Session.

9) An AF transaction identifier referring to the AF request. This allows the AF to update or remove the AF request and to identify corresponding UP path management event notifications. The AF transaction identifier is generated by the AF.

When the AF interacts with the PCF via the NEF, the NEF maps the AF transaction identifier to an AF transaction internal identifier, which is generated by the NEF and used within the 5GC to identify the information associated to the AF request. The NEF maintains the mapping between the AF transaction identifier and the AF transaction internal identifier. The relation between the two identifiers is implementation specific.

When the AF interacts with the PCF directly, the AF transaction identifier provided by the AF is used as AF transaction internal identifier within the 5GC.

10) Indication of UE IP address preservation. This indicates UE IP address related to the traffic identified in bullet 1) should be preserved. If this indication is provided by the AF, the 5GC should preserve the UE IP address by preventing reselection of PSA UPF for the identified traffic once the PSA UPF is selected.

11) Information for EAS IP Replacement in 5GC. This indicates the Source EAS identifier and Target EAS identifier (i.e. IP addresses and port numbers of the source and target EAS) for a service subject to Edge Computing.

12) User Plane Latency Requirement. This includes AF requirements for User Plane latency. (see clause 6.3.6 of TS 23.548 [130]).

13) Information on AF change. The AF relocation information includes:

– AF Identifier: the identifier of the target AF instance.

NOTE 3: The AF relocation information is applicable for interaction with NEF only and it is not stored in UDR or transferred to PCF, even for the case AF directly interacts with PCF.

14) Indication for EAS relocation. This indicates the application(s) are to be relocated.

15) Indication for Simultaneous Connectivity over source and target PSA at Edge Relocation (see clause 6.3.4 of TS 23.548 [130]). Indicates that source and target PSA should coexist for some time at PSA relocation, and may influence the establishment of a temporary N9 forwarding tunnel between the source UL CL and target UL CL. It may also provide guidance for the time interval after the described traffic ceases when the connectivity over the source PSA may be removed.

16) EAS Correlation indication. Indicates selecting a common EAS for the application identified by the Traffic Description accessed by the set of UEs, the set of UEs contains UEs that the AF request aims at.

An AF may send requests to influence SMF routeing decisions, for event subscription or for both.

The AF may request to be subscribed to notifications about UP path management events, i.e. a UP path change occurs for the PDU Session. The corresponding notification about a UP path change sent by the SMF to the AF may indicate the DNAI and /or the N6 traffic routing information that has changed as described in clause 4.3.6.3 of TS 23.502 [3]. It may include the AF transaction internal identifier, the type of notification (i.e. early notification or late notification), the Identity of the source and/or target DNAI, the IP address/prefix of the UE or the MAC address used by the UE, the GPSI and the N6 traffic routing information related to the 5GC UP.

NOTE 4: The change from the UP path status where no DNAI applies to a status where a DNAI applies indicates the activation of this AF request; the change from the UP path status where a DNAI applies to a status where no DNAI applies indicates the de-activation of this AF request.

In the case of IP PDU Session Type, the IP address/prefix of the UE together with N6 traffic routing information indicates to the AF how to reach over the User Plane the UE identified by its GPSI. N6 traffic routing information indicates any tunnelling that may be used over N6. The nature of this information depends on the deployment.

NOTE 5: N6 traffic routing information can e.g. correspond to the identifier of a VPN or to explicit tunnelling information such as a tunnelling protocol identifier together with a Tunnel identifier.

NOTE 6: In the case of Unstructured PDU Session type the nature of the N6 traffic routing information related to the 5GC UP is described in clause 5.6.10.3.

In the case of Ethernet PDU Session Type, the MAC address of the UE together with N6 traffic routing information indicates to the AF how to reach over the User Plane the UE identified by its GPSI. The UE MAC address (es) is reported by the UPF as described in clause 5.8.2.12. The N6 traffic routing information can be, e.g. a VLAN ID or the identifier of a VPN or a tunnel identifier at the UPF.

When notifications about UP path management events are sent to the AF via the NEF, if required, the NEF maps the UE identify information, e.g. SUPI, to the GPSI and the AF transaction internal identifier to the AF transaction identifier before sending the notifications to the AF.

The PCF, based on information received from the AF, operator’s policy, optionally service experience analytics per UP path received from NWDAF, etc., authorizes the request received from the AF and determines for each DNAI, a traffic steering policy ID (derived from the routing profile ID provided by the AF) and/or the N6 traffic routing information (as provided by the AF) to be sent to the SMF as part of the PCC rules. The traffic steering policy IDs are configured in the SMF or in the UPF. The traffic steering policy IDs are related to the mechanism enabling traffic steering to the DN.

The DNAIs are related to the information considered by the SMF for UPF selection and (I‑)SMF (re)selection, e.g. for diverting (locally) some traffic matching traffic filters provided by the PCF.

The PCF acknowledges a request targeting an individual PDU Session to the AF or to the NEF.

For PDU Session that corresponds to the AF request, the PCF provides the SMF with a PCC rule that is generated based on the AF request, Local routing indication from the PDU Session policy control subscription information and taking into account UE location presence in area of interest (i.e. Presence Reporting Area). The PCC rule contains the information to identify the traffic, information about the DNAI(s) towards which the traffic routing should apply and optionally, an indication of traffic correlation and/or an indication of application relocation possibility and/or indication of UE IP address preservation and/or an EAS Correlation indication. The PCC rule also contains per DNAI a traffic steering policy ID and/or N6 traffic routing information, if the N6 traffic routing information is explicitly provided in the AF request. If EAS Correlation_indication or indication of traffic correlation is included in the AF request, a traffic correlation ID will be included in PCC rule. The PCF may also provide in the PCC rule information to subscribe the AF (or the NEF) to SMF events (UP path changes) corresponding to the AF request in which case it provides the information on AF subscription to corresponding SMF events received in the AF request. This is done by providing policies at PDU Session set-up or by initiating a PDU Session Modification procedure. When initiating a PDU Session set-up or PDU Session Modification procedure, the PCF considers the latest known UE location to determine the PCC rules provided to the SMF. The PCF evaluates the temporal validity condition of the AF request and informs the SMF to activate or deactivate the corresponding PCC rules according to the evaluation result. When policies specific to the PDU Session and policies general to multiple PDU Sessions exist, the PCF gives precedence to the PDU Session specific policies over the general policies. The PCF authorizes the AF request of User Plane Latency Requirements. If the PCF determines that the requirements can’t be authorized, the PCF rejects the AF request.

The spatial validity condition is resolved at the PCF. In order to do that, the PCF subscribes to the SMF to receive notifications about change of UE location in an area of interest (i.e. Presence Reporting Area). The subscribed area of interest may be the same as spatial validity condition, or may be a subset of the spatial validity condition (e.g. a list of TAs) based on the latest known UE location. When the SMF detects that UE entered the area of interest subscribed by the PCF, the SMF notifies the PCF and the PCF provides to the SMF the PCC rules described above by triggering a PDU Session Modification. When the SMF becomes aware that the UE left the area subscribed by the PCF, the SMF notifies the PCF and the PCF provides updated PCC rules by triggering a PDU Session Modification. SMF notifications to the PCF about UE location in or out of the subscribed area of interest are triggered by UE location change notifications received from the AMF or by UE location information received during a Service Request or Handover procedure.

When the PCC rules are activated, the SMF may, based on local policies, take the information in the PCC rules and, optionally, the Service Experience analytics and/or DN Performance analytics per UP path (including UPF and/or DNAI and/or AS instance) as defined in clause 6.4.3 and clause 6.14.3, respectively, of TS 23.288 [86] into account to:

– (re)select UP paths (including DNAI(s)) for PDU Sessions. The SMF is responsible for handling the mapping between the UE location (TAI / Cell-Id) and DNAI(s) associated with UPF and applications and the selection of the UPF(s) that serve a PDU Session. This is described in clause 6.3.3. If the PDU Session is of IP type and if Indication of UE IP address preservation is included in the PCC rules, the SMF should preserve the UE IP address, by not reselecting the related PSA UPF once the PSA UPF is selected, for the traffic identified in the PCC rule. If the user plane latency requirement is included in the PCC rules, the SMF chooses the PSA UPF that satisfies the user plane latency requirement. If the PCC rules are related to a 5G VN group served by the SMF and if the PCC rule includes an indication of traffic correlation, the SMF should select a common DNAI for the PDU Sessions of the 5G VN group, see clause 5.29.

– configure traffic steering at UPF, including activating mechanisms for traffic multi-homing or enforcement of an UL Classifier (UL CL). Such mechanisms are defined in clause 5.6.4. This may include that the SMF is providing the UPF with packet handling instructions (i.e. PDRs and FARs) for steering traffic to the local access to the DN. The packet handling instructions are generated by the SMF using the traffic steering policy ID and/or the N6 traffic routing information in the PCC rules corresponding to the applied DNAI. In the case of UP path reselection, the SMF may configure the source UPF to forward traffic to the UL CL/BP so that the traffic is steered towards the target UPF.

– if Information on AF subscription to corresponding SMF events has been provided in the PCC rule, inform the AF of the (re)selection of the UP path (UP path change). If the information includes an indication of "AF acknowledgment to be expected", the SMF may decide to wait for a response from the AF before it activates the new UP path, as described in clause 5.6.7.2.

When an I-SMF is inserted for a PDU Session, the I-SMF insertion, relocation or removal to a PDU session shall be transparent (i.e. not aware) to the PCF and to the AF. The processing of the AF influence on traffic routing is described in clause 5.34 and detail procedure is described in clause 4.23.6 of TS 23.502 [3].

5.6.7.2 Enhancement of UP path management based on the coordination with AFs

In order to avoid or minimize service interruption during PSA relocation for a PDU session of SSC mode 3, or a PDU session with UL CL or branch point, according to the indication of "AF acknowledgment to be expected" on AF subscription to corresponding SMF events (DNAI change) in the PCC rules received from the PCF and local configuration (e.g. DN-related policies) the SMF may wait for a response from the AF after sending a notification (an early notification or a late notification) to the AF. In the case of late notification, based on the indication of "AF acknowledgment to be expected" on AF subscription, the SMF may send the notification before activating the UP path towards a new DNAI (possibly through a new PSA).

NOTE 1: Before the UP path toward the new DNAI is activated, application traffic data (if any exists) is still routed toward the old DNAI.

The notification sent from the SMF to the AF indicates UP path management events (DNAI change) as described in clause 5.6.7.1. The AF can confirm the DNAI change indicated in the notification with the SMF by sending a positive response to the notification to the SMF or reject the DNAI change by sending a negative response.

NOTE 2: The AF can determine whether application relocation is needed according to the notification of DNAI change. If not, the AF can send a positive response to the SMF immediately; otherwise, the AF sends the positive response after application relocation is completed or a negative response if the AF determines that the application relocation cannot be completed on time (e.g. due to temporary congestion). The AF decision and behaviours on application relocation are not defined. However, the new DNAI may be associated with a new AF. In such cases, the SMF and the old AF cancel earlier subscribed UP path management event notifications, and the new AF subscribes to receive UP path management event notifications from the SMF.

The AF can include N6 traffic routing information related to the target DNAI in a positive response sent to the SMF. The SMF configures the N6 traffic routing information from the AF response to the PSA on the UP path.

The AF can include the EAS relocation Indication to indicate the application(s) to be relocated.

In the case of early notification, based on the indication of "AF acknowledgment to be expected" on AF subscription, the SMF does not configure the UP path towards the new DNAI until it receives a positive AF response as specified in clause 4.3.6.3 of TS 23.502 [3].

In the case of late notification, based on the indication of "AF acknowledgment to be expected" on AF subscription, the SMF does not activate the UP path towards the new DNAI until it receives a positive AF response as specified in clause 4.3.5 of TS 23.502 [3].

NOTE 3: After the UP path toward the new DNAI is activated, data is routed toward the new DNAI.

If the SMF receives a negative response at any time, the SMF keeps using the original DNAI and may cancel related PSA relocation or addition. The SMF may perform DNAI reselection afterwards if needed.

The SMF can assume according to local policy a negative response if a response is expected and but not received from the AF within a certain time window.

When Early/Late Notification happens, the SMF notifies AF about the target DNAI and may indicate capability of supporting EAS IP replacement in 5GC.When EAS relocation is performed, the AF sends an/a early/late notification response to the SMF after the EAS relocation is completed, which may include the Information for EAS IP Replacement in 5GC. The SMF may instruct the local PSA with the EAS IP address replacement using "Outer Header Creation" as defined in clause 5.8.2.11.6 and "Outer Header Removal" as defined in clause 5.8.2.11.3. If local PSA relocation is required, the SMF may request the target local PSA to buffer uplink traffic as described in clause 6.3.5 of TS 23.548 [130].

5.6.8 Selective activation and deactivation of UP connection of existing PDU Session

This clause applies to the case when a UE has established multiple PDU Sessions. The activation of a UP connection of an existing PDU Session causes the activation of its UE-CN User Plane connection (i.e. data radio bearer and N3 tunnel).

For the UE in the CM-IDLE state in 3GPP access, either UE or Network-Triggered Service Request procedure may support independent activation of UP connection of existing PDU Session. For the UE in the CM-IDLE state in non-3GPP access, UE-Triggered Service Request procedure allows the re-activation of UP connection of existing PDU Sessions, and may support independent activation of UP connection of existing PDU Session.

A UE in the CM-CONNECTED state invokes a Service Request (see clause 4.2.3.2 of TS 23.502 [3]) procedure to request the independent activation of the UP connection of existing PDU Sessions.

Network Triggered re-activation of UP connection of existing PDU Sessions is handled as follows:

– If the UE CM state in the AMF is already CM-CONNECTED on the access (3GPP, non-3GPP) associated to the PDU Session in the SMF, the network may re-activate the UP connection of a PDU Session using a Network Initiated Service Request procedure.

Otherwise:

– If the UE is registered in both 3GPP and non-3GPP accesses and the UE CM state in the AMF is CM-IDLE in non-3GPP access, the UE can be paged or notified through the 3GPP access for a PDU Session associated in the SMF (i.e. last routed) to the non-3GPP access:

– If the UE CM state in the AMF is CM-IDLE in 3GPP access, the paging message may include the access type associated with the PDU Session in the SMF. The UE, upon reception of the paging message containing an access type, shall reply to the 5GC via the 3GPP access using the NAS Service Request message, which shall contain the list of PDU Sessions associated with the received access type and whose UP connections can be re-activated over 3GPP (i.e. the list does not contain the PDU Sessions whose UP connections cannot be re-activated on 3GPP based on UE policies and whether the S-NSSAIs of these PDU Sessions are within the Allowed NSSAI for 3GPP access). If the PDU Session for which the UE has been paged is in the list of the PDU Sessions provided in the NAS Service Request and the paging was triggered by pending DL data, the 5GC shall re-activate the PDU Session UP connection over 3GPP access. If the paging was triggered by pending DL signalling, the Service Request succeeds without re-activating the PDU session UP connection over the 3GPP access and the pending DL signalling is delivered to the UE over the 3GPP access;

– If the UE CM state in the AMF is CM-CONNECTED in 3GPP access, the notification message shall include the non-3GPP Access Type. The UE, upon reception of the notification message, shall reply to the 5GC via the 3GPP access using the NAS Service Request message, which shall contain the List of Allowed PDU Sessions that can be re-activated over 3GPP or an empty List of Allowed PDU Sessions if no PDU Sessions are allowed to be re-activated over 3GPP access.

NOTE: A UE that is in a coverage of a non-3GPP access and has PDU Session(s) that are associated in the UE (i.e. last routed) to non-3GPP access, is assumed to attempt to connect to it without the need to be paged.

– If the UE is registered in both 3GPP and non-3GPP accesses served by the same AMF and the UE CM state in the AMF is CM-IDLE in 3GPP access and is in CM-CONNECTED in non 3GPP access, the UE can be notified through the non-3GPP for a PDU Session associated in the SMF (i.e. last routed) to the 3GPP access. The notification message shall include the 3GPP Access Type. Upon reception of the notification message, when 3GPP access is available, the UE shall reply to the 5GC via the 3GPP access using the NAS Service Request message.

In addition to the above, a PDU Session may be established as an always-on PDU Session as described in clause 5.6.13.

The deactivation of the UP connection of an existing PDU Session causes the corresponding data radio bearer and N3 tunnel to be deactivated. The UP connection of different PDU Sessions can be deactivated independently when a UE is in CM-CONNECTED state in 3GPP access or non-3GPP access. At the deactivation of the UP of a PDU Session using a N9 tunnel whose end-point is controlled by an I-SMF, the N9 tunnel is preserved. If a PDU Session is an always-on PDU Session, the SMF should not deactivate a UP connection of this PDU Session due to inactivity.

5.6.9 Session and Service Continuity

5.6.9.1 General

The support for session and service continuity in 5G System architecture enables to address the various continuity requirements of different applications/services for the UE. The 5G System supports different session and service continuity (SSC) modes defined in this clause. The SSC mode associated with a PDU Session does not change during the lifetime of a PDU Session. The following three modes are specified with further details provided in the next clause:

– With SSC mode 1, the network preserves the connectivity service provided to the UE. For the case of PDU Session of IPv4 or IPv6 or IPv4v6 type, the IP address is preserved.

– With SSC mode 2, the network may release the connectivity service delivered to the UE and release the corresponding PDU Session(s). For the case of IPv4 or IPv6 or IPv4v6 type, the release of the PDU Session induces the release of IP address(es) that had been allocated to the UE.

– With SSC mode 3, changes to the user plane can be visible to the UE, while the network ensures that the UE suffers no loss of connectivity. A connection through new PDU Session Anchor point is established before the previous connection is terminated in order to allow for better service continuity. For the case of IPv4 or IPv6 or IPv4v6 type, the IP address is not preserved in this mode when the PDU Session Anchor changes.

NOTE: In this Release of the specification, the addition/removal procedure of additional PDU Session Anchor in a PDU Session for local access to a DN is independent from the SSC mode of the PDU Session.

5.6.9.2 SSC mode

5.6.9.2.1 SSC Mode 1

For a PDU Session of SSC mode 1, the UPF acting as PDU Session Anchor at the establishment of the PDU Session is maintained regardless of the access technology (e.g. Access Type and cells) a UE is successively using to access the network.

In the case of a PDU Session of IPv4 or IPv6 or IPv4v6 type, IP continuity is supported regardless of UE mobility events.

In this Release of the specification, when IPv6 multihoming or UL CL applies to a PDU Session of in SSC mode 1, and the network allocates (based on local policies) additional PDU Session Anchors to such a PDU Session, these additional PDU Session Anchors may be released or allocated, and the UE does not expect that the additional IPv6 prefix is maintained during the lifetime of PDU Session.

SSC mode 1 may apply to any PDU Session type and to any access type.

A UE supporting PDU Connectivity shall support SSC mode 1.

5.6.9.2.2 SSC Mode 2

If a PDU Session of SSC mode 2 has a single PDU Session Anchor, the network may trigger the release of the PDU Session and instruct the UE to establish a new PDU Session to the same data network immediately. The trigger condition depends on operator policy e.g. request from Application Function, based on load status, etc. At establishment of the new PDU Session, a new UPF acting as PDU Session Anchor can be selected.

Otherwise, if a PDU Session of SSC mode 2 has multiple PDU Session Anchors (i.e. in the case of multi-homed PDU Sessions or in the case that UL CL applies to a PDU Session of SSC mode 2), the additional PDU Session Anchors may be released or allocated.

SSC mode 2 may apply to any PDU Session type and to any access type.

SSC mode 2 is optional to be supported in the UE.

NOTE 1: Features depending on SSC mode 2 will not work with the lack of support for SSC mode 2 in the UE.

NOTE 2: In UL CL mode, the UE is not involved in PDU Session Anchor re-allocation, so that the existence of multiple PDU Session Anchors is not visible to the UE.

5.6.9.2.3 SSC Mode 3

For PDU Session of SSC mode 3, the network allows the establishment of UE connectivity via a new PDU Session Anchor to the same data network before connectivity between the UE and the previous PDU Session Anchor is released. When trigger conditions apply, the network decides whether to select a PDU Session Anchor UPF suitable for the UE’s new conditions (e.g. point of attachment to the network).

In this Release of specification, SSC mode 3 only applies to IP PDU Session type and to any access type.

In the case of a PDU Session of IPv4 or IPv6 or IPv4v6 type, during the procedure of change of PDU Session Anchor, the following applies:

a. For a PDU Session of IPv6 type, the new IP prefix anchored on the new PDU Session Anchor may be allocated within the same PDU Session (relying on IPv6 multi-homing specified in clause 5.6.4.3), or

b. The new IP address and/or IP prefix may be allocated within a new PDU Session that the UE is triggered to establish.

After the new IP address/prefix has been allocated, the old IP address/prefix is maintained during some time indicated to the UE via NAS signalling (as described in clause 4.3.5.2 of TS 23.502 [3]) or via Router Advertisement (as described in clause 4.3.5.3 of TS 23.502 [3]) and then released.

If a PDU Session of SSC mode 3 has multiple PDU Session Anchors (i.e. in the case of multi-homed PDU Sessions or in the case that UL CL applies to a PDU Session of SSC mode 3), the additional PDU Session Anchors may be released or allocated.

SSC mode 3 is optional to be supported in the UE.

NOTE: Features depending on SSC mode 3 will not work with the lack of support for SSC mode 3 in the UE.

5.6.9.3 SSC mode selection

SSC mode selection is done by the SMF based on the allowed SSC modes -including the default SSC mode) in the user subscription as well as the PDU Session type and if present, the SSC mode requested by the UE.

The operator may provision a SSC mode selection policy (SSCMSP) to the UE as part of the URSP rule -see clause 6.6.2 of TS 23.503 [45]). The UE shall use the SSCMSP to determine the type of session and service continuity mode associated with an application or group of applications for the UE as described in clause 6.6.2.3 of TS 23.503 [45]. If the UE does not have SSCMSP, the UE can select a SSC mode based on UE Local Configuration as described in TS 23.503 [45], if applicable. If the UE cannot select a SSC mode, the UE requests the PDU Session without providing the SSC mode.

NOTE 1: The UE can use the SSC Mode Selection component of the URSP rule with match-all traffic descriptor if there is no SSC mode in the UE local configuration.

The SSC mode selection policy rules provided to the UE can be updated by the operator by updating the URSP rule.

The SMF receives from the UDM the list of allowed SSC modes and the default SSC mode per DNN per S-NSSAI as part of the subscription information.

If a UE provides an SSC mode when requesting a new PDU Session, the SMF selects the SSC mode by either accepting the requested SSC mode or rejecting the PDU Session Establishment Request message with the cause value and the SSC mode(s) allowed to be used back to UE based on the PDU Session type, subscription and/or local configuration. Based on that cause value and the SSC mode(s) allowed to be used, the UE may re-attempt to request the establishment of that PDU Session with the SSC mode allowed to be used or using another URSP rule.

If a UE does not provide an SSC mode when requesting a new PDU Session, then the SMF selects the default SSC mode for the data network listed in the subscription or applies local configuration to select the SSC mode.

SSC mode 1 shall be assigned to the PDU Session when static IP address/prefix is allocated to the PDU Session based on the static IP address/prefix subscription for the DNN and S-NSSAI. The SMF shall inform the UE of the selected SSC mode for a PDU Session.

The UE shall not request and the network shall not assign SSC mode 3 for the PDU Session of Unstructured type or Ethernet type.

NOTE 2: To avoid issues for UEs not supporting all SSC modes, the operator can, in the subscription data and local configuration, include at least SSC mode 1 in the allowed SSC modes, and set default SSC mode to 1 (since all UEs supporting PDU sessions are mandated to support SSC mode 1). Still the 5GC can trigger PDU session release with a cause code indicating reactivation due to, e.g. restoration or user plane path optimization purposes, though this may cause interruption of the service.

5.6.10 Specific aspects of different PDU Session types

5.6.10.1 Support of IP PDU Session type

The IP address allocation is defined in clause 5.8.1

The UE may acquire following configuration information from the SMF, during the lifetime of a PDU Session:

– Address(es) of P-CSCF(s);

– Address(es) of DNS server(s).

– If the UE indicates support of DNS over (D) TLS to the network and the network wants to enforce the use of DNS over (D)TLS, the configuration information is sent by the SMF via PCO may also include the corresponding DNS server security information as specified in TS 24.501 [47] and TS 33.501 [29].

– the GPSI of the UE.

The UE may acquire from the SMF, at PDU Session Establishment, the MTU that the UE shall consider, see clause 5.6.10.4.

The UE may provide following information to the SMF during the lifetime of a PDU Session:

– an indication of the support of P-CSCF re-selection based on procedures specified in TS 24.229 [62] (clauses B.2.2.1C and L.2.2.1C).

– PS data off status of the UE.

NOTE 2: An operator can deploy NAT functionality in the network; the support of NAT is not specified in this release of the specification.

5.6.10.2 Support of Ethernet PDU Session type

For a PDU Session set up with the Ethernet PDU Session type, the SMF and the UPF acting as PDU Session Anchor (PSA) can support specific behaviours related with the fact the PDU Session carries Ethernet frames.

Depending on operator configuration related with the DNN, different configurations for how Ethernet traffic is handled on N6 may apply, for example:

– Configurations with a 1-1 relationship between a PDU Session and a N6 interface possibly corresponding to a dedicated tunnel established over N6. In this case the UPF acting as PSA transparently forwards Ethernet frames between the PDU Session and its corresponding N6 interface, and it does not need to be aware of MAC addresses used by the UE in order to route down-link traffic.

– Configurations, where more than one PDU Session to the same DNN (e.g. for more than one UE) corresponds to the same N6 interface. In this case the UPF acting as PSA needs to be aware of MAC addresses used by the UE in the PDU Session in order to map down-link Ethernet frames received over N6 to the appropriate PDU Session. Forwarding behaviour of the UPF acting as PSA is managed by SMF as specified in clause 5.8.2.5.

NOTE 1: The "MAC addresses used by the UE" correspond to any MAC address used by the UE or any device locally connected to the UE and using the PDU Session to communicate with the DN.

Based on operator configuration, the SMF may request the UPF acting as the PDU Session Anchor to respond to ARP/IPv6 Neighbour Solicitation requests based on local cache information, i.e. the mapping between the UE MAC address to the UE IP address, and the DN where the PDU Session is connected to, or to redirect the ARP traffic from the UPF to the SMF. Responding to ARP/IPv6 ND based on local cache information applies to ARP/IPv6 ND received in both UL and DL directions.

NOTE 2: Responding to ARP/ND from a local cache assumes the UE or the devices behind the UE acquire their IP address via in-band mechanisms that the SMF/UPF can detect and by this link the IP address to the MAC address.

NOTE 3: This mechanism is intended to avoid broadcasting or multicasting the ARP/IPv6 ND to every UE.

Ethernet Preamble and Start of Frame delimiter are not sent over 5GS:

– For UL traffic the UE strips the preamble and frame check sequence (FCS) from the Ethernet frame.

– For DL traffic the PDU Session Anchor strips the preamble and frame check sequence (FCS) from the Ethernet frame.

Neither a MAC nor an IP address is allocated by the 5GC to the UE for a PDU Session.

The PSA shall store the MAC addresses received from the UE, and associate those with the appropriate PDU Session.

The SMF may receive a list of allowed VLAN tags from DN-AAA (for a maximum of 16 VLAN tags) or may be locally configured with allowed VLAN tags values. The SMF may also be configured with instructions on VLAN handling (e.g. the VLAN tag to be inserted or removed, S-TAG to be inserted or removed). Taking this into account, the SMF determines the VLAN handling for the PDU Session, and instructs the UPF to accept or discard the UE traffic based on the allowed VLAN tags, as well as to handle VLAN tags (addition/removal) via PDR (Outer header removal) and FAR (UPF applying Outer header creation of a Forwarding policy). For example:

– The UPF may insert (for uplink traffic) and remove (for downlink traffic) a S-TAG on N6 or N19 or internal interface ("5G VN internal") for the traffic from and to the UE.

– The UPF may insert (for uplink traffic) and remove (for downlink traffic) a VLAN tag on the N6 interface while there is no VLAN in the traffic to and from the UE.

– The UPF may discard any UE traffic that does not contain any allowed VLAN tag when the UPF handles the UE uplink or downlink traffic.

NOTE 4: This can be used for traffic steering to N6-LAN but also for N6-based traffic forwarding related with 5G-VN service described in clause 5.29.4

Apart from specific conditions related to the support of PDU sessions over W-5GAN defined in TS 23.316 [84], the UPF shall not remove VLAN tags sent by the UE and the UPF shall not insert VLAN tags for the traffic sent to the UE.

PDU(s) containing a VLAN tag shall be switched only within the same VLAN by a PDU Session Anchor.

The UE may acquire from the SMF, at PDU Session Establishment, the MTU of the Ethernet frames’ payload that the UE shall consider, see clause 5.6.10.4.

NOTE 5: The UE may operate in bridge mode with regard to a LAN it is connecting to the 5GS, thus different MAC addresses may be used as source address of different frames sent UL over a single PDU Session (and destination MAC address of different frames sent DL over the same PDU Session).

NOTE 6: Entities on the LAN connected to the 5GS by the UE may have an IP address allocated by the DN but the IP layer is considered as an application layer which is not part of the Ethernet PDU Session.

NOTE 7: In this Release of the specification, only the UE connected to the 5GS is authenticated, not the devices behind such UE.

NOTE 8: 5GS does not support the scenario where a MAC address or if VLAN applies a (MAC address, VLAN) combination is used on more than one PDU Session for the same DNN and S-NSSAI.

NOTE 9: This Release of the specification does not guarantee that the Ethernet network remains loop-free. Deployments need to be verified on an individual basis that loops in the Ethernet network are avoided.

NOTE 10: This Release of the specification does not guarantee that the Ethernet network properly and quickly reacts to topology changes. Deployments need to be verified on an individual basis how they react to topology changes.

Different Frames exchanged on a PDU Session of Ethernet type may be served with different QoS over the 5GS. Thus, the SMF may provide to the UPF Ethernet Packet Filter Set and forwarding rule(s) based on the Ethernet frame structure and UE MAC address(es). The UPF detects and forwards Ethernet frames based on the Ethernet Packet Filter Set and forwarding rule(s) received from the SMF. This is further defined in clauses 5.7 and 5.8.2.

When a PDU Session of Ethernet PDU type is authorized by a DN as described in clause 5.6.6, the DN-AAA server may, as part of authorization data, provide the SMF with a list of allowed MAC addresses for this PDU Session; the list is limited to a maximum of 16 MAC addresses. When the list has been provided for a PDU Session, the SMF sets corresponding filtering rules in the UPF(s) acting as PDU Session Anchor for the PDU Session. The UPF discards any UL traffic that does not contain one of these MAC addresses as a source address if the list of allowed MAC addresses is provided.

In this Release of specification, the PDU Session of Ethernet PDU Session type is restricted to SSC mode 1 and SSC mode 2.

For a PDU Session established with the Ethernet PDU Session type, the SMF may, upon PCF request, need to ensure reporting to the PCF of all Ethernet MAC addresses used as UE address in a PDU Session. In this case, as defined in clause 5.8.2.12, the SMF controls the UPF to report the different MAC addresses used as source address of frames sent UL by the UE in the PDU Session.

NOTE 11: This relates to whether AF control on a per MAC address is allowed on the PDU Session as defined in clause 6.1.1.2 of TS 23.503 [45].

The PCF may activate or deactivate the reporting of the UE MAC address using the "UE MAC address change" Policy Control Request Trigger as defined in Table 6.1.3.5-1 of TS 23.503 [45].

The SMF may relocate the UPF acting as the PDU Session Anchor for an Ethernet PDU Session as defined in clause 4.3.5.8 of TS 23.502 [3]. The relocation may be triggered by a mobility event such as a handover, or may be triggered independent of UE mobility, e.g. due to load balancing reasons. In order to relocate the PSA UPF, the reporting of the UE MAC addresses needs to be activated by the SMF.

5.6.10.3 Support of Unstructured PDU Session type

Different Point-to-Point (PtP) tunnelling techniques may be used to deliver Unstructured PDU Session type data to the destination (e.g. application server) in the Data Network via N6.

Point-to-point tunnelling based on UDP/IP encapsulation as described below may be used. Other techniques may be supported. Regardless of addressing scheme used from the UPF to the DN, the UPF shall be able to map the address used between the UPF and the DN to the PDU Session.

When Point-to-Point tunnelling based on UDP/IPv6 is used, the following considerations apply:

– IPv6 prefix allocation for PDU Sessions are performed locally by the (H-)SMF without involving the UE.

– The UPF(s) acts as a transparent forwarding node for the payload between the UE and the destination in the DN.

– For uplink, the UPF forwards the received Unstructured PDU Session type data to the destination in the data network over the N6 PtP tunnel using UDP/IPv6 encapsulation.

– For downlink, the destination in the data network sends the Unstructured PDU Session type data using UDP/IPv6 encapsulation with the IPv6 address of the PDU Session and the 3GPP defined UDP port for Unstructured PDU Session type data. The UPF acting as PDU Session Anchor decapsulates the received data (i.e. removes the UDP/IPv6 headers) and forwards the data identified by the IPv6 prefix of the PDU Session for delivery to the UE.

– The (H-)SMF performs the IPv6 related operations but the IPv6 prefix is not provided to the UE, i.e. Router Advertisements and DHCPv6 are not performed. The SMF assigns an IPv6 Interface Identifier for the PDU Session. The allocated IPv6 prefix identifies the PDU Session of the UE.

– For AF influence on traffic routing (described in clause 5.6.7), when the N6 PtP tunnelling is used over the DNAI and the AF provides, by value, information about N6 traffic routing requirements in the AF request, the AF provides N6 PtP tunnelling requirements (IPv6 address and UDP port of the tunnel end in the DN) as the N6 traffic routing information associated to the DNAI; when the SMF notifies the AF of UP path management events, it includes the N6 PtP tunnel information related to the UP (the IPv6 address and the 3GPP defined UDP port of the tunnel end at the UPF) as N6 traffic routing information in the notification.

In this Release of the specification there is support for maximum one 5G QoS Flow per PDU Session of Type Unstructured.

In this Release of specification, the PDU Session of Unstructured PDU Session type is restricted to SSC mode 1 and SSC mode 2.

The UE may acquire from the SMF, at PDU Session Establishment, the MTU that the UE shall consider, see clause 5.6.10.4.

5.6.10.4 Maximum Transfer Unit size considerations

In order to avoid data packet fragmentation between the UE and the UPF acting as PSA, the link MTU size in the UE should be set to the value provided by the network as part of the IP configuration. The link MTU size for IPv4 is sent to the UE by including it in the PCO (see TS 24.501 [47]). The link MTU size for IPv6 is sent to the UE by including it in the IPv6 Router Advertisement message (see RFC 4861 [54]).

NOTE 1: Ideally the network configuration ensures that for PDU Session type IPv4v6 the link MTU values provided to the UE via PCO and in the IPv6 Router Advertisement message are the same. In cases where this condition cannot be met, the MTU size selected by the UE is unspecified.

When using a PDU Session type Unstructured, the maximum uplink packet size, and when using Ethernet, the Ethernet frames’ payload, that the UE should use may be provided by the network as a part of the session management configuration by encoding it within the PCO (see TS 24.501 [47]).

When using a PDU Session type Unstructured, to provide a consistent environment for application developers, the network shall use a maximum packet size of at least 128 octets (this applies to both uplink and downlink).

When the MT and the TE are separated, the TE may either be pre-configured to use a specific default MTU size or the TE may use an MTU size provided by the network via the MT. Thus, it is not always possible to set the MTU value by means of information provided by the network.

NOTE 2: In network deployments that have MTU size of 1500 octets in the transport network, providing a link MTU value of 1358 octets (as shown in Figure J-1) to the UE as part of the IP configuration information from the network will prevent the IP layer fragmentation within the transport network between the UE and the UPF. For network deployments that uniformly support transport with larger MTU size than 1500 octets (for example with ethernet jumbo frames of MTU size up to 9216 octets), providing a link MTU value of MTU minus 142 octets to the UE as part of the IP configuration information from the network will prevent the IP layer fragmentation within the transport network between the UE and the UPF. Link MTU considerations are discussed further in Annex J.

NOTE 3: As the link MTU value is provided as a part of the session management configuration information, a link MTU value can be provided during each PDU Session establishment. In this release, dynamic adjustment of link MTU for scenarios where MTU is not uniform across transport are not addressed.

5.6.11 UE presence in Area of Interest reporting usage by SMF

When a PDU Session is established or modified, or when the user plane path has been changed (e.g. UPF re-allocation/addition/removal), SMF may determine an Area of Interest, e.g. based on UPF Service Area, subscription by PCF for reporting UE presence in Presence Reporting Area, etc.

For 3GPP access, the Area of Interest corresponds:

– either to Presence Information that may correspond to:

– a list of Tracking Areas; or

– a list of Presence Reporting Area ID(s) and optionally the elements comprising TAs and/or NG-RAN nodes and/or cells identifiers corresponding to the PRA ID(s); or

– a LADN DNN.

For Non-3GPP access, the Area of Interest corresponds to:

– N3GPP TAI (see clause 5.3.2.3).

For UE location change into or out of an "area of interest", the SMF subscribes to "UE mobility event notification" service provided by AMF for reporting of UE presence in Area of Interest as described in clause 5.3.4.4. The AMF may send the UE location to the SMF along with the notification, e.g. for UPF selection. Upon reception of a notification from AMF, the SMF determines how to deal with the PDU Session, e.g. reallocate UPF.

In the case of LADN, the SMF provides the LADN DNN to the AMF to subscribe to "UE mobility event notification" for reporting UE presence in LADN service area. Upon reception of a notification from the AMF, the SMF determines how to deal with the PDU Session as described in clause 5.6.5.

For use cases related to policy control and charging decisions, the PCF may subscribe to event reporting from the SMF or the AMF, for UE presence in a Presence Reporting Area.

A Presence Reporting Area can be:

– A "UE-dedicated Presence Reporting Area", defined in the subscriber profile and composed of a short list of TAs and/or NG-RAN nodes and/or cells identifiers in a PLMN; or derived from the Area of Interest provided by the Application Function to the PCF (see clause 5.6.7) and composed of a short list of TAs and/or NG-RAN nodes and/or cells identifiers in a PLMN; or

– A "Core Network predefined Presence Reporting Area", predefined in the AMF and composed of a short list of TAs and/or NG-RAN nodes and/or cells identifiers in a PLMN.

In the case of Change of UE Presence in Presence Reporting Area, for core network predefined Presence Reporting Area, the AMF determines the "area of interest" corresponding to the Presence Reporting Area Identifier(s), provided by the PCF or the SMF, as a list of TAIs and/or cell identifiers and/or NG-RAN node identifiers based on local configuration. For UE-dedicated Presence Reporting Areas, the subscription for UE location change notification for an "area of interest" shall contain the PRA Identifier(s) and the list(s) of TAs, or NG-RAN Node identifier and/or cell identifiers composing the Presence Reporting Area(s). For Core Network predefined Presence Reporting Areas, the subscription for UE location change notification for an "area of interest" shall contain the PRA identifier(s).

NOTE 1: If the Presence Reporting Area (PRA) and RAN Notification Area (RNA) are partially overlapping, the PCF will not get notified for the change of PRA when UE enters or leaves the PRA but remains in the RNA in CM-CONNECTED with RRC Inactive state, because AMF is not informed.

Each Core Network predefined Presence Reporting Area can be configured with a priority level in the AMF. In order to prevent overload, the AMF may set the reporting for one or more of the received Presence Reporting Area(s) to inactive under consideration of the priority configured for each of Core Network predefined Presence Reporting Area(s), while storing the reporting request for this Presence Reporting Area in the UE context.

NOTE 2: Change of UE presence in Presence Reporting Area reporting does not apply to home routed roaming.

The AMF may be configured with a PRA identifier which refers to a Set of Core Network predefined Presence Reporting Areas. If the PCF subscribes to change of UE location for an area of interest for a Set of Presence reporting areas and provides a PRA identifier then the SMF may subscribe for event reporting for this Set of Presence Reporting Areas by only indicating this PRA Identifier in the area of interest. When the Presence Reporting Area(s) to be reported belong to a set of Core Network predefined Presence Reporting Areas in which the AMF is requested to report on change of UE presence, the AMF shall additionally add to the report the PRA Identifier of the Set of Core Network predefined Presence Reporting Areas.

Upon change of AMF, the PRA identifier(s) and if provided, the list(s) of Presence Reporting Area elements are transferred for all PDU sessions as part of MM Context information to the target AMF during the mobility procedure. If one or more Presence Reporting Area(s) was set to inactive, the target AMF may decide to reactivate one or more of the inactive Presence Reporting Area(s). The target AMF indicates per PDU session to the corresponding SMF/PCF the PRA identifier(s) and whether the UE is inside or outside the Presence Reporting Area(s) as well as the inactive Presence Reporting Area(s), if any.

NOTE 3: The target AMF cannot set the Presence Reporting Area(s) received from the source serving node to inactive.

The subscription may be maintained during the life of PDU Session, regardless of the UP activation state of PDU Session (i.e. whether UP connection of the PDU Session is activated or not).

SMF may determine a new area of interest, and send a new subscription to the AMF with the new area of interest.

SMF un-subscribes to "UE mobility event notification" service when PDU Session is released.

5.6.12 Use of Network Instance

The SMF may provide a Network Instance to the UPF in FAR and/or PDR via N4 Session Establishment or N4 Modification procedures.

NOTE 1: a Network Instance can be defined e.g. to separate IP domains, e.g. when a UPF is connected to 5G-ANs in different IP domains, overlapping UE IP addresses assigned by multiple Data Networks, transport network isolation in the same PLMN, etc.

NOTE 2: As the SMF can provide over N2 the Network Instance it has selected for the N3 CN Tunnel Info, the 5G AN does not need to provide Network Instance to the 5GC.

The SMF determines the Network Instance based on local configuration.

The SMF may determine the Network Instance for N3 and N9 interfaces, taking into account e.g. UE location, registered PLMN ID of UE, S-NSSAI of the PDU Session.

The SMF may determine the Network Instance for N6 interface taking into account e.g. (DNN, S-NSSAI) of the PDU Session.

The SMF may determine the Network Instance for N19 interface taking into account e.g. the (DNN, S-NSSAI) identifying a 5G VN group.

NOTE 3: As an example, the UPF can use the Network Instance included in the FAR, together with other information such as Outer header creation (IP address part) and Destination interface in the FAR, to determine the interface in UPF (e.g. VPN or Layer 2 technology) for forwarding of the traffic.

5.6.13 Always-on PDU session

An always-on PDU Session is a PDU Session for which User Plane resources have to be activated during every transition from CM-IDLE mode to CM-CONNECTED state.

Based on an indication from upper layers, a UE may request to establish a PDU Session as an always-on PDU Session. The SMF decides whether the PDU Session can be established as an always-on PDU Session. In Home Routed roaming case, based on local policies, the V-SMF shall be involved to determine whether the PDU Session can be established as an always-on PDU Session.

If the UE requests the 5GC to modify a PDU Session, which was established in EPS, to an always-on PDU Session after the first inter-system change from EPS to 5GS, the SMF decides whether the PDU Session can be established as an always-on PDU Session based on the procedure described above.

The UE shall request activation of User Plane resources for always-on PDU Sessions even if there are no pending uplink data for this PDU Session or when the Service Request is triggered for signalling only or when the Service Request is triggered for paging response only.

If the UE has one or more established PDU Sessions which are not accepted by the network as always-on PDU Sessions and the UE has no uplink user data pending to be sent for those PDU Sessions, the UE shall not request for activating User Plane resources for those PDU sessions.

5.6.14 Support of Framed Routing

Framed Routing is only defined for PDU Sessions of the IP type (IPv4, IPv6, IPv4v6) and allows to support an IP network behind a UE, such that a range of IPv4 addresses or IPv6 prefixes is reachable over a single PDU Session, e.g. for enterprise connectivity. Framed Routes are IP routes behind the UE.

A PDU Session may be associated with multiple Framed Routes. Each Framed Route refers to a range of IPv4 addresses (i.e. an IPv4 address and an IPv4 address mask) or a range of IPv6 Prefixes (i.e. an IPv6 Prefix and an IPv6 Prefix length). The set of one or more Framed Routes associated to a PDU Session is contained in the Framed Route information. The network does not send Framed Route information to the UE: devices in the network(s) behind the UE get their IP address by mechanisms out of the scope of 3GPP specifications. See RFC 2865 [73], RFC 3162 [74].

Framed Route information is provided by the SMF to the UPF (acting as PSA) as part of Packet Detection Rule (PDR, see clause 5.8.2.11.3) related with the network side (N6) of the UPF.

NOTE: SMF can take the UPF capabilities into account when selecting PSA UPF, to ensure that the SMF chooses PSA UPF(s) that support Framed Routing for PDU Sessions to DNN and/or slices deemed to support Framed Routing e.g. DNN and/or slices intended to support RG or if Framed Route information has been received as part of Session Management Subscription data.

The Framed Route information may be provided to the SMF by:

– the DN-AAA server as part of PDU Session Establishment authentication/authorization by a DN-AAA server (as defined in clause 5.6.6); or by

– Session Management Subscription data associated with DNN and S-NSSAI sent by UDM (as defined in clause 5.2.3.3.1 of TS 23.502 [3]).

If the SMF receives Framed Route information both from DN-AAA and from UDM, the information received from DN-AAA takes precedence and supersedes the information received from UDM.

The IPv4 address / IPv6 Prefix allocated to the UE as part of the PDU Session establishment (e.g. delivered in NAS PDU Session Establishment Accept) may belong to one of the Framed Routes associated with the PDU Session or may be dynamically allocated outside of such Framed Routes.

If PCC applies to the PDU Session, at PDU Session establishment the SMF reports to the PCF the Framed Route information corresponding to the PDU Session (as described in clause 6.1.3.5 of TS 23.503 [45]). In this case, in order to support session binding, the PCF may further report to the BSF the Framed Route information corresponding to the PDU Session (as described in clause 6.1.2.2 of TS 23.503 [45]).

If the UDM or DN-AAA updates the Framed Route information during the lifetime of the PDU Session, the SMF releases the PDU Session and may include in the release request an indication for the UE to re-establish the PDU Session.

5.6.15 Triggers for network analytics

Triggers for the SMF to request for or subscribe to the analytics information from the NWDAF are internal logic may include for example:

– UE PDU Session related event subscription by other NFs (e.g. AMF, NEF);

– UE access and mobility event reports from the AMF;

– locally detected events;

– analytics information received.

The trigger conditions may depend on operator and implementation policy in the SMF. When a trigger condition happens, the SMF may decide if any analytics information is needed and if so, request for or subscription to the analytics information from the NWDAF.

The SMF may, upon detection of certain local events, e.g. number of PDU sessions establishment or released reaches a threshold in a specific area, request for or subscribe to network analytics related to "Abnormal behaviour" as described in TS 23.288 [86] to detect whether there are any exceptional UE behaviours in this area.