Protocol Architecture in the HAN (Home Area Network) for Sensor Networks

3,025 views
2,887 views

Published on

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).

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,025
On SlideShare
0
From Embeds
0
Number of Embeds
11
Actions
Shares
0
Downloads
161
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Protocol Architecture in the HAN (Home Area Network) for Sensor Networks

  1. 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. 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. 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. 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)

×