MUROS – Packing 4 Voice Calls Into a Single GSM Timeslot

Back in 1992, the GSM world was simple. A carrier was divided into 8 timeslots and in those that were not used for broadcast information signaling, one voice call was carried. After some time, half rate channels were invented to put two calls in a single timeslot. At first, there was the HR codec which was inferior in speech quality but would use only use alternating instances of an assigned timeslot. But then, advances in coding technology gave rise to the Adaptive Multi Rate Codecs (AMR), and those codecs which fit into half a timeslot were, from a sound quality point of view, quite up to the Enhanced Full Rate voice quality. A nice move as voice capacity of the network effectively doubled.

And now, companies in 3GPP are attempting to again double the number of voice calls per timeslot to up to four! The work item is called MUROS (Multiple Users Reusing One Slot) and you can find some interesting papers about the concept HERE. The folder unfortunately also contains contributions to other topics discussed during this ad-hoc meeting so it’s a bit time consuming to find the papers on MUROS. For a start have a look at the following ones:

080007 – Details on Downlink DARP and Interference
080019 – Short Into to MUROS in Uplink and Downlink
080041 – A first draft of the 3GPP Technical Report which will result from this work

These papers give a first idea on how four voice calls could potentially be put into a single timeslot. Instead of further splitting up the timeslot in time, as was done for AMR half rate, two signals are to be emitted by the base station simultaneously. From a mobile station point of view one signal contains the user data and the other signal is perceived as noise. The mobile phone then has the task to filter out the noise (i.e. the data stream which is unwanted). In uplink direction, it is also foreseen that two mobiles transmit at the same time and that the base station uses interference cancellation and multi-user detection schemes to separate the two signals, potentially based on the use of different training sequences in the middle of the slot.

While at the moment different means are discussed of how the two signals can be told from each other on the receiving end it is clear that MUROS will not work with current mobile devices and also not with current mobile chipsets. Features like SAIC (Single Antenna Interference Cancellation) and DARP (Downlink Advanced Receiver Performance), both also discussed in 3GPP, will probably become the cornerstones for realizing MUROS.

While making this work on the radio layer is surely a formidable challenge, it will also prove to be tricky for radio resource management. Mobile can only tell the two signals apart under radio conditions that are favorable to them. The task of radio resource management will be to dynamically instruct the mobile to handover to ‘less used’ timeslots when signal conditions deteriorate. In the worst case, the mobile could even have to be handed over to a timeslot which it uses exclusively until radio conditions improve.

Should this feature be accepted and implemented it will keep GSM radio layer-, radio network, and chipset designers busy for quite some time to come.

Using Vista’s Firewall to Limit Traffic For Volume Restricted Access

It's great, all programs on my computer these days think they have to
automatically check for updates whenever they are started or sense that
a connection to the Internet has been established. I usually don't mind
and even welcome it. However, there are situations, especially when I
use volume restricted wireless 3G access such as Vodafone Websessions,
in which I don't want those multi-megabyte downloads. So I've switched
most update services to semi-manual or manual to control this behavior.
But even this sometimes doesn't stop the talkers.

Recently, the Windows update service told me it wanted to download a 30
MB .NET update. Sure, no problem, I was at home at the time, so please
go ahead I thought. However, it didn't as there must have been a
problem with the update service. So the originally agreed update only
started a couple of days later when I was abroad, hanging on a thin
line. No way to stop that 30 MB download, no task revealing itself as
the culprit that could be terminated, no nothing… Ugh, I was angry.

But here's the solution in case you have Windows Vista installed:
Go to the firewall configuration and set the profile which is used for
dial-up connections (in German it's called "Öffentliches Profil",
that's probably or "public profile" in English) to block all "outgoing
(TCP/UDP) connections". Then go to the outgoing rules section and
create new rules which allow only the programs you like such as
Firefox, your eMail program, etc. to establish outbound connections. In
a last step, assign these rules to the "public profile". No more nasty
connection requests and update dialogues while you are away.

LTE and the Voice Gap: CS Fallback

LTE surely is an exciting new radio technology and over time will become a worthy successor to GSM and UMTS. It will have a difficult start though, as it is lacking intrinsic support for the wireless killer application, voice calls. A number of different efforts are underway in 3GPP to fix this. I've reported before on IMS Centralized Services, which is elegant but unfortunately quite complex and CS Voice Services over LTE, which from my point of view would fix things with an acceptable amount of effort and complexity but is currently met with little love in the standards body.

A third initiative that, unlike CS Voice over LTE, has manged to become an active work item in 3GPP is to let the mobile device fall back to GSM or UMTS for incoming and outgoing voice calls. In 3GPP the technical specification that contains an overview of the feature is TS 23.272 'Circuit Switched (CS) fallback in Evolved Packet System (EPS)'.

From an overall architectural point of view I think this work item is rather a confession that there is still a long way to go until we have a real successor technology in place for voice. However, if it can do the job, who cares…

The technical specification of the feature is refreshingly clear how it is supposed to work. For those of you who don't want to go through the spec, here's a short overview of how things will work:

The Preparation Phase

  • When the GSM/UMTS/LTE capable device first connects to the EPS (the Evolved Packet System, i.e. to LTE), it indicates to the network that it wants to perform a "Combined Update". In practice this means that it requests from the network to also register its presence in the 2G/3G circuit switched network.
  • Registration of the mobile in the 2G/3G network is performed on behalf of the mobile device by the MME (Mobility Management Entity) network element which is part of the Access Gateway functionality. It connects back to a legacy Mobile Switching Center (MSC) via the SGs interface, which is an extension of the already known Gs interface between the SGSN and the MSC. In effect, the MME acts as an SGSN and the MSC thinks the device is attached to the 2G/3G network rather than the LTE network and performs a location update via the SGSN. This has been done for backwards compatibility so there are only few if any changes required on the MSC.
  • For the registration in the network, the MME has to give the MSC the 2G/3G Location Area ID (LAI) in which the mobile device is currently 'theoretically' located. Since the mobile can't tell the MME this value, it has to be computed out of the TAI, which is the corresponding identifier in LTE. In practice this creates a dependency between the TAI and the LAI, i.e. the location areas that describe a group of base stations in 2G/3G and LTE must be configured in a geographically similar way in order for the fallback to work later on.

The Execution Phase: Mobile Terminated Call

  • When a circuit switched call comes in for the subscriber it arrives at  MSC. The MSC will then signal the incoming call via the Gs/SGs interface to the MME which is, in it's eyes, a 2G or 3G SGSN that can forward the notification to the mobile device on its behalf. From the MSC point of view this is a legacy procedure that already exists today.
  • If the mobile is in active state, the MME forwards the request immediately to the mobile device. If the mobile wants to receive the call it signals to the MME that it would like to be handed over to the 2G or 3G network in which it can receive the call. The MME then informs the base station that the mobile has to be handed over to the 2G/3G network.
  • Since there might still be an IP data transfer ongoing at the time of the handover, the standard gives the two options: Either the data transfer is suspended or the packet switched connection is handed over to the 2G/3G network. Here, it starts to get a bit complicated as some 2G networks might not be able to handle voice and data connections simultaneously. As a matter of fact, most GSM networks don't have this ability, called Dual Transfer Mode (DTM) today.
  • If the mobile is in idle state when the voice call comes in, the MME pages the mobile to reestablish radio contact. Once contact has been re-established, it forwards the information about the call. Since there is no data transfer ongoing at this time, no handover of the IP connection is required since the mobile can re-establish the packet switched connection itself once it is in the 2G/3G network.
  • The eNodeB has the possibility to request 2G/3G measurements from the device to have a better idea to which cell to hand over the mobile or it can do so blindly by sending it information about a preconfigured cell.
  • Once the mobile device is in the 2G or 3G cell (and the packet switched handover is done if it was performed) it answers to the initial paging via the legacy cell. In case the MME has made a mistake and the legacy cell is in a different location area than where the device was registered in the preparation phase, the specification also contains a mechanism to first perform a location update and then reroute the waiting voice call to the new location area or even to an entirely different MSC.

The Execution Phase: Mobile Originated Call

  • This procedure is very similar to the mobile terminated call example above. The difference is that there is no paging coming from the network for an incoming call and of course no paging response to the MSC after the device is in the legacy cell.

SMS and CISS

  • For receiving text messages, the mobile device can remain the LTE nework, the SMS is forwarded by the MSC to the MME via the Gs/SGs interface and from there via RRC signaling over the LTE radio network to the mobile device. Sending text messages works in a similar way, there is no need to fall back to a legacy network.
  • For call independent supplementary services (CISS) such as changing call forwarding configuration, checking prepaid balance via USSD messaging, etc., a fallback to the legacy network is required.

Summary

When looking at the description above it becomes clear that falling back to GSM or UMTS for voice calls is not quite as straight forward a process as one might think at first. On the legacy side of the network, however, little or no work is required since the LTE network, and specifically the MME, acts like a 3G SGSN and therefore all procedures already existing for 3G to 3G/2G handovers can be reused.

One question that remains and is even asked in the technical specification is how much time is added by this fallback mechanism to the call establishment time and if this additional time will have a negative impact on the user's perception of the service.

And from my personal point of view I wished 3GPP would have rather invested the time it took to come up with this feature into the CS voice over LTE proposal. But better this feature than nothing at all the pragmatist in me says.

Carnival of the Mobilists at Always On Real-Time Access

Cotm-button
Chetan Sharma has taken over the Carnival of the Mobilists this week on this blog Always On Real-Time Access. As always, the carnival is diverse, entertaining and thought provoking, so head over and enjoy! The two posts that especially stood out for me personally this week were James Cooper's report on mobile Internet use in South Africa and C. Enrequie Ortiz's short enty on one click for effective use of bar codes and NFC.

Two Opera Mini Tips

Regular readers of this blog probably know that I am a glowing Opera Mini fan. I am amazed at how versatile this piece of software is for mobile web browsing. Here are two tips of how to extend the functionality which have come in pretty handy recently:

  • Delicous bookmarklet: Opera Mini fans also using the Opera desktop browser are probably pretty happy with the mobile/desktop bookmark synchronization feature. Since I use Firefox and Delicious, I'd like to have a similar feature, as sending links I have found by eMail is a bit too complicated to be efficient. Almost as easy said as done. Denis over from Wap Review has found out how to add a Delicious bookmarklet to the Opera Mini bookmarks. He actually posted the tip over one and a half years ago. Thanks Goolge for pointing me there. Works great, thanks Denis!
  • Google Reader: I used to read my feeds via Thunderbird which had the big disadvantage that more often than not, I failed to keep up to the flow of information as I just did not have time to attend my blog roll in front of a computer. I usually have a couple of minutes to spare when I am mobile though. So I switched to Google Reader, which has both a superb desktop and mobile interface. First, I tried the iPhone mobile interface in the S60 browser. It works great, but the missing up/down page scroll functionality of the S60 browser makes it too awkward to use. Nokia, how much longer do we have to wait for this simple functionality? In the meantime, I use the standard mobile interface, which works well with Opera Mini. It doesn't look as nice as the iPhone web interface, but it does its job superbly.

SIM Cards on a Boat Ride

I recently took a trip over the English channel from Calais to Dover on a P&O ferry and noticed the vending machine shown in the picture on the right from which passengers can get English SIM cards from different operators for their time on the island. Since no registration is required in the UK when buying a SIM, it is already activated and can therefore be used right away.

Note that only UK operators were offering their SIM cards in the machine, French SIM cards were nowhere to be seen. This could be because the ferry was operated by an English company or maybe because identification is required when buying a SIM card in France. Maybe it's also due to the lack of real competition in the wireless market in France. Hard to tell.

However, upon my return to France, I noticed that in some train stations and also in some supermarkets, Virgin, a MVNO using Boyugues' GSM network sells 'mobile phones to go'. The box says they can be used right away but a copy of the passport has to be sent to them within 7 days. The text on the box also suggested that topping up the account might also only be possible once the registration has been processed. I wonder if that is a creative way to comply to government regulations or to ensure people send in their details.

Anyway, I hope that SIM card vending machines do make it into other places such as airports as well, it would significantly reduce the effort to get a local SIM card for mobile Internet access when arriving in a country.

Evolved EDGE Whitepaper by 3G Americas

Over the past 2 years I've written a number of blog entries on Evolved EDGE (here, here, here and here). Now that the feature set is mostly specified, vendors are moving into the implementation phase. A recent whitepaper of '3G Americas' is giving an interesting overview of the different features (without going to much into the implementation details), their potential, and different likely implementation phases. I quite like the paper as it takes a look at EEDGE not only from a technical but also from a deployment point of view.

From a technical point of view the paper mentions one thing in particular which I have not thought about before, and that is that there are two improvements brought by the dual carrier feature. The first improvement is that it improves throughput because timeslots can be assigned simultaneously on two carriers. That's quite obvious.

The second improvement is that even if some timeslots are busy on one carrier for voice calls, the same timeslots on the second carrier might be free and can thus be assigned. This doesn't result in the full theoretical speed but at least compensates for the fact that it is difficult in many situations to have 5 timeslots in sequence available on one carrier. In effect this statistically increases the number of timeslots available for a dual carrier mobile compared to a current single carrier mobile and thus increases the overall speed experienced by a subscriber by using timeslots that could otherwise not be used.

Internet For The Other 3 Billion

Heise News reported recently about O3b Networks, a new satellite operator who’s mission statement is to connect “The Other 3 Billion” to the Internet. Hence, their name O3b. It was probably worth a post as one of the investors is a certain Google Inc. The company’s web site doesn’t yet contain a lot of material but what they’ve already put there makes some interesting reading. Heise reports that the company aims to put 16 satellites built by Thales Alenia aerospace into orbit with a total of 2300 transponders. Each transponder has an uplink/downlink bandwidth of 216 MHz, which delivers a throughput of 600 MBit/s in each direction. The company targets fixed line and mobile networks in the developing world for backhaul services and says there system is designed for significant savings over previous backhaul transport in regions where laying a fiber is no option. It would be interesting to get some hard numbers in terms of dollars per month. Latency of the system is given at 65 milliseconds, quite important for real time services such as voice and interactive services such as web browsing. The company also positions itself for emergency scenarios and says they can get bandwidth to any place around the globe +/- 45 degrees of the equator within 10 minutes. The satellites have yet to be brought into orbit which is foreseen around 2010. An ambitious and exciting project!

The Line Is Busy But You Don’t Notice

I recently surfed the web with my Nokia N95 over my home Wifi network using the OperaMini browser while simultaneously downloading a movie from my online video recorder at the full DSL line speed (7 MBit/s). What quite surprised me was that despite the line being 100% busy because of the file download, the browsing experience on the phone was perceptively not slower than if the DSL line was not used at all.

There are a number of conclusions that can be drawn from that:

  • It shows the huge difference in bandwidth requirements of different applications and due to the little bandwidth requirements of one application the user does not even notice that a network with a significantly higher bandwidth is already fully loaded.
  • From a technical point of view mobile web surfing with compressed page downloads costs almost nothing compared to the transmission costs incurred by other applications such as huge file downloads and full web browser use.

The situation obviously changes when even small screen devices download full web pages including high resolution images. Mobile web browsers such as Opera Mobile, the Nokia N- and Eseries web browser and the iPhone already do that today. However, for most web pages the experience is not as good not only due to the high amount of data that has to be transfered but because the processor is not being able to render the page as quickly as on a PC. Over time, this might well change but I guess there is still a lot of time left where the OperaMini compression approach will deliver suprerior results in most cases.

3G FACH capacity

With the rising number of push eMail devices in 3G networks and mobile applications such as instant messengers and voice over IP clients the number of small IP packets to keep the connections of such applications alive through network address translation routers is rising. For the network this means of lot of radio layer signaling and waste of bandwidth. For the mobile device, keep alive messaging means significantly increased battery consumption.

3G UMTS networks are thus putting devices that only send little data on the Forward Access Channel (FACH) which requires much less radio channel signaling overhead than if the device is instructed to remain or use the High Speed Downlink/Uplink channels for such kind of traffic. As more always-on devices are used in the networks, this will quickly become an issue since the total capacity of the FACH of a cell is limited to 32 kbit/s today. With the bandwidth so small I think most operators will be very thankful for the enhanced-FACH extension which reserves some capacity on the high speed downlink channels for FACH operation. Despite using the high speed channels, no additional radio layer signaling will be used so overhead and battery consumption remains limited at the expense of spectral efficiency. While networks and mobile devices do not support this feature today I expect that this is definitely a feature that will be implemented in the future.

For more on radio interface optimization for future devices and services have a look at my previous entries on continuous packet connectivity (here, here and here), some more background on enhanced FACH (here) and some thoughts on upcoming capacity issues due to keep alive messaging (here).

It seems there is now also an initiative in Release 8 of the 3GPP standards to improve the uplink behavior of the system while a device in in Cell_FACH state. More about that once I have taken a look at the details.