Content for  TS 23.501  Word version:  19.1.0

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. The UE shall perform the association of the application to a new PDU Session described in clause 6.1.2.2.1 of TS 23.503, with the following considerations:

• If there is a matching URSP rule, except the URSP rule with the "match all" Traffic descriptor, 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 Detailed operation is described in TS 24.526.
• Otherwise, if a URSP Rule with the "match all" Traffic descriptor exists, the UE shall set the requested PDU Session Type to the PDU Session Type contained in the "match all" URSP Rule, if this PDU Session Type is supported by the UE's IP stack capabilities. Detailed operation is described in TS 24.526.
• Otherwise, 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:

1. 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.
2. /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 5.8.2.2.3. IPv6 parameter configuration via Stateless DHCPv6 (according to RFC 8415) may also be supported. IPv6 Prefix Delegation using DHCPv6 may be supported for allocating additional IPv6 prefixes for a PDU Session. The details of Prefix Delegation are described in clause 5.8.2.2.4.

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. 5GC may support the provisioning of a static IPv4 address and/or a static IPv6 prefix in the subscription information in the UDM based on NEF Parameter Provision service as described in clause 4.15.6.5 of TS 23.502. 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. If the SMF is notified by UDM that the subscription data has changed, and SMF detects that the static IP address/prefix in the subscription data is added, removed or modified, the SMF may trigger a release of the PDU Session and includes a cause value indicating that a PDU Session re-establishment is requested, as described in clause 4.3.4 of TS 23.502. 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. UPF may use NAT between the UE and the Data Network, and thus the 5GC allocated (private) UE IP address may not be visible on the N6 reference point.

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 4.3.2.2.1 and 4.3.2.2.2 of TS 23.502, using the Mobile Terminated Data Transport in Control Plane CIoT 5GS Optimisation procedures.

Optionally, a single network prefix shorter than the default /64 prefix may be assigned to a PDU Session. In this case, the /64 default prefix used for IPv6 stateless autoconfiguration will be allocated from this network prefix; the remaining address space from the network prefix can be delegated to the PDU Session using prefix delegation after the PDU Session establishment and IPv6 prefix allocation via IPv6 stateless address autoconfiguration as defined in clause 5.8.2.2.3. Depending on configuration, the SMF may obtain the prefix from a locally provisioned pool, from the PSA UPF or from the external DN. The address space provided is maintained as an IPv6 address space pool available to the PDU Session for DHCPv6 IPv6 prefix requests with the exclusion of the IPv6 prefix that is allocated to the PDU Session during PDU Session establishment as defined in clause 5.8.2.2.3. The total IPv6 address space available for the PDU Session (UE PDU Session prefix and UE PDU Session IPv6 address space pool) shall be possible to aggregate into one IPv6 prefix that will represent all IPv6 addresses that the UE may use. If the UE had indicated that it supports prefix exclusion and the prefix to be delegated to the UE includes the /64 prefix that was allocated to the PDU Session, the SMF shall utilise the prefix exclusion feature as specified for DHCPv6 Prefix Delegation in RFC 6603. The UE uses DHCPv6 to request additional IPv6 prefixes (i.e. prefixes in addition to the default prefix) from the SMF after completing stateless IPv6 address autoconfiguration procedures. The UE acts as a "Requesting Router" as described in RFC 8415 and inserts one or more IA_PD option(s) into a DHCPv6 Solicit message sent from the UE to the SMF via the user plane and the UPF. The SMF acts as the DHCP server and fulfils the role of a "Delegating Router" according to RFC 8415. The UE optionally includes the RAPID_COMMIT option in the DHCPv6 Solicit message to trigger two-message DHCPv6 procedure instead of the four-message DHCPv6 procedure. The UE shall include OPTION_PD_EXCLUDE option code in an OPTION_ORO option to indicate support for prefix exclusion. In response to the DHCPv6 Solicit message, the UE receives a DHCPv6 Reply message with one or more IA_PD prefix(es) for every IA_PD option that it sent in the DHCPv6 Solicit message. The SMF delegates a prefix excluding the default prefix with help of OPTION_PD_EXCLUDE. Prefix exclusion procedures shall follow RFC 6603. For scenarios with RG connecting to 5GC, additional feature for IPv6 Prefix Delegation via DHCPv6 is defined in TS 23.316.

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.

The SMF controls the traffic detection at the UP function by providing detection information for every PDR. For IPv4 or IPv6 or IPv4v6 PDU Session type, detection information is a combination of:

• CN tunnel info.
• Network instance.
• QFI.
• IP Packet Filter Set as defined in clause 5.7.6.2.
• Application Identifier: The Application Identifier is an index to a set of application detection rules configured in UPF.
• FQDN Filter for DNS Query message.

For Ethernet PDU Session type, detection information is a combination of:

• CN tunnel info.
• Network instance.
• QFI.
• Ethernet Packet Filter Set as defined in clause 5.7.6.3.

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.

The SMF controls user-plane packet forwarding for traffic detected by a PDR by providing a FAR with instructions to the UPF, including:

• Forwarding operation information;
• Forwarding target information.

The details of the forwarding target and operation will depend on the scenario and is described below. The following forwarding functionality is required by the UPF:

• Apply N3 /N9 tunnel related handling, i.e. encapsulation.
• Forward the traffic to/from the SMF, e.g. as described in Table 5.8.2.5.2-1.
• Forward the SM PDU DN Request Container from SMF to DN-AAA server
• Forward the traffic according to locally configured policy for traffic steering.
• Forward the traffic according to N4 rules of a 5G VN group for 5G VN group communication.
• Forward the traffic to/from the EASDF.

Data forwarding between the SMF and UPF is transmitted on the user plane tunnel established on N4 interface, defined in TS 29.244.

Scenarios for data forwarding between the SMF and UPF are defined as below:

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 5.8.2.6, based on Monitoring Keys and triggers which are specified in TS 23.503.

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 5.8.2.5 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. In addition, the NEF (PFDF) may subscribe to NWDAF to be notified or request to get PFD "Determination analytics" for known applications (as specified in TS 23.288) and may decide whether to create, update, or delete PFD(s) based on the NWDAF analytics as specified 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 4.4.3.5 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 4.4.2.2 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 5.8.2.9.1 and 5.8.2.9.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.