物聯網概論與應用
===
>講師A：清華大學資訊工程系 黃能富教授
>講師B：義守大學資訊工程系 廖冠雄教授
>彙整者：陳奕廷

###### tags: `專科課程`

:::danger
:heavy_exclamation_mark: **僅供學習用途，請勿用於翻印、販售等商業行為**
:::
:::info
:mega: 以下資料均來自於學聯網-[2016秋季物聯網概論與應用](http://www.sharecourse.net/sharecourse/course/view/courseInfo/907)

:mega: 學聯網傳送門:http://www.sharecourse.net/sharecourse/general/home/
:::

:::success
:::spoiler
:mag_right:[TOC]
:::

# 紙本筆記
>PDF：https://files.acrobat.com/a/preview/75f866ec-5788-4510-bc5b-de87921de82b

## 上冊

<iframe src="https://e.issuu.com/anonymous-embed.html?u=casiolike0531&d=mooc___________" style="border:none;width:100%;height:500px;" allowfullscreen></iframe>

# 6LoWPAN

- 6LoWPAN概要

- Sensor Network 與 Internet 相連，以IP方式．連線標準為6LoWPAN
- 全名：IPv6 over Low-Power Wireless Personal Area Network
- 讓Sensor Network具備以IPv6聯網的能力
- 跟Roll(路徑)有關係

- 6LoWPAN特色

- 封包:127bytes
- ZigBee每個封包最小:127bytes
- Mac Adress:64bits
- 頻寬:250kbps
- 低功耗（依靠電池）
- 低成本

- 6LoWPAN

- like Ethernet or WiFi，但是在ZigBee上
- 怎麼做IPv6壓縮
- 透過IP跟應用層做互動

- 6LoPWAN 技術

- 
- 切割IPv6封包，塞進Zigbee
- 標頭壓縮
- 48+ byte UDP(8) IPv6 Header(40)
- 放Data空間太小(127-48)
- Header後頭有其他Header
- Chained Header formet
- (Dispatch)跟IPv6相似，後面有沒有已壓縮Haeder

## 封包切割

- 
- Fragmentation 切割成許多小封包
- Frag Header：切割後的產物，為了以後組合回來。
- Frag Header 內容：

- 
- Size: size of datagram in bytes – Included in all fragments to simplify buffer allocation
- Tag: identifies all fragments of a datagram
- Offset: location of fragment in 8-byte units

## IPv6 標頭壓縮

- 

- 壓縮技術裡跟Follow沒有關係。壓縮時不記錄數與哪一個Follow
- 運用IP相同的值，進而省略

- 壓縮細節

- Ver：版本一樣是第六版，可壓縮
- Traffic class：針對Internet，Sensor Netowrk不需要，都是0，可壓縮。
- Payload Length：在L2 Header取得，可壓縮
- Source & Destination Address：佔128bits
- 如果採用Link-local Adress(開機時取得)，上述兩項Adress可省略。
- 介面卡ID從L2 Addrs(MAC Layer)取得
- 如果一開機要取得IPv6位址，產生Link-local Adress。代表可以直接從L2 Addrs拿，可壓縮
- Next Header 可壓縮

- 結論：IPv6 Header從40byte壓縮到一點點

### 標頭壓縮之Control Code

- 2byte Control Code 紀錄Header怎麼壓縮

### Control Code內容物：

- 
- TF (Traffic Class and Flow Label)
- 

- 0: Carried Inline (ECN+DSCP+Flow), 1: ECN+Flow,
- 2: ECN+DSCP

- 3: All zero

- NH (Next Header compression)

- 

- 0: Carried Inline

- 1: Next Header is compressed

- HLIM (Hop Limit = Inline, 1, 64, 255)

- 

- 這個封包進到網路經過幾個HOP就得出網路
- (經過幾個HOP就減一，減到0出網路)
- 0: Carried Inline,
- 1: 1
- 2: 64
- 3: 255

- CID (Context Identifier Extension)

-
- IPv6位址有兩種：
- Link Local：開機自己產生：fe80::
- Prefix：Router供給(Global)
- 有很大的機會Prefix相同，用一個Context代替
- 0: No 1-byte CID identifier
- 沒有另一個Byte
- 1: 1-byte identifier follows
- CID後頭有一個Byte(Source Adress | Destination Adress)
- 把Prefix作編號(會有16個編號)
- SAC/DAC (Source/Destination Address Compression)

- 0: Stateless
- 壓縮方式
- 1: Context-based
- 編號壓縮方式

- SAM/DAM (Source/Destination Address Mode)
- Mode ： 到底Adress變多長？

- 0: 16 bytes inline,
- 都沒壓縮
- 1: 8 bytes inline,

- 2: 2 bytes inline,

- 3: elided
- 通通可以壓縮

- M (Multicast Destination)

-
- Destination是否為multicast
- 0: Destination is not multicast,
- 1: Destination is multicast

### 標頭壓縮之Adress

- Adress分為Uicast & Multicast

#### Unicast Adress 壓縮

- Unicast Adress：

- Prefix壓縮

- 會有相同Prefix，因為由Router給的(Router通常給相同，因為相同網路)

- Sensor Node跟誰通訊？對象都相當少數
- 針對Prefix建立context
- 編號0~15
- 占4bit
- SAC/DAC = 0：
- Stateless Mode ： Link Local(fe80::/16)
- SAC/DAC = 1:
- Context-based Mode：用意在於自己找Router，然後Router給我們Global Prefix
- 用4bit ContextID 代替

- Interface Identifier(網卡ID)壓縮

- 由Layer2(MAC Layer)提供
- 48bit + XXX
- 可以由Layer2拿即可，不用紀錄。即可壓縮
- SAM/DAM (Source/Destination Address Mode)：

#### Multicast Adress 壓縮

- Group ID(群波)：

- Router群波

- Neighbor群波

- 壓縮方法：
- 128bit Muticast 縮短為 Group ID(Byte)(小數字)

## IPv6 標頭壓縮實例

- 
- 每個Compressed header都會記錄下一個Header是否有壓縮
- HC1 & HC2為Control byte
- HC1會告訴我們IPv6怎麼壓縮，並記錄著NextHeader是否做壓縮
- HC2亦同，UDP怎麼壓縮

### UDP壓縮

- UDP Header：

- UDP Header共通值

- Port坐落 61616 to 61632，16個port number。(4bits)
- 封包長度(Length)IPv6本身會記錄，可省略
- Checksum如果其他協定擁有，可能省略

- UDP Header可由8byte變成1byte：

- C：Check Sum
- 0：無法壓縮
- 1：已壓縮
- P：Ports
- 0(00)：無法壓縮(超過16個port number)
- 1(01)：Dest Ports壓縮
- 2(10)：Source Ports壓縮
- 3(11)：都壓縮

### 壓縮實例：

- ++Link-local Unicast++

- 原先封包大小對比壓縮後：

- Compact Forms：可壓縮
- Deviced form link hdr：由Link Hdr轉換過來
- Link Hdr = Layer2 = MAC Layer
- 結論：
- 壓縮效果最好，因為Prefix由Link-local提供(fe80)

- ++Clobal Unicast++

- 原先封包大小對比壓縮後：

- Compact Forms：可壓縮
- Deviced form link hdr：由Link Hdr轉換過來
- Deviced form Context：
- Router供給Prefix，故使用Context
- Hop Limit不等於1、64、255
- 原本就存在

- ++ Link-local Muticast++

- 原先封包大小對比壓縮後：

- Muticast
- 尋找所有Router、Neighbor所需
- Dest ID + HopLimit = ++2byte IP-HC++
- 使用Muticast，故出現Global ID

## Neghbor Discovery

- IPv6 Neighbor Discovery[RFC4861]
- Host怎麼找到Router & Prefix
- Router，怎麼從IP許出MAC
- 怎麼檢查電腦未開機
- 設計針對LAN，較為穩定的網路環境

- 6LoWPAN Neighbor Discovery
- 網路環境不穩定，封包易流失
- Radio涵蓋範圍不均
- 如果常常做Muticast，容易損耗電力
- 不必常常IP轉換MAC，傳送對象有限
- 裝置可能進入睡眠
- 數據收送完後馬上進入睡眠，不必Always On
- 結論：環境含傳統IP環境有所差異
- RFC4944定義，針對Low Power and Lossy NetWork。

- 6LoWPAN Neighbor Discovery 主要運作模式
- 示意圖：
- Autoconfigure：做自動化設定，找Router()
- RS(mc)：Muticast
- RA(uc)：Unicast
- NS+ARO：找Neighbor，並向對方註冊位置
- NCE：暫時Neighbor狀態儲存
- DAR：
- DAD sucess：檢查Adress有無重複
- DAC：回覆DAD正常
- NA+ARO：確認程序

## IP協議堆疊定位

- 6LoWPAN在IP Stack的位置：

- Power：Wi-Fi耗能的百分之一
- 8-16bit MCUs with KBs(占空間較小)
- 802.15.4已IP聯網

- 6LoWPAN Summary(概要)
- 6LoWPAN turns IEEE 802.15.4 into the next IP-enabled link
- 使得Sensor Network以IP和Internet互聯
- Low Power Device 彼此互通，也和Internet互聯
- 6LoWPAN替未來標準並易基礎
- 如果未來有多家廠商生產的Device Network互通，得需要標準化
- 在資源有限的無線感測網路中運作正常

- 6LoWPAN 說明文件

- RFC 4919, IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals

- RFC4944, Transmission of IPv6 Packets over IEEE 802.15.4 Networks

- RFC6282, Compression Format for IPv6 Datagrams over IEEE 802.15.4- Based Networks

- RFC6568, Design and Application Spaces for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)

- RFC6606, Problem Statement and Requirements for IPv6 over Low- Power Wireless Personal Area Network (6LoWPAN) Routing

- RFC6775, Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)

# 第六周 物聯網框架與國際標準協議

## Bluetooth：
-----------------------------
### Bluetooth簡介：

- 名稱源自於丹麥國王(940~981)

- 整合丹麥與挪威兩個國家
- 發明者者也想無縫通訊notebook & cellular phones

- 想提供短距傳輸模式，且具有安全性，並無所不在。

- 原始應用：

- 資料影音傳輸
- 手機電腦裝置資料換
- 周邊裝置互聯

- 歷史沿革：

- 

- 藍芽協定分層

- 

- 資料傳輸透過L2CAP
- Audio可傳輸語音：如藍芽耳機
- Baseband至Link Manager由晶片組成
- Host Controller是晶片端和Host端的橋樑

- 

- 利用不同介面和電腦溝通

- 藍芽規格

- 頻帶：2.4GHZ，免申請執照
- 調變技術：跳頻展頻(FHSS)

- 會在不同頻帶往返，避免干擾
- 79個頻道
- 每個頻道頻寬1MHz
- 傳輸速率：1Mbps(GFSK機制)
- 跳頻速度快速相較IEEE 802.11
- 一秒鐘1600次跳頻

- 網路拓樸：

- 
- Piconet

- Master同時跟七個裝置做溝通
- 剩的裝置已加入網路但不能傳資料
- 最大頻寬：1Mbps
- 星狀拓樸結構
- 在一個piconet中，只有一個master裝置，其他都是slave裝置
- 一個piconet的建立與維護是由master裝置來負責
- 在一個piconet中，所有的裝置(包含master與slave)彼此之間不可以直接對傳資料

- Scatternet

- 由2 ~ 10個Piconet組成
- Piconet V.S. Scatternet

- 
- 要轉送資料的話得在上層自行定義
- 在藍芽規範中沒有定義在scatternet中的路由規範

### Bluetooth 實體層和頻寬：

- 頻帶：

- 
- 傳送距離30公尺：Class 2
- 傳送耗能：

- 

- 傳輸速率：

- Sysbol Rate：1M symbols/sec
- GFSK機制
- 

- Baseband 協定

- 

- 規範：

- 傳輸資料時成對
- 每625us跳頻一次，把時間分割成時樔，每個時樔就是625us。
- Master在時樔裡送封包出去，對應接收的slave。傳回來亦然。
- 如果封包超過時樔時間，可以送1或3或5個slot time進行傳送
- Master送slot time時是同一個頻道
- 練習題敘述：

- 整個通道的時間被分割成固定625 s的時槽
- 通道使用的分配方式為：master從某個奇數號的時槽開始傳送給某slave裝置，而該slave裝置則使用master傳完之後的下一個時槽傳資料給master
- master一定使用奇數號時槽來傳送，而slave一定使用偶數號時槽傳送
- master的封包(packet)長度必須是奇數個時槽
- <b style="color:#f00;">所有裝置(包含master與slaves)不必競爭每個時槽的使用權</b>
- TDD：

- slot number：0 ~ 2^27 -1
- Master：使用偶數
- Slave：使用奇數

- 定址規範：

- IEEE MAC address(BD_ADDR)

- 出廠時會有 48 bit
- 一旦連上網路，Master會給裝置3 bit active slave assress
- Master broadcast封包，會給3bit [000] adress
- Parked Member address

- 如果進入Parked模式，Master會給你 8 bit parked slave address

- Piconet的形成

- A是Master
- 一開始每個裝置有獨立ID
- 裝置如果想與Master連線，Timer得同步
- 如果沒有資料要傳，所以進入待機(Parked)
- 從裝置ID可推算跳頻順序
- 形成後Master會給：

- 有資料傳裝置：Active Member Address
- 無資料傳裝置：Parked Member Address
- 未加入網路：standby state

### Bluetooth baseband 2 and Physical Links：

- 運作型態：

- 

- 

- 

- 封包格式：

- 

- 三個欄位

- Physical Links

- 藍芽規範任何應用服務要傳資料到另一個裝置的話首先必須要LinK Manger要求跟對方建立連線

- 兩種連線：

- SCO連線：

- 裝置雙方建立固定頻寬速率的通道，拿來做語音傳輸。
- 點對點通道
- 封包不重傳
- 必須保留固定週期的時槽，以供SCO傳送資料

- ACL連線：

- 一般資料傳輸，隨時傳
- 點對多點傳輸
- 資料可以重傳

- 實例：

- 

- 每6個slot一個週期，傳資料
- 封包超過時間就有一個以上slot Time

### Bluetooth L2CAP and Applications

- L2CAP：

- 

- 主機端最下層
- 讓上層服務對下層傳資料有統一窗口
- 協定多工(篩選協定，檢視協定)
- 對上層資料作分割組合讓下層適合接收
- 所有的非語音型態的應用服務，其master裝置與slave裝置之間之邏輯資料連線(Logical link)的建立、使用、與管理

- RFCOMM：

- 透過L2CAP模擬序列埠功能
- 最多同時模擬60個
- 用序列方式傳送資料或數據機訊號
- 應用範圍：
- 撥接網路
- 傳真
- 兩個手機檔案傳輸、名片資料交換
- 透過另一個裝置存取區域網路，對外連線

- SDP：

- 主要跟遠端裝置建立L2CPA連結
- 透過連結設定Query for service
- 透過連結抓取對方裝置所提供的服務及參數，以做設定
- 界定另一個連結開始使用裝置所提供的服務
- 查詢某藍芽裝置所能提供的服務型態

- 藍芽Profiles：

- 會定義下層要建立什麼連線？參數做甚麼設定？
- 定義各種應用服務的實現，提供應用服務
- 不同Profiles牽涉協定層不同
- 

### Bluetooth BLE and BLE PHY(藍芽4.0)

- 為何需要？

- 

- 傳統藍芽

- 裝置間傳送資料需要建立連線，即使沒有資料傳送，也得維護連線

- 沒有資料傳送進入睡眠模式(sniff mode)基本上無法達到IoT需求。

- 傳送時消耗電流過大25mA
- 無法使用輕便電源

- BLE：

- 超省電

- 使用鈕扣電池供應電力
- 最大電流 <20mA
- 平均電流：<5uA
- 封包短小
- 占用RF頻道少
- state machine架構簡單
- 協定單純
- 屬性：

- 

- 資料速率：1Mbps
- 不支援串流資訊
- 不支援傳送檔案
- 定義應用服務時有統一模式(GATT)，協定便輕便。

- 協定層：

- 
- 規範：

- Dual Mode：一個裝置可以同時支援傳統藍芽(BR/EDR)。同時間其中一個Mode
- Single Mode：穿戴式裝置，只支援BLE

- 協定細節：
- 
- 調變技術：1Mbps(GFSK)
- 
- Advertising Channels
- 為何使用這三個頻道?
- 

### Bluetooth BLE Link Layer and

- Link Layer：

- 

- Advertising機制：

- 
- 裝置可以使用Advertising機制宣告自己的存在，或者宣告資訊給別的裝置接收。

- 資料如何傳送？

-

- 過程：

## LPWAN低功耗廣域網路：
-----------------------------
### LPWAN簡介：

- 以此雷達圖為例，圖中的參數如下

- Power Consumption：耗電量
- Bandwidth：頻寬
- Radio Chipset：晶片成本
- Radio Subscription Costs：無線通訊頻道租賃成本
- Number of Base Stations：Base Station數量
- Transmission Latency：傳送時間延遲
- Geographical Coverage,Penetration：訊號覆蓋率

- 雷達圖


### LPWAN特性：

- 網路拓樸大多為星狀型態

- 希望不要造成路由依循的困擾

- 佈建方式

- 1.使用Base Station。Sensor直接套用LPWAN協議


- 2.Sensor仍使用短距離協議，透過Gateway套用LPWAN協議傳送至Base Station


- LPWAN實際開發技術

- 未需申請之頻道LPWAN(Unlicensed-Band)
- 已實際開發完成！

- LoRaWAN
- SigFox
- Weightless
- On-Ramp Wireless(Ingenu)
- DASH7

- 需申請之頻道LPWAN(Licensed-Band)
- 未定義完成，可能得定義至2020年

- LTE MTC(NarrowBand,NB-IoT)

### LPWAN - LoRaWAN ：

- 由 LoRa 聯盟制定
- 由IBM、Cisco組成

- 運作頻帶：
- Sub 1G 免執照頻帶

- 展頻技術：
- Chirp Spread Specturm of FSK
- 在同意頻道內同時好幾組傳送端同時傳送Data不互相干擾

- 資料傳送速率(Data Rate)
- 250 ~ 50Kps
- 根據網路環境改變傳送速率

- 傳送範圍
- 2 ~ 5km(市區)、 15Km(k區) 、45km(人煙稀少)

- 電池消耗
- 兩顆四號電池使用10年

- LoRaWAN網路架構

- 

- GateWay只做資料轉傳、不檢查資料內容及連線維護等協定問題

- End Nodes有資料想送就送

- NetWork統籌處理資料

- Sensor 和 GateWay 通訊上的特性

- 

- 因為GateWay只做資料轉傳，可以在任何時間增加GateWay，增加資料接收的可靠度。

- End Nodes 相當省電，因為可以做自己想做的事情。

- 後端網路處理端

- 

- 統籌管理，架構簡單
- End Nodes和GateWay類似於線路

- LoRoWan 裝置等級

- 
- A Class：
- 由電池供電
- 行為規範：可傳送接收Data，有Data可接收才能接收。
- 傳送完資料後，有兩次downlink可接受資料

- B Class
- 電池供電
- 定期從Server收資料
- downlink週期出現時樔，傳Data給Sensor

- C Class
- 永不睡眠
- 穩定電源供電

### LPWAN - LoRaWAN2 ：

- Class A：

- 傳送方式：

- 

- 裝置使用ALOHA協定
- Data傳送到Gateway時，透過DownLink讓裝置可以接收資料
- 經過Delay Time就會有第二次接收機會

- Class B：

- 傳送方式：

- 

- Network給予裝置Beacon

- 網路屬性：

- 傳輸距離：大於15公里
- 佈建：難易度低

- 範例：台北市12個行政區一個行政區一個基地台
- 省電、經濟、成本低

- 應用：(inteliLIGHT)

- 

### LPWAN - SigFox ：

- Sigfox wireless networks

- 網路架構類似LoRaWAN

- 實體層屬性

- Sub 1G
- UNB + SDR
- Two way communication

- 傳輸範圍：

- 市區：3~10km
- 郊區：30~50km
- 無障礙物：1000km

- 資料速率：

- 為符合歐洲ISM規定(每項服務只能有1% duty cycle)，速率低、限制高
- 每個封包12byte
- 最多一天140個messages

- 傳送耗能

- 10uW ~ 100mW

- 現況：

- 廣泛應用於歐洲國家(都柏林、米蘭)

### LPWAN - Weightless ：

- 標準由Weightless SIC制定

- ARM、Accenture組成

- 三套公開表準

- 

- 網路架構

- 類似於LoRaWAN

- Weightless N：

- 實體層

- 頻帶：TV White Space 無線電視未使用的頻段
- 調變技術：UNB with DBPSK
- 頻寬窄小：200HZ
- 單向

- 傳輸範圍：3km
- 資料速率：

- 100bps
- 封包限制：20bytes極限
- 傳送耗能：17dpm
- 支援裝置移動時不同基地台繼續傳送資料

- Weightless P：

- 實體層

- 頻帶：Sub 1G
- 調變技術：UNB with QPSK
- 頻寬：12.5KHZ
- 雙向

- 傳輸範圍：3km
- 傳輸距離：2km
- 資料速率：

- 200bps ~ 100kbps
- 封包限制：20bytes極限
- 傳送耗能：17dpm
- 支援裝置移動時不同基地台繼續傳送資料
- 省電數據： < 100uW

- Weightless W：

- 實體層

- 頻帶：TV White Space(470MHz~790Mhz)
- 調變技術：16QAM、BPSK
- 頻寬：5MHZ
- 雙向

- 傳輸範圍：3km
- 傳輸距離：5km
- 資料速率：
- 1Kbps ~ 10Mbps
- 封包限制：10bytes ~ 無窮大
- 傳送耗能：17dpm
- 支援裝置移動時不同基地台繼續傳送資料
- 省電數據： < 100uW

### LPWAN - DASH7(D7A)：

- 標準由 DASH Alliance 制定
- active RFID衍生(ISO18000-7)
- OSS-7：OpenSource
- BLAST：網路技術

- BLAST：
- B：資料分段傳送
- L：網路傳輸輕量不複雜
- A：非同步協定
- S：維持隱私性(不用Beacon)
- T：裝置具有移動性(Mobile)with upload

- 特性

- 網路拓樸：樹狀

- 
- 協定(7個layer都有做協定)：

- 
- 實體層：

- - 頻帶： Sub 1G ISM(433,868,915MHz)
- 調變技術：GFSK
- 頻道間隔：25K ~ 200KHz
- 資料速率：

- 9.6Kbps、55.55Kbps、166.667kbps
- 封包限制：256bytes

- MAC：CSMA/A
- 傳輸距離：0~5Km
- 耗能：30~60uW

### LPWAN - On-Ramp Wireless：

- 重新命名為 Ingenu 於 2015年

- 調變技術：自有專利RPMA

- 基於直接序列展頻DSSS改良
- 改良後在2.4GHZ RF Band也有寬廣的傳輸距離
- 2.4GHZ RF Band

- 40 Channels
- 頻寬：1MHZ

- 傳輸範圍：300平方英里
- 傳輸距離：沒有遮蔽物下500Km
- 傳輸耗能：20dpm
- 封包限制：6~10Bytes
- 資料速率：624Kbps~156Kbps(上行到下行)

### LPWAN - 3GPP：

- 

- NB-IoT走向：著重室內覆蓋率

## 物聯網框架標準：
- Service Farmework
- Architectural Framkwork
-------------------------------

### 簡介：

- IoT架構需求：

- IoT架構必須實現互通性

- 上層下層互動(裝置和管理軟體)
- 互通標準：發現、管理、回報、安全
- IoT架構必須支援大量物件
- IoT架構必須技術重複使用和模組化
- IoT架構必須實現低技術門檻

- IoT框架標準：

- Service Framwork類別：

- 定義實現特定應用服務
- 如：醫療保健、智慧家庭
- 達到Web Service水準

- Architectural Framkwork

- 定義所有IoT Framework的Application，讓cross-domain互通
- 系統間相容性、互通性、可交換性
- 目標：希望符合所有IoT Application domain 需求
- Web Servic(WWW)水準現況

- 使用瀏覽器就可以使用Web Servic
- 無論部屬什麼線路，跟Service關連不大
- 各種不同Application也可以利用Web Service做溝通
- Web Service容納尺寸大，供多人使用
- 技術門檻低

- Web Servic(WWW)設計模式

- 使用單一、少量協議，簡化設計
- 協定層分明[(TCP、UDP);(HTTP、REST)]

- 協定分明好處：無論部屬什麼線路，跟Service關連不大
- 所有資源給單一定址方式(URI、超連結)
- 採用Stateless互動

- 本次互動跟上次互動無關
- 以Hypermedia實現

- 如何把Web Servic應用在IoT？

- 讓所有裝置連網
- M2M協定
- 制定統一物件描述模型和資料描述模型
- 定義Hypermedia for Machine API

- Framwork應用範例

- 

### Allseen AllJoyn：

- 由Allseen Alliance制定

- Qualcomm，微軟、飛利浦、LG組成
- 針對IoT制定OpenSource Framwork，彼此互通

- 目的：

- 物跟物彼此透過標準介面互相通訊、交換資料及操作

- 架構：

- 兩種裝置：AllJoyn Rounter 和 Application
- 

- Discover程序：

- 
- 

- 高階軟體架構

- 

### OIC ：

- 定義最佳化IoT架構

- 基於RESTful
- 

- 目標

- 定義框架
- Open Souce Code
- Code：Apache & Spec：RAND-Z
- Open Souce Project
- https://www.iotivity.org
- API

- 以URL呈現
- CoAP存取
- 互通性

- 認證標準
- 參與架構廠商：

- 

- CoreFramework：

- 定義範圍

- 運作架構的框架
- 訊息交換標準
- 彼此呼叫介面協定
- 基於現有use case情境
- 各有自訂的應用服務(如智慧家庭)

- OIP 架構Roles

- 主要使用協定：CoAP
- OIC Clinet
- OIC Server
- 

- OIC Device concept

- 
- 深綠為URI標籤

- 範例：

- 燈座：

- 

- Core Framework Spec

- 

- 定義於Apllication Layer

- Core Framework Basic Operation

- 

- Core Framework 協定大全

- 

### OMA LWM2W ：

- OMA：Open Mobile Alliance
- 目的：制定IoT輕量形M2M協定

- 特性：

- sensor 管理：

- 裝置如何探查
- 裝置組態、控制裝置參數
- 定義韌體隨時更新
- 錯誤回報

- Application：

- 環境設定
- 送控制指令
- Sensor回報機制

- 架構：

- 

- LWM2W Clinet是CoAP Sever
- 所有M2M App依循LWM2W開發應用服務
-

- Thread Framework

- 簡介

- 
- http://www.threadgroup.org/
- 定義IoT下層網路框架，使用各種Application協議實現Application應用服務
- 由google旗下恆溫器大廠所主導
- 主要目標聚焦於智慧家庭
- 
- 利用Ipv6做IoT
- Low Power 可使用電池供應
- 速率：250kbps
- 支援250個nodes
- 低延遲

- 網路模型：

- 

- 特性：

- IPv6連網
- 彈性網路架構
- 穩健網路架構(802.15.4)
- 安全性機制
- 低功耗

### One M2M：

- 想法：

- 希望在各種不同應用領域間訂製共同協定

- 

- 定義的共同協定：

- 絕大多數應用服務都需要
- 註冊
- 安全性
- 群組管理
- 裝置管理
- 資訊訂閱
- Server搜尋
- 定位服務
- 付費機制

- 已定義之技術報告：

- 

- 已定義之技術規格：

- 

- 已定義之Use Cases

- 

- one M2M運行架構

- 

- 

- NSE：可以跟其他node做資訊交換
- 很容易把不同領域的IoT的應用勾建起來，並互相溝通。

### ETSI：

- 架構：

- 

- ETSI有定義GateWay裡的ReSource：GSCL(淺藍區塊)
- 所有元件間有interface

- 架構採用RESTful方式，所有ReSiurce有統一方式作標誌(類似URL)
- 所有Resource關聯橡樹狀
- 串聯Resource，SCL機制來描述Resource關聯性
- 定義標準介面

- 範例：

- 智慧家庭

- 

- 

### IEEE P2413：

- 現況：

- 定義期間
- 整合IoT技術發展需求

- 定義摘要：

- 描述各種不同的IoT的Domain
- 定義IoT Domain共通抽象特性
- 標示IoT Domain的差異性

- 目的：

- 提供參考模型
- 定義IoT Domain關聯
- 定義基本building blocks
- 整合到很多層次的系統
- 描述架構的差異性已文件顯示
- 

- 抽象定義層次

- 

- 定義範例：

-