Category: Uncategorized

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.

A new personal Internet access speed record while traveling: When I was recently staying at a hotel somewhere in the middle of Germany I could reach a steady download rate of 40 Mbit/s while downloading a video file of around 1 GB. At that data rate the file was download in just a couple of minutes which easily dwarfed my 25 Mbit/s VDSL line at home. For a 10 MHz LTE channel in the 800 MHz digital dividend band that's quite something!

In a previous post I have given a high level overview of how Wi-Fi direct works. This follow up post now goes one step further and shows how a Wi-Fi direct connection is established between two devices. Unfortunately the Wi-Fi direct specification is not freely available (poor behavior by the Wi-Fi alliance in my opinion). However, for those of you who'd like to dig even deeper I can recommend these pages on the Microsoft developer network. Also, Wireshark comes in handy for tracing the connection establishment process, and my findings below are based on these.

From a protocol point of view a Wi-Fi direct connection is established using already existing mechanisms in a number of steps:

In a first step, the two devices that are to connect directly have to find each other. This is done by sending standard Wi-Fi probe request and response frames that include the Wi-Fi direct specific generic SSID “DIRECT-” and further Wi-Fi direct capability information. A device answering with a probe response frame uses the same SSID and includes vendor specific tagged information elements to also identify itself as a Wi-Fi direct device and gives further information such as its direct mode capabilities, device type and a name in readable format that can be presented to the user.

During the following Service Discovery phase the devices can then optionally exchange higher layer service information via Provision Discovery Request / Response action frames that carry information supplied by UPNP , Bonjour and other higher layer protocols. Action frames are Wi-Fi management messages and are used as no IP connectivity between the devices exists at this point in time. This allows devices to inquire about services offered by other devices before connectivity is established. The procedure is optional, however, and it can be observed in practice that it is not necessarily used.

Once the user of one of the devices has decided to establish a direct connection it is necessary to decide which device should play the role of the Group Owner (GO), i.e. which device should become the access point. This is done during the Group Owner Negotiation procedure: Again, Wi-Fi management messages (action frames) are used to perform this operation that consists of a three way handshake. In practice it can be observed that the device that is contacted by another device sets the negotiation parameters in a way that it becomes the GO.

After the three way handshake the GO device will reconfigure its Wi-Fi chip into access point mode. The other device waits for beacon frames being broadcast that includes an SSID with a Wi-Fi direct identifier and the name of the other device that was also contained in the earlier probe response frame. Once these are found the device performs and Open Authentication and Association Request as per normal Wi-Fi procedures. Next, security parameters are negotiated via EAP and EAPOL messaging. These protocols are also used during ordinary WPS (Wireless Protected Setup) security context negotiation, i.e. existing functionality is re-used for this step of establishing a link as well. Once the security parameters have been exchanged, a standard WPA2 connection is established between the two devices.

In a final step, the client device requests an IP address from the GO access point in the same way as it would request an IP address form a standard access point. Once the IP address has been acquired the Wi-Fi direct link is established and can now be used by higher layer applications. As the connection is based on the IP protocol applications can work over Wi-Fi direct networks and also over traditional Wi-Fi access point based networks without any modifications to this part of the application logic.

And a quick afterthought to my general comparison post on Wi-Fi Direct vs. Bluetooth. With Bluetooth 3.0 a feature called 3.0 HS was introduced to couple Bluetooth for authentication and initiation of the connection and Wi-Fi for transfer of the actual data. Published at around the same time as Wi-Fi direct (see my posts here and here from back in 2010) I don't see it implemented in any of the major smartphones today. Quite a pity as this would fix the issue with the missing profiles for standardized exchange of files. At the moment 3.0+HS very much looks like a feature that runs in the "nice idea but never implemented" category.