num="0040">Upon receiving information about a set of potential S-CSCF nodes, the HSS 214 may select one to be assigned to the UE 204. In embodiments, the HSS 214 may make such a determination based on information stored in memory related to the P-CSCF node 218 assigned to the UE 204. More particularly, the HSS 214 may store information about details (e.g., a name, address (e.g., IP address), etc.) and capabilities related to the P-CSCF node 218. In some cases, the HSS 214 will attempt to identify a S-CSCF node from the set of potential S-CSCF nodes that best matches the capabilities provided by the P-CSCF node 218. In some cases, such capabilities may include an indication of various features that are supported by the P-CSCF node 218. For example, the capabilities may include an indication of a codec supported by the P-CSCF node 218. In some cases, the capabilities may include an indication of a value (e.g., a numeric value) associated with an attribute such as a maximum bandwidth supported by the P-CSCF node 218.

In some cases, the HSS 214 may perform vector similarity analysis to identify a S-CSCF node that most closely aligns with the capabilities of the P-CSCF node 218. In such cases, the HSS 214 may generate a vector for each S-CSCF node in the set of potential S-CSCF nodes with each capability offered by the respective S-CSCF being represented as a value along an axis associated within a dimensional space. In these cases, the vectors generated for each of the S-CSCF nodes in the set of potential S-CSCF nodes can be compared to a vector generated for the P-CSCF node 218 to identify a S-CSCF node 216 that is closest to the P-CSCF node 218. Once a S-CSCF node 216.

Upon selecting the S-CSCF node 216, the HSS may provide an indication of such an assignment to the S-CSCF node 216. In some cases, the HSS 214 provides an indication of the assignment to a I-CSCF node, which then provides a SIP request to the S-CSCF node 216.

In response to receiving the SIP request, the S-CSCF node 216 is configured to send a request for restoration information to the HSS 214 over a Diameter interface. This request may take the form of a server assignment request (SAR) message. The SAR message can include a server assignment type (SAT) value set to “NO_Assignment” in order to receive the registration data for the UE 204. An example of a SAR message may be as follows: SAR (IMPU, S-CSCF Name, SAT=NO_ASSIGNMENT), where IMPU is the IP multimedia public identity of the UE 204.

In response to receiving the SAR message, the HSS 214 can enable restoration and set a “reassignment pending” flag to TRUE, meaning that the UE 204 is in the process of being reassigned to a different S-CSCF node (in this case, the S-CSCF node 216). Once the HSS 214 overwrites the value for the S-CSCF name AVP with the identifier of the S-CSCF node 216, and the S-CSCF binding, the “reassignment pending” flag can be set to FALSE. Thereafter, the S-CSCF binding is updated in the HSS repository to reflect an association between the UE 204 and the S-CSCF node 216.

The S-CSCF node 216 can receive a server assignment answer (SAA) message from the HSS 214 over a Diameter interface in response to sending the SAR message. The SAA message can include the restoration information requested by the S-CSCF node 216 via the SAR message. An example of a SAA message is as follows: SAA (IMPU, User-Data, S-CSCF-Restoration-Info, Associated-Identities). The receipt of the SAA message by the S-CSCF node 216 informs it that it is was not originally assigned to the UE 204 during the registration procedure for the UE 204.

Additionally, the HSS 214 provides information about the P-CSCF node 218 (e.g., name, address, capabilities, etc.) to which the S-CSCF node 216 has now been assigned. This prevents the S-CSCF node 216 from needing to obtain that information from the P-CSCF node 218 directly, resulting in fewer transmitted communications and a quicker session restoration process.

Once the S-CSCF node 216 has been assigned to the P-CSCF node 218, the application server may be provided with the indication of the S-CSCF node 216 so that the communication can be relayed to it. The S-CSCF node 216, upon receiving that communication, then relays it to the P-CSCF node 218, which forwards the communication to the terminating UE 204.

FIG. 3 depicts a swim lane diagram illustrating a process for optimally performing a restoration procedure without tearing down a current communication session in accordance with at least some embodiments. More particularly, the block diagram illustrates example signaling between a UE (e.g., UE 108) and various IMS nodes within the IMS network to restore a communication session for the UE in the event of a first S-CSCF node 112 (A) becoming unavailable.

As noted elsewhere, a UE 108 may be assigned to both a P-CSCF node 110 as well as a S-CSCF node 112 (A) during a registration process. In embodiments, the P-CSCF node 110 may provide information about itself to the HSS. In some cases, this information may be provided by the P-CSCF node 110 to the HSS 116 during the registration procedure for the UE 108. In some cases, the P-CSCF node 110 provides such information to the HSS 116 at periodic intervals. For example, the P-CSCF node 110 may provide the information to the HSS 116 during a periodically-scheduled status update communication (e.g., a “heartbeat message’). The information about the P-CSCF node 110 that is provided to the HSS 116 may include any suitable information about the P-CSCF node 110 that can be used to reestablish an IMS session including, but not limited to, a name, an address, and an indication of capabilities provided by the P-CSCF node 110.

The HSS 116 can be associated with a master database (sometimes referred to herein as an “HSS repository”) that maintains data pertaining to UEs that have registered, or are in the process of registering, on the IMS network. The information about the P-CSCF node 110 may be provided to the HSS 116 via routing through the S-CSCF node 112 (A). For example, the P-CSCF node 110 may provide the information to the S-CSCF node 112 (A) in a first communication at 302 and the S-CSCF node 112 (A) may forward that information to the HSS 116 in a second communication at 304. In embodiments, the information may be provided to the HSS 116 over a Diameter interface in the form of a profile update request (PUR) message.

At 306, a communication may be directed to the UE 108 via the S-CSCF node 112 (A). In some cases, the communication may be generated and transmitted by a AS 118. For example, an AS 118 may generate a communication directed to the UE 108 upon a second UE attempting to establish a communication session with the UE 108.

At this time, it may be discovered that the S-CSCF node 112 (A) is no longer available. The S-CSCF node 112 (A) may have experienced, after the UE's 108 successful registration, a network failure, or some other failure in hardware and/or software of the S-CSCF node 112 (A) that renders the S-CSCF node 112 (A) inoperative. Alternatively, the S-CSCF node 112 (A) may be operable but is nevertheless unreachable by the AS 118 (or another entity) for some reason (e.g., a fiber cut between the AS 118 and the S-CSCF node 112 (A)).

Upon discovering that the S-CSCF node 112 (A) is no longer available, the AS 118 may provide a notification to the HSS 116 to cause it to perform a restoration procedure at 308.

Upon receiving a notification that a S-CSCF node 112 (A) has become unavailable, the HSS 116 may initiate a restoration procedure at 310. Initially, the HSS 116 may identify the P-CSCF node 110 as being associated with the S-CSCF node 112 (A) based on assignment data stored in its data repository. The HSS 116 may further retrieve other information about the P-CSCF node 110 from its data repository to be used in restoring a connection to the P-CSCF node 110. The HSS 116 may then identify a set of available S-CSCF nodes that can act as a replacement for the S-CSCF node 112 (A) and may select a replacement S-CSCF node 112 (B) from that set of nodes. In some cases, the HSS 116 may make its selection based on information about the P-CSCF node 110, such as the information about the capabilities provided by the P-CSCF node 110. An exemplary process for selecting a S-CSCF node based on capabilities of the P-CSCF node is described in greater detail with respect to FIG. 4 below.

Upon identifying a replacement S-CSCF node 112 (B), the HSS 116 may provide instructions to the S-CSCF node 112 (B) (e.g., via a SIP request) to cause it to act as a replacement for the S-CSCF node 112 (A) at 312. The HSS 116 may further provide at least a portion of the retrieved information about the P-CSCF node 110 to the S-CSCF node 112 (B) in order to enable the S-CSCF node 112 (B) to be configured to replace the S-CSCF node 112 (A) while minimizing required communications. For example, since the S-CSCF node 112 (B) is provided all of the information about the P-CSCF node 110 that it needs to re-establish the session, this prevents the S-CSCF node 112 (B) from needing to communicate with the P-CSCF node 110 directly during the restoration procedure, which can reduce the time needed to restore the session as well as the bandwidth used in doing so.

Once the HSS 116 has received confirmation that the S-CSCF node 112 (B) has been configured to replace the S-CSCF node 112 (A), the HSS 116 may overwrite the information about the S-CSCF node 112 (A) in relation to the UE 108 with corresponding information for the S-CSCF node 112 (B). The HSS 116 may then notify the AS 118 that it may continue with the communication session while providing information about S-CSCF node 112 (B).

Once the AS 118 has received information indicating that S-CSCF node 112 (A) has been replaced with S-CSCF node 112 (B), the AS 118 may continue with the previous communication session. For example, the AS 118 may provide a SIP request to the S-CSCF node 112 (B) at 314, which is then forwarded to the P-CSCF node 110 at 316. The P-CSCF node 110 may then route the communication to the UE 108 at 318 in order to establish/reestablish the communication session.

FIG. 4 depicts a block diagram illustrating an exemplary process for selecting an optimal replacement S-CSCF node in accordance with embodiments. As noted elsewhere, a HSS (or another suitable IMS node) may be configured to select an optimal replacement S-CSCF node for a S-CSCF node that is unresponsive. In such cases, the HSS may make such a selection based on a degree of similarity between the capabilities offered by the potential replacement S-CSCF node and the capabilities of an associated P-CSCF node.

Upon initiation of the exemplary process (e.g., Start), the HSS may identify a P-CSCF node that is associated with the unresponsive S-CSCF node. Such an association may be determined based on a mapping that was established upon registration of a user equipment at an earlier date. Upon identifying the respective P-CSCF node the HSS may retrieve information about a number of capabilities available to that P-CSCF node from a data repository at 402.

Once the HSS has obtained information about the capabilities available to the P-CSCF node, the HSS may generate a vector that is representative of that information at 404. Such a vector may be a representation of a position of the P-CSCF node within a multi-dimensional space. The vector may include a number of axes, each of which are associated with a capability. A position, or value, assigned to each axes may correspond to a magnitude, or value, of the capability. Some capabilities may be binary. For example, the P-CSCF node eithers support a particular application (e.g., a codec, etc.) or it does not. In this example, the value assigned to that vector along the axis associated with that capability may be either 0 or 1 depending on whether the capability is supported.

In some cases, various capabilities may have greater importance than others. In these cases, each capability may be provided with a weight value that corresponds to its level of importance, such that a value along a particular axis of the vector may be magnified (e.g., multiplied) based on its respective weight value.

In addition to generating a vector representative of the capabilities of the P-CSCF node, the HSS may further generate vectors representative of each of the potential replacement S-CSCF nodes (either in parallel or serially). At 406, the HSS may identify a set of potential (i.e., available) S-CSCF nodes. As noted elsewhere, available S-CSCF nodes may be identified by submitting a DNS query to a DNS server. In embodiments, the DNS server may make a determination as to which S-CSCF nodes are currently available based on current workload or bandwidth usage.

Upon determining a set of S-CSCF nodes that can potentially act as a replacement for the unresponsive S-CSCF node, the HSS may generate a vector for each of those in the set at 408. Each vector generated for a node in the set may be similar to the vector representative of the capabilities of the P-CSCF node, in that a position, or value, assigned to each axes of the vector may correspond to a magnitude, or value, of a respective capability. Each vector generated for a potential replacement S-CSCF node in the set of identified S-CSCF nodes may represent a respective position within the same multi-dimensional space in which the vector for the P-CSCF node resides.

Once respective capability vectors have been generated for each of the S-CSCF nodes in the set of available S-CSCF nodes, they may be compared to the capability vector of the P-CSCF node to identify a closest match at 410. In a vector similarity analysis, a distance between each of the S-CSCF node vectors and the P-CSCF node vector is calculated in order to identify the S-CSCF node for which its respective vector has the shortest distance. The S-CSCF node having the vector with the shortest distance to the vector of the P-CSCF node is then returned as a closest match at 412.

In the event that two or more S-CSCF nodes are tied for shortest distance, then other factors may be used to identify an appropriate replacement S-CSCF node. For example, the S-CSCF node having the lowest current workload or bandwidth usage may be selected. In some cases, ties may be resolved by selecting one of the tied S-CSCF nodes randomly.

FIG. 5 depicts a flow chart illustrating an exemplary process for performing IMS session restoration in accordance with at least some embodiments. In embodiments, the process 500 may be performed on a home subscriber server (HSS) that is operating within an IMS network in order to provide IMS services. The HSS may maintain user profile data that stores information about individual accounts associated with the IMS network.

At 502, the process 500 may involve storing, in a data repository of the HSS, information about a proxy call session control function (P-CSCF) node. Such information about the P-CSCF node may include, but is not limited to, a name, an address, and/or an indication of one or more capabilities associated with the P-CSCF node. In some cases, the information about the P-CSCF node is received at the HSS when a user equipment associated with the P-CSCF is registered with the HSS. In some cases, the information about the P-CSCF node is received at the HSS on a periodic basis (e.g., in a “heartbeat” communication).

At 504, the process 500 may involve receiving an indication that a first service call session control function (S-CSCF) node is unresponsive. In some embodiments, the indication that the first S-CSCF node is unresponsive may include either a lack of response from the first S-CSCF node or an error code received from the first S-CSCF node. In some cases, the indication that the first S-CSCF node is unresponsive is received by an entity in relation to a communication directed by that entity toward a user equipment associated with the P-CSCF node.

At 506, the process 500 may involve determining a second S-CSCF node to replace the first S-CSCF node. In embodiments, the HSS is provided with an indication of one or more capabilities based on the communication. For example, if the communication is a voice over IP call, then an indication may be received at the HSS that the replacement S-CSCF node should support VOIP capabilities. Once the HSS has selected a second S-CSCF node to replace the first S-CSCF node, the HSS may provide a notification (e.g., via an I-CSCF node) to that second S-CSCF node to indicate that it has been selected as a replacement.

In embodiments, the first S-CSCF node is associated with the P-CSCF node during a registration of the user equipment. Accordingly, an association between the first S-CSCF node and the P-CSCF node may be determined based on an assignment mapping that was previously made by the HSS.

In embodiments, the second S-CSCF node is selected from a set of available S-CSCF nodes. For example, a set of available S-CSCF nodes may be identified by a DNS server via a domain name system (DNS) query as being available to serve as a replacement for the unavailable first S-CSCF node. In some embodiments, the set of C-CSCF nodes determined to be available is identified based on a current workload or bandwidth usage.

In embodiments, the second S-CSCF node is selected based on a degree of similarity between a first set of capabilities of the P-CSCF node and a second set of capabilities of the second S-CSCF node. For example, the second S-CSCF node may be selected using one or more vector similarity analysis techniques. In this example, the process 500 further involves generating a vector in which each of a number of capabilities supported by the second S-CSCF node are represented as a value along an axis in a multi-dimensional space.

At 508, the process 500 may involve receiving a request from the S-CSCF node for information about the P-CSCF node. In embodiments, when the S-CSCF node receives an indication that it has been selected as a replacement node, it may also receive information (e.g., from the I-CSCF node) about the P-CSCF node.

At 510, the process 500 may involve providing at least a portion of the information about the P-CSCF node to the second S-CSCF node. In embodiments, the second S-CSCF node is caused to be configured to replace the first S-CSCF node using the received portion of the information about the P-CSCF node. The second S-CSCF node may be configured to replace the first S-CSCF node absent (e.g., before) communicating with the P-CSCF node.

FIG. 6 shows an example computer architecture for an IMS node 600 capable of executing program components for implementing the functionality described above. The computer architecture shown in FIG. 6 illustrates a conventional server computer, workstation, desktop computer, laptop, tablet, network appliance, e-reader, smartphone, or other computing device, and can be utilized to execute any of the software components presented herein. The IMS node 600 may, in some examples, correspond to a physical server as described herein, and may comprise networked devices such as servers, switches, routers, hubs, bridges, gateways, modems, repeaters, access points, etc.

The IMS node 600 includes a baseboard 602, or “motherboard,” which is a printed circuit board to which a multitude of components or devices can be connected by way of a system bus or other electrical communication paths. In one illustrative configuration, one or more central processing units (“CPUs”) 604 operate in conjunction with a chipset 606. The CPUs 604 can be standard programmable processors that perform arithmetic and logical operations necessary for the operation of the IMS node 600.

The CPUs 604 perform operations by transitioning from one discrete, physical state to the next through the manipulation of switching elements that differentiate between and change these states. Switching elements generally include electronic circuits that maintain one of two binary states, such as flip-flops, and electronic circuits that provide an output state based on the logical combination of the states of one or more other switching elements, such as logic gates. These basic switching elements can be combined to create more complex logic circuits, including registers, adders-subtractors, arithmetic logic units, floating-point units, and the like.

The chipset 606 provides an interface between the CPUs 604 and the remainder of the components and devices on the baseboard 602. The chipset 606 can provide an interface to a RAM 608, used as the main memory in the IMS node 600. The chipset 606 can further provide an interface to a computer-readable storage medium such as a read-only memory (“ROM”) 610 or non-volatile RAM (“NVRAM”) for storing basic routines that help to startup the IMS node 600 and to transfer information between the various components and devices. The ROM 610 or NVRAM can also store other software components necessary for the operation of the IMS node 600 in accordance with the configurations described herein.

The IMS node 600 can operate in a networked environment using logical connections to remote computing devices and computer systems through a network, such as the network 611 (which may be an IMS network). The chipset 606 can include functionality for providing network connectivity through a NIC 612, such as a gigabit Ethernet adapter. The NIC 612 is capable of connecting the IMS node 600 to other computing devices over the network 611. It should be appreciated that multiple NICs 612 can be present in the IMS node 600, connecting the computer to other types of networks and remote computer systems.