Category: Uncategorized

I read an interesting article today about the current power consumption of the worlds mobile networks. The number is quite staggering. According to the article, current mobile networks consume about 43 billion kilowatt hours of energy a year.

If one assumes 2.5 billion mobile users, that would be 1.4 kWh a month or 46 Watt hours a day or 2 Watt of average power per user. To set this into relation: My personal power consumption at home per month is about 200 kWh. Thus, depending on how you look at the 43 billion kWh the number is quite big or small.

Here’s another number from another source that says that German mobile networks currently use about 1 billion kWh per year. Divided by let’s say 70 million subscribers the numbers per user per month match quite well.

So how many power plants do you need for all networks worldwide? 43 billion kWh broken down to average power is 43 billion kWh / (365 days * 24h) roughly equals 5.000 Megawatts = 5 Gigawatts. That’s the energy which is produced by about three to four big nuclear power generators (source)

Taking traces in a Wireless LAN can be quite a tricky thing if you are using Windows. Except for a few expensive programs which can do the job, other free tools like Wireshark can only trace what the network driver forwards to the operating system. Unfortunately, Windows network drivers only forward pseudo Ethernet frames to the OS and hide all the nitty gritty Wireless LAN details. An alternative to tracing a Wireless LAN with your PC is to let an off the shelf Wireless LAN access point record all packets and save them to a file which can then be analyzed on the PC. Cost of the solution: 60 euros and a bit of time to set it up.

In this and the next couple of blog entries I’ll give an overview of how to collect packets in a Wireless LAN and how to analyze them on a Windows PC with such a setup. If you don’t know much yet about the basic technology behind Wifi, I can warmly recommend chapter 4 of my book.

The Wifi tracing environment consists of the following components:

• A PC or notebook running Windows with an Ethernet port.
• A Linksys WRT54G or WRT54GL wifi router (picture above, for details see below). The WRT54G sells for around 50-60 euros on eBay. Several hardware versions exist, not all of them are suitable. For details, see the next blog entry.
• OpenWRT, a free Linux operating system for the wifi router (open source)
• X-WRT, a better web interface for OpenWRT (open source)
• Kismet for OpenWRT (open source)
• CIFS driver for OpenWRT to be able to mount a directory of your windows computer on the router for file export (open source)
• Wireshark for Windows (open source)
• Putty for Windows, a free telnet/ssh shell for Windows

With this setup, tracing a Wirless LAN can be done as follows: In a first step, the native software of the wifi router has to be replaced with OpenWRT, X-WRT, Kismet and a CIFS driver. Once the setup is running, Kismet is used on the router to collect all 802.11 wifi packets the router receives and to save them to a file. As there is not a lot of room on the router for the file it needs to be stored elsewhere. This is done connecting the router and a Windows PC with an Ethernet cable and by mounting a Windows directory on the router. No extra software is required on the Windows PC. On the wifi router the CIFS driver is used to mount the directory. The file Kismet creates in the shared directory can then be analyzed using Wireshark for Windows. The picture on the left shows how Wireshark decodes an 802.11 beacon frame recorded by Kismet.

Part 2 of this series will pick up at this point and explain how to get started, which wifi routers are suitable for this project, how the software is installed, how the Windows directory is mounted on the router and how to get started with the router.

I’ve been writing on this blog for quite some time now mostly on wireless technical topics and I am enjoying every post. For me, this blog has become an extended notebook that helps me to focus and explore new ideas and topics. There are two reasons for this musing on the reasons why I run this blog:

Firstly, this is my 200th blog entry and ideas are coming faster than I can often write them down. I am very much looking forward to the next 200 entries :-). Secondly, Rudy de Waele has asked me if I wanted to broaden my blogging activities and join forces with him and Yasmine Abbas at m-trends. As we are looking at similar topics all from a different angle, working together could create an interesting combination and open new horizons.

I very much like the idea and I am looking forward not only to your comments to future thoughts here at mobilesociety but also over at m-trends. Off we go, here’s my first article abut the four axis of wireless success.

Over the past couple of days I’ve experienced some problems with large file downloads over Wifi. Regularly, download speeds decreased to almost zero for a couple of seconds before recovering. Today I found the culprit: My new Bluetooth USB stick in combination with the Nokia PC suite.

The 100 mW Bluetooth stick I bought a couple of days ago is used by the Nokia PC suite every now and then to check if one of my phones is in the neighborhood. As Bluetooth and Wifi use the same frequency band they can interfere with each other. The PC suite tries to establish a connection to the phones about every 20 seconds. When the Bluetooth stick attempts to create a Bluetooth connection the Wifi connection is pretty much wiped out. On the first picture on the left it can be seen that the Wifi throughput measured by NetMeter drops to 0 just when the HCI Create Connection Event is sent to the BT stick.

Picture two shows the situation traced with a Wifi network tracing tool. At the time of the interference the access point tries to deliver a packet (4043) but does not get an 802.11 acknowledgment frame from the notebook. It tries three more times before giving up. It then tries to send the next packet (4047) which equally fails. The third packet (4051) gets an ack from the notebook so that transmission was o.k. That doesn’t help much, however, as two packets are missing so the TCP stack immediately stalls and requests a retransmission from the source (not shown in the picture).

I can break the pattern by transmitting a file to the phone over Bluetooth. While the file transfer is in progress the Wifi download returns to normal. Once the file transfer has finished the Wifi connection is interrupted again in the regular pattern. This is most likely because once the Bluetooth connection is established power control kicks in which reduces the Bluetooth power and thus the interference to the Wifi transmission. As both my Bluetooth stick and the remote device are BT 2.0 capable it is also possible that the BT stack recognizes the Wifi interference and starts excluding the Wifi band from the hopping sequence. Maybe it’s even both, hard to tell.

Two remedies come to mind: For the moment I have deactivated Bluetooth in the PC Suite which promptly brings my Wifi transmissions back to normal as the Wifi stick no longer attempts to connect to the phones every 20 seconds or so. I think I’ll bring the 100mW stick back to the shop and see if a 10mW stick creates less interference during connection establishment. I’ll keep you posted.

I was quite surprised that the Nokia PC Suite can connect to several phones simultaneously, e.g. over Bluetooth. Take a look at the picture on the left. When moving the mouse pointer over the PC suite tray bar icon it shows that both phones are connected.

Third Party Applications Support

It even works for third party applications! I use Handysafe on the PC and on a N93 to store my passwords. When synchronizing a window appears in the application to ask the user with which of the phones currently connected to synchronize. Very nice!

Auto Connect

And another nice functionality: The Bluetooth connections to a phone is automatically established whenever it is close to the notebook. That’s a nice feature as I can now access the memory card to transfer files without going through a connection procedure. I’ve used if for a couple of days now and it seems that it doesn’t have a big impact on battery lifetime. That’s probably because the Bluetooth connection is not active all the time and the PC Suite just checks every now and then that the phone is still there.

Also, the permanent virtual connection works nicely alongside other Bluetooth connections I establish every now and then to the mobile phone, e.g. with my foldable Bluetooth keyboard.

But be careful what you wish for: I detected that in conjunction with a 100mW Bluetooth stick, this setup wreaks havoc on my Wifi network. More about that in the next post.

This ‘Deep Inside the Network episode’ focuses on UMTS security mechanisms and enhancements over GSM. Like the previous ‘Deep Inside’ articles I expect the target audience to be rather small. Nevertheless, I decided to post it anyway as I haven’t found this information in a similarly compressed form anywhere else.

Introduction

Like GSM, UMTS has strong security measures which are described in detail in [1] to prevent unauthorized use and eavesdropping on user data traffic and conversations. Over the years, a number of weaknesses have been found in the way GSM protects networks. These have been addressed with a number of enhancements in UMTS. 

These main ones are:

• The GSM circuit switched part does not protect the link between the base station and the BSC. In many cases, microwave links are used which are vulnerable to third party monitoring.
• GSM allows man in the middle attacks with equipment that masquerades as a GSM base station.
• The ciphering key length used in GSM is 64 bits. While having been secure when GSM was first developed back in the early 1990’s it is considered insufficient today. A number of weaknesses with the A5/1 stream cipher have been detected such as described in [2] which allow to decrypt a voice conversation with the appropriate equipment.

UMTS Authentication Vector vs. GSM Authentication Triplet

UMTS addresses these weaknesses in a number of ways. Like in GSM, a one pass authentication and key agreement (AKA) procedure is used with immediate activation of ciphering after successful authentication. When a mobile station first connects to the network it sends its identity (IMSI or T-IMSI) which is stored on the SIM card. In case the subscriber is not known by the MSC/VLR, which is responsible for circuit switched connections, or the SGSN, responsible for packet sessions, authentication information has to be requested from the authentication center which is part of HLR (cp. figure 1.14). In addition to the random number (RAND), the expected response (SRES, referred to as XRES in UMTS) and the ciphering key (Kc, referred to as CK in UMTS) which are already known from GSM, two additional values are returned. These are the integrity key (IK) and the authentication token (AUTN). Together, these five values form an authentication vector.

Authentication Token and Sequence Numbers:

The authentication token (AUTN), which is new in UMTS, serves two purposes. The AuC generates the AUTN using a random number and the secret key of the subscriber. It is then forwarded together with the random number to the mobile in a mobility management (MM) authentication request message. All other values are retained at the MSC/VLR or SGSN for the moment. The mobile station then uses the AUTN to verify that the authentication procedure was initiated by an authorized network. The authentication token additionally includes a sequence number which is increased in both the network and the mobile after every successful authentication. This prevents third parties from using intercepted authentication vectors for fake authentications later on.

Like in GSM, a UMTS mobile station has to generate a response value which it returns to the network in the MM authentication response message. The MSC/VLR or SGSN then compares the response value to the expected response value (XRES) which it has received as part of an authentication vector from the HLR/AuC. If both values match, the subscriber is authenticated.

128 Bit Ciphering Key

In a further step, ciphering between the mobile and the network is activated by the network by sending a RANAP Security Mode Command message to the RNC. This message contains the 128 bit ciphering key. While in GSM ciphering for circuit switched calls is a function of the base station, UMTS calls are ciphered by the RNC. This prevents eavesdropping on the Iub interface between the RNC and the base station which is vulnerable to interception especially if transported over microwave links. A RRC security mode command message informs the mobile that ciphering is to be activated. Like in GSM the ciphering key is not sent to the mobile as this would compromise security. Instead, the mobile calculates the ciphering key itself by using, among other values, its secret key and the random number.

Message Integrity Checking

Security mode command messages do not only activate ciphering but also integrity checking for signaling messages, which was not done in GSM. While ciphering is optional, integrity checking is mandatory to activate after authentication. Integrity checking is performed for RRC, CC, SM, MM and GMM messages between the mobile station and the network. User data on the other hand has to be verified by the application layer if required. To allow the receiver to check the validity of a message a integrity stamp field is added to signaling messages. The most important parameters for the RNC to calculate the stamp the content of the signaling message and the integrity key (IK) which is part of the authentication vector received from the authentication center. Integrity checking is done for both uplink and downlink signaling messages. In order to perform integrity checking for incoming messages and to be able to append the stamp for outgoing messages, the mobile station calculates the integrity key itself after the authentication procedure. This is done by the SIM card by using the secret key and the random number which was part of the authentication request message. This way, the integrity key is also never exchanged between the mobile station and the network.

Key Lifetime

Keys for ciphering and integrity checking have a limited lifetime to prevent attempts to break the cipher or integrity protection by brute force long duration monitoring attacks. The value of the expiry timers are variable and are sent to the mobile station at connection establishment. Upon expiry, a new set of ciphering and integrity keys are generated with a re-authentication between the mobile and the network.

Authentication, ciphering and integrity checking are performed independently for the circuit switched and the packet switched connections. This is because the MSC handles circuit switched calls while the SGSN is responsible for packet sessions. As these devices are independent they have to use different sets of authentication vectors and sequence numbers.

New Algorithms

UMTS also introduces new algorithms to calculate the different parameters used for authentication, ciphering and integrity checking. These are referred to as f0-f9. Details on the purpose and use of these algorithms can be found in [1].

GSM SIM Card Backwards Compatibility

On the user side, all actions which require the secret key are performed on the SIM card to protect the secret key. As older GSM SIM cards are not able to perform the new UMTS authentication procedures, a backwards compatibility mode has been specified to enable UMTS mobile stations to use UMTS networks with an old GSM SIM card. When the mobile station detects an old GSM SIM card it informs the network during connection establishment that a GSM backwards compatible authentication procedure is required. Instead of requesting an authentication vector from the authentication center, the MSC/VLR or SGSN will instead request a GSM compatible authentication triplet. The UMTS ciphering and integrity keys are then computed by the mobile station based on the GSM ciphering key Kc (note: not the secret key!) which is returned by the SIM card. As the SIM card is not able to process the authentication token, it is not sent by the network during authentication. On the network side the MSC/VLR and SGSN are responsible for computing these values. To be backwards compatible, the mobile informs the network during connection establishment that a SIM instead of a USIM is used. The network will then request a standard authentication triplet from the HLR/AuC.

Further Reading

If you are also interested in other topics concerning GSM, GPRS, UMTS, Wifi, WiMAX and Bluetooth, take a closer look at the book to this blog “From GSM to LTE-Advanced: An Introduction to Mobile Networks and Mobile Broadband“, which you can find here.

References:

[1]    3GPP, „3G Security ; Security Architecture“, TS 33.102

[2]    Patrick Ekdahl and Thomas Johansson, „Another Attack on A5/1“, IEEE Transactions on Information Theory, Vol. 49, No.1, January 2003, page 284 – 289

Update 22. Feb. 2016: Spelling errors corrected, link to book updated

Blogs, news web sites, tech tips are all on the web these days. Books, however, are far from being pushed to the side by it as they can explore topics in a much deeper way than articles on the web. So if you are like me and like to read a good book on telecoms and communication, the Telecoms Book Blog might just be the right resource that will help you to find your next book. Check it out, I am listed as well 😉

There is web 2.0, mobile web 2.0 and, believe it or not, Bluetooth 2.0… One of the main benefits of the new version is the enhanced data rates (EDR) feature which promises data rates of up to 2.1 MBit/s. That’s quite a step from the 0.7 MBit/s of previous versions of the standard. To test the higher data rates in action I performed some speed measurements between a notebook with an Anycom Bluetooth 250 USB stick and a Nokia N93.

While measurements between two Bluetooth 2.0 USB sticks might actually show higher transfer speeds than between a notebook and a mobile phone, I nevertheless decided to go for this test setup as I use Bluetooth mostly between such devices for file transfers and to connect my notebook to the Internet via the mobile phone and the 3G network.

The test setup:

• Mobile phone: A Nokia N93, firmware V 10.0.025
• Notebook: Anycom BT200/250 Bluetooth 2.0 USB stick with Widcom Stack V 5.1.0.2100
• File for transfer: A 34 minutes 64 kbit/s MP3 podcast with a file size of 15 MB (16.142.336 bytes)
• For reference tests: A Nokia 6680 with a Bluetooth 1.x chipset

From the notebook to the N93

This is a typical side-loading scenario, i.e. a user downloads a podcast from the Internet to the PC and then sends it via Bluetooth the mobile device. Over Bluetooth the 34 minute podcast was transfered to the N93 in 120 seconds. The resulting transfer speed was thus 16.142.336 bytes / 120 seconds = 134.5 kByte/s. That’s about half of the theoretical maximum speed Bluetooth 2.0+EDR offers with 272.25 kByte/s (2178 kbit/s). Nevertheless, the transfer was about twice as fast as what could be achieved with previous Bluetooth versions.

From the N93 to the notebook

I also transfer a lot of files from the mobile phone to the notebook, mostly images and videos. In order to better compare transmission speeds of both directions I used the same file to test the reverse direction. In this direction, the file was transfered to the notebook in 110 seconds. The resulting transfer speed was thus 16.142.336 bytes / 110 seconds = 146,78 kByte/s.

Bluetooth and the Nokia 6680

To compare the improvement, I ran the same tests once more with a Nokia 6680, a S60 2nd edition phone and predecessor of the Nokia N70. It uses a Bluetooth 1.x stack and the transfer of the file from the notebook to the mobile phone took 273 seconds. That’s a transfer speed of 57.4 kByte/s. In the other direction the file transfer took 313 seconds which corresponds to a transfer speed of about 50 kByte/s.

Summary

While end users won’t care much for the transmission speeds, the time required to transfer a file between two devices is quite important. Compared to the 273 seconds (4.5 minutes) it takes to transfer the file to the 6680, the 110 seconds (slightly less than 2 minutes) required to send the file to the N93 is a vast improvement. There is also still potential to increase the speed further as the transfer rates are far below the theoretical maximum. When using Bluetooth 2.0 capabilities to the fullest, the transfer time could be reduced from 2 minutes to around 1 minute for the 34 minute podcast file.

With file sizes especially of video files getting larger and larger due to the improved capabilities offered by new phones, it is only a matter of time before it becomes impractical to transfer such large files even over an optimized Bluetooth 2.0 connection. Also, 3G network features such as HSDPA with data transfer rates of up to 3.6 MBit/s today and 7.2 MBit/s in the future, Bluetooth definitely becomes the bottleneck.

It is time to think about alternatives. Many of today’s N-series phones already have a built in wireless LAN (wifi) adapter. Adding access point functionalities to the phone as suggested in this blog entry would surely remove this bottleneck.

IMS, the IP Multimedia Subsystem, a buzzword that has been around in the mobile industry for quite a number of years now. However, up to date no IMS services are commercially available and the industry is still working on getting the complex setup and terminal software in place.  In the past year, however, a number of things have happened which might improve chances we are going to see some interesting commercial services soon:

• 3GPP Release 6 integrates WLAN access in IMS. Previously, IMS was only specified for 3G access.With WLAN integration dual mode 3G/Wifi devices that are now available on the market can be used for IMS services while camped in a wireless lan.
• The IMS has become the carrier SIP environment of choice for both fixed line and wireless IP networks. Especially wireless operators with DSL access will be able to offer integrated fixed and wireless services. This is also referred to as Fixed Mobile Convergence.

And here are the services which I see coming (soon?):

• Instant Messaging (IM): This is an easy service to implement from a network point of view as there are no special bandwidth and latency requirements. IM however is already done today via proprietary IM clients from Microsoft, Yahoo and others. Thus, I think IM via IMS will have a difficult time unless operators find a way to include Microsoft, Yahoo and other customers, have international connectivity in mind and offer interesting pricing for the service.

• Push to Talk over Cellular (PoC): Another service that has been with us for quite a number of years now. One US operator had and still has an interesting PoC service but it is based on proprietary hardware/software which hurts general usage. There have been proprietary approaches to bring PoC to the GSM/UMTS world as well but none have really gained great traction due to pricing, user unfriendly clients on mobile phones and non interoperability between national and international mobile networks. IM can change this as the OMA PoC specification now allows vendors for the first time to offer standardized and interworking PoC Servers. This enables talk groups which span multiple national and international wireless networks. A standardized PoC solution will also bring better PoC clients on handsets and will increase the number of PoC capable handsets.

• Addition of video during a voice call: Today, circuit switched 3G wireless networks a capable of transporting voice and video calls. In many cases, however, users would like to add a video stream to an ongoing voice call rather to start a video call in the first place. IMS offers a nice way of doing that by either adding video to an ongoing IMS voice call or to add a video session to an ongoing circuit switched call which is not controlled by the IMS. The later scenario is probably the one going to hit the market first as I thing circuit switched voice calls will be the dominant way voice calls are transported over the network for qutie some time to come. The transmission of the video can also be stopped at any time during the call to continue the conversation in voice only mode.

• Voice Call Continuity (VCC): Standardized in 3GPP TS 23.206 this new IMS service offers quite a number of new possibilities for voice calls: Ongoing calls can be switched from Wireless to Wifi at any time using 2G/3G/Wifi handsets such as the Nokia N-series and E-series phones. Also, a call can be transfered at any time to another handset. Quite nice when you come home and would like to continue the call via the fixed line table phone with good hands-free/loudspeaker facilities. VCC requires a special client in the mobile again but since it is standardized it’s possible that many vendors will likely implement this. Imagine a combined VCC + addition of video during call scenario. You talk to somebody over the 3G network while you drive in the car, carry the phone with you into your apartment and then you transfer the call to your home entertainment system to activate a video feed for the rest of the conversation. Here’s a video from the Daidalos project which impressively demonstrates the possibilities.

In 2006, HSDPA was an important topic during the 3GSMWorldCongress in Barcelona. Let’s see, maybe IMS will be the topic of the year in 2007 during the conference. It would be nice to see real demos of some of the applications above.

While VoIP and video streaming in the home network might have been exotic applications just a year or two ago, they are more and more moving into the main stream segment. Quite a number of VoIP phones are on the market now such as the Linksys Skype phone, the UTStarcom F1000G SIP phone or the Nokia E-series 3G/Wifi phones. While network load on the wireless link is low, speech quality is usually rather good. Things start to deteriorate, however, once the network starts to get loaded, e.g. due to a high bandwidth file transfer.

To improve things, the IEEE standards body has created the 802.11e standard which defines a number of Quality of Service measures for 802.11b/g/n Wifi networks. All are backwards compatible so 802.11e compatible Wifi access points can handle new and old devices simultaneously. In addition, the Wifi Alliance has created the WMM (Wireless Multimedia) certification program to ensure that devices are interoperable with each other and implement the most important options of the 802.11e standard, priorities and prioritized scheduling (EDCA, Enhanced DCF Channel Access).

While researching the topic, I was wondering how applications running on a PC or notebook for example can take advantage of WMM. After all, not all packets originating from a single device should be treated alike by the wireless card. While packets of a VoIP SIP client running on a machine should be treated with the highest priority, packets of a simultaneously ongoing download or web session should be treated with less priority in order for the VoIP packets to flow smoothly. It took quite some reading to find the answer to the puzzle:

• The WMM certification requires that an application shall control the setting of the QoS field in the 802.11 header by setting the DSCP (Differentiated Services Code Point) field in IP (layer 3) packets according to the priority needs of the application. I gave it a try with a SIP soft-phone client and indeed the DSCP field is set to "Expedited Forwarding" instead of "default" as is the case in other packets (see picture above).

• This and this blog entry by Gabe Frost explain how an application can set the DSCP field when opening a socket connection in Windows Vista and how a WMM compatible wifi network driver then makes use of this information to add a QoS header to the 802.11 MAC (layer 2) frame. In addition, wireless devices will only get the "Designed for Windows Vista" sticker if they implement WMM. Good thing!

Once the frame is maked with a QoS header it is delivered to the wifi card. The wifi card then uses the layer 2 QoS header field to put the frame into the correct priority queue. The following parameters, which are broadcast by the wifi access point, are then used by the network card to decide how long to wait before attempting to send a packet once the air interface is not used by another device:

• The number of slots to wait before starting the random backoff procedure. This value is called the AIFSN (Arbitrary Inter-Frame Space Number). The highest priority queue has to wait for the fewest number of slots before the random backoff procedure is started.

• The random backoff procedure is used to prevent several network clients to start transmitting at the same time. The backoff window size for a frame also depends on the priority queue it is currently waiting in. High priority queues have lower maximum backoff window sizes then lower priority queues. This allows other wireless clients to send their high priority frames before low priority frames of other clients.

• The maximum time before the client has to cease transmitting (TXOP). High priority frames are usually very short (e.g. 74 bytes of a VoIP RTP packet compared to 1500 bytes of data contained in a frame which transports part of a web page). A low TXOP time for high priority queues prevents applications mis-using a high priority for large data transfers and they are also not able to interfere with high priority frames from other local and remote applications.

So if access point vendors, network card manufacturers and operating system designers do their homework VoIP calls and video streaming over wifi should be smooth in the future, no matter what other users are doing in the network simultaneously.

P.S.: QoS issues do not end at the Wifi access point of course. Other measures have to be taken to let the VoIP packets flow in the DSL up- and downlink just as nicely. But that’s another story for another day 🙂