IPv6 Header 40Bytes
TCP Header 20Bytes
용량이 큰 Communication 링크가 제공되어야만 HTTP 기반의 IoT 구현이 가능
조그만 sensor, 배터리를 아껴써야 하는 상황 때문에 HTTP over Wifi, HTTP over LTE 등이 적합하지 않음
Lightweight Middleware Protocol이 필요
6LowPAN
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를 통해 전송되도록 해야 함
Header Compression
Redundant information 제거
같은 Stream에 속한 IP Header가 Packet별로 별 차이가 없는 점을 이용
Transmission mode에 따라서 상이함
link-local mode에서는 IPv6 Header를 2bytes까지 줄일 수 있음
Routing
IoT Device들이 Mesh 형태로 구성되었을 때, Multi-hop Routing 필요
IoT 환경에서는 자원이 많이 필요한 link state보다 distance vector를 기반으로 하는 Routing 프로토콜이 많음
RIP Operation
RIP의 Distance Vector를 통한 Table 업데이트
Counting to Infinity problem
Split Horizon
Split Horizon with poisonous reverse
Hop Count limit
RIP 프로토콜을 IoT 망에 사용하면 에너지 Consumption이 심할 수 있음
DSDV(Destination Sequenced Distance Vector)
Distance Vector에 Timestamp(Sequence Number)를 붙임
AODV(Ad Hoc On-demand Distance Vector Routing)
demand가 있을 때만 routing을 다시 계산 -> reactive routing protocol
AODV나 DSDV는 IoT에서 사용하기에 너무 복잡함
RPL(Routing Protocol for LLN)
LLN : Low Power Lossy Network
Google이 주도하는 Thread Group에서 Loop가 없는 아주 Simple한 Distance Vector 프토토콜을 생성
Rank라는 개념 도입
가장 멀리 있는 Node가 Rank가 가장 크다.
Uplink로 보낼 때는 Rank가 줄어드는 방향으로만 Forwarding
--> Loop가 생기지 않음
Web and HTTP
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(Constrained Applicaton Protocol)
CoAP은 HTTP처럼 message를 text로 처리하지 않고 binary화 하여 compact 처리
HTTP over TCP/IP는 IoT에 너무 heavy함
UDP를 사용하기 때문에 CoAP이 Reliability를 제공하기 위해서 retransmission 사용 --> CoAP Transaction layer
- timeout 개념 필요
- TCP만큼은 아니고, simple하게 구현
- CoAP은 Reliable, Unreliable mode 2개 중 선택 가능
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
MQTT
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 확인
- Keep-alive feature : PINGREQ, PINGRESP Control Packet Type 사용
- Last Will & Testament
온도계가 고장나거나 죽는 경우(Client가 ungracefully disconnect 되었을 때), Subscriber에 알려줘야 함
Broker가 정해진 LWT message를 subscriber에게 전달 - QoS
message 중요성에 따라서 사용
QoS 0 : at most once는 안 가도 된다는 의미, ack가 필요 없음
QoS 1 : at least once는 message가 갔다는 것이 보장되어야 함, ack 필요, dup message를 확인하는 mechanism은 없음
QoS 2의 경우에는 아래 message 처리
PUBACK, PUBREC, PUBREL, PUBCOMP
HTTP vs MQTT
HTTP
- IoT Device와 IoT Agent가 직접 연결
- Restful Scheme 사용
- IoT Device는 항상 요청을 기다려야 함
MQTT
- 중간에 Broker 위치
- message 방식의 pub-sub 모델
- IoT Device가 Sleep mode에서 깨어나서 message를 수신
- 저전력
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
