Found this interesting for couple of reasons – it proposes open protocols via IETF in contrast to the state of much of the existing HA industry and it proposes SIP (!) as an application protocol over 6lowpan.
The latter is curious as SIP is more commonly known from VoIP applications. SIP of course is another open protocol which is a big benefit. The other advantage is that there's a lot of OSS SIP code to reuse, one of which are SIP servlets on Tomcat (see for example http://en.wikipedia.org/wiki/Mobicents).
Abstract.
The Smart Grid initiative is an effort in modernization of the
electricity grid using communication technology with the primary
goals of reducing energy consumption, reducing cost (utilities and
consumers), increasing reliability and the creation of new services
for all participants in the value chain. The core focus of this
initiative is the specification of a 'Communications Overlay' network
which can help facilitate intelligent communication (discovery,
session establishment, routing, addressing to name a few) between
various nodes of the heterogeneous Smart Grid network.
One of the 'network segments' of the Smart Grid network is the Home
Area Network (HAN) and how residential and/or commercial devices
(such as TV, washing machine, surveillance camera, etc.) interact
with the smart meter/energy management system and vice-versa.
This draft is an initial input for consideration of SIP as an
appropriate application protocol for use inside devices that operate
over low powered IP networks.
The authors do NOT propose the use of SIP for all HAN devices.
Rather, the authors believe that SIP is an appropriate protocol for
certain categories of devices and therefore, the 6lowapp group should
consider SIP as an appropriate protocol for the same. The final
protocol that is ideal for a particular device communication will
always be determined by the use-case(s) that are envisioned for the
same.
This draft does NOT discuss the use of SIP inside the smart meter
(while the authors believe that the smart meter would also benefit
from SIP, that is the scope of another draft and does not apply to
the 6lowapp work). Therefore, in all diagrams and references, the
authors have used the term 'Energy Management System (EMS)' to refer
to the customer premise EMS that may or may not be the smart meter
itself.
...
1. Introduction
A 'smart home' is a modern day home in which a significant portion of
physical objects have built-in intelligence and communications
capability. Naturally, different devices in the home will require
different levels of intelligence. Furthermore as devices get more
intelligent, the mechanisms used to interact with them will also get
more complex.
Furthermore, home area network applications will not be about
limiting and relating objects to specific homes, but rather need to
be capable and open to much more complex relationships. For example,
if a guest is charging their electric car at a friends house, we
should consider applications that will understand that the charge
should appear on the guests electric bill and not that of the the
friend.
As another example, it is entirely possible that your home IPTV
interacts with the EMS and monitors the current price of electricity
and when it reaches a particular threshold, automatically negotiates
a lower bit rate codec as well as steps down brightness a few
notches.
Continuing this line of thought, your thermostat could be more than
just a programmable 'time-of-day' device. Consider for example, your
cell phone being the 'location updater' for your thermostat and when
the owner is a few miles away from home, the heating automatically
starts. Much better than you arriving early one evening and freezing
for 15 minutes before your thermostat warms up, isn't it?
The examples above all show why the authors feel that the future home
services will not just be limited to traditional home appliances but
which will also involve other communication devices such as your
3G/GSM/CDMA phone, your electric car and others.
SIP is an excellent choice for middleware in building out these sort
of applications as this I-D will describe.
...
2.1 Advantages of SIP
SIP brings in a lot of advantages for HAN devices, only some of which
are described below:
o Addressing: SIP devices are addressed by a URI scheme (example
sip:mycar@myhome.net) and are independent of their current IP
address. This means that the device can be reached anywhere as
long as it is connected and the IP address will be resolved as
part of routing at that instance of communication
o Groups and Forking: The architecture of SIP allows for multiple
devices to be addressable (grouped) using a single id (example:
clocks@myhome.net). This makes it simple to issue one command that
gets "forked" (i.e. sent in parallel) to multiple devices (example
an IM "set dst on" to clocks@myhome.net, or, say "set max heating
72F" to thermostats@myhome.net)
o Events - Subscriptions and Notifications: SIP allows for any
device to subscribe and be notified of any event that is triggered
on that device. For example, your thermostat could subscribe to
the "EnergyRate" event of the smart meter and if the rate/kwh were
to increase beyond a point, the thermostat would be notified and
may choose to adjust its setting of heating automatically.
o Mobility: SIP supports mobility at the application layer,
primarily due to its use of URIs for addressing. A device can 're-
register' its current location dynamically with its home proxy and
can be reached even if its real address is different from the
known address.
o Security: SIP integrates well with security. It supports a variety
of security mechanisms such as TLS, MD5-Auth, AKA, PKI etc.
Furthermore, different devices can use different security
protocols (or none) depending on their need with SIP which serves
very well for limited capability devices/networks
o Offer-Answer: SIP is modeled around an offer-answer model which
ensures that a session is established using capabilities that both
endpoints support. For example, if a homeowner were to monitor his
home nanny cam using his desk phone, it would automatically detect
the phone does not support video and would only provide an audio
stream
o Discovery: SIP natively supports both device and capability
discovery. For example, clocks@myhome.net may result in the
initial communication reaching all the clocks of the house (alarm
clock, radio clock, oven clock). Similarly, the SIP OPTIONS method
can be used to discover the capabilities of multiple devices
before initiating a communication with a selected device. As
another specific example, even though UPnP is the consumer
electronics industries' de-facto standard for discovery and
control, the architecture does not meet the requirements for use
on a pervasive network or lend to mobility. In addition, there is
general consensus that its SOA architecture is unnecessarily
complex. For this reason, the industry is in the process of
standardizing the concept of a UPnP to SIP interface[11] as the
preferred mechanism for pervasive device control and discovery.
o Presence: SIP, specifically the work done in SIMPLE [10] brings in
a strong concept of presence to SIP. A SIP device can advertise
its current presence state (busy, online, offline, DND, lowpower-
sleep etc.) which can both help communicating entities know the
current state of the device before reaching out to it, as well as
open up a lot of innovative service creation possibilities
(example: if my house TV is in 'transmitting' state for 3 hours,
and I am on travel, I may decide to switch it off, not just to
save power, but to ensure my kids are not taking advantage of
their parent-free-time)
o Converged communication: SIP has the ability to interwork multiple
devices to execute a single service. Consider for example, a
situation where your EMS has detected a sudden rise in power usage
that is not the norm based on your past trends. It may choose to
alert you of this situation both by email, as well as a digital
signage overlay on your TV that gives you more information and
then allow you to rectify the situation appropriately.
o Extensible: The architecture of SIP easily enables new methods and
extensions as applicable. This means that if SIP needs to be
modified to fit into a particular network/device characteristic it
can easily be done.
...
3.1 SIP has VoIP baggage and is therefore complicated
SIP can be used completely independent of VoIP. For example, one can
just use SIP IM messages to communicate between devices which does
not need a session to be established
Comments (7)
Oct 21
david menga says:
Hello Juha, Have a look at http://www.enseirb.fr/cosynux/HomeSIP/ but you also...Hello Juha,
Have a look at http://www.enseirb.fr/cosynux/HomeSIP/
but you also have to consider xmpp as an alternative way to talk to smart objects.
Look at http://portal.etsi.org/docbox/Workshop/2008/2008_06_M2MWORKSHOP/ISMB_FORNO_M2MWORKSHOP.pdf
Best regards
David Menga
Oct 21
Juha Lindfors says:
XMPP would be a good choice too. I think anything that gets us out of the curren...XMPP would be a good choice too. I think anything that gets us out of the current proprietary sillyness will do. Good thing about protocols is there are so many to choose from.
I haven't looked at IPv6 over 802.15.4 long enough to say if one protocol has benefits over the other. Akiba was making a point in his earlier IETF draft summary on 6LoWAPP about avoiding message fragmentation but I don't know what is the technical reasoning driving this consideration.
Oct 22
Akiba says:
If you're interested in XMPP, might want to check this out. Someone wrote an XMP...If you're interested in XMPP, might want to check this out. Someone wrote an XMPP implementation for Contiki so they could control devices via IM and Pidgin
Link
Oct 22
Shidan Gouran says:
Hi. I'm one of the authors of this ID and have a few comments. First, just to le...Hi. I'm one of the authors of this ID and have a few comments. First, just to let everyone know, the idea for this grew out of work we are doing which involves SIP in smart meters and neighborhood area networks. For obvious reasons, many carriers and their partner utilities have become interested in our work and so a number of members of the SIP industries main association have decided to explore this space through a special interest group http://www.sipforum.org/content/view/351/266/.
Now, for the most part, our partner companies are not particularly interested in what happens behind the meter, but as individuals, myself (I recently started a venture in the A/V & media management space), Arjun Roychowdhury (who actually implemented a SIP home control system when he worked at Telcordia), Henning Schulzrinne (who did research in domotics using SIP) and Jeff Dionne (who originally wrote uCLinux for building control applications) are people in this group who are very excited about the possibilities for home control.
If the owners of the SIP stack allow us, we will distribute it under LGPL. The thing is, it will take years for even ZigBee SE, which has clear industry and device manufacturer backing, to actually move towards 6LoWPAN/IP, let alone a concept as new as ours. That's why I'm not sure if any of this will be relevant to your project in the near term. One thing which is clear, the whole HAN area will remain a mess for a long time to come so a middleware layer like OpenRemote will be the winning solution.
Having said that, I think the concept of a very light and cheap XMPP or SIP gateway to for example all HANs you guys support and a new 'Boss' component called the "cloud controller" is a great idea and I've been thinking about this idea for a few months now.
The very high level concept is a $40 gateway that abstracts everything to XMPP and a controller on the cloud that only speaks to the gateway using XMPP/SIP. This would allow anyone to create a home control app using an application container similar in idea to OpenSocial without interfacing with the home directly. With the concept of federation this can grow to be pretty impressive and internetworked system. I would prefer to use XMPP for the gateway to controller communications in this project and I plan on throwing up a description of the system architecture and device ontologies, not just for OpenRemote in mind, but any group interested in exploring this idea, on a I site I'm putting up, http://socialhardware.org, in the coming weeks. I haven't played with your system but I imagine your REST and view's models can be a base for the application container concept.
Oct 22
Juha Lindfors says:
Hey Shidan, Thanks for dropping by. Completely agree on the need of the middlew...Hey Shidan,
Thanks for dropping by. Completely agree on the need of the middleware here, and while the road ahead points towards better things with open standards on 6LoWPan, 802.15.4, et al. the industry is moving slowly. So we will do our best to integrate the legacy while working on something better.
If we can do anything to help to convince on the benefits of open sourcing stack implementation, let us know.
Both XMPP and SIP are popping up as almost interchangeable protocols, any insight on the trade-offs between the two?
– Juha
Oct 23
Shidan Gouran says:
They're somewhat intercheangable. Both bring routability to the application laye...They're somewhat intercheangable. Both bring routability to the application layer and can carry a lot of arbitrary information. SIP really outshines anything, I think, for discovery of capabilities between devices & services and negotiating session parameters, XMPP on the other hand, lends itself to much simpler presence/IM application development and, because of this, where you are limited to only a few class of devices, it would be easier for M2M applications. There is nothing 'simple' about SIMPLE.
A few other points to consider is that SIP is already designed for unreliable networks and has a better security model.
So I think for a true pervasive 'Web of Things' or a global network with many devices and, more importantly, class of devices, or even systems on a path towards that, like the Grid and mobile networks, SIP is a better choice.
Truthfully though, for higher level protocols anything will be better as a general middleware layer than the very limited and awkward UPnP &WS-D standards. Specially for breaking down the walls of what we define the home as with respect to these technologies.
I think for the purposes of OpenRemote , and thinking practically for today and not tomorrow, if you want to build something thats much better than what the CEDIA marketplace has to offer, ease of development and larger developer participation becomes a bigger factor. Having said that, let me go back to my idea because no one commented on it, I just want to gauge if you guys think its a bad idea or maybe its something you have already considered.
Together with someone else, I've been discussing for some time, that it would be interesting if we implement an idea I had by putting out an opensource spec for a device similar in concept to your 'ORB' except that we want it to be really cheap, in quantity a BOM of $40. This is entirely possible. Looking at your project, I think having a simple device like this in the home which is part of an XMPP/SIP network on the Internet side and speaks all these different control standards in the home and where applications for controlling the box become just web apps in the cloud would be really interesting.
You can think of the possibility of many small security VARs, ISPs, consumer and small business VoIP providers adopting this as a managed home control service, and who knows, maybe even community driven, federated networks could pop up. So if we designed a box for this and defined the interface to the box and for federation as a part of our project, would you guys be interested in developing the application server side of it as an addition to your project?
Probably this partially entails a multi-tenanted system for panel software and user interface composer? Maybe its too early even for an idea like this. I don't know, but maybe this can grow into something a lot more innovative than what the CEDIA industry currently offers. your opinions are appreciated.
One more point, if OpenRemote plans on supporting any of DLNA, ONVIF or PSIA as part of a whole CEDIA solution, even today, SIP would make more sense as the gateways interface.
Oct 24
Juha Lindfors says:
Together with someone else, I've been discussing for some time, that it would b...Definitely interested in discussing a $40 BOM.
Our current dependency on a full (standard) Java runtime is keeping the BOM price higher. On retail level, the Plug computer (discussed in another forum thread) comes down to $100 and which may be able to run Java runtime sufficiently (remains to be seen) on ARM architecture.
At $40 level today (assuming low or pay-as-you-go manufacturing volumes) I could foresee something that acts purely as a protocol translator (which is what our first iteration of OR Boss software stack is doing as well) but longer term a more accessible software platform for developers to create higher level apps, including temporal rules and software that interacts within the scenarios you've described in the IETF motivational draft, I believe benefits from fully featured Java SE. I think by the time we get to wide-spread adoption of open protocols and specs the current $100 retail price level have gone down quite a bit too.
Please share what details you can about the BOM you were thinking of.