5.4 Policy and Charging Control

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

5.4.1 General

This clause describe how Policy and Charging Control requirements are supported over the Sxa, Sxb, Sxc and N4 reference points.

5.4.2 Service Detection and Bearer/QoS Flow Binding

Service detection refers to the process that identifies the packets belonging to a service data flow or application. For EPC, see clauses 6.2.2.2 and 6.8.1 of 3GPP TS 23.203 [7]. For 5GC, see clause 6.2.2.2 of 3GPP TS 23.503 [44].

For EPC, bearer binding is the procedure that associates service data flow(s) to an IP-CAN bearer deemed to transport the service data flow. UL bearer binding verification refers to the process of discarding uplink packets due to no matching service data flow template for the uplink direction. See clauses 6.1.1.4 and 6.2.2.2 of 3GPP TS 23.203 [7].

For 5GC, QoS flow binding is the procedure that associates service data flow(s) to a QoS flow deemed to transport the service data flow. UL QoS flow binding verification refers to the process of discarding uplink packets due to no matching QoS flow for the uplink direction. See clause 6.1.3.2.4 of 3GPP TS 23.503 [44] and clause 5.7.1.7 of 3GPP TS 23.501 [28].

For 5MBS, QoS flow binding is the procedure that associates a PCC rule to a QoS Flow within an MBS Session. See clause 6.10 in 3GPP TS 23.247 [72].

Service detection is controlled over the Sxa, Sxb, Sxc and N4 reference points by configuring Packet Detection Information in PDRs to match the intended service data flows or application.

For EPC, the mapping of DL traffic to bearers is achieved by configuring and associating FARs to the downlink PDRs, with FARs set to forward the packets to the appropriate downstream bearers (S5/S8 or S1/S12/S4/Iu).

For 5GC, the mapping of DL traffic to QoS flows is achieved by configuring QERs with QFI(s) for the QoS flow marking and associating FARs to the downlink PDRs, with FARs set to forward the packets to the appropriate downstream GTP-U tunnel (N9 or N3).

For EPC, uplink bearer binding verification is achieved by configuring Packet Detection Information in uplink PDRs containing the local F-TEID of the uplink bearer, the UE IP address (source IP address to match for the incoming packet), and the SDF filter(s) or the Application ID. As a result, uplink packets received on the uplink bearer but that do not match the SDF filter(s) or Application detection filter associated to the uplink PDRs are discarded.

For 5GC, uplink QoS flow binding verification (see clause 5.7.1.7 of 3GPP TS 23.501 [28]) is achieved by configuring Packet Detection Information in uplink PDRs containing the local F-TEID of the uplink PDU session, the UE IP address (source IP address to match for the incoming packet), the QFI of the QoS flow and the SDF filter(s) or the Application ID. As a result, uplink packets received on the uplink PDU session but that do not match the SDF filter(s) or Application detection filter and QFI associated to the uplink PDRs are discarded.

NOTE 1: For PCC Rules that contain an application identifier (i.e. that refer to an application detection filter), uplink traffic can be received on other IP-CAN bearers than the one determined by the binding mechanism. The detection of the uplink part of the service data flow can be activated in parallel on other bearers with non-GBR QCI (e.g. the default bearer) in addition to the bearer where the PCC rule is bound to. See clauses 6.1.1.1 and 6.2.2.2 of 3GPP TS 23.203 [7]. Therefore the uplink PDRs for these bearers can be provisioned with the PDI containing this service data flow and the local F-TEID of the uplink bearer.

NOTE 2: To avoid the PGW-U discarding packets due to no matching service data flow template, the operator can apply open PCC rules (with wildcarded SDF filters) to allow for the passage of packets that do not match any other candidate SDF template. Therefore an uplink PDR can be provisioned with the PDI containing only the local F-TEID of the uplink bearer.

NOTE 3: Uplink bearer binding does not apply to Non-IP PDN connections.

NOTE 4: The UPF can be provisioned with a PDR (with low precedence) which contains the CN tunnel info, QFI and filter information that can detect any unwanted/unauthorized traffic with this QFI so that such traffic can be dropped with or without being counted before.

5.4.3 Gating Control

Gating control refers to the process within the user plane function (i.e. PGW-U and TDF-U for EPC, UPF for 5GC) of enabling or disabling the forwarding of IP packets, belonging to a service data flow or detected application’s traffic, to pass through to the desired endpoint (for EPC see clause 4.3.2 of 3GPP TS 23.203 [7] and for 5GC see clause 4.3.3.1 of 3GPP TS 23.503 [44]).

The PGW-C and TDF-C (for EPC) and the SMF (for 5GC) controls the gating in the PGW-U and TDF-U (for EPC) and in the UPF (for 5GC) by creating PDR(s) for the service data flow(s) or application’s traffic to be detected, and by associating a QER, including the Gate Status IE, to the PDRs.

The Gate Status IE indicates whether the service data flow or detected application traffic is allowed to be forwarded (the gate is open) or shall be discarded (the gate is closed) in the uplink and/or in downlink directions.

The PGW-U and TDF-U (for EPC) and the UPF (for 5GC) shall identify UL and DL flows by the Source Interface IE in the PDI of the PDRs or the Destination Interface IE in the FARs. The PGW-U and TDF-U (for EPC) and the UPF (for 5GC) shall apply UL and DL gating accordingly.

The UP function shall discard packets matching a PDR if the PDR is associated with at least one QER provisioned with the Gate Status set to CLOSED.

5.4.4 QoS Control

QoS control refers to the authorization and enforcement of the maximum QoS that is authorized:

– for EPC,

– at the session level (APN-AMBR, TDF session UL and DL bitrates, or UL and DL Packet Rate of a PDN connection);

– at the bearer level (GBR, MBR for GBR bearers);

– at the service data flow (SDF) or application level.

– for 5GC,

– at the session level (Session-AMBR or UL and DL Packet Rate of a PDU session);

– at the QoS Flow level;

– at the service data flow (SDF) or application level.

See clause 4.3.3 of 3GPP TS 23.203 [7] clause 4.5.5 of 3GPP TS 29.212 [8] and clause 4.7.7 of 3GPP TS 23.401 [14].

The CP function shall control the QoS enforcement in the UP function by:

– creating the necessary PDR(s) to represent the service data flow, application, QoS Flow (for 5GC), bearer or session, if not already existing;

– creating QERs for the QoS enforcement at session level, SDF/application level;

– creating QERs for the QoS enforcement of the aggregate of SDFs with the same GBR QCI;

– creating QERs for the QoS enforcement of the aggregate of SDFs with the same GBR QFI (for 5GC);

– associating the session level QER to all the PDRs defined for the session;

– associating the SDF or application QER to the PDRs associated to the SDF or application;

– associating the QER of the aggregate of SDFs to the PDRs associated to SDFs or applications that share the QER.

The same QER may be associated to UL and DL PDRs. The UP function shall identify the UL and DL flows by the Source Interface IE in the PDRs or the Destination Interface IE in the FARs. The UP function shall enforce the QoS for the UL or DL flows accordingly.

The CP function shall map the precedence of a PCC rule to the precedence of the PDRs associated to the corresponding service data flows.

5.4.5 DL Flow Level Marking for Application Detection

DL flow level marking is performed using DL DSCP marking. DL DSCP marking for application indication refers to the process in the TDF of marking detected downlink application traffic with a DSCP value received within an installed ADC rule matching this traffic. See Annex U of 3GPP TS 23.203 [7] and clauses 4.5.2.7 and 4b.5.14 of 3GPP TS 29.212 [8].

DL DSCP marking for application indication is controlled by the TDF-C by associating a QER, including the ToS or Traffic Class within the DL Flow Level Marking IE, to the PDR matching the DL traffic to be marked. The TDF-U performs the DL DSCP marking for the detected DL traffic and sends the marked packet to the PGW-U.

If a tunnelling protocol is used between the TDF-U and the PGW-U, the DSCP value for service data flow detection shall be carried in the inner IP header.

The TDF-C may stop the DL DSCP marking for the application during the PFCP session by removing the related QER or removing the DL Flow Level Marking IE from the related QER, the TDF-U shall then stop such function consequently.

Policy and charging control in the downlink direction by the PCEF for an application detected by the TDF is performed by the PGW-C configuring a PDR with a PDI containing an SDF Filter with the corresponding DSCP value.

5.4.6 Usage Monitoring

Usage Monitoring Control refers to the process of monitoring the user plane traffic in the PGW-U, TDF-U or UPF for the accumulated usage of network resources per:

– individual or group of service data flows;

– individual or group of applications;

– PDU session, possibly excluding an individual SDF or a group of service data flow(s) (for 5GC);

– IP-CAN session, possibly excluding an individual SDF or a group of service data flow(s) (for EPC); and/or

– TDF session, possibly excluding an individual application or a group of application(s) (for EPC).

For EPC, see clauses 4.4, 6.2.2.3 and 6.6 of 3GPP TS 23.203 [7] and clauses 4.5.16, 4.5.17, 4b.5.6, 4b.5.7 of 3GPP TS 29.212 [8].

For 5GC, see clauses 4.3.4 and 6.2.2.3 of 3GPP TS 23.503 [44] and clauses 4.2.2.10, 4.2.3.11, 4.2.4.10, 4.2.6.2.5, 4.2.6.5.3 of 3GPP TS 29.512 [41].

Usage Monitoring Control is supported over the Sxb, Sxc and N4 reference points by activating in the UP function the reporting of usage information towards the CP function, as specified in clauses 5.3 and 7.8.4 of 3GPP TS 23.214 [2] and in clause 5.8.2.6.2 of 3GPP TS 23.501 [28].

The CP function shall control the Usage Reporting in the UP function by:

– creating the necessary PDR(s) to represent the service data flow, application or session;

– creating a URR for each Monitoring key; and

– associating the URR to:

– all the PDRs of the PFCP session, for usage monitoring at IP-CAN or TDF session level, possibly excluding the PDRs matching the SDFs or Applications excluded from the usage monitoring at session level; or

– the PDR(s) of the PFCP session associated to the individual or group of SDF(s) or Application(s), for usage monitoring at SDF or application level.

5.4.7 Traffic Redirection

Traffic Redirection refers to the process of redirecting uplink application traffic, in a PGW, TDF or UPF, towards a redirect destination, e.g. redirect some HTTP flows to a service provisioning page. For EPC, see clause 6.1.13 of 3GPP TS 23.203 [7] and clauses 4.5.2.6 and 4b.5.1.4 of 3GPP TS 29.212 [8]. For 5GC, see clause 6.1.3.12 of 3GPP TS 23.503 [44] and clause 4.2.6.2.4 of 3GPP TS 29.512 [46].

The redirect destination may be provided by the PCRF/PCF or be preconfigured in the CP function or in the UP function.

For EPC and5GC, the traffic redirection shall be enforced in the UP function. If the traffic that the UP function can support may be subject to traffic redirection, traffic redirection enforcement in the UP function shall be supported by the UP function. The UP function reports to the CP function whether it supports traffic redirection enforcement in the UP function via the UP Function Features IE (see clause 8.2.25).

NOTE: A UP function that supports traffic not requiring traffic redirection does not need to support traffic redirection enforcement in the UP function. The CP function can select a UP function supporting traffic redirection enforcement in the UP function for users or services which may require traffic redirection.

To enforce the traffic redirection in the UP function, the CP function shall:

– create the necessary PDR(s) to represent the traffic to be redirected, if not already existing;

– create a FAR with:

– the Redirect Information IE including the redirect destination, if the traffic needs to be redirected towards a redirect destination provided by the CP function; a redirect destination provided by the CP function shall prevail over a redirect destination preconfigured in the UP function;

– For HTTP traffic redirection, the Redirection Address Type shall be set to "URL" and the CP function shall set the Destination Interface IE in the FAR to "Access" (to forward the HTTP response message with a status code indicating redirect). For other types of traffic redirection, the Destination Interface IE in the FAR may be set to "Core";

or

– the Forwarding Policy IE including the identifier of the forwarding policy to apply, if the traffic needs to be redirected towards a redirect destination preconfigured in the UP function;

– associate the FAR to the above PDRs of the PFCP session.

5.4.8 Traffic Steering

Traffic Steering refers to the process of applying a specific (S)Gi-LAN traffic steering policy in the PCEF or TDF (or TSSF), or a specific N6-LAN traffic steering policy in the UPF (PDU Session Anchor), for the purpose of steering the subscriber’s traffic to appropriate operator or 3rd party service functions (e.g. NAT, antimalware, parental control, DDoS protection) in the (S)Gi-LAN or N6-LAN, per service data flows level or applications level.

Application Function influencing traffic routing (see clause 5.6.7 of 3GPP TS 23.501 [28]) also uses traffic steering for the purpose of steering the subscriber’s traffic over N6, e.g. to a local access to a Data Network.

The UP function shall set the TRST feature flag in the UP Function Features IE if it supports Traffic Steering (see clause 8.2.25).

Traffic Steering is supported over the Sxb, Sxc and N4 reference points by instructing the UP function to apply a specific Forwarding Policy, that is locally configured in the UP function and that can be used for the uplink, the downlink or for both directions. A Forwarding Policy is identified by a Forwarding Policy Identifier. Traffic steering is alternatively supported over the N4 reference point by instructing the UP function to route packets according to N6 routing information in the FAR (e.g. providing an IP address in the Outer Header Creation).

When so instructed, the UP function shall perform the necessary actions to enforce the forwarding policy referenced by the CP function, e.g. performing packet marking and routing the traffic towards the service functions within the (S)Gi-LAN or N6-LAN.

See 3GPP TS 23.203 [7], 3GPP TS 29.212 [8] and 3GPP TS 23.501 [28].

The CP function shall control Traffic Steering towards SGi-LAN, N6-LAN or N6 in the UP function by:

– creating the necessary PDRs to represent the service data flows or applications to be steered;

– creating a FAR with the Forwarding Policy IE including the Forwarding Policy Identifier set to the Traffic Steering Policy Identifier, or creating a FAR with a Outer Header Creation with the destination IP address; and

– associating the FAR to the above PDRs of the PFCP session.

The CP function shall control the processing of the traffic received from the (S)Gi-LAN or N6-LAN in the UP function as specified in the rest of this specification for traffic received from any other interface, but with PDR(s) including a PDI with the Source Interface indicating "SGi-LAN/N6-LAN". The UP function shall distinguish packets coming from (S)Gi-LAN/N6-LAN based on local configuration.

5.4.9 Provisioning of Predefined PCC/ADC Rules

A Predefined PCC rule is preconfigured in the PCEF, e.g. a PGW (for EPC) or SMF (for 5GC). Predefined PCC rules can be activated or deactivated by the PCRF/PCF at any time. The Predefined PCC rules may be grouped allowing the PCRF/PCF to dynamically activate a set of PCC rules.

For EPC a predefined ADC rule is preconfigured in the TDF. In the case of solicited reporting, the Predefined ADC rules can be activated or deactivated by the PCRF at any time. Predefined ADC rules within the TDF may be grouped allowing the PCRF to dynamically activate a set of ADC rules.

For the definition of PCC and ADC rules see clauses 4.3.1 and 4b.3.2 of 3GPP TS 29.212 [8] and clause 5.6.2.6 of 3GPP TS 29.512 [41].

The CP function may enforce an activated predefined PCC or ADC rule by the PCRF/PCF in the UP function by:

– determining the service data filters or application IDs referred by the activated predefined PCC or ADC rule(s) and the corresponding QoS and charging control information respectively;

– creating the necessary PDR(s) to identify the service data flow(s), application(s) that the predefined PCC or ADC rule refer to, if not already existing;

– creating the necessary QER for the QoS enforcement at service data flow or application level accordingly;

– creating the necessary FAR if a new FAR needs to be created as result of Bearer binding (for EPC) or QoS flow binding (for 5GC) and QoS control for forwarding the detected service data flow or application traffic, or to redirect or to apply traffic steering control if included in the predefined PCC/ADC rule;

– creating the necessary URR(s) for each monitoring key, charging key, combination of Charging Key and Service ID, or combination of Charging Key, Sponsor ID and Application Service Provider Id if included in the predefined PCC or ADC rule;

and then:

– associating the created URR(s) to the newly created PDR(s);

– associating the existing FAR or the new FAR to the newly created PDR(s);

Optionally, the traffic handling policies common to many PFCP sessions (i.e. predefined PDR(s) / QER(s) / FAR(s) / URR(s)) may be configured in the UP function. The CP function may activate these traffic handling policies by including the Activate Predefined Rules IE or by including predefined FAR/URR/QER ID(s) (of which the most significant bit is set to "1") within:

– the Create PDR IE in an PFCP Session Establishment Request; or

– the Update PDR IE in an PFCP Session Modification Request.

If the CP function activates the traffic handling policies by including predefined FAR/URR/QER ID(s), i.e. where bit 8 is set to "1", then Create/Update FAR/URR/QER IE(s) that shares the same ID shall not be present.

If the received Create/Update PDR IE contains both the Activate Predefined Rules IE and a predefined FAR/URR/QER ID (bit 8 set to "1"), it is an implementation matter how the UPF handles the message. The UPF shall either overwrite the FAR/URR/QER referenced by the Activate Predefined Rules IE with those referenced by the received FAR/URR/QER ID, or reject the message with the Cause value "Rule creation/modification Failure" and the Failed Rule ID IE (see clause 8.2.1).

NOTE 1: The Create/Update PDR IE can contain only dynamic FAR/URR/QER ID. Such dynamic rules provision the UPF with information that was not preconfigured, e.g. with a remote GTP-U F-TEID.

For traffic matching PDR(s) associated with the activated predefined rules, the UP function shall enforce the rules, e.g. for URR, the UP function shall generate Usage Report(s) and send it to the CP function and the CP function shall be able to handle the usage reports as described in clause 5.2.2.

NOTE 2: The URR IDs used in reports triggered by a predefined rule in UP function are also pre-configured at the CP function.

The URR ID used in the usage report may be a predefined URR ID or a URR ID dynamically provisioned by the CP function.

For deactivating predefined rules which have been activated in the UP function using a Predefined Rule Name, the CP function shall include the Deactivate Predefined Rules IE in the Update PDR IE in a PFCP Session Modification Request to inform the UP function to deactivate the corresponding predefined rules for the related PDR.

For deactivating predefined FAR(s) /URR(s) / QER(s) which have been activated in the UP function by including predefined FAR/URR/QER ID(s) in the Create PDR IE or Update PDR IE, the CP function may include Remove FAR IE(s), Remove URR IE(s) and/or Remove QER IE(s) to delete the corresponding predefined FAR/URR/QER ID in an PFCP Session Modification Request message.

NOTE 3: Using Remove FAR IE(s), Remove URR IE(s) and Remove QER IE(s) does not result in any change to predefined rules that was activated using the Activate Predefined Rules IE. Such predefined rules continue to apply if still activated for the PDR.

5.4.10 Charging

For EPC, the charging requirements for online and offline charging in the PS domain specified in 3GPP TS 32.251 [17] shall be preserved with a split SGW, PGW and TDF architecture.

For 5GC, the charging requirements for online and offline charging in the 5G data connectivity domain are specified in 3GPP TS 32.255 [45].

Charging is supported by the CP function by activating in the UP function the measurement and reporting of the accumulated usage of network resources per:

– for EPC:

– IP-CAN bearer, for an SGW;

– IP-CAN bearer, IP-CAN session and/or individual or group of service data flows, for a PGW;

– TDF session and/or individual or group of applications, for a TDF;

– for 5GC:

– PDU session and/or individual or group of service data flows, for an SMF;

– QoS Flow, for an SMF.

See clauses 5.3 and 7.8.4 of 3GPP TS 23.214 [2].

The CP function shall control the usage measurement and reporting in the UP function by:

– creating the necessary PDR(s) to represent the service data flow, application, bearer or session, if not already existing;

– creating URR(s) for each Charging Key, combination of Charging Key and Service ID, or combination of Charging Key, Sponsor ID and Application Service Provider Id;

– associating the URR(s) to the relevant PDRs defined for the PFCP session, for usage reporting at IP-CAN bearer, IP-CAN session, TDF session, SDF or application level.

For online charging, the CP function shall provision the URR with the Volume (or Time) Quota, and with the Volume (or Time) Quota if a quota threshold was received from the OCS, as specified in clause 5.2.2.2. Besides, when the OCS provides a final quota and requests to redirect the traffic towards a redirect destination when exhausing this quota, the CP function shall redirect the traffic towards a redirect destination as specified in clause 5.4.7 upon being notified that the final quota has been reached; to permit HTTP traffic redirection, the UP function should have at least one HTTP packet, e.g. the UP function may store one packet when reaching the Volume (or Time) Quota. An example call flow is depicted in Annex C.2.1.1.

To avoid the risk of signalling storms between the CP and UP functions at times of tariff change, the CP function may include the Monitoring Time IE and zero or more Additional Monitoring IEs in the URR and set it to the time of tariff change to request the UP function to report separately the resource usage before and after the time of tariff change (see e.g. clause 6.3.7.1 of 3GPP TS 32.299 [18]).

5.4.11 (Un)solicited Application Reporting

For EPC, (un)solicited Application Reporting refers to the process of reporting the start or stop of applications by the TDF or PCEF. See 3GPP TS 23.203 [3] and 3GPP TS 29.212 [8].

For 5GC, solicited Application Reporting refers to the process of reporting the start or stop of applications by the SMF to the PCF. See 3GPP TS 23.503 [44] and 3GPP TS 29.512 [41]. Unsolicited application reporting is not applicable for 5GC.

The CP function shall instruct the UP function to detect and report applications by:

– creating the necessary PDR(s) to represent the applications to detect;

– creating a URR with the Reporting Trigger IE set to detect the start and/or stop of Traffic;

– the CP function may include a zero quota together with a FAR ID for Quota Action IE in the URR to instruct the UP function to drop or buffer the packets pertaining to the detected application traffic before the quota is granted in the subsequent PFCP Session Modification Request message. The FAR identified by the FAR ID for Quota Action shall be provisioned according to the "sdfHandl" instruction received from the PCF or the local policies as specified in 3GPP TS 29.512 [41].

NOTE 1: The (normal) FAR associated with the PDR detecting the application traffic is used when the URR is later on provisioned with a non-zero quota.

– associating the URR to the PDR.

For unsolicited application reporting, a PFCP session which is not linked to any specific TDF session may be established and the PDI in the PDR(s) does not contain any UE IP address.

When detecting the start or stop of an application, the UP function shall then initiate the PFCP Session Report procedure and send a Usage Report with the Usage Report Trigger set to ‘Start of Traffic’ or ‘Stop of Traffic’. The UP function shall also include the following information in the Usage Report:

– when reporting the start of an application:

– the Application ID;

– the Flow Information including the Flow Description and the Flow Direction, if the traffic flow information is deducible;

– the Application-Instance-Identifier, if the traffic flow information is deducible; and

– if no UE IP address was provisioned in the PDI, the UE’s IP address, and the Network instance when multiple PDNs with overlapping IP addresses are used in the UP function.

NOTE 2: When the CP function instructs the UP function to perform unsolicited application reporting, the PDI in the corresponding PDR has no UE IP address.

– when reporting the stop of an application:

– the Application ID;

– the Application-Instance-Identifier, if an Application Identifier was provided when reporting the start of the application;

– if no UE IP address was provisioned in the PDI, the UE’s IP address, and the Network instance when multiple PDNs with overlapping IP addresses are used in the UP function.

The UP function shall only report the Application ID when detecting the start or stop of an application and the Reduced Application Detection Information flag is set in the Measurement Information of the URR, e.g. for envelope reporting.

5.4.12 Service Identification for Improved Radio Utilisation for GERAN

Service Identification for improved radio utilization for GERAN refers to the process in the PGW of marking DL user plane traffic with a Service Class Indicator (SCI) value. See clause 5.3.5.3 of 3GPP TS 23.060 [19].

This is controlled by the PGW-C by associating a QER, including the Service Class Indicator within the DL Flow Level Marking IE, to the PDR matching the DL traffic to be marked. The PGW-U performs the SCI marking for the detected DL traffic and sends the packet with the GTP-U Service Class Indicator Extension Header downstreams.

The PGW-C may stop the SCI marking during the PFCP session by removing the related QER or removing the DL Flow Level Marking IE from the related QER, the PGW-U shall then stop such function consequently.

5.4.13 Transport Level Marking

For EPC, transport level marking is performed on a per EPS bearer basis in the SGW and PGW. Transport level marking refers to the process of marking traffic with a DSCP value based on the locally configured mapping from the QCI and optionally the ARP priority level.

For 5GC, transport level marking is performed on a per QoS flow basis. Transport level marking refers to the process of marking traffic at the UPF/MB-UPF with a DSCP value based on the mapping from the 5QI, the Priority Level (if explicitly signalled) and optionally the ARP priority level configured at the SMF/MB-SMF.

Transport level marking shall be controlled by the CP function by providing the DSCP in the ToS or Traffic Class within the Transport Level Marking IE in the FAR that is associated to the PDR matching the traffic to be marked. The UP function shall perform the transport level marking for the detected traffic and sends the marked packet to the peer entity.

The CP function may change transport level marking by changing the Transport Level Marking IE in the related FAR.

5.4.14 Deferred PDR activation and deactivation

As specified in clause 6.3.2 of 3GPP TS 23.203 [7] and clauses 4.5.13 and 4a.5.13 of 3GPP TS 29.212 [8], Policy and charging control rule operations can be also performed in a deferred mode. To support such deferred PCC rule activation or deactivation, the CP function and UP function may optionally support the Deferred PDR activation and deactivation (DPDRA) as described below.

If the feature DPDRA is supported in both CP function and UP function, and when a PCC rule is provisioned in a deferred mode, i.e. with a Rule-Activation-Time and/or Rule-Deactivation-Time, the CP function shall provision the corresponding PDR using Create PDR IE or Update PDR together with an Activation Time and/or Deactivation Time to enable the PDR being activated or deactivated at requested time.

Without being provisioned together with an Activation Time or a Deactivation Time, a PDR shall be active immediately when it is received. When the status of a PDR is changed from active to inactive, the UP function shall keep storing the inactive PDR together with its associated FAR, URR(s) and QER(s), and then UP function shall apply the same behavior as if the PDR is deleted.

The CP function shall control at what time the status of a PDR rule changes using Activation Time and/or Deactivation Time as exactly as being instructed by the PCRF using a Rule-Activation-Time and/or Rule-Deactivation-Time, as specified in clause 4.5.13 of 3GPP TS 29.212 [8].

1) If only Activation Time is specified and has not yet occurred, then the UP function shall set the PDR rule inactive and make it active at that time. If Activation Time has passed, then the UP function shall immediately set the PDR rule active.

2) If only Deactivation Time is specified and has not yet occurred, then the UP function shall set the PDR rule active and make it inactive at that time. If Deactivation Time has passed, then the UP function shall immediately set the PDR rule inactive.

3) If both Activation Time and Deactivation Time are specified, and the Activation Time occurs before the Deactivation Time, and also when the PDR rule is provided before or at the time specified in the Deactivation Time, the UP function shall handle the rule as defined in 1) and then as defined in 2).

4) If both Activation Time and Deactivation Time are specified, and the Deactivation Time occurs before the Activation Time, and also when the PDR rule is provided before or at the time specified in the Activation Time, the UP function shall handle the rule as defined in 2) and then as defined in 1).

5) If both Activation Time and Deactivation Time are specified but time has already occurred for both, and the Activation Time occurs before the Deactivation Time, then the UP function shall immediately set the PDR rule inactive.

NOTE 1: If the CP function receives both Rule-Activation-Time and Rule-Deactivation-Time from the PCRF, but time has already occurred for both, and the Rule-Activation-Time occurs before the Rule-Deactivation-Time, as alternative to above, the CP function can deactivate the corresponding PDR rule by provisioning a Deactivation Time which has occurred or removing the corresponding PDR rule.

6) If both Activation Time and Deactivation Time are specified but time has passed for both, and the Deactivation Time occurs before the Activation Time, then the UP function shall immediately set the PDR rule active.

NOTE 2: If the CP function receives both Rule-Activation-Time and Rule-Deactivation-Time from the PCRF, but time has passed for both, and the Rule-Deactivation-Time occurs before the Rule-Activation-Time, as alternative to above, the CP function can activate the corresponding PDR rule by provisioning a activation Time which has occurred in the Update PDR IE, or create the corresponding PDR rule if the PDR is not provisioned yet.

5.4.15 Packet Rate enforcement

5.4.15.1 General

Packet rate enforcement refers to the process of limiting the rate of uplink and/or downlink packets allowed to be sent for a PDN connection or a PDU session.

Packet rate enforcement shall be used to support:

– APN rate control for UE’s all PDN connections for a given APN in EPC, see 3GPP TS 23.401 [14] and 3GPP TS 23.502 [29]. APN rate control is enforced across N4 interface only for 5GC interworking with EPC scenario (see clause 4.3 in 3GPP TS 23.501 [28]);

– Small data rate control for a PDU session in 5GC, see 3GPP TS 23.501 [28] and 3GPP TS 23.502 [29];

– Serving PLMN rate control, for downlink traffic, see 3GPP TS 23.401 [14] and 3GPP TS 23.501 [28].

5.4.15.2 Packet rate enforcement over Sxb and N4 interfaces

The CP function may instruct the UP function to perform packet rate enforcement, during the establishment or the modification of a PFCP session, over the Sxb and N4 reference points.

The CP function shall control packet rate enforcement in the UP function by:

1) creating the necessary PDR(s) to represent the uplink or downlink traffic to be enforced, if not already existing;

2) creating QER(s) containing the Packet Rate IE with one or more of the following enforcement rules and information:

– Maximum Uplink/Downlink Packet Rates (i.e. Number of Uplink/Downlink Packets Allowed and Time units that determine the time periods for limiting the packet rates);

– Additional Maximum Uplink/Downlink Packet Rates (i.e. Number of Additional Uplink/Downlink Packets Allowed and Time units that determine the time periods for limiting the packet rates), if additional packets are allowed to be sent beyond the maximum Uplink/Downlink Packet Rates;

The QER may also contain the Packet Rate Status IE to indicate remaining numbers of allowed packets until a given time.

The QER may also contain the QER Control Indications IE with the Rate Control Status Reporting (RCSR) flag, indicating the UP function shall report to the CP function the status of the packet rate usage when the PFCP session is released.

3) associating the QER(s) to the UL and/or DL PDRs of the traffic for which packet rate enforcement is required.

When so instructed, the UP function shall proceed as follows:

1) the UP function shall count UL/DL packets within the time period (e.g. per minute, per day, etc.) and if the ‘maximum allowed rate’ is reached, the UP function shall discard or delay further packets.

2) If ‘Additional Maximum Uplink/Downlink Packet Rates’ are provided, the UPF shall consider ‘maximum allowed rate’ is equal to the ‘number of packets per time unit’ plus the ‘number of additional allowed exception report packets per time unit’. Otherwise, the UPF shall consider ‘maximum allowed rate’ is equal to the ‘number of packets per time unit’.

3) If the CP function has requested to report the rate control status, the UP function shall send to the CP function the Packet Rate Status IE, when the PFCP session is released. Otherwise, the UP function shall not send the Packet Rate Status IE to the CP function during the release of the PFCP session.

4) If the CP function provided Packet Rate Status information, then the UP function shall first enforce the rules in the Packet Rate Status IE until either the packet rate limits are reached, or the validity time expires. Only after this shall the UP function enforce the rules in the Packet Rate IE.

5.4.15.3 PGW and SMF behaviour

A PGW, SMF or SMF/PGW shall apply APN rate control, Small Data Rate Control and Serving PLMN rate control by instructing the UP function to perform packet rate enforcement as described in clause 5.4.15.2 with the following additions:

– Serving PLMN rate control:

– the Maximum Downlink Packet Rate shall be set to the DL rate permitted by the Serving PLMN rate control parameters;

– the CP function shall indicate to the UP function to not report the status of the packet rate usage.

NOTE 1: Serving PLMN rate control applies only to control plane PDU sessions and PDN connections. Uplink rate for Serving PLMN rate control is enforced by the MME or SMF, so it does not require support from the UP function.

– Small Data Rate Control:

– the CP function shall indicate to the UP function to report the status of the packet rate usage;

– the QER shall be associated to all the DL/UL PDRs of the PDU session;

– APN rate control:

– the CP function shall indicate to the UP function to report the status of the packet rate usage;

– the QER shall be associated to all the PDRs of all the PDN connections of the UE to the same APN, using the QER Correlation ID (see clause 5.2.1).

If both Serving PLMN rate control and Small Data Rate Control are applied in 5GS, or both Serving PLMN rate control and APN rate control are applied in EPS, the SMF/PGW-C may control packet rate enforcement in the UP function by provisioning:

– a QER for Small Data Rate Control/APN rate control, and by associating DL/UL PDRs to the QER; or

– alternatively, different QERs for Serving PLMN rate control and for Small Data Rate Control/APN rate control, and by associating DL PDRs to both of the QER(s).

APN rate control and Small Data Rate Control are distinct functionalities that apply in EPS and 5GS respectively. For PDU sessions supporting interworking with EPC, the SMF/PGW-C shall start APN rate control (if required for the UE’s PDN connections to the APN) and stop Small Data Rate Control (if this was performed for the PDU session) upon 5GS to EPS mobility, and vice-versa upon EPS to 5GS mobility, e.g. by:

– updating the information of the QER associated to the UL/DL PDRs with the packet rates and packet rate status (if available) applicable for APN rate control or Small Data Rate Control respectively, if the same QER is associated to UL/DL PDRs when the UE is in EPC and in 5GC; in this case, the SMF/PGW-C shall also request the UPF/PGW-U to report immediately the packet rate status at the time of the mobility between 5GS and EPS by including the Query Packet Rate Status IE in the PFCP Session Modification Request; or

NOTE 2: Requesting the UPF/PGW-U to report immediately the packet rate status enables to retrieve the current rate status applicable to the source system before the UPF/PGW-U overwrites the QER parameters with the packet rates and packet rate status (if available) applicable to the target system.

– provisioning different QERs for APN rate control and for Small Data Rate Control, and by associating UL/DL PDRs to the appropriate QER, when the UE is in EPC or in 5GC. In this case, when releasing the PFCP session, the UP function shall include the packet rate status for every QER for which this information has been requested in the corresponding QER Control Indications IE.

Besides, if the SMF/PGW-C set up additional PDRs in the UP function for S5/S8 tunnels for a PDU session supporting interworking with EPS, these PDRs shall not be associated to the QER used to perform Small Data Rate Control.

5.4.16 QoS differentiation for Stand-alone Non-Public Network (SNPN)

5.4.16.1 General

Support of QoS differentiation for SNPN is described in clause 5.30.2.7 and clause 5.30.2.8 of 3GPP TS 23.501 [28].

QoS differentiation procedures as described in the following clauses are optional and may be used when:

– UE access to PLMN services via SNPN;

– UE access to SNPN services via PLMN.

5.4.16.2 Access to PLMN services via SNPN

The SMF in PLMN shall provide DSCP(s) within the Transport Level Marking IE(s) in the FAR(s) that is associated to the PDR(s) matching the traffics to be marked to the UPF in PLMN.

UPF in PLMN shall perform the DSCP marking for the detected traffic and sends the marked packet to the N3IWF.

The SMF in SNPN shall provide PDR to the UPF in SNPN, based on the mapping rules including the mapping between the DSCP markings for the IPsec child SAs on NWu and the corresponding QoS requirement of the PLMN. The PDR may include specific DSCP and N3IWF IP address to enable UPF to detect the DL traffic.

The SMF in SNPN may provide the QER associated to the PDR to ensure the QoS for the DL traffic if the related QoS Flow has been established in the SNPN. Otherwise, the SMF in SNPN may provide the URR associated to the PDR to request the reporting of the detected DL traffic, which may be used by the SMF in SNPN to trigger the PDU session modification procedure to establish the DL traffic related QoS Flow in SNPN. The URR may include the Reporting trigger "Start of application" to enable the UPF sending Usage report with the usage report trigger "START" to the SMF upon detection of the DL traffic with such DSCP and N3IWF IP address.

The SMF in SNPN may also provide DSCP within the Transport Level Marking IE in the FAR that is associated to the PDR. UPF in SNPN shall perform the DSCP re-marking for the detected traffic and sends the marked packet to the NG-RAN.

5.4.16.3 Access to SNPN services via PLMN

The SMF in SNPN shall provide DSCP(s) within the Transport Level Marking IE(s) in the FAR(s) that is associated to the PDR(s) matching the traffics to be marked to the UPF in SNPN.

UPF in SNPN shall perform the DSCP marking for the detected traffic and sends the marked packet to the N3IWF.

The SMF in PLMN shall provide PDR to the UPF in PLMN, based on the mapping rules including the mapping between the DSCP markings for the IPsec child SAs on NWu and the corresponding QoS requirement of the SNPN. The PDR may include specific DSCP and N3IWF IP address to enable UPF to detect the DL traffic.

The SMF in PLMN may provide the QER associated to the PDR to ensure the QoS for the DL traffic if the related QoS Flow has been established in the PLMN. Otherwise, the SMF in PLMN may provide the URR associated to the PDR to request the reporting of the detected DL traffic, which may be used by the SMF in PLMN to trigger the PDU session modification procedure to establish the DL traffic related QoS Flow in PLMN. The URR may include the Reporting trigger "Start of application" to enable the UPF sending Usage report with the usage report trigger "START" to the SMF upon detection of the DL traffic with such DSCP and N3IWF IP address.

The SMF in PLMN may also provide DSCP within the Transport Level Marking IE in the FAR that is associated to the PDR. UPF in PLMN shall perform the DSCP re-marking for the detected traffic and sends the marked packet to the NG-RAN.