S-CSCF IMS Recovery via HSS Contact Data Caching
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In IP Multimedia Subsystems (IMS), a Serving Call Session Control Function (S-CSCF) server restarts due to failures, software or hardware updates, leading to abnormal processing conditions and inability to connect subscribers, as critical subscriber data is lost or becomes untrustable, hindering service provision and call connectivity.
Innovation Solution
The proposed solution involves methods and mechanisms within the Home Subscriber Server (HSS) and S-CSCF to recover IMS services by storing and providing contact data and subscriber profiles, ensuring seamless communication post-restart, including steps like receiving contact data from the S-CSCF, storing it, and providing contact information elements to relevant IMS entities.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If the S-CSCF restarts after a failure or update, then the S-CSCF can resume operation with renewed stability, but the subscriber data stored in the S-CSCF is lost or becomes untrustable, causing service interruption
Solution Approach 1:
The HSS stores contact data (P-CSCF addresses, user profiles) in advance before the S-CSCF restart occurs. When the S-CSCF restarts and loses its subscriber data, it can immediately retrieve the pre-stored contact data from the HSS without needing to re-collect it from external networks, thus resolving the contradiction between maintaining operational stability and preserving subscriber data.
Solution Approach 2:
The HSS acts as an intermediary between the S-CSCF and external network entities (P-CSCF, user equipment). It maintains a cache of contact data that the S-CSCF can access after restart, eliminating the need for the S-CSCF to directly re-establish connections with external entities and preventing service interruption.
2Ease of operation
If the S-CSCF retrieves subscriber data from HSS after restart, then the S-CSCF can restore service functionality, but the signalling overhead and recovery time increase due to additional communication steps
Solution Approach 1:
The HSS proactively stores and updates contact data (P-CSCF addresses, user profiles, service information) in its database before the S-CSCF restart occurs. This preliminary action ensures that when the S-CSCF restarts, it can immediately retrieve all necessary subscriber data from the HSS in a single operation, rather than needing to re-collect data from multiple external sources, thus minimizing recovery time while maintaining full service restoration capability.
3Device complexity
If the S-CSCF ignores signalling path data after restart, then the S-CSCF can simplify its data validation process, but it cannot connect the originating subscriber with the terminating subscriber, breaking call routing
Solution Approach 1:
The HSS serves as a trusted intermediary that stores and validates signalling path data (P-CSCF addresses, routing information). After S-CSCF restart, instead of the S-CSCF attempting to validate complex signalling paths independently, it retrieves pre-validated routing data from the HSS, which then guides the S-CSCF in re-establishing call connections. This maintains call routing reliability while simplifying the S-CSCF's post-restart operations.
Data Source
AI summary
Methods and apparatus facilitate recovery of an IMS in which an S-CSCF has suffered a restart (after a failure, software upgrade, or other reasons). One or more of first and second methods comprise submitting, from the S-CSCF towards a HSS, contact data required by the S-CSCF to contact a given subscriber, or to contact a proxy server through which the subscriber is accessible; storing the contact data at the HSS; and providing from the HSS towards an IMS entity, which may be previously assigned S-CSCF or a new S-CSCF, contact information elements selectable from the contact data.