WirelessMoves

This week a device was announced to the press that can supposedly use LTE networks in the US  and HSPA network in Europe and Asia. To the mainstream press things are clear, Internet access with the device will be better in the US than in Europe. Hm, they just overlooked a small detail: In the US, Verizon and AT&T currently use the 700 MHz band for LTE and each carrier only has 10 MHz of spectrum in that band (see for example Verizon's band 13). In Europe, Dual Carrier HSDPA combines 2×5 MHz to a 10 MHz channel. This nullifies pretty much all of the theoretical speed advantage. The only thing that is left that LTE has and HSPA hasn't is MIMO. Add to that the denser network structure, a more mature technology and very likely a lower power consumption due to optimized networks and things suddenly look quite different. But I guess one can argue as much as one wants, 4G must by definition be better than 3G 🙂

says Fritz Joussen, CEO of Vodafone Germany and president of Bitcom, a German telecom trade association. Last year it was already one third of all phones, which shows an interesting trend. While a few years ago a smartphone sold did not automatically also mean that a data connection came with it, this might have changed in the meantime as well. After all, what's the point of having an iPhone or an Android based phone without Internet connectivity? With Symbian phones this was still a possibility and many people used such smartphones for offline purposes only. Fortunately, prices have changed as well. 10 Euros a month now connect you to the Internet with a flatrate (throttled after 300 MB) + 50 voice minutes, 9 cents for SMS and voice minutes afterwards.

So far I've always assumed that LTE-Advanced Cooperative Multi Point (CoMP) transmission would be similar to what we have in UMTS for voice calls. Here, several base stations transmit a signal in the downlink direction for the mobile at the same time. The mobile device then tries to decode all signals simultaneously to improve reception conditions. With the introduction of HSPA for packet based data transmission this was no longer possible. Here the central scheduler in the central Radio Network Controler was replaced by individual packet schedulers in the base stations. As a consequence fast coordination between the schedulers of the different base stations was not possible due to the delay and limited transmission capacity of the backhaul link.

But I thought time has moved on, technology has improved and some way has been found for schedulers to communicate over the backhaul link to synchronize transmissions to a mobile device. Actually, that is not the case and the CoMP scenarios that have been studied in 3GPP TR 36.819 work quite differently. In fact, all except one scenario is based on fiber links that transmit the fully processed RF signal which is only converted from optical to an electromagnetic signal at a remote radio head. Here's a summary of the two modes and four approches discussed in the study for 3GPP Release 11:

Transmission Modes

In the Joint Processing (JP) mode, the downlink data for a mobile device transmitted from several locations simultaneously (Joint Transmission). A simpler alternative is Dynamic Point Selection (DPS) where data is also available at several locations but only sent from one location at any one time.

Another CoMP mode is Coordinated Scheduling / Beamforming (CS/CB). Here the downlink data for a mobile device is only available and transmitted from one point. The scheduling and optionally beamforming decisions are made among all cells in the CoMP set. Locations from which the transmission is performed can be changed semi-statically.

Deployment Scenarios

Scenario 1, homogeneous network intra-site CoMP: A single eNodeB base station site is usually comprised of 3 or more cells, each being responsible for a 120 degrees sector. In this scenario the eNodeB controls each of the three cell schedulers. This way it is possible to schedule a joint transmission by several cells of the eNodeB or to blank out the resource blocks in one cell that are used in another cell for a subscriber located in the area between two cells to reduce interference. This CoMP method is easy to implement as no external communication to other entities is required. At the same time this is also the major downside as there is no coordination with other eNodeBs. This means that data rates for mobile devices that are located between two cells of two different eNodeBs cannot be improved this way.

Scenario 2, high power TX remote radio heads: Due to the inevitable delay on the backhaul link between different eNodeBs its not possible to define a CoMP scheme to synchronize the scheduler. To improve on scenario 1, it was thus decided to study the use of many (9 or more) Remote Radio Heads (RRH) distributed over an area that is today covered by several independent eNodeBs. The RRHs are connected to a single eNodeB over fiber optic links that transport a fully generated RF signal that the RRH only converts from an optical into an electromagnetic signal that is then transmitted over the antenna. While this CoMP approach can coordinate transmission points in a much larger area than the first approach, its practical implementation is difficult as a fiber infrastructure must be put in place to connect the RRHs with the central eNodeB. A traditional copper based infrastructure is insufficient for this purpose due to the very high data rates required by the RF signal and the length of the cabling.

Scenario 3 and 4, heterogeneous networks: Another CoMP approach is to have several low power transmitters in the area of a macro cell to cover hotspots such as parts of buildings, different locations in shopping malls, etc.). The idea of this approach is to have a general coverage via a macro cell and offload localized traffic via local transmitters with a very limited range, reducing the interference elsewhere. This can be done in two ways. The localized transmissions could have their own cell IDs and thus act as independent cells from a mobile device point of view. From a network point of view, those cells, however would be little more than RRHs with a lower power output instead of a high power output as in scenario 2. Another option would be to use RRHs as defined above with a low power output without a separate cell ID which would make the local signal indistinguishable from the macrocell coverage for the mobile device. Again, fiber optical cabling would be required to connect the low powered transmitter to a central eNodeB.

Overall, the 3GPP CoMP study comes to the conclusion that data rates could be improved between 25 to 50% for mobiles at cell edges with neighboring interference which is a significant enhancement. Except for scenario 1, however, fiber cable installations are required which makes it unlikely that CoMP scenarios 2,3 and 4 are likely to be implemented on a broad scale in the next 5 years.

… for Plan A to work. At least that's what I read in an interview with a high ranking manager from a previously important mobile phone manufacturer recently. But I digress, I wanted to say something else. When I recently went on a long weekend in the countryside, my D100 (3G dongle to Wi-Fi adapter box) I had for many years has suddenly decided to no longer cooperate. Pretty bad when you are in places that use Swisscom Wi-Fi and you have more than a single device that wants to share your 3G Internet connection. But unlike the afore mentioned manager I did have a plan B, Wi-Fi tethering to the Android smartphone I otherwise mostly use for eBook reading and experimenting. The Wi-Fi range is probably not as good as that of the D100 but it was good enough for the hotel room and all devices I needed connectivity for worked just fine. I love it when a plan comes together, even if it's plan B. The attitude could do miracles for the above mentioned manager as well. But perhaps he's not allowed to have a plan B… But I digress again. I'm glad that something I speculated about 6 years ago in 2006 now works so well.

Here comes an interesting number from the French Telecoms Regulatory Office ARCEP: After the fourth mobile network operator Free has just recently started their service in France, there were some complaints from the competition that Free would switch off some of their base stations so that the traffic would be handled by their national roaming partner. I could go into why complains were heard but the much more interesting thing is that ARCEP has launched an investigation and has concluded in their result available here that Free continues to fullfil their regulatory requirement of covering 27% of the population. Interestingly enough they mention with how many cell towers they do that: 735.

That is an incredibly small number. In comparison, Vodafone Germany stated in 2009 (long ago in telecoms land) that they had 20.000 GSM base station deployed in Germany and 13.000 UMTS base stations (in a country that is smaller than France by the way but has more inhabitants, to be fair). One of the highest population densities in France is most likely Paris, with around 10 million people living there, or around 7% of the population. To cover 27% of the population means covering around 4 times the area of Paris. With 735 cell towers? Wow, cell sizes must be quite large and I can imagine that mobile devices keep hoping between the Free network and the national roaming partner frequently even while in the Free coverage area.

It also shows that Free still has the major part of their network deployment still in front of them to meet their next coverage target of 75% of the population by January 2015 (3 years from now) and 90% in January 2018.

And on a closing note I found it quite interesting and I had to smile a bit that ARCEP pointed out that it's the incumbents who where actually those who in the past did not meet the regulatory coverage requirements they agreed to.

Back in June 2011 I ran some speed tests at home in Cologne to see where my 64QAM capable HSDPA category 14 stick would take me in terms of downlink performance. The result was 16 MBit/s which went far beyond the already breathtaking 11 MBit/s I measured the year before when the higher order modulation was not yet switched on. In the meantime, dual-carrier HSPA has been activated which can bundle two 5 MHz downlink carriers. And with a HSDPA category 24 device I've reached my next personal HSDPA downlink speed record of 3.7 MB/s, which translates to 30 MBit/s. And this time I didn't run the test over night but in the morning at 7 a.m., so one can assume there was already a little bit of network load from all those people with smartphones going to work. When running the same test during the day I still get data rates well over 20 MBit/s. Have a look on the picture on the left for the details. Previously I usually used files to download that were a couple of hundred megabytes in size. At speeds like this however, they are downloaded much too quickly so I finally switched to 4 GB DVD images. That says something all by itself, too.

You might have noticed that I am usually quite critical of cloud services that interact with my private data. What bothers me with most services is that I loose control over my data as I am no longer in charge where it is stored outside my home, how well it is protected and for what other purposes it is used. Cloud services such as my blog, for example, are excluded from this, obviously as there is no private data here.

Recently I have started using Firefox Synch to keep my bookmarks backed up and synchronized between several devices. I very much like the approach taken by Firefox Synch as all data that leaves my devices and goes through the cloud or is stored there is encrypted BEFORE it leaves my devices. This is how I like it. The cloud is used for a service but my private data is secure and only available to me.

Nothing is perfect, though, my movementts could still be tracked with the IP address given in the quite frequent synchronization requests. But then the synchronization account is not linked to my name or email address or any other personal ID so tracking me personally would require that an attacker would have to figure out the id of my synchronization account first. But I can probably life with that potential threat as that is likely to be very difficult to pull off.

Let me make a bold assumption: Even in 10 years from now, people will still use their mobile device to call each other. Many other forms of communicating with each other have sprung up over the years, SMS, eMail, instant messaging, Skype video calling, Facebook, etc. etc. And I am a heavy user of most of them. Before I call someone I usually prefer other forms of communication, less interrupting, less direct, less intrusive. But still, voice calls remain important to me and I don't see that change anytime soon. But how will I do voice calls in 10 years from now?

Shouldn't be too difficult to figure out, should it? Back in 2008 I wrote a full chapter in one of my books about mobile voice options in the future but which way it would go was still unclear. Now, four years later, I've revisited that chapter and I have come to the conclusion that there are even more options today and even less clarity of were it will go.

For the IMS supporters the way forward is clear. The VoLTE profile for IMS will be the ultimate solution in the future. The road, however, is long and thorny. CS-Fallback will be used by many to bridge the time until VoLTE can be introduced. Good luck with the longer call setup delays. Once VoLTE has launched, Single Radio Voice Call Continuity (SR-VCC) to a circuit switched channel will have to be used by many network operators until LTE networks are really ubiquitous. IMS, CS-fallback and SR-VCC including IMS centralized services, each system is a daunting task to introduce. CS-fallback might be the easiest one. But even here here, complexity should not be underestimated.

Then there is or was (who can say today) the VOLGA approach that reuses the Generic Access Network (GAN) approach to reuse everything of the existing circuit switched voice solution except the radio layer and send everything over IP, no matter whether it's Wi-Fi (as in GAN) or LTE (as in VOLGA). It's appeal is its incredible simplicity to implement, no new voice infrastructure but only a gateway box, no new billing system, the current one continues to be used for all subscribers, straight forward implementation in mobile devices with reuse of already existing GAN software, e.g. on Android devices. But it's not loved in the operator world so the best this solution can hope for is its reincarnation.

But perhaps even VOLGA is too much to do in the day and age of ever falling prices for voice minutes. So how about dual radio phones? One baseband for the data and one baseband for telephony. The HTC Thunderbird LTE smartphone sold by Verizon for example has gone this way. It's the first of its kind, so its bulky and power hungry. But look at early GSM or UMTS phones, they didn't win exactly prices for slimness or power efficiency. So there is reasonable hope that over time, even dual radio designs can become small and power efficient. But it would mean that "legacy" infrastructure would have to be kept and maintained indefinitely. Perhaps it has to be kept anyway to support those people just wanting a 10 Euro phone for voice and SMS. Yes, there will be fewer people in the future buying such phones but I predict it will still be a sizable group. And then there's all the M2M equipment in embedded systems and perhaps cars in the future with eCall in Europe. No way that in the next 15 years, the infrastructure required to communicate with those devices goes away. So perhaps dual radio will reign?

Or should perhaps Apple with Facetime or Microsoft with Skype become the standard voice and video solutions on PCs and mobile devices? Great, I can't call my friends with an iPhone anymore and vice versa. But perhaps Apple and Microsoft strike a deal and make a gateway between their worlds. I wouldn't count on it. Also, while networks are built like they are built today, especially in the US, over the top voice services will continue to be unreliable at best over mobile infrastructures and drop as soon as you run out of LTE or HSPA+ coverage. So I don't think that's going to be the ultimate answer either.

There's no single solution I look at today from which I would say, 'yes, I'm sure this will be the main telephony service in 10 years from now'. So perhaps a little bit of everything? Or will one of the solutions be able to overcome its weaknesses? From my point of view, the most difficult thing to predict in mobile today is how telephony will work in 10 years from now. Compared to that, everything else is a piece of cake.

Tablets or pads, an interesting new device category since Apple has launched the first iPad back in April 2010. Many manufacturers have followed since then, mostly with Android as an OS or Amazon with their pads designed primarily designed for reading books. And Microsoft is trying hard to launch a pad of their own in 2012. Their approach is radically different than that of Apple or Google, however. They are literally on the other side of the power divide. Let me explain:

The software used by Apple and Google for pads come from the low end of computing, from smartphones. Smartphones are optimized for power consumption, they have a low power CPU, low power components, low power everything and from the outset, the operating systems were designed for that. There might have been more power optimized OSes out there such as Symbian, but nevertheless, I would dare to say that iOS and Android were specifically built from scratch to adapt to this environment. No legacy baggage and apps are trailing behind even though they are built with operating system kernels once designed for the desktop PC, e.g. Linux in the case of Android. But the kernels where shrunken, unnecessary parts removed, the graphics subsystem designed from scratch, etc. It was these operating systems which were then subsequently used as the basis for pads.

From a user's point of view, the user interface on smartphones and pads running the same operating system look pretty similar and apps written in a sensible way to adapt to different screen sizes run on both types of devices without modification. Pads might have the screennsize of netbooks or even small notebooks but they have to be light, which severely limits battery capacity. Consequently the processors used in the tablet are more or less the same as those in smartphones. And it shows when the processor is asked to do complex tasks such as rendering graphics intensive web pages with lots of flash included. Such web pages are rendered more slowly compared to on a PC and scrolling is not as smooth. Sure, you could put in a faster processor but that would come at the expense of how long the device will run on a single battery charge. And, also not to be underestimated, when power consumption rises, so does the heat generated which is immediately noticed negatively by the user. So it's a compromise which works well in most cases but here's the dividing line to netbooks and notebooks and their operating systems: Power

Now back to Microsoft: They are trying something different here which is a good thing as more of the same probably won't work for them, the competition is already there for two years and has a massive lead. What Microsoft is trying to do is to scale down their Windows OS to run on the ARM platform. And more than that they want their Office Suite and other desktop programs to run on ARM as well. Great, get an additional Bluetooth keyboard and you've got a replacement for your notebook!? I remain skeptical that it will work out like that anytime soon for a number of reasons: First, there is the power divide again. Office runs more or less smoothly on high power Intel platforms but how will it perform on a platform that has only a fraction of that processing power by design to conserve power? Secondly, it's a question of the user interface: On a tablet, I like big buttons so I can hit them reliably with a finger. Also I like an app to use as much of the display as possible because while I still multitask on a tablet it is much more limited compared to a PC where I have a keyboard and a mouse and tend to be more in creative mode rather than consuming mode. In creative mode I like a taskbar so I can switch between many applications instantly without holding a menu button for a second, etc. I also like small buttons because sometimes I have several windows open on a small screen and that only works if the applications can run in smaller windows. And with a mouse, that's not a problem, it's an advantage. So a tablet user interface for consumption is very different from an interface for creation.

Microsoft is addressing both things. The link above describes in detail how they are working on the power consumption. And with their consumption focused tile UI first introduced with Windows Mobile, whether you like the design or not, which is intended to run alongside the traditional user interface in Windows 8 on the PC (and tablet) as well, that is taken care of, too. iOS and Android don't have that so far, they are coming from a different direction. So how well will this work for Microsoft? I think there is a certain appeal to replace a netbook with a tablet + keyboard + mouse but only if the UI is right for creation in multitasking mode. Good, that is covered. So it ultimately boils down to power consumption vs. processor speed. I am not sure there is a sweet spot there yet that will ultimately satisfy those who want to use a pad for more than just with their fingers to consume information. Eventually it will come even if it takes some more years until power consumption is further optimized. And I'm pretty sure that by then others will have a UI as well to address those who need a keyboard, creative multitasking and a mouse.

So where does this leave Windows Mobile? For the moment, as far as I can tell that OS is pretty much developed and evolved on its own on the other side of the power divide. With Windows on ARM, Microsoft pretty much says that it will not attempt to jump over to a tablet with Windows Phone. Seems to be a lonely life down there and perhaps a short one should Microsoft succeed and shrink their Windows kernel to run on tablets. After all, it's the same processors running on tablets and smartphones.

One approach to deploying LTE without packet switched voice call functionality at the beginning is to instruct mobile devices to use a 2G and 3G network when the user makes or receives a voice call and return to LTE afterwards. This solution is referred to as CS fallback and has been specified in 3GPP TS 23.272.  As it's likely that it will be deployed over time in quite a number of networks and used over many years, I thought I have once again a closer look at the specs and write a little primer about it. A little warning: This is somewhat of a propeller head post which requires some background knowledge on the circuit switched core network of GSM and UMTS and how LTE works.

SGs, a new interface between the circuit switched core and the LTE network

In principle CS fallback connects the Mobile Switching Center to the LTE Mobility Management Entity (MME) via the new SGs interface. The name and functionality of this interface is similar to the already existing optional Gs interface between an MSC and a 2G or 3G SGSN. In some networks this interface is used for paging and location updating synchronization between the circuit switched and packet switched core network to reduce the signaling load and, in case of GSM, to be able to signal an incoming voice call to a mobile device that is currently busy on the packet switched side.

Preparations

When a mobile device is CS fallback capable it initially performs a combined CS+PS attach to the LTE network. This informs the network that the mobile device wants to use circuit switched services in addition to IP based services over the LTE network and is capable of falling back to a 2G or 3G network for incoming and outgoing voice calls. The MME then performs a location update on behalf of the mobile device over the SGs interface with the Mobile Switching Center and the HSS. This MSC is referred to as the SGs MSC below to distinguish it from other MSCs that might also become involved during the CS-fallback procedure. If successful it signals to the mobile device that it has been registered in the circuit switched network as well and that incoming calls will be signaled to it.

Incoming Calls – Mobile Terminated Calls

When an incoming call for the subscriber arrives at the Gateway-MSC, the HSS is interrogated for the location of the subscriber. The HSS then returns the information to the G-MSC that the subscriber is currently served by the SGs MSC. The call is then forwarded to the SGs MSC. The SGs MSC will then send a paging message over the SGs interface to the MME which will in turn inform the mobile device and require it to leave the LTE network to accept the incoming voice call in a 2G or 3G cell. The mobile device will then do as instructed and start communication over a GSM or UMTS cell.

Moving from one radio technology to another can be done in several ways. The basic scenario is a redirect in which the network gives the mobile device an instruction to select a different radio network. The instruction can contain information about the target cells to reduce the time it takes the device to find a suitable cell and establish communication. In a more advanced scenario, a full Inter-radio access technology (IRAT) packed switched domain handover from LTE to UMTS or GSM is performed which is prepared in the network and thus the interruption time is lower. In this scenario, the network can instruct the mobile device to perform radio measurements. The results of those measurements are then used by the network to select a suitable target cell and give the mobile device precise instructions of how to quickly get to this cell to minimize the handover time.

The thing with the location area

If the GSM or UMTS cell is in a location area that is different from that in which the mobile device is currently registered, a circuit switched location update procedure is required before the call can be forwarded. This could be the case, for example, if the SGs MSC connected to the MME is not controlling the GSM or UMTS cell to which the UE is transferred. This could happen in case the mobile device has selected a cell other than the one intended by the network, e.g. in areas with a location area border, or in case only a single MSC is SGs capable and hence acts as a mere relay for signaling messages rather than a switching center to which cells are directly connected.

In case of UMTS or GSM Dual Transfer Mode, the packet switched context can also be moved so any packet switched communication can continue while the voice call is ongoing. This is important, for example, so email push and other applications can continue running in the background while the voice call is ongoing. Also, this allows users to continue using other web based applications during the phone call, e.g. searching for some information on the web during the call, etc.

In case the SGs MSC does not control the 2G or 3G cell it is necessary that the SGs MSC redirects the voice path that has been established between the Gateway-MSC and itself to the MSC controlling the cell. This is done with the help of the location update procedure which is invoked as described above. Part of the location update procedure is to inform the Home Subscriber Server (HSS) of the change in location. The HSS in turn informs the SGs MSC that the subscriber has changed the MSC area. The SGs MSC then informs the Gateway MSC of this change with a ‘roaming retry’ message as specified in 3GPP TS 23.018. The Gateway MSC then removes the speech path to the SGs MSC and establishes a new link to the new serving MSC. What I m not quite sure about is whether the roaming retry is actually used today in practice for other purposes already. If you have some details about this, I'd be quite interested.

If a location update was necessary the mobile terminated call is delivered immediately after the procedure has finished. To make the MSC aware that a circuit switched call is waiting for the mobile device after the location update it includes a CS-fallback (CSMT) flag in the location update message. This flag allows the MSC to link the location update and the call delivered by the Gateway MSC. In case no location update is required, the mobile sends a paging response message to the MSC, which has the advantage that the call can be established more quickly.

Outgoing Calls – Mobile Originated Calls

When the user initiates a mobile originated call, the mobile device contacts the network with an Extended Service Request message which contains a CS fallback indicator. The network then decides based on its capabilities and that of the mobile device to either perform:

• A packet switched handover to a GSM or UMTS cell, which is the fastest way to move the mobile device to a radio infrastructure from which the circuit switched call can be initiated.

• An RRC release with redirect to GSM or UMTS, optionally with information about possible target cells to decrease the time necessary to find the cell. This is somewhat slower than a handover as the mobile device is required to reestablish contact to the UMTS network on its own without help of the LTE network.

• An inter-RAT cell change order to GSM. Optionally, the network can include information on potential GSM cells in the area (Network Assisted Cell Change, NACC)
  Contacting the network prior to leaving the LTE network is necessary so the mobile device’s context in the LTE base station (eNodeB) can be deleted and to get additional information on potential target cells to speed up the process.

Supplementary Services

The fallback mechanism to GSM or UMTS is also used for supplementary services based on Unstructured Supplementary Service Data (USSD) messages which are used for modifying parameters such as call forwarding settings, or querying the amount of money left on a prepaid account.

SMS Messages

Delivery of SMS messages, however, does not require a fallback to a GSM or UMTS network. This is because SMS messaging is not based on USSD and is not a service implemented in the MSC. Instead, the SGs MSC can forward an SMS message it has received from the SMS Service Center (SMSC) to the MME via the SGs interface. The MME will then deliver it to the mobile device via MME to mobile device signaling messages that are transparent to the eNodeB. Mobile originated SMS messages can be delivered in the same way in the other direction.

International Roaming

As CS fallback is not a Voice over IP technology, it is likely that it will mostly be used in LTE networks before VOLTE becomes available. Furthermore, CS fallback can be used as a backup solution in roaming scenarios in which voice capable LTE devices are roaming in a foreign LTE network in which VOLTE is not available or in case no roaming agreement is in place for IMS voice services.

Pros and Cons of CS fallback

The main advantage of CS fallback is that it will enable network operators and device manufacturers to introduce LTE devices with a single cellular radio chip before VOLTE becomes available and network are deployed widely enough to prevent having to hand over the call to UMTS or GSM too often (how that is done is another story).

The downside of the approach is the increased call setup time required due to the change of the access network and the potential location update procedure that is required in case the new cell is in a different location area before the normal call establishment signaling can proceed. For LTE to LTE CS fallback voice calls, the extra call establishment delay is even doubled. In other words, the extra call establishment time is likely to be noticed by the customer who expects new technologies to work better than the previous ones and not worse.

Alternatives

An alternative to CS fallback is to use dual radio mobile devices that use LTE for data only while it is available and a legacy network for voice calls and also for data once the user roams out of the LTE coverage area. Verizon, for example, is doing this today, perhaps because it was one of the first LTE networks and needed LTE capable mobile devices including voice early on to relieve the strain on its aging CDMA network. If this approach works well enough they just might hold on long enough until their LTE network is dense enough to introduce VOLTE and skip CS fallback altogether.

For UMTS network operators, however, there is little incentive at the moment to go to dual radio devices as they still have ample data capacity in their UMTS networks. As a consequence, they have launched their LTE networks mostly with data only devices. For them, CS fallback might be the better alternative unless the additional call setup delay time becomes annoying. There are several deployment options that influence the additional time required to set-up the call so it's going to be interesting who will do what to reduce the delay.

Summary

CS fallback sounds easy but from the description above I think it is quite clear that it is not quite that. A new interface to be implemented in the MSC software and the MME, the use of roaming retry functionality that is not used so far (please correct me if I'm wrong) and the new CS fallback flag in the location update message will keep network and device engineers busy for a while. A lot of effort for a "temporary" solution.