Tech-invite  3GPPspecsRELsGlossariesSIP
Info21222324252627282931323334353637384‑5x

full Contents for  TS 23.501  Word version:   16.4.0

Top   Up   Prev   Next
1…   3…   4…   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 management
5.8.2.11.1  General
These parameters are used by SMF to control the functionality of the UPF as well as to inform SMF about events occurring at the UPF.
The N4 session management procedures defined in clause 4.4.1 of TS 23.502 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 AF the NW-TT: transparent Port Management Information Container.
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:
  • NW-TT port number;
  • DS-TT port number.
After the N4 session has been established, the SMF and UPF may at any time exchange transparent bridge Port Management Information Container over a N4 session.
Up
5.8.2.11.2  N4 Session ContextWord-p. 162
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 N4 session ID, all PDRs, URRs, QERs and FARs or MARs used for this N4 session.
5.8.2.11.3  Packet Detection RuleWord-p. 163
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 ID
Identifies the N4 session associated to this PDR. NOTE 5.

Rule ID
Unique identifier to identify this rule.

Precedence
Determines the order, in which the detection information of all rules is applied.

Packet Detection Information (NOTE 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 ID, 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 the local 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 address
One IPv4 address and/or one IPv6 prefix with prefix length (NOTE 3).

Network instance (NOTE 1)
Identifies the Network instance associated with the incoming packet.

CN tunnel info
CN tunnel info on N3, N9 interfaces, i.e. F-TEID.

Packet Filter Set
Details see clause 5.7.6.

Application ID

QoS Flow ID
Contains the value of 5QI or non-standardized QFI.

Ethernet PDU Session Information
Refers to all the (DL) Ethernet packets matching an Ethernet PDU session, as further described in clause 5.6.10.2 and in TS 29.244.

Framed Route Information
Refers to Framed Routes defined in clause 5.6.14.

Packet replication and detection carry on information
NOTE 6
Packet replication skip information NOTE 7
Contains UE address indication or N19/N6 indication. If the packet matches the packet replication skip information, i.e., source address of the packet is the UE address or the packet has been received on the interface in the packet replication skip information, the UP function neither creates a copy of the packet nor applies the corresponding processing (i.e., FAR, QER, URR). Otherwise the UPF performs a copy and applies the corresponding processing (i.e., FAR, QER, URR).

Carry on indication
Instructs the UP function to continue the packet detection process, i.e., lookup of the other PDRs without higher precedence.

Outer header removal
Instructs the UP function to remove one or more outer header(s) (e.g. IP+UDP+GTP, IP + possibly UDP, VLAN tag), from the incoming packet.
Any extension header shall be stored for this packet.

Forwarding Action Rule ID (NOTE 2)
The Forwarding Action Rule ID identifies a forwarding action that has to be applied.

Multi-Access Rule ID (NOTE 2)
The Multi-Access Rule ID identifies an action to be applied for handling forwarding for a MA PDU Session.

List of Usage Reporting Rule ID(s)
Every Usage Reporting Rule ID identifies a measurement action that has to be applied.

List of QoS Enforcement Rule ID(s)
Every QoS Enforcement Rule ID identifies a QoS enforcement action that has to be applied.

NOTE 1:
Needed e.g. if:
  • UPF supports multiple DNN with overlapping IP addresses;
  • UPF is connected to other UPF or AN node in different IP domains.
  • UPF "local switch", N6-based forwarding and N19 forwarding is used for different 5G LAN groups.
NOTE 2:
Either a FAR ID or a MAR ID is included, not both.
NOTE 3:
The SMF may provide an indication asking the UPF to allocate one IPv4 address and/or IPv6 prefix. When asking to provide an IPv6 Prefix the SMF provides also an IPv6 prefix length.
NOTE 4:
When in the architecture defined in clause 5.34, a PDR is sent over N16a from SMF to I-SMF, the Packet Detection Information may indicate that CN tunnel info is to be locally determined. This is further defined in clause 5.34.6.
NOTE 5:
In the architecture defined in clause 5.34, the rules exchanged between I-SMF and SMF are not associated with a N4 Session ID but are associated with a N16a association.
NOTE 6:
Needed in the case of support for broadcast/multicast traffic forwarding using packet replication with SMF-provided PDRs and FARs as described in clause 5.8.2.13.3.2.
NOTE 7:
Needed in the case of packet replication with SMF-provided PDRs and FARs as described in clause 5.8.2.13.3.2, to prevent UPF from sending the broadcast/multicast packets back to the source UE or source N19/N6.

Up
5.8.2.11.4  QoS Enforcement RuleWord-p. 166
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 ID
Identifies the N4 session associated to this QER
Rule ID
Unique identifier to identify this information.
QoS Enforcement Rule correlation ID (NOTE 1)
An identity allowing the UP function to correlate multiple Sessions for the same UE and APN.
Is used to correlate QoS Enforcement Rules for APN-AMBR enforcement.
Gate status UL/DL
Instructs the UP function to let the flow pass or to block the flow.
Values are: open, close, close after measurement report (for termination action "discard").
Maximum bitrate
The uplink/downlink maximum bitrate to be enforced for the packets.
This field may e.g. contain any one of:
- APN-AMBR (for a QER that is referenced by all relevant Packet Detection Rules of all PDN Connections to an APN) (NOTE 1).
- Session-AMBR (for a QER that is referenced by all relevant Packet Detection Rules of the PDU Session)
- QoS Flow MBR (for a QER that is referenced by all Packet Detection Rules of a QoS Flow)
- SDF MBR (for a QER that is referenced by the uplink/downlink Packet Detection Rule of a SDF)
- Bearer MBR (for a QER that is referenced by all relevant Packet Detection Rules of a bearer) (NOTE 1).
Guaranteed bitrate
The uplink/downlink guaranteed bitrate authorized for the packets.
This field contains:
- QoS Flow GBR (for a QER that is referenced by all Packet Detection Rules of a QoS Flow)
- Bearer GBR (for a QER that is referenced by all relevant Packet Detection Rules of a bearer) (NOTE 1).
Averaging window
The time duration over which the Maximum and Guaranteed bitrate shall be calculated.
This is for counting the packets received during the time duration.
Down-link flow level marking
Flow level packet marking in the downlink.
For UPF, this is for controlling the setting of the RQI in the encapsulation header as described in clause 5.7.5.3.
QoS Flow ID
QoS Flow ID to be inserted by the UPF.
The UPF inserts the QFI value in the tunnel header of outgoing packets.
Paging Policy Indicator
Indicates the PPI value the UPF is required to insert in outgoing packets (see clause 5.4.3.2).
PPI applies only for DL traffic. The UPF inserts the PPI in the outer header of outgoing PDU.
Packet rate (NOTE 1)
Number of packets per time interval to be enforced.
This field contains any one of:
- downlink packet rate for Serving PLMN Rate Control (the QER is referenced by all PDRs of the UE belonging to PDN connections using CIoT EPS Optimisations as described in TS 23.401).
- 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 RuleWord-p. 169
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 ID
Identifies the N4 session associated to this URR
Rule ID
Unique identifier to identify this information.
Used by UPF when reporting usage.
Reporting triggers
One or multiple of the events can be activated for the generation and reporting of the usage report.
Applicable events include:
- Start/stop of traffic detection with/without application instance identifier and deduced SDF filter reporting; Deletion of last PDR for a URR; Periodic measurement threshold reached; Volume/Time/Event measurement threshold reached; Immediate report requested; Measurement of incoming UL traffic; Measurement of discarded DL traffic; MAC address reporting in the UL traffic; unknown destination MAC/IP address.
Periodic measurement threshold
Defines the point in time for sending a periodic report for this URR (e.g. timeofday).
This allows generation of periodic usage report for e.g. offline charging.
It can also be used for realizing the Monitoring time of the usage monitoring feature.
It can also be used for realizing the Quota-Idle-Timeout, i.e. to enable the CP function to check whether any traffic has passed during this time.
Volume measurement threshold
Value in terms of uplink and/or downlink and/or total byte-count when the measurement report is to be generated.
Time measurement threshold
Value in terms of the time duration (e.g. in seconds) when the measurement report is to be generated.
Event measurement threshold
Number of events (identified according to a locally configured policy) after which the measurement report is to be generated.
Inactivity detection time
Defines the period of time after which the time measurement shall stop, if no packets are received.
Timer corresponding to this duration is restarted at the end of each transmitted packet.
Event based reporting
Points to a locally configured policy which is identifies event(s) trigger for generating usage report.
Linked URR ID(s)
Points to one or more other URR ID.
This enables the generation of a combined Usage Report for this and other URRs by triggering their reporting. See clause 5.2.2.4 of TS 29.244.
Measurement Method
Indicates the method for measuring the network resources usage, i.e. the data volume, duration, combined volume/duration, or event.
Measurement information
Indicates specific conditions to be applied for measurements
It is used to request:
- measurement before QoS enforcement, and/or
- to pause or set to active a measurement as for the Pause of charging described in clause 4.4.4 of TS 23.502, and/or
- to request reduced reporting for application start/stop events.

Up
5.8.2.11.6  Forwarding Action RuleWord-p. 172
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 ID
Identifies the N4 session associated to this FAR.
NOTE 9.
Rule ID
Unique identifier to identify this information.
Action
Identifies the action to apply to the packet
Indicates whether the packet is to be forwarded, duplicated, dropped or buffered.
When action indicates forwarding or duplicating, a number of additional attributes are included in the FAR.
For buffering action, a Buffer Action Rule is also included and the action can also indicate that a notification of the first buffered and/or a notification of first discarded packet is requested (see clause 5.8.3.2).
Network instance (NOTE 2)
Identifies the Network instance associated with the outgoing packet (NOTE 1).
NOTE 8.
Destination interface (NOTE 3) (NOTE 7)
Contains the values "access side", "core side", "SMF", "N6-LAN", "5G VN internal" or "5G VN N19".
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 the local DN), to 5G VN internal (i.e. local switch), or to 5G VN N19 (i.e. N19 interface).
Outer header creation (NOTE 3)
Instructs the UP function to add an outer header (e.g. IP+UDP+GTP, VLAN tag), IP + possibly UDP to the outgoing packet.
Contains the CN tunnel info, N6 tunnel info or AN tunnel info of peer entity (e.g. NG-RAN, another UPF, SMF, local access to a DN represented by a DNAI) (NOTE 8).
Any extension header stored for this packet shall be added.
The time stamps should be added in the GTP-U header if QoS Monitoring is enabled for the traffic corresponding to the PDR(s).
Send end marker packet(s) (NOTE 2)
Instructs the UPF to construct end marker packet(s) and send them out as described in clause 5.8.1.
This parameter should be sent together with the "outer header creation" parameter of the new CN tunnel info.
Transport level marking (NOTE 3)
Transport level packet marking in the uplink and downlink, e.g. setting the DiffServ Code Point.
NOTE 8.
Forwarding policy (NOTE 3)
Reference to a preconfigured traffic steering policy or http redirection (NOTE 4).
Contains one of the following policies identified by a TSP ID:
- an N6-LAN steering policy to steer the subscriber's traffic to the appropriate N6 service functions deployed by the operator, or
- a local N6 steering policy to enable traffic steering in the local access to the DN according to the routing information provided by an AF as described in clause 5.6.7.
or a Redirect Destination and values for the forwarding behaviour (always, after measurement report (for termination action "redirect")).
Request for Proxying in UPF
Indicates that the UPF shall perform ARP proxying and / or IPv6 Neighbour Solicitation Proxying as specified in clause 5.6.10.2.
Applies to the Ethernet PDU Session type.
Container for header enrichment (NOTE 2)
Contains information to be used by the UPF for header enrichment.
Only relevant for the uplink direction.
Buffering Action Rule (NOTE 5)
Reference to a Buffering Action Rule ID defining the buffering instructions to be applied by the UPF (NOTE 6)

NOTE 1:
Needed e.g. if:
    - UPF supports multiple DNN with overlapping IP addresses;
    - UPF is connected to other UPF or NG-RAN node in different IP domains;
    - UPF "local switch" and N19 forwarding is used for different 5G LAN groups.
NOTE 2:
These attributes are required for FAR action set to forwarding.
NOTE 3:
These attributes are required for FAR action set to forwarding or duplicating.
NOTE 4:
The TSP ID is preconfigured in the SMF, and included in the FAR according to the description in clauses 5.6.7 and 6.1.3.14 of 23.503 [45] for local N6 steering and 6.1.3.14 of 23.503 [45] for N6-LAN steering. The TSP ID action is enforced before the Outer header creation actions.
NOTE 5:
This attribute is present for FAR action set to buffering.
NOTE 6:
The buffering action rule is created by the SMF and associated with the FAR in order to apply a specific buffering behaviour for DL packets requested to be buffered, as described in clause 5.8.3 and clause 5.2.4 in 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 UPFWord-p. 175
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, or about one or both accesses becomes available or unavailable in a MA-PDU session. 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.
Following attributes can be included in the usage report:
Attribute
Description
Comment

N4 Session ID
Uniquely identifies a session.
Identifies the N4 session associated to this Usage Report
Rule ID
Uniquely identifies the Packet Detection Rule or Usage Reporting Rule within a session which triggered the report.
Packet Detection Rule is only indicated when Reporting trigger is Detection of 1st DL packet for a QoS Flow or Start/stop of traffic detection.
Usage Reporting Rule is indicated for all other Reporting triggers.
Reporting trigger
Identifies the trigger for the usage report.
Applicable values are:
Detection of 1st DL packet for a QoS Flow; 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.
Start time
Provides the timestamp, in terms of absolute time, when the collection of the information provided within Usage-Information is started.
Not sent when Reporting trigger is Start/stop of traffic detection.
End time
Provides the timestamp, in terms of absolute time, when the information provided within Usage-Information is generated.
Not sent when Reporting trigger is Start/stop of traffic detection.
Measurement information
Defines the measured volume/time/events for this URR.
Details refer to TS 29.244.

Up
5.8.2.11.8  Multi-Access Rule [R16]Word-p. 176
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 ID
Identifies the N4 session associated to this MAR.
Rule ID
Unique identifier to identify this rule.
Steering functionality
Indicates the applicable traffic steering functionality:
Values "MPTCP functionality", "ATSSS-LL functionality".
Steering mode
Values "Active-Standby", "Smallest Delay", "Load Balancing" or "Priority-based".
Per-Access Forwarding Action information (NOTE 1)
Forwarding Action Rule ID
The 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).

Up
5.8.2.11.9  Bridge Management Information [R16]Word-p. 177
The following Table describes the Bridge Management Information (BMI) that includes the information required to configure a 5GS logical bridge for TSC PDU Sessions.
Attribute
Description
Comment

NW-TT Port Number
Port Number allocated by the NW-TT for the TSC PDU Session
DS-TT Port Number
Port Number allocated by the NW-TT for the DS-TT for a given TSC PDU Session

5.8.2.11.10  Port Management Information Container [R16]
The following Table describes the Port Management Information Container (PMIC) that includes information exchanged transparently via 5GS between TSN AF and NW-TT for TSC PDU Sessions.
Attribute
Description
Comment

Port Management Information as in Table 5.28.3.1-1
Information exchanged transparently between NW-TT and TSN AF via 5GS

5.8.2.11.11  Session Reporting Rule [R16]
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 ID
Identifies the N4 session associated to this SRR.
Rule ID
Unique identifier to identify this information.
Used by UPF when reporting.
QoS Monitoring per QoS flow Control Information
Indicates the UPF to apply the QoS Monotoring report for one or more QoS Flows.
The IE is defined in clause 7.5.2.9 of TS 29.244.
Access Availability Control Information
Indicates the UPF to report when an access type becomes available or unavailable for an MA PDU Session.
The IE is defined in clause 7.5.2.9 of TS 29.244.

Up
5.8.2.11.12  Session reporting generated by UPF [R16]Word-p. 178
The UPF sends the session report to inform the SMF the detected events for a PDU Session that are related to an SRR.
Attribute
Description
Comment

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

Up
5.8.2.12  Reporting of the UE MAC addresses used in a PDU Session
For Ethernet PDU Session type, the SMF may control the UPF to report the different MAC (Ethernet) addresses used as source address of frames sent UL by the UE in a PDU Session. These MAC addresses are called UE MAC addresses.
This control and the corresponding reporting takes place over N4.
NOTE:
This is e.g. used to support reporting of all UE MAC addresses in a PDU Session to the PCF as described in clause 5.6.10.2.
The UPF reports the removal of a UE MAC address based on the detection of absence of traffic during an inactivity time. The inactivity time value is provided by the SMF to the UPF.
Up
5.8.2.13  Support for 5G VN group communication [R16]
5.8.2.13.0  General
The SMF may configure the UPF(s) to apply different traffic forwarding methods to route traffic between PDU Sessions for a single 5G VN group. For example, depending on the destination address, some packet flows may be forwarded locally, while other packet flows are forwarded via N19 and other packet flows are forwarded to N6.
The UPF local switching, N6-based forwarding and N19-based forwarding methods require that a common SMF is controlling the PSA UPFs for the 5G VN group.
5G VN group communication includes one to one communication and one to many communication. One to one communication supports forwarding of unicast traffic between two UEs within a 5G VN, or between a UE and a device on the DN. One to many communication supports forwarding of multicast traffic and broadcast traffic from one UE (or device on the DN) to many/all UEs within a 5G VN and devices on the DN.
Traffic forwarding within the 5G VN group is realized by using a UPF internal interface ("5G VN internal") and a two-step detection and forwarding process. In the first step, the packets received from any 5G VN group member (via it's PDU Session, via N6 or via N19) are forwarded to the UPF internal interface (i.e. Destination Interface set to "5G VN internal"). In the second step, PDRs installed at the UPF internal interface (i.e. Source Interface set to "5G VN internal") detect the packet and forward it to the respective 5G VN group member (via it's PDU Session, via N6 or via N19). The details of the PDR and FAR configuration are described in the following clauses.
For UEs belonging to the same 5G VN group and having PDU Sessions that correspond to N4 Sessions in the same PSA UPF, the following applies for traffic that is sent from one of these UEs to another one of these UEs using local switching: The incoming traffic for one PDU Session will match the corresponding N4 Session's PDR(s) of the source PDU Session (based on GTP-U header information). The traffic is then sent back to classification in that UPF (via the internal interface) and will match another N4 Session corresponding to the destination PDU Session (based on destination address in the PDU). The PDU is then forwarded to the target UE.
If 5G VN group members' PDU Sessions are served by different PSA UPFs and N19-based forwarding is applied, the SMF creates a group-level N4 Session with each involved UPF to enable N19-based forwarding and N6-based forwarding. When the traffic is then sent back to classification in that UPF (via the internal interface) it may match group-level N4 Session corresponding to the 5G VN group (based on destination address in the PDU or a default PDR rule with match-all packet filter). The PDU is then forwarded to N6 or to the UPF indicated in the group-level N4 Session via corresponding N19 tunnel. This enables the PDU to be sent to the target group member in the other UPF or to the device in the DN.
In the case of N19-based forwarding is not applied for a 5G VN group, group level N4 session is not required.
If more than one 5G VN group has to be supported in the PLMN, the N4 rule attribute Network Instance is used in addition to the UPF internal interface and set to a value representing the 5G VN group. This keeps the traffic of different 5G VN groups separate from each other and thus enables isolation of the 5G VN group communication during the packet detection and forwarding process. The SMF shall provide the PDRs and FARs related to the UPF internal interface as follows whenever more than one 5G VN group has to be supported in the PLMN:
  • The FAR with Destination Interface set to "5G VN internal" shall also contain the Network Instance set to the value representing the 5G VN group.
  • The PDR with Source Interface set to "5G VN internal" shall also contain the Network Instance set to the value representing the 5G VN group.
Forwarding Ethernet unicast traffic towards the PDU Session corresponding to the Destination MAC address of an Ethernet frame may correspond:
  • either to the SMF explicitly configuring DL PDR(s) with the MAC addresses detected by the UPF on PDU Sessions and reported to the SMF; this is further described in clause 5.8.2.13.1;
  • or to the SMF relying on MAC address learning in UPF as defined in clause 5.8.2.5.3. To request this UPF behaviour the SMF sets the Ethernet PDU Session Information indication in the DL PDR of the "5G VN internal" interface related with a 5G VN group. This may apply in the case that all PDU Sessions related with this 5G VN group are served by the same PSA or by multiple PSAs not inter-connected via N19.
For Ethernet traffic on 5G-VN, in the former case above where SMF explicitly configures DL PDR with the MAC addresses detected on PDU Sessions supporting a 5G VN group, the SMF acts as a central controller which is responsible for setting up the forwarding rules in the UPFs so that it avoids forwarding loops. The SMF becomes aware of the MAC addresses in use within a 5G VN group by the UPF's reporting of the MAC addresses. The SMF is responsible to react to topology changes in the Ethernet network. Local switching without SMF involvement is not specified for a 5G-VN when different PDU Sessions related with this 5G VN group may be served by different PSA(s) connected over N19.
NOTE:
The mechanisms described above implies signalling on N4 Sessions related with a VN group each time a new MAC address is detected as used (or no more used) within a PDU Session related with this 5G VN group. Hence the usage of the solution with SMF explicitly configuring DL PDR with the MAC addresses defined in this release can raise signalling scalability issues for large VN groups with lots of devices (MAC addresses) served by PDU sessions related with this VN group.
Up
5.8.2.13.1  Support for unicast traffic forwarding of a 5G VNWord-p. 179
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 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 mobilityWord-p. 181
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 VN
5.8.2.13.3.1  User plane traffic replication based on UPF internal functionality
For Ethernet PDU Sessions, the SMF may instruct the UPF to route traffic to be replicated as described in clause 5.8.2.5.
For IP PDU Session types, the SMF may instruct the UPF to manage IP multicast traffic as described in TS 23.316, clauses 4.6.6 and 7.7.1. 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 TS 23.316, clauses 4.6.6 and 7.7.1 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: TS 23.316, clauses 4.6.6 and 7.7.1, apply to UE members of a 5G VN group instead of 5G-RG, and
  • TS 23.316, clauses 7.7.1.1.2 and 7.7.1.1.4 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 instructions
Alternatively, for IP or Ethernet type data communication, the SMF instructs the UPF via PDRs and FARs how to replicate user plane traffic.
The mechanism is supported in the following conditions:
  • When N19 is used, there is a full mesh of N19 tunnels between UPFs serving the 5G VN group;
  • There is no support of forwarding packets with destination MAC address not known by SMF/UPF (i.e. no support for new UE MAC addresses from the UE during the PDU Session lifetime)
  • There is no support for forwarding a broadcast/multicast packet with source address not known to SMF/UPF.
  • Each UPF supports one N6 interface instance towards the data network, or only supports N19-based forwarding without N6;
  • Multicast group formation of selected members of a 5G VN 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 without higher precedence. 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, GTP-U header can carry the 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.
Up
5.8.2.14  Inter PLMN User Plane Security functionality [R16]Word-p. 183
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 corresponds to following features:
  • forward valid GTP-U traffic from the N9 interface and discard the remaining, non-valid GTP-U traffic.
The IPUPS functionality is further specified 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 N4.
Up
5.8.3  Explicit Buffer Management
5.8.3.1  General
5GC supports buffering of UE's data packets for deactivated PDU Sessions.
Support for buffering in the UPF is mandatory and optional in the SMF.
5.8.3.2  Buffering at UPF
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, and/or
    • reporting the first discarded downlink packet, or
  • drop packet.
When the UP connection of the PDU Session is deactivated and the SMF decides to activate buffering in UPF for the session, the SMF shall inform the UPF to start buffering packets for this PDU Session.
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 arrives, UPF shall inform the SMF if it is setup to report. UPF sends a downlink data notification message to the SMF via N4 unless specified otherwise and indicates the user plane path on which the downlink packet was received.
After starting buffering, when the first downlink packet 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 dropped downlink data notification message to the SMF via N4 and indicates the PDR for which the downlink packet was received. A new report is sent if the SMF terminates and subsequently re-activates the buffering action.at the UPF and the UPF again receives downlink packets.
NOTE:
For the notification about the downlink data delivery status "buffered" or "discarded" related to packets from a particular AF as part of the Nsmf_EventExposure service, it is expected that a PDR with a traffic filter identifying that AF as source and a Forwarding Action rule with action "buffer" is installed.
When the UP connection of the PDU Session is activated, the SMF updates the UPF of the change in buffering state. The buffered data 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.
Up
5.8.3.3  Buffering at SMFWord-p. 184
When the UP connection of the PDU Session is deactivated and the SMF supports buffering capability, the SMF may decide to activate buffering on SMF, the SMF shall inform the UPF to start forwarding the downlink data packets towards the SMF.
When the UP connection of the PDU Session is activated, if there are buffered 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.
Up
5.8.4  SMF Pause of Charging
The SMF Pause of Charging functionality is supported with the purpose that the charging and usage monitoring data in the core network more accurately reflects the downlink traffic actually sent to the (R)AN. When the amount of downlink data incoming at the UPF for a PDU Session that is in deactivated state goes above a pre-configured threshold, the pause of charging functionality ensures that data that dropped in the core network is not included in charging and usage monitoring records.
The procedures for SMF Pause of Charging are described in TS 23.502.
Up

Up   Top   ToC