Posts

Mobile Roaming

To VoLTE or to OTT. That’s the question? Hmmmm…

This question has taken me back a few years when operators considered introducing Rich Communication Services (RCS) and the “to RCS or to OTT” question was raised as well. The answer is already known; RCS was proven to be a failure as users adopted OTT services instead. Operators have lost billions of dollars since the introduction of OTT services.
Although more than 300 mobile operators have already introduced LTE networks, only a few of them have introduced VoLTE. The reasons include significant technical challenges such as guaranteeing quality of service and very high costs.
VoLTE aims to guarantee HD voice when both ends are on the service, optimize networks and best utilize the frequencies, save battery consumption of the devices and more. Analysts have found that VoLTE can be a nice to have service but it neither increases the ARPU in the short term nor resolves the operator’s major concerns (such as declining roaming revenues or limited service coverage in rural areas, high towers and indoors) in the long term.Mobile Roaming

While operators are looking for a long term solution, there is a serious need to overcome these challenges now before it is too late. VoWifi has been recently introduced and might serve as a long term solution but it is not relevant for the immediate future as only a few mobile devices currently offer this capability. In addition, the technical challenges involved ensure that it’s a long way off until it is fully adopted.
So, is there a less costly, less complicated and much faster solution that overcome these challenges for mobile operators?
The answer is….. Yes. A mobile OTT communications solution consisting of mobile apps and backend servers, costs only a fraction of the invested capital in the new technologies, is fully deployed and operational in few months compared to years and so simple that it requires only the installation of an app by the customer would be a solution.

I have listed some of the challenges and the ways to overcome them by mobile OTT solutions.

The major concerns of mobile operators

Mobile operators have enjoyed high revenues in the past. Today they are facing serious threats from opportunistic OTTs who offer alternative services for little or no cost, causing a sharp decline in their roaming revenues. Limited service coverage in rural areas and high towers is still a concern, as this causes dissatisfaction and disruption of service.

Defending Roaming Revenues Strategies

In recent years, mobile operators have retaliated by adopting VoIP technology. Some have offered roaming VoIP plans utilizing available free Wi-Fi networks while other operators have offered bundled packages of GSM & VoIP over Wi-Fi. This solution was good but not good enough, neither for the operators who couldn’t guarantee high quality service due to the unpredictability of non-controlled Wi-Fi connections, nor for the roaming subscribers who had to search for available open Wi-Fi networks in certain areas and pay high prices due to the bundled high price of GSM roaming costs.

Nowadays, data roaming prices are low, data connectivity is available almost everywhere and operators have upgraded their data networks to support higher capacities. Operators are able to guarantee a higher quality of voice service at low prices, while their customers maintain their same cellular number when using the OTT communications apps.

AudioCodes’ MobilityPlus, ALL IP OTT communications solutions, which consist of white label mobile applications and backend servers, enable operators to offer low cost, yet profitable HD voice, video and messaging over IP services utilizing roaming data networks (3G, 4G, LTE).  This keeps their subscribers using their cellular numbers over IP networks. By doing this, operators promote a new bundle of roaming data and VoIP services. Subscribers who purchase cellular roaming data will have access to VoIP service as well, a service which increases subscriber loyalty.

Improving Service Coverage

Mobile operators are technically challenged, however, to increase service coverage in areas with limited coverage such as rural areas, high towers and indoors. Subscribers in these areas report a high rate of unsuccessful calls and disrupted service causing them to consider alternative solutions which in turn leads to a decrease in communication services revenues.

With the increase of Wi-Fi network availability readily found in these areas, customers receive calls and send texts over existing home and office Wi-Fi networks rather than the operator’s mobile network that is limited or does not exist.

AudioCodes’ MobilityPLUS OTT app supports Wi-Fi calling as a preloaded app within the subscribers’ smartphone (on Android smartphones) or as an OTT app that keeps the subscriber using his mobile number. MobilityPLUS enhances service coverage and guarantees HD voice quality when participants are on Wi-Fi networks.

Continuous Service Connectivity Mobile operators who have adopted VoIP technologies to overcome today’s challenges need to address the lack of continuous service connectivity when subscribers move between Wi-Fi and data networks and vice versa.  Until now, subscribers who were on a VoIP call over Wi-Fi could not move to a data network (3G/4G) without having the call dropped. In many cases, the user disconnected and redialled when moving to another network. Not Anymore. AudioCodes’ MobilityPLUS assures mobility with continuous connectivity, guaranteeing a seamless handover between Wi-Fi to 3G/4G and vice versa. The solution combines AudioCodes’ MobilityPLUS Mobile OTT and Mediant SBC solutions, leveraging unique SBC capabilities and leading mobile VoIP technology.

the whole is greater than the sum of its parts

WebRTC Connectivity Solution with Focus on Quality and Scale

The whole is greater than the sum of its parts

the whole is greater than the sum of its partsWe released a PR today about the AudioCodes WebRTC Connectivity Solution. In this post, I want to provide a technical insight into this solution, explaining why the whole is greater than the sum of its parts.

A typical approach to connecting WebRTC with an existing enterprise VoIP network would follow one of these two architectural concepts:

  • Browser using Opus with some kind of proprietary signaling-> WebRTC to SIP GW -> SBC -> Transcoding to G.7xx -> IP Phone on a SIP network
  • Browser using G.711 with some kind of proprietary signaling-> WebRTC to SIP GW -> SBC -> [Optional: Transcoding from G.711 to G.7xx]-> IP Phone on a SIP network

Both cases introduce some issues

The external WebRTC to SIP GW carries a price.

Transcoding from Opus to G.7xx is something you would want to avoid unless there is no other option. Opus requires hefty CPU resources (much more than most audio codecs) and introduces quality issues while increasing CAPEX.

The other alternative, using G.711 over the open internet, is not a good option as G.711 wasn’t built for sustaining quality over unmanaged networks.

Traffic traverses between networks and different network types (WiFi, Wireline Ethernet, public Internet and enterprise networks) while devices themselves can vary as well. Handling of network impairments should be done in the entity that connects between these networks as it is familiar with the requirements of each and has the per-session knowledge of source and destination of traffic. While the two links above use VoLTE as an example in the post, similar issues arise when traversing WebRTC to non-WebRTC networks and the algorithms described in these posts serve the need of this architecture as well.

Another missing piece in typical deployments is the ability to monitor the traffic, know what is happening on the network and impact SBC decisions for quality improvements.

Putting quality and scale at the front

The solution announced was designed with these two factors at the forefront and that is what makes it stick-out of the crowd.

Integrated solution

In our solution, WebRTC is supported in the SBC itself. This includes WebSockets, DTLS and other WebRTC “special” behavior. This architecture simplifies deployment and management as well as reduces delay, (or in other words, increases quality).

Minimal transcoding scenarios

By supporting Opus in the AudioCodes IP Phone, we hold the rope at both ends. On the one hand, voice over the open Internet is using the Opus codec which is purposely built for this task. On the other hand, transcoding is not required as the IP Phone also supports Opus. This significantly increases the number of calls supported while reducing CAPEX.

Signaling

For signaling we use SIP over WebSockets. We found this to be a good solution when the goal is to connect to existing networks.

Another advantage of the decision to use SIP for signaling is the connection to WebRTC API platforms. WebRTC API platforms typically use proprietary signaling. For connecting to existing networks they build an adaptor which is typically SIP. This basic SIP implementation can’t connect to any existing enterprise SIP network but going through the SBC allows it to do so. While this SIP adaptor varies and is not always pure WebRTC over WebSockets, eliminating the need for this adaptor to implement a full WebRTC to SIP GW, simplifies this interconnection making this task easier.

Voice quality enhancement

As mentioned, traffic traversing between networks typically suffer from call quality degradation. There are different implementations of media engines on the client side that are optimized for the network with which the client plans to work. When the client connects with another client on a network that it wasn’t built to connect with, voice call quality issues increase. Having the SBC as a demarcation point between the networks allows for the utilization of the AudioCodes voice enhancement algorithms for improving audio quality.

Detect & correct

The AudioCodes Session Experience Management (SEM) not only monitors and detects voice call quality issues, it also works in harmony with the SBC to allow for smart, quality based, routing and quality improvements.

Why is this important?

A WebRTC GW doesn’t stand by itself; it needs a multitude of capabilities and supporting elements to ensure effective and high quality service. This is why the whole is indeed greater than the sum of its parts when bringing all that is required for an end-to-end WebRTC Enterprise connectivity solution.

Managing Voice Quality

3 Things Required for Managing Cross Network Voice Quality

So you’ve built your VoLTE network for high quality. You are providing high bandwidth to your customers so browsing and watching video is great. You also managed to get delay, jitter and packet loss down so voice calls are using WB-AMR giving your customers top quality.

Managing Voice QualityBut even though VoLTE is set to succeed, it will not happen overnight and it can’t be an island, there are other networks it needs to connect with. You need to allow for calls to GSM, PSTN and wireline VoIP.

To allow for this, you engineered your network in a way that if a call needs to exit the VoLTE network to any of the other networks you simply transcoded it to G.711. With that, it connects “without any issue” to any network out there.

So you connected your VoLTE network to other networks but that’s exactly when problems started to come up. Users started calling your contact center complaining about voice quality issues, they felt as if a mouse has cut the wire. Analyzing the complaints showed that there are problems not only when calling between the different types of networks but even when calling between VoLTE networks of different service providers.

Different type of networks perform differently

VoLTE

Think of a VoLTE network. It prioritizes voice over other data types. It will not retransmit voice packets even if there is packet loss (different from its handling of data) and it dynamically tunes rate, stuffing multiple voice samples into a single packet and add redundancy when needed.

In a VoLTE to VoLTE case, this results in great quality but when the destination is on a different network, that network handles things differently, resulting in quality issues.

GSM

On the GSM network, data will be retransmitted in case of packet loss, VoIP traffic included. This results in increased delay. Moreover, the 3G network works in burst mode sending a large amount of data to the core of the network in bursts, resulting in delay and jitter.

In case of voice TDM calls, NB-AMR is used which is, of course, different from what is used on the other networks.

Wireline VoIP

In the enterprise and consumer environments, VoIP provided by service providers typically uses G.729. The network itself is typically designed for wireline access but in reality many access it over WiFi. Needless to say that network behaviour is different in each case.

PSTN

Well, I guess there is no need to say too much about this subject. It is robust and voice quality is constant but at PSTN quality.

The brain and the tools that solve the problem

We have seen that different networks have different characteristics. That’s no news I guess. The conclusion though, is. Because this simple fact means that it is not efficient to decide on call setup properties and mid-call changes without knowing exactly the characteristics of the caller and callee networks.

Solving the quality issues when calling between networks requires three things:

  • Knowledge of all networks’ characteristics
  • Real-time monitoring information
  • Voice enhancement tools that will be managed dynamically based on actual call and network information

The entity that answers these requirements would be an SBC or a transcoding GW that resides in the core of the network. It would manipulate voice using various voice enhancement tools, decide on the best codec and rate for a call between the networks and use monitoring information for its decisions

On October 8th, I’ll be speaking on this topic at the LTE Voice Summit in London. If you happen to be there, drop by and say hello.

I will also be posting more information about voice call quality enhancement tools as well as a link to my presentation on SlideShare so stay tuned and be sure to follow: @AudioCodes and @AmirZmora

Here is a sneak peek to one of my presentation slides.

Voice Quality in Wireless Networks

Steve Austin

Why RCS Failed

[Post is better viewed on the blog Website]

How Standards Define Themselves to Death

Steve AustinSteve Austin, The Six Million Dollar Man, was – Better…Stronger…Faster… That was the hope of RCS (Rich Communication Services).

RCS started its journey at the GSMA in 2008 with the promise to allow service providers to deliver “OTT like” services with interoperability across service providers and managed quality of service as it is provided by those that own the network. By being better than what OTT can offer, users would vote for those services of the service provider.

Where was the market back then?

Looking at OTT on mobile at that time, things were still kind of preliminary.

Skype – Mainly used on desktops, Skype for mobile was in its infancy

WeChat – didn’t exist, launched in 2011

WhatsApp – Didn’t exist, launched in 2009

Facebook Messaging – Project Titan for user to user messaging was launch in 2010 and mobile messenger app was launched in 2011

Viber – Didn’t exist, launched in 2010

You get the point…

The important things to conclude from this data are:

  • Back then, when RCS started, there was still plenty of market share for it to capture
  • The OTTs listed above took the market by storm working vertically (a specific service) and not horizontally (many services for a specific segment/region)
  • They are all islands…didn’t wait for any standards
  • Oh…and they are all free

Why RCS lost to OTTs?

RCS has standardized itself to death in 2 ways.

It has insisted on trying to define and standardize everything possible rather than sticking to the bare minimum. Due to this, it lost a lot of time and left little room for flexibility to those who wanted to deploy it. RCS and the brand “joyn” defined everything all the way up to the user experience, what the address book should look like and what the user would see on each and every screen.

On top of that, RCS standardization tries to capture requirements from 2 camps, what was known previously as RCS and RCSe, later to be unified under the Blackbird standard version. This moves sounds great but Blackbird still includes different options for doing pretty much the same thing. When you define multiple ways to send a message and to implement presence based features, the life of the developer becomes more complex.

The promise of RCS was valid

The promise of RCS was, and even today still is a valid one. It has been proven to be valid through the success of OTT players such as WhatsApp that provide some of the RCS services but in a proprietary way.
Different from VoLTE, that has good technical and business reasons to replace Circuit Switched voice, RCS doesn’t enjoy the network ownership advantage, OPEX savings and enhanced user experience compared to using an OTT service for the same purpose.

The major benefit of RCS could have been cross service provider interoperability.

Other assumed benefits, such as a unified user experience, are not more than a pipe dream as not all device vendors will vote for what joyn has defined (i.e. Apple). Given that, we are left with an application, at least on some of the devices, and not a pre-integrated experience that comes pre-loaded on the device.

The enhanced address book and integration with the phone’s address book has come to the OTT applications user experience a long time ago. Given the ubiquitous nature of some of them (who of my friends doesn’t have WhatsApp? None!), the benefit of RCS interoperability is losing its advantage.

There was another option

The other option was to put time-to-service at a higher priority than top to bottom standardization work.

Time-to-service as priority #1 doesn’t translate to zero standards, it translates to standardizing only what really needs to be standardized as was done in WebRTC, while leaving the rest for the implementers.

In context of RCS that would mean APIs (e.g. send message, get contact…) for applications to use the RCS service for launching innovative services and things related to payload (e.g. how a file is transferred between clients).

Service providers and RCS server vendors would provide client SDKs based on which the service provider could launch its own services. Additionally, they would provide them to developers to build services with and integrate them into other applications.

Conclusion

Reality has proven that even in places where standards exist, once communication crosses between services and networks, it goes through mediation servers. We see more coupling between clients and servers today, something that contradicts the goal of standards, to enable zero vendor lock. This reality is apparent today in every type of real-time communication – UC, IP-PBX, VoLTE and WebRTC. There is no reason why it will be different in RCS and therefore waiting runs the risk of missing the opportunity.

One-Fish-Two-Fish-Red-Fish-Blue-Fish-by-Dr-Seuss

A Mouse has cut the Wire: I can’t hear you…..

 [Post is better viewed on the blog Website]

 

When I was a kid, I loved reading the Dr. Seuss books with the fun and educational rhymes. As an adult, I loved reading them to my own children when they were young. Some things never grow old.

It seems that it is the same with the quality of a phone call. From the early days of the switchboard to calls over the cellular network, the phrase “can you repeat that? I couldn’t hear you” has been commonly heard over the years. And so has the emphasis on improving voice quality accompanied the advances made in telephony communications.

One-Fish-Two-Fish-Red-Fish-Blue-Fish-by-Dr-Seuss

Source: One Fish Two Fish Red Fish Blue Fish, by Dr. Seuss

This is no less true today with Voice over IP (VoIP) networks. Perhaps the greatest enemies of a quality call over VoIP networks are delay, jitter and packet loss. Network experts invest great efforts in fine tuning their networks so as to minimize the negative effects of these factors. In a recent post on this blog entitled “Voice is Coming to LTE”, Amir Zmora pointed out that in his experience in speaking with service providers that are already invested in VoLTE and interconnecting with other networks, it was clear that voice quality and QoE are their main concerns.

VoIP traffic may traverse wireline, WAN, cellular or wireless networks. Wireless traffic in particular is inherently inconsistent and the effects of delay, jitter and packet loss, if not handled, can seriously impair the quality of a call. Wireless networks were designed first and foremost for data applications. But in data focused applications, the most important thing is for the payload to arrive complete, how fast it gets there is less important. Thus, compensating measures can be implemented to guarantee that requirement. However, while these capabilities ensure the arrival of the packets, they also increase delay and jitter. And while delay for data applications is acceptable, in the case of VoIP the delay may be intolerable resulting in someone saying “I didn’t catch that, come again?” or just dropping the call altogether.

As most VoIP entities in the network (session border controllers, gateways, ATAs, IP Phones, mobile clients, etc.) were designed to handle wireline, and not wireless impairments, they have a hard time handling (without help) traffic emanating from wireless networks. To get around the problem, AudioCodes has implemented special built-in tools inside its Session Border Controllers. By placing the SBC with these tools between the wireless network and any other network (wireless, wireline, cellular, etc.), the impairments from the wireless network traffic can be managed and reduced dramatically to allow for an end-to-end quality call and prevent someone from saying, “I cannot hear your call. I cannot hear your call at all!”

Want more information?

Click here to download a White Paper in which you will learn how built-in SBC tools such as an adaptive jitter buffer, transcoding, redundancy, trans rating and quality-based routing can each play a major role in significantly enhancing QoE. Furthermore, when taken together and given the ability to fine tune and balance between the variables, they can be truly powerful.

forcing vendors to enter a cat-and-mouse game

Voice is Coming to LTE

[Post is better viewed on the blog Website]

 Back in 1999, when 3G was still a questionable dream IMS started to take root as an architecture for mobile services. It was adopted by the 3GPP and later on also by 3GPP2 and other organizations and forums. Standardization work went on for many years resulting in continuous releases of standard versions forcing vendors to enter a cat-and-mouse game.

forcing vendors to enter a cat-and-mouse game

The adoption of IMS was slow and disappointing

There are many IMS deployments today but IMS didn’t deliver on its promise. While vendors and service providers were busy fighting in the standard bodies, small start-ups came quickly to the market with advanced services and took the market by storm.

VoLTE is based on IMS and is defined in IR.92 and IR.94. In a nutshell, it defines Voice, SMS over IMS (IR.92) and Video (IR.94) over LTE networks.

So what is all the fuss about VoLTE?

The answer to that lies in the eyes of the beholder.

LTE networks are being deployed by hundreds of service providers worldwide. Once LTE coverage is ubiquitous, there is a lot of sense for the service provider to move away from circuit switched (CS) voice to VoLTE, as in a few years it will eliminate the need to continue supporting the CS network, thereby reducing OPEX.

Additionally, higher quality end-to-end voice will be possible as VoLTE supports HD voice and includes features for resource reservation as well as other important features such as security.

From the end user perspective, in addition to the higher quality voice and security that comes with VoLTE, longer battery life will be possible as the need for dual LTE & CS connectivity of the phone will be removed.

Reality check

Learning from the past, there are 3 fundamental challenges service providers and vendors will need to solve.

Time to market

Service providers have waited for technologies to become stable and for standards to become fully ratified. This stopped them from launching advanced services, leaving the door open for OTTs.

Interoperability

The reality is that service providers currently providing VoLTE services are not all doing so the same way. Different capabilities and scenarios are supported by each service provider. This results in the need to verify each device and server before it is deployed on their network and vendors are required to make modifications in order to pass this certification process. Given this reality, there is a need to have a mediation element (SBC) between service providers, thus interoperability is theoretical… (did I say there is no point in waiting for everything to be perfectly compatible and ready?) Launch…don’t wait.

There are other networks out there

The service provider world is more complex than that of an OTT. The service provider doesn’t have the benefit of building an island. It needs to connect to older networks, enterprise networks and other service providers. This again brings up the need for that demarcation point that will mediate signalling and make sure voice quality between those networks remain good.

Speaking with service providers that are already invested in VoLTE and interconnecting with other networks, voice quality and QoE are their main concerns. Solutions for these concerns are provided through advanced audio processing done in mediation entities that interconnect between the networks.

Stay tuned for more on QoE in future posts on this blog.

Why is this important?

There are different opinions about the future of VoLTE and its chances to succeed. There is no doubt that secured voice calls using HD codecs are possible today using OTT. It is also clear that an OTT will not go this route, but in the service provider space VoLTE looks like a technology that will happen because:

  • It makes sense from an operational cost perspective
  • VoLTE integrates nicely into the service provider’s existing OSS/BSS systems
  • There are ways to downgrade the call to 3G/TDM when LTE is not available…SRVCC

Having said that, interoperability is a challenge. Service providers should assume there will be no 100% interoperability and standard support both on phones and servers. Certification of clients will always be required as well as demarcation points between networks as exist today in their VoIP networks.

Therefore time to market is more important than completing every item on the standards checklist.