Hình 2.1. Kiến trúc ngăn xếp 6LoWPAN so sánh với mô hình ISO/OSI Layer
a. Lớp vật lý của 6LoWPAN
Lớp vật lý trong 6LoWPAN có các đặc điểm nhƣ sau:
Lớp vật lý cung cấp các khả năng truyền thông cơ bản của sóng vô tuyến vật lý.
Dựa trên chuẩn IEEE 802.15.4 với tốc độ dữ liệu 250 Kbps và tần số hoạt động từ 2400 – 2483,5 MHz.
Lớp vật lý PDU là lớp theo chuẩn 802.15.4 với kích thƣớc tải lớn nhất 127 bytes.
b. Lớp liên kết dữ liệu của 6LoWPAN
Lớp liên kết dữ liệu trong 6LoWPAN có các đặc điểm nhƣ sau:
Lớp liên kết dữ liệu cung cấp các dịch vụ cho phép độ tin cậy, các tuyến truyền thông đơn chặng liên kết giữa các thiết bị.
Lớp MAC PDU tuân theo chuẩn 802.15.4.
Các mạng IEEE 802.15.4 không yêu cầu hoạt động ở chế độ truyền phát các bản tin beacon. Trong các mạng không có bản tin beacon, các khung dữ liệu (bao gồm các gói tin IPv6) đƣợc gửi đi theo phƣơng thức truy nhập unslotted CSMA/CA.
Số hóa bởi Trung tâm Học liệu http://www.lrc-tnu.edu.vn/
c. Lớp thích ứng của 6LoWPAN
Lớp thích ứng là thành phần chính của 6LoWPAN.
Chức năng chính đầu tiên của lớp này là nén tiêu đề TCP/IP header. Tệp tiêu đề TCP/IP là quá lớn đối với chuẩn 802.15.4, khi nó có kích thƣớc gói lớn nhất 128 byte; thay vào đó kích thƣớc tiêu đề IPv6 là 40 byte, kích thƣớc tiêu đề UDP và ICMP đều là 4 byte, tiêu đề TCP là 20 byte. Nếu không sử dụng nén thì các thiết bị theo chuẩn 802.15.4 không thể truyền phát đƣợc tải dữ liệu hiệu quả.
Chức năng chính thứ hai của lớp thích ứng là sử lý phân đoạn và tập hợp lại gói. IEEE 802.15.4 có kích thƣớc khung lớn nhất là 128 byte, trong khi IPv6 yêu cầu MTU là 1280 byte. Điều này là không phù hợp vì vậy phải xử lý tại lớp thích ứng.
Chức năng chính thứ ba của lớp thích ứng là định tuyến. Các nút ở biên của mạng cảm biến WSN có thể định tuyến các gói tin IPv6 trong mạng gồm các nút mạng WSN từ bên trong ra bên ngoài mạng IP.
o Các giao thức định tuyến khác nhau của lớp thích ứng đƣợc chỉ ra trong bảng.
Còn có các chức năng khác của lớp thích ứng ở trong mạng liên quan đến một số thứ nhƣ là khám phá nút lân cận và hỗ trợ truyền multicast.
Vấn đề định tuyến đƣợc chia làm hai bài toán trong 6LoWPAN: o Mesh Routing: trong không gian mạng PAN.
o Các tuyến có thể có của các gói tin đến/đi từ mạng IPv6 đi/đến mạng PAN.
Một vài các giao thức định tuyến hiện tại đang đƣợc phát triển bởi cộng đồng 6LoWPAN, đó là LOAD, DYMO-LOW, Hi-Low.
Bảng 2.1. Các giao thức định tuyến trong 6LoWPAN
Giao thức định tuyến
Mô tả
Số hóa bởi Trung tâm Học liệu http://www.lrc-tnu.edu.vn/
là một giao thức định tuyến theo yêu cầu đơn giản dựa trên AODV [RFC3561] cho mạng 6LoWPAN. Thuật toán định tuyến dựa vào vector khoảng cách AODV là một giao thức định tuyến đƣợc thiết kế cho các mạng adhoc di động
AODV có khả năng định tuyến theo cả unicast và multicast. Nó là một thuật toán định tuyến theo yêu cầu, nghĩa là nó dựng lên các tuyến giữa các nút duy nhất đƣợc mong muốn bởi nút nguồn
DYMO Low Thuật toán định tuyến theo yêu cầu động MENET On- demand (DYMO) cho giao thức định tuyến 6LoWPAN có ý định cho các nút di động trong mạng vô tuyến không dây đa chặng
Hi-Low Giao thức định tuyến phân cấp dựa trên địa chỉ 16 bit ngắn của mạng 6LoWPAN
d. Lớp mạng của 6LoWPAN
Lớp network layer trong 6LoWPAN có các đặc điểm chính nhƣ sau: Nó cung cấp khả năng tƣơng tác liên mạng giữa các nút cảm biến. Yêu cầu đánh địa chỉ IPv6 cho các node.
Các dịch vụ bảo mật thích hợp. Các suy xét định tuyến.
Quản lý mạng với SNMP (Simple Network Management Protocol).
e. Lớp giao vận của 6LoWPAN
Lớp giao vận chịu trách nhiệm cho việc phân phát dữ liệu đến các tiến trình ứng dụng thích hợp trên máy chủ.
Một vài giao thức lớp giao vận là UDP và TCP.
f. Lớp ứng dụng của 6LoWPAN
Lớp ứng dụng trong 6LoWPAN có các đặc điểm chính nhƣ sau: 6LoWPAN quy định các ứng dụng sử dụng giao diện socket.
Số hóa bởi Trung tâm Học liệu http://www.lrc-tnu.edu.vn/
Các ứng dụng
o Các thiết bị giám sát sức khỏe o Giám sát môi trƣờng
o Bảo mật
o Tòa nhà thông minh o Tòa nhà tự động
2.2. Công nghệ truyền thông lớp ứng dụng hoạt động trên mạng có năng lƣợng hạn chế - CoAP (Constrained Application Protocol)
(Representational State Transfer) trong web.
-
(ví dụ -
(ví dụ nhƣ mạng 6LoWPAN, mạng cảm biến không dâ
– o tìm hiểu cách thứ
Số hóa bởi Trung tâm Học liệu http://www.lrc-tnu.edu.vn/ 2.2.1. Đặc điểm : 2M. . . . . . . (Datagram Transport Layer Security - DTLS).
2.2.2. Kiến trúc CoRE
CoRE là một nhóm làm việc của IETF, nhóm này xác định giao thức CoAP dựa trên kiến trúc REST. Phần này sẽ trình bày tổng quan về kiến trúc REST cũng nhƣ các thành phần và chức năng nhiệm vụ của nó.
REST mô tả giao thức truyền thông client-server và có bộ nhớ cache, nhƣ là HTTP, để tạo ra các cuộc gọi đơn giản giữa các thiết bị. Kiểu kiến trúc REST bao gồm các Client và server. Clients khởi tạo các yêu cầu tới server. Server xử lý các yêu cầu này và trả về các đáp ứng thích hợp. Các yêu cầu và đáp ứng đƣợc xây dựng dựa trên việc chuyển giao đại diện của các tài nguyên. Dƣới đây là các thành phần chính của một kiến trúc REST:
Resources: Phần lớn đƣợc định danh bởi URI (Uniform Resource
Identifier). Resources có thể làđịa chỉ Web, tài nguyên vật lý hoặc đơn giản là văn bản nằm ở một nơi nào đó trên server.
Số hóa bởi Trung tâm Học liệu http://www.lrc-tnu.edu.vn/
Represendentations: Để thao tác với resources. Representations định nghĩa
định dạng của resource. Các Representations điển hình là HTML, XML hoặc JSON.
Methods: Cho phép Clients lấy ra, sửa đổi hoặc xóa các tài nguyên bằng
cách sử dụng các đại diện của chúng. Các hoạt động/phƣơng pháp cơ bản trên tài nguyên là GET, PUT, POST và DELETE.
Hình 2.2. Kiến trúc REST.
Sử dụng các dịch vụ Web trên Internet phụ thuộc vào kiến trúc REST. RESTful là giao thức truyền tải đơn giản để phục vụ các requirements cho môi trƣờng giới hạn tài nguyên. Hỗ trợ URI: ví dụ nhƣ coap://fec0::1:61616/temp. 4 bytes tiêu đề cơ bản, tùy chọn TLV, với 1- 270 bytes/option. Cổng mặc định là 5683.
Số hóa bởi Trung tâm Học liệu http://www.lrc-tnu.edu.vn/ Hình 2.3. Ví dụ minh họa về kiến trúc RESTful cho WSNs.
Hình 2.3 minh họa một end-to-end IP dựa trên kiến trúc dịch vụ web
RESTful để tích hợp các thiết bị hạn chế tài nguyên với Web. Kiến trúc trên cho phép thực hiện cùng thiết kế giao diện trên HTTP và CoAP vì cả hai giao thức đều thực thi theo mô hình REST.
Để một client của giao thức này có thể truy nhập tới tài nguyên của một server của một giao thức khác thì một thiết bị đang cung cấp qua việc ánh xạ giao thức HTTP CoAP và HTTP-CoAP cross-protocol proxy (HC proxy) là cần thiết.
2.2.3. Mô hình giao thức CoAP
.
: Confirmable, Non-confirmable, Acknowledgment, Reset
Confirmable Non-confirmable
Số hóa bởi Trung tâm Học liệu http://www.lrc-tnu.edu.vn/ . a. . . Confirmable confirmable (ví dụ Confirmable ứ Reset . Hình 2.5 B .
Số hóa bởi Trung tâm Học liệu http://www.lrc-tnu.edu.vn/ Non-confirmable ID message Non-confirmable (RST). . . . b. /Response . .
Số hóa bởi Trung tâm Học liệu http://www.lrc-tnu.edu.vn/ .
.
.
Số hóa bởi Trung tâm Học liệu http://www.lrc-tnu.edu.vn/ . , PUT . c. . . , -
Số hóa bởi Trung tâm Học liệu http://www.lrc-tnu.edu.vn/
- .
2.2.4. Phân lớp ngăn xếp giao thức CoAP
Hình 2.10. So sánh ngăn xếp giao thức HTTP(a) với CoAP(b).
Mặc dù HTTP đƣợc sử dụng rộng rãi với dịch vụ Web, điều đó không có nghĩa nó là giao thức duy nhất cho các giao tiếp M2M. Vào tháng 6 năm 2010, nhóm cộng tác Internet Engineering TaskForce (IETF) Constrained RESTful Environments (CoRE) đề xuất bản dự thảo đầu tiên của giao thức truyền web RESTful gọi là Constrained Application Protocol (CoAP). CoAP bao gồm các chức năng HTTP đã đƣợc thiết kế lại cho M2M ứng dụng trên môi trƣờng hạn chế tài nguyên trong IoT, có nghĩa là nó sẽ đƣa vào các thiết bị nhúng (nhƣ cảm biến) thông tin về khả năng xử lý thấp và hạn chế năng lƣợng. Ngoài ra, CoAP cùng một số tính năng mà HTTP không có, chẳng hạn nhƣ xây dựng cơ chế phát hiện tài nguyên, hỗ trợ multicast IP, native push model, và trao đổi bản tin không đồng bộ.
Tổ chức ISO đã xác nhận mô hình tham chiếu OSI 7 lớp. Trong phần này sẽ giới thiệu qua các lớp của mô hình OSI và mô tả làm thế nào ngăn xếp giao thức CoAP khắc phục đƣợc những thách thức của IoT so với một chồng giao thức HTTP điển hình.
Số hóa bởi Trung tâm Học liệu http://www.lrc-tnu.edu.vn/
a. Tầng vật lý và tầng liên kết dữ liệu
Mạng không dây là rất cần thiết cho IoT vì nối dây cho các cảm biến là quá tốn kém. Tiêu chuẩn IEEE 802.15.4 quy định lớp vật lý và truy nhập môi trƣờng truyền (MAC) cho mạng cá nhân không dây công suất thấp (LR- WPANs), trong đó tập trung vào truyền thông với mức tiêu thụ điện năng thấp, chi phí thấp, và tốc độ truyền dữ liệu thấp giữa các thiết bị hạn chế tài nguyên.
b. Tầng mạng
Tiêu chuẩn 6LoWPAN, đƣợc định nghĩa bởi IETF, cung cấp giao thức IP cho thiết bị nhúng (ví dụ, cảm biến) kể cả mạng hạn chế về tài nguyên, ví nhƣ IEEE 802.15.4. Ngoài 6LoWPAN, nhóm cộng tác IETF Routing over Low Power and Lossy Networks (ROLL) đã xác định IPv6 Routing Protocol for Low Power and Lossy Networks (RPL) kết nối mạng các đối tƣợng thông minh. Các công nghệ mạng này cung cấp phƣơng tiện cho các thiết bị nhúng tích hợp vào mạng Internet.
c. Tầng vận chuyển
HTTP dựa trên giao thức Transmission Control Protocol(TCP), trong đó có vấn đề hiệu suất mạng tổn hao năng lƣợng thấp (LLNs), nhạy cảm với di chuyển, không hỗ trợ multicast, và có chi phí giao dịch cao. Mặt khác, CoAP cũng đƣợc xây dựng trên giao thức UDP, cung cấp chi phí thấp hơn đáng kể và hỗ trợ multicast.
d. Tầng ứng dụng
Nhƣ đƣợc mô tả trƣớc đó, CoAP cung cấp dịch vụ web RESTful đƣợc tối ƣu hóa cho mạng và các thiết bị hạn chế tài nguyên, và do đó làm cho các giao thức phù hợp với các ứng dụng IoT và M2M. Ngoài ra, nó cung cấp các cơ chế tin cậy (với thời gian chờ và truyền lại mặc định theo cấp số nhân) ngay cả khi không sử dụng TCP ở lớp vận chuyển. Đây là một trong những mục tiêu thiết kế quan trọng nhất của CoAP cũng là để giữ cho chi phí thông tin càng nhỏ càng tốt. HTTP cũng có thể đƣợc sử dụng 6LoWPAN. Tuy nhiên, kết quả cho thấy rằng điện năng tiêu thụ và số byte đƣợc truyền tải trên mỗi giao dịch thấp hơn đáng kể
Số hóa bởi Trung tâm Học liệu http://www.lrc-tnu.edu.vn/
nếu sử dụng CoAP 6LoWPAN thay cho HTTP 6LoWPAN, và do đó tăng tuổi thọ pin của thiết bị bị hạn chế về tài nguyên.
e. Dữ liệu (payload)
Định dạng W3C Efficient XML Interchange (EXI) là một đại diện Extensible Markup Language (XML) rất nhỏ gọn và hiệu suất cao, trong đó có thể yêu cầu giảm băng thông đáng kể mà không ảnh hƣởng đến hiệu quả sử dụng các tài nguyên khác, chẳng hạn nhƣ tuổi thọ pin, kích thƣớc mã, khả năng xử lý, và bộ nhớ. EXI có kích thƣớc nhỏ hơn 97% XML tƣơng đƣơng. Nó là một lựa chọn hợp lý để đƣợc sử dụng trên 6LoWPAN và mạng hạn chế tài nguyên.
2.2.5. ). . – . 2.2.6. CoAP.
Số hóa bởi Trung tâm Học liệu http://www.lrc-tnu.edu.vn/ : - - confirmable” CON. confirmable non-confirmable”. a. . b. confirmable . ). (ACK_TIMEOUT
Số hóa bởi Trung tâm Học liệu http://www.lrc-tnu.edu.vn/ * ACK_RANDOM_ FACTO . c. . non-confirmable . d. n tin - . ) bên trong EXCHANG .
Số hóa bởi Trung tâm Học liệu http://www.lrc-tnu.edu.vn/ . G . Confirmable Non-confirmable Confirmable Non-confirmable. e. timeout Confirmable Confirmable : . . f.
Số hóa bởi Trung tâm Học liệu http://www.lrc-tnu.edu.vn/ bên 1024 byte. g. 1. h. : 2.2.7. /Response .
Số hóa bởi Trung tâm Học liệu http://www.lrc-tnu.edu.vn/ a. . . b. ng .
Response Code Registry.
.
:
– .
Số hóa bởi Trung tâm Học liệu http://www.lrc-tnu.edu.vn/
– .
.
2.2.8.
4.05 (Method Not Allowed).
GET Accept Option, - . POST . PUT
Số hóa bởi Trung tâm Học liệu http://www.lrc-tnu.edu.vn/ -Type Option. DELETE công . 2.2.9. . . 2.2.9.1. Cơ chế bảo mật DTLS - tin UDP.
Số hóa bởi Trung tâm Học liệu http://www.lrc-tnu.edu.vn/ ủa cơ chế bảo mật DTLS
. Khi quá trình bắt tay DTLS khởi tạo xong, DTLS thêm vào một khối độ lớn 13 bytes trên mỗi datagram, nó không bao gồm bất kỳ sự khởi tạo vector/nonce nào (ví dụ, trƣờng TLS_PSK_WITH _ARES_128_CCM_8[I-D.mcgrew-tls-aes-ccm] độ dài 8-bytes), các giá trị kiểm tra toàn vẹn (ví dụ, trƣờng TLS_PSK_WITH_ARES _128_CCM_8 [I- D.mcgrew-tls-aes-ccm] độ dài 8 bytes) và đƣợc điền thêm vào bởi một mã hóa phù hợp. Khi nào và chế độ nào sử dụng DTLS là khả thi cho các ứng dụng chạy dựa trên giao thức CoAP cần phải đƣợc tính toán cẩn thận có xem xét đến các mã hóa phù hợp khả thi, và khi cơ chế duy trì phiên làm nó tƣơng thích với các luồng ứng dụng và các tài nguyên đầy đủ là có sẵn trên các nút tài nguyên bị rằng buộc và cho chi phí mạng đƣợc thêm vào. DTLS không khả thi với nhóm chính (truyền thông multicast); tuy nhiên, nó có thể sẽ trở thành một thành phần trong một nhóm chính trong tƣơng lai của giao thức quản lý.
2.2.9.2. Cơ chế bảo mật IPsec
Một cơ chế bảo mật của giao thức CoAP trong môi trƣờng tài nguyên hạn hẹp đó là IPsec Encapsulating Security Payload (ESP) [RFC4303] khi CoAP
Số hóa bởi Trung tâm Học liệu http://www.lrc-tnu.edu.vn/
đƣợc sử dụng không có sự tham gia của DTLS trong chế độ NoSec Mode. Dùng IPsec ESP với cấu hình thích hợp, nó đƣợc dùng trong nhiều thiết bị tài nguyên hạn chế để hỗ trợ việc mã hóa gắn liền với phần cứng lớp vật lý. Ví dụ, một vài chip theo chuẩn vô tuyến IEEE 802.15.4 tƣơng thích với cơ chế AES-CBC (với các key độ dài 128bit) [RFC3602] nhƣ đã đƣợc định nghĩa từ trƣớc để sử dụng cùng với IPsec trong [RFC4835]. Ngoài ra, đặc biệt về các phần cứng phổ biến theo chuẩn IEEE 802.15.4 hỗ trợ mã hóa AES nhƣng không giải mã, và để tránh việc đệm thêm vào, các nút mạng có thể trực tiếp sử dụng cơ chế AES-CCM đƣợc hỗ trợ rộng dãi nhƣ đã định nghĩa trong [RFC4309].
2.2.10. Chuyển đổi giữa CoAP và HTTP
CoAP hỗ trợ một tập con các chức năng đã đƣợc giới hạn của HTTP và do đó việc ánh xạ sang HTTP là điều đơn giản. Có nhiều lý do để thực hiện việc ánh xạ giữa HTTP và CoAP, ví dụ nhƣ khi thiết kế giao diện web sử dụng qua giao thức hoặc là khi nhận ra một proxy CoAP- HTTP.
Có hai cách ánh xạ bằng cách chuyển tiếp thông qua một proxy:
Ánh xạ CoAP-HTTP: Cho phép các client CoAP truy nhập vào các tài nguyên trên servers HTTP thông qua proxy trung gian. Điều này đƣợc bắt đầu bằng việc bao gồm tùy chọn Proxy-URI với một URI “http” hoặc “https” trong một yêu cầu CoAP tới một proxy HTTP-CoAP.
Ánh xạ HTTP-CoAP: Cho phép các client HTTP truy nhập đến tài nguyên trên server CoAP thông qua proxy trung gian. Điều này đƣợc bắt đầu bằng việc xác định một URI “coap” hoặc “coaps” trong Reques-Line của một