by Andrew Mackay, Manager Mobile Solutions, Cisco Systems
As Long Term Evolution (LTE) networks continue to be deployed, it is becoming evident that matching the existing 3G coverage quality is going to be a challenge. This is reminiscent of the early days of 3G, when it took many years to get coverage matching underlying GSM. The higher carrier frequency (2.1GHz) and partial initial overlays left deep indoor coverage with “cold spots.” This resulted in unreliable calls and increased battery consumption, which led many users to disable 3G out of frustration. Over time, operators invested in more infill Base Transceiver Station (BTS), wider use of In-building Systems (IBS) and repeaters, but indoor coverage was only really resolved when 3G on 850/900 MHz was deployed as a coverage “safety net.”
In Asia, the majority of LTE deployments are in the 1.8GHz band and higher. As a result, the typical LTE user drops back to 3G (850/900MHz) on a regular basis when deep indoors, commuting, or even inside their home. Initially, the user experience of dropping from LTE to 3G for data services may not be so irritating since voice is still falling back to 3G in the majority of networks. Plus, in many indoor scenarios, good Wi-Fi service is available to fill-in the missing bandwidth. But, ultimately, this is a branding issue: customers subscribing to a 4G service expect that level of service, not to see their service provider icon showing 3G. It becomes an even larger issue when you want to serve your subscriber real-time services over 4G, such-as voice and streaming video. So how do we avoid these service “pot-holes”?
“Warning: 3G pot-holes ahead.”
Many operators tell me that they will wait for sub-1GHz LTE coverage before considering wide spread VoLTE (Voice over LTE) deployment, but this may take years. Unlike in the US and Europe, the benefits of the digital dividend have yet to arrive at APAC with only live LTE APT700MHz deployments (in Taiwan so far). But even after the networks arrive it will take a while for the majority of devices to support the new band. 3G band refarming isn’t as easy as it sounds either; i.e., how do you refarm from carriers full of voice, which you can’t move to 4G until you have good VoLTE coverage? A classic “catch-22.”
One possible solution is to rely on Wi-Fi as a stop-gap measure for voice. Certainly, this approach has been in the press recently with operators 3 and EE in the UK discussing VoWiFi (Voice over Wi-Fi) strategies. In the case of EE, the role of using VoWiFi to plug LTE coverage holes was made explicit: “The aim of VoWiFi is to improve in-building coverage. Calls will be automatically routed via WiFi, for instance, in a user’s home or office, where there is an absence of cellular coverage.” VoWiFi received further attention with the announcement of iOS8 support for Wi-Fi calling on T-Mobile’s USA network.
“iOS8 adds VoWiFi”
The challenge I foresee with VoWiFi is providing a “Carrier Grade” user experience. My concern is not with voice quality, which can be maintained in HD on an uncongested access point, but more the limited mobility. At present, as a Wi-Fi signal fades, the client hangs on to the connection despite quality dropping below what VoIP (Voice over IP) requires, before giving up and switching back to cellular. Another issue is variability of up-stream connectivity on different Wi-Fi networks accessed on a typical day. In the case of a work Wireless Local Area Network (WLAN), for example, Session Initiation Protocol (SIP) traffic might be blocked as per the enterprise policy. Both of these issues are critical in the case of terminating calls, where the user may be forced to stay put to complete the call or have the call go straight to voicemail.
I believe Wi-Fi will be an important stop-gap for poor LTE indoor coverage, but, eventually, it should take on the complementary role of picking up the non-real-time bandwidth workload. The ideal end game has to be to provide sufficient LTE coverage and capacity to match (or exceed) the current 3G user experience for real-time services, particularly voice. How this is achieved given the multiple RAN tools available (lower frequency bands, LTE Smallcells, Repeaters, Relays and IBS) becomes a question of time and the best TCO business case, and that’s a whole other topic.
I have successfully registered my SIP endpoints (which we have developed) with Broadsoft sandbox environment. I can make basic calls without problems. When I try to conduct feature tests like Call Waiting (CW), Call Hold (CH), and Call Transfer (CT)...
I am trying to find if there is any Pros or Cons in deploying MPLS with separate customer AS for each site as opposed to one AS. The end goal is to be able to inject default routes from two DCs and be able to make a subset of sites follow one default rout...
So I have attempted the below config: l2vpn
backup disable never
xconnect group Xconns
In one of the discuss, it was initiated to us that there is a specific DB size for example:1 GB and breaching of which will led to crash of Iedge process.I want to replicate the scenario by creating load of user by tool in the lab and track the CDM db uti...
Some 15 years ago we had implemented a PWLAN service by deploying SSG on IOS and Cisco SESM (Subscriber Edge Services Manager) as the web interface (i.e. captive portal). Fast forward, SESM becomes EOL, gets replaced by Broadhop SME. Some years later...