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

AT&T 3G micro cell, some facts and figures

I was recently looking through some Cisco Live! presentation material on the web and came across an interesting presentation given in June 2012 in San Diego about femto cells. In it, the presenter provides some interesting numbers about AT&T's femto cell offering which is marketed under the name 3G micro cell.

AT&T's micro cell has been around since April 2010 and just over two years later it seems they have a network of 650,000 femto cells! Quite an impressive number in my opinion and probably the largest femto cell deployment in the world.

Looking at some additional figures from their roadmap the 3G micro cell is based on Cisco's DPH-153 product with an AT&T casing. It is capable of 4 simultaneous users which is a typical value for a residential femto cell.

In terms of maximum Tx power it is capable of 13dBm which translates to 20mW. This is actually a very low considering most residential Wi-Fi routers are capable of around 100mW (e.g. Belkin N1, Apple Airport Extreme etc).

HSPA capability is stated as 14.4Mbps for the DL, so 16QAM @ 15 HS-PDSCH codes and 1.5Mbps UL, so 10ms TTI @ 2 x SF4 E-DPDCH. Obviously the ADSL/cable has to be capable of supporting these speeds as well.

Looking at the AT&T 3G micro cell website, there is also an interesting capability that AT&T have enabled and that is for the customer to be able to configure whether the femto cell hands out to the macro or not. At first I thought this was strange but looking through the FAQ it seems this is a recommendation when a customer experiences dropped calls in their house. As the AT&T macro network does not have the capability to hand into the femto, it is possible that a user initiates a call on the femto and as he moves around the house (towards a window, garden, balcony etc) he hands out to the macro. Then as he moves back into the house the macro signal strength deteriorates and the call drops. So to avoid this happening all mobility is disabled and the user stays connected to the femto until a radio link failure occurs which typically is at a much lower point than a handover threshold.

There is a lot more information about femto cells (from Cisco's perspective at least) including the figures above at the Cisco Live! website.

Inter Working Function for CSFB

Traditionally support for CSFB requires an upgrade on the legacy MSCs to support the SGs interface. Additionally careful tracking area to location area mapping is required to avoid MT call failures when the UE falls back to a LA that is not the same as the one it registered on or alternatively call handling procedures such as MTRR or MTRF are required with associated upgrades on MSCs and HLRs.

Putting all this together can be an expensive and complicated process which is where the IWF for CSFB comes in. The IWF provides a number of advantages. At the most basic level it is an interface between the MME and the legacy CS network (as shown above). On one side it communicates using the SGsAP with the MME, while at the other side it communicates using MAP to the MSCs and HLRs. At the same time it provides a VLR function where all the LTE UEs are registered against. This is done by creating a "virtual" LA and updating the HLR accordingly. Any MT calls are thus routed to the IWF. At the same time it eliminates the need for TA - LA planning as all TAs can point towards this one "virtual" LA.

For any MO CS calls the UE fall backs towards the legacy network and discovers a "real" LA. This triggers a LA update and subsequently the call is set up.

For any MT CS calls the process is slightly more complicated and is illustrated in the diagram below (click to enlarge).

The call set up flow can be broken down into 4 phases. At phase 1 the incoming call is routed to the IWF and paging is initiated over the SGs interface. This triggers the CSFB procedure. At phase 2 the UE falls back towards a "real" LA and the LA update procedure is triggered. Phase 3 is the clever bit. Here the IWF sends the HLR an SRI to discover where the UE is located (note the the HLR is still waiting for a response to the PRN message from Phase 1). The HLR queries the MSC and responds. The IWF then uses this information to respond back to the original request from the HLR. The HLR then sends this back to the GMSC and the call is routed. Quite clever!

There is however one drawback with the IWF and that is that every call (MO & MT) requires a LAU before the call is set up. This adds approx. 1 to 2 seconds on the overall setup time. With the classic CSFB, the LAU is not performed and as such faster call setup times can be achieved.

To summarise then the IWF has the advantages of..
1. No upgrade to SGs for legacy network
2. No TA - LA mapping/planning
3. No requirement for MTRR/MTRF

..but the disadvantages of:
1. Longer call set up time due to mandatory LAU procedure

4GEE bandwidth @ 10MHz

Back in October 2012 Everything Everywhere a.k.a. EE launched 4G LTE services in the UK. As EE is the merger of T-Mobile UK and Orange UK, it "re-farmed" part of the 1800MHz spectrum these two companies had and used that for it's 4G LTE network.

At the time I wondered how much spectrum they had managed to re-farm for launch and few days back I had some empirical confirmation of how much that is. The log extract below is taken from a WCDMA SIB19 message which is used by the UE for reselection purposes from 3G to 4G.

Part of the information broadcasted in SIB19 is the IE "measurementBandwidth". As LTE allows for flexible bandwidth allocation (1.4, 3, 5, 10, 15 & 20MHz), the UE has to be informed how much bandwidth is used in order to average the RSRP measurements as explained here.

Rather than specifying the bandwidth in MHz, 3GPP uses Resource Blocks (RB) instead. A RB is 180KHz wide, so 50 RBs give us 9MHz. Taking into account the guard bands on each side of the allocated bandwidth we get a total bandwidth of 10MHz.

This means that at least until EE manage to re-farm some additional spectrum they can only offer 50% of the potential maximum LTE throughput. The good thing about EE is that they have quite a lot of 1800MHz spectrum so I imagine they will continuously monitor their 2G traffic (the 1800MHz was originally awarded to T-Mobile and Orange for GSM services) and as soon as possible another 5MHz block can be re-farmed taking the allocated bandwidth to 15MHz and finally 20MHz. As all LTE devices have to support the maximum of 20MHz, this can happen transparently to the end user.

Looking at the additional information in the log extract, we can also see the exact frequency EE are using which is broadcasted as EARFCN 1617. This translates to a centre DL frequency of 1846.7MHz as shown below.

This in turn can be mapped on EEs 1800MHz spectrum holdings (source: OFCOM) as shown below in red.

Taking into account that EE currently use 10MHz for LTE we can also see what is the top theoretical speed their network could achieve. This is shown in the table below.

In the DL using 2x2 MIMO a maximum throughput of 73Mbps is possible. As 4x4 MIMO is not currently implemented by neither operators or UE manufacturers that column is a bit academical. In the UL a maximum throughput of 36Mbps is possible. As a rule of thumb we can say in the best "real life" situation about 2/3 of those speeds is achievable that would make it as DL approx. 50Mbps and UL approx. 24Mbps. Obviously as more users are added to the system the throughput will decrease accordingly.

The final point to note about the log extract is the priority assigned to the LTE layer. This is configured as 6. As the highest priority is 7, EE have left some room for configuring a higher priority layer. This could be a "small cell" layer or if they are feeling confident of obtaining some 800MHz in the upcoming auction they could use that as a "coverage" layer forcing UEs to camp there by assigning it priority 7 and use the current 1800MHz layer as a "capacity" layer.

Mobile Terminated Roaming Forwarding for LTE CSFB

As described in a previous post one of the issues with LTE CSFB is what happens when the UE falls back to the target RAT but the the LA is not same as the one the UE is registered in during the combined attach procedure. This typically occurs on the borders of Location Areas (LA) and Tracking Areas (TA) or when the target layer is 3G and the UE can only acquire 2G (e.g. indoors).

In order to avoid MT call setup failures, operators must implement either MTRR (Mobile Terminating Roaming Retry) described here or MTRF (Mobile Terminating Roaming Forwarding) which will be described in this post.

The signalling flow for MTRF is shown above (click to enlarge) and essentially consists of 3 phases.

Phase 1 and phase 2 are identical to the MTRR signalling flow, with the exception that the network elements involved must support MTRF and signal as such with the applicable IE (MTRF Supported) defined in the specs.

In phase 3 however rather than cancelling the call setup procedure and re-initiating it towards the "new" MSC like MTRR, with MTRF the old MSC is used as a relay and the call setup procedure continues with an additional PRN & IAM procedure. 

So essentially MTRF manages to cut down the signalling flow and the whole MT procedure completes in 3 phases as opposed to 4. This results in a reduced call setup delay and as such better customer experience.

In the final post on the subject I will describe the IWF solution which overcomes the problem of misaligned LA & TA (and a number of other issues) with the inclusion of an additional core network element. 

F-DPCH on a live network (finally)

F-DPCH (Fractional Dedicated Physical CHannel) was first defined in 3GPP rel6 and then further enhanced in rel7 to overcome some soft handover limitations. Once HSDPA is used for the transfer of user data and L3 signalling (RRC & NAS) it allows the multiplexing of up to 10 users on a single SF 256 code for the purposes of sending TPC (Transmit Power Control) commands in the downlink.

As shown in the table below, 3GPP define 10 slot formats which effectively move the position of the TPC bits in the slot.

The obvious benefit in using F-DPCH is the savings in OVSF codes in the DL. Even though the rel99 DPCH uses only a SF256, once the number of simultaneous users increases (it can easily reach 50-60 users in a busy cell) the impact is quite substantial as sixteen SF256 are equal to one SF16. So clearly 50-60 SF256 will block a large portion of SF16 codes that HSDPA requires. With F-DPCH we can multiplex 10 users on one SF256 thus the impact on the OVSF tree is greatly reduced. On top of this there are savings in DL power and DL noise reduction.

It has always struck me as quite strange then, that mobile operators did not embrace the usage of F-DPCH sooner. As I recently discovered though, things are starting to slowly change and F-DPCH is being used by some operators.

This particular one was Wind in Greece and specifically in the area of Athens that has been upgraded due to a swap (to Huawei).

As can been seen from the trace below the UE signals to the RNC its support for F-DPCH in the RRC Connection Request. This allows the RNC to configure SRB over HSPA and F-DPCH from the RRC Connection Setup message if the establishment cause is related to a PS session. In this particular network, this option was not used and the SRB was mapped to DCH channels initially.

The actual F-DPCH configuration is activated in the Radio Bearer Setup phase as shown below. At the same time the SRB is also mapped on HSPA channels as this is a pre-requisite for F-DPCH.

Looking at the IE present we can deduce which slot format is being used (0 in this case) and which OVSF code is being used (256,17 in this case).

Mobile Terminated Roaming Retry for LTE CSFB

One of the many issues with LTE Circuit Switched Fall Back (CSFB) is what happens when the UE falls back on the target RAT (can be 3G or 2G, operator defined) and the LAC is not the same as the one the UE is registered on through the Combined Attach procedure in LTE. This typically occurs on the borders of Location Areas (LA) and Tracking Areas (TA) or when the target layer is 3G and the UE can only acquire 2G (e.g. indoors).

In these cases, a Mobile Originated CS call would experience a delay as the UE would first have to perform a LAU procedure on the target RAT followed by the subsequent call setup procedure.

A Mobile Terminated CS call on the other hand would fail as the call has already been routed to the "old" MSC (i.e. the one the UE registered on though the Combined Attach procedure) but the UE finds itself in the LAC of a different, "new", MSC.

To prevent this happening two 3GPP defined procedures can be re-used. The first one is called Mobile Terminated Roaming Retry (defined in rel.07) and the second one is called Mobile Terminated Roaming Forwarding (defined in rel.10). Both of these require an upgrade to the CN elements involved in the call setup procedure.

It is interesting to note, that both of these procedures were defined originally to handle the (rare) occasion of a UE being paged in one LA but at the same time moving through a LA border and thus performing a LAU procedure on a different MSC than the one being paged on.

For this post we will have a closer look at the Mobile Terminated Roaming Retry (MTRR) procedure.

The signalling flow is shown above (click to enlarge) and can be broken down into 4 distinct phases.

During phase 1, a MT call comes through the GMSC which initiates the MAP procedures to inform the MSC the UE is registered on (through the Combined Attach procedure). The MSC contacts the MME through the SGs interface which pages the UE. The paging action initiates the CSFB procedure and the UE is directed towards the target RAT.

Under normal circumstances the UE would fall back on the LA it registered on and would send a Paging Response. In this case however the UE falls back on a different LA and thus has to perform a LAU procedure. This is shown in phase 2, as is the subsequent procedure to transfer the UE subscription from the "old" MSC to the "new" one.

This is also where the call setup procedure would fail as the "old" MSC would not have the ability to inform the GSMC that the UE has changed MSCs.

With MTRR however the "old" MSC informs the GMSC through the Resume Call Handling procedure that the call setup procedure should be repeated by contacting the HLR once more. This is shown in phase 3 of the signalling flow.

Finally, phase 4 is a repeat of phase 1, but this time the GMSC contacts the correct "new" MSC and the call setup procedure is successful.

It is also important to note that during the LAU procedure in phase 2, the UE populated an IE indicating that a CS MT call was in progress. This ensures the new "MSC" keeps the signalling link towards the HLR for the subsequent signalling exchange in phase 4.

Obviously this whole procedure would also add a couple of seconds more on the overall call setup time, which due to the general CSFB procedure is already longer that a "native" CS call setup in 2G/3G.

In the next few posts I will look at the second option, MTRF, and also at a completely different approach that uses an inter working function between the MME and MSC in order to avoid any upgrades in the legacy CS network.