WO2009036629A1 - Processing method after core network element restarting or recovering form failure - Google Patents

Abstract

A processing method after core network element restarting or recovering form failure is provided. The method includes: In call process that a user initiates, core network element checks local data after receiving the call request which comes from the user; When the data that corresponds to the user is not found, the core network element send one or many request message to HSS in order to acquiring service-related data; Responding to the request message, the HSS looks up service-related data and send it to core network element; The core network element continues the call according to the above service-related data.

Description

 TECHNICAL FIELD The present invention relates to the field of communications, and more particularly to a method of processing after core network element restart/failure recovery in an IP multimedia subsystem. Background technique

The IP Multimedia Core Network Subsystem (IMS) is the core of a new generation of communication networks. Figure 1 depicts the network element entities associated with the present invention and their associations in the IMS architecture. The User Equipment (UE) 101 represents the terminal device used by the user. The Call Session Control Function (CSCF) is the core network element that controls the session process, including: Proxy Call Session Control Function (Proxy) -CSCF, abbreviated as P-CSCF) 102, Interrogating-CSCF (I-CSCF for short) 103, Serving-CSCF (S-CSCF for short) 104, wherein the home subscriber server ( The Home Subscriber Server (HSS) 104 is the primary storage server for all user and server related data in the IMS. The Application Server (AS) 106 is a network element that provides value-added multimedia services. Between the various network elements shown in FIG. 1, the UE is connected to the P-CSCF through the Gm interface; the P-CSCF, the I-CSCF, and the S-CSCF are interconnected through the Mw interface; the HSS implements the I-CSCF through the Cx interface, The S-CSCF is connected to the AS through the Sh interface. The S-CSCF is connected to the AS through an ISC (IMS Service Control, IMS Service Control, ISCH) interface.

As the first contact point of the user in the IMS system, all the Session Initiation Protocol (SIP) signaling, whether from the UE or the UE, must pass through the P-CSCF. After the UE is successfully registered in the IMS system, the P-CSCF locally stores the contact address of the UE, the Public User Identity (PUI) of the UE, and the Private User Identity (PVI) of the UE.

The S-CSCF is the core of the IMS and is located in the home network to perform session control and registration for the UE. When the UE is in the session, the S-CSCF handles the state of the tongue in the network. After the UE successfully registers in the IMS system, the S-CSCF locally saves the UE used to register with the IMS system. The network ID of the P-CSCF, the IP address of the P-CSCF, the contact address of the UE, the public user identity of the UE, the private user identity of the UE, the user configuration data corresponding to the public user identity of the UE, and the HSS address storing the UE registration status. Or name and other information.

The HSS is the storage core of all user and server related data in the IMS system. It not only stores static data related to users and servers, but also saves some dynamic data. After the UE successfully registers in the IMS system, the HSS saves the S-CSCF address or name assigned to the UE.

After the UE is successfully registered, the P-CSCF, the S-CSCF, and the corresponding HSS allocated by the network for the UE constitute a communication link used by the UE for subsequent communication. After the registration is successful, the UE initiates the call process, the UE is called, and the network will use the communication link already allocated for the UE. Under normal circumstances, after the UE is successfully registered, the communication link allocated by the network to the UE remains unchanged in the subsequent process. This means that once a problem occurs on a link on the link, it will affect the subsequent call and termination procedures of the UE, making the communication not work properly. When the IMS system user accesses the system, an initial registration is required before using the service provided by the IMS system. Typically, the initial registration process usually occurs when the UE is powered on. FIG. 2 shows an initial registration process of an IMS user in the related art, as shown in FIG. 2, including the following steps:

S201: The UE sends a registration request to the P-CSCF, where the registration request carries a public user identifier.

5202, when receiving the registration request, the P-CSCF finds the I-CSCF of the user home network access point through a DNS query or other method, and forwards the registration request to the I-CSCF; S203, the I-CSCF sends a request message to the HSS, Requesting to allocate an S-CSCF to the UE;

5204, the HSS returns the name of the S-CSCF or the S-CSCF of the S-CSCF to the I-CSCF;

5205, the I-CSCF sends a registration request message to the selected S-CSCF;

S206-S216, if the S-CSCF needs to perform authentication authentication on the user, the user authentication vector needs to be obtained from the HSS, and a challenge request (401 Unauthorized message) is constructed according to the authentication vector returned in the S207 message, and the challenge request is forwarded to the UE. After the UE constructs a challenge response, the S-CSCF receives the S215 challenge response message, determines the legitimacy of the user, and completes the authentication and authentication of the user; if authentication authentication is not required, the S217 may be directly executed; S217. The S-CSCF sends a user configuration data acquisition request to the HSS.

5218, the HSS stores the S-CSCF information, and returns the subscription data and the charging address information of the user to the S-CSCF;

5219, the S-CSCF initiates a third-party registration with the AS; S220, the AS successfully performs the third-party registration successfully, and returns a successful response;

S221-S223, the S-CSCF constructs a registration success response, and forwards the response to the UE via the I-CSCF and the P-CSCF. After the initial registration process of the UE is successfully completed, each core network element saves the following data related to the UE: P- The CSCF saves the contact address of the UE, the public user identifier PUI of the UE, and the private user identifier PVI of the UE; the S-CSCF saves the network ID of the P-CSCF corresponding to the UE, the IP address or name of the P-CSCF corresponding to the UE, and the contact of the UE. The address, the public user identifier PUI of the UE, the private user identifier PVI of the UE, the user configuration data corresponding to the public user identifier of the UE, the HSS address or name corresponding to the UE, and the charging address of the PUI user. After the UE successfully registers with the IMS system, the UE can perform a service process such as a subsequent call. FIG. 3 is a flowchart of a call initiated by a UE located in a visited network in a related art, as shown in FIG. 3, including the following processing:

5301. The UE initiates a SIP INVITE request to the P-CSCF, where the INVITE request includes a media format used to initialize media capability negotiation.

5302. After receiving the INVITE request, the P-CSCF forwards the INVITE request to the S-CSCF allocated to the UE.

5303. The S-CSCF checks the monthly service attribute, and initiates a call service for the user. The call service logic includes authorization for the requested SDP, and the SDP is based on the subscription of the multimedia service by the user; in this step, S - The operation of checking the service attribute of the CSCF includes: querying the registration status of the PUI corresponding to the UE in the local data, checking the user configuration data corresponding to the PUI, and the like;

S304: The S-CSCF forwards the INVITE request to the called party network. 5305. The called party network returns an Offer response, where the response includes media support capability of the called party terminal.

 5306, the S-CSCF sends the Offer response back to the P-CSCF;

 5307, the P-CSCF allocates necessary resources for the session;

 S308. The P-CSCF forwards the message to the call originating end.

 5309, the UE sends an acknowledgement response to the Offer response according to the provided media stream set, to confirm the media capability negotiated by the two parties, and forward the acknowledgement information to the P-CSCF through the call initiation process;

 After determining the resources required in step S308, the UE reserves resources for the session.

5311, P-CSCF 4 contention response confirmation message to the S-CSCF;

 S312, the S-CSCF forwards the message to the called party network, and forwards the called party network to the called terminal node;

 S313 - S315, the called party terminal node responds with an acknowledgement message to confirm the media capability selected by the calling party. At this point, the media capacity negotiation is over;

 S316-S318: After completing the resource reservation, the UE sends a message that the resource reservation is successful to the terminal node. The message is forwarded to the called party terminal through the P-CSCF-level;

 S319-S321, the called party terminates the endpoint to respond to the resource reservation success;

 S322-S324, the called party terminates the ringing of the endpoint, and delivers the message to the UE;

 5325, the UE informs the user that the called party is ringing;

 5326. After the called party picks up the call, the terminating endpoint sends a SIP200 (OK) final response to the S-CSCF.

 5327, the S-CSCF sends a SIP 200 (OK) final response to the P-CSCF;

 5328. The P-CSCF indicates that resources reserved for the session are available.

 5329, the P-CSCF sends back a SIP200 (OK) final response to the session initiator;

5330, the UE starts the media stream of the session, S331 ~ S333, the UE responds with 200 (OK) with a SIPACK message. The UE-initiated call flow shown in Figure 3 is only for explaining the role played by the S-CSCF of the calling party's home network in calling the UE-initiated calling process. It can be known from this process that the S-CSCF of the calling party's home network is one of the most important session control process control entities in the process, which is used to check the status of the UE and exchange signaling from the visited network and the terminating network for the UE. . If the S-CSCF allocated by the UE home network for the UE is restarted after the UE successfully registers with the IMS system, the UE may be restarted due to the upgrade of the system, or the S-CSCF itself may be faulty. Restart with the need for recovery. After the S-CSCF is restarted, the originally saved data is also lost, that is, for the UE, the contact address corresponding to the UE and the network ID of the P-CSCF corresponding to the UE saved by the S-CSCF. The name or address of the P-CSCF corresponding to the UE, the PUI corresponding to the UE, the PVI corresponding to the UE, the state of the PUI corresponding to the UE, and the user configuration data associated with the PUI corresponding to the UE, etc. Lost due to failure recovery or restart of the S-CSCF. In this case, if the UE still initiates a call, it will cause the call to fail. Figure 4 depicts the flow of the UE initiating a call failure in this case. Similarly, as an example, the UE is still located in the visited network, and the case where the UE is located in the local network is substantially similar to the flow. In the process of the UE starting the call process failure described in FIG. 4, the following processing is included:

S401. The UE sends a SIP INVITE request to the P-CSCF, where the INVITE request includes a media format for initializing media capability negotiation. S402. After receiving the INVITE request, the P-CSCF forwards the INVITE request to the UE S. -CSCF;

S403, the S-CSCF checks the service attribute, and if the data corresponding to the UE is not retrieved in the locally stored data, the call request is considered unreceivable;

S404: The S-CSCF sends a response that the request is unreceivable to the P-CSCF. S405: The P-CSCF forwards the request unreceivable response to the UE. At this point, the call is interrupted because the S-CSCF cannot process the call request initiated by the UE. In this case, the normal communication link can be re-established only after waiting for the UE to initiate the re-registration process. FIG. 4 illustrates another scenario in which an S-CSCF failure causes a service to be unavailable, wherein the application server AS replaces the user-initiated call flow, and the S-CSCF failure causes the necessary user data to be missing. At this point, the user may have already registered to the IMS system, or may be in a non-registered state. A typical service in which the application server AS in the non-registered state replaces the user to initiate a call is that the user subscribes to the non-registered forwarding service. The user registration status application server AS replaces the typical service initiated by the user with the service actively notified by the AS. The S-CSCF failure described in Figure 4 causes the service to be unavailable. Similarly, it may also appear on the application server. Once the application server lacks the necessary user data, the service will not work properly. It can be seen from the above analysis that the S-CSCF and the AS are important core network elements in the session process. Once they lose user data, they will lose the ability to process subsequent services for the user. At the same time, it can be seen that there are some shortcomings in the current IMS system, especially after the core network element restarts or recovers from the fault, which usually affects the normal processing of subsequent calls and service flows. SUMMARY OF THE INVENTION The present invention has been made in view of the above problems in the related art. Accordingly, the present invention is directed to a processing method after a core network element restart/failure recovery. The method is applied to an IP multimedia subsystem, and the IP multimedia subsystem comprises: a user equipment (UE), an application server (AS), a monthly call session control function entity (S-CSCF), and a proxy call session control function entity (P). -CSCF ), Home User Server (HSS). The method includes the following processing: in a call process in which the user is a calling party, after receiving the call request of the user, the core network element checks the local data, and sends the data to the home subscriber server without checking the data corresponding to the user. One or more request messages to request service related data of the user; in response to the request message of the core network element, the home user server searches for service related data and returns it to the core network element; the core network element uses the service obtained from the home user server Related data, into the subsequent session processing process. The service-related data includes the service configuration data, where the core network element uses the service configuration data to trigger the service logic. Preferably, the service-related data further includes: a registration status information of a public user identifier (PUI), where, the core The network element uses the registration status information to enhance the judgment of call legitimacy. The request message sent by the core network element carries the fault recovery support label. The core network element described above may be an S-CSCF or an AS. The description will be separately made below. In the case that the core network element is the S-CSCF, the S-CSCF sends a request message to the home subscriber server using the Cx interface between the S-CSCF and the home subscriber server, and carries the S-CSCF name and the user in the request message. Public user ID. The above request message may be a service allocation request message. In response to the request message of the S-CSCF, the home subscriber server determines whether the S-CSCF name of the S-CSCF allocated by the public subscriber identity is consistent with the name of the S-CSCF carried in the request message, and if the two are inconsistent, the decision is made. Whether to update the S-CSCF assigned to the public user ID. In the case where the home subscriber server is updated to the S-CSCF assigned to the public subscriber identity, the S-CSCF performs data saving locally. In one aspect, the foregoing call process may be a call initiated by the user equipment, and the S-CSCF may be allocated to the user in the following situations: the user successfully registers with the IP multimedia subsystem network; or the user subscribes to the unregistered service, and is triggered by the unregistered service. The S-CSCF allocation process. In this case, the method may further include: the S-CSCF locally saves the data, and the saved data includes: a contact address of the user equipment, an address of the P-CSCF, a network ID of the P-CSCF, a public user identifier, and a public The registration status of the user ID and the service configuration data of the user. On the other hand, the above call process is an application server instead of a user-initiated call, wherein the user can be in a registered state or a non-registered state. In this case, the S-CSCF saves the data locally, and the saved data includes: the contact address of the application server, the public user ID, the registration status of the public user ID, and the service configuration data of the user. The core network element in the method may also be an application server. In this case, the application server sends a request message to the home subscriber server by using the Sh interface between the application server and the home subscriber server, and carries the public user identifier of the user in the request message. The above request message may be a user data request message. Moreover, in a case where the core network element is an AS, the method may further include: the application server locally saves the data, where the saved data includes: a contact address of the user equipment, an address of the S-CSCF, a public user identifier, and a public user identifier. Registration status, user's business configuration data. Through the invention, after the user data of the core network element of the IMS system is lost, the method of querying the required user data to the HSS can effectively solve the problem that the core network element data is missing. The defect that the service is unavailable, guarantees the continuity of the service, and enhances the fault handling capability of the core network element. Other features and advantages of the invention will be set forth in the description which follows, and The objectives and other advantages of the invention will be realized and attained by the <RTI The drawings are intended to provide a further understanding of the invention, and are intended to be a part of the description of the invention. In the drawings: FIG. 1 is a schematic structural diagram of an IMS system according to the related art; FIG. 2 is a flowchart of initial registration of a UE registered in an IMS system according to the related art; FIG. 3 is a call initiated by a UE according to the related art FIG. 4 is a flowchart of a call failure when a UE initiates a call flow after an S-CSCF restart or failure recovery allocated to a UE according to the related art; FIG. 5 is a core network according to an embodiment of the present invention; FIG. 6 is a flowchart of a processing method after a meta-restart/failure recovery. FIG. 6 is a schematic diagram of a UE initiating a call flow after the UE is successfully registered, after the UE is successfully registered, after the UE is successfully registered or the S-CSCF is restarted or the fault is recovered. - The CSCF obtains the necessary data from the HSS to continue the flow chart of the call; FIG. 7 is a method according to an embodiment of the present invention, in which the PUI (Public User Identity) status corresponding to the UE is not registered, S-CSCF A flowchart of processing a UE-initiated call service by using the method S-CSCF of the present invention in a case where the user registration data is not held; FIG. 8 is a method, after the UE is successfully registered, in the method according to the embodiment of the present invention, After the S-CSCF is assigned to the UE for restart or failure recovery, the AS initiates a call flow instead of the user, and the S-CSCF obtains necessary data from the HSS to continue the completion of the call flow. FIG. 9 is a method according to an embodiment of the present invention, the UE After the registration is successful, after the AS serving the UE restarts or recovers from the fault, the AS obtains the necessary data from the HSS to continue the flow chart of the call. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS The preferred embodiments of the present invention are described with reference to the accompanying drawings. According to an embodiment of the present invention, a method for processing a core network element restart/failure recovery or the like in an IMS system is provided. The core network element mentioned herein may be an S-CSCF or an AS. The IMS environment to which the present invention is applied has been described above with reference to FIG. 1, as described above, including user equipment (UE), application server (AS), serving call session control function entity (S-CSCF), proxy call session control function entity (P-CSCF), Home Subscriber Server (HSS), etc. Based on the above description, as shown in FIG. 5, the method may include the following processing: Step S502: In a call process in which the user is a calling party, after receiving the call request of the user, the core network element checks the local data, and does not check the In the case of the data corresponding to the user, one or more request messages are sent to the HSS to request the service related data of the user. Step S504, in response to the request message of the core network element, the HSS searches for the service related data and returns the data to the core network. In step S506, the core network element uses the service-related data acquired from the HSS to perform a subsequent session processing procedure. The service-related data includes the service configuration data, where the core network element uses the service configuration data to trigger the service logic. Preferably, the service-related data further includes: a registration status information of a public user identifier (PUI), where, the core The network element uses the registration status information to strengthen the judgment of the call legal. In the case that there are multiple HSSs in the IP multimedia subsystem, in step S502, the core network element first queries the HSS where the user's PUI is located, and sends a request message to the queried HSS. In addition, the request message sent by the core network element carries the fault recovery support label, and the label is used to notify the HSS that the message is applied to the scenario of the fault recovery. In addition, in step S506, after acquiring the necessary data, the core network element may choose to save the data locally or not. Part of the data that can be saved comes from the call request, and part of it comes from the HSS. If the core network element chooses to save the data locally, the core network element does not need to request data from the HSS again during the subsequent call. Case 1 The core network element is the S-CSCF. When the core network element is the S-CSCF, the S-CSCF can be allocated to the user in the following cases: The user successfully registers with the IMS network; or the user subscribes to the unregistered service. The registration service triggers the S-CSCF allocation process. Specifically, in this case, in step S502, the S-CSCF sends a request message to the HSS using the Cx interface between the S-CSCF and the HSS, and carries the S-CSCF name and the user's PUI in the request message. The above request message may be a Service-Assignment-Request (SAR). In step S504, in response to the request message of the S-CSCF, the HSS determines whether the S-CSCF name of the S-CSCF allocated by the PUI is consistent with the S-CSCF name carried in the request message, and if the two are inconsistent , decide whether to update to PUI points g ^ ^ S-CSCF. The S-CSCF performs data saving locally when the HSS is updated to the PUI sub-segment S-CSCF ό 'I". The call process mentioned above may be a call initiated by the UE, or the AS may be initiated instead of the user. Example 1: UE-initiated call In the case that the UE initiates a call, in step S506, the S-CSCF can perform data saving locally, and the saved data includes: the contact address of the UE, the address of the P-CSCF, and P. - the network ID of the CSCF, the PUI, the registration status of the PUI, and the service configuration data of the user. However, in step S506, in the case where the registration state of the PUI acquired by the S-CSCF from the HSS is the non-registered state, the S-CSCF returns The service is unreceivable, and the subsequent process is not continued, and the service configuration data acquired from the HSS is not saved locally. The processing in this example is shown in detail in Figure 6. As shown in Figure 6, the following specifically includes:

5601, the UE initiates a SIP INVITE request to the P-CSCF, and includes a media format for initializing the media capability negotiation. Generally, the SIP INVITE request carries the contact address of the UE, the public user identifier PUI corresponding to the UE, and the like;

5602. After receiving the INVITE request, the P-CSCF forwards the INVITE request to the S-CSCF allocated to the UE. When the P-CSCF forwards the INVITE request, the P-CSCF adds the address information related to the P-CSCF to the SIP INVITE request. S603, the S-CSCF checks the service attribute; the operation of the S-CSCF to check the service attribute includes: querying, in the local data, the registration status of the PUI corresponding to the UE, checking the user configuration data corresponding to the PUI, etc.; The user data stored locally by the S-CSCF does not exist. In order to continue processing subsequent requests, the S-CSCF needs to send a data acquisition request to the HSS to query the status and data of the user.

The S-CSCF first extracts information related to the UE and the P-CSCF from the INVITE request sent by the P-CSCF, including the contact address of the UE, the public user identifier PUI corresponding to the UE, the IP address of the P-CSCF, and the network of the P-CSCF. ID or the like; the S-CSCF is locally - temporarily stores the data, and uses the data to transmit a data acquisition request to the HSS; and proceeds to step S604. S604: The S-CSCF initiates a data acquisition request to the HSS by using the PUI corresponding to the user, and expects the HSS to return the user PUI registration status and user service configuration data. In this step, the S-CSCF passes the SAR (Server- Assignment-Request, The service allocation request) command requests the user data to the HSS, and carries the S-CSCF address and the public user identifier PUI of the UE in the command; in addition, the S-CSCF carries the fault recovery support label in the detailed information of the command, and informs the HSS of the request. Is due to the failure recovery scenario;

S605, after the HSS owes a query request to the S-CSCF, obtains the registration of the user PUI; the service configuration data of the user and the user is sent to the S-CSCF; in this step, the HSS checks the SAR sent by the S-CSCF. The command, which carries the fault recovery support label, indicates that the S-CSCF wants to obtain the necessary data through the HSS to continue the service flow. In this step, the HSS checks the SAR command sent by the S-CSCF to obtain the S-CSCF name. Since the PUI corresponding to the UE has been successfully registered in this embodiment, the S-CSCF is allocated to the PUI in the HSS. The HSS checks the name of the S-CSCF corresponding to the PUI stored in the HSS. If the S-CSCF name is different from the name of the S-CSCF in the SAR, the HSS has two options: updating the S-CSCF name and not updating the S-CSCF name. . If the HSS updates the S-CSCF name corresponding to the PUI, it means that the HSS re-allocates the S-CSCF for the UE, and the S-CSCF must locally save the related data of the UE and the P-CSCF, specifically: UE contact Address, name or address of the P-CSCF, network ID of the P-CSCF, PUI corresponding to the UE, PUI registration status of the UE, service configuration data of the user, etc.; if the HSS does not update the S-CSCF corresponding to the PUI Name, the S-CSCF does not locally save the related data of the UE and the P-CSCF as described above in the subsequent steps; if the HSS is updated to the S-CSCF allocated by the PUI, the S-CSCF needs to save in the subsequent step. Number related to UE, P-CSCF According to. The HSS confirms that the SAR command sent by the S-CSCF is used in the fault recovery scenario, so in the response message SAA (Server- Assignment- Answer), the registration status of the PUI and the corresponding user are carried. Business configuration data, etc. Afterwards, the HSS carries the necessary data in the SAA and sends a response to the S-CSCF;

S606. The S-CSCF determines the registration status of the user PUI returned by the HSS. If the registration status of the PUI is already registered, the S-CSCF continues the processing of the call service flow using the acquired data. In this step, the S-CSCF may choose to save or not save the UE, P-CSCF related data described in the previous step. So far, since the S-CSCF utilizes the data acquired in the INVITE request sent from the P-CSCF and the data returned by the HSS, it constitutes the data necessary to support the UE call, so that the call flow can be continued.

The S-CSCF initiates a call service logic for the user. The command includes the media support capability of the UE; S607, the S-CSCF forwards the INVITE request to the called party network;

S608 - S610, the call request is transmitted to the called terminal of the called party network, and the two parties perform the steps of media negotiation, resource reservation, ringing of the called terminal, etc., after the called terminal picks up the call, the called terminal terminates the call to the endpoint. The party sends a SIP 200 ( OK ) final response;

S611 - S612, the UE responds with 200 ( O ) with a SIP ACK message. Corresponding to the embodiment of Fig. 6, when the P-CSCF is trusted for the S-CSCF, the P-CSCF does not send a call request from the unregistered UE. If the call request of the UE forwarded by the P-CSCF is untrustworthy to the S-CSCF, the S-CSCF needs to perform verification by the user registration status returned by the HSS. FIG. 7 shows another case, that is, when the state of the PUI corresponding to the UE stored in the HSS is not the registered state, in the present invention, how does the S-CSCF process the UE-initiated call service. As shown in Figure 7, it includes: ^ Processing:

S701. The UE initiates a SIP INVITE request to the P-CSCF, where the UE includes Media format for media capacity negotiation;

S702: After receiving the INVITE request, the P-CSCF forwards the INVITE request to the S-CSCF allocated to the UE.

5703, the S-CSCF checks the service attribute; the operation of the S-CSCF to check the service attribute includes: querying, in the local data, the registration status of the PUI corresponding to the UE, checking the user configuration data corresponding to the PUI, etc.; The user data stored locally by the S-CSCF does not exist. In order to continue processing subsequent requests, the BJS-CSCF needs to send a data acquisition request to the HSS to query the status and data of the user.

The information includes the contact address of the UE, the public user identifier PUI corresponding to the UE, the IP address of the P-CSCF, and the network ID of the P-CSCF. The S-CSCF saves the data locally and uses the data to send a data acquisition request to the HSS;

5704. The S-CSCF initiates a data acquisition request to the HSS by using the PUI corresponding to the user, and the HSS returns the user PUI registration status and user service configuration data. In this step, the S-CSCF requests the user data from the HSS through the SAR (Server-Assignment-Request) command, and carries the S-CSCF address and the public user identifier PUI of the UE in the command; The CSCF carries the fault recovery support label in the detailed information of the command, and tells the HSS that the request is due to the fault recovery scenario;

After the query request owed to the S-CSCF, the HSS obtains the registration status of the user PUI and the service configuration data of the user, and sends the data to the S-CSCF. In this step, the HSS checks the SAR command sent by the S-CSCF, and checks It carries the fault recovery support tag, which means that the S-CSCF wants to obtain the necessary data through the HSS to continue the service process. Since the PUI corresponding to the UE in this embodiment is not in the registered state, the HSS only extracts the registration status of the PUI and the service configuration data of the user, and returns the necessary data to the S-CSCF through the response message SAA;

5706, the S-CSCF determines the registration status of the user PUI returned by the HSS, and finds that the registration status of the PUI is not registered. The shell 'J S-CSCF does not save the user data, and the step of step S707 is continued;

5707, the S-CSCF sends a response to the P-CSCF requesting unreceivable; S708. The P-CSCF forwards the request unreceivable response to the UE. Example 2: AS instead of a user-initiated call In the case of an AS replacing a user-initiated call, the user may be in a registered state or a non-registered state. And if the S-CSCF saves the data locally, the saved data may include: a contact address of the application server, a PUI, a registration status of the PUI, and a service configuration data of the user. Figure 8 shows a flow chart of the AS initiating a call in place of the user after the S-CSCF assigned to the user PUI fails. In this process, the AS acts as the UE. A typical service in which a user initiates a call by an application server AS has a non-registered forwarding service service and an AS initiative notification service. S801, the application server acquires an S-CSCF address allocated for the public user identifier PUI, and the process is returned to the AS by the HSS through the interface Sh between the AS and the HSS;

5802, the application server sends a SIP INVITE request to the S-CSCF, and includes the media capabilities supported by the AS;

5803, the S-CSCF confirms that the received request is a request of the call originator, and first checks the service attribute; in this step, the S-CSCF regards the received request as a request that has been authenticated and authorized, that is, It is considered to be initiated from a trusted entity within the network; in addition, in this step, the S-CSCF needs to initiate a call service flow using the locally stored PUI-related service triggering rules, and since the S-CSCF is no longer available The public user identity related data, in order to continue processing subsequent requests, the S-CSCF needs to send a data acquisition request to the HSS to query the user's status and data. The S-CSCF first extracts information about the user and the AS from the INVITE request sent by the AS, including the AS's contact address, the public user ID, and the PUI. The S-CSCF temporarily stores the data locally and uses the data to send a data acquisition request to the HSS;

S804: The S-CSCF uses the public user identifier PUI to initiate a data acquisition request to the HSS, and the HSS is expected to return the registration status and service configuration data of the PUI. In this step, the S-CSCF passes the SAR (Server- Assignment-Request, monthly service). The allocation request) command requests the user data to the HSS, and carries the S-CSCF address and the public user identifier PUI in the command; and the S-CSCF carries the fault recovery support label in the detailed information of the command, and tells the HSS that the request is for the fault. Restore the scene;

5805. After receiving the query request of the S-CSCF, the HSS obtains the registration form of the user PUI. The service configuration data of the user and the user is sent to the S-CSCF. In this step, the HSS checks the SAR command sent by the S-CSCF and checks that it carries the fault recovery support label. It can be seen that the S-CSCF wants to obtain the necessary data through the HSS to continue the service flow; since the HSS confirms that the S-CSCF sends The SAR command is used for the fault recovery scenario. Therefore, in the response message SAA (Server- Assignment- Answer), the registered dog status of the PUI, the corresponding service configuration data, and the like are carried. Afterwards, the HSS carries the necessary data in the SAA and sends a response to the S-CSCF;

5806. The S-CSCF continues to process the call business process by using the acquired data. In this step, since the S-CSCF uses the data acquired in the INVITE request sent from the AS and the data returned by the HSS to form the data necessary to support the call, the call flow can be continued.

The S-CSCF initiates a call service logic for the user. Include the media support capabilities supported by the call originator in the command;

5807, the S-CSCF forwards the INVITE request to the called party network, and the called party network forwards the call to the called party terminal; S808 - S809, the call request is transmitted to the called terminal of the called party network, and the Chinese party passes the media Negotiation, resource reservation, ringing of the called terminal, etc., after the called terminal picks up the call, the called end endpoint sends a SIP 200 (OK) final response to the call originator;

S810 - S811, the call originator responds with 200 (OK) with a SIPACK message. Case 2: The core network element is the application server. In this case, in step S502, the AS uses the Sh interface between the AS and the HSS.

The HSS sends a request message and carries the user's PUI in the request message. The above request message may be a User-Data-Request (UDR) message.

If the data is saved locally, the saved data may include: a contact address of the UE, an address of the S-CSCF, a PUI, a registration status of the PUI, and a service configuration data of the user. FIG. 9 shows a process flow of how the AS effectively avoids an unacceptable error when the UE initiates a call after the UE successfully registers with the IMS network. As shown in Figure 9, the following processing can be included:

S901. The UE initiates a SIP INVITE request to the P-CSCF, where the UE is used to initialize the media. Media format for capacity negotiation;

S902: After receiving the INVITE request, the P-CSCF forwards the INVITE request to the S-CSCF allocated to the UE.

S903, after receiving the INVITE request, the S-CSCF forwards the INVITE request to the AS that provides the service according to the service configuration of the user;

5904. The AS checks the service attribute. The AS checks the service attribute. The operation includes: querying, in the local data, the registration status of the PUI corresponding to the UE, and checking the user configuration data corresponding to the PUI. In this case, the user data stored locally by the AS does not exist. In order to continue to process subsequent requests, the AS needs to send a data acquisition request to the HSS to query the status and data of the user. The S-CSCF first extracts information about the UE and the S-CSCF from the INVITE request sent by the S-CSCF, including the contact address of the UE, the public user identifier PUI corresponding to the UE, and the contact address of the S-CSCF. The AS temporarily stores the data locally and uses the data to send a data acquisition request to the HSS;

5905. The AS initiates a data acquisition request to the HSS by using the PUI corresponding to the user, and the HSS is expected to return the user PUI registration status and user service configuration data. In this step, the AS requests user data from the HSS through the UDR (User-Data-Request) command of the Sh interface, and carries the public user identifier PUI of the UE in the command, and the AS is in the detailed information in the command. Carrying the fault recovery support label, and telling the HSS that the request is for the fault recovery scenario; S906, after receiving the query request of the AS, the HSS obtains the registration status of the user PUI and the service configuration data of the user, and sends the data to the AS. In this step, the HSS checks the UDR command sent by the AS and checks that it carries the fault recovery support label. It can be seen that the AS wants to obtain the necessary data through the HSS to continue the service flow. The HSS confirms that the UDR command sent by the AS is used in the fault recovery scenario. Therefore, in the response message UDA (User-Data-Answer), the registration status of the PUI, the service configuration data of the corresponding user, and the like are carried. After that, the HSS carries the necessary data in the UDA and sends a response to the AS;

S907. The AS determines the registration status of the user PUI returned by the HSS. If the registration status of the PUI is already registered, the AS continues the processing of the call service flow by using the already acquired data. In this step, since the AS uses the INVITE request sent from the S-CSCF The data and the data returned by the HSS constitute the data necessary to support the UE call, so that the call flow can continue. In addition, in this step, the AS may choose to locally store user-related data, including the contact address of the UE, the service configuration data of the user, the S-CSCF address, and the like.

The AS initiates a call service logic for the user. Include the UE's media support capabilities in the command;

S908, the AS forwards the INVITE request to the called party network;

S909 - S911, the call request is transmitted to the called terminal of the called party network, and the silent party performs the steps of media negotiation, resource reservation, ringing of the called terminal, etc., after the called terminal picks up the call, the called terminal terminates the endpoint to The calling party sends a SIP 200 (OK) final response; S912 - S913, the UE responds with 200 (OK) with a SIP ACK message. As described above, according to the present invention, after the user data of the IMS system core network is lost, the method of querying the required user data to the HSS can effectively solve the defect that the service is unavailable due to the missing core network data. , to ensure the continuity of the service, enhance the fault handling ability of the core network element. The above description is only the preferred embodiment of the present invention, and is not intended to limit the present invention, and various modifications and changes can be made to the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the scope of the present invention are intended to be included within the scope of the present invention.

Claims

The present invention relates to a method for processing a core network element after restart/failure recovery, and is used for an IP multimedia subsystem, where the IP multimedia subsystem includes a user equipment, an application server, a service call control function entity, that is, an S-CSCF, and a proxy. The call session control function entity, that is, the P-CSCF and the home subscriber server, is characterized in that the method includes the following processing:  After receiving the call request of the user, the core network element checks the local data, and sends a one or Multiple request messages to request service related data of the user;  Responding to the request message of the core network element, the home subscriber server searches for the service related data and returns the core network element to the core network element;  The core network element uses the service related data obtained from the home subscriber server to perform a subsequent session processing procedure. The method according to claim 1, wherein the service related data comprises: service configuration data, wherein the core network element uses the service configuration data to trigger a service logic. The method according to claim 2, wherein the service related data further comprises: registration status information of the public user identifier, wherein the core network element uses the registration status information to enhance the judgment of the call validity. The method according to claim 1, wherein the request message sent by the core network element carries a fault recovery support tag. The method of any one of claims 1 to 4, wherein the core network element is an S-CSCF. The method according to claim 5, wherein the S-CSCF sends the request message to the home subscriber server using a Cx interface between the S-CSCF and the home subscriber server, and carries the request message in the request message. The S-CSCF name, the public user identifier of the user, where the request message is a monthly service allocation request message. The method according to claim 6, wherein, in response to the request message of the S-CSCF, the home subscriber server determines an S-CSCF name of an S-CSCF allocated by the public user identifier. Whether it is consistent with the S-CSCF name carried in the request message, and if the two are inconsistent, determining whether to update the S-CSCF allocated for the public user identity; updating the local user server to In the case of the S-CSCF to which the public user identity is assigned, the S-CSCF performs data saving locally. The method according to claim 5, wherein the call process is a call initiated by a user equipment, where the S-CSCF is allocated to the user in the following situation: the user successfully registers with the IP multimedia sub The system network; or the user subscribes to the unregistered service, and the S-CSCF allocation process is triggered by the unregistered service; the method further includes the following processing:  The S-CSCF saves the data locally, and the saved data includes: a contact address of the user equipment, an address of the P-CSCF, a network ID of the P-CSCF, a public user identifier, a registration status of the public user identifier, and a service configuration of the user. data. The method according to claim 5, wherein the calling process is an application server instead of a user-initiated call, wherein the user may be in a registered state or a non-registered state; the method further includes the following processing:  The S-CSCF saves the data locally, and the saved data includes: a contact address of the application server, a public user identifier, a registration status of the public user identifier, and a service configuration data of the user. The method according to any one of claims 1 to 4, wherein the core network element is an application server. The method according to claim 10, wherein the application server sends the request message to the home subscriber server by using a Sh interface between the application server and the home subscriber server, and in the request message The public user identifier of the user is carried in, where the request message is a user data request message. 12. The method according to claim 10, further comprising:  The application server saves the data locally, and the saved data includes: a contact address of the user equipment, an address of the S-CSCF, a public user identifier, a registration status of the public user identifier, and service configuration data of the user.