China Mobile: A peek at 5G

I was hoping to draw a line under 5G for the time being after a prolonged discussion on my earlier post here and then after clarifying about MSA here. Then this CMCC lecture was brought to my attention and I thought this is a good lecture to listen to so I have embedded the video and slides below. Let me know what you think in the comments below.

A Peek at 5G from Zahid Ghadialy

Case study of SKT deployment using the C-RAN architecture

Recently I came across this whitepaper by iGR, where they have done a case study on the SKT deployment using C-RAN. The main point can be summarised from the whitepaper as follows:

This approach created several advantages for SK Telecom – or for any operator that might implement a similar solution – including the:

• Maximum re-use of existing fiber infrastructure to reduce the need for new fiber runs which ultimately reduced the time to market and capital costs.
• Ability to quickly add more ONTs to the fiber rings so as to support additional RAN capacity when needed.
• Support of multiple small cells on a single fiber strand. This is critical to reducing costs and having the flexibility to scale.
• Reduction of operating expenses.
• Increased reliability due to the use of fiber rings with redundancy.
• Support for both licensed and unlicensed RAN solutions, including WiFi. Thus, the fronthaul architecture could support LTE and WiFi RANs on the same system.

As a result of its implementation, SK Telecom rolled out a new LTE network in 12 months rather than 24 and reduced operating expenses in the first year by approximately five percent. By 2014, SK Telecom expects an additional 50 percent OpEx savings due to the new architecture.

Anyway, the paper is embedded below for your perusal and is available to download from the iGR website here.

Fronthaul: The New Paradigm for Enabling the Het-Net from Zahid Ghadialy

Telecom API's: The why and what

It felt like with the focus on LTE/4G and Small Cells and everything else in the mobile industry, the API's vanished in the background...or so it seemed. Telco API's are alive and kicking and there is a renewed focus on them.

This is from an AT&T press release not so long back:

AT&T*, already the leading carrier deploying network Application Programming Interfaces (APIs) to developers,1 today announced it has launched an enterprise-focused API program that allows enterprise customers, wholesale collaborators and solution providers to innovate using AT&T network APIs.

Led by industry thought leader Laura Merling, VP of Ecosystem Development and Platform Solutions, AT&T is pursuing a telecommunications industry API opportunity expected to grow to $157 billion in global revenues by 2018.2

APIs are software interfaces that provide access to data and core functions within AT&T’s network. By opening up its APIs to customers, AT&T believes it can help them meet three key challenges: do more without spending more; harness technology to gain competitive advantage; and support their ability to create and deploy applications that can be used on almost any device around the world.

...

Some examples of how enterprises can use AT&T APIs include:

• Content formatting: Using APIs, video content from a company’s video library stored in the cloud can be easily optimized in near real-time for users to watch on almost any device and network.
• Communications services: To bring more efficiency and productivity to business operations, businesses can use APIs to automate voice and video calls, integrating speech and video services into applications.

Sometime back, Martin Geddes (MG) posted his discussion on this topic with Alan Quayle (AQ) here:

I interviewed Alan earlier this week, and here is our joint “state of the telecom API nation” report.

MG: My early telecom API project crashed and burned, and past industry initiatives like ParlayX never took off. What has changed since the early 2000s that is triggering new and rapid growth?

AQ: Both the technology and the market have evolved. Large new developer communities have been created by Apple and Google, delivering value through those ecosystems. The need for such ecosystems and partnerships in telecoms is now driven by business demand, not technology supply, and thus is no longer seen as unusual or controversial.

Ten years ago there were developers, but the developer platforms were not as sophisticated. The technology was complex to consume, so you had to be a hardcore developer to use what was on offer. Today we have a mass developer market of people with Web development skills, and an Independent Software Vendor (ISV) market able to consume telecoms capabilities using their existing skills base.

The whole ICT industry – including ancillary services like consulting and equipment – is around a $5tn annual market. Yet it notably lacks a large-scale profitable developer ecosystem for networked service delivery. Why has it failed? Historically there have been too many silos, and too much friction to engage with them. What we are now seeing are companies like Apidaze, Bandwidth, OpenCloud, Plivo, Telestax, Tropo, and Twilio eliminating both of these. Lots of money is being spent on marketing to developers, creating a new business opportunity that telcos and broader ecosystem can take advantage of.

Notably this ecosystem is about more than just APIs. There's also the whole free and open source software arena too. Tools like FreeSWITCH, OpenCloud, Mobicents and WebRTC are becoming core to service innovation. Platforms like Tropo’s Ameche open up new opportunities for value-added voice services. We will be looking at the whole development stack at the Summit in Bangkok.

Who are the key consumers of telecoms APIs and what for?

Telecoms APIs are generally used by enterprises that are embedding communications into their core processes. The term “Communications Enabled Business Processes” was used in the past, but the name never took off, even if the concept did. As such, there is a quiet enterprise communications revolution going on. (See my recent articlefor more information.)

Lots of businesses are doing cool stuff, often to sell to other enterprises. These projects and platforms may not get much press individually, but collectively they add up to a significant market.

For example, Turkcell are a leader in this area of enterprise API delivery. However, they don’t talk about APIs, because it’s about the end user and the value from a better customer experience. They focus on promoting their enterprise services, all of which are (crucially) backed by sales team with technical support. Example services include FreeURL, where customers surf on your pages for free; customer device model and mobile number to support efficient and effective interaction regardless of end user device type; a “find the nearest store” capability to drive sales; and click to call services to capture leads.

That these telecoms services use APIs is about as interesting as them using electricity. The business value and innovation is in the enhanced customer experiences they enable.

Who makes money from producing telecoms APIs and how?

Everyone can! Telcos, intermediaries who work with the developers, enterprises and systems integrators. To make progress, however, telcos have to accept they can't do everything for themselves. For instance, you have to know what developers want – and that means Web scripting, not REST APIs. We will for the foreseeable future need middlemen who translate the value of telecoms APIs into a consumable form.

The greatest value is in customer interaction APIs. The need to communicate with suppliers and customers is fundamental to the human condition, we have been doing it for millennia, and will not stop any time soon. There are long-established markets like bulk SMS and automated calling, and these are ripe for new growth with new capabilities to interact and transact with customers.

What are the most promising areas for future growth?

The growth is around value-added services, notably around the current voice cash cow. It’s time for telcos to remember their heritage: you're the phone company. The distracting “digital lifestyle” stuff only makes money for the content companies. There are too many adjacent businesses being built where the telco doesn't have enough competence, and are competing against low-end competition (e.g. cheap webcams vs managed CCTV or home monitoring services).

Lots of consultants are selling future billion-dollar markets that don't exist. Telcos need to stick to the basic nuts and bolts of communications services, and do them better.

What are the key challenges facing this space?

The key challenge is that this game is that it requires an ecosystem, and telcos are islands. That doesn't mean they should copy Apple and Android, but instead they need to focus on segments where they have credible value and an advantage. A $5tn industry should be able to do this.

What it requires is a whole offering, including sales, business development and support. API-enablement is just a piece of technology, and this cannot be led from a network or IT function; it’s a line of business. The improvement and value to the customers has to come first, and getting the mindset right is hard. We have proof points that you can make money, thanks to companies like Telestax, Tropo and Twilio, if you build a whole supply chain.

Finally, Alan Quayle has posted his independent review of Telecom API's which is embedded below:

Do you have an opinion on Telecom API's? Feel free to add it in the comments.

Multi-stream aggregation (MSA): Key technology for future networks

In our recent 5G presentation here, we outlined multi-technology carrier aggregation as one of the technologies for the future networks. Some of the discussions that I had on this topic later on highlighted the following:

1. This is generally referred to as Multi-stream aggregation (MSA)
2. We will see this much sooner than 5G, probably from LTE-A Rel-13 onwards 

Huawei have a few documents on this topic. One such document is embedded below and aanother more technical document is available on slideshare here.

MSA: A key technology for the evolution of future wireless networks from Zahid Ghadialy

Push to talk (PTT) via eMBMS

I was talking about push to share back in 2007 here. Now, in a recent presentation (embedded below) from ALU, eMBMS has been suggested as a a solution for PTT like services in case of Public safety case. Not sure if or when we will see this but I hope that its sooner rather than later. Anyway, the presentation is embedded below. Feel free to add your comments:

eMBMS for Public Safety from Zahid Ghadialy

#5G: Your Questions Answered

This is our view on what 5G is, please feel free to add your comments here or if you want a much wider audience to discuss your comments, please add them to the Cisco Communities here.

5G: Your Questions Answered from Cisco Service Provider Mobility

LTE for Utilities and Smart Grids

This has been an area of interest for the last couple of years. Discussions have been centred around, "Is LTE fit for IoT?", "Which technology for IoT", "Is it economical to use LTE for M2M?", "Would small cells be useful for M2M?", etc.

Ericsson has recently published a whitepaper titled "LTE for utilities - supporting smart grids". One of the table that caught my eye is as follows:

LTE would be ideally suited for some of the "Performance class" requirements where the transfer time requirements is less than 100ms. Again, it can always be debated if in many cases WiFi will meet the requirements so should WiFi be used instead of LTE, etc. I will let you form your own conclusions and if you are very passionate and have an opinion, feel free to leave comment.

The whitepaper is embedded below:

Related posts:

• Introduction to M2M and its developments in LTE
• From M2M Communications to IoT
• M2M Standardization and its Role for Emerging Smart Cities
• Everything you ever wanted to know about M2M

LTE TDD - universal solution for unpaired spectrum?

TDD deployments are gathering pace. An earlier GSA report I posted here, highlighted the many devices that are TD-LTE ready.

The main thing that is being emphasised is that from the standards point of view, not much additional efforts are required for a TDD device as compared to an FDD device. Of course in practice the physical layer would be different and that could be a challenge in itself.

Qualcomm published a presentation on this topic that is embedded below. Available to download from here.

Throughput Comparison for different wireless technologies

Merged various slides from the recent 4G Americas presentation to get a complete picture of data throughput speeds for various technologies.

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:

• Voice-Over-LTE (VoLTE) Signalling
• Voice over LTE – a step towards future telephony (Ericsson Whitepaper)
• SPS and TTI Bundling Example
• On LTE Roaming ...
• LTE QCI and End-to-end bearer QoS in EPC