WirelessMoves

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.

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.