The objective of this document is to provide technical recommendations for the protocol architecture in the Home Area Network (HAN) for Smart Objects such as sensors and actuators. In particular, these recommendation applies to the Home Energy Controller (HEC) and Multi-Utility Controller (MUC) developed in the context of the Smart Grid initiative for various applications such as metering, Demand Side management (DSM) and Demand-Response (DR).

1. Protocol Architecture in the HAN (Home Area
Network) for Sensor Networks
by JP Vasseur
Objective prietary stacks from physical connectivity
to applications (e.g., Z-Wave).
to-end view is simply lost, leading to
non-optimal routing and routing metrics
The objective of this document is to
translation (when possible), which im-
provide technical recommendations for The emergence of such a plethora of (semi)
plies extra configuration.
the protocol architecture in the Home Area proprietary protocols has led to a high
Network (HAN) for Smart Objects such as degree of fragmentation, very expensive • Quality of Service (QoS) mapping:
sensors and actuators. In particular, these solutions (due to the proprietary nature of requires to “translate” the QoS models.
recommendation applies to the Home
Energy Controller (HEC) and Multi-Utility
those systems), an absence of eco-sys-
tems, etc. Moreover, since most solutions • Security issues: the protocol transla-
tion gateway running a set of protocols
Controller (MUC) developed in the context were targeting specific applications (e.g.
becomes a weak security point in the
of the Smart Grid initiative for various home security, home safety, home control,
network and is subject to various at-
applications such as metering, Demand …), a fully automated home would have
tacks.
Side management (DSM) and Demand-Re- required the deployment of a number of
sponse (DR). closed systems, which are very complex to • Redundancy: since the gateway be-
manage and non scalable. comes a single point of failure, it is often
Introduction In the presence of a number of propri-
required to deploy two gateways for
Home automation has been extensively redundancy purposes thus increasing
etary solutions, the two main architectural
investigated during the past decade with the network design complexity.
options for a home (energy) controller are
no real success, mostly for two reasons:
either to (1) Design a multiprotocol gateway • Scalability: gateways are inherently not
• No break through applications: with or (2) to change the paradigm to promote scalable and become a bottleneck in
the exception of Home Safety and an end-to-end coherent IP architecture. the network.
Security, most of the other applications
have been considered as “potentially Why not a multi- • Flexibility: certainly one of the most
critical issues. Since the gateway
interesting” with a minor impact on
quality of life (e.g. appliance manage-
protocol gateway for “connects” two different worlds, it also
ment, remote monitoring). the HAN? becomes the least common denomina-
tor in terms of services. In other words,
• Lack of standardization: a plethora of
At first sight with no engineering analysis,
the multi-protocol gateway option looks
each time a feature enhancement is
protocols and architectures have been added on one “side” of the gateway, a
inevitable and an easy path to take. But a
developed leading to a high degree of similar operation must be performed
deeper investigation shows that such a
fragmentation, non-manageable home on the other “side”, which may or may
“solution” would be a “short-term” view with
networks and very costly systems. not be possible. This also implies soft-
many undesirable consequences.
Several protocols/architectures are ware upgrades each time one of the
discussed in this document. No, this is not a simple packet format protocols evolves.
The emergence of new key applications for
conversion operation: many people tend to
think that protocol conversion is a simple • Management: not the least issue espe-
the HAN such as energy management and cially when the end user is responsible
packet format conversion, which it is not.
remote healthcare has triggered the need for the gateway. Multi-protocol gate-
The role of a protocol conversion gateway
to design a scalable architecture for sensor ways usually require a wide set of tools
is to map two worlds using different proto-
networks in the HAN. for management purposes considering
cols and sometimes architectures. What
the number of protocols that they sup-
During the past few years the number of does that mean?
port.
proprietary protocols has dramatically
increased, from physical connectivity (pro- • First, a lack of routing consistencies:
• Troubleshooting: is clearly much
Since the protocols on both sides of
prietary low power radio) to semi-closed more challenging not only because
the gateway are different, the end-
stacks (e.g., ZigBee) or entirely closed/pro- the number of troubleshooting tools is
CISCO PUBLIC

2. increased but because the root cause
of the problem can be from any of the
supported protocols or at the protocol
translation level. Note that this is one
of the reasons why Service Provid-
ers have been so far reluctant to offer
home automation services: the training
cost and level of expertise required to
operate such gateways is most of the
time too high in light of the revenue
generated by the service.
Last but not least, designing a multi-proto-
col translation gateway also means slowing
down the adoption of a much superior
solution for the HAN: IP end-to-end.
Haven’t we successfully
developed and
deployed protocol power utilities in charge of managing the will require small incremental resources
translation gateways in HEC is an absolute MUST. in term of RAM and flash.
the past? So Why IP end-to-end? • Standardization: in addition to the
Yes, we did successfully build and design IETF 6lowpan Working Group in
The obvious alternative is IP end-to-end.
protocol gateways in the past but the con- charge of designing IPv6 solutions
Considerable effort has been made during
text was extremely different: over IEEE 802.15.4 (http://www.ietf.
the past three years to demonstrate that
• IP was not dominant and other legacy IP was the right choice for smart objects
org/html.charters/6lowpan-charter.
html), a new Working Group has been
protocols were used in the industry (such as sensors and actuators):
formed (ROLL: Routing Over Low power
such as SNA, IPX, DECnet Phase IV, etc.
For the sake of illustration, let’s consider • Architectures and protocol design: and Lossy networks - http://www.ietf.
a number of new protocols, protocol org/html.charters/roll-charter.html)
the case of SNA: most of the main-
extensions, new algorithms and archi- in 2008 that deals with the routing
frames were using SNA, thus replacing
tectures have been designed by Cisco aspects of such networks. The WG
SNA by IP was clearly not at first an
so as to cope with the peculiarities of has been progressing extremely fast
option. A multi-step approach was thus
Smart Object networks. A number of with a number of participants with
proposed consisting of first bridging
energy management techniques have various backgrounds (industry, chipset
SNA over IP to allow for network con-
also been developed to reduce energy manufacturers, computer scientist, and
vergence and then performing local
consumption for battery-operated researchers). The HAN is one of the 4
processing (termination of LLC2 ses-
devices. use cases the WG decided to focus on
sion, … using DLSw – RFC175/2166)
with IP in the core before a final migra- • The Sensor6 project: developed in
and a protocol specification should be
ready by February 2010.
tion to IP on end systems. collaboration with Atmel and SICS (now
• The gateways were managed by quali-
open source - http://newsroom.cisco. • Cisco is one of the funding compa-
com/dlls/2008/prod_101408e.html) nies of the IPSO Alliance (IP for Smart
fied engineers!
has shown that a very lightweight IPv6 Object alliance – www.ipso-alliance.
By contrast, most of the existing HAN stack could be developed only requir- org). IPSO was formed in September
protocols (e.g., ZigBee, Z-Wave) have not ing 2K of RAM and 11K of RAM. Ad- 2008 with an impressive start and has
been widely deployed and providing a ditional features are being considered already more than 60 members includ-
“plug-and-play” solution for the end user or (e.g., routing, security [IPSec, IKE]) that ing power utilities (Duke Energy, EDF),
IP NGN ARCHITECTURE THOUGHT LEADERSHIP JOURNAL - Q1 FY2010

3. chipset vendors (Atmel, Texas Instru- 802.15.4, LP 802.11, Wibree, WPC). By
ments, Intel), large companies (Ericsson, contrast with IP, most of the existing • High scalability.
Emerson, Sun Microsystems, Google), protocols/architectures do not allow for
Sensor vendors (Arch Rock, Dust, the addition of other PHY/MAC(s).
Technical recommen-
Zensys, Sensinode) and many more to
• No need for protocol translation gate-
dation and conclusion
come. The aim of IPSO is to promote The aim of this paper was to demonstrate
ways,
the use of IP in Smart Objects by pub- the number of issues and mid/long-term
lishing white papers, hosting webinars, • End to end routing and QoS consisten- shortcomings of a multi-protocol gateway
and organizing interoperability events. cies, both from a technical and cost perspective
The reasons for adopting an end-to-end IP • Ease of management and troubleshoot-
(in term of OPEX and CAPEX).
architecture are more than obvious: ing, With the increasing number of companies
• IP is agnostic to the PHY/MAC! Most • Adoption of a standardized protocol
adhering to IP, the growing number of na-
tive IP-based sensors/actuators and the
of the other HAN protocols are tied leading to large eco-system and lower
progress at the IETF, this architecture will
to a specific PHY/MAC (e.g. ZigBee cost for the end devices,
unavoidably be successful in a short term.
to 802.15.4, Z-Wave to their propri-
etary Radio/MAC, etc.). The past few • Reusability of existing well-proven Many Service Providers are now looking at
protocols used in the Internet, such architectures and solutions to provide
years have shown the emergence of a
number of low power PHY/MAC (e.g., • Enhanced security,
next generation services.
CISCO PUBLIC

4. Americas Headquarters Asia Pacific Headquarters Europe Headquarters
Cisco Systems, Inc. Cisco Systems (USA) Pte. Ltd. Cisco Systems International BV
San Jose, CA Singapore Amsterdam, The Netherlands
Cisco has more than 200 offices worldwide. Addresses, phone numbers, and fax numbers are listed on the Cisco Website at www.cisco.com/go/offices.
CCDE, CCENT, CCSI, Cisco Eos, Cisco HealthPresence, the Cisco logo, Cisco Lumin, Cisco Nexus, Cisco Nurse Connect, Cisco Stackpower, Cisco StadiumVision, Cisco TelePresence, Cisco WebEx, DCE, and
Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn and Cisco Store are service marks; and Access Registrar, Aironet, AsyncOS, Bringing the Meeting To You, Catalyst,
CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration
Without Limitation, EtherFast, EtherSwitch, Event Center, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iPhone, iQuick Study, IronPort, the IronPort logo, LightStream, Linksys,
MediaTone, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, Network Registrar, PCNow, PIX, PowerPanels, ProConnect, ScriptShare, SenderBase, SMARTnet, Spectrum Expert, StackWise,
The Fastest Way to Increase Your Internet Quotient, TransPath, WebEx, and the WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0903R)
Americas Headquarters Asia Pacific Headquarters Europe Headquarters
Cisco Systems, Inc. Cisco Systems (USA) Pte. Ltd. Cisco Systems International BV
San Jose, CA Singapore Amsterdam, The Netherlands
Cisco has more than 200 offices worldwide. Addresses, phone numbers, and fax numbers are listed on the Cisco Website at www.cisco.com/go/offices.
CCDE, CCENT, CCSI, Cisco Eos, Cisco HealthPresence, the Cisco logo, Cisco Lumin, Cisco Nexus, Cisco Nurse Connect, Cisco Stackpower, Cisco StadiumVision, Cisco TelePresence, Cisco WebEx, DCE, and Welcome to
the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn and Cisco Store are service marks; and Access Registrar, Aironet, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE,
CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation,
EtherFast, EtherSwitch, Event Center, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iPhone, iQuick Study, IronPort, the IronPort logo, LightStream, Linksys, MediaTone, MeetingPlace,
MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, Network Registrar, PCNow, PIX, PowerPanels, ProConnect, ScriptShare, SenderBase, SMARTnet, Spectrum Expert, StackWise, The Fastest Way to Increase
Your Internet Quotient, TransPath, WebEx, and the WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0903R)