Patent Application
20240406015
This disclosure relates to a charging system.
The Third Generation Partnership Project (3GPP) has specified a service-based architecture in 3GPP TS 32.290 v16.8.0 (“TS 32.290”). According to this architecture a network function (NF) (e.g., a Charging Trigger Function (CTF)) may request charging from a Converged Charging system (CCS). More specifically, the NF requests charging from a Charging Function (CHF) of the CCS, which, among other things, is responsible for generating charging data records. In addition to including the CHF, the CCS also includes: an Account Balance Management Function (ABMF), which holds subscriber account balances and any reservations, and a Rating Function (RF), which determines a value of a network resource usage.
When a charging request transmitted by an NF is received at the CHF, the CHF processes the request (e.g., creates a resource for charging) and transmits a response. The response may include a location header that includes a resource identifier (e.g., a Uniform Resource Identifier (URI)) identifying the resource created by the CHF in response to the request and an optional binding indication. A resource may be an entry in a storage at the CHF such as data received in conjunction with charging requests from a Network Function acting as charging client. This data includes charging data received for the charging session but may also relate to earlier sessions. The binding indication indicates the connection to which the resource is bound, i.e., whether the resource is available and can be obtained from a single NF service instance, NF instance, or an NF set. The resource identifier may have the following form:
{apiRoot}/<apiName>/<api Version>/<apiSpecificResourceUriPart>, as described in 3GPP TS 29.501 v16.6.0 (“TS 29.501”) clause 4.4. The {apiRoot} portion of the resource identifier includes a protocol identifier (e.g., http or http) and a host identifier (e.g., a registered name (e.g., name.com) or a network address (e.g., an IP address)). The <apiSpecificResourceUriPart> portion is a resource identifier relative to {apiRoot}/<apiName>/<apiVersion>/(i.e., the “API URI”). Accordingly, when the NF wants a CHF to update the resource, the NF can identify the resource to the CHF. Such resource may be the rating group, IMSI, or total number used units for the session. A resource may also refer to a directory, such as www (dot) ericsson (dot) com/Nchf_converged_charging/3.0.0/, containing all resources for a particular session. One type resource stored at the CHF may also be a reference to a resource stored at another CCS function, e.g. another CHF, ABMF or RF in the same or different CCS.
Certain challenges presently exist. For example, when an NF wants a CHF to update a previously created charging resource, such as adding rating group or a location for the session or updating the number of used units for session, the NF transmits an update request that includes an identifier of the resource. The CHF that receives the update request may need to obtain one or more resource identifiers identifying a resource created by another CCS function (e.g., the ABMF and/or RF) but may not be able to locate these other resource identifiers. For example, the CHF may have lost the reference for the resource or lost the actual resource.
Accordingly, in one aspect there is provided a method performed by a first CHF to overcome this problem. In one embodiment, the method includes the first CHF receiving a first request message transmitted by a first network function, wherein the first request message relates to a chargeable service requested by a subscriber. The method also includes, after receiving the first request message, the first CHF transmitting a second request message to a second network function (e.g., RF, ABMF, or second CHF) and receiving from the second network function a first response message responsive to the second request message, wherein the first response message includes a first resource identifier identifying a first resource created by the second network function or a third network function. The method also includes, after receiving the first response message transmitted by the second network function, the first CHF transmitting to the first network function a second response message responsive to the first request message. The second response message includes the first resource identifier received from the second network function. The method also includes the first CHF receiving a charging data request message transmitted by a network function, wherein the charging data request message is not an initial charging data request message, and the charging data request message comprises a first resource identifier comprising a first host portion identifying a host and a first specific resource identifier portion. The method also includes the first CHF transmitting a request message to the host identified by the host portion of the first resource identifier, wherein the request message comprises the first specific resource identifier portion.
In another embodiment the method includes the first CHF receiving a first request message transmitted by a first network function, wherein the first request message relates to a chargeable service requested by a subscriber. The method also includes, after receiving the first request message, the first CHF transmitting a second request message to a second network function (e.g., RF, ABMF, or second CHF) and receiving from the second network function a first response message responsive to the second request message, wherein the first response message includes a first resource identifier identifying a first resource created by the second network function or a third network function. The method also includes, after receiving the first response message transmitted by the second network function, the first CHF transmitting to the first network function a second response message responsive to the first request message. The second response message includes the first resource identifier received from the second network function.
In another embodiment, the method includes the first CHF receiving a charging data request message transmitted by a network function, wherein the charging data request message is not an initial charging data request message, and the charging data request message comprises a first resource identifier comprising a first host portion identifying a host and a first specific resource identifier portion. The method also includes the first CHF transmitting a request message to the host identified by the host portion of the first resource identifier, wherein the request message comprises the first specific resource identifier portion.
In another aspect there is provided a computer program comprising instructions which when executed by processing circuitry of a CHF causes the CHF to perform any of the methods disclosed herein. In one embodiment, there is provided a carrier containing the computer program wherein the carrier is one of an electronic signal, an optical signal, a radio signal, and a computer readable storage medium.
In another aspect there is provided a CHF that is configured to perform the methods disclosed herein. In some embodiments, the CHF comprises memory and processing circuitry coupled to the memory, wherein the memory contains instructions executable by the processing circuitry to configure the CHF to perform the methods disclosed herein.
An advantage of the embodiments disclosed herein is that they enable a CHF to be completely stateless (i.e., the CHF does not need to store the resources identifiers that it receives from other CCS function). Thus, if the CHF fails, then any other CHF can take over. The embodiments also allow the ABMF/RF to not be collocated with each other or with the CHF and also makes the CHF to CHF interaction more fault tolerant.
The accompanying drawings, which are incorporated herein and form part of the specification, illustrate various embodiments.
Network node 101 can implement or comprises any network function in the 3GPP 5G core context, even another CHF. In one embodiment, network node 101 comprises a Session Management Function (SMF), which may include a Charging Trigger Function (CTF) 103, that consumes the services provided by the CHF (e.g., the Nchf services).
The network node 101 requests creation of a charging resource at the CHF 102, and the CHF 102 may then, depending on internal configuration, request resources to be created at ABMF 104 and RF 106. In the example of
Step 201: Network node 101 receives a request for a service that is provided by the NF (e.g. video streaming, internet connection). For example, network node 101 may be an SMF that receives a session establishment request.
Step 202: After receiving the request, network node 101 determines that the requested service is chargeable and may require quota monitoring, and, therefore, network node 101 sends an initial charging data (CD) request message to CHF 102 requesting recording and possibly quota for the service.
Step 203: In response to receiving the charging data request [initial] transmitted by network node 101, CHF 102 decides, based on charging information included in the charging data request and internal configuration, whether or not it needs to get account information (e.g., account information for an enterprise (e.g. the MVNO, HPLMN operator, company)). As a result of determining that it needs to get account information, CHF 102 transmits to ABMF 104 an account data request (ADR). For example, CHF 102 transmits to ABMF 104 a Hypertext Transfer Protocol (HTTP) message (e.g., an HTTP GET message or an HTTP POST message) requesting account data for a specified account.
Step 204: ABMF 104 checks the account and responds with an account data response that includes the request account information (e.g., the account information identifies services the enterprise has and which buckets/balances that can be used as well as their values).
Step 205: After receiving the account data response, CHF 102 decides, based on the charging information, the account information, and internal configuration whether it needs to rate the service before it can reserve anything from the account. In response to determining that it needs to rate the service, CHF 102 transmits to RF 106 a rate request (RR) message for a reservation comprising the charging information and the account information.
Step 206: In response to receiving the rate request message, RF 106 rates the event based on charging information, the account data, and internal configuration, and responds by sending to CHF 102 a rate response message that includes information indicating an amount to reserve. Additionally, if required to be able to continue the rating where it left of at the next request, RF 106 includes in the rate response a resource identifier. For example, the resource identifier may be of the form:
http://rf_106.com/rating/v1/ratinginfo/QweRTY09876,
where “QweRTY09876” is a unique reference that is generated for the specific rate request so that it can be differentiated from other requests.
Step 207: In response to receiving the rate response from RF 106, CHF 102 decides, based on the information included in the rate response, that it needs to reserve from the account. Accordingly, CHF 102 transmits to ABMF 104 a reserve request (e.g., Account Data Request [Reserve]).
Step 208: ABMF 104, in response to receiving the reserve request, checks the account and then transmits to CHF 102 an account data response comprising information indicating the reserved amount. The account data response may also include a resource identifier for the reservation. For example, the resource identifier may be of the form:
http://abmf_104.com/accountbalancemanagement/v1/accountinfo/876asdF,
where “876asdF” is a unique reference that is generated for the specific rate request so that it can be differentiated from other requests.
Step 209: CHF 102 decides based on the charging information and internal configuration that it needs to create a record with the charging information and reservations made. That is, CHF 102 records the information by creating a Charging Data Record (CDR) that contains the information.
Step 210: In this example, CHF 102 determines, based the charging information, account data, and internal configuration, whether the service is chargeable by CHF 122. If it is, then CHF 102 sends to CHF 122 an initial charging data request requesting recording and possibly quota for the service.
Step 211: In response to receiving the Charging Data Request [initial] transmitted by CHF 102, CHF 122 decides, based on charging information included in the charging data request and internal configuration, whether or not it needs to get account information for the end user (e.g. the UE, subscriber, employee). As a result of determining that it needs to get account the information for the end user, CHF 122 transmits to ABMF 124 an account data request. For example, CHF 102 transmits to ABMF 124 an HTTP GET request message requesting account data for a specified account.
Step 212: ABMF 104 checks the account and responds with an account data response that includes the request account information (e.g., information identifying services the end user has access to and which buckets/balances that can be used as well as their values).
Step 213: After receiving the account data response, CHF 122 decides, based on the charging information, the account information, and internal configuration whether it needs to rate the service before it can reserve anything from the account. In response to determining that it needs to rate the service, CHF 122 transmits to RF 126 a rate request message for a reservation comprising the charging information and the account information.
Step 214: In response to receiving the rate request message, RF 126 rates the event based on charging information, the account data, and internal configuration, and responds by sending to CHF 122 a rate response message that includes information indicating an amount to reserve. Additionally, if required to be able to continue the rating where it left of at the next request, RF 126 includes in the rate response a resource identifier. For example, the resource identifier may be of the form:
http://rf_126.com/rating/v1/ratinginfo/hyde4747dhckp1, where
“hyde4747dhckp1” is a unique reference generated by RF 126 and associated with the rate request.
Step 215: In response to receiving the rate response from RF 126, CHF 122 decides, based on the information included in the rate response, that it needs to reserve from the account. Accordingly, CHF 122 transmits to ABMF 124 a reserve request (e.g., Account Data Request [Reserve]).
Step 216: ABMF 124, in response to receiving the reserve request, checks the account and then transmits to CHF 122 an account data response comprising information indicating the reserved amount. The account data response may also include a resource identifier for the reservation. For example, the resource identifier may be of the form:
http://abmf_124.com/accountbalancemanagement/v1/accountinfo/b74lap69, where “b74lap69” is a unique reference generated by ABMF 124 and associated with the reserve request.
Step 217: CHF 122 decides based on the charging information and internal configuration that it needs to create a record with the charging information and reservations made. That is, CHF 122 records the information by creating a Charging Data Record (CDR) that contains the information.
Step 218: CHF 122 now responds to the request message transmitted by CHF 102 by transmitting to CHF 102 a charging data response message. In one embodiment, the charging data response message includes a resource identifier created by CHF 122. This resource identifier may be of the form:
http://chf_122.com/nchf-covergedcharging/v3/chargingdata/Asdf1234q, where
“Asdf1234q” is a unique reference generated by CHF 122 and associated with the charging data request from CHF 102. This resource can be used by another CHF if CHF 122 fails.
Additionally, in some embodiments, the charging data response message transmitted by CHF 122 to CHF 102 may further include the resource identifier received from ABMF 124 and the resource identifier received from RF 126. In such an embodiment, the charging data response message transmitted by CHF 122 to CHF 102 may include the following linkedResources data structure (a.k.a., information element (IE)):
As illustrated above, the linkedResources IE includes three records, where each record includes a field storing a resource identifier (e.g., a Uniform Resource Identifier (URI)) and an associated field storing a network function identifier (e.g., “CHF” or “RF”) that identifies the function associated with the resource identifier (e.g., the function from which CHF 122 obtained the resource identifier).
Step 219: After receiving the charging data response message transmitted by CHF 122, CHF 102 decides, based on the response and internal configuration, whether it needs to update the CDR created in Step 209 with information from the charging data response message. If so, CHF 102 included the information in the CDR.
Step 220: CHF 102 now responds to the request message transmitted by network node 101 by transmitting to network node 101 a charging data response message with linked resources created to provide the charging service. For example, in one embodiment, the charging data response message transmitted by CHF 102 includes a resource identifier created by CHF 102. This resource identifier may be of the form:
http://chf_102.com/nchf-covergedcharging/v3/chargingdata/ujhge437, where
“ujhge437” is a unique reference generated by CHF 102 and associated with the request from network node 101.
Additionally, in some embodiments, the charging data response message transmitted by CHF 102 to NF 102 may further include the resource identifier received from ABMF 104, the resource identifier received from RF 106, and all of the resource identifiers received from CHF 122. In such an embodiment, the charging data response message transmitted by CHF 102 to CHF 104 may include the following two IEs (serviceDeploymentClusters and linkedResources):
The steps 203 to 208 and 211 to 217 may be done in different order or multiple times depending on CHF implementation and what is needed from a request point of view.
To avoid a lot of signaling the ABMF and RF may be combined and in that case the CHF would just do a request like “rate and reserve” to the AMBF+RF.
Step 301: Network node 101 transmits an update charging data request message containing the resource identifiers contained in the charging data response message transmitted by CHF 102 in step 220. For example, the update message may include the two IEs shown in Table 2. This update charging data request message is received at a CHF (e.g., CHF 102 or another CHF) in SDC 110.
Step 302: After receiving the update message, the CHF transmits a request message to another network function 310 (e.g., ABMF 104, RF 106, or CHF 122). If the request message is sent to ABMF 104, then the request message includes the ABMF resource identifier included in the linkedResources IE of the update request message (e.g., http://abmf_104.com/accountbalancemanagement/v1/accountinfo/876asdF). If the request message is sent to RF 104, then the request message includes the RF resource identifier included in the linkedResources IE of update request message (e.g., http://rf_106.com/rating/v1/ratinginfo/QweRTY09876). Similarly, if the request message is sent to CHF 122, then the request message includes the serviceDeploymentClusters, which, as shown in Table 2, includes three resource identifiers.
Step 303: The network function 310 transmits a response to the CHF. The response may include a resource identifier generated by network function 310.
Step 304: The CHF transmits a charging data response responsive to the update charging data request message. The charging data response may include all or some of the resource identifiers included in the update charging data request message. Additionally, if the response received in step 303 includes a resource identifier, then this resource identifier is included in the charging data response message.
In one embodiment, the body of the charging data request message transmitted in step 301 may include one or more of the information elements (e.g., attribute-value pairs) described in the table below:
In one embodiment, the body of the charging data response message may include one or more of the information elements (e.g., attribute-value pairs) described in the table below:
In some embodiments, the first request message is an initial charging data request message (i.e., a message that initiates a charging session), and the second response message is a charging data response message responsive to the initial charging data request message.
In some embodiments, the second network function is an RF, the second request message is a rate request message, the first response message is a rate response message responsive to the rate request message, the rate response message further includes, in addition to the first resource identifier, information indicating an amount to reserve, and the first resource identified by the first resource identifier was created by the RF.
In some embodiments, the second network function is an ABMF, the second request message is a reservation request message, the first response message is a reservation response message responsive to the reservation request message, the reservation response message further includes, in addition to the first resource identifier, information indicating a reserved amount, and the first resource identified by the first resource identifier was created by the ABMF.
In some embodiments, the method also includes, after receiving the first request message and prior to transmitting the second request message, the first CHF determining, based on information included in the first request message, that the first CHF needs to obtain account information from an ABMF: as a result of determining the need to obtain the account information, the first CHF transmitting to the ABMF an account data request message requesting the account information; and the first CHF receiving from the ABMF an account data response message comprising the account information.
In some embodiments, the method also includes, before transmitting the second response message to the first network function, the first CHF determining that the chargeable service is chargeable by a second CHF, wherein the second CHF is the second network function; and as a result of determining that the chargeable service is chargeable by the second CHF, the first CHF transmitting to the second CHF the second request message, wherein the second request message is a second charging data request message. In some embodiments, the first CHF is a component of a first service deployment cluster the second CHF is a component of a second service deployment cluster the first response message further includes a second resource identifier identifying a resource created by an RF or an ABM of the second service deployment cluster, and the charging data response message responsive to the initial charging data request message further includes the second resource identifier.
In some embodiments, the method also includes, after transmitting the second response message to the first network function, receiving a second request message transmitted by the second network function, wherein the second request message comprises the first resource identifier.
In some embodiments, the first resource identifier is an absolute resource identifier that comprises a host portion identifying a host and a specific resource identifier, while in other embodiments the first resource identifier is a relative resource identifier that comprises the specific resource identifier.
In some embodiments, the charging data request message comprises a set of resource identifiers including the first resource identifier and a second resource identifier, and the request message transmitted to the host further comprises the second resource identifier. In some embodiments, the host is or comprises a second CHF.
While various embodiments are described herein, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of this disclosure should not be limited by any of the above-described exemplary embodiments. Moreover, any combination of the above-described elements in all possible variations thereof is encompassed by the disclosure unless otherwise indicated herein or otherwise clearly contradicted by context.
Additionally, while the processes described above and illustrated in the drawings are shown as a sequence of steps, this was done solely for the sake of illustration. Accordingly, it is contemplated that some steps may be added, some steps may be omitted, the order of the steps may be re-arranged, and some steps may be performed in parallel.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/SE2021/050989 | 10/8/2021 | WO |
