The Constrained Application Protocol for Pervasive Machine-To-Machine Communications (Ràng buộc giao thức ứng dụng cho giao tiế p M2M) I.
Introduction
- Trong Constrained RESTful Environments (CoRE) làm vi ệc trong một nhóm Internet Engineering Task Force (IETF) đượ c đinh nghĩa là vớ i những ràng buộc về những nút và m ạng. - CoAP (Constrain Application Protocol) t ổ chức xung quanh UDP và xây dựng cách truyền lại đơn giản thay vì s ử dụng những cách điều khiển phúc tạp như trong tiêu chuẩn TCP - Thay vào đó sử dụng một Message ID đặc biệt tương quan vớ i CoAP yêu cầu đáp ứng để định danh yêu c ầu truyền lại. - CoAP vớ i mục tiêu là nh ững ràng buộc về băng thông nhỏ và lượ ng ng tin ít, nhưng giao thức tương tự như vậy sẽ đượ c ứng dụng tiêu bi ểu trong M2M ( các thi ết bị di động ) - Short Message Service (SMS) ho ặc General Packet Radio Service (GPRS) - SMS đượ c sử dụng như giao tiế p M2M với năng lương ít và tiêu thụ ng ít năng lượ ng
II. Research Contribution - Giải pháp IP đượ c dựa trên gôm cái nút m ạng cảm biến. - CoAP thu th ậ p dữ liệu cảm biến trong quá trình v ận chuyển - Cấu trúc Intelligent Contaner bao g ồm cái nút m ạng cảm biến và thiết bị truyền thông dung để trao đổi thông tin như nhiệt độ, độ ẩm - Truyền thông tin đến đích vớ i hiệu quả cao hơn - Sử dụng hai cổng của giao th ức , thông tin liên l ạc không độc quyền phổ biến, hiệu quả vớ i các dịch vụ web RESTful đang trở nên nên kh ả
thi đối vớ i truyền thông M2M.
- Hình 1 cho th ấy các cách truy ền thông khác nhau - 1a chỉ ra mô hình M2M, thông tin đầu ở ngườ i sử dụng đượ c truyền bằng đườ ng truyền CoAP vớ i SMS message từ thiết bị truyền thông sau đó được đưa tớ i mạng cảm biến không dây (WSNs) - SMS đượ c chuyển đượ c xử lý bằng 1 SMS-C (SMS- Center) s ử dụng Computer Interface to Message Distribution (CIMD) (Giao diện máy tính phân ph ối tin nhắn) hoặc UCP/EMI.... - 1b ngườ i dùng truy c ậ p thông tin từ các gói đã đượ c chuyển sử dụng 1 thiết bị di động cũng dựa trên SMS - 1c người dùng đang xây dựng CoAP vớ i k ết nối dựa trên GPRS - 1d khi lấy các gói đã đượ c vân chuyển từ warehouse thi ết bị truyền thông có thể đượ c k ết nối và sử dụng WSNs, do đó ngườ i dùng có thể truy cậ p thông tin với CoAP trên địa chỉ IP - CoAP đượ c sử dụng trong Intelligent Container để vận dụng ngườ i tài nguyên (nhiệt độ, độ ẩm) bằng cách s ử dụng phương pháp:
Phục hồi lại nguồn tài nguyên t ừ các nút trong m ạng cảm biến hoặc các thi ết bị truyền thông. Tài nguyên s ẽ được xác định bở i URI (GET method) Sử đổi 1 tài nguyên hi ện có trên nút m ạng cảm biến hoặc thiết bị truyền thông (PUT method)
III. Demonstration
1. CoAP dựa trên 1 SMS v ận chuyển từ thiết bị mạng di động đến 1 thiết bị mạng IP 2. CoAP dựa trên 1 SMS v ận chuyển từ thiết bị mạng IP đến 1 thiết bị mạng IP 3. CoAP trong 1 802.15.4/6LoWPAN/RPL mạng cảm biến không dây sử dụng TelosB vớ i TinyOS và 1 thi ết bị xài Android - Khách hàng CoAP và server có th ể chạy trên các thi ết bị truyền thông, Smart Phone, cũng như các nút mạng cảm biến
Bảng I và II cho thấy nhữ ng nguồn tài nguyên có thể cung cấp cho các nút cảm biến và các thiết bị truyền thông.
Ví dụ, một yêu cầu CoAP GET đượ c phát ra b ở i thiết bị truyền thông có thể đượ c hiển thị để lấy giá tr ị độ ẩm từ một nút cảm biến. Máy chủ CoAP chạy trên nút c ảm biến sẽ gửi phản hồi CoAP vớ i giá tr ị độ ẩm đượ c hỗ tr ợ bở i một tin nhắn ACK.
IV. Technical requirement - Tất cả các thi ết bị phần cứng đượ c yêu cầu chi ti ết về các thi ết lậ p thử nghiệm trong b ảng III
Ngoài ra còn có 1 s ố yêu cầu khác: - Free 802.11 wireless channel - Free 802.15.4 wireless channel
- Several power sockets - Cellular network coverage (at least basic GSM SMS coverage, if possible GSM GPRS coverage) - IP connectivity by Ethernet
A Low-Power CoAP for Contiki
- Các thiết bị Internet of Things s ẽ đượ c vận hành bằng pin, nhưng các giao thức ứng dụng hiện tại thường không đượ c thiết k ế vớ i hiệu suất năng lượ ng cao. - Trong các mạng không dây công su ất thấ p thì hiệu quả năng lượ ng được đánh giá bở i khả năng duy trì năng lương thấ p theo chu k ỳ: giữ radio ngủ càng nhiều càng tốt - CoAP là giao th ức ở lớ p ứng dụng có thể đượ c tạo ra v ớ i hiệu quả năng lượ ng thông qua chu kì c ủa radio I. Introdution - Mạng của những thiết bị không dây c ần các giao th ức hiệu quả về năng lượ ng, tuy nhiên các giao th ức hiện tại thường đượ c thiết k ế mà không có hiệu quả về nó. - Trong các h ệ thống không dây công su ất thấ p, bộ thu phát vô tuy ến thườ ng là thành ph ần tiêu tốn nhiều năng lượ ng nhất, do đó hiệu quả năng lượ ng sẽ chuyển đổi thành chu k ỳ nhiệm vụ hiệu quả của radio: khả năng để giữ cho radio t ắt càng nhi ều càng tốt. - Giao thức mạng phù hợ p là 1 giải pháp cho IoT - IP có thể đượ c sử dụng để truy cậ p tr ức tiế p các thông số cảm biến của 1 thành ph ố, thu thậ p những thông tin cần thiết cho lưới điện thông minh, smart home, nhà máy.... - Chúng tôi đã triể n khai IETF Constrained Application Protocol (CoAP) cho Contiki, cho phép tương tác tạ i lớ p ứng dụng thông qua dịch vụ RESTful Web.
- Hình 1 mô tà s ự tích h ợ p một chồng giao thức đầy đủ và cần thiết cho một IoT và đánh giá hiệu suất năng lượ ng hệ thống từ lớ p ứng dụng.
- Nhu cầu quản lý năng lượ ng tại lớ p ứng dụng bằng cách hạn chế sự quản lý năng lượ ng trên chu k ỳ thức của radio, độ phức tạ p có thể đượ c loại bỏ khỏi lớ p ứng dụng. II. Background A. Power Efficiency through Duty Cycling - Radio thu phát là thi ết bị tiêu tốn nhiều năng lượ ng nhất - Việc lắng nghe các gói tin cũng tiêu tốn như việ c nhận chúng - Để bớ t tiêu t ốn năng lương thì radio thu phát cần phải tắt hầu hết thờ i gian - Radio duty cycling đã đượ c thiết k ế, cho phép các nút ng ủ 99% thờ i gian trong khi v ẫn có kh ả năng nhận và gửi các tin nh ắn. - Giaothức ContikiMAC RDC: ContikiMAC là m ột giao th ức MAC nghe điện năng thấ p sử dụng cơ chế đánh thức có hiệu quả để đạt đượ c hiệu quả cao: vớ i tần số khởi động là 8 Hz, chu k ỳ r ảnh của radio chỉ chiếm 0,6%. - Hình 2 là cơ chế hoạt động của ContikiMAC
- Các nút th ức dậy theo chu k ỳ kiểm tra kênh truy ền để truyền từ các nút lân c ận. Nếu phát hi ện đượ c tín hi ệu radio, nút s ẽ nghe gói tin và khi nhậc đượ c khung dữ liệu sẽ tr ả lại một khung xác nh ận (ACK) - Để gửi gói tin, nút g ửi gửi liên tục các khung d ữ liêu cho đến khi nhận đượ c một ACK, hoặc cho đến khi các gói tin đượ c gửi trong một giai đoạn đánh thứ c toàn bộ mà không nh ận đượ c gói ACK. B. The Constrained Application Protocol - The IETF Constrained Application Protocol (CoAP) là một giao thức tầng ứng dụng đượ c thiết k ế để cung cấ p giao diện giống như REST, nhưng vớ i chi phí th ấp hơn về băng thông và sự phức tạ p của việc triển khai so vớ i giao di ện REST dựa trên HTTP. - CoAP sử dụng các m ẫu từ HTTP như khai thác tài nguyên, các URI, tương tác RESTful, và tiêu đề tùy chọn mở r ộng, nhưng sử dụng các đại diện nhị phân nhỏ gọn đượ c thiết k ế để dễ phân tích. - Không giống như HTTP qua TCP, CoAP sử dụng UDP. Điều này giúp bạn có thể sử dụng CoAP trong các mô hình truy ền thông oneto-many và many-to-one. - Cơ chế của bô máy CoAP: 1) Các ứng dụng có thể gửi các tin nh ắn CoAP tin cậy ("confirmable") ho ặc không đáng tin cậy ("nonconfialable"). Các đối số đượ c truyền lại vớ i thờ i gian chờ cho đến khi đượ c nhận bởi ngườ i nhận hoặc đạt đến số lần phát lại tối đa. 2) CoAP nhằm cung cấ p truyền thông nhóm thông qua IP multicast nhưng cơ chế này vẫn chưa đượ c cụ thể hóa.
CoAP có các thông báo đẩy bản địa thông qua cơ chế publish/subscribe đượ c gọi là "quan sát tài nguyên". Client có th ể gửi một yêu cầu vớ i một tiêu đề tùy chọn quan sát đến một nguồn tài nguyên CoAP. Server theo dõi nh ững người đăng ký này và gửi phản hồi bất cứ khi nào tài nguyên quan sát được thay đổi. 4) Đối vớ i việc phát hiện tài nguyên, CoAP theo RFC 5785 b ằng cách sử dụng đườ ng dẫn /.well-known/core để cung cấ p các mô tả tài nguyên trong CoRE Link Format. Định dạng này mở r ộng Web Linking và xác định các thu ộc tính cho m ột loại ngữ nghĩa ("rt"), cách s ử dụng giao diện ("if"), lo ại nội dung ("ct"), và kích thước mong đợ i tối đa ("sz") của tài nguyên. Ngoài ra, m ột dịch vụ thư mục dượ c dự định. - Khi bộ nhớ RAM cho IP và b ộ đệm ứng dụng bị hạn chế, thiết bị chỉ có thể xử lý một số lượ ng dữ liệu cụ thể trong một thờ i gian. Dữ liệu lớn hơn có thể đượ c xử lý bằng cách lưu trữ các "kh ối" này trong b ộ nhớ fl ash, ví d ụ như để nhận đượ c một phần mềm rmware mớ i hoặc cung cấ p một datalog đầy đủ. Để tránh sự cần thiết của một giao thức thứ cấp để trao đổi những dữ liệu này, CoAP chỉ định một cơ chế ngừng và chờ đơn giản gọi là "phép chuy ển khối" 3)
III. A Low-Power CoAP For Contiki A. The Contiki REST Engine - Là một sự cải thiện của Contiki’s REST layer - Nó cung cấp các macro để xác định và tự động khở i tạo nguồn tài nguyên RESTful Web. - Công cụ REST mớ i cung cấ p ba khái niệm tr ừu tượng để tạo các nguồn RESTful: RESOURCE: Đối vớ i mỗi tài nguyên, ứng dụng phải cung cấ p một hàm xử lý tài nguyên nh ận đượ c yêu cầu và tạo ra phản hồi tương ứng. Cả những message đượ c truy cậ p thông qua REST Engine API EVENT_RESOURCE: Yêu cầu một hàm điều khiển thứ hai đượ c thực hiện bở i nhà phát tri ển ứng dụng. PERIODIC_RESOURCE: REST Engine định k ỳ gọi một chức năng điều khiển thứ hai tương tự vớ i một cho các s ự kiện. Chức năng này có thể đượ c sử dụng để thăm dò các cảm biến on-board và ví d ụ thực hiện kiểm tra ngưỡ ng cho dù tài nguyên có nên được xem là đã thay đổi hay không.
- Cuối cùng, một ứng dụng dịch vụ RESTful Web điển hình bao g ồm một C-fi duy nh ất. Nó ch ứa các macro tài nguyên cùng v ớ i các ch ức năng xử lý của chúng và một quy trình Contiki kh ở i tạo REST Engine, kích ho ạt các tài nguyên và tùy ch ọn chờ đợ i cho các s ự kiện của ngườ i dùng cho b ất k ỳ EVENT_RESOURCE nào. B. Blockwise Transfers - CoAP thực hiện hỗ tr ợ truyền các Blockwise - Nếu một phản hồi đượ c tạo ra b ở i một trình xử lý tài nguyên vượ t quá kích thướ c khối yêu cầu của khách hàng, thì REST Engine s ẽ tự động chia câu tr ả lờ i mà không c ần sự tham gia của trình xử lý. C. Observing Resources D. Separate Responses - Một vài nguồn tài nguyên có th ể yêu cầu xử lý thờ i gian dài ho ặc đợ i tài nguyên từ phần cứng như một cảm biến chậm, trong một khoảng thời gian không xác định. - Điều này là không c ần thiết cho sự truyền lại hoặc tr ả lờ i lại timeout - Vì vậy, CoAP cung cấp “phản hồi riêng bi ệt”, cho phép máy chủ gửi ACK tr ống ngay lậ p tức và một thông báo có th ể bị xóa khi hoàn thành.
- Cung cấ p một trình xử lý tiền xử lý sự cố ACK và xác nh ận phản ứng thực tế vớ i ID và ki ểu tin nhắn mớ i. E. Resource Discovery F. CoAP Clients - Công cụ REST giúp vi ệc triển khai các ứng dụng CoAP dễ dàng. Mô hình lậ p trình tuyến tính này cũng có thể ẩn các phép chuy ển khối, bở i vì nó tiế p tục khi tất cả dữ liệu đượ c nhận. G. Message Deduplication - Quá trình th ực hiện hiện nay đượ c thực hiện sau khi xem xét các quy định của CoAP để thư giãn lặ p lại. Contiki được định nghĩa là các thiết bị bị hạn chế về bộ nhớ . Ở đây, việc quản lý một số địa chỉ Internet IPv6 sẽ gây ra m ột chi phí quá l ớ n trong khi chỉ các yêu c ầu thườ ng. H. Memory Management - Hợp tác đa luồng của Contiki cho phép chúng tôi cung c ấ p truy cậ p vào các t ải tr ọng và các chu ỗi byte (ví d ụ như ETag, nhưng cũng phân tích cú pháp các biến truy vấn) tr ực tiế p trong bộ đệm IP. - Đối vớ i thế hệ phản hồi, REST Engine c ủa chúng tôi t ổ chức các b ộ đệm cho các trình x ử lý tài nguyên. Các b ộ đệm đượ c sử dụng lại để tuần tự hóa các thông điệ p CoAP tại chỗ và lưu trữ các điều kiện để truyền lại. - REST Engine cho phép các nhà phát tri ển xác định kích thướ c khối cần thiết cho ứng dụng của họ và sau đó kích thướ c các bộ đệm yêu cầu cho phù h ợ p. IV.
EVALUATION Đánh giá cả tính năng tĩnh và độ ng của CoAP năng lượ ng thấ p của chúng tôi: d ấu chân b ộ nhớ , tiêu thụ năng lượng và thông lượ ng dữ liệu. A. Experimental Setup - Chạy các thí nghi ệm trên Tmote Sky sensor motes. N ền dựa trên MSP -bit CPU ch ạy tại 3.9MHz. Cung c ấ p 1 CC2420 radio chip, 48kB bộ nhớ flash và 10kB RAM
- Sử dụng giao thức ContikiMAC và cài đặt chu k ỳ thức là 8Hz, tương ứng vớ i chu k ỳ nhàn r ồi là 0.6%. - Các k ết quả hiển thị đượ c tính trung bình trên 100 l ần chạy và các thanh báo lỗi hiển thị độ lệch tiêu chuẩn. Chúng tôi đặc trưng tiêu thụ năng lượ ng motes qua s ản phẩm tích hợ p sẵn của Contiki Powertrace B. Memory Footprint - Bảng I cho th ấy dấu chân chi ti ết của việc triển khai CoAP của chúng tôi đối vớ i Contiki.
- Code đượ c biên dịch vớ i msp-430-gcc (GCC) 3.2.3 cho Tmote Sky. - Tất cả việc thực thi yêu c ầu 8.5 kB ROM và 1.5 kB RAM ( Heap cộng vớ i stack tối đa được đo cho tất cả các chức năng liên quan đến CoAP và REST ). - CoAP-07 vận chuyển module đòi hỏi số lượ ng RAM lớ n nhất, vì nó cung cấ p các bộ đệm thông báo đã đề cậ p. Với các cài đặt mặc định đượ c sử dụng, có thể lưu trữ đượ c bốn thông điệ p có thể chứa đượ c với kích thướ c 128 byte. - Đượ c tách riêng kh ỏi giao th ức và chỉ sử dụng API REST Engine, mã ứng dụng là nhỏ gọn. Một ứng dụng RESTful vớ i các ngu ồn tài nguyên như đã đượ c mô tả trong Bảng II chỉ tiêu thụ 1.5 kB ROM và 160 B heap.
-
Đối vớ i việc thực hiện một hệ thống IoT trên các thi ết bị nhớ , kích thướ c lớ n nhất đượ c hỗ tr ợ. CoAP block size là m ột tham số thiết k ế
trung tâm. - Do kích cỡ khối mũ của CoAP từ 16 đến 1024 byte, các bướ c trên 128 byte dường như quá thô và do đó hạn chế không gian thi ết k ế. Nó sẽ tr ở nên khó khăn để tối ưu hóa bộ nhớ phân phối giữa các thành phần hệ thống khác nhau và để điều chỉnh các nguồn tài nguyên phần cứng khác nhau.
-
-
-
-
C. Energy Consumoption Để đánh giá sự cân bằng giữa mức tiêu th ụ năng lượ ng và thờ i gian tr ễ, chúng tôi đã thiết lậ p một thử nghiệm trong đó chúng tôi đưa ra yêu cầu về các động cơ khác nhau trong mạng 4 kênh c ủa chúng tôi, vớ i ContikiMAC b ị vô hiệu hóa và b ật (0.6% RDC). Tài nguyên CoAP đượ c yêu cầu tr ả lờ i bằng một token 2 byte và m ột tải tr ọng 64 bytes. Hình 4a cho th ấy biểu đồ năng lượ ng của tất cả các nút liên quan đến quá trình xử lý. Nó bao g ồm các nút chuy ển tiếp cũng như máy chủ CoAP đượ c chỉ định. Như mong đợ i, ContikiMAC tiết kiệm đượ c nhiều năng lượ ng, reaching an improvement by a factor of 26 compared to no duty cycling ( ko hi ểu khúc này nó nói gì ). Hình 4b cho th ấy r ằng các hình ph ạt của chu k ỳ nhiệm vụ về độ tr ễ là chấ p nhận đượ c vớ i một chu k ỳ nhiệm vụ dướ i mức 1%. Giảm chậm nhất là v ề yếu tố 6, giữ độ tr ễ dướ i 1 giây trên 4 hops.
-
-
-
-
D. Transmitting Large Data Không phải tất cả các đại diện của tài nguyên CoAP đều có thể đượ c cấu thành trong một khung 802.15.4, vì v ậy cần phải phân mảnh hoặc chuyển giao theo chi ều hướ ng 6LoWPAN. Chi phí năng lượ ng của việc chuyển đổi theo khối lượ ng chỉ đơn giản là tương ứng vớ i nhiều yêu cầu với kích thướ c payload đượ c điều chỉnh cho tùy ch ọn Block2 header b ổ sung. Để cho phép truy ền hiệu quả năng lượ ng các khung liên ti ế p, chúng ta sử dụng bursts lớ p liên k ết. Khi sender có các frames để gửi, đầu tiên nó sẽ đánh thức neighbor b ằng một bộ điều khiển ContikiMAC và đặt là “frame pending” bit trong 802.15.4 để cho receiver bi ết và frame tiế p sẽ làm theo. Khung con lại đượ c gửi liên ti ếp và đượ c nhận bởi ngườ i nhận cho đến khi bit tạm dừng, khung đượ c bỏ cài đặt. Hình 5 cho th ấy mức tiêu th ụ năng lượng tích lũy của tất cả các nút tham gia vào yêu c ầu (chuyển tiế p và máy ch ủ) và độ tr ễ đáp ứng yêu cầu. Loại thứ 2 gần như không bị ảnh hưở ng bở i 6LoWPAN phân mảnh do các khung v ỡ (??)
- Tuy nhiên, sự gia tăng tiêu thụ năng lượng rõ ràng là đáng chú ý đối vớ i fragment bổ sung đầu tiên (trong c ấu hình ở 70 byte cho 4 hops và 79 byte cho 1 và 2 hops). - Hơn nữa, chúng tôi có độ lệch sai số chuẩn lớ n do ch ất lượ ng liên k ết có độ thay đổi r ất cao: thử nghiệm đã đượ c thực hiện và các động cơ bị nhiễu WiFi. Khi mất gói tin x ảy ra, ContikiAC ddowngiarn truyền lại gói khung cho đế n khi nhận đượ c ACK. - Do môi trườ ng bị mất mát này nên t ổng số khung đượ c gửi phụ thuộc nhiều hơn vào chất lượ ng liên k ết cục bộ so vớ i phân mảnh. E. Optimizing Separate Responses - Kiểm tra khả năng chia cắt đáp ứng để giảm năng lượ ng bằng cách tránh sự truyền lại. - We targeted a mote 4 hops from the border router.
- Tài nguyên CoAP mất một khoảng thời gian để xử lý yêu c ầu, từ 1 đến 24 giây. Chúng tôi đã kiểm tra hai c ấu hình CoAP khác nhau: đầu tiên không s ử dụng các phản hồi riêng biệt, thứ hai là có. - Hình 6 cho th ấy năng lượ ng tiêu th ụ bở i các mote ph ụ thuộc vào sự chậm tr ễ đáp ứng phía máy ch ủ, không có và có ph ản ứng riêng biệt. Biểu đồ tiêu th ụ tăng tuyến tính vớ i sự chậm tr ễ do chu kì nghe radio không hoạt động.
- Sau khoảng 10 giây, hai đường cong đi qua: tại thời điểm này, ph ản hồi riêng b ắt đầu tiết kiệm năng lượng. Trước điểm đó, cơ chế tiết kiệm năng lượ ng nhiều hơn sơ vớ i ACK. - Việc tối ưu hóa bằng các ph ản hồi riêng bi ệt là không đáng kể. Tuy nhiên, lưu ý rằng đối vớ i các yêu c ầu dài hơn, cơ chế này là c ần thiết để tránh yêu c ầu hủy bỏ.