Showing posts with label IMS. Show all posts
Showing posts with label IMS. Show all posts

Monday, 9 May 2022

Transitioning from eCall to NG-eCall and the Legacy Problem

eCall (an abbreviation of "emergency call") is an initiative by the European Union, intended to bring rapid assistance to motorists involved in a collision anywhere within the European Union. The aim is for all new cars to incorporate a system that automatically contacts the emergency services in the event of a serious accident, sending location and sensor information. eCall was made mandatory in all new cars sold within the European Union as of April 2018.

In UK, the National Highways have a fantastic summary of the eCall feature here. The following video explains how this feature works:

Last year, ETSI hosted the Next Generation (NG) eCall webinar and Plugtests. The presentations from the event are available here. The presentations from GSMA, Qualcomm and Iskratel have a fantastic summary of many of the issues and challenges  with eCall and transitioning to NG eCall.

From the Qualcomm presentation:

The eCall standardisation began in 2004 when 2G networks were prevalent and 3G was being deployed. The chosen solution was in-band modem and Circuit Switched (CS) 112 call. The in-band modem was optimised for GSM (2G) and UMTS (3G) as the standard completed in 2008.

eCall for 4G (NG eCall) standardisation was started in 2013 and completed in 2017. As there is no CS domain in 4G/5G, IMS emergency calling will replace circuit switched emergency call. Next generation (NG) eCall provides an extension to IMS emergency calls and support for 5G (NR) has since been added.

The picture above from GSMA presentation highlights the magnitude of the problem if NG eCall deployment is delayed. GSMA is keen for the mobile operators to switch off their 2G/3G networks and only keep 4G/5G. There are problems with this approach as many users and services may be left without connectivity. Fortunately the European operators and countries are leaving at least one previous generation of technology operational for the foreseeable future.

GSMA's presentation recommends the following:

  • New technology neutral eCall Regulation (type approval and related acts) to be amended, adopted by European Commission and enter into force by end 2022 the latest.
  • OEMs to start installing NG eCall /remotely programable/exchangeable modules by end 2022; by end 2024 all new vehicles sold in the market should be NG eCall only
  • New vehicle categories to start with NG eCall only by 2024
  • MNOs have initiated to phase out 2G/3G between 2020 and 2025 , whereas the optimal transition path of their choice beyond this date will depend on market and technology specifics, and may require alignment with NRAs.
  • By 2022 , the industry will develop solutions for the transition period that need to be implemented country by country, which will also assess the amount of needed public funding to be economically feasible.
  • Retrofitting to be acknowledged, completed and formalised as a process by end 2024; standards should already be available in 2022.
  • Aftermarket eCall solution to be completed (including testing) and formalised by end 2024; standards should already be available in 2022.
  • The European Commission to make available public funding to support OEMs and alternative solutions to legacy networks starting from 2022 , under the RRF/ recovery package (or other relevant instruments)
  • Legacy networks availability until 2030 at the latest. By then deployment of all alternative solutions simultaneously would have ensured that the remaining legacy fleet will continue to have access to emergency services through NG eCall.

EENA, the European Emergency Number Association, is a non-governmental organisation whose mission is to contribute to improving people’s safety & security. One of the sessions at the EENA 2021 Conference was on eCall. The video from that is embedded below and all information including agenda and presentations are available here.

Related Posts:

Thursday, 24 February 2022

IP Multimedia Subsystem (IMS) Support for Service Based Architecture (SBA)

I looked at IMS briefly in my LTE voice tutorial here. The Nokia Lectures covered IMS in-depth in part 5 of the video. I recently came across a short overview of IMS for SBA. You can see our old tutorial on Service Based Architecture (SBA) for 5G Core (5GC) here.

I came across this short video from Mpirical that nicely explains the IMS support for SBA. It's embedded below. The related posts at the bottom may also be worth checking out.

Related Posts:

Monday, 7 December 2020

Nokia Lectures in Collaboration with Bangalore University

Nokia recently delivered some lectures virtually to Bangalore University students. The talks covered a variety of talks from LTE to 5G, Security & IMS. The playlist from Nokia is embedded below. The video contains following topics:

Part 1: 5G - General Introduction and IoT Specific Features
Part 2: 5G Overview
Part 3: Network Security Practices and Principles
Part 4: LTE Network Architecture - Interface and Protocols
Part 5: IMS - IP Multimedia Subsystem

Related Posts:

Wednesday, 20 September 2017

A quick starter on 4G voice (for beginners)


I recently did a 4G voice presentation for beginners after realizing that even though so many years have passed after VoLTE was launched, people are still unsure how it works or how its different from CS Fallback.

There are many other posts that discuss these topics in detail on this blog (follow the label) or on 3G4G website. Anyway, here is the video:


The slides are available on 3G4G Slideshare account here. More similar training videos are available here.

Wednesday, 7 January 2015

Enhancing voice services using VoLTE


VoLTE has been a very popular topic on this blog. My overview of the LTE Voice Summit missed out narrowly from the Top 10 posts of 2014 but there were other posts related to VoLTE that made it.

In this magazine article, NTT Docomo not only talks about its own architecture and transition from 3G to 4G for voice and video, it provides some detailed insights from its own experience.

There is also discussion into technical details of the feature and examples of signalling for VoLTE registration and originating/terminating calls (control, session and user plane establishment), SMS, SRVCC, Video over LTE (ViLTE) and voice to video call switching.

The paper is embedded below and available from slideshare to download.



Related links:

Saturday, 1 November 2014

4G Security and EPC Threats for LTE

This one is from the LTE World Summit 2014. Even though I was not there for this, I think this has some useful information about the 4G/LTE Security. Presentation as follows:


Monday, 5 May 2014

WebRTC (Web Real-Time Communication) Updates

Its been a while since I last blogged about WebRTC. Things have been progressing as rather fast pace in this area.



WebRTC capabilities have quietly sneaked in our browsers. There is a debate about who would move to WebRTC before, Apple or Microssoft; Tsahi Levent-Levi makes his predictions here.



As per Light Reading, Japanese operator NTT has opened a WebRTC based chatroom recently.



The Korean operator SK Telecom as been showing off its WebRTC interworking with IMS platform.



The problem with WebRTC can be as seen in the slide above. Classic problem of what was promised and whats the reality.

There are 2 interesting presentations that I am embedding below that I found useful:






Additional Reading:


Thursday, 13 February 2014

VoLTE Roaming with RAVEL (Roaming Architecture for Voice over IMS with Local Breakout)


Voice over LTE or VoLTE has many problems to solve. One of the issues that did not have a clear solution initially was Roaming. iBasis has a whitepaper on this topic here, from which the above picture is taken. The following is what is said above:

The routing of international calls has always been a problem for mobile operators. All too often the answer—particularly in the case of ‘tromboning’ calls all the way back to the home network—has been inelegant and costly. LTE data sessions can be broken out locally, negating the need for convoluted routing solutions. But in a VoIMS environment all of the intelligence that decides how to route the call resides in the home network, meaning that the call still has to be routed back.

The industry’s solution to this issue is Roaming Architecture for Voice over LTE with Local Breakout (RAVEL). Currently in the midst of standardisation at 3GPP, RAVEL is intended to enable the home network to decide, where appropriate, for the VoIMS call to be broken out locally. 

Three quarters of respondents to the survey said they support an industry-wide move to RAVEL for VoLTE roaming. This is emphatic in its enthusiasm but 25 per cent remains a significant share of respondents still to be convinced. Just over half of respondents said they plan to support VoIMS for LTE roaming using the RAVEL architecture, while 12.3 per cent said they would support it, but not using RAVEL.

Until RAVEL is available, 27.4 per cent of respondents said they plan to use home-routing for all VoLTE traffic, while just under one fifth said they would use a non-standard VoLTE roaming solution.

Well, the solution was standardised in 3GPP Release-11. NTT Docomo has an excellent whitepaper (embedded below) explaining the issue and the proposed solution.

In 3GPP Release 11, the VoLTE roaming and interconnection architecture was standardized in cooperation with the GSMA Association. The new architecture is able to implement voice call charging in the same way as circuit-switched voice roaming and interconnection models by routing both C-Plane messages and voice data on the same path. This was not possible with the earlier VoLTE roaming and interconnection architecture.

Anyway, here is the complete whitepaper




Monday, 20 January 2014

Different flavours of SRVCC (Single Radio Voice Call Continuity)



Single Radio Voice Call Continuity (SRVCC) has been quietly evolving with the different 3GPP releases. Here is a quick summary of these different flavors

In its simplest form, SRVCC comes into picture when an IMS based VoLTE call is handed over to the existing 2G/3G network as a normal CS call. SRVCC is particularly important when LTE is rolled out in small islands and the operator decided to provide VoLTE based call when in LTE. An alternative (used widely in practice) is to use CS Fallback (CSFB) as the voice option until LTE is rolled out in a wider area. The main problem with CSFB is that the data rates would drop to the 2G/3G rates when the UE falls back to the 2G/3G network during the voice call.



The book "LTE-Advanced: A Practical Systems Approach to Understanding 3GPP LTE Releases 10 and 11 Radio Access Technologies" by Sassan Ahmadi has some detailed information on SRVCC, the following is an edited version from the book:

SRVCC is built on the IMS centralized services (ICS) framework for delivering voice and messaging services to the users regardless of the type of network to which they are attached, and for maintaining service continuity for moving terminals.

To support GSM and UMTS, some modifications in the MSC server are required. When the E-UTRAN selects a target cell for SRVCC handover, it needs to indicate to the MME that this handover procedure requires SRVCC. Upon receiving the handover request, the MME triggers the SRVCC procedure with the MSC server. The MSC then initiates the session transfer procedure to IMS and coordinates it with the circuit-switched handover procedure to the target cell.

Handling of any non-voice packet-switched bearer is by the packet-switched bearer splitting function in the MME. The handover of non-voice packet-switched bearers, if performed, is according to a regular inter-RAT packet-switched handover procedure.

When SRVCC is enacted, the downlink flow of voice packets is switched toward the target circuit-switched network. The call is moved from the packet-switched to the circuit-switched domain, and the UE switches from VoIP to circuit-switched voice.

3GPP Rel-10 architecture has been recommended by GSMA for SRVCC because it reduces both voice interruption time during handover and the dropped call rate compared to earlier configurations. The network controls and moves the UE from E-UTRAN to UTRAN/GERAN as the user moves out of the LTE network coverage area. The SRVCC handover mechanism is entirely network-controlled and calls remain under the control of the IMS core network, which maintains access to subscribed services implemented in the IMS service engine throughout the handover process. 3GPP Rel-10 configuration includes all components needed to manage the time-critical signaling between the user’s device and the network, and between network elements within the serving network, including visited networks during roaming. As a result, signaling follows the shortest possible path and is as robust as possible, minimizing voice interruption time caused by switching from the packet-switched core network to the circuit-switched core network, whether the UE is in its home network or roaming. With the industry aligned around the 3GPP standard and GSMA recommendations, SRVCC-enabled user devices and networks will be interoperable, ensuring that solutions work in many scenarios of interest.

Along with the introduction of the LTE radio access network, 3GPP also standardized SRVCC in Rel-8 specifications to provide seamless service continuity when a UE performs a handover from the E-UTRAN to UTRAN/GERAN. With SRVCC, calls are anchored in the IMS network while the UE is capable of transmitting/ receiving on only one of those access networks at a given time, where a call anchored in the IMS core can continue in UMTS/GSM networks and outside of the LTE coverage area. Since its introduction in Rel-8, the SRVCC has evolved with each new release, a brief summary of SRVCC capability and enhancements are noted below

3GPP Rel-8: Introduces SRVCC for voice calls that are anchored in the IMS core network from E-UTRAN to CDMA2000 and from E-UTRAN/UTRAN (HSPA) to UTRAN/GERAN circuit-switched. To support this functionality, 3GPP introduced new protocol interface and procedures between MME and MSC for SRVCC from E-UTRAN to UTRAN/GERAN, between SGSN and MSC for SRVCC from UTRAN (HSPA) to UTRAN/GERAN, and between the MME and a 3GPP2-defined interworking function for SRVCC from E-UTRAN to CDMA 2000.

3GPP Rel-9: Introduces the SRVCC support for emergency calls that are anchored in the IMS core network. IMS emergency calls, placed via LTE access, need to continue when SRVCC handover occurs from the LTE network to GSM/UMTS/CDMA2000 networks. This evolution resolves a key regulatory exception. This enhancement supports IMS emergency call continuity from E-UTRAN to CDMA2000 and from E-UTRAN/UTRAN (HSPA) to UTRAN/ GERAN circuit-switched network. Functional and interface evolution of EPS entities were needed to support IMS emergency calls with SRVCC.

3GPP Rel-10: Introduces procedures of enhanced SRVCC including support of mid-call feature during SRVCC handover (eSRVCC); support of SRVCC packet-switched to circuit-switched transfer of a call in alerting phase (aSRVCC); MSC server-assisted mid-call feature enables packet-switched/ circuit-switched access transfer for the UEs not using IMS centralized service capabilities, while preserving the provision of mid-call services (inactive sessions or sessions using the conference service). The SRVCC in alerting phase feature adds the ability to perform access transfer of media of an instant message session in packet-switched to circuit-switched direction in alerting phase for access transfers.

3GPP Rel-11: Introduces two new capabilities: single radio video call continuity for 3G-circuit-switched network (vSRVCC); and SRVCC from UTRAN/GERAN to E-UTRAN/HSPA (rSRVCC). The vSRVCC feature provides support of video call handover from E-UTRAN to UTRAN-circuitswitched network for service continuity when the video call is anchored in IMS and the UE is capable of transmitting/receiving on only one of those access networks at a given time. Service continuity from UTRAN/GERAN circuitswitched access to E-UTRAN/HSPA was not specified in 3GPP Rel-8/9/10. To overcome this drawback, 3GPP Rel-11 provided support of voice call continuity from UTRAN/GERAN to E-UTRAN/HSPA. To enable video call transfer from E-UTRAN to UTRAN-circuit-switched network, IMS/EPC is evolved to pass relevant information to the EPC side and S5/S11/Sv/Gx/Gxx interfaces are enhanced for video bearer-related information transfer. To support SRVCC from GERAN to E-UTRAN/HSPA, GERAN specifications are evolved to enable a mobile station and base station sub-system to support seamless service continuity when a mobile station hands over from GERAN circuit-switched access to EUTRAN/ HSPA for a voice call. To support SRVCC from UTRAN to EUTRAN/ HSPA, UTRAN specifications are evolved to enable the RNC to perform rSRVCC handover and to provide relative UE capability information to the RNC.

NTT Docomo has a presentation on SRVCC and eSRVCC which is embedded below:



Thursday, 16 January 2014

3GPP Rel-12 and Future Security Work


Here is the 3GPP presentation from the 9th ETSI Security workshop. Quite a few bits on IMS and IMS Services and also good to see new Authentication algorithm TUAK as an alternative to the widely used Milenage algorithm.



Sunday, 5 May 2013

Thursday, 14 March 2013

What is WebRTC and where does it fit with LTE and IMS

This simple video from MWC should give an idea on what WebRTC is and can do:


So what exactly WebRTC is in technical terms. Here is a recent presentation from WebRTC Conference and Expo



And here is another presentation that explains where it fits in with the LTE Architecture.



Dean Bubley from Disruptive Analysis has writted extensively on this topic and his recent post "Is the telephony "threat" from VoIP & WebRTC about competition or contextualisation?" is an interesting read.

Iain Sharp from Netovate recently pointed out that 3GPP have 'nearly' approved a work item for WebRTC access to IMS.

It would be interesting to see how operators will view WebRTC. As an opportunity or as a threat. Please feel free to air your opinions via comments.

Thursday, 20 December 2012

IMS Whitepapers from Spirent



Couple of old but interesting whitepapers from Spirent available, in case you are interesting in IMS. Available to download from here (registration required)

Related blog posts:



Sunday, 26 August 2012

Voice-Over-LTE (VoLTE) Signalling

MetroPCS has recently launched rolled out VoLTE in USA using LG connect phones. More operators would be rolling it out soon so here is example of Signaling in VoLTE.




To read in detail, please see the article from NTT Docomo technical journal here.

Thursday, 22 March 2012

UICC and ISIM (IMS SIM)



I have mentioned before that UICC is the physical card and 2G SIM/USIM/ISIM are applications on the UICC card. The IMS SIM holds data provided by the IMS Operator, generally the same operator that would provide USIM services that would allow to camp on the 3G or LTE network.

Private User Identity: This identifies the user uniquely with the IMS operator and is used when the user registers with the IMS network. This is used by the operator to check the subscription and which services the user can avail of.

Public User Identity: A user can have multiple public identities that can be used for different services. To avail a particular service, user has to register with the particular public identity that has been allowed for that service.

Security Keys: Security keys are used for authentication to the IMS Network.

Home Network Domain Name: This is the name of the entry point that the user uses to register. This makes sure that a users request is sent to the Home Network.

Access Rule Reference: This is used to store information about which personal identification number needs verification for accessing a particular application

Address of P-CSCF: If it is not possible do dynamically find the Proxy-Call Session Control Function then this address is helpful

Administrative Data: Some of this could be operator specific proprietary information