Rainy-day Scenarios – S-CSCF Restoration

I’ve just went through a couple of books about IMS. They mostly don’t mention restoration scenarios at all. But for engineers who really work with IMS the rainy-day scenarios are quite important. We have to know ‘what-if’. In this case what happens if the primary S-CSCF is either restarted or it is not available at all. The scenarios come into play quite often because some maintenance downtimes or even occasional failures are unavoidable. But still we should handle them without any real effect on the service. The 3GPP TS 23.380 document specifies a set of standardized procedures for automatic restoration after loss or corruption of data.

S-CSCF Restoration

Registration

Let’s start with the registration procedure. Firstly it can happen the S-CSCF, whose name is returned by HSS (or selected by I-CSCF), is not for some reason available. In that case the I-CSCF sends one more 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 forwards the REGISTER to the new S-CSCF.

 

S-CSCF Failure

 

Well, that was not a proper restoration scenario. So we should firstly go through the registration procedure and see what data and when we store to be able to later do the restoration. The SCSCF-Restoration-Info is stored in SAR message. The SCSCF-Restoration-Info header  has a following format:

SCSCF-Restoration-Info ::= < AVP Header: 639, 10415> 
      { User-Name } 
      1*{ Restoration-Info } 
      [ SIP-Authentication-Scheme ] 
      *[ AVP ] 

where

AVP format Restoration-Info ::= < AVP Header: 649, 10415> 
      { Path } 
      { Contact }
      [ Subscription-Info ]

This information – User Name, Authentication Scheme, Path and Contact headers plus the information about subscriptions for Event: Reg is stored in the HSS. Now we have the data in the HSS.

Registration – SCSCF -Restoration-Info

If user has more devices, it can happen that she is already registered with some other device. In the SAA the HSS shares all the registered Private User Identities (IMPIs) for the given Public User Identity (IMPU). Then the S-CSCF compares the registered IMPIs received from the HSS with the one which is registering. If data for some IMPIs is missing, the S-CSCF shall send another SAR with Server Assignment Type set to NO_ASSIGNMENT. Based on this message S-CSCF gets the restoration information from HSS. If the IMPU is shared by multiple IMPIs, the HSS includes all of the S-CSCF restoration information in the SAA. One group of S-CSCF restoration information then corresponds to one IMPI.

SCSCF Restoration – multiple IMPIs

Location Failure

Now when we need to restore the data? Maybe the S-CSCF handling a context for a particular subscriber is not available. Similarly to the situation we have seen above with the UAR/UAA message also the S-CSCF returned by the HSS during LIR/LIA can be unreachable. Honestly there is a very little difference between UAR/UAA and LIR/LIA. So also in this case, the I-CSCF sends one more LIR to the HSS to explicitly request S-CSCF capabilities. Based on the response than the I-CSCF performs re-selection to another S-CSCF. The new S-CSCF executes the S-CSCF Restoration procedure.

LIR/LIA – S-CSCF Restoration

From the flow above we can see that the in order to inform the HSS that we want to do the restoration we set the Server-Assignment-Type AVP to NO_ASSIGNMENT, which means:

NO_ASSIGNMENT – This value is used to request from HSS the user profile assigned to one or more public identities and to retrieve the S-CSCF restoration information for a registered Public User Identity, without affecting the registration state of those identities.

In the SAA the S-CSCF learns the restoration data along with the User-Data and Charging-Information. Mind that the information about what Application Server (TAS) is used as primary can be missing (see Third Party Registration post).

Terminating request coming to restarted S-CSCF

Similar situation is when S-CSCF is restarted or for any reason has a problem to get the subscriber data. 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. Also via the User-Data-Already-Available AVP the S-CSCF informs the HSS whether it has the part of the user profile that it needs to serve the user or not. The HSS sends the S-CSCF restoration information together with the user profile in the SAA. The result code (Experimental-Result AVP) is set to DIAMETER_ERROR_IN_ASSIGNMENT_TYPE. 

Restoration of S-CSCF after restart

Originating request coming to restarted S-CSCF

If a restarted S-CSCF receives an originating request (different from SIP REGISTER), then it sends SAR to the HSS with Server Assignment Type set to NO_ASSIGNMENT to restore the user data.

S-CSCF restoration – originating flow

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 doesn’t overwrite the S-CSCF name. Instead it sends a response with result code set to DIAMETER_UNABLE_TO_COMPLY. In this case also the S-CSCF returns a specific error response to the UE in order to trigger a new registration.

Otherwise the HSS responds with the SCSCF restoration information together with the user profile. Again, if there are more than one group of S-CSCF restoration information related to the IMPU, the HSS includes all of them in the SAA. 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 SCSCF restoration information includes the UE’s subscription information, the S-CSCF constructs a NOTIFY message to trigger a new registration at anytime after normal processing of the originating request.

 

S-CSCF not reachable

The easiest scenario. If the P-CSCF is unable to contact the S-CSCF in the Route, the P-CSCF returns a specific error response to the UE to trigger a new registration.

 

AS related flows

As we have seen either the S-CSCF can restarted or it might be not available for AS. In case when the S-CSCF is not reachable then after timeout, the application server resends the originating service request to the I-CSCF. Note, we talk about the originating service here  (i.e. top-most route header in request contains “orig” parameter – for example because of call diversion) as the terminating part has been more or less already covered.

 

AS – originating flow

If the S-CSCF was just restarted then it sends SAR to the HSS with Server Assignment Type set to UNREGISTERED_USER. The HSS responds with the  result code shall be set to DIAMETER_ERROR_IN_ASSIGNMENT_TYPE. The S-CSCF shall trigger matched originating services for the IMPU.

If the IMPU is stored as registered in the HSS, but there is no S-CSCF restoration information stored, the HSS sends the user profile in the SAA and sets the registration state for the IMPU to unregistered. The result code is set to DIAMETER_SUCCESS. Based on this the S-CSCF executes the originating unregistered services for the subscriber.

AS to restarted S-CSCF

Note that if the S-CSCF name sent in the SAR and the previously assigned S-CSCF name stored in the HSS are different, the HSS does not overwrite the S-CSCF name. Result Code will be DIAMETER_IDENTITY_ALREADY_REGISTERED. The S-CSCF should then return a specific error response to AS. The AS will resend the request to the I-CSCF.

The address of the S-CSCF can be obtained by AS either by querying the HSS on the Sh interface or during third-party registration. If AS is using third party registration and a reassignment occurred during a terminating request, then the AS will have the wrong S-CSCF name.