There are two big enemies of mobile communication. Weak signal and battery drain. With the LTE technology in place we need to deal with the situation when our signal gets too weak. The higher frequencies have a problem to penetrate walls, currently the radio network is not covering whole country yet, etc.. these problems seems to be only temporary (as the LTE is moving forward) but at this point of time we can’t rely on the LTE network only. When we are out of 4G coverage while we are not calling we’ll simply fallback to CS network and VoLTE supports CS breakout or CS retry so our voice service is still working.
But what if it happens during an ongoing call ?
Can we handover and still maintain the session ?
It is possible but not easy as because of the battery drain we can access only one radio network at the time. What we are looking for is called Single Radio Voice Call Continuity (SRVCC). SRVCC is applied during PS to CS access transfer in a single radio system from LTE to 3G/2G.
SRVCC Scenarios and evolution
The main objective of SRVCC evolution is to imprve VOLTE user experience.
- SRVCC – Access transfer without media anchoring – no ATCF/ATGW, SCC AS addressed by STN-SR (R9)
- Emergency SRVCC – Support of access transfer for Emergency Calls (R9)
- eSRVCC – Enhanced SRVCC – Media anchoring (+ mid-call feature support) (R10)
- aSRVCC – Alerting SRVCC – Support of SRVCC PS-CS transfer of a call in alerting (ringing) phase (R10)
- vSRVCC – Video Call support (R11)
- rSRVCC – Reverse SRVCC – Support of access transfer from GSM/UTMS to LTE (R11)
- bSRVCC – Before ringing SRVCC – Support of SRVCC PS-CS transfer of a call in pre-alerting phase (R12)
==> In this post we will focus on eSRVCC
eSRVCC is introduced to shorten the speech gap caused by SRVCC handovers. Media information on the UE does not need to be updated.
eSRVCC call flow is probably one of the most complex flows you can encounter in VoLTE. To allow this functionality we need to add some more IMS elements in the network:
- Access Transfer Control Function (ATCF)
ATCF acts as SIP signalling anchor and is located in the SIP signalling path between P-SCSF and S-CSCF. Very often it is part of the SBC. ATCF controls the ATGW, where the media plane is anchored. During the session transfer, the ATCF establishes a new session with the SCC AS. This new session substitutes the old session between the ATCF and the SCC AS.
- Access Transfer Gateway (ATGW)
The ATGW anchors the media session.
- Service Centralization and Continuity Application Server (SCC AS)
The SCC AS anchors originated and terminated sessions when using the PS or CS access. It is also responsible for the Terminating Access Domain Selection (T-ADS).
IMS Architecture for eSRVCC
 |
| IMS Architecture for eSRVCC |
As the new elements ATCF and SCC are anchoring the session we have also to modify the basic VoLTE flows.
Firstly we need to modify the registration. We have to send the information about what ATCF is responsible for the user to enhanced MSC/MGCF. This information is called Session Transfer Number for SRVCC (STN-SR) and it is a TEL URI of ATCF.
Another important information which we need to exchange is the MSISDN which is being used by the user in the CS network. We call it Correlation MSISDN (C-MSISDN).
And last but not least ATCF has to be able to address the SCC AS. The address is referenced as Transfer Update – Session Transfer Identifier (ATU-STI) and it is a SIP URI of SCC AS.
The flows for eSRVCC in IMS are described in 3GPP 23.237 and ETSI TS 124 237.
eSRVCC Registration
 |
| eSRVCC Registration |
ATCF decides, based on the operator’s policy and if the home network supports eSRVCC with ATCF to alocate an STN-SR. The ATCF decides to include itself for sessions created using this registration and adds its record in the Path: ATCF URI for terminating requests followed by P-CSCF URI for terminating requests. ATCF URI for terminating requests uniquely identifies registration (or registration flow, if multiple registration mechanism is used).
Then the ATCF forwards the SIP REGISTER request to the I-CSCF.
SCC AS will receive the STN-SR (the TPR contains the original SIP REGISTER in the body) and will update the ePC HSS. Then it’ll send its own uri – ATU-STI along with the C-MSISDN to ATCF as an xml payload of a SIP MESSAGE.
eSRVCC Call Flow
When a weak signal is detected the MME sends a handover request to CS network. Part of the request is the STN-SR and C-MSISDN. MSC/MGCF will create a new SIP INVITE and will send it to STN-SR e.g.
INVITE tel:+21622126927 SIP/2.0
ATCF finds the existing dialog for C-MSISDN (P-Asserted-Identity) and decides whether to anchor the media in the ATGW. Then sends a new SIP INVITE to SCC AS with the Target-Dialog which is to be transferred.
If the call is anchored in the SBC (ATGW) then we don’t need to renegotiate the SDP again. The SBC will simply do the translation between the access leg (e.g. narrow band) and remote leg (e.g. wide band). In case that this is not possible the SCC AS will send SIP UPDATE with the new SDP. This is something we are trying to avoid as it noticeably increases the delay during the transfer.
Read also:
Subscribe by Email
Follow Updates Articles from This Blog via Email
No Comments