Being a Mobile Network Operator For a Day

Plugs
When you go to a lot of meetings at other people’s locations you learn over time to take two indispensable things with you to stay connected: First, a multiple socket outlet with a long extension cable as there are usually only two power sockets for 20 people. This has the nice side effect that other people are usually more than grateful for your seemingly bright idea (see picture on the left). Second, I bring my own Internet access as either there is no Wifi or Ethernet cable available or a firewall blocks my IPsec connection back to the home network.

Ap
Last week, I hosted an internal meeting at one of our locations for a number of employees coming to town from all over the world. Usually, our Wifi network works quite well except, of course, when you need it. So the local Wifi went on strike as soon as our two day meeting started. But we are an R&D lab, so we have Wifi Access Points around that can take over in times of crisis. So I became a mobile network operator for a day.

Traffic1
The Linksys WRT-54 Access Point with OpenWRT has a nice graphical network traffic analysis tool which I used throughout the meetings to see how much the network was used. Most of the time there were around 15 people connected to the access point, mostly for keeping up to date with their eMail and browsing the web a bit (the split attention syndrome). Even in the breaks when usage increased I was quite surprised that the usage of the network rarely went beyond an average of 10-20%. In other words, most of the time 80-90% of the capacity was not used.

Traffic2
I would have guessed before the experiment that utilization would be much higher as people often report from conferences that Wifi access at some point comes to a standstill. Looks like my conference was too small and my visitors less demanding despite some YouTube videos being streamed during the breaks 🙂

On the left are some graphics which show how the network was used during high times. The time recorded on the graph is around 4 minutes.

Offline Web Applications on Mobile Devices

I am currently doing some research in which directions applications on mobile devices will develop in the future. The following post on offline web applications on mobile devices has been inspired by a blog entry on Ajit Jaokars OpenGardens blog.

On the desktop, many web browser based JavaScript applications exist today with well designed user interfaces and connectivity to services and databases on the web. Web based applications such as GMail (email reader), Bloglines (blog reader), Writley (text processor), etc. are now even taking over some of the functionality of locally installed programs.  On mobile devices, this trend is not yet wide spread. In my opinion, there are a number of reasons for this:

  • Web browsers on mobile devices need to become AJAX capable. This is well underway and in the mid-term its likely that most mobile devices will include such a browser. As JavaScript and the functions for asynchronous communication with the web server are standardized, developers can design applications which will work over a wide variety of mobile devices. This is an important key to success as services which only work on a limited number of mobile devices are unlikely to be successful as they will be unable to attract a sufficiently large user base.
  • Web applications need to work even if the network is not available. This is crucial for applications such as calendars, address books, etc., which have to be accessible at any time and any place.
  • Some applications should also be able to get access to the resources of the device which is important for applications used for uploading information such as pictures to the web or use the device’s built in GPS device to get the current position to be able to deliver information relevant to the user’s current location.

With the traditional server/browser approach these things are not possible. If the connection to the network is lost, web applications can not be loaded onto the device from the web server and user input can not be sent back to the web. A number of different initiatives have thus started to address these shortcomings.

Google Gears

Google’s approach is based on a web browser plugin which offers JavaScript applications on web pages an API to store pages locally. Furthermore, the plugin allows applications to store data locally. When the page is accessed when the device is not connected to the network, the local copy of the web page including the JavaScript program is used instead. The Gears plugin extends a web browser with the following functionality:

  • A local server which feeds the web browser with web pages which have been stored in the local cache in case the device is used in offline mode.
  • A relational database in which JavaScript applications on web pages can store information. To stay with the example above, a calendar application could hold a copy of the user’s calendar entries which are synchronized with the calendar entries in the web when the device is online and the application is used.
  • As synchronizing the local and remote data depository after going online could take considerable time it is important that such activities do not block the execution of the JavaScript application on the web page. Thus, the Gears API contains a ‘WorkerPool’ which allows executing JavaScript code in the background.

At the beginning of 2008, Google Gears is only available for desktop based browsers as it depends on a web browser plugin interface which is not yet available in any mobile browser. As the software is available as open source under a BSD license the way is free for mobile browser developers to include it in future versions of their products. While Google Gears enables web applications to run offline, there is not yet an extension which also allows web applications to use local resources (e.g. access to the file system, getting network information, GPS information, etc.).

Nokia S60 Web Widgets

Nokia’s vision for local web applications on mobile devices are widgets. Unlike Google Gear’s approach a widget is not executed inside the web browser. Instead, it just uses the web browser’s core as a runtime environment and otherwise looks like a native application. Widgets can even have their own icon that appears along local applications in application menus of the device. Not running in the user interface of the web browser but instead having the full screen available has a number of advantages. From the user’s point of view the program can be started and controlled just like local applications. When the widget is started by clicking on the icon in the program list, the web browser core is loaded and the JavaScript and HTML page which the JavaScript application can modify is shown on the screen just as a local application.

The first version of the web widgets packet does not offer local storage to applications which limits its use to times when the device is connected to the network in case data needs to be stored between invocations of the widget. Also, there are no interfaces at the moment to get other data from the device such as calendar entries, address book access, etc. Widgets do have access, however, to system information such as the current battery power level, network properties such as signal strength and network name, display light control, vibration control, speaker control, memory properties, etc.

HTML-5

For version 5 of the Hypertext Markup Language (HTML) the World Wide Web Consortium (W3C) is specifying tools to make web pages and embedded JavaScript applications available offline. The approach taken by the W3C is very similar to Google Gears and also features offline caching of web pages and a data repository for JavaScript applications to store data locally. There are two ways of storing data locally. For simple data structures, data can be stored in name/value pairs. For more complex data, JavaScript applications can use a SQL database with standardized functions to query, insert, change and delete data. The advantage over Google Gears is that once the standardization of HTML-5 is finalized, browsers can natively support offline web applications and a plugin like for Google Gears is no longer required.

That’s it for a first overview. In a future post I’ll take a look at data synchronization between the network database and the local cache, why and how some applications should be able to access local data beyond the cache and the security and privacy implications of local web applications.

As always, comments are welcome.

IMS Terminal Specifications

While 3GPP specs pretty much go on the bit layer to describe how the IMS should look like in the network, I was wondering lately how the IMS could be implemented from the handset point of view. Here are links to two interesting documents which give a rather interesting insight into how the industry thinks IMS should work on terminals:

Bit Pipe or Profiting from the Long Tail?

Mobile network operators are always pointing to the fact that they don’t want to be mere bitpipes but would rather prefer to remain a network + service provider as they are with voice telephony today. Most have recognized some time ago that this is a rather unrealistic goal and are opening their walled gardens. But maybe this bitpipe disgust could be remedied with a different perspective on things!?

Apart from the few killer apps born out of web 2.0 (Google search, maps, Flickr, Amazon, eBay, Facebook, …) most people today use quite a number of services in the Long Tail of the web. In case you are not familiar with Long Tail economics, take a look the original article by Chris Anderson published on Wired magazine which focused on goods on the long tail but is in my opinion applicable to services as well. It is these startup or niche segment services that might give the final incentive for users to consider going online from their mobile. The "problem" for network operators is that they can’t be the provider of the killer apps, since they are already out there and they also can’t be the provider of those niche apps, since there is not a lot of money to be made in the long tail as this article by Alex Isold on ReadWriteWeb aptly points out.

What Alex also points out, however, that while you can not make a lot of money in the Long Tail but you can actually make a lot of money WITH the Long Tail as aptly demonstrated by Amazon or eBay. So now look at mobile operators: Selling bandwidth is nothing but making money with the Long Tail of the web. Sounds a lot better than ‘bitpipe’, no?

Comments as always welcome!

Broadband Internet via 2-way Astra Satellite

Every now and then I get an eMail from someone asking me for advice on how to best hook up to the Internet from that little cottage they have bought in a remote place in Italy. Not quite sure why it’s always Italy, seems to be a nice place for a cottage. If 3G is not available their best chance so far was to buy a prepaid SIM card from TIM and use their nationwide EDGE network. But it seems there is no an affordable alternative available.

SES Astra has started their broadband Internet satellite service that does not require a phone line for the return path. The receiver/transmitter requires a satellite dish or, in case a satellite dish is already installed for reception of TV programs from the Astra satellite, the receiver/transmitter can be installed alongside the TV receiver module.

It seems the service is not sold directly by Astra but via national resellers. In Germany, Filiago is the reseller. A flatrate with 1 MBit/s downlink and 128 kbit/s uplink is available for around 40 euros a month.

According to Astra the service is available throughout Europe. Very nice!

Why The Mobile Web Had Such A Terrible Start

I’ve been thinking a bit about the recent history of mobile Internet access lately because I was wondering why it had such a teribble start. In the mobile world, the web had a much more difficult start compared to the fixed line world for a number of reasons. First attempts by mobile phone manufacturers to mobilize the web were a big disappointment for quite a number of reasons. In the fixed line world the web got an incubation time of at least a decade to grow, to be refined and to be fostered by researchers and students at universities before being used by the public who already had sufficiently capable notebooks, PCs and a reasonably priced connection to the Internet. In the mobile world, things were a lot different when first web browsers appeared on mobile phones around the year 2001:

  • Mobile Internet access was intended straight for the public instead of first attracting researchers and students to use and refine the services. Unlike at universities where the web was free for users, companies wanted to monetize the service from day one.
  • Few if any appealing content for the targeted audience was available in an adapted version for mobile phones.
  • Mobile access to the Internet was very expensive so only few were willing to use it.
  • Circuit switched bearers were used at the beginning which were slow and not suitable for packet switched traffic.
  • The mobile phone hardware was not yet powerful enough for mobile web browsers. Display sizes were small, screen resolutions not suited for graphics, no color, not enough processing power and not enough memory for rendering pages.
  • Use of a dedicated protocol stack (the Wireless Application Protocol, WAP) instead of HTML required special tools for web page creation and at the same time limited the possibilities to design mobile and user friendly web pages.

Each of the points mentioned above would have been enough on its own to stop the mobile web in its tracks. Consequently many roadblocks needed to be overcome before the Internet on mobile devices started to become interesting to a wider audience. This fortunately coincided with the emergence of the web 2.0 and its evolution into the mobile domain. But that’s another story.

As always, comments are welcome!

TDD UL and DL Ratios and Uplink Speeds

An interesting technical detail came to my attention today concerning Time Division Duplex (TDD) wireless systems such as WiMAX: Since uplink and downlink transmission is done in the same frequency band, uplink and downlink capacity can be adjusted based on demand. In theory this is an advantage over FDD (Frquency Division Duplex), used by most cellular 2G and 3G systems today. Here, uplink transmissions use a seperate frequency band which is just as large as the downlink frequency band (e.g. 5 MHz for UMTS). This means that FDD systems always have a 1:1 ratio between uplink and downlink. With TDD systems, this ratio can be changed, for example to 2:1, 3:1, etc. to give more capacity to the downlink. But there is one important thing to remember: The efficiency of uplink transmissions is much lower than in the downlink due to the lower transmission power and small antennas of the mobile device. Thus, even with a 1:1 ratio, uplink data rates are far lower than data rates in the downlink despite the using the same amount of bandwidth. I estimate that the maximum overall speed achieved in uplink direction is only 1/3 or 1/4 of the downlink. With rising uplink requirements of web 2.0 applications (picture, video uploads for example) I wonder if it will even make sense in practice to configure a 2:1 or 3:1 ratio in TDD systems as the uplink capacity would then be only a tenth of that of the downlink!? Opinions, anyone?

NokiaWorld: Chris Anderson and What Happens When Things Become Almost Free

Not much news from NokiaWorld which took place this week in Amsterdam concerning the hardware side. No cool N95 successor announced, no mind blowing N93+++ in the pipe. I am a bit disappointed. But the presentations of the guest speakers made up for it a bit. A lot of videos of what happened can be found here. I’ll surely take a look at most of them in the next couple of days. I’ve watched Chris Anderson’s presentation today on the impact of things that almost become free. For a minute he speculated what would happen if Nokia gave away the phone for free and charged for services. Well, I would "buy" a new phone instantly 🙂

IMS and the TISPAN secrets – Part 2

IMS and TISPAN, a bit of a mystery combination. In part one I’ve taken a look at what TISPAN is and how it uses IMS in it’s architecture. This part focuses on the PSTN/ISDN Emulation Sub-System and how the IMS can be used to simulate an analogue telephony switching center.

Besides the IMS subsystem the PSTN/ISDN (Public Switched Telephone
Network / Integrated Services Digital Network) Emulation Sub-System
(PES) is another important element of TISPAN. Its aim is to enable
legacy analog and ISDN telephones to be connected to an IP based next
generation network (NGN) via a media gateway which is either part of
the access modem or a standalone device. An IMS independent
implementation for PES is described in ETSI ES 282 002 while ETSI TS
182 012 defines how a PES can be implemented with IMS. Both standards documents are available via ETSI’s web site for free but one must register first.

As legacy devices can not be
modified a gateway has to be deployed on the user’s location. On the
one side of the gateway the analog or digital telephone is connected to
a legacy connector. In case of a standalone device the other side of
the device usually features an Ethernet connector with which the device
can be connected to the DSL or cable modem. The PES specification in
ETSI TS 182 012 knows two types of devices. Voice Gateways (VGWs)
emulate a SIP User Agent on the behalf of the legacy device and
communicate with SIP commands with the P-CSCF of the IMS. The second
approach is to deploy a media gateway (GW) which communicates via the
H.248 (Media Gateway Protocol, MEGACO) to the Access Gateway Control
Function (AGCF). In this approach the SIP User Agent functionality is
included in the AGCF, i.e. not on the customer device but in the
network itself.  Additionally, the AGCF includes the P-CSCF
functionality. During call establishment, the P-CSCF or the AGCF then
communicate with the RACS to reserve the required transport resources
to ensure the quality of service for a call. In addition, PES requires
an IMS Application Server (AS) to emulate the PSTN or ISDN service
logic when the PES User Agent sends SIP messages with embedded ISUP
messages.

And a final note: The TISPAN standard also aims to standardize non IMS
sub-systems. While out of scope of the current version of the
specification it is likely that TISPAN will specify a standardized IPTV
and Video on Demand (VoD) system in the next version.