Author: Martin

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.

For many years SSD drives were prohibitively expensive and had a far lower capacity than hard drives so I had little desire to get one for my mobile computing equipment. But in 2012, SSDs finally reached a price level that made me change my mind. At the moment, a 500 GB Samsung SSD is available for around 300 euros so I finally decided to buy one.

While I expected a dramatic improvement in OS boot and program startup times I was nevertheless still surprised when I finally experienced it myself. Installing a full Ubuntu on it in less than 15 minutes was breathtaking. After I've put a 1:1 copy of my hard drive on the SSD with Clonezilla I could again hardly believe it was still the same PC. The OS boots much faster, programs open almost instantly and a full Windows 7 in a virtual machine boots in 25 seconds to the desktop with disk activity ceasing. And all of this with an entry level Intel i3 processor. I found some reports on the net that SDDs are more power hungry than hard drives but I can't confirm that with my notebook, I still get around 4.5 hours out of the battery.

As it's likely that SSD prices will fall further over time I don't think it will take long now before hard drives are replaced by SSDs not only in high end PCs and notebooks but also in in the medium range, i.e. the 600-800 euro range. After my recent experiences one thing is fore sure: I'll never have a personal PC without an SSD anymore, the difference is just so significant. Which makes the fan the last mechanical part in a notebook. But perhaps that will also be taken care of soon with fanless Ultrabooks being talked about for some years now.

And here's the review of the drive I bought over at Anandtech.

And another LTE success story today: When recently traveling in rural areas in Germany I knew, but was still surprised, that LTE is available in many remote places. This is due to the rules of the 2010 spectrum auction that required mobile network operators to deploy LTE in the 800 MHz band in rural areas first before they could move on to bigger cities. And this has indeed been done as I noticed that LTE was available in many places where 3G was absent. That, for example, solves lack of cellular Internet coverage I have experienced in the past at many remote highway restaurants that were so far only covered by GSM networks. Quite a different experience this time around. Great!

This brings to mind a recent blog post over at Stephen Temple's site about the three goals that a government can achieve by assigning spectrum:

• Money for the treasury
• Improving network coverage
• Lower prices for consumers

Obviously these goals are at odd with each other and it's in a government's hands to balance and steer the result, e.g. by doing an auction and by setting the right rules for the auctions and deployment afterward. In the case of Germany, the requirement to deploy in rural areas first has significantly benefited national network coverage. Prices for telephony and Internet access are not the lowest in Europe but, from my point of view, on an acceptable level. And as far as money for the treasury was concerned, they didn't go away empty handed either. To me that looks like a good balance.