Can You Really Forbid 3G to Wi-Fi Bridges At The Olympics?

Yesterday, the net was full with reports about the London Olympics 2012 organizers banning the use of 3G-Wifi Access point functionality of modern smartphones in Olympic areas. What I found interesting on the reporting side is that only few news agency actually wondered why this ban was in place and only some speculated that this might have security reasons, or, what seems more likely to me, commercial reasons as one British network operator has deployed Wi-Fi hotspots on Olympic venues and wants to monetize the service. Non of the news agencies actually tried to get an official statement. Why not?

So in case it was commercial reasons, I wonder if 3G/Wi-Fi bridges for non commercial reasons, i.e. me connecting my friends can actually be forbidden by the organizers? The 2.4 GHz band used for Wi-Fi is an open band accessible freely for everyone. The Olympic organizers don't have a monopoly on the band so how can they possibly forbid any sort of legal use? I'd really like to know if there is a legal basis for this!? Anyone!?

But apart from that I wonder if they have even remotely thought about how to enforce this!? This seems like a hilarious joke and I wonder if this ban will actually make people start thinking about sharing their 3G connectivity with others rather than having the desired  effect.

VOLGA Forum Publishes Stage 1 Specification for CS Voice over LTE

Not too long ago I reported on the foundation of the VOLGA (Voice Over LTE via Generic Access) Forum, which, as the abbreviation implies, wants to specify and implement a pragmatic approach for using the current circuit switched voice solution can over LTE. Looks like they have been quick to start their work, as the Stage 1 document for the proposed service is now already available on their website. Stage 1 is the first of 3 steps to describe a service from the basic concept (stage 1) to methods and procedures (stage 2) to the fine details including composition of messages (stage 3). Beyond what's already been written in 3GPP TR 23.879, I found the following interesting details:

  • The interface between the Volga Access Controller can be either A (GSM) or Iu (UMTS), in either their tradition variant or over IP. So if IP is selected the VOLGA solution is end to end (compare also to my R4 MSC post).
  • Transcoding Free Operation (TFO) shall be supported
  • H.324M for Video Calls shall be supported (great, completely forgot about that)

So, as you can see, quite some interesting details in the document, despite only being a stage 1 document.

Can't wait to see stage 2 and stage 3. Congrats to the VOLGA forum for the swift action!

The Volga-Forum: Taking the Quest For Voice over LTE out of 3GPP

Over the past two years I've written numerous posts about different proposed options on how to do voice calls over LTE and the lack of a simple and straight voice solution. This is, in my opinion, a serious threat to the success of LTE if not resolved soon. A number of alternative solutions to the IP Multimedia Subsystem (IMS) have been analyzed in 3GPP, which is envisaged to be the successor to the circuit switched MSC voice architecture. However, even after many years of standardization, it has still not seen the light of day and some fear that it's become to complex. Instead, only fallback to GSM or UMTS for an incoming voice call has made it into the 3GPP standards. Looks like some parties in the game are not happy and have started to push things forward by going off stream with the newly formed Volga-Forum (Voice over LTE via Generic Access).

It seems that other solutions, which have been examined in 3GPP for connecting the current MSC (Mobile Switching Center) architecture to LTE have so far not found the necessary approval by the necessary majority of 3GPP members to become a work item, a necessity for becoming an official feature. I've discussed one of the alternatives back in August 2008 here for those who would like to have a closer look. In summary, the two MSC options examined suggest to replace the lower layers of the current voice protocol stack by IP, while leaving the higher layers of the protocol stack untouched. With relatively little work, the existing voice service can be reused for LTE, including the seamless handover of an ongoing call between LTE, UMTS and GSM and international roaming.

Even simple things don't happen over night and each day waiting for 3GPP to finally start working on this topic drags out the day when LTE can really go beyond USB dongles or built in laptop modems and compete with HSPA where voice calls work like a charm. This is where the Volga-Forum comes in. With a strong list of supporters such as T-Mobile and Ericsson, just to name the two biggest (some more operators in the boat would be nice though), they have pledged to take the task of defining an interoperable voice solution for LTE outside of 3GPP.

I would guess the aim is to put some pressure on 3GPP to move forward and the intention is to fold their work back into the standards later on. But even if they stay separate, the solution selected is based on UMA/GAN, as described in option 2 in 3GPP TR 23.879, so the Volga-Forum does not depend on the support of 3GPP to drive their implementation. The main parts of the approach require no modifications in the LTE radio network, the LTE core network or the MSC. All enhancements suggested would be implemented on the mobile device and a new gateway controller between the LTE core network and the MSC. The situation is thus very similar to the days when Kineto and others privately developed UMA, which tunnels GSM and GPRS over Wi-Fi, before it officially became part of the 3GPP standards some years later after being renamed to GAN (Generic Access Network).

A very interesting move, and I think it's good to see that things are moving forward! If you would like to add anything on the political or technical side of this, please leave a comment below.

Thanks to LTE Watch for the first pointer!

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.


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


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.

Beyond 3G: The Manuscript is Ready

Some of you might have noticed that recent blog entries haven grown in size again and speculated that I have a bit more time at hand again. Well you have guessed right. Over the past months, I spent most of my free time working on my next book, to be published by John Wiley and Sons by the end of the year. Finally, the manuscript is ready and the title will be

"Beyond 3G: Bringing Networks, Terminals and the Web Together"

For the moment, people at Wiley's are now working on the cover, they are proof-reading the manuscript, and typesetting is starting soon. After that, I'll have to work a bit on the index, on the glossary, etc., etc. But that's a bit later in the year. I always find it amazing how many steps are necessary from finalizing the manuscript to having the finished book finally being shipped to the bookstores.

It's a long process. However, I strongly feel that all of this work is necessary and justified to produce something outstanding that has something which is missing in day to day online publishing: Depth and broadness.

That doesn't mean that online sources are less valuable, they are just different. I very much like my blog for example, because it catches spontaneous thoughts, thoughts about a clearly defined single topics, ideas, it's great for posting the latest news, for responding to someone else publishing something, and it is thus a great complement to my offline writing activities. Together, online and offline are hard to beat!

So what exactly will the book be about? Here's the current version of the back cover text:

Giving a sound technical introduction to 3GPP LTE and SAE, this book explains the decisions taken during standardization while also examining the likely competition for LTE such as HSPA+ and WiMAX. As well as looking at next generation network technologies, Beyond 3G – Bringing Networks, Terminals and the Web Together describes the latest mobile device developments, voice and multimedia services and the mobile web 2.0. It considers not only how the systems, devices and software work but also the reasons behind why they are designed in this particular way. How these elements strongly influence each other is discussed as well as how network capabilities, available bandwidth, mobile device capabilities and new application concepts will shape the way we communicate in the future.

  • Examines current and next-generation network technologies such as UMTS, HSPA+, WiMAX, LTE and Wifi
  • Analyses and explains performance and capacity in practice as well as future capacity requirements and how they can be fulfilled.
  • Introduces the reader to the current cellular telephony architecture and to voice over IP architectures such as SIP, IMS and TISPAN
  • Looks at mobile device hardware and mobile operating system evolution
  • Encompasses all major global wireless standards for application development and the latest state of the mobile web 2.0

As I said above, it's going to take until the end of the year until the book is finally shipped. If you would like to be informed when it's available, please send an eMail to "gsmumts at", I'll be happy to keep you informed.

CS Voice (And Other Services) over LTE

I've been speculating recently how voice calls could work in next generation 3GPP LTE networks. The politically and technically foreseen way is IMS, the IP Multimedia Subsystem, and a service platform running on top of IMS such as the IMS Centralized Services (ICS). ICS is quite promising as it includes a solution to bring GSM only handsets without any IMS extensions into an overall voice solution and can hand-over voice calls from LTE to GSM when leaving the coverage area. The major drawback of ICS is its complexity and its anyone's guess when we will see this in mobile devices for the general public.

In the meantime, there has been some support in 3GPP to investigate a different solution: How to extend the current circuit switched voice service of GSM to LTE. In 3GPP a number of companies started writing some proposals, which were gathered in 3GPP TR 23.879. In this paper, the main proposal is to connect the Media Gateway part of the Circuit Switched Mobile Switching Center (MSC) to the packet core and give the the MSC Server direct access to the Mobility Management (MME) Entity of the Access Gateway to the LTE Radio network.

This approach completely circumvents the IMS and reuses all upper signaling protocols already known from GSM. Only the lower protocol layers are replaced by TCP/IP. For the voice call itself, all higher layers of the voice transmission protocol are foreseen in the technical report to be kept, while the lower layers would be replaced by TCP/UDP/RTP between the mobile device and the MSC's media gateway.

Handovers would be supported via the interface between the LTE Access Gateway and the evolved MSC (eMSC). When the base station signals that a handover to a 2G GSM cell is required, the Access Gateway informs the evolved MSC via this interface of the handover and the intended target cell. The eMSC can then prepare a circuit switched channel in the 2G or 3G network and respond to the LTE Access Gateway with the necessary details which are then given to the mobile device by the base station in the handover command.

From a development point of view such an approach is much simpler than installing a full IMS system and put ICS on top. Also, all services available today, including SMS, are instantly available, without any further development.

Here are the main developments that I think would be required for such a solution:

  • Mobile device: The stack for voice telephony must be enhanced to put the signaling and voice data a packet switched connection while the device is attached to LTE. Also, the handover code must be enhance to not only support 2G to 2G, 3G to 2G, 2G to 3G handovers but also 4G to 2G or 3G and vice versa.
  • LTE Base station: The software needs a small enhancement to transparently forward the CS handover information it receives from the Access Gateway to the mobile device.
  • LTE Access Gateway: The MME in the Access Gateway needs to be enhanced to report a handover to the eMSC and to wait with the handover until the eMSC gives the go-ahead. Also, it would have to forward a transparent data container with information about the resources allocated in the circuit switched network to the mobile device.
  • MSC: Would have to be enhanced to communicate via DTAP over IP (instead of ATM, IuCS, BSSMAP and BSSAP) and to perform handovers from 4G to 3G or 2G and vice versa. Further, instead of assigning circuit switched traffic channels it would have to interact with the packet core to assign the correct QoS attributes which will ensure a smooth call and sets the scene for the MME to signal a 2G handover to the eMSC.

For further details, including how to deal with roaming subscribers, have a look at the technical report.

All in all, I would say that the enhancements required for 4G handovers are far less complicated than those required at the time to implement 3G to 2G handovers when UMTS was specified. 

From a technical point of view, this architecture has the drawback that voice calls to mobile clients would continue to use a protocol other than SIP, which is the dominant protocol in the fixed line VoIP world. The MSC and the Media Gateway would in effect act as a signaling protocol converter and, in case the call is handed over to a circuit switched 2G connection, as a voice codec transcoding function. Considering the comparatively small enhancements required in the handset and the newtork compared to a full IMS/ICS solution, this architectural imperfection could well be worth it.

From an IMS/ICS point of view the proposed solution looks of course "stone age". It would only support voice calls, i.e. no multimedia sessions, would not support several devices per account, no sessions, no instant messaging, you name it, just pure and simple voice and SMS (but with all the supplementary services that have been developed over the past 30 years!).

BUT: Due to its handover capabilities to 2G GSM and and seamless use over 2G, 3G and 4G networks, it might be the killer VoIP solution for operators to beat Internet based VoIP services (think Skype, etc) which are also pushing into wireless networks and devices today.

Strangely enough, the current work plan lists the technical report as "moved to Release 9" (look for "FS on CS Domain Services over evolved PS access"). I am not sure what that means but it sounds like it didn't meet the love of enough companies represented in 3GPP.

IMS Centralized Services (ICS)

Interesting to see which 3GPP Release 8 work items around the IP Multimedia Subsystem (IMS) are bearing fruit these days. While in Release 7, the hot application specifications for IMS services were Multi Media Telephony (MMTel) and device centric Voice Call Continuity (VCC), work in Release 8 seems to have to have shifted towards IMS Centralized Services (ICS) and a network centric Voice Call Continuity.

As the name implies, ICS offers centralized services, which means an IMS Application Server for ICS manages sessions for a user in several respects:

Multiple Devices – Several devices can be associated to the same user account and can be active simultaneously. Incoming media sessions can then be forwarded to one, several or all of these devices. Devices can be switched during ongoing sessions.

Including GSM mobiles – ICS has been designed not only to work with IP/IMS devices but also with "legacy" GSM  phones without any special software on board. When mobiles are switched on the MSC server communicates with the ICS Application Server (the Service Centralization and Continuity Application Server SCC AS) on behalf of the mobile. This is done either directly, in case the MSC server has been enhanced to act as an IMS client for the mobile, or via an Intelligent Network (IN) node that communicates with the MSC Server via CAP (CAMEL Application Part). The later one is probably preferred by many suppliers since IN nodes and CAP are used today for many applications such as prepaid billing. This has the advantage that the MSC software does not have to be extended for ICS.

Managing Supplementary Services – The ICS offers a standardized way of implementing services such as call forwarding, barring, hold, resume, 3-way calling.

Combination of Different Types of Media– ICS is not limited to voice telephony. Video calling, picture sharing and other media streams can be added or removed from a session at any time. 

Handover to 2G – And finally, the 3GPP ICS working group has also thought about how to hand over the voice portion of a session to a circuit switched bearer when the mobile reaches the limit of the broadband wireless networks. Currently, handovers from LTE are supported to GSM and 1xCDMA (hello Verizon!). Unlike the previous Voice Call Continuity (VCC) specification which requires the handover decision to be made by the mobile, the ICS handover to a circuit switched channel is network initiated and controlled. The advantage of network control is that the device does not have to be attached to two different radio networks simultaneously. This is important since like GSM/UMTS mobiles today, future LTE mobiles will also not be able to connect to two cellular network technologies simultaneously. From my point of view this network centric Single Radio Voice Call Continuity (SR VCC) approach is a major step towards solving the LTE voice gap. I'll describe the details in a future post.

For further information, here are links to the three main ICS specifications:

And for some more general background reading, here are some more resources: