Tuesday, 30 October 2012

Quick summary of the 'Operator Mindshare' session from Small Cells Global Congress

We had quite a few interesting discussions in the Small Cells Global Congress, Operator Mindshare session. Here are some of the things that were discussed:

Licensed v/s Unlicensed deployments:
Many operators are now deploying WiFi in the unlicensed spectrum. This can help in the short term to alleviate the capacity problems but as more and more of this unlicensed spectrum nodes get deployed, they create interference between each other and make them unusable for anyone. An example was provided about Tokyo where in some areas, too many free WiFi hotspots means its unusable for anyone. One solution is to have one operator do all the logistics for the deployment and other operators can pay to use the service. Who (operator) would be the first one to go through the process of deploying everything first? Everyone would prefer wait and watch approach.

Providing free WiFi: 
The consensus was that the free WiFi provided by operators don't give any additional benefit to them and there isn't much of a business case. 

Consumer awareness for residential Femtocells:
Globally, not much effort is being done by the operator to make the end users aware of residential Femtocells and this is hampering the take-up  A point was made about when Vodafone launched their product, Vodafone Access Gateway (VAG), it was perceived as negative thing because the ads show that if the coverage was poor you can install this to improve coverage. From a users perspective, it showed that the network had poor coverage. Still consumer awareness is important, how to do it?

Placement of Small Cells:
Where should the public small cells (metrocells) be placed. The Biggest challenges are:
* Site Acquisition is the biggest problem. - This is a bigger problem if lap posts are sought to deploy on public locations
* Rent
* Planning
* Installation
* Power - Lamp posts are centrally switched off, so small cells on laamp posts may need alternative sources
* Power meter if used in a shared location
* Bullet proof (especially in the US)
* Backhaul - especially is non line of sight case.
* Health concerns (if visible)
* Visual appearance
* Opex

Operators should be clearer in what they want. Right now the vendors are pushing the solutions that operators not necessarily need and not giving what the operators want. The Backhaul should be more flexible and future proof. It should be able to cater for upcoming technologies like Carrier Aggregation, CoMP, etc.

Shared v/s Dedicated carrier for 3G Small Cells:
Dedicated carrier is ideal but is not easily possible for most operators. When shared carrier is used it causes interference and handovers are not easy. 

Interoperability in the new hardware equipment for support of small cells:
Certain vendors are still not creating the the networks that can interwork with other vendors equipment. As we are moving towards LTE, this seems to be a much bigger problem. Sprint for example has 3 completely different networks in the US with no interoperability between them. Standards are not helping either as they do not dictate implementation. 

Some Interesting discussions on Case studies, Business Cases, etc.

Mosaic Telecom:
* Deployed residential Femtocells
* Deployed for coverage purpose
* Dont have handover capability yet
* Want to be able to deploy Microcells/Small Cells on Highways, around 1-2Km radius
* Their typical Microcells use 40W output power
* The cost of deployment if Macro using cabinet, antenna, etc is roughly 100K per site.

Telefonica, O2 trials in UK
* To get access to council lamp posts, it was required that the bidder offer free WiFi
* O2 set a high bar by paying lot of money to the councils in London, but this is not a sustainable model

A Business case for carrier neutral WiFi on light pole in Lima, Peru
* Each light pole can have 3 different locations
* The retail business case is to get the user to usse the offering and maybe offer the operator services, tempting to move to this operator from current one
* There can be a wholesale case of selling the WiFi capacity in bulk to companies, organisations

Some interesting statistics thrown up:
* WiFi cell radius is 30m in South America
* 83% of people in US think that operators should provide free WiFi because of lousy coverage of the mobile network.
* The first 4000 customers of a WiMax operator were using an average of 750 MB per day, 22.5GB per month.
* Some fixed Internet operators are now thinking of putting a cap on unlimited offering at 350GB per month.

There were no consensus and conclusions for many items so feel free to write your opinion in the comments.

Sunday, 28 October 2012

Whats inside a Picocell?

Interesting pic from Public wireless:

• Intelligent Cell Control & Management Boards
  – Evolved OA&M for remote system management and monitoring
• Single/Multi Baseband Boards
• Digital Carrier Boards
• RF Chains / Power Amplifiers
• Various WAN Backhaul Modules
  – Wireline
    – Fiber, DOCSIS, Ethernet
  – Wireless
    – Satellite, NLOS, Microwave
• Power Supply + Battery Backup
• IP67 Outdoor thermal design

The presentation is available from Small Cell Forum website here.

Friday, 26 October 2012

Developing and Integrating a High Performance HetNet

I have seen on Twitter some people think that HetNets (Heterogeneous Networks) is just a new name for the Hierarchical Cell Structures (HCS). The main difference between then is that while HCS requires all layers to have different frequencies, HetNets can use the same or the different frequency. In case the same frequency is used, there needs to be a way to manage interference between the different layers. In fact the term 'layers' is hardly used with HetNets as there is nothing strictly hierarchical with different types of cells that co-exist in a HetNet. Typically a HetNet comprises of Macro cells, Micro/Pico cells, other Small Cells (including Femtocells) and WiFi as well (if used to offload traffic).

This recent whitepaper from 4G Americas is an excellent source to understand more about HetNets

Available to download from Slideshare here.

Thursday, 25 October 2012

Humour: 5 Stages of Bug Fixing

The above Dilbert strip is a reality for a lot of us, everyday. There are many bugs in each product and we only have a limited amount of time and resources that can be dedicated to fixing bugs. The '5 stages of bug fixing' was presented in one of the Cambridge Wireless events not long ago. I am not sure if allowed to mention by whom, so here it is anonymously.

The five stages of Bug Fixing

If you think about it from the Tester's point of view, this is what he prays for everyday. See the old post here.

Tuesday, 23 October 2012

Intelligent Devices and Smart Journeys

Couple of days back, I posted some videos that show technology advancements for the mobile phones. Here is a presentation by Peter Whale from Qualcomm in a recent Cambridge Wireless event about how Sensors and Context-engine will make the future devices much more intelligent then they already are.

A shameless plug for my presentation on the similar topic from the LTE World Summit 2012, that has now crossed 6000 views, available here.

Monday, 22 October 2012

M2M and the 'Big Data'

Couple of months back, there was this Dilbert strip on the big data.

Apparently, Social networks, M2M devices and many other sources of data, keeps on generating data all the time. This data can provide us with a lot of useful information if proper analytics can be done on it. This is a real challenge in guess. There will also be security and privacy implications that may decide how and what can be used and by whom.

Here is a simple introductory video by Intel explaining what Big Data is:

Tuesday, 16 October 2012

Extended Access Barring (EAB) in Release 11 to avoid MTC overload

M2M is going to be big. With the promise of 50 Billion devices by 2020, the networks are already worried about the overloading due to signalling by millions of devices occurring at any given time. To counter this, they have been working on avoiding overloading of the network for quite some time as blogged about here.

The feature to avoid this overload is known as Extended Access Barring (EAB). For E-UTRAN, in Rel-10, a partial solution was implemented and a much better solution has been implemented in Rel-11. For GERAN a solution was implemented in Rel-10. The following presentation gives a high level overview of EAB for E-UTRAN and GERAN.

In Rel-11, a new System Information Block (SIB 14) has been added that is used specifically for EAB. Whereas in Rel-10, the UE would still send the RRCConnectionRequest, in Rel-11, the UE does not even need to do that, thereby congesting the Random Access messages.

The following is from RRC 36.331 (2012-09)

–                SystemInformationBlockType14

The IE SystemInformationBlockType14 contains the EAB parameters.
SystemInformationBlockType14 information element

SystemInformationBlockType14-r11 ::= SEQUENCE {
    eab-Param-r11                        CHOICE {
       eab-Common-r11                       EAB-Config-r11,
       eab-PerPLMN-List-r11                 SEQUENCE (SIZE (1..6)) OF EAB-ConfigPLMN-r11
    }                                                  OPTIONAL, -- Need OR
    lateNonCriticalExtension             OCTET STRING          OPTIONAL, -- Need OP

EAB-ConfigPLMN-r11 ::=               SEQUENCE {
    eab-Config-r11                   EAB-Config-r11            OPTIONAL -- Need OR

EAB-Config-r11 ::=               SEQUENCE {
    eab-Category-r11                 ENUMERATED {a, b, c, spare},
    eab-BarringBitmap-r11            BIT STRING (SIZE (10))


SystemInformationBlockType14 field descriptions
Extended access class barring for AC 0-9. The first/ leftmost bit is for AC 0, the second bit is for AC 1, and so on.
Indicates the category of UEs for which EAB applies. Value a corresponds to all UEs, value b corresponds to the UEs that are neither in their HPLMN nor in a PLMN that is equivalent to it, and value c corresponds to the UEs that are neither in the PLMN listed as most preferred PLMN of the country where the UEs are roaming in the operator-defined PLMN selector list on the USIM, nor in their HPLMN nor in a PLMN that is equivalent to their HPLMN, see TS 22.011 [10].
The EAB parameters applicable for all PLMN(s).
The EAB parameters per PLMN, listed in the same order as the PLMN(s) occur in plmn-IdentityList in SystemInformationBlockType1.


Here is my attempt to explain the difference in overload control mechanism in Rel-8, Rel-10 and Rel-11. Please note that not actual message names are used.

As usual, happy to receive feedback, comments, suggestions, etc.