A year ago, I reported that I could receive a stunning 13 Wifi networks at my flat. Since then, the number has risen even further! When I checked this time, I was able to detect over 25 access points, not counting secondary SSIDs of some access points and those networks that could be received but not decoded correctly due to their weak signal strength. Channel 11 is a hot place with over 10 access points sending out their signals in this area. A place in the spectrum definitely to be avoided as at least one access point sends a continuous high bitrate broadcast, probably a TV or video stream. The screenshot on the left, taken with WiSpy/Chanalyzer, shows the distribution of the networks on the different channels an how strong they can be received. My own network is the red curve on the left on channel 1, with at least three or four additional networks using the same channel. However, compared to what's going on at channel 11, this spot in the spectrum can be considered as being almost calm.
An IMS Wireshark Trace
Thanks to the guys at Fraunhofer FOKUS in Berlin, IMS has moved from theory to at least a bit of practice for me as I reported in THIS BLOG ENTRY. As a little souvenir, I got the (Wireshark) pcap trace for an IMS voice call from many different interfaces including interactions between the IMS core and the network layer. Traces a great, one can learn a great deal of how the system works by looking at who says what to whom. Since I got the permission to share the trace I thought I'd post it here since I am sure some of you would like to have a look, too.
Most packets will decode nicely with a standard Wireshark installation, only the router interaction to allow more bandwidth for the connection requires additional DIAMETER xml descriptions. These have to be put into the /wireshark/diameter directory and the dictionary.xml file in the same directory has to be extended as follows:
At the beginning of the file put the following xml descriptions into the already existing list:
<!ENTITY TGPPRx SYSTEM "TGPPRx.xml">
<!ENTITY TGPPGx SYSTEM "TGPPGx.xml">
Afterwards, put the following instructions at the end of the file to load them.
&TGPPRx;
&TGPPGx;
</dictionary>
Final step: Open Wireshark, go to 'edit, 'preferences', 'protocols', select DIAMETER and add ports 4868 and 5868 to the default port 3868.
Have fun!
SIP and AMR
Another post on SIP, yes I am doing a lot of experimenting around it these days. While we don't have AMR-Wideband yet on Nokia phones, one experiment has at least confirmed that for Nokia SIP to SIP device calls, the bandwidth efficient AMR (Adaptive Multi Rate) codec is used instead of the default G.711 codec. The figure on the left shows how this looks like in Wireshark. While the bandwidth requirement of G.711 is 2 x 85.6 kbit/s (uplink + downlink), AMR brings the transmission bandwidth, including Ethernet, IP, UDP and RDP header down to 2x 34.4 kbit/s. The codec rate itself is only 12.2 kbit/s, so 2/3 of the required bandwidth goes into packetization header overhead. While not much can be done about that in most parts of the network, Robust Header Compression (ROHC) in future wireless radio networks can reduce the overhead from 54 bytes down to just a few, thus making SIP calls almost as efficient as current wireless circuit switched calls.
Network Based Packet Modification
By now I guess you must have heard of Deep Packet Inspection (DPI), a method of looking at each IP packet passing through a gateway router for the purposes of making statistics or to shape the traffic of users depending on the content of the packet. A recent article in Heise News now describes what kind of other features such gateways seem to have built in these days. The report states that wireless network operator of O2 (Telefonica) had “accidentally” activated a feature for some time that did not only look inside the packets but also modified their content to prevent email being sent over an encrypted connection.
It’s easier than it sounds: Most email programs encrypt the connection, if they activate it at all, if the SMTP email server tells them at connection establishment that encryption is available. To this end, the server includes a “250 – STARTTLS” notification in the startup information exchange. To prevent the email client from activating encryption, the network based router simply overwrote this string with “250-XXXXXXXA”.
If the email program is configured to use optional encryption, the email is transferred without establishment of a secure connection and the user does not notice anything at all. The email transfer only fails if the email program is set to require transport encryption, which for example, has to be set manually in Thunderbird and is thus not used very often. In this case the user gets an error message which is how the whole story was uncovered. The same approach also works to stop encryption being activated between SMTP servers exchanging email allowing to look into email transfers between any two SMTP servers such a router sits in between.
Clearly this kind of packet inspection and modification does not serve traffic shaping purposes…
Mobile Broadband Use in Sweden – Interesting Statistics
I have never been to Sweden before, but judging from Ram Krishnan's report on his blog and the pages on Sweden on the prepaid wireless internet wiki, it seems the situation there concerning mobile broadband use is similar as in Austria: Affordable prices and prepaid SIMs that make it easy to go online with a 3G USB stick have made the mobile broadband market surge in the past 18 months. Ram quotes from the 2007 Swedish Telecommunications Market Report of the National Post and Telecom Agency (PTS), available in English here, on the uptake of mobile Internet access in Sweden. Here's my interpretation of the facts and figures:
Only 1% use mobile broadband as their only Internet access
If you have some time, take a look at diagram 8 in the report and Chapter 5 in general, there are some very interesting facts: The diagram shows that at the end of 2007 there were about 375.000 mobile broadband users, up from only 90.000 a year earlier. That compares to about 3 million DSL users and a population of around 10 million. The report says on page 39 that of 2.000 people questioned, only 40 said that they used the 3G dongle at home to complement another access method and only 20 (i.e. = 1%) said that the 3G dongle was their only Internet connectivity at home. So these numbers clearly point out that 3G Internet access is currently used mainly as a supplement to fixed line Internet connectivity. The report also says that since this is a relatively new phenomenon and that it remains to be seen if 3G will remain mainly an add-on to fixed line connectivity at home or if it will seriously start to compete with DSL.
500MB on average per user per month
Diagram 8 says that 375.000 users generated a traffic of 2.200 Terabyte (in the whole of 2007 ?). If you do the maths that amounts to (2.200.000 GByte / 375.000 users / 12 months = 493 MBytes / month.
How Close Are We To Saturation?
So how much is this in practice, how close are we to network saturation? I guess that's quite easy to say for someone who has access to the data of mobile operators. But I don't have that, so let's do a little extrapolating to get an idea of where we might be here with a bunch of assumptions: Let's say the number of people covered by a single 3G base station is roughly the same as a 2G base station, 2000 people. 375.000 broadband users compared to a population of 10 million is 3.75% of the population. Let's double that value to 7% to account for unequal 3G network distribution. 7% of 2000 people are 140 people per cell with a 3G card. Let's say the base stations usually have 3 sectors, and each sector gives an average throughput of 2 MBit/s. That's 6 MBit/s in total. Let's say busy hour accounts for 10% of the daily traffic of 500 MB * 140 people / 30 days / 10 = 233 MB/hour/base station. The capacity of the base station is 6 MBit/s * 60 seconds * 60 minutes / 8 bytes = 2700 MB/hour (minus the capacity used for voice calls).
The above calculation brings us at less than 10% of total available capacity of a base station today. But the input parameters used are highly speculative so the number could easily be half of that our it could be double. If anyone has a different opinion, please let me know.
How Much Traffic Growth in 2008 And Beyond?
This of course opens up the big question of how the growth will continue. When taking the 2006 numbers from the report, an average user consumed 200.000 GByte / 90.000 users / 12 months = 185 MByte / month, i.e. less than half of that of 2007. So this year's traffic and that of the following years will depend on:
- How many additional users can be signed up
- Do these users have the same usage patterns as the users today, or more, or less? Potentially, falling prices could attract users with less usage and only very occasional use but also other groups with little money but high Youtube desire.
I think the numbers are hard to predict since the user behavior and clientele will change. While I think that at this point Generation Youtube is not yet on a 3G stick, I wonder what will happen once they do?
The report references a forecast for 2008,
which reports another 140.000 3G USB sticks have been sold in the first
quarter 2008 and which expects 600.000 users by the end of 2008, an
increase of 40% over 2007. This is impressive but definitely a slowdown over the growth observed between 2006/07.
If we stick to the numbers above, we should still be way clear of the capacity limit for 2008. Same for the year after if another 300.000 subscribers are added. If the amount of traffic per user grows by a factor of two in that time frame and the network stays the same, data traffic would grow to 933 MB/base station/h in 2010, still clear of the capacity limit.
Once the limit of current deployments are reached, operators have a number of options:
- Deploy a second carrier frequency
- Densify the network, i.e. install more macro, micro or pico base stations to reduce the coverage per site and thus the number of users per base station
- Work on DSL/mobile broadband conversion and offer interesting packages to users to offload traffic from the mobile network. This of course only helps if people start using wireless broadband as an alternative to DSL. This doesn't seem to be the case so far.
Anyway, one thing is for sure: In countries where broadband wireless access is priced attractively, base stations are no longer just stitting around idling and producing only heat.
Carnival of the Mobilists 143 at the Smartphone Show Blog
This weeks Carnival of the Mobilists is hosted by Steve Litchfield, whom many might know from his Smartphone Show no rebranded to "The Phones Show", the definite video guide on the latest smartphones appearing on the market. As always, the carnival is a great read and summarizes the week in the blogsphere on mobile topics. So head over and enjoy!
An IMS Morning at FOKUS in Berlin
Some encounters are interesting, fun, inspiring and enlightening on top. The recent meeting I had with Dragos Vingarzan, Alberto Diez and Bogdan Harjoc of Fraunhofer FOKUS NGNI can certainly be counted among them. For those of you who have not come accross FOKUS before, they are a German research institute under the roof of the Fraunhofer Gesellschaft and their group is working on IMS related topics. Here's a short roundup of what I've seen and what we discussed, which might be interesting to those of you working on any kind of IMS topic:
Over the years they have put together an impressive IMS setup. Not only have they developed an extensible IMS client, an IMS core network for testing purposes comprising all elements from the various CSCF's, an HSS, presence server, etc., etc., but they have built lots of tools around it from application server toolkits to stress test utilities. Also, they've put their setup to good use and developed a number of stunning IMS application prototypes. On top, their lab and software is open for any company wishing to test their components, devices or IMS backend software in an end to end system. HP, Ericsson, Nokia, Tektronix and many others are making frequent use of it.
Want to play around with an IMS core at home and have a look at the code? No problem, they offer their open source IMS core as a Vmware package that is ready to run with a Vmware player right from your PC.
Not only did I see my first real IMS VoIP call including policy interactions between the IMS network and a core network router, for which I was kindly provided with the pcap trace for some follow up investigations, but I was also shown a stunning combined IMS VoIP/Instant Messaging/Sharing/Collaboration application and a utility called SIPNuke that can easily simulate 10.000 SIP messages a second on an off the shelf notebook to make that IMS core or application server sweat.
If you want to see it for yourself you can do so on the 6th to the 7th November during the 4th International FOKUS IMS Workshop in Berlin. Here's the link for further information and registration.
Thanks Dragos, Alberto and Bogdan, it has been an exciting visit! I'll put some more detailed thoughs on the demos I've seen in one of the next blog entries.
Breakthrough for VoIP with Wideband Codecs?
I recently wondered why we are still using narrow band speech codecs for VoIP calls between two SIP devices. There were a number of interesting answers and as always the issue is multi-faceted. However, it seems that wideband codec capable devices are now appearing on the market and SIP phones such as the Siemens Gigaset 6XX are actually advertised with superior voice quality between two 'High Definition Sound Performance' (HDSP) phones these days. Here's a link to a web page that demonstrates the difference between today's voice quality and the wideband codec used by Siemens.
While it is difficult (but not impossible) to introduce wideband codecs in fixed and wireless circuit switched networks (e.g. due to the required tandem/transcoder free operation) things are pretty much straight forward in IP based networks. Here, devices negotiate the speech codec to be used directly and no interworking-, transcoding- and digitizing functions are required beyond the user's device that would force the use of a specific speech codec.
Let's hope we don't have to go through many years of fragmentation
where each vendor implements his own set of wideband codecs,
incompatible with those of the competition. But in the end I can very well imagine that wideband
codecs are the missing piece to bring a real breakthrough for
VoIP. So far, VoIP offers little to nothing beyond circuit switched telephony to the average user. With wideband codecs, however, I am sure most people will start convincing others to switch once they've been on a wideband conversation with someone.
For true success, an important additional requirement is that VoIP providers connect their registrar servers with each other to avoid the call being routed into the circuit switched national network first before being thrown back into the VoIP domain. When this happens, there is no transparent VoIP connection in place and consequently the smallest common denomitator, today's G.711 narrow band voice codec, is used for the call.
Well, maybe it's not so straight forward after all… As always, theory and practice…
Trapeze Networks: Giving Wifi an Edge (Literally)
Recently, I came across Trapeze Networks and the name instantly rung a bell. Yes, that's the company Matthew Gast works for, author of THE book on Wifi. Trapeze does a lot beyond the MAC header with Wifi and has a couple of features in their equipment I was not aware one could do with Wifi these days. I was especially amazed by the location tracking features they have put into their equipment.
By triangulation with several access points and some other tricks, it's possible to detect the location of a client device within a few meters. This feature can be put into good use for a number of applications:
- Access Restrictions: It's possible to restrict network access for a set of users to specific parts of the coverage area, i.e. one can use the same Wifi infrastructure for both employees and guests. Besides restricting guests to pure Internet access it is also possible to limit their access to meeting rooms. This is not done on a per access point limitation but by triangulation, which means permission to use the network can be granted for a location that is much smaller than the coverage area of an access point. It's also possible to limit access to the network to the building, and stop anyone from accessing the network from the parking lot nearby.
- Equipment Tracking: The location of active and passive WLAN Tags (e.g. have a look at AeroScout) can be monitored to track the location of equipment or devices.
- Find rouge access points: One of the biggest threats to company security is employees bringing their own Wifi access points from home and connecting them to the network. If not properly secured they can be an open door into the company's intranet for anyone in range. With localization, the Trapeze access points can not only detect the presence of such access points and warn the network administrator but also include the approximate location of the equipment in the message.
- Find unwanted devices or attackers: In case outsiders try to penetrate your network, the system can not only warn the administrator of such attacks but again include the location of the attacker, which is an invaluable help in large campus wide networks. Trapeze says their access points and controllers can detect over 200 different types of Wifi attacks and warn the administrator. The system even offers the possibility to "shoot back". I am not quite sure what that means in practice but I am sure it would be fun to find out more about this feature.
Also quite amazing are their tools for site surveys, maintaining the network, their features for VoIP over Wifi for QoS on the air interface (WMM), optimized routing of VoIP calls through the network, their 802.11n implementation in their new MP-432 access points, which by the way look like smoke detectors, etc. If you want to check out their site, bring some time, there is tons of good information to be discovered there.
T-Mobile USA and the HTC G1 Google Phone – An Interesting Couple
O.k. the HTC G1, or the first Google Android phone, is about to launch and everybody is looking at the Google side of things. But have a look on the other side of the equation: That phone has to use a network. And this network is going to be T-Mobile USA. The interesting thing about this is that this is one of the two networks on this planet that is using 1700 MHz UMTS. For the moment, they only have three very low end 3G phones (according to Wikipedia, see here, here and here) which must sell very well against insignificant competition such as the iPhone.
The HTC G1 will be even more than a quantum leap for T-Mobile USA, it will be the first phone which will use their 3G network in a meaningful way. The HTC page doesn't yet list a lot of network specifications on the device yet. I wonder if it will be dual band 3G, 1700 MHz for T-Mobile USA and 2100 MHz for the rest of the world or if the version announced for the UK will be a different hardware. But then, how about positively surprising me and delivering a Quad band UMTS device with 850, 1700, 1900 and 2100 MHz UMTS built in? Now that would be something, but I'd be really surprised.
I just had a look around which other phones do/will support 1700 MHz. Interestingly the Sony Ericsson X1 came up as 1700 Mhz + quad-band 3G capable. I wonder if T-Mobile USA will pick it up sooner or later!? Also interesting is the Wikipedia link on UMTS quad-band and UMTS tri-band. They give a pretty interesting overview which 3G phones work on more than one continent on speeds faster then EDGE. Nice to see that the list is growing. But what would really be nice for true world roamers are 5 bands. How would that be called? Quinband?