U.S. patent application number 14/013696 was filed with the patent office on 2015-03-05 for customized diameter performance metrics.
This patent application is currently assigned to ALCATEL-LUCENT CANADA INC.. The applicant listed for this patent is ALCATEL-LUCENT CANADA INC.. Invention is credited to PETER JORGENSEN, ROBERT A. MANN, MIKAEL VIHTARI.
Application Number | 20150063130 14/013696 |
Document ID | / |
Family ID | 49671663 |
Filed Date | 2015-03-05 |
United States Patent
Application |
20150063130 |
Kind Code |
A1 |
VIHTARI; MIKAEL ; et
al. |
March 5, 2015 |
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.
Inventors: |
VIHTARI; MIKAEL; (KANATA,
CA) ; MANN; ROBERT A.; (CARP, CA) ; JORGENSEN;
PETER; (NEPEAN, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
ALCATEL-LUCENT CANADA INC. |
Ottawa |
|
CA |
|
|
Assignee: |
ALCATEL-LUCENT CANADA INC.
Ottawa
CA
|
Family ID: |
49671663 |
Appl. No.: |
14/013696 |
Filed: |
August 29, 2013 |
Current U.S.
Class: |
370/252 |
Current CPC
Class: |
H04L 47/12 20130101;
H04L 12/1407 20130101; H04W 24/08 20130101; H04L 63/0892 20130101;
H04L 67/1036 20130101; H04L 67/1097 20130101; H04L 67/28 20130101;
H04L 67/327 20130101 |
Class at
Publication: |
370/252 |
International
Class: |
H04W 24/08 20060101
H04W024/08 |
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.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] 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
[0002] Various exemplary embodiments disclosed herein relate
generally to communication networks.
BACKGROUND
[0003] 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.
[0004] 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
[0005] 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.
[0006] 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.
[0007] 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.
[0008] 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
[0009] In order to better understand various exemplary embodiments,
reference is made to the accompanying drawings, wherein:
[0010] FIG. 1 illustrates an exemplary network environment
including Diameter nodes;
[0011] FIG. 2 illustrates an exemplary Diameter node;
[0012] FIG. 3 illustrates an exemplary hardware diagram of a
Diameter node;
[0013] FIG. 4 illustrates an embodiment of a custom metric
rule;
[0014] FIG. 5 illustrates an embodiment of a method of applying
custom metrics rules.
[0015] 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
[0016] 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.
[0017] 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.
[0018] 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.
[0019] 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.
[0020] 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.
[0021] 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.
[0022] 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).
[0023] 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.
[0024] 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.
[0025] 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.
[0026] 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.
[0027] 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.
[0028] 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.
[0029] 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.
[0030] 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.
[0031] 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.
[0032] 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.
[0033] 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.
[0034] 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.
[0035] 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.
[0036] 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.
[0037] 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.
[0038] 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.
[0039] 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.
[0040] Below examples of custom metrics are described.
[0041] 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.
[0042] 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.
[0043] 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.
[0044] 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.
[0045] 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.
[0046] 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.
[0047] 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.
[0048] 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.
[0049] 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.
[0050] 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.
[0051] 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.
[0052] 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.
[0053] 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.
[0054] 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.
[0055] 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.
[0056] 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.
[0057] 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.
[0058] 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.
[0059] 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.
[0060] 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.
[0061] 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.
[0062] 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.
[0063] 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.
[0064] 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.
[0065] 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.
[0066] 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.
[0067] 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.
[0068] 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.
[0069] 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.
[0070] 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.
[0071] 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.
[0072] 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.
[0073] 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.
* * * * *