Method and apparatus for billing management

Abstract

An embodiment of the present disclosure provides a method and apparatus for charging management, the method being performed by a first user plane function, includes determining a charging action for a first session, the method further including transmitting information regarding the charging action for the first session to a second user plane function.

Description

[Technical field]

[0001] TECHNICAL FIELD Non-limiting and exemplary embodiments of the present disclosure relate generally to the field of communications technology, and more particularly, to methods and apparatus for charging management. [Background technology]

[0002] This section introduces aspects that may facilitate a better understanding of the present disclosure and, accordingly, the statements in this section are to be read in this light and are not to be understood as admissions about what is in the prior art or what is not in the prior art.

[0003] In communication networks, an architecture of control plane / user plane separation (CUPS) has been introduced for various network devices such as SGW (Serving Gateway), PGW (Packet Data Network (PDN) Gateway (GW)), TDF (Traffic Detection Function), etc. For example, 3rd Generation Partnership Project (3GPP) TS 23.214 V16.2.0 and TS 29.244 V16.6.0, the disclosures of which are incorporated herein by reference in their entirety, define various interfaces between control plane nodes (or functions) and user plane nodes (or functions). As described in 3GPP TS23.214 V16.2.0, an Sxb interface is defined between the PGW control plane (PGW-C) and the PGW user plane (PGW-U), an Sxa interface is defined between the SGW control plane (SGW-C) and the SGW user plane (SGW-U), and an Sxc interface is defined between the TDF control plane (TDF-C) and the TDF user plane (TDF-U). As described in 3GPP TS29.244 V16.6.0, an N4 interface is defined between the Session Management Function (SMF) and the User Plane Function (UPF). In addition, 3GPP TS23.214 V16.2.0 and TS29.244 V16.6.0 define various Packet Forwarding Control Protocol (PFCP) node-related procedures and PFCP session-related procedures between the control plane nodes (or functions) and the user plane nodes (or functions).

[0004] 3GPP TS23.502 V16.7.1, the entire disclosure of which is incorporated herein by reference, describes the SMF charging suspension procedure. As described in section 4.4.4 of 3GPP TS23.502 V16.7.1, the SMF charging suspension procedure aims to make the SMF charging and usage monitoring data more accurately reflect the downlink traffic actually transmitted to the AN (Access Network). The following are example triggers for the SMF to activate charging suspension: - Operator specified criteria / thresholds (e.g. number / percentage of packets / bytes dropped by the UPF in the downlink since the N3 tunnel towards the AN was last opened). The SMF requests the UPF to be notified each time the criteria / thresholds are met. - "Radio link failure" indication (see 3GPP TS23.502 V16.7.1 clause 4.2.6).

[0005] If a trigger is met that allows the SMF to suspend billing, based on the operator's policies, the SMF must suspend billing. When the SMF suspends billing, the following applies: -For UPFs configured for usage reporting, the SMF modifies the usage reporting rules for PDU sessions and stops collecting usage for billing purposes. -The SMF may request the UPF to limit the rate of downlink traffic sent to a downstream UPF or AN.

[0006] In a home routed roaming scenario, based on the operator's policy, the H-SMF (Home SMF) can indicate to the V-SMF (Visited SMF) whether this feature is enabled on a per PDU (Protocol Data Unit) session basis. This is indicated to the V-SMF by the "PDU Session Charging Suspend Available" indication in the Nsmf_PDUSession_Create response during the PDU session establishment procedure. This indicates to the V-SMF that it can suspend charging in the H-SMF when the criteria for suspending SMF charging are met in the VPLMN (Visited Public Land Mobile Network).

[0007] When the H-SMF receives a "Start suspend charging" indication in the Nsmf_PDUSession_Update request from the V-SMF, it stops charging and usage monitoring operations for the PDU session. When the H-SMF receives a "Stop suspend charging" indication in the Nsmf_PDUSession_Update request for the PDU session, it resumes charging for the PDU session.

[0008] When the (V-)SMF receives a Nsmf_PDUSession_UpdateSMContext request or a Namf_EventExposure_Notify regarding UE reachability, the (V-)SMF shall consider charging for the PDU session to be unsuspended if it was previously suspended.

[0009] Figure 1 shows a flowchart of the charging suspension procedure of the SMF. Figure 1 is the same as Figure 4.4.4-1 of 3GPP TS23.502 V16.7.1. The procedure of Figure 1 is described in Section 4.4.4 of 3GPP TS23.502 V16.7.1.

[0010] In step 1, the UPF receives a downlink data packet for a PDU session that does not have an N3 tunnel, and the UPF sends a data notification to the SMF. The packet is buffered or discarded in the UPF based on the operator's policy.

[0011] In step 2, based on operator policy / configuration, the SMF triggers a procedure to suspend PDU session charging. The trigger criteria is based on the SMF operator policy / configuration.

[0012] In step 3, the SMF sends an N4 Session Modify Request message to the UPF for which usage reporting is configured to modify the usage reporting rules for the PDU session and stop the usage collection for charging. In a home routed roaming scenario, the V-SMF sends an Nsmf_PDUSession_Update request with a "start charging pause" indication to the H-SMF. The H-SMF then requests the H-UPF to stop the usage collection as described above.

[0013] In step 4, the UPF acknowledges with an N4 Session Modify Response message.

[0014] 3GPP TS23.401 V16.9.0 describes the PDN_GW charging suspension procedure. As described in 3GPP TS23.401 V16.9.0, clause 5.3.6A, the PDN_GW charging suspension procedure is optionally supported by the Serving GW and the PDN_GW and aims to reduce the mismatch of charging and packet counts of the PDN_GW and the Serving GW. In general, the aim is for the PDN_GW charging and usage monitoring data to more accurately reflect the downlink traffic actually sent to the E-UTRAN (Evolved Terrestrial Radio Access Network).

[0015] Figure 2 is a flowchart of the charging suspension procedure of the PDN_GW. Figure 2 is the same as Figure 5.3.6A of 3GPP TS23.401 V16.9.0. The procedure of Figure 2 is described in Section 5.3.6A of 3GPP TS23.401 V16.9.0.

[0016] In step 1, the Serving GW receives a downlink data packet for a UE that is known to be not user plane connected (i.e. the Serving GW context data indicates that there is no downlink user plane TEID (Tunnel Endpoint Identifier) ​​for the eNodeB) as described in step 1 of clause 5.3.4.3 of 3GPP TS23.401 V16.9.0.

[0017] In step 2, based on operator policy / configuration, the Serving GW triggers the procedure to suspend charging for the PDN. The triggering criteria is based on the Serving GW operator policy / configuration. Examples of such policies are: a. Operator specified criteria / thresholds (e.g. number / percentage of packets / bytes dropped in the Serving GW in the downlink since the UE was last in ECM-CONNECTED state (or PMM-CONNECTED state in case of ISR (Idle Mode Signaling Reduced))). b. A recent indication of "Radio Link Abnormal Clearance" (see clause 5.3.5) or "Downlink Data Notification Rejection" (clause 5.3.4.3) without the UE having recently re-entered ECM-CONNECTED state (or in the case of ISR, without also re-entering PMM-CONNECTED state).

[0018] In step 3, the serving GW sends a bearer modification request (start PDN charging suspension) message to the PDN_GW. Start PDN charging suspension indicates that charging of the PDN_GW is to be suspended.

[0019] In step 4, the PDN_GW confirms with a Bearer Modification Response message. Summary of the Invention

[0020] This Summary is provided to introduce some concepts in a simplified form that are described later in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0021] There may be some problems in the prior art of charging procedures. For example, if the UPF detects that the discard threshold has been reached, this should be exactly the time to suspend charging. However, as defined in 3GPP TS23.502 V16.7.1 and 3GPP TS23.401 V16.9.0, the UP (user plane) needs to send a report to the CP (control plane), and the CP needs to send information about the start of the charging pause to the peer CP. The peer CP sends an N4 message to instruct the peer UP to suspend charging. During the transfer of two PFCP messages + transfer time between CP functions + additional processing time (time to process PFCP, or GTPv2 (General Packet Radio Service Tunneling Protocol version 2) for EPS (Evolved Packet System), or HTTP (Hypertext Transfer Protocol) messages for 5GC (5G Core Network)), more data may be discarded (e.g., in the case of MBB (Mobile Broadband) services). However, in reality, the discarded data during the transfer time has already been charged by the peer CP. The discarded data shall not be charged since it is discarded in the UP. This charging procedure may cause overcharging problems and lead to dissatisfaction of network operators and / or users.

[0022] This "overcharging" problem can be applied in various scenarios, such as 4G CUPS using SGW-C and PGW-C, 5G roaming using V-SMF and H-SMF, 5G with I-SMF (intermediate SMF) and I-UPF (intermediate UPF) inserted, 5G with I-UPF inserted and 5G without I-SMF inserted.

[0023] Figure 3 shows an example of the overcharging problem with billing suspension in a 5G roaming scenario.

[0024] In step 1, if the dropped packets reach the threshold at time T1 (dropped packets start time), the V-UPF may send a PFCP session report request (usage report trigger (DROTH (dropped DL traffic threshold)))) to the V-SMF.

[0025] In step 2, the V-SMF may send a PFCP Session Report response to the V-UPF.

[0026] In step 3, the V-SMF may send an Nsmf_PDUSession_Update request ("Start charging suspension" indication) to the H-SMF.

[0027] In step 4, the H-SMF may send a Nsmf_PDUSession_Update response to the V-SMF.

[0028] In step 5, the H-SMF may send a PFCP Session Modify Request (inactive measurement flag=1) to the H-UPF. At time T2 (time to start suspending charging), the H-UPF may suspend charging.

[0029] In step 6, the H-UPF may send a PFCP session modify response to the H-SMF.

[0030] The problem is that packets sent in the time interval T2-T1 (T2 minus T1) are billed by the H-SMF, but are dropped by the V-UPF, resulting in overcharging of these packets.

[0031] Figure 4 shows an example of the overcharging problem of billing suspension in a scenario where I-SMF and I-UPF are inserted in 5G.

[0032] In step 1, if the dropped packets reach the threshold at time T1 (dropped packets start time), the I-UPF may send a PFCP session report request (usage report trigger (DROTH)) to the I-SMF.

[0033] In step 2, the I-SMF may send a PFCP Session Report response to the I-UPF.

[0034] In step 3, the I-SMF may send an Nsmf_PDUSession_Update request ("Start charging suspension" indication) to the A-SMF (Anchor SMF).

[0035] In step 4, the A-SMF may send a Nsmf_PDUSession_Update response to the I-SMF.

[0036] In step 5, the A-SMF sends a PFCP session modification request (inactive measurement flag = 1) to the A-UPF (Anchor UPF). At time T2 (time to start suspending charging), the A-UPF may suspend charging.

[0037] In step 6, the A-UPF sends a PFCP session modify response to the A-SMF.

[0038] The problem is that packets sent in the time interval T2-T1 (T2 minus T1) are billed by the A-SMF, but are dropped by the I-UPF, resulting in overcharging of these packets.

[0039] Figure 5 shows an example of an overcharging problem for billing suspension in a scenario where I-UPF is inserted and I-SMF is not inserted in 5G.

[0040] In step 1, if the dropped packets reach the threshold at time T1 (dropped packets start time), the I-UPF may send a PFCP session report request (usage report trigger (DROTH)) to the SMF.

[0041] In step 2, the SMF can send a PFCP Session Report response to the I-UPF.

[0042] In step 3, the SMF sends a PFCP session modification request (with inactive measurement flag = 1) to the A-UPF. At time T2 (time to start suspending charging), the A-UPF may suspend charging.

[0043] In step 4, the A-UPF can send a PFCP session modify response to the SMF.

[0044] The problem is that packets sent in the time interval T2-T1 (T2 minus T1) are billed by the SMF, but if they are dropped by the I-UPF, these packets are over-billed.

[0045] The messages in FIGS. 3 to 5 are similar to the corresponding messages described in 3GPP TS29.244 V16.6.0.

[0046] Figure 6 shows an example of the overcharging problem of billing suspension in a 4G CUPS scenario.

[0047] In step 1, if the dropped packets reach the threshold at time T1 (dropped packets start time), the SGW-U may send a PFCP session report request (utilization report trigger (DROTH)) to the SGW-C.

[0048] In step 2, the SGW-C sends a PFCP Session Report Response to the SGW-U.

[0049] In step 3, the SGW-C may send a bearer modification request (PDN pause on indication flag / indication) to the PGW-C.

[0050] In step 4, the PGW-C may send a bearer modification response to the SGW-C.

[0051] In step 5, the PGW-C may send a PFCP session modify request (inactive measurement flag=1) to the PGW-U. At time T2 (time to start suspending charging), the PGW-U may suspend charging.

[0052] In step 6, the PGW-U sends a PFCP session modify response to the PGW-C.

[0053] The problem is that packets sent in the time interval T2-T1 (T2 minus T1) are billed at the PGW-C, but are dropped at the SGW-U, resulting in overcharging of these packets.

[0054] Since more DL data packets are charged at the PGW-U or PSA UPF, while the SGW-U and I / V-UPF consider the packets as dropped, the charging discrepancy becomes large, especially when considering eMBB (enhanced MBB) services with higher bandwidth.Ideally, the PGW-U and PSA UPFs should be notified at the exact moment when the SGW-U and I / V-UPF reach the DL traffic threshold.

[0055] The messages in FIG. 6 are similar to the corresponding messages described in 3GPP TS23.214 V16.2.0.

[0056] To overcome or mitigate at least one of the above-mentioned problems or other problems, embodiments of the present disclosure propose an improved solution for charging management.

[0057] In a first aspect of the present disclosure, there is provided a method performed by a first user plane function, the method including determining a charging action for a first session, the method further including transmitting information regarding the charging action for the first session to a second user plane function.

[0058] In one embodiment, the method further includes receiving an acknowledgement from the second user plane function for the information regarding a charging operation for the first session.

[0059] In one embodiment, the information regarding charging operations for the first session is included in a General Packet Radio Service Tunneling Protocol for User Plane (GTP-U) tunnel status message, and an acknowledgment response to the information regarding charging operations for the first session is included in another GTP-U tunnel status message.

[0060] In one embodiment, the charging action is determined based on at least one of an operator policy, an operator configuration.

[0061] In one embodiment, sending information regarding a charging operation for the first session to a second user plane function includes immediately sending the information regarding a charging operation for the first session to the second user plane function after determining a charging operation for the first session.

[0062] In one embodiment, the charging action includes immediately initiating a suspension of charging.

[0063] In one embodiment, the method further includes, after determining a charging action for the second session, receiving an indication from a control plane function to send information regarding the charging action for the second session to another user plane function.

[0064] In one embodiment, the indication is included in at least one of a Packet Forwarding Control Protocol (PFCP) session establishment request, a PFCP session modification request.

[0065] In one embodiment, the method further comprises transmitting capabilities supported by the first user plane function to a control plane function, the capabilities supported by the first user plane function indicating that the first user plane function supports sending and / or receiving information regarding charging operations for sessions to and / or from other user plane functions.

[0066] In one embodiment, the supported capabilities of the first user plane function are included in a Packet Forwarding Control Protocol (PFCP) association setup response or request.

[0067] In one embodiment, the control plane function includes at least one of a Packet Data Network Control Plane (PGW-C), a Serving Gateway Control Plane (SGW-C), and a Session Management Function (SMF).

[0068] In one embodiment, the first user plane function includes at least one of a Serving Gateway User Plane (SGW-U), a Visited User Plane Function (V-UPF), and an Intermediate User Plane Function (I-UPF).

[0069] In one embodiment, the second user plane function includes at least one of a packet data network user plane (PGW-U), an intermediate user plane function (I-UPF), a home user plane function (H-UPF), and an anchor user plane function (A-UPF).

[0070] In a second aspect of the present disclosure, a method is provided that is performed by a second user plane function, the method including receiving information from a first user plane function regarding a charging operation for a first session, the method further including performing a charging operation for the first session based on the information regarding a charging operation for the first session.

[0071] In one embodiment, the method further includes sending an acknowledgement to the first user plane function for the information regarding a charging operation for the first session.

[0072] In one embodiment, performing a charging operation for the first session based on the information regarding a charging operation for the first session includes immediately performing a charging operation for the first session based on the information regarding a charging operation for the first session after receiving the information regarding a charging operation for the first session from a first user plane function.

[0073] In one embodiment, the method further includes receiving an indication from the control plane function whether the usage reporting rules are applicable to the charging actions received from the other user plane functions.

[0074] In one embodiment, the method further comprises transmitting capabilities supported by the second user plane function to a control plane function, the capabilities supported by the second user plane function indicating that the second user plane function supports sending and / or receiving information regarding charging operations for sessions to and / or from other user plane functions.

[0075] In one embodiment, the supported capabilities of the second user plane function are included in a Packet Forwarding Control Protocol (PFCP) association setup response or request.

[0076] In a third aspect of the present disclosure, there is provided a method performed by a first control plane function, the method including receiving, from a user plane function, capabilities supported by a user plane function, the capabilities supported by the user plane function indicating that the user plane function supports sending and / or receiving information regarding charging operations for sessions to and / or from other user plane functions.

[0077] In one embodiment, the method further comprises, after determining a charging action for the session, sending an indication to the user plane function to send information regarding the charging action for the session to another user plane function.

[0078] In one embodiment, the method further comprises transmitting capabilities supported by the first control plane function to a second control plane function, the capabilities supported by the first control plane function indicating that the first control plane function supports configuring a user plane function to send and / or receive information regarding charging operations for sessions to and / or from other user plane functions.

[0079] In one embodiment, the method further comprises receiving from a second control plane function capabilities supported by a second control plane function, wherein the capabilities supported by the second control plane function indicate that the second control plane function supports configuring a user plane function to send and / or receive information regarding charging operations for sessions to and / or from other user plane functions.

[0080] In one embodiment, the supported capabilities of the first control plane functionality are included in a create session request, and the supported capabilities of the second control plane functionality are included in a create session response.

[0081] In a fourth aspect of the present disclosure, a first user plane function is provided. The first user plane function comprises a processor and a memory coupled to the processor. The memory includes instructions executable by the processor. The first user plane function is operable to determine a charging action for a first session and to send information regarding the charging action for the first session to a second user plane function.

[0082] In a fifth aspect of the present disclosure, a second user plane function is provided. The second user plane function comprises a processor and a memory coupled to the processor. The memory includes instructions executable by the processor. The second user plane function is operable to receive information regarding a charging operation for a first session from a first user plane function and to perform a charging operation for the first session based on the information regarding a charging operation for the session.

[0083] In a sixth aspect of the present disclosure, a first control plane function is provided, the first control plane function comprising: a processor; and a memory coupled to the processor, the memory including instructions executable by the processor, the first control plane function operable to receive from a user plane function capabilities supported at a user plane function, the capabilities supported at the user plane function indicating that the user plane function supports sending and / or receiving information regarding charging operations for sessions to and / or from other user plane functions.

[0084] In a seventh aspect of the present disclosure, a first user plane function is provided. The first user plane function comprises a determining module and a first transmitting module. The determining module is configured to determine a charging action for the first session. The first transmitting module is configured to transmit information regarding the charging action for the first session to a second user plane function.

[0085] In one embodiment, the first user plane function further comprises a first receiving module configured to receive an acknowledgement response from the second user plane function for the information regarding the charging operation for the first session.

[0086] In one embodiment, the first user plane function further comprises a second receiving module configured to receive, after determining a charging action for the second session, an indication from the control plane function to send information regarding the charging action for the second session to another user plane function.

[0087] In one embodiment, the first user plane function further comprises a second transmitting module configured to transmit to the control plane function features supported by the first user plane function, the features supported by the first user plane function indicating that the first user plane function supports transmitting and / or receiving information regarding charging operations for sessions to and / or from other user plane functions.

[0088] In an eighth aspect of the present disclosure, a second user plane function is provided. The second user plane function comprises a first receiving module and an executing module. The first receiving module is configured to receive information related to a charging operation for the first session from the first user plane function. The executing module is configured to execute the charging operation for the first session based on the information related to the charging operation for the first session.

[0089] In one embodiment, the second user plane function further comprises a first transmission module configured to transmit an acknowledgement of the information regarding the charging operation for the first session to the first user plane function.

[0090] In one embodiment, the second user plane function further comprises a second receiving module configured to receive from the control plane function an indication of whether the usage reporting rule is applicable to the charging action received from the other user plane function.

[0091] In one embodiment, the second user plane function further comprises a second transmitting module configured to transmit to the control plane function features supported by the second user plane function, the features supported by the second user plane function indicating that the second user plane function supports transmitting and / or receiving information regarding charging operations for sessions to and / or from other user plane functions.

[0092] In a ninth aspect of the present disclosure, a first control plane function is provided. The first control plane function comprises a first receiving module. The first receiving module is configured to receive from the user plane function functionality supported by the user plane function. The functionality supported by the user plane function indicates that the user plane function supports sending and / or receiving information regarding charging operations for sessions to and / or from other user plane functions.

[0093] In one embodiment, the first control plane function further comprises a first transmitting module configured to, after determining a charging action for the session, transmit an indication to a user plane function to transmit information regarding the charging action for the session to another user plane function.

[0094] In one embodiment, the first control plane function further comprises a second transmitting module configured to transmit capabilities supported by the first control plane function to a second control plane function, the capabilities supported by the first control plane function indicating that said first control plane function supports configuring a user plane function to transmit and / or receive information regarding charging operations for sessions to and / or from other user plane functions.

[0095] In one embodiment, the first control plane function further comprises a second receiving module configured to receive from the second control plane function functionality supported by the second control plane function, the functionality supported by the second control plane function indicating that said second control plane function supports configuring a user plane function to send and / or receive information regarding charging operations for sessions to and / or from other user plane functions.

[0096] In a tenth aspect of the present disclosure, there is provided a computer program product comprising instructions which, when executed by at least one processor, cause the at least one processor to perform any of the methods according to the first, second or third aspects of the present disclosure.

[0097] In an eleventh aspect of the present disclosure, there is provided a computer-readable storage medium storing instructions which, when executed by at least one processor, cause the at least one processor to perform any of the methods according to the first, second or third aspects of the present disclosure.

[0098] The embodiments herein provide many advantages, a non-exhaustive list of examples of which follows. Some embodiments herein can solve the overcharging problem of charging suspension in at least one of the following scenarios: CUPS in 4G with SGW-C and PGW-C, 5G roaming with V-SMF and H-SMF, 5G with I-SMF and I-UPF inserted, and 5G with I-UPF inserted and I-SMF not inserted. Some embodiments herein can improve network quality. Some embodiments herein can improve operator satisfaction. Some embodiments herein can improve user satisfaction. The embodiments herein are not limited to the features and advantages described above. Those skilled in the art will recognize additional features and advantages upon reading the following detailed description. [Brief description of the drawings]

[0099] The above and other aspects, features, and advantages of various embodiments of the present disclosure will become more fully apparent from the following detailed description, taken by way of example only with reference to the accompanying drawings, in which: The drawings are illustrated to facilitate an understanding of embodiments of the present disclosure and are not necessarily drawn to scale:

[0100] [Figure 1] 13 is a flowchart of an SMF billing suspension procedure.

[0101] [Diagram 2] 13 is a flowchart of the charging suspension procedure of the PDN_GW.

[0102] [Diagram 3] An example of the overcharging problem with billing suspension in a 5G roaming scenario is given.

[0103] [Figure 4] This shows an example of the overcharging problem of billing suspension in a scenario where I-SMF and I-UPF are inserted in 5G.

[0104] [Diagram 5] An example of an overcharging problem for billing suspension in a scenario where I-UPF is inserted and I-SMF is not inserted in 5G is shown.

[0105] [Figure 6] This shows an example of the overcharging problem with billing suspension in a 4G CUPS scenario.

[0106] [Figure 7] 1 shows a schematic diagram of the high-level architecture of CUPS in a 4G network.

[0107] [Figure 8] 1 illustrates a schematic diagram of a high-level architecture in a fifth generation network according to one embodiment of the present disclosure.

[0108] [Figure 9] 1 shows a flowchart of a method according to one embodiment of the present disclosure.

[0109] [Figure 10] 4 shows a flowchart of a method according to another embodiment of the present disclosure.

[0110] [Figure 11] 4 shows a flowchart of a method according to another embodiment of the present disclosure.

[0111] [Figure 12] 4 shows a flowchart of a method according to another embodiment of the present disclosure.

[0112] [Figure 13] 4 shows a flowchart of a method according to another embodiment of the present disclosure.

[0113] [Figure 14] 4 shows a flowchart of a method according to another embodiment of the present disclosure.

[0114] [Figure 15] 1 illustrates a flowchart of a solution for solving the overcharging problem in a 5G roaming scenario according to an embodiment of the present disclosure.

[0115] [Figure 16] 1 illustrates a flowchart of a solution for solving the overcharging problem in a scenario of I-SMF and I-UPF inserted into 5G according to an embodiment of the present disclosure.

[0116] [Figure 17] 1 illustrates a flowchart of a solution for solving the overcharging problem in a scenario in which I-UPF is inserted and I-SMF is not inserted in 5G according to one embodiment of the present disclosure.

[0117] [Figure 18] 1 illustrates a flowchart of a solution for solving the overcharging problem in a 4G CUPS scenario according to one embodiment of the present disclosure.

[0118] [Figure 19] FIG. 1 is a block diagram illustrating an apparatus suitable for use in implementing some embodiments of the present disclosure.

[0119] [Figure 20] FIG. 2 illustrates a simplified block diagram of a first user plane function according to one embodiment of the present disclosure.

[0120] [Figure 21] FIG. 2 illustrates a simplified block diagram of a second user plane function according to one embodiment of the present disclosure.

[0121] [Figure 22] FIG. 2 illustrates a simplified block diagram of a first control plane function according to one embodiment of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0122] The embodiments of the present disclosure will be described in detail with reference to the accompanying drawings. It should be understood that these embodiments are discussed merely for the purpose of enabling those skilled in the art to better understand and thus practice the present disclosure, and are not intended to imply any limitations on the scope of the present disclosure. Throughout this specification, references to features, advantages, or similar language do not imply that all of the features and advantages that may be realized by the present disclosure should be in any single embodiment of the present disclosure, or are in any single embodiment of the present disclosure. Rather, language referring to features and advantages is understood to mean that the particular features, advantages, or characteristics described in connection with the embodiments are included in at least one embodiment of the present disclosure. Furthermore, the described features, advantages, and characteristics of the present disclosure can be combined in any suitable manner in one or more embodiments. A person skilled in the relevant art will recognize that the present disclosure may be practiced without one or more specific features or advantages of a particular embodiment. In other instances, additional features and advantages that may not be present in all embodiments of the present disclosure may be recognized in certain embodiments.

[0123] As used herein, the term "network" refers to a network conforming to any suitable wireless communication standard, such as New Radio (NR), Long Term Evolution (LTE), LTE Advanced, Wideband Code Division Multiple Access (WCDMA), High Speed ​​Packet Access (HSPA), Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal Frequency Division Multiple Access (OFDMA), Single Carrier Frequency Division Multiple Access (SC-FDMA), and other wireless networks. A CDMA network may implement a radio technology such as Universal Terrestrial Radio Access (UTRA). UTRA includes other variants of WCDMA and CDMA. A TDMA network may implement a radio technology such as Global System for Mobile Communications (GSM). The OFDMA network may implement a radio technology such as Evolved UTRA (E-UTRA), Ultra Mobile Broadband (UMB), IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, Flash-OFDMA, ad-hoc networks, wireless sensor networks, etc. In the following description, the terms "network" and "system" may be used interchangeably. Furthermore, communication between two devices in the network may be performed according to any suitable communication protocol, including, but not limited to, communication protocols defined by a standards organization such as 3GPP. For example, the communication protocol may include first generation (1G), 2G, 3G, 4G, 4.5G, 5G communication protocols, and / or other protocols currently known or developed in the future.

[0124] The term "network device" or "network node" as used herein refers to a network entity such as a core network device of a communication network. For example, in a wireless communication network such as a 3GPP type cellular network, the network node is composed of control plane functions (e.g., SMF, PGW-C, TDF-C and SGW-C) and user plane functions (e.g., UPF, PGW-U, TDF-U and SGW-U), etc., and can provide multiple services to customers interconnected by access network devices. Each access network device can be connected to a core network device via a wired or wireless connection.

[0125] The term "Network Function (NF)" refers to any suitable function that can be implemented in a network node (physical or virtual), such as a core network node of a communication network. For example, a 5G system (5GS) may be composed of multiple NFs, such as AMF (Access and Mobility Function), SMF (Session Management Function), AUSF (Authentication Service Function), UDM (Unified Data Management), PCF (Policy Control Function), AF (Application Function), NEF (Network Exposure Function), UPF (User Plane Function), and NRF (NF Repository Function), RAN (Radio Access Network), SCP (Service Communication Proxy), etc. In other embodiments, the Network Function may be composed of different types of NFs, for example, depending on the particular type of network.

[0126] The term "terminal device" refers to any end device capable of accessing and receiving services from a communications network. By way of example and not limitation, a terminal device may refer to a mobile terminal, a user equipment (UE), or other suitable device. A UE may be, for example, a subscriber station (SS), a mobile subscriber station, a mobile station (MS), or an access terminal (AT). Terminal devices include, but are not limited to, portable computers, imaging terminal devices such as digital cameras, gaming terminal devices, music storage and playback appliances, mobile phones, cellular phones, smartphones, voice over IP (VoIP) phones, wireless local loop phones, tablets, wearable devices, personal digital assistants (PDAs), portable computers, desktop computers, wearable terminal devices, in-vehicle wireless terminal devices, wireless endpoints, mobile stations, laptop embedded equipment (LEE), laptop embedded equipment (LME), USB dongles, smart devices, wireless customer premises equipment (CPE), and the like. In the following description, the terms "terminal device", "terminal", "user equipment" and "UE" may be used interchangeably. As an example, a terminal device may represent a UE configured to communicate according to one or more communication standards promulgated by 3GPP, such as the 3GPP LTE or NR standards. As used herein, "user equipment" or "UE" may not necessarily have a "user" in the sense of a human user who owns and / or operates the associated equipment. In some embodiments, a terminal device may be configured to transmit and / or receive information without direct human interaction. For example, a terminal device may be designed to transmit information to a network on a predetermined schedule, when triggered by an internal or external event, or in response to a request from the communication network. Instead, a UE may represent a device that is intended for sale to or operation by a human user, but may not initially be associated with a particular human user.

[0127] As yet another example, in an Internet of Things (IOT) scenario, a terminal device may represent a machine or other device that performs monitoring and / or measurements and transmits results of such monitoring and / or measurements to other terminal devices and / or network equipment. In this case, the terminal device is a machine-to-machine (M2M) device, which may be referred to in the 3GPP context as a machine-type communication (MTC) device. As a particular example, the terminal device may be a UE implementing the 3GPP narrowband Internet of Things (NB-IoT) standard. Specific examples of such machines or devices include sensors, metering devices such as power meters, industrial machines, or household or personal appliances (such as personal wearables such as refrigerators, televisions, and watches). In other scenarios, the terminal device may represent a vehicle or other equipment that can monitor and / or report its operating state or other functions related to its operation.

[0128] References herein to "one embodiment," "one(a) embodiment," "exemplary embodiment," and the like indicate that the embodiment being described may include a particular feature, structure, or characteristic, but not all embodiments need to include the particular feature, structure, or characteristic. Moreover, such phrases do not necessarily refer to the same embodiment. Furthermore, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one of ordinary skill in the art to affect such feature, structure, or characteristic in connection with other embodiments, whether or not expressly described.

[0129] In this specification, terms such as "first" and "second" may be used to describe various elements, but it should be understood that these elements should not be limited by these terms. These terms are merely used to distinguish one element from another. For example, a first element can be referred to as a second element, and similarly, a second element can be referred to as a first element, without departing from the scope of the exemplary embodiments. As used herein, the term "and / or" includes any and all combinations of one or more of the associated listed terms.

[0130] The terms used herein are for the purpose of describing particular embodiments only and are not intended to limit the exemplary embodiments. As used herein, the singular forms "a", "an", and "the" are intended to include the plural forms unless the context clearly indicates otherwise. It will be further understood that as used herein, the terms "comprises", "comprising", "has", "having", "includes", and / or "including" specify the presence of stated features, elements, and / or components, etc., but do not exclude the presence or addition of one or more other features, elements, components, and / or combinations thereof.

[0131] Please note that these terms used in this document are only used to briefly describe and distinguish between nodes, devices, networks, etc. As technology develops, other terms with similar / identical meanings may also be used.

[0132] In the following description and claims, unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs.

[0133] Although the subject matter described herein may be implemented in any suitable type of system using any suitable components, the embodiments disclosed herein are described in the context of a communication system conforming to the exemplary system architecture shown in Figures 7 and 8. For simplicity, the system architectures of Figures 7-8 depict only some exemplary elements. In practice, the communication system may further include any additional elements suitable for supporting communications between terminal devices, or between wireless devices and other communication devices (such as landlines, service providers, or any other network nodes or terminal devices). The communication system may provide communications and various types of services to one or more terminal devices and facilitate the terminal devices' access to and / or use of services provided by or via the communication system.

[0134] FIG. 7 illustrates a schematic high-level architecture of CUPS in a fourth generation network. The system architecture in FIG. 7 may be the same as the architecture reference model described in section 4.2 of 3GPP TS23.214 V16.2.0 and may be composed of several exemplary network nodes such as Serving Gateway-C (SGW-C), Serving Gateway-U (SGW-U), PDN Gateway-C (PGW-C), PDN Gateway-U (PGW-U), TDF-C and TDF-U. As further illustrated in FIG. 7, the exemplary system architecture may also include several interfaces such as Sxa.Sxb, Sxc, etc. The various network nodes illustrated in FIG. 7 may be responsible for functions as defined in 3GPP TS23.214 V16.2.0, for example. Although only one PGW-U is illustrated in the system, each PGW-C can manage / control one or more PGW-Us. Although each SGW-C can manage / control multiple SGW-Us, only one SGW-U is illustrated in the system. Each TDF-C can manage / control multiple TDF-Us, but only one TDF-U is visible in the system.

[0135] FIG. 8 illustrates a schematic diagram of a high-level architecture in a fifth generation network according to an embodiment of the present disclosure. For example, the fifth generation network may be a 5GS (5G system). The architecture in FIG. 8 is the same as FIG. 4.2.3-1 described in 3GPP TS23.501 V16.7.0, the disclosure of which is incorporated herein by reference in its entirety. The system architecture in FIG. 8 may be composed of several exemplary elements, such as AUSF, AMF, DN (Data Network), NEF, NRF, NSSF, PCF, SMF, UDM, UPF, AF, UE, (R)AN, SCP (Service Communication Proxy), and NSSAAF (Network Slice-Specific Authentication and Authorization Function).

[0136] According to an example embodiment, the UE can establish a signaling connection with the AMF via reference point N1, as shown in Figure 8. This signaling connection can enable NAS (Non-Access Stratum) signaling exchange between the UE and the core network, including a signaling connection between the UE and the (R)AN and an N2 connection of this UE between the (R)AN and the AMF. The (R)AN can communicate with the UPF via reference point N3. The UE can establish a Protocol Data Unit (PDU) session to a DN (data network, e.g., an operator network or the Internet) via the UPF via reference point N6.

[0137] As further illustrated in Figure 8, the exemplary system architecture also includes service-based interfaces such as Nnrf, Nnef, Nausf, Nudm, Npcf, Namf and Nsmf that are indicated by NFs such as NRF, NEF, AUSF, UDM, PCF, AMF and SMF. Additionally, reference points such as N1, N2, N3, N4, N6, N9 that can support interactions between NF services within a NF are also illustrated in Figure 8. For example, these reference points can be realized through corresponding NF service-based interfaces and by specifying consumers and providers of some NF services and their interactions to perform certain system procedures.

[0138] The various NFs shown in Figure 8 may be responsible for functions such as session management, mobility management, authentication, security, etc. The AUSF, AMF, DN, NEF, NRF, NSSF, PCF, SMF, UDM, UPF, AF, UE, (R)AN, and SCP may include functions defined, for example, in Section 6.2 of 3GPP TS23.501 V16.7.0.

[0139] 9 illustrates a flowchart of a method according to one embodiment of the present disclosure, which may be implemented in / as a first user plane function or performed by an apparatus communicatively coupled to the first user plane function. In this manner, the apparatus may provide means or modules for accomplishing various portions of the method 900, as well as means or modules for accomplishing other processes in conjunction with other components.

[0140] At block 902, the first user plane function may determine a charging action for the first session. The first session may be any suitable session, such as described in various 3GPP specifications, e.g., 3GPP TS23.501 V16.7.0, 3GPP TS23.401 V16.9.0, etc. In one embodiment, the first session may be a PDU session or an IPCAN (Internet Protocol-Connectivity Access Network) session. The first user plane function may be any suitable entity or node capable of performing a user plane function. In an embodiment, the first user plane function may be a Serving Gateway User Plane (SGW-U), a Visited User Plane Function (V-UPF), an Intermediate User Plane Function (I-UPF), etc.

[0141] The charging action may be any suitable charging action, such as start charging, suspend charging, stop charging, cancel charging, etc. In one embodiment, the charging action comprises an immediate initiation of a suspension of charging.

[0142] The first user plane function may determine a charging action for the first session if some condition or policy or configuration is met. In one embodiment, the charging action is determined based on at least one of an operator policy or an operator configuration. For example, the following are exemplary triggers for the first user plane function to determine a charging action, such as suspend charging: - Operator specified criteria / thresholds (e.g. number / percentage of packets / bytes dropped in the downlink UPF since the N3 tunnel towards the AN was last opened). Whenever a criterion / threshold related to the first session is met, the first user plane function can decide on a charging action, such as suspending charging. Indication of radio link failure: Whenever the first user plane function learns of a radio link failure related to the first session, the first user plane function can decide on a charging action, such as suspending charging.

[0143] At block 904, the first user plane function may send information regarding the charging operation for the first session to the second user plane function. The second user plane function may be any suitable entity or node capable of performing a user plane function. In one embodiment, the first user plane function may be a Packet Data Network User Plane (PGW-U), a Home User Plane Function (H-UPF), an Anchor User Plane Function (A-UPF, also referred to as PDU Session Anchor (PSA) UPF), or the like.

[0144] In an embodiment, the first user plane function may be a user plane function closer to the UE or RAN, and the second user plane function may be a user plane function closer to the data network. In an embodiment, the first user plane function may be a user plane function closer to the UE or RAN than the second user plane function.

[0145] The information regarding the charging action for the first session may be included in an appropriate message (such as an existing message or a new message) that may be sent between the first user plane function and the second user plane function.

[0146] In one embodiment, the information regarding the charging operation of the first session is configured in a GTP-U (General Packet Radio Service Tunneling Protocol for User Plane) tunnel status message.

[0147] In one embodiment, after the first user plane function determines the charging action for the first session, it immediately sends information regarding the charging action for the first session to the second user plane function.

[0148] At block 906, optionally, the first user plane function may receive an acknowledgment from the second user plane function for the information regarding the charging operation for the first session.

[0149] The acknowledgement for the information regarding the charging operation of the first session may be configured in an appropriate message (such as an existing message or a new message) that can be sent between the first user plane function and the second user plane function. In one embodiment, the acknowledgement for the information regarding the charging operation of the first session is included in another GTP-U tunnel status message, such as a GTP-U tunnel status acknowledgement message.

[0150] 10 shows a flowchart of a method according to another embodiment of the present disclosure, which may be implemented in / as a first user plane function or executed by an apparatus communicatively coupled to the first user plane function. In this manner, the apparatus may provide means or modules for accomplishing various parts of the method 1000, as well as means or modules for accomplishing other processes in cooperation with other components. Some parts described in the above embodiments are not described here for brevity.

[0151] In block 1002, the first user plane function may receive an indication from the control plane function to send information regarding the charging action for the second session to another user plane function after determining the charging action for the second session. The second session may be any suitable session, as described in various 3GPP specifications, e.g., 3GPP TS23.501 V16.7.0, 3GPP TS23.401 V16.9.0, etc. In one embodiment, the second session may be a PDU session or an IPCAN session. In an embodiment, the second session may be the same as the first session. The control plane function may send this indication for a single session, a group of sessions, or all sessions controlled by the first user plane function.

[0152] The control plane function may be any suitable entity or node capable of implementing a control plane function. In one embodiment, the control plane function may be a Packet Data Network Control Plane (PGW-C), a Serving Gateway Control Plane (SGW-C), or a Session Management Function (SMF), as described in 3GPP TS23.214 V16.2.0 and TS29.244 V16.6.0. The SMF may be an Intermediate SMF (I-SMF), Anchor SMF (A-SMF), Visited SMF (V-SMF), or Home SMF (H-SMF), etc.

[0153] The indication may be configured in an appropriate message (such as an existing message or a new message) transmittable between the first user plane function and the control plane function. In one embodiment, the indication is included in at least one of a Packet Forwarding Control Protocol (PFCP) Session Establishment Request, a PFCP Session Modification Request, an Sx Session Establishment Request, or an Sx Session Modification Request, as described in 3GPP TS 29.244 V16.6.0, as described in 3GPP TS 23.214 V16.2.0.

[0154] Blocks 1004, 1006, and 1008 are the same as blocks 902, 904, and 906, respectively, of FIG.

[0155] 11 shows a flowchart of a method according to another embodiment of the present disclosure, which may be implemented in / as a first user plane function or executed by an apparatus communicatively coupled to the first user plane function. In this manner, the apparatus may provide means or modules for accomplishing various parts of the method 1100, as well as means or modules for accomplishing other processes in cooperation with other components. Some parts described in the above embodiments are not described here for brevity.

[0156] At block 1102, the first user plane function may send capabilities supported by the first user plane function to the control plane function, where the capabilities supported by the first user plane function indicate that the first user plane function supports sending and / or receiving information regarding charging operations of sessions to and / or from other user plane functions.

[0157] The capabilities supported by the first user plane function may be configured in an appropriate message (such as an existing message or a new message) that may be sent between the first user plane function and the control plane function. In one embodiment, the capabilities supported by the first user plane function are configured in a Packet Forwarding Control Protocol (PFCP) Association Setup Response or Request, as described in 3GPP TS29.244 V16.6.0.

[0158] In block 1104, the first user plane function may receive from the control plane function an indication to send information regarding the charging operation for the second session to other user plane functions after determining the charging operation for the second session. For example, if the control plane function knows that the first user plane function supports sending information regarding the charging operation for the session to other user plane functions, the control plane function may send this indication to the first user plane function.

[0159] 12 shows a flowchart of a method according to another embodiment of the present disclosure, which may be implemented in / as a second user plane function or executed by an apparatus communicatively coupled to the second user plane function. In this manner, the apparatus may provide means or modules for accomplishing various parts of the method 1200, as well as means or modules for accomplishing other processes in cooperation with other components. Some parts described in the above embodiments are not described here for brevity.

[0160] The second user plane function may receive information regarding charging operations for the first session from the first user plane function in block 1202. For example, the first user plane function may send information regarding charging operations for the first session to the second user plane function in block 904 of Figure 9, and the second user plane function may then receive the information regarding charging operations for the first session.

[0161] In block 1204, the second user plane function may perform a charging operation for the first session based on the information about the charging operation for the first session. For example, if the charging operation is start charging, pause charging, stop charging, or cancel charging, the second user plane function may perform start charging, pause charging, stop charging, or cancel charging.

[0162] At block 1206, optionally, the second user plane function may send an acknowledgment to the first user plane function regarding the charging operation for the first session.

[0163] In one embodiment, after the second user plane function receives information regarding a charging operation for the first session from the first user plane function, the second user plane function can immediately perform a charging operation for the first session based on the information regarding the charging operation for the first session.

[0164] 13 shows a flowchart of a method according to another embodiment of the present disclosure, which may be implemented in / as a second user plane function or executed by an apparatus communicatively coupled to the second user plane function. In this manner, the apparatus may provide means or modules for accomplishing various parts of the method 1300, as well as means or modules for accomplishing other processes in cooperation with other components. Some parts described in the above embodiments are not described here for brevity.

[0165] In block 1302, the second user plane function may send capabilities supported by the second user plane function to the control plane function. The capabilities supported by the second user plane function indicate that the second user plane function supports sending and / or receiving information regarding charging behavior of sessions to and / or from other user plane functions. Block 1302 is similar to block 1102 of Figure 11. The capabilities supported by the second user plane function are configured in a Packet Forwarding Control Protocol (PFCP) association setup response or request.

[0166] In block 1304, the second user plane function may receive an indication from the control plane function of whether a usage reporting rule (URR) is applicable to the charging action received from the other user plane function. If the URR is applicable to the charging action received from the other user plane function, the second user plane function may apply the URR. If not, the second user plane function may not apply the URR.

[0167] 14 shows a flowchart of a method according to another embodiment of the present disclosure, which may be implemented in / as a first control plane function or executed by an apparatus communicatively coupled to the first control plane function. In this manner, the apparatus may provide means or modules for accomplishing various parts of the method 1400, as well as means or modules for accomplishing other processes in cooperation with other components. Some parts described in the above embodiments are not described here for brevity.

[0168] At block 1402, the first control plane function may receive user plane function supported capabilities from a user plane function. The user plane function supported capabilities indicate that the user plane function supports sending and / or receiving information regarding charging behavior of sessions to and / or from other user plane functions.

[0169] In block 1404, optionally, the first control plane function, after determining the charging action for the session, may send an indication to a user plane function to send information regarding the charging action for the session to another user plane function.

[0170] In block 1406, optionally, the first control plane function may send capabilities supported by the first control plane function to the second control plane function, where the capabilities supported by the first control plane function indicate that the first control plane function supports configuring the user plane function to send and / or receive information regarding charging behavior for the session to and / or from other user plane functions.

[0171] In block 1408, optionally, the first control plane function may receive from the second control plane function capabilities supported by the second control plane function, where the capabilities supported by the second control plane function indicate that the second control plane function supports configuring the user plane function to send and / or receive information regarding charging operations for the session to and / or from other user plane functions.

[0172] The capabilities supported by the first control plane function may be configured in an appropriate message (such as an existing message or a new message) that may be sent between the first control plane function and the second control plane function. In one embodiment, the capabilities supported by the first control plane function may be configured in a create session request. In an embodiment, the create session request may be an Nsmf_PDUSession_Create request as described in 3GPP TS23.502 V16.7.1 or a Create Session request as described in 3GPP TS23.401 V16.9.0.

[0173] The capabilities supported by the second control plane function may be configured in an appropriate message (such as an existing message or a new message) that may be sent between the first and second control plane functions. In an embodiment, the capabilities supported by the second control plane function may be configured in a create session response. In an embodiment, the create session response may be an Nsmf_PDUSession_Create response as described in 3GPP TS23.502 V16.7.1 or a Create Session response as described in 3GPP TS23.401 V16.9.0.

[0174] In one embodiment, a new function "Initiate Charging Suspension Immediately" is introduced: the UP function (function closer to the RAN) immediately sends a new GTP-U (General Packet Radio Service Tunneling Protocol for User Plane) message to the remote upstream UPF with information that triggers the receiving UPF to stop measuring URRs (Usage Reporting Rules) with "Charging Suspension Applied Flag" set when the dropped packets threshold is reached.

[0175] In one embodiment, the UP function (e.g., SGW-U, PGW-U, I-UPF, PSA-UPF) may negotiate with the CP function (e.g., SGW-C, PGW-C, I-SMF, Home-SMF, SMF) during the PFCP association setup procedure that it supports the new function "Immediate Start of Charging Suspension".

[0176] In one embodiment, during a PDU session establishment or modification procedure, the CP function (e.g., SGW-C, I-SMF) may provide an indication to the UP function to send a new GTP-U message (which may be referred to as "GTP-U tunnel state information") or an existing GTP-U message including a flag to the upstream UPF (e.g., I-UPF, PSA's UPF, PGW-U). The indication may be, for example, a flag in the measurement information in the URR to the I-UPF, PSA's UPF, or PGW-U) to send a new GTP-U message, which may be referred to as "GTP-U tunnel state information", or an existing GTP-U message including a flag that triggers the receiving UPF to stop measuring the URR with the "Charging Suspend Applied Flag" set to "1" when the upstream UPF reaches a threshold of dropped packets. The indication may be, for example, a flag in the measurement information in the URR.

[0177] In one embodiment, during a PDU session establishment or modification procedure, the CP function (e.g., PGW-C, SMF and Home SMF) includes a new flag, which may be called the "Charging Suspension Applied Flag", in the URR for which charging is intended to be suspended, allowing the UP function to stop measuring the URR if it receives a GTP-U message with an indication to stop measurement.

[0178] In one embodiment, CPs such as SGW-C, I-SMF, V-SMF, etc., can indicate support for the new feature "Immediate Start of Suspension of Charging over User Plane" when establishing a PDN connection / PDU session towards CPs such as PGW-C, SMF, Home SMF, etc., if UPs such as SGW-U, I-UPF, V-UPF, etc., support the new feature. CPs such as PGW-C, SMF, Home SMF, etc., can confirm support for the same new feature if UPs such as PGW-U, PSA's UPF, etc., support the new feature.

[0179] In one embodiment, between a first CP, such as an SGW-C, and a second CP, such as a PGW-C, a new flag that can be called "Support for initiating charging suspension over user plane path" is introduced (e.g., in an indication IE (information element)) over the interface (e.g., S5 / S8) between the first CP and the second CP, or entered as a supported capability using an echo request / response as part of the supported capabilities notification as specified in 3GPP TS29.274 V17.0.0, clause 11.

[0180] In one embodiment, after a UP such as UPF receives DL data and triggers a DDN (Downlink Data Notification) procedure, the UP such as UPF starts dropping packets due to slow paging response, and the dropped packets reach a threshold, so the UP such as UPF immediately sends a GTP-U Tunnel Status message to a remote UP such as UPF, which includes an indicator of Initiate Charging Suspend. The remote UP such as UPF immediately suspends charging for this PDU session.

[0181] In one embodiment, the normal charging suspend procedure is still performed and the remote UP, such as the UPF, does not have a suspend charging operation because a suspend charging operation was previously performed. A normal charging suspend is performed for the following reasons: · The subsequent billing suspension unblocking procedure must be performed on the remote CP. If unblocking is required, the CP can notify the remote CP of the billing suspension; · Even if a new GTP-U message fails to be sent, the existing mechanisms still work to properly maintain the suspension of charging.

[0182] In one embodiment, the proposed solution to the overcharging problem can be applied to at least one of the scenarios: 4G CUPS with SGW-C and PGW-C, -5G roaming with V-SMF and H-SMF, 5G with I-SMF and I-UPF inserted 5G with I-UPF inserted but I-SMF not inserted

[0183] In one embodiment, when an intermediate UP such as a UPF receives the same information regarding the charging operation of the first session from an upstream UP entity (e.g., UE-NG-RAN-I-UPF-I-UPF2 (e.g., BP (Branch Point))-PSA1), it can forward the information regarding the charging operation of the first session to the next downstream UP entity, and the I-UPF2 forwards the information regarding the charging operation of the first session received from the I-UPF to PSA1.

[0184] FIG. 15 shows a flowchart of a solution for solving the overcharging problem in a 5G roaming scenario according to an embodiment of the present disclosure.

[0185] In step 1, the V-SMF sends a PFCP association setup request to the V-UPF.

[0186] In step 2, the V-UPF sends the PFCP association setup response with the UP Capability Feature: ISPOC (Initiate Charging Suspension Immediately) to the V-SMF to inform it that the V-UPF supports ISPOC.

[0187] In step 3, the H-SMF sends a PFCP association setup request to the H-UPF.

[0188] In step 4, the H-UPF sends the PFCP association establishment response to the H-SMF with the UP feature: ISPOC (Initiate Charging Suspension Immediately) to inform the H-SMF that the H-UPF supports ISPOC.

[0189] In step 5 of the PDU session establishment procedure, the V-SMF sends a PFCP session establishment / modification request (measurement information: sent-start-pause-of-charging) to the V-UPF. This indicator is used to instruct the UPF to send a new GTP-U message containing an indicator (start-pause-of-charging) when the DL threshold is reached.

[0190] In step 6, the V-UPF sends a PFCP Session Establishment / Modification Response to the V-SMF.

[0191] In step 7, the V-SMF sends a Nsmf_PDUSession_Create request (supported functions: ISPOC) to the H-SMF.

[0192] In step 8, the H-SMF sends a PFCP Session Establishment / Modification Request to the H-UPF with measurement information: start-pause-of-charging. This indicator is used to tell the UPF to stop measurements when it receives a new GTP-U message with indicator: start-pause-of-charging.

[0193] In step 9, the H-UPF sends a PFCP Session Establishment / Modification Response to the H-SMF.

[0194] In step 10, the H-SMF sends a Nsmf_PDUSession_Create response (corresponding feature: ISPOC) to the V-SMF.

[0195] In step 11, later when the UE enters IDLE state, the V-UPF receives DL data of the UE and triggers the DDN procedure, and the V-UPF starts dropping packets for reasons such as slow paging response, and the dropped packets reach a threshold.

[0196] In step 12, the V-UPF immediately sends the GTP-U tunnel status to the H-UPF.

[0197] In step 13, the H-UPF sends a GTP-U tunnel status response to the V-UPF.

[0198] In step 14, charging is suspended in the H-UPF for this PDU session.

[0199] In step 15, the V-UPF sends a PFCP session report request (Utilization Report Trigger (DROTH)) to the V-SMF.

[0200] In step 16, the V-SMF sends a PFCP Session Report response to the V-UPF.

[0201] In step 17, the V-SMF sends an Nsmf_PDUSession_Update request ("Start charging suspension" indication) to the H-SMF.

[0202] In step 18, the H-SMF sends a Nsmf_PDUSession_Update response to the V-SMF.

[0203] In step 19, the H-SMF sends a PFCP session modification request (inactive measurement flag=1) to the H-UPF.

[0204] In step 20, the H-UPF sends a PFCP session modification response to the H-SMF.

[0205] Steps 15-20 are the normal billing suspension procedure, and since the billing suspension operation has already been executed in step 14 of FIG. 15, the H-UPF does not perform the billing suspension operation.

[0206] FIG. 16 shows a flowchart of a solution for solving the overcharging problem in a scenario of I-SMF and I-UPF inserted into 5G according to an embodiment of the present disclosure.

[0207] In step 1, the I-SMF sends a PFCP association setup request to the I-UPF.

[0208] In step 2, the I-UPF sends a PFCP association establishment response to the I-SMF with the UP feature: ISPOC (Initiate Charging Suspension Immediately) to inform the I-SMF that the I-UPF supports ISPOC.

[0209] In step 3, the A-SMF sends a PFCP association setup request to the A-UPF.

[0210] In step 4, the A-UPF sends the PFCP association setup response with the UP capability feature: ISPOC (Immediate Initiation of Charging Suspension) to the A-SMF to inform it that the A-UPF supports ISPOC.

[0211] In step 5 of the PDU Session Establishment procedure, the I-SMF sends a PFCP Session Establishment / Modification Request containing the measurement information (sent-start-pause-of-charging) to the I-UPF. This indicator is used to instruct the UPF to send a new GTP-U message containing an indicator (start-of-charging pause) when the DL threshold is reached.

[0212] In step 6, the I-UPF sends a PFCP Session Establishment / Modification Response to the V-SMF.

[0213] In step 7, the I-SMF sends a Nsmf_PDUSession_Create request (corresponding feature: ISPOC) to the A-SMF.

[0214] In step 8, the A-SMF sends a PFCP Session Establishment / Modification Request to the A-UPF with measurement information: start-pause-of-charging. This indicator is used to tell the UPF to stop measurements when a new GTP-U message with indicator: start-pause-of-charging is received.

[0215] In step 9, the A-UPF sends a PFCP Session Establishment / Modification Response to the A-SMF.

[0216] In step 10, the A-SMF sends a Nsmf_PDUSession_Create response (supported features: ISPOC) to the V-SMF.

[0217] In step 11, later when the UE enters IDLE state, the I-UPF receives DL data of the UE and triggers the DDN procedure, and the I-UPF starts dropping packets for reasons such as slow paging response, and the dropped packets reach a threshold.

[0218] In step 12, the I-UPF immediately sends the GTP-U tunnel status with an indicator to the A-UPF.

[0219] In step 13, the A-UPF sends a GTP-U tunnel status response to the I-UPF.

[0220] In step 14, charging is suspended in the A-UPF for this PDU session.

[0221] In step 15, the I-UPF sends a PFCP session report request (usage report trigger (DROTH)) to the I-SMF.

[0222] In step 16, the I-SMF sends a PFCP Session Report response to the I-UPF.

[0223] In step 17, the I-SMF sends an Nsmf_PDUSession_Update request ("Start charging suspension" indication) to the A-SMF.

[0224] In step 18, the A-SMF sends an Nsmf_PDUSession_Update response to the I-SMF.

[0225] In step 19, the A-SMF sends a PFCP session modification request (inactive measurement flag=1) to the A-UPF.

[0226] In step 20, the A-UPF sends a PFCP session modify response to the A-SMF.

[0227] Steps 15 to 20 are the normal billing suspension procedure, and since the billing suspension operation has already been executed in step 14 in FIG. 16, the A-UPF does not perform the billing suspension operation.

[0228] FIG. 17 shows a flowchart of a solution for solving the overcharging problem in a scenario in which I-UPF is inserted and I-SMF is not inserted in 5G according to one embodiment of the present disclosure.

[0229] In step 1, the SMF sends a PFCP association setup request to the I-UPF.

[0230] In step 2, the I-UPF sends the PFCP association establishment response with UP Function Features: ISPOC (Suspend Charging Immediately Initiated) to the SMF to inform the SMF that the I-UPF supports ISPOC.

[0231] In step 3, the SMF sends a PFCP association setup request to the A-UPF.

[0232] In step 4, the A-UPF sends the UP Capability feature in the PFCP Association Setup Response to inform the SMF that the H-UPF supports ISPOC.

[0233] In step 5 of the PDU session establishment procedure, the SMF sends a PFCP Session Establishment / Modification Request containing the measurement information (sent-start-pause-of-charging) to the I-UPF. This indicator is used to instruct the UPF to send a new GTP-U message containing an indicator (start-of-charging pause) when the DL threshold is reached.

[0234] In step 6, the I-UPF sends a PFCP Session Establishment / Modification Response to the SMF.

[0235] In step 7, the SMF sends a PFCP Session Establishment / Modification Request to the A-UPF with measurement information: start-pause-of-charging. This indicator is used to tell the UPF to stop measurements when it receives a new GTP-U message with indicator: start-pause-of-charging.

[0236] In step 8, the A-UPF sends a PFCP Session Establishment / Modification Response to the SMF.

[0237] In step 9, later when the UE enters IDLE state, the I-UPF receives DL data of the UE and triggers the DDN procedure, and the I-UPF starts dropping packets for reasons such as slow paging response, and the dropped packets reach a threshold.

[0238] In step 10, the I-UPF immediately sends the GTP-U tunnel status with an indicator to the A-UPF.

[0239] In step 11, the A-UPF sends a GTP-U tunnel status response to the I-UPF.

[0240] In step 12, charging is suspended in the A-UPF for this PDU session.

[0241] In step 13, the I-UPF sends a PFCP session report request (usage report trigger (DROTH)) to the SMF.

[0242] In step 14, the SMF sends a PFCP Session Report response to the I-UPF.

[0243] In step 15, the SMF sends a PFCP session modification request (inactive measurement flag = 1) to the A-UPF.

[0244] In step 16, the A-UPF sends a PFCP session modify response to the SMF.

[0245] FIG. 18 illustrates a flowchart of a solution for solving the overcharging problem in a 4G CUPS scenario according to one embodiment of the present disclosure.

[0246] In step 1, the SGW-C sends a PFCP association setup request to the SGW-U.

[0247] In step 2, the SGW-U sends a PFCP association setup response with the UP capability to the SGW-C: SGW-C sends an ISPOC (Initiate Charging Suspend Immediately) to the SGW-C to inform it that the SGW-U supports ISPOC.

[0248] In step 3, the PGW-C sends a PFCP association setup request to the PGW-U.

[0249] In step 4, the PGW-U sends a PFCP association setup response with UP function: PGW-C sends ISPOC (Initiate Charging Suspend Immediately) to the PGW-C to inform it that the PGW-U supports ISPOC.

[0250] In step 5 of the PDU session establishment procedure, the SGW-C sends a PFCP session establishment / modification request (measurement information: sent-start-pause-of-charging) to the SGW-U. This indicator is used to instruct the SGW-U to send a new GTP-U message containing an indicator (start-pause-of-charging) when the DL threshold is reached.

[0251] In step 6, the SGW-U sends a PFCP Session Establishment / Modify Response to the SGW-C.

[0252] In step 7, the SGW-C sends a create session request (PDN pause support indication) to the PGW-C.

[0253] In step 8, the PGW-C sends a PFCP Session Establishment / Modification Request (measurement information: start-pause-of-charging) to the PGW-U. This indicator is used to instruct the PGW-U to stop measurements when it receives a new GTP-U message with indicator: start-pause-of-charging.

[0254] In step 9, the PGW-U sends a PFCP Session Establishment / Modification Response to the PGW-C.

[0255] In step 10, the PGW-C sends a session creation response (PDN pause enable indication) to the SGW-C.

[0256] In step 11, when the UE enters IDLE state, the SGW-U receives the UE's DL data and triggers the DDN procedure.

[0257] In step 12, the SGW-U immediately sends the GTP-U tunnel status with an indicator to the PGW-U.

[0258] In step 13, the PGW-U sends a GTP-U tunnel status confirmation to the SGW-U.

[0259] In step 14, the PGW-U suspends charging for this PDU session.

[0260] In step 15, the SGW-U sends a PFCP session report request (usage report trigger (DROTH)) to the SGW-C.

[0261] In step 16, the SGW-C sends a PFCP Session Report Response to the SGW-U.

[0262] In step 17, the SGW-C sends a bearer modification request (PDN pause on indication) to the PGW-C.

[0263] In step 18, the PGW-C sends a bearer modification response to the SGW-C.

[0264] In step 19, the PGW-C sends a PFCP session modify request (inactive measurement flag=1) to the PGW-U.

[0265] In step 20, the PGW-U sends a PFCP session modify response to the PGW-C.

[0266] Steps 15-20 are the normal billing suspension procedure, and since the billing suspension operation has already been executed in step 14 of FIG. 18, the PGW-U does not perform the billing suspension operation.

[0267] In one embodiment, the following may be added to 3GPP TS29.281 V16.1.0: A new generic tunnel management message called "Tunnel Status" is introduced, which can be used to inform the UPF of the PGW-U or PSA that a charging suspension has been triggered. 4.4.2.x Tunnel Status The UDP destination port in the tunnel state must be the user plane UDP port (2152). 4.4.3.x Tunnel Status The IP source address MUST be the IP address of the source GTP-U entity where the message originated. The IP destination address must be the IP address of the destination GTP-U entity. The IP destination address and the IP source address must be the same as the corresponding GTP-U tunnel (sending G-PDU) through which the tunnel status message is sent. 5.1 General Format The GTP-U header is a variable-length header with a minimum length of 8 bytes. There are three flags used to indicate the presence of additional optional fields: the PN flag, the S flag, and the E flag. The PN flag is used to signal the presence of the N-PDU number. The S flag is used to signal the presence of the GTP sequence number field. The E flag is used to signal the presence of an extension header field, allowing future extensions of the GTP header defined in this document without the need to use other version numbers. The sequence number, N-PDU, and extension header fields shall be present if and only if one or more of these three flags are set. A sender MUST set all bits of unused fields to zero. A receiver MUST NOT evaluate unused fields. For example, if only the E flag is set to 1, the N-PDU number and sequence number fields are also present but are not evaluated as they do not have meaningful values. Fields that are always present: - Version Field: This field is used to determine the version of the GTP-U protocol. The version number is set to "1". - Protocol Type (PT): This bit is used as the protocol identifier for GTP (if PT is '1') and GTP' (if PT is '0'). The GTP is described in this document, and the GTP' protocol in 3GPP TS 32.295 [8]. Note that the interpretation of header fields may differ between GTP and GTP'. - Extension Header Flag (E): This flag indicates the presence of a meaningful value in the Next extension header field. If this flag is set to "0", the Next extension header field is not present or, if present, is not interpreted. If it is set to "1", the Next extension header field is present and is interpreted as described later in this section. -Sequence Number Flag (S): This flag indicates the presence of a meaningful value in the Sequence Number field. If this flag is set to "0", the Sequence Number field is not present or is not interpreted if present. If set to "1", the Sequence Number field is present and is interpreted as described later in this section. In Echo Request, Echo Reply, Error Indication and Supported Extension Header Notification messages, the S flag MUST be set to "1". Since the use of sequence numbers is optional for G-PDU, PGW, SGW, ePDG, eNodeB and TWAN should set this flag to "0". However, if a G-PDU (T-PDU + header) is relayed by the indirect data forwarding procedure of an inter-RAT HO, the relay entity shall set the S flag to "1" and forward the G-PDU (T-PDU + header) if the S flag is set to "1" in the received G-PDU. End Marker and tunnel status messages In this case, the S flag must be set to "0". - N-PDU Number Flag (PN): This flag indicates the presence of a meaningful value of the N-PDU Number field. If this flag is set to "0", the N-PDU Number field is not present or, if present, is not interpreted. If this flag is set to "1", the N-PDU Number field is present and is interpreted as described later in this section. - Message Type: This field indicates the type of the GTP-U message. - length: This field indicates the length in octets of the payload, i.e. the rest of the packet following the mandatory part of the GTP header (the first 8 octets). Any sequence number, N-PDU number or extension headers are considered part of the payload. - Tunnel Endpoint Identifier (TEID): This field unambiguously identifies the tunnel endpoint to the receiving GTPU protocol entity. The receiving side of a GTP tunnel locally assigns the TEID value to be used by the sending side. TEID values ​​shall be assigned in an unpredictable manner for the S5 / S8 / S2a / S2b interfaces of the PGW (see 3GPP TS 33.250

[32] ). The TEID is used by the receiving entity to locate the PDP context, except in the following cases: - In echo request / reply and supported extension header notification messages, the tunnel endpoint identifier MUST be set to all zeros. - An error indication message in which the tunnel endpoint identifier is set to all zeros. -When setting up a GTP-U tunnel, a GTP-U entity MUST NOT assign its own TEID the value "all zeros". However, for backward compatibility, if a GTP-U entity receives (in each control plane message) the TEID of its peer set to the value "all zeros", it shall accept this value as valid and send subsequent G-PDUs with the TEID field in the header set to the value "all zeros". Optional fields: - Sequence Number: If the sequence number field is used in a G-PDU (T-PDU + header), increasing sequence numbers of T-PDUs are sent through the GTP-U tunnel when the transmission order needs to be preserved. In supported extension header notification and error indication messages, the sequence number is ignored by the receiver even if the S flag is set to "1". -N-PDU number: This field is used in the inter-SGSN routing area update procedure and in some inter-system handover procedures (e.g. between 2G and 3G radio access networks). This field is used to coordinate the data transmission of confirmed communication modes between the MS and the SGSN. The exact meaning of this field depends on the scenario (e.g. GSM / GPRS to GSM / GPRS, the N-PDU number of the SNDCP is present in this field). - Next Extension Header Type: This field defines the type of the extension header that follows this field in the GTPPDU. TIFF0007652913000001.tif801706.1 General GTP-U defines a set of messages between both ends of the user plane of interfaces Iu, Gn, Gp, S1-U, S11-U, S2a, S2b, S4, S5, S8, S12, X2, M1, Sn, Xn, N3, N9, and N19. GTP-U messages are sent across the GTP user plane tunnel. GTP-U messages are either signaling messages that pass through the user plane tunnel, or G-PDU messages. -GTP-U signaling messages are used for user plane path management or user plane tunnel management. -G-PDU is a vanilla user plane message that carries the original packet (T-PDU). In a G-PDU message, the GTP-U header is followed by the T-PDU. A T-PDU is an original packet, such as an IP datagram, an Ethernet frame, or unstructured PDU data, from a UE or from a network node of an external packet data network. The full range of message types defined in GTPv1 is defined in 3GPP TS 29.060[6]. The table below includes those that apply to the GTP user plane. The three columns on the right define which of the three protocols (GTP-C, GTP-U, or GTP') that share the common header of GTPv1 implements that particular message type. TIFF0007652913000002.tif581707.3.2 End Marker 7.3.2.1 General The end marker message indicates the end of the payload stream for a tunnel, i.e., any G-PDUs arriving after the end marker message for this tunnel are silently discarded. Table 7.3.2.1-1 shows the information elements contained in the end marker message. If an end marker message is received with a TEID for which no context exists, the receiver MUST ignore the message. Optional private extensions contain vendor or operator specific information. TIFF0007652913000003.tif17170 7.3.x Tunnel Status The Tunnel Status message is optional. If supported, a GTP-U entity may send one or more Tunnel Status messages to a peer GTP-U entity to provide status information related to the corresponding GTP-U tunnel at the sending GTP-U entity. Table 7.3.2.1-1 shows the information elements contained in the Tunnel Status message. If a Tunnel Status message is received with a TEID for which no context exists, or if the message is not supported, the recipient MUST ignore the message. Optional private extensions contain vendor or operator specific information. TIFF0007652913000004.tif211708.1 Information element type GTP-U signaling messages contain multiple information elements. GTP information elements use the TLV (type, length, value) or TV (type, value) encoding format. In signaling messages, information elements are sorted in ascending order of the type field. The length field contains the length of the information element excluding the type and length fields. For all length fields, bit 8 of the least significant octet is the most significant bit, and bit 1 of the most significant octet is the least significant bit. Within an information element, certain fields may be described as reserved. These bits shall be transmitted with the defined values. To allow for future functionality, receivers shall not evaluate these bits. The most significant bit of the type field is set to 0 when using the TV format and to 1 when using the TLV format. The full range of information element types defined in GTPv1 is defined in 3GPP TS 29.060 [6]. The following table includes those that apply to the GTP user plane. TIFF0007652913000006.tif77170*** Next change **** 8.X GTP-U Tunnel Status Information The GTP-U tunnel state information includes state information related to the sending GTP-U entity's corresponding GTP-U tunnel. TIFF0007652913000007.tif34170 Octet 5 is encoded as follows: - Bit 1 - SPOC (Start Suspend Charging): if set to "1", indicates to the receiving GTP-U entity to request that it stop the usage measurement of the URR with an indication applicable to charging of the specified PFCP session. The GTP-U entity forwards the Tunnel Status message to the upstream GTP-U entity if it is not a UPF or PGW-U of the PSA connected to the N6 / SGi interface. -Bits 2 through 8 - Reserved, set to "0" for future use.

[0268] In one embodiment, the following content may be added to 3GPP TS29.244 V16.6.0: 5.2.2.2.1 General If the NSPOC functionality specified in section 5.x is supported by the CP and UP functions, the CP function can provision: - Measurement information with the "Start Charging Pause" flag set to "1" to request the UP function (SGW-U or I / V-UPF) to send a start charging pause indication to the upstream GTP-U entity when the dropped DL traffic threshold is reached. - Measurement information with the "Applicable for Start of Charging Suspend" flag set to "1" to indicate the UP capability to stop usage metering of the URR upon receiving a Start of Charging Suspend indication from the peer GTP-U entity. A CP function can request the UP function to measure the usage of network resources and generate a corresponding number of "usage reports" by specifying a "report count" IE in the URR, if the UP function supports the NORP function (see clause 8.2.25-1), in which case the URR becomes inactive in the UP function after the requested "report count" has been reported. The CP function may resume measurements of an inactive URR by setting the Inactive Measurement Flag in the Measurement Information IE of the URR to "0" in the Update URRIE of the PFCP Session Modify Request message, with or without the Report Count IE. If the CP function wishes the UP function to perform continuous measurements for the URR specified by the Report Count (i.e., to no longer limit the number of reports generated), the CP function shall provide a null length in the Report Count IE in the Update URR to remove the limit on the number of reports generated. Note 12: The "number of reports" can be specified in the URR, regardless of which measurement method is used. 5.x Billing Suspension Initiation Notification The requirements for the EPC PGW suspend charging are specified in 3GPP TS 23.401

[14] , and the requirements for the 5GC SMF suspend charging function are specified in 3GPP TS 23.502

[29] . In order to reduce charging inconsistencies due to signaling latency between the SGW-C and PGW-C, or between the I / V-SMF and (h)SMF, for notifying the start of a charging suspension, the CP function (SGW-C and PGW-C in the EPC, I / V-SMF and (h)SMF in 5GC) and the UP function (SGW-U and PGW-U in the EPC, I / V-UPF and UPF in the PSA) may support notifying the start of a charging suspension via the user plane function (NSPOC), as described below. If both the CP function and the UP function support the NSPOC function, the CP function (SGW-C, or I / V-SMF) may set the SSPOC bit in the measurement information included in the URR to "1" when the dropped DL traffic threshold is reached to request the UP function (SGW-C, I / V-UPF) to send a start indication of charging suspension to the upstream GTP-U entity(ies) via one or more GTP-U tunnel status messages. If both the CP and UP functions support the NSPOC function, the CP function (PGW-C or (h)SMF) may, if the URR is intended for charging, set the ASPOC bit in the measurement information contained in the URR to "1" and request the UP function to stop usage measurement of the URR when it receives a Start Pause Charging indication from the peer downstream GTP-U entity, so that the UP function behaves as if the inactive measurement flag was set for the URR when it receives a Tunnel Status message with the Start Pause Charging indication set to "1" from the downstream peer GTP-U entity. NOTE 1: Existing procedures for initiating a charging suspension (using control plane signalling) are not affected. NOTE 2: The UP function forwards the tunnel status message to the upstream GTP-U entity if it is not the UPF or PGW-U of the PSA connecting to the N6 or SGi interface. If the UP function is a UL / CL or BP, it must send or forward the tunnel status message to the UPF of all PSAs. NOTE 3: If the CP function knows that there are at least some UPFs in the PGW-U or PSA that support the NSPOC functionality, the CP function can request the UP function to use this functionality (i.e., send a GTP-U tunnel status message to the upstream GTP-U entity when the dropped DL traffic threshold is reached). 7.5.2.4 Generation of URRIE in a PFCP Session Establishment Request The Create URR Grouping IE is encoded as shown in Figure 7.5.2.4-1 of 3GPP TS 29.244 V16.6.0. TIFF0007652913000008.tif187170TIFF0007652913000009.tif229170TIFF0007652913000010.tif178170TIFF0007652913000011.tif136170TIFF0007652913000012.tif50170TIFF0007652913000013.tif1701707.5.4.4 Updating the URRIE in a PFCP Session Modify Request The Update URR Grouping IE is encoded as shown in Figure 7.5.4.4-1 of 3GPP TS 29.244 V16.6.0. TIFF0007652913000014.tif161170TIFF0007652913000015.tif204170TIFF0007652913000016.tif187170TIFF0007652913000017.tif1361708.2.25 Features of the UP function The UP Capability Feature IE indicates the features that the UP capability supports and is coded as shown in the following table. The TIFF0007652913000018.tif43170UP Capability Features IE takes the form of a bitmask, where each bit indicates that the corresponding feature is supported. Reserved bits are ignored by the receiver. The same bitmask is defined for all PFCP interfaces. The following table shows the functions defined in the PFCP interface and the interfaces to which they apply. TIFF0007652913000019.tif238170TIFF0007652913000020.tif1661708.2.68 Measurement information The Measurement Information IE shall be encoded as shown in the table below. It provides information about the requested measurement information. Octet 5 of TIFF0007652913000021.tif31170 is encoded as: Bit 1 - MBQE (Measurement before QoS enforcement): When set to "1", indicates a request to measure traffic usage before QoS enforcement. - Bit 2 - INAM (Inactive Measurement): When set to "1", it indicates that the measurement is paused (inactive). -Bit 3-RADI (Reduced Application Discovery Information): When set to "1", indicates that the application discovery information reported to the CP function when detecting an application start or stop contains only the application ID. - Bit 4 - ISTM (Immediate Start of Timing): if set to "1", indicates that the timing starts immediately when the flag is received. - bit 5 - MNOP (Measurement of Number of Packets): if set to "1", indicates a request to measure the number of packets transferred on the UL / DL / Total in addition to the octet-based measurement if volume-based measurements are applied. -Bit 6 - SSPOC (Send Start of Charging Suspend): when set to "1", indicates that the UP function sends a Start of Charging Suspend indication to the upstream GTP-U entity when the dropped DL traffic threshold is reached. - Bit 7 - ASPOC (Applicable to Initiate Charging Suspension): if set to "1", indicates that the URR of the UP function is applicable to initiate a charging suspension and will stop the usage metering of the URR upon receiving an Initiate Charging Suspension indication from the peer downstream GTP-U entity. - Bits 6-8: Reserved, set to “0” for future use. At least one bit must be set to "1." For example, both the MBQE and MNOP bits are set to "1."

[0269] In one embodiment, the following content may be added to 3GPP TS29.281 V16.1.0: 7.7.0 General GTP signaling messages contain multiple information elements. GTP information elements use the TLV (type, length, value) or TV (type, value) encoding format. In signaling messages, information elements are sorted in ascending order of the type field. The length field stores the length of the information element excluding the type and length fields. For all length fields, bit 8 of the least significant octet is the most significant bit, and bit 1 of the most significant octet is the least significant bit. Within an information element, certain fields may be described as reserved. These bits shall be transmitted with the defined values. To allow for future functionality, receivers shall not evaluate these bits. The most significant bit of the type field is set to 0 when using the TV format and to 1 when using the TLV format. TIFF0007652913000022.tif60170In Table 37, length types can be fixed, variable, or extensible. These are defined as follows: - Information elements of type fixed length have a fixed set of fields and a fixed number of octets, the last octet having a fixed number, e.g. "4". - Information elements of type variable length have a fixed set of fields and a variable number of octets. They have the number of the last octet with a variable value, for example "n". No new octet fields may be added to a variable length information element beyond the last variable octet. - Information elements with length type extensible have a variable number of fields and a variable number of octets. They have a variable value for the number of the last octet, e.g. "n", and a description such as: "These octets are present only if explicitly specified." TV format information elements must always have a fixed length type. TLV format information elements may have a fixed, variable or extensible length type. TIFF0007652913000023.tif204170TIFF0007652913000024.tif238170TIFF0007652913000025.tif233170TIFF0007652913000026.tif78170

[0270] In an embodiment, the following content may be added to 3GPP TS29.502 V16.6.0. TIFF0007652913000027.tif229170

[0271] The embodiments herein provide many advantages, a non-exhaustive list of examples of which follows. Some embodiments herein can solve the overcharging problem of charging suspension in at least one of the following scenarios: CUPS in 4G with SGW-C and PGW-C, 5G roaming with V-SMF and H-SMF, 5G with I-SMF and I-UPF inserted, and 5G with I-UPF inserted and I-SMF not inserted. Some embodiments herein can improve network quality. Some embodiments herein can improve operator satisfaction. Some embodiments herein can improve user satisfaction. The embodiments herein are not limited to the features and advantages described above. Those skilled in the art will recognize additional features and advantages upon reading the following detailed description.

[0272] 19 is a block diagram illustrating an apparatus suitable for use in implementing some embodiments of the present disclosure. For example, any one of the first control plane function, the first user plane function, and the second user plane function described above may be implemented through the apparatus 1900.

[0273] The apparatus 1900 comprises at least one processor 1921, such as a DP, and at least one MEM 1922 coupled to the processor 1921. The apparatus 1900 may further comprise a transmitter TX and a receiver RX 1923 coupled to the processor 1921. The MEM 1922 stores PROG 1924. The PROG 1924 may include instructions that, when executed on an associated processor 1921, enable the apparatus 1920 to operate according to an embodiment of the present disclosure. The combination of the at least one processor 1921 and the at least one MEM 1922 may form a processing means 1925 adapted to perform various embodiments of the present disclosure.

[0274] Various embodiments of the present disclosure may be implemented by a computer program executable by one or more of the processor 1921, software, firmware, hardware, or combinations thereof.

[0275] MEM1922 may be of any type suitable for the local technology environment and may be implemented using any suitable data storage technology, such as, by way of non-limiting examples, semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed and removable memory.

[0276] The processor 1921 may be of any type suitable for the local technology environment and may include, by way of non-limiting examples, one or more of a general purpose computer, a special purpose computer, a microprocessor, a digital signal processor DSP, and a processor based on a multi-core processor architecture.

[0277] In embodiments in which the device is implemented as or in a first control plane function, memory 1922 includes instructions executable by processor 1921 to cause the first control plane function to operate according to any one of the methods associated with the first control plane function described above.

[0278] In an embodiment in which the device is implemented as or in a first user plane function, the memory 1922 includes instructions executable by the processor 1921 to cause the first user plane function to operate according to any one of the methods associated with the first user plane function described above.

[0279] In embodiments in which the device is implemented as or in a second user plane function, the memory 1922 includes instructions executable by the processor 1921 to cause the second user plane function to operate according to any one of the methods associated with the second user plane function described above.

[0280] 20 illustrates a simplified block diagram of a first user plane function according to an embodiment of the present disclosure. The first user plane function 2000 includes a determining module 2002 and a first transmitting module 2004. The determining module 2002 is configured to determine a charging operation for the first session. The first transmitting module 2004 is configured to transmit information regarding the charging operation for the first session to a second user plane function.

[0281] In one embodiment, the first user plane function 2000 further comprises a first receiving module 2006 configured to receive an acknowledgement response from the second user plane function for the information regarding the charging operation of the first session.

[0282] In one embodiment, the first user plane function 2000 further comprises a second receiving module 2008 configured to receive an instruction from the control plane function to send information regarding the charging action for the second session to another user plane function after determining the charging action for the second session.

[0283] In one embodiment, the first user plane function 2000 further comprises a second transmitting module 2010 configured to transmit capabilities supported by the first user plane function to the control plane function, the capabilities supported by the first user plane function indicating that the first user plane function supports transmitting and / or receiving information regarding charging behavior of sessions to and / or from other user plane functions.

[0284] 21 illustrates a simplified block diagram of a second user plane function according to an embodiment of the present disclosure. The second user plane function 2100 includes a first receiving module 2102 and an executing module 2104. The first receiving module 2102 is configured to receive information related to a charging operation for the first session from the first user plane function. The executing module 2104 is configured to execute a charging operation for the first session based on the information related to the charging operation for the first session.

[0285] In one embodiment, the second user plane function 2100 further comprises a first transmission module 2106 configured to transmit an acknowledgment of the information regarding the charging operation for the first session to the first user plane function.

[0286] In one embodiment, the second user plane function 2100 further comprises a second receiving module 2108 configured to receive an indication from the control plane function of whether the usage reporting rule is applicable to the charging action received from the other user plane function.

[0287] In one embodiment, the second user plane function 2100 further comprises a second transmitting module 2110 configured to transmit capabilities supported by the second user plane function to the control plane function, the capabilities supported by the second user plane function indicating that the second user plane function supports transmitting and / or receiving information regarding charging behavior of sessions to and / or from other user plane functions.

[0288] 22 illustrates a simplified block diagram of a first control plane function according to an embodiment of the present disclosure. The first control plane function 2200 comprises a first receiving module 2202. The first receiving module 2202 is configured to receive user plane function supported functionality from a user plane function. The user plane function supported functionality indicates that the user plane function supports sending and / or receiving information regarding charging behavior of a session to and / or from other user plane functions.

[0289] In one embodiment, the first control plane function 2200 further comprises a first transmitting module 2204 configured to, after determining a charging action for the session, transmit an instruction to a user plane function to transmit information regarding the charging action for the session to another user plane function.

[0290] In one embodiment, the first control plane function 2200 further comprises a second sending module 2206 configured to send the capabilities supported by the first control plane function to the second control plane function, where the capabilities supported by the first control plane function indicate that the first control plane function supports configuring the user plane function to send and / or receive information regarding charging operations for the session to and / or from other user plane functions.

[0291] In one embodiment, the first control plane function 2200 further comprises a second receiving module 2208 configured to receive from the second control plane function the capabilities supported by the second control plane function, where the capabilities supported by the second control plane function indicate that the second control plane function supports configuring the user plane function to send and / or receive information regarding charging operations for the session to and / or from other user plane functions.

[0292] According to one aspect of the present disclosure, a computer program product is provided that includes instructions tangibly stored on a computer-readable storage medium and that, when executed on at least one processor, cause the at least one processor to perform any of the methods associated with the first control plane function, the first user plane function, and the second user plane function described above.

[0293] According to one aspect of the present disclosure, a computer-readable storage medium is provided that stores instructions that, when executed by at least one processor, cause the at least one processor to perform any of the methods associated with the first control plane function, the first user plane function, and the second user plane function described above.

[0294] Furthermore, the present disclosure may provide a carrier comprising such a computer program, the carrier being one of an electronic signal, an optical signal, a radio signal, or a computer-readable storage medium. The computer-readable storage medium may be, for example, an optical compact disc, or an electronic storage device such as a RAM (random access memory), a ROM (read only memory), a flash memory, a magnetic tape, a CD-ROM, a DVD, a Blu-ray disc, or the like.

[0295] The techniques described herein may be implemented by various means, such that an apparatus performing one or more functions of the corresponding apparatus described in the embodiments may be composed of means for performing one or more functions of the corresponding apparatus described in the embodiments as well as means of the prior art, and may be composed of separate means for each function, or means configured to perform two or more functions. For example, these techniques may be implemented in hardware (one or more devices), firmware (one or more devices), software (one or more modules), or a combination thereof. In the case of firmware or software, the implementation may be through modules (e.g., procedures, functions, etc.) that perform the functions described herein.

[0296] Exemplary embodiments herein have been described above with reference to block diagrams and flow charts of methods and apparatus. It will be understood that each block of the block diagrams and flow charts, and combinations of blocks in the block diagrams and flow charts, respectively, can be implemented by various means including computer program instructions. These computer program instructions can be loaded into a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine such that the instructions, which execute on the computer or other programmable data processing apparatus, create means for implementing the function specified in the block or block of the flow chart.

[0297] Furthermore, although operations are depicted in a particular order, this should not be understood as requiring such operations to be performed in the particular order shown, or sequentially, or to perform all of the operations depicted, to achieve desired results. In certain circumstances, multitasking and parallel processing may be advantageous. Similarly, although some specific implementation details are included in the above discussion, these should not be construed as limitations on the scope of the subject matter described herein, but rather as descriptions of features that may be specific to particular embodiments. Certain features that are described in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment may also be implemented in multiple embodiments separately or in any suitable subcombination.

[0298] Although many specific implementation details are described herein, these should not be construed as limitations on the scope of any implementation or what may be claimed, but rather as descriptions of features that may be specific to a particular embodiment of a particular implementation. Certain features described herein in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented in multiple embodiments separately or in any suitable subcombination. Furthermore, although features may be described above as acting in a particular combination, and may even be initially claimed as such, one or more features from a claimed combination may in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or a variation of the subcombination.

[0299] It will be obvious to those skilled in the art that with the advancement of technology, the concept of the present invention can be implemented in various ways. The above-mentioned embodiments are given to illustrate the present disclosure, not to limit it, and it should be understood that those skilled in the art can resort to modifications and variations without departing from the spirit and scope of the present disclosure, as can be easily understood by those skilled in the art. Such modifications and variations are considered to be within the scope of the present disclosure and the appended claims. The scope of protection of the present disclosure is defined by the appended claims.

Claims

1. 1. A method performed by a first user plane function, comprising: determining a charging action for the first session; sending information regarding a charging operation for the first session to a second user plane function; transmitting capabilities supported by the first user plane function to a control plane function, the capabilities supported by the first user plane function indicating that the first user plane function supports sending and / or receiving information regarding charging operations for sessions to and / or from other user plane functions; The method includes:

2. and receiving, from the second user plane function, an acknowledgement for the information regarding a charging action for the first session. The method of claim 1.

3. The information regarding charging operations for the first session is included in a General Packet Radio Service Tunneling Protocol for User Plane (GTP-U) tunnel status message, and an acknowledgement for the information regarding charging operations for the first session is included in another GTP-U tunnel status message. The method according to claim 1 or 2.

4. The charging operation is Operator policies, Operator configuration, is determined based on at least one of 4. The method according to any one of claims 1 to 3.

5. Sending information regarding a charging operation for the first session to a second user plane function includes: and immediately transmitting the information regarding the charging action for the first session to the second user plane function after determining a charging action for the first session.

5. The method according to any one of claims 1 to 4.

6. The charging action includes immediately initiating a suspension of charging.

6. The method according to any one of claims 1 to 5.

7. and receiving, after determining a charging action for the second session, an indication from a control plane function to transmit information regarding the charging action for the second session to another user plane function.

7. The method according to any one of claims 1 to 6.

8. The indication may include: Packet Forwarding Control Protocol (PFCP) session establishment request, PFCP Session Modify Request, Included in at least one of The method according to claim 7.

9. The supported capabilities of the first user plane function are included in a Packet Forwarding Control Protocol (PFCP) association setup response or request.

9. The method according to any one of claims 1 to 8.

10. The control plane function Packet Data Network Control Plane (PGW-C); Serving Gateway Control Plane (SGW-C); Session Management Function (SMF), Contains at least one of 10. The method according to any one of claims 7 to 9.

11. The first user plane function, Serving Gateway User Plane (SGW-U), Visited User Plane Function (V-UPF), Intermediate User Plane Function (I-UPF); Contains at least one of 11. The method according to any one of claims 1 to 10.

12. The second user plane function Packet Data Network User Plane (PGW-U); Intermediate User Plane Function (I-UPF); Home User Plane Function (H-UPF), Anchor User Plane Function (A-UPF), Contains at least one of 12. The method according to any one of claims 1 to 11.

13. A method performed by a second user plane function, comprising: receiving information from a first user plane function regarding a charging operation for the first session; performing a charging operation for the first session based on the information regarding a charging operation for the first session; transmitting capabilities supported by the second user plane function to a control plane function, the capabilities supported by the second user plane function indicating that the second user plane function supports sending and / or receiving information regarding charging operations for sessions to and / or from other user plane functions; The method includes:

14. and transmitting an acknowledgement to the first user plane function for the information regarding charging operations for the first session. The method of claim 13.

15. The information regarding charging operations for the first session is included in a General Packet Radio Service Tunneling Protocol for User Plane (GTP-U) tunnel status message, and an acknowledgement for the information regarding charging operations for the first session is included in another GTP-U tunnel status message.

15. The method according to claim 13 or 14.

16. The charging operation is Operator policies, Operator configuration, is determined based on at least one of 16. A method according to any one of claims 13 to 15.

17. Performing a charging operation for the first session based on the information regarding a charging operation for the first session includes: and immediately performing a charging operation for the first session based on the information regarding a charging operation for the first session after receiving the information regarding a charging operation for the first session from a first user plane function.

17. A method according to any one of claims 13 to 16.

18. The charging action includes immediately initiating a suspension of charging.

18. A method according to any one of claims 13 to 17.

19. and receiving an indication from the control plane function whether the usage reporting rules are applicable to the charging actions received from the other user plane functions.

19. A method according to any one of claims 13 to 18.

20. The indication may include: Packet Forwarding Control Protocol (PFCP) session establishment request, PFCP Session Modify Request, Included in at least one of 20. The method of claim 19.

21. The supported capabilities of the second user plane function are included in a Packet Forwarding Control Protocol (PFCP) association setup response or request.

21. A method according to any one of claims 13 to 20.

22. The control plane function Packet Data Network Control Plane (PGW-C); Serving Gateway Control Plane (SGW-C); Session Management Function (SMF), Contains at least one of 22. A method according to any one of claims 19 to 21.

23. The first user plane function, Serving Gateway User Plane (SGW-U), Visited User Plane Function (V-UPF), Intermediate User Plane Function (I-UPF); Contains at least one of 23. A method according to any one of claims 13 to 22.

24. The second user plane function, Packet Data Network User Plane (PGW-U); Intermediate User Plane Function (I-UPF); Home User Plane Function (H-UPF), Anchor User Plane Function (A-UPF), Contains at least one of 24. A method according to any one of claims 13 to 23.

25. A method performed by a first control plane function, comprising: Receiving capabilities supported by a user plane function from a user plane function, the capabilities supported by the user plane function indicating that the user plane function supports sending and / or receiving information regarding charging operations for sessions to and / or from other user plane functions. The method includes:

26. The supported capabilities of the user plane function are included in a Packet Forwarding Control Protocol (PFCP) association setup response or request.

26. The method of claim 25.

27. and after determining a charging action for the session, sending an indication to the user plane function to send information regarding the charging action for the session to another user plane function.

27. The method of claim 25 or 26.

28. The indication may include: Packet Forwarding Control Protocol (PFCP) session establishment request, PFCP Session Modify Request, Included in at least one of 28. The method of claim 27.

29. The charging operation is Operator policies, Operator configuration, is determined based on at least one of 29. A method according to any one of claims 25 to 28.

30. The charging action includes immediately initiating a suspension of charging.

30. A method according to any one of claims 25 to 29.

31. transmitting capabilities supported by the first control plane function to a second control plane function, the capabilities supported by the first control plane function indicating that the first control plane function supports configuring a user plane function to send and / or receive information regarding charging operations for sessions to and / or from other user plane functions; receiving from a second control plane function capabilities supported by a second control plane function, the capabilities supported by the second control plane function indicating that the second control plane function supports configuring a user plane function to send and / or receive information regarding charging operations for sessions to and / or from other user plane functions; Also includes 31. A method according to any one of claims 25 to 30.

32. the supported capabilities of the first control plane function are included in a create session request; The supported capabilities of the second control plane function are included in a session creation response.

32. The method of claim 31 .

33. The first control plane function Packet Data Network Control Plane (PGW-C); Serving Gateway Control Plane (SGW-C); Session Management Function (SMF), Contains at least one of 33. A method according to any one of claims 25 to 32.

34. The user plane function Packet Data Network User Plane (PGW-U); Serving Gateway User Plane (SGW-U), User Plane Function (UPF), Contains at least one of 34. A method according to any one of claims 25 to 33.

35. A first user plane function, A processor; a memory coupled to the processor, the memory comprising instructions executable by the processor whereby the first user plane function comprises: Determining a charging action for the first session; Sending information regarding a charging operation for the first session to a second user plane function; sending capabilities supported by the first user plane function to a control plane function, the capabilities supported by the first user plane function indicating that the first user plane function supports sending and / or receiving information regarding charging operations for sessions to and / or from other user plane functions; the memory being operable to A first user plane function comprising:

36. The first user plane function is further operable to perform a method according to any one of claims 2 to 12. A first user plane function according to claim 35.

37. A second user plane function, A processor; a memory coupled to the processor, the memory comprising instructions executable by the processor, whereby the second user plane function comprises: receiving information from a first user plane function regarding a charging operation for the first session; performing a charging operation for the first session based on the information regarding a charging operation for the session; sending capabilities supported by the second user plane function to a control plane function, the capabilities supported by the second user plane function indicating that the second user plane function supports sending and / or receiving information regarding charging operations for sessions to and / or from other user plane functions; the memory being operable to A second user plane function comprising:

38. The second user plane function is further operable to perform a method according to any one of claims 14 to 24. A second user plane function according to claim 37.

39. A first control plane function, A processor; a memory coupled to the processor, the memory comprising instructions executable by the processor, whereby the first control plane function receiving from a user plane function capabilities supported by a user plane function, the capabilities supported by the user plane function indicating that the user plane function supports sending and / or receiving information regarding charging operations for sessions to and / or from other user plane functions; the memory being operable to A first control plane function comprising:

40. The first control plane function is further operable to perform a method according to any one of claims 26 to 34.

40. A first control plane function according to claim 39.

41. A computer readable storage medium storing instructions which, when executed by at least one processor, cause the at least one processor to perform the method of any one of claims 1 to 12.

42. A computer-readable storage medium storing instructions that, when executed by at least one processor, cause the at least one processor to perform a method according to any one of claims 13 to 24.

43. A computer-readable storage medium storing instructions that, when executed by at least one processor, cause the at least one processor to perform a method according to any one of claims 25 to 34.

Images