IPv6 Header 40Bytes
TCP Header 20Bytes
용량이 큰 Communication 링크가 제공되어야만 HTTP 기반의 IoT 구현이 가능
조그만 sensor, 배터리를 아껴써야 하는 상황 때문에 HTTP over Wifi, HTTP over LTE 등이 적합하지 않음
Lightweight Middleware Protocol이 필요
ZigBee 계열
IEEE 802.15.4 link
Sensor Network 기술에 특화
IP로 연결
WiFi와 유사
느리고, Frame Size(127Bytes)도 작음
대신 에너지 Consumption이 매우 적음
특성을 볼 때 Bluetooth와 WiFi 사이에 위치, 미니어처 버전의 WiFi
Frame Size가 너무 작기 때문에, IPv6/UDP Header만 해도 벌써 48Bytes 차지
802.14.5 자체의 MAC Header는 25Bytes or 46Bytes(AES 사용 시)
HTTP Payload가 들어갈 공간이 33Bytes or 54Bytes만 남음
IPv6의 Minimum MTU 요구 사항
IPv6는 IPv4와 다르게 Fragmentation을 금지
따라서, 너무 큰 패킷이 오면 Drop
최소한 모든 IPv6의 link들은 1280Bytes를 지원해야 함
하지만 802.15.4 Frame size가 127Bytes이기 때문에 IPv6의 1280Bytes를 그대로 담을 수 없음
6LowPan Stack에서 1280Bytes packet이 잘 가는 것처럼 127Bytes 보다 작게 여러 개로 쪼개서 802.15.4 link를 통해 전송되도록 해야 함
Redundant information 제거
같은 Stream에 속한 IP Header가 Packet별로 별 차이가 없는 점을 이용
Transmission mode에 따라서 상이함
link-local mode에서는 IPv6 Header를 2bytes까지 줄일 수 있음
IoT Device들이 Mesh 형태로 구성되었을 때, Multi-hop Routing 필요
IoT 환경에서는 자원이 많이 필요한 link state보다 distance vector를 기반으로 하는 Routing 프로토콜이 많음
RIP의 Distance Vector를 통한 Table 업데이트
Counting to Infinity problem
Split Horizon
Split Horizon with poisonous reverse
Hop Count limit
RIP 프로토콜을 IoT 망에 사용하면 에너지 Consumption이 심할 수 있음
Distance Vector에 Timestamp(Sequence Number)를 붙임
demand가 있을 때만 routing을 다시 계산 -> reactive routing protocol
AODV나 DSDV는 IoT에서 사용하기에 너무 복잡함
LLN : Low Power Lossy Network
Google이 주도하는 Thread Group에서 Loop가 없는 아주 Simple한 Distance Vector 프토토콜을 생성
Rank라는 개념 도입
가장 멀리 있는 Node가 Rank가 가장 크다.
Uplink로 보낼 때는 Rank가 줄어드는 방향으로만 Forwarding
--> Loop가 생기지 않음
Client가 HTTP request를 보내면 Server가 HTTP response를 보냄
Client가 항상 initiate
Client가 Server의 주소를 알아야 함
HTTP over TCP의 overhead
non-persistent HTTP
persistent HTTP
HTTP request message
ASCII code로 보냄 --> Human Readable
길다는 약점이 있음
HTTP는 Restful architecture에 따라 설계
stateless : HTTP protocol 자체가 state 정보가 없음, session 정보 등
CoAP은 HTTP처럼 message를 text로 처리하지 않고 binary화 하여 compact 처리
HTTP over TCP/IP는 IoT에 너무 heavy함
UDP를 사용하기 때문에 CoAP이 Reliability를 제공하기 위해서 retransmission 사용 --> CoAP Transaction layer
binary header를 사용하여 HTTP보다 header size가 훨씬 작아짐
IoT device의 energy consumption 관점에서 CoAP을 사용하면 HTTP over TCP보다 약 50% 정도 효율적이다는 paper도 있음
Confirmable request
Non-confirmable request
CoAP의 중요한 기능 중 하나 proxy
Proxy : request들을 다른 request로 convert 해주기도 하고, cache 역할도 수행
HTTP와의 protocol conversion 역할
Smart Phone <-> HTTP <-> Proxy <-> CoAP <-> Sensor
IoT Device가 sleep mode에 있을 수 있으므로 proxy가 IoT Device의 온도 정보를 cache하고 있다가 대신 답해주는 것도 가능
CoAP Observer
변화가 생기면 observer에게 알림
Forwarding proxy
Cross proxy
Message Oriented Middleware(MOM)
asynchronous 구조
Pub-sub model
중간에 Broker server 존재
Subscriber는 주로 Smart phone
Broker는 Subscriber의 요청 사항을 기억
IoT Context에서 Pub-sub model을 support하는 middleware protocol이 MQTT(IBM에서 개발)
Telemetry : 멀리 metering 한다는 의미
Broker는 클라우드에 위치한다고 가정
Broker는 Cache 역할, 어떤 데이터에 대한 정보인지도 확인
Publisher가 Subscriber의 Physical ID(ex. IP Address)를 알 필요가 없음
Publisher가 Sleep mode에 들어가도 Broker가 대신 Subscriber에게 응답 가능
온도계와 습도계 두 개의 Publisher가 있는 모델
꼭 단말 device가 MQTT를 지원하지 않더라도 중간에 MQTT Client가 있어서 protocol conversion 가능
데이터에 대한 sementic 필요
예를 들어, 온도는 "temperature"로 부르기로 약속
Control Header의 Packet Type 확인
HTTP
MQTT
Data Centric
Address Centric
Internet은 Address Centric
원하는 Contents를 알기 위해서 Search engine 사용
Search engine이 data를 address로 convert
Contents Centric(CCN)
Broker가 Multi-hop으로 확장되었을 때
Publish한 data를 누구에게 보낼 것인가 문제 발생
SPIN : Data centric한 architecture를 제안한 routing protocol
Future Internet
SDN이 Future Internet의 Sub Branch