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

Wednesday, 21 January 2015

Voice over WiFi (VoWiFi) technical details

VoWiFi is certainly a hot topic, thanks to the support of VoWiFi on iPhone 6. A presentation from LTE World Summit 2014 by Taqua on this topic has already crossed 13K views. In this post I intend to look at the different approaches for VoWiFi and throw in some technical details. I am by no means an expert so please feel free to add your input in the comments.

Anybody reading this post is not aware of S2a, S2b, Samog, TWAG, ePDG, etc. and what they are, please refer to our whitepaper on cellular and wi-fi integration here (section 3).

There are two approaches to VoWiFi, native client already in your device or an App that could be either downloaded from the app store or pre-installed. The UK operator '3' has an app known as ThreeInTouch. While on WiFi, this app can make and receive calls and texts. The only problem is that it does not handover an ongoing call from WiFi to cellular and and vice versa. Here are a few slides (slides 36-38) from them from a conference last year:



The other operators have a native client that can use Wi-Fi as the access network for voice calls as well as the data when the device is connected on the WLAN.

A simple architecture can be seen from the picture above. As can be seen, the device can connect to the network via a non-3GPP trusted wireless access network via the TWAG or via a non-3GPP untrusted wireless access network via ePDG. In the latter case, an IPSec tunnel would have to be established between the device and the ePDG. The SIM credentials would be used for authentication purposes so that an intruder cannot access ePDG and the core.

Now, I dont want to talk about VoLTE bearers establishment, etc. which I have already done here earlier. In order to establish S2a (trusted) and S2b (untrusted) connection, the AAA server selects an APN among those which are subscribed to in the HLR/HSS. The PDN-GW (generally referred to as PGW) dynamically assigns an IP address out of a pool of addresses which is associated with this APN. This UE IP address is used by the VoWiFi SIP UA (User Agent) as the contact information when registering to the SIP soft switch (which would typically be the operators IMS network).

If for any reason the SIP UA in the device is not able to use the SIM for authentication (needs ISIM?) then a username/password based authentication credentials can be used (SIP digest authentication).

Typically, there would be a seperate UA for VoLTE and VoWiFi. They would both be generally registering to the same IMS APN using different credentials and contact addresses. The IMS network can deal with multiple registrations from the same subscriber but from different IP addresses (see 3GPP TS 23.237 - 'IMS Service Continuity' for details).

Because of multiple UA's, a new element needs to be introduced in order to 'fork' the downstream media streams (RTP/RTCP packets) to different IP addresses over time.

3GPP has defined the Access Transfer Gateway (ATGW) which is controlled by the Access Transfer Control Function (ATCF); the ATCF interfaces to the IMS and Service Centralization and Continuity Application Server (SCC AS). All these are not shown in the picture above but is available in 3GPP TS 23.237. The IMS networks in use today as well as the one being deployed for VoLTE does not have ATGW/ATCF. As a result vendors have to come up with clever non-standardised solutions to solve the problem.

When there is a handover between 3GPP and non-3GPP networks, the UE IP address needs to be preserved. Solutions like MIP and IPSec have been used in the past but they are not flexible. The Release-12 solution of eSAMOG (see 3GPP TS 23.402) can be used but the solution requires changes in the UE. For the time being we will see proprietary solutions only but hopefully in future there would be standardised solutions available.

3GPP TS 23.234 describes more in detail the interworking of 3GPP based system and WLAN. Interested readers can refer to that for further insight.

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:

Wednesday, 5 November 2014

2015 will finally be the year of Voice over LTE (VoLTE)


On 4th Nov. 2009, the One Voice initiative was published by 12 companies including AT&T, Orange, Telefonica, TeliaSonera, Verizon, Vodafone, Alcatel-Lucent, Ericsson, Nokia Siemens Networks, Nokia, Samsung and Sony Ericsson. These all agreed that the IMS based solution, as defined by 3GPP, is the most applicable approach to meet their consumers expectations for service quality, reliability and availability when moving from existing CS based voice services to IP based LTE services.

On 15th Feb 2010, GSMA announced that it has adopted the work of the One Voice initiative to drive the global mobile industry towards a standard way of delivering voice and messaging services for LTE. The GSMA’s VoLTE initiative was supported by more than 40 organisations from across the mobile ecosystem, including many of the world’s leading mobile communication service providers, handset manufacturers and equipment vendors, all of whom support the principle of a single, IMS-based voice solution for next-generation mobile broadband networks. This announcement was also supported by 3GPP, Next Generation Mobile Networks alliance (NGMN) and the International Multimedia Teleconferencing Consortium (IMTC).

GSMA has produces various reference documents that map to the 3GPP standards documents as can be seen above.



As per GSA71 operators are investing in VoLTE studies, trials or deployments, including 11 that have commercially launched HD voice service. The number of HD voice launches enabled by VoLTE is forecast to reach 19 by end-2014 and then double in 2015. In July 2014 GSA confirmed 92 smartphones (including carrier and frequency variants) support VoLTE, including products by Asus, Huawei, LG, Pantech, Samsung and Sony Mobile. The newly-announced Apple iPhone 6 & 6 Plus models support VoLTE.

Things are also moving quickly with many operators who have announced VoLTE launches and are getting more confident day by day. Du, Dubai recently announced Nokia as VoLTE partner. KDDI, Japan is launching au VoLTE in December. Telstra, Australia has already been doing trials and plans to launch VoLTE network in 2015. Finally, Verizon and AT&T will have interoperable VoLTE calls in 2015.

Below is my summary from the LTE Voice Summit 2014. Let me know if you like it.


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: