CN100391167C - Service call session control function entity backup method and system - Google Patents

Abstract

The invention relates to a SIP multimedia subsystem, and discloses an S-CSCF backup method and system thereof, enabling the S-CSCF to realize remote disaster recovery. In the present invention, by building the AS in the S-CSCF, when the user registers successfully, the user information is sent to other S-CSCFs that work in a load sharing manner with the S-CSCF, and stored by other S-CSCFs The user's information is used to realize the third-party registration of the user, and at the same time, the S-CSCF backs up the dynamic data required for processing the user's business to the HSS. When the S-CSCF fails, the network side forwards the service requests of registered users in the failed S-CSCF to other S-CSCFs. If the S-CSCF receives a service request belonging to a third-party registered user, it will download the user's dynamic data and subscription information from the HSS according to the third-party registration information of the user, and continue to provide services for the user.

Description

Service call session control function entity backup method and system

technical field

The invention relates to the SIP multimedia subsystem, in particular to the internal backup technology of the SIP multimedia subsystem.

Background technique

The mobile communication system can meet people's requirements for communication anytime and anywhere, and has developed rapidly since its appearance. With the introduction and further development of the third-generation mobile communication (The Third Generation, referred to as "3G") technology, the bandwidth of the mobile network has greatly increased, and mobile communication will not only be limited to traditional voice communication, but also combine audio, video, pictures and Multimedia services of multiple media types such as text will be developed gradually. The combination of mobile communication with data services such as presence, short message, web browsing, positioning information, push service (PUSH), and file sharing can provide users with more service options. For example, instant messages, chat rooms, and multimedia short messages for message services; entertainment, multimedia information, and daily communication for video services; product catalogs, search engines, shopping carts, order management, and payment for e-commerce; single-player games for games Games, group games; positioning services such as tracing, guides, and alarms; personal assistants such as address book, calendar, bookmark management, file storage, event reminders, and emails can better meet the various needs of users.

Considering that the Internet Protocol (Internet Protocol, referred to as "IP") network is more and more widely used, the 3rd Generation Partnership Project (3rd Generation Partnership Project, referred to as "3GPP") and the 3rd Generation Partnership Project 2 (3rd Generation Partnership Project Generation Partnership Project 2, referred to as "3GPP2") and other standard organizations have formulated standards for the evolution of mobile communication networks to all-packet and all-IP directions, and proposed an IP-based multimedia subsystem architecture. A standardized and open structure to realize a variety of multimedia applications, providing users with more choices and richer experience.

Among them, 3GPP introduced the IP Multimedia Subsystem (IP Multimedia Subsystem, "IMS") domain in the Release 5 (Release 5, referred to as "R5") stage, which is superimposed on the packet domain network. IMS consists of call state control function (Call Session Control Function, referred to as "CSCF"), media gateway control function (Media Gateway Control Function, referred to as "MGCF"), media resource function (Multimedia Resource Function, referred to as "MRF") and attribution User server (Home Subscriber Server, referred to as "HSS") and other functional entities. CSCF can be further divided into three logical entities: Serving CSCF (Serving CSCF, referred to as "S-CSCF"), Proxy CSCF (ProxyCSCF, referred to as "P-CSCF") and Inquiring CSCF (Interrogating CSCF, referred to as "I-CSCF"). Among them, S-CSCF is the service switching center of IMS, which performs session control, maintains session state, manages user information, generates billing information, etc.; P-CSCF is the access point for terminal users to access IMS, completes user registration, is responsible for QoS control and security management, etc.; I-CSCF is responsible for the intercommunication between IMS domains, manages the allocation of S-CSCF, hides network topology and configuration from the outside, and generates charging data, etc. The MGCF controls the gateway to realize the intercommunication between the IMS network and other networks, and the MRF provides media resources, such as audio playback, codec and multimedia conference bridge. The HSS is a user database, which stores subscription data and configuration information of IMS users.

Since the capacity of IMS equipment is generally relatively large, in addition to the reliability mechanism of the equipment itself, remote disaster recovery capabilities must also be considered. That is to say, when a network element device in a certain IMS fails, other devices can take over the device in time, so that the failure device has the least impact on the entire IMS network.

At present, network element devices in the IMS, such as P-CSCF, S-CSCF, and application server (Application Server, referred to as "AS"), etc., often need to save dynamic data related to registration after user registration. Here, if the network element equipment fails, the relevant user dynamic data such as registration information, subscription information, etc. will be lost, so that the users provided by the faulty network element will not be able to continue to obtain services. Until the users who can no longer obtain the service register again, the data of these users will be allocated to new devices, so as to resume the normal business processing of these users.

In practical applications, the above solution has the following problems: when the S-CSCF fails, the service of the relevant user cannot be recovered in time, so the continuity of the service cannot be maintained, which affects the experience of the user.

The main reason for this situation is that, in the prior art, once an S-CSCF fails, users served by the failed S-CSCF will not be able to continue to obtain services until these users who cannot continue to obtain services register again , to restore normal session handling for these users. However, since a short registration interval will generate a large amount of communication traffic, the user registration interval is generally relatively long, about tens of minutes. That is to say, if the user registration interval is tens of minutes, then the user who cannot continue to obtain services due to the faulty S-CSCF will still be unable to resume normal session processing within the user registration interval of tens of minutes , affecting the user experience. Moreover, even after the faulty S-CSCF recovers, if these users do not re-register, services may not be restored immediately.

Contents of the invention

In view of this, the main purpose of the present invention is to provide a SCSCF entity backup method and system thereof, so that S-CSCF can realize remote disaster recovery.

To achieve the above object, the present invention provides a method for backing up a service call session control function entity, comprising the following steps:

When the user registration is successful, the SCSCF entity initiates a request to save the relevant information of the user to another SCSCF entity that shares the load with this entity, and backs up and processes the user session initiation protocol in the data backup entity Dynamic data required for SIP requests;

If the other CSCF entity receives the user's SIP request, the other CSCF entity downloads the user's SIP request from the data backup entity according to the stored relevant information of the user. The dynamic data, and process the user's SIP request accordingly.

Among them, the following steps are also included:

When the SCSCF entity fails, the network side forwards the SIP request of the registered user in the entity to the other SCSCF entity.

In addition, in the method, the S-CSCF entity initiates the request for storing relevant information of the user to the other S-CSCF entity through third-party registration, and the request includes the relevant information of the user. information;

The other service call session control function entity saves the received relevant information of the user.

Furthermore, in the method, the relevant information of the user includes a user identification of the user.

In addition, in the method, the data backup entity is an entity built in the home subscriber server or other network equipment for backing up data.

In addition, in the method, the service call session control function entity and the other service call session control function entities are respectively equipped with application servers supporting the IP multimedia subsystem service control ISC interface and the Sh interface;

The application server in the service call session control function entity initiates the request for saving the user-related information through the ISC interface, and backs up the dynamic data to the data backup entity through the Sh interface;

The application server in the other service call session control function entity receives the request for saving the relevant information of the user through the ISC interface, and downloads the dynamic data from the data backup entity through the Sh interface.

In addition, in the method, the dynamic data is saved or downloaded in the data backup entity as transparent data;

The other S-CSCF entity downloads corresponding dynamic data from the data backup entity according to the user-related information stored in the S-CSCF entity.

Furthermore, in the method, the SIP request includes one of the following or any combination thereof: a registration request, a session request, and an independent transaction request.

In addition, in the method, the dynamic data includes user registration data, subscription data and session data;

The user registration data includes the "path" header field and the "Contact" header field address in the registration message.

Furthermore, in the method, the domain name of the S-CSCF entity is the same as that of the other S-CSCF entities. When the call session control function entity fails, query the call session control function entity to use DNS to resolve the domain name, obtain the address of the other service call session control function entity, and then forward the user's SIP request message to the Other services call the session control functional entity.

The present invention also provides a backup system for the service call session control function entity, which includes two service call session control function entities working in a load sharing manner, and the service call session control function entity also includes information for initiating and saving user related information The request module for the request, the save module for saving user-related information, the backup module for backing up the dynamic data required for processing the user's SIP request to the data backup entity, and querying whether the received SIP request belongs to the call session control function entity of this service A query module for users who save relevant information, and a download module for downloading the dynamic data from the data backup entity;

When the user registration of the SCSCF entity is successful, the request module in the entity initiates a request to save the relevant information of the user to other SCSCF entities, and the backup in the SCSCF entity The module backs up the dynamic data required for processing the user's SIP request to the data backup entity;

The storage module in the other service call session control function entity saves the received relevant information of the user, and the query module in the entity inquires whether the received SIP request belongs to the storage module in the service call session control function entity If there is a user with relevant information saved, the download module in the entity downloads corresponding dynamic data from the data backup entity according to the saved user related information, and processes the user's SIP request accordingly.

Wherein, the service call session control function entity is respectively equipped with an application server, and the request module, storage module, backup module, query module, and download module are located in the application server.

In addition, in the system, the application server supports the ISC interface and the Sh interface;

The requesting module and the saving module initiate and receive the request for saving user-related information through the ISC interface of the application server

The backup module backs up the dynamic data to the data backup entity through the Sh interface of the application server;

The download module downloads the dynamic data from the data backup entity through the Sh interface.

Through comparison, it can be found that the main difference between the technical solution of the present invention and the prior art is that, through the built-in AS in the S-CSCF, when the user registers successfully, the user's information is sent to the S-CSCF through third-party registration. - In another S-CSCF where the CSCF works in load sharing mode, the S-CSCF that receives the user-related information saves the user-related information as third-party registration information, and at the same time, the S-CSCF will process the SIP request of the user The required dynamic data is backed up to a data backup entity, such as HSS. When the S-CSCF fails, the network side forwards the SIP request of the registered user in the failed S-CSCF to another S-CSCF. If the S-CSCF receives a SIP request belonging to a third-party registered user, it will download the dynamic data of the user from the HSS according to the third-party registration information of the user, and continue to provide services for the user. In this way, service continuity of registered users in the faulty S-CSCF is guaranteed, remote disaster recovery capability of S-CSCF equipment is realized, user experience is improved, and IMS service quality is improved.

Description of drawings

Fig. 1 is a system structure diagram according to a kind of S-CSCF backup of the present invention;

Fig. 2 is a flow chart of user registration in the S-CSCF backup method according to the first embodiment of the present invention;

Fig. 3 is a flow chart of calling user session processing in the S-CSCF backup method according to the second embodiment of the present invention;

Fig. 4 is a flow chart of called user session processing in the S-CSCF backup method according to the third embodiment of the present invention.

Detailed ways

In order to make the object, technical solution and advantages of the present invention clearer, the present invention will be further described in detail below in conjunction with the accompanying drawings.

The core of the present invention is that when the user successfully registers in the S-CSCF, the S-CSCF initiates the process of saving the user-related information to another S-CSCF that shares the load with the S-CSCF through a third-party registration method. request, and back up the dynamic data required to process the user's SIP request as transparent data to the data backup entity used for backing up data in the HSS or other network devices. When the S-CSCF fails, the network side forwards the SIP request of the registered user in the failed S-CSCF to another S-CSCF sharing the load with the S-CSCF. If the S-CSCF receives a SIP request that does not belong to the registered user of the S-CSCF, it will check whether the SIP request belongs to a third-party registered user of the S-CSCF, and if so, it will backup the data according to the third-party registration information of the user The entity downloads the dynamic data required for processing the user's SIP request, and processes the user's SIP request accordingly.

The system structure of the present invention is shown in Figure 1. It includes two S-CSCFs that work in a load sharing manner. Each S-CSCF also includes a request module for initiating a request for storing user-related information, and a request module for storing user-related information. Information storage module, a backup module for backing up the dynamic data required for processing user SIP requests to the data backup entity, and a query for inquiring whether the received SIP request belongs to the user with relevant information stored in the S-CSCF module, and a download module for downloading dynamic data from the data backup entity.

The interaction between the modules in the system is described below.

When the user successfully registers in the S-CSCF (such as S-CSCF 1), the request module in the S-CSCF 1 registers with another S-CSCF that shares the load with the S-CSCF 1 through a third-party registration method, For example, the saving module of S-CSCF 2 initiates a request for saving the relevant information of the user. After receiving the relevant information of the user, the storage module in the S-CSCF2 stores the information as the third-party registration information of the user. At the same time, the backup module in S-CSCF 1 backs up the dynamic data required for processing the user's SIP request to a data backup entity, such as HSS. It should be noted that S-CSCF 1 and S-CSCF 2 use the same domain name.

When S-CSCF 1 fails, because the S-CSCF 1 cannot process the corresponding SIP request for its registered users, the network side forwards the SIP requests of the registered users in the S-CSCF 1 to S-CSCF 2. When S-CSCF 2 receives a SIP request and judges that the SIP request does not belong to the registered user of the S-CSCF 2, it will query whether the SIP request belongs to the SIP request through the query module in the S-CSCF 2 according to the third-party registration information in the storage module. A third-party registered user of S-CSCF 2. If the query module determines that the SIP request received by the S-CSCF 2 belongs to a third-party registered user of the S-CSCF 2, then the download module of the S-CSCF 2 can retrieve the data from the data according to the third-party registration information of the user in the storage module. The backup entity, such as the HSS, downloads the corresponding dynamic data, and the S-CSCF 2 processes the received SIP request accordingly.

It should be noted that the above-mentioned request module, save module, backup module, query module and download module can be located in the AS added in the S-CSCF, and make the AS support the ISC interface and the Sh interface, so that the request module and the save module The request for saving user-related information initiated by the third-party registration method can be initiated or received through the ISC interface of the AS. The backup module can back up the dynamic data required for processing the user's SIP request to the HSS through the Sh interface of the AS. The download module can

Download the corresponding dynamic data and subscription information from the HSS through the Sh interface of the AS.

The system configuration of the present invention has been described above, and the first embodiment of the present invention will be described below. The first embodiment of the present invention is based on the above-mentioned system. In this embodiment, it is mainly clarified that when the user registration is successful, the S-CSCF initiates a request to save user-related information through a third-party registration method, and the data backup entity is HSS .

As shown in FIG. 2, in step 201, a user initiates a registration request.

In step 202, when the P-CSCF receives the user's registration request, it uses the domain name service system (DOMAIN NAME SYSTEM, referred to as "DNS") to analyze the home network address in the registration request, so as to obtain the user's attribution Address of the network I-CSCF.

Next, in step 203, the P-CSCF forwards the received user registration request to the I-CSCF obtained in step 202.

In step 204, after receiving the user registration request forwarded by the P-CSCF, the I-CSCF queries the HSS for the registration status of the user through the Cx.

Next, enter step 205, the I-CSCF obtains the S-CSCF assigned to the user according to the information returned by the HSS in step 204. In this embodiment, the S-CSCF assigned to the user is S-CSCF 1. And send the user registration request received from the P-CSCF to the obtained S-CSCF assigned to the user, namely S-CSCF 1.

Then, enter step 206, after S-CSCF 1 receives the registration request from the user, it inquires the user data of the user from the HSS through the Cx interface and checks the registration information provided by the user. If the user is successfully registered in the S-CSCF 1, the S-CSCF 1 downloads the subscription data of the user from the HSS.

Then, enter step 207, S-CSCF 1 initiates a request to save the relevant information of the user to another S-CSCF sharing the load with the S-CSCF 1, that is, S-CSCF 2, through a third-party registration method. Specifically, S-CSCF 1 and S-CSCF 2 are equipped with ASs supporting ISC interface and Sh interface respectively. When a user successfully registers in S-CSCF 1, the AS in S-CSCF 1 registers with a third party The method sends the relevant information of the user to the AS in the S-CSCF 2 through the ISC interface. Wherein, the relevant information of the user may only include the user ID of the user.

Then, enter step 208, the S-CSCF 2 saves the received relevant information of the user as the third-party registration information of the user. Specifically, after the AS in S-CSCF 2 receives the user-related information sent by the AS in S-CSCF 1 through the ISC interface through the ISC interface, the information is stored in the S-CSCF as the third-party registration information of the user. In the AS of CSCF 2, complete the third-party registration of the user.

Next, enter step 209, the S-CSCF 2 sends a confirmation message to the S-CSCF 1, in order to respond to the request initiated by the S-CSCF 2 for storing user-related information.

Next, enter step 210, S-CSCF 1 saves user registration data. Then, go to step 211.

In step 211, S-CSCF 1 saves the dynamic data required for processing the user's SIP request into the HSS as transparent data. Specifically, the AS in S-CSCF 1 saves the dynamic data required to process the user's SIP request as transparent data into the HSS through the Sh interface. Among them, in addition to the "path" header field and the "Contact" header field that are used to find the terminal where the user is located and the specific address of the user terminal in the registration message at least included in the dynamic data, the dynamic data may also include or partially include the registration information according to the different SIP requests. data, subscription data, and session data. Wherein, the registration data includes information such as registration timer duration and IMPI identifier carried in the registration message. Subscription data includes subscription data including CallID, From tag, To tag, timer duration, Request-URI, Record-Route and other information carried in the subscription request of the user to subscribe to the registration event. So that the network can notify the user of the registration status based on this information. Dialog data refers to the dialog data established by the user, including dialog control data, dialog call status, billing data, etc. So that the network can continue to control these conversations based on the information, and can charge the conversations.

Next, in step 212, the HSS sends an update response notification message to S-CSCF 1. Then, the S-CSCF 1 in the step 213 sends the registration success confirmation message to the I-CSCF, the I-CSCF in the step 214 sends the registration success confirmation message to the P-CSCF and the P-CSCF in the step 215 sends the registration success confirmation message to the user where the user is located. The device sends a success confirmation message, and finally returns the user's registration success confirmation message to the user.

In this embodiment, the SIP request may be a registration request, a session request, an independent transaction request, or any combination thereof.

The second embodiment of the present invention is based on the first embodiment. In this embodiment, the calling side user who initiates the SIP request is a third-party registered user belonging to S-CSCF2.

As shown in Fig. 3, in step 301, a user initiates a SIP request to the P-CSCF of its home network.

Next, in step 302, after receiving the SIP request initiated by the user, the P-CSCF uses the DNS protocol to resolve the S-CSCF domain name saved by the user during the registration process, thereby obtaining the S-CSCF domain name of the user's home network. The address, in this embodiment, is the address of S-CSCF 1.

Next, in step 303, the P-CSCF forwards the user's SIP request to the address of the user's home network S-CSCF 1 obtained in step 302.

Then, in step 304, S-CSCF 1 cannot answer the SIP request forwarded by P-CSCF due to failure.

Then, enter step 305, after the timer expires, the P-CSCF judges that the S-CSCF 1 is unavailable, and resolves the domain name of the S-CSCF 1 through DNS to obtain another S-CSCF address that can forward the SIP request. Specifically, for S-CSCF 1 and S-CSCF 2 working in load sharing mode, since their IP addresses correspond to the same domain name on the DNS server, when an address is unavailable, P-CSCF can Query results, select other available addresses from the addresses corresponding to the domain name. Therefore, P-CSCF selects the address of S-CSCF 2.

Then, in step 306, the P-CSCF forwards the SIP request to the S-CSCF 2.

Next, in step 307, S-CSCF 2 inquires whether the received SIP request belongs to a user registered by a third party. Specifically, when S-CSCF 2 receives a SIP request, if the user who initiates the request is not registered, but the S-CSCF 2 learns that its built-in AS has saved the user as third-party registration information through query relevant information, the S-CSCF 2 considers that the S-CSCF serving the user has failed, and the user needs to be migrated to the S-CSCF.

Next, enter step 308, the S-CSCF 2 requests the HSS to download the transparent data. Specifically, the AS in the S-CSCF 2 requests the HSS to download the dynamic data stored as transparent data of the user through the Sh interface according to the stored user-related information.

Next, in step 309, the HSS responds to the transparent data download request of the S-CSCF 2, and returns the transparent data of the user to the S-CSCF2.

Next, in step 310, the S-CSCF 2 requests the HSS to download the subscription information. Specifically, the S-CSCF2 queries the HSS for the obtained subscription information of the user through the Cx interface according to the user registration information in the transparent data.

Then, in step 311, the HSS responds to the download request of the S-CSCF 2, and returns the subscription information of the user to the S-CSCF 2.

Next, in step 312, S-CSCF 2 processes the user's SIP request according to the downloaded user's dynamic data and subscription information.

Specifically, if the S-CSCF 2 receives a registration request message belonging to a third-party registered user, the S-CSCF 2 will request the HSS to download the user's transparent data through the Sh interface of the built-in AS. If the user needs to be authenticated, according to the downloaded transparent data, download the user's authentication data from the HSS through the Cx interface, and then initiate re-authentication for the user according to the authentication data. After the authentication is passed, the subscription information is downloaded from the HSS, and the registration request is processed according to the subscription information. After the user registers successfully, refresh the registration data in the downloaded transparent data according to the data requested by the user registration.

If S-CSCF 2 receives a subscription request message belonging to a third-party registered user, S-CSCF 2 will request the HSS to download the user's transparent data through the Sh interface of the built-in AS, and then according to the downloaded transparent data, through Cx The interface downloads the subscription information of the user from the HSS, and then processes the subscription request according to the subscription information. After the subscription request is successfully processed, the subscription data in the downloaded transparent data is refreshed according to the data of the user subscription request.

If S-CSCF 2 receives other dialogue request messages or transaction request messages belonging to a third-party registered user, S-CSCF 2 will request the HSS to download the transparent data of the user through the Sh interface of the built-in AS, and then Transparent data, download the user's subscription information from the HSS through the Cx interface, and then process the request according to the subscription information.

It should be noted that, if the transparent data downloaded by S-CSCF 2 contains dialog data, S-CSCF 2 restores the dialog based on these data, and processes subsequent messages of the dialog.

Then, in step 313, S-CSCF 2 forwards the processed SIP request of the user to the called side network.

In this embodiment, because the S-CSCF 2 sharing the load can continue to provide services for the registered users in the failed S-CSCF 1. In this way, the service continuity of the registered users in the faulty S-CSCF 1 is guaranteed, the remote disaster recovery capability of the S-CSCF equipment is realized, the user experience is improved, and the IMS service quality is improved.

The third embodiment of the present invention is roughly the same as the second embodiment, the only difference is that in the second embodiment, the user belonging to the third party registration in S-CSCF 2 is the calling side user, while in this embodiment , the user registered by the third party in S-CSCF 2 is the called side user.

As shown in Fig. 4, in step 401, the home I-CSCF of the user on the called side receives the SIP request from the calling side.

Next, enter step 402. After receiving the SIP request from the calling side, the I-CSCF uses the DNS protocol to resolve the S-CSCF domain name saved by the called user during the registration process, thereby obtaining the user's home network S- The address of the CSCF is, in this embodiment, the address of the S-CSCF 1.

Next, in step 403, the I-CSCF forwards the user's SIP request to the address of the user's home network S-CSCF 1 obtained in step 402.

Then, in step 404, S-CSCF 1 cannot answer the session request forwarded by I-CSCF due to failure.

Then, in step 405, after the timer expires, the I-CSCF judges that the S-CSCF 1 is unavailable, and resolves the domain name of the S-CSCF 1 through DNS to obtain another S-CSCF address that can forward the session request. Specifically, for S-CSCF 1 and S-CSCF 2 working in load sharing mode, since their IP addresses correspond to the same domain name on the DNS server, when one address is unavailable, I-CSCF can Query results, select other available addresses from the addresses corresponding to the domain name. Therefore, I-CSCF selects the address of S-CSCF 2.

Then, in step 406, the I-CSCF forwards the SIP request to the S-CSCF 2.

Next, in step 407 to step 412, S-CSCF 2 inquires whether the received SIP request belongs to a user registered by a third party. If yes, then download the user's dynamic data stored as transparent data and the user's subscription information to the HSS, and process the user's SIP request accordingly. Step 407 to step 412 correspond to step 307 to step 312, and will not be repeated here.

In step 413, S-CSCF 2 forwards the processed SIP request of the user to the home P-CSCF of the user according to the "path" header field and the "Contact" header field in the transparent data.

It can be seen that even if the registered user in the faulty S-CSCF 1 is the called side user, the S-CSCF 2 sharing the load with the faulty S-CSCF 1 can also guarantee the service continuity of the user, realizing the S - The remote disaster recovery capability of CSCF equipment improves user experience and IMS service quality.

Although the present invention has been illustrated and described with reference to certain preferred embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the present invention. The spirit and scope of the invention.

Claims (13)

1. A service call session control function entity backup method, is characterized in that, comprises the following steps: When the user registration is successful, the SCSCF entity initiates a request to save the relevant information of the user to another SCSCF entity that shares the load with this entity, and backs up and processes the user session initiation protocol in the data backup entity Dynamic data required for SIP requests; If the other CSCF entity receives the user's SIP request, the other CSCF entity downloads the user's SIP request from the data backup entity according to the stored relevant information of the user. The dynamic data, and process the user's SIP request accordingly. 2. The service call session control function entity backup method according to claim 1, is characterized in that, also comprises the following steps: When the SCSCF entity fails, the network side forwards the SIP request of the registered user in the entity to the other SCSCF entity. 3. The SCSCF entity backup method according to claim 1, wherein the SCSCF entity initiates the saving to the other SCSCF entities through third-party registration A request for relevant information of the user, which includes relevant information of the user; The other service call session control function entity saves the received relevant information of the user. 4. The SCSCF entity backup method according to claim 3, wherein the relevant information of the user includes the user ID of the user. 5. The SCSCF entity backup method according to claim 1, wherein the data backup entity is an entity for backing up data built in the home subscriber server or other network equipment. 6. The method for backing up an S-CSCF entity according to any one of claims 1 to 5, wherein the S-CSCF entity and the other S-CSCF entities are respectively equipped with Application server supporting IP multimedia subsystem service control ISC interface and Sh interface; The application server in the service call session control function entity initiates the request for saving the user-related information through the ISC interface, and backs up the dynamic data to the data backup entity through the Sh interface; The application server in the other service call session control function entity receives the request for saving the relevant information of the user through the ISC interface, and downloads the dynamic data from the data backup entity through the Sh interface. 7. The service call session control function entity backup method according to claim 6, wherein the dynamic data is saved or downloaded in the data backup entity as transparent data; The other S-CSCF entity downloads corresponding dynamic data from the data backup entity according to the user-related information stored in the S-CSCF entity. 8. The method for backing up a service call session control function entity according to claim 6, wherein the SIP request includes one of the following or any combination thereof: a registration request, a dialog request, and an independent transaction request. 9. The service call session control function entity backup method according to claim 8, wherein the dynamic data includes user registration data, subscription data and session data; The user registration data includes the "path" header field and the "Contact" header field address in the registration message. 10. The method for backing up an S-CSCF entity according to claim 6, wherein the domain name of the S-CSCF entity is the same as that of the other S-CSCF entities. 11. A SCSCF entity backup system, comprising two SCSCF entities working in a load-sharing manner, characterized in that, the SCSCF entity also includes a function for initiating and saving user-related Request module for information request, save module for saving user-related information, backup module for backing up dynamic data required for processing user SIP requests to the data backup entity, query whether the received SIP request belongs to the service call session control function entity A query module for users with relevant information stored therein, and a download module for downloading the dynamic data from the data backup entity; When the user registration of the SCSCF entity is successful, the request module in the entity initiates a request to save the relevant information of the user to other SCSCF entities, and the backup in the SCSCF entity The module backs up the dynamic data required for processing the user's SIP request to the data backup entity; The storage module in the other service call session control function entity saves the received relevant information of the user, and the query module in the entity inquires whether the received SIP request belongs to the storage module in the service call session control function entity If there is a user with relevant information saved, the download module in the entity downloads corresponding dynamic data from the data backup entity according to the saved user related information, and processes the user's SIP request accordingly. 12. The service call session control function entity backup system according to claim 11, characterized in that, the service call session control function entity is respectively equipped with an application server, and the request module, the preservation module, the backup module, and the query module , and the download module are located in the application server. 13. The service call session control function entity backup system according to claim 12, wherein the application server supports an ISC interface and a Sh interface; The requesting module and the saving module initiate and receive the request for saving user-related information through the ISC interface of the application server The backup module backs up the dynamic data to the data backup entity through the Sh interface of the application server; The download module downloads the dynamic data from the data backup entity through the Sh interface.

Images