Content for TS 23.380 Word version: 17.1.0
6 Recovery after SCC AS failure
6.1 General
6.2 General Procedure
6.2.1 Enhanced Third Party Registration Procedure
6.2.2 Enhanced Service Request Procedure
$ Change history
6 Recovery after SCC AS failure |R13| p. 53
6.1 General p. 53
The following clauses show the requirements and information flows of IMS Restoration Procedures for the SCC-AS service interruption in each of the scenarios where they apply.
It is an optional feature to support SCC-AS restoration. If SCC-AS restoration is supported, it is required to support enhanced third part registration procedure described in 6.2.1 and enhanced service request procedure described in 6.2.2 together.
6.2 General Procedure p. 53
During the 3rd party registration, the SCC-AS should store extra SRVCC related information, i.e, ATCF-Path-URI, ATCF-Management-URI and g.3gpp.accesstype media feature tag if received as specified in clause 6.3.2 of TS 24.237, in the HSS as Repository Data.
When a service request is received when assigned SCC-AS is down, the S-CSCF should forward the service request to a working SCC-AS and this SCC-AS should:
- download corresponding ATCF related information previously stored in the HSS and it should notify the ATCF with its own ATU-STI for SRVCC; and
- download corresponding g.3gpp.accesstype media feature tag (if exist) previously stored in the HSS and determine that PS to CS SRVCC is usable for UE as specified in clause 6.3.2 of TS 24.237.
6.2.1 Enhanced Third Party Registration Procedure p. 53
6.2.1.1 Introduction p. 53
The restoration described in the clause 6.2.1 is an optional mechanism which applies for third party registration. The SCC-AS are optionally enhanced to store ATCF related information and g.3gpp.accesstype media feature tag (if received) in the HSS as Repository Data.
6.2.1.2 Description p. 53
Enhanced third party registration procedure is described in Figure 6.2.1.2-1.
Step 21.
For the first time the SCC-AS receives a third party registration of a served user, the SCC-AS shall store the ATCF-Path-URI, ATCF-Management-URI parameters and g.3gpp.accesstype media feature tag (if received) contained in the SIP REGISTER request as new Repository Data in the HSS. For the subsequent third party registration of that served user, the SCC-AS shall update the ATCF-Path-URI, the ATCF-Management-URI and the g.3gpp.accesstype media feature tag stored in the HSS as Repository Data with the new received value.
The SCC-AS may as well store this data locally, and then for the subsequent third party registration of that served user, if the ATCF-Path-URI, the ATCF-Management-URI and/or the g.3gpp.accesstype media feature tag (if received) contained in the SIP REGISTER request is different from previously stored one, the SCC-AS shall update the locally stored ATCF-Path-URI, the ATCF-Management-URI or the g.3gpp.accesstype media feature tag as well as that stored in the HSS as Repository Data with the new received value.
Step 22.
HSS updates data and responds back.
Step 23 ~ 24.
HSS sends the received STN-SR and C-MSISDN to update MME/SGSN as normal.
6.2.2 Enhanced Service Request Procedure p. 54
6.2.2.1 Introduction p. 54
The restoration described in the clause 6.2.2 is an optional mechanism which applies for service request. And SCC-AS is optionally enhanced to download SRVCC related information as Repository Data from the HSS and notify the ATCF with new ATU-STI.
Enhanced Service Request Procedure is based on enhanced third part registration procedure in 6.2.1.
6.2.2.2 Description p. 55
Enhanced service request procedure is described in Figure 6.2.2.2-1.
Step 1.
The S-CSCF receives session service request message and it attempts to route the message towards the registered SCC-AS, that in the Figure 6.2.2.2-1 is "SCC-AS1".
Step 2.
The S-CSCF detects the failure of SCC-AS1.
Step 3.
S-CSCF re-selects a new available SCC-AS, i.e. "SCC-AS2" e.g. by a DNS procedure or by configuration in the matched Filter Criteria of an alternative SCC-AS to provide services to the user.
Step 4.
The S-CSCF sends the message to the selected SCC-AS2.
Step 5.
After receiving the service request message, if no subscriber data is found, SCC-AS2 starts implicit registration procedure as normal (not displayed in Figure 6.2.2.2-1). After retrieving required subscriber data from the HSS, the SCC-AS2 shall request the ATCF related information and the g.3gpp.accesstype media feature tag stored as Repository Data (if present).
Step 6.
If ATCF related Repository Data is stored in the HSS, it is received back by the SCC-AS2.
Step 7.
If ATCF related Repository Data is received by the SCC-AS2, it shall send a MESSAGE with its own ATU-STI towards the ATCF that is identified by received ATCF-Management-URI. If the g.3gpp.accesstype media feature tag is present, the SCC-AS2 shall determine that PS to CS SRVCC is usable for UE as specified in clause 6.3.2 of TS 24.237.
Step 8.
The SCC-AS2 continues the session as normal.
$ Change history p. 55
