Method, system, and computer-readable medium for diameter connectivity restoration - Patents.com

Abstract

A method, system, and computer-readable medium for restoring Diameter connectivity. One example of a method includes accepting a first Diameter connection with a Diameter client having a Diameter identifier. The method includes receiving a request to establish a new Diameter connection using the Diameter identifier. The method includes holding the request to establish the new Diameter connection for a particular time limit and probing the first Diameter connection while holding the request to determine whether the first Diameter connection is disconnected. In response to determining that the first Diameter connection is disconnected, the method includes abandoning the first Diameter connection and accepting a second Diameter connection with the Diameter client having the Diameter identifier.

Description

[Technical field]

[0001] Claiming priority This application claims the benefit of priority to U.S. patent application Ser. No. 17 / 491,984, filed Oct. 1, 2021, the entire disclosure of which is incorporated herein by reference.

[0002] Technical Field The subject matter described herein relates to telecommunications networks. More particularly, the subject matter described herein relates to methods, systems, and computer-readable media for restoration of Diameter connectivity. [Background technology]

[0003] background Diameter is an Authentication, Authorization, and Accounting (AAA) protocol widely used in communication core networks to convey subscriber and policy information between core network elements. Diameter operates at the application layer and uses, for example, Transmission Control Protocol (TCP) or Stream Control Transmission Protocol (SCTP) as the underlying transport protocol. A Diameter client establishes a transport connection with a server before sending a CER (Capability Exchange Request) message to initiate a Diameter connection. When the server responds with a CEA (Capability Exchange Answer) message, the Diameter connection is established.

[0004] When a Diameter client fails, reboots, or switches active nodes, it may take some time for connectivity to be restored. Delays in restoring Diameter connectivity may result in service-affecting problems for the client, such as dropped calls, loss of accounting, and authorization / accounting failures.

[0005] In view of these and other difficulties, a need exists for methods, systems, and computer-readable media for restoring Diameter connectivity. Summary of the Invention

[0006] overview A method for restoring Diameter connectivity includes accepting a first Diameter connection with a Diameter client having a Diameter identifier. The method includes receiving a request to establish a new Diameter connection using the Diameter identifier. The method includes holding the request to establish the new Diameter connection for a particular time limit and probing the first Diameter connection while holding the request to determine whether the first Diameter connection is disconnected. The method includes determining that the first Diameter connection is disconnected and, in response to determining that the first Diameter connection is disconnected, aborting the first Diameter connection and accepting a second Diameter connection with the Diameter client having the Diameter identifier.

[0007] According to other aspects of the subject matter described herein, determining that the first Diameter connection is disconnected includes determining that the first Diameter connection is disconnected before a particular time limit is reached.

[0008] According to other aspects of the subject matter described herein, probing the first Diameter connection includes sending a Diameter watchdog request to a Diameter client on the first Diameter connection.

[0009] According to other aspects of the subject matter described herein, determining that the first Diameter connection is disconnected includes receiving a reset message from the Diameter client.

[0010] According to other aspects of the subject matter described herein, the reset message is a Transmission Control Protocol (TCP) message sent as a result of the Diameter client processing a Diameter watchdog request as having been received on an unexpected connection.

[0011] According to other aspects of the subject matter described herein, establishing the first Diameter connection includes creating a first peer state machine for the first Diameter connection using the Diameter identifier.

[0012] According to other aspects of the subject matter described herein, aborting the first Diameter connection and establishing the second Diameter connection includes resuming processing of requests to establish new Diameter connections by creating a second peer state machine after cleaning up the first peer state machine.

[0013] In accordance with other aspects of the subject matter described herein, Diameter clients are deployed in a highly available configuration comprising an active node and one or more standby nodes configured to take over the active role in response to a failure of the active node.

[0014] According to another aspect of the subject matter described herein, a particular time limit for holding a request to establish a new Diameter connection is less than a Diameter transaction timeout.

[0015] According to other aspects of the subject matter described herein, establishing the first Diameter connection includes receiving a Capability Exchange Request (CER) message on the transport connection after establishing the transport connection.

[0016] According to another aspect of the subject matter described herein, a system for restoring Diameter connectivity includes at least one processor and a memory. The system further includes a Diameter server implemented by the at least one processor and configured to: accept a first Diameter connection with a Diameter client having a Diameter identifier, receive a request to establish a new Diameter connection using the Diameter identifier, hold the request to establish the new Diameter connection for a certain time limit, and while holding the request, probe the first Diameter connection to determine whether the first Diameter connection is down, determine that the first Diameter connection is down, and in response to determining that the first Diameter connection is down, discontinue the first Diameter connection and accept a second Diameter connection with the Diameter client having the Diameter identifier.

[0017] According to other aspects of the subject matter described herein, determining that the first Diameter connection is disconnected includes determining that the first Diameter connection is disconnected before a particular time limit is reached.

[0018] According to other aspects of the subject matter described herein, probing the first Diameter connection includes sending a Diameter watchdog request to a Diameter client on the first Diameter connection.

[0019] According to other aspects of the subject matter described herein, determining that the first Diameter connection is disconnected includes receiving a reset message from the Diameter client.

[0020] According to other aspects of the subject matter described herein, the reset message is a Transmission Control Protocol (TCP) message sent as a result of the Diameter client processing a Diameter watchdog request as being received on an unexpected connection.

[0021] According to other aspects of the subject matter described herein, establishing the first Diameter connection includes creating a first peer state machine for the first Diameter connection using the Diameter identifier.

[0022] According to other aspects of the subject matter described herein, aborting the first Diameter connection and establishing the second Diameter connection includes resuming processing of requests to establish new Diameter connections by creating a second peer state machine after cleaning up the first peer state machine.

[0023] In accordance with other aspects of the subject matter described herein, Diameter clients are deployed in a highly available configuration comprising an active node and one or more standby nodes configured to take over the active role in response to a failure of the active node.

[0024] According to another aspect of the subject matter described herein, a particular time limit for holding a request to establish a new Diameter connection is less than a Diameter transaction timeout.

[0025] According to other aspects of the subject matter described herein, establishing the first Diameter connection includes receiving a Capability Exchange Request (CER) message on the transport connection after establishing the transport connection.

[0026] According to another aspect of the subject matter described herein, a non-transitory computer-readable medium having stored thereon executable instructions that, when executed by a processor of a computer, control the computer to perform steps including accepting a first Diameter connection with a Diameter client having a Diameter identifier, receiving a request to establish a new Diameter connection using the Diameter identifier, holding the request to establish the new Diameter connection for a particular time limit and probing the first Diameter connection while holding the request to determine whether the first Diameter connection is disconnected, and determining that the first Diameter connection is disconnected and, in response to determining that the first Diameter connection is disconnected, aborting the first Diameter connection and accepting a second Diameter connection with the Diameter client having the Diameter identifier.

[0027] The subject matter described herein can be realized in software combined with hardware and / or firmware. For example, the subject matter described herein can be realized in software executed by a processor. In one exemplary implementation, the subject matter described herein can be realized using a computer-readable medium having computer-executable instructions stored thereon that, when executed by a processor of a computer, control a computer to perform steps.

[0028] Exemplary computer-readable media suitable for implementing the subject matter described herein include non-transitory devices such as disk memory devices, chip memory devices, programmable logic devices, and application specific integrated circuits. Additionally, computer-readable media implementing the subject matter described herein may be located on a single device or computing platform or may be distributed across multiple devices or computing platforms.

[0029] The subject matter described herein will now be described with reference to the accompanying drawings. [Brief description of the drawings]

[0030] [Figure 1] A message flow diagram showing messages sent between a Diameter server and a Diameter client. [Diagram 2] A message flow diagram illustrating an example situation in which a Diameter client completes restart before the Diameter server determines that the Diameter client is unreachable over the old connection. [Diagram 3] A message flow diagram illustrating an example situation in which the Diameter server does not immediately determine that the Diameter connection is disconnected after the Diameter client resumes service. [Figure 4] FIG. 13 is a message flow diagram illustrating an example of a high availability configuration. [Diagram 5] FIG. 13 is a message flow diagram showing restoration of Diameter connectivity. [Figure 6] 1 is a flow diagram of an example method for restoring Diameter connectivity. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0031] Detailed Description The subject matter described herein relates to methods, systems, and computer-readable media for restoring Diameter connectivity.

[0032] Diameter is an Authentication, Authorization, and Accounting (AAA) protocol widely used in communication core networks to convey subscriber and policy information between core network elements. Diameter operates at the application layer and uses, for example, Transmission Control Protocol (TCP) or Stream Control Transmission Protocol (SCTP) as the underlying transport protocol. A Diameter client establishes a transport connection with a server before sending a CER (Capability Exchange Request) message to initiate a Diameter connection. When the server responds with a CEA (Capability Exchange Answer) message, the Diameter connection is established.

[0033] Typically, Diameter connections are persistent in nature, i.e., they remain established for extended periods of time, such as weeks, months, or years. Diameter network elements (or nodes) maintain a peer state machine for each peer to which they are connected. Diameter network elements continuously monitor the health of the underlying transport connections and the liveness of peer applications, so that they can take appropriate action as soon as they detect a problem, such as a connection becoming unstable / terminated or a peer application becoming slow / halted. A Diameter application response from a peer node is taken as an assurance that the peer application is reachable and alive.

[0034] However, if there is not enough signaling to send on a connection, Diameter nodes use the application layer watchdog, DWR / DWA (Diameter Watchdog Request / Answer), to detect transport or application layer failures in a timely manner. The time to wait before sending a watchdog message is controlled by a configurable timer, Tw, which is initially set in Twinit.

[0035] Per RFC3539, the recommended value in Twinit is 30 seconds and must not be set lower than 6 seconds minus the random jitter value. There is another timer (Tc) that controls the frequency of transport connection attempts to peers with no active transport connection. Per RFC6733, the recommended value for Tc is also 30 seconds.

[0036] Consider an example situation where two Diameter nodes A, B have a Diameter connection established between them. When node A is about to close the connection, or when node A goes out of service in a graceful manner, node A is expected to send a Disconnect-Peer-Request (DPR) message to node B.

[0037] However, if node A suddenly becomes unavailable (e.g., node A shuts down), it cannot send a DPR. As a result, node B continues to assume that node A is still alive. If node B does not see a response on this connection for Tw duration, it sends a DWR to node A. If node A is still not alive, this DWR is lost. After waiting for a further Tw duration, node B finally infers that node A is no longer in service, cleans up its peer state machine, and closes the transport connection.

[0038] An example of this is shown in Figure 1. As shown in Figure 1, it may take a Diameter node up to twice the maximum Tw time to detect a broken connection. Some implementations send the DWR several more times before declaring the peer dead or unreachable.

[0039] Figure 1 is a message flow diagram illustrating messages sent between the Diameter Server 102 and the Diameter Client 104. The Diameter Server 102 and the Diameter Client 104 may each be implemented on a computer system comprising at least one processor and memory. Figure 1 illustrates a scenario in which the Diameter Server 102 determines that the connection is lost before the Diameter Client 104 completes the restart.

[0040] The Diameter client 104 sends message 106 to initiate a new transport connection with the Diameter server 102 at the transport layer 108. The Diameter client 104 then sends a request message 110 to establish a Diameter connection with the Diameter server 102. The request message 110 can be, for example, a Capabilities Exchange Request (CER) message with a Diameter identifier at the Diameter client 104. The Diameter identifier can be, for example, Origin-Host OH1.

[0041] The Diameter server 102 establishes a Diameter connection by creating 112 a peer state machine 114 for the connection. The state machine 114 can change state between Closed and Open. The state machine 114 is associated with a Diameter identifier, Origin-Host OH1, in the Diameter client 104.

[0042] The Diameter server 102 responds to the request message 110 with a response message 116, e.g., a Capabilities Exchange Answer (CEA). The request message 116 is sent 118 to the Diameter client via the transport layer 108. The Diameter client 104 can then exchange various Diameter messages 120 with the Diameter server 102, e.g., messages for operating a core network of a telecommunications network.

[0043] The Diameter client 104 then begins to restart (122). The Diameter client 104 can initiate a restart for any of a variety of reasons. However, the Diameter client 104 does not restart normally in that it does not send a message to the Diameter server 102 to close the Diameter connection.

[0044] At the same time, a watchdog timer 124 is running since the last exchange of Diameter message 120. When the watchdog timer 124 expires, it sends message 126 to state machine 114, which responds by sending DWR message 128. A Diameter send timer 130 starts running. The DWR message 128 is then sent 132 by the transport layer 108 to the Diameter client 104.

[0045] However, the Diameter client 104 is still restarting (122). Therefore, the Diameter client 104 does not receive or respond to the DWR message 132, and the message is lost. When the send timer 130 expires, it sends a message 134 (e.g., R-Peer-Disc) to the state machine 114.

[0046] The state machine 114 determines that the Diameter connection is down in response to not receiving a DWA message before the transmission timer 130 expires. The Diameter server 102 releases (136) the computing resources reserved for the Diameter connection and deletes (138) the state machine 114.

[0047] The Diameter client 104 then completes the restart (122) and sends a new message 140 to establish the transport layer connection. The Diameter client 104 sends a request message 142 to establish the Diameter connection, e.g., a CER message with Origin-Host=OH1. The Diameter server 102 creates a new Diameter connection (144) by creating a new OH1 state machine 146. The state machine 146 sends a response message 148, e.g., a CEA message. The Diameter server 102 sends the response message 150 using the transport layer 108.

[0048] As a variation of the above scenario, node A may restart and come back into service before node B can determine that node A is no longer reachable over the old connection. In this case, if node A receives a DWR (or any other message) from node B over the old connection, it will no longer recognize the connection and will immediately reset / abort the old transport connection (e.g., by sending a TCP RST bit). Thus, node B will determine that the connection is torn down as soon as node A sends the first message after coming back into service. Upon receiving the reset indication, node B will clean up its "old" Diameter peer state machine. This scenario is illustrated in Figure 2.

[0049] FIG. 2 is a message flow diagram illustrating an example situation in which a Diameter client 104 completes a restart before the Diameter server 102 determines that the Diameter client 104 is unreachable over the old connection.

[0050] The Diameter client 104 sends message 106 to initiate a new transport connection with the Diameter server 102 at the transport layer 108. The Diameter client 104 then sends a request message 110 to establish a Diameter connection with the Diameter server 102. The request message 110 can be, for example, a Capabilities Exchange Request (CER) message with a Diameter identifier at the Diameter client 104. The Diameter identifier can be, for example, Origin-Host OH1.

[0051] The Diameter server 102 establishes a Diameter connection by creating 112 a peer state machine 114 for the connection. The state machine 114 can change state between Closed and Open. The state machine 114 is associated with a Diameter identifier, Origin-Host OH1, in the Diameter client 104.

[0052] The Diameter server 102 responds to the request message 110 with a response message 116, e.g., a Capabilities Exchange Answer (CEA). The request message 116 is sent 118 to the Diameter client via the transport layer 108. The Diameter client 104 can then exchange various Diameter messages 120 with the Diameter server 102, e.g., messages for operating a core network of a telecommunications network.

[0053] The Diameter client 104 then begins to restart (122). The Diameter client 104 can initiate a restart for any of a variety of reasons. However, the Diameter client 104 does not restart normally in that it does not send a message to the Diameter server 102 to close the Diameter connection.

[0054] At the same time, a watchdog timer 124 runs from the last exchange of Diameter message 120. When the watchdog timer 124 expires, it sends message 126 to the state machine 114, which responds by sending a DWR message 128. The DWR message 128 is then sent (132) by the transport layer 108 to the Diameter client 104.

[0055] The Diameter client 104 completes the restart (122) and receives a DWR message 132. The Diameter client 104 does not recognize the old connection and in response resets / aborts the old transport connection by sending a message 202, e.g., a TCP RST bit.

[0056] The Diameter server 102 receives (206) the message 202. The Diameter server 102 releases (208) the computing resources reserved for the Diameter connection and deletes (210) the state machine 114.

[0057] The Diameter client 104 sends a new message 212 to establish a transport layer connection. The Diameter client 104 sends a request message 214, e.g., a CER message with Origin-Host=OH1, to establish a Diameter connection. The Diameter server 102 creates (216) the new Diameter connection by creating a new OH1 state machine 218. The state machine 218 sends a response message 220, e.g., a CEA message. The Diameter server 102 sends (222) the response message 220 using the transport layer 108.

[0058] Consider another example situation where Node B is a Diameter server and has little (or no) signaling to send to Node A (the client) except for DWR, which it sends according to the configured Tw interval. In this case, even after the client node comes back into service, the server does not immediately realize that the previous connection is broken. Even worse, the server will reject any new Diameter connection requests (CERs) sent by the client after the restart.

[0059] This is because, upon receipt of a CER message, the server checks whether there is an existing peer state machine for the same Origin-Host. According to RFC6733, if the server finds an existing connection in R-open state (i.e., established state) with the same peer (identified by the Origin-Host in the CER), the server MUST reject the CER and drop the transport connection over which the CER was received. The client is then expected to retry the connection after the Tc timer interval. This scenario is illustrated in Figure 3.

[0060] FIG. 3 is a message flow diagram illustrating an example situation in which the Diameter server 102 does not immediately determine that the Diameter connection is disconnected after the Diameter client 104 resumes service.

[0061] The Diameter client 104 sends message 106 to initiate a new transport connection with the Diameter server 102 at the transport layer 108. The Diameter client 104 then sends a request message 110 to establish a Diameter connection with the Diameter server 102. The request message 110 can be, for example, a Capabilities Exchange Request (CER) message with a Diameter identifier at the Diameter client 104. The Diameter identifier can be, for example, Origin-Host OH1.

[0062] The Diameter server 102 establishes a Diameter connection by creating 112 a peer state machine 114 for the connection. The state machine 114 can change state between Closed and Open. The state machine 114 is associated with a Diameter identifier, Origin-Host OH1, in the Diameter client 104.

[0063] The Diameter server 102 responds to the request message 110 with a response message 116, e.g., a Capabilities Exchange Answer (CEA). The request message 116 is sent 118 to the Diameter client via the transport layer 108. The Diameter client 104 can then exchange various Diameter messages 120 with the Diameter server 102, e.g., messages for operating a core network of a telecommunications network.

[0064] The Diameter client 104 then begins to restart (122). The Diameter client 104 can initiate a restart for any of a variety of reasons. However, the Diameter client 104 does not restart normally, in that it does not send a message to the Diameter server 102 to close the Diameter connection. A watchdog timer 124 has been running since the last exchange of Diameter messages 120.

[0065] When the Diameter client 104 resumes service, it sends message 302 to establish a new transport connection. The Diameter client 104 sends a request message 304, e.g., a CER message with Origin-Host=OH1. The Diameter server 102 finds (306) that there is an existing state machine 114 with the same identifier, Origin-Host=OH1. In response, the Diameter server 102 rejects the request message 304, initiates (308) the teardown of the transport connection, and sends a Close Transport Connection message 310.

[0066] When the watchdog timer 124 expires, the watchdog timer 124 sends a message 312 to the state machine 114, which responds by sending a DWR message 314. The DWR message 314 is then sent (316) by the transport layer 108 to the Diameter client 104.

[0067] In response, the Diameter client 104 sends a message 318 to reset the transport connection. The Diameter server 102 receives the message 318, for example, as an R-Peer-Disc message 320. The Diameter server 102 deletes 322 the state machine 114 and releases the computing resources.

[0068] When the Tc timer expires, the Diameter client 104 sends a new message 324 to establish a transport layer connection. The Diameter client 104 sends a request message 326, e.g., a CER message with Origin-Host=OH1, to establish a Diameter connection. The Diameter server 102 creates (328) a new Diameter connection by creating a new OH1 state machine 330. The state machine 330 sends a response message 332, e.g., a CEA message. The Diameter server 102 sends (334) the response message 332 using the transport layer 108.

[0069] Delays in restoring Diameter connectivity can result in service-affecting problems for clients, such as dropped calls, loss of accounting, and authorization / accounting failures.

[0070] This issue is more likely when clients are deployed in a HA (High Availability, e.g. 1+1, n+1, or n+k) configuration compared to when they are deployed as standalone nodes. This is because a standalone client node typically takes tens of seconds (sometimes minutes) to resume service after a reboot, and therefore it is very likely that by that time the server will have detected the broken connection (through the watchdog failure mechanism shown in Figure 1). Thus, the connection is almost always restored as soon as the client is back in service.

[0071] In an HA configuration, when the active node fails, one of the standby nodes takes over the active role within a few seconds or even less (hereafter referred to as "switchover"). Since the switchover time is much shorter than the Tw timer value, the client tries to re-establish the Diameter connection well before the server can send the next DWR on the old connection and detect the loss of the connection. In other words, even if the client is operational immediately after the switchover (e.g. within 2 seconds), there may be a long delay before the connection is restored. This scenario is illustrated in Figure 4.

[0072] 4 is a message flow diagram illustrating an example of a high availability configuration. The Diameter client 104 includes an active node 402 and a standby node 404.

[0073] The Diameter client 104 uses node 402 to send message 106 initiating a new transport connection with the Diameter server 102 at the transport layer 108. The Diameter client 104 then sends a request message 110 to establish a Diameter connection with the Diameter server 102. The request message 110 can be, for example, a Capabilities Exchange Request (CER) message with a Diameter identifier at the Diameter client 104. The Diameter identifier can be, for example, Origin-Host OH1.

[0074] The Diameter server 102 establishes a Diameter connection by creating 112 a peer state machine 114 for the connection. The state machine 114 can change state between Closed and Open. The state machine 114 is associated with a Diameter identifier, Origin-Host OH1, in the Diameter client 104.

[0075] The Diameter server 102 responds to the request message 110 with a response message 116, e.g., a Capabilities Exchange Answer (CEA). The request message 116 is sent 118 to the Diameter client via the transport layer 108. The Diameter client 104 can then exchange various Diameter messages 120 with the Diameter server 102, e.g., messages for operating a core network of a telecommunications network.

[0076] The Diameter client 104 then initiates a switchover 406 from the active node 402 to the standby node 404, and the standby node 404 becomes active. The Diameter client 104 may initiate a switchover for any of a variety of reasons: The Diameter client 104 does not send a message to the Diameter server 102 to close the Diameter connection. The watchdog timer 124 has been running since the last exchange of Diameter messages 120.

[0077] When the Diameter client 104 resumes service using the currently active node 404, the Diameter client 104 sends a message 302 to establish a new transport connection. The Diameter client 104 sends a request message 304, e.g., a CER message with Origin-Host=OH1. The Diameter server 102 finds (306) that there is an existing state machine 114 with the same identifier, Origin-Host=OH1. In response, the Diameter server 102 rejects the request message 304, initiates (308) the teardown of the transport connection, and sends a Close Transport Connection message 310.

[0078] When the watchdog timer 124 expires, the watchdog timer 124 sends a message 312 to the state machine 114, which responds by sending a DWR message 314. The DWR message 314 is then sent (316) by the transport layer 108 to the Diameter client 104.

[0079] In response, the Diameter client 104 sends a message 318 to reset the transport connection. The Diameter server 102 receives the message 318, for example, as an R-Peer-Disc message 320. The Diameter server 102 deletes 322 the state machine 114 and releases the computing resources.

[0080] When the Tc timer expires, the Diameter client 104 sends a new message 324 to establish a transport layer connection. The Diameter client 104 sends a request message 326, e.g., a CER message with Origin-Host=OH1, to establish a Diameter connection. The Diameter server 102 creates (328) a new Diameter connection by creating a new OH1 state machine 330. The state machine 330 sends a response message 332, e.g., a CEA message. The Diameter server 102 sends (334) the response message 332 using the transport layer 108.

[0081] When a connection request is rejected, there may be a delay in restoring Diameter connectivity if the client waits for another Tc timer to expire before initiating a new request. This delay can be mitigated by having the Diameter server detect a broken stale connection with a client as soon as it receives the first CER on a new connection from the same client. This allows the server to immediately clean up the stale peer state machine and accept a new connection without waiting for the next watchdog timeout and without incurring any additional overhead.

[0082] When a Diameter server finds an existing peer state machine corresponding to the Origin-Host received in a CER, the Diameter server can determine if this CER is the result of a client restart or switchover by doing the following:

[0083] - The server SHALL conditionally hold the CER processing for a maximum time limit "Hold-cer-timer" (e.g., 200 ms), which is much shorter than the typical transaction timeouts used in Diameter (on the order of a few seconds).

[0084] - The server SHALL send a DWR on the old connection immediately, or as soon as possible.

[0085] -The server has already received a CER request from the client, so it expects the client application to be back in service and ready to receive a DWR.

[0086] -If this is a client switchover case, DWR will reach the new active node as it uses the same public IP as the previous active node.

[0087] -If this is a standalone client restart, DWR will reach the original client node.

[0088] -In either case, the client SHOULD treat this as an unexpected message on the connection and immediately reset / abort the connection (e.g., by sending back a TCP RST). This indication should generally reach the server within a few milliseconds (0-10 ms).

[0089] Upon receiving this reset indication, the server's transport layer will notify the application immediately (or as soon as possible) and the application will clean up its peer state machine.

[0090] -These steps occur almost instantly, so the server will resume CER processing well before the hold-cer-timer expires. Since the original state machine no longer exists, the server will proceed as if this was a new connection request from a new client and will accept the connection.

[0091] - If the server receives a DWA within the hold-cer-timer duration, this indicates that the old connection is still alive, so the server shall behave as it does now, i.e., reject the new CER and drop the new connection.

[0092] -If for some reason the server does not receive a DWA or transport reset indication within the hold-cer-timer limit (e.g., the client is suffering from a rolling reboot or back-to-back switchover), the server rejects the CER and drops the new connection. In other words, it is no worse than the traditional approach, except that it waits a short time (e.g., 200 ms) before rejecting the CER.

[0093] In summary, this approach allows the server to determine if a client has restarted or switched over and accept new connection requests accordingly without further delay. This improves the speed at which Diameter connectivity is restored compared to blindly rejecting client connection attempts after a restart / switchover. This approach is illustrated in Figure 5.

[0094] FIG. 5 is a message flow diagram illustrating restoration of Diameter connectivity. The Diameter client 104 sends message 106 to initiate a new transport connection with the Diameter server 102 at the transport layer 108. The Diameter client 104 then sends a request message 110 to establish a Diameter connection with the Diameter server 102. The request message 110 can be, for example, a Capabilities Exchange Request (CER) message with a Diameter identifier at the Diameter client 104. The Diameter identifier can be, for example, Origin-Host OH1.

[0095] The Diameter server 102 establishes a Diameter connection by creating 112 a peer state machine 114 for the connection. The state machine 114 can change state between Closed and Open. The state machine 114 is associated with a Diameter identifier, Origin-Host OH1, in the Diameter client 104.

[0096] The Diameter server 102 responds to the request message 110 with a response message 116, e.g., a Capabilities Exchange Answer (CEA). The request message 116 is sent 118 to the Diameter client via the transport layer 108. The Diameter client 104 can then exchange various Diameter messages 120 with the Diameter server 102, e.g., messages for operating a core network of a telecommunications network.

[0097] The Diameter client 104 then initiates a switchover 406 from the active node 402 to the standby node 404, which then becomes active. The Diameter client 104 may initiate a switchover for any of a variety of reasons: The Diameter client 104 does not send a message to the Diameter server 102 to close the Diameter connection. The watchdog timer 124 has been running since the last exchange of Diameter messages 120.

[0098] When the Diameter client 104 resumes service with the currently active node 404, the Diameter client 104 sends a message 302 to establish a new transport connection. The Diameter client 104 sends a request message 304, e.g., a CER message with Origin-Host=OH1. The Diameter server 102 finds (306) that there is an existing state machine 114 with the same identifier, Origin-Host=OH1.

[0099] Instead of rejecting the request message 304, the Diameter server 102 probes the Diameter connection by sending a DWR message 502. The Diameter client 104 receives the DWR message 504 and treats it as an unexpected message on the connection by sending back a message 506 to reset / abort the connection (e.g., sending back a TCP RST). The transport layer 108 notifies the Diameter application of the message 508. The Diameter server 102 deletes (510) the state machine 114 and releases the computing resources used for the Diameter connection.

[0100] The Diameter server 102 then creates (512) a new Diameter connection by creating a new peer state machine 514. The Diameter server resumes CER processing, sends a CEA message 516, and the transport layer 108 sends message 518 to the Diameter client 104 to complete the establishment of the new Diameter connection.

[0101] The solution proposed here provides an efficient way for the server to reliably determine client switchover / restart and restore connectivity without wasting time, and limits the scope of impact by sending DWR on affected connections and when a possible restart / switchover (at the client) is suspected.

[0102] 6 is a flow diagram of an example method 600 for restoring Diameter connectivity. Method 600 can be performed by any suitable Diameter node, such as a Diameter server. In some examples, Diameter clients are deployed in a high availability configuration having an active node and one or more standby nodes configured to take over the active role in response to a failure of the active node.

[0103] The method 600 includes establishing 602 a first Diameter connection with a Diameter client having a Diameter identifier. For example, the Diameter client and server can exchange CER / CEA messages. Establishing the first Diameter connection can include creating a first peer state machine for the first Diameter connection using the Diameter identifier. The Diameter client and server may exchange Diameter messages on the first Diameter connection for some time before the Diameter client restarts (e.g., restarts or switches over to a new active node).

[0104] The method 600 includes receiving 604 a request to establish a new Diameter connection using the Diameter identifier. The method 600 includes holding 606 the request to establish the new Diameter connection for a particular time limit and probing the first Diameter connection while holding the request to determine if the first Diameter connection is disconnected. Probing the first Diameter connection may include sending a Diameter watchdog request to a Diameter client on the first Diameter connection. The particular time limit for holding the request to establish a new Diameter connection may be, for example, less than or significantly less than a Diameter transaction timeout.

[0105] The method 600 includes determining 608 that the first Diameter connection is down. Determining that the first Diameter connection is down can include determining that the first Diameter connection is down before a particular time limit is reached. Determining that the first Diameter connection is down can include receiving a reset message from a Diameter client. The reset message can be a Transmission Control Protocol (TCP) message sent as a result of the Diameter client processing a Diameter watchdog request as being received on an unexpected connection.

[0106] The method 600 includes, in response to determining that the first Diameter connection is disconnected, aborting the first Diameter connection and establishing a second Diameter connection with a Diameter client having the Diameter identifier 610. Aborting the first Diameter connection and establishing the second Diameter connection can include cleaning up the first peer state machine and creating a second peer state machine to resume processing requests to establish new Diameter connections.

[0107] The scope of the present disclosure includes any feature or combination of features (either explicit or implicit) disclosed herein, or generalization of the disclosed features, regardless of whether such feature or generalization alleviates some or all of the problems described herein. Accordingly, new claims may be made during prosecution of this application (or an application claiming priority to this application) to any such combination of features.

[0108] In particular, with reference to the appended claims, features of the dependent claims may be combined with features of the independent claims, and features of each independent claim may be combined in any suitable manner and not merely in the specific combinations recited in the appended claims.

Claims

1. 1. A method for restoring Diameter connectivity, comprising: accepting a first Diameter connection with a Diameter client having a Diameter identifier; receiving a request to establish a new Diameter connection using the Diameter identifier; maintaining the request to establish a new Diameter connection for a specified time limit, and probing the first Diameter connection while maintaining the request to determine whether the first Diameter connection has been disconnected; determining that the first Diameter connection is down, and in response to determining that the first Diameter connection is down, abandoning the first Diameter connection and accepting a second Diameter connection with the Diameter client having the Diameter identifier; The method includes:

2. The method of claim 1 , wherein determining that the first Diameter connection is down comprises determining that the first Diameter connection is down before the particular time limit is reached.

3. 2. The method of claim 1, wherein probing the first Diameter connection comprises sending a Diameter watchdog request to the Diameter client on the first Diameter connection.

4. The method of claim 3 , wherein determining that the first Diameter connection is disconnected comprises receiving a reset message from the Diameter client.

5. 5. The method of claim 4, wherein the reset message is a Transmission Control Protocol (TCP) message sent as a result of the Diameter client treating the Diameter watchdog request as having been received on an unexpected connection.

6. 2. The method of claim 1, wherein establishing the first Diameter connection includes creating a first peer state machine for the first Diameter connection using the Diameter identifier.

7. 7. The method of claim 6, wherein abandoning the first Diameter connection and establishing the second Diameter connection includes restarting processing of the request to establish the new Diameter connection by creating a second peer state machine after cleaning up the first peer state machine.

8. 2. The method of claim 1, wherein the Diameter client is deployed in a highly available configuration comprising an active node and one or more standby nodes configured to take over an active role in response to a failure of the active node.

9. 2. The method of claim 1, wherein the particular time limit for holding the request to establish a new Diameter connection is less than a Diameter transaction timeout.

10. 2. The method of claim 1, wherein establishing the first Diameter connection comprises receiving a capabilities exchange request (CER) message on the transport connection after establishing a transport connection.

11. 1. A system for restoring Diameter connectivity, comprising: at least one processor and memory; a Diameter server implemented by said at least one processor and configured to execute the method according to any one of claims 1 to 10; A system comprising:

12. A program comprising executable instructions which, when executed by a processor of a computer, control the computer to perform a method according to any one of claims 1 to 10.

Images