Author: Martin

The first HSPA+ dual carrier smartphones are on the market now and I can already imagine of how they will be marketed: It can do 42 MBit/s!  That's easy for the press but it completely misses the point.

It's not the theoretical top speed that will make these phones better for users than their current models but their ability two bundle two 5 MHz carriers. While this allows for the theoretical 42 MBit/s top speed, the real sweet thing about this is that it also doubles cell edge performance. Here, the signal strength is low, interference is high and as a consequence, data rates are much lower than closer to the cell tower. Having the ability to bundle two channels in effect doubles the data rate in many places with a weak signal and high interference and that will be noticeable to users.

Another benefit not to be underestimated: Dual-carrier chips usually come with sophisticated interference cancellation technologies and perhaps even two antennas for diversity. This again will do wonders in areas where the neighbor cells and even data sent to other users from the local cell creates interference. 

Networks will be happy about such devices, too as the 64-QAM modulation and interference cancellation technologies will implicitly increase overall network capacity as data can be sent to such mobiles in much less time than to non HSPA+ devices. In other words, more time is left to communicate with other devices.

Let's see if the main stream press will take note of this at some point.

Teltarif has recently reported (in German) some figures on fixed and mobile network usage in Germany on the 31st December 2011 which are interesting to play around with a bit. The article says that the Vodafone Germany network has transported 25 million megabytes between 8pm and 3am the other morning, i.e. in 7 hours.

Let's say that during that time the data rate on the interfaces to the rest of the Internet was more or less the same, what's the throughput during that time with this number? Here's the math:

• 25.000.000 megabytes = 25.000 gigabytes (SI prefix system with 1 GB = 1000 MB)
• 25.000 GB * 8 = 200.000 gigabits
• 200.000 gigabits / (7 hours * 60 minutes *60 seconds) = 7,93 GBit/s

7,93 GBit/s quite an impressive number, that's (7,93 GBit/s * 60 seconds * 60 minutes) / 8 bytes = 3.5 terabytes per hour of data transferred.

Let's just assume for a second the data rate would always be that high, which is likely not the case since this is a high load scenario, but just for the fun of doing it and comparing it to something else I have in mind the amount of data transferred per day would look like this:

• 3.5 TB/h * 24h  = 84 TB per day

Again a high number, but already back in 2010, 3UK reported that they shuffle 100 TB a day through their network. The numbers are in the same ballpark coming from different network operators which helps to ascertain that at least the order of magnitude is correct (I'm always a bit cautios with such reports as they don't contain a lot of detail how and what exactly was measured and went through legal and public relation "washing machines" for a while). What's a bit odd is that Vodafone Germany has around 36 million customers in Germany while 3UK has around 7 million.

I would have expected that Vodafone's number is actually higher, especially as their number was not an average but during a peak load scenario while 3's number sounds like a daily average. So assuming the numbers are correct, perhaps the difference is due to pricing!? 3UK offers data very cheaply on prepaid and in very high quantities (15GB for around 18 euros and it's possible to top-up again once the limit has been reached). Vodafone Germany is not quite at this point yet (5 GB for around 24 euros). I don't have numbers on this, so this part is pure speculation.

Despite the difference in customers, however, the number of base station sites seem to be similar with 3UK saying they have about 12.000 and Vodafone Germany saying they have about 13.000 (the number is from 2009, they probably have added some more in the meantime).

The CES 2012 has come and gone and I am quite amazed about the kind of spin even some technically sound German tech websites (here and here) have put on US LTE smartphones and why we are not seeing them over here in Europe. Their spin is that the US is far advanced with their LTE smartphones and Europe is lagging behind. Actually it's quite the other way around if you don't let yourself be blinded by the words LTE and 4G. Here's why:

In the US, carriers like Verizon and Sprint have a problem with their CDMA networks: They are quite limited in terms of performance and capacity in their current deployment state to a few hundred kilobits up to perhaps a megabit or two per second per user. The development on this radio technology has come to an end, quite to the contrary to W-CDMA (UMTS) which goes from strength to strength with its HSPA evolution path. Verizon's and Sprint's networks have become crowded and they had to resort to introduce LTE as quickly as possible to get further capacity and also higher speeds per user. The downside of this is that current Verizon phones run two radio chips simultaneously, one for LTE data and one for CDMA over which voice services are handled. As a result the smartphones are bulky and battery performance is an issue. For details see here.

AT&T is in a slightly better position with their HSPA network as they could build out their network to perform well and offer sufficient capacity. It would spare them the trouble of dual radio devices and the issues described above by going along this route for smartphones. AT&T may opt for CS-Fallback for voice instead of dual radio but the downside of that would be significantly longer call establishment times and higher call setup failure rates (at least by European standards). So they could do the smart thing and use LTE for dongles, tablets and other non voice devices for the moment. But it seems everything that is not LTE these days in the US is seen as inferior by the public and it's difficult to market around it. It's true, LTE is superior for pure data services on a 20 MHz carrier (only used in in Europe for the moment) but not with the 10 MHz LTE carriers used in the US and not for smartphones were a quick and reliable voice service is still important.

Let's have a look to Europe. It is true that in most countries, LTE is not yet deployed. There are some exceptions, notably the nordic countries and Germany. But here, the choice of all network operators has been to focus on data only devices for LTE. With the introduction of HSPA+ and data rates well in the 30 MBit/s range in unloaded cells when HSPA+ with dual carrier is used, the technology can deliver at least as good a throughput as 10 MHz LTE deployments. In addition, voice service is integrated, which means no bulky smartphones due to dual radio are necessary or CS fallback ruining your call setup performance. While AT&T's HSPA network is under constant criticism, HSPA networks over here perform well and there are no signs that this will change anytime soon. So offloading the dongle users to LTE that use much more data than smartphones anyway and keep the smartphones on the evolving HSPA network is the much smarter choice. And by the way HSPA+ networks are still assumed to be 3G over here in Europe and don't have to be marketed as 4G like in the US.

I can see why the mainstream press is easily fooled by terms such as 4G and LTE which are newer than 3G and UMTS but for smartphones, well built UMTS networks continue to outperform LTE on smartphones. Don't get me wrong, there's nothing wrong with LTE, it's a great technology, but until the voice issue is solved in one way or another it just doesn't make sense for smartphones.

The more time that passes by the more it seems likely to me that dual radio smartphones will shrink in size and the power consumption overhead by dual radio diminishes. Once those two values are right it might be just another solution to the voice problem, even for European operators and users.

At the end of 2011, Stefan Viehböck published a paper on the insecurity of the Wi-Fi Protected Setup (WPS) protocol and how implementation flaws make it even worse. With code to exploit these weaknesses now in the public domain, WPS enabled routers are easily crackable under certain circumstances that seem to be widespread. There's lots of information on this to be found on the web in the meantime and since I think this is an issue not to be underestimated if your neighbors have kids who spend their afternoons with the latest hacker tools I thought it was time to learn a bit more about it and collect some sources for further reading. Here's the result:

The initial weakness found was that many routers on the market today have WPS activated by default with a PIN printed on the device which allow an unlimited number of WPS pairing attempts. Due to the length of the WPS pin, a brute force attack on the system is successful within a few hours. This is the what was discovered by Stefan and described here, with a Wikipedia entry here and a US CERT vulnerability note note here.

If a router implements WPS in this faulty way the only solution is to turn WPS off, hope for a software update in the future and for the moment rely on the WPA-PSK password authentication scheme, which is just as simple to use and much more secure anyway. As it turns out, there are products out there where WPS can't be switched off at all, or, what's even worse, where the Web GUI has an option to turn it off but it remains activte nevertheless.

Better WPS implementations have a safeguard against this by:

• limiting the number of attempts that can be made before WPS pairing is blocked for some time
• using a different PIN for every pairing attempt
• limiting the pairing time to two minutes

Unfortunately that does not solve the whole problem. If an attacker is able to record a successful WPS pairing between two devices it's possible to retrieve the authentication details in an offline brute force attack in a reasonable amount of time due to the length of the PIN of 7 characters + 1 checksum character. Fortunately, the odds of being able to intercept a WPS pairing and then performing an offline brute force calculation of the credentials are much smaller than an active brute for attack, as the attacker has to intercept the WPS. A good explanation of this can be found in episode 337 of my favourite weekly security podcast 'Security Now'.

So for people who like their home networks to be secure, the best advice is to turn WPS off. Good luck!

Update, 6. Feb. 2012: Episode 338 of Security Now has an errata early on in the podcast in which it is made clear that it's NOT possible to get the WPS PIN and WPA key by observing a successful pairing and then cracking it offline. This is because at the beginning of the PIN exchange a Diffie-Hellman key exchange is performed to encrypt (not authenticate!) the reset of the conversation. This prevents the offline cracking approach.

An interesting parameter in the Internet world is how much a carrier has to pay to send a certain amount of data to another part of the Internet. The currency for that is peak bandwidth requirement, i.e. the peak MBit/s going through an interface (at the 95% percentile). So if a carrier has 20 GBit/s a second that goes to or from him it's going to cost him 20 * 1000 = 20.000 MBit/s. According to Telegeography, the current price per MBit/s is around 4 Euros in London and New York, down from over 4 times that price only 4 years ago. So for the 20 GBit/s peak, the carrier has to pay 20.000 * 4 Euros = 80.000 Euros a month. Sounds a lot, but 20 GBit/s is also not a negligible number.

How many DSL lines might that be? Obviously, you can't device the 20 GBit/s through the average MBit/s a DSL line offers as most of the time, the link is unused and there is some sort of statistical multiplexing between the users of a network. Also, most mobile TV offers terminate in the network operator's network, so that traffic doesn't go over an IP transit line. A couple of years ago, the over-subscription rate between the line rate and the backhaul from the DSL access multiplexer was said to be in the order of 1:50. Perhaps its a bit more today with all those Youtube videos, so let's say it's 1:25 Assuming DSL lines with an average speed of 8 MBit/s (which includes much slower and much faster connections) each line, 20 GBit/s would be enough to support (20.000 MBit/s % 8 MBit/s) * 25 = 62.500 lines. Dividing the 80.000 euros a month for the IP transit by the 62.500 lines results in about 1.30 euros per line per month for the transit.

The numbers in the second paragraph are all assumptions. If you agree or disagree with the numbers and have references for one or the other parameters, please consider leaving a comment, I'd be quite interested.

Obviously, the IP transit costs per line as calculated here is only one part of the overall costs a network operator has for its DSL networks. All the cables, the DSLAMs, central offices and the capital and operations expenditure for that are the other part and have nothing to do with the IP transit costs.

My friends regularly mock me for checking network coverage for places I plan to go on vacation to and that I would feel uncomfortable the moment I ran out of coverage. But it's probably true. So you will understand my shock and disbelief that there is a UK overseas territory in the South Atlantic that has no wireless network (not even GSM). Even worse, landline calls and Internet connectivity to anyone but the 4000 inhabitants is prohibitively expensive.

I'm talking of St. Helena, a small island somewhere in the middle between South America and Africa. Once an important stronghold for shipping it is now an island pretty much apart from the rest of the planet. An old satellite is used for voice and Internet connectivity with prices between 29 and 119 pounds for data buckets between 300 MB and 3GB. No this is not over wireless, these are data buckets for DSL lines. On top, the speed over the Satellite for all inhabitants is limited to 10 MBit/s. That makes the 25 MBit/s I have on my DSL line at home that I only share with the household and not 4000 other people shine in a totally new light. You can imagine how "busy hour" on that network looks like…

The British government wants to build an airport on St. Helena to stimulate tourism. But really, who wants to go there when Internet connectivity is limited at best and your iPhone can't communicate with the rest of the world? Ten years ago, this might still have worked. Today only those suffering from communication overload might consider it. I doubt one can fill planes that way.

But there's a solution, and it's called SAex, a new submarine cable about to be laid between South America and Africa, just passing by St. Helena at a distance of about 50km. Currently, there are no plans to connect the island which I would find quite a shame. But perhaps there's a chance with initiatives such as "Connect St. Helena" creating awareness of this once in lifetime opportunity.

In the meantime the press has caught wind of the opportunity as well, such as here and here. The Facebook page of the initiative is here. An airport is a nice thing to have, but in the 21st century, connectivity to the rest of the world is not just planes and ships anymore…

I've recently checked out a nearby hotel in Germany for a future conference for network coverage and what kind of Wi-Fi they are providing. Turned out that they have a Wi-Fi system provided by Swisscom. Many years ago I have used them once and was quite surprised that after 250 megabytes the connection was interrupted abruptly and I had to pay again. Since then I've made a big circle around them.

Surely this can't be the case these days anymore, especially not for the horrendous daily price of over 17 Euros they want per day!? Turns out that the very same limit is still in place. Swisscom, you can't be serious, 17 Euros a day is outrageous even without a transfer limit. We'll definitely stay away from your offer and go for an alternative. To bad for you, too bad for the hotel but the market has long since moved on to offer Wi-Fi as part of the price of the hotel room (I don't pay extra for towels either…), or if that is not the case, offer connectivity at a price you don't have to think about twice.

Every couple of weeks I am hearing of a new LTE trial of one network operator or another and I am beginning to wonder what they are actually trialing or what the word "trial" actually means!? Two years ago, when first network operators in the Nordic European countries trialed LTE, it was uncharted territory, the network hardware and software was in its infancy, mobile devices were hardly available and anything that had something to do with LTE was a trial which brought the technology one step closer to actually work.

Fast forward to the end of 2011 and the beginning of 2012 and many LTE networks are providing service to customers. However, some network operators are still trialing LTE or are just starting to do so. But these sorts of trials are quite different from those that happened two years ago. The technology is here, customers are using the networks already and despite some vital ingredients still missing such as a voice service (for which no good near term solution is at hand) and seamless handover to 3G.

In other words, LTE trials today are more of an exercise of network operators to warm up to the technology rather than poineer's work back some years ago.

When being abroad or accessing information stored on a server on another continent, the data traverses submarine cables, sometimes for more than 10.000 km in one hop before resurfacing at the other end. Quite a piece of technology I knew but little about so far. Recently, however, a comment to a post contained an interesting link to Greg's cable map of deployed submarine cables that contains interesting information about each cable and links to further details, many of them on Wikipedia. This entry contains general information about submarine cables and here, here and here, as an example, some information can be found on a particular cable (TAT-14) that is currently used in the Atlantic.

Here are some facts which I found interesting:

Capacity: The system capacity of the cable is given as 1.87 TBit/s or half in each direction by the third link above on the TAT-14 website. The two Wikipedia articles linked above give some more details on how the capacity is calculated but the descriptions do not match the 1.87 Tbit/s. The next cable generation seems to be close to be brought into operation, however, with the WASACE cable, foreseen to enter operation in 2014 having a capacity on Greg's cable map of 40 TBit/s, due to the use of 100 Gbit/s per wavelength instead of the current 10 MBit/s.

Signal regeneration: The German Wikipedia entry states that there is a repeater every 50-70 km but does not give a source from which this information was obtained. The English entry mentions the use of erbium-doped fiber amplifiers (EDFA) as repeater / amplification technology, also without a reference, that amplifies the light signal directly to light again without conversion into an electrical signal first. EDFA is also mentioned in the general Wikipedia article on optical data transmission (see section on "optical telephone cables") as the amplification technology for intercontinental cables.

Below ground: If possible, the cable is laid one meter deep into the sea bed to protect it from anchors and fishing nets that seem to frequently plague cables in areas where they are not well protected.

Lifespan: Cables laid at the end of the 1980's (i.e. before GSM was launched in 1992 to give a reference) such as TAT-8 (the first optical cable through the Atlantic!) and PTAT-1 were operated until 2002 and 2004 respectively. In less than 15 years, the cable's capacity of 20 GBit/s, which equals 40.000 telephone circuits according to the Wikipedia entry became only a fraction of the capacity offered by new cables coming online in those years such as the TAT-14 with a used system capacity of 1.87 TBit/s. This is two orders of magnitude greater. In other words, the 10-15 year telecoms cycle found in mobile networks (GSM – UTMS – LTE) applied to this field of telecommunication as well.

Yes, the Internet at meetings topic keeps me interested and I keep refining my setup. The major problem of hotel or meeting room Wi-Fi is definitely the instability when too many client devices use the network simultaneously. But even if the local network doesn’t crash when it sees 80 to 100 devices simultaneously there is usually another side effect, the network becomes very slow.

This is because it doesn’t take a lot for the network to become congested. If the network is unmanaged, two or three devices using the network continuously over longer periods to upload or download data at the full bandwidth the network is capable of is all it takes to significantly slow down communication for everyone. Especially uplink congestion slows down TCP acknowledgment packets for downlink data to reach the server on the Internet in time which makes it impossible to make use of the full downlink bandwidth available.

To tackle uplink and downlink congestion I had a look if there is any way to shape uplink and downlink data streams on the router. Shaping individual services or streams is of little use as the majority of meeting participants use a VPN and thus, all communication flows over the same TCP or UDP stream. I was therefore looking for a way to shape all traffic to and from individual IP addresses to ensure that adequate uplink and downlink resources remain available even if several users transmit data simultaneously over a prolonged amount of time.

After quite a bit of research I found out how to perform traffic shaping the way I want on DD-WRT. Below’s the script I’ve come up with to shape traffic on a per-IP address basis with different maximum throughput speeds for up- and downlink transmissions. The uplink traffic is shaped on the WAN Ethernet interface while the downlink traffic is shaped on the LAN Ethernet interface for devices connected via a cable to the router and also on the two Wi-Fi Interfaces (2.4 and 5 GHz Wi-Fi) for the majority of devices that communicate wirelessly. Consequently, uplink traffic is only shapped on one port while the downlink traffic needs to be shaped on three interfaces.

In practice, my Netgear 3700 router with a 680 MHz processor can shape an aggregate traffic of around 40 MBit/s. In the vast majority of circumstances, thats much more than what the backhaul link provides anyway. In addition to limiting each IP address to a given maximum throughput, each IP address also gets its own IP transmit queue and packets are sent from all queues in a round-robin fashion. That means that even if the link gets congested, nobody needs to queue up behind a long queue of IP packets of heavy users as is the case in a default setup without any shaping with a single queue per interface.

And here’s the script:

#!/bin/sh

set -x

#the devices on which downlink shaping can be performed
DEV=eth0
DEV2=eth1
DEVWIFI0=wifi0
DEVWIFI1=wifi1

DOWN_SPEED=5000kbit
UP_SPEED=1500kbit

#The /8 IP subnet to use this script on
IP_NET=192.168.2.

tc qdisc del dev $DEV root
tc qdisc add dev $DEV root handle 1: cbq avpkt 1000 bandwidth 100mbit

tc qdisc del dev $DEV2 root                                          
tc qdisc add dev $DEV2 root handle 1: cbq avpkt 1000 bandwidth 100mbit 

tc qdisc del dev $DEVWIFI0 root                                          
tc qdisc add dev $DEVWIFI0 root handle 1: cbq avpkt 1000 bandwidth 100mbit

tc qdisc del dev $DEVWIFI1 root                                          
tc qdisc add dev $DEVWIFI1 root handle 1: cbq avpkt 1000 bandwidth 100mbit

#start with x.x.x.2 ip address (.1 is the gateway)
l=2

while test $l -le 253
do
    #
    # limit downlink bitrate
    tc class add dev $DEV parent 1: classid 1:$l cbq rate $DOWN_SPEED
         allot 1500 prio 5 bounded isolated
    tc filter add dev $DEV parent 1: protocol ip prio 16 u32
           match ip dst $IP_NET$l flowid 1:$l

    tc class add dev $DEVWIFI0 parent 1: classid 1:$l cbq rate $DOWN_SPEED
         allot 1500 prio 5 bounded isolated
    tc filter add dev $DEVWIFI0 parent 1: protocol ip prio 16 u32
           match ip dst $IP_NET$l flowid 1:$l

    tc class add dev $DEVWIFI1 parent 1: classid 1:$l cbq rate $DOWN_SPEED
         allot 1500 prio 5 bounded isolated
    tc filter add dev $DEVWIFI1 parent 1: protocol ip prio 16 u32
           match ip dst $IP_NET$l flowid 1:$l

    # limit uplink bitrate
    tc class add dev $DEV2 parent 1: classid 1:$l cbq rate $UP_SPEED allot 1500 prio 5 bounded isolated
    tc filter add dev $DEV2 parent 1: protocol ip prio 16 u32 match ip src $IP_NET$l flowid 1:$l
    

    l=$(($l+1))
done