This phrase “Small is Beautiful” was popularised in the 1970s as a result of a set of essays on people-centred economics by E. F. Schumacher but it can also be applied to cells in mobile networks. As I have discussed before, one big challenge for cellular operators is the growth of mobile data – lots of it - driven by things such as the rise of social media such as Facebook, Twitter and YouTube; the massive growth in smartphone use; and the growing phenomenon of internet tablets. This creates a problem for current cellular networks – the more data you transmit the greater the potential interference to other devices close by, and the laws of physics limit how much data you can transmit in a piece of radio spectrum with a certain level of interference. So the problem’s big, but part of the answer is small.
Small – if you want to get that interference down, then get the phones to transmit at lower power by being a lot closer to the cell, and make the cell a lot smaller, cheaper and lower power in turn. Better still, make it a bit like a WiFi Access Point that can just plug into your DSL or cable modem at home. That way the signal can reach those hard-to-reach parts of the home that walls, terrain or limits to the locations of the large cells can limit good reception. And so the femtocell was born, with estimates of over a million deployed by various operators in the USA alone and the AT&T Microcell by Cisco and ip.access being one of the first deployed and numerous.
However, it’s important to remember that whilst small cells, and femtocells & picocells in particular, are a great disruptive technology, in the model that they are deployed right now they are neither an exact substitute for the macro network layer and nor do they come with all the bells and whistles of a macrocell (but they are a whole lot cheaper and more cost effective in extending the macro layer to offer better coverage, capacity and localised services), so it's important to remember the purpose for which they were designed.
Well engineered where they need to be
As an illustrative anecdote, arguably the most successful tank in the Second World War was the Soviet T-34 medium tank which was produced in large numbers for many years. It could not always match up one-to-one against the German heavy tanks it opposed, but was more agile and numerous. When a captured one was shown to the German leader, he criticised it as being poor because of the quality of its finish; however a tank general present privately noted that it was well-engineered where it needed to be and much cheaper to manufacture. “Well engineered where they need to be” is the philosophy adopted in small cell design.
A specific and more directly relevant example is the delivery of high speed 3G data from the terminal to the network using High Speed Uplink Packet Access (HSUPA). HSUPA is a shared multiple access channel and so subject to interference from other transmitting devices on the same cell, on neighbouring cells as well as underlying thermal noise. The successful delivery of the highest data rates across several users will depend on extracting the wanted signals from out of the combined signals received at the base station. There is a useful paper from Qualcomm about the best theoretical and practical ways of going about achieving this. A very good way to do this is to use a technique called Successive Interference Cancellation (SIC) where you first identify the largest wanted signal, estimate and decode it, then re-modulate it using the model of the channel determined, subtract from the original, and repeat as long as necessary. There are other reasonable methods that produce good results with less processing effort.
However, the SIC method does have a catch – the base station has to store up copies of the incoming signal as it is being worked on, and all the repetitions have to be completed before the next uplink frame arrives requring processing, and so we have significant demand for both memory and processing power in the base station. Femtocells and picocells are intended to be cheap and easily powered – some within the scope of Power over Ethernet (PoE) or USB – and so this is one area where the chipset suppliers have used the market requirements and made the pragmatic decision on what to enable.
I've spent the last 4 years working in the groups that have put together the standards for 3G and LTE femto and picocells (aka HNB, HeNB). From the initial 3GPP Release-8 release put together in a few months (and admittedly with a number of gaps in the rush to get it out in time) we're now on the 4th generation of these specifications and have gradually added features in to improve mobility and handover performance, and in the last release we added the ability to access and offload data in the home. So we've gone from this:
3GPP Release 10 Radio Access Network Architecture (source: 3GPP document)
The next logical step is to add an Iur link between the HNB GW and the HNB to complete the links between femto layers and macro layers by allowing handover and information exchange without going via the core network.
Why is this relevant to adopting a KISS approach? Standards engineers are naturally happy with more work in the pipeline and harmonising behaviour across the network. It's also clearly useful to be able roll out a feature in a small cell that is available in a macrocell if the situation is right - e.g. small cell concepts being used in metrocells of a few Watts power output where the expected behaviour, use case and experience is broadly the same as for a microcell and macrocell-enabled network. Such a deployment isn't going to be as simple as for the home or SOHO. However, for the generic supply of small cells, it then becomes necessary for the operator to ensure that they do not duplicate product requirements from their macrocells straight down to those for an indoor enterprise deployment say, or else the product then becomes much more expensive and less flexible as vendors have to develop custom platforms for a smaller market segment. In such cases everyone loses out.
So, small is beautiful, it's not the same as big, and remember why you started along the path in the first place.
Hi, At few ASR 9006 I have hardware like below: 0/RSP0/CPU0 A9K-RSP440-TR(Standby) IOS XR RUN PWR,NSHUT,MON0/RSP1/CPU0 A9K-RSP440-TR(Active) IOS XR RUN PWR,NSHUT,MON0/FT0/SP ASR-9006-FAN-V2 READY0/FT1/SP ASR-9006-FAN-V2 READY0/0/CPU0 A9K-MOD80-T...
Hey folks, I was trying to follow the configuration guide at: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipmulti_mvpn/configuration/12-2sx/imc-mvpn-12-2sx-book/imc_cfg_mc_vpn_sup.pdf on how to configure InterAS MVPN between PEs in di...
BGP flowspec in a nutshell is a feature that will allow you to receive IPv4/IPv6 traffic flow specification (source X, destination Y, protocol UDP, source port A .. etc) and actions that need to be taken on that traffic (drop, or polic...
Hello, In an ASR9006 platform with A9K-24X10GE-TR modules and image 6.4.2 I am unable to have a working SPAN port from a source subinterface. I'm using this configuration: !monitor-session capture ethernet destination in...
Hi, I want to implement the local policy based routing feature on IOS XR, with IOS it was basically done by matching certain destination traffic and management-protocols with access-lists and then assigning for example a QOS marking to them. (this ge...