Patent Application
20150148003
The present disclosure relates to charging domains, and more particularly, to messages exchanged in a charging domain.
Service providers are experiencing ever-growing service usage by subscribers. A service provider implements a charging system in which subscribers are charged for their service usage. An example charging system may implement a policy and charging control solution, such as that developed under 3GPP™ (3rd Generation Partnership Project) IMS (Internet Protocol Multimedia Subsystems) and provides a new standard for charging system business models.
The present invention may be better understood, and its numerous objects, features and advantages made apparent to those skilled in the art by referencing the accompanying drawings.
While the present disclosure is susceptible to various modifications and alternative forms, specific embodiments of the present disclosure are provided as examples in the drawings and detailed description. It should be understood that the drawings and detailed description are not intended to limit the present disclosure to the particular form disclosed. Instead, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the present disclosure as defined by the appended claims.
The present disclosure provides a method, non-transitory computer readable storage medium, and apparatus that implement an adaptable payload object model. In one embodiment, a payload object is generated using a payload specification that defines a plurality of payload attributes, where the payload object includes the plurality of payload attributes. The plurality of payload attributes of the payload object are populated with message attribute values that are extracted from an incoming message. The plurality of payload attributes of the payload object are validated. In one embodiment, the payload object is inserted into an outgoing message and forwarded to a destination, such as a subscriber or a charging engine.
User equipment 115 is a computing device of a subscriber (or a user of a service). Examples of user equipment 115 include a computing device (e.g., a mobile phone, a smartphone, a tablet computer, a laptop computer), a terminal, a kiosk, and like devices that are utilized to access a service. Computing devices are further discussed below in connection with
Elastic charging engine 130 is configured to perform calculation of charges that arise from a subscriber's service usage. Elastic charging engine 130 can be implemented on one or more processing nodes, where the one or more processing nodes are implemented on one or more servers (such as on a grid-based high availability cluster of servers), where a server can be implemented on one or more computing devices. Elastic charging engine 130 includes one or more charging components, each of which is responsible for performing a portion of the calculations needed to charge the subscriber for service usage. The charging components of elastic charging engine 130 can be implemented on the one or more processing nodes of elastic charging engine 130.
External billing engine and/or charging engine 135 may optionally be implemented in charging system 100. If implemented in charging system 100, external billing/charging engine 135 is distinct from elastic charging engine 130 and is configured to perform billing of charges for subscribers and/or additional calculation of charges that arise from a subscriber's service usage. External billing engine/charging engine 135 can be implemented on one or more processing nodes, where the one or more processing nodes are implemented on one or more servers (such as on a grid-based high availability cluster of servers), where a server can be implemented on one or more computing devices. External billing/charging engine 135 also includes one or more charging components, each of which is responsible for performing a portion of the calculations needed to bill and/or additionally charge the subscriber for service usage. The charging components of external billing/charging engine 135 can be implemented on the one or more processing nodes of external billing/charging engine 135. Usage of “charging engine” herein generally refers to a charging engine implemented in charging system 100, which includes charging engine 130 and external billing/charging engine 135.
Mediation system 125 can be implemented on one or more servers, where a server can be implemented on one or more computing devices. Mediation system 125 is communicatively coupled to both elastic charging engine 130 and external billing/charging engine 135. When a subscriber wishes to utilize a service, user equipment 115 of the subscriber is configured to send a service request to mediation system 125 via gateway 120. Mediation system 125 is configured to generate a corresponding charging request and route the charging request to the appropriate charging component of elastic charging engine 130 or external billing/charging engine 135. Each charging request includes a payload that contains information in the form of attributes about the subscriber's service usage, such as the type of service being utilized and service usage measurements (e.g., volume-, time-, or event-based service usage measurements). Elastic charging engine 130 and external billing/charging engine 135 are configured to utilize the payload to charge the subscriber.
Different service providers charge subscribers differently, where a service provider's charging engine performs charging operations for a subscriber based on payload attributes that are often specific to the service provider's charging domain. For example, a charging engine in a telecommunications charging domain would need to receive attributes related to voice usage or data usage, while a charging engine in a shipping charging domain would need to receive attributes related to package size and weight. Other example charging domains include (but are not limited to) a toll road charging domain (e.g., receives attributes related to distance traveled), a telephone charging domain (e.g., receives attributes related to call duration), and a pay per view video charging domain (e.g., receives attributes related to the requested video). Often, a charging engine is built for a particular charging domain, where the charging engine supports the particular attributes needed to charge a subscriber in the particular charging domain.
Some charging systems today attempt to support multiple charging domains by overloading the payload with different sets of attributes that are related to each of the multiple charging domains, resulting in a “kitchen sink” union of all types of charging request payloads (where only one out of the multiple sets of attributes would actually be used in a given charging domain). This approach produces a payload that is larger in size than necessary (due to the excessive number of attributes included in the payload, many of which are unused), which in turn makes the payload expensive to transport across network devices and to persist in memory. This approach also fails to provide a service provider with guidance as to what attributes are required by a specific charging operation, meaning the payload is complicated to construct and implement.
Other charging systems attempt to support multiple charging domains by expressing the payload in abstract terms (e.g., Field1, Param2, and the like). This approach is difficult to implement due to the non-descriptive nature of the abstract terms and the lack of guidance as to what attributes are required by a specific charging operation, meaning the payload is complicated to construct and implement. Additionally, some charging systems fail to validate the payload prior to submitting the charging request to the charging engine. This failure to validate may result in charging errors that occur during runtime charging due to incomplete payloads (e.g., the charging engine does not receive all the information needed to calculate charges) and/or invalid payloads (e.g., the charging engine receives information that is not compatible with the information the charging engine expected to receive).
The present disclosure provides an adaptable payload object model that is used to model different types of payloads and supports the various attributes specified by any particular service provider. A payload definition is a text file that defines a number of attributes carried by a particular type of payload. Multiple payload definition text files can be created, one for each type of payload used in the charging system. A payload definition text file can be created by an administrator of a service provider using a simple text-based domain specific language (DSL) that is applicable to a payload domain, which is a charging domain that uses payloads to perform charging operations (such as the charging domains mentioned above). The DSL, which has a small vocabulary and is easy to learn, allows an administrator to define payload attributes that are specific to the charging domain, without requiring extensive programming knowledge (as opposed to an XML (extensible markup language) based solution, which would burden the service provider by requiring constructs that are not required for the charging domain). The administrator can use DSL to define descriptive attribute names that accurately describe the attributes being used in the charging system, which provides clearer guidance as to what attributes are required by a particular charging operation and prevents runtime charging errors (e.g., errors due to the charging engine receiving attributes mismatched with charging operations or missing information).
Each payload definition text file is parsed into a runtime-specific payload object template, also referred to as a payload specification, which is available for use anywhere in the charging system. Multiple payload specifications can be generated, one for each payload definition text file (and thus one for each type of payload used in the charging system). One or more message builders use the payload specifications to generate payload objects for the various messages exchanged in the charging system. A payload specification represents a particular type of payload, and a payload object generated from the payload specification is an instance of that particular type of payload. Each payload object is populated with attribute values, as defined by the payload specification used to generate the payload object. The payload object is validated to ensure the payload object adheres to the payload specification, and any violations of the payload specification are reported to the subscriber while the payload object is being populated. A validated payload object is used to construct a well-formed message. The message builders will not construct a malformed message, preventing unnecessary runtime charging errors due to malformed payloads (e.g., incomplete and/or invalid payloads). Payload specifications are also versionable, allowing service providers to introduce new attributes in a charging system without requiring extensive programming knowledge or stopping any processes related to the charging engine. The introduction of new attributes while the charging engine is running is critical in some charging domain cases, such as for a pre-paid cell phone service provider whose charging engine must always be on. New versions of a payload specification can be introduced and consumed into a high availability (HA) system without incurring downtime.
The present disclosure is implemented by adaptive request processing service module 140, which is implemented on mediation system 125. Adaptive request processing service module 140 is discussed in further detail below, in connection with
Mediation system 125 can be communicatively coupled to gateway 120, elastic charging engine 130, and/or external billing/charging engine 135 via one or more IP (Internet Protocol) networks that utilize Ethernet, IEEE 802.11x, or some other communications protocol. In light of the present disclosure, it will be appreciated that charging system 100 and access network 110 can include other components such as base stations, access gateways, serving gateways, IP networks, servers, routers, switches, firewalls, and the like that are not germane to the discussion of the present disclosure and will not be discussed further herein. It will also be appreciated that other configurations are possible. For example, a large number of distinct user equipment devices and gateways can be implemented in access network 110. Also, charging system 100 may also include additional components not illustrated. Also, a repository and/or a data store discussed herein can be implemented using one or more storage devices (e.g., a single storage device or a collection of storage devices). A storage device can be implemented using network attached storage (NAS), file servers, storage filers, a storage area network (SAN), and the like.
The letter N is used to indicate a variable number of devices or components that are discussed herein. For example, a variable number of payload specifications 515(1)-(N) are stored in payload specification repository 225. Although the letter N is used in describing a variable number of instances of each of these different devices and components herein, a repeated use of the letter N does not necessarily indicate that each device and component has a same number of N instances implemented in the system.
Payload specification generation module 210 is configured to generate payload specifications from payload definition text files written by an administrator of a service provider. Payload specification generation module 210 includes a DSL (domain specific language) text editor 215, a DSL text parser 220, and a payload specification repository 225. Each component is discussed below.
DSL text editor 215 is configured to provide a user interface (e.g., a graphical user interface (GUI) or a text-based user interface) that is configured to display text entered (e.g., text typed on a keyboard or text selected from a GUI element, such as a drop down menu) by a user or administrator. DSL text editor 215 is configured to implement a DSL, which is a programming language that has a small vocabulary and simplified syntax.
An administrator utilizes DSL text editor 215 to define a payload definition, which is a textual representation of a particular type of payload. A payload definition defines (in text) a number of attributes carried by a particular type of payload used in the charging system. An administrator uses the DSL to define a number of attributes to be included in a payload, where such payload attributes are specific to the charging domain. For example, rather than defining abstract attributes as “Field1” or “Attribute2,” an administrator can accurately describe attributes such as “Call_Duration” in a telephone charging domain, “Distance_Traveled” in a toll road charging domain, “Requested_Video” in a pay per view video charging domain, and the like. Payload attributes that have descriptive names have the benefit of providing an administrator with clearer guidance as to what attributes are necessary for a particular charging operation, thereby preventing runtime charging errors (e.g., errors due to the charging engine receiving mismatched or missing information).
Further, an administrator can use the simplified syntax of the DSL to define the payload attributes and data types included in a payload without being required to have extensive programming knowledge. The DSL's syntax includes well-defined constructs (such as RequestSpecification, ResponseSpecification, Info, Payload, Block, and the like, discussed below) that are used to define the attributes (and data types of those attributes) that are included in a payload. An “optional” keyword also indicates whether a given attribute is optionally included in a payload, rather than required to be included in a payload. The administrator can also define default values or ranges of values for attributes, can define whether zero or more instances of a particular attribute are included in a payload, and can define that the payload is used for a particular type of message (such as charging requests for various types of services). Components of a payload definition text file are further discussed below in connection with
The payload definition is saved as a text file, which can be stored locally at DSL text editor 215 (e.g., in memory or in a storage device communicatively coupled to DSL text editor 215). In another embodiment, payload definitions can be generated using any text editor, as long as the text adheres to the constructs implemented by the DSL when defining a payload. The administrator can define a number of distinct payload definition text files, one text file for each type of payload expected to be used in the charging domain. The administrator can deploy a payload definition to the charging system by sending the payload definition to DSL text parser 220. New payload definitions can be sent to DSL text parser 220 while the charging engine is running (e.g., without stopping or restarting any components of the charging engine).
DSL text parser 220 is configured to parse the payload definition text files received from DSL text editor 215 into payload specifications. DSL text parser 220 is configured to recognize the constructs used by the administrator to define attributes in a payload definition text file and parse the attributes into a payload specification. A payload specification is a payload object template for a particular type of payload and defines a number of attributes carried by the particular type of payload. One or more payload objects are generated using the payload specification as a template, where the payload objects are instances of that particular type of payload. In one embodiment, DSL text parser 220 is implemented using Scala programming language, or a similar programming language.
DSL text parser 220 is configured to output two types of payload specifications, a request specification and a response specification, which are used for different types of messages exchanged in the charging system. A request specification is a payload object template that is used to generate a payload object for a request message destined for the charging engine, and a response specification is a payload object template that is used to generate a payload object for a response message destined for the subscriber. An administrator also uses mapping module 205 to define mapping information between information in a format compatible with a gateway (which is coupled to a subscriber's user equipment) and information in a format compatible with the charging engine, where the two formats are not compatible with one another. Mapping module 205 is configured to maintain a mapping table (which is accessible by instances of message builder 245, further described below) that stores mapping information that associates attributes compatible with the gateway with attributes compatible with the charging engine. The request specification and response specification describe how the mapping information is used to translate information of a subscriber's service request into a charging request compatible with the charging engine, and to translate the charging engine's response into a response compatible with the subscriber's gateway, respectively. Payload specifications are further discussed below in connection with
DSL text parser 220 stores payload specifications in payload specification repository 225, which is a database or other organized collection of data located on a storage device. Payload specifications are added to repository 225 while the charging engine is running (e.g., without stopping or restarting components of the charging engine). Once stored in repository 225, payload specifications are available for use throughout the charging system. In order to implement a “modified” payload specification, a new instance of the payload specification is created (e.g., an administrator can use a copy of the payload specification's payload definition text file as the source material for the new instance of the payload specification). The new instance can be deployed in the charging system as a new version of the payload specification (where both the original version and new version of the payload specification are available for use in the charging system), or the new instance can overwrite the original instance of the payload specification (such as by the new instance having the same version information as the original instance, replacing the original instance). As further described below, each payload specification is associated with an instance of message builder 245, where the message builder instance generates a payload object that adheres to the associated payload specification.
Subscriber message receiver 230 and subscriber message transmitter 235 are coupled to one or more ports of mediation system 125 (e.g., one or more ports of a server on which mediation system 125 is implemented) that are also communicatively coupled to gateway 120. Subscriber message receiver 230 is configured to receive an incoming message from a subscriber's user equipment 115 via gateway 120. In one embodiment, the incoming message is a service request message that requests usage of a service. Subscriber message transmitter 235 is configured to transmit an outgoing message to the subscriber's user equipment 115 via gateway 120. In one embodiment, the outgoing message is a service response message that is responsive to the subscriber's service request message.
Charging engine message transmitter 270 and charging engine message receiver 275 are coupled to one or more ports of mediation system 125 (e.g., ports of a server on which mediation system 125 is implemented) that are also communicatively coupled to components of elastic charging engine 135 (and also to components of external billing/charging engine 140, if implemented in the charging system). Charging engine message transmitter 270 is configured to transmit an outgoing message to a component of elastic charging engine 130 and/or external billing/charging engine 135. In one embodiment, the outgoing message is a charging request message corresponding to a subscriber's (incoming) service request message. Charging engine message receiver 275 is configured to receive an incoming message from a component of elastic charging engine 130 and/or external billing/charging engine 135. In one embodiment, the incoming message is a charging response message responsive to the charging request message (and corresponds to the (outgoing) service response message).
Builder manager 240 is configured to instantiate and to manage one or more message builders 245. Builder manager 240 is configured to instantiate two types of message builders: a request message builder configured to process an incoming message received from a subscriber, and a response message builder configured to process an incoming message from the charging engine. A request message builder is associated with a request specification, and a response message builder is associated with a response specification. Each instance of message builder 245 includes a payload specification retrieval module 250, a payload object generation module 255, a payload attribute population module 2260, and a payload build module 265. Payload specification retrieval module 250 is configured to retrieve an associated payload specification from payload specification repository 225, as further discussed below in connection with
Builder manager 240 is also configured to route an incoming message to the appropriate message builder instance for payload processing. Each message builder instance also has an associated queue or buffer for holding incoming messages in the order that the incoming messages were received at the adaptive request processing service module and routed to the message builder by builder manager 240. Payload object generation module 255 is configured to generate a payload object according to the payload specification associated with the message builder instance. Payload attribute population module is configured to populate the payload object with attributes extracted from the incoming message (in a manner that adheres to the payload specification). Payload build module 265 is configured to build an outgoing message that includes the payload object, where the payload object is validated as the message is built to prevent the creation of any malformed payload objects. Payload build module 265 constructs an outgoing usage request message destined for a charging engine component in response to receiving an incoming service request message from a subscriber, and an outgoing service response message destined for a subscriber in response to receiving an incoming usage response message from a charging engine component. If the outgoing message is successfully built (and the payload object is validated to be a well-formed payload object), payload build module 265 provides the outgoing message to the appropriate transmitter (either subscriber message transmitter 235 or charging engine message transmitter 270), depending on the destination of the outgoing message. The payload processing performed by message builder 245 is further discussed below in connection with
Builder manager 240 may implement multiple thread processes that implement the one or more message builders. The number of thread processes is dependent on the processing capabilities of the one or more computing devices used to implement adaptive request processing service module 140, as well as dependent on the number of messages received from subscribers and from the charging engine that need to be processed. For example, additional thread processes may be instantiated in order to maintain a predefined level of throughput (e.g., a minimum number of messages that are processed by adaptive request processing service module 140 in a given time period).
RequestSpecification construct 315 and ResponseSpecification construct 355 both include DSL constructs Info 320 and Payload 325. Info construct 320 includes metadata describing the payload specification being defined. As illustrated in
The payload specification name (“ReqSpec_Name” for the request specification in
The product type name (“ProductType_Name” in both
The event type name (“EventType_Name” in both
In one embodiment, the event type name also associates the payload specification with the event type's charging plan. Each triggering event may be associated with a different charging or rating plan (referred to herein as simply a charging plan) that is used to calculate charges that arise from a subscriber's service usage of the service product. For example, a Voice product may include different charging plans for a “Voice_Usage” event and a “VOIP_Usage” event (Voice Over IP). A payload specification that includes the combination of the Voice product type and Voice_Usage event type indicates that the payload specification is also associated with the charging plan associated with Voice_Usage.
Payload construct 325 includes information that defines a particular type of payload. As illustrated, Payload construct 325 includes an Info construct 330 and includes zero or more attributes 335 and zero or more Block constructs 340. Info construct 330 includes (but is not limited to) one or more fields, such as a name of a charging operation type (“OperationType” in both
Attributes 335 are payload attributes that are carried by the particular type of payload for a request message and are relevant to the one or more charging operation types identified in Info construct 330. Attributes 335 represent information relevant to the charging operation types identified in Info construct 330, such as network information and subscriber plan information. As discussed above, payload attributes are defined by an administrator and have descriptive names that better identify the information being conveyed in the particular type of payload. However, for simplicity's sake, generalized attribute names Payload_Att_A and Payload_Att_B are used as examples attribute names in
Attributes 345 are payload attributes that are carried by the particular type of payload for a response message and are returned from the one or more charging operation types identified in Info construct 330. Attributes 345 represent information responsive to the request message sent by the subscriber via the gateway. While attributes 335 are compatible with the charging engine, attributes 345 are compatible with the gateway. For simplicity's sake, generalized attribute names Payload_Att_L, Payload_Att_M, and Payload_Att_N are used as example attribute names in
The DSL supports a number of data types used to define payload attributes 345 and 335, including (but not limited to): string, integer, datetime (date time stamp), long integer, big decimal, duration (service product usage in milliseconds, seconds, minutes, hours, days, and so on), occurrence (service product usage that involved a particular event occurence), and data (service product usage in bytes, kilobytes, megabytes, gigabytes, and so on). Attributes can be optional (as indicated by an “optional” keyword, as illustrated in
Block construct 340 also includes one or more payload attributes, which represent subscriber usage information relevant to the charging operation types identified in Info section 330. Payload construct 325 can include a number of Block constructs 340, as indicated by block cardinality located at the end of Block construct 340. Supported block cardinality includes, but is not limited to:
The payload attributes defined in Payload construct 325 (including those defined in Block construct 340) define aspects of the particular event type identified in Info construct 320. The associated charging operation (identified in Info construct 330) uses the attributes in the Payload construct 325 to rate or calculate charges for the particular event type. In this manner, the payload can be constrained to include a limited number of payload attributes that are needed to perform the associated charging operation, rather than including an excessive number of attributes included in a “kitchen sink” type of payload.
Various combinations of product type and event type also indicate when an appropriate payload specification should be used to generate a payload object for a given message. The charging operation associated with the product type and event type combination also uses a charging plan or offer associated with the product type and/or event type to calculate the charges for the subscriber's usage.
Request specifications and response specifications can also be generated for an external billing/charging engine. In such a case, an “external” keyword or flag is used to indicate that the products and events identified in the request or response specification are mapped to service products and events of the external billing/charging engine (e.g., see request specification example 4 below).
Some example payload definition text files for a request specification are provided below:
DSL text parser 220 is configured to recognize DSL constructs in a payload definition text file and to parse the text file into a corresponding payload specification instance. For example, in response to recognizing the “RequestSpecification” keyword in the payload definition text file, DSL text parser 220 is configured to utilize RequestSpecImp1 (request specification implementation class) 410 to generate (or create) a new RequestSpecification template 420. DSL text parser 220 is also configured to utilize ResponseSpecImp1 (response specification implementation class) 415 to generate (or create) a new ResponseSpecification template 425 in response to recognizing the “ResponseSpecification” keyword in the payload definition text file. Both RequestSpecImp1 410 and ResponseSpecImp1 415 have an InfoSection 405, which includes the payload specification name, version, product type, and event type definitions. DSL text parser 220 is configured to populate these definitions with the corresponding values that are extracted from the payload specification text file.
Both RequestSpecification template 420 and ResponseSpecification template 425 have a PayloadSpec template 430 that represents the payload, which is further illustrated in
DSL text parser is configured to recognize constructs defining a number of payload attributes in the payload definition text file and to generate corresponding attributes in PayloadSpec 430. For example, DSL text parser extracts a payload attribute name and associated data type from the text file and generates a corresponding (object) payload attribute in PayloadSpec 430 that has the payload attribute name and associated data type. RequestSpecification 420 and ResponseSpecification 425 are each used to generate instances of a particular payload object, which includes PayloadSpec 430, PayloadView interface 440, and PayloadSet interface 445, which are further discussed below in connection with
The new message builder 510(N+1) includes a payload specification retrieval module 250 that is configured to search the payload specification repository 225 and retrieve a payload specification 515(N) that matches the builder's associated product, event, and version information. The new message builder 510 is dedicated to generating instances of the particular payload object defined by the retrieved (and associated) payload specification, for all incoming messages that require this particular payload object. Retrieval of the payload specification from the repository need only occur once when the message builder is instantiated. This avoids repeated interfacing with the repository to select a different payload specification if general (or non-dedicated) message builders were used. If a new version of a payload specification is deployed in the charging system, builder manager 240 is responsible for managing the associated message builder(s), such as instantiating a new message builder associated with a new version (if the new version runs concurrently or simultaneously with the old version) and/or decommissioning the message builder associated with an old version (if the new version replaces or overwrites the old version), without incurring any downtime for the charging engine.
Builder manager 240 routes the incoming message 505 to the appropriate message builder 510 (such as an existing message builder or a newly-instantiated message builder), depending on the product, event, and version information. An incoming message received from a subscriber is routed to a request message builder (which is associated with a request specification that matches the product, event, and version information) and an incoming message received from a charging engine is routed to a response message builder (which is associated with a response specification that matches the product, event, and version information).
In response to detecting that a message has been received in the queue, payload object generation module 255 is configured to generate a payload object from the associated payload specification (i.e., the payload specification associated with the message builder 510). Payload object generation module 255 uses the associated payload specification as an object template to create a new object instance, or payload object 525. Payload object 525 includes a number of attributes relevant to one or more charging operations, as defined by the payload specification used to generate the payload object. Some of the attributes may be defined to have default attribute values, while other attributes may have empty or null values. For example, if request specification 310 (illustrated in
In one embodiment, payload object 525 also has a number of fixed attributes that are not defined in request specification 310, but are included in every payload object generated by payload object generation module 250. Examples of fixed attributes are userIdentity (the public user identity of the person or entity using the service product, such as a phone number, email address, and the like), requestID (an identifier that uniquely identifies the service product usage, is the same across different operation types, and is used to locate an active session associated with the subscriber), requestStart (the time at which service product usage started, used for Initiate operations for session-based requests), requestEnd (the time at which service product usage ended, which is the same as requestStart for event-based charging, indicating no duration), and sequenceNumber (the sequential session-centric attribute).
Payload object generation module 255 provides payload object 525 to payload attribute population module 260. Payload attribute population module 260 is configured to populate the payload attributes of the payload object with attribute values extracted from the incoming message, using mapping information defined by the administrator. An incoming message from a subscriber can include hundreds of attribute value pairs, or AVPs, that include information about a subscriber's usage and network-related information. However, a charging engine may only need to receive a subset of the hundreds of AVPs that are relevant to a particular charging operation, where the payload object includes the relevant attributes needed by the charging engine to perform the particular charging operation. The mapping information indicates which particular ones of the incoming message's AVPs 520 should be used to populate each payload attribute in accordance with the payload specification. In one embodiment, the mapping information is stored in a mapping table accessible by message builder 510. The mapping table includes a number of table entries, where each entry includes a name of an attribute compatible with the charging engine and a name of an associated attribute compatible with the gateway. Payload attribute population module 260 is configured to perform a lookup for the name of the relevant payload attribute (which is compatible with the charging engine) in the mapping table to find a corresponding entry that includes a name of an associated attribute (which is compatible with the gateway). Payload attribute population module 260 identifies the associated attribute in the incoming message (e.g., uses the associated attribute name to identify an AVP in the message that has a matching attribute name) and extracts the value of the associated attribute from the message (e.g., extracts the value from the AVP that has the matching attribute name).
For each extracted attribute value, payload attribute population module 260 is configured to determine whether the data type of the extracted attribute value matches the data type specified for the corresponding payload attribute, as defined by the payload specification. If the data types match, the payload attribute value pair is valid and the extracted attribute value is set as the payload attribute value in the payload object. If the data types do not match, the payload attribute value pair is invalid and the extracted attribute value is not set in the payload object (which leaves either an empty value or a default value for the payload attribute value).
Payload object 525 includes a payload set interface 530 that is configured to provide write access to the payload attributes in the payload object and a payload view interface 535 that is configured to provide read access to the payload attributes in the payload object. Payload attribute population module 260 is configured to use payload set interface 530 to set the extracted values of the incoming message attributes as the payload attribute values in payload object 525 (e.g., creates a new AVP in the payload object that includes the name of the payload attribute and the extracted value of the incoming message attribute), as defined by the mapping information. The resulting populated payload object 540 includes Payload_Att_A having Value X and Payload_Att_B having Value Y (with the default 0 value overwritten by Value Y).
Payload attribute population module 260 provides populated payload object 540 to payload build module 265, which invokes a build process. Payload build module 265 is configured to build an outgoing message that includes the payload object, where the payload attributes of the payload object are validated as the outgoing message is being built. Payload build module 265 is configured to validate whether all required payload attributes have been successfully (or validly) set in the payload. If any of the required payload attributes have not been successfully set (e.g., required payload attributes have an empty value, or the data type of an extracted message value does not match the data type of the required payload attribute), payload build module 265 determines that the payload object is invalid (and incomplete). Payload attributes that are optional and have an empty value will not result in an invalid payload object.
Payload build module 265 generates an error message when the payload object is determined to be invalid (e.g., the payload object includes a required payload attribute that is associated with an extracted value having a mismatched data type, and/or the payload object includes at least one required payload attribute that has an empty value). The error message indicates the problem (e.g., the information received from the subscriber is invalid or incomplete) and is provided to subscriber message transmitter 235 to be sent to the subscriber via gateway 120. The outgoing message and payload object are discarded, and the message builder goes on to process a next incoming message in the queue. The subscriber may send another service request (or subsequent incoming message) that remedies the error, which will be processed by the message builder instance in the order the incoming message was received. Error messages can be logged and displayed to the administrator. Since the payload object is discarded once payload build module 265 determines that the payload object is invalid (e.g., a payload attribute is not successfully set or that the payload object does not include all required payload attributes), payload build module will not allow the creation of any outgoing message that is in violation of the payload specification.
If all required payload attributes have been successfully set (e.g., all required payload attributes have a non-empty value that matches the data type indicated in the payload specification), the payload object is valid (and well-formed) and the outgoing message is forwarded to the destination. Since the incoming message is a service request message from a subscriber, the message builder instance is configured to generate an outgoing usage request message 550 destined for the charging engine, which is sent via charging engine message transmitter 270. At this point, payload set interface 530 is no longer available and the validated payload object 545 can no longer be modified by the mediation system (or client-side components of the charging system). The charging engine is configured to use payload view interface 540 to read the values of the relevant attributes in the payload object and perform the associated charging operation(s).
In one embodiment, the charging engine (or server-side components of the charging system) may be able to mutate the payload via a payload mutator. A service provider administrator can implement one or more customization plug-ins, or payload mutators that are configured to modify a payload object, depending on a set of business rules. Payload mutators are configured to mutate (e.g., change, overwrite) values of an existing payload before and after charging behavior has occurred. For example, a subscriber may initiate a cell phone call that falls under a particular charging plan associated with the product used by the subscriber and particular triggering event. The mediation system creates a payload corresponding to the cell phone call, which is sent to the charging engine for charging. However, if the cell phone call has a poor connection or has low quality, the business rules indicate that the charging engine (or component thereof) should change the call duration to zero to avoid charging the subscriber. To do so, the charging engine executes a payload mutator configured to change the existing call duration value of the payload to zero, even after the cell phone call is complete. In light of the present disclosure, it will be further appreciated that the payload can be re-associated with the payload specification to offer the full gamut of modifications that were available at the time the payload was originally created by the mediation client.
In response to detecting that a message has been received in the queue, payload object generation module 255 is configured to generate a payload object from the associated payload specification. In the example illustrated in
Payload attribute population module 260 is configured to populate the payload attributes of the payload object with values from AVPs 520 using payload set interface 530, as defined by the mapping information. The AVPs from the incoming message are compatible with the charging engine (e.g., have descriptive names). The mapping information indicates which particular ones of the incoming message attributes 520 should be used to populate each payload attribute in accordance with the payload specification. In one embodiment, payload attribute population module 260 is configured to perform a lookup for the name of the payload attribute (which is compatible with the gateway) in the mapping table to find a corresponding entry that includes a name of an associated attribute (which is compatible with the charging engine). Payload attribute population module 260 identifies the associated attribute in the incoming message, extracts the value of the associated attribute from the message, and sets the payload attribute in the payload object with the extracted value if the data types match. The resulting populated payload object 540 includes Payload_Att_L with Value R, Payload_Att_M with default value 5 (which was not overwritten with any values extracted from AVPs 520), and Payload_Att_N with empty value.
Payload build module 265 validates the attributes of the payload object and builds an outgoing message that includes the payload object. Since Payload_Att_N is an optional attribute, the empty value does not trigger an invalid error. If the required payload attributes have been successfully set, the payload object is valid and the outgoing message is forwarded to the destination. Since the incoming message is a usage response message from a charging engine, the message builder is configured to generate an outgoing service response message 550 destined for the subscriber, which is sent via subscriber message transmitter 235 to the gateway. At this point, payload set interface 530 is no longer available and the validated payload object 545 can no longer be modified by the mediation system (or client-side components of the charging system), but may be modified by the charging system (or server-side components of the charging system) using a payload mutator, as discussed above in connection with
The process continues to operation 715, where the builder manager determines whether there is an existing message builder associated with the identified event, product, and version information. If there is an existing message builder, the process continues to operation 720, where builder manager retrieves the message builder (e.g., calls or requests the message builder). The process continues to operation 725, where the builder manager routes the incoming message to the (existing) message builder for payload processing. The process then ends.
Returning to operation 715, if there is no existing message builder associated with the identified event, product, and version information, the process continues to operation 730, where the builder manager instantiates a new message builder. The process continues to operation 735, where the builder manager associates the message builder with a payload specification that matches the identified event, product, and version number. The instantiated message builder includes a payload specification retrieval module, which uses the event, product, and version number to search for and retrieve a payload specification from the payload specification repository, where the retrieved payload specification matches the identified event, product, and version number. The process continues to operation 725, where the builder manager routes the incoming message to the (new) message builder for payload processing. The process then ends.
The process continues to operation 815, where the message builder determines whether the message build operation is successful. If the build is successful, the process continues to operation 820, where message builder forwards the resulting outgoing message to the destination. The outgoing message may be transmitted to a subscriber via a gateway (e.g., is routed to and transmitted from subscriber message transmitter) or to a charging engine (e.g., is routed to and transmitted from charging engine message receiver). The process then ends.
Returning to operation 815, if the message and payload object build operation is not successful, the process continues to operation 825, where the message builder sends an error message to the subscriber. The process continues to operation 830, where the message builder discards the message and the payload object. The process then ends.
The process continues to operation 910, where payload attribute population module identifies a message attribute that is associated with payload attribute [i] of the payload object. The payload object includes a number of payload attributes, where the letter [i] acts as a counter that indicates a present payload attribute being processed (where i is initialized to one in operation 905). In one embodiment, payload attribute population module performs a lookup for the name of payload attribute [i] in a mapping table, where the lookup returns an associated attribute name. The process continues to operation 915, where payload attribute population module extracts the value of the associated message attribute from the incoming message. In one embodiment, payload attribute population module finds the associated attribute (which was returned from the mapping table in operation 910) in the incoming message (e.g., finds the AVP in the incoming message with an attribute name that matches the returned associated attribute name) and extracts the value from the incoming message.
The process continues to operation 920, where payload attribute population module determines whether the data type of the message attribute value matches the data type of the payload attribute [i] value. If the data types do not match, payload attribute population module does not set the payload attribute with the value having mismatched data type. At this point, the payload attribute population module is aware the payload object is invalid due to mismatched data type, and can override the remaining portion of the process illustrated in
Returning to operation 920, if the data types of the message attribute value and payload attribute [i] value match, the process continues to operation 925, where payload attribute population module sets the payload attribute [i] with the extracted value of the associated message attribute. The process continues to operation 930, where payload attribute population module determines whether there is another payload attribute to set in the payload object. If so, the process continues to operation 935, where [i] is incremented to indicate a next payload attribute is being processed, and the process returns to operation 910.
Returning to operation 930, if there are no other payload attributes to set in the payload object, the process continues to operation 940, where payload attribute population module invokes a message build process. The message build process is performed by payload build module, which builds an outgoing message and validates the payload object that is included in the outgoing message. Payload build module determines whether all required payload attributes are included in the payload object. A payload attribute that is not designated as an optional attribute is a required payload attribute. All required payload attributes need to be set with an appropriate value for the charging engine in order to avoid a run time charging error (e.g., in order to avoid empty values, an administrator can define default values for the required payload attributes in the payload definition text file). If at least one required payload attribute has an empty value, the payload object is determined to be invalid, and the payload build module generates an error message for the subscriber, indicating that the present error relates to missing required payload attributes. Optional attributes that have empty values do not trigger an error message. If all required payload attributes are included in the payload object, the payload object is determined to be valid. In both cases, the process then ends (and returns to
As shown above, the present invention can be implemented using a variety of computer systems and networks. An example of one such computing and network environment is described below with reference to
Bus 1012 allows data communication between central processor 1014 and system memory 1017, which may include read-only memory (ROM) or flash memory (neither shown), and random access memory (RAM) (not shown), as previously noted. The RAM is generally the main memory into which the operating system and application programs are loaded. The ROM or flash memory can contain, among other code, the Basic Input-Output system (BIOS) which controls basic hardware operation such as the interaction with peripheral components. Applications resident with computer system 1010 are generally stored on and accessed via a computer-readable medium, such as a hard disk drive (e.g., fixed disk 1044), an optical drive (e.g., optical drive 1040), a floppy disk unit 1037, or other storage medium. Additionally, applications can be in the form of electronic signals modulated in accordance with the application and data communication technology when accessed via network modem 1047 or interface 1048.
Storage interface 1034, as with the other storage interfaces of computer system 1010, can connect to a standard computer-readable medium for storage and/or retrieval of information, such as a fixed disk drive 1044. Fixed disk drive 1044 may be a part of computer system 1010 or may be separate and accessed through other interface systems. Modem 1047 may provide a direct connection to a remote server via a telephone link or to the Internet via an internet service provider (ISP). Network interface 1048 may provide a direct connection to a remote server via a direct network link to the Internet via a POP (point of presence). Network interface 1048 may provide such connection using wireless techniques, including digital cellular telephone connection, Cellular Digital Packet Data (CDPD) connection, digital satellite data connection or the like.
Many other devices or subsystems (not shown) may be connected in a similar manner (e.g., document scanners, digital cameras and so on). Conversely, all of the devices shown in
Moreover, regarding the signals described herein, those skilled in the art will recognize that a signal can be directly transmitted from a first block to a second block, or a signal can be modified (e.g., amplified, attenuated, delayed, latched, buffered, inverted, filtered, or otherwise modified) between the blocks. Although the signals of the above described embodiment are characterized as transmitted from one block to the next, other embodiments of the present invention may include modified signals in place of such directly transmitted signals as long as the informational and/or functional aspect of the signal is transmitted between blocks. To some extent, a signal input at a second block can be conceptualized as a second signal derived from a first signal output from a first block due to physical limitations of the circuitry involved (e.g., there will inevitably be some attenuation and delay). Therefore, as used herein, a second signal derived from a first signal includes the first signal or any modifications to the first signal, whether due to circuit limitations or due to passage through other circuit elements which do not change the informational and/or final functional aspect of the first signal.
With reference to computer system 1110, modem 1047, network interface 1048 or some other method can be used to provide connectivity from each of client computer systems 1110, 1120 and 1130 to network 1150. Client systems 1110, 1120 and 1130 are able to access information on storage server 1140A or 1140B using, for example, a web browser or other client software (not shown). Such a client allows client systems 1110, 1120 and 1130 to access data hosted by storage server 1140A or 1140B or one of storage devices 1160A(1)-(N), 1160B(1)-(N), 1180(1)-(N) or intelligent storage array 1190.
The present invention is well adapted to attain the advantages mentioned as well as others inherent therein. While the present invention has been depicted, described, and is defined by reference to particular embodiments of the invention, such references do not imply a limitation on the invention, and no such limitation is to be inferred. The invention is capable of considerable modification, alteration, and equivalents in form and function, as will occur to those ordinarily skilled in the pertinent arts. The depicted and described embodiments are examples only, and are not exhaustive of the scope of the invention.
The foregoing describes embodiments including components contained within other components (e.g., the various elements shown as components of computer system 1010). Such architectures are merely examples, and, in fact, many other architectures can be implemented which achieve the same functionality. In an abstract but still definite sense, any arrangement of components to achieve the same functionality is effectively “associated” such that the desired functionality is achieved. Hence, any two components herein combined to achieve a particular functionality can be seen as “associated with” each other such that the desired functionality is achieved, irrespective of architectures or intermediate components. Likewise, any two components so associated can also be viewed as being “operably connected,” or “operably coupled,” to each other to achieve the desired functionality.
The foregoing detailed description has set forth various embodiments of the present invention via the use of block diagrams, flowcharts, and examples. It will be understood by those within the art that each block diagram component, flowchart step, operation and/or component illustrated by the use of examples can be implemented, individually and/or collectively, by a wide range of hardware, software, firmware, or any combination thereof, including the specialized system illustrated in
The present invention has been described in the context of fully functional computer systems; however, those skilled in the art will appreciate that the present invention is capable of being distributed as a program product in a variety of forms, and that the present invention applies equally regardless of the particular type of computer-readable media used to actually carry out the distribution. Examples of computer-readable media include computer-readable storage media, as well as media storage and distribution systems developed in the future.
The above-discussed embodiments can be implemented by software modules that perform one or more tasks associated with the embodiments. The software modules discussed herein may include script, batch, or other executable files. The software modules may be stored on a machine-readable or computer-readable storage media such as magnetic floppy disks, hard disks, semiconductor memory (e.g., RAM, ROM, and flash-type media), optical discs (e.g., CD-ROMs, CD-Rs, and DVDs), or other types of memory modules. A storage device used for storing firmware or hardware modules in accordance with an embodiment of the invention can also include a semiconductor-based memory, which may be permanently, removably or remotely coupled to a microprocessor/memory system. Thus, the modules can be stored within a computer system memory to configure the computer system to perform the functions of the module. Other new and various types of computer-readable storage media may be used to store the modules discussed herein.
The above description is intended to be illustrative of the invention and should not be taken to be limiting. Other embodiments within the scope of the present invention are possible. Those skilled in the art will readily implement the steps necessary to provide the structures and the methods disclosed herein, and will understand that the process parameters and sequence of steps are given by way of example only and can be varied to achieve the desired structure as well as modifications that are within the scope of the invention. Variations and modifications of the embodiments disclosed herein can be made based on the description set forth herein, without departing from the scope of the invention.
Consequently, the invention is intended to be limited only by the scope of the appended claims, giving full cognizance to equivalents in all respects.
The present patent application claims priority to Provisional Patent Application Ser. No. 61/908,588, filed Nov. 25, 2013, and entitled “Adaptive Data Model for Charging Requests,” which is hereby incorporated by reference herein, in its entirety and for all purposes.
| Number | Date | Country | |
|---|---|---|---|
| 61908588 | Nov 2013 | US |
