Category: Uncategorized

Once a year many telecom regulators in Europe publish their yearly analysis of the state of competition in the telecommunication market. A while ago, the German regulator has published it's report for 2012 (in English) which contains, among many many other interesting numbers, the amount of data transported through fixed in wireless networks in Germany.

As per the report, 4.3 billion gigabytes of data were transported through fixed line networks in Germany in 2012 (page 77) compared to 0.139 billion gigabytes (or 139.75 million GB to sound more impressive) in wireless networks (page 78). In other words, there's 30 times more data flowing to and from fixed line connections compared to wireless.

According to the report there are 28 million fixed line Internet connections in Germany today and thus the average monthly amount of data per line is around 12 GB. Also interesting is the rise of fixed line data from 3.7 billion to 4.3 billion gigabytes from 2011 to 2012, that's a rise of 16%. In wireless networks the amount of data transferred rose from 93 million GB to 139 million. That's a 30% rise which is quite substantial but far from the doubling or tripling the year before and the year before that respectively. In other words, the growth has been slowing down for a number of years now.

The report further says that there were 139 million mobile subscribers in Germany in 2012 out of which around 40 million are actively transferring data (page 79). This made me think a bit. I pay around 40 euros a month for my fixed line Internet and telephony connection today and around the same amount for wireless connectivity. And while the fixed line is shared, every family member has an individual mobile contract. So in effect I pay less for my fixed line connection when broken down per user compared to my wireless subscription and on top transfer over 30 times more data over it. Or put the other way round I pay more for my mobile subscription then for my fixed line and use it far far less.

All of this makes sense if wireless networks are more expensive to build and maintain than fixed line networks. But is it really cheaper to drag a fiber cable close to people's homes these days and then have a copper wire to each individual house or apartment compared to setting up a base station on a rooftop that servers one thousand users? I have my doubts.

Which device will be my next smartphone? I've made my choice and it will be the Fairphone. It's in the process of being built by a small company established in the Netherlands and the aim is to produce it with the people and the environment in mind. No children labor in African mines, fair wages for Chinese works and safe working conditions. In addition the company is open about the whole process of building the device and using an open operating system, i.e. Android and perhaps Firefox OS and Ubuntu in the future.

The device is in production now with shipment foreseen around Christmas time. One interesting piece of information I recently came across when I wanted to get an update on their status is the cost breakdown of the device's retail price of €325 based on a production run of 25.000 devices. Here are some noteworthy numbers:

• €129 design, engineering, components, manufacturing

• €4.75 prototyping

• €4.25 reseller margin

• €9 certifications (CE, GCF, RoHS, FCC, Reach) and testing

• €63 taxes (VAT, etc.)

• €11.75 personnel costs, office space, IT, travel

• €11.00 legal, accounting

• €6 events

• €5.25 webshop hosting

• €18.25 warranty costs

• €11 interventions (sustainability, being fair to people and environment)

For the full details, see here. If you are interested in how a phone is built from scratch then the website is a treasure trove of information. Bring some time…

I was recently faced with the dauntingly tedious task of doing throughput testing which meant uploading and downloading files from HTTP and FTP servers and noting the average throughputs in each direction separately and simultaneously. This is fun for about 30 minutes if done by hand but gets very tedious and even confusing afterward as constantly triggering up- and downloads makes you loose your thread at some point when your mind wanders somewhere else during the downloads. So I decided to automate the process.

There must be about a zillion ways to do this and I chose to do it with cURL, a handy command line tool to upload and download files in just about any protocol used on the net, including http, ftp, pop, etc. etc. It's ultra configurable via the command line and has a great variety of output options that make later analysis such as averaging downloads speeds of different files very simple.

For doing repetitive downloads I came up with the bash script (works well under Ubuntu and MacOS):

#!/bin/bash
URL="http://ftp.xyz.com/name-of-file"
OUTFILE=test-down.csv
rm test-down.csv
curl $URL -o /dev/null -w '%{size_download}, %{speed_download}n' >>$OUTFILE
curl $URL -o /dev/null -w '%{size_download}, %{speed_download}n' >>$OUTFILE
curl $URL -o /dev/null -w '%{size_download}, %{speed_download}n' >>$OUTFILE
cat $OUTFILE

The URL variable holds the URL to the file to be downloaded. Obviously if you test high speed links, the server should have enough bandwidth available on its side for the purpose. The OUTFILE variable holds the name of the local file to which the file size and download speeds are written into. Then, the same curl instruction is run 3 times and each time, the result is appended to OUTFILE. While the script runs, each curl instruction outputs information about current speeds, percentage of the download completed, etc.

And here's my script for automated uploading:

#!/bin/bash
UPURL="http://xyz.com/test/upload.html"
LOCALFILE="10MB.zip"
OUTFILE="test-upload.csv"
rm $OUTFILE
curl  -d @$LOCALFILE $UPURL -o /dev/null -w '%{size_upload}, %{speed_upload}n' >> $OUTFILE
curl  -d @$LOCALFILE $UPURL -o /dev/null -w '%{size_upload}, %{speed_upload}n' >> $OUTFILE
cat $OUTFILE

The trick with this one is to find or build a web server as a sink for file uploads. The LOCALFILE variable holds the path and filename to be uploaded and OUTFILE contains the filename of the text file for the results.

Note the '.csv' file extensions of the OUTFILES which is convenient to import the results to a spreadsheet for further analysis.

When GSM was first launched in Europe a long long long time ago back in 19992 the GSM logo could quite often be seen in advertisements. It's gone a bit out of fashion in the past decade but every now and then I still stumble over it like in the image on the left I took in Bratislava. I've done a lot of research into the history of GSM but I could never find any information on the logo. Who designed it and what do the 4 dots you can see in the "M" of GSM signify. Who put them there? It's all a big mystery. If you know something about this, I'd be glad if you could share it in the comments below.

Back in August I reported that I suddenly found a use again for Bluetooth connectivity after I haven't used it for quite some time thanks to my new Notebook now including a Bluetooth radio. Since then I've added yet another one. As I travel a lot I like to have a good loudspeaker connected to my PC in hotel rooms either for listening to music or for watching a movie streamed from the PC to the TV set in the room. When I looked for a Bluetooth enabled small loudspeaker two years ago I didn't find any, at least not in the size I wanted so I opted for a cable based loudspeaker. So I was quite surprised that two years later it's quite easy to find small Bluetooth enabled loudspeakers produced by many companies. Quite an interesting change. So I bought one and it just works fine with my Ubuntu powered notebook and with my Android smartphone as well. Great!

When updating the software of my devices I am usually a bit cautions and wait a couple of days after patches and updates are announced just in case it is discovered that the update breaks something and needs to be fixed. While this tactic usually works it somewhat failed me recently when two updates massively failed within the hour. Luckily the Internet came to the rescue.

The first major fail occurred when updating the Ubuntu distro on my media PC from 13.04 to 13.10. While everything looked fine during the update, the system would not let me log on after rebooting. All I saw was a mysterious error message after typing in my username and password before I was thrown back to the login prompt. WOT!? One can be skeptical about Google but they do find things quickly and thus rescued the day. Only a few hours before somebody posted a fix for the issue: Switch to the console and unistall Cinnamon and the Nemo file manager which I installed previously as Ubuntu has castrated the Nautilus file manager to be basically uselessness. Could this really be the issue? I was skeptical at first but it worked and I could log in again. So much about installing software from third party repositories… Fortunately, the Nemo file manager made it into the official Ubuntu repository in the meantime and I could re-install it from there without the issue re-appearing.

Once that was fixed I updated Thunderbird to apply the latest security patches on my production notebook. That can't possibly go wrong now can it? It seems it can as I stumbled right into the next issue. After restarting Thunderbird, the Lightning calendar just showed and empty window. WOT!? Two minutes and another Internet search and I found out that for a yet unknown reason, updating Thunderbird broke the plugin. The solution: Downgrade Thunderbird until Lightning is updated as well. Fortunately I do not use the pre-packaged Thunderbird so I can apply security patches quicker than with the default Ubuntu install. I guess that saved me this time as I just had to rename the directory and download the previous version again.

So was I too quick with the updates? Perhaps, but from a different point of view my somewhat cautious update behavior has saved me nevertheless. If I had updated both systems earlier I would probably not have found a fix for both issue on the net. And while I can live with a broken media PC for a while, a broken Thunderbird on my production notebook would have been totally unacceptable. So perhaps I waited just long enough.

Another takeaway from this is that without people out there sharing information via blogs, message boards and other means, things would be a lot more difficult and some even impossible. And it's not an overstatement, I still remember how desperate I was sometimes in the days when I 'only' had books e.g. to learn programming and getting stuck often meant hours searching for an answer in seemingly endless trial and error loops.

Back last month I was musing about how 2G we still were only 10 years ago which makes it even more amazing what has happened since in the mobile domain. When looking at UMTS and LTE and how they were used in their early years I see a striking difference. When UMTS first launched it took quite a while for devices to actually become available and even longer before there was a general take-up. For quite a number of years, UMTS base stations were just sitting there producing heat but were actually little used.There were probably a number of reasons for this. One was certainly that mobile Internet access was a novelty and only used by few. In addition, content readable on small screens was even scarcer. And on top, screens were tiny by today's standards and devices were bulky. Not a good mixture for fast take-up.

With LTE the story is quite different. There was perhaps a time span of one year after the launch of networks during which networks were mostly used with LTE capable USB data sticks. The situation changed quite quickly, however, due to devices such as the Samsung Galaxy S-III and the iPhone becoming LTE capable. Yes, there were certainly other LTE smartphones available before those two but those still seemed to have something of an experimental character to me and probably weren't sold in high volumes. And LTE had the invaluable advantage that by the time the networks were launched, mobile Internet access had become mainstream, devices thin and screens large enough for enjoyable media consumption.

And here's my personal LTE timeline:

• 2009: Lot's of talk about it, but nothing commercially deployed
• 2010: Experimental network deployments
• 2011: Mass rollout of networks
• 2012: First LTE capable smartphones that could actually be bought became available
• 2013: Real LTE usage with the iPhone 5 and Samsung Galaxy S-III

 

 

A quick observational post today from the Hong Kong metro. Not surprisingly, smartphones and tablets are universally used by HK residents in the metro these days. What I found surprising, however, is what they do with them while commuting. While I was expecting that most of them would browse the news, this was actually an activity I couldn't only seldomly observe. Instead, by far the number one application is texting in all forms and shapes. Next is playing offline games, followed by watching videos and making phone calls. Only few people were actually using it for web browsing or reading and ebooks. Quite a different usage from my own in public transportation. But then I am fortunate enough that my suburban trains are usually only two thirds full and I usually get a place to sit and open up the notebook for writing blog posts, emails, etc.

In the past couple of years we've become accustomed to weekly news of grand scale username and password thefts at major web services. As many people use very insecure passwords that can be cracked in seconds and by using the same passwords for many web services, usernames and passwords have become very insecure. In addition, viruses and Trojan horses try to get username and password combinations directly on PCs to get access to banking web sites and other high value targets. To me it looks like the situation is getting more and more out of control. While two factor authentication (e.g. an SMS with an additional code being sent by the bank before a transaction is made) fixes some of the issues for some web services, it's too cumbersome for everyday logins. But now Steve Gibson, famous for his SpinRite product and perhaps even more for his weekly Security Now podcast has come up with a solution that fixes all of this. Too good to be true? I thought so, too, at first but it seems he's really figured it out.

The core of his solution that he named SQRL (Secure QR Code Login) is that web services no longer store usernames and passwords but just a public key that was sent from the user when he first registered to the web site. For login, the web site sends a random number that is encrypted on the client side with the users secret key to generate a response. On the web service's side the response is decrypted with the public key agreed during initial registration. In other words, the secret password is no longer in the hands of the web service but in the hand of the user. That means that there is no longer a password database with millions of entries worth stealing on the web service's side. As each web service gets a different public key with the SQRL method and a different random number is used for each login, there's no password leakage between services due to the user of the same username and password for different sites as done by many users today to make their life simpler. Also not to underestimate is the advantage that no password has to be typed in, which fixes the issues that simple to remember and easy to crack passwords are used.

On the client side the use of SQRL is straight forward. Either a smartphone is used to scan a QR code on the login page for an out-of-band authentication which is the most secure way to access a web service in case the secret key can be stored securely on the mobile device. Also, implementations are possible with a browser plugin that detects that a web service offers SQRL login and automatically generates the response.

For more, head over to Steve's page that explains the details or listen to the podcast /videocast on the topic where he introduces SQRL starting at around 38 minutes into the podcast. I am amazed and very enthusiastic about it and hope we'll see implementations of this in the wild soon.

While LTE roaming and LTE for prepaid SIMs is still not really a reality so far I was positively surprised to see that a number of network operators are already deploying LTE on several frequency bands. This is unlike UMTS which most network operators have only deployed in one band at any one location (yes, there are a few exceptions but not many).

One multi-frequency LTE deployment I have recently observed, e.g. with my inexpensive layer 1 scanner solution (for details see here and here), is the Vodafone LTE network in Den Haag in the Netherlands where they have LTE active in the 800 MHz digital dividend band as well as in the 1800 MHz band. Add to that the capacity of their 3G network on the 2.1 GHz band and it's a fair assumption they won't run out of capacity any time soon.

And the second deployment I have observed is China Mobile Hong Kong. This one is very interesting. On the 1800 MHz band they have deployed a 3 MHz carrier (!!) while further up on the frequency dial, they are on air with a 15 MHz carrier in the 2.6 GHz band. As 3 MHz isn't really all that much I wonder if that 3 MHz carrier will still be on-air in a year or two down the road when not only most but all LTE capable phones that support the 1800 MHz band also support the 2600 MHz band. Another option would be of course to get some additional 1800 MHz spectrum and then to increase the bandwidth. But I'm not into Hong Kong spectrum assignment details so I don't know if that's an option for them down the road.