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..

Combined (3G & 2G) Compressed Mode Patterns

Key functionality in WCDMA is the use of compressed mode which creates measurement gaps that allow the UE to measure either 2G or 3G inter-frequency neighbours. Typically most UTRAN implementations restrict the usage of compressed mode to either 2G measurements or 3G inter-frequency measurements.

As almost all 3G network deployments today utilise multiple 3G FDD carriers, the operator has to make a choice. When radio conditions deteriorate, should traffic be handed over to another 3G FDD carrier or to 2G? Handing over to 2G is often seen as the safe choice to make, but why re-direct traffic to 2G when potentially other 3G carriers of good radio quality exist?

This problem can be solved by the use of combined (3G & 2G) compressed mode patterns, which is what I recently observed on a live network. With combined compressed mode patterns the UE is asked to measure both 2G and 3G inter-frequency neighbours at the same time. Based on the measurement reports received the RNC can then decide to which layer to handover the UE to (with an obvious preference to 3G if possible). The RRC signalling flow can be seen below (click to enlarge).

The procedure is initiated by the UE sending a  MEASUREMENT REPORT for event 2d (estimated quality of used frequency is below a certain threshold). The RNC responds by sending a PHYSICAL CHANNEL RECONFIGURATION message which configures the compressed mode patterns. The UE accepts these and then two MEASUREMENT CONTROL messages are sent. The first provides a 3G neighbour list for the UE to measure (and activates the compressed mode patterns) and the second provides the 2G neighbour list for the UE to measure. Following this the UE starts sending periodic MEASUREMENT REPORTS (separate ones for 2G & 3G) indicating which (if any) neighbours it has detected.

An extract of the PHYSICAL CHANNEL RECONFIGURATION message is provided below.

dpch-CompressedModeInfo
                            {
                              tgp-SequenceList
                              {
                                {
                                  tgpsi 2,
                                  tgps-Status deactivate : NULL,
                                  tgps-ConfigurationParams
                                  {
                                    tgmp gsm-CarrierRSSIMeasurement,
                                    tgprc 0,
                                    tgsn 4,
                                    tgl1 7,
                                    tgd 270,
                                    tgpl1 8,
                                    rpp mode1,
                                    itp mode0,
                                    ul-DL-Mode ul-and-dl :
                                      {
                                        ul sf-2,
                                        dl sf-2
                                      },
                                    dl-FrameType dl-FrameTypeA,
                                    deltaSIR1 12,
                                    deltaSIRAfter1 6
                                  }
                                },
                                {
                                  tgpsi 3,
                                  tgps-Status deactivate : NULL,
                                  tgps-ConfigurationParams
                                  {
                                    tgmp gsm-initialBSICIdentification,
                                    tgprc 0,
                                    tgsn 4,
                                    tgl1 7,
                                    tgd 270,
                                    tgpl1 8,
                                    rpp mode1,
                                    itp mode0,
                                    ul-DL-Mode ul-and-dl :
                                      {
                                        ul sf-2,
                                        dl sf-2
                                      },
                                    dl-FrameType dl-FrameTypeA,
                                    deltaSIR1 12,
                                    deltaSIRAfter1 6,
                                    nidentifyAbort 66
                                  }
                                },
                                {
                                  tgpsi 1,
                                  tgps-Status deactivate : NULL,
                                  tgps-ConfigurationParams
                                  {
                                    tgmp fdd-Measurement,
                                    tgprc 0,
                                    tgsn 4,
                                    tgl1 7,
                                    tgd 270,
                                    tgpl1 8,
                                    rpp mode1,
                                    itp mode0,
                                    ul-DL-Mode ul-and-dl :
                                      {
                                        ul sf-2,
                                        dl sf-2
                                      },
                                    dl-FrameType dl-FrameTypeA,
                                    deltaSIR1 12,
                                    deltaSIRAfter1 6
                                  }
                                }
                              }

As can be seen 3 TGPSI (Transmission Gap Pattern Sequence Identities) are configured. TGPSI 1 is for FDD measurements (i.e. other 3G frequencies), TGPSI 2 is for 2G RSSI measurements and TGPSI 3 is for initial BSIC identification of the 2G cells.

The compressed mode IEs for each TGPSI, result in a measurement gap as shown at the top of the post (for TGPSI 1). This essentially consists of a single measurement gap, 7 slots in duration (4.67ms). The other TGPSI are configured in an identical fashion. The overall repeating pattern is shown below (click to enlarge).