Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.501  Word version:  19.1.0

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

 

5.8.2.11  Parameters for N4 session management (moved)p. 215

The parameters used by SMF to control the functionality of the UPF as well as to inform SMF about events occurring at the UPF are described in clause 5.8.5.

5.8.2.12  Reporting of the UE MAC addresses used in a PDU Sessionp. 216

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

5.8.2.13  Support for 5G VN group communication |R16|p. 216

5.8.2.13.0  Generalp. 216
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.
If a single SMF serves the DNN/S-NSSAI of the 5G VN group, the UPF local switching, N6-based forwarding and N19-based forwarding methods described in clause 5.29.4 are coordinated by the SMF. If an SMF set serves the DNN/S-NSSAI of the 5G VN group, implementation based mechanisms can be used between SMF(s) that are part of the SMF set for controlling the connectivity between the PSA UPFs of the UE members of the 5G VN group.
When a 5G VN group communication is extended in a wide area, bigger than the service area of any SMF set serving the DNN/S-NSSAI of the 5G VN group, multiple SMF sets might control the PDU Sessions of the UE members of the 5G VN group. In this case, N6/N19 connectivity between PSA UPFs of the UE members of the 5G VN group controlled by different SMF sets, is achieved via OAM configuration. As a deployment option, a subset of the UPFs controlled by an SMF Set may be configured with the N6/N19 connectivity to enable 5G VN group communication across SMF Sets. N6 connectivity between PSA UPFs via a DN may also exist.
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.
Up
5.8.2.13.1  Support for unicast traffic forwarding of a 5G VNp. 217
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 (e.g. based on the IP address range supported by the peer UPF); 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.
Up
5.8.2.13.2  Support for unicast traffic forwarding update due to UE mobilityp. 218
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).
Up
5.8.2.13.3  Support for user plane traffic replication in a 5G VNp. 218
5.8.2.13.3.1  User plane traffic replication based on UPF internal functionalityp. 218
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. 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 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, 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 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
Up
5.8.2.13.3.2  User plane traffic replication based on PDRs with replication instructionsp. 218
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 controlled by each SMF Set serving the 5G VN group;
  • 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 or N6-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" and Destination Address set to the broadcast address 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.
Up

5.8.2.14  Inter PLMN User Plane Security functionality |R16|p. 220

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

5.8.2.15Void

5.8.2.16  Support for L2TP tunnelling on N6 |R17|p. 221

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

5.8.2.17  Data exposure via Service Based interface |R18|p. 221

The UPF may expose information by means of UPF Event Exposure service as described in clause 5.2.26.2 of TS 23.502, via a service-based interface directly. The NF consumers, which may receive UPF event notifications, are AF/NEF, TSNAF/TSCTSF and NWDAF/DCCF/MFAF.
When the UPF supports the data exposure via the service based interface, it may register its NF profile to the NRF including the UPF Event Exposure services and the related Event ID(s).
For data collection from UPF (see clause 4.15.4.5 of TS 23.502), NF consumers can do the subscription to the UPF either directly or indirectly via SMF. An NF consumer may subscribe to the UPF Event Exposure service directly if target of data collection is "any UE", e.g. to collect user data usage information for NWDAF NF Load analytics (see clause 6.5 of TS 23.288 or if target of data collection is a UE IP address,) and if the subscription is not including any of the following parameters: AoI, BSSID/SSID and DNAI. Otherwise the NF consumer shall subscribe indirectly via SMF.
When the UPF changes for the scenario of UPF relocation, if the UPF event subscription for a UE is directly sent to the UPF, the UPF may send a notification with a subscription termination indication and an optional cause code to the UPF event consumer. In the case of subscribing to UPF event via SMF or directly to UPF, the source UPF may report to the consumer any data that has been collected but not sent to the consumer yet when the UPF changes (see clause 4.15.4.5 of TS 23.502).
To alleviate the load of UPF due to frequent event notification for data collection related events, 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. If the Reporting urgency information indicates "delay tolerant", the Reporting window is also provided, which defines the last valid reporting time, and UPF shall report the event before that time. If the Reporting suggestion information allows this, the UPF can concatenate several event reports (of the same event) to the same notification endpoint into one notification message.
The UPF may also expose UE information by means of the Nupf_GetUEPrivateIPaddrAndIdentifiers service as described in clause 5.2.26.3 of TS 23.502. An UPF which is deployed with NAPT (Network Address Port Translation) functionality may support to provide the 5GC UE IP address to NEF based on NEF request containing public IP address and port number using the Nupf_GetUEPrivateIPaddrAndIdentifiers service as described in clause 4.15.10 of TS 23.502 for AF specific UE ID retrieval.
The UPF event exposure service may allow NF consumer to obtain one NATed UE public IP address and Port number for a particular PDU Session, based on the UE private IP address allocated by 5GC. An UPF which is deployed with NAT functionality may support to provide the UE public IP address and port number to consumer based on Nupf_EventExposure_Subscribe request as defined in clause 5.2.26.2.3 of TS 23.502.For information flow for getting UE public IP address and port number, see clause 6.2.8.2.4 of TS 23.288.
Up

5.8.2.18  QoS Flow related QoS monitoring and reporting |R18|p. 222

The SMF may configure the UPF to perform QoS monitoring for a QoS Flow and to report the monitoring results with the help of the following parameters provided in the Session Reporting Rule (SRR) described in clause 5.8.5.11:
  • QoS monitoring parameter(s) indicating the subject of the QoS monitoring as defined in clause 5.45;
  • Reporting period indicating the time interval in which a new measurement result and a potential report has to be available. Generally, if no measurement result is available to the UPF within the Reporting period, the UPF shall report a measurement failure; however, for some QoS monitoring parameters (e.g. congestion information, PDV and data rate), the measurement failure report is not applicable.
  • Reporting frequency indicating the type of the reporting as "periodic" or "event triggered":
    • If the Reporting frequency indicates "periodic", the UPF shall send a report each time the reporting period is over.
    • If the Reporting frequency indicates "event triggered", a Reporting threshold for each parameter in the QoS monitoring parameter(s) and a Minimum waiting time are provided as well. The UPF shall send a report when the measurement result matches or exceeds the indicated Reporting threshold. Subsequent reports should not be sent by the UPF during the Minimum waiting time. The UPF shall continue to report a measurement result that matches or exceeds the indicated Reporting Threshold when the Minimum waiting time is over.
  • (Optional) Target of the reporting and Indication of direct event notification indicating that the UPF shall send the reports to a different NF than the SMF (e.g. to the NEF/AF or the NWDAF/DCCF/MFAF). The NF is identified by a Notification Target Address and a Notification Correlation ID. The SMF can also indicate that the UPF shall send the reports to both, the NF indicated by the Target of reporting and to the SMF. If so, the UPF shall send the reports to the SMF as well. If the Indication of direct event notification is not provided, the UPF shall send the reports to the SMF.
  • (Optional) Reporting suggestion information as defined in clause 5.8.2.17 applicable to Target of the reporting to reduce the UPF performance impacts.
  • (Optional) Indication of QoS Flow associated with the default QoS Rule (see clause 4.15.4.5.1 of TS 23.502). The UPF shall forward this indication, that the QoS monitoring report is for the QoS Flow associated with the default QoS Rule, in the Nupf_EventExposure_Notify service operation when sending reports.
The UPF shall send the QoS Monitoring Report as follows:
  • when the UPF sends reports to the SMF, the UPF shall use QoS Monitoring Reports as described in clause 5.8.5.12; and/or
  • When the UPF sends reports to a different NF than the SMF (e.g. the NEF/AF or the NWDAF/DCCF/MFAF), the UPF shall use the Nupf_EventExposure_Notify service operation described in clause 5.2.26.2.2 of TS 23.502.
Up

5.8.2.19  Explicit Buffer Management |R18|p. 223

5.8.2.19.1  Generalp. 223
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.2.19.2  Buffering at UPFp. 223
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). Based on local policy and/or an indication from the AMF, e.g. the RAT type of REDCAP or the CN based MT handling indication, the SMF may also instruct the UPF to report the DL data size in case of arrival of the first downlink packet.
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.
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. When the buffering of uplink packets is stopped the UPF shall forward all buffered uplink packets before it forwards any new uplink packets.
Up
5.8.2.19.3  Buffering at SMFp. 224
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.2.20  SMF Pause of Charging |R18|p. 224

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

5.8.2.21  Operator configurable UPF capability |R19|p. 224

UPF may support operator defined non-standardized or partially supported feature(s), such as hardware features (e.g. xPUs information), computing features (e.g. computing resource type, computing capability), and protection features (e.g. Firewall, DDoS). If the UPF supports such features, the UPF indicates the supported features to the SMF using the operator configurable UPF capability as described in clause 4.17 or clause 4.4.3 of TS 23.502.
Up

5.8.3  Explicit Buffer Management (moved)p. 224

The Explicit Buffer Management is described in clause 5.8.2.19.

5.8.4  SMF Pause of Charging (moved)p. 224

The SMF Pause of Charging is described in clause 5.8.2.20.

5.8.5  Parameters for N4 session management |R18|p. 224

5.8.5.1  Generalp. 224

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 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/Router 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 bridge/router configuration between the SMF and the UPF:
  • Information that the SMF needs for bridge/router management (clause 5.8.5.9);
  • Information that 5GS transparently relays between the TSN AF or TSCTSF 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 TSCTSF and the NW-TT: transparent user plane node Management Information Container (clause 5.8.5.14).
When a N4 Session related with bridge/router management is established, the UPF allocates a dedicated port number for the PDU Session. The UPF then provides to the SMF following configuration parameters for the N4 Session:
  • port number.
  • user-plane node ID.
To support TSN, the user-plane node ID is Bridge ID. To support integration with IETF DetNet, the user-plane node ID can be Router ID. The User Plane Node 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.
Up

5.8.5.2  N4 Session Contextp. 225

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

5.8.5.3  Packet Detection Rulep. 226

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.
Attribute Description Comment
N4 Session IDIdentifies the N4 session associated to this PDR (5).
Rule IDUnique identifier to identify this rule.
PrecedenceDetermines the order, in which the detection information of all rules is applied.
Packet Detection Information (4)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, packet filter set, application identifier, Ethernet PDU Session Information and QFI are used for traffic detection.
Source interface identifies the interface for incoming packets where the PDR applies, e.g. from access side (i.e. up-link), from core side (i.e. down-link), from SMF, from N6-LAN (i.e. the DN), or from "5G VN internal" (i.e. local switch).
Details like all the combination possibilities on N3, N9 interfaces are left for stage 3 decision.
The FQDN or FQDN range only used for detection of plain DNS Query message (i.e. not subject to ciphering). The usage is described in TS 23.548.
UE IP addressOne IPv4 address and/or one IPv6 prefix with prefix length (3).
Network instance (1)Identifies the Network instance associated with the incoming packet.
CN tunnel infoCN tunnel info on N3, N9 interfaces, i.e. F-TEID.
Packet Filter SetDetails see clause 5.7.6.
Application identifier
QoS Flow IDContains the value of 5QI or non-standardized QFI.
Ethernet PDU Session InformationRefers 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.
Framed Route InformationRefers to Framed Routes defined in clause 5.6.14.
FQDN Filter for DNS QueryContains one or more FQDN, FQDN range, and/or any FQDN.
Protocol DescriptionIndicates service protocol used by the flow (NOTE 8).
Packet replication and detection carry on information (6)Packet replication skip information (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).
Carry on indicationInstructs the UP function to continue the packet detection process, i.e. lookup of the other PDRs.
Outer header removalInstructs 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 (2)The Forwarding Action Rule ID identifies a forwarding action that has to be applied.
Multi-Access Rule ID (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.
  • UPF "local switch" may be used for DNN/S-NSSAI dedicated for PIN.
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.
NOTE 8:
Not for PDR matching. It may be provided to assist PDU Set identification when PDU Set Identification and marking applies to the PDR and/or to assist identification of the last packet of the Data burst in downlink when End of Data Burst identification and marking in downlink applies to the PDR. See clause 5.8.2.4.2 and TS 26.522.
Up

5.8.5.4  QoS Enforcement Rulep. 229

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.
Attribute Description Comment
N4 Session IDIdentifies the N4 session associated to this QER
Rule IDUnique identifier to identify this information.
QoS Enforcement Rule correlation ID (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/DLInstructs 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) (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) (1).
Guaranteed bitrateThe 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) (1).
Averaging windowThe 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 markingFlow 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 IDQoS Flow ID to be inserted by the UPF.The UPF inserts the QFI value in the tunnel header of outgoing packets.
Paging Policy IndicatorIndicates 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 (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).
  • 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).
End of Data Burst Marking IndicationIndicates to the UPF to provide an End of Data Burst indication of the last PDU of a Data burst to the NG-RAN over GTP-UNG-RAN can configure UE power management schemes like connected mode DRX when UPF provides an indication of the End of Data Burst, see clause 5.37.8.3.
PDU Set Information marking IndicatorIndicates the UPF to insert PDU Set Information related to packets belonging to a PDU Set into GTP-U header.UPF identifies PDU Sets in DL traffic and forwards PDU Set related information of each PDU to the NG-RAN over GTP-U, as described in clause 5.37.5.
ECN marking for L4S indicatorIndicates the UPF to perform ECN marking for L4S for the corresponding QoS Flow.UPF uses information sent by NG-RAN in GTP-U header extension to perform ECN marking for L4S for the corresponding direction.
NOTE 1:
This parameter is only used for interworking with EPC.
Up

5.8.5.5  Usage Reporting Rulep. 232

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.
Attribute Description Comment
N4 Session IDIdentifies the N4 session associated to this URR
Rule IDUnique identifier to identify this information.Used by UPF when reporting usage.
Reporting triggersOne 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 thresholdDefines 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 thresholdValue in terms of uplink and/or downlink and/or total byte-count when the measurement report is to be generated.
Time measurement thresholdValue in terms of the time duration (e.g. in seconds) when the measurement report is to be generated.
Event measurement thresholdNumber of events (identified according to a locally configured policy) after which the measurement report is to be generated.
Inactivity detection timeDefines 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 reportingPoints to a locally configured policy which is identifies event(s) trigger for generating usage report.This enables the generation of a combined Usage Report for this and other URRs by triggering their reporting. See clause 5.2.2.4 of TS 29.244.
Linked URR ID(s)Points to one or more other URR ID.
Measurement MethodIndicates 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, and/or
  • to request reduced reporting for application start/stop events.
Up

5.8.5.6  Forwarding Action Rulep. 235

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.
Attribute Description Comment
N4 Session IDIdentifies the N4 session associated to this FAR.(9)
Rule IDUnique identifier to identify this information.
ActionIdentifies 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.2.19.2).
For drop action, a notification of the discarded packet may be requested (see clause 5.8.2.19.2).
Network instance (2)Identifies the Network instance associated with the outgoing packet (1).(8)
Destination interface (3, 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 (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) (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 for packet delay is enabled for the traffic corresponding to the PDR(s).
Send end marker packet(s) (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 (3)Transport level packet marking in the uplink and downlink, e.g. setting the DiffServ Code Point.(8)
Forwarding policy (3)Reference to a preconfigured traffic steering policy or http redirection (4). The Forwarding policy refers to a preconfigured forwarding behaviour in UPF, which may be related to:
  • N6-LAN steering to steer the subscriber's traffic to the appropriate N6 Service Functions deployed by the operator;
  • local N6 steering 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;
  • a Redirect Destination and values for the forwarding behaviour (always, after measurement report (for termination action "redirect")).
Metadata (10)Metadata the UPF needs to add to traffic sent over a SFC.The metadata information is associated with a TSP ID related to N6-LAN steering.
Request for Proxying in UPFIndicates 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 (2)Contains information to be used by the UPF for header enrichment.Only relevant for the uplink direction.
Buffering Action Rule (5)Reference to a Buffering Action Rule ID defining the buffering instructions to be applied by the UPF (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 used to determine the Forwarding Policy included in the FAR according to the description in clause 5.6.7 and clause 6.1.3.14 of TS 23.503 for local N6 steering and in clause 5.6.16 and clause 6.1.3.14 of TS 23.503 for N6-LAN steering. The Forwarding Policy 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.
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.
NOTE 10:
The use of Metadata is described in clause 5.6.16. How the UPF transforms the Metadata into actual information sent with the traffic (e.g. in the encapsulation header) is based on local policies related with the Forwarding Policy and not specified.
Up

5.8.5.7  Usage Report generated by UPFp. 238

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:
Attribute Description Comment
N4 Session IDUniquely identifies a session.Identifies the N4 session associated to this Usage Report
Rule IDUniquely 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 triggerIdentifies 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 timeProvides 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 timeProvides 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 informationDefines the measured volume/time/events for this URR.For details refer to clause 7.5.8.3 of TS 29.244.
Other informationOther events/information, e.g. related to reporting of UE MAC addresses.For details refer to clause 7.5.8.3 of TS 29.244.
Up

5.8.5.8  Multi-Access Rulep. 239

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.
Attribute Description Comment
N4 Session IDIdentifies the N4 session associated to this MAR.
Rule IDUnique identifier to identify this rule.
Steering functionality (5) Indicates the applicable traffic steering functionality:
Values "MPTCP functionality", "ATSSS-LL functionality", "MPQUIC functionality".
Transport Mode Identifies the transport mode (see clause 5.32.6.2.2.1) that should be used for the matching traffic, when the Steering functionality is the MPQUIC functionality. The Transport Mode shall be included only when the Steering Functionality is the MPQUIC functionality. In all other cases, the Transport Mode shall not be included.
Steering mode (5) Values "Active-Standby", "Smallest Delay", "Load Balancing", or "Priority-based" or "Redundant".
Steering Mode Indicator (4) Indicates either autonomous load-balance operation or UE-assistance operation if steering mode is set to "Load Balancing".
Threshold values (3, 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 Action information (1) (2)Forwarding Action Rule IDThe Forwarding Action Rule ID identifies a forwarding action that has to be applied.
Weight Identifies the weight for the FAR if steering mode is "Load Balancing" The weights for all FARs need to sum up to 100
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 or when the Steering Mode is "Redundant". If the Steering Mode is "Redundant", either a Maximum RTT or a Maximum Packet Loss Rate may be provided, but not both.
NOTE 4:
The Steering Mode Indicator and the Threshold Values shall not be provided together.
NOTE 5:
The Steering functionality "ATSSS-LL functionality" shall not be provided together with Steering Mode "Redundant".
Up

5.8.5.9  Bridge/Router Informationp. 240

The following table describes the User plane node Information (UI) that includes the information required to configure a 5GS logical bridge/router for TSC or Deterministic Networking PDU Sessions.
Attribute Description Comment
Port NumberPort Number allocated by the node for a given PDU Session
User plane node IDBridge identifier of the 5GS TSN bridge, or user-plane node ID.
Up

5.8.5.10Void

5.8.5.11  Session Reporting Rulep. 241

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.
  • Per QoS Flow N6 Traffic Parameter Measurement Report.
Attribute Description Comment
N4 Session IDIdentifies the N4 session associated to this SRR.
Rule IDUnique identifier to identify this information.Used by UPF when reporting.
QoS Monitoring per QoS Flow Control InformationIndicates the UPF to apply perform the QoS Monitoring report for one or more QoS Flows.The IE is defined in clause 7.5.2.9 of TS 29.244.
See NOTE 1.
Access Availability Control InformationIndicates 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.
N6 Traffic Parameter Measurement Control InformationIndicates the UPF to report N6 Traffic parameter measurements for one QoS Flow, e.g. a measurement of N6 jitter range for a DL Periodicity and conditionally, a measurement of the UL/DL periodicity.
May indicate the DL Periodicity (See NOTE 2).
The IE is defined in clause 7.5.2.9 of TS 29.244.
See NOTE 2.
NOTE 1:
The QoS Monitoring per QoS Flow Control Information may contain an Indication of local direct event notification and. The Indication of local event notification includes a Notification Target Address (the details are described in clause 5.8.2.18) that identifies the recipient of the information being notified by the UPF (Local NEF/AF). The Indication of local direct event notification also indicates that the UPF reports the information to the NF indicated by the Target of reporting via Nupf_EventExposure_Notify service operation.
NOTE 2:
The DL Periodicity is provided by the SMF in the N6 Traffic Parameters Measurement Control Information when the DL Periodicity is received from the PCF.
Up

5.8.5.12  Session reporting generated by UPFp. 241

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.
Attribute Description Comment
N4 Session IDIdentifies the N4 session associated to the SRR which triggered the report.
Rule IDUnique identifier to identify the Session Reporting Rule within a session which triggered the report.Used by UPF when reporting.
QoS Monitoring ReportIndicates the QoS Monitoring result for one or more QoS Flows.The IE is defined in clause 7.5.8.6 of TS 29.244.
Access Availability ReportIndicates 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.
N6 Traffic Parameter Measurement ReportIndicates the N6 Traffic Parameter measurement result for one QoS Flow, e.g. a measurement of N6 jitter range associated with a DL Periodicity and conditionally, a measurement of the UL/DL periodicity.The IE is defined in clause 7.5.8.6 of TS 29.244.
Up

5.8.5.13Void

5.8.5.14  TSC Management Informationp. 242

The following Table describes the TSC Management Information Container (TSC MIC) that includes UMIC, PMIC and the associated NW-TT port number.
The SMF may include the notification target address for PMIC/UMIC UPF event provided by the PCF in the TSC Management Information sent to UPF if the UPF supports the related redirect reporting via Nupf. If the notification target address for PMIC/UMIC UPF event is provided by the SMF, the UPF may directly report TSC management information to the TSNAF or TSCTSF using Nupf_EventExposure_Notify service operation described in clause 7.2.29.
Attribute Description Comment
User plane node Management Information Container 5GS TSN Bridge or Router information exchanged transparently between NW-TT and TSN AF or TSCTSF via 5GS (as in Table K.1-2).
Port Management Information Container Information exchanged transparently between NW-TT and TSN AF or TSCTSF via 5GS (as in Table K.1-1).
NW-TT Port NumberNW-TT Port Number related to the PMIC.Included when the PMIC information is present.
Notification Target Address for PMIC/UMIC UPF event (+ Notification Correlation ID) for PMIC/UMIC UPF eventIdentifies the recipient of the information being notified by the UPF (TSNAF/TSCTSF).
Up

5.8.5.15  Downlink Data Report generated by UPFp. 242

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:
Attribute Description Comment
N4 Session IDUniquely identifies a session.Identifies the N4 Session associated to this Usage Report
Rule IDUniquely identifies the Packet Detection Rule which triggered the report.
Downlink Data Service InformationIndicates 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 StatusIndicates 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.
Up

Up   Top   ToC