IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session. By growing the number of basic applications and the media that it is possible to combine, the number of services offered to the end users will grow, and the inter-personal communication experience will be enriched. This will lead to a new generation of personalised, rich multimedia communication services, including so-called “combinational IP Multimedia” services.
The Universal Mobile Telecommunications System (UMTS) is a third generation wireless system designed to provide higher data rates and enhanced services to subscribers. UMTS is a successor to the Global System for Mobile Communications (GSM), with an important evolutionary step between GSM and UMTS being the General Packet Radio Service (GPRS). GPRS introduces packet switching into the GSM core network and allows direct access to packet data networks (PDNs). This enables high-data rate packets switch transmissions well beyond the 64 kbps limit of ISDN through the GSM call network, which is a necessity for UMTS data transmission rates of up to 2 Mbps. UMTS is standardised by the 3rd Generation Partnership Project (3GPP) which is a conglomeration of regional standards bodies such as the European Telecommunication Standards Institute (ETSI), the Association of Radio Industry Businesses (ARIB) and others. See 3GPP TS 23.002 for more details.
The UMTS architecture includes a subsystem known as the IP Multimedia Subsystem (IMS) for supporting traditional telephony as well as new IP multimedia services (3GPP TS 22.228, TS 23.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 and TS 29.329 Releases 5 to 7). The IMS provides key features to enrich the end-user person-to-person communication experience through the use of standardised IMS Service Enablers, which facilitate new rich person-to-person (client-to-client) communication services as well as person-to-content (client-to-server) services over IP-based networks. The IMS is able to connect to both Public Switched Telephone Network/Integrated Services Digital Network (PSTN/ISDN) as well as the Internet.
The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or user terminals and application servers). The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, IMS allows operators and service providers to control user access to services and to charge users accordingly. The 3GPP has chosen SIP for signalling between a User Equipment (UE) and the IMS as well as between the components within the IMS.
Specific details of the operation of the UMTS communications network and of the various components within such a network can be found from the Technical Specifications for UMTS that are available from http://www.3gpp.org. Further details of the use of SIP within UMTS can be found from the 3GPP Technical Specification TS 24.228 V5.8.0 (2004-03).
FIG. 1 of the accompanying drawings illustrates schematically how the IMS fits into the mobile network architecture in the case of a GPRS/PS access network (IMS can of course operate over other access networks). Call/Session Control Functions (CSCFs) operate as SIP proxies within the IMS. The 3GPP architecture defines three types of CSCFs: the Proxy CSCF (P-CSCF) which is the first point of contact within the IMS for a SIP terminal; the Serving CSCF (S-CSCF) which provides services to the user that the user is subscribed to; and the Interrogating CSCF (I-CSCF) whose role is to identify the correct S-CSCF and to forward to that S-CSCF a request received from a SIP terminal via a P-CSCF.
A user registers with the IMS using the specified SIP REGISTER method. This is a mechanism for attaching to the IMS and announcing to the IMS the address at which a SIP user identity can be reached. In 3GPP, when a SIP terminal performs a registration, the IMS authenticates the user, and allocates a S-CSCF to that user from the set of available S-CSCFs. Whilst the criteria for allocating S-CSCFs is not specified by 3GPP, these may include load sharing and service requirements. It is noted that the allocation of an S-CSCF is key to controlling (and charging for) user access to IMS-based services. Operators may provide a mechanism for preventing direct user-to-user SIP sessions which would otherwise bypass the S-CSCF.
During the registration process, it is the responsibility of the I-CSCF to select an S-CSCF if a S-CSCF is not already selected. The I-CSCF receives the required S-CSCF capabilities from the home network's Home Subscriber Server (HSS), and selects an appropriate S-CSCF based on the received capabilities. (It is noted that S-CSCF allocation is also carried out for a user by the I-CSCF in the case where the user is called by another party, and the user is not currently allocated an S-CSCF.) When a registered user subsequently sends a session request to the IMS, the P-CSCF is able to forward the request to the selected S-CSCF based on information received from the S-CSCF during the registration process.
Within the IMS service network, Application Servers (ASs) are provided for implementing IMS service functionality. Application Servers provide services to end-users in an IMS system, and may be connected either as end-points over the 3GPP defined Mr interface, or “linked in” by an S-CSCF over the 3GPP defined ISC interface. In the latter case, Initial Filter Criteria (IFC) are used by an S-CSCF to determine which Applications Servers should be “linked in” during a SIP Session establishment. Different IFCs may be applied to different call cases. The IFCs are received by the S-CSCF from an HSS during the IMS registration procedure as part of a user's User Profile. Certain Application Servers will perform actions dependent upon subscriber identities (either the called or calling subscriber, whichever is “owned” by the network controlling the Application Server). For example, in the case of call forwarding, the appropriate (terminating) application server will determine the new terminating party to which a call to a given subscriber will be forwarded. In the case that an IFC indicates that a SIP message received at the S-CSCF should be forwarded to a particular SIP AS, that AS is added into the message path. Once the SIP message is returned by the AS to the S-CSCF, it is forwarded on towards its final destination, or forwarded to another AS if this is indicated in the IFCs.
The 3GPP uses the concept of contact addresses in the IMS network. These addresses are tied to an IP Multimedia Private Identity (IMPI) and IP Multimedia Public Identity (IMPU) and are typically IP addresses of user terminals. A particular IMPU may be simultaneously registered from multiple UEs that use different IMPIs and different contact addresses. It will eventually be possible to register a Public User Identity that is simultaneously shared across multiple contact addresses (at the same or via separate UEs) via IMS registration procedures.
Certain entities of an IMS are critical entities expected to be fault tolerant since a failure in such entities may cause an important network failure and a huge amount of subscribers of such network not being able to communicate. In particular, a S-CSCF serving a number of IMS subscribers is one of these entities whose failure might make the IMS reach abnormal processing conditions so that the number of IMS subscribers served in the S-CSCF cannot properly make use of services or cannot even make calls. In this respect most, or all, failures are accompanied by a reset of the failing entity and a restart once the failure has been solved, probably by reloading permanent stable data if inconsistent data were found to be a reason for the failure. Other issues may also necessitate a critical entity going out of service, for example a software or hardware update which cannot enter into operation without producing a restart of the critical entity concerned.
A mechanism to recover the network after an IMS restoration has been discussed in the 3GPP work item CP-070031.0 and the resulting study 3GPP TS 23.820 v0.2.0 and v0.3.0. This study contains a proposal that the S-CSCF should store some network information into the HSS for later retrieval after a S-CSCF failure. In this proposal, the nature of this data is the user's registered contact headers including Display-Name, SIP URI and all contact header parameters, together with the path header and timestamp associated at registration.
However, there may be other types of information that the S-CSCF may need to store in the HSS in order to recover fully from failure. One example of such information is subscriptions to the registration event package handled by the S-CSCF. It is important that this information can be recovered by the S-CSCF, since it contains details of the entities like the UEs, P-CSCFs and ASs that have subscribed to the event. If this information is lost, these subscribing entities will remain unaware if the user is otherwise deregistered. This in turn may lead to an attempt by a subscribing entity to initiate traffic as though the user was registered, leading to a fault in the network.
Thus existing proposals for S-CSCF data to be stored in HSS do not cover all the data that the S-CSCF may need to store in the HSS to be able to fully recover and align state information across the IMS. The existing proposals are general in nature and do not detail the method by which the S-CSCF data is stored in the HSS.
One proposal involves the use of the Cx Server Assignment Request (SAR) command during the registration process to store the contact data information in the HSS. However, this mechanism is not readily applicable when multiple contact addresses are used, since the deregistration of one contact address may leave other contact addresses still to be registered, and will therefore not result in any change of the user registration status.
Furthermore, some indication must be made of how contact addresses are stored in the HSS, since a normal SAR command leads to the overwriting of previous contact information in a re-registration case.
There is thus a need for a suitable mechanism by which S-CSCF information (such as contact addresses and registration event package information) can be stored in the HSS and deleted when required.
USPTO Backgrounds
USPTO Backgrounds