HSUPA scheduler, a closer look

In any shared access scheme, the scheduler is key to the performance of the system. Here we take a closer look at a HSUPA (a.k.a. EUL) scheduler and how it functions in practice. With HSUPA the shared resource the scheduler has to control is the uplink interference. This is done via the Serving Grant (SG) concept, where a SG is translated into a particular power ratio (relative to the DPCCH). From a UE point of view this is further translated into a particular data rate. The above is a fairly simplistic explanation, for those interested there is a lot more detail in books, the web and the specs.

In terms of the graph then (click to enlarge), this represents a speedtest on a HSUPA capable live network. The Y axis is kilobits and the X axis is time.

The measured variables are:

Available Power Throughput represents a theoretical maximum throughput the UE could achieve with the power headroom it currently has. Limited by max TB for 10ms TTI (14480) in this case.

Serving Grant Throughput  represents a theoretical maximum throughput the UE could achieve with the SG it currently has. This also represents the tolerable UL interference the nodeB can expect from the UE.

Actual Throughput this how much the UE is actually transmitting based on the above and the data it has in the buffer.

Bearing the above in mind we can split the graph in 3 distinct areas:

Region A

Power headroom allows for the maximum possible throughput with 10ms TTI. Serving Grant allocated is limiting throughput to a maximum possible of approx. 550kbps. Actual throughput is only around 100Kbps however due to data in the buffer. Sub-optimal utilisation. (Note: this region is also the part of the speedtest where the DL was tested. Hence the UL throughput is low as it is just ACKs/NACKs at the application layer)

Region B

Power, Serving Grant and Actual Throughput, peak at the maximum for 10ms TTI. Optimal utilisation. (Note: this region is also the part of the speedtest where the UL was tested)

Region C

Serving Grant remains at the maximum, but the UE becomes power limited and hence the actual throughput drops. Sub-optimal utilisation. (Note: this region is also the part of the speedtest where the UL was tested)

So from scheduler perspective, what could be done differently? How could we have optimal utilisation in all areas? The answer lies in the making use of the scheduling information the UE can provide as part of the MAC layer. Specifically the Uplink Power Headroom (UPH) and the Total E-DCH Buffer Status (TEBS). By using the TEBS reporting better the utilisation in region A could be improved. By using the UPH reporting better the utilisation in region C could be improved. 

4G RACH optimisation through SON

The scope of LTE SON (Self Optimising Network) is vast and although reading through the standard might make one think that images like the one above are a thing of the past, what vendors offer and operators deploy today is fairly limited. The one that is very obvious in use is ANR (Automatic Neighbour Relations) and true to its name it has made neighbour planning a thing of the past in LTE deployments.

I was recently looking through some air interface logs of one UK operator and I was pleasantly surprised to see one more SON feature in use, namely RACH reporting. RACH performance historically has relied on drive testing to quantify, as a failed procedure is not recorded by the network. With RACH reporting the UE (if supported) can be requested to report how many preambles it used to access the network and if it encountered any contention. In a simple solution this information could simply be recorded statistically for an operator to look at, or for a full SON solution the requested preamble power could be adjusted (either way depending if UEs are reporting too many preambles or too few) or more RACH signatures could be assigned if contention is widely reported (typically the signature pool is statically split between contention based and contention free usage) or some other relevant parameter based change could be automatically triggered.

The procedure itself starts with the UE reporting its support as shown below (click to expand).

The network can then request from the UE to report on the result of the RACH procedure through the UE information request procedure as shown below.

Finally the UE reports the result in the UE Information Response message. In this particular example, two preambles had to be sent as the result of the first one was met with contention.

A simple solution, to an age old mobile network problem. Quite good..

Small cells out in the open

As mentioned in previous posts I am a big fan of small cells/femto cells, so it was great to see Vodafone in the UK using the product in a novel way. Essentially they are deploying these in small rural communities with no existing macro coverage, but rather that the more typical operator led installation, they are asking rural communities to contact them and also provide the physical locations for installation and the necessary broadband connectivity. So all Vodafone have to do, is turn up mount the product on a chimney/wall/post and off you go. There is lots more detail here.

These small cells typically radiate around 1W, as compared to the 20-30W of a typical macro base station and can handle around 32 connected users. They are also self configuring (cell ID, PSC, neighbour detection) so require very little or no planning.

Small cells become a lot more interesting (and complicated) when they are deployed in the presence of a macro (so called HetNets), but even so the above story is still very interesting and encouraging to see.

XLTE & the marketing side of technology

I was recently reading about Verizon's "XLTE" and it got me thinking about the marketing side of technology and specifically mobile technology.

Essentially XLTE is not a new technology, it is just Verizon's deployment of LTE over 20MHz of spectrum. This is something many other countries have deployed from day one, but in the US it has become a big marketing deal. I imagine Verizon paid a lot of money for that additional spectrum and quite a lot to upgrade eNodeBs and antennas, so in order to get a return of investment a big marketing campaign was put into place. But how do you market 20MHz of spectrum? Here in the UK, EE has marketed it as "double speed" (double as their initial deployment was over 10MHz). But I guess that is quite boring. "XLTE" sounds much better.

All this of course is not new. To my recollection, it started with HSDPA. How do you market HSDPA? Surely not as High Speed Downlink Packet Access. A few terms appeared, there was 3G+, 3.5G, Super 3G, Turbo 3G. As HSDPA evolved, we also had HSDPA+ and some operators even called it 4G!

What about WB-AMR? "Do you want a phone that supports Wide Band Adaptive Multi Rate Sir?" Probably not. HD Voice however sounds great.

Needless to say, this will continue. LTE Advanced with Carrier Aggregation is just around the corner (actually launched already in Korea). So, XXXLTE maybe? 4.5G? 5G even? Let's see..

Optimal spectrum refarming for LTE

When looking to refarm some spectrum for LTE (e.g. 1800MHz spectrum from GSM) the following simple approach will lead to optimal results.

Start by thinking of how much spectrum you would ideally refarm. This will typically be 20MHz. Assuming this was possible pick the centre frequency for this allocation. This will be your EARFCN. Then look at how much spectrum you can actually refarm. This will typically be less, as the traffic on the legacy RAT might not have reduced enough or frequency re-planning your whole legacy network will take time. Most operators go for 10MHz, but in some cases 5MHz is also used.

Deploy your network.

After some time has passed and more spectrum is available, keep the centre frequency the same and just expand the bandwidth. Some cells might be using 10MHz, some 15MHz or 20MHz but because the centre frequency has not changed, all mobility can be intra-frequency. No need for inter-frequency handovers, no need for additional neighbour planning, no need for measurement gaps, no need for additional SIBs being broadcasted. UEs will seamlesly reselect & handover taking into account the used bandwidth every time as this is broadcasted in the MIB which is read in idle mode and after every handover.

Although the above might sound like the obvious way of doing things, both EE in the UK (see here) and other LTE deployments (see here) don't follow this but rather offset their two bandwidth allocations leading to needless inter-frequency mobility.

PRACH preamble power considerations in LTE

Unlike UMTS, the PRACH in LTE is used only for the transmission of random access preambles. These are used when the UE wants to access the system from RRC idle, as part of the RRC re-establishment procedure following a radio link failure, during handover or when it finds itself out of sync.

As part of the PRACH procedure the UE needs to determine the power to use for the transmission of the preamble and for this it looks at SIB2 for the preambleInitialReceivedTargetPower IE. As shown from the extract above (taken from a live network) this is expressed in the dBm and in this specific case it is set to -104dBm. So this is the expected power level of the PRACH preamble when it reaches the eNodeB.

What is also broadcasted is the reference signal power, which in our case is set to 18dBm. Based on this and a current measurement of the RSRP, the UE can determine the pathloss. Once it knows the pathloss it can then determine how much power it needs to allocate the PRACH preamble to reach the enodeB at -104dBm.

So lets say that the UE measures an RSRP of -80dBm. Based on the broadcasted reference signal power it can calculate the pathloss, PL = 18 - (-80) = 98dB. This means that for a preamble to reach the eNodeB at -104dBm it needs to be transmitted at PPRACH = -104 + 98 = -6dBm. That is fine.

But what happens if we consider other values of RSRP? For example cell edge? Cell edge can be determined by the value of the qRxLevMin. Looking at SIB1 from the same network we can see that this is set to -128dBm (IE x 2). 

So at an RSRP of -128dBm the pathloss is PL = 18 - (-126) = 144dB. So the UE needs to transmit the preamble at PPRACH = -104 + 144 = 40dBm. Is this ok? Actually no, as LTE UEs are only capable of transmitting at a maximum power of 23dBm. Does this mean the UE does not even go through the PRACH procedure? No, but it will be limited to transmitting at 23dBm meaning that the preamble will reach the eNodeB at - 121dBm, which means that the probability of a successful detection is very low.

In actual fact based on this network we can say that anywhere in the cell where the RSRP is below -109dBm will lead to a power limited PRACH attempt and a lower probability of detection. This is something to think about next time your LTE signal strength is low and your phone seems unresponsive..

3.2Mbps @ 2003? I don't think so..

Three UK have put up the above graphic on their website, here, depicting their network evolution from a throughput point of view.

It is quite nice to look at but was 3.2Mbps possible in 2003? I don't think so, as at that time only R99 networks were available and the max throughput was 384kbps. This was only increased with the first HSDPA networks in 2005 and even then speeds were limited to 1.8Mbps (category 12 devices).

Let's see how long it takes for them to correct this.. :)

Deep dive into commercial LTE networks

I was recently in Greece and took the opportunity to have a closer look at two commercial LTE networks in order to understand what capability and configuration operators are using in the field.

The networks in question were Cosmote and Vodafone. Cosmote has launched 4G since around November 2012, initially limited to PS devices (dongles, Mi-Fi etc) and later on added support for smartphones. Vodafone has had a very limited LTE offering since the end of 2012 also limited to PS devices, but has also since expanded its LTE network and added support for smartphones.

Spectrum:
Both operators are using re-farmed 1800MHz spectrum to support 4G services. Each operator seems to have re-farmed 20MHz of spectrum which is split into a 10MHz block and a overlapping 20MHz block. In busy/important areas the 20MHz block is used in other areas the 10MHz block. Obviously as the spectrum is overlapping the two blocks cannot be used in the same geographic area. Details are shown below.

Vendors:
Vendor details are not usually shared in the public domain although occasionally certain vendors/operators do make announcements about awarded contracts. In this particular case I could not find any announcements in the public domain but what I call "L3 signatures" indicate that Vodafone are using Huawei EUTRAN while Cosmote uses NSN.

Idle Mode Selection/re-selection:
Unlike 3G which uses both a quality (Qqualmin) and signal strength (Qrxlevmin) selection criterion, LTE only uses signal strength (at least in rel8). Vodafone have configured their Qrxlevmin to -128dBm RSRP while Cosmote uses -130dBm. Although the standard allows for up to -140dBm, both of these values can be considered quite low. The obvious benefit is that UEs stay in LTE for longer, the obvious question is what is performance like (especially in the uplink) at such low RSRP values?

Specifically to intra-frequency cell re-selection Vodafone UEs start searching when the RSRP is equal or less than -68dBm. They perform the reselection if the neighbour cell is 4dB stronger.

Cosmote UEs start searching when the RSRP is equal or less than -68dBm as well but perform the reselection if the neighbour cell is 2dB stronger.

From an inter-frequency (not applicable for these networks) and IRAT re-selection point of view, LTE uses priorities similar to HCS. The configured priorities are shown below. As can be expected 4G has the highest priority followed by 3G and finally 2G.

Vodafone UEs will start measuring lower priority RATs at -118dBm and reselect when the serving cell RSRP falls below -128dBm.
Cosmote UEs will start measuring lower priority RATs at -124dBm and reselect at the same threshold.

Intra-frequency mobility:
Intra-frequency mobility in LTE is governed by event A3. A comparison of the A3 configuration for each operator is shown below.

 a3-offset is IE x 0.5dB so Vodafone trigger a HO when the neighbour cell is a3-offset + hysteresis stronger, which equates to 3dB. Cosmote also trigger a HO at 3dB however they don't make use of the hysteresis.

Connected mode IRAT mobility:
Both operators use event A2 to trigger IRAT mobility actions. The mobility mechanism itself is through an RRC connection release with redirect (PS handover is not supported). Vodafone use a measurement based approach. Two A2 thresholds are defined. The first at -120dBm RSRP triggers measurements against 3G & 2G neighbour cells. Depending on what is detected by the UE the appropriate re-direct RAT is selected. The second A2 threshold at -126dBm, is used to trigger a blind redirect to 3G directly. This is used when the UE does not report anything back following the first A2 event.

Cosmote on the other hand only use the blind re-direct and the UE is always re-directed to 3G at -124dBm RSRP.

CSFB:
Both operators use "basic" CSFB (i.e no DMCR, no SIB tunneling) to 3G (2100MHz band).
Interestingly enough, Cosmote use a CSFB inter-working function as described here. Although this eliminates any TAC to LAC planning it does create an additional call setup delay as shown from the measurements below.

RRC connection management:
The RRC state machine in 4G is very simple as only two states are defined. Idle and Connected. To transition from RRC_CONNECTED to RRC_IDLE Vodafone use a 5s inactivity timer while Cosmote use a 30s inactivity timer. It can be expected that 5s lead to an increase in signalling while 30s will impact battery life (assuming connected mode DRX is shorter than idle mode DRX which in this case it is).

That is it, quite an interesting deep dive into commercial LTE deployments and it also establishes something of a baseline for other networks I look at.

A breath of fresh 4G air

Today was a "historic" day for 4G in the UK. After almost 11 months of 4G monopoly by EE, two more operators, O2 and Vodafone, launched 4G services. But considering their tariffs are high and their coverage is poor, that is not what I wanted to talk about.

What drew my attention today is the announcement from Three UK, the smallest of the 4 operators and the undisputed disruptor in the otherwise stale UK market that described the terms of their 4G offering due in December this year.

I quote "..Every customer with a 4G ready device will get a 4G upgrade at no extra cost, with no need to go to a store, no need for a new contract, Sim or tariff change. The All You Can Eat data offering will still be available on 4G".

Now, that is the way to launch 4G in my opinion. Why spend millions upgrading your network to 4G only to then apply such high tariffs that nobody uses it? In today's smartphone world every operators 3G network is heavily overloaded so it makes perfect sense to me to offer 4G as an extension to someones data contract and not charge extra for it. That means you are getting a return of investment and you are also improving the customer experience on 3G by offloading data traffic from it and thus reducing churn.

LTE contracts by vendor

A few days ago I came across an interesting article that lists the proportion of LTE contracts awarded by vendor worldwide (as of August 2013). The source is Informa Telecoms & Media and according to them the data has been verified by the vendors themselves.

Clearly two companies, Chinese Huawei and Swedish Ericsson dominate the market with Huawei at a slight advantage. Third is NSN followed by "Other" which inlcudes Samsung, Alcatel Lucent and ZTE. Of these Samsung and ZTE can be considered developing, while Alcatel Lucent seems a shadow of its former self.

I guess what this article fails to mention is the scale of these contracts. From that perspective Ericsson would definitely be ahead as it has secured big contracts in the US, Korea & Japan where the vast majority of LTE users and traffic is today (approx 85% according to some recent stats published by the GSMA). Huawei on the other hand is pretty much banned from the US so that doesn't help either.

The full article can be found here

VoLTE checklist

Had enough of CSFB call set up delays, delays in returning to LTE after voice call termination, additional signalling due to routing/location/tracking area updates?

Time to deploy VoLTE!

Here is my checklist to get things started..

1. An IMS network

2. UEs that support VoLTE

3. Support for QCI 1 (voice) and 5 (IMS signalling)

4. Support of QoS on your LTE network to prioritise QCI 1 & 5 and pre-empt other QCIs if needed

5. Semi-persistent scheduling so you don't run out of PDCCH capacity

6. Support for RoHC

7. A dropped call rate on LTE equal or better than the CS dropped call rate on the legacy network

8. Support for RRC Re-establishment (intra & inter eNodeB) to help with the above

10. Support for TTI bundling to improve cell edge performance

11. If your LTE coverage is not as good as the legacy network then SRVCC support to handover calls from LTE VoLTE to the legacy CS domain

12. Upgrade legacy MSCs to connect to IMS

13. Upgrade legacy MSCs to connect to MME via Sv interface

14. UE battery life in LTE equal or better than 3G

Easy :)

4GEE bandwidth now @ 20MHz

Back in October when EE launched their 4G network I wrote a post on their spectrum usage at the time (here). As recently announced by EE themselves they have now manage to re-farm another 10MHz block from their 1800MHz spectrum and thus offer LTE at the maximum 3GPP rel8 bandwidth of 20MHz.

As can be seen from the SIB19 extract below their new 20MHz EARFCN is 1667. This effectively extends the original 1617 EARFCN by 10MHz to the right of the 1800MHz spectrum allocation.

By defining both carriers in SIB19 they don't need to constantly update their 3G network as the 20MHz roll-out continues, as UEs will scan both centre frequencies and pick the one available to reselect to.

From a device perspective all LTE capable UEs must support 20MHz bandwidth so they all take advantage of the additional capacity.

Next step for EE is 3GPP rel10 carrier aggregation, which they announced they are looking into and will take advantage of their additional spectrum assets in the 800MHz and 2600MHz bands.

How safe is your network?

I was recently watching a video on youtube about GSM hacking (here) and it got me thinking, how safe are GSM networks and what can operators do to make them safer?

The first thing I looked at was the actual encryption algorithm itself. This is typically termed A5/X as there are a few different variants. A5/1 is the original encryption algorithm. A5/2 is a deliberate weakened version developed at a time when the standardisation community did not want to pass on the details of the A5/1 to certain non-trusted countries. A5/3 is the stronger version of A5/1. Finally A5/4 was recently introduced which is even stronger but still at its infancy in terms of support on UEs and deployment in live networks. So of all these options A5/3 sounds like the right choice to encrypt your voice calls. Right? Lets see..

First of all we need a device that supports A5/3. Even though the encryption algorithm has been around for a while, a lot of device manufacturers deliberately disable it. For the purposes of our testing I found a device that actually supported it as shown below.

Next we just need to make some voice calls and see which encryption algorithm the network instructs the device to use. The actual encryption is initiated via the RRC Ciphering Mode Command as shown below.

As can be seen the algorithm identity selected is 0. Looking at 3GPP TS 44.018 we find the table below which indicates that algorithm 0 equates to the older & and easier to crack A5/1. All 4 networks tested used A5/1.

The second thing to look at is how often is the ciphering key (termed Kc) is renewed. Obviously reusing the same key is bad practice and the ideal situation is to use a different cipher key for every call. The cipher key is generated by algorithm A8 using the RAND number and the individual subscriber key Ki. Ki resides in the SIM and RAND is sent via the Authentication procedure. It follows that in order to generate a new ciphering key Kc, the user needs to be re-authenticated. So how often does this happen?

Looking at operator 1, the same cipher key is re-used 7 times as shown below (only the messages of interest are shown and the rest are filtered).

Operator 2, seemed to have some random pattern of re-authenticating. This could be as low as once per call, but on other occasions the same cipher key was re-used 15 times.

Operator 3 had a regular pattern, re-using the same cipher key 15 times.

Finally operator 4 was the best of all re-using the same cipher key 5 times.

From an operators point of view of course, re-authenticating the user generates signalling load on the core network as the MSC/VLR has to fetch authentication triplets from the Authentication Centre. This explains why some operators are more or less generous with their cipher keys.

So what can you do as a subscriber to better protect yourself? Unless you have a trace tool, figuring out what ciphering algorithm your operator uses and how often the ciphering key changes is not something easy to find as operators do not make this information public. An easier choice would be to use the 3G network for your voice calls which means having a 3G device and finding a network that provides adequate 3G coverage. If you are are "brave" enough you could even lock you device to 3G only to prevent any accidental wandering to the 2G network. To date, to my knowledge, there have been no documented successful attacks on 3G networks.

Spectrum for rent, with a twist

At the recent auctions for 800MHz & 2600MHz spectrum here in the UK, a company by the name of Niche Spectrum Ventures Ltd (a subsidiary of BT) won 2x15MHz of FDD and 10MHz of TDD. 

There has been a lot of speculation about how a company that does not own a mobile infrastructure could use such spectrum and the conclusion is usually a) they build a network from scratch or b) they re-sell or lease the spectrum to an existing mobile operator.

However another business model I have been thinking of is a lot more interesting and it goes something like this..

A company wins some spectrum. It purchases and installs LTE small cells in key locations. These are fairly cheap and easy to install. If that company has transport network assets (like BT) then all the better. Once the small cells are installed and connected to an IP backbone, the company sells access to existing mobile operators. They way it does this is via MOCN (Multi Operator Core Network) functionality. For each customer that signs up their PLMN ID is broadcasted by the small cell and their core network is connected to the IP backbone. The specs allow for up to 6 PLMNs to be broadcasted so potentially all the existing mobile operators could be customers. What about the interworking of the LTE small cells with the existing network of the customer? Well, LTE has a raft of SON features that can take care of all of that with the minimum of manual intervention.  For neighbour planning the ANR feature can take care of that. This will work for intra-freq LTE, inter-freq LTE and IRAT. All it takes is for some UEs to camp on the small cell and send some measurement reports. PCI planning can also be automated as is RACH planning. As the core network is owned by the incumbent mobile operators do they have to do anything? Well not much. The S1 setup procedure takes care of that as it allows the MME and eNodeB to exchange the information they require to interwork. Finally from a UE perspective, MOCN functionality is mandatory in LTE so UE support is guaranteed.

As the company only owns radio network assets the management of the network is fairly simple as everything else (core network, billing, subscriber management etc) belongs to the mobile network operators.

That is it. All it takes is a commercial agreement, the PLMN ID of the customer and some minimal configuration.

CELL_FACH to LTE reselection in 3GPP release 11

Just to keep everybody on their toes it seems the wise people at 3GPP decided to introduce mobility from 3G CELL_FACH to LTE from release 11 onwards. As the figure above shows (TS 36.331), that all important arrow from CELL_FACH to E-UTRA RRC_IDLE has been introduced. Why it was not included  in the first place is still a mystery to me as from a UE complexity point of view I wouldn't have thought it would be that difficult. From a RAN point of view it just re-uses the FACH measurement occasion concept defined since release 99 that allows a UE to search for inter frequency and IRAT neighbours during specific time intervals when it knows the RAN will not send it any data on the SCCPCH.

In addition to the above, SIB19 on 3G has some changes as the operator can choose if all EARFCNs will be searched for or only the higher priority ones (if applicable).

Although CELL_FACH can be thought of as a transient state it is possible that a UE can stay there long depending on RNC inactivity timers and keep alive periodicity from applications on the UE. With this change then the possibility of being "stuck" in 3G is minimised.

Base station in disguise, gone wrong..

One of issues faced with operators around the world is getting planning permission for base stations. At least here in the UK, one of the most common designs is the base station disguised as a lamp post. They usually blend in nicely, the public don't even notice them and some even have a functioning lamp so they serve a practical purpose besides housing an antenna.

Sometimes however things go wrong as the photograph above shows. I wonder how many people notice that it is a bit strange to have two lamp posts separated by 1 metre. Clearly the traditional lamp post should be removed but I guess someone got a bit lazy.. 

Small Cells, Big Impact (my version)

I was reading the now few month old announcement from AT&T around small cell strategy here and a few things came to mind. First, the story. AT&T announced back at the end of January that they were planning to roll-out 40,000 small cells by the end of 2015. They have also posted a video on the link above that shows one of the products they are trialing, which although the logo is purposefully out of focus can easily be identified as the Alcatel Lucent 9364 Metro Cell described here. The video also mentions that AT&Ts plan is to roll these out to improve coverage which is where an important distinction in my opinion has to be made.

Small cells can be used for two scenarios. Scenario 1: Not spot. Scenario 2: Hot spot.

Scenario 1 is the easier of the two and the one AT&T has opted for. Regardless of how much an operator can try some areas will always suffer from poor/no coverage. Once these areas are identified a small cell can easily be installed to provide coverage. Small cells due to their femto background are easily deployed, mostly auto-configure and require just a backhaul connection which can be of xDSL nature. Due to their small size they are also usually exempt from the usual painful planning permission process.

Scenario 2 is the more difficult one. Here there is macro coverage, but due to the high amount of traffic the macro network cannot cope. The solution? Either try to use Wi-Fi offload (with the problems described in my previous post here) or use a small cell to absorb some of the traffic. However placing a small cell among large powerful macro cells is not as easy as some people make. At best the range of the small cell is severely interference limited and at worst it acts as a noise source affecting macro network performance. In addition to this UE uplink power can interfere with the small cell when power controlled by a macro cell further away. The solution to these problems is the new industry buzz word "HetNets" (Heterogeneous Networks). But what does Heterogenous mean anyway?

heterogeneous [ˌhɛtərəʊˈdʒiːnɪəs]adj

1. composed of unrelated or differing parts or elements

2. not of the same kind or type

When it comes to mobile telecoms, HetNets is essentially an umbrela term to descibe a number of features (some standardised and some not) that allow nodes of different types (macro cells, small cells etc) to co-exist. To date most of it is theoretical or simulation based so it is too soon to draw any conclusions as to how well HetNets will perform.

Another thing to bear in mind is that HetNets require close co-operation between the small cell and the macro cells which is where the small cells from a femto background might face some problems due to their flat architecture (combined RNC/nodeB) which essentially makes interactions between small cell and macro cell inter-RNC based. Traditional macro cell vendors have recognised this opportunity, which is why most of them are introducing small cells in their product portfolio.

All is not lost though, as vendors from a femto background already have a lot of experience in interference mitigation techniques and also auto configuration which when dealing with a large number of cells is a strong requirement.

It also worth remembering that LTE is based on a flat architecture so any advantages traditional macro vendors have might be short lived.

So, it will be interesting to see which small cells are the eventual winners. Will it be the enhanced femto cells or the miniaturised macro cells?

Nokia 6150, thirteen years on

When I started working in the mobile telecoms industry back in 2000, my employer at the time gave me a Nokia 6150. It was my first mobile phone and I loved it. At the time Nokia was the dominant force in mobile handsets and the 6150 was regarded as a top end device. Apple on the other hand in 2000 was purely focused on computers, launching products such as the Power Mac G4 and the iBook.

As time passed I got other mobiles and sold off the Nokia 6150. A few days ago however in a fit of nostalgia I went on eBay and purchased another 6150. A couple of days later I had in my hands and the rubbery keys felt instantly familiar. As I powered it on to make that first call, it got me thinking how much things have changed in the past 13 years..

So let's see. The Nokia 6150 supports GSM. That is it. No GPRS, no EDGE, no 3G, no HSDPA, no HSUPA, no HSPA+. Life was simple back then. Just GSM. The 6150 was dual band so it supported GSM in the 900MHz (no E-GSM though) and  the 1800MHz band. This at the time was quite a revolution. It also supported SMS, but only to a maximum of 160 characters, no concatenation. For data, it supported CSD (Circuit Switched Data) which essentially was a dial-up modem at an amazing speed of 9.6kbps! From a codec perspective it suppoted Full Rate, Half Rate and Enhanced Full Rate. No AMR obviously. Looking further into its capabilities it also supports the A5/2 cipher algorithm which has since been removed as a ciphering option by the GSMA.

Fast forward 13 years and the mobile telecoms industry has completely changed. But GSM networks are still around and are still backwards compatible as my Nokia 6150 works perfectly. I guess this is testament to those people in ETSI who developed GSM.

Comparing the Nokia 6150 to my current mobile, an iPhone 4, is obviously an unfair comparison but one thing has not changed...

The weight. They both weigh 140gr!

CSFB alternative using E-UTRA detection

Traditional LTE deployments, set the LTE carrier(s) at a higher priority than the 3G carrier(s) thus ensuring the UE will always camp on the LTE carrier when present. Any voice calls are handled by CSFB with an associated delay in call set-up and a few signalling issues as described in previous posts.

I have recently been thinking of the IE eutraDetection as broadcasted in SIB19 on 3G (shown above) and an alternative approach to CSFB came to mind..

First let's look at how the IE eutraDetection is described in the specifications. The applicable document is TS 25.331 and the description is given as:

Furthermore section 8.6.2.5 provides this additional information "If the IE E-UTRA detection is included in a received message and set to TRUE and the UE is in CELL_PCH, URA_PCH state or idle mode, the UE may detect the presence of a E-UTRA cell on a frequency with a priority lower than the current UTRA cell and report the information to the NAS."

Taking the above into consideration the alternative to CSFB would be to set the LTE carrier(s) at a lower priority thus ensuring the UE camps on the 3G carrier(s). By setting the IE E-UTRA detection to TRUE the UE will display the 4G icon on the screen as that is passed on to the NAS layer. This will ensure the customer is happy as for all he/she knows they are camped on the 4G network.

Any voice calls would be set up on the 3G carrier directly without the need for CSFB and avoiding any call set-up delays. If on the other hand the UE wanted to establish a data session the RNC would trigger a re-direct or handover to 4G. Once the UE would finish with the data transfer it would reselect back to 3G but still display the 4G icon as before. So in essence the opposite of CSFB can be created, which could be termed PSFB :)

One problem with this approach is that UEs, especially smartphones, are prone to many small bursts of data, so these could be handled on the 3G layer and use a traffic volume measurement report to trigger the redirect  to 4G for larger data transfers. At the same time ISR (Inter-system Signalling Reduction) could be used to minimise the signalling when moving between the 3G and 4G networks.

So that is it, some small development needed on the RNC SW and PSFB could become reality..

The issues with Wi-Fi offloading

Thinking about how my data consumption has changed over the past ten years, it is quite clear that it has increased at an enormous rate. Where ten years ago I was happy with some email and static web pages, today there is video content embedded everywhere, web pages are dynamic, flash based content, streaming, VoIP, attachments, the "Cloud", synching etc, etc. Either consciously or subconsciously this is true for most people and most people want to access all this on the go.

Mobile networks have obviously evolved over the last ten years to cater for this, and the 3GPP is continously working to improve the standard to allow for faster throughputs but more importantly more efficient networks.

Sometimes however either because site density is not adequate, spectrum is not enough, or networks are not configured properly, things come a grinding slow stop which is where "Wi-Fi offloading" comes into play.

As a quick search on Google will show, Wi-Fi offloading is presented as the solution to the problem (the cynic might say this mostly comes from Wi-Fi AP manufacturers) and quite a few operators have either partnered with Wi-Fi network operators or deployed their own networks, in the hope of offloading some traffic from the cellular network.

But does this really work? The biggest problem with Wi-Fi is obviously the fact that it uses shared spectrum. How big a problem is this? Well, a quick scan of the available Wi-Fi networks, as shown in the picture above, will quickly put things into perspective. Sitting at home I could pick out 17 access points of considerable strength, all fighting for the coveted non-overlaping channels. There were even two double bandwidth 802.11n APs spreading themselves over 40MHz. So QoS is obviously an issue here, as all of these uncontrolled access points can appear anywhere, anytime ready to interfere with your "offloading".

So even though Wi-Fi might be available, it is possible that the user experience on the cellular network is much better. This is something people in the industry are aware of and it was interesting to see that for a while even Apple were thinking of switching from Wi-Fi to cellular when things get bad. This screenshot below taken from iOS 6 beta shows this, but for reasons unknown it never made it into the official release (for now).

There are interference mitigation techniques of course, ranging from switching channels (not good if they are all congested) to using various smart antenna techniques (beamforming etc) to try to improve things. I have no personal experience of these, but of course these will come at a cost and with a few caveats.

Furthermore there is always the problem of seemless mobility between Wi-Fi and cellular which even though various solutions have been put forward for it, none have made it into the mainstream yet.

So it seems the only positive aspect of Wi-Fi offloading might be that it is free to use, but then of course that creates another problem for the operator as there is no return in investment.

This then is where the industry has started thinking about "small cells" and another story begins..