This post is a follow up to an article I wrote less than a month ago called The Future of Tech: Interoperability, and AllJoyn Doesn’t Realise Its Potential.
A brief summary of my previous article:
- Our ‘technology future’ has a current major hurdle hindering its growth. The scene at the moment is a collection of incompatible walled-gardens, isolated ‘cloud’ ecosystems preventing our many devices / applications interoperating with one another. (eg: Google, Facebook and Apple’s incompatible platforms, media systems like Sonos and Apple’s AirPlay etc…)
- ‘Hub’ companies like IFTTT and Revolv are a step in the right direction, but don’t fix the problem.
- To realise our visions of the future, we need a standard, open, peer-to-peer platform / protocol which allows our devices and software to control one another and share and manage our data, regardless of manufacturer.
- A platform like this would need to have security and privacy issues addressed front-and-centre.
- Qualcomm have already started something called AllJoyn, along with the AllSeen Alliance.
A couple of years ago, Qualcomm began to realise the problems that I pointed out in my previous article. They started a project called AllJoyn which aimed to solve these problems by implementing an open platform / protocol (like mentioned we need above).
Recently, Qualcomm have teamed up with the Linux Foundation to create a new consortium called the AllSeen Alliance. This alliance aims to bring lots of companies together to achieve the same goal that Qualcomm initially began doing by itself with AllJoyn. Qualcomm have donated AllJoyn (all it’s source code and documentation) to this new organisation.
The Alliance is already gaining quite a bit of traction, with notable companies already involved, including Haier, LG, Panasonic, Sharp and Cisco. (A full list of members can be found here).
- AllSeen Alliance is a consortium of companies with a common goal.
- AllJoyn is the main project of the AllSeen Alliance.
This article will be outlining the core design concepts behind AllJoyn. (Warning: it gets a little technical…)
Addressing my previous article:
I was wrong. Before going into the specifics of AllJoyn, I’d like to correct my comments regarding the Alliance, in my previous post I said “There are a few differences though between my ideas and the Alliance’s, and I feel as though they are missing a trick”, I have now discovered this is completely false! Since writing the article, myself and a fellow student at Oxford have had the pleasure of a conference call with Liat Ben-Zur (Chairwoman of the Alliance) and Greg Burns (Chief Software Architect of AllJoyn).
The conference call was a complete eye-opener; their articulation of the current problems we face and the potential of a platform like this, along with their ideas for tackling the problems I’ve talked about, were not only similar to mine, they were more or less identical. As my colleague (who independently manifested the same ideas as myself) said to Greg during the call: “It’s as if you’re taking the ideas directly from my head and handing them back to me on a silver platter”.
So with that cleared up, and any distinction between my own ideas and Qualcomm’s proved non-existent, lets begin talking about AllJoyn itself.
The Design of AllJoyn
An open protocol to solve the problems we have mentioned would need to have the following features:
- Work peer-to-peer.
- Work on numerous communication layers, including, for example: bluetooth, ethernet + Wi-Fi, Wi-Fi direct, NFC, etc…
- Include device identification and discovery.
- Include a security layer providing authenticity, confidentiality, and integrity (tied in with device identification).
- A control layer, with authorization. (We want to be able to control our washing machine from any of our devices, but wouldn’t want a visitor to be able to do the same with their phone.)
- A data layer, with peer-to-peer synchronization, and authorization.
- Provide suitable abstractions to be built upon, to allow for further features and services in the future.
Qualcomm have made the sensible decision to abstract these features into different modules, and the most high level view of AllJoyn looks a little like this:
They have divided the features we would need from an open protocol like this into to main categories, the AllJoyn Core, and Services.
The core part of the platform manages device identification, and discovery, transparently works across multiple communication platforms, and allows proximal peer-to-peer networks to be built up, so you can have topologies that look like this:
The core provides abstractions up to the next layer to allow services to run over the AllJoyn framework. There will be one instance of the core part of AllJoyn running on any device, managing communication to all other devices, discovering new devices, and managing traffic for all of the different services.
An application on a device will then be able to connect to AllJoin by either listening for connection requests of, or trying to connect to, specific services. This will allow it to communicate with any other application that can also speak the same service.
The core part of AllJoyn will automatically select the best methods to direct traffic to other devices, (which may, as the image above shows, be via other devices running AllJoyn).
The rest of the features I mentioned would be implemented by designing services on top of AllJoyn’s Core. So you would have a number of devices that are all AllJoyn compatible, each able to use a different selection of services.
You would have individual services for:
- Sending notifications from a device (for example, when your doorbell rings, or when your washing has finished, you could have a notification appear on each of the active screens around the house).
- Controlling devices (opening curtains, unlocking a door, starting your coffee machine, turning on and of lights, etc etc…).
- Synchronizing your data across all of your devices.
- Playing music at the same time throughout multiple speakers in your home.
- Sending files / sharing links from one device to another.
And developers could create their own services to perform a specific need, for example, if you created a multi-player game, you could make an AllJoyn Service which allowed you to very easily incorporate peer-to-peer multi-player functionality in your app, cross-vendor, over a mixture of communications mediums.
Here are a couple of main services that are being developed as part of the AllJoyn project.
Mentioned many times throughout this article already, this service allows devices to broadcast human-readable notifications to any device which may be interested in it. Like your TV, smartphone or tablet.
Here is an example of it in action:
An interesting service (not yet open sourced) that allows you to play music simultaneously out of numerous speakers, again, this will be completely dependent of device manufacturer, and there are no legal contracts involved either. Forget Sonos and AirPlay!
What’s Next for AllJoyn
AllJoyn is already a fantastic platform, and it is only going to improve and expand as interest increases and more companies get involved.
Not all the bases have yet been covered for us to really feel like we have freed ourselves completely from the many walled gardens tech offers us today. For example, that data component I mention so frequently has yet to be given a service on AllJoyn, whicch would allow us to completely decouple our data from the ‘cloud’ and manage it exactly as we would like.
In addition, AllJoyn’s core is currently focussed heavily on proximal networks, but of course as it evolves, we’ll be able to access, for example, devices in our own home from anywhere with an internet connection, safely and securely.
The future for AllJoyn is certainly bright, be sure to check out more videos on YouTube covering each of the existing services and the core in more detail. Also, if you’re a developer, do get involved! AllJoyn is an open source project and welcomes contributions from anyone.
I’m a Computer Scientist, currently studying at Oxford University in the UK, and am a past president of the Oxford University Computer Society. I have a passion for technology, in particular ubiquitous computing, communication and security.