WO2021226530A1

WO2021226530A1 - Systems and methods for providing an interface to an external charging system in a digital telecommunications network

Info

Publication number: WO2021226530A1
Application number: PCT/US2021/031400
Authority: WO
Inventors: Ronald Mark Parker; Santos Kumar Das; Srinivas Kappla; Kantha Rao DAMMALAPATI; Ramakrishna PRASAD
Original assignee: Microsoft Technology Licensing, Llc
Priority date: 2020-05-08
Filing date: 2021-05-07
Publication date: 2021-11-11

Abstract

A first charging profile identifies a first charging interface among a plurality of charging interfaces. Each of the plurality of charging interfaces, when provisioned, provides a communication link between an application at a node of a telecommunications network with charging capabilities and an external charging system. The first charging interface can be provisioned. A first messaging format can be associated with the first charging interface. A first message associated with the first charging profile can be received. The first message can be received via a second charging interface, and the first message can conform to a second messaging format that is associated with the second charging interface. The first message can be adapted to conform to a first messaging format associated with the first charging interface, thereby creating a first adapted message. The first adapted message can be forwarded to the external charging system via the first charging interface.

Description

SYSTEMS AND METHODS FOR PROVIDING AN INTERFACE TO AN EXTERNAL CHARGING SYSTEM IN A DIGITAL TELECOMMUNICATIONS NETWORK

TECHNICAL FIELD

[0001] This application relates generally to digital networking and specifically to techniques for providing an interface to an external charging system in a digital telecommunications network.

BACKGROUND

[0002] To date, digital networking technologies have enabled a wide variety of digital applications, such as smart phones and wearable devices. As networking technologies improve, even more applications are on the horizon. For example, the deployment of 5^th generation (5G) digital cellular networks in the coming years is expected to enable a host of emerging applications such as autonomous vehicles, augmented and virtual reality devices, machine-to-machine (M2M) communications, and the like.

[0003] On the other hand, deploying, operating, and maintaining digital telecommunications networks can be costly. It can therefore be desirable to charge users for their usage of network services that are delivered via digital telecommunications networks.

[0004] Accordingly, it is desirable to develop improved techniques for charging users of digital telecommunications networks.

BRIEF DESCRIPTION OF THE DRAWINGS

[0005] FIG. 1 is a simplified diagram of a telecommunications system with charging capabilities according to some embodiments. [0006] FIG. 2 is a simplified diagram of a legacy (pre-5G) 3GPP charging architecture according to some embodiments.

[0007] FIG. 3 is a simplified diagram of a 5G 3GPP converged charging architecture according to some embodiments.

[0008] FIG. 4 is a simplified diagram of a converged charging architecture that provides charging interfeces associated with legacy nodes and 5G nodes according to some embodiments.

[0009] FIGS. 5 A and SB are simplified diagrams of a 5G converged charging architecture according to some embodiments.

[0010] FIGS. 6A and 6B are simplified diagrams of a telecommunications network with a unified charging system according to some embodiments.

[0011] FIG. 6C is a simplified diagram of an API description for an API provided by a unified charging interface according to some embodiments.

[0012] FIG. 7 is a simplified diagram of a method for providing an interface to an external charging system according to some embodiments.

[0013] Various objectives, features, and advantages of the disclosed subject matter can be more fully appreciated with reference to the following detailed description of the disclosed subject matter when considered in connection with the following drawings, in which like reference numerals identify like elements.

DETAILED DESCRIPTION

[0014] Digital telecommunications networks often include features for charging and quota enforcement. For example, configuring a network to charge users according to the amount of network bandwidth they use (e.g., the amount of uplink traffic sent, downlink traffic received, or a combination thereof) can facilitate efficient management and maintenance of the network.

[0015] Charging and quota enforcement can be implemented in a variety of ways.

For example, users who access the network can be charged an amount of money for exceeding their quota, or their traffic can be blocked or throttled when they exceed their quota. These metering and enforcement mechanisms can help disincentivize users from overusing the network and straining the resources of the network. In addition, these mechanisms can ensure that high volume users pay more to access the network than low volume users. Charging can be “online” (e.g., users are charged in real-time based on their usage of the networking services, which can include real-time reduction in services if the user exceeds their usage limits) or “offline” (e.g., usage data is collected and stored, and the user is later charged at the end of a billing period, such that real-time usage is not affected).

[0016] On the other hand, the process of configuring a network to implement charging and quota management features can itself consume network resources. For example, charging and quota management may include communication among network nodes, e.g., between a first node that provides call control services and a second node that provides charging services. Because these communications occur over communication interfaces, each node that is associated with charging and quota management features may include one or more interfaces for handling charging- related communications. Provisioning these communication interfaces can be resource-intensive and can involve substantial complexity.

[0017] This complexity of charging interfaces is exacerbated by the fact that some nodes may include a plurality of charging interfaces. For example, a node may include a first communication interface for communications related to “online” charging and a second communication interface for communications related to “offline” charging. A node can also support different telecommunications standards or different versions of a given telecommunications standard. In such scenarios, the node may include a plurality of charging interfaces associated with each standard or version of a standard that the node supports. Accordingly, the node may devote significant resources to implementing these charging interfaces. Moreover, the complexity of the node is increased because each application of the node that uses the charging interfaces may include additional logic to determine which of the plurality of charging interfaces to use for a given communication and to send and receive communications over each charging interface with the appropriate formatting. The node may also include logic for handling scenarios when a charging interface or the destination charging system is down.

[0018] Accordingly, it is desirable to develop improved techniques for charging in digital telecommunication networks, particularly techniques that simplify and reduce the resources used to implement charging interfaces.

[0019] FIG. 1 is a simplified diagram of a telecommunications system 100 with charging capabilities according to some embodiments. A plurality of devices 101- 109 are communicatively coupled via a plurality of networks 111-119. Devices 101- 109 generally correspond to computing devices with networking capabilities. Non- limiting examples of devices 101-109 include, but are not limited to, mobile devices, smart phones, wearable computers, laptop computers, desktop computers, or server blades. Devices 101-109 can also include or be associated with household devices, vehicles (including autonomous vehicles and drones), industrial equipment, medical devices, or the like. For example, devices 101-109 can include objects that are connected via networks 111-119 using a suitable framework such as Intemet-of- Things (IOT).

[0020] Networks 111-119 can include various types of digital communication networks, such as local area networks, wide area networks, the Internet, wired networks, wireless networks, or any combination thereof. Networks 111-119 can be implemented using physical networking resources, virtual networking resources, or a combination thereof.

[0021] A telecommunications network 120 is coupled between networks 111-119 and is configured to carry one or more network traffic flows between a first network (e.g., network 111) and one or more second networks 112-119. Each network traffic flow includes network traffic (e.g., sequences of packets or other digital signals that convey information) that is communicated between a first device (e.g., device 101) and one or more second devices (e.g., devices 102-109). For example, a network traffic flow can include uplink traffic (e.g., traffic that originates at device 101 and is transmitted to one or more of devices 102-109), downlink traffic (e.g., traffic that originates from one or more of devices 102-109 and is transmitted to device 101), or a combination thereof.

[0022] In some embodiments, the network traffic flows may carry traffic associated with one or more applications associated with device 101. Examples of applications that may be associated with the network traffic flows include, but are not limited to, streaming video applications, social media applications, messaging applications, augmented reality or virtual reality applications, machine to machine (M2M) applications, or the like. In some embodiments, a network traffic flow may be associated with a quality-of-service (QoS) or other parameters indicating the priority of a given flow relative to other flows.

[0023] Telecommunications network 120 may provide charging capabilities. For example, telecommunications network 120 may be configured to monitor and/or enforce quotas on the amount of network traffic associated with device 101 (online charging), collect data associated network traffic flows for billing purposes (offline charging), or the like, hi some embodiments, device 101 (or a user of device 101) may be assigned a quota on uplink, downlink, or total network traffic. Different types of network traffic may be charged against the quota in different ways, e.g., in a weighted fashion. For example, certain types of traffic flows may be zero-rated (e.g., they do not consume any of the quota), and others may be charged less or more than other flows relative to the quantity of bandwidth that they consume. As a non- limiting illustration, a network traffic flow carrying video streaming traffic associated with a video streaming content provider (e.g., Netflix or Youtube) may be charged at a first rate, a network traffic flow carrying social media traffic associated with a social media content provider (e.g., Facebook or Instagram) may be charged at a second rate, and a default network traffic flow carrying general Internet traffic may be charged at a third rate, the three rates being different from one another. Accordingly, telecommunications network 120 may monitor network traffic flows and enforce the quotas based on the amount of network traffic in each flow. For example, telecommunications network 120 may enforce a usage quota associated by throttling or limiting an amount of network traffic when a usage quota is used up, by charging a user of device 101 for an additional amount of usage quota, or the like.

[0024] To provide these charging capabilities, telecommunications network 120 may include one or more charging systems, such as charging system 130. Charging system 130 may provide online charging services, offline charging services, or the like. Charging system 130 may be implemented using a variety of charging architectures, illustrative embodiments of which are discussed below with reference to FIGS. 2-5B. In some embodiments, charging system 130 may provide charging capabilities in accordance with one or more different telecommunications standards, including different versions of a given standard. Charging system 130 may interact with a billing domain 135, which provides services for billing users of telecommunications network 120. Billing domain 135 may be part of the core telecommunications network 120 or may be separate, as depicted in FIG. 1.

[0025] A controller 140 of system 100 includes a processor 142 (e.g., one or more hardware processors) coupled to a memory 144 (e.g., one or more non-transitory memories). In some embodiments, memory 144 may store one or more computer programs that include, e.g., instructions and data to cause processor 142 to perform operations associated with the one or more computer programs. Although a single processor 142 and memory 144 are shown in FIG. 1, the computing resources of controller 140 can generally be distributed, virtualized, containerized, cloud-based, or the like. In some embodiments, controller 140 may be located in one or more data centers of a telecommunications service provider.

[0026] As depicted in FIG. 1, memory 144 stores a program that includes instructions that cause processor 142 to carry out operations associated with a node 150 of telecommunications network 120 when executed by processor 142. In general, node 150 can perform a variety of functions associated with telecommunications network 120. For example, node 150 may include an application 152, such as a call control application. In some embodiments, node 150 may be located along the data path of one or more of the network traffic flows associated with device 101, in which case node 150 may process network traffic to or from device 101. In some embodiments, node 150 may be located outside of the data path and may perform control and management functions, such as functions associated with session management, charging, and the like. Although a single node 150 is shown in FIG. 1 for simplicity, it is to be understood that telecommunications network 120 may include a plurality of nodes. For example, charging system 130 may include one or more nodes. Node 150 may communicate with other nodes of telecommunications network 120 via various communications interfaces.

[0027] Application 152 may be configured to interact with charging system 130 during operation. For example, application 152 may perform functions associated with monitoring network traffic, managing or enforcing quotas, rating traffic, billing, or the like. In some embodiments, one or more functions of application 152 may trigger application 152 to send information to charging system 130 when certain charging-related events occur. Accordingly, node 150 may include one or more charging interfaces over which application 152 can communicate with charging system 130. Via the one or more charging interfaces, for example, application 152 may send data associated with network traffic to charging system 130, may receive quota information from charging system 130, or the like.

[0028] In some embodiments, the one or more charging interfaces associated with node 150 may be implemented using a unified charging system 154. Embodiments of unified charging system 154 are discussed in further detail below with respect to FIGS. 6A-6B. As will be discussed, using unified charging system 154 reduces the complexity associated with the one or more charging interfaces relative to configurations in which the one or more charging interfaces are implemented in an ad hoc or piecemeal manner. Although unified charging system 154 is depicted as being a part of node 150, it is to be understood that other arrangements are possible. For example, unified charging system 154 may be provided on a different node of telecommunications network 120 or may be provided as a platform as a service

(PaaS).

[0029] In some embodiments, telecommunications network 120 may correspond to a 3GPP network, e.g., a 2G, 3G, 4G, or 5G network. In such embodiments, node 150 may generally correspond to a 3GPP Network Function (NF) or Network Element (NE). For example, node 150 may provide services in the form of procedures performed by a Call Control application (e.g., application 152). Consistent with such embodiments, application 152 may include or may be associated with a 3GPP Charging Trigger Function (CTF). Examples of Network Elements that can include CTFs include a Packet Data Network Gateway (PGW), a Serving Gateway (SGW) and a Service Capabilities Exposure Function (SCEF). Examples of Network Functions that can include CTFs include an Access and Mobility Management Function (AMF), a Session Management Function (SMF), and a Network Exposure Function (NEF).

[0030] FIGS. 2-5B depict different types of charging architectures used in 3GPP telecommunications networks. As these figures illustrate, 3GPP charging architectures have evolved over a period of time with the introduction of the new technologies (e.g., 2G, 3G, 4G, and 5G). The concept of converged charging was introduced in 5G service-based architecture, where the NFs/NEs communicate, for example, over the representational state transfer (REST) based Nchf charging interface. In 2G, 3G, and 4G architectures, the NFs/NEs use, for example, the Gz, Gy, Ga, Bp, Bd, and Bam interfaces. In embodiments consistent with FIG. 1, the NFs/NEs depicted in FIGS. 2-5B may generally correspond to node 150, and the charging system may generally correspond to charging system 130. FIGS. 2-5B are described in further detail in 3GPP Specification TS 32.240, entitled “Telecommunication management; Charging management; Charging architecture and principles,” which is incorporated by reference herein in its entirety. It is to be understood that, with appropriate modifications, the charging architectures depicted in FIGS. 2-5B may analogously be used in non-3GPP telecommunications networks or future versions of 3GPP networks.

[0031] FIG. 2 is a simplified diagram of a legacy (pre-5G) 3GPP charging architecture 200 according to some embodiments. Charging architecture 200 includes an offline charging architecture 202 and an online charging architecture 204. Offline charging architecture 202 includes a node (e.g., an NF/NE) 212 that includes a charging trigger function (CTF) 222. Similarly, online charging architecture 204 includes a node (e.g., a 3GPP NF/NE) 214 that includes a charging trigger function (CTF) 224. CTF 222 interacts with nodes associated with an offline charging system 232, including a charging data function (CDF) node and a charging gateway (CGW) node. CTF 224 interacts with nodes associated with an online charging system 234, including an online charging function (OCF) node.

[0032] FIG. 3 is a simplified diagram of a 5G 3GPP converged charging architecture 300 according to some embodiments. Converged charging architecture 300 includes a node (e.g., a 3GPP NF/NE) 310 that includes a charging trigger function (CTF) 320. CTF 320 interacts with nodes associated with a converged charging system 330 to provide both online and offline charging capabilities.

[0033] FIG. 4 is a simplified diagram of a converged charging architecture 400 that provides charging interfaces associated with legacy nodes (e.g., node 420) and 5G nodes (e.g., node 430) according to some embodiments. Charging system 410 interacts with the legacy nodes over a first set of charging interfaces, which includes separate charging interfaces for offline and online charging communications, and interacts with the 5G nodes over the Nchf charging interface, which handles online and offline charging communications in a converged manner.

[0034] FIGS. 5A and 5B are simplified diagrams of a 5G converged charging architecture 500 according to some embodiments. Converged charging architecture 500 includes one or more of a 5G Core Access and Mobility Management Function (AMF) node 512 or a Session Management Function (SMF) node 514. Nodes 512 and 514 each include a charging trigger function (CTF) 520. CTF 520 interacts with a charging function (CHF) associated with a converged charging system 530 via the Nchf charging interface. Converged charging system 530 interacts with a billing domain 540 via a Charging Gateway function (CGF) node. Depending on the location of the CGF node relative to converged charging system 530 and billing domain 540, one or more interfaces may be used to handle communications between converged charging system 530 and billing domain 540. For example, when the CGF node is located in converged charging system 530, a Bam interface may be used. When the CGF node is located in billing domain 540, a Ga interface may be used. When the CGF node is located between converged charging system 530 and billing domain 540, each of the Bam and Ga interfaces may be used.

[0035] As illustrated in FIGS. 2-5B, 3GPP Network Elements and Network Functions may support one or more charging interfaces. These charging interfaces may be ancillary to the primary functions the NEs/NFs, such as call control processing. Moreover, the charging interfaces may increase the complexity of the NEs/NFs and may therefore introduce challenges into the design, programming, operation, and maintenance of the NEs/NFs. To illustrate, the charging interfaces may provide a wide range of functionalities, and as such may involve significant complexity. A non-limiting set of functionalities provided by the charging interfaces of a given node may include the one or more of the following: generating charging data records (CDR), such as those defined in the 3GPP 32.297 and 32.298 specifications (each of which is hereby incorporated by reference in its entirety); providing an interface to communicate with one or more of a Converged Charging System, an Online Charging System (OCS), or an Offline Charging System (OFCS); generating GPRS Tunneling Protocol Prime (GTPP) protocol CDRs for transmission over a Ga interface; rotation management of CDR files for local CDRs; transferring local CDRs to a Billing Server/Mediation Server through pull/push modes; providing disk management through CDR file purge policies; interworking between the 5G Nchf charging interface and legacy interfaces, such as DIAMETER and GTPP; generating CDRs on a local disk when a remote server (e.g., converged charging server, OCS/OFCS server, GTPP server) is down; formatting local CDRs (e.g., in ASN1, XML, or CSV format); and redirecting Nchf messages for 3xx HTTP status codes using a location header.

[0036] Accordingly, each node that supports charging and/or interacts with a charging system or a billing domain may separately implement charging interfaces that provide one or more of these functionalities. Moreover, each node may provide fine grained control over the provisioning of these interfaces, e.g., based on operator deployment considerations. The complexity of provisioning and managing these charging interfeces is in addition to the call control processing or other functions performed by the node. Moreover, the functionality for particular charging interface (for example Ga) may be same for any NF/NE that uses the charging face, resulting in redundant yet complicated interfeces being implemented across NFs/NEs.

[0037] FIGS. 6A and 6B are simplified diagrams of a telecommunications network 600 with a unified charging system 610 according to some embodiments. Telecommunications network 600 includes one or more nodes (e.g., nodes 622 and 624) and one or more charging systems (e.g., charging system 630), which generally correspond to similarly labeled components depicted in FIG. 1. In some embodiments, telecommunications network 600 may be a 3GPP telecommunications network. Consistent with such embodiments, nodes 622 and 624 may correspond to 3GPP NFs/NEs, such as those depicted in FIGS. 2-5B. Charging system 630 may include one or more of a 3GPP Converged Charging System with a Charging Function (CHF) 631, an Online Charging System (OCS) 632, an Offline Charging System (OFCS) 633, or a Charging Gateway Function (CGF) 634. However, it is to be understood that the features of unified charging system 610 are not limited to 3GPP telecommunications networks and may, with appropriate modifications, be applicable to various types of telecommunications networks with charging capabilities.

[0038] Unified charging system 610 addresses the complexity of implementing a plurality of different charging interfeces and charging functionalities at each node of telecommunications network 600 that supports charging capabilities. In general, unified charging system 610 may provide the functionalities of the charging interfeces described above with reference to FIGS. 2-5B through a unified interface 640. Through unified interface 640, applications running on nodes 622 and 624, such as a call control application 650, can interact with one or more different external charging systems, or nodes thereof.

[0039] Unified charging system 610 may simplify the applications running on nodes 622 and 624. For example, the applications can operate in accordance with the charging architecture implemented by unified interface 640 (e.g., the 5G converged charging architecture). Adaptation to other charging architectures (e.g., online or offline charging architectures), and other services (e.g., generation of local CDRs), may be handled by unified charging system 610 rather than by the applications themselves. This may reduce development costs associated with adding charging functionality to applications running on nodes 622 and 624.

[0040] Unified charging system 610 may be able to accommodate a wide range of applications that support charging capabilities. Because a number of nodes and applications in given network may leverage unified charging system 610, unified charging system 610 may reduce the cost ofNF/NE productization and maintenance. The external interfaces of unified charging system 610 may be selectively enabled (e.g., based on various criteria like DNN, RAT Type, etc.) through provisioning, thereby expanding the range of applications that can use unified charging system 610 without significantly increasing the complexity of applications that use a subset of the external interfaces.

[0041] Unified charging system 610 may reduce revenue loss associated with telecommunications network 60 by providing applications with access to one or more interfeces, such as legacy interfaces. For example, an application may be able to charge for an event that it may not otherwise have been able to charge, e.g., when the particular event is associated with a legacy interface. Unified charging system 610 may also provide network operators with revenue assurance during migrations. For example, during a migration from legacy charging architectures to a 5G architecture (or another type of migration), a network operator could enable both the legacy and 5G charging architectures during the migration to ensure the 5G architecture is working according to the requirements before completing the migration. Moreover, unified charging system 610 may provide the network operator with the flexibility to upgrade the core network to 5G, even when the billing domain remains legacy.

[0042] In some embodiments, unified charging system 610 may generate and store local charging records, such as CDRs. The local records may be based on at least a portion of the charging communications that unified charging system 610 receives. The records may be prepared according to a standard format (e.g., 4G or 5G) and stored in a predefined file format (e.g., ASN1, XML, or CSV). The records may be generated by default or in response to predefined conditions, such as when an external charging system or an internal application is determined to be down or otherwise unreachable or nonoperational (e.g., “emergency" CDR generation).

[0043] Unified charging system 610 can be implemented locally with respect to a given node, as depicted in FIG. 6A, remotely from a node, as depicted in 6B, or in other distributed arrangements. For example, unified charging system 610 can be implemented as as a functional extension of Network Function/N etwork Element in public, private, or hybrid cloud deployments, or on bare metal. In some embodiments, unified charging system 610 may be implemented as a platform as a service (PaaS), such that a plurality of nodes may leverage a given instance of unified charging system 610.

[0044] Unified charging system 610 may include one or more external charging interfaces 661-669 that communicatively couple unified charging system 610 to one or more external charging systems, or functions thereof. For example, external charging interfaces 661-669 may include an Nchf charging interface that couples unified charging system 610 to CHF 631 and one or more legacy 3GPP interfeces, such as Gy, Gz, and Ga, which couple unified charging system 610 OCS 632, OCFS 633, and CGF 634, respectively. Other interfeces implemented by unified charging system 610 may include Bd, Bp, and Bam interfaces.

[0045] In some embodiments, unified charging interface 640 may be a REST-based interface. One or more, including all, of the communications among various internal components of unified charging system 610 may be communicated over REST-based interfeces. For example, in some embodiments, one or more components of unified charging system 610 is independently scalable, e.g., vertically, horizontally, or both. In this manner, various components unified charging system 610, and various processing instances of a given component, can be added or removed based on deployment needs. The use of REST-based interfaces allows unified charging system 610 to operate in a stateless manner, thereby facilitating scalability. The statelessness of the services may also provide high availability, for example, through the use of external databases to store information associated with charging sessions.

[0046] Information transmitted over unified charging interface 640 may include data related to charging, metadata, and the like. In some embodiments, the metadata may include information from an application that informs unified charging system 610 how to process a given transmission. For example, metadata may be used to determine which of external charging interfaces 661-669 to send a given transmission over, to determine how to format a transmission for communication over a particular interface, or the like. In this manner, an application, such as call control application 650, may use the metadata to signal to unified charging system 610 how to process charging information that is communicated via unified charging interface 640. The formatting of the metadata (e.g., permitted fields, data types, and values) may be specified in an application programming interface (API) description associated with unified charging interface 640, such as an OpenAPI Specification. An illustrative API description 641 for an API provided by unified charging interface 640 is depicted in FIG. 6C. API description 641 specifies a variety of metadata fields 642 associated with unified charging interface 640.

[0047] In some embodiments, unified charging interface 640 may provide an internal communications interface for applications running on nodes 622 and 624 that is consistent with a standardized charging interface, such as the 5G Nchf charging interface. Unified charging interface 640 may be compliant with the Nchf charging interface and may optionally provide for additional metadata (or other signaling mechanisms) that is not part of the Nchf specification. Although the internal unified charging interface 640 is consistent with Nchf, the communications may be forwarded over external charging interfaces other than the Nchf charging interface, such as legacy interfaces. Accordingly, unified charging interface 640 may be denoted Nchf+ The applications running on nodes 622 and 624 may communicate over Nchf+ consistently as if it is using the 5G converged charging model, even when using non-5G charging capabilities or when one or more external charging functions 631-634 is unreachable (e.g., when generating emergency CDRs). Because the complexity of implementing and adapting communications to each of external charging interfaces 661-669 or to emergency CDRs is handled by unified charging system 610, applications running on nodes 622 and 624 may be able to access a rich set of external charging interfaces by providing metadata or other control information over unified charging interface 640, which may be less complex than implementing each of external charging interfaces 661-669 themselves.

[0048] In some embodiments, unified charging system 610 may include a charging agent 672. Each processing instance of charging agent 672 sends and receives communications over unified charging interface 640 between unified charging system 610 and applications running on nodes 622 and 624. For example, charging agent 672 may provide one or more charging profiles, e.g., sets of configuration information associated with external charging interfaces 661-669. In this manner, an application can provide, via metadata or otherwise, the name (or other identifier) of a charging profile associated with an external charging interface that the application has selected to use for a given charging session. In some embodiments, unified charging system 610 may include a plurality of processing instances of charging agent 672 corresponding to different charging sessions.

[0049] A charging profile may include provisioning details for a given external interface, such as the type of interface (e.g., Nchf, Ga, Gy, or Gz), whether to perform local CDR generation, the local CDR format, or the like. Based on information in the selected charging profile, a processing instances of charging agent 672 initiates signaling via the corresponding external charging interface to establish a charging session over the interface. For example, when a charging profile is associated with the Nchf charging interface and provides for local CDR generation, the corresponding processing instance of charging agent 672 initiates signaling towards CHF 631 to create the converged charging session and initiates a CDR generation request to a CDR agent 674, e.g., via an application programming interface (API) provided by CDR agent 674. The processing instance of charging agent 672 converts data from unified interface 640 into the format used for CDR generation. For example, when the CDR is generated in the ASN1 format, charging agent 672 adapts content received via unified interface 640 to the ANS 1 format content type. Accordingly, charging agent 672 can streamline interface provisioning and conversion tasks by using charging profiles, thereby reducing the complexity of the applications that use the interface.

[0050] In some embodiments, charging agent 672 may be configured to automatically select a charging profile for a given processing instances. Consistent with such embodiments, an application may omit the process of identifying a charging profile using metadata (or other control information). For example, charging agent 672 may be configured to carry out a profile selection method, which may include selecting a charging profile for a given message received via unified interface 640 based on one or more provisioning options. For example, the provisioning options may define a set of keys or identities, which correspond to information contained in the message. Illustrative examples of such keys or identities include 3GPP call processing related identities, such as DNN Name, SUPI, RAT Type, and the like. In this manner, charging agent 672 may automatically select a charging profile based on one or more identities received in a given message via unified interface 640. In some embodiments, an application can override the automatically selected charging profile by sending metadata or other control information to charging agent 672.

[0051] In some embodiments, charging agent 672 may be configured to provide adapter functionality, which may facilitate interconnectivity between call control application 650 and various external charging interfaces 661-669 without significantly increasing the complexity of call control application 650. For example, when call control application 650 is a 5G Network Function and interacts with legacy interfaces like Gy, Gz or GTPP, or generates local CDRs in 4G format, charging agent 672 may provide the 5G-to-4G adapter functionality. When call control application 650 is a 4G Network Element and interacts with a 5G Nchf interface or GTPP, or generates local CDRs in a 5G format, charging agent 672 may provide 4G- to-5G adapter functionality. Various other adapter functionalities are possible based on the type of application and the type of interface the application is interacting with.

[0052] When a charging profile is associated with local CDR generation, charging agent 672 may provide adapter functionality from Nchf to a target CDR file format (e.g., ASN1, CSV, XML, or the like). Consistent with such embodiments, charging agent 672 may interact with CDR agent 674 via an API. For example, charging agent 672 may interact with a CDR agent 674 over a REST-based interface.

[0053] When a charging profile is associated with online Gy interface provisioning, charging agent 672 may provide adapter functionality from Nchf to Gy format Consistent with such embodiments, charging agent 672 may interact with an OCS agent 676, e.g., over a REST-based interface.

[0054] When a charging profile is associated with offline Gz interface provisioning, charging agent 672 may provide adapter functionality from Nchf to Gz format Consistent with such embodiments, charging agent 672 may interact with an OFCS agent 678, e.g., over a REST-based interface.

[0055] When a charging profile is associated wife offline Ga interface provisioning, charging agent 672 may provide adapter functionality from Nchf to GTPP format Consistent wife such embodiments, charging agent 672 may interact wife a GTPP agent 680, e.g., over a REST-based interface.

[0056] More generally, each processing instance of charging agent 672 may interact with one or more additional agents (including but not limited to agents 674-680) or other services, each of which corresponds to a particular charging interface (or set of interfeces) among charging interfeces 661-669. The determination of which additional agents charging agent 672 interacts with is based on the charging profile that is identified by the application or is automatically selected by charging agent 672, as discussed previously. Charging agent 672, alone or in conjunction with the additional agents or services, may provide adapter functionality as appropriate to convert messages from a first messaging format (e.g., Nchf or another format used to communicate over unified interface 640) to a second messaging format (e.g., Gy, Gz, GTPP, or other formats used to communicate over charging interfeces 661-669). The communications between charging agent 672 and the one or more additional agents may occur over REST-based interfeces, e.g., to facilitate horizontal and vertical scalability, to improve availability, or the like.

[0057] When a charging profile is associated with a converged Nchf interface, charging agent 672 may strip off metadata from messages received from an application via unified interface 640 and forward the content of the message to CHF 631. The message may be forwarded over the Nchf interface by charging agent 672 without using an additional agent of unified charging system 610. Messages from CHF 631 to tire application are received by charging agent 672, which relays the messages to the application.

[0058] For each charging session, charging agent 672 may create a unique resource identifier (URI) and share the identifier (and other charging session information, as appropriate) with CHF 631. Sharing the URI with CHF 631 may allow a particular charging session to receive CHF-initiated server messages on behalf of the application. In some embodiments, the URI may be transmitted to CHF 631 by adding the identifier to a payload or header of a message forwarded to CHF 631. Charging agent 672 may similarly share the URI (and other charging session information, as appropriate) with the application in a response message associated with the start of a charging session. For example, charging agent 672 may transmit the URI in a Location header field of a converged charging create response message. Charging agent 672 may persist charging session information in a database, such as database 682. Charging agent 672 may also persist charging session information used for CDR generation in database 682 or a different database, such as database 684.

[0059] In some embodiments, charging agent 672 may be aware of 3GPP slice details. For example, charging agent 672 may obtain information associated with public land mobile networks (PLMNs) and network slices to provide 3GPP network slicing functionality. In some embodiments, charging agent 672 may receive PLMN and slice information via an interface message from a CTF and may use that information to identify external charging interfaces 661-669. T he use of slicing information may be consistent with 5G system requirements associated with network slicing capabilities at PLMN and slice levels. In some embodiments, generated CDRs related to different PLMNs and slices may be kept in separate directories, which may assist in the billing domain to segregate and send CDRs to the correct mediation functions.

[0060] .When a charging system or charging function that provides online charging services (e.g., Nchf 631 or OFS 632) is down, unified charging system 610 may be configured to automatically switch to one or more of local CDR generation, GTPP CDR generation, offline charging services (e.g., OFCS), or the like. When the online charging service is back online, unified charging system 610 may automatically switch back to the online charging service.

[0061] In some embodiments, CDR agent 674 may provide REST-based interface towards charging agent 672. For each type of record, CDR agent 674 may provide a different API associated with a different instance of CDR agent 674. A given processing instance of CDR agent 674 is configured to encode and write local CDRs into one or more files.

[0062] When deployed in 3GPP telecommunications networks, CDR agent 674 may provide functionality that is compliant with the 3GPP 32.298 and 32.297 specifications. However, it is to be understood that CDR agent 674 may perform tasks associated with non- 3 GPP charging records in various embodiments, in which case CDR agent 674 may maintain charging records in accordance with other telecommunications standards, non-standardized charging records, or the like.

[0063] CDR agent 674 may write the files to persistent storage, e.g., database 684, which can be local, remote, distributed, or may include any other suitable storage type. During startup, CDR agent 674 may bind to the persistent storage. An operator of telecommunications network 600 may configure the directory structure where the files are written. To distinguish between open files (e.g., those which CDR agent 674 is in the process of writing) and closed files, separate subdirectories may be maintained for open files and closed files, in some embodiments, CDR agent 674 may be aware of network slices, and may generate and segregate files according to the slice level details. When a given processing instance of CDR agent 674 ceases operation (e.g., due to an operator instruction, a fault, or the like), another processing instance of CDR 674 may claim orphaned open files — e.g., files that were opened, but not closed, by the terminated processing instance — and close them. The processing instance that is claiming the file may then move it to a directory designated for closed files.

[0064] In some embodiments, CDR agent 674 processing instances may include timers for open orphan files. For example, the timers may be configured as reliable timers, which provide a reliable timer expiry notification for a given timer interval. The timers may be associated with a handle or other information that identifies a corresponding processing instance of CDR agent 674. Based on the handle, it can be determined whether the corresponding processing instance is alive at the expiration of the timer, hi a scenario where the corresponding processing instance is alive, the timer is restarted. In a scenario where processing instance is not alive at the expiration of the timer, files related to this processing instance are closed and moved to the closed directory by another instance of CDR agent 674.

[0065] In some embodiments, CDR agent 674 may name files according to one or more file name conventions. For example, CDR agent 674 may name files using a unique running counter, e.g., according 32.297 specification.

[0066] In some embodiments, database 684 may correspond to a mounted path, or another suitable type of shared directory. This mounted path may also be mounted to (or otherwise shared with) one or more of a local CDR file manager 686 or a shared file transfer protocol (SFTP) server service 687. For example, SFTP server service 687 may be responsible for the transfer of CDRs to the billing domain. [0067] In some embodiments, CDR agent 674 may perform file rotation based on, e.g., the number of records in a file, the size of the file, a time limit associated with the open file, or the like. In some embodiments, file rotation may be controlled using file rotation profiles for each processing instance of CDR agent 674. For example, a file rotation profile may include provisioning options to control the file size, number of records in file and open file limit, private extension, file extension, or the like.

[0068] Local CDR file manager 686 is configured to manage files stored in database 684. For example, local CDR file manager 686 may manage files based on a file purge policy, which includes policies for deleting files when a disk usage threshold reached based on, e.g., the age of the file, the size of the file, or the like. Local CDR file manager 686 may provision the file purge policies based on a file management profile, which identifies the disk capacity and sets thresholds for the disk usage. Based on the provisioning, local CDR file manager 686 may monitor the disk usage and maintain it within the threshold. In some embodiments, local CDR file manager 686 may generate notifications or alerts to inform the operator when disk thresholds are reached.

[0069] In some embodiments, GTPP agent 680 may manage an interface (e.g., the Ga interface) between unified charging system 610 and an external GTPP server, such as CGF 634. GTPP agent 680 may perform CDR transfer and automatic retransmission of CDRs when the GTPP server is down, fluctuated, or the otherwise unreachable. Each processing instance of GTPP agent 680 may provide a REST -based interface towards an associated processing instance of charging agent 672. Because GTPP agent 680 provides services to provision the GTPP servers used for the CDR transfer and manage the interface, charging agent 670 may be simplified, eg., the role of charging agent 670 with respect to the interface may be limited to the task of sending a CDR request to GTPP agent 680. For example, GTPP agent 680 may manage the process of storing the CDR in temporary storage or other persistent storage (e.g., a database 688) and may automatically transmit the CDRs when the interface is available for use.

[0070] In some embodiments, one or more of the Gy and Gz interfaces may correspond to diameter links that support messaging using the diameter protocol. Consistent with such embodiments, unified charging system 610 may include a diameter base service 690. Diameter base service 690 manages one or more diameter links to external Gz and Gy servers (e.g., OCS 676, OFCS 678, or the like).

Diameter base service 690 receives and maintains information about the Gx and Gy links, e.g., status information. This information may be shared with OFCS agent 678 and OCS agent 676 using a subscribe/notify mechanism, such as etcd. Based on the shared status information, OFCS agent 678 or OCS agent 674 may select an alternate server when the link status indicates that a given diameter server cannot be reached.

[0071] OFCS agent 678 provides an interface to OFCS 633 via diameter base service 690. OFCS agent 678 provides offline charging capabilities for pre-5G Network Elements and provides interoperability with legacy charging systems for 5G Network Functions. In some embodiments, when using the Gz interface, charging agent 672 converts messages from the Nchf or Nchf+ format to the Gz format and sends the message to OFCS agent 678. OFCS agent 678 is aware of the available diameter servers and their link status, e.g., based on information shared by diameter base service 690. OFCS agent 678 may perform diameter peer selection when creating a session and may encode message according to diameter protocol. The encoded messages may be sent to diameter base service 690, e.g., via a REST -based interface. For a given Gz diameter session, OFCS agent 678 may create a session identifier (session-id). Based on session identifiers or other suitable signaling information, diameter base service 690 forwards messages from OFCS agent 678 over the corresponding diameter link. In some embodiments, OFCS agent 678 can store various messages and records — such as credit control request (e.g., CCR-T) records — when a given diameter link is down and can resend the messages or records when the diameter link is available.

[0072] OCS agent 676 provides an interface to OCS 632 via diameter base service 690. OCS agent 676 provides online charging capabilities for pre-5G Network Elements and provides interoperability with legacy charging systems for 5G Network Functions, hi some embodiments, when using the Gy interface, charging agent 672 converts messages from the Nchf or Nchf+ format to the Gy format and sends the message to OCS agent 676. OCS agent 676 is aware of the available diameter servers and their link status, e.g., based on information shared by diameter base service 690. OCS agent 676 may perform diameter peer selection when creating a session and may encode message according to diameter protocol. The encoded messages may be sent to diameter base service 690, e.g., via a REST-based interface. For a given Gy diameter session, OCS agent 676 may create a session identifier (session-id). Based on session identifiers or other suitable signaling information, diameter base service 690 forwards messages from OCS agent 676 over the corresponding diameter link. In some embodiments, OCS agent 676 can store various messages and records — such as credit control request (e.g., CCR-T) records — when a given diameter link is down and can resend the messages or records when the diameter link is available.

[0073] FIG. 7 is a simplified diagram of a method 700 for providing an interface to an external charging system according to some embodiments. In some embodiments consistent with FIGS. 1-6B, method 700 may be performed by controller 140 and/or system 600.

[0074] At a process 710, a first charging profile is retrieved. The first charging profile identifies a first charging interface among a plurality of charging interfaces, such as external charging interfaces 661-669. Each of the plurality of charging interfaces, when provisioned, provides a communication link between an application (e.g., application 152 or call control application 650) and an external charging system (e.g., charging system 630). For example, the plurality of charging interfaces may include an Nchf charging interface that provides a link to CHF 631, a Ga charging interface that provides a link to CGF 632, a Gy charging interface that provides a link to OCS 633, a Gz charging interlace that provides a link to OCFS 634, or the like. The external charging system may be consistent with one or more charging architectures, such as a 3GPP online charging architecture, a 3GPP offline charging architecture, a 5G converged charging architecture, or tire like, or any combination thereof.

[0075] The first charging profile may be selected based on, for example, metadata or other information received in a message from the application that identifies the first charging profile. In some embodiments, the first charging profile may be selected automatically (e.g., without metadata from the application) based on, for example, one or more provisioning options provided by a network operator. For example, the provisioning options may define a set of keys or identities, which correspond to information contained in the message. Illustrative examples of such keys or identities include 3GPP call processing related identities, such as DNN Name, SUPI, RAT Type, and the like.

[0076] At a process 720, the first charging interface is provisioned. Provisioning the first charging interface may include creating one or more processing instances of one or more agents associated with the first charging interface (e.g., charging agent 672, CDR agent 674, OCS agent 676, OCFS agent 678, GTPP agent 680, diameter base service 690, or the like), establishing a charging session that allows communication between the application and the external charging system, or the like. In some embodiments, the processing instances of the one or more agents may communicate with each other via REST-based interfaces. In some embodiments, session information associated with a charging session may be stored in a database, such as database 682. [0077] At a process 730, a message associated with the first charging profile is received from the application. For example, the message may include a message transmitted by a charging trigger function (CTF) associated with a 3GPP NF/NE call control application, hi some embodiments, the message may be received via a unified charging interface, such as unified charging interface 640. Accordingly, the message may conform to a messaging protocol associated with the unified charging interface, which may or may not be the same as a messaging protocol associated with the first charging interface. For example, the unified charging interface correspond to the Nchf or Nchf+ charging interface, whereas the first charging interface may include the Nchf interface or a legacy interface, such as Ga, Gy, or Gz. The message may include metadata, such as the optional metadata used at process 710 to identify the first charging interface.

[0078] At a process 740, the message is forwarded to the external charging system via the first charging interface. Forwarding the message may include adapting the message to conform to a messaging format associated with the first charging interface. For example, the message may be adapted from the Nchf format (or other messaging format) used by the unified charging interface to a legacy format associated with the first charging interface. In some embodiments, when the received message includes metadata, the metadata may be stripped from the message at process 740. For example, when the message received at process 740 is an Nchf message with optional metadata and the first charging interface is an Nchf message, the optional metadata may be removed from the received Nchf message during forwarding of the message. In some embodiments, one or more of the agents associated with the first charging interface may store the message (or contents thereof) in response to determining that the first charging interface is down and may replay the stored messages when connectivity is restored. [0079] Analogous processes may be performed to forward messages received from the external charging system to the application. For example, a second message may be received from the external charging system via the first charging interface. The second message may be adapted to conform to the messaging format associated with the unified charging interface, including optionally adding metadata to the message. The second message may then be sent to the application via the unified charging interface.

[0080] At a process 750, a charging record is generated based on the message. For example, the charging record may include a CDR. In some embodiments, the charging record may be generated according to a first charging record format among a plurality of charging record formats. The first charging record format can be identified in the first charging profile retrieved at process 710. In some embodiments consistent with FIGS. 6A-6B, generating the charging record may include forwarding, by a processing instance of a charging agent (e.g., charging agent 672), the message (or information derived from the message) to a processing instance of a CDR agent (e.g., CDR agent 674). The charging record and session information used for generating charging records may be stored in a database, such as database 684.

[0081] In some embodiments, a charging record may be generated at process 750 in response to determining that the first charging interface is down. For example, the external charging system may be unreachable or unresponsive, the first charging interface may lose connectivity, or the like. This determination may be made by one or more agents associated with the first charging interface (e.g., charging agent 672, CDR agent 674, OCS agent 676, OCFS agent 678, GTPP agent 680, diameter base service 690, or the like). Accordingly, process 750 may include generating emergency charging records when the first charging interface is down.

[0082] The subject matter described herein can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structural means disclosed in this specification and structural equivalents thereof, or in combinations of them. The subject matter described herein can be implemented as one or more computer program products, such as one or more computer programs tangibly embodied in an information carrier (e.g., in a machine readable storage device), or embodied in a propagated signal, for execution by, or to control the operation of, data processing apparatus (e.g., a programmable processor, a computer, or multiple computers). A computer program (also known as a program, software, software application, or code) can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment A computer program does not necessarily correspond to a file. A program can be stored in a portion of a file that holds other programs or data, in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code). A computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network.

[0083] The processes and logic flows described in this specification, including the method steps of the subject matter described herein, can be performed by one or more programmable processors executing one or more computer programs to perform functions of the subject matter described herein by operating on input data and generating output. The processes and logic flows can also be performed by, and apparatus of the subject matter described herein can be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit).

[0084] Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processor of any kind of digital computer. Generally, a processor will receive instructions and data from a read only memory or a random access memory or both. The essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto optical disks, or optical disks. Information carriers suitable for embodying computer program instructions and data include all forms of nonvolatile memory, including by way of example semiconductor memory devices, (e.g., EPROM, EEPROM, and flash memory devices); magnetic disks, (e.g., internal hard disks or removable disks); magneto optical disks; and optical disks (e.g., CD and DVD disks). The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.

[0085] To provide for interaction with a user, the subject matter described herein can be implemented on a computer having a display device, e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, for displaying information to the user and a keyboard and a pointing device, (e.g., a mouse or a trackball), by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well. For example, feedback provided to the user can be any form of sensory feedback, (e.g., visual feedback, auditory feedback, or tactile feedback), and input from the user can be received in any form, including acoustic, speech, or tactile input.

[0086] The subject matter described herein can be implemented in a computing system that includes a back end component (e.g., a data server), a middleware component (e.g., an application server), or a front end component (e.g., a client computer having a graphical user interface or a web browser through which a user can interact with an implementation of the subject matter described herein), or any combination of such back end, middleware, and front end components. The components of the system can be interconnected by ary form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (“LAN”) and a wide area network (“WAN”), e.g., the Internet.

[0087] It is to be understood that the disclosed subject matter is not limited in its application to the details of construction and to the arrangements of the components set forth in the following description or illustrated in the drawings. The disclosed subject matter is capable of other embodiments and of being practiced and carried out in various ways. Also, it is to be understood that the phraseology and terminology employed herein are for the purpose of description and should not be regarded as limiting.

[0088] As such, those skilled in the art will appreciate that the conception, upon which this disclosure is based, may readily be utilized as a basis for the designing of other structures, methods, and systems for carrying out the several purposes of the disclosed subject matter. It is important, therefore, that the embodiments be regarded as including such equivalent constructions insofar as they do not depart from the spirit and scope of the disclosed subject matter.

[0089] Although the disclosed subject matter has been described and illustrated in the foregoing exemplary embodiments, it is understood that the present disclosure has been made only by way of example, and that numerous changes in the details of implementation of the disclosed subject matter may be made without departing from the spirit and scope of the disclosed subject matter, which is limited only by the embodiments which follow.

[0090] Additional embodiments of the specification described as below:

Claims

1. A method, comprising: retrieving a first charging profile that identifies a first charging interface among a plurality of charging interfaces, wherein each of the plurality of charging interfaces, when provisioned, provides a communication link between an application at a node of a telecommunications network with charging capabilities and an external charging system; provisioning the first charging interface, wherein a first messaging format is associated with the first charging interface; receiving, from the application, a first message associated with the first charging profile, wherein the first message is received via a second charging interface, and wherein the first message conforms to a second messaging format that is associated with the second charging interface; adapting the first message to conform to a first messaging format associated with the first charging interface, thereby creating a first adapted message; and forwarding the first adapted message to the external charging system via the first charging interface.

2. The method of claim 1, wherein: the second charging interface comprises a unified charging interface; the second messaging format comprises an Nchf messaging format; the first messaging format comprises a legacy messaging format; and adapting the first message comprises converting the first message from the Nchf messaging format to the legacy messaging format.

3. The method of claim 1, wherein: the first message comprises metadata; and the method further comprises stripping the metadata from the first message.

4. The method of claim 1, further comprising: receiving a second message from the external charging system via the first interface, wherein the second message conforms to the first messaging format that is associated with the first charging interface; adapting the second message to conform to the second messaging format associated with the second charging interface, thereby creating a second adapted message; and forwarding the second adapted message to the application via the second charging interface.

5. The method of claim 1, further comprising generating a charging record based on the first message, «herein the charging record is generated according to a charging record format that is specified in the first charging profile.

6. The method of claim 1, wherein the charging record is generated in response to determining that the first charging interface is down.

7. The method of claim 1, wherein provisioning the first charging interface comprises: creating processing instances of agents associated with the first charging interface; and establishing a charging session that allows communication between the application and the external charging system.

8. The method of claim 7, wherein the agents comprise at least one of a charging data record (CDR) agent, an online charging system (OCS) agent, an offline charging system (OFCS) agent, a General Packet Radio Service (GPRS) tunneling protocol prime (GTPP) agent, or a diameter base service.

9. A system, comprising: one or more processors; memory in electronic communication with the one or more processors; and instructions stored in the memory, the instructions being executable by the one or more processors to: retrieve a first charging profile that identifies a first charging interface among a plurality of charging interfaces, wherein each of the plurality of charging interfaces, when provisioned, provides a communication link between an application at a node of a telecommunications network with charging capabilities and an external charging system; provision the first charging interface, wherein a first messaging format is associated with the first charging interface; receive, from the application, a first message associated with the first charging profile, wherein the first message is received via a second charging interface, and

«herein the first message conforms to a second messaging format that is associated with the second charging interface; adapt the first message to conform to a first messaging format associated with the first charging interface, thereby creating a first adapted message; and forward the first adapted message to the external charging system via the first charging interface.

10. The system of claim 9, wherein: the second charging interface comprises a unified charging interface; the second messaging format comprises an Nchf messaging format; the first messaging format comprises a legacy messaging format; and adapting the first message comprises converting the first message from the Nchf messaging format to the legacy messaging format.

11. The system of claim 9, wherein: the first message comprises metadata; and the method further comprises stripping the metadata from the first message.

12. The system of claim 9, wherein the instructions are additionally executable by the one or more processors to: receive a second message from the external charging system via the first interface, wherein the second message conforms to the first messaging format that is associated with the first charging interface; adapt the second message to conform to the second messaging format associated with the second charging interface, thereby creating a second adapted message; and forward the second adapted message to the application via the second charging interface.

13. The system of claim 9, wherein the instructions are additionally executable by the one or more processors to generate a charging record based on the first message, and wherein the charging record is generated according to a charging record format that is specified in the first charging profile.

14. The system of claim 9, wherein the charging record is generated in response to determining that the first charging interface is down.

15. The system of claim 9, wherein provisioning the first charging interface comprises: creating processing instances of agents associated with the first charging interface; and establishing a charging session that allows communication between the application and the external charging system.