The following clauses specify the behaviour of HSS and S-CSCF if they support the IMS restoration feature.

If the UE initiates a SIP REGISTER and the S-CSCF returned by the HSS during user registration status query procedure fails, the I-CSCF is unable to contact the S-CSCF. In this case, regardless of this registration is an initial registration, a re-registration or a de-registration, the I-CSCF shall send UAR with Authorization Type set to REGISTRATION_AND_CAPABILITIES to the HSS to explicitly request S-CSCF capabilities. After re-assignment of another S-CSCF according to the S-CSCF capabilities, the I-CSCF shall forward the REGISTER to the new S-CSCF. For registrations and re-registrations, S-CSCF shall proceed with the registration procedure as for initial registration, except for the clauses specified in clause 4.2.3. For de-registrations, S-CSCF shall proceed as for user-initiated de-registration.

If the I-CSCF is unable to contact the currently assigned S-CSCF, regardless of this registration is an initial registration, a re-registration or a de-registration, the I-CSCF shall reselect an S-CSCF and forward the REGISTER to the new S-CSCF. The I-CSCF shall include a reselection indication in the REGISTER request. The S-CSCF shall proceed with the registration procedure as for initial registration. Additionally, the S-CSCF shall include the reselection indication towards the HSS. When receiving the reselection indication, the HSS shall allow the new S-CSCF to overwrite the current S-CSCF.

During the registration procedure, the HSS shall send all the registered Private User Identities sharing the same Public User Identity which is being registered in the SAA, in addition to the basic user data to the S-CSCF. Subject to the operator policy, the HSS may include the S-CSCF restoration information for the registered Public User Identity in the response. Then the S-CSCF compares the registered Private User Identities received from the HSS with the ones it stores. If there are any registered Private User Identities the S-CSCF does not have their registration data, the S-CSCF shall send SAR with Server Assignment Type set to NO_ASSIGNMENT to the HSS to retrieve the S-CSCF restoration information for the registered Public User Identity. If there are S-CSCF restoration information related to the Public User Identity stored in the HSS, the HSS shall send the S-CSCF restoration information together with the user profile in the SAA to the S-CSCF. The result code shall be set to DIAMETER_SUCCESS. Subject to the operator policy, sending this SAR with Server Assignment Type set to NO_ASSIGNMENT may be skipped if the S-CSCF restoration information for the registered Public User Identity information was already received from the HSS. If there are more than one group of S-CSCF restoration information related to the Public User Identity stored in the HSS, which may happen if the Public User Identity is shared by multiple Private User Identities, the HSS shall include all of the S-CSCF restoration information in the SAA. One group of S-CSCF restoration information corresponds to one Private User Identity. If the S-CSCF receives an initial registration request for a Public User Identity that does not match any Public User Identity currently registered with the same Private User Identity as in the request at this S-CSCF, the S-CSCF shall check whether there is a reg-id parameter in the Contact header in the SIP REGISTER message and whether there is an "sos" SIP URI parameter in the SIP REGISTER message. Only when a reg-id parameter exists and an "sos" SIP URI parameter does not exist, the S-CSCF shall indicate to the HSS that the registration is related to a multiple registration. If the HSS receives an SAR request with multiple registration indication, and the Public User Identity is stored as registered in the HSS, and there is restoration information related to the Private User Identity, the HSS shall not overwrite stored restoration information, instead, it shall send the stored S-CSCF restoration information together with the user profile in the SAA. Subject to the operator policy, the HSS may include all the S-CSCF restoration information groups associated to the registered Public User Identity in the response. The result code shall be set to DIAMETER_ERROR_IN_ASSIGNMENT_TYPE. The S-CSCF shall send a new SAR with Server-Assignment-Type set to RE_REGISTRATION and the User Data Already Available parameter set to USER_DATA_ALREADY_AVAILABLE to update the restoration information in the HSS in accordance to the current registration event. If the S-CSCF receives a user-initiated deregistration request for a Public User Identity that does not match any Public User Identity currently registered with the same Private User Identity as in the request at this S-CSCF, the S-CSCF shall check whether there is a reg-id parameter in the Contact header in the received SIP REGISTER message,

• if a reg-id parameter exists, the S-CSCF shall:
  1. Send SAR with Server-Asignment-Type set to NO_ASSIGNMENT to retrieve the S-CSCF restoration information associated with the Public User Identity. The Result-Code shall be set to DIAMETER SUCCESS.
  2. Compare the contact address(es) received in SAA with the contact address(es) in REGISTER request:
     • If they are not the same, the S-CSCF shall send SAR with Server-Asignment-Type set to RE_REGISTRATION to update the S-CSCF restoration information in HSS with the Contact address(es) still associated with the Public User Identity after the deregistration event.
     Otherwise, the S-CSCF shall send SAR with Server-Asignment-Type set to USER_DEREGISTRATION.

The following clauses specify the behaviour of HSS, I-CSCF and S-CSCF if they support the IMS Restoration feature.

The S-CSCF lost all user data if it restarts after a failure or it is unable to trust any data after it resumes operation, due to the fact that it may have lost profile updates from the HSS in the service interruption period. If such a S-CSCF receives a terminating service request from the I-CSCF, it sends an SAR to the HSS for unregistered service data. In this case, HSS and S-CSCF proceed as indicated in TS 29.228, except that

• if the Public User Identity is stored as registered in the HSS, and there are S-CSCF restoration information related to the Public User Identity stored in the HSS, the HSS shall send the S-CSCF restoration information together with the user profile in the SAA. The result code shall be set to DIAMETER_ERROR_IN_ASSIGNMENT_TYPE. The S-CSCF shall trigger matched registered services for the Public User Identity.

If there are more than one group of S-CSCF restoration information related to the Public User Identity, which may happen if the Public User Identity is shared by multiple Private User Identities, the HSS shall include all of the S-CSCF restoration information in the SAA. One group of S-CSCF restoration information corresponds to one Private User Identity. If the S-CSCF restoration information received includes the UE's subscription information, the S-CSCF shall construct a NOTIFY message according to the information and send it to the UE (or UEs if the IMPU is shared between several IMPIs) to trigger a new registration at anytime after normal processing of the terminating request. If the S-CSCF restoration information received includes the P-CSCF's subscription information, the S-CSCF shall construct a NOTIFY message and send it to the P-CSCF to update the registration information at any time after normal processing of the terminating request. If the S-CSCF restoration information received includes the UE's registration expiration time and the value is in the past, the S-CSCF proceeds as indicated in clause 5.3.2.1 of TS 23.228.

If the S-CSCF returned by the HSS during location query procedure fails, the I-CSCF is unable to contact the S-CSCF during terminating procedure. In this case, the I-CSCF shall send LIR to the HSS to explicitly request S-CSCF capabilities. If the HSS returns the S-CSCF capabilities to the I-CSCF, after re-selection of another S-CSCF according to the S-CSCF capabilities, the I-CSCF shall forward the service request to the new S-CSCF. The HSS and this new S-CSCF shall behave as described in clause 4.3.2, except that the HSS shall overwrite the S-CSCF name when receiving the SAR request, only if there is a previous explicit LIR request for S-CSCF capabilities.

If the I-CSCF is unable to contact the S-CSCF during terminating procedure, the I-CSCF shall reselect an S-CSCF and forward the terminating request to the new S-CSCF. The I-CSCF shall include a reselection indication in the request. The S-CSCF shall proceed with the terminating request for an unregistered user. Additionally, the S-CSCF shall include the reselection indication towards the HSS. When receiving the reselection indication, the HSS shall allow the new S-CSCF to overwrite the current S-CSCF.

The following clauses specify the behaviour of HSS, S-CSCF and P-CSCF if they support the IMS Restoration feature.

The S-CSCF lost all user data if it restarts after a failure or it is unable to trust any data after it resumes operation, due to the fact that it may have lost profile updates from the HSS in the service interruption period. If such a S-CSCF receives an originating request different from SIP REGISTER coming from the UE, the S-CSCF shall send SAR to the HSS with Server Assignment Type set to NO_ASSIGNMENT to restore the user data. If the S-CSCF name sent in the Server-Assignment-Request command and the previously assigned S-CSCF name stored in the HSS are different, which may happen if S-CSCF reassignment occurred during a terminating restoration before, the HSS shall not overwrite the S-CSCF name; instead it shall send a response to the S-CSCF with result code set to DIAMETER_UNABLE_TO_COMPLY, as specified in the TS 29.228. If there are S-CSCF restoration information related to the Public User Identity stored in the HSS, the HSS shall send the S-CSCF restoration information together with the user profile in the SAA to the S-CSCF. If the HSS returns an error DIAMETER_UNABLE_TO_COMPLY to the S-CSCF, the S-CSCF shall then return a specific error response to the UE to trigger a new registration. If there are more than one group of S-CSCF restoration information related to the Public User Identity stored in the HSS, which may happen if the Public User Identity is shared by multiple Private User Identities, the HSS shall include all of the S-CSCF restoration information in the SAA. One group of S-CSCF restoration information corresponds to one Private User Identity. If authentication of SIP request methods initiated by the UE excluding REGISTER is desired according to operator's policy, for other authentication schemes different from IMS-AKA, the S-CSCF requires authentication information (e.g. authentication vectors). If this information is not stored in the S-CSCF, the S-CSCF shall fetch that information from the HSS by means of the authentication procedures (Cx-MAR/MAA). If the S-CSCF receives SAA with the service profile of the user, the S-CSCF shall continue the originating service as normal. If the S-CSCF receives SAA with S-CSCF restoration information and the S-CSCF restoration information includes the UE's subscription information, the S-CSCF shall construct a NOTIFY message according to the information and send it to the UE (or UEs if the IMPU is shared between several IMPIs) to trigger a new registration at anytime after normal processing of the originating request. If the S-CSCF restoration information received includes the P-CSCF's subscription information, the S-CSCF shall construct a NOTIFY message and send it to the P-CSCF to update the registration information at any time after normal processing of the originating request.

If the UE initiates an originating service request different from SIP REGISTER and the P-CSCF is unable to contact the S-CSCF in the Route, the P-CSCF shall return a specific error response to the UE to trigger a new registration.

The following clauses specify the behaviour of HSS, I-CSCF and S-CSCF if they support the IMS Restoration feature.

The S-CSCF lost all user data if it restarts after a failure or it is unable to trust any data after it resumes operation, due to the fact that it may have lost profile updates from the HSS in the service interruption period. If such S-CSCF receives an originating request on behalf of a user (i.e. top-most route header in request contains "orig" parameter) coming from an AS, the S-CSCF shall send SAR to the HSS with Server Assignment Type set to UNREGISTERED_USER to inform the HSS that the user is unregistered. HSS and S-CSCF proceed as indicated in TS 29.228, except that:

• if the Public User Identity is stored as registered in the HSS, and there is S-CSCF restoration information related to the Public User Identity stored in the HSS, the HSS shall send the S-CSCF restoration information together with the user profile in the SAA. The result code shall be set to DIAMETER_ERROR_IN_ASSIGNMENT_TYPE. The S-CSCF shall trigger matched originating services for the Public User Identity.if the Public User Identity is stored as registered in the HSS, and there is no S-CSCF restoration information related to the Public User Identity stored in the HSS, the HSS shall send the user profile in the SAA and set the registration state for the Public Identity to unregistered. The result code shall be set to DIAMETER_SUCCESS. The S-CSCF shall trigger matched originating unregistered services for the Public User Identity.
• if the S-CSCF name sent in the Server-Assignment-Request command and the previously assigned S-CSCF name stored in the HSS are different, the HSS shall not overwrite the S-CSCF name. Result Code will be DIAMETER_IDENTITY_ALREADY_REGISTERED. The S-CSCF shall return a specific error response to AS. The AS shall resend the request to the I-CSCF.

If the application server sends the originating service request on behalf of the user to the S-CSCF, and the S-CSCF can not be contacted, after timeout, the application server shall resend the originating service request to the I-CSCF. If the application server sends the originating service request directly to the I-CSCF, or resends the originating service request to the I-CSCF due to the S-CSCF can not be contacted, the I-CSCF shall behave as in clause 4.3.3. The S-CSCF and HSS shall behave as in clause 4.5.2, except that the HSS shall overwrite the S-CSCF name when receiving the SAR request, only if there is a previous explicit LIR request for S-CSCF capabilities.

The following clauses specify the behaviour of HSS and S-CSCF if they support the IMS Restoration feature.

The S-CSCF shall backup the following data in the HSS during the initial registration process.

• the list of SIP proxies in the path (normally it would be just the P-CSCF address)
• the Contact Information (Contact Addresses and Contact Header parameters)
• the Authentication Information (SIP-Authentication-Scheme)

The S-CSCF may backup the following data in the HSS during the initial registration process.

• the Initial-CSeq-Sequence-Number and the Call-ID used if used for temporary GRUU generation (see RFC 3261)
• The point in time of registration expiration

This is done with an additional information element in the SAR requesting user information, in addition to the basic set of information required to handle traffic, as specified in the TS 29.228. The information is associated with the Private User Identity and the Implicit Registration Set that is affected by the SAR request. The HSS shall store this information. If any of the above data is changed, the S-CSCF shall update it in the HSS using SAR request with Server-Assignment-Type set to RE_REGISTRATION and the User Data Already Available parameter set to USER_DATA_ALREADY_AVAILABLE, as specified in the TS 29.228. Note: Updating the point in time of registration expiration in the restoration information contributes to a better user experience at the cost of additional Cx traffic.

If the S-CSCF receives the UE's subscription to notification of the reg-event for the first time, the S-CSCF shall send an SAR to the HSS to store the following UE's subscription information.

• Call-ID, From, To, Record-Route, Contact

To avoid frequent storing of the subscription information in the HSS, the CSeq should not be included in the S-CSCF restoration information. Instead, the CSCF shall ensure that subsequent notification after retrieving this data includes a sufficiently large Cseq value so that the UE is able to accept it. This is done with Server Assignment Type set to RE_REGISTRATION and the User Data Already Available parameter set to USER_DATA_ALREADY_AVAILABLE in the SAR, as specified in the TS 29.228. The information is associated with the Private User Identity affected by the SAR request. The HSS shall store this information. If any of the above data is changed, the S-CSCF shall update it in the HSS using SAR request with Server-Assignment-Type set to RE_REGISTRATION and the User Data Already Available parameter set to USER_DATA_ALREADY_AVAILABLE, as specified in the TS 29.228. The S-CSCF shall send the registration data together with the subscription data as one S-CSCF restoration information. Each time the HSS receives the S-CSCF restoration information related to the same Private User Identity in the SAR with Server-Assignment-Type set to RE_REGISTRATION, the HSS shall overwrite the previous S-CSCF restoration information.

Backup and Update of S-CSCF Restoration Information after P-CSCF's Subscription is an optional S-CSCF capability. If supported, the following applies: If the S-CSCF receives the P-CSCF's subscription to notification of the reg-event for the first time, the S-CSCF shall send an SAR to the HSS to store the following P-CSCF's subscription information.

• Call-ID, From, To, Contact

To avoid frequent storing of the subscription information in the HSS, the CSeq should not be included in the S-CSCF restoration information. Instead, the CSCF shall ensure that subsequent notification after retrieving this data includes a sufficiently large Cseq value so that the P-CSCF is able to accept it. This is done with Server Assignment Type set to RE_REGISTRATION and the User Data Already Available parameter set to USER_DATA_ALREADY_AVAILABLE in the SAR, as specified in the TS 29.228. The information is associated with the Private User Identity affected by the SAR request. The HSS shall store this information. If any of the above data is changed, the S-CSCF shall update it in the HSS using SAR request with Server-Assignment-Type set to RE_REGISTRATION and the User Data Already Available parameter set to USER_DATA_ALREADY_AVAILABLE, as specified in the TS 29.228. The S-CSCF shall send the registration data together with the subscription data as one S-CSCF restoration information. Each time the HSS receives the S-CSCF restoration information related to the same Private User Identity in the SAR with Server-Assignment-Type set to RE_REGISTRATION, the HSS shall overwrite the previous S-CSCF restoration information.