Method, system, and computer-readable medium for restoring Diameter connectivity

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] Claim of Priority This application claims the benefit of priority of U.S. Patent Application No. 17 / 491,984, filed on October 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 the recovery of Diameter connectivity.

Background Art

[0003] Background Diameter is an Authentication, Authorization, and Accounting (AAA) protocol widely used in communication core networks to transfer 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, restarts, or switches active nodes, it may take time for the connection to be restored. Delayed recovery of Diameter connectivity can cause problems that affect services at the client, such as call drops, accounting losses, and authorization / accounting failures.

[0005] Considering these and other difficulties, there is a need for methods, systems, and computer-readable media to restore Diameter connectivity. [Overview of the project]

[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 a new Diameter connection for a specified time limit, and while holding the request, examining the first Diameter connection to determine whether the first Diameter connection has been disconnected. The method determines that the first Diameter connection has been disconnected, and in response to this determination, includes terminating the first Diameter connection and accepting a second Diameter connection with a Diameter client having a Diameter identifier.

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

[0008] According to other aspects of the subject matter described herein, examining a 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 a 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, a reset message is a Transmission Control Protocol (TCP) message sent as a result of a Diameter client treating a Diameter watchdog request as having been received on an unexpected connection.

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

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

[0013] According to other aspects of the subject matter described herein, the Diameter client is 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 other aspects of the subject matter described herein, the specific time limit for holding a request to establish a new Diameter connection is less than the Diameter transaction timeout.

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

[0016] According to other aspects of the subject matter described herein, a system for restoring Diameter connectivity includes at least one processor and memory. The system further includes a Diameter server, implemented by at least one processor, 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 a new Diameter connection for a specified time limit, examine the first Diameter connection while holding the request to determine whether the first Diameter connection has been disconnected, determine that the first Diameter connection has been disconnected, and in response to the determination that the first Diameter connection has been disconnected, terminate the first Diameter connection and accept a second Diameter connection with a Diameter client having a Diameter identifier.

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

[0018] According to other aspects of the subject matter described herein, examining a 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 a 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, a reset message is a Transmission Control Protocol (TCP) message sent as a result of a Diameter client treating a Diameter watchdog request as having been received on an unexpected connection.

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

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

[0023] According to other aspects of the subject matter described herein, the Diameter client is 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 other aspects of the subject matter described herein, the specific time limit for holding a request to establish a new Diameter connection is less than the Diameter transaction timeout.

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

[0026] According to other aspects of the subject matter described herein, there is provided a non - transient computer - readable medium storing executable instructions that, when executed by a computer's processor, control the computer to perform steps. The steps include receiving 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 specific time limit, and while holding the request, scrutinizing the first Diameter connection to determine whether the first Diameter connection has been disconnected, determining that the first Diameter connection has been disconnected, and in response to the determination that the first Diameter connection has been disconnected, terminating the first Diameter connection and receiving a second Diameter connection with a Diameter client having the Diameter identifier.

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

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

[0029] Reference will now be made in detail to the accompanying drawings in connection with the subject matter described herein.

Brief Description of the Drawings

[0030] [Figure 1] It is a message flow diagram showing messages transmitted between a Diameter server and a Diameter client. [Figure 2] It is a message flow diagram showing an exemplary situation where the Diameter client completes restart before the Diameter server determines that the Diameter client is unreachable on an old connection. [Figure 3] It is a message flow diagram showing an exemplary situation where the Diameter server does not immediately determine that the Diameter connection is disconnected after the Diameter client resumes service. [Figure 4] It is a message flow diagram showing an example of a high availability configuration. [Figure 5] It is a message flow diagram showing the recovery of Diameter connectivity. [Figure 6] It is a flowchart of an exemplary method for recovering Diameter connectivity.

Modes for Carrying Out the Invention

[0031] Detailed Description The subject matter described herein relates to a method, system, and computer-readable medium for recovering Diameter connectivity.

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

[0033] Typically, Diameter connections are inherently persistent, meaning they remain established for extended periods, such as weeks, months, or years. Diameter network elements (or nodes) maintain a peer state machine for each peer they connect to. Diameter network elements continuously monitor the health of the underlying transport connection and the operational status of peer applications, allowing them to take appropriate action as soon as they detect problems such as unstable / terminating connections or slow / stopped peer applications. Diameter application responses from peer nodes are considered confirmation that the peer application is reachable and alive.

[0034] However, if there is insufficient signaling to send over the connection, the Diameter node uses the application layer watchdog DWR / DWA (Diameter Watchdog Request / Answer) to timely detect transport or application layer failures. The waiting time before sending a watchdog message is controlled by a configurable timer Tw, which is initially set in Twinit.

[0035] According to RFC3539, the recommended value in Twinit is 30 seconds and should not be set to a value less than 6 seconds minus the random jitter value. There is another timer (Tc) that controls the frequency of transport connection attempts to peers that do not have an active transport connection. According to RFC6733, the recommended value for Tc is also 30 seconds.

[0036] Consider an example scenario where two Diameter nodes, A and B, have a Diameter connection established between them. If node A is to close the connection, or if node A ceases service in a normal 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), Node A cannot send a DPR. As a result, Node B continues to assume that Node A is still alive. If Node B does not encounter a response over the Tw duration on this connection, Node B sends a DWR to Node A. If Node A is still not operational, this DWR is lost. After waiting for another 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] This example is shown in Figure 1. As shown in Figure 1, it may take twice the maximum Tw time for a Diameter node to detect a disconnected connection. Some implementations send several more DWRs before declaring the peer dead or unreachable.

[0039] Figure 1 is a message flow diagram showing messages sent between Diameter server 102 and Diameter client 104. Diameter server 102 and Diameter client 104 can each be implemented on a computer system having at least one processor and memory. Figure 1 shows a scenario in which Diameter server 102 determines that the connection is lost before Diameter client 104 has completed its 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. Subsequently, the Diameter client 104 sends request message 110 to establish a Diameter connection with the Diameter server 102. Request message 110 may be, for example, a Function Exchange Request (CER) message with a Diameter identifier in the Diameter client 104. The Diameter identifier may be, for example, Origin-Host OH1.

[0041] The Diameter server 102 establishes a Diameter connection by creating a peer state machine 114 for the connection. The state machine 114 can change its state between a closed state and an open state. The state machine 114 is associated with the 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, for example, a Function Exchange Response (CEA). The request message 116 is sent to the Diameter client via the transport layer 108 (118). The Diameter client 104 can then exchange various Diameter messages 120, for example, messages to operate the core network of a telecommunications network, with the Diameter server 102.

[0043] Subsequently, the Diameter client 104 begins to restart (122). The Diameter client 104 may start restarting for any of the following reasons. However, the Diameter client 104 does not restart properly in that it does not send a message to the Diameter server 102 to close the Diameter connection.

[0044] Simultaneously, a watchdog timer 124 has been running since the last exchange of Diameter messages 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 Diameter send timer 130 begins to operate. Subsequently, the DWR message 128 is sent to the Diameter client 104 by the transport layer 108 (132).

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

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

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

[0048] As a variation of the scenario described above, Node A may restart and return to service before Node B can determine that the old connection is unreachable. In this case, Node A will no longer recognize the old connection if it receives a DWR (or other message) from Node B on the old connection, and therefore immediately resets / aborts the old transport connection (for example, by sending a TCP RST bit). Thus, Node B will determine that the connection is broken as soon as it sends the first message after Node A resumes service. Upon receiving the reset instruction, Node B cleans up the "old" Diameter peer state machine. This scenario is illustrated in Figure 2.

[0049] Figure 2 is a message flow diagram illustrating an exemplary scenario in which the Diameter client 104 completes its restart before the Diameter server 102 determines that the Diameter client 104 is unreachable via 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. Subsequently, the Diameter client 104 sends request message 110 to establish a Diameter connection with the Diameter server 102. Request message 110 may be, for example, a Function Exchange Request (CER) message with a Diameter identifier in the Diameter client 104. The Diameter identifier may be, for example, Origin-Host OH1.

[0051] The Diameter server 102 establishes a Diameter connection by creating a peer state machine 114 for the connection. The state machine 114 can change its state between a closed state and an open state. The state machine 114 is associated with the 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, for example, a Function Exchange Response (CEA). The request message 116 is sent to the Diameter client via the transport layer 108 (118). The Diameter client 104 can then exchange various Diameter messages 120, for example, messages to operate the core network of a telecommunications network, with the Diameter server 102.

[0053] Subsequently, the Diameter client 104 begins to restart (122). The Diameter client 104 may start restarting for any of the following reasons. However, the Diameter client 104 does not restart properly in that it does not send a message to the Diameter server 102 to close the Diameter connection.

[0054] Simultaneously, a watchdog timer 124 has been running since the last exchange of Diameter messages 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 to the Diameter client 104 by the transport layer 108 (132).

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

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

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

[0058] Consider another scenario where node B is the Diameter server and sends little (or no) signaling to node A (the client), except for DWRs sent according to the configured Tw interval. In this case, even after the client node resumes service, the server does not immediately recognize that the previous connection has been broken. Even worse, the server also rejects any new Diameter connection requests (CERs) sent by the client after the restart.

[0059] This is so that when a CER message is received, the server checks if an existing peer state machine exists for the same Origin-host. According to RFC6733, if the server finds an existing R-open state (i.e., established state) connection with the same peer (identified by the Origin-host in the CER), the server should reject the CER and drop the transport connection that the CER received. The client is then expected to retry the connection after the Tc timer interval. This scenario is illustrated in Figure 3.

[0060] Figure 3 is a message flow diagram illustrating an exemplary scenario in which the Diameter server 102 does not immediately determine that the Diameter connection has been lost after the Diameter client 104 has resumed 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. Subsequently, the Diameter client 104 sends request message 110 to establish a Diameter connection with the Diameter server 102. Request message 110 may be, for example, a Function Exchange Request (CER) message with a Diameter identifier in the Diameter client 104. The Diameter identifier may be, for example, Origin-Host OH1.

[0062] The Diameter server 102 establishes a Diameter connection by creating a peer state machine 114 for the connection. The state machine 114 can change its state between a closed state and an open state. The state machine 114 is associated with the 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, for example, a Function Exchange Response (CEA). The request message 116 is sent to the Diameter client via the transport layer 108 (118). The Diameter client 104 can then exchange various Diameter messages 120, for example, messages to operate the core network of a telecommunications network, with the Diameter server 102.

[0064] Subsequently, the Diameter client 104 begins to restart (122). The Diameter client 104 may start restarting for any of the following reasons. However, the Diameter client 104 does not restart properly in that it 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.

[0065] When Diameter client 104 resumes service, it sends message 302 to establish a new transport connection. Diameter client 104 sends request message 304, for example, a CER message with Origin-Host=OH1. Diameter server 102 finds that an existing state machine 114 exists with the same identifier, Origin-Host=OH1 (306). In response, Diameter server 102 rejects request message 304, initiates disconnecting the transport connection (308), and sends message 310 to close the transport connection.

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

[0067] In response, the Diameter client 104 sends message 318 to reset the transport connection. The Diameter server 102 receives message 318, for example, as an R-Peer-Disc message 320. The Diameter server 102 deletes the state machine 114 (322) and releases 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, for example, a CER message with Origin-Host=OH1, to establish a Diameter connection. The Diameter server 102 creates a new Diameter connection by creating a new OH1 state machine 330 (328). The state machine 330 sends a response message 332, for example, a CEA message. The Diameter server 102 sends the response message 332 using the transport layer 108 (334).

[0069] Delays in restoring Diameter connectivity can lead to service-impacting issues for clients, including call disconnections, loss of accounting, and authorization / accounting failures.

[0070] This problem is more likely to occur when a client is deployed in an HA (High Availability, e.g., 1+1, n+1, or n+k) configuration compared to when the client is deployed as a standalone node. This is because, generally, it takes tens of seconds (sometimes several minutes) for a standalone client node to resume service after a reboot, and therefore, by that point, the server is very likely to have detected the disconnected connection (through the watchdog failure mechanism shown in Figure 1). Thus, in most cases, the connection is restored as soon as the client returns to service.

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

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

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

[0074] The Diameter server 102 establishes a Diameter connection by creating a peer state machine 114 for the connection. The state machine 114 can change its state between a closed state and an open state. The state machine 114 is associated with the 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, for example, a Function Exchange Response (CEA). The request message 116 is sent to the Diameter client via the transport layer 108 (118). The Diameter client 104 can then exchange various Diameter messages 120, for example, messages to operate the core network of a telecommunications network, with the Diameter server 102.

[0076] Subsequently, the Diameter client 104 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 the following 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 Diameter client 104 resumes service using the currently active node 404, Diameter client 104 sends message 302 to establish a new transport connection. Diameter client 104 sends request message 304, for example, a CER message with Origin-Host=OH1. Diameter server 102 finds that an existing state machine 114 exists with the same identifier, Origin-Host=OH1 (306). In response, Diameter server 102 rejects request message 304, initiates disconnecting the transport connection (308), and sends message 310 to close the transport connection.

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

[0079] In response, the Diameter client 104 sends message 318 to reset the transport connection. The Diameter server 102 receives message 318, for example, as an R-Peer-Disc message 320. The Diameter server 102 deletes the state machine 114 (322) and releases 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, for example, a CER message with Origin-Host=OH1, to establish a Diameter connection. The Diameter server 102 creates a new Diameter connection by creating a new OH1 state machine 330 (328). The state machine 330 sends a response message 332, for example, a CEA message. The Diameter server 102 sends the response message 332 using the transport layer 108 (334).

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

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

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

[0084] - The server shall immediately, or as soon as possible, send the DWR over the old connection.

[0085] - The server has already received the CER request from the client, so it is expected that the client application will be able to return to the service and receive the DWR at any time.

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

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

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

[0089] - Upon receiving this reset instruction, the server's transport layer immediately (or as soon as possible) notifies the application, and the application cleans up the peer state machine.

[0090] -These steps are executed almost instantaneously, so the server resumes CER processing well before the hold-cer-timer expires. Since the original state machine no longer exists, the server proceeds as if this were a new connection request from a new client and accepts 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 should behave as it currently does, i.e., reject the new CER and drop the new connection.

[0092] - If for any reason the server does not receive a DWA or transport reset instruction within the hold-cer-timer time limit (for example, if the client is suffering a rolling reboot or back-to-back switchover), the server will reject the CER and drop any new connections. In other words, it's no worse than the traditional approach, except that it waits for a short time (e.g., 200 milliseconds) before rejecting the CER.

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

[0094] Figure 5 is a message flow diagram showing the recovery 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. Subsequently, the Diameter client 104 sends request message 110 to establish a Diameter connection with the Diameter server 102. Request message 110 may be, for example, a Function Exchange Request (CER) message with a Diameter identifier in the Diameter client 104. The Diameter identifier may be, for example, Origin-Host OH1.

[0095] The Diameter server 102 establishes a Diameter connection by creating a peer state machine 114 for the connection. The state machine 114 can change its state between a closed state and an open state. The state machine 114 is associated with the 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, for example, a Function Exchange Response (CEA). The request message 116 is sent to the Diameter client via the transport layer 108 (118). The Diameter client 104 can then exchange various Diameter messages 120, for example, messages to operate the core network of a telecommunications network, with the Diameter server 102.

[0097] Subsequently, the Diameter client 104 initiates a switchover 406 from the active node 402 to the standby node 404, after which the standby node 404 becomes active. The Diameter client 104 may initiate a switchover for any of the following 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 Diameter client 104 resumes service using the currently active node 404, Diameter client 104 sends message 302 to establish a new transport connection. Diameter client 104 sends request message 304, for example, a CER message with Origin-Host=OH1. Diameter server 102 finds that an existing state machine 114 exists with the same identifier, Origin-Host=OH1 (306).

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

[0100] Subsequently, the Diameter server 102 creates a new Diameter connection by creating a new peer state machine 514 (512). The Diameter server resumes CER processing and 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 herein provides an efficient method for servers to reliably determine client switchovers / reboots and restore connectivity without wasting time. Furthermore, this solution limits the scope of impact by sending a DWR on affected connections and when a reboot / switchover (on the client) is suspected.

[0102] Figure 6 is a flowchart of an exemplary method 600 for restoring Diameter connectivity. Method 600 can be performed by any suitable Diameter node, e.g., a Diameter server. In some examples, the Diameter client is deployed in a highly available configuration having an active node and one or more standby nodes configured to take over the active role in response to the failure of the active node.

[0103] Method 600 includes establishing a first Diameter connection with a Diameter client having a Diameter identifier 602. For example, the Diameter client and server can exchange CER / CEA messages. Establishing a first Diameter connection may 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 over the first Diameter connection for some time before the Diameter client restarts (e.g., a reboot or a switchover to a new active node).

[0104] Method 600 includes receiving a request to establish a new Diameter connection using a Diameter identifier 604. Method 600 includes holding the request to establish a new Diameter connection for a specified time limit 606, and while holding the request, scrutinizing the first Diameter connection to determine whether the first Diameter connection has been disconnected. Scrutinizing the first Diameter connection may include sending a Diameter watchdog request to the Diameter client on the first Diameter connection. The specified time limit for holding the request to establish a new Diameter connection may be, for example, shorter than or significantly shorter than the Diameter transaction timeout.

[0105] Method 600 includes determining that a first Diameter connection has been disconnected 608. Determining that a first Diameter connection has been disconnected may include determining that a first Diameter connection has been disconnected before a certain time limit is reached. Determining that a first Diameter connection has been disconnected may include receiving a reset message from a Diameter client. The reset message may be a Transmission Control Protocol (TCP) message sent as a result of the Diameter client treating a Diameter watchdog request as having been received on an unexpected connection.

[0106] Method 600 includes, in response to a determination that a first Diameter connection has been disconnected, 610 aborting the first Diameter connection and establishing a second Diameter connection with a Diameter client having a Diameter identifier. Aborting the first Diameter connection and establishing a second Diameter connection may 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 this disclosure includes any feature or combination of features (express or implied) disclosed herein, or generalizations of the features disclosed herein, regardless of whether such features or generalizations mitigate some or all of the issues described herein. Therefore, new claims may be created for such combinations of features during the examination of this application (or an application claiming priority to this application).

[0108] In particular, referring to the attached claims, the features of the dependent claims can be combined with the features of the independent claims, and the features of each independent claim can be combined in any appropriate way, not just in the specific combinations listed in the attached claims.

Claims

1. A method for restoring Diameter connectivity, Accepting a first Diameter connection with a Diameter client having a Diameter identifier, Receiving a request to establish a new Diameter connection using the aforementioned Diameter identifier, The method includes holding the request to establish a new Diameter connection for a specified time limit, and while holding the request, checking the first Diameter connection to determine whether the first Diameter connection has been disconnected, wherein checking the first Diameter connection includes sending a Diameter watchdog request to the Diameter client, and the method further includes: The method includes determining that the first Diameter connection is disconnected, and determining that the first Diameter connection is disconnected includes receiving a reset message in response to the Diameter watchdog request, and the method further includes: In response to the determination that the first Diameter connection has been disconnected, the first Diameter connection is terminated, and a second Diameter connection is accepted with the Diameter client having the Diameter identifier. A method that includes this.

2. The method according to claim 1, wherein determining that the first Diameter connection is disconnected includes determining that the first Diameter connection is disconnected before the specified time limit is reached.

3. The method according to claim 1, wherein the reset message is a Transmission Control Protocol (TCP) message transmitted as a result of the Diameter client processing the Diameter watchdog request as having been received on an unexpected connection.

4. The method according to claim 1, wherein establishing the first Diameter connection comprises creating a first peer state machine for the first Diameter connection using the Diameter identifier.

5. The method according to claim 4, wherein terminating the first Diameter connection and establishing the second Diameter connection includes resuming processing of the request to establish the new Diameter connection by creating the second peer state machine after cleaning up the first peer state machine.

6. The method according to claim 1, wherein the Diameter client is deployed in a high-availability 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.

7. The method according to claim 1, wherein the specific time limit for holding the request to establish a new Diameter connection is less than the Diameter transaction timeout.

8. The method according to claim 1, wherein establishing the first Diameter connection includes receiving a Function Exchange Request (CER) message on the transport connection after establishing the transport connection.

9. A system for restoring Diameter connectivity, At least one processor and memory, A Diameter server, which is implemented by at least one of the processors and configured to perform the method described in any one of claims 1 to 8, A system equipped with these features.

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

Images