Category: Uncategorized

Last year around this time an interesting Firefox plugin appeared on the scene called Firesheep, making it easy for just about everyone to track other people on unencrypted public Wi-Fi and to easily get to their Facebook, Twitter, etc. information. Most of those companies have reacted in the meantime and have introduced secure http (HTTPS) sessions for their services so all traffic would be encrypted. Facebook was among the first. However, even now, one year later, HTTPS are still not activated by default. Users have to go to their security settings and turn it on manually. I wonder how many people have done that in the meantime. Not many I suspect.

Over the past couple of days I've taken a closer look at some of the demos of the first Windows 8 developer releases aiming to set Microsoft's message into a larger context. There are two things that I find of particular interest: ARM support and a tile like interface as an alternative to the current Aero interface.

Perhaps these two things should be seen in reverse order: First, the new interface, which has many similarities with the current Windows Phone 7 user interface. The UI is tiles based, the layout is simple and everything can be moved and manipulated with fingers. In other words, this is a user interface for smaller devices such as mobile phones and pads. The direction is clear from the user interface and the demos shown, Microsoft seems to see Windows 8, the successor of Windows 7 and not of the current Windows Phone OS to be its next operating system for pads.

Microsoft therefore takes exactly the opposite steps compared to the rest of the industry. Apple and Google have initially scaled down a BSD or Linux based kernel to a bare minimum and then built an API and user interface around it and only then moved to larger screen devices with no legacy attached in terms of overhead. Microsoft on the other hand seems to take a different route: Take Windows 7, remove everything that's not necessary, try to make it as fast as possible, put a second user interface on it to be used on pads / tablets and other devices in the future. Given the current bulkiness of Windows 7 that's a huge challenge. I wonder how much RAM and solid state storage a Windows 8 based tablet will need in the future compared to Apple and Android, which, compared to Windows 7, are ultra "lean and mean".

This brings me to the second avenue Microsoft is pursuing, porting Windows to the ARM architecture. The idea is quite clear, Intel seems to continue to be struggling to produce anything based on the x86 architecture that is anywhere near as power efficient as ARM. And in small devices, power efficiency is the most important thing as this defines the amount of heat and size of the battery a device will feature. And quite frankly, a fan on a pad is something unlikely to acceptable to a mass audience.

But with power efficiency comes a performance limit. I think few doubt that even a dual core ARM processor running at 1.5 GHz today can't come anywhere close to even a two year old Intel Atom processor in terms of performance. But it doesn't have to, it's designed for a lean operating system and the graphics chip in the mobile device takes over when it comes to rendering web pages quickly and to stream HD videos. But I've seen a standard Linux running on an ARM chip with some applications like Firefox and OpenOffice and it was no joy at all. Things will get better over time but I have a hard time imagining Windows 8 running on a pad that is light enough that I don't need a stand for it like in the demos.

Perhaps Windows Phone 7 apps will be able to run on Windows 8 in the tiles interface? I think it's almost a must as otherwise the Apple and Google camps have a decisive advantage when it comes to apps. But if that is so and if Windows Phone 7 apps run on Windows 8 then why bother with the heavy Windows 8 on pads? Why not do it like the rest of the industry and evolve from the bottom? Perhaps the long term strategy of Microsoft is to sit this one out until ARM or Intel processor become powerful enough with acceptable energy consumption to drive a full Windows 8? And then, perhaps not only on pads but on even smaller devices. And what about Windows Phone then?

One way or another, Microsoft is running a tricky gamble here. On the one hand, they have to persuade their desktop users to migrate to Windows 8 and use the tile interface because otherwise what's the difference to Windows 7? At the same time Windows 8 needs to be lean enough to run on light weight pad devices. With or without an Aero UI mode, with ARM or with Intel, it doesn't matter it just has to run and do so as lightly as a feather. And I wonder what they are saying to their Windows Phone development team?

Exciting times it must be in Redmond!

Here's an anecdote of something that recently happened to me which has some interesting insights into what's currently happening in mobile: During the day I got a call from a friend calling me in my role as a tech- and mobile-savy person. He tells me that he is somewhere in a city because he has an appointment at a certain place with someone he communicated over Facebook. He thought he could remember the address from the top of his head, and, if not, just look it up in Facebook. Wrong on both accounts. Having arrived, the memory of the street number was gone and just in this very instant, Facebook was down as well. Is there anything I could do he asked me?

I quickly checked Facebook and saw that the message stream was also down for me. Nothing you can do I told him, the data you need is in the cloud and won't come out for now. Sorry. So I recommended to go to a street corner café and wait till either the memory or the cloud returns. Eventually, the memory returned. So much relying on online services. Agreed, the exchange of data had to go through the cloud in this case but leaving the critical pieces of information there and then relying on it is a dangerous thing. And that's one reason why I like to have my personal data with me.

Once you have more than just your notebook connected as part of your local wireless network at home to ultimately reach the Internet, there is of course the need and desire to exchange data between the devices. Sure, there are cloud services, but for those who like to keep their files and private data close to themselves there are other means.

One is a shared file system, residing on one of the computers, or, even better, on one of the better Wi-Fi access point / router models with USB connectivity in the back for USB sticks, printers, etc. The protocol of choice here understood by pretty much anything with Wi-Fi connectivity are "SMB" shares, a protocol designed by Microsoft. It's easy to set up and then reachable by all Windows and Linux computers in the network. I assume Mac's can reach them as well but I haven't tried personally.

That's for computers, though, but what about smartphones and tablets? As far as those devices with Android OS are concerned, it's actually quite straight forward. There are quite a number of apps and plugins to popular file managers available that add SMB network functionality. So while you are in your Wi-Fi cloud, it's easy to access those network shares as well. And, in turn, files can be exchanged easily as well. A PDF file can then be moved from a PC to the network share and from there to the smartphone or tablet.

Wonderful!

It's a joy to see that due to the flexibility and openness of Android, pretty much all major Android based smartphones sold by Orange UK now come with UMA Wi-Fi installed. A recent post on Recombu says, Orange is shipping the Samsung Galaxy S II, LG phones, Huawei phones, HTC phones, etc. etc with UMA. Not only does UMA extend in-house coverage of voice and SMS services in places where neither GSM nor UMTS is available by tunneling the connection of the smartphone and the Mobile Switching Center over Wi-fi, but it also shows how easy voice over LTE could be achieved in the future. After all, like Wi-Fi, LTE is an end-to-end IP based technology. Perhaps I'm repeating myself, but the thought just keeps coming back. For the details see here.

Here's an interesting piece of information for those with a history streak: 1991 was a tumultuous year. The coup in Moscow, tanks driving around in the city and Jelzin becoming the first president of Russia is surely remembered by those who's memory dates back to then. But there were three other things, small at the time but with a massive impact 20 years later:

Within 6 weeks, the first GSM networks were launched, Linux saw the day of light and the World Wide Web was started. All three things probably went unnoticed by most people then but have evolved quite a bit since then. Imagine how the world would look like today without these technologies.

I find it also quite interesting to tie these technology launches to a (totally unrelated) political event you can still remember and to set things into perspecive of how long some things have already been there, when you first heard about them (probably only many years after they went public) and how long it took them to mature and reach a wider audience.

Via: The Ericsson History pages

Back in 1991 when first GSM networks were launched and still today in many networks, the GSM world is simple when it comes to voice: 1 timeslot = 1 user. Some networks use half rate codecs in some situations, basically splitting a timeslot and use every alternate timeslot occasion for two users. This in effect doubles voice capacity in networks at somewhat the expense of voice quality. Back in 2008 I reported  about a new scheme coming up called MUROS (Multiple Users Reusing One Slot) which can cram up to 4 users in one timeslot.

At the time I perceived it as an interesting idea but thought it wouldn’t probably go very far as, and that was my assumption, MUROS would only work with new mobiles with special transceivers. Well, it turns out that is not the case as MUROS, now standardized in 3GPP and referred to as VAMOS (Voice services over Adaptive Multi-user channels on One Slot) also works with a significant number of mobiles already in the field.

In essence VAMOS works as follows: In a first instance, VAMOS can be combined with half rate channels, i.e. the starting point is using the AMR half-rate or AMR-Wideband half rate speech codecs which already results in two users sharing one timeslot. Nothing new here. VAMOS then extends this scheme by transmitting the combination of two signals at the same time over the same channel, each with a different sequence of training bits in the middle of the timeslot which is used by the receiver for channel estimation. Each of the two mobiles that receive the data stream at the same time use their knowledge of their individual training sequence to reconstruct their own part of the signal, effectively filtering away the second data stream as noise. Instead of today’s GMSK (Gaussian Minimum Shift Keying) modulation, VAMOS uses QPSK modulation in the downlink direction that approximates a GMSK signal when the “noise” (i.e. the second signal) is filtered away.

The scheme works best if the mobile has a Single Antenna Interference Cancellation (SAIC) receiver. I have found two papers on the Internet that describe this in more detail, one from NSN here and one from Ericsson here. From an implementation point of view the important thing is that for several years now, many mobiles have been equipped with SAIC receivers to improve their resistance against inter-cell interference, i.e. not even with VAMOS in mind. These receivers are also able to filter out local interference, a nice side benefit. The NSN paper, which must date back from 2009 mentions that there are already over 1 billion devices shipped with SAIC receivers. In other words, when VAMOS gets deployed one does not have to wait for special VAMOS capable devices to reach a critical mass before the benefits can be seen.

VAMOS in 3GPP has also specified extensions to mobile chipsets so they can be informed of the training sequence of the other signal not intended for them which further improves their ability to filter out the second signal. Also, one paper mentions that it is even possible to pair non-SAIC and SAIC/VAMOS mobiles on the same timeslot if the non-SAIC mobile gets more of the signal energy than the SAIC mobile, i.e. there is less noise from its point of view. And finally, there could be two users sharing a timeslot of legacy half rate operation and one using a full rate VAMOS channel which in effect allows three users sharing the timeslot or two half rate VAMOS channels and one full rate VAMOS channel.

Another way to look at this is that VAMOS exploits the fact that no matter how good or bad signal conditions are for a mobile device at any particular time, the voice channel always uses the same power and same modulation, thus in effect wasting spectrum. VAMOS doubles the number of bits sent per time and thus doubles the efficiency of spectrum usage. That means that VAMOS does not work everywhere in the cell. Especially in cell border areas where the signal strength is weaker and interference from neighboring cells is higher compared to the center of the cell the connection might have to fall back to normal GMSK modulation. In effect, VAMOS adds the channel adaptivity that was introduced many years ago with GPRS and then EDGE for packet switched data.

In the uplink direction, and that’s again an interesting twist, VAMOS uses the existing GMSK modulation scheme. In other words, no new transmitter elements are required in mobile devices. On the base station side, two antennas are required to tell the two GMSK transmissions from two devices apart, using Multi User MIMO (Multiple Input Multiple Output) algorithms.

In addition, the radio network has to monitor the signal quality in the uplink and in the downlink direction very carefully and change the timeslot configuration to single use in case the bit error rate becomes too high on a VAMOS channel for one of the users.

Altogether, a very interesting scheme. I can very well imagine that VAMOS is going to be used in emerging markets to expand capacity without additional hardware in the base stations. It should be noted, however, that additional calls on the air interface requires additional backhaul capacity, so activating VAMOS requires an upgrade of backhaul links. The papers also note that another benefit of using a timeslot for more than one or two users is the overall power reduction of the base stations per call. That is perhaps a good reason for countries in which diesel generators, solar panels and wind mills supply the electric power for base stations and every watt counts. In countries where network operators are measured in terms of voice quality, VAMOS might have a more difficult stance. This probably depends how much speech quality is impacted.

In a somewhat more distant future when GSM service could be much reduced in countries having deployed later generation systems and only serves M2M traffic (data), roamers and other devices not being 3G and perhaps LTE voice capable, one might perhaps even live with a somewhat degraded speech quality in return for freed-up bandwidth that can then be put to good use for UTMS and LTE.

So I think it’s quite likely that in both emerging and developed markets, this is not the last we have heard of VAMOS.

Like last year, October is going to be an exciting month for me as I'll be in Oxford for a couple of days for two events:

The first is my two day 'Beyond 3G – Bringing Networks, Terminals and the Web Together' course, which follows the lines of one of my books. I am very happy to co-present with Ajit Jaokar of Open Gardens and John Edwards of PicoChip who will bring in their great expertise from their angle of the industry. It's scheduled on October 26th/27th and you can find out more about the course via the link above. It would be great to see you there!

The second event which follows on October 28th is the Forum Oxford Mobile Apps and Technologies Conference, an event definitely not to be missed! I've attended and presented at the previous three conferences and I think it's THE mobile event of the year to visit!

In addition, there are two more courses that will run in the two days before the conference that might also be of interest to you: Tomi Ahonen will present his 'Mobile as 7th of the Mass Media' course on October 26 and 27th and Ajit Jaokar has a one day course on 'Designing Multiplatform Apps: TV, Web, Mobile and Automotive Platforms' on October 27th.

It's going to be a packed week and I am very much looking forward to it!

Dear Adobe,

So far I was only mildly annoyed by having to click on a check box to confirm the T&Cs during Adobe Flash player security updates that seem to happen now on a more or less bi-weekly basis. Why is that necessary, everyone else seems to be able to do security updates quite nicely in the background? Anyway, it has just become a lot worse:

This morning while rushing through the latest Adobe Flash fix the installer suddenly proclaimed that Google's Chrome browser is being installed. WHAT!!!!!????? Why, where, when!? Running the same security update on another computer in the same manual way (after a Firefox security update) I noticed that the Adobe security fix web page contains a check box already checked by default which says that Google Chrome is going to be installed unless the box is un-ticked.

Adobe, why do you have to resort to these kind of things for the extra buck? Most companies are humble about their security issues and install updates in the background without fuss. You on the other hand make it a cumbersome, and now, even a worrisome event. I understand you need to make money. However, is it ethical to install 3rd party software by default during a security fix installation? Please think this through and also talk to your friends at Oracle that keep trying to install some sort of toolbar in my browsers during Java security updates unless you catch it before it starts. Reminds me of a post of Andrew Grill who's also fed up of such practices.

It a normal thing in an evolving world: Some things are invented, documented and even standardized but because of one reason or the other they never see the light of day. GSM, UMTS and LTE, all of them part of the 3GPP standardization process, are no different. Today, there are many many features and options described in the specification documents that have never made it into real networks. Documents are bloated and when you are looking for something specific they are in the way of finding what you want. So how about having one 3GPP release dedicated to just one purpose: Clean up the specs and remove stuff that is irrelevant today!?

It's not that this never happens, take for example this GERAN report from 2009 in which it is noted that T-GSM 900 and PBCCH stuff was removed. Nevertheless I think the specifications would benefit from a somewhat larger effort. I guess it is unlikely to happen, though, because where's the immediate financial gain of cleaning up…