Linux Device Drivers – Exploring the Kernel And Reviewing A Book 10 Years Later

Apart from mobile, I like to explore other computer topics every now and then as there are often surprising ideas springing up from this that also impact my work in mobile. Android programming, Raspberry Pi's, Owncloud and my dive into PHP web programming and databases last year immediately filtered back to the work that earns the daily bread. Earlier this year I started having a closer look (again) at the Linux kernel.

The great thing about the Linux kernel is that it's open source and you can have a look yourself. The problem is, however, that it's a monumental piece of code and without any prior kernel knowledge, diving into the material seems daunting. I'm a hands-on person so just going through the code for the fun of it is not my piece of cake. So I was looking for some insight with practical things to be done along the way. That's not easy to come by as books on the topic with hands-on tutorials are rather dated. One of the best books on the topic is perhaps the "Linux Device Drivers" book as it explains many things about the kernel from a device driver perspective. The good thing about this approach is that it offers hand-on experience with a couple of sample drivers one can compile, modify and run. 

Unfortunately the current 3rd edition of the book is from 2005. Ancient history… I would have never bought it in print at first. Fortunately, it is available online free of charge and so I decided to start reading it in electronic form first and see if the sample code would still run. The source code would of course not compile anymore, too many changes were made to the kernel since. But a number of people have updated the source over time and there's a working version available that compiles with current kernels on Github by duxing2007.

Together with the working source the book suddenly made a lot more sense and even though some of the book's content is clearly dated (e.g. using the parallel port for some of the sample code or discussing the ISA bus) the majority of the content still gives a good introduction to the kernel with lots of things to try out via the driver examples that one can compile, run and modify. At some point I decided it was worth to buy the print version of the book as sometimes information in print still beats the electronic version. In other words, despite the book being 10 years old now, I still found it a worthwhile read!

While not necessary to compile and run the examples in the book, having the kernel source to explore is great. As it turns out it's quite simple to download and even compile it. If you are running Ubuntu, have a look here for how to do that. On my notebook in a virtual machine running an Ubuntu guest, it takes around 2.5 hours to compile the kernel. Installing the compiled kernel to boot from is a simple command. I wouldn't have dared that on my notebook but in a virtual machine there's nothing you can break in the process that couldn't be restored with the click of a button that restores a previous snapshot of the guest OS.

With all these things in place it's never been easier to explore the kernel! Have fun!

Methods In The Wild To Return To LTE As Fast As Possible

LTE deployments are making steady progress and with good network coverage, network operators are keen to make sure devices are on LTE as much as possible instead of lingering around in 2G or 3G for too long. There are actually quite a number of mechanisms I've seen in various networks in the past so I thought I'd sum them up in a single post. Note that there are more mechanisms than described below but those are the one's I've seen in different networks while traveling.

Autonomous Reselection: This one's the easiest as the network only needs to signal LTE availability in 2G or 3G System Information messages (2G SIB 2quater and 3G SIB19). Mobile devices in idle state that have ended up in 2G or 3G for various reasons then periodically scan for LTE coverage in spectrum locations indicated in the SIBs and autonomously change back.

Release With Redirection: Instead of switching a mobile from active to a more power conserving state (e.g. from Cell-DCH to Cell-PCH), the network releases the connection with an RRC Connection Release message that contains redirect information to LTE. The mobile device then has a look if LTE is available straight away and leaves for greener pastures if LTE is found. For this to work the network operator must be reasonably sure that LTE coverage is actually present in the area where a release is made instead instructing the mobile device to use an active but less power hungry 3G state. Otherwise the mobile ends up in 3G idle state from which it takes more than one and a half seconds before data can flow again (for details see this post).

CSFB Release With Redirection: That's almost the same as above but part of a CS-Fallback procedure for voice calls. After the voice call ends the network releases all bearers and also includes redirect information. This is even done when a PS bearer is still established at the end of the call and IP packets are flowing.

GPRS to LTE Reselection During Data Transfer: This is a relatively new feature and allows the mobile to interrupt an ongoing 2G data transfer and switch back to LTE. Have a look here for the details.

UMTS to LTE Handover During Data Transfer: This functionality is unfortunately not yet widely deployed in networks, I haven't come across a single network that supported it. But from my point of view it's a very important piece of the puzzle as often I use a notebook and VPN that constantly keeps data flowing and once I end up in 3G due to running out of LTE coverage I'm stuck there until I run out of 3G coverage. At this point anything can happen, depending on how the network looks like once coverage is regained. I already wrote a post about this back in November 2014 so have a look in this post for the details.

Moving Beyond the Aggregation of 5 LTE Carriers

While aggregating two LTE carriers in Europe exists but is still not very widespread due to the availability of 20 MHz single carriers there is talk in the industry about aggregating 3 carriers. There is still some room in the specs for the moment as the maximum number of aggregated carriers that can be accommodated so far is 5. But eventually, carriers might want to go beyond that as well so 3GPP is gearing up to work on a solution to eventually combine up to 32 carriers.

The work item description can be found in document RP-142286 presented not long ago in TSG RAN#66 in December 2014. At first I thought extending CA beyond 5 carriers might be straight forward by introducing a couple of additional information elements and extensions. But that's a bit too short sighted as the current solution puts all uplink transmissions including channel feedback on the primary cell (i.e. the primary carrier). So as more and more devices become carrier aggregation capable there's more and more uplink traffic in the PCell which increases as more and more carriers are aggregated. Therefore the model does not scale well and uplink traffic and feedback at some point needs to be distributed over several carriers if more and more of them are combined.

From an overall conceptual point if find an aggregation of up to 32 carriers quite interesting. Before the aggregation of 2 carriers made it into chipsets many people were saying that this is going to be difficult as it would increase complexity and hardware cost significantly. Fast forward to 2015 and the aggregation of 2 carriers is in the wild and built into many devices. Obviously the aggregation 32 carriers is yet again another beast. And then again who would have predicted just two years ago that we would see mass market devices that support 20 LTE bands?

The “Ringing For Favourites Only” Feature Is Back!

One of the features I was dearly missing when I finally switched my main device from a Symbian phone to an Android device was that I had to give up the feature to put the device into silent mode but still make it ring for selected contacts. This was and still is an important feature for me, especially when traveling to other timezones and people being unaware that they are calling while it's night in my current time zone and I'm sleeping. So for the last two years I fixed this with a kludge, i.e. taking an extra phone and SIM only known to few contacts. Now I discovered that the feature was introduced on Android and the iPhone at some point between then and now.

On my Android 4.4.4 based CyanogenMod Samsung Galaxy S4 which I've been using for more than half a year now, the sound menu now contains a menu item called "Quiet Hours". When selecting the item it's not only possible to set the quiet hours but also further things such as which events shall not be indicated to the user and the "Phone Ringer" menu item which can be set to "Ring for Favorite Contacts" (only). Works like a charm!

O.k. so this is a pretty much stock Android OS, how about customized variants? I had a quick look on a current high end Samsung device with Android L and while it looks slightly different the option is there as well. Also I could find a similar option on the iPhone.

Great stuff and nobody told me… 😉 Must have been in the software for quite some time now.

1-silent 2-silent 3-silent

Latency Comparison – DSL, UMTS, LTE and Fiber

Speaking of the 1 ms 5G latency myth in my previous post on the topic let's have a look at what round trip times are to servers on the Internet today over different access networks – with surprising results!

(V)DSL: When I ping a sever pretty close to my location and within the network of my access provider I get ping round trip delay times over my VDSL connection of around 24 milliseconds. Since that's what I have at home it's my reference and quite far away from the mythical 1 millisecond 5G latency. About 3-5 ms are spent on the Wi-Fi link, the rest are a result from delays in the fixed access network. Delay after that to the server is minimal, in the order of a millisecond or two.

UMTS: To the same server my round trip delay times are in the order of 100 milliseconds, so quite a bit more.

LTE: Here, I get round trip times of around 45 milliseconds to that server, so quite a bit of improvement over the UMTS network

Fiber: In Paris I have a Fiber to the Home (FTTH) GPON Link. From a server connected over Ethernet to a router which then connects to a fiber/Ethernet converter I get round trip times to a server close to the edge of that network in the order of 3-4 milliseconds. That is quite a bit closer to the mythical 1 millisecond 5G delay time already. I then pinged a server around 600 km away in Germany and got round trip times of 15 milliseconds. Out of those, 6 milliseconds is due to the physical delay of the light in the fibers, the rest is processing delay.

There we go, I was quite surprised about the phenomenal delay performance of the fiber connection, it's not far away from the physical limits. The question now is if and how this efficiency can be ported to wireless as well, when even VDSL has far more delay, even though it's a fixed line technology.

The 1 Millisecond 5G Myth

5G must be on the steep rise part of the Gartner Hype Cycle curve as I have heard a lot of non-technical people making a lot of technical statements out of context apart from the usual Mbit/s peak data rate claims. A prime example is the 1 millisecond round trip time that 5G should/will have to enable the 'tactile' Internet, i.e. Internet connectivity that is used to remotely interact with the physical world.

Sounds all nice but physics stands a bit in the way of this and nobody seems to say so. The speed of light and electricity is limited and in one millisecond, light can only travel around 200 km through an optical cable. So even if network equipment does not add any latency whatsoever, the maximum round trip distance is 100 km. In other words, there's no way to remotely control a robot with a latency of 1 ms in one part of the world from a place halfway around the world. But then, why let physics stop you?

So perhaps what was really meant is to further reduce the latency of network components? A big step was done in LTE with an air interface that has 1 ms slices and to base all network interfaces on the IP protocol to remove protocol conversions and the resulting overhead and latency. A scheduling interval of 1 ms means the round trip time on the eNodeB is in the order of at least twice this without even forwarding the packet to another node in the network. Add to this potential HARQ (Hybrid ARQ) retransmissions so you already end up at several milliseconds. Sure one could further reduce the length of the timeslices at the expense of additional overhead. But would it really help considering the many other routers between one device and another? Have a look at this great post of Don Brown and Stephen Wilkus which goes into the details.

GoGo Experience Over The Clouds – Without Certificate Forgery

Gogo-wifi-sign-onHere I am, over the clouds again and an interesting aspect of flying in the US is that they have Internet access on board on many of their flights. Here's how it worked for me while putting together this blog post:

On Delta, Internet over the clouds is provided by GoGoAir and I was getting download speeds between 1 and 3 Mbit/s with round trip times of around 90 ms without my VPN. With an OpenVPN tunnel to my gateway in Europe I got round trip delay times of around 260 ms, quite a good value as well. In the uplink direction I got around half a megabit per second out of the connection. Over the hour I used the system it was quite stable but there were temporary outages of 15-20 seconds every now and then and occasional long round trip times of several seconds while data only trickled in. Not sure why these things happen, cell edge or handover problems perhaps?

Wikipedia says that the system uses 160 ground base stations distributed over the continent and 'classic' EvDo 3G connectivity between the plane and the ground. That would be consistent with the speeds I've experienced but it could of course always be that traffic shaping is applied on a device basis and overall speeds could have been higher.

Web browsing felt snappy and just for the fun of it I dropped my VPN tunnel for a little while to see if Gogo still forges Google certificates for Youtube. It looks like the bad press around the issue has made them think about it again and I couldn't observe rogue certificates for Youtube anymore.

Today a 3G link to the ground might still be sufficient but with rising data traffic the system needs to be upgraded to a faster technology in the future. Let's see if ground based LTE will be the technology of choice for planes flying over ground rather than satellites which are the only choice over oceans for obvious reasons. Personally I'd prefer ground based communication, as using satellites in geostationary orbit results in very long round tip delay times.

So What Exactly Is 5G?

Now that 3GPP has officially started working on 5G, the time has come to put lofty ideas and cheap talk into practical specifications. I'm looking forward to this because I still find most ideas that are currently floating around too abstract and unrealistic. But vendors and the NGMN have started publishing whitepapers that give a bit more insight into where we are going. After reading the whitepapers of Ericsson, Nokia and the NGMN on the topic, here's my summary and my own thoughts:

Radio Technology Mix: All whitepapers agree that 5G will not be about a single radio technology vying for dominance but rather a technology mix. Current radio technologies such as LTE(-Advanced) in the cellular domain and Wi-Fi in the home and office domain will be further evolved and are part of the technology mix. New technologies should be specified to grasp the potential offered by using large chunks of so far unused spectrum above 6 GHz for communication over very short distances. Some technologies are already there today, take Wi-Fi 802.11ad as an example.

Virtually Latency Free: The "Tactile Internet" is a new buzzword which means tactile remote control of machines and instantaneous (virtually latency free) feedback. Here's a good description of the concept. Marketing managers are promising round trip delay times of a millisecond in future networks but forget to mention the constraints. But perhaps they have discovered Star Trek like subspace communication? More on this in a future post.

Ultra-Dense Deployments With Ultra-Cheap Radios: As all whitepapers I've read correctly point out, the only way to increase data rates is to shrink cell sizes. This goes hand in hand with using higher frequency bands above 6 GHz. That means that the number of (what we still call) 'base stations' has to grow by orders of magnitude. That in turn means that they have to become ultra-cheap to install, they must configure themselves without human intervention and operate at almost zero cost. Sounds like a nice challenge and perhaps it could be done by turning light bulbs into yocto base stations (nano, femto and other small units are already used…) for this to become a reality? But who's going to pay the extra money to put a transmitter into light bulbs, who's going to 'operate' the light bulb and should such connectivity be controlled or open to everyone? That's not only a technical question but will also require a totally different business model compared to network operators running a cellular network and installing infrastructure without involvement of their customers. Again, the light bulb comes to mind. Light bulbs and power cables that are installed by their owners not only to illuminate a certain area for them but also for others. So in addition to fundamentally new technology and fundamentally new business models it's also a fundamentally new psychological approach to providing connectivity. Perhaps it should be called "light-bulb connectivity"?

Lots of Devices Exchanging Little Data: Today's networks are optimized to handle a limited number of devices that transfer a significant amount of data. In the future there might well be many devices talking to each other or to servers on the network and exchange only very little data and only very infrequently. That means that a new approach is required to reduce the overhead required for devices to signal to the network where they are and that they are still available, perhaps beyond what 3GPP has already specified as part of the 'Machine Type Communication' (MTC) work item.

Local Interaction: Great ideas are floating around on radio technologies that would allow local interaction between devices. An example are cars communicating with each other and exchange information about their location, speed, direction, etc. Sounds like an interesting way to enable cars driving autonomously or to prevent accidents but might break the business model of making money by backhauling data.

Spectrum Licensing Scheme Shake-Up: Some whitepapers also point out that for higher frequencies it might not make a lot of sense to sell spectrum for exclusive use to network operators. After all, range is very limited and not everybody can be in the same place. So license-free or cooperative use might be more appropriate especially if a chunk of spectrum is not used for backhauling but only for local connectivity.

3GPP's Role: All of this makes me wonder a bit how 3GPP fits into the equation? After all it's an industry body where manufacturers and network operators are defining standards. In 5G, however, network operators are probably no longer in control of the 'last centimeter' devices and thus have no business model for that part of 5G. So unlike in 2G, 3G and 4G, 3GPP might not have all the answers and specifications required for 5G?

Summary

So here's my take on the situation: For 5G, everything needs to change and whenever the concept or a part of it is discussed one central question should be asked: Who is going to backhaul the massive amounts of data and how is that done? In 2G, 3G and 4G that question was very simple to answer over the last decades: Network operators are setting up base stations on rooftops and install equipment to backhaul that data over copper cables, fiber or radio. For 5G that simple answer will no longer work due to the massive increase in the number of radios and backhaul links required. Operators will no longer be able to do that on their own as we move from nodes that cover the last mile to nodes that only cover the last centimeters. That means we have to move to a 'lightbulb' model with all that this implies.

GPRS to LTE Reselection During Data Transfers – Part 2

In a comment to a previous blog post on new mobiles now supporting GPRS to LTE Reselection during ongoing data transfers there was a comment that this was a network and not a device feature. The answer to this is quite interesting so I decided to make a post out of the response rather than just post an answer in the comments section.

It's in the nature of 3GPP to have several options for a feature and this one is no exception. Reselection from GPRS to LTE during data transfer is optional, it can be implemented as a device only feature or the device can signal to the network that it is capable to make LTE measurements during an ongoing GPRS data transfer and let the network decide what to do. Which of these options are supported are sent to the network during the GPRS attach process: 

Message:  ATTACH REQUEST
Information Element: GERAN to E-UTRA support in GERAN packet transfer mode

Possible Values:

  • 0 0 (0): None
  • 0 1 (1): E-UTRAN Neighbour Cell measurements and MS autonomous cell reselection to E-UTRAN supported
  • 1 0 (2): CCN towards E-UTRAN, E-UTRAN Neighbour Cell measurement reporting and Network controlled cell reselection to E-UTRAN supported in addition to capabilities indicated by '01'
  • 1 1 (3): PS Handover to E-UTRAN supported in addition to capabilities indicated by '01' and '10'

I've checked a number of recent mobiles and all of them either don't support the feature at all or support the autonomous cell reselection option without involvement of the network (like it is the case for GSM to UMTS reselection today as well).

That doesn't mean there are no networks and mobiles that support a network variant but I wonder if network operators are really interested in the feature when the autonomous variant works quite well!?

For details see 3GPP TS 24.008, Table 10.5.146 and search for "GERAN to E-UTRA support in GERAN packet transfer mode".

SSD Endurance – Theory and Practice

Two years ago I estimated that my SSD would last around 30 years based on the number of re-write cycles and the theory laid out in an epic Anandtech article on the topic. That was the theory. Now we have real numbers based on a practical endurance test of several SSD drives made by TechReport.

According to the report, the Samsung SSD could take at least 100 TB before even first hints of wear could be detected. It still kept working for twice the amount of data written to it before it eventually stopped working. So based the 5 GB of data that I write to my SSD per day (have a look at the first link above of how I get to this value) my SSD would last me for 54 years based on the 100 TB value.

I should mention though, perhaps, that I already replaced the first SSD I bought after about a year and a half because it was full and I had to upgrade to a 1 TB model… 30 years, 54 years, it's all a bit academical with the amount of data I keep accumulating resulting in drive swaps to increase capacity…