The disclosures of each of the following commonly-owned, co-pending U.S. patent applications filed on Feb. 11, 2011 are hereby incorporated herein by reference in their entireties:
“Methods, Systems, And Computer Readable Media for Inter-Diameter-Message Processor Routing,” (Ser. No. 13/025,968);
“Methods, Systems, And Computer Readable Media For Source Peer Capacity-Based Diameter Load Sharing” (Ser. No. 13/026,031);
“Methods, Systems, And Computer Readable Media For Inter-Message Processor Status Sharing,” (Ser. No. 13/026,105);
“Methods, Systems, And Computer Readable Media For Providing Priority Routing At A Diameter Node,” (Ser. No. 13/026,060);
“Methods, Systems, And Computer Readable Media For Providing Origin Routing At A Diameter Node,” (Ser. No. 13/026,081);
“Methods, Systems, And Computer Readable Media For Providing Local Application Routing At A Diameter Node,” (Ser. No. 13/026,098);
“Methods, Systems, And Computer Readable Media For Answer-Based Routing Of Diameter Request Messages,” (Ser. No. 13/026,112);
“Methods, Systems, And Computer Readable Media For Performing Diameter Answer Message-Based Network Management At A Diameter Signaling Router (DSR),” (Ser. No. 13/026,125);
“Methods, Systems, And Computer Readable Media For Multi-Interface Monitoring And Correlation Of Diameter Signaling Information,” (Ser. No. 13/026,133);
“Methods, Systems, And Computer Readable Media For Diameter Protocol Harmonization,” (Ser. No. 13/026,144);
“Methods, Systems, And Computer Readable Media For Diameter Network Management,” (Ser. No. 13/026,153); and “Methods, Systems, And Computer Readable Media For Diameter Application Loop Prevention,” (Ser. No. 13/026,162).
The subject matter described herein relates to performing routing at a Diameter node. More specifically, the subject matter relates to methods, systems, and computer readable media for providing peer routing at a Diameter node.
Diameter is an authentication, authorization and accounting (AAA) protocol for computer networks, and is a successor to RADIUS. The Diameter base protocol is defined in IETF RFC 3588, the disclosure of which is incorporated by reference herein in its entirety. RFC 3588 discusses a Diameter routing agent that routes Diameter signaling messages, but does not specify architecture for the Diameter routing agent or Diameter routing in general.
Accordingly, in light of these difficulties, a need exists for improved methods, systems, and computer readable media for providing peer routing at a Diameter node.
Methods, systems, and computer readable media for providing peer routing at a Diameter node are disclosed. One exemplary method includes receiving, at an ingress Diameter message processor associated with a DSR, a Diameter message from a first Diameter node. The method further includes accessing, using the ingress Diameter message processor, Diameter peer routing information to determine an egress Diameter message processor among a plurality of egress Diameter message processors within the DSR and associated with a second Diameter node that is a peer of the DSR and to which the Diameter message is to be forwarded. The method also includes forwarding the Diameter message to the determined egress Diameter message processor.
As used herein, the term “node” refers to a physical computing platform including one or more processors and associated memory.
The subject matter described herein may be implemented in software in combination with hardware and/or firmware. For example, the subject matter described herein may be implemented in software executed by a processor. In one exemplary implementation, the subject matter described herein for providing peer routing at a Diameter node may be implemented using a non-transitory computer readable medium to having stored thereon executable instructions that when executed by the processor of a computer control the processor to perform steps. Exemplary non-transitory computer readable media suitable for implementing the subject matter described herein include chip memory devices or disk memory devices accessible by a processor, programmable logic devices, and application specific integrated circuits. In addition, a computer readable medium that implements the subject matter described herein may be located on a single computing platform or may be distributed across plural computing platforms.
The subject matter described herein will now be explained with reference to the accompanying drawings of which:
The subject matter described herein includes methods, systems, and computer readable media for providing peer routing at a Diameter node. Specifically, the present subject matter described herein may be implemented at a Diameter signaling router (DSR) network element (NE) including a Diameter connection layer (DCL), Diameter routing layer (DRL), one or more local applications, and one or more routing tables, such as a peer routing table (PRT) and application routing table (ART). In one embodiment, a DSR includes a set of co-located DSR MPs that share common Diameter routing tables. As used herein, the term “Diameter connection layer (DCL)” refers to a software layer of a Diameter stack in the DSR that implements Diameter transport connections. As used herein, the term “Diameter routing layer (DRL)” refers to a software layer of the Diameter stack which implements Diameter routing. Exemplary DRL capabilities may include: routing request messages to Diameter peer nodes or local applications based on message content, discarding or rejecting Diameter request messages based on message content rules, peer congestion control, and easier configuration. In order to support both application processing and core Diameter routing functions, the DRL in the DSR may support the following message routing tables: an application routing table (ART) and a peer routing table (PRT), each of which will be described in greater detail later. It will be appreciated that embodiments of the present may be implemented in any node that is adapted to route Diameter messages, including but not limited to, a Diameter routing agent, a Diameter proxy agent, a Diameter relay agent, or a Diameter translation agent.
In block 104, at the ingress Diameter message processor, a PRT is accessed to determine an egress Diameter message processor among a plurality of egress Diameter message processors associated with the DSR the Diameter message is to be forwarded. In one embodiment, the DRL may extract a set of parameter values from the received Diameter message which may be used as criteria for Diameter message matching in a PRT. Alternatively, the received Diameter message may be first processed by a local Diameter signaling application on the DSR prior to the extraction of the parameter values. Exemplary parameters (i.e., rule message selection parameters) found in a Diameter message may include 1) a Destination-Realm parameter, 2) an Application ID parameter, 3) a Destination-Host parameter, 4) a Origin-Realm parameter, which identifies the realm from which the message was originated, 5) an Origin-Host parameter that identifies the Host from which the message was originated, 6) a User-Name parameter that identifies the user for which this service is being invoked, and 7) a Command-Code parameter that identifies the request message type.
The extracted parameter values may be used by the DRL to search Diameter peer routing information stored in one or more local peer routing tables on the DSR. If the parameter values match at least one rule entry in the peer routing table, then the matching entry with the highest priority value is selected. An “Action” parameter from the selected rule entry from the PRT is then inspected. If the Action indicates “Route to Peer”, then the DRL invokes a route selection process based on the rule's Route List. The route selection process involves creating a list of available routes with the Route List's designated Active Route Group. The DSR then selects a route from the list based on, for example, a statistical algorithm (see details below). Consequently, the route selected from the list is associated with a particular egress Diameter message processor on the DSR.
In block 106, the Diameter message is forwarded to the determined egress Diameter message processor. In one embodiment, the DRL on the ingress Diameter message processor forwards the Diameter message to the DRL on the selected egress Diameter message processor. The DRL on the egress Diameter message processor, in turn, forwards the Diameter message to a local DCL queue for transport.
In block 108, the Diameter message is transmitted from the determined egress Diameter message processor to a second Diameter node. In one embodiment, the DCL on the egress Diameter message processor forwards the processed Diameter message from the DSR to the intended Diameter peer node over a Diameter connection. Notably, this step is conducted without performing any routing-related processing by the egress Diameter message processor itself. The route and peer node selection is conducted entirely by the ingress Diameter message processor on the DSR.
There are several exemplary architecture options in which may be employed by a DSR. A first architecture option may include where each message processor (MP) supports a full Diameter stack that includes the DCL, DRL, and Application layers. A second architecture option may include a DCL that runs on dedicated MPs, Routing and Application layers can either be combined on dedicated MPs or have dedicated MPs for each layer. A third architecture option may include a Diameter stack (DCL, DRL) that runs on dedicated MPs, local Diameter applications run on separate dedicated MPs. Each of these exemplary architecture options are described in greater detail below with respect to
In an exemplary Diameter message routing scenario, Diameter peer node N−1 218 may send a Diameter message to DSR 200. The Diameter message may be received by DCL 206 of ingress MP 202. In one embodiment, the received Diameter message is a Diameter request message. Ingress messages may be processed completely on ingress MP 202 including the selection of a destination Diameter peer node for the Diameter message by DRL 208. Continuing with the above example, DRL 208 may receive a Diameter message passed by DCL 206.
If local application processing is required, ingress DRL 208 may forward the Diameter message to an appropriate local application. For example, DRL 208 may forward the Diameter message to local application 210, which processes the message and returns the message to DRL 208. It is appreciated that an application distribution function may not be required.
Next, ingress DRL 208 may forward the Diameter message to egress DRL 214 for forwarding to the local queue associated with DCL 212. Egress DCL 212 may then transmit the Diameter message to Diameter peer node N+1 220.
In an exemplary Diameter message routing scenario analogous to the one described above with respect to
In one embodiment, ingress DRL-MP 302 may then select a destination peer and route for the Diameter message using a peer routing table (not shown) and ingress DRL-MP 302 may forward the message to egress DRL-MP 306 based on the route selection process. Egress DRL-MP 306 may then forward the Diameter message to egress DCL-MP 308 (for delivery to Diameter peer node N+1 220 as selected by ingress DRL-MP 302.
If signaling application processing is required, ingress DRL 208 may forward the Diameter message to local signaling application(s). For example, DRL 208 may forward the Diameter message to local application 304, which may process the message and return the message to DRL 208. Afterwards, ingress DRL 208 may forward the Diameter message to egress DRL 214 for forwarding to the local queue associated with DCL 212. Egress DCL 212 may then transmit the Diameter message to Diameter peer node N+1 220.
As shown in
By eliminating the need for application MP 304 to communicate messages back towards ingress MP 202 (i.e., returning the Diameter message back to ingress MP 202 for DRL processing), the routing efficiency of Diameter messages within DSR 200 can be improved. Namely, switch transit times and other latency generating factors typically experienced in a DSR element or routing agent may be reduced or eliminated.
After application processing is completed in DSR 200, ART 500 may forward the message to Peer Routing Table (PRT) 502. In one embodiment, PRT 502 may be searched after ART 500 searching is completed such that if the message content (after application processing updates) matches a rule in PRT 502, the message may be routed to a Diameter peer node as defined by a Route List in route list table 504 associated with the rule. Thus, the message may be sent to Diameter peer N+1 220 after route list table 504 is consulted.
By using a single DSR configuration as described above, redundant DRL routing on both the ingress and egress MPs may be eliminated. For example, the ingress MP may be configured to receive a Diameter message from a first Diameter peer node and be responsible for conducting ART and PRT searches and a route selection process. The ingress MP would select a route from the Active Route Group and forward both the Diameter message received from a sending Diameter peer node and the selected route to the egress DSR MP that controls the Diameter peer connection. Notably, when the egress MP on the DSR receives a Diameter request message from an ingress MP containing a route, the egress MP will bypass local ART and PRT process described above and attempt to deliver the message to the Diameter peer node selected by the ingress MP.
This is aspect is depicted in
In one embodiment, the inter-MP Diameter message routing with the scalable DSR may be optimized. In order to minimize overhead associated with inter-MP routing of Diameter messages, the overhead of Diameter messages on inter-MP links should be avoided. Namely, forwarding a Diameter request message from the ingress MP to the egress MP may involve the ingress DRL creating a new Hop-by-Hop identifier for the request message directed toward the egress MP. Specifically, the ingress DRL may insert a MP identifier into the Hop-by-Hop identifier, which allows an egress DRL to back-route a Diameter answer response message to a ingress DRL. If the egress DRL happens to encounter an error (e.g., the failure of the second Diameter peer node, the transport queue is full, etc.), the egress DRL may send an error response (with a cause code) to the ingress DRL. In one embodiment, the error response may include either a Diameter answer message or an internal message.
In one embodiment, egress-to-ingress MP Diameter answer messages may be forwarded upon the egress DRL validating the embedded MP identifier in the Diameter answer message's Hop-by-Hop identifier. If the MP identifier is valid and the MP is available, the egress DRL internally routes the Diameter answer message to the ingress DRL for Diameter back-routing processing. If either the MP identifier is invalid or the MP is unavailable, then the egress DRL may discard the Diameter answer message received from a second Diameter peer node. Notably, any Diameter answer messages received by the Ingress DRL from an egress DRL may be processed as if the Diameter message has been received directly from the second Diameter peer node.
In an alternate embodiment, where multiple Diameter message processors may be associated with or service the same Diameter peer connection, the present subject matter allows for the ingress MP that receives a Diameter answer message to select an egress MP that is different from the MP that received the associated Diameter request message. As such, in the event that an MP which served as the ingress MP for a Diameter request message fails (or becomes unavailable) prior to receipt at the DSR of an associated answer message, the Diameter answer message may be internally routed by the ingress MP to an egress MP that is different from the failed MP.
In one embodiment, a scalable DSR may be used to route Diameter messages to Diameter peer nodes. After local application routing has completed on the DSR (or not invoked if the DSR has no locally configured services/applications), the ingress DRL on a DSR may search the PRT using parameters included in the Diameter message. In one embodiment, the PRT may include a plurality of message content matching rule entries, each of which may have one of the following Actions assigned by a network operator. For example, the assigned Action may either be “Route to Peer” or “Send Answer response”. If the Action is “Route to Peer”, the rule may be associated with a “Route List” that the ingress DRL can use to route the Diameter message towards the ultimate message destination (i.e., a Diameter peer node). In one embodiment, a Route List consists of one or more routes, each of which is associated with a specific Diameter peer node. An exemplary route list 1000 is depicted in
As indicated above, a “route” may actually represent a specific Diameter peer node. Because more than one route can be assigned to a “Route List”, each route may be assigned a priority and weight to provide assistance in the route selection process. A set of routes in a Route List with equal priority may be called a “Route Group”. In one embodiment, a Route Group in a Route List may be used for routing messages selected by a PRT rule. The Route Group that is currently being used for routing, based on Route Group availability and capacity rules, may be called the “Active Route Group.”
The routing of Diameter messages from a DSR to a Diameter peer node is conducted in accordance with certain rules or objectives. In one embodiment, the DSR may support routing to Diameter peer nodes that is consistent with DNS load-share routing required by 1) the ability to define multiple Route Groups to a Diameter peer node using costs/priorities and/or 2) the ability to load share messages across multiple routes within the same priority (Route Group) using route weights. However, the DSR may not select a route within a Route Group if the Diameter peer node does not support the Diameter application indicated by the application ID in the message or if a Diameter peer node has already processed the message (i.e., message looping detection). Also, the DSR may not select a route if the Diameter peer node's transport layer queue is full. In one embodiment, the DSR may reduce the percentage of messages the DSR routes to a Diameter peer node based on the peer node's level of congestion. In another embodiment, the DSR may not attempt to select a route more than once for routing the same Diameter message. In yet another embodiment, the DSR should not exceed the Diameter peer node's rated capacity.
In one embodiment, the DSR may attempt to route a message to a Diameter peer node using the highest priority Route Group in the Route List that is available. A Route Group is “available” if all of the following criteria are met. First, at least one route in the set is “Available” and the available routes in the set meet the minimum capacity requirement assigned to the Route List. Please note that “capacity” may be defined in terms of route weights. For example, if the minimum capacity assigned to a Route List is “5”, and Route Group-1 is comprised of Route-A (weight=4) and Route-B (weight=6), then Route Group-1 is Available only if Route-B is Available. Also, the DSR may be configured to send a Diameter answer message indicating “DIAMETER_UNABLE_TO_DELIVER” if the peer routing process selects a Route List that does not have any available Route Groups.
As mentioned above, the PRT may include a number of contents, such as a rule name, a rule priority, and a plurality of message selection parameters. As used herein, the rule name is an operator provided name for identification. Similarly, the rule priority refers to the selection of a table entry with the highest priority in the event a table query finds multiple matches. As used herein and indicated above, rule message selection parameters include Diameter message parameters that the user may specify as criteria for message matching. Exemplary rule message selection parameters in the PRT (which may match parameters in the Diameter message) include: 1) a Destination-Realm which is similar to Diameter Realm Routing Table and has an OctetString core data type, 2) an Application ID which is similar to Diameter Realm Routing Table and may be represented by a 32-bit value, and 3) a Destination-Host which is not unlike to “Host Identity” in a Diameter Peer Table and has an OctetString core data type, 4) the Origin-Realm, which identifies the realm from which the message was originated and has an OctetString core data type, 5) an Origin-Host that identifies the Host from which the message was originated, 6) a User-Name that identifies the user for which this service is being invoked and has an OctetString core data type, and 7) a Command-Code that that includes 24 bits and identifies the request message type. Any value may be supported in order to later add application-specific command-codes.
Additional contents of the PRT may include an “Action”, which may be defined as the action to perform when the rule is invoked. Exemplary actions include “Route to Peer” (where the Diameter message may be routed to a Diameter peer node defined by the rule's “Route List” field) and “Send Answer Response”, which is a Diameter answer response that may be sent using the rules' Result-Code field when a Diameter peer node is unavailable.
In one embodiment, the PRT may also include “Route List Name” and a “Result-Code” parameters associated with a given Action parameter. The Route List name indicates the Route List to be used when the “Action” is set to “Route to Peer”. Similarly, the Result-Code includes a Result-Code AVP value to be used when the “Action” is set to “Send Answer Response.” The default value of the Result-Code may be 3002 “DIAMETER_UNABLE_TO_DELIVER. For example, if the ingress DRL searches the PRT and is unable to find a match, then a routing failure occurs. The DRL may then send a DIAMETER_UNABLE_TO_DELIVER Answer response message to the original sending Diameter peer node.
In one embodiment, a PRT utilizes one or more default entries. With the ability to wildcard PRT entries and assign priorities to rules, a network operator may specify routing for Diameter request messages addressed to a specific Destination-Realm (regardless of Application ID), a specific Application ID (regardless of Destination-Ream), or for all request messages. This flexibility enables the network operator to configure one or more specific routing rules and then utilize one or more default entries to handle everything else. For example,
Proxy Agent peer which indicates support for two different application IDs in the CER/CEA handshake. Lastly, rules 7-8 are routing rules for a local realm Diameter Relay Agent peer which indicates support for all application IDs (0xffffffff) in a CER/CEA handshake.
In one embodiment, a PRT and associated route lists may be used to route Diameter request messages to a Diameter peer node. For example, entries in the PRT may utilize priority routing schemes that include priority indicators and load sharing routing schemes that include weights to facilitate the routing of Diameter messages. Priority routing includes defining more than one route to a destination and assigning a relative priority to each route. With priority routing, the route with the highest priority available Route Group (as indicated with a priority indicator) may be selected for routing. Likewise, load Share routing allows for the distributing of Diameter the messages to a set of routes with equal priority (i.e., a Route Group). The distribution of Diameter messages within a Route Group is controlled by assigning a relative weight to each route within a Route Group. The percentage of messages sent to a given route in the Route Group may be determined from the set of Available routes in the Route Group (i.e., Unavailable routes are excluded) using the calculation:
Percent=100*(weight of Route-X)/(sum of the weights of the available routes in the Route Group)
In one embodiment, a route list may be comprised of multiple route groups in a PRT, wherein each route group has a unique priority within its route list. Two types of route list redundancy schemes may be supported. A first redundancy scheme may include all route groups within a route list being eligible for routing messages. In such an embodiment, the route selection may start with the highest priority route group with overflows assigned to lower priority groups when no routes in the higher priority can be selected. A second redundancy scheme may involve Active/Standby route groups. For example, one Route Group for routing messages may be designated as the “Active Route Group” while all other Route Groups serve as backups to the Active Route Group in the event the Active Route Group fails. These alternate groups are referred to as “Standby Route Groups”. In one embodiment, the highest priority Route Group is always the Active Route Group if at least one route in the Route Group is Available. The Active/Standby redundancy scheme is typically the default Route List redundancy option supported by the DRL.
Similarly, the present subject matter may address a route group's availability status. In one embodiment, a route group's availability status may be expressed in terms of its capacity. Statuses may include 1) Available, 2) Degraded, or 3) Unavailable. As used herein with respect to a route group's availability status, “Available” is intended to mean the route group's capacity meets or exceeds the minimum value assigned to the route list, “Degraded” is intended to mean the route group's capacity is greater than zero but less than the minimum value assigned to the route list, and “Unavailable” is intended to mean the route group's capacity is zero.
In one embodiment, a Route Group is designated the “Active Route Group” for the Route List when it meets one of the following criteria: 1) it is the Highest priority Route Group among Route Groups with the status of “Available”, or 2) it is the Highest capacity Route Group when no Route Groups have the status “Available”. If more than one Route Group has the same capacity, then the highest priority Route Group is designated as the Active Route group.
In one embodiment, the DRL evaluates and may change the Route Group status and the designated “Active Route Group” for a Route List when any of the following events occur: 1) a Peer (Route) status change (i.e., this potentially impacts multiple Route Lists), 2) the Route added to a Route List by operator (i.e., this increases capacity of a Route Group if peer's status is Available), 3) the Route is deleted from a Route List by a network operator (i.e., this decreases current capacity of a Route Group if peer's status is Available), 4) the route's priority is modified by the network operator, or 5) the route's weight is modified by operator (i.e., this changes the current capacity of associated Route Group if the Diameter peer node's status is Available). In one embodiment, an availability status may be maintained for each Route List to quickly facilitate routing decisions when a Route List is selected by a PRT rule. A Route List availability status may be identical to the status of its Active Route Group. This is depicted in
The present subject matter may include a peer table that contains the list of Diameter peer nodes to which a DSR has direct connections for routing Diameter messages via TCP, SCTP, or UDP transport. Notably, all of the information a DSR MP needs to know about a peer node is stored in a peer record. Any peer-specific information required in making a decision of routing a message to a peer node may be stored in this table. Peer-specific information may include the peer node's availability status (i.e., whether at least one active transport connection is available), the peer node's congestion state, and a list of applications IDs the Diameter peer node supports (acquired during Capabilities-Exchange). Any information about the Diameter peer node which is acquired during the Capabilities-Exchange may be stored in the peer node's record so it can be viewed by the network operator.
In one embodiment, the present subject matter may allow for route selection by the ingress DRL. When peer routing is invoked for a Diameter message that matches a PRT rule Action of “Route to Peer”, the DRL may use the Route List assigned to that rule for routing the message to a Diameter peer node. In one embodiment, the DRL uses the Route List's currently designated Active Route Group to route the Diameter message. Notably, the “Active Route Group” designation may be determined asynchronously from message routing based on peer status changes and route list management events. If the Active Route Group has more than one route, then the DRL creates a list of available routes from the Route Group that will be used for all subsequent decisions about routing this message. In one embodiment, this list is stored in the “pending transaction record” for this Diameter message in case message rerouting is required after a message is forwarded. Also, Diameter message rerouting may occur after a Diameter message is forwarded if a Diameter peer node failure occurs or if a negative Diameter answer response message is received.
Once a list of available routes for the Diameter message has been created, the DRL may select a route from the list based on the relative weights assigned to each route. As indicated above, weights may be used to proportion traffic across routes in the Route Group. A weight assigned to a route does not serve as the route's priority for route selection within the Route Group, but rather the assigned weight serves to calculate the probability that the route may be selected from the list. For example, if a Route Group is comprised of four routes with weights 40, 30, 20, and 10, respectively, then the probability that Route-1 will be selected first for routing any message is 40% (i.e., 40/(40+30+20+10)). In one embodiment, the DRL selects a route from the list using a statistical algorithm that utilizes the route weights. For example, the algorithm may select Route-1 40% of the time.
Once the DRL selects a route from the list, the DRL determines whether it is possible to use that route based on certain criteria. In one embodiment, the criteria includes: 1) the Diameter message's Application ID is supported by the peer, 2) the Diameter peer node has not previously processed the message (e.g., the peer node's identity does not match one of the message's Route-Record AVPs), 3) the peer node's transport layer queue is not full, 4) the peer node is congested but the Diameter message meets the criteria for forwarding the message to the peer (as described below with respect to peer congestion), 5) the peer node's status is Unavailable, and 6) the peer node is no longer associated with the Route Group or Route List.
If a Diameter peer node matches the route selection criteria, standard Request message processing will be invoked (as mentioned above) and the message will be queued on the Diameter peer node's transport layer queue. If a Diameter peer node does not match the route selection criteria then the DRL may remove that route from the list (i.e., a route should never be considered more than once for routing the same message) and the DRL may re-invoke the statistical route selection algorithm based on the remaining routes in the list. In the previous example, if Route-1 was selected first but did not meet the additional criteria for using that route as defined above, the new list would be limited to routes 2, 3, and 4 with weights 30, 20, and 10, respectively. Thus, with the smaller list of routes, the probability of selecting Route-2 would be 50% (i.e., 30/(30+20+10)=50%). Notably, the route selection process continues until a viable route is found or the list is exhausted. Specifically, if no peer nodes in the Active Route Group meet the route selection criteria, the DRL may abandon peer routing and send a DIAMETER_UNABLE_TO_DELIVER Answer response message to the Diameter peer node that originally sent the Diameter request message.
In one embodiment, the present subject matter may utilize peer application identifiers to conduct route selection. As mentioned above, a Diameter message should not be routed to a Diameter peer node that does not support the Application identifier indicated in the Diameter message. The Diameter base protocol indicates that each time a first transport connection is established between Diameter peer nodes, a Capabilities-Exchange is performed before the transport connection is allowed. Namely, a peer node will send the lists of Application IDs it supports in the CER or CEA message. When a DSR receives a list of Application IDs from a peer node, these identifiers are stored in the Peer Table to be accessed during message routing. When the DSR message routing selects a route from a Route List associated with a peer node, the peer node's supported Application ID list is interrogated to verify that the Application ID in the message matches one of the Application IDs supported by the peer node. If an Application ID match is not found, the DSR bypasses this route and continues the route selection process.
In one embodiment, the present subject matter may consider peer congestion to conduct route selection. A Diameter peer node may report congestion by sending an Answer response with Result-Code AVP set to DIAMETER_TOO_BUSY. The congested node is identified by the Origin-Host in the Answer response (i.e., the response may not have been sent by a peer node). The DRL should only be concerned with peer congestion, not upstream node congestion. That is, the Diameter protocol is only peer status aware such that the status of upstream nodes is not tracked or managed. In one embodiment, the DRL may detect peer congestion via DIAMETER_TOO_BUSY Answer responses containing the peer node's identity in the Origin Host AVP and via the transport layer interface to the peer (e.g., outbound queue depth, etc.).
A peer congestion detection and control solution may be implemented in DSR that includes monitoring based on internal queue lengths (e.g., SCTP association egress queue). Currently, simple congestion control procedure may involve discarding the Diameter message if the queue is full. Thus, a DSR may bypass this route during route selection when a Diameter peer node's SCTP egress queue is full. In one embodiment, a DIAMETER_TOO_BUSY Answer response from a peer node may be used to determine the congestion level of peer node. For example, upon receipt of an initial DIAMETER_TOO_BUSY message, the peer congestion level may be set to “1”. The DSR may maintain a rolling window of percentage of Request messages rejected by the DIAMETER_TOO_BUSY response and adjust the peer node's congestion level accordingly. It is worth noting that a DIAMETER_TOO_BUSY Answer response received from a peer node may have been originated by an upstream node. The DRL validates that the busy response was initiated by the peer node (i.e., Origin-Host AVP set to the peer node's FQDN) in order to determine if the peer node is congested.
It will be understood that various details of the subject matter described herein may be changed without departing from the scope of the subject matter described herein. Furthermore, the foregoing description is for the purpose of illustration only, and not for the purpose of limitation, as the subject matter described herein is defined by the claims as set forth hereinafter.
This application claims the benefit of U.S. Provisional Patent Application Ser. No. 61/304,310 filed Feb. 12, 2010 and U.S. Provisional Patent Application Ser. No. 61/373,636 filed Aug. 13, 2010; the disclosures of which are incorporated herein by reference in their entireties.
Number | Name | Date | Kind |
---|---|---|---|
5228083 | Lozowick et al. | Jul 1993 | A |
5719861 | Okanoue | Feb 1998 | A |
6157621 | Brown et al. | Dec 2000 | A |
6273622 | Ben-David | Aug 2001 | B1 |
6304273 | Bonnet | Oct 2001 | B1 |
6584073 | Steele, Jr. et al. | Jun 2003 | B1 |
6795546 | Delaney et al. | Sep 2004 | B2 |
6819652 | Aravamudhan et al. | Nov 2004 | B1 |
6865153 | Hill et al. | Mar 2005 | B1 |
6915345 | Tummala et al. | Jul 2005 | B1 |
6918041 | Chen | Jul 2005 | B1 |
6954790 | Forslöw | Oct 2005 | B2 |
6967956 | Tinsley et al. | Nov 2005 | B1 |
7042877 | Foster et al. | May 2006 | B2 |
7043000 | Delaney et al. | May 2006 | B2 |
7136635 | Bharatia et al. | Nov 2006 | B1 |
7257636 | Lee et al. | Aug 2007 | B2 |
7286516 | Delaney et al. | Oct 2007 | B2 |
7292592 | Rune | Nov 2007 | B2 |
7298725 | Rune | Nov 2007 | B2 |
7333438 | Rabie et al. | Feb 2008 | B1 |
7333482 | Johansson et al. | Feb 2008 | B2 |
7383298 | Palmer et al. | Jun 2008 | B2 |
7403492 | Zeng et al. | Jul 2008 | B2 |
7403537 | Allison et al. | Jul 2008 | B2 |
7466807 | McCann et al. | Dec 2008 | B2 |
7551926 | Rune | Jun 2009 | B2 |
7567796 | Tammi et al. | Jul 2009 | B2 |
7583963 | Tammi et al. | Sep 2009 | B2 |
7590732 | Rune | Sep 2009 | B2 |
7633872 | Pitcher et al. | Dec 2009 | B2 |
7633969 | Caugherty et al. | Dec 2009 | B2 |
7706343 | Delaney et al. | Apr 2010 | B2 |
7792981 | Taylor | Sep 2010 | B2 |
7822023 | Lahetkangas et al. | Oct 2010 | B2 |
7894353 | Li et al. | Feb 2011 | B2 |
7898957 | Lea et al. | Mar 2011 | B2 |
7916685 | Schaedler et al. | Mar 2011 | B2 |
7961685 | Suh et al. | Jun 2011 | B2 |
7996007 | Bantukul | Aug 2011 | B2 |
7996541 | Marathe et al. | Aug 2011 | B2 |
8041021 | Xu et al. | Oct 2011 | B2 |
8045983 | Bantukul | Oct 2011 | B2 |
8170035 | Furey et al. | May 2012 | B2 |
8170055 | Fang et al. | May 2012 | B2 |
20010024443 | Alriksson et al. | Sep 2001 | A1 |
20020049901 | Carvey | Apr 2002 | A1 |
20020051427 | Carvey | May 2002 | A1 |
20020087723 | Williams et al. | Jul 2002 | A1 |
20020133494 | Goedken | Sep 2002 | A1 |
20020133534 | Forslow | Sep 2002 | A1 |
20020141346 | Garcia-Luna-Aceves et al. | Oct 2002 | A1 |
20020181507 | Jones | Dec 2002 | A1 |
20030095536 | Hu et al. | May 2003 | A1 |
20030115358 | Yun | Jun 2003 | A1 |
20040037278 | Wong et al. | Feb 2004 | A1 |
20040042485 | Gettala et al. | Mar 2004 | A1 |
20040098612 | Lee et al. | May 2004 | A1 |
20050002417 | Kelly et al. | Jan 2005 | A1 |
20050099964 | Delaney et al. | May 2005 | A1 |
20050232236 | Allison et al. | Oct 2005 | A1 |
20050232407 | Craig et al. | Oct 2005 | A1 |
20050235065 | Le et al. | Oct 2005 | A1 |
20050246545 | Reiner | Nov 2005 | A1 |
20050246716 | Smith et al. | Nov 2005 | A1 |
20060045249 | Li et al. | Mar 2006 | A1 |
20060077926 | Rune | Apr 2006 | A1 |
20060101159 | Yeh et al. | May 2006 | A1 |
20060104210 | Nielsen | May 2006 | A1 |
20060123477 | Raghavan et al. | Jun 2006 | A1 |
20060172730 | Matsuda | Aug 2006 | A1 |
20060177007 | Vaghar et al. | Aug 2006 | A1 |
20060200670 | Kuffel et al. | Sep 2006 | A1 |
20060221972 | Bhargava et al. | Oct 2006 | A1 |
20060253563 | Yang et al. | Nov 2006 | A1 |
20060274744 | Nagai et al. | Dec 2006 | A1 |
20070047539 | Agarwal et al. | Mar 2007 | A1 |
20070153995 | Fang et al. | Jul 2007 | A1 |
20070168421 | Kalyanpur et al. | Jul 2007 | A1 |
20070214209 | Maeda | Sep 2007 | A1 |
20070280447 | Cai et al. | Dec 2007 | A1 |
20070297419 | Askerup et al. | Dec 2007 | A1 |
20080025230 | Patel et al. | Jan 2008 | A1 |
20080039104 | Gu et al. | Feb 2008 | A1 |
20080144602 | Casey | Jun 2008 | A1 |
20080167035 | Buckley et al. | Jul 2008 | A1 |
20080212576 | O'Neill | Sep 2008 | A1 |
20080301162 | Wall et al. | Dec 2008 | A1 |
20080317247 | Jeong et al. | Dec 2008 | A1 |
20090080440 | Balyan et al. | Mar 2009 | A1 |
20090083861 | Jones | Mar 2009 | A1 |
20090129271 | Ramankutty et al. | May 2009 | A1 |
20090138619 | Schnizlein et al. | May 2009 | A1 |
20090185494 | Li et al. | Jul 2009 | A1 |
20090193071 | Qiu et al. | Jul 2009 | A1 |
20090232011 | Li et al. | Sep 2009 | A1 |
20100017846 | Huang et al. | Jan 2010 | A1 |
20100042525 | Cai et al. | Feb 2010 | A1 |
20100135287 | Hosain et al. | Jun 2010 | A1 |
20100251330 | Kroeselberg et al. | Sep 2010 | A1 |
20100265948 | Patel et al. | Oct 2010 | A1 |
20100299451 | Yigang et al. | Nov 2010 | A1 |
20110060830 | Kang et al. | Mar 2011 | A1 |
20110116378 | Ramankutty et al. | May 2011 | A1 |
20110116382 | McCann et al. | May 2011 | A1 |
20110188397 | McCann et al. | Aug 2011 | A1 |
20110199895 | Kanode et al. | Aug 2011 | A1 |
20110199906 | Kanode et al. | Aug 2011 | A1 |
20110200047 | McCann et al. | Aug 2011 | A1 |
20110200053 | Kanode et al. | Aug 2011 | A1 |
20110200054 | Craig et al. | Aug 2011 | A1 |
20110202604 | Craig et al. | Aug 2011 | A1 |
20110202612 | Craig et al. | Aug 2011 | A1 |
20110202613 | Craig et al. | Aug 2011 | A1 |
20110202614 | Graig et al. | Aug 2011 | A1 |
20110202676 | Craig et al. | Aug 2011 | A1 |
20110202677 | Craig et al. | Aug 2011 | A1 |
20110202684 | Craig et al. | Aug 2011 | A1 |
20110225280 | Delsesto et al. | Sep 2011 | A1 |
20110225306 | Delsesto et al. | Sep 2011 | A1 |
20110302244 | McCann et al. | Dec 2011 | A1 |
20110314178 | Kanode et al. | Dec 2011 | A1 |
20120155389 | McNamee et al. | Jun 2012 | A1 |
20120224524 | Marsico | Sep 2012 | A1 |
Number | Date | Country |
---|---|---|
2 716 544 | Dec 2010 | CA |
1 134 939 | Sep 2001 | EP |
1 328 102 | Jul 2003 | EP |
1 465 385 | Oct 2004 | EP |
1 314 324 | Aug 2008 | EP |
1 847 076 | Feb 2012 | EP |
WO 2008087633 | Jul 2008 | WO |
WO 2009058067 | May 2009 | WO |
WO 2009070179 | Jun 2009 | WO |
WO 2009134265 | Nov 2009 | WO |
WO 2011047382 | Apr 2011 | WO |
WO 2011100587 | Aug 2011 | WO |
WO 2011100594 | Aug 2011 | WO |
WO 2011100600 | Aug 2011 | WO |
WO 2011100606 | Aug 2011 | WO |
WO 2011100609 | Aug 2011 | WO |
WO 2011100610 | Aug 2011 | WO |
WO 2011100612 | Aug 2011 | WO |
WO 2011100615 | Aug 2011 | WO |
WO 2011100621 | Aug 2011 | WO |
WO 2011100626 | Aug 2011 | WO |
WO 2011100629 | Aug 2011 | WO |
WO 2011100630 | Aug 2011 | WO |
WO 2012119147 | Sep 2012 | WO |
Entry |
---|
Notification of Transmittal of the International Search Report and the Written Opinion of the International Searching Authority, or the Declaration for International Application No. PCT/US2010/053062 (Jun. 28, 2011). |
Znaty, “Diameter, GPRS, (LTE+ePC=EPS), IMS, PCC and SDM,” EFORT, pp. 1-460 (May 2010). |
“Ericsson Unified Number Portability,” (Downloaded from the Internet on Jan. 24, 2011). |
“3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Policy and Charging Control signalling flows and Quality of Service (QoS) parameter mapping (Release 9),” 3GPP TS 29.213, V9.2.0, pp. 1-129 (Mar. 2010). |
“Traffix Diameter Gateway; Instant Diameter Connection to any Network Element,” Traffix Systems, pp. 1-4 (Publication Date Unknown) (Downloaded from the Internet on Feb. 8, 2010). |
“Traffix Diameter Load Balancer; Scaling the Diameter Control Plane,” Traffix Systems, pp. 1-4 (Publication Date Unknown) (Downloaded from the Internet on Feb. 8, 2010). |
“Next Generation Networks Load Balancing—The Key to NGN Control, Management, and Growth,” Whitepaper by Traffix Systems, pp. 1-7 (Publication Date Unknown) (Downloaded from the Internet on Feb. 8, 2010). |
“Univerisal Mobile Telecommunications Systems (UMTS); LTE; InterWorking Function (IWF) Between MAP Based and Diameter Based Interfaces (3GPP TS 29.305 Version 9.0.0 Release 9),” ETSI TS 129 305 V9.0.0 (Jan. 2010). |
“Digital Cellular Telecommunications System (Phase 2+); Universal Mobile Telecommunications System (UMTS); LTE; IP Multimedia (IM) Subsystem Cx and Dx Interfaces; Signalling Flows and Message Contents (3GPP TS 29.228 Version 8.7.0 Release 8),” ETSI TS 129 228 v8.7.0 (Jan. 2010). |
“Mapping Diameter Interfaces to Functionality in 3GPP/3GPP2 IMS Architecture,” Whitepaper by Traffix Systems, pp. 1-10 (Copyright 2010). |
Jones et al., “Diameter Extended NAPTR,” Individual Submission Internet-Draft, draft-ietf-dime-extended-naptr-00, pp. 1-9 (Dec. 29, 2009). |
Korhonen et al., “Clarifications on the Routing of Diameter Requests Based on the Username and the Realm,” RFC 5729, pp. 1-9 (Dec. 2009). |
3GPP, “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Generic Authentication Architecture (GAA); Generic Bootstrapping Architecture (Release 9),” 3GPP TS 33.220 V9.2.0 (Dec. 2009). |
3GPP, “3rd Generation Partnership Project; Technical Specification Group Service and System Aspects; Telecommunication Management; Charging Management; Diameter Charging Applications (Release 9),” 3GPP TS 32.299 V9.2.0 (Dec. 2009). |
3GPP, “3rd Generation Partnership Project; Technical Specification Group Service and System Aspects; Telecommunication Management; Charging Management; Online Charging System (OCS): Applications and Interfaces (Release 9),” 3GPP TS 32.296 V9.1.0 (Dec. 2009). |
3GPP, “3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Diameter-based Protocols Usage and Recommendations in 3GPP (Release 9),” 3GPP TR 29.909 V9.0.0 (Dec. 2009). |
3GPP, “3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Sh Interface Based on the Diameter Protocol; Protocol Details (Release 9),” 3GPP TS 29.329 V9.0.0 (Dec. 2009). |
3GPP, “3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; IP Multimedia (IM) Subsystem Sh Interface; Signalling Flows and Message Contents (Release 9),” 3GPP TS 29.328 V9.0.0 (Dec. 2009). |
3GPP, “3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 3GPP System to Wireless Local Area Network (WLAN) Interworking; Stage 3 (Release 9),” 3GPP TS 29.234 V9.0.0 (Dec. 2009). |
3GPP, “3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Cx and Dx Interfaces Based on the Diameter Protocol; Protocol Details (Release 9),” 3GPP TS 29.229 V9.0.0 (Dec. 2009). |
3GPP, “3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; IP Multimedia (IM) Subsystem Cx and Dx Interfaces; Signalling Flows and Message Contents (Release 9),” 3GPP TS 29228 V9.0.0 (Dec. 2009). |
3GPP, “3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Policy and Charging Control Over Rx Reference Point (Release 9),” 3GPP TS 29.214 V9.2.0 (Dec. 2009). |
3GPP, “3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Policy and Charging Control over Gx Reference Point (Release 9),” 3GPP TS 29.212 V9.1.0 (Dec. 2009). |
3GPP, “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Policy and Charging Control Architecture (Release 9),” 3GPP TS 23.203 V9.3.0 (Dec. 2009). |
Jiao et al., “The Diameter Capabilities Update Application,” Network Working Group Internet-Draft draft-ietf-dime-capabilities-update-01, pp. 1-8 (Dec. 1, 2009). |
Tsou et al., “Realm-Based Redirection in Diameter,” Internet Engineering Task Force, draft-ietf-dime-realm-based-redirect-02, pp. 1-7 (Oct. 27, 2009). |
Huang et al., “The Diameter Precongestion Notification (PCN) Data Collection Applications,” Network Working Group Internet-Draft <draft-huang-dime-pcn-collection-02>, pp. 1-19 (Oct. 26, 2009). |
Carlberg et al., “Diameter Priority Attribute Value Pairs,” Diameter Maintenance and Extensions (DIME) Internet-Draft <draft-carlberg-dime-priority-avps-00.txt>, pp. 1-6 (Oct. 19, 2009). |
Korhonen et al., “Diameter User-Name and Realm Based Request Routing Clarifications,” Diameter Maintenance and Extensions (DIME) Internet-Draft, draft-ietf-dime-nai-routing-04.txt, pp. 1-13 (Oct. 6, 2009). |
Fajardo et al., “Diameter Base Protocol,” DIME Internet-Draft, draft-ietf-dime-rfc3588bis-19.txt, pp. 1-160 (Sep. 2, 2009). |
3GPP, “3rd Generation Partnership Project; Technical Specification Group core Network and Terminals; Generic Authentication Architecture (GAA); Zh and Zn Interfaces Based on the Diameter Protocol; Stage 3 (Release 8),” 3GPP TS 29.109 V8.3.0 (Sep. 2009). |
3GPP, “3rd Generation Partnership Project; Tecnhical Specification Group Core Network and Terminals; Numbering, Addressing and Identification (Release 8),” 3GPP TS 23.003 V8.6.0 (Sep. 2009) |
Jones et al., “Diameter Extended NAPTR,” Internet-Draft, draft-jones-dime-extended-naptr-00, pp. 1-8 (Aug. 23, 2009). |
Korhonen et al., “Diameter User-Name and Realm Based Request Routing Clarifications,” Internet-Draft, draft-ietf-dime-nai-routing-03,txt, pp. 1-11 (Aug. 19, 2009). |
Tsou et al., “Session-Specific Explicit Diameter Request Routing,” Network Working Group Internet-Draft, draft-tsou-diameter-explicit-routing-03, pp. 1-18 (Aug. 5, 2009). |
3GPP, “3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Evolved Packet System (EPS); Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) Related Interfaces Based on Diameter Protocol (Release 8),” ETSI TS 129.272 V8.3.0 (Jun. 2009). |
Bhardwaj, “Roaming Hubbing & LTE,” GSMA London, pp. 1-11 (May 19, 2009). |
3GPP, “3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Diameter-based Protocols Usage and Recommendations in 3GPP (Release 8),” 3GPP TR 29.909 V8.1.2 (Jan. 2009). |
3GPP, “3rd Generation Partnership Project; Technical Specification Group Service and System Aspects; Telecommunication Management; Charging Management; Charging Data Description for the IP Multimedia Subsystem (IMS) (Release 5),” 3GPP TS 32.225 V5.11.0 (Mar. 2006). |
Liu et al., “Introduction to Diameter,” Developer Works http://www.ibm.com/developerworks/library/wi-diameter/index.html (Downloaded from the Internet on Aug. 2, 2011), pp. 1-9 (Jan. 24, 2006). |
Aboba et al., “The Network Access Identifier,” Network Working Group, RFC 4282, pp. 1-17 (Dec. 2005). |
3GPP, “3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Policy Control Over Go Interface (Release 6),” 3GPP TS 29.207 V6.5.0 (Sep. 2005). |
Eronen et al., “Diameter Extensible Authentication Protocol (EAP) Application,” Network Working Group, RFC 4072, pp. 1-31 (Aug. 2005). |
Hakala et al., “Diameter Credit-Control Application,” Network Working Group RFC 4006, pp. 1-107 (Aug. 2005). |
Calhoun et al., “Diameter Mobile IPv4 Application,” Network Working Group, RFC 4004, pp. 1-50 (Aug. 2005). |
3GPP, “3rd Generation Partnership Project; Technical Specification Group Core Network; Support of Mobile Number Portability (MNP); Technical Realization; Stage 2 (Release 6),” 3GPP TS 23.066, V6.0.0, pp. 1-83 (Dec. 2004). |
Calhoun et al., “Diameter Base Protocol,” Network Working Group, RFC 3588, pp. 1-148 (Sep. 2003). |
Aboba et al., “Authentication, Authorization and Accounting (AAA) Transport Profile,” Network Working Group, RFC 3539, pp. 1-39 (Jun. 2003). |
Stewart et al., “Stream Control Transmission Protocol,” Network Working Group RFC 2960, pp. 1-134 (Oct. 2000). |
Greene et al., “Bi-Directional Session Setup Extension to Diameter,” Internet Draft <draft-greene-diameter-ss7-session-00.txt>, pbs. 1-12 (Jul. 1998). |
“Diameter Overview,” referenced from www.ulticom.com/html/products/signalware-diameter-reference-guide.asp (Publication Date Unknown). |
Final Official Action for U.S. Appl. No. 12/906,816 (Feb. 21, 2012). |
Applicant-Initiated Interview Summary for U.S. Appl. No. 12/906,816 (Jan. 27, 2012). |
Notification of Transmittal of the International Search Report and the Written Opinion of the International Searching Authority, or the Declaration for International Application No. PCT/US2011/024622 (Oct. 31, 2011). |
Notification of Transmittal of the International Search Report and the Written Opinion of the International Searching Authority, or the Declaration for International Application No. PCT/US2011/024617 (Oct. 31, 2011). |
Notification of Transmittal of the International Search Report and the Written Opinion of the International Searching Authority, or the Declaration for International Application No. PCT/US2011/024614 (Oct. 31, 2011). |
Notification of Transmittal of the International Search Report and the Written Opinion of the International Searching Authority, or the Declaration for International Application No. PCT/US2011/024646 (Oct. 28, 2011). |
Notification of Transmittal of the International Search Report and the Written Opinion of the International Searching Authority, or the Declaration for International Application No. PCT/US2011/024645 (Oct. 28, 2011). |
Notification of Transmittal of the International Search Report and the Written Opinion of the International Searching Authority, or the Declaration for International Application No. PCT/US2011/024642 (Oct. 28, 2011). |
Notification of Transmittal of the International Search Report and the Written Opinion of the International Searching Authority, or the Declaration for International Application No. PCT/US2011/024621 (Oct. 28, 2011). |
Notification of Transmittal of the International Search Report and the Written Opinion of the International Searching Authority, or the Declaration for International Application No. PCT/US2011/024637 (Oct. 27, 2011). |
Notification of Transmittal of the International Search Report and the Written Opinion of the International Searching Authority, or the Declaration for International Application No. PCT/US2011/024629 (Oct. 27, 2011). |
Notification of Transmittal of the International Search Report and the Written Opinion of the International Searching Authority, or the Declaration for International Application No. PCT/US2011/024625 (Oct. 25, 2011). |
Notification of Transmittal of the International Search Report and the Written Opinion of the International Searching Authority, or the Declaration for International Application No. PCT/US2011/024611 (Oct. 20, 2011). |
Notification of Transmittal of the International Search Report and the Written Opinion of the International Searching Authority, or the Declaration for International Application No. PCT/US2011/024601 (Oct. 20, 2011). |
Notification of Transmittal of the International Search Report and the Written Opinion of the International Searching Authority, or the Declaration for International Application No. PCT/US2011/024588 (Oct. 20, 2011). |
Non-Final Official Action for U.S. Appl. No. 12/906,816 (Oct. 5, 2011). |
Jones et al., “Diameter Command Code Registration for the Third Generation Partnership Project (3GPP) Evolved Packet System (EPS),” Network Working Group, RFC 5516, pp. 1-5 (Apr. 2009). |
Final Office Action for U.S. Appl. No. 13/026,060 (May 10, 2013). |
Notice of Allowance and Fee(s) Due for U.S. Appl. No. 13/026,144 (May 1, 2013). |
Notice of Allowance and Fee(s) Due for U.S. Appl. No. 13/026,112 (Apr. 26, 2013). |
Notice of Allowance and Fee(s) Due for U.S. Appl. No. 13/026,153 (Apr. 15, 2013). |
Notice of Allowance and Fee(s) Due for U.S. Appl. No. 13/026,162 (Apr. 1, 2013). |
Supplemental Notice of Allowability for U.S. Appl. No. 13/026,031 (Mar. 22, 2013). |
Notice of Allowance and Fee(s) Due for U.S. Appl. No. 13/026,098 (Mar. 11, 2013). |
Interview Summary for U.S. Appl. No. 13/026,144 (Mar. 4, 2013). |
Supplemental Notice of Allowability for U.S. Appl. No. 13/026,162 (Feb. 27, 2013). |
Notice of Allowance and Fee(s) Due for U.S. Appl. No. 13/025,968 (Feb. 27, 2013). |
Supplemental Notice of Allowability for U.S. Appl. No. 13/026,162 (Feb. 7, 2013). |
Notice of Allowance and Fee(s) Due for U.S. Appl. No. 13/026,031 (Jan. 30, 2013). |
Supplemental Notice of Allowability for U.S. Appl. No. 13/026,162 (Jan. 24, 2013). |
Notice of Allowance and Fee(s) Due for U.S. Appl. No. 13/026,162 (Dec. 19, 2012). |
Communication of European Publication Number and Information on the Application of Article 67(3) EPC for European Patent Application No. 11742923.3 (Nov. 21, 2012). |
Communication of European Publication Number and Information on the Application of Article 67(3) EPC for European Patent Application No. 11742912.6 (Nov. 21, 2012). |
Communication of European Publication Number and Information on the Application of Article 67(3) EPC for European Patent Application No. 11742909.2 (Nov. 21, 2012). |
Communication of European Publication Number and Information on the Application of Article 67(3) EPC for European Patent Application No. 11742906.8 (Nov. 21, 2012). |
Communication of European Publication Number and Information on the Application of Article 67(3) EPC for European Patent Application No. 11742905.0 (Nov. 21, 2012). |
Communication of European Publication Number and Information on the Application of Article 67(3) EPC for European Patent Application No. 11742901.9 (Nov. 21, 2012). |
Communication of European Publication Number and Information on the Application of Article 67(3) EPC for European Patent Application No. 11742894.6 (Nov. 21, 2012). |
Final Official Action for U.S. Appl. No. 13/026,105 (Nov. 26, 2012). |
Non-Final Official Action for U.S. Appl. No. 13/026,153 (Nov. 6, 2012). |
Non-Final Official Action for U.S. Appl. No. 13/412,352 (Oct. 26, 2012). |
Non-Final Official Action for U.S. Appl. No. 13/026,144 (Oct. 16, 2012). |
Non-Final Official Action for U.S. Appl. No. 13/026,098 (Sep. 20, 2012). |
Non-Final Official Action for U.S. Appl. No. 13/026,060 (Sep. 19, 2012). |
Communication of European Publication Number and Information on the Application of Article 67(3) EPC for European Patent Application No. 11742921.7 (Sep. 12, 2012). |
Non-Final Official Action for U.S. Appl. No. 13/026,081 (Sep. 12, 2012). |
Non-Final Official Action for U.S. Appl. No. 13/026,112 (Aug. 29, 2012). |
Communication of European publication number and information on the application of Article 67(3) EPC for European Application No. 10824243.9 (Jul. 25, 2012). |
Notification of Transmittal of the International Search Report and the Written Opinion of the International Searching Authority, or the Declaration for International Patent Application No. PCT/US2012/027736 (Jun. 12, 2012). |
Advisory Action for U.S. Appl. No. 12/906,816 (Jun. 5, 2012). |
Applicant-Initiated Interview Summary for U.S. Appl. No. 12/906,816 (May 17, 2012). |
Non-Final Official Action for U.S. Appl. No. 13/026,105 (May 16, 2012). |
Traffix Systems, “Datasheet; Traffix Signaling Delivery Controller (SDC),” pp. 1-5 (May 2011). |
Number | Date | Country | |
---|---|---|---|
20110202676 A1 | Aug 2011 | US |
Number | Date | Country | |
---|---|---|---|
61304310 | Feb 2010 | US | |
61373636 | Aug 2010 | US |