Posts Tagged ‘AODV’

Where is Google going with the “Android@Home” initiative?

The recent announcement and demo of the “Android @ Home” initiative by Google is quite interesting in many aspects. In addition to the fact that Google is now officially jumping into the home automation market, what is also interesting to us is the news that Google is developing a “new wireless mesh network” technology (i.e. Wireless Sensor Network – WSN).

Google seems to be doing many things at the same time.  In addition to its core business of advertizing by search engine, Google is/has been working on social networks (Buzz, Google+), emails (Gmail), software-as-a-service (Google Doc), library (Google Books) and many others.  In addition to the more established services, Google also has (or had) many experimental projects – robotic cars, Google PowerMeter, etc.  Although it is generally understood that Google’s core business is search engine, one can see that they are trying many things beyond their traditional comfort zone.  I understand that this is what big companies tend to do – like GE’s diverse projects – but sometimes I cannot get away from the feeling that Google is trying too many things at the same time without fully understanding the nature of the projects it is jumping into.

Now, Google has added yet another project to their list: the Android@Home initiative.  As expressed in a previous post about where Google appears to be going with this initiative, I think it is a great idea and I believe this is kind of thing Google should be doing.  However, to make this initiative successful, Google should carefully review what happened with their previous successful projects (like Android for smart phone) and those that were not as successful (like Buzz or PowerMeter).

There are many reasons why Android has been a big success.  First, the technology worked. This is usually the very first and most important concern. Yes, there have been many complaints about the “immaturity” of initial versions of Android, but at the end of the day, Android was significantly faster and easier to use than other competing outdated smart phone OS.  Android is an open platform – open to the point that the source code is open which means it is free.  Smart phone developers do not need to pay for using Android other than perhaps technical support from Google.  Android also has easy-to-use application programming interfaces so that many developers can easily come up with numerous interesting applications.  The first wide-spread operating system for smart phone was not Android or Apple’s iOS.  They were Nokia’s Symbian and Microsoft Windows Mobile 5.0, which eventually disappeared from the market due to its heavy overhead, its closed platform and slow speed, and complicated programming environments.  In the home networking/automation market, there are already several existing wireless technologies that look much like Microsoft Windows Mobile or Symbian.

Let’s take Zigbee as an example. In addition to its technical limitations, although Zigbee claims it is an “open standard”, it is not difficult to see that it is actually very much like a closed system once you look into its architecture.  Zigbee defines everything from low layers (PHY, MAC, NET) up to top application layers (Profiles).  In other words, if someone comes up with a “crazy but innovative application”, it cannot be easily and widely adopted on top of Zigbee unless Zigbee Alliance endorses the application by authorizing a “profile” for the application.  Basically, Zigbee standard defines pretty much everything from top to bottom. Although this approach may help promote its claim of interoperability (which is not yet proven at the end-product level) it may actually hinder innovations.

So, what is the right approach for Google’s Android@Home?  It may be as simple as following or repeating what Google has done with Android smart phone.  The wireless sensor network (WSN) platform used by Android@Home should provide highly robust and reliable data link as well as rich and easy API (Application Programming Interface) to the application developers, and leave it at that.  Application developers should be given ultimate freedom to come up with as many crazy applications as they can without worrying about the robustness of the wireless network platform, and their imagination and innovation should not be limited by authorities of “profiles” defined by one company or organization. For example, MeshScape platform from Millennial Net provides such high performance and flexibility.

Why is this important?  Because of where WSN industry is at the moment.  In a  separate blog article, I explained the importance of “killer-apps” for WSN.  As mentioned in the article, the industry has not yet found a true “killer-app” for WSN, even if many experts have been looking for one for more than 10 years.  To find (or nurture) a true killer-app, we should be able to develop and test as many applications as possible in the market.  You cannot come up with a “profile” behind closed doors of an alliance and expect a killer-app to suddenly emerge out of nowhere.  The market needs to test as many WSN applications as possible and a true killer app will emerge.  For this, the WSN platform at the application level must be as easy and open as possible to application developers.

Another important factor is that Google should pay attention to the participation of as many hardware manufacturers as partners.  Actually, Google can learn from its own experience of less-than-expected performance of PowerMeter program due to the lack of participation from utilities.  On the other hand, I am sure Google has already gone through this process successfully while growing the Android handset market.  However, the issue in the home automation market may be somewhat different.  In the smart phone market, there exist relatively small number of major players such as Motorola, Samsung, HTC, and LG.  Google simply had to cut deals with a handful of mega-manufacturers and support them.  In home automation market, there are many more players than with the smart phone.  The home automation market is much more fragmented and the requirements are much more diverse.  Therefore, Google must be prepared to deal with a higher number of partners with more diverse requirements.  From a technical point of view, this means the Android@Home platform must be as agile and self-supporting as possible.  It also means that the platform must be very reliable and scalable from the beginning.  Unlike smart phone, WSN-enabled home automation devices will be relying on each other for continuous operation.  For example, when your smart phone stops working, it does not affect the operation of your friend’s smart phone.  In WSN-enabled networks one troubled device may affect the operation of other devices.  This is where reliable mesh network capability as well as other requirements are crucial for Android@Home platform.

Finally, Google must think about how it can expand Android@Home beyond a mere home network platform.  Building home networks should not be the ultimate goal.  The ultimate goal should be to connect all the devices in the world reliably and safely to benefit people as a whole.  I encourage Google to spend a serious amount of time thinking about how to create real value for people by connecting devices as well as spending time thinking about how to connect devices.

Eventually, devices will be networked and they will all talk to each other.  The devices will be “friends” to each other and will work together. The air conditioner in my family room will be sharing my temperature preference information with my car.  I am sure a smart phone will be at the center of the connected world.  Now, the important question is this : When everything is connected, what will it do for us?

Update : See my article “What will Happen when Devices are Connected?” for my answer to this important question.


Get every new post delivered to your Inbox.

%d bloggers like this: