2015. Spring
목차 1. Lightweight IPv6 Networking for IoT - 6LoWPAN - GloWBAL IPv6 - IPv6 Addressing Proxy 2. Lightweight Security for IoT 3. Internetworking Bluetooth Low Energy(BLE) 4. Application Examples(Google Thread etc)
1. Lightweight IPv6 Networking for IoT
Lightweight IPv6 Networking for IoT IPv6 : Most suitable technology for IoT Vast address space Mobility support End-to-End connectivity Security Tested IPv6 : Too heavy for networks of low capability (B/W, MTU, Delay, Unreliable) BLE, Zigbee, Lowpan, etc Ex) BLE의최대 MTU는 27byte, IPv6 헤더만 40byte
6LoWPAN
6LoWPAN IPv6 requires the maximum transmission unit (MTU) to be at least 1280 Bytes. IEEE 802.15.4 standard packet size is 127 Bytes. Link layer header 25 Bytes Optional security(aes-ccm-128) 21 Bytes Payload = 127-25-(21) = 102(81) Bytes << 1280 Bytes (IPv6 Header + Payload) Too much fragmentation needed
6LoWPAN IEEE 802.15.4 위에서 IPv6 패킷을전송하고자하는기술 6LoWPAN을사용하는 IoT 디바이스는개별적인 IPv6 주소를가져야함 IoT 디바이스와기존 IPv6 망과연동하기위해 6LoWPAN이내장된게이트웨이가필요 센서는 IP/UDP 혹은 IP/TCP stack이필수적임.
6LoWPAN 구조 IoT 디바이스가 IPv6를사용하기위해 adaptation layer가필요 Adaptation layer IPv6 데이터를센서에전송하기위해단편화기능, 헤더압축기능, 멀티홉전송기능을제공 6LoWPAN 게이트웨이 IPv6 기반프로토콜과 6LoWPAN 프로토콜을동시에탑재, 두프로토콜간의변환을담당
Application payload for 6LoWPAN Compression of IPv6 Header and UDP Header(49 -> 6 bytes) 압축 102bytes 102bytes
IPv6 Header Compression Dispatch code 를사용해 compression 여부를알려줌 Best case 의경우 IP header 를 40Byte => 2Byte 로축소가능 Octet-0 Octet-1 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 0 1 1 TF NH HLIM CID SAC SAM M DAC DAM # bit Description 011XXXXX 3 LOWPAN_IPHC Dispatch code TF 2 Traffic class, Flow label NH 1 Next Header HLIM 2 Hop LIMit CID 1 Context Identifier SAC 1 Source Address Compression SAM 2 Source Address Mode M 1 Multicast Compression DAC 1 Destination Address Compression DAM 2 Destination Address Mode
IPv6 Header Compression IPv6 Header compression ( RFC6282 ) IPv6 기존 Header format Octet 0 Octet 1 Octet 2 Octet 3 4 Byte Version Traffic Class Flow Label 8 Byte Payload Length Next Header Hop Limit 12 Byte 16 Byte 20 Byte 24 Byte 28 Byte Source Address 32 Byte 36 Byte 40 Byte Destination Address Compression Octet 0 Octet 1 In-line field 모두 DSP TF NH HLIM CID SAC SAM M DAC DAM 2 Byte 0 1 1 1 1 1 0 1 0 0 1 1 0 0 1 1 생략된경우 IPHC 에따라 In-line IPv6 Header fields 가생략됨
IPv6 Header Compression (Best case scenario) Octet 0 Octet 1 DSP TF NH HLIM CID SAC SAM M DAC DAM 2 Byte 0 1 1 1 1 1 0 1 0 0 1 1 0 0 1 1 011 [DSP] : LOWPAN_IPHC IPv6 Header Encoding임을나타냄 11 [TF] : Traffic Class and Flow Label from IPv6 are both 0 1 [NH] : Next Header Compression follows LOWPAN_IPHC(ex. UDP) 01 [HLIM] : Hop limit is 1 (Single-hop) 0 [CID] : No additional 8-bit CID is needed 0 [SAC] : Source address compression uses stateless compression 11 [SAM] : Source IP is derived using link address of SRC 0 [M] : Not a multicast 0 [DAC] : Destination address compression uses stateless compression 11 [DAM] : Destination IP is derived using link address of DST Single-hop unicast best case 시나리오 : LOWPAN_IPHC 뒤로 IPv6 헤더 없이바로 LOWPAN_NHC 가시작됨 2 Byte
IPv6 Header Compression cont. Octet Octet 2 byte 0 1 1 1 1 1 0 0 1 1 1 0 0 1 1 0 4 byte Context Identifier Extension Hop Limit 6 byte Short IEEE 802.15.4 address of SRC(16-bit) 8 byte Short IEEE 802.15.4 address of DST(16-bit) 00 [HLIM] : Hop Limit field is carried in-line after LOWPAN_IPHC 1 [CID] : Context Identifier Extension + Short IEEE 802.15.4 Address[16- bits] Able to create globally unique IPv6 address (RFC6282, RFC4291) 1 [SAC/DAC] : Source address and destination address compression uses stateful compression 0 [M] : Not a multicast 10 [SAM/DAM] : Short 802.15.4 source/destination link addresses(16- bit) are carried in-line after LOWPAN_IPHC Global unicast best case 시나리오 : LOWPAN_IPHC, CID, HLIM, Short 802.15.4 SRC+DST address 뒤로 IPv6 헤더없이바로 LOWPAN_NHC 시작됨 8 Byte
IPv6 Header Compression cont. Octet 0 Octet 1 2 byte 0 1 1 0 0 1 0 0 1 1 0 1 1 1 0 0 4 byte Context Identifier Extension Traffic Class 6 byte 4-bit padding Flow Label(12 out of 20-bit) 8 byte Flow Label(8 out of 20-bit) Hop Limit 10 byte 12 byte 14 byte Extended 802.15.4 address of SRC(64-bit) 16 byte 18 byte 20 byte Extended 802.15.4 address of DST(48-bit) 22 byte 00 [TF] : (Traffic Class + 4-bit padding + Flow Label) = 4 byte is carried 1 [M] : Multicast in-line after LOWPAN_IPHC 01 [SAM] : Extended 802.15.4 link address(64-bit) is carried in-line 00 [DAM] : Unicast-prefix-based IPv6 Multicast address compression(48-bit) is carried in-line Global multicast worst case 시나리오 : LOWPAN_IPHC, CID, TF, HLIM, Extended 802.15.4 SRC+DST address 뒤로 IPv6 헤더없이바로 LOWPAN_NHC 시작됨 22 Byte
UDP Header Compression UDP Header compression UDP 기존 Header format Octet 0 Octet 1 Octet 2 Octet 3 4 byte SRC Port DST Port 8 byte UDP Length UDP Checksum Compression Octet Octet 2 byte 1 1 1 1 0 0 1 1 Last 4-bit of SRC port Last 4-bit of DST port 4 byte UDP Checksum UDP Header 는 UDP LOWPAN_NHC 에따라 8 Byte 4 Byte 로감소
6LoWPAN 장단점 센서네트워크에적용되는 6LoWPAN의장점기존의 IP 인프라및 IP 기반기술재사용가능 IPv6에서제공되는넓은주소공간사용가능 DHCP서버를통해 IP 주소를할당받지않더라도, IPv6의기능으로센서스스로자신의 IP 주소생성가능 6LoWPAN의기술적목표과제헤더압축을통해헤더의크기를줄여더많은데이터공간을확보하는것이필요함. 많은수의 IoT 디바이스가 6LoWPAN을적용하지못함. - 기존기술에 6LoWPAN을적용하기위해서는 hardware를변환하거나통신 stack의구조를크게변환해야함 (not cost-effective)
GloWBAL IPv6
GloWBAL IPv6 개념 Smart device에 IPv6 주소를할당하여 IPv6 network와통신하기위한기술 6LoWPAN을제외한통신방식 (ex)ieee 802.15.4, Bluetooth Low Energy) 을사용하는기존 smart device의경우 IPv6 network와호환성이없음 Access Address/Identifier(AAID) 를사용하여 device에 IPv6 주소할당. interoperability in IPv6 network for smart device GloWBAL IPv6
현재기술의한계 현재기술 (6loWPAN) 을이용해 IPv6 capability를구현하기에는 cost가크다. 모든 device 를 6loWPAN 사용가능 device 로전환해야함 IPv6 의경우 header 의크기를기존 IoT 기술에적용하기에는너무크다. Ex) Bluetooth Low Energy has a limited payload of 19~27 bytes IPv6의경우하나의 IP address만해도 16bytes IPv6 header
IPv6 AAID 변환 GloWBAL IPv6 의경우 Hash 함수를이용하여 36bytes 의정보를 4bytes 로 변환 (CRC 32 사용 ). AAID identifier = h{source IP, destination IP, source Port, destination Port}
AAID identifier & AAID dispatch 해쉬함수를이용해 IPv6를변환하여 4byte 크기의 AAID identifier 생성 AAID management control information을지시하는역할을진행하는 AAID dispatch (8 bits) 가추가되어최종적으로 header의크기가 5bytes( 기존 IPv6의경우 36bytes) AAID identifier 와 AAID dispatch 로인해최종적으로 5bytes
AAID identifier & AAID dispatch AAID dispatch (8 bits) AAID 구성에관한정보 S Set Mode (1bit) 새로운연결구성에대한알림 M Mobility (1bit) Device 의 mobility 에관한정보 IP src IP dst Port Src Port dst Source IP Configuration (2bits) Set Destination IP (1 bits) Source Port Configuration (2bits) Set Destination Port (1bit) < IPv6 src 할당방식에관한정보 > 00 : 네트워크에서주소자동할당 01 : 내부네트워크의주소사용 10 : 내부네트워크주소, 자신주소정보사용 11 : 게이트웨이에서주소할당 목적지의 IPv6 주소에대한알림 ( 초기 setup 시혹은 updating 시 ) < Port src 할당방식에관한정보 > 00 : Default 값이나게이트웨이에서설정해준값. 01, 10, 11 : application 에맞는 port 사용 ( 사용정보량에따라설정다름 ) 목적지의 Port 정보에대한알림 ( 초기 setup 시혹은 updating 시 ) 예시 : 특정지점에대한정보를가지고연결을구성하며, 이때 device 의 IPv6 주소와 port number 값은게이트웨이에서설정한다.
AAID gateway AAID gateway 가필요 AAID 와 IPv6 를 mapping 하는역할 (hash 함수를 이용하여 AAID-IPv6 변환을진행 )
IPv6 Addressing Proxy
IPv6 Addressing Proxy 기존에 industrial markets이나 building automation market 등의분야에서사용하고있던통신기술 (CAN, X10, EIB/KNX, RFID) 을 IPv6 network와 proxy 연결하는방식. 각 device에 IPv6를할당하고, proxy에서 device가사용하고있는통신기술의 frame을 IPv6 network 용 frame으로변환 ( 반대과정도수행 )
IPv6 Addressing Proxy Proxy 내부에서 X10, CAN, EIB/KNX, RFID 의기존통신기술에대한정보 를바탕으로 IPv6 로전환하기위해 multiprotocol card 가존재
IPv6 변환 IPv6 의 128bits 중에서 NETWORK ID, HOST ID 로구분하여사용, 기존 기술의정보를삽입 (2 가지방식 ). LINE ID : device 가연결되어있는 line 에대한정보 (8bits) TECHNOLOGY ID : device 가사용하는통신기술의정보 (8bits) RESERVED TECHNOLOGY MAPPING : 메시지정보 ( 통신기술에따라다름 ) 가삽입 (48bits) NETWORK ID (64 bits) HOST ID (64 bits) LINE ID (8 bits) TECHNOLOGY ID (8 bits) RESERVED TECHNOLOGY MAPPING (48 bits) (a) Addressing functionality in application level NETWORK ID (48 bits) LINE ID (8 bits TECH ID (8 bits) HOST ID (64 bits) RESERVED (16 bits) RESERVED TECHNOLOGY MAPPING (48 bits) (b) Addressing functionality within kernel IPv6 addressing in the IPv6 Addressing proxy
Ex) CAN 메시지의변환 CAN 메시지의형식 (EXTENDED FRAME FORMAT) 을 IPv6 에맞게 mapping. Information Type Identifier : 메시지의 type에대한정보 Device Type : 메시지를전송하는 device가 sender, receiver, or controller인지에대한정보 Device Identifier : device의 ID(CAN 형식에따름 ). Rserved : 아무설정이없는경우모든자리가 0, device의상태를나타냄 (ex) 긴급상황 ). SOF (1 bit) ARBITRATION FIELD CONTROL (6 bits) DATA (64 bits) CRC (16 bits) ACK (2 bits) EOF (7 bits) SOF (1 bit) 11 BIT IDENTIFIER SRR (1 bit) IDE (1 bit) 18 BIT IDENTIFIER RTR 1bit CONTROL (6 bits) EXTENDED FRAME FORMAT INF TYPE ID (2 bits) DEVICE TYPE (2 bits) DEVICE ID (29 bits) RESERVED (15 bits) IPv6 mapping from CAN NETWORK ID (48 bits) LINE ID (8 bits) TECH ID (8 bits) RESERVED (16 bits) RESERVED TECHNOLOGY MAPPING (48 bits) RESERVED TECHNOLOGY MAPPING 에삽입됨.
Comparison of Technlogies(IPv6 for IoT)
Protocol/ Features Low memory requirement Header size optimization Communication stack independent Compatibility with legacy technologies (Editable) Compatibility with proprietary technologies (Non-editable) Border Gateway requirement IPv6 (Base) lwip (lightweight IP) uip (microip) 6LoWPAN (RFC 6282) GLoWBAL IPv6 IPv6 Addressing Proxy X X X X X O X X X X O X X X X O X X X O O O O X O O O X O O
Protocol/ Features Low memory requirement Header size optimization Communication stack independent Compatibility with legacy technologies (Editable) Compatibility with proprietary technologies (Non-editable) Border Gateway requirement IPv6 (Base) lwip (lightweight IP) uip (microip) 6LoWPAN (RFC 6282) GLoWBAL IPv6 IPv6 Addressing Proxy X X X X X O X X X X O X X X X O X X X O O O O X O O O X O O
Protocol/ Features Low memory requirement Header size optimization Communication stack independent Compatibility with legacy technologies (Editable) Compatibility with proprietary technologies (Non-editable) Border Gateway requirement IPv6 (Base) lwip (lightweight IP) uip (microip) 6LoWPAN (RFC 6282) GLoWBAL IPv6 IPv6 Addressing Proxy X X X X X O X X X X O X X X X O X X X O O O O X O O O X O O
Protocol/ Features Low memory requirement Header size optimization Communication stack independent Compatibility with legacy technologies (Editable) Compatibility with proprietary technologies (Non-editable) Border Gateway requirement IPv6 (Base) lwip (lightweight IP) uip (microip) X 40 Byte X X X X O 40 Byte X X X X O 40 Byte X X X X 6LoWPAN (RFC 6282) O 26 Byte 2 Byte X X X O GLoWBAL IPv6 IPv6 Addressing Proxy O 5 Byte O O X O O - O X O O
Protocol/ Features Low memory requirement Header size optimization Communication stack independent Compatibility with legacy technologies (Editable) Compatibility with proprietary technologies (Non-editable) Border Gateway requirement IPv6 (Base) lwip (lightweight IP) uip (microip) 6LoWPAN (RFC 6282) GLoWBAL IPv6 IPv6 Addressing Proxy X 40 Byte X X X X O 40 Byte X X X X O 40 Byte X X X X O 6LoWPAN: 2 Byte X IPv6 X compression X for use O with 802.15.4 26 Byte O 5 Byte O GLoWBAL O IPv6 X and O IPv6 Addressing Proxy: O - O Non-IP X devices O IPv6 O
Protocol/ Features Low memory requirement Header size optimization Communication stack independent Compatibility with legacy technologies (Editable) Compatibility with proprietary technologies (Non-editable) Border Gateway requirement IPv6 (Base) lwip (lightweight IP) uip (microip) 6LoWPAN (RFC 6282) GLoWBAL IPv6 IPv6 Addressing Proxy X 40 Byte X X X X O 40 Byte X X X X O 40 Byte X X X X BLE O on top 26 Byte of 802.15.1 X is X X O able to implement an AAID for O GLoWBAL 5 Byte IPv6 O O X O Non-editable predefined O - O communication stacks use X O O IPv6 addressing proxy ex) CAN frame
Protocol/ Features Low memory requirement Header size optimization Communication stack independent Compatibility with legacy technologies (Editable) Compatibility with proprietary technologies (Non-editable) Border Gateway requirement IPv6 (Base) lwip (lightweight IP) uip (microip) X 40 Byte X X X X O 40 Byte X X X X O 40 Byte X X X X 6LoWPAN (RFC 6282) O 26 Byte 2 Byte X X X O GLoWBAL IPv6 IPv6 Addressing Proxy O 5 Byte O O X O O - O X O O
2. Lightweight Security for IoT
6Lowpan 기반헤더압축기법필요성 Data / Header 효율향상을위한 Lightweight security 필요 <802.15.4 위에서 IPv6, UDP 를사용했을때 payload 비교 > 1) 기본 (IPv6 + UDP) 2) 기본 + 보안 (IPv6 + IPSec + UDP + DTLS) 3) IPv6/UDP 헤더압축 (Compressed IPv6/UDP + IPSec +DTLS) 4) IPv6/UDP 헤더압축 + IPSec/DTLS 압축 (Compressed IPv6/UDP + Compressed IPSec/DTLS)
Compression Ratio Uncompressed compressed Compression Ratio IPv6 IPv6 IPSec IPv6 Header 41 2 83% AH 24 16 33% ESP 10 6 40% UDP UDP UDP Header 8 4 50% DTLS DTLS 25 8 68% 시나리오별압축비율 TOTAL 압축률 시나리오 1 : IPv6 + AH + UDP + DTLS (69%) 시나리오 2 : IPv6 + ESP + UDP + DTLS (76%) 시나리오 3 : IPv6 + AH + ESP + UDP + DTLS (66.7%)
IPv6 Extension Header Compression (AH) AH Format Compressed AH Format AH 에서는해당필드부분이 24bytes -> 16bytes 로감소 8bytes 감소
AH Processing & compression example 1byte 12bytes 8bytes 감소 4bytes 6LowPAN NH NHC_AH 코딩이용 (Shahid Raza) NHC_EH(Extension header) 1옥텟사용 ( 확장헤더정보를제공하기위해추가 ) NHC_AH 코딩으로 PL(SPI로부터정보제공받으므로생략 ) 과 SPI( 상호협약없을시생략 ) 값조정 SN => 4에서 2옥텟으로압축 (SPI 값생략에따른 SN 값조정 )
IPv6 Extension Header Compression (ESP) ESP format ESP 에서는해당필드부분이 10bytes 에서 6bytes 로감소 Compressed ESP format 4bytes 감소
ESP Processing & compression example 1byte 8bytes 4bytes 감소 4bytes 6LowPAN NH NHC_ESP 코딩이용 (Shahid Raza) NHC_EH(Extension header) 1옥텟사용 ( 확장헤더정보를제공하기위해추가 ) NHC_ESP 코딩으로 SPI( 상호협약없을시생략 ) 값조정 (4->0) SN => 4에서 2옥텟으로압축 (SPI 값생략에따른 SN 값조정 )
Compressed DTLS 13 bytes 12 bytes 42 bytes 38 bytes 5 bytes 3 bytes 33 bytes 33 bytes (8) bytes (9) bytes (9) bytes (5) bytes * 6LoWPAN Compressed DTLS for CoAP
DTLS based End to End Security Architecture * A DTLS Based End-To-End Security Architecture for the IoT with Two-Way Authentication
Packet RTT PER PALOAD for different encryptions Payload 대비 RTT Payload 가대략 100bytes 배수가될때마다 RTT 의증가폭이변함 IEEE 802.15.4 128 bytes Maximum frame size * A DTLS Based End-To-End Security Architecture for the IoT with Two-Way Authentication
DTLS Compression Compression header for DTLS LOWPAN_NHC_RH (Record + Handshake) LOWPAN_NHC_R (Record only) LOWPAN_NHC_CH (ClientHello) LOWPAN_NHC_SH (ServerHello) LOWPAN_NHC_CH LOWPAN_NHC_RH LOWPAN_NHC_R LOWPAN_NHC_SH
DTLS Compression DTLS Compression Example DTLS _ RECORD Compression(13 bytes -> 5bytes) LOWPAN_NHC_R V(version) : 0 (2bytes -> 0byte) EC(Epoch) : 0 (2 bytes -> 1 byte) SN(Seqeunce number) : 00 (6bytes -> 2bytes) Compression header : 1bytes Contest type : 1bytes Length : 2bytes -> 0byte
DTLS Compression DTLS 는 UDP Payload 내에존재하며각세부구조에서 Record Header : 13bytes -> 5bytes, Handshake Header 에서 12bytes -> 3bytes 총 17byte 의절약이생긴다
Lightweight security Lightweight security 에서 AH(HMAC-SHA1-96 Mode), ESP(AES-CBC Mode) 보안기법을사용한경우 payload 보안기법을 AH & DTLS 사용시 : Payload 73 bytes (compression 이전 47 bytes) 보안기법을 ESP & DTLS 사용시 : Payload 83 bytes (compression 이전 61 bytes)
3. Internetworking for Bluetooth Low Energy
Internetworking Bluetooth 구분 BLE 디바이스 Addressing Layer Application 특징 1 BLE ( 현재 ) 현재 BLE MAC address Link layer + Application layer GATT 를이용한서비스정의가필요 Local 사용에국한됨 2 BLE + RESTful API 현재 URI : host 는 Gateway Application layer GATT 를이용한서비스정의가필요 BLE 가서버, Gateway 에서 HTTP/TCP/IP 를 GATT 서비스로변환 3 BLE + HTTP proxy HTTP Proxy 서비스 (HPS) 추가 (2014) URI(BLE : HPS 클라이언트, HTTP Proxy : 서버 ) Application layer HTTP 를사용 BLE 가클라이언트, HTTP 를하나의 GATT 서비스로정의 4 BLE + IPv6 6LoWPAN + IPSP( 프로파일 ) 추가 IPv6 address Autoconfig IP layer 모든 TCP/IP 응용을자유롭게사용가능 Proxy 필요없음 Mobility, Security, 멀티홈, end-to-end 연결
1 BLE ( 현재 ) Gateway(Central) 가클라이언트가되어서버인 Sensor(Peripheral) 로부 터데이터를가져옴
BLE 의응용 Data Hierarchy GATT : Two BLE devices transfer data back and forth using Services and Characteristics. ATT : Store Services, Characteristics and related data in a simple lookup table using 16-bit IDs for each entry in the table.
1 BLE ( 현재 ) Example : Health Thermometer 서비스 Service Health Thermometer Service Characteristics Temperature measurement Characteristics Intermediate Temperature Characteristics Temperature Type Characteristics Measurement Interval
UUID represents service and characteristic Example : Health Thermometer 서비스 Handle UUID Description Value 0x0100 0x2800 Health Thermometer service UUID 0x1809 0x0101 0x2803 Characteristic: Temperature measurement UUID 0x2A1C Value handle : 0x0102 0x0102 0x2A1C Temperature value 20 degrees 0x0104 0x2A1F Descriptor : unit Celsius 0x0110 0x2803 Characteristic : Measurement interval UUID 0x2A21 Value handle : 0x0111 0x0111 0x2A21 Measurement interval 3600 seconds
1 BLE ( 현재 ) BLE stack(low part) Physical Layer : 실질적인패킷을주고받음 Link Layer : medium access, 연결확립, 에러컨트롤, 플로우컨트롤 L2CAP : 상위레이어로부터데이터를 Muxing, fragmentation 된패킷을결합
2 BLE + RESTful API(BLE 가 server) BLE + RESTful API Bluetooth Internet Gateway 에서각 BLE 디바이스의기능마다 URI 주소를 부여함 외부에서 RESTful API(PUT, GET 등 ) 를써서 BLE 를 Access
2 BLE + RESTful API(BLE 가 server) BLE + RESTful API HTTP 명령어를사용 BLE device를 GAP의 Resource로 access 게이트웨이에연결된 BLE device들을 Passive scan으로찾음 GATT Feature Primary Service Discovery GATT Sub- Procedure Discover All Primary Services Discover Primary Services By Service UUID REST API Method and URI GET http://monet2.sogang.ac.kr/gatt/nodes/temp erature_01/services?primary=1 GET http://monet2.sogang.ac.kr/gatt/nodes/temp erature_01/services?primary=1&uuid=0x02 01
3 BLE + HTTP proxy(ble 가 client) BLE 쪽의 Client가보내는 HTTP Write Request를 HPS(HTTP proxy service) 를이용하여게이트웨이에게보내고게이트웨이는이것을 HTTP request 로변환하여웹서버로보낸다. HPS Server는웹서버로부터받은 HTTP response를 BLE에게전달한다. HPS 에서 BLE가클라이언트가되고, 게이트웨이가서버가됨 현재진행중인상호운용성테스트가성공적으로끝나면 Bluetooth 스펙으로확정 (2015, Bluetooth SIG)
3 BLE + HTTP proxy(ble 가 client) Service HTTP Proxy Service Characteristics URI Characteristics HTTP Entity Body URI Characteristics HTTP Status Code Characteristics HTTP Headers Characteristics HTTP Control Point Characteristics HTTPS Security
2, 3 방식장 / 단점 (RESTful API, HTTP Proxy) 장점 현재 BLE 를그대로사용가능 (2 RESTful API) 현재 BLE 에 HPS 서비스만추가하여인터넷연결가능 (3 HTTP Proxy) 단점 Gateway에의존적이다 Connection 의개념이없다 ( 지속적연결이아닌일회성 ) Ex VOIP, Streaming 구현이어려움 디바이스에범용 TCP/IP 프로그램을쓰기어렵다 End-to-end 가성립되지않는다 Mobility 지원이어렵다 멀티홉지원이어려움
4 BLE + IPv6(Node Routher) BLE + IPv6
4 BLE + IPv6(IPSP, IPSS) IPSP(Internet protocol support profile) IPSP를지원하는 Device들을찾아서통신하도록해줌 IPSP를지원하는 Device들간에는 IPv6 패킷을 BLE transport를통해전송할수있음 IPSS(Internet protocol support service) Bluetooth 스펙으로발표예정 (2015 년, Bluetooth SIG)
4 BLE + IPv6(IPSP, IPSS) Roles Node originates or consumes IPv6 application packet (usually sensor and actuator) Router routes IPv6 packets(likely AP) Router + Node possible A Router supports GAP central role and may additionally support GAP peripheral role L2CAP requirement Connection oriented channel MTU is 1280bytes or higher
IPv6 over BLE(IETF Draft 2014 년 9 월 ) IPv6 over Bluetooth LE stack A IPSS discovers IP enabled devices and establishes link layer connection for transporting IPv6 packets B After this, IP layer communication(udp/tcp/others over IPv6 and 6LoWPAN) can take place. A B
IPv6 over BLE(IETF Draft 2014 년 9 월 ) Stateless address auto configuration IID(Interface identifier) 는 48bit Bluetooth device address 에서부터만들어짐 (RFC2464) Link local 을의미하는 prefix fe80::/64 를 IID 앞에붙여줌
BLE MTU 의한계와 IPv6 의관계 MTU defined for L2CAP fixed channels over BLE : 27bytes (L2CAP header 4bytes 포함 ) L2CAP header 제외하면 23bytes 를상위 layer 에서사용가능 1280bytes 혹은그이상되는 IPv6 패킷을전송하기위해 L2CAP layer 에서 fragmentation and reassembly solution 제공 (IPSP 1.0 에의해정의 ) Connection oriented channel with flow control 사용
Neighbor Discovery 기본적으로 Neighbor Discovery 는 6LoWPAN 의 Neighbor Discovery Optimization 표준을따름 (RFC6775) 6LN 노드는 6LBR 에게 ARO(Address Registration Option) 가포함된 NS(Neighbor Solicitation) 메시지를보내어 non-link-local 주소를등록한 다. 이에따라 NA(Neighbor Advertisement) 를프로세스한다.
Header compression 기본적으로 IEEE 802.15.4 over IPv6 에서의 Header compression 기법을 따름 Compression 메커니즘사용을위해 ARO(address registration option) 가 사용 노드의 local 주소가보더라우터의 ARO 에저장되어있다면센서가보더 라우터로데이터를보낼시 source address 는모두생략할수있음
Main benefits of IPv6 over BLE 1) 응용에대한제한이없어짐 - BLE 방식은 profile, service, characteristic으로정의한응용만사용가능한데 비해모든인터넷응용을가능하게함 2) BLE device를 host로 addressing 3) IPv6 over BLE is not so costly when compressed 4) Bluetooth SIG, IETF에서표준화가진행중 5) 구현사례 6) IPv6 adoption gains momentum 7) Security (IPSec, etc.) 8) Mobility
1) 응용에대한제한이없어짐 기존 BLE : Service, characteristic 에의해정의된응용만사용가능 (e.g. Health thermometer) IPv6 over BLE : 모든인터넷응용이가능 (TCP/UDP/Others)
2) BLE device 를 host 로 addressing 4 IPv 6 + BLE 방식에서 IP 주소는 BLE device 의 interface 를 address 하므로이를통하여 (service, characteristic 정의없이 ) 여러가지응용이동시에인터넷을통해외부프로그램과연결가능 (IP addresses host not application!!) 2 BLE + RESTful API 의경우외부에서 BLE device 에있는특정응용을 object 로 addressing 하여 access 함 (URI Addresses a predefined application as an object) 3 BLE + HTTP proxy 의경우 BLE 응용이 HPS 서비스를사용하여외부의웹서버에있는 object 를 access 함 (URI Addresses a resource at external server)
3) IPv6 is not so costly when compressed 6LoWPAN ipv6 compression Global unicast Octet 0 Octet 1 Octet 2 Octet 3 4-bit 8-bit 12-bit 16-bit 20-bit 24-bit 28-bit 32-bit 4-Byte Version Traffic Class Flow Label best-case scenario 8-Byte Payload Length Next Header Hop Limit 12-Byte 16-Byte Source Address 20-Byte 24-Byte IPv6 28-Byte Octet 0 Octet 1 Octet 2 Octet 3 32-Byte 4-bit 8-bit 12-bit 16-bit 20-bit 24-bit 28-bit 32-bit Destination Address 36-Byte 4-Byte [LOWPAN]_IPHC CID Hop Limit 40-Byte 8-Byte Source Address Destination Address 4-Byte Next Header Payload Length Reserved 4-Byte [ ]_NHC_EH [ ]_NHC_AH Sequence Number 8-Byte Security Parameter Index IPv6 8-Byte 12-Byte Sequence Number Field Extension 12-Byte Integrity Check Value(variable) 16-Byte Header 16-Byte 20-Byte Integrity Check Value(variable) AH 4-Byte [ ]_NHC_UDP SRC/DST Port UDP Checksum 24-Byte 4-Byte [ ]_NHC_RHS Epoch Sequence Number 4-Byte SRC Port DST Port 7-Byte Message type Message Sequence UDP 8-Byte UDP Length UDP Checksum 4-Byte Type Version Epoch 8-Byte Epoch Sequence Number 12-Byte Sequence Number Length 13-Byte Length Payload 4-Byte Type Length 8-Byte Message Sequence Fragment Offset 12-Byte Frag. Offset Fragment Length Handshake Payload 5bytes DTLS Record DTLS Handshake Headers : 97Bytes 35bytes Payload : 5bytes 67bytes 802.15.4 Payload : 102bytes 67bytes
3) IPv6 is not so costly when compressed IPv6 Header compression ( RFC6282 ) IPv6 기존 Header format Octet 0 Octet 1 Octet 2 Octet 3 4 Byte Version Traffic Class Flow Label 8 Byte Payload Length Next Header Hop Limit 12 Byte 16 Byte 20 Byte 24 Byte 28 Byte Source Address 32 Byte 36 Byte 40 Byte Destination Address Compression In-line field 모두생략된경우 Octet 0 Octet 1 DSP TF NH HLIM CID SAC SAM M DAC DAM 2 Byte 0 1 1 1 1 1 0 1 0 0 1 1 0 0 1 1 IPHC 에따라 In-line IPv6 Header fields 가생략됨
3) IPv6 is not so costly when compressed Octet 0 Octet 1 DSP TF NH HLIM CID SAC SAM M DAC DAM 2 Byte 0 1 1 1 1 1 0 1 0 0 1 1 0 0 1 1 011 [DSP] : LOWPAN_IPHC IPv6 Header Encoding임을나타냄 11 [TF] : Traffic Class and Flow Label from IPv6 are both 0 1 [NH] : Next Header Compression follows LOWPAN_IPHC(ex. UDP) 01 [HLIM] : Hop limit is 1 (Single-hop) 0 [CID] : No additional 8-bit CID is needed 0 [SAC] : Source address compression uses stateless compression 11 [SAM] : Source IP is derived using link address of SRC 0 [M] : Not a multicast 0 [DAC] : Destination address compression uses stateless compression 11 [DAM] : Destination IP is derived using link address of DST Single-hop unicast best case 시나리오 : LOWPAN_IPHC 뒤로 IPv6 헤더없이바로 LOWPAN_NHC가시작됨 2 Byte
4) 표준화가진행중 (Bluetooth SIG) 2 BLE + RESTful API Published as White Paper, April, 2014 3 BLE + HTTP proxy(hps) ProtoSpec, October, 2014 현재진행중인상호운용성테스트가성공적으로끝나면스펙으로확정 (2015) 4 BLE + IPv6(IPSP) Draft1.0, October, 2014
4) 표준화가진행중 (IETF) Transmission of IPv6 Packets over BLUETOOTH(R) Low Energy draft-ietf-6lo-btle-03 IPv6 over Bluetooth LE is dependent on both Bluetooth 4.1 and IPSP 1.0 or newer
5) 구현사례 (IPv6 over BLE, Aalto Univ.) * T. Savolainen, M. Xi, IPv6 over Bluetooth Low-Energy Prototype, Aalto University Workshop on Wireless Sensor Systems, 2012. 6LoWPAN over BT-LE implementation by NOKIA Interoperability implementations with another company already started
5) 구현사례 (HOP Ubiquitous, Jara et. al) Lower power consumption Multipurpose Totally flexible Device 별 ipv6 address 부여 Smart home, BEMS와같이사용자가여러 device를통제할수있는상황에적합 Hop basic Hop extended * http://hopu.eu/
5) 구현사례 (HOP Ubiquitous, Jara et. al)
6) IPv6 adoption gains momentum J.Czyz et al., Measuring IPv6 Adoption, ICSI, 2013.8
6) IPv6 Gains Momentum J.Czyz et al., Measuring IPv6 Adoption, ICSI, 2013.8
6) IPv6 adoption gains momentum (IPSO) Goal Promote the use of IP as the premier solution for access and communication for Smart Objects
6) IPv6 adoption gains momentum (IoT6) Goal Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture enabling heterogeneous components interoperability.
6) IPv6 adoption gains momentum (IoT6) Companies aligned with IoT6 Turn it ipv6 Universal Device gateway(udg) Smart IPv6 Building Hobnet EAR-IT
7) Security IPSec Panasonic 에서제시한 IPSec over IPv6 개념
8) Mobility
4. Application Examples(Google Threads etc)
Lightweight IPv6 적용기술 ( 유사기술포함 ) IP Non-IP 구분 1 Thread (Google etc.) 2 HOPu 3 JenNet-IP 4 HomeKit (Apple) 5 CSRmesh IP 사용 6LoWPAN GloWBAL IPv6 6LoWPAN 통신방식 ( 물리채널 ) 802.15.4 BLE 802.15.4 BLE BLE Mesh Self-heal Self-heal Grouping Flood mesh OS Thread Beta ( 회원사배포 ) ios and Android JenOS ios Android (ios 개발중 ) Security Banking-class public key - 128-bit AES encryption bi-directional authentication, persession encryption Public Key, Authentication 비고 Self-heal(RPL?), 250+(802.15.4?) Bluetooth Profile 사용 500+ Bluetooth Profile 사용 Bluetooth Profile 사용 QR 코드사용
1 Thread (Google etc.) Thread Group Thread Group 은가정에있는여러제품들을인터넷망에연결하여저전력으로통신할수있도록레이어프로토콜, 소프트웨어플랫폼개발, 제품개발을하기위해만들어진단체 Thread Group 의회원으로 ARM, BIGASS, freescale, nest(google), 삼성, Silicon Labs, Yale 사가참여
1 Thread (Google etc.) IEEE 802.15.4 MAC 위에 6LoWPAN 을사용 IPv6 통신이가능함에따라모든인터넷응용을사용가능 (cf. BLE 의경우 Profile/Service 등으로정의한응용만사용가능 ) Thread = 6LoWPAN + IP routing + UDP + Security Reliable transport (application layer 구현 ) (e.g. CoAP confirmable 이용 )
1 Thread (Google etc.) 250+ 의디바이스를 mesh 로연결 Self-healing mesh (RPL? RFC 6550)
1 Thread (Google etc.) : 제품개발동향 Freescale : IEEE 802.15.4 를 MAC 으로 하는 MCU 를판매중, Thread beta development program 을운영중 Silicon Labs : IP 기반매쉬를지원하는 Thread beta 소프트웨어를회원 / 협업사 에게배포중
1 Thread (Google etc.) : 제품개발동향 NEST Thermostat NEST Protect
BLE over IPv6 vs Thread Group 6LoWPAN 구분 BLE over IPv6 Thread Group 6LoWPAN Stack 구조 802.15.1 기반 802.15.4 기반 Networking 6LoWPAN after IPSP 6LoWPAN MTU 27bytes 127bytes Topology Star Mesh 보급화 우세 ( 휴대폰단말에대부분탑재 ) 열세 (2014 후반기배포예정 ) 평가 Bluetooth 는이미대중화되어있으 나 2015 년 stack 표준화발표결과를 주목할필요있음. Zigbee 설치기반확장으로문제 해결시시장주도가능성 ( 대기업참가중, google, ARM, 삼성 )
2 HOPu Mapping 기반 IPv6 + UDP Compression ( 36bytes -> 5bytes ) cf. 6LoWPAN 은 IPv6 + UDP Compression ( 48bytes -> 6 ~ 30bytes )
2 HOPu Bluetooth 의 Profile 을이용하여구현 기존 BLE 디바이스에바로적용가능 ( 응용메시지에 AAID 전송가능 )
2 HOPu IPSS (IP Support service), IPSP (IP Support Profile) 등을이용하여 IP 구현한것으로추측됨 BLE 의 Service/Profile 을이용하여 IP 서비스를시작하고실제메시지는 GATT 위의 Application level 에서전송하거나 ( 응용계층에서전송 ) 또는 Bluetooth 4.1(2013년 12월 ) 에서새로정의한 L2CAP Connection Oriented Channel with Credit Based Flow Control Mode 위에서직접전송가능 ( 링크계층위에서직접전송 )
2 HOPu BLE 디바이스를 IPv6와 RESTful API를이용하여스마트폰, 인터넷, 클라우드에연결할수있도록오픈 SDK제공 HOP Basic : End-to-End IPv6 연결이가능한 BLE 디바이스 (GloWBAL IPv6 사용하여 IPv6주소를디바이스별로제공 ) cf. ibeacon 이 IPv6 주소없이일방향통신만을제공하는것과차별화 HOP Extended : Wearable activity monitor sensor IP 사용동기 : 모두가쉽게이해하고사용할수있는솔루션개발을위해, 기존 IP 관련기술을활용하기쉬움 Hop basic Hop extended
2 HOPu(Catalog)
3 JenNet-IP Self-Healing 가능한 mesh 구성하고 6LoWPAN으로업그레이드기존산업용으로사용하던 JenNet의 Tree networking을이용하여 6LoWPAN으로업그레이드 NXP에서 2011년개발, 자체 Micro-controller만사용가능하여범용성떨어짐
3 JenNet-IP JenNet-IP 프로토콜스택은 NXP 의 JenNet 프로토콜 (IETF 6LoWPAN 계층 으로업그레이드 ) 을채택
4 HomeKit (Apple) Siri 음성인식기반통합 UI 제공 iphone ipad가게이트웨이역할 HomeKit chip을이용해개발된디바이스만사용가능 (HomeKit Accessary Protocol 사용 ) Group으로묶어제어가능 지문인식기반의보안솔루션제공 2014년 6월 WWDC에서발표
4 HomeKit (Apple) Non-IP solution ( 기존 GATT 응용계층위에 Overlay 형태로존재 ) Services Garage door openers Lights Door locks Thermostats IP camera controls Switches Characteristics Power state Lock state Target state Brightness Model number Current temperature
4 HomeKit (Apple) : 제품개발동향 Elgato Eve 스마트홈시스템 IFA 2014 에서공개 control status
HomeKit (Apple) vs Thread (Google etc) 구분 HomeKit (Apple) Thread (Google etc) 통신방식 BLE 802.15.4 개발참여회사 Apple 단독 Google, 삼성, nest 등 IP x IPv6 이용 (6LoWPAN) Gateway iphone, ipad 가 Gateway 기능 802.15.4 기반의스마트폰이없어별도의 Gateway 가필요 사용가능한기기 HomeKit chip 을이용해개발된 디바이스만사용가능 기존 802.15.4 디바이스를 software 업데이트를통해이용가능
5 CSRmesh BLE 디바이스들로 mesh 를구성하여 Group 별로제어가능 Android, ios 등어떤 OS 기반으로도제어가능
5 CSRmesh QR code 를이용한간단한디바이스등록
5 CSRmesh Flood Mesh (broadcast and relay by re-broadcast)