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.