WirelessMoves

Back in 2009 I published the first edition of my Beyond 3G book giving an introduction to the technology of wireless networks, capacity forecasting, mobile voice, mobile device hardware and also the software running on them. It's been a tremendous success so I decided to update it and publish a second edition with a slightly changed title to address the launch of LTE networks: "3G, 4G and Beyond – Bringing Networks, Devices and the Web Together".

It is quite amazing what has changed since 2009. Many of the predictions I have made at the time have become a reality and new challenges and opportunities have arisen. While LTE was only on the distant horizon when the first edition was published, it is a reality today and HSPA networks have undergone a significant evolution as well. New spectrum bands have been assigned and auctioned in the meantime and many network operators around the globe have since made use of them to increase the coverage and capacity of their networks.

Perhaps the biggest evolution over the past five years has been on the mobile device side. Mobile operating systems dominating the market only a few years ago have almost vanished and new entrants such as Android and iOS have taken the mobile world by storm. On the web and application programming side, significant advances triggered an update of this chapter as well and I've even included a section that introduces Android programming to the reader.

As a consequence, about half the content of the previous edition of this book was updated or entirely rewritten to reflect the current state of the art and to give an outlook of what is to come in the next five years.

It's been fun and, needless to say, a tremendous amount of work to radically update the book this way. But besides staying up to date in all the different areas discussed in the book it's been an interesting way to experience the change of 3 years in one effort. As always, comments are very welcome and I am looking forward to the changes coming in the next couple of years.

Before the German LTE spectrum auctions almost exactly three years ago, pretty much everyone I talked to agreed that the 2600 MHz range is the beachfront property for LTE due to the large 20 MHz channels it was offering. Yes, 800 MHz spectrum was interesting as well but not very much loved due to the obligations to deploy on the countryside first. Few people spoke of the 1800 MHz band and actually saw it as a side show. Fast forward to 2013 with three LTE networks now deployed in Cologne where I live. Two of the three networks run on 10 MHz channels in the 800 MHz band because countryside coverage obligations have been met. And the third one is using a 20 MHz channel with twice the speed in the initially little observed 1800 MHz band which has drawn a lot of attention in the meantime all over Europe. And what about the 2600 MHz beachfront property? Nowhere to be seen for the moment. An interesting change of tides.

Telegeography has recently published an update of their zoomable submarine cable map with chronological information and overall lit capacity. Especially interesting for me is the the graph at the bottom which shows a sudden strong increase of used (lit) capacity in 2007 and onwards compared to previous years. To get political for a moment, I also found it quite interesting that the name of the state of Isreal is missing on the map while even small countries such as Luxembourg have their name on the map!? I wonder if that has something to do with the sponsor? Back to technology: For more detailed information on individual cables I can also recommend Greg's cable map and for some technical nuggets have a look at my post from back in January 2012.

One of the limitations of Solid State Drives is that the Flash cells can’t be rewritten indefinitely. The cells on the SSD drive I recently bought can only be rewritten around 1000 times. That doesn’t sound like much but wear leveling ensures that desktop users with normal use don’t have to worry about it. AnandTech has a good analysis on how wear leveling works and how long I should be able to use my SSD here. According to these calculations, my 500 GB version should be good for at least 14 years, based on a daily write amount of 10 GB and and a write amplification factor of 10. So while I believe those numbers I was wondering how how much data I actually write to disk on average per day. As I use Ubuntu Linux I found a couple of interesting counters that shed some more light on this:

The first one is /proc/diskstats. It lists all block devices and lots of counters for them. For my SDD which is the ‘sda’ device in the list, field 7 contains the number of sectors written since boot time. A sector is 512 bytes so one can easily calculate the number of bytes written since power on.

The second is /sys/fs/ext4/sda1/lifetime_write_kbytes. As the name suggests this counter contains the overall total and is only available for ext4 formated volumes. Since I only use one volume and no swap partition (due to my 8 GBs of RAM) these two counters should actually increase by the same value over time.

Here’s a command line displays both counters and strips away all other information the commands also output:

date; awk '/sda/ {print $3"\t"$10 / 2 / 1024}' /proc/diskstats; cat /sys/fs/ext4/sda1/lifetime_write_kbytes

The result: I am using this computer for about half a year now and the total lifetime writes give me 922 GB. Divided by approx. 180 days, that’s approx. 5 GB of data written to the drive per day on average. The data written since power on gives me a similar value, around 4 GB per day. Comparing that to the 10 GB a day used in the AnandTech post for estimating my SSD lifetime, I should be good for twice their calculated amount, i.e. no write issues due to wear out of the flash cells due to writing for the next 30 years. A comforting result.

So while it is comforting that my average daily use is less than what was used in AnandTech’s caclulations, I’d still like to understand a bit better why my daily average is around 5 GB of data written to the drive as it seems to be quite a lot and I am not using the drive (or the sda1 volume queried) for memory swapping at all.

This post over at the radio access blog has made me think a bit of how many users in Cell-DCH state could be supported simultaneously on HSDPA. As the post analyzes correctly, each user requires a Dedicated Physical Control Channel in the downlink direction with a spreading factor of 256. That means that there are a maximum number of 256 such channels that could be used but unfortunately that wouldn't leave spreading codes for any other use, including the high speed data channels themselves. So in practice there must be significantly fewer users to still have enough codes for other purposes such as the HS channels and also for voice calls. So we end up with quite a small number and it will be more and more difficult to serve the 2000 subscribers with 3 sector base stations if there can only be a fraction of them active at the same time. So fast forward to the fractional DPCCH feature also described in the blog post above that bundles 10 control channels on a single spreading code and it's quite obvious how significant this feature will become in the future as smartphones and connected apps spread ever further.

Over the years, my Huawei D100 with a 3G stick has done me a good service of distributing 3G Internet access to several devices when I'm traveling. These days, Wi-Fi tethering to a smartphone can do the job as well. But there are some places in the world for which I don't have a 3G prepaid SIM card for Internet access and have to fall back to the Hotel's Wi-Fi coverage. Unfortunately, hotels often only give out a single code for a single device so I resorted of taking a Wi-Fi router with me for using it in combination with my notebook for bridging a single hotel Wi-Fi connection to several devices. This works quite well in practice but the PC has to be powered on all the time and the extra router is obviously a bit bulky. But now I have found the ultimate solution for this problem, the Edimax 6258nL:

Being smaller than a pen (see picture on the right) and powered out of a USB port of a PC or a standard USB charger it does all for which I so far used the notebook and the extra Wi-Fi access point for: It acts as a Wi-Fi client to the hotel Wi-Fi and then distributes this to my devices in a second Wi-Fi network in which it acts as an access point. Network address translation is used between the two, so all the devices just use the single IP address assigned by the hotel network. I tested the device for a couple of days with three client devices and in several host Wi-Fi networks, both non-encrypted like hotel Wi-Fi and encrypted as one would use in other places. It worked fine in all instances. Perfect!

There are lots of identifiers in LTE to identify cells, tracking areas, users, tunnel endpoints, etc. etc. Most are similar to what already exists in GPRS and UMTS but most of them have new names and lengths. While I know some of them that I use regularly, there are quite a number of them that I have to look up every now and then. Here's a good resource that has them all, including a description of how they are related and sometimes part of each other. Enjoy.

Back in 2011 I ran a post titled "Voice over IP – The Move Away from the Baseband" describing how Over-The-Top Voice over IP clients such as Skype do not run in the modem baseband chip as traditional circuit switched voice today but rather on the application processor as an application of Android or another mobile operating system. At the time there were no indications in the public domain that Voice over LTE (VoLTE) clients supporting future network operator voice services would be any different, hence the post's "move away" title. This would have a rather significant impact on operating systems such as Android, iOS, etc., as the integrated voice application ("the dialer") would have to become aware of:

• IMS and VoLTE
• The interworking between VoLTE and traditional circuit switched (CS) voice
• It would have to handle mid-call handovers from VoLTE to CS when leaving the LTE coverage area.

Gone would be the days of just sending a couple of straight forward commands to the modem chip to establish a voice call, to end it and to have a couple of simple commands to manage supplementary services such as call forwarding settings and conference calls. But now it seems things are looking different:

In recent posts on the ST-Ericsson technology blog they describe an approach in which the core of VoLTE, the IMS client and the VoLTE application itself do not run on the application processor but are back in the modem baseband chip. From the information given there I take it that this is not just a concept but something they are serious about to commercialize. The core of that post is around the IMS client in the modem being an IMS B2BUA (Back to Back User Agent, more on this later) but there are a number of other fundamental technical details that are worth thinking about as well:

To have the IMS Client and VoLTE IMS application in the modem baseband chip means that no longer does that chip only transparently move IP packets to and from that application processor. Instead it needs to have a full IP protocol stack of its own now as well. The PDF linked in the ST-Ericsson post above shows how the 3GPP concept of having an IMS signaling APN (Access Point Name) with an IP address that can be separate from the APN and the IP address used for transparent Internet access is handled by the modem based IP stack and the IMS client first. The modem IMS client then forwards the processed signaling to either the VoLTE client, also running on the modem chip or to an IMS client app running on the application processor.

The link to the application processor is necessary as VoLTE may not be the only IMS app running on a device. The RCS-e service that is currently worked on is an example of an IMS app running on the application processor. No special IMS API is required for the IMS app (such as an RCS-e client) on the application processor to communicate with the IMS client (the IMS B2BUA) on the modem as everything is based on an IP connection and the B2BUA concept. 

And in case you have been wondering what a B2BUA is in IMS: Basically the B2BUA sits between an IMS app such as the VoLTE or RCS-e app and the IMS server in the network. Instead of the apps communicating directly with the IMS server in the network, the apps communicate with the B2BUA. The B2BUA then modifies and forwards the messages on the app's behalf. Wikipedia has some further details.

So while all of this sounds a bit complicated it actually makes a couple of things a lot easier. First, it allows to run several IMS client apps simultaneously on one device that all share a single IMS session towards the network managed by the B2BUA in the modem chip. And second, the VoLTE app has moved back into the baseband. That means that all of the complexity of managing the duality of CS voice outside of LTE coverage and using VoLTE while an LTE covered area are hidden away from Android and other mobile operating systems. Also, mid-call handovers between VoLTE and the circuit switched network (IMS Centralized Service, SR-VCC) can be made transparently from the point of view of the user operating system. In other words, the "dialer" app of Android, iOS, etc. can continue to use the same commands as in a CS only device and never notices a difference.

 

With a 20 MHz LTE channel it's quite easy now to fully load a Wi-Fi network. When I recently tested Wi-Fi tethering with an LTE smartphone I noticed that the maximum data rate was caped at around 45 MBit/s despite the LTE network supporting higher speeds. That's about as much as a single 20 MHz 802.11n Wi-Fi channel can transport in a real environment on the IP layer without MIMO. Many access points these days also support the optional bundling of two 20 MHz channels. My Layer 1 Chanalyzer tool showed, however, that my smartphone was not using the option. Not that this is too much of an issue but we've reached a point where the cellular network can be faster than what can be provided locally by the phone to other devices over Wi-Fi.

Here's two interesting statistics from the regulators of Spain and Germany on SMS volumes that completely point in the opposite direction: While the Spanish regulator reports quickly falling SMS volumes since 2008 (see here and here) the German regulator (see here) has reported continued increases year after year with a big increase of 30% in 2011 over 2010.

Very strange disparate behavior and I wonder what the reason for this is!? Perhaps there is no bulk SMS pricing in Spain (probably not)? The first link above points to a post that speculates that IP based messaging is to blame. Interesting hypothesis but no facts are given. So while I can imagine that this is a factor I don't think it's the only one because back in 2008 there was no IP based messaging system used by the masses. Mobile Internet access on mobile devices was still something for freaks…

It will be a few months until the report for 2012 from the German regulator will be available but I will surely have a close look at the SMS numbers and also at the growth in mobile data volumes in the past year (sorry, changing the subject now). Last year, the growth was actually slowing to a factor of 0.5, also contrary to what the media usually likes to report.