IoT関連技術の動向 Sep-2013

Shoichi Sakane
Cisco Systems
IoT関連技術の動向
26-Sep-2013

© 2010 Cisco and/or its affiliates. All rights reserved. Cisco ConfidentialPresentation_ID 2
Agenda
§ M2M/IoTに関連する背景
§ ユースケース
§ 技術の標準化動向
§ おわりに
22

Agenda
ü IP技術の優位性
ü M2M/IoTへの期待
ü IoTからIoEへ
33

Agenda
44

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
1111

センサーシステムの多様化
Improve
Productivity
Enhanced
Safety &
Security
Predictive
Maintenance
High-Confidence
Transport and
Asset Tracking
Intelligent
Buildings
Healthcare
Data Center
Energy
Saving
Improve Food
and H
2
O
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
1515

インターネットに接続する「モノ」の量
1995 2011 20202000
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
2020

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

Trains
Public
Safety
Rail
Bus Fleets
Savelivesandreduceemergencyservices’responsetimes
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, 米国
•  クロスドック倉庫でトラクター、コンテナにタグを添付、ス
ループット増大、無駄な作業時間・使用燃料の量を抑制
コンテナ・ターミナル, 韓国
•  コンテナクレーン、トランスファークレーン、ヤードトラクター
を追跡、港湾でのコンテナ処理にかかる生産性を向上。
物流における位置情報利活用システム

スマートグリッド教科書, インプレスジャパン
大型発電所
電力取引市場
送電網
送配電制御
通信事業者
需要家
FAN
WAN
HAN
インターネット
インターネット
制御所間通信
ネットワーク
配電網
スマートグリッドを構成する様々なシステム（米国）

スマートグリッド概念図, 次世代エネルギーシステムに係る国際標準化に向けて 2010年1月
大型発電所
送配電制御
通信事業者
需要家
送電網
配電網
スマートグリッドを構成する様々なシステム（日本）

§  変電所システムにおけるIEDのための通信規格
§  機能を抽象化し、通信プロトコルが変わっても対応可能
例: IEC 61850
スマートグリッドに係わる情報・通信の国際標準化動向, JPNC, Mar 2011
IEC61850を適用した変電所自動化システムの例
プロトコルスタック概略
TCP
UDP
IP
IP技術を活用した様々な標準技術
IED: Intelligent Electric Device （ディジタル化に対応した装置）

§  フランスのスマートグリッド用のPLC（電力線搬送通信）の規格
§  IP技術を活用して、様々なトポロジに対応可能。
例: G3-PLC, IEEE P1901.2
G3-PLC Profile, http://www.maxim-ic.com/products/powerline/g3-plc/
MAC
PHY
Adaptation
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 MLETLS
Security
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
ü 対象エリア
ü IETFにおける動向
ü 技術概要
3838

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 !!

本日の対象エリア：システム視点
大型発電所
送配電網
送配電制御
分散型電源
通信事業者
需要家
FAN
FAN
FAN
FAN
FAN

本日の対象エリア：システム視点
大型発電所
送配電網
送配電制御
分散型電源
通信事業者
需要家
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

Hands
ets

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
標準化
LLN向け機器の
実装ガイド
の標準化
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
LLN向け機器の
実装ガイド
の標準化

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
LLN向け機器の
実装ガイド
の標準化

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
LLN向け機器の
実装ガイド
の標準化
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
LLN向け機器の
実装ガイド
の標準化

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(Cost
OSPF fail fail fail pass fail
OLSRv2 fail fail fail pass pass
TBRPF fail pass fail pass unclear
RIP fail fail fail unclear fail
AODV pass unclear pass fail fail
DSDV fail fail fail unclear fail
DYMO pass fail pass fail fail
DSR 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 routing5
1
1
1
1
1
11
1
1
1
3
3
2
3 3
3
3
3
3
7
wired link
wireless link
ETX value on linkn
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
LLN向け機器の
実装ガイド
の標準化

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
LLN向け機器の
実装ガイド
の標準化

“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
LLN向け機器の
実装ガイド
の標準化

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
LLN向け機器の
実装ガイド
の標準化

技術の標準化動向：まとめ
§  IP技術の標準化はIETFにて行われている。
§  5つのチャレンジ
§  3つのキープロトコル
Ø  6LoWPAN：IPv6用アダプテーション層
Ø  RPL：LLNに最適化な経路制御プロトコル
Ø  CoAP：M2M通信に最適化したメッセージプロトコル
§  実運用を元にした技術の検討が始まっている。
Ø  セキュリティ
Ø  運用管理技術
Ø  実装ガイダンス
§  新たなリンクへの応用が検討されている。
Ø  Bluetooth, Z-WAVE, DECT, 3G, GSM, etc.
標準化
Challenge Areas
LLN向け機器の
実装ガイド
の標準化

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

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の相互接続性を向上させるための動
きがある。
一方で、
§  普及のためには、既存システムとのギャップを埋める事が重要。

IoT関連技術の動向 Sep-2013

IoT関連技術の動向 Sep-2013

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à IoT関連技術の動向 Sep-2013

Similaire à IoT関連技術の動向 Sep-2013 (20)

Plus de Shoichi Sakane

Plus de Shoichi Sakane (7)

Dernier

Dernier (10)

IoT関連技術の動向 Sep-2013