5.8 User Plane Management

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

5.8.1 General

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

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

5.8.2 Functional Description

5.8.2.1 General

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.

5.8.2.2 UE IP Address Management

5.8.2.2.1 General

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:

a. 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 [9]) can also be used once PDU Session is established.

b. /64 IPv6 prefix allocation shall be supported via IPv6 Stateless Auto-configuration according to RFC 4862 [10], 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 3736 [14]) 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 [84].

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.

NOTE: The IP Index can e.g. be used to select between different IP pools, including between IP pools with overlapping private address range. To support deployments with overlapping private IPv4 address, the IP domain corresponding to IP index can also be provided from UDM to SMF as part of the subscription data and then provided to 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.

5.8.2.2.2 Routing rules configuration

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 [45]. 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 [8] at any time during the lifetime of the IPv6 multi-homed PDU Session. Such messages are sent via the UPF.

NOTE: For multiple IPv4 PDU Session and multiple IPv6 PDU Session cases, routing rule based PDU Session selection is not specified in this Release of the specification.

5.8.2.2.3 The procedure of Stateless IPv6 Address Autoconfiguration

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 [10]. 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 [10]) 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 [19] 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 [23] 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 [54]. 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 [3], using the Mobile Terminated Data Transport in Control Plane CIoT 5GS Optimisation procedures.

5.8.2.3 Management of CN Tunnel Info

5.8.2.3.1 General

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.

5.8.2.3.2 Void

5.8.2.3.3 Management of CN Tunnel Info in the UPF

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.

5.8.2.4 Traffic Detection

5.8.2.4.1 General

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.

5.8.2.4.2 Traffic 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.

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.

5.8.2.5 Control of User Plane Forwarding

5.8.2.5.1 General

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

5.8.2.5.2 Data forwarding between the SMF and UPF

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

Table 5.8.2.5.2-1: Scenarios for data forwarding between the SMF and UPF

	Scenario description	Data forwarding direction
1	Forwarding of user-plane packets between the UE and the SMF e.g. DHCP signalling.	UPF to SMF SMF to UPF
2	Forwarding of packets between the SMF and the external DN e.g. with DN-AAA server	UPF to SMF SMF to UPF
3	Forwarding of packets subject to buffering in the SMF.	UPF to SMF SMF to UPF
4	Forwarding of End Marker Packets constructed by the SMF to a downstream node.	SMF to UPF
5	Forwarding of user data using Control Plane CIoT 5GS Optimisation	UPF to SMF SMF to UPF

5.8.2.5.3 Support of Ethernet PDU Session type

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.

NOTE 1: The UPF can consider a PDU Session or a N6 interface to be active or inactive in order to avoid forwarding loops. User data traffic is not sent on inactive PDU sessions or inactive N6 interface. This release of the specification does not further specify how the UPF determines whether a PDU Session or N6 interface is considered active or inactive.

NOTE 2: This release of the specification supports only a single N6 interface in a UPF associated with the N6 Network Instance.

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

NOTE 3: This release of the specification supports Independent VLAN Learning (IVL) and does not support Shared VLAN Learning (SVL), as described in IEEE Std 802.1Q [98].

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

NOTE 4: The UPF/NW-TT may also be provided with static filtering entries as described in clause 5.28.3. How the UPF uses the static filtering entry to achieve forwarding of Ethernet frames to one or more egress ports is up to UPF implementation. The externally observable behaviour of 5GS Bridge needs to comply with IEEE Std 802.1Q [98].

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.

NOTE 5: Local policies in UPF associated with the Network Instance can prevent local traffic switching in the UPF between PDU Sessions either for unicast traffic only or for any traffic. In the case where UPF policies prevent local traffic switching for any traffic (thus for broadcast/multicast traffic) some mechanism such as responding to ARP/ND based on local cache information or local multicast group handling is needed to ensure that upper layer protocol can run on the Ethernet PDU sessions.

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

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.

5.8.2.6 Charging and Usage Monitoring Handling

5.8.2.6.1 General

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.

5.8.2.6.2 Activation of Usage Reporting in 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 [45]. 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 [68]. 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 [45] for usage monitoring and by TS 32.255 [68] 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 [65].

When the PCC Rule attribute Service Data flow handling while requesting credit (specified in TS 23.503 [45]) 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.

5.8.2.6.3 Reporting of Usage Information towards 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 [68].

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

5.8.2.7 PDU Session and QoS Flow Policing

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.

5.8.2.8 PCC Related Functions

5.8.2.8.1 Activation/Deactivation of predefined PCC rules

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.

5.8.2.8.2 Enforcement of Dynamic PCC Rules

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.

5.8.2.8.3 Redirection

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.

5.8.2.8.4 Support of PFD Management

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 [45]. 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 [3], 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 [45]). 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.

NOTE 1: SMF can assure not to overload N4 signalling while managing PFD(s) to the UPF, e.g. forwarding the PFD(s) to the right UPF where the PFD(s) is enforced.

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.

NOTE 2: For the case a single UPF is controlled by multiple SMFs, the conflict of PFD(s) corresponding to the same application identifier provided by different SMF can be avoided by operator enforcing a well-planned NEF (PFDF) and SMF/UPF deployment.

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

5.8.2.9 Functionality of Sending of "End marker"

5.8.2.9.0 Introduction

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.

5.8.2.9.1 UPF Constructing the "End marker" Packets

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.

5.8.2.9.2 SMF Constructing the "End marker" Packets

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.

5.8.2.10 UP Tunnel Management

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

5.8.2.11 Parameters for N4 session management

5.8.2.11.1 General

These parameters are used by SMF to control the functionality of the UPF as well as to inform SMF about events occurring at the UPF.

The N4 session management procedures defined in clause 4.4.1 of TS 23.502 [3] will use the relevant parameters in the same way for all N4 reference points: the N4 Session Establishment procedure as well as the N4 Session Modification procedure provide the control parameters to the UPF, the N4 Session Release procedure removes all control parameters related to an N4 session, and the N4 Session Level Reporting procedure informs the SMF about events related to the PDU Session that are detected by the UPF.

The parameters over N4 reference point provided from SMF to UPF comprises an N4 Session ID and may also contain:

– Packet Detection Rules (PDR) that contain information to classify traffic (PDU(s)) arriving at the UPF;

– Forwarding Action Rules (FAR) that contain information on whether forwarding, dropping or buffering is to be applied to a traffic identified by PDR(s);

– Multi-Access Rules (MAR) that contain information on how to handle traffic steering, switching and splitting for a MA PDU Session;

– Usage Reporting Rules (URR) contains information that defines how traffic identified by PDR(s) shall be accounted as well as how a certain measurement shall be reported;

– QoS Enforcement Rules (QER), that contain information related to QoS enforcement of traffic identified by PDR(s);

– Session Reporting Rules (SRR) that contain information to request the UP function to detect and report events for a PDU session that are not related to specific PDRs of the PDU session or that are not related to traffic usage measurement.

– Trace Requirements;

– Port Management Information Container in 5GS;

– Bridge Information.

The N4 Session ID is assigned by the SMF and uniquely identifies an N4 session.

If the UPF indicated support of Trace, the SMF may activate a trace session during a N4 Session Establishment or a N4 Session Modification procedure. In that case it provides Trace Requirements to the UPF. The SMF may deactivate an on-going trace session using a N4 Session Modification procedure. There shall be at most one trace session activated per N4 Session at a time.

For the MA PDU Session, the SMF may add an additional access tunnel information during an N4 Session Modification procedure by updating MAR with addition of an FAR ID which refers to an FAR containing the additional access tunnel information for the MA PDU session for traffic steering in the UPF. For the MA PDU Session, the SMF may request Access Availability report per N4 Session, during N4 Session Establishment procedure or N4 Session Modification procedure.

A N4 Session may be used to control both UPF and NW-TT behaviour in the UPF. A N4 session support and enable exchange of TSN bridge configuration between the SMF and the UPF:

– Information that the SMF needs for bridge management (clause 5.8.2.11.9);

– Information that 5GS transparently relays between the TSN AF or NEF and the NW-TT: transparent Port Management Information Container along with the associated NW-TT port number.

– Information that 5GS transparently relays between the TSN AF or NEF and the NW-TT: transparent user plane node Management Information Container (clause 5.8.2.11.14).

When a N4 Session related with bridge management is established, the UPF allocates a dedicated port number for the DS-TT side of the PDU Session. The UPF then provides to the SMF following configuration parameters for the N4 Session:

– DS-TT port number.

– user-plane node ID.

To support TSN, the user-plane node ID is Bridge ID. The User Plane Node ID/Bridge ID may be pre-configured in the UPF based on deployment.

After the N4 session has been established, the SMF and UPF may at any time exchange transparent user plane node and Port Management Information Container over a N4 session.

5.8.2.11.2 N4 Session Context

N4 Session Context is identified by an N4 Session ID. An N4 Session Context is generated by SMF and UPF respectively to store the parameters related to an N4 session, including the N4 session ID and following information (see TS 29.244 [65] for an exhaustive list):

1) general session related parameters such as S-NSSAI, PDU Session Type, Trace Information, APN/DNN, ATSSS Control Information;

2) the PDRs, URRs, QERs, BAR(s), FARs, MARs used for this N4 session;

3) parameters sent to support UPF statistics.

The UPF may use parameters listed above in bullets 1) (e.g. S-NSSAI) and 2) (e.g. Network Instance in PDR/FAR(s)) for determining internal UPF resources.

5.8.2.11.3 Packet Detection Rule

The following table describes the Packet Detection Rule (PDR) containing information required to classify a packet arriving at the UPF. Every PDR is used to detect packets in a certain transmission direction, e.g. UL direction or DL direction.

Table 5.8.2.11.3-1: Attributes within Packet Detection Rule

Attribute		Description	Comment
N4 Session ID		Identifies the N4 session associated to this PDR. NOTE 5.
Rule ID		Unique identifier to identify this rule.
Precedence		Determines the order, in which the detection information of all rules is applied.
Packet	Source interface	Contains the values "access side", "core side", "SMF", "N6-LAN", "5G VN internal".	Combination of UE IP address (together with Network instance, if necessary), CN tunnel info,
Detection	UE IP address	One IPv4 address and/or one IPv6 prefix with prefix length (NOTE 3).	packet filter set, application identifier, Ethernet PDU Session
Information. NOTE 4.	Network instance (NOTE 1)	Identifies the Network instance associated with the incoming packet.	Information and QFI are used for traffic detection. Source interface identifies the
	CN tunnel info	CN tunnel info on N3, N9 interfaces, i.e. F-TEID.	interface for incoming packets
	Packet Filter Set	Details see clause 5.7.6.	where the PDR applies, e.g. from access side (i.e. up-link),
	Application identifier		from core side (i.e. down-link),
	QoS Flow ID	Contains the value of 5QI or non-standardized QFI.	from SMF, from N6-LAN (i.e. the
	Ethernet PDU Session Information	Refers to all the (DL) Ethernet packets matching an Ethernet PDU session, as further described in clause 5.6.10.2 and in TS 29.244 [65].	DN), or from "5G VN internal" (i.e. local switch).
	Framed Route Information	Refers to Framed Routes defined in clause 5.6.14.	Details like all the combination possibilities on N3, N9 interfaces are left for stage 3 decision.
Packet replication and detection carry on information	Packet replication skip information NOTE 7	Contains UE address indication or N19/N6 indication. If the packet matches the packet replication skip information, i.e. source address of the packet is the UE address or the packet has been received on the interface in the packet replication skip information, the UP function neither creates a copy of the packet nor applies the corresponding processing (i.e. FAR, QER, URR). Otherwise the UPF performs a copy and applies the corresponding processing (i.e. FAR, QER, URR).
NOTE 6	Carry on indication	Instructs the UP function to continue the packet detection process, i.e. lookup of the other PDRs.
Outer header removal		Instructs the UP function to remove one or more outer header(s) (e.g. IP+UDP+GTP, IP + possibly UDP, VLAN tag), from the incoming packet.	Any extension header shall be stored for this packet.
Forwarding Action Rule ID (NOTE 2)		The Forwarding Action Rule ID identifies a forwarding action that has to be applied.
Multi-Access Rule ID (NOTE 2)		The Multi-Access Rule ID identifies an action to be applied for handling forwarding for a MA PDU Session.
List of Usage Reporting Rule ID(s)		Every Usage Reporting Rule ID identifies a measurement action that has to be applied.
List of QoS Enforcement Rule ID(s)		Every QoS Enforcement Rule ID identifies a QoS enforcement action that has to be applied.
NOTE 1: Needed e.g. if: – UPF supports multiple DNN with overlapping IP addresses; – UPF is connected to other UPF or AN node in different IP domains. – UPF "local switch", N6-based forwarding and N19 forwarding is used for different 5G LAN groups. NOTE 2: Either a FAR ID or a MAR ID is included, not both. NOTE 3: The SMF may provide an indication asking the UPF to allocate one IPv4 address and/or IPv6 prefix. When asking to provide an IPv6 Prefix the SMF provides also an IPv6 prefix length. NOTE 4: When in the architecture defined in clause 5.34, a PDR is sent over N16a from SMF to I-SMF, the Packet Detection Information may indicate that CN tunnel info is to be locally determined. This is further defined in clause 5.34.6. NOTE 5: In the architecture defined in clause 5.34, the rules exchanged between I-SMF and SMF are not associated with a N4 Session ID but are associated with a N16a association. NOTE 6: Needed in the case of support for broadcast/multicast traffic forwarding using packet replication with SMF-provided PDRs and FARs as described in clause 5.8.2.13.3.2. NOTE 7: Needed in the case of packet replication with SMF-provided PDRs and FARs as described in clause 5.8.2.13.3.2, to prevent UPF from sending the broadcast/multicast packets back to the source UE or source N19/N6.

5.8.2.11.4 QoS Enforcement Rule

The following table describes the QoS Enforcement Rule (QER) that defines how a packet shall be treated in terms of bit rate limitation and packet marking for QoS purposes. All Packet Detection Rules that refer to the same QER share the same QoS resources, e.g. MFBR.

Table 5.8.2.11.4-1: Attributes within QoS Enforcement Rule

Attribute	Description	Comment
N4 Session ID	Identifies the N4 session associated to this QER
Rule ID	Unique identifier to identify this information.
QoS Enforcement Rule correlation ID (NOTE 1)	An identity allowing the UP function to correlate multiple Sessions for the same UE and APN.	Is used to correlate QoS Enforcement Rules for APN-AMBR enforcement.
Gate status UL/DL	Instructs the UP function to let the flow pass or to block the flow.	Values are: open, close, close after measurement report (for termination action "discard").
Maximum bitrate	The uplink/downlink maximum bitrate to be enforced for the packets.	This field may e.g. contain any one of: – APN-AMBR (for a QER that is referenced by all relevant Packet Detection Rules of all PDN Connections to an APN) (NOTE 1). – Session-AMBR (for a QER that is referenced by all relevant Packet Detection Rules of the PDU Session) – QoS Flow MBR (for a QER that is referenced by all Packet Detection Rules of a QoS Flow) – SDF MBR (for a QER that is referenced by the uplink/downlink Packet Detection Rule of a SDF) – Bearer MBR (for a QER that is referenced by all relevant Packet Detection Rules of a bearer) (NOTE 1).
Guaranteed bitrate	The uplink/downlink guaranteed bitrate authorized for the packets.	This field contains: – QoS Flow GBR (for a QER that is referenced by all Packet Detection Rules of a QoS Flow) – Bearer GBR (for a QER that is referenced by all relevant Packet Detection Rules of a bearer) (NOTE 1).
Averaging window	The time duration over which the Maximum and Guaranteed bitrate shall be calculated.	This is for counting the packets received during the time duration.
Down-link flow level marking	Flow level packet marking in the downlink.	For UPF, this is for controlling the setting of the RQI in the encapsulation header as described in clause 5.7.5.3.
QoS Flow ID	QoS Flow ID to be inserted by the UPF.	The UPF inserts the QFI value in the tunnel header of outgoing packets.
Paging Policy Indicator	Indicates the PPI value the UPF is required to insert in outgoing packets (see clause 5.4.3.2).	PPI applies only for DL traffic. The UPF inserts the PPI in the outer header of outgoing PDU.
Packet rate (NOTE 1)	Number of packets per time interval to be enforced.	This field contains any one of: – downlink packet rate for Serving PLMN Rate Control (the QER is referenced by all PDRs of the UE belonging to PDN connections using CIoT EPS Optimisations as described in TS 23.401 [26]). – uplink/downlink packet rate for APN Rate Control (the QER is referenced by all PDRs of the UE belonging to PDN connections to the same APN using CIoT EPS Optimisations as described in TS 23.401 [26]).
NOTE 1: This parameter is only used for interworking with EPC.

5.8.2.11.5 Usage Reporting Rule

The following table describes the Usage Reporting Rule (URR) that defines how a packet shall be accounted as well as when and how to report the measurements.

Table 5.8.2.11.5-1: Attributes within Usage Reporting Rule

Attribute	Description	Comment
N4 Session ID	Identifies the N4 session associated to this URR
Rule ID	Unique identifier to identify this information.	Used by UPF when reporting usage.
Reporting triggers	One or multiple of the events can be activated for the generation and reporting of the usage report.	Applicable events include: – Start/stop of traffic detection with/without application instance identifier and deduced SDF filter reporting; Deletion of last PDR for a URR; Periodic measurement threshold reached; Volume/Time/Event measurement threshold reached; Immediate report requested; Measurement of incoming UL traffic; Measurement of discarded DL traffic; MAC address reporting in the UL traffic; unknown destination MAC/IP address; end marker packet has been received.
Periodic measurement threshold	Defines the point in time for sending a periodic report for this URR (e.g. timeofday).	This allows generation of periodic usage report for e.g. offline charging. It can also be used for realizing the Monitoring time of the usage monitoring feature. It can also be used for realizing the Quota-Idle-Timeout, i.e. to enable the CP function to check whether any traffic has passed during this time.
Volume measurement threshold	Value in terms of uplink and/or downlink and/or total byte-count when the measurement report is to be generated.
Time measurement threshold	Value in terms of the time duration (e.g. in seconds) when the measurement report is to be generated.
Event measurement threshold	Number of events (identified according to a locally configured policy) after which the measurement report is to be generated.
Inactivity detection time	Defines the period of time after which the time measurement shall stop, if no packets are received.	Timer corresponding to this duration is restarted at the end of each transmitted packet.
Event based reporting	Points to a locally configured policy which is identifies event(s) trigger for generating usage report.
Linked URR ID(s)	Points to one or more other URR ID.	This enables the generation of a combined Usage Report for this and other URRs by triggering their reporting. See clause 5.2.2.4, TS 29.244 [65].
Measurement Method	Indicates the method for measuring the network resources usage, i.e. the data volume, duration, combined volume/duration, or event.
Measurement information	Indicates specific conditions to be applied for measurements	It is used to request: – measurement before QoS enforcement, and/or – to pause or set to active a measurement as for the Pause of charging described in clause 4.4.4 and clause 4.23.14 of TS 23.502 [3], and/or – to request reduced reporting for application start/stop events.

5.8.2.11.6 Forwarding Action Rule

The following table describes the Forwarding Action Rule (FAR) that defines how a packet shall be buffered, dropped or forwarded, including packet encapsulation/decapsulation and forwarding destination.

Table 5.8.2.11.6-1: Attributes within Forwarding Action Rule

Attribute	Description	Comment
N4 Session ID	Identifies the N4 session associated to this FAR.	NOTE 9.
Rule ID	Unique identifier to identify this information.
Action	Identifies the action to apply to the packet	Indicates whether the packet is to be forwarded, duplicated, dropped or buffered. When action indicates forwarding or duplicating, a number of additional attributes are included in the FAR. For buffering action, a Buffer Action Rule is also included and the action can also indicate that a notification of the first buffered and/or a notification of first discarded packet is requested (see clause 5.8.3.2). For drop action, a notification of the discarded packet may be requested (see clause 5.8.3.2).
Network instance (NOTE 2)	Identifies the Network instance associated with the outgoing packet (NOTE 1).	NOTE 8.
Destination interface (NOTE 3) (NOTE 7)	Contains the values "access side", "core side", "SMF", "N6-LAN", "5G VN internal".	Identifies the interface for outgoing packets towards the access side (i.e. down-link), the core side (i.e. up-link), the SMF, the N6-LAN (i.e. the DN), or to 5G VN internal (i.e. local switch).
Outer header creation (NOTE 3)	Instructs the UP function to add an outer header (e.g. IP+UDP+GTP, VLAN tag), IP + possibly UDP to the outgoing packet.	Contains the CN tunnel info, N6 tunnel info or AN tunnel info of peer entity (e.g. NG-RAN, another UPF, SMF, local access to a DN represented by a DNAI) (NOTE 8). Any extension header stored for this packet shall be added. The time stamps should be added in the GTP-U header if QoS Monitoring is enabled for the traffic corresponding to the PDR(s).
Send end marker packet(s) (NOTE 2)	Instructs the UPF to construct end marker packet(s) and send them out as described in clause 5.8.1.	This parameter should be sent together with the "outer header creation" parameter of the new CN tunnel info.
Transport level marking (NOTE 3)	Transport level packet marking in the uplink and downlink, e.g. setting the DiffServ Code Point.	NOTE 8.
Forwarding policy (NOTE 3)	Reference to a preconfigured traffic steering policy or http redirection (NOTE 4).	Contains one of the following policies identified by a TSP ID: – an N6-LAN steering policy to steer the subscriber’s traffic to the appropriate N6 service functions deployed by the operator, or – a local N6 steering policy to enable traffic steering in the local access to the DN according to the routing information provided by an AF as described in clause 5.6.7. or a Redirect Destination and values for the forwarding behaviour (always, after measurement report (for termination action "redirect")).
Request for Proxying in UPF	Indicates that the UPF shall perform ARP proxying and / or IPv6 Neighbour Solicitation Proxying as specified in clause 5.6.10.2.	Applies to the Ethernet PDU Session type.
Container for header enrichment (NOTE 2)	Contains information to be used by the UPF for header enrichment.	Only relevant for the uplink direction.
Buffering Action Rule (NOTE 5)	Reference to a Buffering Action Rule ID defining the buffering instructions to be applied by the UPF (NOTE 6)
NOTE 1: Needed e.g. if: – UPF supports multiple DNN with overlapping IP addresses; – UPF is connected to other UPF or NG-RAN node in different IP domains; – UPF "local switch" and N19 forwarding is used for different 5G LAN groups. NOTE 2: These attributes are required for FAR action set to forwarding. NOTE 3: These attributes are required for FAR action set to forwarding or duplicating. NOTE 4: The TSP ID is preconfigured in the SMF, and included in the FAR according to the description in clauses 5.6.7 and 6.1.3.14 of 23.503 [45] for local N6 steering and 6.1.3.14 of 23.503 [45] for N6-LAN steering. The TSP ID action is enforced before the Outer header creation actions. NOTE 5: This attribute is present for FAR action set to buffering. NOTE 6: The buffering action rule is created by the SMF and associated with the FAR in order to apply a specific buffering behaviour for UL/DL packets requested to be buffered, as described in clause 5.8.3 and clause 5.2.4 of TS 29.244 [65]. NOTE 7: The use of "5G VN internal" instructs the UPF to send the packet back for another round of ingress processing using the active PDRs pertaining to another N4 session of the same 5G VN group. NOTE 8: When in architectures defined in clause 5.34, a FAR is sent over N16a from SMF to I-SMF, the FAR sent by the SMF may indicate that the I-SMF is to locally determine the value of this attribute in order to build the N4 FAR rule sent to the actual UPF controlled by the I-SMF. This is further defined in clause 5.34.6. NOTE 9: In the architecture defined in clause 5.34, the rules exchanged between I-SMF and SMF are not associated with a N4 Session ID but are associated with a N16a association.

5.8.2.11.7 Usage Report generated by UPF

The UPF sends the Usage Report to inform the SMF about the measurement of an active URR or about the detection of application traffic of an active Packet Detection Rule. For each URR, the Usage Report may be generated repeatedly, i.e. as long as any one of the valid event triggers applies. A final Usage Report is sent for a URR when it is no longer active, i.e. either the URR is removed or all the references to this URR in any of the Packet Detection Rules belonging to the N4 session.

The following attributes can be included:

Table 5.8.2.11.7-1: Attributes within Usage Report

Attribute	Description	Comment
N4 Session ID	Uniquely identifies a session.	Identifies the N4 session associated to this Usage Report
Rule ID	Uniquely identifies the Packet Detection Rule or Usage Reporting Rule within a session which triggered the report.	Packet Detection Rule is only indicated when Reporting trigger is Start/stop of traffic detection. Usage Reporting Rule is indicated for all other Reporting triggers.
Reporting trigger	Identifies the trigger for the usage report.	Applicable values are: Start/stop of traffic detection with/without application instance identifier and deduced SDF filter reporting; Deletion of last PDR for a URR; Periodic measurement threshold reached; Volume/Time/Event measurement threshold reached; Immediate report requested; Measurement of incoming UL traffic; Measurement of discarded DL traffic; MAC address reporting in the UL traffic; reporting of unknown destination MAC/IP address; end marker packet has been received.
Start time	Provides the timestamp, in terms of absolute time, when the collection of the information provided within Usage-Information is started.	Not sent when Reporting trigger is Start/stop of traffic detection.
End time	Provides the timestamp, in terms of absolute time, when the information provided within Usage-Information is generated.	Not sent when Reporting trigger is Start/stop of traffic detection.
Measurement information	Defines the measured volume/time/events for this URR.	For details refer to clause 7.5.8.3 of TS 29.244 [65].
Other information	Other events/information, e.g. related to reporting of UE MAC addresses.	For details refer to clause 7.5.8.3 of TS 29.244 [65].

5.8.2.11.8 Multi-Access Rule

The following table describes the Multi-Access Rule (MAR) that includes the association to the two FARs for both 3GPP access and non-3GPP access in the case of supporting ATSSS.

Table 5.8.2.11.8-1: Attributes within Multi-Access Rule

Attribute		Description	Comment
N4 Session ID		Identifies the N4 session associated to this MAR.
Rule ID		Unique identifier to identify this rule.
Steering functionality		Indicates the applicable traffic steering functionality: Values "MPTCP functionality", "ATSSS-LL functionality".
Steering mode		Values "Active-Standby", "Smallest Delay", "Load Balancing" or "Priority-based".
Steering Mode Indicator (NOTE 4)		Indicates either autonomous load-balance operation or UE-assistance operation if steering mode is set to "Load Balancing".
Threshold values (NOTE 3, NOTE 4)		A Maximum RTT and/or a Maximum Packet Loss Rate	The Threshold Values are applied by UPF as described in clause 5.32.8.
Per-Access Forwarding	Forwarding Action Rule ID	The Forwarding Action Rule ID identifies a forwarding action that has to be applied.
Action information	Weight	Identifies the weight for the FAR if steering mode is "Load Balancing"	The weights for all FARs need to sum up to 100
(NOTE 1) (NOTE 2)	Priority	Values "Active or Standby" or "High or Low" for the FAR	"Active or Standby" for "Active-Standby" steering mode and "High or Low" for "Priority-based" steering mode
	List of Usage Reporting Rule ID(s)	Every Usage Reporting Rule ID identifies a measurement action that has to be applied.	This enables the SMF to request separate usage reports for different FARs (i.e. different accesses)
NOTE 1: The Per-Access Forwarding Action information is provided per access type (i.e. 3GPP access or Non-3GPP access). NOTE 2: The Weight is treated as the default percentages if the Autonomous operation is allowed for the "Load Balancing" steering mode. NOTE 3: The Threshold Values may be provided when the Steering Mode is Priority-based or when the Steering Mode is Load-Balancing with fixed split percentages. NOTE 4: The Steering Mode Indicator and the Threshold Values shall not be provided together.

5.8.2.11.9 Bridge Information

The following table describes the User plane node Information (UI) that includes the information required to configure a 5GS logical bridge for TSC PDU Sessions.

Table 5.8.2.11.9-1: User plane node Information

Attribute	Description	Comment
DS-TT Port Number	Port Number allocated by the NW-TT for the DS-TT for a given PDU Session
User plane node ID	Bridge identifier of the 5GS TSN bridge, or user-plane node ID.

5.8.2.11.10 Void

5.8.2.11.11 Session Reporting Rule

The following table describes the Session Reporting Rule (SRR) that defines the detection and reporting events that the UPF shall report, that are not related to specific PDRs of the PDU Session, as follows:

– Per QoS Flow per UE QoS Monitoring Report, as specified in clause 5.33.3.2.

– Change of 3GPP or non-3GPP access availability, for an MA PDU session.

Table 5.8.2.11.11-1: Attributes within Session Reporting Rule

Attribute	Description	Comment
N4 Session ID	Identifies the N4 session associated to this SRR.
Rule ID	Unique identifier to identify this information.	Used by UPF when reporting.
QoS Monitoring per QoS Flow Control Information	Indicates the UPF to apply the QoS Monitoring report for one or more QoS Flows.	The IE is defined in clause 7.5.2.9 of the TS 29.244 [65]. See NOTE 1.
Access Availability Control Information	Indicates the UPF to report when an access type becomes available or unavailable for an MA PDU Session.	The IE is defined in clause 7.5.2.9 of TS 29.244 [65].
NOTE 1: The QoS Monitoring per QoS Flow Control Information may contain an Indication of local event notification. The Indication of local event notification includes a Notification Target Address that identifies the recipient of the information being notified by the UPF (Local NEF/AF). The Indication of local event notification also indicates that the UPF reports the information via Nupf_EventExposure_Notify service operation.

5.8.2.11.12 Session reporting generated by UPF

The UPF sends the session report to inform the SMF the detected events for a PDU Session that are related to an SRR. The UPF may support notification to the AF possibly via local NEF as described in clause 6.4 of TS 23.548 [130].

Table 5.8.2.11.12-1: Attributes within Session Reporting

Attribute	Description	Comment
N4 Session ID	Identifies the N4 session associated to the SRR which triggered the report.
Rule ID	Unique identifier to identify the Session Reporting Rule within a session which triggered the report.	Used by UPF when reporting.
QoS Monitoring Report	Indicates the QoS Monitoring result for one or more QoS Flows.	The IE is defined in clause 7.5.8.6 of TS 29.244 [65].
Access Availability Report	Indicates the change of 3GPP or non-3GPP access availability, for an MA PDU session.	The IE is defined in clause 7.5.8.6 of TS 29.244 [65].

5.8.2.11.13 Void

5.8.2.11.14 TSC Management Information

The following table describes the TSC Management Information Container (TSC MIC) that includes UMIC, PMIC and the associated NW-TT port number.

Table 5.8.2.11.14-1: TSC Management Information Container

Attribute	Description	Comment
User plane node Management Information Container	5GS TSN Bridge information exchanged transparently between NW-TT and TSN AF or TSCTSF via 5GS (as in Table 5.28.3.1-2).
Port Management Information Container	Information exchanged transparently between NW-TT and TSN AF or TSCTSF via 5GS (as in Table 5.28.3.1-1).
NW-TT Port Number	NW-TT Port Number related to the PMIC.	Included when the PMIC information is present.

5.8.2.11.15 Downlink Data Report generated by UPF

The UPF sends the Downlink Data Report to inform the SMF about the events related to receiving or discarding of downlink packets. The SMF controls this type of UPF report by providing instructions in the Buffer Action Rule of a FAR.

Following attributes can be included:

Table 5.8.2.11.15-1: Attributes within Downlink Data Report

Attribute	Description	Comment
N4 Session ID	Uniquely identifies a session.	Identifies the N4 Session associated to this Usage Report
Rule ID	Uniquely identifies the Packet Detection Rule which triggered the report.
Downlink Data Service Information	Indicates that the first downlink packet has been received for a QoS Flow at the UPF by reporting the QFI, if it is available. For the IP PDU Session Type, the DSCP in TOS (IPv4) / TC (IPv6) value from the IP header of the downlink packet will also be reported.	This is used for downlink data notification related to QoS Flows.
Downlink Data Status	Indicates that the first downlink packet has been buffered or discarded for a service data flow at the UPF.	This is used for downlink data delivery status notification related to individual services.

5.8.2.12 Reporting of the UE MAC addresses used in a PDU Session

For Ethernet PDU Session type, the SMF may control the UPF to report the different MAC (Ethernet) addresses used as source address of frames sent UL by the UE in a PDU Session. These MAC addresses are called UE MAC addresses.

This control and the corresponding reporting takes place over N4.

NOTE: This is e.g. used to support reporting of all UE MAC addresses in a PDU Session to the PCF as described in clause 5.6.10.2.

The UPF reports the removal of a UE MAC address based on the detection of absence of traffic during an inactivity time. The inactivity time value is provided by the SMF to the UPF.

5.8.2.13 Support for 5G VN group communication

5.8.2.13.0 General

The SMF may configure the UPF(s) to apply different traffic forwarding methods to route traffic between PDU Sessions for a single 5G VN group. For example, depending on the destination address, some packet flows may be forwarded locally, while other packet flows are forwarded via N19 and other packet flows are forwarded to N6.

The UPF local switching, N6-based forwarding and N19-based forwarding methods require that a common SMF is controlling the PSA UPFs for the 5G VN group.

5G VN group communication includes one to one communication and one to many communication. One to one communication supports forwarding of unicast traffic between two UEs within a 5G VN, or between a UE and a device on the DN. One to many communication supports forwarding of multicast traffic and broadcast traffic from one UE (or device on the DN) to many/all UEs within a 5G VN and devices on the DN.

Traffic forwarding within the 5G VN group is realized by using a UPF internal interface ("5G VN internal") and a two-step detection and forwarding process. In the first step, the packets received from any 5G VN group member (via it’s PDU Session, via N6 or via N19) are forwarded to the UPF internal interface (i.e. Destination Interface set to "5G VN internal"). In the second step, PDRs installed at the UPF internal interface (i.e. Source Interface set to "5G VN internal") detect the packet and forward it to the respective 5G VN group member (via it’s PDU Session, via N6 or via N19). The details of the PDR and FAR configuration are described in the following clauses.

For UEs belonging to the same 5G VN group and having PDU Sessions that correspond to N4 Sessions in the same PSA UPF, the following applies for traffic that is sent from one of these UEs to another one of these UEs using local switching: The incoming traffic for one PDU Session will match the corresponding N4 Session’s PDR(s) of the source PDU Session (based on GTP-U header information). The traffic is then sent back to classification in that UPF (via the internal interface) and will match another N4 Session corresponding to the destination PDU Session (based on destination address in the PDU). The PDU is then forwarded to the target UE.

If 5G VN group members’ PDU Sessions are served by different PSA UPFs and N19-based forwarding is applied, the SMF creates a group-level N4 Session with each involved UPF to enable N19-based forwarding and N6-based forwarding. When the traffic is then sent back to classification in that UPF (via the internal interface) it may match group-level N4 Session corresponding to the 5G VN group (based on destination address in the PDU or a default PDR rule with match-all packet filter). The PDU is then forwarded to N6 or to the UPF indicated in the group-level N4 Session via corresponding N19 tunnel. This enables the PDU to be sent to the target group member in the other UPF or to the device in the DN.

In the case of N19-based forwarding is not applied for a 5G VN group, group level N4 session is not required.

If more than one 5G VN group has to be supported in the PLMN, the N4 rule attribute Network Instance is used in addition to the UPF internal interface and set to a value representing the 5G VN group. This keeps the traffic of different 5G VN groups separate from each other and thus enables isolation of the 5G VN group communication during the packet detection and forwarding process. The SMF shall provide the PDRs and FARs related to the UPF internal interface as follows whenever more than one 5G VN group has to be supported in the PLMN:

– The FAR with Destination Interface set to "5G VN internal" shall also contain the Network Instance set to the value representing the 5G VN group.

– The PDR with Source Interface set to "5G VN internal" shall also contain the Network Instance set to the value representing the 5G VN group.

Forwarding Ethernet unicast traffic towards the PDU Session corresponding to the Destination MAC address of an Ethernet frame may correspond:

– either to the SMF explicitly configuring DL PDR(s) with the MAC addresses detected by the UPF on PDU Sessions and reported to the SMF; this is further described in clause 5.8.2.13.1;

– or to the SMF relying on MAC address learning in UPF as defined in clause 5.8.2.5.3. To request this UPF behaviour the SMF sets the Ethernet PDU Session Information indication in the DL PDR of the "5G VN internal" interface related with a 5G VN group. This may apply in the case that all PDU Sessions related with this 5G VN group are served by the same PSA or by multiple PSAs not inter-connected via N19.

For Ethernet traffic on 5G-VN, in the former case above where SMF explicitly configures DL PDR with the MAC addresses detected on PDU Sessions supporting a 5G VN group, the SMF acts as a central controller which is responsible for setting up the forwarding rules in the UPFs so that it avoids forwarding loops. The SMF becomes aware of the MAC addresses in use within a 5G VN group by the UPF’s reporting of the MAC addresses. The SMF is responsible to react to topology changes in the Ethernet network. Local switching without SMF involvement is not specified for a 5G-VN when different PDU Sessions related with this 5G VN group may be served by different PSA(s) connected over N19.

NOTE: The mechanisms described above implies signalling on N4 Sessions related with a VN group each time a new MAC address is detected as used (or no more used) within a PDU Session related with this 5G VN group. Hence the usage of the solution with SMF explicitly configuring DL PDR with the MAC addresses defined in this release can raise signalling scalability issues for large VN groups with lots of devices (MAC addresses) served by PDU sessions related with this VN group.

5.8.2.13.1 Support for unicast traffic forwarding of a 5G VN

To enable unicast traffic forwarding in a UPF, the following applies:

– The SMF provides for each 5G VN group member’s N4 Session (i.e. N4 Session corresponding to PDU Session) the following N4 rules that enable the processing of packets received from this UE.

– in order to detect the traffic, a PDR containing Source Interface set to "access side", and CN Tunnel Information set to PDU Session tunnel header (i.e. N3 or N9 GTP-U F-TEID); and

– in order to forward the traffic, a FAR containing Destination Interface set to "5G VN internal".

– The SMF provides for each 5G VN group member’s N4 Session (i.e. N4 session corresponding to PDU Session) the following N4 rules that enable the processing of packets towards this UE.

– in order to detect the traffic, a PDR containing Source Interface set to "5G VN internal", and Destination Address set to the IP/MAC address (es) of this 5G VN group member; and

– in order to forward the traffic, a FAR containing Outer Header Creation indicating the N3/N9 tunnel information, and Destination Interface set "access side".

– If N19-based forwarding is applied, the SMF configures the group-level N4 Session for processing packets received from a N19 tunnel with the following N4 rules for each N19 tunnel.

– in order to detect the traffic, a PDR containing Source Interface set to "core side", and CN Tunnel Information set to N19 tunnel header (i.e. N19 GTP-U F-TEID); and

– in order to forward the traffic, a FAR containing Destination Interface set to "5G VN internal".

– If N19-based forwarding is applied, the SMF configures the group-level N4 Session for processing packets towards 5G VN group members anchored at other UPFs with the following N4 rules for each N19 tunnel.

– in order to detect the traffic, a PDR containing Source Interface set to "5G VN internal", and Destination Address set to the IP/MAC address (es) of UEs anchored at the peer UPF of this N19 tunnel; and

– in order to forward the traffic to a 5G VN group member anchored at another UPF via the N19 tunnel, a FAR containing Outer Header Creation indicating the N19 tunnel information, Destination Interface set to "core side".

– The SMF configures the group-level N4 Session for processing packets received from a 5G VN group member connected via N6 with the following N4 rules.

– in order to detect the traffic, a PDR containing Source Interface set to "core side", and Source Address set to the IP/MAC address (es) of this 5G VN group member; and

– in order to forward the traffic, a FAR containing Destination Interface set to "5G VN internal".

– The SMF configures the group-level N4 Session for processing packets towards a 5G VN group member connected via N6 or packets towards a device residing in DN with the following N4 rules.

– in order to detect the traffic, a PDR containing Source Interface set to "5G VN internal", and Destination Address set to the IP/MAC address (es) of this 5G VN group member; and

– in order to forward the traffic to the 5G VN group member or device via N6, a FAR containing Destination Interface set to "core side".

– The SMF shall update N4 rules for group-level N4 Session to enable correct forwarding of packets towards UE who’s PSA UPF has been reallocated and address is unchanged.

– The SMF may also configure the following N4 rules for the group-level N4 Session to process packets with an unknown destination address:

– in order to detect the traffic, a PDR containing Source Interface set to "5G VN internal", a match-all Packet Filter, and a Precedence set to the lowest precedence value; and

– in order to process the traffic, a FAR containing Destination Interface set to "core side" to route the traffic via N6 by default, or in the case of local SMF configuration that N6-based forwarding is not applied a FAR instructing the UPF to drop the traffic.

5.8.2.13.2 Support for unicast traffic forwarding update due to UE mobility

To enable the service continuity when the PSA UPF serving the UE changed, the following applies:

– Keep the UE address unchanged if N6-based forwarding is not used.

– Configure the UE’s N4 Session with N4 rules (PDR, FAR) to detect and forward the traffic to this UE via its PDU Session tunnel(i.e. N3 tunnel) on the target PSA UPF.

– If N19-based forwarding is applied: To switch the traffic towards this UE from the source PSA UPF to the target PSA UPF for N19-based forwarding, the SMF deletes the N4 rule (PDR) that detects the traffic towards this UE in the group-level N4 Session at UPFs involved in the 5G VN group (except the source PSA UPF), then adds or updates the PDR that detects the traffic towards this UE with the FAR containing the N19 tunnel information of the target PSA UPF in the group-level N4 Session at UPFs involved in the 5G VN group (except the target PSA UPF).

5.8.2.13.3 Support for user plane traffic replication in a 5G VN

5.8.2.13.3.1 User plane traffic replication based on UPF internal functionality

For Ethernet PDU Sessions, the SMF may instruct the UPF to route traffic to be replicated as described in clause 5.8.2.5.

For IP PDU Session types, the SMF may instruct the UPF to manage IP multicast traffic as described in clauses 4.6.6 and 7.7.1 of TS 23.316 [84]. The UPF replicates the IP multicast traffic received from PDU Sessions or N6 interface and sends the packets over other PDU Sessions and other N6 interface subscribed to the IP Multicast groups.

Mechanisms described in clauses 4.6.6 and 7.7.1 of TS 23.316 [84] apply to support 5G VN group communication with following clarifications:

– These mechanisms are not limited to Wireline access and can apply on any access,

– IP Multicast traffic allowed for a PDU Session is not meant for IPTV services reachable over N6,

– IGMP /MLD signalling does not relate with STB or 5G-RG: Clauses 4.6.6 and 7.7.1 of TS 23.316 [84], apply to UE members of a 5G VN group instead of 5G-RG, and

– Clauses 7.7.1.1.2 and 7.7.1.1.4 of TS 23.316 [84] are not applicable to 5G VN groups: members of the 5G VN groups may receive any multicast traffic associated with the (DNN, S-NSSAI) of the 5G VN group.

– UPF exchange of signalling such as PIM (Protocol-Independent Multicast) may apply as defined in TS 23.316, with following clarification:

– PIM signalling is generally exchanged over N6 but may be sent towards the PDU Session supporting the source address of multicast traffic identified by IGMP / MLD signalling for Source Specific Multicast. In the case of IGMP / MLD signalling not related with Source Specific Multicast no PIM signalling is sent towards any PDU Session

5.8.2.13.3.2 User plane traffic replication based on PDRs with replication instructions

Alternatively, for IP or Ethernet type data communication, the SMF instructs the UPF via PDRs and FARs how to replicate user plane traffic.

The mechanism is supported in the following conditions:

– When N19 is used, there is a full mesh of N19 tunnels between UPFs serving the 5G VN group;

– There is no support of forwarding packets with destination MAC address not known by SMF/UPF (i.e. no support for new UE MAC addresses from the UE during the PDU Session lifetime)

– There is no support for forwarding a broadcast/multicast packet with source address not known to SMF/UPF.

– Each UPF supports one N6 interface instance towards the data network, or only supports N19-based forwarding without N6;

– Multicast group formation of selected members of a 5G VN for Ethernet type data communication is not described in this release of the specification.

In this case, when the UPF receives a broadcast packet of a 5G VN group from N19 or N6, it shall distribute it to all 5G VN group members connected to this UPF. When the UPF receives a broadcast packet from a UE (source UE) via PDU Session associated with a 5G VN group, it shall distribute it to:

– All 5G VN group members (except the source UE) connected to this UPF via local switch, and

– All 5G VN group members connected to other UPFs via N19-based forwarding, and

– The devices on the DN via N6-based forwarding.

To enable broadcast traffic forwarding of a 5G VN group in a UPF, the following applies:

– The SMF provides group-level N4 Session and each 5G VN group member’ N4 Session with the PDR that detect the broadcast packet sent via "internal interface". When UPF receives the broadcast packets sent via "internal interface", it matches the broadcast packet against all PDRs installed at the "internal interface". A successful matching with a PDR that detect the broadcast packet instructs the UPF to continue the lookup of the other PDRs. A matching PDR that detects the broadcast packet shall instruct the UPF to duplicate the broadcast packet and perform processing (using associated FAR, URR, QER) on the copy instead of the original packet if the broadcast packet does not satisfy the packet replication skip information, otherwise the PDR instructs the UPF to skip the processing of the broadcast packet.

– The broadcast packets received from N19 or N6 are forwarded to the UPF internal interface together with a N19 or N6 indication.

– The SMF provides for each 5G VN group member’ N4 Session (i.e. N4 session corresponding to PDU Session) the following N4 rules that enable the processing of broadcast packets towards this UE.

– in order to detect the traffic, a PDR containing Source Interface set to "5G VN internal", Destination Address set to the broadcast address, the Packet replication skip information set to the IP/MAC address (es) of this 5G VN group member, and the indication to carry on matching; and

– in order to forward the traffic, a FAR containing Outer Header Creation indicating the PDU Session tunnel information, and Destination Interface set "access side".

– The SMF configures the group-level N4 Session for processing packets received from a N19 tunnel with the following N4 rules for each N19 tunnel.

– in order to detect the traffic, a PDR containing Source Interface set to "core side", Destination Address set to the broadcast address, and CN Tunnel Information set to N19 tunnel header (i.e. N19 GTP-U TEID); and

– in order to forward the traffic, a FAR containing Destination Interface set to "5G VN internal", Outer Header Creation with the N19 indication.

– The SMF provides for the group-level N4 Session the following N4 rules that enable the processing of broadcast packets towards the other UPFs.

– in order to detect the traffic, a PDR containing Source Interface set to "5G VN internal", Destination Address set to the broadcast address, the Packet replication skip information set to the N19 indication, and the indication to carry on matching; and

– in order to forward the traffic to each involved UPF via the corresponding N19 tunnel, a FAR containing "Duplication" instruction, Outer Header Creation indicating the N19 tunnel information, Destination Interface set to "core side".

– The SMF configures the group-level N4 Session for processing packets received from N6 with the following N4 rules.

– in order to detect the traffic, a PDR containing Source Interface set to "core side", and Destination Address set to the broadcast address; and

– in order to forward the traffic, a FAR containing Destination Interface set to "5G VN internal", Outer Header Creation with the N6 indication.

– The SMF provides for the group-level N4 Session the following N4 rules that enable the processing of broadcast packets towards N6.

– in order to detect the traffic, a PDR containing Source Interface set to "5G VN internal", a match-all packet filter, and the Packet replication skip information set to the N6 indication; and

– in order to forward the traffic to N6, a FAR containing Destination Interface set to "core side".

In this case, to enable multicast traffic forwarding of a 5G VN group in a UPF, broadcast traffic forwarding of a 5G VN applies to multicast traffic forwarding of a 5G VN with the following modifications:

– The SMF installs PDRs for the multicast address instead of the broadcast address.

– The PDRs and FARs are installed for PDU Sessions corresponding to the members of the multicast group.

– In addition, the SMF installs the PDR identifying IGMP/MLD signalling for each 5G VN group member’ N4 Session and a URR with a Reporting Trigger set to "IGMP reporting" for IGMP or set to "MLD reporting" for MLD. Based on the IP Multicast address in "IP multicast join" or "IP multicast leave" reports received from UPF, the SMF manipulates (delete or add) the PDR identifying the multicast traffic for the reported IP Multicast address at the corresponding 5G VN group member’ N4 Session, and if required at the group-level N4 Session at the UPF(s) of the 5G VN group.

5.8.2.14 Inter PLMN User Plane Security functionality

Operators can deploy UPF(s) supporting the Inter PLMN User Plane Security (IPUPS) functionality at the border of their network to protect their networks from invalid inter PLMN N9 traffic.

The IPUPS functionality forwards GTP-U packets (received via the N9 interface) only if they belong to an active PDU Session and are not malformed, as described in TS 33.501 [29].

The SMF can activate the IPUPS functionality together with other UP functionality in the same UPF, or insert a separate UPF in the UP path for the IPUPS functionality. In both cases the UPF with IPUPS functionality is controlled by the SMF via the N4 interface.

5.8.2.15 Void

5.8.2.16 Support for L2TP tunnelling on N6

If requested by the SMF during N4 Session Establishment, the UPF (PSA) may setup L2TP towards an L2TP network server (LNS) in the DN and tunnel the PDU Session user plane traffic in this L2TP tunnel. In this case the UPF acts as a L2TP access concentrator (LAC).

To enable this, the SMF may provide L2TP information to the UPF, such as LNS IP address and/or LNS host name, as described in TS 29.244 [65]. This L2TP information may be configured on the SMF as part of the DNN configuration or received from the DN-AAA Server during secondary authentication/authorization, as described in clause 5.6.6. Alternatively, the L2TP tunnel parameters may be configured in the UPF Function. The L2TP tunnel parameters include necessary parameters for setting up L2TP tunnel towards the LNS (e.g. LNS address, tunnel password, etc.).

In addition, the SMF may provide PAP/CHAP authentication information to the UPF, for use in L2TP session establishment, in case it was received from the UE in the PDU Session Establishment Request.

When L2TP is to be used for a PDU Session, the SMF may select a UPF based upon support of this feature. The SMF determines whether the UPF supports this feature via N4 capability negotiation during N4 Association Setup or via NRF discovery.

If SMF requests the UPF to allocate UE IP address, as described in clause 5.8.2.2.1, the UPF (LAC) may retrieve this IP address from the LNS. In addition, if the SMF requests the UPF to provide DNS address(es), the UPF (LAC) may request the LNS to provide DNS address(es) and report such DNS address(es) to the SMF.

5.8.2.17 Data exposure via SBI interface

The UPF may expose information described in TS 23.502 [3] clause 5.2.26.2, via a service-based interface directly. The NF consumer, which may receive UPF event notifications, are AF/NEF, TSNAF/TSCTSF and NWDAF.

When the UPF support the data exposure via the SBI interface, it may register its NF profile to the NRF. The NF profile include the supported event exposure service and related event ID(s).

To get exposure data from UPF, NF consumer do the subscription to the UPF directly or indirectly via SMF. UPF selection is further described in clause 6.3.3.1.

Only NWDAF can subscribe to the UPF event exposure service directly and only for the following case:

– Data collected for UPF load analytics.

– Data collected for analytics targeting "any UE", but not related with an AoI or with a specific data flow.

To minimize the impact of event notification to UPF data processing, the event subscription may include Reporting suggestion information. The Reporting suggestion information includes Report urgency and Reporting window information. Reporting urgency information represents whether this event report can be delay tolerant, i.e. the event report can be delayed. When the related event is detected, the Reporting window defines the last reporting valid time. Per Reporting suggestion information UPF can concatenate several notification messages to the same notification endpoint in one notification message.

5.8.3 Explicit Buffer Management

5.8.3.1 General

5GC supports buffering of UE’s downlink packets for deactivated PDU Sessions.

Support for buffering in the UPF is mandatory and optional in the SMF.

When the UP connection of a PDU Session is deactivated, buffering in UPF can be activated by the SMF. If the SMF supports buffering capability, the SMF can decide to activate buffering in SMF instead of buffering in UPF.

5.8.3.2 Buffering at UPF

When the SMF decided to activate buffering in UPF, the SMF shall inform the UPF to start buffering packets for this PDU Session.

The SMF provides instructions to the UPF for at least the following behaviour:

– buffer downlink packets with the following additional options:

– reporting the arrival of first downlink packet (for a QoS Flow or a service data flow), and/or

– reporting the first discarded downlink packet (for a service data flow), or

– drop downlink packets with the following additional options:

– reporting the first discarded downlink packet (for a service data flow).

– buffer uplink packets.

When the SMF instructs the UPF for a service data flow to buffer downlink packets and to report the first discarded downlink packet, the SMF shall also instruct the UPF to report the arrival of the first downlink packet for this service data flow to enable the SMF check if this is also the first report for the QoS Flow (as described below).

Buffering in the UPF may be configured based on timers or the amount of downlink data to be buffered. The SMF decides whether buffering timers or amount of downlink data are handled by the UPF or SMF.

After starting buffering, when the first downlink packet (of a QoS Flow or a service data flow) arrives, UPF shall inform the SMF if it is setup to report. UPF sends a Downlink Data Report to the SMF via N4 unless specified otherwise and indicates the PDR by which the downlink packet was received. If the SMF receives a Downlink Data Report for a service data flow, the SMF shall also check if this is the first report for the QoS Flow corresponding to the PDR. If so, the SMF shall also proceed as described in clause 5.4.3.1.

After starting buffering, when the first downlink packet (of a service data flow) in a configured period of time that has been buffered is discarded by the UPF because the configured buffering time or amount of downlink data to be buffered is exceeded, the UPF shall inform the SMF if it is setup to report. UPF sends a Downlink Data Report to the SMF via N4 and indicates the PDR by which the discarded downlink packet was received.

A new report is sent if the SMF terminates and subsequently re-activates the buffering action at the UPF and the UPF again receives downlink packets.

NOTE: For the notification about the downlink data delivery status "buffered" or "discarded" related to packets from a particular AF as part of the Nsmf_EventExposure service, it is expected that a PDR with a traffic filter identifying that AF as source and a Forwarding Action rule with action "buffer" is installed.

When the UP connection of the PDU Session is activated, the SMF updates the UPF of the change in buffering state. The buffered downlink packets, if any, are then forwarded to the (R)AN by the UPF.

If the UP connection of the PDU Session has been deactivated for a long time, the SMF may indicate the UPF to stop buffering for this PDU Session.

The SMF may indicate to the UPF to start or stop the buffering of uplink packets of an application associated to the PCC rule as described in clause 6.3.5 of TS 23.548 [130]. When the buffering of uplink packets is stopped the UPF shall forward all buffered uplink packets before it forwards any new uplink packets.

5.8.3.3 Buffering at SMF

When the SMF supports buffering capability and the SMF decided to activate buffering in SMF for the PDU Session, the SMF shall inform the UPF to start forwarding the downlink packets towards the SMF.

When the UP connection of the PDU Session is activated, if there are buffered downlink packets available and their buffering duration has not expired, the SMF shall forward those packets to the UPF to relay them to the UE. These packets are then forwarded by the UPF to the (R)AN.

5.8.4 SMF Pause of Charging

The SMF Pause of Charging functionality is supported with the purpose that the charging and usage monitoring data in the core network more accurately reflects the downlink traffic actually sent to the (R)AN. When the amount of downlink data incoming at the UPF for a PDU Session that is in deactivated state goes above a pre-configured threshold, the pause of charging functionality ensures that data that dropped in the core network is not included in charging and usage monitoring records.

The procedures for SMF Pause of Charging are described in TS 23.502 [3].