We are living in times where the mobile device is no longer a device to just make calls, text, browse or a music player. In fact a mobile device is now the crux of our lives in this highly app-centric world where every use-case is an application. Mobile device has become the top source for information retrieval, content consumption and also for content creation. This has been possible not just because device OEMs have built such devices and ecosystems but also because of the rapid evolution of mobile networks from kbps to Mbps throughput and broader capacity to support these users.
From developed markets such as US, Japan or Korea to emerging markets such as Chile or China, operators have been on their toes to roll out the aspirational high speed, reliable and cost efficient LTE networks to tackle the rising data deluge. Operators are banking on charging premium for this ultra-fast broadband service to increase the ARPU and tackle the loss of revenues in voice as well as to the long tail of OTT players. However, there are a couple of things these operators should be careful about with respect to current generation LTE networks.
Firstly, marketing LTE network's throughput and reliability might attract the subscribers to upgrade their devices and plans but maintaining that promise is going to be the biggest challenge operators are about to face. There is a significant probability we are underestimating the amount of data consumption the mobile devices are capable of. These devices are continue to getting bigger with sharper screens and faster speed, a perfect recipe to consume more (& more) streaming videos on their devices. Thus it will thoroughly test if the current deployed 'reliable' LTE networks are actually capable of handling such consistent capacity sucking traffic. While operators might be already thinking of offloading many consumers to WiFi to address hotspot traffic areas but practically the capacity constraint bug is soon going to hamper many operators' these first generation LTE deployments.
Secondly, since the global LTE rollouts, operators have been racing with each other on how many hundreds of LTE POPs/markets have been covered. While this is an encouraging sign but neither promises if it is a blanket coverage nor the depth of the coverage. A patchy coverage with overall content consumption performance falling back to legacy network quality or pushed to a Wi-Fi hotspot won't justify operators' charging premium for the LTE service. Managing the future expectations of quality & reliable IP based voice, video and content consumption from coverage point of view should be another key pain point and cannot be assumed that the current LTE networks will be able to handle those. (QoE) Quality of Experience should be at the center and consistent enough as the user is on the move or in-building.
The current (or first) generation LTE networks deployed may reach saturation points quicker than expected in some developed markets where the LTE (with smart devices) subscriber penetration is exponentially rising. This makes a good case study for other operators globally planning to deploy their first LTE networks. We will thus eventually witness many operators to leapfrog straight to LTE-Advanced (3GPP Rel. 10 & above) networks to leverage advanced features such as carrier aggregation, HetNets, enhanced MIMO and thus better utilize the multiple band spectrum available, tighter network control and boost overall capacity and coverage in a much better way. It will also warrant the first generation LTE network operators to upgrade to LTE-A sooner than expected, firstly to live up to the promised premium network quality and secondly to compete with other operators leapfrogging to LTE-A.
When doing multi-hop async BFD sessions on ASR9K, the following restrictions / caveats are noted:1. HW-offload is not supported2. LC CPU which hosts the session is randomized according to line cards listed under 'multipath include location X/X...
Hello,In previous post (https://community.cisco.com/t5/xr-os-and-platforms/asr9000-forwarding-latency/td-p/2708349) back in 2015, it was identified that Typhoon to Typhoon forwarding latency on ASR9K is estimated to be around 15usec. Is there such fi...
Hi, My question is regarding the Radius AVpair client-mac-address that is sent to a Radius server as part of the authentication process and accounting. Let me clarify first that we are NOT using the mac-address as part of the username at all. T...
Hallo on ios-xr is possible or not when we wan to disable prompt "Destination file name (control-c to abort): " when copy file cisco ios-xr to usb like file prompt quiet on ciso ios ? Thank you for help