[要約] RFC 5867は、低消費電力で信頼性の低いネットワークにおける建物自動化のルーティング要件についてのガイドラインです。このRFCの目的は、建物自動化システムの効率的な通信とネットワークの信頼性を向上させるための要件を定義することです。
Internet Engineering Task Force (IETF) J. Martocci, Ed.
Request for Comments: 5867 Johnson Controls Inc.
Category: Informational P. De Mil
ISSN: 2070-1721 Ghent University - IBCN
N. Riou
Schneider Electric
W. Vermeylen
Arts Centre Vooruit
June 2010
Building Automation Routing Requirements in Low-Power and Lossy Networks
低電力および損失のあるネットワークでの自動化ルーティング要件を構築します
Abstract
概要
The Routing Over Low-Power and Lossy (ROLL) networks Working Group has been chartered to work on routing solutions for Low-Power and Lossy Networks (LLNs) in various markets: industrial, commercial (building), home, and urban networks. Pursuant to this effort, this document defines the IPv6 routing requirements for building automation.
低電力と損失のある（ロール）ネットワークのワーキンググループを介したルーティングは、さまざまな市場で低電力および損失のあるネットワーク（LLN）のルーティングソリューションに取り組むようにチャーターされています。この取り組みに従って、このドキュメントは、自動化の構築のためのIPv6ルーティング要件を定義しています。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5867.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5867で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................4
2. Terminology .....................................................6
2.1. Requirements Language ......................................6
3. Overview of Building Automation Networks ........................6
3.1. Introduction ...............................................6
3.2. Building Systems Equipment .................................7
3.2.1. Sensors/Actuators ...................................7
3.2.2. Area Controllers ....................................7
3.2.3. Zone Controllers ....................................8
3.3. Equipment Installation Methods .............................8
3.4. Device Density .............................................9
3.4.1. HVAC Device Density .................................9
3.4.2. Fire Device Density .................................9
3.4.3. Lighting Device Density ............................10
3.4.4. Physical Security Device Density ...................10
4. Traffic Pattern ................................................10
5. Building Automation Routing Requirements .......................12
5.1. Device and Network Commissioning ..........................12
5.1.1. Zero-Configuration Installation ....................12
5.1.2. Local Testing ......................................12
5.1.3. Device Replacement .................................13
5.2. Scalability ...............................................13
5.2.1. Network Domain .....................................13
5.2.2. Peer-to-Peer Communication .........................13
5.3. Mobility ..................................................13
5.3.1. Mobile Device Requirements .........................14
5.4. Resource Constrained Devices ..............................15
5.4.1. Limited Memory Footprint on Host Devices ...........15
5.4.2. Limited Processing Power for Routers ...............15
5.4.3. Sleeping Devices ...................................15
5.5. Addressing ................................................16
5.6. Manageability .............................................16
5.6.1. Diagnostics ........................................17
5.6.2. Route Tracking .....................................17
5.7. Route Selection ...........................................17
5.7.1. Route Cost .........................................17
5.7.2. Route Adaptation ...................................18
5.7.3. Route Redundancy ...................................18
5.7.4. Route Discovery Time ...............................18
5.7.5. Route Preference ...................................18
5.7.6. Real-Time Performance Measures .....................18
5.7.7. Prioritized Routing ................................18
5.8. Security Requirements .....................................19
5.8.1. Building Security Use Case .........................19
5.8.2. Authentication .....................................20
5.8.3. Encryption .........................................20
5.8.4. Disparate Security Policies ........................21
5.8.5. Routing Security Policies to Sleeping Devices ......21
6. Security Considerations ........................................21
7. Acknowledgments ................................................22
8. References .....................................................22
8.1. Normative References ......................................22
8.2. Informative References ....................................22
Appendix A. Additional Building Requirements ......................23
A.1. Additional Commercial Product Requirements ................23
A.1.1. Wired and Wireless Implementations .................23
A.1.2. World-Wide Applicability ...........................23
A.2. Additional Installation and Commissioning Requirements ....23
A.2.1. Unavailability of an IP Network ....................23
A.3. Additional Network Requirements ...........................23
A.3.1. TCP/UDP ............................................23
A.3.2. Interference Mitigation ............................23
A.3.3. Packet Reliability .................................24
A.3.4. Merging Commissioned Islands .......................24
A.3.5. Adjustable Routing Table Sizes .....................24
A.3.6. Automatic Gain Control .............................24
A.3.7. Device and Network Integrity .......................24
A.4. Additional Performance Requirements .......................24
A.4.1. Data Rate Performance ..............................24
A.4.2. Firmware Upgrades ..................................25
A.4.3. Route Persistence ..................................25
The Routing Over Low-Power and Lossy (ROLL) networks Working Group has been chartered to work on routing solutions for Low-Power and Lossy Networks (LLNs) in various markets: industrial, commercial (building), home, and urban networks. Pursuant to this effort, this document defines the IPv6 routing requirements for building automation.
低電力と損失のある（ロール）ネットワークのワーキンググループを介したルーティングは、さまざまな市場で低電力および損失のあるネットワーク（LLN）のルーティングソリューションに取り組むようにチャーターされています。この取り組みに従って、このドキュメントは、自動化の構築のためのIPv6ルーティング要件を定義しています。
Commercial buildings have been fitted with pneumatic, and subsequently electronic, communication routes connecting sensors to their controllers for over one hundred years. Recent economic and technical advances in wireless communication allow facilities to increasingly utilize a wireless solution in lieu of a wired solution, thereby reducing installation costs while maintaining highly reliant communication.
商業ビルには、空気圧症、その後電子通信ルートが装備されており、センサーをコントローラーに100年以上接続しています。ワイヤレス通信における最近の経済的および技術的進歩により、施設は有線ソリューションの代わりにワイヤレスソリューションをますます利用することで、非常に依存しない通信を維持しながら設置コストを削減できます。
The cost benefits and ease of installation of wireless sensors allow customers to further instrument their facilities with additional sensors, providing tighter control while yielding increased energy savings.
コストのメリットとワイヤレスセンサーの設置の容易さにより、顧客は追加のセンサーで施設をさらに整理することができ、エネルギーの節約を増やしながらより厳しい制御を提供します。
Wireless solutions will be adapted from their existing wired counterparts in many of the building applications including, but not limited to, heating, ventilation, and air conditioning (HVAC); lighting; physical security; fire; and elevator/lift systems. These devices will be developed to reduce installation costs while increasing installation and retrofit flexibility, as well as increasing the sensing fidelity to improve efficiency and building service quality.
ワイヤレスソリューションは、暖房、換気、エアコン（HVAC）を含むがこれらに限定されない多くの建築用途で、既存の有線対応物から採用されます。点灯;物理的なセキュリティ;火;エレベーター/リフトシステム。これらのデバイスは、設置コストを削減しながら設置コストを削減し、設置と柔軟性を改装し、センシングの忠実度を高めて効率とサービス品質を向上させるために開発されます。
Sensing devices may be battery-less, battery-powered, or mains-powered. Actuators and area controllers will be mains-powered. Due to building code and/or device density (e.g., equipment room), it is envisioned that a mix of wired and wireless sensors and actuators will be deployed within a building.
センシングデバイスは、バッテリーレス、バッテリー駆動、またはメイン駆動型です。アクチュエーターとエリアコントローラーは、主電源を搭載します。建築基準および/またはデバイス密度（機器室など）により、ワイヤードセンサーとワイヤレスセンサーとアクチュエーターの混合物が建物内に展開されることが想定されています。
Building management systems (BMSs) are deployed in a large set of vertical markets including universities, hospitals, government facilities, kindergarten through high school (K-12), pharmaceutical manufacturing facilities, and single-tenant or multi-tenant office buildings. These buildings range in size from 100K-sq.-ft. structures (5-story office buildings), to 1M-sq.-ft. skyscrapers (100-story skyscrapers), to complex government facilities such as the Pentagon. The described topology is meant to be the model to be used in all of these types of environments but clearly must be tailored to the building class, building tenant, and vertical market being served.
建築管理システム（BMSS）は、大学、病院、政府施設、幼稚園から高校（K-12）、医薬品製造施設、シングルテナントまたはマルチテナントのオフィスビルなど、大規模な垂直市場に展開されています。これらの建物の範囲は、100K平方フィートのサイズです。構造（5階建てのオフィスビル）、1M平方フィートまで。高層ビル（100階建ての高層ビル）、ペンタゴンなどの複雑な政府施設へ。記載されているトポロジーは、これらすべてのタイプの環境で使用されるモデルであることを意図していますが、明らかに建物クラス、建物テナント、および垂直市場に合わせて調整する必要があります。
Section 3 describes the necessary background to understand the context of building automation including the sensor, actuator, area controller, and zone controller layers of the topology; typical device density; and installation practices.
セクション3では、トポロジーのセンサー、アクチュエータ、エリアコントローラー、ゾーンコントローラー層など、自動化の構築のコンテキストを理解するために必要な背景について説明します。典型的なデバイス密度;およびインストールプラクティス。
Section 4 defines the traffic flow of the aforementioned sensors, actuators, and controllers in commercial buildings.
セクション4では、商業ビルの前述のセンサー、アクチュエーター、およびコントローラーの交通流を定義します。
Section 5 defines the full set of IPv6 routing requirements for commercial buildings.
セクション5では、商業ビルのIPv6ルーティング要件の完全なセットを定義します。
Appendix A documents important commercial building requirements that are out of scope for routing yet will be essential to the final acceptance of the protocols used within the building.
付録Aは、ルーティングの範囲外である重要な商業ビルの要件を文書化していますが、建物内で使用されるプロトコルの最終的な受け入れに不可欠です。
Section 3 and Appendix A are mainly included for educational purposes.
セクション3と付録Aは、主に教育目的で含まれています。
The expressed aim of this document is to provide the set of IPv6 routing requirements for LLNs in buildings, as described in Section 5.
このドキュメントの表明された目的は、セクション5で説明されているように、建物内のLLNのIPv6ルーティング要件のセットを提供することです。
For a description of the terminology used in this specification, please see [ROLL-TERM].
この仕様で使用されている用語の説明については、[ロールタイム]を参照してください。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
To understand the network systems requirements of a building management system in a commercial building, this document uses a framework to describe the basic functions and composition of the system. A BMS is a hierarchical system of sensors, actuators, controllers, and user interface devices that interoperate to provide a safe and comfortable environment while constraining energy costs.
商業ビルの建物管理システムのネットワークシステムの要件を理解するために、このドキュメントはフレームワークを使用して、システムの基本的な機能と構成を説明しています。BMSは、エネルギーコストを制約しながら、安全で快適な環境を提供するために相互運用するセンサー、アクチュエーター、コントローラー、およびユーザーインターフェイスデバイスの階層システムです。
A BMS is divided functionally across different but interrelated building subsystems such as heating, ventilation, and air conditioning (HVAC); fire; security; lighting; shutters; and elevator/lift control systems, as denoted in Figure 1.
BMSは、暖房、換気、空調（HVAC）などの異なるが相互に関連する建物のサブシステムで機能的に分割されます。火;安全;点灯;シャッター;図1に示されているように、エレベーター/リフト制御システム。
Much of the makeup of a BMS is optional and installed at the behest of the customer. Sensors and actuators have no standalone functionality. All other devices support partial or complete standalone functionality. These devices can optionally be tethered to form a more cohesive system. The customer requirements dictate the level of integration within the facility. This architecture provides excellent fault tolerance since each node is designed to operate in an independent mode if the higher layers are unavailable.
BMSの構成の多くはオプションであり、顧客の要請にインストールされています。センサーとアクチュエーターには、スタンドアロン機能がありません。他のすべてのデバイスは、部分的または完全なスタンドアロン機能をサポートしています。これらのデバイスは、オプションで、よりまとまりのあるシステムを形成するためにつなぐことができます。顧客の要件は、施設内の統合レベルを決定します。このアーキテクチャは、高レイヤーが利用できない場合は、各ノードが独立モードで動作するように設計されているため、優れたフォールトトレランスを提供します。
+------+ +-----+ +------+ +------+ +------+ +------+
Bldg App'ns | | | | | | | | | | | |
| | | | | | | | | | | |
Building Cntl | | | | | S | | L | | S | | E |
| | | | | E | | I | | H | | L |
Area Control | H | | F | | C | | G | | U | | E |
| V | | I | | U | | H | | T | | V |
Zone Control | A | | R | | R | | T | | T | | A |
| C | | E | | I | | I | | E | | T |
Actuators | | | | | T | | N | | R | | O |
| | | | | Y | | G | | S | | R |
Sensors | | | | | | | | | | | |
+------+ +-----+ +------+ +------+ +------+ +------+
Figure 1: Building Systems and Devices
図1：構築システムとデバイス
As Figure 1 indicates, a BMS may be composed of many functional stacks or silos that are interoperably woven together via building applications. Each silo has an array of sensors that monitor the environment and actuators that modify the environment, as determined by the upper layers of the BMS topology. The sensors typically are at the edge of the network structure, providing environmental data for the system. The actuators are the sensors' counterparts, modifying the characteristics of the system, based on the sensor data and the applications deployed.
図1が示すように、BMSは、建物の用途を介して相互に織り込まれた多くの機能的なスタックまたはサイロで構成される場合があります。各サイロには、BMSトポロジの上層によって決定されるように、環境を変更する環境とアクチュエーターを監視するセンサーの配列があります。センサーは通常、ネットワーク構造の端にあり、システムの環境データを提供します。アクチュエーターはセンサーのカウンターパートであり、センサーデータと展開されたアプリケーションに基づいて、システムの特性を変更します。
An area describes a small physical locale within a building, typically a room. HVAC (temperature and humidity) and lighting (room lighting, shades, solar loads) vendors oftentimes deploy area controllers. Area controllers are fed by sensor inputs that monitor the environmental conditions within the room. Common sensors found in many rooms that feed the area controllers include temperature, occupancy, lighting load, solar load, and relative humidity. Sensors found in specialized rooms (such as chemistry labs) might include air flow, pressure, and CO2 and CO particle sensors. Room actuation includes temperature setpoint, lights, and blinds/curtains.
エリアは、建物内の小さな物理的な場所、通常は部屋を説明しています。HVAC（温度と湿度）と照明（部屋の照明、シェード、太陽負荷）ベンダーは、しばしばエリアコントローラーを展開します。エリアコントローラーは、部屋内の環境条件を監視するセンサー入力によって供給されます。エリアコントローラーに供給される多くの部屋に見られる一般的なセンサーには、温度、占有率、照明荷重、太陽負荷、相対湿度が含まれます。特殊な部屋（化学ラボなど）に含まれるセンサーには、空気の流れ、圧力、CO2およびCO粒子センサーが含まれる場合があります。部屋の作動には、温度セットポイント、ライト、ブラインド/カーテンが含まれます。
Zone controllers support a similar set of characteristics to area controllers, albeit for an extended space. A zone is normally a logical grouping or functional division of a commercial building. A zone may also coincidentally map to a physical locale such as a floor.
ゾーンコントローラーは、拡張スペースではありますが、エリアコントローラーと同様の特性セットをサポートしています。ゾーンは通常、商業ビルの論理的なグループまたは機能的部門です。ゾーンは、偶然にも床などの物理的なロケールにマッピングされる場合があります。
Zone controllers may have direct sensor inputs (smoke detectors for fire), controller inputs (room controllers for air handlers in HVAC), or both (door controllers and tamper sensors for security). Like area/room controllers, zone controllers are standalone devices that operate independently or may be attached to the larger network for more synergistic control.
ゾーンコントローラーには、直接センサー入力（火災の煙探知機）、コントローラー入力（HVACのエアハンドラー用のルームコントローラー）、またはその両方（ドアコントローラーとセキュリティのタンパーセンサー）があります。エリア/ルームコントローラーと同様に、ゾーンコントローラーは独立して動作するスタンドアロンデバイスであるか、より相乗的な制御のためにより大きなネットワークに接続される可能性があります。
A BMS is installed very differently from most other IT networks. IT networks are typically installed as an overlay onto the existing environment and are installed from the inside out. That is, the network wiring infrastructure is installed; the switches, routers, and servers are connected and made operational; and finally, the endpoints (e.g., PCs, VoIP phones) are added.
BMSは、他のほとんどのITネットワークとは非常に異なってインストールされています。ITネットワークは通常、既存の環境へのオーバーレイとしてインストールされ、内側からインストールされます。つまり、ネットワーク配線インフラストラクチャがインストールされています。スイッチ、ルーター、サーバーが接続され、動作可能になります。そして最後に、エンドポイント（PC、VoIP電話など）が追加されます。
BMSs, on the other hand, are installed from the outside in. That is, the endpoints (thermostats, lights, smoke detectors) are installed in the spaces first; local control is established in each room and tested for proper operation. The individual rooms are later lashed together into a subsystem (e.g., lighting). The individual subsystems (e.g., lighting, HVAC) then coalesce. Later, the entire system may be merged onto the enterprise network.
一方、BMSは外側から取り付けられます。つまり、エンドポイント（サーモスタット、ライト、煙探知器）が最初にスペースに設置されます。各部屋にローカルコントロールが確立され、適切な操作がテストされています。個々の部屋は、後にサブシステム（照明など）にまとめられます。個々のサブシステム（照明、HVACなど）は合体します。その後、システム全体がエンタープライズネットワークに統合される場合があります。
The rationale for this is partly due to the different construction trades having access to a building under construction at different times. The sheer size of a building often dictates that even a single trade may have multiple independent teams working simultaneously. Furthermore, the HVAC, lighting, and fire systems must be fully operational before the building can obtain its occupancy permit. Hence, the BMS must be in place and configured well before any of the IT servers (DHCP; Authentication, Authorization, and Accounting (AAA); DNS; etc.) are operational.
これの理論的根拠は、さまざまな時期に建設中の建物にアクセスできるように異なる建設取引が原因であるためです。建物の膨大なサイズは、単一の貿易でさえ、複数の独立したチームが同時に機能する可能性があることをしばしば指示します。さらに、建物が占有許可を取得する前に、HVAC、照明、および火災システムは完全に動作する必要があります。したがって、BMSは、ITサーバー（DHCP;認証、承認、および会計（AAA）; DNS;など）のいずれかのいずれかのいずれかのいずれかのいずれかのいずれかが運用可能になる前に、整備され、構成されている必要があります。
This implies that the BMS cannot rely on the availability of the IT network infrastructure or application servers. Rather, the BMS installation should be planned to dovetail into the IT system once the IT system is available for easy migration onto the IT network. Front-end planning of available switch ports, cable runs, access point (AP) placement, firewalls, and security policies will facilitate this adoption.
これは、BMSがITネットワークインフラストラクチャまたはアプリケーションサーバーの可用性に依存できないことを意味します。むしろ、ITシステムがITネットワークに簡単に移行できるようになったら、BMSのインストールをITシステムに刻むように計画する必要があります。利用可能なスイッチポート、ケーブルの実行、アクセスポイント（AP）配置、ファイアウォール、およびセキュリティポリシーのフロントエンド計画により、この採用が促進されます。
Device density differs, depending on the application and as dictated by the local building code requirements. The following subsections detail typical installation densities for different applications.
デバイス密度は、アプリケーションに応じて、現地の建築基準要件によって決定されるように異なります。次のサブセクションでは、さまざまなアプリケーションの典型的な設置密度を詳述します。
HVAC room applications typically have sensors/actuators and controllers spaced about 50 ft. apart. In most cases, there is a 3:1 ratio of sensors/actuators to controllers. That is, for each room there is an installed temperature sensor, flow sensor, and damper actuator for the associated room controller.
HVACルームアプリケーションには、通常、センサー/アクチュエーターとコントローラーが約50フィート離れています。ほとんどの場合、コントローラーに対するセンサー/アクチュエーターの3：1の比率があります。つまり、各部屋には、関連するルームコントローラー用の温度センサー、フローセンサー、ダンパーアクチュエータがあります。
HVAC equipment room applications are quite different. An air handler system may have a single controller with up to 25 sensors and actuators within 50 ft. of the air handler. A chiller or boiler is also controlled with a single equipment controller instrumented with 25 sensors and actuators. Each of these devices would be individually addressed since the devices are mandated or optional as defined by the specified HVAC application. Air handlers typically serve one or two floors of the building. Chillers and boilers may be installed per floor, but many times they service a wing, building, or the entire complex via a central plant.
HVAC機器ルームアプリケーションはまったく異なります。エアハンドラーシステムには、エアハンドラーの50フィート以内に最大25個のセンサーとアクチュエーターを備えた単一のコントローラーがあります。チラーまたはボイラーは、25のセンサーとアクチュエーターを備えた単一の機器コントローラーで制御されています。これらの各デバイスは、指定されたHVACアプリケーションで定義されているように、デバイスが義務付けられているか、オプションであるため、個別にアドレス指定されます。通常、エアハンドラーは建物の1階または2階を提供します。チラーとボイラーはフロアごとに設置される場合がありますが、多くの場合、中央のプラントを介して翼、建物、または複合施設全体にサービスを提供します。
These numbers are typical. In special cases, such as clean rooms, operating rooms, pharmaceutical facilities, and labs, the ratio of sensors to controllers can increase by a factor of three. Tenant installations such as malls would opt for packaged units where much of the sensing and actuation is integrated into the unit; here, a single device address would serve the entire unit.
これらの数字は典型的です。クリーンルーム、手術室、医薬品施設、ラボなどの特別な場合、センサーに対するセンサーの比率は3倍に増加する可能性があります。モールなどのテナントの設置は、センシングと作動の多くがユニットに統合されているパッケージユニットを選択します。ここでは、単一のデバイスアドレスがユニット全体にサービスを提供します。
Fire systems are much more uniformly installed, with smoke detectors installed about every 50 ft. This is dictated by local building codes. Fire pull boxes are installed uniformly about every 150 ft. A fire controller will service a floor or wing. The fireman's fire panel will service the entire building and typically is installed in the atrium.
火災システムは、はるかに均一に設置されており、煙探知器は約50フィートごとに設置されています。これは、地元の建物コードによって決定されます。火のプルボックスは、約150フィートごとに均一に設置されています。消防車が床または翼を提供します。消防士の消防士は建物全体にサービスを提供し、通常はアトリウムに設置されます。
Lighting is also very uniformly installed, with ballasts installed approximately every 10 ft. A lighting panel typically serves 48 to 64 zones. Wired systems tether many lights together into a single zone. Wireless systems configure each fixture independently to increase flexibility and reduce installation costs.
照明も非常に均一に設置されており、バラストは約10フィートごとに設置されています。通常、照明パネルは48〜64ゾーンを提供します。有線システムは、多くのライトを単一のゾーンにつなぎ合わせます。ワイヤレスシステムは、柔軟性を高め、設置コストを削減するために、各フィクスチャーを個別に構成します。
Security systems are non-uniformly oriented, with heavy density near doors and windows and lighter density in the building's interior space.
セキュリティシステムは不均一に配向されており、ドアや窓の近くに密度が高く、建物の内部スペースには軽い密度があります。
The recent influx of interior and perimeter camera systems is increasing the security footprint. These cameras are atypical endpoints requiring up to 1 megabit/second (Mbit/s) data rates per camera, as contrasted by the few kbit/s needed by most other BMS sensing equipment. Previously, camera systems had been deployed on proprietary wired high-speed networks. More recent implementations utilize wired or wireless IP cameras integrated into the enterprise LAN.
最近のインテリアおよび境界カメラシステムの流入により、セキュリティフットプリントが増加しています。これらのカメラは、他のほとんどのBMSセンシング機器で必要な少数のKBIT/Sとは対照的に、カメラごとに最大1メガビット/秒（MBIT/S）データレートを必要とする非定型エンドポイントです。以前は、カメラシステムは独自の有線高速ネットワークに展開されていました。より最近の実装では、エンタープライズLANに統合された有線またはワイヤレスIPカメラを利用しています。
The independent nature of the automation subsystems within a building can significantly affect network traffic patterns. Much of the real-time sensor environmental data and actuator control stays within the local LLN environment, while alarms and other event data will percolate to higher layers.
建物内の自動化サブシステムの独立した性質は、ネットワークトラフィックパターンに大きな影響を与える可能性があります。リアルタイムセンサーの環境データとアクチュエータ制御の多くは、ローカルLLN環境内にとどまりますが、アラームやその他のイベントデータは高層に浸透します。
Each sensor in the LLN unicasts point to point (P2P) about 200 bytes of sensor data to its associated controller each minute and expects an application acknowledgment unicast returned from the destination. Each controller unicasts messages at a nominal rate of 6 kbit/minute to peer or supervisory controllers. Thirty percent of each node's packets are destined for other nodes within the LLN. Seventy percent of each node's packets are destined for an aggregation device (multipoint to point (MP2P)) and routed off the LLN. These messages also require a unicast acknowledgment from the destination. The above values assume direct node-to-node communication; meshing and error retransmissions are not considered.
LLNユニキャストの各センサーは、ポイント（P2P）から約200バイトのセンサーデータを関連するコントローラーに毎分ポイントし、目的地から返されるアプリケーションの確認ユニキャストが期待されています。各コントローラーは、ピアまたは監督者のコントローラーに6 kbit/分の名目レートでメッセージをユニカストします。各ノードのパケットの30％は、LLN内の他のノードに向けられています。各ノードのパケットの70％は、集約デバイス（Multipoint to Point（MP2P））用に運命づけられ、LLNから外れています。これらのメッセージには、目的地からのユニキャストの承認も必要です。上記の値は、直接ノード間通信を想定しています。メッシュとエラーの再送信は考慮されません。
Multicasts (point to multipoint (P2MP)) to all nodes in the LLN occur for node and object discovery when the network is first commissioned. This data is typically a one-time bind that is henceforth persisted. Lighting systems will also readily use multicasting during normal operations to turn banks of lights "on" and "off" simultaneously.
LLNのすべてのノードへのマルチキャスト（マルチポイント（P2MP）のポイント）は、ネットワークが最初に委託されたときにノードとオブジェクトの発見に対して発生します。このデータは、通常、1回限りのバインドであり、今後も持続します。また、照明システムは、通常の操作中にマルチキャストを容易に使用して、ライトバンクを「オン」と「オフ」と同時に変えます。
BMSs may be either polled or event-based. Polled data systems will generate a uniform and constant packet load on the network. Polled architectures, however, have proven not to be scalable. Today, most vendors have developed event-based systems that pass data on event. These systems are highly scalable and generate low data on the network at quiescence. Unfortunately, the systems will generate a heavy load on startup since all initial sensor data must migrate to the controller level. They also will generate a temporary but heavy load during firmware upgrades. This latter load can normally be mitigated by performing these downloads during off-peak hours.
BMSは、ポーリングまたはイベントベースのいずれかです。ポーリングされたデータシステムは、ネットワーク上に均一で一定のパケット負荷を生成します。ただし、投票されたアーキテクチャは、スケーラブルではないことが証明されています。今日、ほとんどのベンダーは、イベントのデータに合格するイベントベースのシステムを開発しています。これらのシステムは非常にスケーラブルであり、静止時にネットワーク上の低データを生成します。残念ながら、すべての初期センサーデータがコントローラーレベルに移行する必要があるため、システムは起動に大きな負荷を生成します。また、ファームウェアのアップグレード中に一時的なが重い負荷を生成します。この後者の負荷は、通常、オフピーク時間中にこれらのダウンロードを実行することで緩和できます。
Devices will also need to reference peers periodically for sensor data or to coordinate operation across systems. Normally, though, data will migrate from the sensor level upwards through the local and area levels, and then to the supervisory level. Traffic bottlenecks will typically form at the funnel point from the area controllers to the supervisory controllers.
また、デバイスは、センサーデータのために定期的にピアを参照するか、システム全体で動作を調整する必要があります。ただし、通常、データはセンサーレベルからローカルレベルおよびエリアレベルを介して上向きに移行し、次に監督レベルに移行します。通常、トラフィックボトルネックは、エリアコントローラーから監督コントローラーまでの目標到達プロセスで形成されます。
Initial system startup after a controlled outage or unexpected power failure puts tremendous stress on the network and on the routing algorithms. A BMS is comprised of a myriad of control algorithms at the room, area, zone, and enterprise layers. When these control algorithms are at quiescence, the real-time data rate is small, and the network will not saturate. An overall network traffic load of 6 kbit/s is typical at quiescence. However, upon any power loss, the control loops and real-time data quickly atrophy. A short power disruption of only 10 minutes may have a long-term deleterious impact on the building control systems, taking many hours to regain proper control. Control applications that cannot handle this level of disruption (e.g., hospital operating rooms) must be fitted with a secondary power source.
制御された停止または予期しない停電後の最初のシステム起動は、ネットワークとルーティングアルゴリズムに大きなストレスをかけます。BMSは、部屋、エリア、ゾーン、およびエンタープライズレイヤーの無数のコントロールアルゴリズムで構成されています。これらの制御アルゴリズムが静止状態にある場合、リアルタイムのデータレートは小さく、ネットワークは飽和しません。6 kbit/sの全体的なネットワークトラフィック負荷は、静止時に典型的です。ただし、電力損失により、コントロールループとリアルタイムデータは迅速に萎縮します。わずか10分の短い電力破壊は、建物制御システムに長期的な有害な影響を与える可能性があり、適切な制御を取り戻すのに何時間もかかります。このレベルの混乱を処理できない制御アプリケーション（病院の手術室など）には、二次電源を装備する必要があります。
Power disruptions are unexpected and in most cases will immediately impact lines-powered devices. Power disruptions, however, are transparent to battery-powered devices. These devices will continue to attempt to access the LLN during the outage. Battery-powered devices designed to buffer data that has not been delivered will further stress network operations when power returns.
電源の混乱は予想外であり、ほとんどの場合、ライン駆動のデバイスにすぐに影響を与えます。ただし、電力の破壊は、バッテリー駆動のデバイスに対して透明です。これらのデバイスは、停止中にLLNにアクセスしようとし続けます。配信されていないデータをバッファーするように設計されたバッテリー駆動のデバイスは、電源が戻ったときにネットワーク操作をさらに強調します。
Upon restart, lines-powered devices will naturally dither due to primary equipment delays or variance in the device self-tests. However, most lines-powered devices will be ready to access the LLN network within 10 seconds of power-up. Empirical testing indicates that routes acquired during startup will tend to be very oblique since the available neighbor lists are incomplete. This demands an adaptive routing protocol to allow for route optimization as the network stabilizes.
再起動すると、ライン駆動のデバイスは、プライマリ機器の遅延またはデバイスのセルフテストの分散により、自然に自然にディザーになります。ただし、ほとんどのライン駆動型デバイスは、電力アップから10秒以内にLLNネットワークにアクセスする準備ができています。経験的テストは、スタートアップ中に取得したルートが利用可能な近隣リストが不完全であるため、非常に斜めになる傾向があることを示しています。これにより、ネットワークが安定するにつれてルートの最適化を可能にするための適応ルーティングプロトコルが必要です。
Following are the building automation routing requirements for networks used to integrate building sensor, actuator, and control products. These requirements are written not presuming any preordained network topology, physical media (wired), or radio technology (wireless).
以下は、建物センサー、アクチュエータ、および制御製品の統合に使用されるネットワークの建築自動化ルーティング要件です。これらの要件は、事前に定められたネットワークトポロジ、物理メディア（有線）、または無線技術（ワイヤレス）を推定しないと書かれています。
Building control systems typically are installed and tested by electricians having little computer knowledge and no network communication knowledge whatsoever. These systems are often installed during the building construction phase, before the drywall and ceilings are in place. For new construction projects, the building enterprise IP network is not in place during installation of the building control system. For retrofit applications, the installer will still operate independently from the IP network so as not to affect network operations during the installation phase.
建物制御システムは通常、コンピューターの知識がほとんどなく、ネットワーク通信の知識がまったくない電気技師によってインストールおよびテストされます。これらのシステムは、ドライウォールと天井が配置される前に、建物の建設段階でしばしば設置されます。新しい建設プロジェクトの場合、建物制御システムの設置中は、建物のエンタープライズIPネットワークが整っていません。アプリケーションの改造の場合、インストーラーは、インストールフェーズ中にネットワーク操作に影響を与えないように、IPネットワークから独立して動作します。
In traditional wired systems, correct operation of a light switch/ballast pair was as simple as flipping on the light switch. In wireless applications, the tradesperson has to assure the same operation, yet be sure the operation of the light switch is associated with the proper ballast.
従来の有線システムでは、ライトスイッチ/バラストペアの正しい動作は、ライトスイッチをめくるのと同じくらい簡単でした。ワイヤレスアプリケーションでは、商人は同じ操作を保証する必要がありますが、ライトスイッチの動作が適切なバラストに関連付けられていることを確認してください。
System-level commissioning will later be deployed using a more computer savvy person with access to a commissioning device (e.g., a laptop computer). The completely installed and commissioned enterprise IP network may or may not be in place at this time. Following are the installation routing requirements.
後にシステムレベルの試運転は、試運転デバイス（ラップトップコンピューターなど）にアクセスできるよりコンピューターに精通した人を使用して展開されます。完全にインストールおよび委託されたエンタープライズIPネットワークは、現時点で導入されている場合とそうでない場合があります。以下は、インストールルーティング要件です。
It MUST be possible to fully commission network devices without requiring any additional commissioning device (e.g., a laptop). From the ROLL perspective, "zero configuration" means that a node can obtain an address and join the network on its own, without human intervention.
追加のコミッショニングデバイス（ラップトップなど）を必要とせずに、ネットワークデバイスを完全に委託することが可能である必要があります。ロールの観点から見ると、「Zero Configuration」とは、ノードがアドレスを取得し、人間の介入なしにそれ自体でネットワークに参加できることを意味します。
During installation, the room sensors, actuators, and controllers SHOULD be able to route packets amongst themselves and to any other device within the LLN, without requiring any additional routing infrastructure or routing configuration.
インストール中、部屋のセンサー、アクチュエーター、およびコントローラーは、追加のルーティングインフラストラクチャやルーティング構成を必要とせずに、自分自身やLLN内の他のデバイスにパケットをルーティングできる必要があります。
To eliminate the need to reconfigure the application upon replacing a failed device in the LLN, the replaced device must be able to advertise the old IP address of the failed device in addition to its new IP address. The routing protocols MUST support hosts and routers that advertise multiple IPv6 addresses.
LLNで失敗したデバイスを交換するとアプリケーションを再構成する必要性を排除するために、交換されたデバイスは、新しいIPアドレスに加えて、故障したデバイスの古いIPアドレスを宣伝できる必要があります。ルーティングプロトコルは、複数のIPv6アドレスを宣伝するホストとルーターをサポートする必要があります。
Building control systems are designed for facilities from 50,000 sq. ft. to 1M+ sq. ft. The networks that support these systems must cost-effectively scale accordingly. In larger facilities, installation may occur simultaneously on various wings or floors, yet the end system must seamlessly merge. Following are the scalability requirements.
建物制御システムは、50,000平方フィートから1m平方フィートまでの施設向けに設計されています。これらのシステムをサポートするネットワークは、それに応じて費用対効果の高いスケーリングが必要です。より大きな施設では、さまざまな翼または床に設置が同時に発生する可能性がありますが、最終システムはシームレスにマージする必要があります。スケーラビリティ要件が次のとおりです。
The routing protocol MUST be able to support networks with at least 2,000 nodes, where 1,000 nodes would act as routers and the other 1,000 nodes would be hosts. Subnetworks (e.g., rooms, primary equipment) within the network must support up to 255 sensors and/or actuators.
ルーティングプロトコルは、少なくとも2,000ノードのネットワークをサポートできる必要があります。1,000ノードはルーターとして機能し、他の1,000ノードがホストになります。ネットワーク内のサブネットワーク（部屋、一次機器など）は、最大255個のセンサーおよび/またはアクチュエーターをサポートする必要があります。
The data domain for commercial BMSs may sprawl across a vast portion of the physical domain. For example, a chiller may reside in the facility's basement due to its size, yet the associated cooling towers will reside on the roof. The cold-water supply and return pipes snake through all of the intervening floors. The feedback control loops for these systems require data from across the facility.
市販のBMSのデータドメインは、物理ドメインの膨大な部分に広がる可能性があります。たとえば、チラーはそのサイズのために施設の地下室に存在する可能性がありますが、関連する冷却塔は屋根の上にあります。冷水供給と返品パイプヘビは、介入するすべての床を通して蛇行します。これらのシステムのフィードバック制御ループには、施設全体からのデータが必要です。
A network device MUST be able to communicate in an end-to-end manner with any other device on the network. Thus, the routing protocol MUST provide routes between arbitrary hosts within the appropriate administrative domain.
ネットワークデバイスは、ネットワーク上の他のデバイスとエンドツーエンドの方法で通信できる必要があります。したがって、ルーティングプロトコルは、適切な管理ドメイン内の任意のホスト間のルートを提供する必要があります。
Most devices are affixed to walls or installed on ceilings within buildings. Hence, the mobility requirements for commercial buildings are few. However, in wireless environments, location tracking of occupants and assets is gaining favor. Asset-tracking applications, such as tracking capital equipment (e.g., wheelchairs) in medical facilities, require monitoring movement with granularity of a minute; however, tracking babies in a pediatric ward would require latencies less than a few seconds.
ほとんどのデバイスは、壁に貼られているか、建物内の天井に設置されています。したがって、商業ビルのモビリティ要件はほとんどありません。ただし、ワイヤレス環境では、居住者と資産の場所追跡が好まれています。医療施設での資本機器の追跡（車椅子など）などの資産追跡アプリケーションには、1分間の粒度を備えた監視の動きが必要です。ただし、小児病棟で赤ちゃんを追跡するには、数秒未満のレイテンシが必要になります。
The following subsections document the mobility requirements in the routing layer for mobile devices. Note, however, that mobility can be implemented at various layers of the system, and the specific requirements depend on the chosen layer. For instance, some devices may not depend on a static IP address and are capable of re-establishing application-level communications when given a new IP address. Alternatively, mobile IP may be used, or the set of routers in a building may give an impression of a building-wide network and allow devices to retain their addresses regardless of where they are, handling routing between the devices in the background.
次のサブセクションでは、モバイルデバイスのルーティングレイヤーのモビリティ要件を文書化します。ただし、モビリティはシステムのさまざまなレイヤーで実装でき、特定の要件は選択されたレイヤーに依存することに注意してください。たとえば、一部のデバイスは静的IPアドレスに依存せず、新しいIPアドレスが与えられた場合にアプリケーションレベルの通信を再確立することができます。あるいは、モバイルIPを使用する場合があります。または、建物内のルーターのセットが建物全体のネットワークの印象を与え、デバイスがどこにいるかに関係なくアドレスを保持できるようにする場合があります。
To minimize network dynamics, mobile devices while in motion should not be allowed to act as forwarding devices (routers) for other devices in the LLN. Network configuration should allow devices to be configured as routers or hosts.
ネットワークダイナミクスを最小限に抑えるために、動いている間のモバイルデバイスは、LLNの他のデバイスの転送デバイス（ルーター）として機能することを許可されてはなりません。ネットワーク構成では、デバイスをルーターまたはホストとして構成できるようにする必要があります。
An LLN typically spans a single floor in a commercial building. Mobile devices may move within this LLN. For example, a wheelchair may be moved from one room on the floor to another room on the same floor.
LLNは通常、商業ビルの1階に及びます。モバイルデバイスはこのLLN内に移動する場合があります。たとえば、車椅子は、床のある部屋から同じ床の別の部屋に移動できます。
A mobile LLN device that moves within the confines of the same LLN SHOULD re-establish end-to-end communication with a fixed device also in the LLN within 5 seconds after it ceases movement. The LLN network convergence time should be less than 10 seconds once the mobile device stops moving.
同じLLNの範囲内に移動するモバイルLLNデバイスは、動きをやめた後5秒以内に、LLNの固定デバイスとのエンドツーエンド通信を再確立する必要があります。LLNネットワークの収束時間は、モバイルデバイスの移動が停止すると、10秒未満にする必要があります。
A mobile device may move across LLNs, such as a wheelchair being moved to a different floor.
モバイルデバイスは、車椅子が別の床に移動するなど、LLNを横切って移動する場合があります。
A mobile device that moves outside of its original LLN SHOULD re-establish end-to-end communication with a fixed device also in the new LLN within 10 seconds after the mobile device ceases movement. The network convergence time should be less than 20 seconds once the mobile device stops moving.
元のLLNの外側に移動するモバイルデバイスは、モバイルデバイスが動きを止めてから10秒以内に、新しいLLNでも固定デバイスとのエンドツーエンド通信を再確立する必要があります。ネットワークの収束時間は、モバイルデバイスの移動を停止すると、20秒未満にする必要があります。
Sensing and actuator device processing power and memory may be 4 orders of magnitude less (i.e., 10,000x) than many more traditional client devices on an IP network. The routing mechanisms must therefore be tailored to fit these resource constrained devices.
センシングおよびアクチュエータデバイスの処理能力とメモリは、IPネットワーク上の多くの従来のクライアントデバイスよりも4桁少ない（つまり、10,000x）になる場合があります。したがって、ルーティングメカニズムは、これらのリソース制約付きデバイスに適合するように調整する必要があります。
The software size requirement for non-routing devices (e.g., sleeping sensors and actuators) SHOULD be implementable in 8-bit devices with no more than 128 KB of memory.
非ルーティングデバイス（睡眠センサーやアクチュエーターなど）のソフトウェアサイズの要件は、128 kb以下のメモリを持つ8ビットデバイスで実装できる必要があります。
The software size requirements for routing devices (e.g., room controllers) SHOULD be implementable in 8-bit devices with no more than 256 KB of flash memory.
ルーティングデバイスのソフトウェアサイズの要件（例：ルームコントローラー）は、256 kbのフラッシュメモリを持つ8ビットデバイスで実装できる必要があります。
Sensing devices will, in some cases, utilize battery power or energy harvesting techniques for power and will operate mostly in a sleep mode to maintain power consumption within a modest budget. The routing protocol MUST take into account device characteristics such as power budget.
センシングデバイスは、場合によっては、電力のためにバッテリー電源またはエネルギー収穫技術を利用し、主に睡眠モードで動作し、控えめな予算内で電力消費を維持します。ルーティングプロトコルは、電力予算などのデバイスの特性を考慮する必要があります。
Typically, sensor battery life (2,000 mAh) needs to extend for at least 5 years when the device is transmitting its data (200 octets) once per minute over a low-power transceiver (25 mA) and expecting an application acknowledgment. In this case, the transmitting device must leave its receiver in a high-powered state, awaiting the return of the application ACK. To minimize this latency, a highly efficient routing protocol that minimizes hops, and hence end-to-end communication, is required. The routing protocol MUST take into account node properties, such as "low-powered node", that produce efficient low-latency routes that minimize radio "on" time for these devices.
通常、センサーのバッテリー寿命（2,000 MAH）は、デバイスが低電力トランシーバー（25 MA）で1分あたり1回データ（200オクテット）を送信し、アプリケーションの確認を期待している場合、少なくとも5年間延長する必要があります。この場合、送信装置は受信機を高電力状態にして、アプリケーションACKの返還を待たなければなりません。このレイテンシを最小限に抑えるには、ホップを最小限に抑え、したがってエンドツーエンドの通信を最小限に抑える非常に効率的なルーティングプロトコルが必要です。ルーティングプロトコルでは、これらのデバイスの「時間」時に無線を最小限に抑える低遅延性ルートを生成する「低電力ノード」などのノードプロパティを考慮する必要があります。
Sleeping devices MUST be able to receive inbound data. Messages sent to battery-powered nodes MUST be buffered by the last-hop router for a period of at least 20 seconds when the destination node is currently in its sleep cycle.
睡眠デバイスは、インバウンドデータを受信できる必要があります。バッテリー駆動のノードに送信されたメッセージは、宛先ノードが現在睡眠サイクルにある場合、少なくとも20秒間、ラストホップルーターによってバッファリングする必要があります。
Building management systems require different communication schemes to solicit or post network information. Multicasts or anycasts need to be used to decipher unresolved references within a device when the device first joins the network.
構築管理システムには、ネットワーク情報を募集または投稿するために、さまざまな通信スキームが必要です。デバイスが最初にネットワークに結合したときに、デバイス内の未解決の参照を解読するために、マルチキャストまたはエイキャストを使用する必要があります。
As with any network communication, multicasting should be minimized. This is especially a problem for small embedded devices with limited network bandwidth. Multicasts are typically used for network joins and application binding in embedded systems. Routing MUST support anycast, unicast, and multicast.
他のネットワーク通信と同様に、マルチキャストを最小限に抑える必要があります。これは、ネットワーク帯域幅が限られている小さな埋め込みデバイスにとって特に問題です。マルチキャストは通常、ネットワーク結合および埋め込みシステムでのアプリケーションバインディングに使用されます。ルーティングは、Anycast、Unicast、およびMulticastをサポートする必要があります。
As previously noted in Section 3.3, installation of LLN devices within a BMS follows an "outside-in" work flow. Edge devices are installed first and tested for communication and application integrity. These devices are then aggregated into islands, then LLNs, and later affixed onto the enterprise network.
セクション3.3で前述したように、BMS内のLLNデバイスのインストールは、「外部」ワークフローに従います。エッジデバイスは最初にインストールされ、通信とアプリケーションの整合性についてテストされます。これらのデバイスは、島、次にLLNSに集約され、後にエンタープライズネットワークに貼り付けられます。
The need for diagnostics most often occurs during the installation and commissioning phase, although at times diagnostic information may be requested during normal operation. Battery-powered wireless devices typically will have a self-diagnostic mode that can be initiated via a button press on the device. The device will display its link status and/or end-to-end connectivity when the button is pressed. Lines-powered devices will continuously display communication status via a bank of LEDs, possibly denoting signal strength and end-to-end application connectivity.
診断の必要性は、ほとんどの場合、設置および試運転段階で発生しますが、通常の操作中に診断情報が要求される場合があります。通常、バッテリー駆動のワイヤレスデバイスは、デバイスのボタンを押すことで開始できる自己診断モードを備えています。デバイスは、ボタンが押されたときにリンクステータスおよび/またはエンドツーエンドの接続を表示します。ライン駆動のデバイスは、LEDのバンクを介して通信ステータスを継続的に表示し、おそらく信号強度とエンドツーエンドのアプリケーション接続を示すものです。
The local diagnostics noted above oftentimes are suitable for defining room-level networks. However, as these devices aggregate, system-level diagnostics may need to be executed to ameliorate route vacillation, excessive hops, communication retries, and/or network bottlenecks.
上記の地元の診断は、多くの場合、部屋レベルのネットワークを定義するのに適しています。ただし、これらのデバイスが集計するため、ルートの動揺、過度のホップ、通信再編成、および/またはネットワークボトルネックを改善するには、システムレベルの診断を実行する必要があります。
In operational networks, due to the mission-critical nature of the application, the LLN devices will be temporally monitored by the higher layers to assure that communication integrity is maintained. Failure to maintain this communication will result in an alarm being forwarded to the enterprise network from the monitoring node for analysis and remediation.
運用ネットワークでは、アプリケーションのミッションクリティカルな性質により、LLNデバイスは、通信の完全性が維持されることを保証するために、より高いレイヤーによって一時的に監視されます。この通信を維持できないと、分析と修復のために監視ノードからエンタープライズネットワークにアラームが転送されます。
In addition to the initial installation and commissioning of the system, it is equally important for the ongoing maintenance of the system to be simple and inexpensive. This implies a straightforward device swap when a failed device is replaced, as noted in Section 5.1.3.
システムの最初のインストールと試運転に加えて、システムの継続的なメンテナンスがシンプルで安価であることも同様に重要です。これは、セクション5.1.3に記載されているように、失敗したデバイスが交換されたときに簡単なデバイススワップを意味します。
To improve diagnostics, the routing protocol SHOULD be able to be placed in and out of "verbose" mode. Verbose mode is a temporary debugging mode that provides additional communication information including, at least, the total number of routed packets sent and received, the number of routing failures (no route available), neighbor table members, and routing table entries. The data provided in verbose mode should be sufficient that a network connection graph could be constructed and maintained by the monitoring node.
診断を改善するために、ルーティングプロトコルを「冗長」モードに内外に配置できる必要があります。詳細モードは、少なくとも送信および受信したルーティングパケットの総数、ルーティング障害の数（ルートなし）、ネイバーテーブルメンバー、ルーティングテーブルエントリなど、追加の通信情報を提供する一時的なデバッグモードです。冗長モードで提供されるデータは、監視ノードによってネットワーク接続グラフを構築および維持できるほど十分でなければなりません。
Diagnostic data should be kept by the routers continuously and be available for solicitation at any time by any other node on the internetwork. Verbose mode will be activated/deactivated via unicast, multicast, or other means. Devices having available resources may elect to support verbose mode continuously.
診断データは、ルーターによって継続的に保持され、インターネットワークの他のノードがいつでも勧誘に利用できるようにする必要があります。冗長モードは、ユニキャスト、マルチキャスト、またはその他の手段を介してアクティブ化/非アクティブ化されます。利用可能なリソースを持つデバイスは、冗長モードを継続的にサポートすることを選択する場合があります。
Route diagnostics SHOULD be supported, providing information such as route quality, number of hops, and available alternate active routes with associated costs. Route quality is the relative measure of "goodness" of the selected source to destination route as compared to alternate routes. This composite value may be measured as a function of hop count, signal strength, available power, existing active routes, or any other criteria deemed by ROLL as the route cost differentiator.
ルート診断をサポートする必要があり、ルートの品質、ホップ数、関連するコストを備えた利用可能な代替アクティブルートなどの情報を提供する必要があります。ルートの品質は、代替ルートと比較して、選択したソースの宛先ルートへの「良さ」の相対的な尺度です。この複合値は、ホップカウント、信号強度、利用可能な電力、既存のアクティブルート、またはロールによってルートコストの差別化要因と見なされるその他の基準の関数として測定できます。
Route selection determines reliability and quality of the communication among the devices by optimizing routes over time and resolving any nuances developed at system startup when nodes are asynchronously adding themselves to the network.
ルートの選択により、ルートを時間の経過とともに最適化し、ノードがネットワークに非同期的に追加されているときにシステムスタートアップで開発されたニュアンスを解決することにより、デバイス間の通信の信頼性と品質を決定します。
The routing protocol MUST support a metric of route quality and optimize selection according to such metrics within constraints established for links along the routes. These metrics SHOULD reflect metrics such as signal strength, available bandwidth, hop count, energy availability, and communication error rates.
ルーティングプロトコルは、ルートの品質のメトリックをサポートし、ルートに沿ったリンクに確立された制約内のこのようなメトリックに従って選択を最適化する必要があります。これらのメトリックは、信号強度、利用可能な帯域幅、ホップカウント、エネルギーの可用性、通信エラー率などのメトリックを反映する必要があります。
Communication routes MUST be adaptive and converge toward optimality of the chosen metric (e.g., signal quality, hop count) in time.
通信ルートは適応的であり、選択したメトリック（たとえば、信号品質、ホップカウント）の最適性に向かって収束する必要があります。
The routing layer SHOULD be configurable to allow secondary and tertiary routes to be established and used upon failure of the primary route.
ルーティングレイヤーは、一次ルートの故障時に二次および三次ルートを確立し、使用できるように構成可能である必要があります。
Mission-critical commercial applications (e.g., fire, security) require reliable communication and guaranteed end-to-end delivery of all messages in a timely fashion. Application-layer time-outs must be selected judiciously to cover anomalous conditions such as lost packets and/or route discoveries, yet not be set too large to over-damp the network response. If route discovery occurs during packet transmission time (reactive routing), it SHOULD NOT add more than 120 ms of latency to the packet delivery time.
ミッションクリティカルな商用アプリケーション（例：火災、セキュリティ）には、信頼できるコミュニケーションが必要であり、すべてのメッセージのエンドツーエンド配信がタイムリーに必要です。アプリケーション層のタイムアウトは、失われたパケットやルートの発見などの異常な条件をカバーするために慎重に選択する必要がありますが、ネットワーク応答を過剰に抑えるには大きすぎると設定する必要はありません。パケット伝送時間（反応ルーティング）中にルートの発見が発生した場合、パケット配信時間に120ミリ秒以上の遅延を追加しないでください。
The routing protocol SHOULD allow for the support of manually configured static preferred routes.
ルーティングプロトコルは、手動で構成された静的優先ルートのサポートを可能にする必要があります。
A node transmitting a "request with expected reply" to another node must send the message to the destination and receive the response in not more than 120 ms. This response time should be achievable with 5 or less hops in each direction. This requirement assumes network quiescence and a negligible turnaround time at the destination node.
別のノードに「予想される返信を伴うリクエスト」を送信するノードは、宛先にメッセージを送信し、120ミリ秒以内に応答を受信する必要があります。この応答時間は、各方向に5回以下のホップ以下で達成できる必要があります。この要件は、ネットワークの静止と、宛先ノードでのターンアラウンド時間が無視できると想定しています。
Network and application packet routing prioritization must be supported to assure that mission-critical applications (e.g., fire detection) cannot be deferred while less critical applications access the network. The routing protocol MUST be able to provide routes with different characteristics, also referred to as Quality of Service (QoS) routing.
ネットワークとアプリケーションのパケットルーティングの優先順位付けをサポートして、ミッションクリティカルなアプリケーション（火災検出など）を延期できないことを保証する必要があります。ルーティングプロトコルは、さまざまな特性を備えたルートを提供できる必要があります。これは、サービス品質（QoS）ルーティングとも呼ばれます。
This section sets forth specific requirements that are placed on any protocols developed or used in the ROLL building environment, in order to ensure adequate security and retain suitable flexibility of use and function of the protocol.
このセクションでは、適切なセキュリティを確保し、プロトコルの使用と機能の適切な柔軟性を保持するために、ロールビルディング環境で開発または使用されるプロトコルに配置された特定の要件を示します。
Due to the variety of buildings and tenants, the BMSs must be completely configurable on-site.
さまざまな建物やテナントのため、BMSはオンサイトで完全に構成可能でなければなりません。
Due to the quantity of the BMS devices (thousands) and their inaccessibility (oftentimes above ceilings), security configuration over the network is preferred over local configuration.
BMSデバイスの量（数千）とそのアクセス不能（多くの場合、天井の上にある）により、ネットワーク上のセキュリティ構成がローカル構成よりも優先されます。
Wireless encryption and device authentication security policies need to be considered in commercial buildings, while keeping in mind the impact on the limited processing capabilities and additional latency incurred on the sensors, actuators, and controllers.
ワイヤレス暗号化とデバイス認証セキュリティポリシーは、商業ビルで検討する必要がありますが、センサー、アクチュエーター、コントローラーに発生した制限された処理機能と追加のレイテンシーへの影響を念頭に置いてください。
BMSs are typically highly configurable in the field, and hence the security policy is most often dictated by the type of building to which the BMS is being installed. Single-tenant owner-occupied office buildings installing lighting or HVAC control are candidates for implementing a low level of security on the LLN, especially when the LLN is not connected to an external network. Antithetically, military or pharmaceutical facilities require strong security policies. As noted in the installation procedures described in Sections 3.3 and 5.2, security policies MUST support dynamic configuration to allow for a low level of security during the installation phase (prior to building occupancy, when it may be appropriate to use only diagnostic levels of security), yet to make it possible to easily raise the security level network-wide during the commissioning phase of the system.
BMSは通常、フィールドで高度に構成可能であるため、セキュリティポリシーは、BMSがインストールされている建物のタイプによって最も多くの場合決定されます。特にLLNが外部ネットワークに接続されていない場合、照明またはHVAC制御を設置するシングルテナントオーナーが占有するオフィスビルは、LLNに低レベルのセキュリティを実装する候補です。野心的には、軍事施設または製薬施設には強力なセキュリティポリシーが必要です。セクション3.3および5.2で説明されているインストール手順で述べたように、セキュリティポリシーは、設置フェーズ中に低レベルのセキュリティを可能にする動的構成をサポートする必要があります（建物の占有前、セキュリティの診断レベルのみを使用することが適切な場合）、まだシステムの試運転段階でセキュリティレベルを簡単にネットワークレベルに引き上げることを可能にしています。
LLNs for commercial building applications should always implement and use encrypted packets. However, depending on the state of the LLN, the security keys may either be:
1) a key obtained from a trust center already operable on the LLN;
1)
2) a pre-shared static key as defined by the general contractor or its designee; or
2)
3) a well-known default static key.
3)
Unless a node entering the network had previously received its credentials from the trust center, the entering node will try to solicit the trust center for the network key. If the trust center is accessible, the trust center will MAC-authenticate the entering node and return the security keys. If the trust center is not available, the entering node will check to determine if it has been given a network key by an off-band means and use it to access the network. If no network key has been configured in the device, it will revert to the default network key and enter the network. If neither of these keys were valid, the device would signal via a fault LED.
This approach would allow for independent simplified commissioning, yet centralized authentication. The building owner or building type would then dictate when the trust center would be deployed. In many cases, the trust center need not be deployed until all of the local room commissioning is complete. Yet, at the province of the owner, the trust center may be deployed from the onset, thereby trading installation and commissioning flexibility for tighter security.
Authentication SHOULD be optional on the LLN. Authentication SHOULD be fully configurable on-site. Authentication policy and updates MUST be routable over-the-air. Authentication SHOULD occur upon joining or rejoining a network. However, once authenticated, devices SHOULD NOT need to reauthenticate with any other devices in the LLN. Packets may need authentication at the source and destination nodes; however, packets routed through intermediate hops should not need reauthentication at each hop.
These requirements mean that at least one LLN routing protocol solution specification MUST include support for authentication.
Data encryption of packets MUST be supported by all protocol solution specifications. Support can be provided by use of a network-wide key and/or an application key. The network key would apply to all devices in the LLN. The application key would apply to a subset of devices in the LLN.
The network key and application key would be mutually exclusive. The routing protocol MUST allow routing a packet encrypted with an application key through forwarding devices without requiring each node in the route to have the application key.
The encryption policy MUST support either encryption of the payload only or of the entire packet. Payload-only encryption would eliminate the decryption/re-encryption overhead at every hop, providing more real-time performance.
Due to the limited resources of an LLN, the security policy defined within the LLN MUST be able to differ from that of the rest of the IP network within the facility, yet packets MUST still be able to route to or through the LLN from/to these networks.
The routing protocol MUST gracefully handle routing temporal security updates (e.g., dynamic keys) to sleeping devices on their "awake" cycle to assure that sleeping devices can readily and efficiently access the network.
The requirements placed on the LLN routing protocol in order to provide the correct level of security support are presented in Section 5.8.
LLNs deployed in a building environment may be entirely isolated from other networks, attached to normal IP networks within the building yet physically disjoint from the wider Internet, or connected either directly or through other IP networks to the Internet. Additionally, even where no wired connectivity exists outside of the building, the use of wireless infrastructure within the building means that physical connectivity to the LLN is possible for an attacker.
Therefore, it is important that any routing protocol solution designed to meet the requirements included in this document addresses the security features requirements described in Section 5.8. Implementations of these protocols will be required in the protocol specifications to provide the level of support indicated in Section 5.8, and will be encouraged to make the support flexibly configurable to enable an operator to make a judgment of the level of security that they want to deploy at any time.
As noted in Section 5.8, use/deployment of the different security features is intended to be optional. This means that, although the protocols developed must conform to the requirements specified, the operator is free to determine the level of risk and the trade-offs against performance. An implementation must not make those choices on behalf of the operator by avoiding implementing any mandatory-to-implement security features.
This informational requirements specification introduces no new security concerns.
In addition to the authors, JP. Vasseur, David Culler, Ted Humpal, and Zach Shelby are gratefully acknowledged for their contributions to this document.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[ROLL-TERM] Vasseur, JP., "Terminology in Low power And Lossy Networks", Work in Progress, March 2010.
Appendix A contains additional building requirements that were deemed out of scope for ROLL, yet provided ancillary substance for the reader.
Vendors will likely not develop a separate product line for both wired and wireless networks. Hence, the solutions set forth must support both wired and wireless implementations.
Wireless devices must be supportable unlicensed bands.
Product commissioning must be performed by an application engineer prior to the installation of the IP network (e.g., switches, routers, DHCP, DNS).
Connection-based and connectionless services must be supported.
The network must automatically detect interference and seamlessly switch the channel to improve communication. Channel changes, and the nodes' responses to a given channel change, must occur within 60 seconds.
In building automation, it is required that the network meet the following minimum criteria:
<1% MAC-layer errors on all messages, after no more than three retries;
<0.1% network-layer errors on all messages, after no more than three additional retries;
<0.01% application-layer errors on all messages.
Therefore, application-layer messages will fail no more than once every 100,000 messages.
Subsystems are commissioned by various vendors at various times during building construction. These subnetworks must seamlessly merge into networks and networks must seamlessly merge into internetworks since the end user wants a holistic view of the system.
The routing protocol must allow constrained nodes to hold an abbreviated set of routes. That is, the protocol should not mandate that the node routing tables be exhaustive.
For wireless implementations, the device radios should incorporate automatic transmit power regulation to maximize packet transfer and minimize network interference, regardless of network size or density.
Commercial-building devices must all be periodically scanned to assure that each device is viable and can communicate data and alarm information as needed. Routers should maintain previous packet flow information temporally to minimize overall network overhead.
An effective data rate of 20 kbit/s is the lowest acceptable operational data rate on the network.
To support high-speed code downloads, routing should support transports that provide parallel downloads to targeted devices, yet guarantee packet delivery. In cases where the spatial position of the devices requires multiple hops, the algorithm should recurse through the network until all targeted devices have been serviced. Devices receiving a download may cease normal operation, but upon completion of the download must automatically resume normal operation.
To eliminate high network traffic in power-fail or brown-out conditions, previously established routes should be remembered and invoked prior to establishing new routes for those devices re-entering the network.
Authors' Addresses
Jerry Martocci Johnson Controls Inc. 507 E. Michigan Street Milwaukee, WI 53202 USA Phone: +1 414 524 4010 EMail: jerald.p.martocci@jci.com
Pieter De Mil Ghent University - IBCN G. Crommenlaan 8 bus 201 Ghent 9050 Belgium Phone: +32 9331 4981 Fax: +32 9331 4899 EMail: pieter.demil@intec.ugent.be
Nicolas Riou Schneider Electric Technopole 38TEC T3 37 quai Paul Louis Merlin 38050 Grenoble Cedex 9 France Phone: +33 4 76 57 66 15 EMail: nicolas.riou@fr.schneider-electric.com
Wouter Vermeylen Arts Centre Vooruit Ghent 9000 Belgium EMail: wouter@vooruit.be