Pages

Join our LinkedIn group

Showing posts with label LTE Voice and SMS Issues. Show all posts
Showing posts with label LTE Voice and SMS Issues. Show all posts

Thursday, 30 October 2014

Codecs and Quality across VoLTE and OTT Networks

Codecs play an important role in our smartphones. Not only are they necessary and must for encoding/decoding the voice packets but they increase the price of our smartphones too.

A $400 smartphone can have as much as $120 in IPR fees. If you notice in the picture above its $10.60 for the H.264 codec. So its important that the new codecs that will come as part of new generation of mobile technology is free, open source or costs very little.


The new standards require a lot of codecs, some for backward compatibility but this can significantly increase the costs. Its important to make sure the new codecs selected are royalty-free or free license.

The focus of this post is a presentation by Amir Zmora from AudioCodecs in the LTE Voice Summit. The presentation below may not be self-explanatory but I have added couple of links at the bottom of the post where he has shared his thoughts. Its worth a read.



A good explanation of Voice enhancement tools as follows (slide 15):

Adaptive Jitter Buffer (AJB) – Almost all devices today (Smartphones, IP phones, gateways, etc.) have built in jitter buffers. Legacy networks (which were LAN focused when designed) usually have older devices with less sophisticated jitter buffers. When designed they didn’t take into account traffic coming in from networks such as Wi-Fi with its frequent retransmissions and 3G with its limited bandwidth, in which the jitter levels are higher than those in wireline networks. Jitter buffers that may have been planned for, say, dozens of msec may now have to deal with peaks of hundreds of msec. Generally, if the SBC has nothing to mediate (assume the codecs are the same and the Ptime is the same on both ends) it just forwards the packets. But the unexpected jitter coming from the wireless network as described above, requires the AJB to take action. And even if the network is well designed to handle jitter, today’s OTT applications via Smart Phones add yet another variable to the equation. There are hundreds of such devices out there, and the audio interfaces of these devices (especially those of the Android phones) create jitter that is passed into the network. For these situations, too, the AJB is necessary.

To overcome this issue, there is a need for a highly advanced Adaptive Jitter Buffer (AJB) built into the SBC that neutralizes the incoming jitter so that it is handled without problem on the other side. The AJB can handle high and variable jitter rates.

Additionally, the AJB needs to work in what is called Tandem scenarios where the incoming and outgoing codec is the same. This scenario requires an efficient solution that will minimize the added delay. AudioCodes has built and patented solutions supporting this scenario.

Transcoding – While the description above discussed the ability to bypass the need to perform transcoding in the Adaptive Jitter Buffer context, there may very well be a need for transcoding between the incoming and outgoing packet streams. Beyond being able to mediate between different codecs on the different networks on either end of the SBC, the SBC can transcode an incoming codec that is less resilient to packet loss (such as narrowband G.729 or wideband G.722) to a more resilient codec (such as Opus). By transcoding to a more resilient codec, the SBC can lower the effects of packet loss. Transcoding can also lower the bandwidth on the network. Additionally, the SBC can transcode from narrowband (8Khz) to wideband (16Khz) (and vice versa) as well as wideband transcoding, where both endpoints support wideband codecs but are not using the same ones. For example, a wireless network may be using the AMR wideband codec while the wireline network on the other side may be using Opus. Had it not been for the SBC, these two networks would have negotiated a common narrowband codec.

Flexible RTP Redundancy – The SBC can also use RTP redundancy in which voice packets are sent several times to ensure they are received. Redundancy is used to balance networks which are characterized by high packet loss burst. While reducing the effect of packet loss, Redundancy increases the bandwidth (and delay). There are ways to get around this bandwidth issue that are supported by the SBC. One way is by sending only partial packet information (not fully redundant packets). The decoder on the receiving side will know how to handle the partial information. This process is called Forward Error Correction (FEC).

Transrating – Transrating is the process of having more voice payload ‘packed’ into a single RTP packet by increasing the packet intervals, thus changing the Packetization Time or Ptime. Ptime is the time represented by the compression of the voice signals into packets, generally at 20 msec intervals. In combining the payloads of two or more packets into one, the Transrating process causes a reduction in the overhead of the IP headers, lowering the bandwidth and reducing the stress on the CPU resources, however, it increases delay. It thus can be used not only to mediate between two end devices using different Ptimes, but also as a means of balancing the network by reducing bandwidth and reducing CPU pressure during traffic peaks.

Quality-based Routing – Another tool used by the SBC is Quality-based routing. The SBC, which is monitoring all the calls on the network all the time, can decide (based on pre-defined thresholds and parameters) to reroute calls over different links that have better quality.

Further reading:


Friday, 27 June 2014

Voice over WiFi (VoWiFi)


One of the changes that I have noticed in the last year is that some of the operators who have been opposed to WiFi in the past have not only embraced it but are now trying to monopolise the same WiFi spectrum they billed as interference prone. Personally, I think the future of Wi-Fi is not just offloading but also working together with LTE. We are billing this as 4.5G and have recently produced a whitepaper, available here.

There has been a flurry of activity on Voice over Wi-Fi in the last few months. Recently the UK operators '3' and EE announced that they are both allowing WiFi calling and SMS. While '3' customers will have to use an OTT app for the time being, EE customers will experience this seamlessly.

I heard Taqua in the recent LTE World Summit talking about their solution and have offered to share their slides (embedded below). It was interesting to find out while having a discussion with them that their solution supports 'hand-in' and 'hand-out'. This takes away a major advantage that Small Cells offered, seamless roaming. Anyway, feel free to let me know of you have any opinion on this topic


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:



Saturday, 31 August 2013

VoLTE Bearers

While going through Anritsu whitepaper on VoLTE, I found this picture that explains the concepts of bearers in a VoLTE call well. From the whitepaper:

All networks and mobile devices are required to utilize a common access point name (APN) for VoLTE, namely, “IMS”. Unlike many legacy networks, LTE networks employ the “always-on” conception of packet connectivity: Devices have PDN connectivity virtually from the moment they perform their initial attach to the core network. During the initial attach procedure, some devices choose to name the access point through which they prefer to connect. However, mobile devices are not permitted to name the VoLTE APN during initial attach, i.e., to utilize the IMS as their main PDN, but rather to establish a connection with the IMS AP separately. Thus, VoLTE devices must support multiple simultaneous default EPS bearers.

Note that because the VoLTE APN is universal, mobile devices will always connect through the visited PLMN’s IMS PDN-GW. This architecture also implies the non-optionality of the P-CSCF:

As stated, VoLTE sessions employ two or three DRBs. This, in turn, implies the use of one default EPS bearer plus one or two dedicated EPS bearers. The default EPS bearer is always used for SIP signaling and exactly one dedicated EPS bearer is used for voice packets (regardless of the number of active voice media streams.) XCAP signaling may be transported on its own dedicated EPS bearer – for a total of three active EPS bearers – or it may be multiplexed with the SIP signaling on the default EPS bearer, in which case only two EPS bearers are utilized.

My understanding is that initially when the UE is switched on, a default bearer with QCI 9 (see old posts on QoS/QCI here) is established that would be used for all the signalling. Later on, another default bearer with QCI 5 is established with the IMS CN. When a VoLTE call is being setup, a dedicated bearer with QCI 1 is setup for the voice call. As the article says, another dedicated bearer may be needed for XCAP signalling. If a Video call on top of VoLTE is being used than an additional dedicated bearer with QCI 2 will be setup. Note that the voice pat will still be carried by dedicated bearer with QCI 1.

Do you disagree or have more insight, please feel free to add the comment at the end of the post.

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



Related posts:

Tuesday, 8 January 2013

VoLTE, Battery Issues and Solutions


Sometime back we had news about how VoLTE is battery killer and how it would suck our 4G phones dry. Well, I agree. I am no fan of VoLTE and think that CSFB solution can suffice in mid-term. Having said that, there is a solution which would be soon available to sort this battery issue during VoLTE call. I had a post on this topic earlier titled SPS and TTI Bundling. I am not sure about exactly how much saving would occur if either of the features are implemented.

ST Ericsson has recently released a whitepaper on this topic that is embedded below. If you have more idea on this, please add it in comments.



Wednesday, 7 November 2012

CSFB Performance

Here is another presentation from Qualcomm from the '4G World'.



With regards to SI Tunneling mentioned in the presentation, I found the following in another Qualcomm whitepapers:


With Release 9 Enhanced Release with Redirection—SI Tunneling, the device follows 3GPP release 9, where SIB information can be tunneled from the target Radio Access Network (RAN) via the core network to the source RAN and be included in the redirection message sent to the device. This can avoid reading any SIBs on the target cell. 

The predominant solutions deployed today are based on Release 8 Release with Redirection — SIB Skipping, in order to achieve good call setup times, good reliability, and simplify deployments. It is anticipated that Release 9 Enhanced Release with Redirection will be deployed in the near future. At this time, there is not as much push for handover-based CSFB since both Release 8 Release with Redirection—SIB Skipping and Release 9 Enhanced Release with Redirection—SI Tunneling have largely addressed any call setup time issues that may have existed with the Basic Release with Redirection solution.


I have blogged on this topic before, here.

More on Dual Radio here and SVLTE here.

Tuesday, 6 November 2012

17 LTE Voice Modes

No wonder why LTE chipsets are complicated.


From Qualcomm's presentation in 4G World, available here.

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.

Saturday, 19 May 2012

SPS and TTI Bundling Example

I have blogged about Semi-Persistent Scheduling (SPS) and Transmit Time Interval (TTI) Bundling feature before. They are both very important for VoIP and VoLTE to reduce the signalling overhead.



It should be noted that as per RRC Specs, SPS and TTI Bundling is mutually exclusive. The following from RRC specs:

TTI bundling can be enabled for FDD and for TDD only for configurations 0, 1 and 6. For TDD, E-UTRAN does not simultaneously enable TTI bundling and semi-persistent scheduling in this release of specification. Furthermore, E-UTRAN does not simultaneously configure TTI bundling and SCells with configured uplink.

Wednesday, 16 May 2012

Thursday, 23 February 2012

High level view on how SMS works in LTE


The following is from E\\\ whitepaper available here:


In 2010, 6.9 trillion text messages were sent globally and this figure is expected to break the eight trillion mark in 2011. This represents USD 127 billion in revenue for operators. LTE provides the same basic SMS features, such as concatenated SMS, delivery notification and configuration. However, the SMS delivery mechanism is somewhat different. A VoLTE device can send and receive text messages encapsulated within a SIP message. To receive a text message, the encapsulation process is invoked by an IP short-message-gateway in the IMS domain, and the gateway converts traditional Signaling System Number 7 (SS7) Mobile Application Part (MAP) signaling to IP/SIP.


To ensure that text messages are routed via the gateway, the home location register (HLR) of the recipient needs an additional function to return a routable gateway address back to the SMS-C on receipt of an SMS-routing request.


When a VoLTE device sends a text message, it should perform the encapsulation. The gateway extracts the text message inside a SIP MESSAGE signal before passing it on to the SMS-C.


However, if the VoLTE device is configured to not invoke SMS over IP networks, text messages can be sent and received over LTE without the need for any SIP encapsulation. A received text message will reach the mobile switching center server (MSC-S) of the mobile softswitch system in the same way as it does today. The MSC-S will page the device via the SGs interface with the Mobile Management Entity (MME) of the EPC system. Once a paging response is received, the MSC-S will pass the SMS on to the MME, which in turn tunnels it onto the device. Due to the support for SMS delivery and IP connectivity provided by LTE/EPC, MMS works seamlessly.


For more technically minded people, there is a whitepaper that covers SMS in detail available here.

Wednesday, 30 November 2011

Reducing CSFB Timing with RRC R9 Optimisations

While in the initial testing CSFB timing used to be between 6-8 seconds, most Rel-8 phones can complete the CSFB procedure between 4-4.5 seconds. Unfortunately this is still a lot in terms of signalling. To reduce this in Rel-9 there is a simple optimisation that has been done.
In the RRC Connection Release message, there is a possibility to add UTRAN/GERAN System Information messages. In the picture above, I have only shown UTRA System Information but a similar picture can be drawn for GERAN.

Once all the Mandatory SIB's are sent to the UE then it can immediately camp on without the need to read any other additional system info. This will reduce the CSFB time between 1-2 seconds.

The lesser the CSFB time, the better the Quality of end user experience

Tuesday, 18 October 2011

HD Voice - Next step in the evolution of voice communication

Nearly 2 years back I blogged about Orange launching HD Voice via the use of AMR-WB (wideband) codecs. HD voice is already fully developed and standardized technology and has so far been deployed on 32 networks in almost as many countries.

People who have experienced HD voice say it feels like they are talking to a person in the same room. Operators derive 70 percent of their revenue from voice and voice-related services, and studies show that subscribers appreciate the personal nature of voice communication, saying it offers a familiar and emotional connection to another person.

HD voice is also a reaction to the competition faced by the operators from OTT players like Skype.

Below is an embed from the recent whitepaper by Ericsson:



For more information also see:



Wednesday, 5 October 2011

Simultaneous Voice and LTE (SVLTE)


When LTE is an overlay to a CDMA/EV-DO network, the current de facto standard for voice delivery is Simultaneous Voice and LTE (SVLTE). In this arrangement, voice service is deployed as a 1x service running in parallel with LTE data services. For this solution to work, the handset needs to have two radios that are on simultaneously. The problem that is obvious is that the power consumption would generally be higher as two radios are on when the voice call is ongoing. The advantage (and I think its a big advantage) is that the data speeds are not affected by ongoing voice call and at the same time the state machine is simple.

For some reason this idea is not very popular for the 2G/3G evolution to LTE as the reliance will be on the CS Fallback. I had discussed this idea in the LTE World Summit and had blogged about it, you can read more details and comments here.

There is also a recent whitepaper from Huawei that covers these issues going towards VoLTE. Its available here.

Edit 06/10/11: Changed the acronym of SVLTE from 'Simultaneous Voice Over LTE' to 'Simultaneous Voice and LTE' as this is correct and referred to elsewhere.

Friday, 27 May 2011

Dual Radio Solution for Voice in LTE

I did mention in the Twitter conversations post from LTE World Summit 2011 that there are now certain analysts and players in the market who think that it should be possible to have two radios. Here is a slide from ZTE that shows that they are thinking in this direction as well.


Click on the pic to enlarge.

Tri-SIM phones have been available for quite a while but now there are Quad-Sim Shanzhai phones that are available in China. I am sure there is a market for these kind of phones.

With the battery life and the mobile technology improving, these are no longer the concerns when talking about dual radio possibility in the devices. Another common argument is that there may be additional interference due to multiple radios simultaneously receiving/transmitting. I am sure these can be managed without much problem.

Another problem mentioned is we may need multiple SIM cards but the SIM cards used is actually a UICC. There can be multiple SIM applications and IMSI's on it. The network may need some very minor modifications but they should be able to manage this with no problems. In the good old days, we used to have mobiles with built in Fax. The mobile number used to be different from the Fax number. It was a similar kind of problem but managed without problem.

So there may still be time to keep LTE simple by standardising the dual-radio solution rather than having CSFB, VoLTE, SRVCC, VoLGA, etc.

Any thoughts?

Monday, 25 April 2011

Advanced Telephony Services for LTE

With LTE World Summit just round the corner, I was going through the last year's presentations and realised that we didn't talk of this one before.

The concept for the advanced telephony services has been around since the early days of IMS and this was one of the ways IMS was sold. Unfortunately IMS didn't take off as planned and only now with the standardisation of VoLTE, there is a possibility of the advanced services becoming a reality.

The following presentation summarises some of these advanced telephony services concepts.