The Internet Of Things? Discoverability first!
One of the hot buzzwords (or buzz phrases, to be more precise) today is "The Internet of things"; the interconnection of all sorts of everyday objects. The idea is that, in the near future, one can envision that a proliferation of sensors and outputs will make even the most mundane object a useful node on the Internet.
For example, your fridge notifying you via your communications channel of choice that the amount of liquids stored in it has dropped below minimum levels (or, spoken more plainly: "you're running out of beer!"). Or being able to tell the temperature in a specific locality by visualizing a map of all the locally available networked temperature sensors: those in your neighbours' cars, by windows, and so on. Or, in the most recent case highlighted by Google's announcement of its self-driving cars, traffic flow and incident, moving objects (people, bicycles or parcels) tracked in real time.
The Location of Things
The technology to build the Internet of things is available today. Beyond the obvious cost overhead to build a network component to all those objects, the main issue is how to network them. In order to network them, you of course need to give them a location address.
Using good old IPv4 addresses is out of the question, as we've essentially all but run out of them. This isn't a problem for .tel domains as of course they're not needed to host websites, but it could well be a challenge for the rest of the domain industry in 2011 unless there's a wholesale migration to IPv6, which has been around for a long time.
Naming Requirements and Discoverability
However, regardless of IPv6 address adoption at present, we have plenty! Imagine every single device having an IP address, and from there, an actual name. Take for example thermometer.floor1.house.john.smith.com. That's a good start, but how will we know what that device can do? How will other devices be told how to communicate with it? What can thermometer.floor1 offer to the Internet at large? In more technical terms, the problem is that of discovering the device and its API (an application programming interface, which is an interface implemented by a software program to enable interaction with other software).
A Network of Hubs
Using IP addresses and the DNS can solve this problem very elegantly, using the techniques .tel has perfected; leveraging the DNS infrastructure to expose communication channels and entry points.
Here's a concrete example: Assume I own a Ford GT and a fridge. Both are fully networked and both are full of really neat sensors. I could set up my .tel domain to not only let someone (securely) discover the existence of these machines, but also what they can do. Here's how I'd set up my .tel domain:
fridge.devices.henri.tel would have records like:
x-temp:http+x-inside => http://fe80::222:41ff:fefa:e3ba/temp/
x-pwr:http => http://fe80::222:41ff:fefa:e3ba/power/
and fordgt.devices.henri.tel could have records similar to the below:
x-temp:http+x-outside => http://fe80::222:41ff:fefa:e3be/deg/
x-vol:http => http://fe80::222:41ff:fefa:e3be/gastank/
where both fridge and Ford GT would update their location (LOC) records in real time (obviously the fridge wouldn't move too much, but hopefully the Ford would).
Of course these are just hypothetical records, but anyone defining an x-temp service type could specify how that would work over http. For example, appending "get_temp" to the url could return the temperature of the sensor.
Some Examples
Imagine two scenarios. I have a service contract with the supplier of my fridge and I have given that service provider the rights to access fridge.devices.henri.tel and the information stored under it. Their servicing software can access the fridge on a regular basis to make sure that it is performing appropriately and, if a temperature fluctuation occurs, alert me to that (I may have left the fridge door open) so that I can take action or, if there's a prolonged issue, fix a service appointment to find out what the problem is and fix it, all automatically and proactively.
The second scenario is a public service one. The records in fordgt.devices.henri.tel I've set to public. As Google crawls my .tel domain, it finds these devices and takes the opportunity to read the temperature from these sensors, and inserts those data points in its map using their respective LOC records. Instant real-time, on-the-ground temperature monitoring, enabling open data to be accessed and manipulated to provide better information services to all.
Obviously, in these two cases, the access is set by the owner of both the fridge and the car. With .tel, the individual is in control of the information being shared and is able to set access levels dependent on their relationship with vendors or other service providers and revoke that access at any time. Thus, concerns regarding privacy and data protection can be managed at a personal level, rather than with systems thrust upon them.
What's likely?
Whilst sounding like science fiction, these scenarios are not far off. There are already developed initiatives for home systems management that are being rolled out today in order to better manage energy efficiency and automated home management. Devices are already becoming internet aware at an increasing rate. As any type of record can be stored in the DNS and it's of course possible to write to .tel domains via APIs today and monitor, if not manage, these devices. So a personal or home .tel domain can be the data store and interface between multiple devices and sensors in the future, enabling tight control of information being shared privately or publicly at the choice of the individual.
Interesting technology. Can you explain how the service "get_temp" would return the temperature of the sensor?
Mark, let's say I'm the sensor company and my product supports the hypothetical x-temp service type.
The hypothetical x-temp service type documentation would state that:
The x-temp service type functions only over http or https protocols. The x-temp service can expose the following methods:/get_temp : Gets the temperature of the sensor, timestamp of latest reading, and unit used (F, C or K).
/average_temp: Returns the average temperature of the sensor, start time, end time, and unit used. Default is the last hour. Pass in begin=[DATE] and end=[DATE] to specify the date range.
For both of the above services, pass in the parameter unit=(F|C|K) to specify the requested unit. All results are in JSON format.
Given the above, if you find a x-temp:http(s) in a .tel domain, you can then do a query such as:
http://x.x.x.x/get_temp?unit=F
which would return you something like this:
temp=72tstamp="2010.11.09 12:00:00 UTC"
unit="F"
What's important to note in this hypothetical example is that:
- An app can automatically discover the existence and capabilities of a "thing"
- An app developer can independently decide to support whatever service types she's interested in
- Everything is decentralized with completely open specs