Tech-invite  3GPPspecsRELsGlossariesSIP
Info21222324252627282931323334353637384‑5x

full Contents for  TS 23.501  Word version:   16.4.0

Top   Up   Prev   Next
1…   3…   4…   4.2.4   4.2.5…   4.2.8…   4.2.8.2.2   4.2.8.2.3…   4.2.8.4…   4.2.9…   4.3…   4.3.3   4.3.4   4.3.5   4.4…   4.4.6…   4.4.8   5…   5.3…   5.3.3…   5.4…   5.5…   5.6…   5.6.7…   5.7…   5.7.2…   5.7.3…   5.7.4   5.7.5…   5.8…   5.8.2.11…   5.9…   5.10…   5.11…   5.15…   5.16…   5.17…   5.18…   5.19…   5.21…   5.22…   5.27…   5.28…   5.29…   5.30…   5.31…   5.32…   5.33…   5.34…   5.35…   6…   6.3…   7…   7.2…   8…   8.2.4   8.2.5…   8.3…   A…   D…   E…   F   G…   G.3   G.4…   J…

 

5.6  Session Management
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 TS 23.502, clause 4.16.12.2 and therefore the UE requested DNN will be up to date.
In order to cover cases that UE operates using local configuration, but also other cases where operator policies can be used in order to replace an "up to date" UE requested DNN with another DNN used only internally in the network, during UE Registration procedure the PCF may indicate, to the AMF, the operator policies to be used at PDU Session Establishment for DNN replacement of a UE requested DNN. PCF may indicate a policy for DNN replacement of UE requested DNNs not supported by the network, and/or indicate a list of UE requested DNNs per S-NSSAI valid for the serving network, that are subject for replacement (details are described in TS 23.503).
If the DNN provided by the UE is not supported by the network and AMF cannot select an SMF by querying NRF, the AMF shall reject the NAS Message containing PDU Session Establishment Request from the UE with a cause indicating that the DNN is not supported unless the PCF provided the policy to perform a DNN replacement of unsupported DNNs.
If the DNN requested by the UE is indicated for replacement or the DNN provided by the UE is not supported by the network and the PCF provided the policy to perform DNN replacement of UE requested DNNs not supported by the network, the AMF shall interact with the PCF to perform a DNN replacement. During PDU Session Establishment procedure and as a result of DNN replacement, the PCF provides the selected DNN that is applicable for the S-NSSAI requested by the UE at the PDU Session Establishment. The AMF uses the selected DNN in the query towards the NRF for the SMF selection, as specified in clause 6.3.2, and provides both requested and selected DNN to the selected SMF. For PDU Session with Home-routed Roaming whether to perform DNN replacement is based on operator agreements.
NOTE 1:
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 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.240.
A PDU Session may support:
  1. a single-access PDU Connectivity Service, in which case the PDU Session is associated with a single access type at a given time, i.e. either 3GPP access or non-3GPP access; or
  2. a multi-access PDU Connectivity Service, in which case the PDU Session is simultaneously associated with both 3GPP access and non-3GPP access and simultaneously associated with two independent N3/N9 tunnels between the PSA and RAN/AN.
A PDU Session supporting a single-access PDU Connectivity Service is also referred to as single-access PDU Session, while a PDU Session supporting a multi-access PDU Connectivity Service is referred to as Multi-Access PDU (MA PDU) Session and it is used to support the ATSSS feature (see clause 5.32 for details).
A UE that is registered over multiple accesses chooses over which access to establish a PDU Session. As defined in TS 23.503, the HPLMN may send policies to the UE to guide the UE selection of the access over which to establish a PDU Session.
NOTE 3:
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.
In a PDU Session Establishment Request message sent to the network, the UE shall provide a PDU Session ID. The PDU Session ID is unique per UE and is the identifier used to uniquely identify one of a UE's PDU Sessions. The PDU Session ID shall be stored in the UDM to support handover between 3GPP and non-3GPP access when different PLMNs are used for the two accesses. The UE also provides as described in TS 24.501:
  1. PDU Session Type.
  2. S-NSSAI of the HPLMN that matches the application (that is triggering the PDU Session Request) within the NSSP in the URSP rules or within the UE Local Configuration as defined in clause 6.1.2.2.1 of TS 23.503.
    NOTE 4:
    If the UE cannot determine any S-NSSAI after performing the association of the application to a PDU Session, then it does not indicate any S-NSSAI in the PDU Session Establishment procedure as defined in clause 5.15.5.3.
  3. S-NSSAI of the Serving PLMN from the Allowed NSSAI, corresponding to the S-NSSAI of the HPLMN (b).
    NOTE 5:
    Generally, in non-roaming scenario the mapping of the Allowed NSSAI to HPLMN S-NSSAIs is not provided to the UE (because the S-NSSAI of the Serving PLMN (c) has the same value of the S-NSSAI of the HPLMN (b)), therefore the UE provides in the PDU Session Request only the S-NSSAI of the Serving PLMN (c). However, if the UE is provided with the mapping of the Allowed NSSAI to HPLMN S-NSSAIs even in non-roaming scenario, then the UE provides in the PDU Session Request both the S-NSSAI of the HPLMN (b) and the S-NSSAI from the Allowed NSSAI (c) that maps to the S-NSSAI of the HPLMN.
    NOTE 6:
    In roaming scenarios the UE provides in the PDU Session Request both the S-NSSAI of the HPLMN (b) and the S-NSSAI of the VPLMN from the Allowed NSSAI (c) that maps to the S-NSSAI of the HPLMN.
  4. DNN (Data Network Name).
  5. SSC mode (Service and Session Continuity mode defined in clause 5.6.9.2).
Additionally, if the UE supports ATSSS and wants to activate a MA PDU Session, the UE shall provide Request Type as "MA PDU Request" and shall indicate the supported ATSSS capabilities (see clause 5.32 for details).
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) does not change during lifetime of the PDU session.
Up
5.6.2  Interaction between AMF and SMFWord-p. 105
The AMF and SMF are separate Network Functions.
N1 related interaction with SMF is as follows:
  • The single N1 termination point is located in AMF. The AMF forwards SM related NAS information to the SMF based on the PDU Session ID in the NAS message. Further SM NAS exchanges (e.g. SM NAS message responses) for N1 NAS signalling received by the AMF over an access (e.g. 3GPP access or non-3GPP access) are transported over the same access.
  • The serving PLMN ensures that subsequent SM NAS exchanges (e.g. SM NAS message responses) for N1 NAS signalling received by the AMF over an access (e.g. 3GPP access or non-3GPP access) are transported over the same access.
  • SMF handles the Session management part of NAS signalling exchanged with the UE.
  • The UE shall only initiate PDU Session Establishment in RM-REGISTERED state.
  • When a SMF has been selected to serve a specific PDU Session, AMF has to ensure that all NAS signalling related with this PDU Session is handled by the same SMF instance.
  • Upon successful PDU Session Establishment, the AMF and SMF stores the Access Type that the PDU Session is associated.
N11 related interaction with SMF is as follows:
  • The AMF reports the reachability of the UE based on a subscription from the SMF, including:
  • The UE location information with respect to the area of interest indicated by the SMF.
  • The SMF indicates to AMF when a PDU Session has been released.
  • Upon successful PDU Session Establishment, AMF stores the identification of serving SMF of UE and SMF stores the identification of serving AMF of UE including the AMF set. When trying to reach the AMF serving the UE, the SMF may need to apply the behaviour described for "the other CP NFs" in clause 5.21.
N2 related interaction with SMF is as follows:
  • Some N2 signalling (such as handover related signalling) may require the action of both AMF and SMF. In such case, the AMF is responsible to ensure the coordination between AMF and SMF. The AMF may forward the SM N2 signalling towards the corresponding SMF based on the PDU Session ID in N2 signalling.
  • SMF shall provide PDU Session Type together with PDU Session ID to NG-RAN, in order to facilitate NG-RAN to apply suitable header compression mechanism to packet of different PDU type. Details refer to TS 38.413.
N3 related interaction with SMF is as follows:
  • Selective activation and deactivation of UP connection of existing PDU Session is defined in clause 5.6.8.
N4 related interaction with SMF is as follows:
  • When it is made aware by the UPF that some DL data has arrived for a UE without downlink N3 tunnel information, the SMF interacts with the AMF to initiate Network Triggered Service Request procedure. In this case, if the SMF is aware that the UE is unreachable or if the UE is reachable only for regulatory prioritized service and the PDU Session is not for regulatory prioritized service, then the SMF shall not inform DL data notification to the AMF
The AMF is responsible of selecting the SMF per procedures described in clause 6.3.2. For this purpose, it gets subscription data from the UDM that are defined in that clause. Furthermore, it retrieves the subscribed UE-AMBR from the UDM, and optionally dynamic serving network UE-AMBR from PCF based on operator local policy, and sends to the (R)AN as defined in clause 5.7.2
AMF-SMF interactions to support LADN are defined in clause 5.6.5.
In order to support charging data collection and to fulfill regulatory requirement (in order to provide NPLI - Network Provided Location Information- as defined in TS 23.228) related with with the set-up, modification and release of IMS Voice calls or with SMS transfer the following applies
  • At the time of the PDU Session Establishment, the AMF provides the SMF with the PEI of the UE if the PEI is available at the AMF.
  • When it forwards UL NAS or N2 signalling to a peer NF (e.g. to SMF or to SMSF) or during the UP connection activation of a PDU Session, the AMF provides any User Location Information it has received from the 5G-AN as well as the Access Type (3GPP - Non 3GPP) of the AN over which it has received the UL NAS or N2 signalling. The AMF also provides the corresponding UE Time Zone. In addition, in order to fulfill regulatory requirement (i.e. providing Network Provided Location Information (NPLI), as defined in TS 23.228) when the access is non-3GPP, the AMF may also provide the last known 3GPP access User Location Information with its age, if the UE is still attached to the same AMF for 3GPP access (i.e. valid User Location Information).
  • The User Location Information, the access type and the UE Time Zone may be further provided by SMF to PCF. The PCF may get this information from the SMF in order to provide NPLI to applications (such as IMS) that have requested it.
The User Location Information may correspond to:
  • In the case of 3GPP access: Cell-Id. The AMF includes only the Primary Cell-Id even if it had received also the Cell-Id of the Primary cell in the Secondary RAN node from NG-RAN.
  • In the case of Untrusted non-3GPP access: a UE local IP address (used to reach the N3IWF) and optionally UDP or TCP source port number (if NAT is detected).
  • In the case of Trusted non-3GPP access: TNAP/TWAP Identifier, a UE/N5CW device local IP address (used to reach the TNGF/TWIF) and optionally UDP or TCP source port number (if NAT is detected).
  • When the UE uses WLAN based on IEEE 802.11 technology to reach the TNGF, the TNAP Identifier shall include the SSID of the access point to which the UE is attached. The TNAP Identifier shall include at least one of the following elements, unless otherwise determined by the TWAN operator's policies:
    • the BSSID (see IEEE Std 802.11-2012 [106]);
    • civic address information of the TNAP to which the UE is attached.
    The TWAP Identifier shall include the SSID of the access point to which the NC5W is attached. The TWAP Identifier shall also include at least one of the following elements, unless otherwise determined by the TWAN operator's policies:
  • the BSSID (see IEEE Std 802.11-2012 [106]);
  • civic address information of the TWAP to which the UE is attached.
  • NOTE 1:
    The SSID can be the same for several TNAPs/TWAPs and SSID only cannot provide a location, but it might be sufficient for charging purposes.
    NOTE 2:
    the BSSID associated with a TNAP/TWAP is assumed to be static.
  • In the case of W-5GAN access: The User Location Information for W-5GAN is defined in TS 23.316.
When the SMF receives a request to provide Access Network Information reporting while there is no action to carry out towards the 5G-AN or the UE (e.g. no QoS flow to create / Update / modify), the SMF may request User Location Information from the AMF.
The interaction between AMF and SMF(s) for the case of a I-SMF insertion, relocation or removal for a PDU session is described in clause 5.34.
Up
5.6.3  RoamingWord-p. 107
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 TS 23.502, clause 4.3.2.2.3.3, and provides the identifier of the selected SMF in the HPLMN to the selected SMF in the VPLMN.
In roaming with LBO, the AMF selects a SMF in the VPLMN as described in clause 6.3.2 and TS 23.502, clause 4.3.2.2.3.2. In this case, when handling a PDU Session Establishment Request message, the SMF in the VPLMN may reject the N11 message (related with the PDU Session Establishment Request message) with a proper N11 cause. This triggers the AMF to select both a new SMF in the VPLMN and a SMF in the HPLMN in order to handle the PDU Session using home routed roaming.
Up
5.6.4  Single PDU Session with multiple PDU Session AnchorsWord-p. 108
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 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.
Up
5.6.4.2  Usage of an UL Classifier for a PDU SessionWord-p. 109
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.
Up
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 access to the local 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 N9 forwarding tunnel is maintained until all active traffic flowing on it ceases to exist for a configurable period of time or until the AF informs the SMF that it can release the source PSA providing access to the source local 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 DN into the N9 forwarding tunnel towards the source UL CL.
  • force any traffic related to the application in the target local DN to go to the new local DN via the target PSA.
SMF may send a Late Notification to AF to inform it about the DNAI change as described in TS 23.502, clause 4.3.6.3. This notification can be used by the AF e.g. to trigger mechanisms in the source local DN to redirect the ongoing traffic sessions towards an application in the target local DN. SMF can also send late notification to the target AF instance if associated with this target local DN.
The procedure for session continuity upon UL CL relocation is described in TS 23.502, clause 4.3.5.7.
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.
Up
5.6.4.3  Usage of IPv6 multi-homing for a PDU SessionWord-p. 110
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 TS 23.502, clause 4.3.5.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.
Up
NOTE 2:
It is possible for a given UPF to support both the Branching Point and the PDU Session Anchor functionalities.
Up
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 NetworkWord-p. 112
The access to a DN via a PDU Session for a LADN is only available in a specific LADN service area. A LADN service area is a set of Tracking Areas. LADN is a service provided by the serving PLMN. It includes:
  • LADN service applies only to 3GPP accesses and does not apply in Home Routed case.
  • The usage of LADN DNN requires an explicit subscription to this DNN or subscription to a wildcard DNN.
  • Whether a DNN corresponds to a LADN service is an attribute of a DNN and is per PLMN.
The UE is configured to know whether a DNN is a LADN DNN on a per-PLMN basis, and an association between application and LADN DNN. The configured association is considered to be a UE local configuration defined in TS 23.503. Alternatively, the UE gets the information whether a DNN is a LADN DNN from LADN Information during (re -)registration procedure as described in this clause.
NOTE 1:
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 clause 4.2.4 and clause 4.2.2.2.2 in TS 23.502.
When receiving PDU Session Establishment with LADN DNN or Service Request for the established PDU Session corresponding to LADN, the AMF determines UE presence in LADN service area and forwards it to the SMF if the requested DNN is configured at the AMF as a LADN DNN.
Based on the LADN Service Area Information in the UE, the UE determines whether it is in or out of a LADN service area. If the UE does not have the LADN Service Area Information for a LADN DNN, the UE shall consider it is out of the LADN service area.
The UE takes actions as follows:
  1. When the UE is out of a LADN service area, the UE:
    • shall not request to activate UP connection of a PDU Session for this LADN DNN;
    • shall not establish/modify a PDU Session for this LADN DNN (except for PS Data Off status change reporting for an established PDU Session);
    • need not release any existing PDU Session for this LADN DNN unless UE receives explicit SM PDU Session Release Request message from the network.
  2. When the UE is in a LADN service area, the UE:
    • may request a PDU Session Establishment/Modification for this LADN DNN;
    • may request to activate UP connection of the existing PDU Session for this LADN DNN.
The SMF supporting a DNN is configured with information about whether this DNN is a LADN DNN or not.
When receiving SM request corresponding an LADN from the AMF, the SMF determines whether the UE is inside LADN service area based on the indication (i.e. UE Presence in LADN service area) received from the AMF. If the SMF does not receive the indication, the SMF considers that the UE is outside of the LADN service area. The SMF shall reject the request if the UE is outside of the LADN service area.
When the SMF receives a request for PDU Session Establishment with the LADN DNN, it shall subscribe to "UE mobility event notification" for reporting UE presence in Area of Interest by providing LADN DNN to the AMF as described in clauses 5.6.11 and 5.3.4.4.
Based on the notification about the UE presence in LADN service area notified by AMF (i.e. IN, OUT, or UNKNOWN), the SMF takes actions as follows based on operator's policy:
  1. When SMF is informed that the UE presence in a LADN service area is OUT, the SMF shall:
    • release the PDU Session immediately; or
    • deactivate the user plane connection for the PDU Session with maintaining the PDU Session and ensure the Data Notification is disabled and the SMF may release the PDU Session if the SMF is not informed that the UE moves into the LADN service area after a period.
  2. When SMF is informed that the UE presence a LADN service area is IN, the SMF shall:
    • ensure that Data Notification is enabled.
    • trigger the Network triggered Service Request procedure for a LADN PDU Session to active the UP connection when the SMF receives downlink data or Data Notification from UPF.
  3. When the SMF is informed that the UE presence in a LADN service area is UNKNOWN, the SMF may:
    • ensure that Data Notification is enabled.
    • trigger the Network triggered Service Request procedure for a LADN PDU Session to active the UP connection when the SMF receives downlink data or Data Notification from UPF.
Up
5.6.6  Secondary authentication/authorization by a DN-AAA server during the establishment of a PDU SessionWord-p. 114
At PDU Session Establishment to a DN:
  • The DN-specific identity (TS 33.501) of a UE may be authenticated/authorized by the DN.
  • NOTE 1:
    the DN-AAA server may belong to the 5GC or to the DN.
  • If the UE provides authentication/authorization information corresponding to a DN-specific identity during the Establishment of the PDU Session, and the SMF determines that Secondary authentication/authorization of the PDU Session Establishment is required based on the SMF policy associated with the DN, the SMF passes the authentication/authorization information of the UE to the DN-AAA server via the UPF if the DN-AAA server is located in the DN. If the SMF determines that Secondary authentication/authorization of the PDU Session Establishment is required but the UE has not provided a DN-specific identity as part of the PDU Session Establishment request, the SMF requests the UE to indicate a DN-specific identity using EAP procedures as described in TS 33.501. If the Secondary authentication/authorization of the PDU Session Establishment fails, the SMF rejects the PDU Session Establishment.
  • NOTE 2:
    If the DN-AAA server is located in the 5GC and reachable directly, then the SMF may communicate with it directly without involving the UPF.
  • The DN-AAA server may authenticate/authorize the PDU Session Establishment.
  • When DN-AAA server authorizes the PDU Session Establishment, it may send DN Authorization Data for the established PDU Session to the SMF. The DN authorization data for the established PDU Session may include one or more of the following:
    • A DN Authorization Profile Index which is a reference to authorization data for policy and charging control locally configured in the SMF or PCF.
    • a list of allowed MAC addresses for the PDU Session; this shall apply only for PDU Session of Ethernet PDU type and is further described in clause 5.6.10.2.
    • a list of allowed VIDs for the PDU Session; this shall apply only for PDU Session of Ethernet PDU type and is further described in clause 5.6.10.2.
    • DN authorized Session AMBR for the PDU Session. The DN Authorized Session AMBR for the PDU Session takes precedence over the subscribed Session-AMBR received from the UDM.
    • a list of Framed Routes (see clause 5.6.14) for the PDU Session.
SMF policies may require DN authorization without Secondary authentication/authorization. In that case, when contacting the DN-AAA server for authorization, the SMF provides the GPSI of the UE if available.
Such Secondary authentication/authorization takes place for the purpose of PDU Session authorization in addition to:
  • The 5GC access authentication handled by AMF and described in clause 5.2.
  • The PDU Session authorization enforced by SMF with regard to subscription data retrieved from UDM.
Based on local policies the SMF may initiate Secondary authentication/authorization at PDU Session Establishment. The SMF provides the GPSI, if available, in the signalling exchanged with the DN-AAA during Secondary authentication/authorization.
After the successful Secondary authentication/authorization, a session is kept between the SMF and the DN-AAA.
The UE provides the authentication/authorization information required to support Secondary authentication/authorization by the DN over NAS SM.
NOTE 3:
The way for the UE to acquire such information is not defined.
When SMF adds a PDU Session Anchor (such as defined in clause 5.6.4) to a PDU Session Secondary authentication/authorization is not carried out, but SMF policies may require SMF to notify the DN when a new prefix or address has been added to or removed from a PDU Session or N6 traffic routing information has been changed for a PDU Session.
When SMF gets notified from UPF with the addition or removal of MAC addresses to/from a PDU Session, the SMF policies may require SMF to notify the DN-AAA server.
Indication of PDU Session Establishment rejection is transferred by SMF to the UE via NAS SM.
If the DN-AAA sends DN Authorization Data for the authorized PDU Session to the SMF and dynamic PCC is deployed, the SMF sends the PCF the DN authorized Session AMBR and/or DN Authorization Profile Index in the DN Authorization Data for the established PDU Session.
If the DN-AAA sends DN Authorization Profile Index in DN Authorization Data to the SMF and dynamic PCC is not deployed, the SMF uses the DN Authorization Profile Index to refer the locally configured information.
NOTE 4:
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.
At any time, a DN-AAA server or SMF may trigger Secondary Re-authentication procedure for a PDU Session established with Secondary Authentication as specified in clause 11.1.3 in TS 33.501.
During Secondary Re-authentication/Re-authorization, if the SMF receives from DN-AAA the DN authorized Session AMBR and/or DN Authorization Profile Index, the SMF shall report the received value(s) to the PCF.
The procedure for secondary authentication/authorization by a DN-AAA server during the establishment of a PDU Session is described in TS 23.502, clause 4.3.2.3.
Up

Up   Top   ToC