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.