5.2 Packet Forwarding Model

29.2443GPPInterface between the Control Plane and the User Plane nodesRelease 17TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

5.2.1 General

The packet forwarding scenarios supported over the Sxa, Sxb and Sxc reference points are specified in 3GPP TS 23.214 [2].

The packet forwarding scenarios supported over the N4 reference point are specified in 3GPP TS 23.501 [28] and 3GPP TS 23.502 [29].

The packet forwarding scenarios supported over the N4mb reference point are specified in 3GPP TS 23.247 [72].

The CP function controls the packet processing in the UP function by establishing, modifying or deleting PFCP Session contexts and by provisioning (i.e. adding, modifying or deleting) PDRs, FARs, QERs, URRs, BAR and/or MAR or by activating/deactivating pre-defined PDRs, FARs, QERs, URRs, per PFCP session context, whereby a PFCP session context may correspond:

– for EPC, to an individual PDN connection, a TDF session, or a standalone session not tied to any PDN connection or TDF session used e.g. for forwarding Radius, Diameter or DHCP signalling between the PGW-C and the PDN.

– for 5GC, to an individual PDU session, a standalone PFCP session not tied to any PDU session or an MBS session.

Each PDR shall contain a PDI, i.e. one or more match fields against which incoming packets are matched, and may be associated to the following rules providing the set of instructions to apply to packets matching the PDI:

– one or more FARs, which contains instructions related to the processing of the packets as follows:

– an Apply Action parameter, which indicates whether the UP function shall:

– forward, duplicate, drop or buffer the packet with or without notifying the CP function about the arrival of a DL packet;

– accept or deny UE requests to join an IP multicast group;

– forward, duplicate, drop or buffer the UL packet; or

– forward the MBS session data to a Low Layer Source Specific Multicast (LL SSM) address (using multicast transport) and/or forward and replicate the MBS session data to multiple GTP-u peers (using unicast transport).

– forwarding, buffering and/or duplicating parameters, which the UP function shall use if the Apply Action parameter requests the packets to be forwarded, buffered or duplicated respectively. These parameters may remain configured in the FAR regardless of the Apply Action parameter value, to minimize the changes to the FAR during the transitions of the UE between the idle and connected modes. The buffering parameters, when present, shall be provisioned in a BAR created at the PFCP session level and referenced by the FAR.

NOTE 1: Buffering refers here to the buffering of the packet in the UP function. The UP function is instructed to forward DL packets to the CP function when applying buffering in the CP function. See clause 5.3.1.

– zero, one or more QERs, which contains instructions related to the QoS enforcement of the traffic;

– zero, one or more URRs, which contains instructions related to traffic measurement and reporting.

– zero or one MAR, which contains instructions related to Access Traffic Steering, Switching and Splitting (ATSSS) for the downlink traffic of a Multi-Access (MA) PDU session. See clause 5.2.7.

NOTE 2: A downlink PDR can be associated with two FARs for an N4 session established for an MA PDU session as an MAR contains two FARs for 3GPP and non-3GPP respectively.

A FAR, a QER, an URR and an MAR shall only be associated to one or multiple PDRs of the same PFCP session context.

The QoS Enforcement Rule Correlation ID shall be assigned by the CP function to correlate QERs from multiple PFCP session contexts. For instance, the enforcement of APN-AMBR in the PGW-U shall be achieved by setting the same QoS Enforcement Rule Correlation ID to the QERs from different PFCP sessions associated with all the PDRs corresponding to the non-GBR bearers of all the UE’s PDN connections to the same APN. The QERs that are associated to the same QoS Enforcement Rule Correlation ID in multiple PFCP sessions shall be provisioned, with the same QER contents, in each of these PFCP sessions. The QoS Enforcement Rule Correlation ID shall be only used to enforce the APN-AMBR when the UE is in EPC, it may be provided by the CP function over N4 to the UP function for a PDU session may move to EPC in a later stage.

The following principles shall apply for the provisioning of PDRs in the UP function:

– Every PDR provisioned for a PFCP session shall allow to identify the PFCP session, i.e. every PDR shall contain the information element(s) to identify the PFCP session, which is either a Traffic Endpoint Identifier (if the PDI Optimization feature is supported) or equivalent information, e.g. UE IP address, Local F-TEID, Frame-Route, in the PDI IE.

– The CP function shall not provision more than one PDR with the same match fields in the PDI (i.e. with the same set of match fields and with the same value). The CP function may provision PDRs with the same value for a subset of the match fields of the PDI but not all;

– different PDRs of a same PFCP session may overlap, e.g. the CP function may provision two PDRs which differ by having one match field set to a specific value in one PDR and the same match field not included in the other PDR (thus matching any possible value);

– different PDRs of different PFCP sessions, not including the Packet Replication and Detection Carry-On Information IE, shall not overlap, i.e. PDRs in each PFCP session shall differ by at least one different (and not wildcarded) match field in their PDI, such that any incoming user plane packet may only match PDRs of a single PFCP session;

– As an exception to the previous principle, the CP function may provision a PDR with all match fields wildcarded (i.e. all match fields omitted in the PDI) in a separate PFCP session, to control how the UP function shall process packets unmatched by any PDRs of any other PFCP session. The CP function may provision the UP function to send these packets to the CP function or to drop them. The UP function shall grant the lowest precedence to this PDR.

– different PDRs of different PFCP sessions, including the Packet Replication and Detection Carry-On Information IE, may overlap. The Detection Carry-On Indication indicates that the UP function shall proceed with the look-up of other PDRs of other PFCP sessions matching the packet. This is used for broadcast traffic forwarding in 5G VN Group Communication.

– different downlink PDRs of different PFCP sessions, with a PDI including the IP multicast IP address IE, may overlap. The UP function shall proceed with the look-up of other PDRs of other PFCP sessions matching the packet. This is used for downlink IP multicast traffic for IPTV service (see clause 5.25).

– different downlink PDRs of different PFCP sessions, with a PDI including the MBS Session Identifier, may overlap. The UPF shall proceed with the look-up of other PDRs of other PFCP sessions with the same MBS Session Identifier matching the packets. This is used for multicast MBS services in 5GS using 5GC Individual Traffic Delivery (see clause 5.34).

On receipt of a user plane packet, the UP function shall perform a lookup of the provisioned PDRs in the UP function to identify only one PDR in a PFCP session according to the following steps:

– identify first the PFCP session to which the packet corresponds; and

– find the first PDR matching the incoming packet, among all the PDRs provisioned for this PFCP session, starting with the PDRs with the highest precedence and continuing then with PDRs in decreasing order of precedence. Only the highest precedence PDR matching the packet shall be selected, i.e. the UP function shall stop the PDRs lookup once a matching PDR is found.

A packet matches a PDR if all the match fields which are identified with different IE type in the PDI of the PDR are matching the corresponding packet header fields unless specified otherwise. If a match field is not included in the PDI, it shall be considered as matching all possible values in the header field of the packet. If the match field is present and does not include a mask, the match field shall be considered as matching the corresponding header field of the packet if it has the same value. If the match field is present and includes a mask (e.g. IP address with a prefix mask), the match field shall be considered as matching the corresponding header field of the packet if it has the same value for the bits which are set in the mask. If a match field has multiple instances, i.e. there are several IEs with the same IE type, a packet matches this match field if any instance is matching the corresponding packet header field.

The match fields of the PDI shall correspond to outer and/or inner packet header fields, e.g. uplink bearer binding verification in the PGW-U may be achieved by configuring a PDR with the PDI containing the local GTP-U F-TEID (for outer IP packet matching) and the SDF filters of the data flows mapped to the bearer (for inner IP packet matching).

NOTE 3: A DL PDR can be provisioned with a UE IP address together with a Framed-Route or a Framed-IPv6-Rotue either in the PDI IE or in the Create Traffic Endpoint IE; in such case, the PDR is matched if the packet matches either the UE IP address or the Framed-Route (Framed-IPv6-Route).

When one or more pre-defined PDR(s) are activated for a given PDR (see clause 5.19), an incoming packet matches the PDR if it matches one of activated pre-defined PDR(s).

The UP function should drop packets unmatched by any PDRs.

The packet processing flow in the UP function is illustrated in Figure 5.2.1-1.

Figure 5.2.1-1: Packet processing flow in the UP function

At the deletion of a PFCP session, the UP function shall delete the PFCP session context and all the associated non-preconfigured rules.

NOTE 4: Deleting a QER in one PFCP session does not result in deleting another QER in another PFCP session even when these two QERs have the same QER ID and/or are associated with the same QER Correlation ID.

A UP Function controlled by multiple CP functions shall handle Rule IDs from the different CP functions independently from each other.

Rule ID used for PDR, FAR, BAR, QER, URR or MAR is uniquely identifying a rule of the corresponding rule type within a session.

For an MA-PDU session, IP addresses translation for MPTCP traffic (see Annex E.3) is independent from the handling of URR/QER/BAR, but it shall be performed before applying the FAR (e.g. before creating the outer header and forwarding the packet).

5.2.1A Packet Detection Rule Handling

5.2.1A.1 General

When provisioning a PDR in the UP function, the CP function shall provide the PDI with the following information:

– the source interface of the incoming packets;

– a combination of the parameters, that incoming packets are requested to match, among: Local F-TEID, Network Instance, UE IP address(es), SDF Filter(s) and/or Application ID. For 5GC, the PDI may additionally contain one or more QFI(s) to detect traffic pertaining to specific QoS flow(s), Ethernet Packet Filter(s), Ethernet PDU Session Information (see clause 5.13.1) and/or DNS Query Filter(s).

The requirements for provisioning an SDF filter in the PDI are specified in clauses 5.2.1A.2A and 5.2.1A.3.

The CP function may provision the parameters, that incoming packets are requested to match, in the UP function by:

– providing the parameters individually in each PDI of the PFCP session; or

– optionally, if the PDI Optimization feature is supported by the UP function, by providing the parameters which may be common to multiple PDIs of a same PFCP session in a Traffic Endpoint IE and by referencing this Traffic Endpoint in the PDI(s) of the PFCP session. See clause 5.2.1A.2. A Traffic Endpoint may include a Local F-TEID, Network Instance, UE IP address(es) and/or Ethernet PDU Session Information (see clause 5.13.1).

NOTE: A Traffic Endpoint can correspond to a GTP-u endpoint, an SGi or an N6 endpoint.

5.2.1A.2 PDI Optimization

The PDI Optimization feature should be supported by CP and UP functions complying with this release of the specification. This feature allows the CP function to optimize the signaling towards the UP function by creating the information that are common to multiple PDRs as a Traffic Endpoint with a Traffic Endpoint ID and then referring to this common information from multiple PDRs. The Traffic Endpoint ID shall be unique within a PFCP session. If MTE feature is supported, one PDI may refer to more than one Traffic Endpoints. When a PDI refers to a Traffic Endpoint, the parameters that are in the Traffic Endpoint shall not be once again provided in the PDI. The CP function may update the Traffic Endpoint at any time.

If a Traffic Endpoint is updated, all the PDRs that refer to this Traffic Endpoint in the UP function shall use the updated information.

The UP function shall allocate and store the F-TEID associated to the Traffic Endpoint. When the UP function provides the allocated F-TEID to the CP function in the PFCP Session Establishment response or PFCP Session Modification response message, the CP function shall update the Traffic Endpoint information stored in the CP function with the received F-TEID.

The CP function should use a Traffic Endpoint ID created in a different PFCP message only after getting the confirmation from the UP function of the Traffic Endpoint ID creation.

If the CP function deletes a Traffic Endpoint, the UP Function shall delete all the PDRs that refer to this Traffic Endpoint.

NOTE 1: The requirements specified in clause 5.2.2.3.1 for reporting usage reports to the CP function also apply if the deletion of the Traffic Endpoint results in deleting the last PDR associated to a URR.

NOTE2: For EPC, the Remove Traffic Endpoint IE can be used to delete a bearer for which multiple PDRs exist (with the same Traffic Endpoint ID).

5.2.1A.2A Provisioning of SDF filters

When provisioning an SDF Filter in a PDI, the CP function shall:

– copy the Flow Description if it is received from the PCRF (or PCF), in the corresponding PDI of a PDR regardless of whether the PDR is for matching uplink or downlink traffic;

NOTE 1 The Flow Description received from the PCRF (or PCF) is set assuming downlink flows only, see clause 5.4.2 of 3GPP TS 29.212 [8]. The CP function uses the Flow-Direction AVP received from the PCRF (or PCF) to determine the actual direction and thus the source interface of the packet flows described in the Flow Description.

– for traffic from CP-function or SGi-LAN:

– If the traffic is intended to be forwarded to the UE, the CP function shall provision the Flow Description with IPFilterRule "source" parameters set to correspond to the CP function or SGi-LAN and the IPFilterRule "destination" parameters correspond to the UE;

– If the traffic is intended to be forwarded to the PDN, the CP function shall provision the Flow Description with IPFilterRule "source" parameters set to correspond to the CP function or SGi-LAN and the IPFilterRule "destination" parameters correspond to the PDN.

The UP function shall apply the SDF filter based on the Source Interface of the PDR as follows (see also clause 8.2.5):

– when the Source Interface is CORE, this indicates that the filter is for downlink data flow, so the UP function shall apply the Flow Description as is;

– when the Source Interface is ACCESS, this indicates that the filter is for uplink data flow, so the UP function shall swap the source and destination address/port in the Flow Description;

– when the Source Interface is CP-function or SGi-LAN, the UP function shall use the Flow Description as is.

5.2.1A.3 Bidirectional SDF Filters

The CP function may provision bidirectional SDF Filters in the UP function (see clause 8.2.5), i.e. SDF Filters that may be associated to both uplink and downlink PDRs of a same PFCP/N4 session, as follows:

– when provisioning a bidirectional SDF Filter the first time for a PFCP/N4 session, the CP function shall provision the SDF filter definition together with a SDF Filter ID uniquely identifying the SDF Filter among all the SDF Filters provisioned for a given PFCP/N4 Session;

– the CP function may then provision a PDR for the same PFCP/N4 session but the opposite direction, by provisioning the SDF Filter ID in the SDF filter ID field of the PDI, without provisioning again the SDF filter definition;

– the UP function shall apply any modification of a bidirectional SDF Filter to all PDRs of the PFCP/N4 session making use of this SDF Filter;

– upon deletion of a PDR making use of a bidirectional SDF Filter, the UP function shall still apply the SDF Filter for any other PDR making use of the SDF Filter.

The requirements specified for provisioning SDF filters in clause 5.2.1A.2A shall also apply when provisioning bidirectional SDF Filters.

5.2.1A.4 Application detection with PFD

The detection information for a given application may be provisioned by the CP function to the UP function via PFD management procedure. See clause 6.2.5.

The PFDE (PFD Enhancement) feature may be optionally supported by the CP function and UP function. When the feature is supported in both the CP function and UP function, the CP function may provision a PFD Contents IE including a property (i.e. either flow description, or URL or Domain Name/Domain Name Protocol) with multiple values.

NOTE 1: It is assumed, when the PFDE feature is not supported, a PFD Contents can only include a property with one value.

When the UP function attempts to detect the traffic pertaining to an application by using the application’s PFDs (see clause 7.4.3.1 and 8.2.39), the UP function shall consider:

– the application is detected if the incoming traffic matches at least one PFD Contents;

– one PFD Contents is matched if the incoming traffic matches every property contained in the corresponding PFD Contents IE;

– the incoming traffic matches one property (i.e. flow description, URL and Domain Name/Domain Name Protocol) if it matches at least one value of the property.

NOTE 2: Interpretation of the Custom PFD Content is implementation specific.

5.2.2 Usage Reporting Rule Handling

5.2.2.1 General

The CP function shall provision URR(s) for a PFCP session in a PFCP Session Establishment Request or a PFCP Session Modification Request to request the UP function to:

– measure the network resources usage in terms of traffic data volume, duration (i.e. time) and/or events, according to the provisioned Measurement Method; and

– send a usage report to the CP function, when the measurement reaches a certain threshold, periodically or when detecting a certain event, according to the provisioned Reporting Triggers or when an immediate report is requested within a PFCP Session Modification Request.

NOTE: The UP function sends a usage report without performing network resources usage measurements when being requested to detect and report the start of an SDF or application traffic.

5.2.2.2 Provisioning of Usage Reporting Rule in the UP function

5.2.2.2.1 General

When provisioning a URR, the CP function shall provide the reporting trigger(s) in the Reporting Triggers IE of the URR which shall cause the UP function to generate and send a Usage Report for this URR to the CP function. When adding or removing reporting trigger(s) to or from the URR, the CP function shall provide the new complete list of applicable reporting triggers in the Reporting Triggers IE in the PFCP Session Modification Request message.

For the volume-based measurement method, the CP function may provision:

– the Volume Threshold IE, to request the UP function to generate a usage report when the measured traffic reaches the threshold;

– the Volume Quota IE, to request the UP function to stop forwarding packets (or only allow forwarding of some limited user plane traffic, based on operator policy in the UP function) and, if no Volume Threshold is provisioned, to also generate a usage report, when the measured traffic reaches the quota;

– the Dropped DL Traffic Threshold IE, to request the UP function to generate a usage report when the downlink traffic that is being dropped reaches the threshold; and/or

NOTE 1: For EPC, the Dropped DL Traffic Threshold can be armed in a SGW-U for triggering the PGW Pause of Charging feature (see 3GPP TS 23.401 [14]). For 5GC, the Dropped DL Traffic Threshold can be armed in a UPF for triggering the SMF Pause of Charging feature (see 3GPP TS 23.502 [29]).

– a Measurement Information with the ‘Measurement Before QoS Enforcement’ flag set to "1", to request the UP function to measure the traffic usage before any enforcement, e.g. bitrate enforcement for QoS, Gate control enforcement (as specified in clause 5.4.3) or packets dropped as requested by the FAR;

– a Measurement Information with the ‘Measurement of Number of Packets’ flag set to "1", to request the UP function to measure the number of packets be transferred in UL/DL/Total in addition to the measurement in octets, if the UP function supports the MNOP feature.

For the time-based measurement method, the CP function may provision:

– a Time Threshold IE, to request the UP function to generate a usage report when the measured traffic reaches the threshold;

– a Time Quota, to request the UP function to stop forwarding packets (or only allow forwarding of some limited user plane traffic, based on operator policy in the UP function) and, if no Time Threshold is provisioned, to also generate a usage report, when the measured traffic reaches the quota;

– a Measurement Information with the "Immediate Start Time Metering" flag set to "1", to request the UP function to start time metering immediately at receiving the flag; otherwise, the UP function shall start time metering when the first packet is received; and/or

– an Inactivity Detection Time, to request the UP function to suspend the time measurement when no packets are received during the provisioned Inactivity Detection Time. The time measurement shall then be resumed by the UP function when subsequent traffic is received. If an Inactivity Detection Time value of zero is provided, or if no Inactivity Detection Time has been provided by the CP function, the time measurement shall be performed continuously until a new non-zero Inactivity Detection Time is received or the time-based usage measurement is stopped. See Figure 5.2.2.2-1:

Figure 5.2.2.2-1: IDT based charging

NOTE 2: The Inactivity Detection Time can be set to the Quota Consumption Timer if received. The Inactivity Detection Time is not used to control when the time metering starts.

– For EPC, a Time Quota Mechanism, including a Base Time Interval Type, which is either Continuous Time Period (CTP) or Discrete Time Period (DTP), and a Base Time Interval (BTI), to the UP function. See clause 6.5.7 in 3GPP TS 32.299 [18].

– For CTP (Continuous Time Period), the time measurement starts from the time that traffic has occurred up to the first Base Time Interval (BTI) which contains no traffic. The time measurement shall include the last Base Time Interval, i.e. the one which contained no traffic. The time measurement resumes by the UP function when subsequent traffic is received. See Figure 5.2.2.2-2:

Figure 5.2.2.2-2: CTP based charging

– For DTP (Descrete Time Period), the time measurement starts from the time that traffic has occurred up to the Base Time Interval end. The time measurement shall be resumed by the UP function when subsequent traffic is received. See Figure 5.2.2.2-3:

Figure 5.2.2.2-3: DTP based charging

When the time-based measurement method applies, and when the Envelope Reporting is required for EPC, the CP function shall request the UP function to report the usage by setting the reporting trigger to Envelope Closure in addition to other Reporting Trigger(s), in the Reporting Triggers IE. The CP function may indicate the UP function to report for just time, time and volume, time and events, or time and volume and number of events by setting Measurement Method accordingly. The CP function may set the Reduced Application Detection Information flag in the Measurement Information of the URR, when requesting the detection of start and stop of an application solely for the purpose of envelope reporting for EPC.

The CP function may provision a Volume Threshold IE, a Volume Quota IE, or both (and/or respectively a Time/Event Threshold IE, a Time/Event Quota IE, or both). In such a case, the CP function may set the reporting trigger for threshold (VOLTH/TIMTH/EVETH) and/or the reporting trigger for quota (VOLQU/TIMQU/EVEQU)) in the Reporting Triggers IE.

When both a Volume (or Time or Event) Threshold IE and a Volume (or Time or Event) Quota IE are provisioned and only the reporting trigger for threshold (VOLTH/TIMTH/EVETH) is set, the UP function shall send a usage report only when reaching the Volume (or Time or Event) Threshold. When subsequently reaching the Volume (or Time or Event) Quota, the UP function shall stop forwarding packets (or only allow forwarding of some limited user plane traffic, based on operator policy in the UP function) without sending a new usage report to the CP function.

If both a Volume (or Time or Event) Threshold IE and a Volume (or Time or Event) Quota IE are provisioned and both of the respective Threshold and Quota reporting triggers are set, the UP function shall send a usage report when reaching the Volume (or Time or Event) Threshold and also later on when subsequently reaching the Volume (or Time or Event) Quota.

NOTE 3: A UP Function complying with Release 14 or Release 15 of the specification only sends one usage report when the threshold is reached, even if both reporting triggers (for the threshold and the quota) are set.

NOTE 4: After sending a usage report on reaching a threshold, the UP function typically gets a new quota before the earlier provisioned quota exhausts. This implies that the UP function typically sends a quota report when reaching the final quota.

NOTE 5: For online charging, the Volume Threshold (or Time Threshold) can be set in a PGW-U or TDF-U to the value of the granted volume (or time) quota minus the volume (or time) quota threshold, such as to get a usage report from the UP function when the volume (or time) based credit falls below the remaining quota thresholds provided by the OCS.

NOTE 6: The Volume Quota or Time Quota can be armed in a PGW-U or TDF-U for online charging to enable the traffic to be forwarded up to an intermediate or final quotas granted by the OCS. The CP function can provision both a Volume (or Time) Threshold and a Volume (or Time) Threshold to request the UP function to:
– send a usage report when the consumed resources reach the volume (or time) usage threshold provided by the OCS, and
– to stop forwarding packets (or only allow forwarding of some limited user plane traffic, based on operator policy in the UP function), without sending a second usage report, when the granted volume (or time) quota is exhausted.

For event based measurement method, the CP function may provision:

– the Event Threshold IE, to request the UP function to generate a usage report when the number of events reaches the event threshold;

– the Event Quota IE, to request the UP function to stop forwarding packets applicable to the event (or only allow forwarding of some limited user plane traffic, based on operator policy in the UP function) and, if no Event threshold is provisioned, to also generate a usage report, when the number of events reaches the event quota;

NOTE 7: An event is preconfigured with one or more event detection logic in the UPF. Each event detection logic is associated with an Application ID. The CP function activates the detection and reporting of an event by provisioning PDR(s) with the PDI set to an Application ID and by provisioning a URR with an event threshold or event quota reporting trigger. The CP function identifies an event reported in a Usage Report by the URR ID.

For all the measurement methods (i.e. volume, time or event), the CP function may also provision:

– a Quota Holding Time, to request the UP function to send a usage report and to also stop forwarding packets (or only allow forwarding of some limited user plane traffic, based on operator policy in the UP function) when no packets have been received for the duration indicated in this parameter;

NOTE 8: A Quota Holding Time can be armed in a PGW-U or TDF-U for online charging to request the UP function to send a Usage Report when the Quota Holding Time provided by the OCS (see 3GPP TS 32.299 [18]) expires. The UP function can be instructed in the same Usage Reporting Rule with the Report Triggers – START to generate a new Usage Report upon receiving any subsequent packets associated with this URR.

– a Quota Validity Time, if the VTIME feature is supported by UP function, to request the UP function to send a usage report after the validity duration is over. After Quota validity timer expiry, if packets are received on UPF, the UPF shall stop forwarding packets or only allow forwarding of limited user plane traffic, based on operator’s policy in the UP function;

NOTE 9: After sending the usage report triggered by the QUHTI or QUVTI (i.e. the Quota Holding Time or Quota Validity Time expires), any remaining quota for the URR is discarded in the UP function.

– a Monitoring Time IE and zero or more Additional Monitoring IEs, to request the UP function to measure the network resources usage before and after the monitoring time in separate counts and to re-apply the volume and/or time, and/or event thresholds at the monitoring time. The CP function may additionally provision a Subsequent Volume (or Time or Event) Threshold IE and/or a Subsequent Volume (or Time or Event) Quota IE, for a volume (or time or event) based measurement. When being provisioned with a Monitoring Time, the UP function shall:

– reset its usage thresholds at the monitoring time to the value provided in the Subsequent Volume (or Time or Event) Threshold IE, if provisioned in the URR, or to the remaining value of the Volume (or Time or Event) threshold used before the monitoring time (i.e. excluding the already accumulated volume or time usage);

– shall indicate the usage up to the Monitoring time and usage after the Monitoring time in separate usage reports as specified in clause 5.2.2.3.1;

– an Measurement Period, indicating the period to generate periodic usage reports to the CP function.

– an User Plane Inactivity Timer, to request the UP function to send an usage report when no packets have been received for any of the PDRs associated to the URR for the duration indicated in this parameter.

If the UP function indicated support of the Quota Action feature in the UP Function Features IE, when the CP function provisions a Volume Quota or Time Quota or Event Quota in a URR, the CP function may also provision the "FAR ID for Quota Action" IE identifying the substitute FAR the UP function shall apply, for the traffic identified by the PDR to which the URR is associated, when exhausting any of these quotas. This FAR may require the UP function to drop the packets or buffer the packets or redirect the traffic towards a redirect destination as specified in clause 5.4.7.

If the UP function has indicated support of the QUASF feature as specified in clause 8.2.25, and when the CP function provisions a Volume Quota, Time Quota, or Event Quota in a URR, the CP function may also provision the Exempted Application ID for Quota Action IE or the Exempted SDF Filter for Quota Action IE, to instruct the UP function, that traffic matching the associated PDR(s) and matching the Application ID(s) or SDF Filter(s) shall be handled based on the FAR associated with the PDR as normal, even when the quota has been exhausted.

NOTE 10: The traffic forwarded after the quota has been exhausted need not to be measured.

NOTE 11: A PDR can be associated with multiple URRs. If one of these URRs requires the UP function to drop the user data packets, e.g. when the Quota has been exhausted, the other URRs associated to the PDR need also to stop their measurements, except for URRs including the Measurement Information with the ‘Measurement Before QoS Enforcement’ flag set to "1".

The CP function may request at any time the UP function to activate or deactivate a network resources usage measurement, using the Inactive Measurement flag of the Measurement Information IE of the URR.

NOTE 12: This can be used in a PGW-U for the PGW Pause of Charging procedure (see 3GPP TS 23.401 [14]).

When the NSPOC feature as specified in clause 5.30 is supported by the CP and UP function, the CP function may provision:

– an Measurement Information with the ‘Send Start Pause of Charging’ Flag set to "1", to request the UP function (SGW-U or I/V-UPF) to send a Start Pause of Charging indication to the upstream GTP-U entity(s) when the Dropped DL Traffic Threshold is reached.

– an Measurement Information with the ‘Applicable for Start of Pause of Charging’ Flag set to "1", to indicate the UP function to stop the usage measurement for the URR when receiving Start Pause of Charging indication from the peer downstream GTP-U entity.

When the NSPOC feature is supported by the CP and UP functions, the CP function may use the "SUMPC" and "RUMUC" flags in the PFCPSMReq-Flags IE, and the "SUMPC" flag in the PFCPSEReq-Flags IE, to request the UP function to stop or resume the usage measurement for all URRs with the ASPOC flag set to "1". The CP function may set the "CIAM" flag in the Measurement Information IE in a Create URR or a Update URR IE to request the UP function to stop or resume the usage measurement according to the value of the Inactive Measurement flag for a specific URR with the "ASPOC" flag set to "1" if necessary. See also clause 5.30.

The CP function may request the UP function to measure network resources usage and generate the corresponding Usage Reports only for a number of times, by provisioning the "Number of Reports" IE in a URR, if the UP function supports the NORP feature (see clause 8.2.25-1). If so, the URR shall become inactive in the UP function after the requested "Number of Reports" have been reported.

The CP function may resume the measurement for an inactive URR by setting the Inactive Measurement flag of the Measurement Information IE of the URR to "0" in the Update URR IE in a PFCP Session Modification Request message, with or without the Number of Report IE if the URR was deactivated by setting the Inactive Measurement flag of the Measurement Information IE of the URR to from "0" to "1".

For any other cases, i.e. the URR becoming inactive, which is not caused by changing the Inactive Measurement flag from "0" to "1", the CP may resume the URR:

– by provisioning a Number of Report IE with a (new) non-zero value (to receive the corresponding number of usage reports) or with a null length (to request UP function to perform continous measurement) when the requested Number of Reports has been reached;

– by setting the CIAM flag to "1" and the INAM flag to "0" if the URR was provisioned with ASPOC bit set to "1" in the Update URR (for the URR) when the CP function has requested to stop usage measurement for pause of charging by setting the SUMPC flag to "1"; or

– by associating (new) PDR(s) with the URR when the last PDR associated with the URR has been removed.

If the CP function wishes the UP function to perform continuous measurement for a URR which was provisioned with a Number of Reports (i.e. to no longer limit the number of reports to be generated), the CP function shall provide the Number of Reports IE in the Update URR with a null length to delete the limit on the number of reports to be generated.

NOTE 13: The Number of Reports can be provisioned in an URR regardless which Measurement Method is used.

5.2.2.2.2 Credit pooling (for EPC)

For EPC, when the Credit Pool feature is supported and the CP function (e.g. PGW-C) is instructed to handle a Credit Pool for a given Gy Session, the CP function shall create a URR for the Credit Pool, and in this URR, the CP function:

– shall include one Aggregated URR ID IE per URR sharing the credit pool, including the URR ID of the URR sharing the credit pool and the associated Multiplier to measure the abstract service units the corresponding traffic consumes from the credit pool;

– shall set the Time or Volume Threshold or Quota IE to the value calculated as specified in IETF RFC 4006 [16] according to the Measurement Method.

NOTE 1: The value can be calculated using the following formula:

S = Q1*M1 + Q2*M2 + … + Qn*Mn,
where the S is the quota for the credit pool, Qn is the quota and Mn is the multiplier for each Rating Group (RG) which are provided via the Multiple Services Credit Control from the OCS.
An URRn is defined for each of RG.

NOTE 2: When the Measurement Method is set to the combined volume/duration, the Time and Volume Threshold or Quota are calculated independently.

– may set the Reporting Trigger to reporting upon reaching a volume or time threshold or quota;

– may set the Measurement Method to the data volume, duration (i.e. time), combined volume/duration according to the Measurement Method set in the URRs in the Credit Pool.

NOTE 3: The UP function is instructed to handle a Credit Pool when a G-S-U-Pool-Reference AVP is included within a Multiple Services Credit Control from the OCS. A Credit Pool is identified by the G-S-U-Pool-Identifier AVP. See clause 6.3.11, 6.4.3 and 6.4.4 of 3GPP TS 32.299 [18].

In addition, the CP function shall also include the Linked URR IE, set to the Credit Pool URR ID, in all the URRs which are sharing the credit pool (i.e. which are associated with RGs sharing the Credit Pool).

5.2.2.3 Reporting of Usage Report to the CP function

5.2.2.3.1 General

When detecting that a provisioned reporting trigger occurs, the UP function shall generate a Usage Report for the related URR and send it to the CP function by initiating the PFCP Session Report procedure.

When providing usage report information for a URR in a message, the UP function shall include the UR-SEQN (Usage Report Sequence Number) identifying the order in which a Usage Report is generated for the given URR. The UR-SEQN (Usage Report Sequence Number) shall be set to "0" for the first Usage Report and incremented for every subsequent Usage Report generated by the UP function for the URR. The UP function shall also indicate the trigger that causes the usage report to be generated in the Usage Report Trigger IE.

Upon generating a usage report for an URR towards the CP function, the UP function shall:

– reset its ongoing measurement counts for the related URR (i.e. the UP function shall report in a usage report the network resources usage measurement since the last usage report for that URR);

– re-apply all the thresholds (Volume/Time/Event Threshold) provisioned for the related URR, if the usage report was triggered due to one of the thresholds being reached, i.e. upon the reporting triggers VOLTH/TIMTH/EVETH; otherwise, if the usage report was triggered for other reporting triggers, adjust the thresholds (Volume/Time/Event Threshold) respectively by subtracting the (volume/time/event) reported usage in the usage report to determine when to generate the next report for reporting triggers VOLTH/TIMTH/EVETH;

– when the quota (Volume/Time/Event Quota) is provisioned in the URR:

– adjust the quota for volume/time/event respectively by subtracting the (volume/time/event) reported usage in the usage report and use it when applying quota related handling, e.g. to drop or buffer the packets, or apply FAR ID for Quota Action (if provisioned) when the quota becomes "0" and to generate the relevant usage report if the corresponding reporting trigger(s)(VOLQU/TIMQU/EVEQU) is set;

– consider no quota left for the URR when the usage report was triggered for the reporting triggers QUHTI and QUVTI; and

– continue to apply the remaining provisioned parameters in the URR and perform the related network resources usage measurement(s), until getting any further instruction from the CP function.

When receiving a new threshold and/or quota from the CP function for a measurement that is already ongoing in the UP function, the UP function shall consider its ongoing measurements counts for the related URR against the new threshold and/or quota to determine when to send its next usage report to the CP function or to apply quota handling, i.e. the UP function shall discard any remaining quota.

At receiving a quota with value set to zero, the UP function shall:

– handle packets based on the FAR associated with the PDR, if the packets match the Application ID(s) or the SDF Filter(s) provisioned in the IE Exempted Application ID for Quota Action or the Exempted SDF Filter for Quota Action;

– apply the FAR identified in the FAR ID for Quota Action IE if the CP function has provisioned it, otherwise the UP function shall stop forwarding packets (or only allow forwarding of some limited user plane traffic, based on operator policy in the UP function); and

– report in a usage report the network resources usage measurement since the last usage report for that URR, if applicable.

When the UP function receives a non-zero quota for the same URR in one subsequent PFCP Session Modification Request message, the UP function shall apply the (normal) FAR associated with the PDR (detecting the application traffic) for the buffered traffic if the FAR ID for Quota Action was set to buffer the application traffic at zero quota (either be provisioned with zero quota earlier or the quota has been exhausted).

NOTE 1: The UP function determines when to send its next usage report to the CP function by deducting from the newly provisioned threshold or quota the traffic it has forwarded since its last usage report. As an example, if the UP function has forwarded 10 Mbytes of traffic since it last usage report to the CP function and the CP function provisions a new volume threshold or quota of 100 Mbytes, the UP function sends its next usage report upon forwarding an additional 90 Mbytes traffic.

NOTE 2: When receiving a new threshold or quota from the CP function for a measurement that is already ongoing in the UP function and if the UP function has already generated the usage report but had not sent it, the UP function can send the usage report before performing the update of the URR.

NOTE 3: A URR with the quota set to 0 can be provisioned when a service data flow is not allowed to start before quota is allocated to the service. See clause 5.4.11.

When reporting the network resources usage before and after a Monitoring Time, the UP function shall send two Usage Reports in the PFCP message (e.g. PFCP Session Report Request) for the same URR ID. Each Usage Report shall then include the Usage Information IE indicating whether the reported network resource usage was consumed before or after the Monitoring Time. Omission of this IE in a Usage Report indicates that no monitoring time has occurred. The UP function shall send Usage Reports soon after the occurrence of the Monitoring Time. For a URR, when multiple (Additional) Monitoring Time IEs are provisioned, or a new Monitoring Time is provisioned after the previous Monitoring Time has passed, the UP function may not be able to send the usage report with the Usage Information set to "AFT" for the previous Monitoring Time if there is no Reporting Trigger armed before the next Monitoring Time is reached; in such case, the UP function may send multiple usage reports with the Usage Information set to "BEF", together with one usage report with the Usage Information set to "AFT".

NOTE 4: The UP function needs to take care to smooth the signalling load towards the CP function if Usage Reports need to be generated for a large number of PFCP sessions after the occurrence of the Monitoring Time.

For the volume-based measurement method, the UP function shall report the traffic usage after any QoS enforcement. Additionally, if the CP function requested to measure the traffic usage before QoS enforcement, the UP function shall also report corresponding measurements, when measurements needs to be reported for the traffic usage after QoS enforcement, by sending two Usage Reports in the PFCP message (e.g. PFCP Session Report Request) for the same URR ID. Each Usage Report shall then include the Usage Information IE indicating whether the reported network resource usage corresponds to the traffic before or after QoS enforcement. Thresholds provisioned in a URR shall apply to the traffic usage after any QoS enforcement.

For the volume-based measurement method, the UP function shall include all the counters (Total, Uplink and Downlink) of the URR in the Volume Measurement IE in the Usage Report IE; the UP function shall also include the number of packets counted for Total, Uplink, Downlink in the Volume Measurement IE if requested by the CP function and if the UP function supports the MNOP feature.

An usage report triggered only due to the Dropped DL Traffic Threshold (DROTH) or Start of Traffic (START), or MAC Address Reporting (MACAR), or IP Multicast Join/Leave (IPMJL) shall not contain any measurement information, i.e. either the Volume/Duration Measurement set to zero or Volume/Duration Measurement IE is not present.

When being instructed to remove a URR or the last PDR associated to a URR, the UP function shall stop its ongoing measurements for the URR and include a Usage Report in the PFCP Session Modification Response or in an additional PFCP Session Report Request if there are non-null measurements to report for the URR. When being instructed to remove the last PDR associated to a URR, the UP function shall keep the URR and reset any measurement for the URR.

NOTE 5: A URR provisioned in a PFCP session can be provisioned/kept in the UP function without being associated with any PDR and the URR can be associated with a PDR in a later stage. The UP function will not remember any remaining quota and will consider the quota (if provisioned) as it was provisioned.

When being instructed to deactivate a network resources usage measurement via the Inactive Measurement flag of the Measurement Information IE of the URR, the UP function shall stop measuring the network resources usage (against the volume/time/event threshold/quota) and store the current measurement counts which will be resumed when the URR is activated again. The UP function shall not generate a usage report upon the deactivation of the URR and it shall send a usage report during the period when the URR is deactivated for the following scenarios:

– if the Quota Holding Time is expired and if the reporting trigger QUHTI is set;

– if the Quota Validity Time is expired and if the reporting trigger QUVTI is set;

NOTE 6: The Quota Holding Time can have been started before the URR is deactivated or starts from the moment when the URR is deactivated since no quota will be consumed.

– if it is the time for a periodic reporting and if the reporting trigger PERIO is set;

– if it is required to send a usage report for this URR when a usage report is reported for a linked URR and if the reporting trigger LIUSA is set;

– if it is required to send an immeditate report upon a query for the URR, or the URR is removed, dissociated from the last PDR;

NOTE 7: Multiple usage reports can be required to be reported to the CP function when deleting a PDR that is the last one to be associated to multiple URRs.

– if the User Plane Inactivity Timer is expired and if the reporting trigger UPINT is set.

NOTE 8: The User Plane Inactivity Timer can have been started before the URR is deactivated.

The CP function may request the UP function, in a PFCP Session Modification Request, to report its ongoing network resources measurement for one or multiple URRs of the PFCP session. In this case, the UP function shall:

– generate usage report(s) (based on the existing definition of any URR(s) included in the PFCP Session Modification Request message before any update) for the URR(s) being queried and for any associated linked usage reports (see clause 5.2.2.4) for which there are non-null measurements to report;

– include them in the PFCP Session Modification Response or in additional PFCP Session Report Request messages; and

– proceed as specified above upon generating a usage report for a URR towards the CP function, with the following additions:

– if the PFCP Session Modification Request includes the Update URR IE (for the URR being queried) with a Volume or Time Threshold, the UP function shall re-apply the threshold received in the request;

– otherwise, if a threshold and/or a quota had been set for the URR that is queried, since the usage report is not triggered due to the threshold being reached, the UP function shall adjust the threshold and/or quota by subtracting the time/volume reported in the usage report to determine when to generate the next report.

NOTE 9: Upon reaching a threshold that was adjusted due to a URR query as specified above, the UP function re-applies then the threshold that was provisioned in the URR (i.e. not the value of the adjusted threshold).

NOTE 10: The CP function can query a URR without including a Volume or Time Threshold in the PFCP Session Modification Request e.g. when it needs to close a traffic volume/service container (see clause 5.2.3.10.3 of 3GPP TS 32.251 [17]).

NOTE 11: The CP function can query a URR including a Volume or Time Threshold in the PFCP Session Modification Request e.g. when it needs to close a CDR (see clause 5.2.3.10.3 of 3GPP TS 32.251 [17]). In such a case, the CP function can include the same threshold for the URR being queried in the Update URR IE in the PFCP Session Modification Request message to trigger the UP function to re-apply the threshold.

NOTE 12: It is up to the CP function to request the UP function to generate an immediate report (or not) as specified above when the CP function modifies a URR or any other rules of the PFCP session. As an exception, the UP function always generates an immediate report when being instructed to remove a URR.

When additional usage reports need to be sent in additional PFCP Session Report Request messages, i.e. when not all usage reports can be included in the PFCP Session Modification Response message, the UP function shall indicate, in the PFCP Session Modification Response message, either:

– that more usage reports will follow, by setting the AURI flag to 1 in the Additional Usage Reports Information IE (see clause 8.2.91); or

– the total number of additional usage reports that will be sent in all the additional PFCP Session Report Request messages (i.e. that will be sent after the PFCP Session Modification/Deletion Response message), by setting this value in the Additional Usage Reports Information IE (see clause 8.2.91).

In the former case (i.e. if the UP function indicates in the PFCP Session Modification Response message that more usage reports will follow), the UP function shall indicate, in one of the additional PFCP Session Report Request message, the total number of additional usage reports to be sent after the PFCP Session Modification Response message, by setting this value in the Additional Usage Reports Information IE. In both cases, the UP function may set the AURI flag to 1 in every additional PFCP Session Report Request message but the last one, to indicate that more usage reports will follow.

Besides, if the PFCP Session Modification Request included the Query URR Reference IE, usage reports sent in response to the query in the PFCP Session Modification Response and/or additional PFCP Session Report Request messages shall include the Query URR Reference IE set to the same value as received in the PFCP Session Modification Request.

When the reporting trigger "Envelope Closure" is set in the corresponding Usage Reporting Rule, the UP function shall generate a usage report with the measurement of the time and/or volume as instructed in the Measurement Method:

– when the Inactivity Detection Time (if included) is expired;

– when detecting no usage for the first Base Time Interval if the Base Time Interval Type in the Time Quota Mechanism is set to CTP; or

– at the end of each of base time interval if the Base Time Interval Type in the Time Quota Mechanism is set to DTP.

NOTE 13: Events (e.g. application detection information) are reported individually and independently from the usage report sent for envelope closure.

When the UP function supports the NORP feature and if a URR is provisioned with a "Number of Reports" IE, the number of Usage Reports generated according to the Reporting Trigger(s) defined in the URR shall not be more than the value of "Number of Reports". If the UP function is requested to resume the measurement for an inactive URR, the UP function shall generate a maximum number of Usage Reports equal to the new value of the Number of Reports IE received in the Update URR if any, or equal to the value of the Number of Reports IE previously provisioned in the URR if any; if no Number of Reports IE was provisioned before, there is no limit on the number of reports to send. If the CP function provisions a "Number of Reports" IE together with a Monitoring Time and/or a Measurement Information where the "Measurement Before QoS Enforcement’ flag is set to "1" in a URR, the UP function shall generate usage reports as required by the Monitoring Time and/or the Measurement Information where the "Measurement Before QoS Enforcement’ flag is set to "1" in a URR, which may lead UP function to generate more usage reports than the value of the "Number of Reports" IE.

NOTE 14: If the CP function expects to receive the exact number of usage reports as requested in the Number of Reports, it can abstain from provisioning a Number of Report IE together with a Monitoring Time and/or a Measurement Information where the "Measurement Before QoS Enforcement’ flag is set to "1" in a URR.

At the PFCP session termination, the UP function shall indicate to the CP function, in the PFCP Session Deletion Response, the resources that have been consumed for each URR that was provisioned in the PFCP session since the last usage report (respective to each URR). A CP function may indicate support of Additional Usage Reports in PFCP Session Deletion Request by setting the ARDR flag in the CP Function Features IE (see clause 8.2.58). When additional PFCP Session Report Request messages need to be sent:

– the UP function shall:

– set the cause to "More Usage Report to send" in the PFCP Session Deletion Response;

– include the Additional Usage Reports Information IE in PFCP Session Deletion Response with either the AURI flag set to "1" or indicating the total number of additional usage reports that will be sent in all the additional PFCP Session Report Request messages; as described above:

– in the former case, the UP function shall indicate in one additional PFCP Session Report Request message the total number of additional usage reports that will be sent after the PFCP Session Deletion Response;

– in both cases, the UP function may set the AURI flag to 1 in every additional PFCP Session Report Request message but the last one, to indicate that more usage reports will follow.

– set the PSDBU flag to 1 in the last PFCP Session Report Request message.

– when the CP function receives a PFCP Session Deletion Response with the Cause set to "More Usage Report to send", the CP function shall not delete the PFCP session until it receives a PFCP Session Report Request message with the PSDBU flag set to "1" (that indicates this is the last report), or it has received the number of usage reports indicated in the Additional Usage Reports Information IE in PFCP Session Deletion Response, or until an implementation specific timer expires otherwise.

At the PFCP session termination, the UP function shall set the PURU flag to "1" in the PFCP Session Deletion Response if it has pending PFCP Session Report Request messages which have not been acknowledged yet. This indicates that the CP function should wait for some time before deleting the PFCP Session.

Upon receiving the Usage Report from the UP function, the CP function may initiate PFCP Session Modification procedure as result of the communication with the PCRF or OCS, as described in clause 5.3 of 3GPP TS 23.214 [2], e.g. by:

– modifying the URR (e.g. changing the Volume/Time threshold, Volume/Time quota, disabling the usage monitoring);

– creating a new FAR (e.g. for redirect) and/or modifying the existing FAR; or

– modifying the QER (s) in the PFCP session.

5.2.2.3.2 Credit pooling

When a URR is received with at least one Aggregated URRs IE included, the UP function:

– shall calculate the traffic usage of the URR by applying the Multiplier(s) and aggregating the traffic usage from all URRs indicated in the Aggregated URRs IE(s), as specified in IETF RFC 4006 [16];

NOTE 1: The usage of this URR is calculated using the following formula:

C1*M1 + C2*M2 + … + Cn*Mn = U,
where U is the usage counted by this URR, Cn is the usage counted by each aggregated URR (i.e. URR for each RG sharing the credit pool), and Mn is the multiplier for each aggregrated URR.

– shall generate a report when the counted usage exceeds the threshold;

– shall generate a report if the threshold is not provided, and stop packets forwarding (or only allow forwarding of some limited user plane traffic, based on operator policy in the UP function) for all Aggregated URRs when the counted usage exceeds the quota.

NOTE 2: The handling of the aggregated URR(s), e.g. generating a Usage Report upon the Reporting Trigger(s) is not impacted by handling of this URR for the Credit Pool.

5.2.2.3.3 Traffic Usage Reporting with Redundant Transmission

The following requirements shall apply when using Redundant Transmission on N3/N9 interfaces or Redundant Transmission at transport layer:

– the UPF shall not count redundant packets in Usage Reports (e.g. Volume Measurement), i.e. it shall count the traffic only once in Usage Reports;

– the SMF shall provide the quota for the non-redundant transmission (i.e. not counting redundant traffic).

5.2.2.4 Reporting of Linked Usage Reports to the CP function

The CP function may instruct the UP function to generate a Usage Report for a URR "X" when a Usage Report is generated for another URR "Y", by:

– provisioning the URR "X" with the Reporting Triggers IE set to Linked Usage Reporting; and

– including in the URR "X" the Linked URR ID IE set to the URR ID of the URR "Y".

NOTE 1: This can be used by the CP function e.g. to request the UP function to report a Usage Report for an SDF (i.e. URR "X") when the UP function reports a Usage Report for a bearer (i.e. URR "Y").

NOTE 2: This can be used by the CP function e.g. to request the UP function to report a Usage Report for a RG (i.e. URR "X") when the UP function reports a Usage Report for a credit pool to which this RG pertain (i.e. URR "Y").

When a usage report is to be generated for the URR "Y", regardless of the condition which triggers the report, the UP function shall also send a Usage Report for the URR "X" with the accumulated usage information, and the Usage Report Trigger IE set to Linked Usage Reporting.

NOTE 3: This also applies e.g. when an immediate usage report is requested for the URR "Y"within a PFCP session Modification Request.

The URR "Y" may be linked to more URRs than just URR "X".

A RG level URR may be linked to IP-CAN bearer level URR as well as IP-CAN Session level URR to enable the CP function to generate a CDR on the different level. In such case, a URR "X" may link to more URRs than just URR "Y".

5.2.2.5 End Marker Reception Reporting

The CP function may request the UP function to report the End Marker reception during UE Triggered Service Request with, or without I-SMF insertion/change/removal procedures (see clauses 4.2.3.2 and 4.23.4.3 in 3GPP TS 23.502 [29]):

– If a new I-UPF is selected by the SMF to replace the old I-UPF, the SMF may provide two PDRs to the new I-UPF, e.g. PDR-1 for DL data from the PSA UPF, where the Apply Action IE in FAR-1 associated with PDR-1 is set to BUFF; and e.g. PDR-2 for receiving the buffered DL data from the old I-UPF, where the Apply Action IE in FAR-2 associated with PDR-2 is set to FORW. In this case, the SMF shall indicate to the new I-UPF to report the reception of the End Marker packet from the old I-UPF, by providing a URR related to PDR-2 with REEMR flag set to 1 in the Reporting Triggers IE, which is included in a Create URR IE within PFCP Session Establishment Request.

– If the SMF removes the old I-UPF but does not replace it with a new I-UPF, then the SMF may provide two PDRs to the PSA UPF, e.g. PDR-3 for receiving DL data across N6, where the Apply Action IE in FAR-3 associated with PDR-3 is set to BUFF; and e.g. PDR-4 for receiving the buffered DL data from the old I-UPF, where the Apply Action IE in FAR-4 associated with PDR-4 is set to FORW. The SMF shall indicate to the PSA UPF to report the reception of the End Marker packet from the old I-UPF, by providing a URR related to PDR-4 with REEMR flag set to 1 in the Reporting Triggers IE which is included in a Create URR IE within PFCP Session Modification Request.

Once the End Marker packet is received from the old I-UPF, the UPF (either new I-UPF or the PSA UPF) shall inform the SMF about this by sending the PFCP Session Report Request with the Usage Report IE containing the usage measurement as instructed in the URR, where EMRRE flag shall be set to 1 in a Usage Report Trigger IE and shall discard the End Marker packet(s). The SMF shall instruct the UPF to start sending the buffered DL data identified by PDR-1 or PDR-3 by sending a PFCP Session Modification Request message, where the Apply Action IE in the FAR-1/FAR-3 related to PDR-1/PDR-3 shall be changed from BUFF to FORW.

5.2.3 Forwarding Action Rule Handling

5.2.3.1 General

The CP function shall provision one and only one FAR for each PDR provisioned in a PFCP session. The FAR provides instructions to the UP function on how to process the packets matching the PDR.

By setting the appropriate flag(s) in the Apply Action IE in the FAR (see clause 8.2.26), the CP function may request the UP function to:

– drop the packets, by setting the DROP flag;

– forward the packets, by setting the FORW flag and by provisioning the Forwarding Parameters providing instructions on how to forward the packets;

– forward the MBS session data:

– using multicast transport, by setting the FSSM flag together with the MBS Multicast Parameters to forward the packets to a Low Layer source specific multicast address; and/or

– using unicast transport by setting the MBSU flag together with one or more MBS Unicast Parameters to forward and replicate the packets towards one or more GTP-U DL tunnels terminated at PSA UPF(s) and/or NG-RAN(s).

– buffer downlink or uplink packets by setting the BUFF flag and by optionally provisioning buffering parameters providing instructions on how to buffer the packets;

– notify the CP function about the arrival of a first DL packet being buffered, by setting the NOCP flag;

– notify the CP function about the first discarded DL packet for each service data flow identified by a PDR, when the CP function requests the UP function to buffer DL packets but the DL Buffering Duration or the DL Buffering Suggested Packet Count is exceeded, or when the CP function requests the UP function to drop DL packets and a packet is discarded directly, by setting the DDPN flag, if the UP function supports the DDDS feature;

– notify the CP function about first buffered DL packet for each service data flow identified by a PDR, by setting the BDPN flag, if the UP function supports the DDDS feature;

– duplicate the packets, by setting the DUPL flag and by provisioning the Duplicating Parameters providing instructions on how to forward the duplicated packets;

– accept or deny UE requests to join an IP multicast group (see clause 5.25), by setting the IPMA or IPMD flag;

– duplicate the packets for redundant transmission (see clause 5.24.2), by setting the DFRT flag and by provisioning the Redundant Transmission Forwarding Parameters IE providing instructions on how to forward the duplicated packets for redundant transmission;

– eliminate duplicate packets used for redundant transmission (see clause 5.24.2), by setting the EDRT flag and by provisioning the Redundant Transmission Detection Parameters IE providing instructions on how to detect the duplicated packets for redundant transmission.

The CP function may request the UP function to duplicate packets that are to be dropped, forwarded or buffered.

The CP function may request the UP function to forward the packets and duplicate the packets for redundant transmission.

The CP function may request the UP function to forward the packets and eliminate duplicate packets used for redundant transmission.

The CP function may provision one or more FAR(s) per PFCP session. Different FARs of a same PFCP session may be provisioned with a different Apply Action flags, e.g. to enable the forwarding of downlink data packets for some PDRs while requesting to buffer downlink data packets for other PDRs.

NOTE 1: This is necessary to establish or release a partial set of radio access bearers in UTRAN.

When instructed to buffer and notify the CP function about the arrival of a DL packet, the UP function shall notify the CP function, when it receives a first downlink packet for a given FAR (in EPC), or when it receives a first downlink packet for each QoS flow for a given FAR (in 5GC), by sending a PFCP Session Report Request including a Downlink Data Report IE identifying the PDR(s) for which downlink packets have been received.

NOTE 2: Receipt of downlink packets on PDRs associated to different FARs can result in sending multiple PFCP Session Report Request messages for the same PFCP session.

NOTE 3: Receipt of downlink packets pertaining to different QoS flows associated to the same FAR can result in sending multiple PFCP Session Report Request messages for the same PFCP session. The CP function identifies the QFI based on the PDR ID (when different PDRs are used for different QoS flows) or based on the Downlink Data Service Information IE.

NOTE 4: The end marker packet is not considered as DL data packet so that it does not trigger the UP function to notify the CP function about the arrival of a DL packet. The UP function can discard the received end marker packet(s) silently, when it is not possible to be forwarded.

If the UP function indicated support of Header Enrichment of UL traffic (see clause 8.2.25), the CP function may provide the UP function with header enrichment information for uplink traffic, by including one or more Header Enrichment IE(s) in the FAR. In this case, the UP function should use this information to enrich the header of the uplink traffic (e.g. HTTP header enrichment).

NOTE 5: It is not defined how to support SGi PtP tunnelling mechanisms other than based on UDP/IP encapsulation (such as PMIPv6/GRE, L2TP, GTP-C/U, see clause 4.3.17.8.3.3.3 of 3GPP TS 23.401 [14]) for Non-IP PDN connections.

If the UP function indicated support of PDI optimisation (see clause 8.2.25), the CP function may include in the forwarding parameters of the FAR the Linked Traffic Endpoint ID, if it is available, identifying the traffic Endpoint allocated for this PFCP session to receive the traffic in the reverse direction.

NOTE 6: This information can enable an SGW-U or PGW-U to correlate the UL and DL traffic (i.e. PDRs) sent over a same bearer.

Assuming for instance a PFCP session provisioned in a PGW-U with:

– an UL PDR 1 (for an S5/S8 bearer 1) with Source Interface "Access" associated to an UL Traffic Endpoint ID "1" (comprising the IP address, a local TEID and optionally a network instance),

– a DL PDR 1 with Source Interface "Core", UE IP address and SDF 1,

the CP function sets the Linked Traffic Endpoint in the DL FAR 1 (associated to DL PDR 1) to the UL Traffic Endpoint "1", which allows the PGW-U to correlate the uplink and downlink PDRs for the same bearer (i.e. that UL PDR 1 associated to UL Traffic Endpoint "1", and DL PDR1 associated to DL FAR 1 with Linked Traffic Endpoint set to UL Traffic Endpoint "1", use the same S5/S8 bearer).

NOTE 7: The Linked Traffic Endpoint can possibly refer to a Traffic Endpoint in the reverse direction requested to be created in the same PFCP request.

5.2.4 Buffering Action Rule Handling

5.2.4.1 General

A BAR provides instructions to control the buffering behaviour of the UP function for all the FARs of the PFCP session set with an Apply Action parameter requesting the packets to be buffered and associated to this BAR.

The CP function may create a BAR for a PFCP session and associate it to the FAR(s) of the PFCP session in a PFCP Session Establishment Request or a PFCP Session Modification Request to request the UP function to apply a specific buffering behaviour for packets requested to be buffered and associated to this BAR.

The CP function may modify the following buffering instructions provided in a BAR as follows:

– the Downlink Data Notification Delay in a PFCP Session Modification Request (for EPC); or

– the Downlink Data Notification Delay (for EPC), DL Buffering Duration and/or DL Buffering Suggested Packet Count in a PFCP Session Report Response message.

NOTE: The CP function needs to provision a (possibly empty) BAR and associate it to the FARs of the PFCP session when establishing or modifying the PFCP session to be able to modify the BAR in a PFCP Session Report Response.

If the UP Function has indicated support of the feature UL/DL Buffering Control (UDBC), the CP function may provide the Suggested Buffering Packet Count IE in a BAR which is created during a PFCP Session Establishment procedure or a PFCP Session Modification procedure, and the CP function may modify it in a subsequent PFCP Session Modification Request, and/or a PFCP Session Report Response message. The same BAR may be associated with all the FARs in a PFCP session to indicate that all Service Data Flows in the PFCP Session share the same buffer in the UP function for the PFCP Session.

If the SGW-U has indicated support of the feature MT-EDT, the CP function may provide the MT-EDT (Mobile Terminated Early Data Transmission) Control Information IE in a BAR when it is created and modified, to request the SGW-U to report the sum of DL Data Packets Size in byte when sending Downlink Data Report.

In this release of the specification, at most one BAR may be created per PFCP session.

5.2.4.2 Provisioning of Buffering Action Rule in the UP function

The CP function may provision the following buffering parameters in a BAR:

– For EPC, the Downlink Data Notification Delay IE, to request the UP function to delay the sending of a PFCP Session Report Request, between receiving a downlink data packet and notifying the CP function about it, if the UP function indicated support of the Downlink Data Notification Delay parameter (see clause 8.2.28);

– the DL Buffering Duration IE, to request the UP function to buffer the downlink data packet for an extended duration without sending any further notification to the CP function about the arrival of DL data packets, if the UP function indicated support of the DL Buffering Duration parameter (see clause 8.2.25);

– the DL Buffering Suggested Packet Count, to request the UP function to buffer the suggested number of downlink data packets, when extended buffering of downlink data packet is required in the UP function;

– the Suggested Buffering Packet Count IE if the UP Function has indicated support of the feature UDBC, to indicate the number of packets (including both uplink or downlink) that the CP function suggests to be buffered in the UP function, until it receives new instructions from the CP function, e.g. when the new Quota is granted.

The UP function shall stop applying the DL Buffering Duration and DL Buffering Suggested Packet Count parameters and shall delete these parameters from the BAR (without explicit request from the CP function) when extended buffering of downlink data packets ends in the UP function.

NOTE: The CP function will provide the DL Buffering Duration and DL Buffering Suggested Packet Count parameters again when re-invoking extended buffering of downlink data packets.

The UP function shall stop applying buffering when new instruction is received from the CP function. The buffered packets shall be either dropped or forwarded following the packet forwarding model specified in clause 5.2.1 and taking into consideration that the buffered Packets have been already processed earlier.

5.2.5 QoS Enforcement Rule Handling

5.2.5.1 General

The CP function shall provision QER(s) for a PFCP session in a PFCP Session Establishment Request or a PFCP Session Modification Request to request the UP function to perform QoS enforcement of the user plane traffic.

5.2.5.2 Provisioning of QoS Enforcement Rule in the UP function

The CP function may request the UP function to perform the following QoS enforcement actions in a QER:

– Gating Control, as specified in clause 5.4.3;

– QoS Control, i.e. MBR, GBR or Packet Rate enforcement, as specified in clause 5.4.4;

– DL flow level marking for application detection, as specified in clause 5.4.5;

– SCI (Service Class Indicator) marking for service identification for improved radio utilisation for GERAN, as specified in clause 5.4.12;

– for 5GC reflective QoS for uplink traffic.

5.2.5.3 Reflective QoS (for 5GC)

The 5GS may support Reflective QoS functionality (see clauses 5.7.5 in 3GPP TS 23.501 [28]).

When the 5GC determines to use Reflective QoS for a specific SDF, the SMF shall set the Reflective QoS Indication (RQI) bit to 1 in the QER associated to the DL PDR for this SDF in a PFCP Session Establishment Request or PFCP Session Modification Request message.

The SMF may also provision the UPF to perform uplink QoS flow binding verification for the specific SDF as specified in clause 5.4.2.

When the 5GC determines to no longer use Reflective QoS for a specific SDF, the SMF shall request the UPF to stop applying Reflective QoS for the corresponding downlink traffic, e.g. by setting the Reflective QoS Indication (RQI) bit to 0 in the QER that is associated to the DL PDR or by dissociating the QER from the DL PDR (as appropriate) in a PFCP Session Modification Request message.

If the SMF had provisioned the UPF to perform uplink QoS flow binding verification for the specific SDF, after an operator configurable time, the SMF shall update the UL PDR(s) to no longer perform uplink QoS flow binding verification for the corresponding uplink traffic and QFI.

5.2.6 Combined SGW/PGW Architecture

The usage of a combined SGW/PGW remains possible in a deployment with separated control and user planes, see clause 4.2.2 of 3GPP TS 23.214 [2]. This is enabled by supporting a combined Sxa/Sxb interface with a common packet forwarding model, message and parameter structure for non-combined and combined cases.

The following additional requirements shall apply to a combined Sxa/Sxb interface between a combined SGW/PGW-C and a combined SGW/PGW-U:

– all the functionalities specified for Sxa and Sxb shall be supported, possibly concurrently, over a combined Sxa/Sxb association;

– a single PFCP session may be setup to support both the functionalities of an SGW-U and PGW-U;

– the CP function may provision PDRs, QERs, URRs, FARs (possibly with a buffering instruction) and BAR, possibly concurrently, for the same PFCP session;

– the CP function may provision concurrently parameters in a message or for the PFCP session that are applicable to Sxa and Sxb.

5.2.7 Multi-Access Rule Handling (for 5GC)

5.2.7.1 General

The UP function (i.e. the UPF) shall support the Multi-Access Rule (MAR) if it supports the ATSSS feature (see MPTCP and ATSSS-LL flags in UP Function Features, Table 8.2.25-1).

The CP function (i.e. the SMF) shall provision in the UP function acting as the PDU Session Anchor (PSA) and supporting the ATSSS feature, one and only one MAR for every downlink PDR corresponding to non-GBR traffic of a PFCP session that is established for a Multi-Access (MA) PDU session.

The MAR provides instructions to the UP function on how to forward the packets matching the PDR over 3GPP and non-3GPP accesses. See clauses 5.8.2.11.8 and 5.32.8 in 3GPP TS 23.501 [28].

In an MAR, the CP function (i.e. the SMF) shall:

– instruct the UPF which traffic steering functionality to use, i.e. MPTCP or ATSSS-LL, using the Steering Functionality IE (see clause 8.2.124);

– set the Steering Mode to instruct how the packets shall be distributed across 3GPP and non-3GPP accesses, e.g. Active-Standby, Smallest Delay, Load Balancing and Priority Based (see clause 8.2.125);

– provision access specific forwarding action information including:

– a FAR ID which control the packets forwarding either to 3GPP access or non-3GPP access;

– a Weight to indicate the proportion of traffic to be forwarded by the given FAR when the Steering Mode is set to "Load Sharing";

– a Priority to indicate at which condition the traffic is to be forwarded by the given FAR when the Steering Mode is set to "Active-Standby" or "Priority-Based";

– a list of URR IDs to enable the SMF to request separate usage report for different accesses.

As specified in clause 5.32.8 of 3GPP TS 23.501 [28], in an MAR, the CP function (i.e. the SMF) may:

– provision Threshold values, including RTT and/or Packet Loss Rate, if the Steering Mode is Load Balancing with fixed split percentages or Priority-based;

– include a Steering Mode Indicator to indicate that the default steering parameters provided in the Steering Mode may be adjusted:

– set autonomous load-balance flag to allow the UPF to adjust the traffic steering based on its own decisions when the Steering Mode is Load Balancing; or

– set UE-assistance flag to allow the UPF to adjust the traffic steering based on the UE Assistance Data from UE when the Steering Mode is Load Balancing.

NOTE: The autonomous load-balance flag and the UE-assistance flag can not be set to "1" at the same time.

The CP function may provision one or more MAR(s) (for different PDRs) per PFCP session. Different MARs of a same PFCP session may be provisioned with a different steering functionality and/or a different steering mode. Different MARs of a same PFCP session may be associated with the same FAR(s).

If a UE indicates it supports MPTCP and ATSSS-LL, and if the network determines to apply both MPTCP functionality and ATSSS-LL functionality for the UE’s PDU session, the CP function shall provision separate downlink PDRs for MPTCP traffic and for Non-MPTCP traffic. Correspondingly, different MARs shall be provisioned and associated with the separate downlink PDRs. The steering functionality shall be set to ATSSS-LL for the MAR associated with the downlink PDR for non MPTCP traffic.

The UP function shall distribute the downlink traffic across the two access networks (and the two N3/N9 tunnels) according to the instructions received in the MAR and feedback information received from the UE via the user plane (e.g. access network Unavailability or Availability reports for ATSSS-LL received by PMF, see 3GPP TS 24.193 [59]).

If the autonomous load-balance is set in the Steering Mode Indicator, the Weight shall be treated as the default percentages, and the UPF may autonomously determine its own percentages for traffic splitting to maximize the aggregated bandwidth in the downlink direction. If the UE-assistance is set in the Steering Mode Indicator, the UE may inform the UPF on how it decided to distribute the UL traffic of the matching SDF.

5.2.8 Session Reporting Rule Handling

5.2.8.1 General

The CP function may provision SRR(s) for a PFCP session in a PFCP Session Establishment Request or a PFCP Session Modification Request to request the UP function to detect and report events for a PFCP session that are not related to specific PDRs of the PFCP session or that are not related to traffic usage measurement.

– Change of 3GPP or non-3GPP access availability, for an MA PDU session (see clause 5.20.4.2).

– Reporting the per QoS flow per UE QoS Monitoring Report, as specified in clause 5.33.3.2 of 3GPP TS 23.501 [28].

5.2.8.2 Provisioning of Session Reporting Rule in the UP function

5.2.8.2.1 General

When provisioning an SRR, the CP function shall provide control information identifying the events that the UPF is requested to detect and report. If Direct Reporting of QoS monitoring events to Local NEF or AF is supported and required, the CP function shall also provide Direct Reporting Information in the SRR (see clause 5.33.5).

The CP function may modify an SRR in the PFCP Session Modification Request message.

The CP function may request the UP function to stop the detection and reporting of specific events by removing the SRR or, if the SRR is used to control different types of events, by updating the SRR with a control information IE for the events to stop with a null length. When so instructed, the UP function shall stop detecting and reporting the corresponding events.

5.2.8.3 Reporting of Session Report to the CP function

5.2.8.3.1 General

When detecting that a provisioned event to report occurs, the UP function shall generate a Session Report for the related SRR and send it to the CP function by initiating the PFCP Session Report procedure, unless Direct Reporting of QoS monitoring events to Local NEF or AF applies (see clause 5.33.5).

Upon generating a session report for an SRR towards the CP function or towards the Local NEF or AF if Direct Reporting of QoS monitoring event applies, the UP function shall continue to apply all the provisioned SRR(s), until getting any further instruction from the CP function.

5.2.9 Handling of Rules that cannot be activated

The CP function shall indicate support of the Partial Success (PSUCC) feature (see clause 8.2.58) during the PFCP association setup or update procedure, if it supports PFCP session establishment or modification with Partial Success, i.e. with the UP function partially accepting a PFCP session establishment or modification request when some rules requested to be created or modified cannot be applied, e.g. when a pre-defined rule name or pre-defined rule ID is not configured in the UP function.

If the CP function indicated support of the the PSUCC feature, and if this feature is also supported by the UP function, the UP function should partially accept a PFCP session establishment or modification request, if possible, even when it fails to create or modify one or more rules. In such a case, the UP function shall set the cause to "Request partially accepted" in the response and include the Partial Failure Information IE identifying the rules that the UP function could not activate and the cause of the failure.

NOTE: Partial acceptance of a request is not possible in some cases, when the failure to activate a rule would result in a PFCP session state that is not consistent, e.g. if no PDR or FAR would end up being activated for the PFCP session. Details on the conditions when a request can be partially accepted or not are left to UP function implementation.

Upon receipt of a PFCP session establishment or modification response indicating a partial acceptance of the request, the CP function shall consider that not all rules were successfully activated in the UP function and determine those which failed to be activated based on the Partial Failure Information IE in the response.

If the CP function or the UP function does not support the PSUCC feature, the UP function shall reject a PFCP session establishment or modification request if at least one rule fails to be applied.