#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

New Mobile related terms added in Oxford dictionary

The Oxford dictionary has just added some new words in its dictionary. Here is a summary of the words related to mobiles.

BYOD: n.: abbreviation of 'bring your own device': the practice of allowing the employees of an organisation to use their own computers, smartphones, or other devices for work purposes. Wikipedia also calls it bring your own technology (BYOT), bring your own phone (BYOP), and bring your own PC (BYOPC).

digital detox, n.: a period of time during which a person refrains from using electronic devices such as smartphones or computers, regarded as an opportunity to reduce stress or focus on social interaction in the physical world.

Another term called "Nomophobia" which has unfortunately not yet entered the dictionary refers to as the fear of being out of mobile phone contact. The term, an abbreviation for "no-mobile-phone phobia". According to a recent survey some 54% of Brits have experienced this. If someone is getting affected by Nomophobia, its time they undergo a 'digital detox' to sort their life out.

emoji, n: a small digital image or icon used to express an idea or emotion in electronic communication.

Everyone using OTT applications would know them well. They are very useful in communicating emotions. I generally think this as one of the drawbacks of SMS that we cant use emoji's. On the other hand OTT apps can be making money by providing extended emoji's for a premium but I havent seen anyone do this yet.

FOMO, n.: fear of missing out: anxiety that an exciting or interesting event may currently be happening elsewhere, often aroused by posts seen on a social media website

'FOMO' is big and I personally know people who suffer from this. In the good old days this was known as jealousy where one would be jealous that someone was going on more holidays, have a bigger house/car, etc. In this connected world where we can get Facebook updates and notifications on the phones and tablets the digital term is FOMO. A slide from Mary Meeker's presentation that I put here shows that a typical user checks their phone 150 times every day and social media is not very far from the top.

internet of things, n.: a proposed development of the Internet in which everyday objects have network connectivity, allowing them to send and receive data.

This 'Internet of Things' or 'IoT' has been covered in the blog more than enough times.

phablet, n.: a smartphone having a screen which is intermediate in size between that of a typical smartphone and a tablet computer.

Earlier this year I put a post here that talked all about feature phones, smartphones, phablets, etc. Other terms like Tabphones and Phonetabs didn't make it.

selfie, n. (informal): a photograph that one has taken of oneself, typically one taken with a smartphone or webcam and uploaded to a social media website.

Here is a selfie of me using my phone today to end this post :-)

Centralized SON

I was going through the presentation by SKT that I blogged about here and came across this slide above. SKT is clearly promoting the benefits of their C-SON (centralized SON) here.

The old 4G Americas whitepaper (here) explained the differences between the three approaches; Centralized (C-SON), Distributed (D-SON) and Hybrid (H-SON). An extract from that paper here:

In a centralized architecture, SON algorithms for one or more use cases reside on the Element Management System (EMS) or a separate SON server that manages the eNB's. The output of the SON algorithms namely, the values of specific parameters, are then passed to the eNB's either on a periodic basis or when needed. A centralized approach allows for more manageable implementation of the SON algorithms. It allows for use case interactions between SON algorithms to be considered before modifying SON parameters. However, active updates to the use case parameters are delayed since KPIs and UE measurement information must be forwarded to a centralized location for processing. Filtered and condensed information are passed from the eNB to the centralized SON server to preserve the scalability of the solution in terms of the volume of information transported. Less information is available at the SON server compared to that which would be available at the eNB. Higher latency due to the time taken to collect UE information restricts the applicability of a purely centralized SON architecture to those algorithms that require slower response time. Furthermore, since the centralized SON server presents a single point of failure, an outage in the centralized server or backhaul could result in stale and outdated parameters being used at the eNB due to likely less frequent updates of SON parameters at the eNB compared to that is possible in a distributed solution.

In a distributed approach, SON algorithms reside within the eNB’s, thus allowing autonomous decision making at the eNB's based on UE measurements received on the eNB's and additional information from other eNB's being received via the X2 interface. A distributed architecture allows for ease of deployment in multi-vendor networks and optimization on faster time scales. Optimization could be done for different times of the day. However, due to the inability to ensure standard and identical implementation of algorithms in a multi-vendor network, careful monitoring of KPIs is needed to minimize potential network instabilities and ensure overall optimal operation.

In practical deployments, these architecture alternatives are not mutually exclusive and could coexist for different purposes, as is realized in a hybrid SON approach. In a hybrid approach, part of a given SON optimization algorithm are executed in the NMS while another part of the same SON algorithm could be executed in the eNB. For example, the values of the initial parameters could be done in a centralized server and updates and refinement to those parameters in response to the actual UE measurements could be done on the eNB's. Each implementation has its own advantages and disadvantages. The choice of centralized, distributed or hybrid architecture needs to be decided on a use-case by use case basis depending on the information availability, processing and speed of response requirements of that use case. In the case of a hybrid or centralized solution, a practical deployment would require specific partnership between the infrastructure vendor, the operator and possibly a third party tool company. Operators can choose the most suitable approach depending upon the current infrastructure deployment.

Finally, Celcite CMO recently recently gave an interview on this topic on Thinksmallcell here. An extract below:

SON software tunes and optimises mobile network performance by setting configuration parameters in cellsites (both large and small), such as the maximum RF power levels, neighbour lists and frequency allocation. In some cases, even the antenna tilt angles are updated to adjust the coverage of individual cells.

Centralised SON (C-SON) software co-ordinates all the small and macrocells, across multiple radio technologies and multiple vendors in a geographic region - autonomously updating parameters via closed loop algorithms. Changes can be as frequent as every 15 minutes– this is partly limited by the bottlenecks of how rapidly measurement data is reported by RAN equipment and also the capacity to handle large numbers of parameter changes. Different RAN vendor equipment is driven from the same SON software. A variety of data feeds from the live network are continuously monitored and used to update system performance, allowing it to adapt automatically to changes throughout the day including outages, population movement and changes in services being used.

Distributed SON (D-SON) software is autonomous within each small cell (or macrocell) determining for itself the RF power level, neighbour lists etc. based on signals it can detect itself (RF sniffing) or by communicating directly with other small cells.

LTE has many SON features already designed in from the outset, with the X.2 interface specifically used to co-ordinate between small and macrocell layers whereas 3G lacks SON standards and requires proprietary solutions.

C-SON software is available from a relatively small number of mostly independent software vendors, while D-SON is built-in to each small cell or macro node provided by the vendor. Both C-SON and D-SON will be needed if network operators are to roll out substantial numbers of small cells quickly and efficiently, especially when more tightly integrated into the network with residential femtocells.

Celcite is one of the handful of C-SON software solution vendors. Founded some 10 years ago, it has grown organically by 35% annually to 450 employees. With major customers in both North and South America, the company is expanding from 3G UMTS SON technology and is actively running trials with LTE C-SON.

Quite a few companies are claiming to be in the SON space, but Celcite would argue that there are perhaps only half a dozen with the capabilities for credible C-SON solutions today. Few companies can point to live deployments. As with most software systems, 90% of the issues arise when something goes wrong and it's those "corner cases" which take time to learn about and deal with from real-world deployment experience.

A major concern is termed "Runaway SON" where the system goes out of control and causes tremendous negative impact on the network. It's important to understand when to trigger SON command and when not to. This ability to orchestrate and issue configuration commands is critical for a safe, secure and effective solution.

Let me know your opinions via comments below.

How Cyber-Attacks Can Impact M2M Infrastructure

An Interesting presentation from Deutsche Telekom in the Network Security Conference which highlights some of the issues faced by the M2M infrastructure. With 500 Billion devices being predicted, security will have to be stepped up for the M2M infrastructures to work as expected. Complete presentation embedded below:

How Cyber-Attacks Can Impact M2M from Zahid Ghadialy

eIMTA: Enhanced Interference Mitigation & Traffic Adaptation

eIMTA is one of the features being discussed in 3GPP Rel-12. The pictures above and below provide the details.

As can be seen, at the moment all the eNodeB's associated with a network has to transmit the same UL/DL pattern throughout out the system. With eIMTA, each eNodeB can decide the UL/DL pattern itself depending on the load.

The main challenge would be interference management while using this scheme.

See also, this slideshare presentation for details:

White Paper: Dynamic TDD for LTE-a (eIMTA) and 5G from Eiko Seidel

Stress Testing of LTE devices

Another interesting presentation from R&S LTE Summit 2013 embedded below:

Stressing a LTE device with Typical User Behaviors from Zahid Ghadialy