User Plane Function(s) handle the user plane path of PDU Sessions. 3GPP specifications support deployments with a single UPF or multiple UPFs for a given PDU Session. UPF selection is performed by SMF. The details of UPF selection is described in clause 6.3.3. The number of UPFs supported for a PDU Session is unrestricted.
For an IPv4 type PDU Session or an IPv6 type PDU Session without multi-homing or an IPv4v6 type PDU Session, when multiple PDU Session Anchors are used (due to UL CL being inserted), only one IPv4 address and/or IPv6 prefix is allocated for the PDU Session. For an IPv6 multi-homed PDU Session there are multiple IPv6 prefixes allocated for the PDU Session as described in clause 220.127.116.11.
If the SMF had requested the UPF to proxy ARP or IPv6 Neighbour Solicitation for an Ethernet DNN, the UPF should respond to the ARP or IPv6 Neighbour Solicitation Request, itself.
Deployments with one single UPF used to serve a PDU Session do not apply to the Home Routed case and may not apply to the cases described in clause 5.6.4.
Deployments where a UPF is controlled either by a single SMF or multiple SMFs (for different PDU Sessions) are supported.
UPF traffic detection capabilities may be used by the SMF in order to control at least following features of the UPF:
Traffic detection (e.g. classifying traffic of IP type, Ethernet type, or unstructured type)
Traffic reporting (e.g. allowing SMF support for charging).
QoS enforcement (The corresponding requirements are defined in clause 5.7).
Traffic routing (e.g. as defined in clause 5.6.4. for UL CL or IPv6 multi-homing).
This clause contains detailed functional descriptions for some of the functions provided by the UPF. It is described how the SMF instructs it's corresponding UP function and which control parameters are used.
The UE IP address management includes allocation and release of the UE IP address as well as renewal of the allocated IP address, where applicable.
If there is a matching URSP rule or a matching UE Local Configuration containing a PDU Session Type of "IPv4", "IPv6" or "IPv4v6", then the UE shall set the requested PDU Session Type to the PDU Session Type contained in the matching URSP rule or in the matching UE Local Configuration, if this PDU Session Type is supported by the UE's IP stack capabilities. If there is no PDU Session Type value in the matching URSP rule or in the matching UE Local Configuration, the UE shall not include the requested PDU Session Type in the PDU Session Establishment Request message.
Otherwise, if there is no matching URSP rule and no matching UE Local Configuration, the UE shall set the requested PDU Session Type during the PDU Session Establishment procedure based on its IP stack capabilities as follows:
A UE which supports IPv6 and IPv4 shall set the requested PDU Session Type "IPv4v6".
A UE which supports only IPv4 shall request for PDU Session Type "IPv4".
A UE which supports only IPv6 shall request for PDU Session Type "IPv6".
When the IP version capability of the UE is unknown in the UE (as in the case when the MT and TE are separated and the capability of the TE is not known in the MT), the UE shall request for PDU Session Type "IPv4v6".
The SMF selects PDU Session Type of the PDU Session as follows:
If the SMF receives a request with PDU Session Type set to "IPv4v6", the SMF selects either PDU Session Type "IPv4" or "IPv6" or "IPv4v6" based on DNN configuration, subscription data and operator policies.
If the SMF receives a request for PDU Session Type "IPv4" or "IPv6" and the requested IP version is supported by the DNN the SMF selects the requested PDU Session type.
In its answer to the UE, the SMF may indicate the PDU Session Types not allowed for the combination of (DNN, S-NNSAI). In this case, the UE shall not request another PDU Session to the same (DNN, S-NNSAI) for PDU Session Types indicated as not allowed by the network. In the case that the initial PDU Session was established with a PDU Session Type and the UE needs another single IP version PDU Session Type, the UE may initiate another PDU Session Establishment procedure to this (DNN, S-NNSAI) in order to activate a second PDU session with that PDU Session Type.
An SMF shall ensure that the IP address management procedure is based on the selected PDU Session Type. If IPv4 PDU Session Type is selected, an IPv4 address is allocated to the UE. Similarly, if IPv6 PDU Session type is selected, an IPv6 prefix is allocated. If IPv4v6 PDU Session Type is selected, both an IPv4 address and an IPv6 prefix are allocated. For Roaming case, the SMF in this clause refers to the SMF controlling the UPF(s) acting as PDU Session Anchor. i.e. H-SMF in home routed case and V-SMF in local breakout case. For home routed case, V-SMF forwards the PDU Session Type requested by UE to H-SMF without interpreting it. V-SMF sends back to UE the PDU Session Type selected by H-SMF. The SMF shall process the UE IP address management related messages, maintain the corresponding state information and provide the response messages to the UE.
The 5GC and UE support the following mechanisms:
During PDU Session Establishment procedure, the SMF sends the IP address to the UE via SM NAS signalling. The IPv4 address allocation and/or IPv4 parameter configuration via DHCPv4 (according to RFC 2131) can also be used once PDU Session is established.
/64 IPv6 prefix allocation shall be supported via IPv6 Stateless Auto-configuration according to RFC 4862, if IPv6 is supported. The details of Stateless IPv6 Address Autoconfiguration are described in clause 18.104.22.168.3. IPv6 parameter configuration via Stateless DHCPv6 (according to RFC 3736) may also be supported.
For scenarios with RG connecting to 5GC, additional features for IPv6 address allocation and IPv6 prefix delegation are supported, as described in TS 23.316.
To allocate the IP address via DHCPv4, the UE may indicate to the network within the Protocol Configuration Options that the UE requests to obtain the IPv4 address with DHCPv4, or obtain the IP address during the PDU Session Establishment procedure. This implies the following behaviour both for static and dynamic address allocation:
The UE may indicate that it requests to obtain an IPv4 address as part of the PDU Session Establishment procedure. In such a case, the UE relies on the 5GC network to provide IPv4 address to the UE as part of the PDU Session Establishment procedure.
The UE may indicate that it requests to obtain the IPv4 address after the PDU Session Establishment procedure by DHCPv4. That is, when the 5GC network supports DHCPv4 and allows that, it does not provide the IPv4 address for the UE as part of the PDU Session Establishment procedure. The network may respond to the UE by setting the allocated IPv4 Address to 0.0.0.0. After the PDU Session Establishment procedure is completed, the UE uses the connectivity with the 5GC and initiates the IPv4 address allocation on its own using DHCPv4. However, if the 5GC network provides IPv4 address to the UE as part of the PDU Session Establishment procedure, the UE should accept the IPv4 address indicated in the PDU Session Establishment procedure.
If the UE sends no IP Address Allocation request, the SMF determines whether DHCPv4 is used between the UE and the SMF or not, based on per DNN configuration.
If dynamic policy provisioning is deployed, and the PCF was not informed of the IPv4 address at PDU Session Establishment procedure, the SMF shall inform the PCF about an allocated IPv4 address. If the IPv4 address is released, the SMF shall inform the PCF about the de-allocation of an IPv4 address.
In order to support DHCP based IP address configuration, the SMF shall act as the DHCP server towards the UE. The PDU Session Anchor UPF does not have any related DHCP functionality. The SMF instructs the PDU Session Anchor UPF serving the PDU Session to forward DHCP packets between the UE and the SMF over the user plane.
When DHCP is used for external data network assigned addressing and parameter configuration, the SMF shall act as the DHCP client towards the external DHCP server. The UPF does not have any related DHCP functionality. In the case of DHCP server on the external data network, the SMF instructs a UPF with N6 connectivity to forward DHCP packets between the UE and the SMF and the external DHCP server over the user plane.
The 5GC may also support the allocation of a static IPv4 address and/or a static IPv6 prefix based on subscription information in the UDM or based on the configuration on a per-subscriber, per-DNN basis and per-S-NSSAI.
If the static IP address/prefix is stored in the UDM, during PDU Session Establishment procedure, the SMF retrieves this static IP address/prefix from the UDM. If the static IP address/prefix is not stored in the UDM subscription record, it may be configured on a per-subscriber, per-DNN and per-S-NSSAI basis in the DHCP/DN-AAA server and the SMF retrieves the IP address/prefix for the UE from the DHCP/DN-AAA server. This IP address/prefix is delivered to the UE in the same way as a dynamic IP address/prefix. It is transparent to the UE whether the PLMN or the external data network allocates the IP address and whether the IP address is static or dynamic.
For IPv4 or IPv6 or IPv4v6 PDU Session Type, during PDU Session Establishment procedure, the SMF may receive a Subscriber's IP Index from the UDM. If the UE IP address/prefix was not already allocated and provided to PCF when SMF initiates the SM policy association, the SMF may receive a Subscribers IP Index from the PCF. If the SMF received a Subscriber's IP index from both UDM and PCF, the SMF shall apply the Subscriber's IP Index received from the PCF. The SMF may use the Subscriber's IP Index to assist in selecting how the IP address is to be allocated when multiple allocation methods, or multiple instances of the same method are supported. In the case of Home Routed roaming, the H-SMF may receive the IP index from the H-PCF.
When Static IP addresses for a PDU session are not used, the actual allocation of the IP Address(es) for a PDU Session may use any of the following mechanisms:
The SMF allocates the IP address from a pool that corresponds to the PDU Session Anchor (UPF) that has been selected
The UE IP address is obtained from the UPF. In that case the SMF shall interact with the UPF via N4 procedures to obtain a suitable IP address. The SMF provides the UPF with the necessary information allowing the UPF to derive the proper IP address (e.g. the network instance).
In the case that the UE IP address is obtained from the external data network, additionally, the SMF shall also send the allocation, renewal and release related request messages to the external data network, i.e. DHCP/DN-AAA server, and maintain the corresponding state information. The IP address allocation request sent to DHCP/DN-AAA server may include the IP address pool ID to identify which range of IP address is to be allocated. In this case the SMF is provisioned with separate IP address pool ID(s), and the mapping between IP address pool ID and UPF Id, DNN, S-NSSAI, IP version. The provision is done by OAM or during the N4 Association Setup procedure.
A given IP address pool is controlled by a unique entity (either the SMF or the UPF or an external server). The IP address managed by the UPF can be partitioned into multiple IP address pool partition(s), i.e. associated with multiple IP address pool ID(s).
When the SMF is configured to obtain UE IP addresses from the UPF, the SMF may select a UPF based upon support of this feature. The SMF determines whether the UPF supports this feature via NRF or via N4 capability negotiation during N4 Association Setup. If no appropriate UPF support the feature, the SMF may allocate UE IP addresses, if configured to do so.
The IP address/prefix is released by the SMF (e.g. upon release of the PDU Session), likewise the UPF considers that any IP address it has allocated within a N4 session are released when this N4 session is released.
When the UE has an IPv6 multi-homed PDU Session the UE selects the source IPv6 prefix according to IPv6 multi-homed routing rules pre-configured in the UE or received from network. IPv6 multi-homed routing rules received from the network have a higher priority than IPv6 multi-homed routing rules pre-configured in the UE
The SMF can generate the IPv6 multi-homed routing rules for a UE based on local configuration or dynamic PCC rules received from the PCF as defined in TS 23.503. If dynamic PCC is deployed, the SMF generates the IPv6 multi-home routing rules for a source IPv6 prefix based on the SDF Templates of those PCC rules which contain the DNAI corresponding to the newly assigned IPv6 prefix. The SMF can send IPv6 multi-homed routing rules to the UE to influence the source IPv6 prefix selection in IPv6 Router Advertisement (RA) messages according to RFC 4191 at any time during the lifetime of the IPv6 multi-homed PDU Session. Such messages are sent via the UPF.
If Stateless IPv6 Address Autoconfiguration is used for IPv6 address allocation to the UE, after PDU Session Establishment the UE may send a Router Solicitation message to the SMF to solicit a Router Advertisement message. The SMF sends a Router Advertisement message (solicited or unsolicited) to the UE. The Router Advertisement messages shall contain the IPv6 prefix.
After the UE has received the Router Advertisement message, it constructs a full IPv6 address via IPv6 Stateless Address Autoconfiguration in accordance with RFC 4862. To ensure that the link-local address generated by the UE does not collide with the link-local address of the UPF and the SMF, the SMF shall provide an interface identifier (see RFC 4862) to the UE and the UE shall use this interface identifier to configure its link-local address. For Stateless Address Autoconfiguration however, the UE can choose any interface identifier to generate IPv6 addresses, other than link-local, without involving the network. However, the UE shall not use any identifiers defined in TS 23.003 as the basis for generating the interface identifier. For privacy, the UE may change the interface identifier used to generate full IPv6 address, as defined in TS 23.221 without involving the network. Any prefix that the SMF advertises to the UE is globally unique. The SMF shall also record the relationship between the UE's identity (SUPI) and the allocated IPv6 prefix. Because any prefix that the SMF advertises to the UE is globally unique, there is no need for the UE to perform Duplicate Address Detection for any IPv6 address configured from the allocated IPv6 prefix. Even if the UE does not need to use Neighbor Solicitation messages for Duplicate Address Detection, the UE may, for example, use them to perform Neighbor Unreachability Detection towards the SMF, as defined in RFC 4861. Therefore, the SMF shall respond with a Neighbor Advertisement upon receiving a Neighbor Solicitation message from the UE.
In IPv6 multi-homing PDU session, SMF shall not allocate an interface identifier when a new IPv6 prefix allocated corresponding to the new PDU Session Anchor.
The above IPv6 related messages (e.g. Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement) are transferred between the SMF and UE via the UPF(s). If the Control Plane CIoT 5GS Optimisation is enabled for a PDU session, the above IPv6 related messages are transferred between the SMF and UE via the AMF after PDU Session Establishment, see clauses 22.214.171.124.1 and 126.96.36.199.2 of TS 23.502, using the Mobile Terminated Data Transport in Control Plane CIoT 5GS Optimisation procedures.
CN Tunnel Info is the Core Network address of a N3/N9 tunnel corresponding to the PDU Session. It comprises the TEID and the IP address which is used by the UPF on the N3/N9 tunnel for the PDU Session.
The CN Tunnel Info allocation and release is performed by the UPF. The SMF shall indicate to the UPF when the UPF is required to allocate/release CN Tunnel Info.
The UPF shall manage the CN Tunnel Info space. When a new CN Tunnel Info is needed, the SMF shall request over N4 the UPF to allocate CN Tunnel Info for the applicable N3/N9 reference point. In response, the UPF provides CN Tunnel Info to the SMF. In the case of PDU Session Release or a UPF is removed from the user plane path of an existing PDU Session, the SMF shall request UPF to release CN Tunnel Info for the PDU Session. If the corresponding N4 Session is released the UPF releases the associated CN Tunnel Info.
This clause describes the detection process at the UPF that identifies the packets belonging to a session, or a service data flow.
The SMF is responsible for instructing the UP function about how to detect user data traffic belonging to a Packet Detection Rule (PDR). The other parameters provided within a PDR describe how the UP function shall treat a packet that matches the detection information.
In this Release of the specification for Unstructured PDU Session Type, the UPF does not perform-QoS Flow level traffic detection for QoS enforcement.
Traffic detection information sent by the SMF to the UPF for a PDU Session may be associated with Network instance for detection and routing of traffic over N6. In the case of IP PDU Session Type, Network Instances can e.g. be used by the UPF for traffic detection and routing in the case of different IP domains or overlapping IP addresses. In the case of Ethernet PDU Session Type, different Network Instances can e.g. be configured in the UPF with different ways to handle the association between N6 and the PDU Sessions.
When configuring an UPF acting as PSA for an Ethernet PDU Session Type, the SMF may instruct the UPF to route the traffic based on detected MAC addresses as follows.
The UPF learns the MAC address(es) connected via N6 based on the source MAC addresses of the DL traffic received on a N6 Network Instance.
The UPF learns the MAC address(es) of UE(s) and devices connected behind, if any, based on the source MAC address contained within the UL traffic received on a PDU Session (N3/N9 interface).
The UPF forwards DL unicast traffic (with a known destination address) on a PDU Session determined based on the source MAC address(es) used by the UE for the UL traffic.
The UPF forwards UL unicast traffic (with a known destination address) on a port (PDU Session or N6 interface) determined based on the source MAC address(es) learned beforehand.
In the case of multicast and broadcast traffic (if the destination MAC address is a broadcast or multicast address):
for DL traffic received by UPF on a N6 Network Instance the UPF should forward the traffic to every DL PDU Session (corresponding to any N4 Session) associated with this Network Instance
for uplink traffic received by UPF over a PDU session on a N3/N9 interface, the UPF should forward the traffic to the N6 interface and downlink to every PDU session (except toward the one of the incoming traffic) associated with the same N6 Network Instance
for uplink and downlink unicast traffic received by UPF, if the destination MAC has not been learnt, the UPF should forward the traffic to every PDU session associated with the same N6 Network Instance and towards the N6 interface. In any case the traffic is not replicated on the PDU Session or the N6 interface of the incoming traffic.
if the traffic is received with a VLAN ID, the above criteria apply only towards the N6 interface or PDU session matching the same VLAN ID, unless the UPF is instructed to remove the VLAN ID in the incoming traffic.
if the destination MAC address of traffic refers to the same N6 interface or PDU session on which the traffic has been received, the frame shall be dropped.
In order to handle scenarios where a device behind a UE is moved from a source UE to a target UE, a MAC address is considered as no longer associated with a UPF interface (source UE's PDU session) when the MAC address has not been detected as Source MAC address in UL traffic for a pre-defined period of time or the MAC address has been detected under a different interface (target UE's PDU Session or N6).
For ARP/IPv6 Neighbour Solicitation traffic, a SMF's request to respond to ARP/IPv6 Neighbour Solicitation based on local cache information or to redirect such traffic from the UPF to the SMF overrules the traffic forwarding rules described above.
The SMF may ask to get notified with the source MAC addresses used by the UE, e.g. if the PCF has subscribed to UE MAC address change notifications, as described in TS 23.503.
In order to request the UPF to act as defined above, the SMF may, for each PDU Session corresponding to a Network Instance, set an Ethernet PDU Session Information in a DL PDR that identifies all (DL) Ethernet packets matching the PDU session. Alternatively, for unicast traffic the SMF may provide UPF with dedicated forwarding rules related with MAC addresses notified by the UPF.
The SMF shall support interfaces towards CHF and PCF. The SMF interacts with CHF and PCF based on information received from other control plane NFs and user plane related information received from the UPF.
QoS Flow level, PDU Session level and subscriber related information remain at the SMF, and only usage information is requested from the UPF.
Triggered by the PCC rules received from the PCF or preconfigured information available at SMF, as well as from the CHF for online charging method via quota management mechanisms, the SMF shall provide Usage Reporting Rules to the UPF for controlling how usage reporting is performed.
The SMF shall request the report of the relevant usage information for Usage Monitoring, based on Monitoring Keys and triggers which are specified in TS 23.503. Each Usage Reporting Rule requested for usage monitoring control is associated with the PDR(s) whose traffic is to be accounted under this rule. The SMF shall generate the Usage Reporting Rule for each Monitoring-key within the active PCC Rule(s), either preconfigured or received from the PCF and also shall keep the mapping between them. Multiple Usage Reporting Rules may be associated with the same PDR.
The SMF shall request the report of the relevant usage information for offline and online charging, based on Charging keys and additional triggers which are specified in TS 32.255. Each Usage Reporting Rule requested for offline or online charging is associated with the PDR(s) whose traffic is to be accounted under this rule. The SMF shall generate the Usage Reporting Rule for each Charging key and Sponsor Identity (if applicable) within the active PCC Rule(s), either preconfigured or received from the PCF, and also shall keep the mapping between them. Multiple Usage Reporting Rules may be associated with the same PDR.
The SMF function shall also provide reporting trigger events to the UPF for when to report usage information. The reporting trigger events (e.g. triggers, threshold information etc.) shall be supported for the PDU Session level reporting as well as on Rule level basis as determined by the SMF. The triggers may be provided as a volume, time or event to cater for the different charging/usage monitoring models supported by the TS 23.503 for usage monitoring and by TS 32.255 for converged offline and online charging. The SMF shall decide on the thresholds value(s) based on allowance received from PCF, CHF or based on local configuration. Other parameters for instructing the UPF to report usage information are defined in TS 29.244.
When the PCC Rule attribute Service Data flow handling while requesting credit (specified in TS 23.503) indicates "non-blocking", the SMF shall request the report of the relevant usage information for the Charging key and Sponsor Identity (if applicable) and provide a default threshold value to the UPF while waiting for the quota from the CHF.
In some cases, the same Usage Reporting Rule can be used for different purposes (for both usage monitoring and charging), e.g. in the case that the same set of PDR(s), measurement method, trigger event, threshold, etc. apply. Similarly a reported measurement can be used for different purposes by the SMF.
The UPF shall support reporting of usage information to the SMF. The UPF shall be capable to support reporting based on different triggers, including:
Periodic reporting with period defined by the SMF.
Usage thresholds provided by the SMF.
Report on demand received from the SMF.
The SMF shall make sure that the multiple granularity levels required by the reporting keys in the Usage Reporting rules satisfy the following aggregation levels without requiring a knowledge of the granularity levels by the UPF:
PDU Session level reporting;
Traffic flow (for both charging and usage monitoring) level reporting as defined by the reporting keys in the Usage Reporting Rule (see the description above).
Based on the mapping between Monitoring key and PCC rule stored at the SMF, the SMF shall combine the reported information with session and subscriber related information which is available at the SMF, for Usage Monitoring reporting over the corresponding Npcf interface (N7 reference point).
Based on the mapping between Charging key and Sponsor Identity (if applicable) and PCC rule stored at the SMF, the SMF shall combine the reported information with session and subscriber related information which is available at the SMF, for offline and online charging reporting over the corresponding charging interfaces.
This functionality is specified in TS 32.255.
The usage information shall be collected in the UPF and reported to the SMF as defined in 188.8.131.52, based on Monitoring Keys and triggers which are specified in TS 23.503.
ARP is used for admission control (i.e. retention and pre-emption of the new QoS Flow). The value of ARP is not required to be provided to the UPF.
For every QoS Flow, the SMF shall determine the transport level packet marking value (e.g. the DSCP in the outer IP header) based on the 5QI, the Priority Level (if explicitly signalled) and optionally, the ARP priority level and provide the transport level packet marking value to the UPF.
The SMF shall provide the Session-AMBR values of the PDU Session to the UPF so that the UPF can enforce the Session-AMBR of the PDU Session across all Non-GBR QoS Flows of the PDU Session.
SMF shall provide the GFBR and MFBR value for each GBR QoS Flow of the PDU Session to the UPF. SMF may also provide the Averaging window to the UPF, if Averaging window is not configured at the UPF or if it is different from the default value configured at the UPF.
A predefined PCC rule is configured in the SMF.
The traffic detection filters, e.g. IP Packet Filter, required in the UP function can be configured either in the SMF and provided to the UPF, as service data flow filter(s), or be configured in the UPF, as the application detection filter identified by an application identifier. For the latter case, the application identifier has to be configured in the SMF and the UPF.
The traffic steering policy information can be only configured in the UPF, together with traffic steering policy identifier(s), while the SMF has to be configured with the traffic steering policy identifier(s).
Policies for traffic handling in the UPF, which are referred by some identifiers corresponding to the parameters of a PCC rule, can be configured in the UPF. These traffic handling policies are configured as predefined QER(s), FAR(s) and URR(s).
When a predefined PCC rule is activated/deactivated by the PCF, SMF shall decide what information has to be provided to the UPF to enforce the rule based on where the traffic detection filters (i.e. service data flow filter(s) or application detection filter), traffic steering policy information and the policies used for the traffic handling in the UPF are configured and where they are enforced:
If the predefined PCC rule contains an application identifier for which corresponding application detection filters are configured in the UPF, the SMF shall provide a corresponding application identifier to the UPF;
If the predefined PCC rule contains traffic steering policy identifier(s), the SMF shall provide a corresponding traffic steering policy identifier(s) to the UPF;
If the predefined PCC rule contains service data flow filter(s), the SMF shall provide them to the UPF;
If the predefined PCC rule contains some parameters for which corresponding policies for traffic handling in the UPF are configured in the UPF, the SMF shall activate those traffic handling policies via their rule ID(s).
The SMF shall maintain the mapping between a PCC rule received over Npcf and the flow level PDR rule(s) used on N4 interface.
The application detection filters required in the UPF can be configured either in the SMF and provided to the UPF as the service data flow filter, or be configured in the UP function identified by an application identifier.
When receiving a dynamic PCC rule from the PCF which contains an application identifier and/or parameters for traffic handling in the UPF:
if the application detection filter is configured in the SMF, the SMF shall provide it in the service data flow filter to the UPF, as well as parameters for traffic handling in the UPF received from the dynamic PCC rule;
otherwise, the application detection filters is configured in UPF, the SMF shall provide to UPF with the application identifier and the parameters for traffic handling in the UPF as required based on the dynamic PCC rule.
The SMF shall maintain the mapping between a PCC rule received over Npcf and the flow level PDR(s) used on N4 interface.
The uplink application's traffic redirection may be enforced either in the SMF (as specified in 184.108.40.206 Control of user plane forwarding) or directly in the UPF. The redirect destination may be provided in the dynamic PCC rule or be preconfigured, either in the SMF or in the UPF.
When receiving redirect information (redirection enabled/disabled and redirect destination) within a dynamic PCC rule or being activated/deactivated by the PCF for the predefined redirection policies, SMF shall decide whether to provide and what information to be provided to the UPF based on where the redirection is enforced and where the redirect destination is acquired/preconfigured. When redirection is enforced in the UPF and the redirect destination is acquired from the dynamic PCC rule or is configured in the SMF, SMF shall provide the redirect destination to the UPF. When redirection is enforced in the SMF, SMF shall instruct the UPF to forward applicable user plane traffic to the SMF.
The NEF (PFDF)shall provide PFD(s) to the SMF on the request of SMF (pull mode) or on the request of PFD management from NEF (push mode), as described in TS 23.503. The SMF shall provide the PFD(s) to the UPF, which have active PDR(s) with the application identifier corresponding to the PFD(s).
The SMF supports the procedures in clause 220.127.116.11 of TS 23.502, for management of PFDs. PFD(s) is cached in the SMF, and the SMF maintains a caching timer associated to the PFD(s). When the caching timer expires and there's no active PCC rule that refers to the corresponding application identifier, the SMF informs the UPF to remove the PFD(s) identified by the application identifier using the PFD management message.
When a PDR is provided for an application identifier corresponding to the PFD(s) that are not already provided to the UPF, the SMF shall provide the PFD(s) to the UPF (if there are no PFD(s) cached, the SMF retrieves them from the NEF (PFDF) as specified in TS 23.503). When any update of the PFD(s) is received from NEF (PFDF) by SMF (using "push" or "pull" mode), and there are still active PDRs in UPF for the application identifier, the SMF shall provision the updated PFD set corresponding to the application identifier to the UPF using the PFD management message.
When the UPF receives the updated PFD(s) from either the same or different SMF for the same application identifier, the latest received PFD(s) shall overwrite any existing PFD(s) stored in the UPF.
When a PFD is removed/modified and this PFD was used to detect application traffic related to an application identifier in a PDR of an N4 session and the UPF has reported the application start to the SMF as defined in clause 18.104.22.168 of TS 23.502 for the application instance corresponding to this PFD, the UPF shall report the application stop to the SMF for the corresponding application instance identifier if the removed/modified PFD in UPF results in that the stop of the application instance is not being able to be detected.
If the PFDs are managed by local O&M procedures, PFD retrieval is not used; otherwise, the PFDs retrieved from NEF (PFDF) override any PFDs pre-configured in the SMF. When all the PFDs retrieved from the NEF (PFDF) for an application identifier are removed, the pre-configured PFDs are used. The SMF shall provide either the PFDs retrieved from NEF (PFDF) or the pre-configured PFDs for an application identifier to the UPF.
Sending of "end marker" is a functionality which involve SMF and UPF in order to assist the reordering function in the Target RAN. As part of the functionality, constructing of end marker packets can either be done in the SMF or in the UPF, as described in clauses 22.214.171.124.1 and 126.96.36.199.2. Whether constructing of end marker packets is performed by SMF or UPF is determined by network configuration.
In the case of inter NG-RAN Handover procedure without UPF change, SMF shall indicate the UPF to switch the N3 path(s) by sending an N4 Session Modification Request message with the new AN Tunnel Info of NG RAN and in addition, provide an indication to the UPF to send the end marker packet(s) on the old N3 user plane path.
On receiving this indication, the UPF shall construct end marker packet(s) and send it for each N3 GTP-U tunnel towards the source NG RAN after sending the last PDU on the old path.
In the case of inter NG-RAN Handover procedure with change of the UPF terminating N3, the SMF shall request the UPF with N9 reference point to the UPF terminating N3 to switch the N9 user plane path(s) by sending an N4 Session Modification Request message (N4 session ID, new CN Tunnel Info of the UPF terminating N3) and in addition, provide an indication to this UPF to send the end marker packet(s) on the old path.
On receiving this indication, the UPF shall construct end marker packet(s) and send it for each N9 GTP-U tunnel towards the source UPF after sending the last PDU on the old path.
On receiving the end marker packet(s) on N9 GTP-U tunnel, source UPF shall forward the end marker packet(s) and send it for each N3 GTP-U tunnel towards the source NG RAN.
UPF referred in this clause is the UPF terminates N3 reference point.
It is assumed that the PDU Session for the UE comprises of an UPF that acts as a PDU Session Anchor and an intermediate UPF terminating N3 reference point at the time of this Handover procedure.
In the case of inter NG-RAN Handover procedure without UPF change, SMF shall indicate the UPF to switch the N3 path(s) by sending an N4 Session Modification Request message (N4 session ID, new AN Tunnel Info of NG RAN). After sending the last PDU on the old path, UPF shall replace the old AN Tunnel Info with the new one and responds with an N4 Session Modification Response message to acknowledge the success of path switch.
When the path switch is finished, SMF constructs the end marker packet(s) and sends it to the UPF. UPF then forwards the packet(s) to the source NG RAN.
In the case of inter NG-RAN Handover procedure with UPF change, SMF shall indicate the PSA UPF to switch the N9 user plane path(s) by sending an N4 Session Modification Request message (N4 session ID, new CN Tunnel Info of UPF). After sending the last PDU on the old N9 path, PSA UPF shall replace the old CN Tunnel Info with the new one and responds with an N4 Session Modification Response message to acknowledge the success of path switch.
When the path switch is finished, SMF constructs the end marker packet(s) and sends it to PSA UPF. PSA UPF then forwards the packet(s) to the source UPF.
5GC shall support per PDU Session tunnelling on N3 between (R)AN and UPF and N9 between UPFs. If there exist more than one UPF involved for the PDU Session, any tunnel(s) between UPFs (e.g. in the case of two UPFs, between the UPF that is an N3 terminating point and the UPF for PDU Session Anchor) remains established when a UE enters CM-IDLE state. In the case of downlink data buffering by UPF, when mobile terminated (MT) traffic arrives at the PDU Session Anchor UPF, it is forwarded to the UPF which buffer the data packet via N9 tunnel. See clause 5.8.3 for more details on UPF buffering. In the case of Home Routed roaming, the SMF in HPLMN is not aware of the UP activation state of a PDU Session.
When the UP connection of the PDU Session is deactivated, the SMF may release the UPF of N3 terminating point. In that case the UPF (e.g. the Branching Point/UL CL or PDU Session Anchor) connecting to the released UPF of N3 terminating point will buffer the DL packets. Otherwise, when the UPF with the N3 connection is not released, this UPF will buffer the DL packets.
When the UP connection of the PDU Session is activated due to a down-link data arrived and a new UPF is allocated to terminate the N3 connection, a data forwarding tunnel between the UPF that has buffered packets and the newly allocated UPF is established, so that the buffered data packets are transferred from the old UPF that has buffered packets to the newly allocated UPF via the data forwarding tunnel.
For a PDU Session whose the UP connection is deactivated and the SMF has subscribed the location change notification, when the SMF is notified of UE's new location from the AMF and detects that the UE has moved out of the service area of the existing intermediate UPF, the SMF may decide to maintain the intermediate UPF, remove the established tunnel between UPFs (in the case of removal of the intermediate UPF) or reallocate the tunnel between UPFs (in the case of reallocation of the intermediate UPF).