MMS Still Doesn’t Get Through

A quick self observation today: For the second time in so many weeks, I've sent an MMS message to someone just to get a call later-on in which the other person tells me that they've received an SMS message that I sent them a picture and that they can take a look at a web address. With all the spam these days, both callers were a bit worried if it was actually a scam.

Three things are not right here:

First, the MMS should have been delivered but wasn't because both persons lately changed their phones and it seems the network was not quite sure the multimedia messaging configuration in the phone was correct.

Which brings me to the second point: In many networks, MMS messages still cost significantly more than SMS messages. And while SMS messages are perceived as practically free by many people because an unlimited amount is part of their contract, MMS is still the expensive and disregarded sibling. While this goes on, MMS will never become popular.

And finally, I wonder how many of those MMS messages that were not delivered would have gone through anyway if the system had tried!? The system could even be sure that the configuration is correct by sending an MMS message once an initial auto-configuration SMS has been delivered to the phone (that the user has to confirm). When this MMS is delivered correctly, one can assume that the configuration succeeded.

So quite a number of fronts to work on to bring MMS to the masses. It's not a technology question anymore…

Offline Navigation Not Google’s Business Model?

Since the start several years ago, Nokia Maps, called Ovi Maps these days had offline navigation capabilities, i.e. maps data can be stored on the mobile so there's no data cost for navigation except for the few kilobytes of data required to get the A-GPS ephemeris almanac when the program is started to give the GPS chip a hint where the satellites can be found. This is not only beneficial to keep the delay down when scrolling through a map but is a bare essential requirement for me due to the high roaming charges for data as I often use navigation abroad. I guess I am not the only person with the problem which is why I find it even more surprising that Google still doesn't have an offline mode for Google maps. But perhaps its not so surprising because Google is a company that has its services in the cloud. So an offline mapping application doesn't make much sense for their product portfolio. So maybe that's the explanation!?

Let’s talk about LIPA

I recently read somewhere that 3GPP stage 2 specifications for Local IP Access (LIPA) are in pretty good shape by now so I thought it was time to take a look to understand the basic principle that is taken forward. So here’s my summary:

First of all, the general idea of LIPA is to enable a UMTS or LTE device to access the local IP network that a femtocell is connected to. In other words, when a user has a femtocell at home or in the office, mobile devices can use LIPA to access devices that are connected to the local network such as connected TVs, video and picture libraries on computers, NAS servers, etc. over the femtocell.

A number of different approaches were studied in 3GPP and the different options can be found in 3GPP TR 23.829. The selected solution that now goes into Technical Specification (TS) documents can be found in 7.2.1, where it says that LIPA solution 1 variant 1 described in 5.2 has been selected. Note that TR 23.829 also treats SIPTO, which stands for Selective IP Traffic Offload, but that’s something different and a topic for another post.

The selected solution for LIPA works as follows: To get access to devices on a local network to which a femto is connected to, the mobile device can use a special APN. The APN tells the SGSN (UMTS) or the MME (LTE) that the mobile device wants to get a connection to the local network and not to the network operator’s core network. This way, the solution is backwards compatible to current devices, i.e. LIPA will work without any software modifications on devices. Optionally, a LIPA flag is defined that can be sent by the mobile device during the PDP context establishment (UMTS) or the Default Bearer activation (LTE) for the same purpose. This, however, requires some additional software in the mobile device.

For simultaneous access to the local network and the Internet, two solutions are given in the TR. First, the mobile could have two PDP contexts (UMTS) or two default bearers (LTE), one that terminates in the local network and one that goes through the core network to the GGSN/P-GW. Also the TR specifically says that the in case Internet connectivity is available through the local network, LIPA does allow the UE to reach the Internet this way. This might be desirable in many cases as it nicely offloads Internet traffic as well but has some consequences for IP based network operator services such as MMS as these can’t be reached that way.

Further, the TR specifies a (logical) Local Gateway (L-GW) in the femtocell that acts as a GGSN (UMTS) or P-GW (LTE). Once the LIPA PDP context / default bearer is established data flows directly to the L-GW and from there into the local network without traversing the radio access network or the core network of the network operator.

Control of the LIPA PDP context / default bearer, however, remains with the SGSN / MME in the core network. In other words, authentication, authorization and security procedures remain with the network operator. An interesting result of this architecture is how incoming packets from the local network are forwarded to a mobile device that is in UMTS Idle/Cell- or URA-PCH state or LTE Idle state respectively. In these states the mobile device needs to be paged first and has to re-establish an RRC (Radio Resource Control) connection before the data can be forwarded. The paging remains a responsibility of the SGSN/MME and hence, the femtocell needs to send a notification to the SGSN/MME which then pages the mobile device via the femtocell. Once the RRC connection is established again, the data packet is forwarded.

Mobility of the LIPA bearer between femtocells, e.g. when several femtocells are deployed in an office is discussed in the TR, but the conclusion is that this part will not be specified in 3GPP Release 10. In other words, in a first version of LIPA, the bearer is lost when the mobile looses contact to the femtocell.

And finally, here’s a list of some of the specs that will be expanded for LIPA in Release 10: TS 23.060, TS 23.203 and TS 23.401.

There we go, this should be enough to get you started once you want to find out more about LIPA. The question for me is if it will find traction!? Today, smartphones with  operating systems such as Symbian, Android, iOS, etc. already have a Wi-Fi chip build in and the OS is capable of switching between a known Wi-Fi network and 3G connectivity automatically. Many Symbian applications can even be configured to use a specific APN / Wi-Fi network, e.g. a podcast catcher application can always and exclusively use the Wi-Fi network at home if configured that way. In other words, local access that LIPA wants to give mobile devices is already done over Wi-Fi today. As always, any thought on the topic are greatly appreciated.

Advantages of Wi-Fi Tethering And Other Uses

It's good to have Wi-Fi tethering on some smartphones these days as it has a number of advantages over Bluetooth when it comes to connecting notebooks and other devices over a mobile to the Internet:

  • Wi-Fi is now built into virtually any consumer device with services requiring Internet access while Bluetooth is not yet universally available, especially in the notebook and netbook sector
  • It's easy to set-up for the average user
  • Several people can share the connection simultaneously
  • The transmission speed of Wi-Fi is sufficient for 3G high speed data rates while Bluetooth is limited to 2-3 MBit/s.

Any disadvantage? Yes, tethering has to be manually activated/deactivated on the mobile as running the Wi-Fi chip on the mobile in access point mode quickly depletes the battery. This is unlike Bluetooth that I have switched on all the time and can thus be used for Internet connectivity without prior interaction with the device.

So what's the next step? One thing I like about Bluetooth is that I can quickly browse the file system of the mobile to transfer files such as pictures I have taken to the notebook, again without interacting with the mobile device prior to the transfer. The disadvantage is again the slow transmission speed for about 2-3 Mbit/s, making the transfer of more than two or three pictures, each being 1-2 megabytes a somewhat uncomfortable procedure.

This is where Wi-Fi tethering could help in the future. As the mobile is reachable via an IP address it could also host an SMB server so any Windows/Linux/Mac box could access the files on the device and transfers would be much quicker than over Bluetooth. Especially a plus if lots of content has to be transferred.

So let's see when this functionality will be built in as well…

Pros and Cons of EDoF

Ever heard of EDoF? No, me neither until today but something that has to be taken into account in the future when buying a smartphone. EDoF stands for Extended Depth of Field and is a fixed focus lens technology to make pretty much everything sharp and in focus from about half a meter away from the camera to infinity. Steve Litchfield over at All About Symbian has a detailed post on the topic and the pictures that can be taken are quite stunning. Have a look for the details.

There is one big caveat, however: Quite often I take a picture of A4 pages instead of scanning them as it is much faster and usually more convenient. And that's the one thing EDoF has difficulties with as it can't focus on objects that are very close. And to take a picture of an A4 page it unfortunately has to be closer than what the technology is capable of focusing on. A bit of a pity, as that means I have to stay with smartphones that have a real auto-focus camera module for now.

Bluetooth 3.0 and Wi-Fi Integration

There are quite a number of mobile devices on the market now boasting Bluetooth 3.0 support. But exactly which new features this encompasses remains a puzzle. None of the reviews I have seen so far from those devices have been able to establish if the central feature of version 3.0, i.e. the integration of Wi-Fi as a transport technology is meant or if only some other smaller improvements have been done. I suspects its rather the later and this description on Wikipedia suggests that Wi-Fi is only supported if a device is labled to support 'Bluetooth 3.0 + HS'.

In general I wonder a bit how difficult it is/will be to marry Wi-Fi with Bluetooth!? Today, the same RF chip is used for Bluetooth signaling and user data transfer. When using Wi-Fi as the bearer, signaling and user data will run over two independent hardware units that so far have no software in common at the lower layers. In mobile phones that are tightly integrated and potentially have a single chip for Bluetooth and Wi-Fi this might be easier to accomplish than on other devices such as notebooks where the two radios are on different chips, especially when Wi-Fi is built in while for Bluetooth a small USB dongle is used.

A Quick Symbian Tip: Batch Delete Old Calendar Entries

Here's a quick tip today to myself for the future which might be helpful to some of you as well: When I switch from one phone to another it takes ages to transfer all the calendar entries as I have well over a thousand on my Nokia Symbian OS phone. Most of them are years old and not very useful anymore. Deleting them one by one is not really an option. But I just found out that it's possible to batch delete them from a certain date backwards. Go to calendar – month view – options – delete entries – select date. It even figures out to leave the yearly recurring ones in. Very nice and smooth!

DoCoMo Ideally Positioned for IMS Migration?

One of the things that will make it tough for future IMS deployments is the need to hand-over a connection to a circuit switched 2G carrier when running out of coverage of a network technology such as UMTS or LTE that can support the required packet switched quality of service and speeds. Yes, there is SR-VCC (Single Radio Voice Call Continuity) and soon even Reverse SR-VCC (see here) but it's still a long way from theory to practice.

Recently, it appeared to me that a network operator that doesn't have that sort of problem is NTT DoCoMo. They are fully relying on their 3G network for everything including voice calls (which is still handled by the MSC) so there is no need to fall back to 2G. In other words, they are in an ideal position to introduce IMS, perhaps with LTE once they feel coverage is sufficient and then seamlessly hand-over the packet switched IMS voice call to a packet switched UMTS bearer.

So as you can't get it any easier, I wonder if they will be one of the first to deploy IMS?

Bluetooth Hopping

Bt2 Back in 2007, Metageek sent me one of their Layer-1 2.4 GHz probes to play around with. So far I mostly used it for Wi-Fi network analysis. But the 2.4 GHz band is also used by other technologies such as Bluetooth. Unlike Wi-Fi with its 20/40 MHz channels, Bluetooth only uses 1 MHz chunks and performs frequency hopping over the full 80 MHz of the band to keep interference with Wi-Fi and other technologies using the band to a minimum. So far the theory. How it looks like in practice can be seen on the screenshot on the left (click opn the picture to enlarge). Thanks to Metageek, your hardware and software keeps coming in handy!

Ubuntu and Bluetooth

In theory, Bluetooth is a great technology, but in practice, I find Bluetooth implementations on many operating systems and drivers for many sticks immature, unstable, not very well integrated into the OS and cumbersome to use. For example, I find the standard Bluetooth integration in Ubuntu 10.04 too rudimentary to be of much use. But then I stumbled over this web page which describes how to easily integrate the Blueman project in Ubuntu for using a mobile phone as a 3G gateway to the Internet over Bluetooth (dial-up functionality). Yes, Bluetooth is too slow these days to make full use of 3G speeds beyond but in most cases, the 2-3 MBit/s that can be squeezed over the Bluetooth link are sufficient. Also, Blueman makes file transfers from and to a mobile phone a quick and easy thing and the integration into the native file browser is great. So here's the short version of how to make it work:

  • Install Blueman: sudo apt-get install blueman
  • Hide the default Bluetooth manager icon in the tray by deactivating it in "System -> Preferences -> Bluetooth Manager"
  • Plug in a Bluetooth dongle and the Blueman icon will appear in the tray. The rest is pretty much self explaining