CUSTOMIZED DIAMETER PERFORMANCE METRICS

Abstract

Various exemplary embodiments relate to a method performed by a Diameter node, the method including: receiving a Diameter message at the Diameter node; evaluating a custom metric rule to identify a metric to be collected; and collecting the metric related to the received Diameter message based upon the evaluation of the custom metric rule.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is related to the following co-pending applications, which are hereby incorporated by reference for all purposes as if fully set forth herein: application Ser. No. 13/482,690, filed on May 29, 2012, “ORGANIZATION OF DIAMETER ROUTING AGENT RULE SETS;” application Ser. No. 13/482,587, filed on May 29, 2012, “ROUTING DECISION CONTEXT OBJECTS;” application Ser. No. 13/602,579, filed on Sep. 4, 2012, “RULE ENGINE EVALUATION OF CONTEXT OBJECTS;” and application Ser. No. 13/962,071, filed on Aug. 8, 2013, Attorney Docket No. ALC 3895, “GENERIC PERSISTENCE IN A DIAMETER ROUTING AGENT.”

TECHNICAL FIELD

Various exemplary embodiments disclosed herein relate generally to communication networks.

BACKGROUND

Since its proposal in Internet Engineering Task Force (IETF) Request for Comments (RFC) 3588, the Diameter protocol has been increasingly adopted by numerous networked applications. For example, the Third Generation Partnership Project (3GPP) has adopted Diameter for various policy and charging control (PCC), mobility management, and IP multimedia subsystem (IMS) applications. As IP-based networks replace circuit-switched networks, Diameter is even replacing SS7 as the key communications signaling protocol. As networks evolve, Diameter is becoming a widely used protocol among wireless and wireline communications networks.

3GPP networks may include various types of Diameter nodes, e.g., policy and charging rules nodes (PCRNs), Diameter routing agents (DRAs), etc. Such Diameter nodes may include a metrics sub-component used to measure various aspects of performance within the products. The metrics may give the network operator a view of what the system is doing. For example, the metrics sub-component counts events processed, including Diameter requests and LDAP requests, recording the average latency and throughput. Any system overload events may also be recorded as metrics. CPU, memory, network and disk utilization may all be recorded as metrics.

SUMMARY

A brief summary of various exemplary embodiments is presented below. Some simplifications and omissions may be made in the following summary, which is intended to highlight and introduce some aspects of the various exemplary embodiments, but not to limit the scope of the invention. Detailed descriptions of a preferred exemplary embodiment adequate to allow those of ordinary skill in the art to make and use the inventive concepts will follow in later sections.

Various exemplary embodiments relate to a method performed by a Diameter node, the method including: receiving a Diameter message at the Diameter node; evaluating a custom metric rule to identify a metric to be collected; and collecting the metric related to the received Diameter message based upon the evaluation of the custom metric rule.

Various exemplary embodiments relate to a Diameter node (DN) for processing a Diameter message, the DN including: a rule storage configured to store a custom metrics rule that defines a custom metrics scenario; a Diameter stack configured to receive a Diameter message from another Diameter node; a rule engine configured to evaluate the custom metric rule to identify a metric to be collected; and a metrics collector configured to collect the metric related to the received Diameter message based upon the evaluation of the custom metric rule.

Various exemplary embodiments relate to a non-transitory machine-readable storage medium encoded with instructions for execution by a Diameter node (DN) for processing a Diameter message, the medium including: instructions for receiving a Diameter message at the Diameter node; instructions for evaluating a custom metric rule to identify a metric to be collected; and instructions for collecting the metric related to the received Diameter message based upon the evaluation of the custom metric rule.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to better understand various exemplary embodiments, reference is made to the accompanying drawings, wherein:

FIG. 1 illustrates an exemplary network environment including Diameter nodes;

FIG. 2 illustrates an exemplary Diameter node;

FIG. 3 illustrates an exemplary hardware diagram of a Diameter node;

FIG. 4 illustrates an embodiment of a custom metric rule;

FIG. 5 illustrates an embodiment of a method of applying custom metrics rules.

To facilitate understanding, identical reference numerals have been used to designate elements having substantially the same or similar structure or substantially the same or similar function.

DETAILED DESCRIPTION

The description and drawings merely illustrate the principles of the invention. It will thus be appreciated that those skilled in the art will be able to devise various arrangements that, although not explicitly described or shown herein, embody the principles of the invention and are included within its scope. Furthermore, all examples recited herein are principally intended expressly to be only for pedagogical purposes to aid the reader in understanding the principles of the invention and the concepts contributed by the inventor(s) to furthering the art, and are to be construed as being without limitation to such specifically recited examples and conditions. Additionally, the term, “or,” as used herein, refers to a non-exclusive or (i.e., and/or), unless otherwise indicated (e.g., “or else” or “or in the alternative”). Also, the various embodiments described herein are not necessarily mutually exclusive, as some embodiments can be combined with one or more other embodiments to form new embodiments. As used herein, the terms “context” and “context object” will be understood to be synonymous, unless otherwise indicated.

A Diameter node may include a metrics sub-component that records metrics for numerous predetermined scenarios, however, the possible scenarios that could be of interest is virtually limitless. It is impractical (if not impossible) to hard-code/predetermine every single scenario to record metrics for. It is also impractical to continue selecting a subset of scenarios to support, as different network operators will have different needs regarding metrics collection. Accordingly there remains a need for customizing the metrics recorded on a network operator site to reflect the uniqueness of each network operator deployment. Described below is a method and a system that allows a network operator to collect custom metrics. This method and system may take advantage of a rule engine implemented in the Diameter node. Such rule engine may have other uses as well, for example, evaluating policy decisions and implementing policy rules, providing Diameter routing using a DRA, etc. Because such a rule engine may already be present in Diameter nodes, it may be leveraged to provide a solution to providing custom metric collection in the Diameter nodes as specified by a network operator or user.

FIG. 1 illustrates an exemplary network environment including Diameter nodes. Exemplary network environment 100 may be a subscriber network for providing various services. In various embodiments, subscriber network 100 may be a public land mobile network (PLMN). Exemplary subscriber network 100 may be telecommunications network or other network for providing access to various services. Exemplary subscriber network 100 may include user equipment 110, base station 120, evolved packet core (EPC) 130, packet data network 150, and application function (AF) 160.

User equipment 110 may be a device that communicates with packet data network 150 for providing the end-user with a data service. Such data service may include, for example, voice communication, text messaging, multimedia streaming, and Internet access. More specifically, in various exemplary embodiments, user equipment 110 is a personal or laptop computer, wireless email device, cell phone, tablet, television set-top box, or any other device capable of communicating with other devices via EPC 130.

Base station 120 may be a device that enables communication between user equipment 110 and EPC 130. For example, base station 120 may be a base transceiver station such as an evolved nodeB (eNodeB) as defined by the relevant 3GPP standards. Thus, base station 120 may be a device that communicates with user equipment 110 via a first medium, such as radio waves, and communicates with EPC 130 via a second medium, such as Ethernet cable. Base station 120 may be in direct communication with EPC 130 or may communicate via a number of intermediate nodes (not shown). In various embodiments, multiple base stations (not shown) may be present to provide mobility to user equipment 110. Note that in various alternative embodiments, user equipment 110 may communicate directly with EPC 130. In such embodiments, base station 120 may not be present.

Evolved packet core (EPC) 130 may be a device or network of devices that provides user equipment 110 with gateway access to packet data network 140. EPC 130 may further charge a subscriber for use of provided data services and ensure that particular quality of experience (QoE) standards are met. Thus, EPC 130 may be implemented, at least in part, according to the relevant 3GPP standards. EPC 130 may include a serving gateway (SGW) 132, a packet data network gateway (PGW) 134, and a session control device 140.

Serving gateway (SGW) 132 may be a device that provides gateway access to the EPC 130. SGW 132 may be one of the first devices within the EPC 130 that receives packets sent by user equipment 110. Various embodiments may also include a mobility management entity (MME) (not shown) that receives packets prior to SGW 132. SGW 132 may forward such packets toward PGW 134. SGW 132 may perform a number of functions such as, for example, managing mobility of user equipment 110 between multiple base stations (not shown) and enforcing particular quality of service (QoS) characteristics for each flow being served. In various implementations, such as those implementing the Proxy Mobile IP standard, SGW 132 may include a Bearer Binding and Event Reporting Function (BBERF). In various exemplary embodiments, EPC 130 may include multiple SGWs (not shown) and each SGW may communicate with multiple base stations (not shown).

Packet data network gateway (PGW) 134 may be a device that provides gateway access to packet data network 140. PGW 134 may be the final device within the EPC 130 that receives packets sent by user equipment 110 toward packet data network 140 via SGW 132. PGW 134 may include a policy and charging enforcement function (PCEF) that enforces policy and charging control (PCC) rules for each service data flow (SDF). Therefore, PGW 134 may be a policy and charging enforcement node (PCEN). PGW 134 may include a number of additional features such as, for example, packet filtering, deep packet inspection, and subscriber charging support. PGW 134 may also be responsible for requesting resource allocation for unknown application services.

Session control device 140 may be a device that provides various management or other functions within the EPC 130. For example, session control device 140 may provide a Policy and Charging Rules Function (PCRF). In various embodiments, session control device 140 may include an Alcatel Lucent 5780 Dynamic Services Controller (DSC). Session control device 140 may include a DRA 142, a plurality of policy and charging rules blades (PCRBs) 144, 146, and a subscriber profile repository. The DRA 142 and PCRBs 144, 146 are Diameter nodes.

As will be described in greater detail below, DRA 142 may be an intelligent Diameter Routing Agent. As such, DRA 142 may receive, process, and transmit various Diameter messages. DRA 142 may include a number of user-defined rules that govern the behavior of DRA 142 with regard to the various Diameter messages DRA 142 may encounter. Based on such rules, the DRA 142 may operate as a relay agent, proxy agent, or redirect agent. For example, DRA 142 may relay received messages to an appropriate recipient device. Such routing may be performed with respect to incoming and outgoing messages, as well as messages that are internal to the session control device.

Policy and charging rules blades (PCRB) 144, 146 may each be a device or group of devices that receives requests for application services, generates PCC rules, and provides PCC rules to the PGW 134 or other PCENs (not shown). PCRBs 144, 146 may be in communication with AF 160 via an Rx interface. As described in further detail below with respect to AF 160, PCRB 144, 146 may receive an application request in the form of an Authentication and Authorization Request (AAR) from AF 160. Upon receipt of an AAR, PCRB 144, 146 may generate at least one new PCC rule for fulfilling the application request.

PCRB 144, 146 may also be in communication with SGW 132 and PGW 134 via a Gxx and a Gx interface, respectively. PCRB 144, 146 may receive an application request in the form of a credit control request (CCR) from SGW 132 or PGW 134. As with an AAR, upon receipt of a CCR, PCRB 144, 146 may generate at least one new PCC rule for fulfilling the application request. In various embodiments, the AAR and the CCR may represent two independent application requests to be processed separately, while in other embodiments, the AAR and the CCR may carry information regarding a single application request and PCRB 144, 146 may create at least one PCC rule based on the combination of the AAR and the CCR. In various embodiments, PCRB 144, 146 may be capable of handling both single-message and paired-message application requests.

Upon creating a new PCC rule or upon request by the PGW 134, PCRB 144, 146 may provide a PCC rule to PGW 134 via the Gx interface. In various embodiments, such as those implementing the proxy mobile IP (PMIP) standard for example, PCRB 144, 146 may also generate QoS rules. Upon creating a new QoS rule or upon request by the SGW 132, PCRB 144, 146 may provide a QoS rule to SGW 132 via the Gxx interface.

Subscriber profile repository (SPR) 148 may be a device that stores information related to subscribers to the subscriber network 100. Thus, SPR 148 may include a machine-readable storage medium such as read-only memory (ROM), random-access memory (RAM), magnetic disk storage media, optical storage media, flash-memory devices, and/or similar storage media. SPR 148 may be a component of one of PCRB 144, 146 or may constitute an independent node within EPC 130 or session control device 140. Data stored by SPR 148 may include subscriber information such as identifiers for each subscriber, bandwidth limits, charging parameters, and subscriber priority.

Packet data network 150 may be any network for providing data communications between user equipment 110 and other devices connected to packet data network 150, such as AF 160. Packet data network 150 may further provide, for example, phone or Internet service to various user devices in communication with packet data network 150.

Application function (AF) 160 may be a device that provides a known application service to user equipment 110. Thus, AF 160 may be a server or other device that provides, for example, a video streaming or voice communication service to user equipment 110. AF 160 may further be in communication with the PCRB 144, 146 of the EPC 130 via an Rx interface. When AF 160 is to begin providing known application service to user equipment 110, AF 160 may generate an application request message, such as an authentication and authorization request (AAR) according to the Diameter protocol, to notify the PCRB 144, 146 that resources should be allocated for the application service. This application request message may include information such as an identification of the subscriber using the application service, an IP address of the subscriber, an APN for an associated IP-CAN session, or an identification of the particular service data flows that must be established in order to provide the requested service.

As will be understood, various Diameter applications may be established within subscriber network 100 and supported by DRA 142. For example, an Rx application may be established between AF 160 and each of PCRBs 144, 146. As another example, an Sp application may be established between SPR 148 and each of PCRBs 144, 146. As yet another example, an S9 application may be established between one or more of PCRBs 144, 146 and a remote device implementing another PCRF (not shown). As will be understood, numerous other Diameter applications may be established within subscriber network 100.

In supporting the various potential Diameter applications, DRA 142 may receive Diameter messages, process the messages, and perform actions based on the processing. For example, DRA 142 may receive a Gx CCR from PGW 134, identify an appropriate PCRB 144, 146 to process the Gx CCR, and forward the Gx CCR to the identified PCRB 144, 146. DRA 142 may also act as a proxy by modifying the subsequent Gx CCA sent by the PCRB 144, 146 to carry an origin-host identification pointing to the DRA 142 instead of the PCRB 144, 146. Additionally or alternatively, DRA 142 may act as a redirect agent or otherwise respond directly to a request message by forming an appropriate answer message and transmitting the answer message to an appropriate requesting device.

A Diameter node may include a metrics sub-component that records metrics for numerous predetermined scenarios, however, the possible scenarios that could be of interest is virtually limitless. It is impractical (if not impossible) to hard-code/predetermine every single scenario to record metrics for. It is also impractical to continue selecting a subset of scenarios to support, as different network operators will have different needs regarding metrics collection. The metric to be collected may include, for example, message source, message destination, application, message type, command, result code, message counts, processor throughput and latency, message latency, etc.

Current Diameter nodes, e.g., DRA, PCRN, etc., may include a metrics sub-component used for measuring various aspects of performance within the Diameter nodes. The metrics may provide the network operator a view of what the system is doing. For example, the metrics sub-component may count events processed, including Diameter requests and LDAP requests, recording the average latency and throughout. Any system overload events may also be recorded as metrics. Further, CPU, memory, network and disk utilization may all be recorded as metrics.

Each metric scenario may be identified by a set of conditions describing the scenario for which the metric has been recorded and a collection of name-value pairs identifying the metrics to collect. For example a metric scenario for a particular Diameter message type might include {Application=Gx, Command=CCR, Request type=Initial, Origin Host=MyOriginHost, Origin Realm=MyOriginRealm}. As a result, counts, latencies, throughput, etc., may be recorded against very specific scenarios including various conditions, in this case against the message type and where the message originated from.

Previously, metric scenarios and metric attributes were hard-coded. The hard-coded set of metric attributes may now be extended by adding additional name-value pairs to the metric to be recorded in a specific metric scenario. Further, additional metric scenarios and their associated metrics may also be defined for collecting metrics in the Diameter nodes.

The metrics sub-component may provide an application programming interface (API) for registering one or more metric attribute name-value pairs against the event currently being processed. Once the event has been processed to completion, the metrics sub-component may record the metrics taking into account any custom metric attributes that were registered for that event during processing. As a result, more granular metrics may be recorded that may provide more insight to what is occurring in the system.

The Diameter nodes may include a rule engine that may be used to record customized metrics. While the embodiments described herein use a rule engine that may process other types of rules (e.g., policy rules, routing rules, overload rules, etc.) in the Diameter node, a metrics specific rule engine may also be used separate from the rule engines found in the Diameter nodes for processing other types of rules.

Below examples of custom metrics are described.

On a DRA, the primary job of the node is to route Diameter messages to the correct destination. The algorithm for determining the destination for the Diameter message may be written in the form of routing rules in the rule engine. The routing decision may be made by interrogating the content of the Diameter message alone, or the rules may have to retrieve more information from some other source (e.g., transient storage, persistent storage, external client). The rules author may choose to add additional conditions to assign a unique scenario metric attribute (name-value pair) to each scenario. For example, a custom scenario metric attribute {“Routing”, “Message Only”} may be used when the routing decision is to be made by looking at the Diameter message only, and another custom scenario metric attribute {“Routing”, “Transient”} may be used when the routing decision must refer to some transient information.

On a PCRN, predefined metrics scenarios may specify the recording of count, latency, throughput per application (e.g., Gx), command (e.g., CCR), and per a few other predetermined characteristics. Such predefined metrics are not very granular when considering the breadth of functionality in the PCRN. A key feature in the PCRN is metering which may enable the network operator to monitor a subscriber's data usage and modify the subscriber's level of service based on that usage. Accordingly, the network operator may manage their subscriber base and its level of service via rules in the PCRN rule engine. As in the previous example, the rules author may write custom metric rules to assign custom metric attributes to coincide with other actions related to metering scenarios. For example, this may be an effective way for a network operator to determine how often their subscriber base crosses certain usage thresholds.

In another example, by default, metrics collection may make no distinction between local and roaming subscribers. If desired, the network operator may further refine the recording of metrics between local and roaming subscribers or some other subscriber category. For example, custom metric rules may define a scenario where usage and other custom metric data for roaming users is collected. In addition, custom metric rules may define a scenario to collect similar custom metric data for local subscribers, but the data collected may be different depending upon the needs of the network operator.

In another example, a Diameter node may include support for an external subscriber repository (SPR). The Diameter node may use an SPR sub-component to interact with the external SPR. The SPR sub-component may use plugins to support a particular network operators external SPR. The plugin may include software supplied by the supplier of the SPR to provide interaction with the SPR. Such plugins may be customized for the specific component associated with the plugin. There may be scenarios within the plugin that are of interest from a metrics perspective. Accordingly, custom metric rules may be used to define scenarios where unique metric data may be collected relating to the operation and interaction with the SPR. One example of a metric to measure with the SPR is cache hits. Data from the SPR may be cached in the PCRN so that requests to the SPR for the data, which take longer, are not needed. Accordingly, a metric may be collected indicating whether SPR data was obtained from a local cache or from a request to the SPR. Such data may help to understand the latencies involved in accessing SPR data.

FIG. 2 illustrates an exemplary Diameter node (DN) 200. DN 200 may be a standalone device or a component of another system. For example, DN 200 may correspond to DRA 142 or the PCRBs 144, 146 that act as a PCRN of exemplary environment 100. In such an embodiment, DN 142 may support various Diameter applications defined by the 3GPP such as, for example, Gx, Gxx, Rx, or Sp. It will be understood that DN 200 may be deployed in various alternative embodiments wherein additional or alternative applications are supported. As such, it will be apparent that the methods and systems described herein may be generally applicable to supporting any Diameter applications and messages of other protocols such as RADIUS, SS7 or HTTP/XML, among others.

DN 200 may include a number of components such as Diameter stack 205, message handler 210, rule engine 215, rule storage 220, user interface 225, metrics collector 230, and metrics storage 235.

Diameter stack 205 may include hardware or executable instructions on a machine-readable storage medium configured to exchange messages with other devices according to the Diameter protocol. Diameter stack 205 may include an interface including hardware or executable instructions encoded on a machine-readable storage medium configured to communicate with other devices. For example, Diameter stack 205 may include an Ethernet or TCP/IP interface. In various embodiments, Diameter stack 205 may include multiple physical ports.

Diameter stack 205 may also be configured to read and construct messages according to the Diameter protocol. For example, Diameter stack may be configured to read and construct CCR, CCA, AAR, AAA, RAR, and RAA messages. Diameter stack 205 may provide an application programmer's interface (API) such that other components of DRA 200 may invoke functionality of Diameter stack. For example, rule engine 215 may be able to utilize the API to read an attribute-value pair (AVP) from a received CCR or to modify an AVP of a new CCA. Various additional functionalities will be apparent from the following description.

Message handler 210 may include hardware or executable instructions on a machine-readable storage medium configured to interpret received messages and invoke rule engine 215 as appropriate. In various embodiments, message handler 210 may extract a message type from a message received by Diameter stack 205 and invoke the rule engine 215 using a rule set that is appropriate for the extracted message type. For example, the message type may be defined by the application and command of the received message. After evaluating one or more rules, rule engine 215 may pass back an action to be taken or a message to be sent. Message handler 210 may then transmit one or more messages via Diameter stack 205, as indicated by the rule engine 215.

Rule engine 215 may include hardware or executable instructions on a machine-readable storage medium configured to process a received message by evaluating one or more rules stored in rule storage 220. As such, rule engine 215 may be a type of processing engine. Rule engine 215 may retrieve one or more rules, evaluate criteria of the rules to determine whether the rules are applicable, and specify one or more result of any applicable rules. The rules evaluated by the rule engine 215 may be one of various types of rules, for example, policy rules, shedding rules, routing rules, context routing rules, or custom metrics rules. The custom metrics rules will be further described in more detail below.

Rule storage 220 may be any machine-readable medium capable of storing one or more rules for evaluation by rule engine 215. Custom metrics rules may be stored in the rule storage. Accordingly, rule storage 220 may include a machine-readable storage medium such as read-only memory (ROM), random-access memory (RAM), magnetic disk storage media, optical storage media, flash-memory devices, and/or similar storage media. In various embodiments, rule storage 220 may store one or more rule sets as a binary decision tree data structure. Various other data structures for storing a rule set will be apparent.

User interface 225 may include hardware or executable instructions on a machine-readable storage medium configured to enable communication with a user. As such, user interface 225 may include a network interface (such as a network interface included in Diameter stack 205), a monitor, a keyboard, a mouse, or a touch-sensitive display. User interface 225 may also provide a graphical user interface (GUI) for facilitating user interaction. User interface 225 may enable a user to customize the behavior of DN 200. For example, user interface 225 may enable a user to define custom metrics rules for storage in rule storage 220 and evaluation by rule engine 215. The user may also define other sorts of rules for use by the rule engine 215 as well. Various additional methods for a user to customize the behavior of DN 200 via user interface 225 will be apparent to those of skill in the art.

Metrics collector 230 may include hardware or executable instructions on a machine-readable storage medium configured to collect metrics data in the metrics storage 235. The metrics collector 230 may include a predefined set of metrics scenarios and metrics to collect for those scenarios. Based upon custom metrics rules evaluated by the rule engine, the metrics collector 230 may extend existing predefined metrics scenarios or even create additional metrics scenarios. The metrics collector 230 communicates with the message handler 210 and the diameter stack 205 in order to collect the desired metrics data. As the metrics data is collected, it may be stored in the metrics storage for further processing or access by the network operator. The metrics collector 230 may be or include the metrics sub-component described above.

Metrics storage 235 may be any machine-readable medium capable of storing metrics data collected by the metrics collector 230. Accordingly, metrics storage 235 may include a machine-readable storage medium such as read-only memory (ROM), random-access memory (RAM), magnetic disk storage media, optical storage media, flash-memory devices, and/or similar storage media. In various embodiments, metrics storage 235 may store metrics data sets using various data structures as will be apparent. Further, the metrics storage 235 may be part of the rules storage 220 or any other available storage device on the DN 200.

Upon DN 200 receiving a Diameter message to be processed, message handler 210 may pass information regarding the Diameter message to the rule engine 215. The rule engine 215 may determine if the message fits within any custom metrics scenarios as defined by custom metrics rules. If so, rule engine 215 may invoke the metrics collector to collect and store the metrics data specified by the custom metrics scenarios. It is possible that a single received Diameter message may fit within more than one scenario based upon scenarios defined by the custom metrics rules. Accordingly, the rule engine 215 may direct the metrics collector 230 to collect and store data for these multiple scenarios in the metrics storage 235.

The network operator may use the user interface 235 to access the metrics storage 235 to view various metrics data. The user interface 225 may include a display to select and view metrics data. Further, the user interface 225 may allow a network operator to use search queries to search for specific metrics data. Such ability to view and search the metrics data allows the network operator to determine the overall system performance and health. It might also provide information regarding performance problems or errors in system operation.

A network operator may use the user interface 225 to create custom metrics rules. Such rules may extend existing predefined metrics scenarios. In such a case the existing predefined metrics scenarios may be presented to the network operator using the user interface 225, and the network operator may select additional AVPs to be collected in the metrics scenario. Additionally, the network operator may add additional conditions to define the metrics scenario. Also, the predefined scenario may serve as a template to create a new custom metrics scenario.

In addition, the network operator may define completely new custom metrics scenarios. Such scenarios may include the various conditions that define when the custom metrics scenario is present. In addition, the specific AVPs may be defined to determine the specific metrics data to be collected and stored.

The custom metrics rules may be implemented using a pseudo-code representation of the rule. Such an implementation provides a network operator great flexibility in defining rules to meet various requirements and conditions. These custom metrics rules may use the information described above to evaluate whether the receipt of a Diameter message requires the collection of metrics data. The custom metrics rules may be as simple or complex as needed in order to satisfy the specific needs of the network operator.

In an alternative embodiment, the metrics collector 230 may evaluate the custom metrics rules instead of the rule engine 220. Upon DN 200 receiving a Diameter message to be processed, message handler 210 may pass information regarding the Diameter message to the metrics collector 230. The metrics collector 230 may determine if the message fits within any custom metrics scenarios as defined by custom metrics rules. If so, the metrics collector stores the metrics data specified by the custom metrics scenarios. It is possible that a single received Diameter message may fit within more than one scenario. Accordingly, the metrics collector 230 may collect and store data for these multiple scenarios in the metrics storage 235.

FIG. 3 illustrates an exemplary hardware diagram of a Diameter node 300. The exemplary DN 300 may correspond to the DN 200 of FIG. 2 or to DRA 142 or the PCRBs 144, 146 that act as a PCRN of exemplary environment 100 of FIG. 1. As shown, the hardware device 300 may include a processor 310, memory 320, user interface 330, network interface 340, and storage 350 interconnected via one or more system buses 360. It will be understood that FIG. 3 constitutes, in some respects, an abstraction and that the actual organization of the components of the DRA 300 may be more complex than illustrated.

The processor 310 may be any hardware device capable of executing instructions stored in memory 320 or storage 350. As such, the processor may include a microprocessor, field programmable gate array (FPGA), application-specific integrated circuit (ASIC), or other similar devices.

The memory 320 may include various memories such as, for example L1, L2, or L3 cache or system memory. As such, the memory 320 may include static random access memory (SRAM), dynamic RAM (DRAM), flash memory, read only memory (ROM), or other similar memory devices.

The user interface 330 may include one or more devices for enabling communication with a user such as an administrator. For example, the user interface 330 may include a display, a mouse, and a keyboard for receiving user commands.

The network interface 340 may include one or more devices for enabling communication with other hardware devices. For example, the network interface 340 may include a network interface card (NIC) configured to communicate according to the Ethernet protocol. Additionally, the network interface 340 may implement a TCP/IP stack for communication according to the TCP/IP protocols. Various alternative or additional hardware or configurations for the network interface 340 will be apparent.

The storage 350 may include one or more machine-readable storage media such as read-only memory (ROM), random-access memory (RAM), magnetic disk storage media, optical storage media, flash-memory devices, or similar storage media. In various embodiments, the storage 350 may store instructions for execution by the processor 310 or data upon with the processor 310 may operate. For example, the storage 350 may store rule engine instructions 352 and rules 354 read and acted upon by the rule engine. The storage 350 may also store custom metrics rules 356 for use in defining the custom metrics to be collected. It will be apparent that various information described as stored in the storage 350 may be additionally or alternatively stored in the memory 320. For example, the custom metrics rules 356 may be additionally, alternatively, or partially stored in memory 320. Various other arrangements will be apparent.

FIG. 4 illustrates an embodiment of a custom metrics rule. In the example rule, the network operator is interested in recording metrics for any messages requesting greater than 10 Mbps of download bandwidth. That interest is further scoped by differentiating between IMSI type subscribers versus all other subscriber types. In this case, the network operator does not care about whether the request type is an initial request or an update, so for simplicity, the ‘Request Type’ metric attribute is removed. The custom metrics rule in FIG. 4 may first determine if the message is requesting a download bandwidth greater than 10 Mbps and if the subscriber is an IMSI type subscriber. If so, two metric attributes are added: Name=Subscription ID Type and Value=1; and Name=QoS Range and Value=+10 Mbps range. In addition the Request Type metric is removed. If the first condition is not met, the rule then determines if the message is requesting a download bandwidth greater than 10 Mbps. If so, one metric attribute is added: Name=QoS Range and Value=+10 Mbps range. In addition the Request Type metric is removed.

As shown in the above examples, custom metrics rules may be defined to allow for the custom collection of metrics data at Diameter nodes. The custom metrics rules may define a scenario, i.e., a definition of conditions where certain metrics should be collected. Such scenarios may be defined by the type of message received, the sender of the message, subscriber information, etc. Further, a specific set of metrics, e.g., AVPs, to be collected may be defined for the scenario. Further, the custom metrics may be defined as modifying existing predefined metrics scenarios or as completely new scenarios.

FIG. 5 illustrates an embodiment of a method of applying custom metrics rules. The method 500 may be performed by a DN. Within the DN the Rule Engine 215, message handler 210, Diameter stack 205, user interface, 225, and/or metrics collector 230 may perform some of the steps in method 500. The method 500 may begin 505 and then may receive user input regarding custom metrics rules 510. The user may include the complete definition of custom metrics rules and the information used in those rules. Also, a set of predefined custom metrics rule templates may be presented to the user, and the user may select a predefined rule template and provide information to be used to fully define the rule. Also, the user may select an existing predefined custom metrics scenario and create a custom metrics rule to modify the existing predefined custom metrics scenario.

Next, based upon the user input, the method creates the custom metrics rule 515. The DN then may receive a Diameter message 520. Next, the DN may apply the custom metrics rule to the received diameter message 525. The DN may then collect the custom metrics based upon the custom metrics rule 530. Then the method may end at 545.

It should be apparent from the foregoing description that various exemplary embodiments of the invention may be implemented in hardware or firmware. Furthermore, various exemplary embodiments may be implemented as instructions stored on a machine-readable storage medium, which may be read and executed by at least one processor to perform the operations described in detail herein. A machine-readable storage medium may include any mechanism for storing information in a form readable by a machine, such as a personal or laptop computer, a server, or other computing device. Thus, a tangible and non-transitory machine-readable storage medium may include read-only memory (ROM), random-access memory (RAM), magnetic disk storage media, optical storage media, flash-memory devices, and similar storage media.

It should be appreciated by those skilled in the art that any block diagrams herein represent conceptual views of illustrative circuitry embodying the principles of the invention. Similarly, it will be appreciated that any flow charts, flow diagrams, state transition diagrams, pseudo code, and the like represent various processes which may be substantially represented in machine readable media and so executed by a computer or processor, whether or not such computer or processor is explicitly shown.

Although the various exemplary embodiments have been described in detail with particular reference to certain exemplary aspects thereof, it should be understood that the invention is capable of other embodiments and its details are capable of modifications in various obvious respects. As is readily apparent to those skilled in the art, variations and modifications can be effected while remaining within the spirit and scope of the invention. Accordingly, the foregoing disclosure, description, and figures are for illustrative purposes only and do not in any way limit the invention, which is defined only by the claims.

Claims

1. A method performed by a Diameter node, the method comprising:

receiving a Diameter message at the Diameter node;

evaluating a custom metric rule to identify a metric to be collected; and

collecting the metric related to the received Diameter message based upon the evaluation of the custom metric rule.

2. The method of claim 1, wherein the Diameter node is a diameter routing agent (DRA).

3. The method of claim 1, wherein the Diameter node is a policy and charging rules node (PCRN).

4. The method of claim 1, further comprising, receiving, via a user interface, a definition of the custom metric rule, wherein the definition specifies the metric and a condition when the metric is to be collected.

5. The method of claim 4, further comprising,

receiving a plurality of Diameter messages at the Diameter node;

collecting a plurality of values of the specified metric from a set of Diameter messages in the plurality of Diameter messages that meet the specified condition; and

transmitting via a user interface the collected plurality of values.

6. The method of claim 4, further comprising,

interfacing with an external node using a custom plugin; and

wherein,

the Diameter message is received from the external node,

the custom metric rule is related to Diameter messages from the external node, and

the collected metric relates to the received Diameter message from the external node.

7. The method of claim 4, wherein the definition of the custom metric rule modifies a preexisting custom metrics scenario.

8. A Diameter node (DN) for processing a Diameter message, the DN comprising:

a rule storage configured to store a custom metrics rule that defines a custom metrics scenario;

a Diameter stack configured to receive a Diameter message from another Diameter node;

a rule engine configured to evaluate the custom metric rule to identify a metric to be collected; and

a metrics collector configured to collect the metric related to the received Diameter message based upon the evaluation of the custom metric rule.

9. The DN of claim 8, wherein the Diameter node is a diameter routing agent (DN).

10. The DN of claim 8, wherein the Diameter node is a policy and charging rules node (PCRN).

11. The DN of claim 8, further comprising, a user interface configured to receive a definition of the custom metric rule, wherein the definition specifies the metric and a condition when the metric is to be collected.

12. The DN of claim 11, wherein,

the Diameter stack is configured to receive a plurality of Diameter messages from other nodes,

the metrics collector is configured to collect a plurality of values of the specified metric related to the received Diameter message based upon the evaluation of the custom metric rule, and

a user interface configured to transmit the collected plurality of values.

13. The DN of claim 11, wherein,

the Diameter stack is configured to interface with an external node using a custom plugin,

the Diameter message is received from the external node,

the custom metric rule is related to Diameter messages from the external node, and

the collected metric relates to the received Diameter message from the external node.

14. The DN of claim 11, wherein the definition of the custom metric rule modifies a preexisting custom metrics scenario.

15. A non-transitory machine-readable storage medium encoded with instructions for execution by a Diameter node (DN) for processing a Diameter message, the medium comprising:

instructions for receiving a Diameter message at the Diameter node;

instructions for evaluating a custom metric rule to identify a metric to be collected; and

instructions for collecting the metric related to the received Diameter message based upon the evaluation of the custom metric rule.

16. The non-transitory machine-readable storage medium of claim 15, wherein the Diameter node is a diameter routing agent (DN).

17. The non-transitory machine-readable storage medium of claim 15, wherein the Diameter node is a policy and charging rules node (PCRN).

18. The non-transitory machine-readable storage medium of claim 15, further comprising, instructions for receiving, via a user interface, a definition of the custom metric rule, wherein the definition specifies the metric and a condition when the metric is to be collected.

19. The non-transitory machine-readable storage medium of claim 18, further comprising,

instructions for receiving a plurality of Diameter messages at the Diameter node;

instructions for collecting a plurality of values of the specified metric from a set of Diameter messages in the plurality of Diameter messages that meet the specified condition; and

instructions for transmitting via a user interface the collected plurality of values.

20. The non-transitory machine-readable storage medium of claim 18, wherein the definition of the custom metric rule modifies a preexisting custom metrics scenario.