Category: Uncategorized

It's a good thing that the majority of mobile device manufacturers are now using the USB port on their devices for charging as it reduces the number of power adapters I have to carry along. But there's one catch: While my Nokia charges have so far featured an ultra thin and flexible cable, standard USB cables are thick and quite inflexible.

So I was wondering if there are "thin" USB cables available for that purpose as so far I've never seen one. So I searched a bit on the web and found some shops that actually sell thin USB cables. (here's an example, but be advised, I don't endorse the company, it's just an example). The cable only supports low and full speed transmissions, i.e. USB 1.1 with 1.5 and 12 MBit/s.

I am not sure if that limitation causes problems when a USB 2.0 device wants to talk to another USB 2.0 device over the cable, which would be the case for most mobile phones today. Something that needs to be tried out once I get my hands on one. If you already have experience with thin cables for charging, please leave a note below. Thanks!

So far I thought that Skype calls always had to go over a relay computer in the network when both ends of the connection are behind a NAT router. Turns out that this is not the case at all.

When monitoring the establishment of a Skype call it can be seen that during call establishment Skype tries quite hard to find out how the UDP port mapping is done by sending UDP packets over many ports simultaneously and if there is a way to get through the NAT directly (e.g. with UPnP and also with the NAT Port Mapping Protocol NAT PMP). At the same time the protocol also seems to try to find relay nodes over which the voice and video traffic could run in case the NAT scheme can't be figured out. In case a direct channel between the two end points can be established the other end is alerted of the incoming call and the direct link between the two parties is used.

I was successful to establish "direct" calls between two computers that were behind two NAT DSL routers and also with one computer behind a DSL router and the other one connected to a public hotspot of a nationwide hotspot provider. When using a VPN tunnel, however, Skype could not establish a direct link and had to fall back to channel the voice packets over one relay in the network. The same IP address was used as destination address on both ends, i.e. exactly one relay was necessary.

In that regard, the number of relays shown in the call technical info does not reflect that. The technical info often showed 4 relays when in fact the call was direct or only going over one relay. So perhaps this relay indication is something else entirely?

I've had quite a number of posts in the past couple of weeks on Android but today it's time for a quick Symbian post as well: One of the features I particularly like is the SMS remote lock feature built into the OS that lets you lock the phone by sending an SMS with a user defined content. This way the phone becomes useless to anyone not knowing the unlock code. But what about access to the files on the Flash memory via the USB port? Ideally, the USB port would be locked as well when the phone is locked. But is it really? Turns out that it is. As soon as the phone gets locked, USB connectivity is disabled until the general unlock code for the phone is entered. Very nicely implemented!

Yes, app stores for mobile platforms are a great thing, no doubt about it, and for most people that's how they discover and where they get all their apps and content from. An app store mono-culture, however, also has its dangers as the store owner can block apps he doesn't like. And some do… But I don't want to discuss policy but rather how alternatives work in practice.

On Symbian, apps can be installed from an sd-card or if received via Bluetooth or other means pretty much since its inception. An app store has only come recently as an addition and I have since used both methods to install applications. Android is also open and apps can also be installed from the SD card. Until now, I haven't tried this in practice so it was time to see for myself how that works.

For the purpose, I've used a self-written app (more about that in a future post) so I could experience first hand what a developer has to do to publish an application in an app store or otherwise. Android applications need to be signed by the developer with a private key that he generates himself, i.e. there is no certificate authority that authorizes a developer or the deployment of an application. The purpose of signing an app is to identify the author of an app but since there is no central certificate authority, that's a relative thing. Furthermore, the signature can be used to build a trust relationship between applications but I am not sure how and if that is used in practice. For details on the signing process see here.

The result of packaging and self-signing an application by the developer is a single ".apk" file that can then be put on an SD card by whatever means. The app is then installed with the help of a file explorer on the mobile device which comes pre-installed on Samsung based Android devices such as the Galaxy S for example. With a tap on the filename the app installer is launched which then requests the user to confirm the access rights requested by the app in the same way as if the app had been loaded from an app store.

Android enforces access rights for functionality that could incur cost such as making phone calls, sending messages, accessing the network, etc. and also for privacy related features such as accessing location information, accessing the phonebook, calendar, sd-card contents, etc. During the installation process the user is presented with the list of access rights the application requests so he gets an idea if the application requests more rights than it actually needs. If, for example, a calendar widget requests full location and network access that's more than a bit suspicious. If the user agrees to give the requested permissions the app is installed, otherwise the process is aborted.

If an application tries to use functions it doesn't have requested permission for during the installation process it dies a quick death once it tries to access those parts of the system. That means that the virtual machine terminates the execution of the app with an ugly error message as I experienced myself with the demo app I installed when I forgot to ask for permission to access location information.

For the user, all of this is transparent. All he needs to do to install the app is to put the ".apk" file on the sd card, use a file explorer to start the installation process and confirm the access right requests made by the app.

A quick note about the recent release of Firefox 4: While I am usually bit reluctant to immediately update to new software versions that are likely to break some add-ons until the authors have caught up with the version numbering I gave Firefox 4 a try as I could install it in a separate directory on my Ubuntu netbook and could thus go back to 3.6 if I didn't like what I saw. And indeed, some add-ons I occasionally use don't work with the new version for the moment. However, there are two major new features that more than make-up for it:

• Two more lines: On netbooks, vertical screen resolution is a premium. In version 4 the status bar has been removed once the page is fully loaded and the main menu has been put into a drop down menu. In other words, two more lines of screen space for web pages. Fantastic, that makes a big difference! I am not sure if the reason this was done was because of netbook screen size limitations but in any case it's very helpful!

• Java script speed-up: This has been promised a number of times before but I've never experienced a big difference where it hurt most, the Java Script based editor of Typepad that I use to write blog entries. But with this version it's different, the speedup of the editor is remarkable!

Apart from those two features I like the new "eye candy" of the clockwise and counter clockwise rotation of the activity indication in the tabs. When you click on a link the activity indicator starts rotating in one direction and once the connection to the server has been established it changes color and starts turning the other way around.

A very worthwhile update indeed, kudos to the guys over at Mozilla!

In my ongoing exploration of the Android OS I've arrived at Wi-Fi tethering. Quite simple to set-up on Android 2.2 and while I wished the settings would also allow WPA to be used as an encryption algorithm instead of WPA2, I don't think one can really ask for it. Too bad one of my notebooks will only do WPA and is thus not usable with it. But apart from that things work straight out of the box.

Performance is also great with the full speed of the HSPA chip forwarded to the Wi-Fi interface as proven by the 6 MBit/s throughput I got. Impressive! Also, the stability is impeccable. I tried the tethering over two days and the device didn't crash once. Also, on-board apps remain fully usable even while tethering is active and share the same network connection. There's not much more you can ask for.

Two little quirks though in addition to the missing WPA encryption:

• Power consumption: The battery of my Galaxy S lasts for about 3 hours when a notebook is connected over Wi-Fi and modest web surfing is done in addition to having a continuous ping running (see next bullet point for the reason). One can of course connect the mobile via USB to supply power.

• Fast dormancy (pre-Release 8) while tethering: The Galaxy S interrupts the RRC connection after 3 seconds of inactivity resulting in long waiting times especially during web browsing on the PC. While fast dormancy is great when only background applications are running on the device itself, it should really be switched off while tethering for performance sake. O.k. you can have a ping running on the tethered device to keep the mechanism from kicking in but that's a bit of a kludge…

Thanks Google, a very worthwhile functionality that will find it's way into my everyday use for special scenarios!

How many IP addresses does an IP packet have when it is sent between two devices? In a simple world only two, i.e. one for the destination and one of the source. The fun thing is how often that changes between source and destination due to all the tunneling and NATing applied. Let me give you an example of a typical setup of mine, a netbook connected via a Wifi / 3G bridge with a VPN tunnel established:

Leg 1: Netbook – WiFi / 3G bridge

As the VPN is established an IP packet is tunneled over IP. Thus there are 2 IP addresses to identify me as the source and two IP addresses for the destination:

• IP-1: IP address given by the Wifi bridge to the netbook
• IP-2: IP address of the VPN remote endpoint

    Inside the VPN tunnel:

• IP-3: IP address given by the VPN service to the tunnel end point (i.e. netbook)
• IP-4: IP address of the destination (e.g. the web server)

Leg 2: Wi-Fi / 3G bridge to Mobile Network Gateway (GGSN)

• IP-5: IP address given to the WiFi bridge from the GGSN (NAT)
• IP-2: -unchanged-

    Inside the VPN tunnel:

• IP-3: -unchanged-
• IP-4: -unchanged-

Leg 3: GGSN to VPN remote endpoint

• IP-6: IP address of the GGSN after NAT translation
• IP-2: -unchanged-

    Inside the VPN tunnel:

• IP-3: -unchanged-
• IP-4: -unchanged-

Leg 4: VPN remote end point to web server

• IP-7: IP address of the VPN remote endpoint after NAT translation
• IP-2: -unchanged-

    Inside the VPN tunnel:

• IP-3: -unchanged-
• IP-4: -unchanged-

Leg 1 to 4 are not the full story, there's also tunneling performed in the wireless network:

Tunneling between SGSN and GGSN

User data packets are tunneld over IP in the wireless core network. Here the packet looks like this:

• IP-7 SGSN network internal IP address
• IP-8 GGSN network internal IP address

    User data packet:

• IP-5: -unchanged-
• IP-2: -unchanged-

    Inside the VPN tunnel:

• IP-3: -unchanged-
• IP-4: -unchanged-

Base Station to RNC

While in the past the 3G radio access network was based on ATM, it is more and more replaced with Ethernet and IP for routing. This gives the packet another two IP addresses in this part of the network:

• IP-9 Base station network internal IP address
• IP-10 RNC network internal IP address

    User data packet:

• IP-5: -unchanged-
• IP-2: -unchanged-

    Inside the VPN tunnel:

• IP-3: -unchanged-
• IP-4: -unchanged-

RNC to core network IP address

No, we are not finished yet, the interface between RNC and SGSN is also based on IP these days and again tunneling is applied:

• IP-11 RNC network internal IP address on core network bound interface
• IP-12 SGSN network internal IP address on RAN bound interface

    User data packet:

• IP-5: -unchanged-
• IP-2: -unchanged-

    Inside the VPN tunnel:

• IP-3: -unchanged-
• IP-4: -unchanged-

12 different IP addresses are used in the course of transfering a packet between source and destination! WOW!

With the advent of Java on mobile phones many years ago, third party companies for the first time had the possibility to write software that runs on mobile phones. Many other programing environments have followed over the year and the most popular ones are currently the native programming environment for the iPhone, for Android and for Symbian. While it's incredible what can be done with them the quite deliberately set one limitation: All 3rd party programs are shielded from the operating systems. The can use the API offered to them but they are restricted from directly accessing any hardware or to interact directly with other parts of the operating system. With Android, things have become quite different though.

As Android does not only publish an API for programs running in the Dalvik virtual machine but the complete source code of the operating system, companies interested in offering functionality that requires interaction with the hardware or directly extend OS functionality can do so relatively easily. I have two interesting examples:

• GAN for Android: Orange UK and T-Mobile US are now shipping Android based phones with Kineto's GAN stack that tunnel GSM voice calls over Wi-Fi (see here and here). Developed many years ago, GAN depended on Nokia, Samsung and others to integrate the GAN stack into mobile phones as the programing environments of their phones did not allow 3rd parties to dwell deep enough in the OS. With Android however, external companies can do it themselves.

• NFC functionality: NXP and G&D have worked on integrating NFC and SIM Secure Element functionality into the Android OS (see here). Again, something that would have been only possible for device manufactures can now be done by 3rd parties to enable their services.

But there is one catch: Anything running outside Dalvik virtual machine can't be installed from the outside by a third party on non-rooted devices. In other words, such solutions have to be delivered as part of the firmware image. Which brings in Google and handset manufacturers again. 3rd parties can develop the code but it has to be integrated by the manufacturers. Still, a significant advantage over closed source operating systems, where such functionality can only be implemented by the OS owner.

Here's an interesting report from PC World about this years state of mobile networks in the US with a bunch of measurements and comparisons of previous years. By and large, improvements are impressive but there are a number of things I haven't quite figured out.

First, the round trip delay times they are quoting. In all networks, even including Verizon's new LTE network, latency values beyond 100 ms are given. When I compare that to HSPA+ networks here in Europe, same technology as that of AT&T and T-Mobile US and the typical latency values of 60 ms, I don't quite know where the extra delay comes from!?

And second, the data speeds. Good to see that all carriers have now left the sub-1 MBit/s average speed range and moved up significantly up the ladder. The 6+ MBit/s measured in downlink direction for Verizon's LTE network (in 10 MHz bandwidth) and around 3.5 MBit/s for T-Mobile US's network (in 5 MHz bandwidth) compare very well to the 4.5 MBit/s measured in German networks in comparable measurement campaigns. But what about maximum achievable speeds in the network?

And by that I don't mean theoretical peaks, those can be taken from the standards documents. What I mean is maximum speeds that can be reached in the live networks under very good signal conditions. In Germany, networks go as far as 12 MBit/s today on one carrier or 24 Mbit/s if you take the second 5 MHz carrier into account that is deployed in bigger cities for additional capacity (sorry, no reference here, as the values are from the print version of a magazine, my personal record is 11 MBit/s). The article seams to dance around those values but quite never mentioning them.

Agreed, average speeds also take overall load in the networks into account, but the article does not say at which times of the day (or night?) the measurements were taken. So one has to be a bit careful here but by and large it's a good indicator, especially for smartphone use. But maximum achievable speeds are just as important, as some people using the network for connecting their notebooks to the Internet benefit from maximum speeds if they are clever enough to look for a good place when using their device at home or in public, i.e. be close to a window, have a look at the number of signal bars, etc.

So again, a good article, but some interesting details are unfortunately missing.

 

One of the absolute must have's for me I use quite heavily on my Symbian phone today is profiles with which I can configure the phone's behavior with the touch of a button. Especially the functionality to silence the phone in general and only allow it to ring for a select few phone numbers is a real must for me. On Android there is no such functionality out of the box. Either the phone rings or it doesn't independently of the number of the caller. So I started to look for something in the Android market and found "Auto Ring" which fits my needs quite nicely. When Auto Ring is installed one can select the numbers out of the phone book which will make the phone ring when the phone is either in "silent" or "vibrate only" mode. Works great and another important piece of my Android puzzle gets solved this way!