iot関連技術の動向 sep-2013

Shoichi Sakane Cisco Systems

IoT関連技術の動向

26-Sep-2013

© 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential Presentation_ID 2

Agenda

§ M2M/IoTに関連する背景 § ユースケース § 技術の標準化動向

§ おわりに

2 2


Agenda

§ M2M/IoTに関連する背景 ü IP技術の優位性 ü M2M/IoTへの期待 ü IoTからIoEへ

§ ユースケース § 技術の標準化動向 § おわりに

3 3


Agenda



4 4

© 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential Presentation_ID 5 NIST Framework and Roadmap for Smart Grid Interoperability Standards, Release 1.0, NIST, Jan 2010

大型発電所

電力取引市場送配電制御通信事業者

需要家送電網配電網

スマートグリッドを構成する様々なシステム（米国）


スマートグリッドの通信システムの要求事項

異なる伝送メディア・リンク技術の相互接続の必要性

The role of standards in the Smart Grid: an IETF view, Fred Baker

§ リンク技術に依存しないアドレス体系 § リンク技術に依存しないメッセージ配送技術

§ リンク技術に依存しないセキュリティ技術 § 多様な伝送メディア・リンク技術の相互接続性

スマートグリッド通信システムの要求事項


IP技術の通信スタック構造

IP

Web, E-Mail, Voice, Video, Management, …

HTTP, CoAP, SNMP, DHCP, DNS, …

TCP, UDP

Ethernet, WiFi, BACnet/IP, PLC, …

UTPケーブル, 光ケーブル, 無線, 電力線, …

各層に・・・ ü アドレス体系 ü メッセージ配送機能 ü セキュリティ機能 ü 選択可能な暗号技術

IP技術の通信スタック（概念図）

ü データリンク技術と完全に分離


§ リンク技術に依存しないセキュリティ技術



柔軟性と拡張性に優れたIP技術

Internet World Map 2007 The ISC Domain Survey

約５０億台（Aug-2010, IMS Research）

(May 2011, World Autonomous System Number Statistics) 222ヶ国, 54459 ASs

AS AS

AS AS

自律分散協調システム（概念図）

§ 多様な伝送メディア・リンク技術が相互に接続。 § 地球規模のスケールで実運用されている。

§ 自律分散システムであり障害に強い。

実証されたIP技術の特性


スマートグリッドの通信システムの要求事項と IP技術の親和性

スマートグリッド通信システムの要求事項



§ リンク技術に依存しないセキュリティ技術

実証されたIP技術の特性

§ 多様な伝送メディア・リンク技術が相互に接続。 § 地球規模のスケールで実運用されている。

§ 自律分散システムであり障害に強い。


スマートグリッドのためのIP技術の選定

§ SGIPの優先行動計画 PAP01 として文書化

§  https://datatracker.ietf.org/doc/rfc6272/

§  Internet Protocols for the Smart Grid

§  RFC6272: スマートグリッドのためのIPアーキテクチャとプロトコルセット IP技術とその基本構成要素アドレッシングの考慮点

パケット配送技術 (OSPF,ISS,BGP,DYMO,OLSR,RPL) トランスポート技術 (TCP,UDP,SCTP,DCCP) インフラ技術 (DNS,DHCP) セキュリティの考察 IPv4/IPv6混在時の注意点 NATやFirewall導入の注意点

PAP01 Smart Power Directorate

リエゾン Fred Baker, Cisco

SGIP: Smart Grid Interoperability Panel


Agenda



11 11


センサーシステムの多様化 Improve Productivity

Enhanced Safety & Security

Predictive Maintenance

High-Confidence Transport and Asset Tracking

Intelligent Buildings

Healthcare Data Center Energy Saving

Improve Food and H2O

Smart Grid

Smart House Smart Community

ソリューションの水平展開への期待


センサー網の多様性と非相互接続性

GW GW GW GW

GW

GW GW GW GW GW GW GW

GW

§  Zigbee, Z-Wave, Xmesh, SmartMesh, MeshScape, … Ø 互換性のないプロトコル Ø 下位から上位層まで１つのスタック Ø 閉鎖的なアーキテクチャ

§  GWの乱立 Ø 開発・導入・メンテナンスコストの増大 Ø スケーラビリティの欠如 Ø 一貫した経路制御が不可能 Ø 本質的に複雑なアーキテクチャになり普及が困難 Ø センシング情報の共有化が困難


センサー網の多様性と非相互接続性

TCP/IP

§  Zigbee, Z-Wave, Xmesh, SmartMesh, MeshScape, … Ø 互換性のないプロトコル Ø 下位から上位層まで１つのスタック Ø 閉鎖的なアーキテクチャ

§  GWの乱立 Ø 開発・導入・メンテナンスコストの増大 Ø スケーラビリティの欠如 Ø 一貫した経路制御が不可能 Ø 本質的に複雑なアーキテクチャになり普及が困難 Ø センシング情報の共有化が困難

センサー網の統合運用への期待


Agenda



15 15


インターネットに接続する「モノ」の量

1995 2011 2020 2000

Source: Cisco IBSG, 2012

2億

500億

毎年1.3倍

毎年1.4倍

毎年2倍?

“Fixed” computing you go to the device

Mobility / BYOD the device goes

with you

Internet of Everything people, process,

data, things

100億

Internet of Things age of devices

センサーの小型化/低価格化

スマートデバイスの普及

クラウドコンピューティングの普及

ソーシャルネットワークの普及


•  人/モノ/データが連携されることによりビジネスプロセスの自動化（自律化）や最適化を実現

•  ビジネスプロセスに沿って、正確な情報が適したタイミングで相応しい人やモノに提供される

インターネットに接続する「モノ」の変化 •  デバイスを通して集積されたデータを解析/処理 •  分散したデータが統合化され、関連付けられることにより、有用

度の高い情報へと昇華 Data （情報）

People （人）

•  スマートフォン、タブレット、PCなどのデバイスを通して各種ネットワークに接続する

•  センシング技術によりデバイスと一体化して情報発信

•  物理的なモノがインターネットに相互接続 •  従来に比べて、より自律敵なデータ収集/蓄積/発信を実現 •  モノの情報が相互に関連し、より価値のある情報へと変換

Things （モノ）

Process （プロセス）

情報の有機的な連携が重要になる。


M2M/IoTからIoEへ

People

Things Data

Process

People to People(P2P)

Machine to People(M2P)

Machine to Machine(M2M)

Internet of Everythingの考え方

現在、世の中の99.4%のモノはインターネットにつながっていない

Internet Of Everything により…

【近い将来】 •  モノだけでなく人、プロセス、データのイン

テリジェントな連携が実現される。

•  膨大な情報から適切なアクションを即時に導き出すことにより、個人/企業/国家の

新たなケイパビリティ(できること)の創造、従来にない価値が創出される。

Point： Internet of Things（IoT）をベースに、ネットワークインテリジェンスを高めることにより、異なるシステム内の情報を有機的に連携させる。


M2M/IoTに関連する背景：まとめ

§  IP技術の優位性 Ø リンク技術に依存しない

アドレス体系・メッセージ配送技術・セキュリティ技術 Ø 多様な伝送メディア・リンク技術との親和性 Ø 自律分散システムによる高い耐障害性 Ø 地球規模のスケールでの運用実績

§ M2M/IoTへの期待 Ø ソリューションの水平展開 Ø センサー網の統合運用

§ M2M/IoTからIoEへ Ø 人・モノ・データ・プロセスを結合させることで、ネットワークのインテ

リジェンスを高め、異なるシステム内の情報を有機的に連携させる。 Ø 個人/企業/国家の新たなCapability(できること)を創造・創出するこ

とができる。


Agenda

§ M2M/IoTに関連する背景 § ユースケース § 技術の標準化動向 § おわりに

20 20


Agenda

§ M2M/IoTに関連する背景 § ユースケース

ü 産業分野 ü 標準技術 ü 普及促進

§ 技術の標準化動向 § おわりに

21 21


Trains

Public Safety

Rail

Bus Fleets

Save lives and reduce emergency services’ response times

AMBULANCE ER UNIT

VITAL STATS AND MEDICAL

RECORDS SENT AHEAD

Intelligent Transportation System


Recloser Control

Transformer Meter

Feeder Meter

Smart Meters

920MHz mesh

920MHz mesh

920MHz帯無線技術を利用した電力設備管理

WiFi技術を利用した工場内設備管理

WiFiやWPANを利活用した無線システム


ガラスメーカー　米国 •  ガラスキャリアーの位置を無線タグと無線LAN環境を利用しト

ラッキング。探索時間を15分から1分に削減。

myTECHNIC, トルコ •  高額な工具・部品、作業者をトラッキング。航空機メンテナンス

作業をより迅速に効率的に実行。作業の遅延を回避。

海洋石油ガスプラットフォーム, メキシコ •  石油プラットフォームに隣接する洋上ホテルにいる作業者、訪

問者をトラッキング。転倒・転落など異常の検知、動線調査

製薬メーカー, ヨーロッパ •  工場で働く従業員の転倒・転落など異常の検知にモーションセ

ンサーを利用。

その他 •  金型メーカー、タイヤメーカー、鉱山、・・・

製造業における位置情報利活用システム


自動車配送センター, チリ •  工場から出た完成車にタグを添付し、アクセサリを装着する

際のミスや遅れを抑制。

DHL/Microlise, ヨーロッパ •  ヨーロッパに搬送する医薬品の温度をリアルタイムに監視

し、規定温度範囲を超えることによる廃棄を減らす。

CityLink, イギリス •  大容量バッテリー付き堅牢タグをかご車に貼付、デポセン

ター毎のかご車利用率を平準化し、翌日配送サービスの遅れを最小化。

APS, 米国 •  クロスドック倉庫でトラクター、コンテナにタグを添付、ス

ループット増大、無駄な作業時間・使用燃料の量を抑制

コンテナ・ターミナル, 韓国 •  コンテナクレーン、トランスファークレーン、ヤードトラクター

を追跡、港湾でのコンテナ処理にかかる生産性を向上。

物流における位置情報利活用システム

© 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential Presentation_ID 26 スマートグリッド教科書, インプレスジャパン

大型発電所

電力取引市場

送電網

送配電制御通信事業者

需要家

FAN WAN

HAN

インターネットインターネット

制御所間通信ネットワーク

配電網

スマートグリッドを構成する様々なシステム（米国）

© 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential Presentation_ID 27 スマートグリッド概念図, 次世代エネルギーシステムに係る国際標準化に向けて 2010年1月

大型発電所

送配電制御

通信事業者

需要家

送電網

配電網

スマートグリッドを構成する様々なシステム（日本）


§ 変電所システムにおけるIEDのための通信規格

§ 機能を抽象化し、通信プロトコルが変わっても対応可能

例: IEC 61850

スマートグリッドに係わる情報・通信の国際標準化動向, JPNC, Mar 2011

IEC61850を適用した変電所自動化システムの例

プロトコルスタック概略

TCP UDP IP

IP技術を活用した様々な標準技術

IED: Intelligent Electric Device （ディジタル化に対応した装置）


§ フランスのスマートグリッド用のPLC（電力線搬送通信）の規格

§  IP技術を活用して、様々なトポロジに対応可能。

IP技術を活用した様々な標準技術例: G3-PLC, IEEE P1901.2

G3-PLC Profile, http://www.maxim-ic.com/products/powerline/g3-plc/

MAC

PHY

Ada

ptat

ion

NET

Header Compression

Fragment Recovery

LOAD Routing

Forwarding Bootstrap

EAP Security

TRN

APP COSEM TFTP SNMP

UDP

IPv6

Tone Map Query Neighbor Table

PSK/OFDM FEC Tone Map

802.15.4-2006


例: OpenHAN § スマートハウスを実現する技術として OpenSGにて検討中。

§ エネルギー管理プロトコル ZigBee SEP2.0 を採用。

§  IETFと積極的にリエゾンし、IP技術を最大限活用している。


需要家

プロトコルスタック概略 UCAIug (Utility Communication Architecture International Users Group)

IEEE 802.15.4 MAC/PHY

6LoWPAN Adaption Layer

Network Layer IPv6, ICMPv6, 6LP-ND

Routing RPL

mDNS PANA MLE TLS

Sec

urity

Applications; e.g., SEP 2.0


Facility A

Facility B

例: IEEE 1888 （FIAP or UGGCCNet） § グリーンICT技術の社会インフラ化を目指して設計・開発

§ 日本と中国の産学が協力して標準化を進めている。

§  ISO/IEC TC1/SC6/WG7 in progress


XML / HTML


§  Established since 1990. Ø  Board: ABB, Emerson, E&H, Honeywell, Simens Ø Members: world wide 230~ companies.

§  Mission: to standardize and to deploy the HART protocol.

§  HART Ø C/S communication by HART command over 4-20mA line.

§  WirelessHART Ø  Published in 2007, the HART7 including wireless communicaiton Ø  IEC 62591


WirelessHART


§  Goal: to standardize the specification ISA100.11a for the device communication technology in the wireless automation system.

§  802.15.4-based for non critical automation system Ø  Partially similar to 802.15.4e (backported from .11a) Ø  Process monitoring and control (latency is about 100ms)

§  ISA100.11a-2011 is approved in IEC as PAS/NP. §  Key of ISA100.11a

Ø widely applicable Ø  robustness & scalability Ø  simple installation Ø  convergence Ø  interoperability Ø world wide usable

Application Class Timeliness Safty Class0: Emergency action Control Class1: Closed loop regulatory control

Class2: Closed loop supervisory control Class3: Open loop control

Monitoring Class4: Alerting Class5: Logging and downloading / uploading

ISA100 Application Class

High

Low


ISA100.11a


モノへのIP技術普及推進活動 IPSO §  Alliance established in September, 2008

à 59 members (Nov 2012) Ø  Chairman: Geoff Mulligan (Proto6) Ø  President: Pete St. Perre (Oracle) Ø  Vice-President: Patrick Wetterwald (Cisco) Ø  TAB Chair: Jari Akko (Ericsson)

§  Mission ü  Smart Object（モノ）へのIPの応用の推進活動 ü  技術普及・教育活動やユースケースの紹介 ü  IETF等の他標準化組織の活動サポート ü  相互接続試験の主催

http://ipso-alliance.org/resource-library

§  Formal Liaison ETSI

IPv6 Forum

Zigbee Alliance

§ On-Going Activities o  Interoperability Testing

o Tutorials, Webinars


IPSO Plugfest at IETF84

§  Nivis (http://www.nivis.com/products/product.php?pID=11) Ø  6lowpan,ipv6,rpl,coapスタックを1チップ化。 Ø  freescale RFモジュールにadd-onしている。 Ø  日本の技適取得は現在進行中。 10月にプレスリリース予定。

§  Proto6 + colorado micro Ø  10円玉ほどのデバイスとbeagleboneで作るネットワークのデモ Ø  core + IPv6 + 6lowpan + L2メッシュ Ø  10円玉デバイスは Colorado Microと言っていた。

§  NOKIA Ø  TI cc2540ベースの bluetooth heart beat sensor Ø  coap + udp + ipv6 + 6lowpan + bluetooth Ø  APにbluetooth USBドングルを挿してデータを受ける。 Ø  APにてbluetooth to ethernet変換してロンドンのDCへ転送する。 Ø  coap/httpはロンドンのDCにてやる。

§  Sensinode (http://www.sensinode.com/) Ø  coap関連スタック開発 link formatを使ったregistration&management GUIを見せていた。 Ø  plugfestにあるデバイスは、ここにregistrationしていて、GUIから制御できる。

§  NXP / jennic (http://www.jennic.com/products/protocol_stacks/jennet-ip)


IPSO Demo: Bits-N-Bites in IETF85

§  L+G: FOCUS RXR-SD

§ Nivis+Freescale Ø TWR-METRO-KIT-NA

§ Sensinode

§ Proto6


ユースケース：まとめ

§ 産業分野、特にICT、スマートグリッド、工場の分野で IP技術を利活用したシステムの事例紹介。

§  IP技術を利活用した標準技術の紹介。 Ø スマートグリッドを中心に標準化が進んでいる。 Ø 無線技術を利活用したシステムが多い。

§ 普及促進 Ø  IPSO：モノをインターネットにつなぐための技術を普及する団体


Agenda

§ M2M/IoTに関連する背景 § ユースケース § 技術の標準化動向

ü 対象エリア ü IETFにおける動向 ü 技術概要

§ おわりに

38 38


Data Center Cloud Application Hosting, Management, IoT Analytics

Core Networking IP/MPLS, QoS, Multicast, Security

Multi-Service Edge 3G, 4G, LTE, WiMAX, WiFi Ethernet

Embedded Systems and Sensors Low power & bandwidth, Machines Wired or Wireless

Network Management Applications

本日の対象エリア：アーキテクチャ視点 M2M/IoTアーキテクチャ例, Fog Computing, Cisco

Here !!


本日の対象エリア：システム視点

スマートグリッド概念図, 次世代エネルギーシステムに係る国際標準化に向けて 2010年1月

大型発電所

送配電網

送配電制御

分散型電源

通信事業者

需要家

FAN

FAN

FAN

FAN

FAN


本日の対象エリア：システム視点

スマートグリッド概念図, 次世代エネルギーシステムに係る国際標準化に向けて 2010年1月

大型発電所

送配電網

送配電制御

分散型電源

通信事業者

需要家

FAN

FAN

FAN

FAN

FAN

様々な呼び方があるが、ここではFANと呼ぶ。

WiMAX

SUN WiFi

2G/3G

Ethernet

FAN

etc.


本日の対象エリア：標準化団体視点

Health care

Transporta/on Energy Automo/ve Industrial automa/on M2M

Applica/ons

SP Networks (Access + Core)

Gateway Layer

M2M Area Network

Meters Robots Appliances Sensors Medical monitors

Handsets

Data Models

M2M PlaJorm

IETF 6LoWPAN, Roll, CoRE

Zigbee Alliance KNX ZWave

ETSI ANSI

CEN

CENELEC

DLMS

IEC

TISPAN 3GPP 3GPP2

ETSI

Devices

ETSI GSMA

GSMA

Management

Agriculture

OSI

SNIA

CMWG

TMF

OMA

CMWG

oneM2M

oneM2M

oneM2M

API

IEEE


IP技術の策定過程と相互接続性

§  ＩＥＴＦ Ø インターネット技術全般の標準化を行う組織。 Ø 策定した技術はRFCとして発行され、誰でも自由に参照できる。 Ø 会社や国の代表としてではなく原則として個人で参加する。 Ø ８エリア、１２４WG

§ 仕様は全てオープン Ø 全ての議論や文書が公開されている。 Ø 誰でも自由に議論に参加でき文書を発行できる。

§ 動作実績のある仕様と相互接続性が最も重要 “We reject kings, presidents and voting. We believe in rough consensus and running code”, Dave Clark (1992)

www.ietf.org


最近は”Constrained Node”が主流か？

センサー網におけるIP技術の主な5つの課題 § 動作条件の厳しい通信機器の存在

Ø 省電力 Ø 物理的サイズ（5mm〜） Ø 低CPU性能（8 or 16-bit, 低クロック 8~16MHz） Ø 少ないメモリ（~128 KB） Ø スリープモード

新しいリンクに対応する技術の標準化

LLN向け汎用アプリケーションプロトコルの標準化

耐障害性経路制御プロトコルの標準化

Challenge Areas

これらの特徴を持つネットワークをIETFでは “LLN” （Low power and Lossy Network）低消費電力＆高パケット損失ネットワーク

と呼んでいる

LLN向け機器の実装ガイド

これらの特徴を持つ機器をIETFでは “Smart Object” と呼んでいる

LLN向け機器管理・セキュリティ技術の標準化

§ 通信条件の厳しいネットワークの存在 Ø 多数のノード（〜数千ノード） Ø 低通信帯域（〜250kbps） Ø 高パケット損失性

Ø 厳しい動作環境条件


3G Bluetooth DECT etc.

IoT/M2Mに関するIETFの動向

Z-Wave Zigbee IP

Low Power WiFi PLC LoWPAN

Zigbee/HomePlug, Autumn 2008

OpenSG/UCAlug, Summer 2009

IEEE802.15.4-2003, Autumn 2003

Zigbee & WiFi collaboration,

Sprint 2010

SmartGrid Bar-BoF, IETF77, Oct 2009

EISA ACT, 2007

IoT Bar-BoF, IETF79, Jul 2010

Cross Layers Issues BoF

IETF82, Nov 2011


3G Bluetooth DECT etc.

IoT/M2Mに関するIETFの動向

Z-Wave Zigbee IP

Low Power WiFi PLC LoWPAN

lwig: Lightweight Impl. Guidance WG

IETF80, Mar 2011

roll: Low power and Lossy Networks WG

IETF71, Mar 2008 core: Constrained RESTful Envinronments WG

IETF76, Nov 2009

solace: SO Lifecycle Architecture for Constrained Envinronments BoF

IETF85, Mar 2012

coman: Constrained Networks and Devices Managemnet BoF

IETF85, Nov 2012





6lowpan: IPv6 over LoWPAN WG

IETF61, Nov 2004


6lo: IPv6 over Foo BoF IETF87, Jul 2013

6tsch: IPv6 Time Synchronization and Channel

Hopping BoF IETF87, Mar 2013

dice: DTLS In Constrained Environments BoF

IETF87, Jul 2013

Smart Objects Workshop IETF80, Mar 2011

Smart Object Security Workshop IETF83, Mar 2012

Zigbee/HomePlug, Autumn 2008

OpenSG/UCAlug, Summer 2009

IEEE802.15.4-2003, Autumn 2003

Zigbee & WiFi collaboration,

Sprint 2010

SmartGrid Bar-BoF, IETF77, Oct 2009

EISA ACT, 2007

IoT Bar-BoF, IETF79, Jul 2010

Cross Layers Issues BoF

IETF82, Nov 2011


“6lowpan” WG and 6LoWPAN §  IPv6 over Low power

Wireless Personal Area Networks §  Internet Area

Co-chairs: Ø Carsten Borman (Bremen Univ.) Ø Geoff Mulligan (Consultant)

§ Mission & Status Ø  IEEE 802.15.4-basedネットワークに対する、

IPv6 Adaptation Layerの策定とIPv6仕様の拡張 Ø ほぼ一通りの作業が完了している。 Ø  “6lo” に引き継がれることが検討されている。




Challenge Areas




What are “6LoWPAN” protocols ? §  802.15.4ベースのL2リンクとTCP/IP技術のギャップを埋める。

Ø 当初は、802.15.4-2006が対象だった。 Ø 現在は、IEEE P1901.2や IEEE 802.15.1等への応用も検討中。

§ What’s new ? Ø Fragmentation and Reassembly Ø  IPv6 Header compression

ü  スタック全体で冗長なフィールドを削除ヘッダーチェーンChained header by a dispatch field.

リンクヘッダから取れる情報 e.g. EUI-61

ネットワークの設定から読み取れるもの e.g. prefix, version

Ø ND Optimization ü  multicast packet の抑制 ü  L2網の情報の伝達

border routerのアドレス header comporessのための情報

IEEE802.15.4 IPv6

Ø 127B frame size. Ø Data Rate: 20~250Kbps Ø Maximize battery life.

Ø 40B Header (Min.) Ø 1280B MTU. Ø ND in multicast.

6LR 6LR

6LR

6LR

6LN 6LN 6LN 6LN

6LBR


127 bytes IEEE802.15.4 最大フレームサイズ 127(B)

102 bytes 最大25(B)

81 bytes IEEE802.15.4 セキュリティヘッダ

IPv6 Header Compression IPv6 Payload

Fragment Header

IPv6 Header Compression IPv6 Payload

Fragment Header

IPv6 Header Compression

Mesh Header IPv6 Payload

IPv6 Header Compression

Mesh Header IPv6 Payload

最大21(B)

IEEE802.15.4 ヘッダ

6lowpan: Fragment/Mesh Header

§  IPv6 HC Ø 常に存在する。

§  Fragment Header Ø 81バイトに収まらない

場合に使用する。

§ Mesh Header Ø L2ルーティングする

場合に使用する。


6lowpan: Header Compression

Best case: (6 bytes)

Multicast: 16 bytes

Multiple IP Hops Full IPv6 Address, Compressed UDP ports e.g 2001:0db8:cafe:cafe:0217:3B00:1111:2222 -> 2001:0db8:beef:beef: :68

DSP + LoWPAN_IPHC

(2 bytes)

LoWPAN_NHC (1 byte)

UDP ports (4 bits SRC, 4 bits DST)

(1 byte)

DSP + LoWPAN_IPHC

(2 bytes)

Hop Limit (1 byte)

Source Address

(16 bytes)

Destination Address

(16 bytes)

LoWPAN_NHC (1 byte)

UDP ports SRC & DST

(4 bytes)

UDP Checksum (2 bytes)

DSP + LoWPAN_IPHC

(2 bytes)

Hop Limit (1 byte)

Destination Multicast Address (6 bytes)

LoWPAN_NHC (1 byte)

UDP ports SRC & DST

(4 bytes)

UDP Checksum (2 bytes)

Link local addresses + Compressed IPv6/UDP header e.g. FE80::0217:3B00:1111:2222 -> FE80::0217:3B00:3333:4444

Multicast Address Compression, Compressed UDP ports e.g. FE80::0217:3B00:1111:2222 -> FFxx::00xx:xxxx:xxxx


6lowpan: ND Message Exchange

§  3つのIPv6 ND optionと、2つのICMPv6 typeを定義 §  6LRから、6lowpan context (6CO), Authoritative Border Router (ABRO)を通知。 §  6LRから、Address Registration (ARO)を使用した6LBRへの登録とDADの実施。 §  DA Request/Confirmationを使用した、6LBRでのDADの実施。

RS: SLLAO

RA: PIO+SLLAO+6CO+ABRO

NS: ARO+SLLAO

NA: ARO Response

DAR (ARO+SLLAO)

DAC (ARO+SLLAO)

6LR 6LBR 6LN

NS: ARO+SLLAO Lifetime Expired

self-assigned LLA

default route, prefix,

contexts,


6lowpan: Document Status

§ RFC 4919: Problem Statement, and Goals

§ RFC 4944: Transmission of IPv6 Packets

§ RFC 6282: Compression Format

§ RFC 6568: Design and Application Spaces

§ RFC 6775: 6lowpan Neighbor Discovery


IPv6 over networks of resource constrained nodes (6lo) BoF §  Co-chairs

Ø  Ralph Droms (Cisco) Ø  Ulrich Herberg (Fujitsu Lab.)

§  Background Ø  様々なLLNでIPv6が使われようとしている。 Ø  6lowpan WGで802.15.4ベースリンクの

適合層を定義(RFC4944/6282)した。 Ø  WGがクロージング・フェイズになっている。

§  Problem Ø  IPv6 over fooの提案が増えているが受け皿がない。

ü  e.g. BT, G.9959(subset of Z-Wave), DECT ULE, RS485

Ø  SO管理のMIB(e.g. 6lowpan MIB) が未定義。 Ø  6lowpan-HCはプロトコル毎に定義されている。 Ø  LLN boot-strappingが未定義。




Challenge Areas




6lo: proposals, but no home.

§  MIB Ø  draft-schoenw-6lowpan-mib

§  Header Compression Ø  Basis: RFC6282 (aka. 6LoWPAN-HC) Ø  draft-bormann-6lowpan-ghc (LZ77-based) Ø  draft-raza-6lowpan-ipsec-00 (IPcomp)

§  Setting up LLNs Ø  Basis: RFC6775 (aka. 6LoWPAN-ND) Ø  draft-kelsey-intarea-mesh-link-establishment

ü  cover gaps b/w 802.15.4 MAC, 6LoWPAN-ND and RPL

Ø  draft-thubert-6lowpan-backbone-router ü  make multiple edge routers act as one

Ø  draft-thubert-roll-forwarding-frags ü  optimize fragment retransmission


6lo: the scope and out-of-scope

§  scope Ø  INT Areaに関係する項目 Ø 可能であれば既存のプロトコルを再利用する。

§  out of scope Ø no larger cross-layer efforts (e.g. 6tcsh work under discussion) Ø 不特定リンクに対するセキュリティや管理は対象外とする。 Ø ルーティングは対象外とする。(àroll WG)

チャーターを明確にすべき “IPv6 over foo” is unclear. should clarify it. e.g. 6lowpan over new type of L2 and how nd and hc apply to


IPv6 over the TSCH mode of IEEE 802.15.4e (6tsch) BoF §  Co-chairs

Ø  Pascal Thubert (Cisco) Ø  Thomas Watteyne (Linear Technology)

§  Background Ø  IEEE802.15.4e-2012: TSCH mode

ü  low-power operation by synchronizing nodes

ü  high reliability by channel hopping

Ø  Allowing deterministic behavior. ü  flow isolation

ü  traffic engineering

ü  predictable power consumption

Ø  産業用ネットワーク用途で期待されている。 ü  IEEE 802.1TSN, ISA100.20, IoT6




Challenge Areas



Time Synchronized Channel Hopping


6tsch: the problem and work items §  Route and track computation, installation

Ø  Time slot scheduling and bandwidth allocation by PCE.

Ø  Flow label for RPL domain (6man WG)

Ø  Centralized: PCEP over UDP/CoAP (pce WG)

Ø  Distributed: RPL, RSVP

§  Management and setup, discovery, pub/sub (CoAP/DTLS)

§  Key distribution and Authentication for network access (PANA)

§  Network formation

Ø  Architecture definition

Ø  Initial Configuration: Time sources, Join priority

Ø  Data flow control: Queue length, Priority, Retransmission Control

Ø  Efficient ND aka. WiND (6man WG)

§  Backbone integration (6lo) Ø  6LoWPAN-ND

Ø  Backbone router

Ø  Fragment forwarding and recovery


“roll” WG and RPL

§ Routing Over Low power and Lossy networks

§ Routing Area Co-chairs: Ø  JP Vasseur (Cisco) Ø Michael Richardson (Consultant)

§ Mission & Status Ø  LLNの経路制御に関する技術の策定 Ø  現在は、RPLの策定がひとまず完了した。




Challenge Areas




roll: Why do we want a new protocol ?

§  Table scalability: how does the routing table size scale? Ø  Fail: Table scales with O(N) or O(L) - Scaling with O(D) can pass

§  Loss response: how expensive is it when links come and go? Ø  Fail: Loss response scales with O(N) - Scaling with O(1) or O(D) can pass

§  Control cost: how does the control overhead scale? Ø  Fail: Control traffic is unbounded inrelation to data rate (e.g., fixed beacon time - Bounded or tied

to data traffic passes

§  Link cost: can the protocol consider link properties? Ø  Fail: Protocol has no way to distinguishlink costs (e.g., only hopcount) - Supporting link metrics

passes.

§  Node cost: can the protocol consider node properties? Ø  Fail: Protocol has no way to distinguishnode properties. - Supporting node properties passes.

Name Table(Size Loss(Response Control(Cost Link(Cost Node(CostOSPF fail fail fail pass failOLSRv2 fail fail fail pass passTBRPF fail pass fail pass unclearRIP fail fail fail unclear failAODV pass unclear pass fail failDSDV fail fail fail unclear failDYMO pass fail pass fail failDSR fail unclear pass fail unclear


DODAG: Destination Oriented Directed Acyclic Graph

roll: What is “RPL” ?

§ 多様なLLN向けアプリケーションの要求を元に設計 Ø Urban, Industrial, Home Automation, Building Automation.

ü  à MP2P, P2MP and P2P

§ 物理的に同じリンク上に複数のツリーを構築可能 à 異なるのアプリケーションの要求に応じた最適なパスを構築できる。

§ DODAGを構築する複数のメトリックを指定可能。 Ø  メトリック: node state, energy, hop-count, throughput, link reliability

§  LLN向けのパス構築機構 Ø 近隣状態に応じて制御情報の送出間隔を変化させる。

!Trickle Timer Ø メモリが少ないノードがパケットを転送できるモードがある。

!Non-Storing Mode!

Ø 2つのパス再構築機構 ü  Global Repair : 全体を再構築する機構 e.g. DODAGのメトリックが変わった場合等 ü  Local Repair : 部分的に自動修復する機構 e.g. リンクの状態が変化した場合等

Routing over low Power Lossy networks: ripple [rípl]


roll: Path Construction by RPL

§  ICMPv6 type (155): RPL Control Messages ü  DIS / DIO for MP2P

ü  DAO / DAO-ACK for P2MP ü  DIO+RDO / DRO+RDO / DRO-ACK for P2P

§  2 IPv6 Extensions Ø  RPL SRH in Routing Header: transmission b/w RPL routers.

Ø  RPL Option for HbH Options Header: exchaning RPL information b/w RPL routers.

§  ICMPv6 Destination Unreachable Ø  Code (7) Error in Source Routing Header

MP2P P2MP P2P

Host

Router

Root

Traffic

Path

DIS: DODAG Information Solicitation DIO: DODAG Information Object DAO: Destination Advertisement Object DRO: Discovery Reply Object RDO: Route Discovery Option


roll: RPL Routing Metrics

Node Metrics Link Metrics

Node State and Attributes Object Purpose is to reflects node workload

(e.g. CPU, Memory…) “O” flag signals overload of resource “A” flag signal node can act as traffic

aggregator

Throughput Object Currently available throughput

(Bytes per second) Throughput range supported

Node Energy Object “T” flag: Node type:

0 = Mains, 1 = Battery, 2 = Scavenger “I” bit: Use node type as a constraint

(include/exclude) “E” flag: Estimated energy remaining

Latency Can be used as a metric or constraint Constraint - max latency allowable on path Metric - additive metric updated along path

Hop Count Object Can be used as a metric or constraint Constraint - max number of hops that can be

traversed Metric - total number of hops traversed

Link Reliability Link Quality Level Reliability (LQL)

0=Unknown, 1=High, 2=Medium, 3=Low Expected Transmission Count (ETX)

(Average number of TX to deliver a packet)

Link Colour Metric or constraint, arbitrary admin value


roll: RPL path construction (IMAGE)

Root 0

Root 1

App 1: Sensor Data Collection Metric: ocp1 = Best link quality (ETX)

Metric based parent selection Metric: ocp1 = Best link quality

1 hop, ETX = 5 3 hops, ETX = 3

Constraint-based routing e.g. avoid wireless links à Find alternative path

App 2: backbone monitoring Metric: ocp2 = min rank (hopcount) +

constraint-based routing 5 1

1

1 1

1

1 1

1

1

1

3

3 2

3 3

3 3

3

3

7

wired link wireless link ETX value on link n

A

B

D

C

E


roll: Document Status §  RFCs and Significant Documents

Ø  RFC 5548, 5673, 5826, 5867: Requirement for Urban, IA, HA, BA Ø  RFC 6206: Trickle Algorithm Ø  RFC 6550: RPL Core Spec Ø  RFC 6551: Routing Metrics Ø  RFC 6552: Objective Function Zero Ø  RFC 6553: IPv6 Hop-by-Hop Option for RPL Ø  RFC 6554: IPv6 Routing Header Option for RPL

§  Reactive Discovery of Point-to-Point Routes in LLN Ø  IESG evaluation was done. Ø  approved by IESG as Experimental RFC. (30-Mar-2013)

§  Trickle Multicast Ø  IPR claim filed, Nokia Corporation Ø  WG Last Call ended. (30-Mar-2013)


roll: Document Status, cont. §  p2p-measurements

Ø  approved by IESG as Experimental RFC. (04-Apr-2013) Ø  now in Editor queue.

§  Terminology Ø  AD evaluation was done, revised id needed. Ø  IETF Last Call ended. (30-Mar-2013)

§  Security Threat Analysis Ø  IETF Last Call ended (21-Jan-2013) Ø  draft-ietf-roll-security-threats-01 was published. (25-Feb-2013)

§  Applicability Ø  Industrial, home and building app. are WG adopted. Ø  Metering applicbility statement has gone AWOL ?


“core” WG and CoAP

§ Constrained RESTful Environment §  Application Area

Co-chairs Ø  Carsten Borman (Bremen Univ) Ø  Andrew McGregor (Allied Telesis)

§ Mission Ø LLN向けアプリケーションのフレームワークの策定 Ø 現在は、CoAPの策定に注力している。




Challenge Areas




CoAP Packet Example

core: What is “CoAP” ?

§ Constrained Application Protocol Ø  A UDP-based Specialized Web Transfer Protocol

for M2M Applications

§  2つのレイヤを定義 Ø  Message Layer Ø  Requests/Responses Layer

§ Message Layer Ø  UDP port #5683 Ø  Simple small header < 10B Ø  Retransmission Ø  Asynchronous Message Exchange Ø  Block-wise transfer Ø  Multicast Ø  Caching Ø  Observation

Protocol Stack Image

Application

Requests /Responses

Messages

UDP

CoAP

Message Type Operation

Confirmable CON receiver is requested to make a response

Acknowledgement ACK response to CON

Non-confirmable NON receiver is not requested any action

Reset RST reset the receiver’s state.

CoAP Message Type


core: What is “CoAP” ?, cont. § Requests/Responses Layer

Ø  RESTful protocol Ø  URI and Content-Type Support Ø  Proxy and Caching Ø  A stateless HTTP mapping Ø  HTTP compatible response code

Protocol Stack Image

Application

Requests /Responses

Messages

UDP

CoAP

method operation

GET to retrieve a representation of the resource, no change.

POST usually to create or update a resource. the behavior depends on the server.

PUT to update or create a resource by the indicated representation.

DELETE to delete a resource.


core: Resource Discovery

§ Well Known Interface Ø  /.well-known/core{?search*} Ø  /.well-known/core?/href=/foo*

§ Link-Format Ø Discovery Ø Collections Ø Directory

e.g. REQUEST:

GET /.well-known/core RESPONSE:

2.05 Content </sensors>;ct=40;title="Sensor Index", </sensors/temp>;rt="temperature-c";if="sensor", </sensors/light>;rt="light-lux";if="sensor", <http://www.example.com/sensors/t123>;anchor="/sensors/temp”;rel="describedby", </t>;anchor="/sensors/temp";rel="alternate”

Attribute Description

ct Content-Format of the resource.

rt Resource Type to assign an application specific semantic type.

if Interface name or URI to interact with the target resource.

sz Maximum Size of the resource representation.

Link Format Attribute


core: CoAP message exchange (1/3)

§ Confirmable Request and Piggy-backed Response

§ Non-confirmable message

TCP 3-way handshake

HTTP GET /temperature

HTTP 200 OK 25.3

TCP 2-way termination

cf. HTTP

CoAP CON GET /temperature

CoAP ACK 200 OK 25.3

CoAP

CoAP NON PUT /temperature



§ Confirmable Request and Separate Response (Asynchronous Message Exchange)

MID: メッセージの対応を示すToken: セッションを示す

Header: GET T=CON Code=1 MID=0x7d38 Token: 0x53 Uri-Path: “temperature”

Header: T=ACK Code=0 MID=0x7d38

Header: 2.05 Content T=CON Code=69 MID=0x2d7b Token: 0x53 Payload: “22.5C”

Header: T=ACK Code=0 MID=0x2d7b

1

1

2

2

GET /Temperature

ACK

Client

22.5C

ACK

Server

1

2


Cache: 418kWh Age: 15min


§ Proxy and HTTP Mapping

CON GET /Electricity

CoAP-HTTP Proxy GW

ACK 200 OK 418kWh Max-Age: 15min

CoAP Server

HTTP GET /Electricity

HTTP 200 OK 418kWh

HTTP Device

HTTP GET /Electricity

HTTP 200 OK 418kWh

Cache: 418kWh Age: 9min


core: Authorization

§  AAA for core ? Ø  Accounting is out of scope. Ø  Authentication by DTLS. Ø  Authorization ?

§  CoAP for information transfer.

§  Defines the data structure and usage.

§  draft-selander-core-access-control-00 Ø  Assertion transfer (XACML-SAML, 2 ways: CoAP or DTLS) Ø  Message protection, alternative way to communication security

ü  i.e. object security

Ø  implementation (http://soda.swedish-ict.se/5523/)

§  draft-gerdes-core-dcaf-authorize-00 Ø  Delegated CoAP Authorization Framework Protocol Ø  Similar to Kerberos, but TLSàDTLS, ASN.1àJSON

AS for C

AS for RS

C RS

DTLS DTLS

TLS or DTLS

DTLS


core: HTTP-CoAP Mapping

§  Best Practices for HTTP-CoAP Mapping Implementation Ø  for making implementations interoperable. Ø  draft-castellani-core-advanced-http-mapping-0702 Ø  HTTP to CoAP URI mapping for reverse proxy. Ø  added requirements, proposals, comparison matrix.

e.g. Solution #2 /.well-known/core-translate/{authority-encoded}/{path}?{query}

http://proxy.example.com/.well-known/core-translate/server.coap.example.com:4567/foo/bar?a=3 à coap://server.coap.example.com:4567/foo/bar?a=3 e.g. Solution #5

/.well-known/core-translate/{scheme}/{+host}/{port}/{+path}/{+query} http://proxy.example.com/.well-known/core-translate/coap/server.coap.example.com/4567/foo%2Fbar/a=3 à coap://server.coap.example.com:4567/foo/bar?a=3


core: RD & CoRE Interfaces

§ Resource directory Ø draft-shelbyietf-core-resource-directory-0500 Ø Define an interface for registration, update, and de-registration. Ø OMA Lightweight M2M standard.

ü  In traffic monitoring systems. ü  In street lighting systems. ü  For vehicular asset tracking. ü  By a major cellular M2M operator.

§ CoRE Interfaces Ø draft-shelbyietf-core-interfaces-0500 Ø well-known REST I/F description for typical IoT applications.

ü  Read, Write, Monitoring, Actuation, Constrained web services

End Point

End Point

Client

Client

Registration

Lookup

RD

Interface Link Format Methods

Link List if=core.ll GET

Sensor if=core.s GET

Actuator if=core.a GET,PUT,POST

Function Root Interface

Descriptions /d if=core.ll

Sensors /s if=core.s

Actuators /a if=core.a

Function Set Example Interface Example


core: Document Status

§  RFC 6690: CoRE Link Format

§  Constrained Application Protocol Ø  CoAP core specification Ø  draft-ietf-core-coap-18 Ø  [MISSREF] in RFC Editor Queue

ü  AES-CCM-ECC [AD Eval], OOB-PUBKEY [tls WG]

§  Blockwise transfers in CoAP Ø  Fragment/reassemble support Ø  draft-ietf-core-block-12 Ø  WG draft in progress.

§  Observing Resources in CoAP Ø  RESTful Pub/Sub support Ø  draft-ietf-core-observe-08 Ø  WG draft in progress.


“lwig” WG

§  Light Weight Implementation Guidance

§  Internet Area Co-chairs: Ø  Zhen Cao (China Mobile) Ø  Robert Cragie (consultant)

§ Mission Ø 組込み機器向けのTCP/IPスタック実装

ガイダンスの作成

リファレンスモデル

Data Size (e.g. RAM) Code Size (e.g. Flash)

Class 1 ~ 10KB ~ 100KB

Class 2 ~ 50KB ~ 250KB




Challenge Areas




“dice” BoF

§  DTLS In Constrained Environments

§  Co-chairs Ø  Zach Shelby (ARM 元Sensinode) Ø  Carsten Bormann (Bremen Univ.)

§  Background Ø  CoAPのセキュリティメカニズムとして

DTLS v1.2が選択されている。

§  Problem

Constrained Deviceに対して・・・ Ø  ハンドシェイクのオーバーヘッドが大きい。 Ø  ステートマシンが複雑である。 Ø  オプション、モードについて、どれを使えば？ Ø  マルチキャスト通信に対応していない。




Challenge Areas




dice: the mission and scope

§ Mission Ø CoAP向けDTLSプロファイルの策定 Ø TLSv1.3に対するCD向け要求事項の策定

§  scope Ø DTLSの必要十分な最小セットを定義する。 Ø TLS v1.3に対して要求事項を提案する。 Ø DTLS record layerとグループ鍵を使ったマルチキャスト通信の方

法を定義する。

§  out of scope Ø TLSに関する修正 à tls WG Ø グループ鍵交換 à msec WG Ø 新しいcipher suites à tls WG or cfrg


Others

§  SOLACE BoF Ø  Smart Object Lifecycle Architecture

for Constrained Environments Ø  Focusing to:

ü  setup processes.

ü  bootstrapping security of smart objects. e.g. where do devices get keys ?

ü  what do devices do in its lifecycle ?

§  COMAN BoF Ø  Constrained Networks and Devices Management Ø  Management for LLN, not Manet management. Ø  Gap analysis first, then starting a charter discussion.

ü  1) Terminology.

ü  2) Class of networks in focus.

ü  3) Analysis the management feature.




Challenge Areas




技術の標準化動向：まとめ

§  IP技術の標準化はIETFにて行われている。

§  5つのチャレンジ

§  3つのキープロトコル Ø 6LoWPAN：IPv6用アダプテーション層 Ø RPL：LLNに最適化な経路制御プロトコル Ø CoAP：M2M通信に最適化したメッセージプロトコル

§ 実運用を元にした技術の検討が始まっている。 Ø セキュリティ Ø 運用管理技術 Ø 実装ガイダンス

§ 新たなリンクへの応用が検討されている。

Ø Bluetooth, Z-WAVE, DECT, 3G, GSM, etc.




Challenge Areas




Agenda

§ M2M/IoTに関連する背景 § ユースケース § 技術の標準化動向 § おわりに

Ø IP技術の課題 Ø 既存システムとのギャップ

82 82


M2M/IoT におけるIP技術の課題

§ 旧システムとの連携と新システムへの移行 Ø  IPv6/IPv4アドレスが混在するシステムの運用形態 Ø トランスポートプロトコルのマッピング

§ 多様な通信システムが混在する環境での運用管理手法 Ø 効果的な無線リソースの配分方法 Ø 障害検知と対応手法

§ 計算資源の少ない機器における暗号技術の開発

§ 技術の普及 Ø 既存のTCP/IP技術 + 新規技術

§ スマートグリッド特有の脅威への対策 Ø NIST IR 7628, “Guidelines for Smart Grid Cyber Security”


スマートグリッドにおける脅威

§ 意図的な攻撃（Deliberate Attacks）愉快犯・内部犯・スパイ活動

§ 不慮の事故（Inadvertent Threats）不注意による人為的な事故

想定外の機器のエラーによる事故

§ 天災による事故

§ システムが複雑・巨大になる事による影響

§ 攻撃対象と方法の増加の可能性

§ 新技術の導入による影響

スマートグリッド特有の脅威

既存ICTシステムにおける脅威

NIST IR 7628, “Guidelines for Smart Grid Cyber Security”


既存ICTシステムと制御システムの相違点

§ 機器の計算資源

§ ライフサイクル

§ ソフトウエア等の更新頻度

§ 通信遅延の要求

§ 可用性の重要度

§ 運用管理方法

§ 物理セキュリティ

National SCADA Security, Idaho National Laboratory


Cisco のアプローチ

• インターネットの次の発展領域として IoT リサーチ開始

• 組込み向けIP スマートオブジェクトのプロトタイプ

•  IoT に向け新規技術としてIPv6 をベースにした新プロトコル開発への取り組み

6lowpan / RPL / CoAP IETF, IEEE, ETSI等のSDO での積極的な活動

• 学術研究機関と共同で次世代のセンサー情報応用技術の研究を実施

• アーキテクチャー策定 • SDO連携

•  IPSO (IP for Smart Objects) アライアンス設立

•  IPv6 フォーラムとの連携 • ZigBee アライアンスの　　

Smart Energy Profile 2.0 (SEP2.0) 仕様への貢献

•  ITUでのWeb of Things & Cloud Computing での貢献

•  IoTエコシステム構築 • テクノロジー • ビジネスモデル

• センサーやスマートデバイス等への IP Smart Object 搭載開発支援

• クラウドコンピューティングとフォグコンピューティングの機能連携

• フィールド実証実験

技術革新・標準化活動

テクノロジー普及促進に向けた取り組み

IoT ソリューション開発推進

Cisco IoT インキュベーションラボの活動スコープ


本日のまとめ

§  センサーネットワークは垂直統合型で独自進化を遂げてきた。 §  アプリケーションの多様化により、

ü 水平統合型のソリューションが期待されている。 ü それらを統合運用する要求がある。

§  そのためにIP技術の応用が検討・実施されている。

§  爆発的に増加する「モノ」の情報を有機的に結合させることで、新たなCapabilityが創造できる。

IETFにおいて、 §  LLN/SOに最適化したIP技術の標準化が進んでいる。

§  標準化以外にも、M2M/IoTの相互接続性を向上させるための動きがある。

一方で、

§  普及のためには、既存システムとのギャップを埋める事が重要。