Subject: [core] Simple Monitoring and Control Protocol

From: Robert Quattlebaum <[email-masked]>
Date: Fri, 16 Apr 2010 14:55:44 -0700

I recently bought a house, and this has spurred my interest in  
wireless sensor networks and home automation in general. After finding  
that there didn't seem to be a unified IP-based protocol for this sort  
of thing, I decided that I would go ahead and start to develop one.  
Today, I found CoRE, and I think that this may be a better forum for  
developing such a protocol than what I was previously envisioning.

I just wanted to describe some of the work that I have done so far, as  
I think it may be relevant. Originally I started developing the  
protocol without realizing the extreme packet size limitations, so my  
original version was a bit verbose. Packets were nominally 130 bytes.  
I'm working on a much smaller version with the same features that  
would be suitable for use over 6LoWPAN.

The protocol that I was working on I was informally calling the Simple  
Monitoring and Control Protocol. It had the following design goals:

1) Be largely layer 2 and layer 3 independent, even though I was  
targeting UDP over IPv6.
2) Be designed from the ground up with the security mechanisms to  
prevent unauthorized control of devices (including replay attacks)
3) Be designed to not require any centralized server. For example, the  
temperature sensor would be able to directly tell the heater to turn  
on or off.
4) Be event based.

Each physical device contains a hierarchy of nodes, which are either  
one of the following:

  * Device - An organizational unit, like a folder. A physical device  
can contain several sub-devices, such as multiple temperature sensors,  
etc.
  * Variable - A named value that can be polled. Polling the value of  
a variable is considered an administrative action, and isn't done  
between devices.
  * Action - Invoked by an event to change or record something
  * Event - Invokes actions when certain criteria are met

Devices/subdevices can contain variables, events, and actions.  
Variables can contain events and actions. Device names always end with  
a '/', Action names always begin with a '?', and event names always  
begin with a '!'. Variable names do not have any prefixes or suffixes.

Individual nodes can be referenced using a URL syntax:

* Subdevice: <scmp://[::1]/sensor01/>
* Variable: <scmp://[::1]/sensor01/temperature>
* Action: <scmp://[::1]/sensor01/alarm-max?set>
* Event: <scmp://[::1]/sensor01/temperature!changed>

The real workhorse of the system is the event/action relationship.  
Events are paired to actions using an administrative interface. Once  
an event is paired to an action, the two devices will communicate  
directly with each other. Pairings are created using a special request  
which is authenticated with the administrative credentials. Both the  
action and the event must be configured for the pairing. Each pairing  
contains it's own unique authentication credentials. If an attacker  
were to learn the credential of a pairing somehow, they would only be  
able to control the specific action the pairing was attached to.

Probably the best way to describe how this system would work is by  
example. Lets say you wanted to have a light that would be triggered  
by a motion sensor. The device hierarchy would look something like this:

MotionSensor/
!motion-detected
Timer/
period
remaining
enabled
?set
?set=1
?set=0
?reset
?stop
!fire
LampController/
state
?set
?set=0
?set=1

Keep in mind that just because I'm listing the timer separately  
doesn't mean that it is necessarily a separate physical device. It  
could easily be combined into same physical device as the motion  
sensor, or the lamp controller.

Then we would make the following connections: (events on the left,  
actions on the right)

MotionSensor/!motion-detected ........ Timer/?reset
MotionSensor/!motion-detected ........ LampController/state?set=1
Timer/!fire ........ LampController/state?set=0

When motion is detected, the timer is reset and the lamp state is set  
to ON. When the timer expires, it turns the lamp off. This is a fairly  
simplistic example. Lets try one that is more complicated: What if we  
want to be able to control the lamp with a switch as well?

Here, we add one more device:

Switch
state
!changed
!changed=0
!changed=1

Then we would make the following connections:

MotionSensor/!motion-detected ........ Timer/?reset
MotionSensor/!motion-detected ........ LampController/state?set=1
Timer/!fire ........ LampController/state?set=0
Switch/state!changed ........ LampController/state?set
Switch/state!changed=1 ........ Timer/enabled?set=0
Switch/state!changed=0 ........ Timer/enabled?set=1

Whenever the light switch is on, the light will always be on. If the  
light switch is off, then the light will turn on when motion is  
detected and turn off after the timeout. If the user wants to turn off  
the light before the timeout happens, they simply need to only flip  
the switch on and off.

A nice feature of this system is that it allows you to pair sensors  
and actuators across networks without any additional infrastructure  
other than what is needed for standard IP networking.

There are a lot more details (ie: mechanisms for preventing infinite  
loops of events, authenticating pairings, challenge/response stuff,  
etc), but I'll spare them for now.

Originally, the packet format was based on SIP and HTTP: very verbose,  
easy to read, easy to understand. Thinking that I had 1280 bytes to  
work with, I didn't think it would be a problem... But now that I'm  
aware of 6LoWPAN and its limitations, I'm considering re-working the  
packet format into something much more terse and compact.

Thoughts and comments would be appreciated.

__________________
Robert Quattlebaum
Jabber: [email-masked]
eMail:  [email-masked]
www:    http://www.deepdarc.com/