WO2020173548A1

WO2020173548A1 - Sx protocol extension to support pause measurement on user plane

Info

Publication number: WO2020173548A1
Application number: PCT/EP2019/054694
Authority: WO
Inventors: Yong Yang; Jiehong YANG; Anders ENGSTRÖM; Ioannis Sapountzis
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2019-02-26
Filing date: 2019-02-26
Publication date: 2020-09-03

Abstract

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

Description

SX PROTOCOL EXTENSION TO SUPPORT PAUSE MEASUREMENT ON USER PLANE

Technical field

The present invention is directed to methods and apparatuses involving Long Term Evolution, LTE technologies. In particular, the invention relates to architectures where a control plane is split from the user plane.

Background

The well-known SAE - LTE (System Architecture Evolution - Long Term Evolution) architecture has been shown in fig. 1 .

CUPS stands for Control and User Plane Separation of EPC nodes and provides the architec ture enhancements for the separation of functionality in the Evolved Packet Core’s Serving Gateway, SGW, PDN (Packet Data Network) Gateway PGW and Traffic Detection Function, TDF. This enables flexible network deployment and operation, by distributed or centralized de ployment and the independent scaling between control plane and user plane functions - while not affecting the functionality of the existing nodes subject to this split

c.f. http://www.3gpp.org/cups

Such a split is also known from 5G also denoted New Radio, NR, or Next Generation, NG sys tems.

CUPS allows for:

Reducing Latency on application service, e.g. by selecting user plane nodes which are closer to the Radio Access Node, RAN, or more appropriate for the intended User Entity, UE, usage type without increasing the number of control plane nodes.

Supporting Increase of Data Traffic, by enabling to add user plane nodes without changing the number of SGW-C(Control plane function), PGW-C(Control plane function) and TDF-C(Control plane function) in the network.

Locating and Scaling the CP (Control Plane) and UP (User Plane) resources of the EPC nodes independently.

Independent evolution of the CP and UP functions.

Enabling Software Defined Networking to deliver user plane data more efficiently.

CUPS introduces 3 new interfaces, Sxa, Sxb and Sxc between the CP and UP functions of the

SGW, PGW and TDF respectively. The following high-level principles are adopted: The CP function terminates the Control Plane protocols: GTP(GPRS Tunneling Protocol)-C, Di ameter (Gx, Gy, Gz).

A CP function can interface multiple UP functions, and a UP function can be shared by multiple CP functions.

An UE is served by a single SGW-CP but multiple SGW-UPs can be selected for different PDN (Packet Data Network) connections. A user plane data packet may traverse multiple UP func tions.

The CP function controls the processing of the packets in the UP function by provisioning a set of rules in Sx sessions, i.e. Packet Detection Rules for packets inspection, Forwarding Action Rules for packets handling (e.q. forward, duplicate, buffer, drop), QoS (Quality of Service) En forcement Rules to enforce QoS policing on the packets, Usage Reporting Rules for measuring the traffic usage.

All the 3GPP features impacting the UP function (PCC (Policy and Charging Control), Charging, Lawful Interception, etc) are supported, while the UP function is designed as much as possible 3GPP agnostic. For example, the UPF (User Plane Function) is not aware of bearer concept. Charging and Usage Monitoring are supported by instructing the UP function to measure and report traffic usage, using Usage Reporting Rule(s). No impact is expected to OFCS (Offline Charging System), OCS (Online Charging Function) and the PCRF (Policy and Charging Rules Function).

The CP or UP function is responsible for GTP-u F-TEID (Tunnel endpoint Identifier) allocation.

A legacy SGW, PGW and TDF can be replaced by a split node without effecting connected leg acy nodes.

3GPP TS 23.214 describes in section 4.1 .1 - Architecture references:

“4.2.1 Non-roaming and roaming architectures

This clause defines the complementary aspects of the architecture reference models specified in 3GPP documents TS 23.401 V15.2.0 (2017-12) clause 4.2 and TS 23.402 V15.2.0 (2017-12) clauses 4.2.2 and 4.2.3 for GTP-based interfaces when SGW, PGW and TDF control and user planes are separated.

For S2a, S2b, S5 and S8 reference points, this architecture reference model is only supported with GTP-based interfaces. PMIP-based interfaces and S2c interface are not supported.

Figure (corresponding to fig. 2 in this document) 4.2.1 -1 in TS 23.214 V15.1 .0 (2017-12) shows the architecture reference model in the case of separation between control plane and user plane. This architecture reference model covers non-roaming as well as home routed and local breakout roaming scenarios. NOTE 1 : The -C or -U suffix appended to S2a, S2b, S5 and S8 existing reference points only indicate the control plane and user plane components of those interfaces.

NOTE 2: The architecture in figure 4.2.1 -1 only depicts the case when the CP and UP functions of all SGW, PGW and TDF nodes are split. However, the other cases when the CP and UP function of only one of these nodes is split while the CP and UP function of the other in terfacing node is not split, e.g. PGW’s control plane and user plane is split while SGW’s control plane and user plane is not split, are also supported. The split architecture of a node does not put any architectural requirements on the peer nodes with which it interfaces.

NOTE 3: TDF is an optional functional entity.

NOTE 4: Additional interfaces/reference points are documented in 3GPP documents TS

23.401 , TS 23.402, TS 23.060 V15.1 .0 (2017-12) and TS 23.203 V15.1 .0 (2017-12).

NOTE 5: For a roaming architecture with local breakout, the Gx interface is defined be tween the PGW-C and PCRF in the visited network.

4.2.2 Combined SGW/PGW architecture

The usage of a combined SGW/PGW documented in TS 23.401 remains possible in a deploy ment with separated control and user planes. This is enabled by supporting an Sx interface with a common parameter structure for non-combined and combined cases. Figure 4.2.2-1 (corre sponding to fig. 3 in this document) shows the architecture reference model for a combined SGW/PGW in the case of separation between control plane and user plane.”

Summary

According to the prior art, when CP and UP splits and when charging measurement is re quested on UP, UP is deemed to perform the measurement and the reporting. When network performs Pause Charging on a user session due to the latter’s connectivity status, it is required that CP shall instruct the UP to pause the measurement and the reporting for the usage until the measurement is resumed later. 3GPP has specified a flag to indicate the pause action to UP. However, it has the following problems and drawbacks:

Once receiving the pause indication, the UP shall send an immediate report to the CP. The problem with this report is that CP won’t have a defined mechanism to handle it, since pause charging itself is not a chargeable event (or a charging condition change trigger in any sense) for either online charging or offline charging defined by 3GPP. There isn’t any functionality de fined for handling this‘unexpected’ report.

It is the object of the present invention to set forth methods and apparatuses for providing a so lution to the above-mentioned problem in the prior art and further to provide improved and more reliable services for the purpose of improving charging reliability and ultimately end user experi ence. It is proposed to create a new Flag to support the pause of charging, only applicable for the Sx Session Modification Request message.

Brief description of the drawings

Fig. 1 shows a known reference architecture for a LTE access and core network system for a non-roaming scenario, fig. 2 shows a known reference architecture for a EPC system with UP / CP split, fig. 3 shows a known combined SGW/PGW-C wit UP / CP split, fig. 4 shows a known signalling diagram concerning session establishment, fig. 5 shows IDT based charging according to the invention, fig. 6 shows CTP charging according to the invention, fig. 7 shows DTP charging according to the invention.

Detailed description

To avoid the earlier mentioned drawbacks of the prior art, additional information elements can be introduced to indicate to the UP that it shall suspend the ongoing measurement on the Us age Report Rule (URR) and wait for the new instruction to resume the measurement. The al ready measured usage shall be saved locally on the UP;

Furthermore, In the prior art there is a drawback with the default options.‘Drop’ leads to bad user experience, especially when the user still has credit to use;‘Forward’ leads to risk of reve nue leakage, that is the user traffic is allowed/forwarded while the user doesn’t have any credit left. The Sx specification 3GPP TS 29.244 V15.0.0 (2017-12) does not specify a buffering option for packet handling that can be used for the period when the UP awaits new instructions from the CP as in the case of initial credit authorization or credit update (signalling A-D in figures below). The“Buffer” mechanism in the current release is only designed to accommodate for the Down link Data Notification procedure. The existing mechanism, either forward or drop packets, which can be applied for any other reason, can lead to either revenue leakage or bad user experience. With the introduction of CP/UP split and reporting in the form of URRs (Usage Reporting Rule), the UP upon reporting has to wait for new instructions from CP and in the meantime, apply a forwarding action based on a subsequent FAR (CR 0032 29.244 Rel-15) or a default action which can be either drop or forward. This is especially critical for online credit control during ini tial authorization as well as during an interim update due to quota exhaustion or other reporting reason.

According to Fig. 5, when provisioning a URR, the CP function shall provide the reporting trig gers) 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 Sx 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 al low 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 meas ured traffic reaches the quota;

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

NOTE 1 : 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]).

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 QoS enforcement.

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 for warding 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; and/or an Inactivity Detection Time, to request the UP function to suspend the time measure ment 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 from the point when the first packet is received until the time-based usage measurement is stopped. NOTE 2: The Inactivity Detection Time can be set to the Quota Consumption Timer if re ceived. a Time Quota Mechanism, including a Base Time Interval Type, which is either Continu ous Time Period (CTP) or Discrete Time Period (DTP), and a Base Time Interval (BTI), to the UP function. See subclause 6.5.7 in 3GPP TS 32.299[18].

For CTP (Continuous Time Period) as shown in Fig. 6, 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 con tained no traffic. The time measurement resumes by the UP function when subsequent traffic is received.

For DTP (Descrete Time Period) as shown in Fig. 7, the time measurement starts from the time that traffic has occurred up to the Base Time Interval end. The time measurement shall be re sumed by the UP function when subsequent traffic is received.

When the time-based measurement method applies, and when the Envelope Reporting is re quired, 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 accord ingly. The CP function may set the Reduced Application Detection Information flag in the Meas urement Information of the URR, when requesting the detection of start and stop of an applica tion solely for the purpose of envelope reporting.

The CP function may provision a Volume Threshold, a Volume Quota, or both (and/or respec tively a Time Threshold, a Time Quota, or both).

When both a Volume (or Time) Threshold and a Volume (or Time) Quota are provisioned, the UP function shall send a usage report only when reaching the Volume (or Time) Threshold; when subsequently reaching the Volume (or Time) 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. NOTE 3: 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 4: 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 all the measurement methods (i.e. volume, time or event), the CP function may also provi sion:

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 indi cated in this parameter;

NOTE 5: 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 re ceiving any subsequent packets associated with this URR.

a Monitoring Time, 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 time thresholds at the monitoring time. The CP function may additionally provision a Subsequent Vol ume (or Time) Threshold IE and/or a Subsequent Volume (or Time) Quota IE, for a volume (or time) 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) Threshold IE, if provisioned in the URR, or to the remaining value of the Vol ume (or Time) threshold used before the monitoring time (i.e. excluding the already accumu lated volume or time usage);

shall indicate the usage up to the Monitoring time and usage after the Monitoring time in the first usage report after the Monitoring Time is reached;

a Measurement Period, indicating the period to generate periodic usage reports to the CP function. The CP function may request at any time the UP function to activate or deactivate a network re sources usage measurement and the sending of corresponding Usage Reports, using the Inac tive Measurement flag of the Measurement Information IE of the URR.

When detecting that a provisioned reporting trigger occurs, the UP function shall generate a Us age Report for the related URR and send it to the CP function by initiating the Sx Session Re port 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 in cremented for every 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 a URR towards the CP function, the UP function shall:

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

re-apply the threshold provisioned for the related URR, if the usage report was triggered due to a threshold being reached; and

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

When receiving a new threshold or quota from the CP function for a measurement that is al ready ongoing in the UP function, the UP function shall consider its ongoing measurements counts for the related URR against the new threshold or quota to determine when to send its next usage report to the CP function.

NOTE 1 : The UP function determines when to send its next usage report to the CP func tion 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.

When reporting the network resources usage before and after a Monitoring Time, the UP func tion shall send two Usage Reports in the PFCP message (e.g. Sx 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. NOTE 2: 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 Sx sessions after the oc currence 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. Sx Session Report Request) for the same URR ID. Each Usage Report shall then include the Usage Information IE indicating whether the re ported 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.

A usage report triggered only due to the Dropped DL Traffic Threshold shall not contain any measurement information.

When being instructed to remove a URR or the last PDR associated to a URR, or to deactivate a network resources usage measurement via the Inactive Measurement flag of the Measure ment Information IE of the URR, the UP function shall include a Usage Report in the Sx Session Modification Response if there are non-null measurements to report for the URR, and shall re set its ongoing measurements for the URR that is removed, dissociated from the last PDR or deactivated.

NOTE 3: 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.

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

generate usage report(s) for the URR(s) being queried and for any associated linked us age reports (see subclause 5.2.2.4) for which there are non-null measurements to report,

include them in the Sx Session Modification Response and, if necessary, additional Sx Session Report Request messages, and

proceed as specified above upon generating a usage report for a URR towards the CP function.

NOTE 4: 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 Sx session. As an exception, the UP function always generates an immediate report when being instructed to remove a URR or deactivate a network resource measurement via the Inac tive Measurement flag of the Measurement Information IE of the URR.

When additional Sx Session Report Request messages need to be sent, the UP function shall indicate, either in the Sx Session Modification Response or in one Sx Session Report Request, how many usage reports will be sent in Sx Session Report Request messages. If this is indi cated in one Sx Session Report Request, the Sx Session Modification Response shall indicate that more reports will follow by setting the AURI flag of the Additional Usage Reports Infor mation IE. Besides, if the Sx Session Modification Request included the Query URR Reference IE, usage reports sent in response to the query in the Sx Session Modification Response and/or additional Sx Session Report Request messages shall include the Query URR Reference IE set to the same value as received in the Sx Session Modification Request.

When the PGW Pause of Charging is activated, (see 3GPP TS 23.401 [14]) the CP function (PGW-C) may request the UP function (PGW-U), in an Sx Session Modification Request, by in cluding Suspend URR IE(s) to stop its ongoing network resources measurement for one or mul tiple URRs of the Sx session, where these URR(s) are associated with the charging function. The UP function shall store the current counts without reporting to the CP function.

When the PGW Pause of Charging is deactivated, (see 3GPP TS 23.401 [14]) the CP function (PGW-C) may request the UP function (PGW-U), in an Sx Session Modification Request, by in cluding Resume URR IE(s) to stop its ongoing network resources measurement for one or multi ple URRs of the Sx session, which are previously suspended. The UP function shall continue with the measurement of the usage on top of the stored counts.

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; or

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 5: Events (e.g. application detection information) are reported individually and inde pendently from the usage report sent for envelope closure.

At the Sx session termination, the UP function shall indicate to the CP function, in the Sx Ses sion Deletion Response, the resources that have been consumed for each URR that was provi sioned in the Sx session since the last usage report (respective to each URR).

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

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

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

modifying the QER (s) in the Sx session. The Sx Session Modification Request is used over the Sxa, Sxb and Sxc interface by the CP function to request the UP function to modify the Sx session.

Table 1 : Information Elements in a Sx Session Modification Request

The Suspend URR grouped IE shall be encoded as shown in Table 2.

The Resume URR grouped IE shall be encoded as shown in Table 3.

A PFCP message may contain several lEs. In order to have forward compatible type definitions for the PFCP lEs, all of them shall be TLV (Type, Length, Value) coded. PFCP IE type values are specified in the Table 8.1 .2-1 . The last column of this table indicates whether the IE is:

Fixed Length: the IE has a fixed set of fields, and a fixed number of octets;

Variable Length: the IE has a fixed set of fields, and has a variable number of octets. For example, the last octets may be numbered similar to "5 to (n+4)". In this example, if the value of the length field, n, is 0, then the last field is not present;

Extendable: the IE has a variable number of fields, and has a variable number of octets. The last fields are typically specified with the statement: "These octet(s) is/are present only if explicitly specified". The legacy receiving entity shall ignore the unknown octets. An IE of any of the above types may have a null length as specified in subclause 5.6.3. This shall not be considered as an error by the receiving PFCP entity.

In order to improve the efficiency of troubleshooting, it is recommended that the lEs should be arranged in the signalling messages as well as in the grouped lEs, according to the order the lEs are listed in the message definition table or grouped IE definition table in section 7. However the receiving entity shall be prepared to handle the messages with lEs in any order.

Within lEs, certain fields may be described as spare. These bits shall be transmitted with the value set to 0. To allow for future features, the receiver shall not evaluate these bits.

Table 4: Information Element Types The Usage Report Trigger IE shall be encoded as shown in Table 5. It indicates the trigger of the usage report.

Table 5: Usage Report Trigger

Octet 5 shall be encoded as follows:

Bit 1 - PERIO (Periodic Reporting): when set to 1 , this indicates a periodic report.

Bit 2 - VOLTH (Volume Threshold): when set to 1 , this indicates that the data volume usage reaches a volume threshold.

Bit 3 - TIMTH (Time Threshold): when set to 1 , this indicates that the time usage reaches a volume threshold.

Bit 4 - QUHTI (Quota Holding Time): when set to 1 , this indicates that no packets have been received for a period exceeding the Quota Holding Time.

Bit 5 - START (Start of Traffic): when set to 1 , this indicates that the start of traffic is de tected.

Bit 6 - STOPT (Stop of Traffic): when set to 1 , this indicates that the stop of traffic is de tected.

Bit 7 - DROTH (Dropped DL Traffic Threshold): when set to 1 , this indicates that the DL traffic being dropped reaches a threshold.

Bit 8 - IMMER (Immediate Report): when set to 1 , this indicates an immediate report re ported on CP function demand.

Octet 6 shall be encoded as follows:

Bit 1 - VOLQU (Volume Quota): when set to 1 , this indicates that the Volume Quota has been exhausted.

Bit 2 - TIMQU (Time Quota): when set to 1 , this indicates that the Time Quota has been exhausted.

Bit 3 - LIUSA (Linked Usage Reporting): when set to 1 , this indicates a linked usage re port, i.e. a usage report being reported for a URR due to a usage report being also reported for a linked URR (see subclause 5.2.2.4). Bit 4 - TERMR (Termination Report): when set to 1 , this indicates a usage report being reported (in a Sx Session Deletion Response) for a URR due to the termination of the Sx ses sion, or a usage report being reported (in a Sx Session Modification Response) for a URR due to the removal of the URR.

Bit 5 - MONIT (Monitoring Time): when set to 1 , this indicates a usage report being re ported for a URR due to the Monitoring Time being reached.

Bit 6 - ENVCL (Envelope Closure): when set to 1 , this indicates the usage report is gen erated for closure of an envelope (see subclause 5.2.2.3).

Bits 7 to 8: Spare, for future use and set to 0.

At least one bit shall be set to 1 . Several bits may be set to 1 .

The Reporting Triggers IE shall be encoded as shown in Figure 8.2.19-1 . It indicates the report ing trigger(s) for the UP function to send a report to the CP function.

Table 5: Reporting Triggers

Octet 5 shall be encoded as follows:

Bit 1 - PERIO (Periodic Reporting): when set to 1 , this indicates a request for periodic reporting.

Bit 2 - VOLTH (Volume Threshold): when set to 1 , this indicates a request for reporting when the data volume usage reaches a volume threshold

Bit 3 - TIMTH (Time Threshold): when set to 1 , this indicates a request for reporting when the time usage reaches a time threshold.

Bit 4 - QUHTI (Quota Holding Time): when set to 1 , this indicates a request for reporting when no packets have been received for a period exceeding the Quota Holding Time.

Bit 5 - START (Start of Traffic): when set to 1 , this indicates a request for reporting when detecting the start of an SDF or Application traffic.

Bit 6 - STOPT (Stop of Traffic): when set to 1 , this indicates a request for reporting when detecting the stop of an SDF or Application Traffic.

Bit 7 - DROTH (Dropped DL Traffic Threshold): when set to 1 , this indicates a request for reporting when the DL traffic being dropped reaches a threshold. Bit 8: - LIUSA (Linked Usage Reporting): when set to 1 , this indicates a request for linked usage reporting, i.e. a request for reporting a usage report for a URR when a usage re port is reported for a linked URR (see subclause 5.2.2.4).

Octet 6 shall be encoded as follows:

- Bit 1 -VOLQU (Volume Quota): when set to 1 , this indicates a request for reporting when a Volume Quota is exhausted.

Bit 2 - TIMQU (Time Quota): when set to 1 , this indicates a request for reporting when a Time Quota is exhausted.

Bit 3 - ENVCL (Envelope Closure): when set to 1 , this indicates a request for reporting when conditions for closure of envelope is met (see subclause 5.2.2.3).

Bits 4 to 8: Spare, for future use and set to 0.

At least one bit shall be set to 1. Several bits may be set to 1.

Claims

1. Packet core system comprising a User Plane UP and a Control Plane CP, the UP and CP being split, the UP and CP allowing communication over one or more SX interfaces, the packet core system being configured such as,

when provisioning a Usage report Rule URR, the CP function is adapted to providing at least one reporting trigger in the Reporting Triggers IE of the URR, the UP function being adapted to generating and sending a Usage Report for this URR to the CP function, and when adding or removing reporting trigger(s) to or from the URR, the CP function is configured to providing a new complete list of applicable reporting triggers in the Report ing Triggers IE in the Sx Session Modification Request message.

2. Packet core system according to claim 1 , further comprising a Volume Threshold IE able to measure traffic,

wherein the Volume Threshold IE is configured to request that the UP function generates a usage report when the measured traffic reaches a predetermined threshold.

3. Packet core system according to claim 1 or 2, further comprising a Volume Quota IE, wherein the Volume Quota IE is configured to request that the UP function stops forward ing at least one group of packets and, if no Volume Threshold is provisioned, that it also generates a usage report, when the measured traffic reaches a predetermined quota.

4. Packet core system according to any of the preceding claims, further comprising a

Dropped DL Traffic Threshold IE, wherein the Dropped DL Traffic Threshold IE is config ured to request that the UP function generates a usage report when the downlink traffic that is being dropped reaches a predetermined threshold.

5. Packet core system according to any of the preceding claims, further comprising a Meas urement Information having a 'Measurement Before QoS Enforcement' flag, wherein the Measurement Information with the 'Measurement Before QoS Enforcement' flag is set to 1 and is configured to request that the UP function measures the traffic usage before a QoS enforcement.

6. Packet core system according to any of the preceding claims, further comprising a Time Threshold IE, wherein the Time Threshold IE is configured to request that the UP function generates a usage report when the measured traffic reaches a predetermined threshold.

7. Packet core system according to any of the preceding claims,

wherein a Time Quota is configured to request that the UP function stops forwarding at least one group of packets and, if no Time Threshold is provisioned, that it also generates a usage report when the measured traffic reaches a predetermined quota.

8. Packet core system according to any of the preceding claims, further comprising an Inac tivity Detection Time, wherein the Inactivity Detection Time is configured to request that the UP function suspends time measurement when no packets are received during the provisioned Inactivity Detection Time.

9. Packet core system according to any of the preceding claims, further comprising a Time Quota Mechanism, wherein the Time Quota Mechanism is configured to adding a Base Time Interval Type, being either Continuous Time Period (CTP) or Discrete Time Period (DTP), and a Base Time Interval (BTI), to the UP function.

10. Packet core system according to claim 9, wherein Continuous Time Period (CTP) is

measured from the time that traffic has occurred until the first Base Time Interval (BTI) which contains no traffic.

1 1 . Packet core Packet core system according to claim 9, wherein Discrete Time Period (DTP), is measured from the time that traffic has occurred until the Base Time Interval (BTI) ends.

12. Packet core system according to any of the preceding claims, further comprising a Quota Holding Time, wherein the Quota Holding Time is configured to request that the UP func tion sends a usage report and also stops forwarding at least a group of packets when no packets have been received for the duration indicated in the Quota Holding Time.

13. Method for packet core system comprising a User Plane UP and a Control Plane CP, the UP and CP being split, the UP and CP allowing communication over one or more SX in terfaces,

the method comprising the steps of: - when provisioning a User Report Rule URR, the CP function provides at least one re porting trigger in the Reporting Triggers IE of the URR, resulting in that the UP func tion generates and sends a Usage Report for said URR to the CP function, and

- when adding or removing reporting trigger(s) to or from the URR, the CP function pro- vides a new complete list of applicable reporting triggers in the Reporting Triggers IE in the Sx Session Modification Request message.