After reading the recently uploaded IETF draft co-written by members of the Zigbee Alliance and IPSO, I thought it was a must-read for others interested in the Zigbee/IP effort, IPSO, or in the application of WSNs to smart energy. Since I know its a pain to read through IETF draft documents online, I thought I would post an outline summary of the document in bulleted form for easy scanning. That way, you can just look for the keywords that you're interested in. Just a note, I slightly reworded things or added comments (they're italicized) to put things in more laymens terms. Some of the jargon is meant for people that are well versed in wireless sensor networks, Zigbee, 6LoWPAN, and web protocols. If there are any questions, you should refer to the original document located here.
One good thing to note is that it looks like 6LoWPAN is locked in for Smart Energy and Zigbee will be integrated into 6LowAPP for the application level protocol and features. Anyways, here's the summary:
- Major deployment of 802.15.4 and 6LoWPAN is Smart Energy v2.0 (SE2)
- 6LoWAPP recognized as key to deployment
- Unlike previous Zigbee protocol stacks, SE2 built on IEEE, IETF, IEC, and W3C standards and will be IPv6 based
- Application payload formats specified by IEC using W3C standards
- Smart Energy networks may be self-contained or bridged at application level due to security concerns
- Smart Energy transactions focused on interation with energy consumers and equipment rather than grid automation and management
- Any solution must be inexpensive to implement, simple to deploy, and must not increase return rates or support costs
- 6LoWAPP must facilitate bullet proof application messaging while remaining simple to implement
- Smart Energy devices must have simple way to determine services on network (simplified service discovery)
- Service discovery must not require substantial fixed resources (RAM/flash/CPU), not require central directory (single point of failure), or time consuming node-by-node interrogation (current Zigbee service discovery method)
- Ideal solution allows new node to easily determine services offered on network and allow existing nodes to discover new services as they become available (like if a new device joins the network that can provide real-time energy stats)
- End-to-end IPv6 across back end and embedded networks
- Integration into Smart Grid Architecture
- Compatible with microcontrollers with small resources typically on order of 128k flash, 4k RAM (coincidentally, roughly size of Ember EM250…hee hee hee…never thought of 128k flash as resource constrained)
- Lightweight implementations of standard IETF security solutions desired due to large key lengths and multiple large packet exchanges in existing secure communications solutions
- Communication with non-utility devices that have no explicit authorization (public messaging…no more need to license Certicom SW if you just want to display energy usage…yay!)
- SE2 requires app protocol to carry messages between SE devices and servers
- More powerful devices can use XML/HTTP/TCP for messaging. For constrained devices, simplified application messaging protocol required
- Interoperability w/HTTP can be provided through proxy (constrained nodes prob won't run HTTP directly)
- Try to limit messaging to single packet exchange while remaining compatible with wider Internet (remove fragmentation if possible. Fragmentation = breaking up long messages into multiple short messages that fit into 802.15.4 payload)
- Standard application protocol response and error codes compatible with HTTP
- Reliable app layer messaging (similar to TCP)
- UDP support required with optional future use of TCP as reliable transport
- Publish/subscribe mechanism for delivery of smart energy events to client devices (like: "hey dryer, your ass is using too much juice")
- Push data mechanism to support data delivery to battery powered devices (like 802.15.4 indirect data transfer…node pings parent when it wakes up to check for pending messages)
- SE2 will exchange messages via XML so W3C EXI encoding is planned. Payload indication of content type (ie: application/xml, text/xml) and transfer encoding (x-exi) is required.
- Roaming support required since IPv6 addresses may change
- Minimal overhead for use over 6LoWPAN networks and other low bandwidth links with goal that majority of messages fit in single 802.15.4 payload
- Latency times should be limited and should consist of single request and response
- Must support get/set operations for application and device management but not expected that nodes support SNMP.
- Service discovery is process used for finding other SE services and registering offered services.
- Service discovery will be limited to smart energy services only, rather than generic devices and services like UPnP (oh...snap).
- Fully unattended devices (no user interaction) must be able to locate correct homeowner network, join it, and discover its services. Envisions using advertised XML message exchange.
- Large central directory not desirable (central repository that contains list of all registered services) but due to sleeping devices, some nodes can act as agent for service advertisement if a node is asleep (like parent of a node will hold service info about its sleepy child node in case a service discovery request arrives while its asleep)
- Multicast for discovery and advertisement must be supported
- Interchanging full XML strings and encoded/compressed XML in service discovery is desired.
- Smart Energy and Smart Grid is a long-term process with far-reaching goals (don't hold your breath for all this to happen soon)
- TCP struggles with lossy links (as opposed to lossless with wired networks like ethernet, ie: assumption is no packet loss). Many lossy link deployments used UDP with application level protocol for reliable delivery.
- Enhancements to TCP to enable deployment on lossy, mesh routed links would allow for seamless deployment of services on media that does not always behave like ethernet (like wireless, powerline)
- SE2 will be important smart grid application of IPv6 with resource constrained devices and limited wireless mesh networks.
- Requirements of SE2 should be taken into account for 6LoWAPP charter work
- Security can be implemented at Link layer (802.15.4 AES-128), IP layer (IPSEC), and application layer (TLS).
- Difficult to determine which service can be successfully applied to resource constrained devices and networks.
- May be difficult to apply lightweight IPSEC and TLS due to short-lived message sequences of SE2.
- Future may require development of more generic security mechanisms for this domain (specifically for resource constrained devices)