Author: Martin

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.

Wi-Fi Direct (formerly Wi-Fi P2P) is appearing in more and more smartphones these days and despite not having used it so far for anything useful I thought I'd investigate a bit more to see how it works and how it differs from Bluetooth in addition to the obviously higher data transfer rates.

Unlike many other Wi-Fi functionalities, Wi-Fi Direct is not specified by the IEEE. Instead, the Wi-Fi Alliance, best known for it's Wi-Fi certification program and logo, was responsible for the feature. It's not their first one, they were also the driving force to fix the WEP encryption issue many years ago with WPA and later WPA2. Also, they have defined the set of rules for Wireless Multi Media (WMM) and other options in the IEEE standards to ensure the implementation of a minimum set of features and interoperability between devices.

In essense the Wi-Fi direct feature is straight forward. While traditional Wi-Fi networks require an access point for devices to communicate with each other, Wi-Fi direct allows two devices to communicate with each other without a dedicated access point. Instead, one of the two devices assumes the role of the access point and becomes the Group Owner (GO) of the Wi-Fi direct network. Other devices, even non-Wi-Fi direct devices, can then join this group as the GO behaves just like a standard access point.  This means that the GO device also includes DHCP functionality to assign IP addresses to clients of the group network.

Once the Wi-Fi connection is established and an IP address has been assigned the standard TCP/IP protocol stack is used to transfer data between devices. And this is the biggest difference between Bluetooth and Wi-Fi direct. While Bluetooth defines profiles for transferring images, business cards, calendar entries, audio signals, etc., Wi-Fi direct itself only offers a transparent IP channel. To transfer data between two devices, compatible apps are required.

The advantage of this approach is that those apps can work in Wi-Fi direct networks and also in traditional Wi-Fi environments. A TV, for example, that is capable of traditional Wi-Fi and Wi-Fi direct can run a server application to receive pictures and video streams over both Wi-Fi variants. The home owner would stream his material over the traditional Wi-Fi network while visitors would use Wi-Fi direct to skip the somewhat complicated process of joining the local wireless infrastructure network.

The disadvantage of this approach in the example above is that the visitor has to first download a client app that can communicate with the server app on the television. While this might be acceptable for the scenario above, it's too complicated for just exchanging a few images, files or contacts on the go between two smartphones. Perhaps Google will add such apps to Android in the future to make this easier but this wouldn't help transferring files to the iPhone, Blackberries, Windows Phone, etc. This is where Bluetooth still shines due to its standardized profiles which are implemented on many operating systems. This is a bit unfortunate as transferring multimedia content between different mobile operating systems would definitely benefit from fast Wi-Fi transmissions due to ever increasing file sizes and the practical transfer speeds of Bluetooth of only around 2 Mbit/s.

In practice, Wi-Fi direct has arrived in Android smartphones today but is not really noticed so far. The Android OS offers an API for apps from version 4 of the OS to scan for Wi-Fi direct devices and then to establish a connection. That offers interesting possibilities for ad-hoc communication, such as for example local multi-player games. Think kids in cars on a long road trip…

When I recently used an Android 4.x device I noticed that some applications such as the calendar and the image viewer have a printing option. As I have two network printers in my Wi-Fi network at home I was curious if and how this would work.

To my surprise both printers were instantly usable without configuration. When the printing option is selected, Android searched for printers on the network and within a few seconds presented both my network printers, an old HP Photosmart C7280 and a somewhat newer Samsung MW-2525W laser printer. And both worked without any further configuration. Interesting, I thought, how is that possible!? When looking at what Android configured for the printers, I noticed that it uses port 9100 for communication with both. So perhaps it uses the Page Description Language (PDL) in one of its forms as described here? 

I know there's a myriad of third party printing tools that will print just about anything from an Android phone these days. But from a security point of view I am a bit hesitant to allow third party tools I don't now much about to handle my documents.

It seems there is no native printer API in Android 4.x at the moment so both the calendar and image application must have proprietary built in printer support. But it's a start so perhaps we'll see more general Android built in printer support in the future!? Especially for tablet style device this would surely be appreciated by many

Combined GSM/UMTS/LTE base stations require a fat backhaul pipe today so traditional means of connecting them via one or more 2 Mbit/s E-1 links is no longer an option. A UMTS base station can see peaks of over 30 Mbit/s in a sector in the downlink direction and for LTE, the peak for a 20 MHz carrier is well over 80 Mbit/s. Combined and averaged over the three technologies and three sectors (GSM requires only little compared to those numbers) there are only two real options for connecting base stations in the age of high speed wireless Internet access: Fiber or microwave Ethernet.

Fiber sounds great but I guess it must be a challenge to connect base station sites via fiber in practice. But it seems this problem is being worked on, especially by those network operators also owning fixed line assets. A1, the former state carrier in Austria is now reported to have have connected over two thirds of their base station sites via fiber. Quite a significant number that should prevent backhaul bottlenecks well into the future.

Austria is walking down on an adventurous path after the EU has granted Three Austria to take over Orange Austria accroding to this report. From the once five networks in the country only three now remain and from my point of view there is a big questionmark whether three network operators will be enough to ensure healthy competition.

Countries such as France and Belgium who only had three network operators (Belgium still only has three) are far from being islands of good prices and competition in the EU. Let's hope, the terms and conditions of the takeover will prevent a similar fate. And those conditions are actually quite interesting because Three Austria now has to offer Mobile Virtual Network Operators access to its network at least for the following prices:

• Price per voice minute: 1 euro cent
• Price per SMS: 0.4 cent
• 1 Megabyte of data: 0.16 to 0.2 euro cent (up to 30 Mbit/s)

Alternatively, an MVNO can get 25% rebate on the tarrifs offered by Three itself.

0.2 euro cents per megabyte, that's 2 euros per Gigabyte of data traffic. Interesting, I pay 10 euros for 180 MB of data in France on a prepaid SIM. Hm, that's around 25 times more…

So while those prices are certainly very cheap I wonder how these prices will look like 5 years from now and how competitive the networks will be then!? After all, it's now only a competition between three physical networks no matter how many MVNO's will use Three's physical network.

By now you've probably heard about Ubuntu having announced a mobile phone edition of their operating system / user interface. Here's a link to the industry proposition video on Youtube that gives a first glimpse of the user interface and their broader idea behind a similar user interface of phone, PC and TV.

Unlike the PC variant, Ubuntu phone seems to be based on an Android Linux kernel and driver environment. In addition others report that native apps written in C/C++/Qt/QML and Web Apps written in HTML5 and Java Script can be fully integrated into the desktop environment. This is different from Android where apps are written in Java and run in Dalvik, a virtual machine, and little interaction between the desktop environment and web applications is possible at the moment. Furthermore, the video mentions the same API for desktop integration of web apps on the phone and PC desktop.

The intriguing part for me is that Ubuntu promisses to create an open source alternative to the current Apple/Google smartphone duopoly. Sure, Google's Android is also open source but something with fewer ties into Google's cloud services is something that is quite appealing to me as I like to keep closer control over my own data. What remains to be seen, however, is how much Ubuntu wants to get my data into their cloud and if alternatives are offered.

Technical details are sparse at this point but I'll surely take a look once they become available.

While my Wi-Fi access point / VDSL router at home was so far limited to a single 20 MHz channel in the 2.4 GHz band I was surprised that after a recent software update for getting better file sharing abilities has also resulted in a much improved throughput in the 2.4 GHz band. When copying a large file from one PC to another I noticed that the aggregate throughput was suddenly around 80 Mbit/s. A layer 1 Wi-Fi trace confirmed the assumptions as shown in the screenshot on the left. While my Wi-Fi card easily detects 20+ networks, the layer 1 trace reveals that they were not heavily used. Another thing that was fixed by the update was the interoperability I had for almost two years with my Nokia N8 and that Wi-Fi router. For some reason, the power save mode on the N8 slowed the Wi-Fi access point down to a trickle. The only solution so far was to disable the power save mode on the N8 or only running 802.11g on the access point. With this software update the issue has disappeared so they must have fixed it. Quite a long time for a fix but better late than never.

To predict 10 years into the future is a very long time in technology but perhaps a look back will help.

Let's zoom back to 2002. At the time there were only GSM and GPRS networks deployed in Europe. Mobile was was already ubiquitous but mobile data was just at the very beginning with a data rate of just a few kilobits per second over the air. UMTS was already standardized in Release 99, with efforts having started in the mid 1990's, but networks were not available yet. UMTS HSDPA was standardized in the 2002 timeframe when networks were not even launched and the uplink part HSUPA followed in 2004. In other words, the wireless technologies we are using today were first thought of about 12 years ago and then put into standards which were finalized around 10 years ago. Wikipedia has a good overview of which 3GPP Release was published when. LTE networks have launched in the meantime as well and their standardization started in 2004, even before I had my first UMTS phone, as described in further detail here.

With that in mind, let's have a look what's currently being standardized by 3GPP. Unlike 10 years ago, no move to a new revolutionary air interface technology is on the agenda like the move from GSM to UMTS previously. So the acronym LTE (Long Term Evolution) holds true to its name so far. The reason for that is that with LTE all angles of increasing data transfer rates are being explored. Ever higher modulation and coding schemes, MIMO, sectorization, beamforming and carrier aggregation across diffrent bands are possible from a standardization point of view and only the hardware implementation and physical nature of the radio channel are the limit. This is different to GSM with its focus on 200 kHz (0.2 MHz) channels and its voice centric timeslot design. Also, UMTS came to its limits in the frequency domain with its 5 MHz channels. The standard evolved over time to allow carrier aggregation and many networks and some device implement the dual-carrier variant by now. But several carriers was not in the mind of engineers from the beginning so aggregating more becomes cumbersome from a protocol point of view. As everyone is going to LTE anyway I doubt we'll see more than two carriers aggregated in the future.

So without any other air interface technology currently in the specification phase it's pretty certain that the networks we'll have in 10 years from now will still be based on LTE. LTE macro networks are still being expanded, however, so the LTE networks 10 years down the road will be much more ubiquitous than today and also much more dense in metro areas to satisfy the increasing demand. While in the US most networks use a 10 MHz LTE carrier today and 20 MHz carriers are used by many networks in Europe, most network operators have bought much more spectrum and will start using it once more capacity is needed. Whether channels will mostly be used independently and users are scheduled on different channels and bands depending on the channel load and local transmission conditions or whether mobiles will be able to aggregate channels beyond 20 MHz is, from my point of view, not quite clear. The standards exist to aggregate several 20 MHz channels but if this will happen in practice is another matter. But hardware evolves and when looking back 10 years and what radio interfaces of mobile devices were capable then (remember, there wasn't even UMTS at the time in practice) I guess one should never say never.

Except for using ever more spectrum, other angles of approach to increase the capacity of the network without increasing the highest data rate achievable by mobile devices is to use techniques such as using 6 instead of only 3 independent sectors per base station and to bring beamforming technologies to fruition that concentrates the available power during the transmission of data to a particular user into his direction.

What I think that we won't see is a further densification of the macro layer beyond what we have with 2G and 3G today. As described here, the range of one sector in a cell is typically already 300m or less today in densely populated areas. To get to a cell range of 50m or less such as in some parts of Seoul, new approaches are required. Small cells is the buzzword when further densification is required. Small refers to the size of the base station and the antenna which should be integrated and not much bigger than today's Wi-Fi access points so they can be deployed anywhere quickly and cheaply. Small also referrs to the power output and thus the range and area covered by that radio. The smaller the cell the higher the overall capacity of the network as the channel can be more often reused.

Apart from getting a backhaul link to small cells, another challenge is how to mitigate interference at the many cell edges as interference has a significant impact on data transfer rates at those cell borders. The straight forward approach is to have them work independently from each other and let them coordinate in the same loose fashion as today in the macro network by handing over ongoing connections and manage inter-cell interference by cooperation between the cells. Another, albeit more complicated approach, is Heterogeneous Networks (HetNets, eICIC) and Coordinated Multipoint (CoMP) in which the smaller cells are tightly coupled with a macro cell or are even remote radio heads controlled by a central scheduler. Which of these approaches will be dominant in 10 years from now is difficult to tell. Perhaps simplicity trumps over complexity. On the other hand, 10 years is a long time to perfect HetNet and CoMP.

Needless to say is that Wi-Fi will also be around in 10 years from now and will play an ever more important role at home and work. New standards such as the 802.11ac extension will further increase data rates in such places, which will certainly be needed as DSL, cable and fiber backhaul to homes are already today often exceeding the practical transfer speeds achievable with 802.11n through typical home environments with several rooms and walls between access point and devices. In theory, public Wi-Fi hotspots could also be more tightly integrated into cellular networks to offer higher localized transmission speeds. Standards exist for such a coupling but I am skeptical that they will really be implemented. On the one hand, Wi-Fi is a completely unmanaged component in mobile devices today and users have full control over it. Changing this might not be very desirable from a mobile device manufacturer, operating system and user point of view. Also, there are other alternatives such has HetNets and CoMP on the other hand that can be implemented mostly on the network side and as part of the baseband radio chip in mobile devices.

And finally, there's the voice gap in LTE networks today. Currently, all major networks still use either a dual radio approach (e.g. Verizon) or fallback to GSM or UMTS. Migrating to an operator based Voice over LTE service requires a lot to be put in place. First, network coverage must become much more ubiquitous than LTE and even 3G networks are today. While I can have an ongoing voice call on my daily train commute without any call drops, there are several data outages on the 3G layer that that would kill any Voice over LTE call. But since we won't get there anytime soon, a fallback to traditional GSM or UMTS circuit switched channels for IP voice calls needs to be put in place. This is called Single-Radio Voice Call Continuity (SR-VCC) and more details can be found here. The feature behind SR-VCC is IMS Centralized Services and the practical implementation of this in real networks is likely going to be a major pain. But I can imagine that in 10 years from now LTE networks are ubiquitous enough for true voice over LTE without many fallbacks required anymore. It won't come cheap, however, to get the same voice call quality and very low drop rates we have today in many networks.

Summary

In short, there are currently no plans to replace LTE with anything different in 10 years from now, unlike previously where UMTS was not even out of the tracks when a successor technology was already in the making. Instead, the LTE air interface will be refined as networks become denser and capacity requirements increase.