Martin – Page 110 – WirelessMoves

My Uploads Are Three Times Faster On LTE Than With VDSL At Home

It's a bit ironic but my uplink speed in LTE is three times higher when I'm sitting in a train comunting to work and being connected over LTE than what it would be when sitting at my desk at home and being connected over a 25 MBit/s down + 5 Mbit/s uplink VDSL line.

I just had that thought when I uploaded a 50 MB ZIP file to the cloud in a couple of seconds at around 15 Mbit/s which is, mind you, not the maximum LTE can provide on a 20 MHz bearer, but my uplink speed is limited. It's really time for a fiber link at my home in Germany like I already have in Paris. But unfortunately, German politics creates no incentives for network providers to catch up to more developed parts of the world… Quite the contrary, DSL vectoring is the future as far as the government and the local incumbent is concerned 🙁

Book Review: The Innovators

The history of computing has me firmly in its grip and so after having read “Fire in the Valley” I continued with “The Innovators”. While the latest edition of the previous book mainly focused on what was going on in Silicon Valley in the 1970s to the 1990s, “The Innovators” expands the story back to Charles Babbage and Ada Lovelace in the 1850’s and ends in the 21st century with the creation and evolution of Google.

“The Innovators” is of course much briefer about what happened in Silicon Valley in the 1970s to 1990’s than the previous book I read. Instead it tells the stories of many other people, how they built on work of their predecessors and how their success was usually due to working in a team rather than doing something on their own all the way as it is often portrayed elsewhere. Also, it doesn’t focus on developments in only a single location it mentions how Konrad Zuse came up with his electromechanical computer in Germany in the 1940’s, Alan Turing in Great Britain, the computers that were built in Britain after the war, how the ENIAC in Philadelphia came to be, the women behind programming ENICAC like Grace Hopper and Jean Jennings, the story of John von Neumann, the Atanasov-Berry computer, how the transistor was invented, again by a team, at Bell labs, etc., etc., etc.

Beginning in the 1960’s the book then continues the the story with the move from transistors to integrated circuits and how Silicon Valley mushroomed from Shockley Semiconductors to Fairchild to Intel and, what I found to be one of the many interesting new insights I gained, that Intel was founded not as a processor company but to produce memory chips as that was seen as the major application of integrated circuits once it was understood of how to cram more than just a few transistors on a die. The microprocessor on a chip only came later and was not envisioned as a product when Intel was created.

I could go on and on about the book but to make it short, I very much enjoyed reading it as it doesn’t only convey facts but also tells the stories of the people and gives a sense of who these people were, how they were growing up and what drove them to do what they did.

Nibbler: The 4-Bit Self-Made CPU

Time flies but it still seems like yesterday when I discovered "But How Do It Know", the must-read book if you want to understand how a CPU works, the central piece of electronics in any electronic device today be it a SIM card, a smartphone, a notebook or a supercomputer at a large computing facility. Once you have read this book and have some background in tinkering with electronics you can build a working CPU with memory and I/O at home. I started doing this and came as far as making shift registers and memory work. Unfortunately, there just wasn't enough time and there were too many components I wanted to use in my design so that's about as far as I got. But perhaps there is yet another way to achieve this goal without waiting for retirement: The Nibbler by Steve Chamberlin.

The Nibbler is a 4-bit CPU with ROM and RAM, fitting on a single medium sized board. The difference between what I had in mind and the Nibbler is that it uses a single chip 4-bit Arithmetic Logical Unit (ALU) which I initially wanted to build out of individual logic chips like adders, etc. Also, I had an 8-bit ALU and address bus in mind, but obviously the 4-bit approach makes wiring a lot more practicable. And finally, the Nibbler simplifies things by separating the program ROM and RAM, which again saves a lot of wires. While the original Nibbler design was done in wire-wrap technology, William Buchholz has picked up the project and produced a "real" PCB which again significantly reduces the time it takes to put things together.

Obviously this design is a bit different from the CPU discussed in "But How Do It Know". But in the end that doesn't matter because the concepts are the same. Using a single ALU chip is somewhat of a compromise between reducing complexity and being as discrete as possible to understand how the stuff really works. Fortunately there's a good description of the 74HC181 ALU chip on Wikipedia and a great diagram that shows how it looks like inside, basically consisting of several function blocks for different arithmetic functions and a total of 75 gates.

Another thing that makes this ALU chip appealing is its historical background. According to the Wikipedia page linked above, it was the basis for a number of historically important computers that were designed before fully integrated CPU chips became available, the DEC PDP-11 being one of them. The PDP-11 was obviously not a 4-bit computer but with the help of a support chip it's possible to daisy chain a number of these 4-bit ALUs to perform arithmetical operations on bytes and words.

Finding stuff like this is one of the reasons why the Internet is so great. Without it, it's unlikely that I would have ever found this project because building your own CPU does not only seem to be a niche, its more of a nano-niche. What I find a bit amazing, and sadly so, is that William didn't sell too many of his boards yet even though the price makes it a no-brainer for those with ambitions to understand how a CPU works not only from a theoretical point of view but also in practice.

15+ Devices At Home With A WiFi Interface Today – But It All Started With An Orinoco

At the end of the 1990's coax based 10 Mbit/s Ethernet was the network technology most companies used at the time, including the one I worked for then. It was also there that I held the first 802.11 wireless network card in my hand. The brand was Orinoco, the company that produced it was Lucent and it could transfer data at a whooping speed of 1 and 2 Mbit/s, just a tiny fraction of what is possible now. Today, 'Wi-Fi card' would be the term used by most but Wi-Fi cards to be plugged into PCs are mostly a thing of the past as most devices now have a Wi-Fi chip and antenna built-in. Gone are also the days when Wi-Fi connectivity was expensive. For less than 10 euros one can buy an 802.11n Wi-Fi USB dongle these days for the few devices that are not Wi-Fi equipped yet.

So much for the history part of this blog entry. I'm writing all of this because I recently realized that I have over 15 Wi-Fi enabled devices at home these days that are in frequent use. There's my notebook of course that I work with every day, a test notebook to try out new things, a notebook mostly used for video streaming, at least 3 smartphones, my spouse's notebook and her 2 smartphones, a Raspberry Pi for audio streaming to the 20 year old Hifi set in the corner, the access point itself, a second access point that also acts as an Ethernet switch and 2 Wi-Fi enabled printers. In addition to these devices that are in use all the time there are at least half a dozen Wi-Fi USB dongles that are occasionally put into good use with about as many Raspbery Pis for various purposes.

Quite an extraordinary development when I think back to this first and hyper-expensive Orinoco wireless LAN card I once held in my hands for the first time and marveled at how it is possible to transfer data so quickly over the air with just such a 'little' card.

We Can’t Afford To Let Any Part Of The Internet Rot In Place

Over the last decade Wi-Fi devices have become tremendously popular. Unfortunately it seems the Federal Communications Commission (FCC) and its counterpart in the EU are becoming concerned that 3rd party software that controls the radio hardware may negatively impact interoperability with other applications using the same frequency bands, e.g. by increasing transmission power beyond the regulatory limits. As a result the FCC and the EU are proposing or have already implemented laws that require the hardware manufacturer of a device to ensure that only their radio software can be used in the device. The problem with that is that instead of 'only' locking down the radio software, manufacturers of Wi-Fi access points and other Wi-Fi devices such as smartphones might be tempted to use this as an excuse to lock-down the whole device thus making it potentially impossible in the future to use Wi-Fi routers with alternative software such as Open-WRT or smartphones with alternative Android derivates such as CyanogenMod.

While the EU has already published a directive to that end that shall come into effect in June 2016, but first needs to be implemented in national laws of the individual member states, the FCC is still in the comments phase of the process. One response, signed by pretty much everyone of the who-is-who in the Open Source community including Linus Torvalds and Internet luminaries such as Vint Cerf, is truly outstanding:

In their response, the authors explain the dire state of the Wi-Fi router market today that is only driven by price but not by quality and responsibility. This leads to hundreds of millions of devices in the field today that are insecure and pose a significant risk to their owners and the Internet as a whole.

To fix both the radio issue addressed by the FCC and the wider issue of software with grave security issues being abandoned by device manufacturers, the authors propose an alternative approach to the FCC's lock-down proposal:

1. Any vendor of software-defined radio (SDR), wireless, or Wi-Fi radio must make public the full and maintained source code for the device driver and radio firmware in order to maintain FCC compliance. The source code should be in a buildable, change-controlled source code repository on the Internet, available for review and improvement by all.

2. The vendor must assure that secure update of firmware be working at time of shipment, and that update streams be under ultimate control of the owner of the equipment. Problems with compliance can then be fixed going forward by the person legally responsible for the router being in compliance.

3. The vendor must supply a continuous stream of source and binary updates that must respond to regulatory transgressions and Common Vulnerability and Exposure reports (CVEs) within 45 days of disclosure, for the warranted lifetime of the product, or until five years after the last customer shipment, whichever is longer.

4. Failure to comply with these regulations should result in FCC decertification of the existing product and, in severe cases, bar new products from that vendor from being considered for certification.

5. Additionally, we ask the FCC to review and rescind any rules for anything that conflicts with open source best practices, produce unmaintainable hardware, or cause vendors to believe they must only ship undocumented “binary blobs” of compiled code or use lock down mechanisms that forbid user patching. This is an ongoing problem for the Internet community committed to best practice change control and error correction on safety-critical systems.

These are powerful proposals and I am delighted that the letter was signed by a huge number of well known and respected people in the industry. But not everyone will like the proposals and I can already see the marching orders for lobbyists of hardware manufacturers to fight this. While many manufacturers have an open source driver for their Wi-Fi hardware today, the software that runs on the Wi-Fi chip itself is usually closed source and only available as a binary blob. Having the source available of this part as well would be truly revolutionary. Requiring that the owner of the device must have ultimate control over the software update process (if he wishes so) is another strong requirement. This wouldn't prevent automatic updates for those who don't care but the ability to stay in control of what you own if you wish to do so.

The paper from which I have quoted the 5 proposals above is well worth a read. It is well written and explains in detail why the FCC should adopt the proposals above instead of what they have initially suggested. So let's see how visionary the FCC can be.

P.S.: The headline of this post is an abbreviation of a quote of Vint Cerf in a recent article on the topic in Businesswire:

"We can't afford to let any part of the Internet's infrastructure rot in place. We made this proposal because the wireless spectrum must not only be allocated responsibly, but also used responsibly. By requiring a bare minimum of openness in the technology at the edge of the Internet, we'll ensure that any mistakes or cheating are caught early and fixed fast"

P.P.S.: And for further background info about EU directive 2014/53/EU that has something similar like the FCC in mind have a look at Julia Reda's recent blog entry on the topic.

The Interesting Prepaid Shift To Data Only Buckets For Smartphones

Over the last few years, apps on smartphones such as Facebook, WhatsApp, etc. have become hugely successful, especially among teens and twens. While I was one of the few just 5 years ago who used the mobile Internet on my daily train tips there are now only few without a smartphone in their hand or a notebook on their lap. In other words, use of mobile devices has significantly changed during that time, away from voice and SMS towards Internet based applications. Prepaid tariffs, however, have not, at least not until recently.

No matter to which network operator I turn in Germany, most prepaid tariffs are a bundle of included voice minutes, SMS messages and a few hundred MB or a GB or two for Internet access. Many people today, however, do not need endless amounts of voice minutes and SMS, they are communicating mostly via the Internet. In effect they need to pay for something they don't use. But now things are changing. In the last couple of weeks I have seen two offers that let prepaid subscribers chose the number of voice minutes, SMS and the amount of data traffic per month independently of each other. The number of voice minutes and SMS can even be set to 0 and then paid by the minute or by SMS instead.

An interesting offer for many customers and I would not be surprised to see the number of mobile voice minutes not only declining in fixed line networks but also in mobile now as we are way beyond peak telephony by now.

3G-Only Coverage – A Strange Feeling By Now

Last week I attended a meeting for a couple of days in a hotel which had good network coverage for Internet connectivity from my network operator of choice. However, it was 3G and not LTE. Not that it was slow, by far not, I could easily reach speeds above 15 Mbit/s when downloading files. By now, however, 3G coverage feels somehow strange and outdated once one is used to that LTE logo on the display. If I wouldn't have seen the network type indicator on the phone I probably would not have noticed at all so it's only a psychological effect. I found that quite interesting as I still remember the day I bought my first UMTS phone 11 years ago and the day UMTS came to my home town which were breakthrough moments for my mobile Internet usage. Time flies.

Docomo Doesn’t Want To Wait And Launches S8HR VoLTE Roaming On Its Own

Back in July this year I had a post on a GSMA and 3GPP initiative to think about a simpler VoLTE roaming approach. Instead of the quite complicated VoLTE roaming with local breakout, some members of the two fora openly pushed for for a much simpler solution called S8 Home Routing (S8HR). For the details have a look at my previous post. There are surprisingly few public documents that can be found on the web even today which leads me to believe that it’s not really a very popular topic amongst network operators. Japanese network operator NTT Docomo certainly doesn’t belong to those delaying a standard based on S8HR and perhaps they are even tired of waiting for an emerging industry standard as they have announced that they will launch their S8HR VoLTE roaming with KT in South Korea TODAY.

That’s quite NTT Docomo like. Already in the days of 3G, they had a UMTS network up and running well before anyone else. They suffered a bit later on as their network wasn’t quite compatible with the final 3GPP standards so they had to evolve their equipment over time. When LTE was first launched they were again one of the very early adopters. The same goes for VoLTE, they launched their service already back in mid-2014. And now they are pushing the state of the art again with VoLTE roaming.

Fortunately, VoLTE S8HR in it’s very basic form requires no support from the roaming network as all signaling and even the voice data packets are tunneled back to the home network. On mobile devices, however, some things need to be modified. Today, mobile devices deactivate VoLTE when not in their home network which is the first thing that has to change.

In addition, the following things need to be considered on the mobile side:

IMS registration should work like in the home network, no things to change.

When establishing a call, forget about preconditions and dedicated bearer establishment.

For emergency calls just fall back to 2G and 3G even if it is done differently in the home network.

There is no SR-VCC support to hand-over an ongoing call to 2G or 3G when running out of LTE coverage as the roaming is not aware of an ongoing VoLTE call (it’s all home routed…). There are no modifications for this on the mobile devices side, as this is controlled by the network. In case of roaming, the SR-VCC command will simply not come and the call will drop. As I mentioned in my previous post, that’s a pity but the competition can’t do this either. On the other hand, in countries with good LTE coverage such as South Korea there should be little need for SR-VCC anyway.

If you can think of any other things that have to change on mobile devices to make S8HR VoLTE roaming work, please leave a comment, I’d be quite interested.

In the home IMS network, quite a number of changes were probably required. Roaming calls are likely to be charged differently so the components involved in call charging were probably dapted. That shouldn’t have been much of a challenge though. Somewhat more effort was likely spent on the IMS call establishment logic. In the home network, dedicated LTE bearers are established to ensure constant bandwidth and priority for voice packets on the radio interface and in the network which requires interaction between the IMS and the network infrastructure. As the IMS system in the home network can’t interact with the network components of the visited network, the IMS call flow for roaming calls needs to be modified. Compared to the VoLTE local breakout solution that requires such an international interaction, such changes are pretty much a no-brainer.

Kudos to Docomo for racing ahead, it’s another way to make others follow.

5G Super High Frequency Radio Technologies Are Great, BUT…

Last week, a 3GPP 5G RAN (Radio Access Network) workshop took place in Phoenix, Arizona for interested companies to voice their opinions about requirements and potential implementations of Super High Frequency Air Interfaces between 6 GHz and 100 GHz. A summary can be found here as well as a number of very interesting presentations, it's well worth a look. There is one important thing, however, that is rarely mentioned, perhaps because it's implicitly understood: All transmissions over 6+ GHz radios will only reach devices a few meters away at best which means we have to say good bye to our current idea of what a cellular radio network is. Or, in other words, how do you bring such a radio close enough to devices, be they carried by humans, or be they machine type communication devices installed in fixed places or moving inside and outside of buildings?

Today it's already very difficult to drag a fiber to macro base stations covering hundreds of meters in diameter. So how is that going to work in the future? Electricity lines are dragged into the last corners of civilization but the business model for that is entirely different: It's not the electricity company doing that, it's the end user with an interest to have electricity for lighting and other things in all places not necessarily only for himself but also for others. Do we require a similar approach for 5G data networks as well, is there an alternative to such an approach, how can an end user provide connectivity for others and not be responsible for the data flowing over this connection and can an organization consisting of network operators and equipment manufactures actually define something like that? For me the answers to those questions are even more interesting than the details of future 6 GHz+ radio interfaces.

Obviously, answers to this can't be given by 3GPP RAN as they focus on air interface aspects. Instead, this is the task of 3GPP's System Architecture (SA) Group and they will have a first meeting on 5G (only) in December 2015. A joint workshop between SA and RAN is scheduled for the second half of 2016 according to the 3GPP tentative timeline for 5G. In other words, there's still quite some time to ponder these questions.

Configuring Prosody and Conversations For Pictures in Group Chats

While most features of Prosody and Conversations for XMPP messaging are straight forward there is one feature that is very popular in other IM systems that requires a bit of manual tweaking to set-up: Pictures in Group Chats.

To be able to post pictures that are shown automatically in a group chat in Conversations, the server needs to support XMPP extension XEP-363, "HTTP File Upload". If you have a Prosdoy server at home a corresponding module can be added without too much difficulty. I haven't seen widespread support on public servers yet, with Jabber.at being a notable exception. If you know of others supporting the feature, please consider leaving a comment below. If you are with a public server you can check in Conversations if it is supported by going to "Manage Accounts", clicking on the account that is active at the moment, go to the "…" in the top right corner menu and select "Server Info". That brings up a list that shows which XMPP features are supported by the server. The screenshot on the left shows the features supported by my server, with XEP-363 being the important one for pictures in group chats.

To install the http_upload module in Prosody, have a look here. Once done and Prosody is restarted, support will be indicated in Prosody in the "Server Info" overview. After that there is one more hurdle to be overcome. As it could be potentially dangerous to automatically load in a message stream, Conversations restricts this to pictures that are sent via HTTP links from known contacts. For pictures received from other contacts, only the URL from which they can be downloaded is shown. A long-press on the URL will then download the picture on demand. By default, chat groups created in Conversations are anonymous so even if you know others communicating in a group, Conversations can't identify them and hence only the link shows up. So to see pictures in a chat group instead of links, the group needs to be set into "non-anonymous" mode before participants are added. In this regard, security is a bit in the way of usability I'm afraid.

One other thing is important to remember: As group chats are not end-to-end encrypted (yet), pictures are uploaded to the XMPP server and are stored there in the clear. TLS still protects the conversation so nobody can eavesdrop in a public and open Wi-Fi hotspot. That's probably enough for most people but one should be aware of the fact and always remember that an unencrypted copy is stored for a while on the server. But from what I hear a solution is already in the works.