Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 23.501  Word version:  17.5.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.3…   4.3.3   4.3.4   4.3.5   4.4…   4.4.6…   4.4.8   5…   5.3…   5.3.3…   5.4…   5.5…   5.6…   5.6.7…   5.7…   5.7.2…   5.7.3…   5.7.4   5.7.5…   5.8…   5.8.2.11…   5.9…   5.10…   5.11…   5.15…   5.16…   5.17…   5.18…   5.19…   5.21…   5.22…   5.27…   5.28…   5.29…   5.30…   5.31…   5.32…   5.33…   5.34…   5.35…   6…   6.3…   7…   7.2…   8…   8.2.4   8.2.5…   8.3…   A…   D…   E…   F   G…   G.3   G.4…   J…

 

5.8.2.11  Parameters for N4 session managementp. 186

5.8.2.11.1  Generalp. 186
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 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.
Up
5.8.2.11.2  N4 Session Contextp. 188
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.2.11.3  Packet Detection Rulep. 188
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.
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.
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.
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.
Up
5.8.2.11.4  QoS Enforcement Rulep. 191
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).
NOTE 1:
This parameter is only used for interworking with EPC.
Up
5.8.2.11.5  Usage Reporting Rulep. 194
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.2.11.6  Forwarding Action Rulep. 197
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.3.2).
For drop action, a notification of the discarded packet may be requested (see clause 5.8.3.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 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). 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 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 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 clause 6.1.3.14 of TS 23.503 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.
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.
Up
5.8.2.11.7  Usage Report generated by UPFp. 200
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.2.11.8  Multi-Access Rule |R16|p. 201
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 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 (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.
NOTE 4:
The Steering Mode Indicator and the Threshold Values shall not be provided together.
Up
5.8.2.11.9  Bridge Information |R16|p. 202
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.
Attribute Description Comment
DS-TT Port NumberPort Number allocated by the NW-TT for the DS-TT for a given TSC PDU Session
User plane node IDBridge identifier of the 5GS TSN bridge, or user-plane node ID.
Up
5.8.2.11.10Void
5.8.2.11.11  Session Reporting Rule |R16|p. 202
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.
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 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.
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.
Up
5.8.2.11.12  Session reporting generated by UPF |R16|p. 203
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.
Up
5.8.2.11.13Void
5.8.2.11.14  TSC Management Information |R16|p. 203
The following Table describes the TSC Management Information Container (TSC MIC) that includes UMIC, PMIC and the associated NW-TT port number.
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 NumberNW-TT Port Number related to the PMIC.Included when the PMIC information is present.
Up
5.8.2.11.15  Downlink Data Report generated by UPF |R16|p. 204
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

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

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

5.8.2.13.0  Generalp. 204
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.
Up
5.8.2.13.1  Support for unicast traffic forwarding of a 5G VNp. 205
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.
Up
5.8.2.13.2  Support for unicast traffic forwarding update due to UE mobilityp. 206
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. 207
5.8.2.13.3.1  User plane traffic replication based on UPF internal functionalityp. 207
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. 207
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.
Up

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

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.15  Reporting of satellite backhaul to SMF |R17|p. 209

If the AMF is aware that a satellite backhaul with long delay is used towards 5G AN, the AMF may report this to SMF as part of the PDU Session establishment procedure as described in clause 4.3.2 of TS 23.502. If AMF is aware that satellite backhaul category changes (e.g. at handover), the AMF reports the current satellite backhaul category and indicates the satellite backhaul category change to SMF.
Satellite backhaul category refers to the type of the satellite (i.e. GEO, MEO, LEO or OTHERSAT) used in the backhaul. Only a single backhaul category can be indicated.
Up

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

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.3  Explicit Buffer Managementp. 210

5.8.3.1  Generalp. 210

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 UPFp. 210

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.
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.3.3  Buffering at SMFp. 211

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 Chargingp. 211

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

Up   Top   ToC