Mạng cảm biến không dây trên nền kiến trúc ip phần 2

Chương IPv6 CHO MẠNG CẢM BIẾN KHÔNG DÀY Trong thời gian qua, có số sách xuất bàn viết IPv6 Chương sê giới thiệu ứng dụng IPv6 cho mạng cảm biến không dây Để có thơng tin chi tiết ứng dụng IPv6 cho mạng cảm biến không dây, bạn đọc cỏ thể tìm hiểu thêm tài liệu RFC IPvỏ quy định bời IETF IPv6 đóng vai trò tảng kiến trúc "Internet o f Things" nói chung mạng cảm biến khơng dây nói riêng Chương giới thiệu số động lực thúc đẩy cùa việc lụa chọn IPv6 cho mạng cảm biến không dây 4.1 GIỚI THIỆU VÈ IPv6 IPv6 đóng vai trị quan trọng mạng cảm biến không dây kiến trúc IP IPv6 hoàn toàn theo nguyên tắc kiến trúc cùa IP EPv6 chi phiên bàn IP nhằm giải số hạn chế IPv4 Mặc dù có số hạn chế IPv4 đạt thành công lớn IPv4 chắn hoạt động năm tới nhà thiết kế IPv6 phát triển loạt chế nhằm cho phép chuyển đổi dễ dàng từ IPv4 sang IPv6 Một số đặc điểm IPv6 bao gồm: • 98 K hơng gian đ ịa lớn đáp ứng yêu cầu đổi với m ạn g có quy mơ lớn: Mặc dù số trường hợp ứng dụng, mạng cảm biến khơng dây chì bao gồm vài chục nút Tuy nhiên, số trường hợp ứng dụng khác số lượng nút cảm biến lên tới vài trăm ngàn nút Với cạn kiệt địa chi IPv4 IPv6 lựa chọn tất yếu Với việc mờ rộng không gian địa chi từ 32 bit lên 128 bit IPv6 cho phép lượng lớn không gian địa chi dành cho nút cảm biến với cỗ nhiều mức phân cấp địa chi đặc điẻm tự động cấu hình Nhưng khơng phải lý cho việc lựa chọn IPv6 • T ự động cấu hình: Đối với mạng có quy mơ lớn việc qn lý (bao gồm việc dự phịng, cấu hình, qn lý lỗi, thong kê, phân tích hiệu năng) trở nên khó khăn Do vậy, việc thiết lập tính tự động cấu hình IPv6 lý khác dẫn đến việc sừ dụng IPv6 mạng cảm biến không dây • Sự thay đổi tiêu đề: Một số trường tiêu đề IPv4 khơng sử dụng loại bỏ (ví dụ phân mành, tồng kiểm tra, ) cấu trúc đơn giàn với tiêu đề cố định thêm vào tiêu đề m rộng tùy chọn Các trường thêm vào (ví dụ trường nhãn luồng) • Nhận thực bảo m ật: Các phần mở rộng định nghĩa nhằm hỗ trợ việc nhận thực, tính tồn vẹn bảo mật liệu • V ấn đề an ninh: IPSec (tùy chọn IPv4) bắt buộc IPv6 4.2 CÁC TIÊU ĐỀ GÓI TIN IPv6 4.2.1 Tiêu đề IPv6 cố định (IPv6 Fixed Header) Cách tốt để bẳt đầu học giao thức nên tìm hiểu trường tiêu đề gói tin Định dạng tiêu đề gói tin IPv6 minh họa hình Varsion I Traff*c d a ss I Paytoad length Flow label I Next header Hop Hmit Source address * '' Destination address Hình 4.1: Đinh dạng tiẽu đề gỏi tin IPv6 99 Các trường tiêu đề gói tin IPv6 bao gồm: - Version (4 bit): IP phiên bàn - Traffĩc class (8 bit): Trường bit dùng để xác định lớp dịch vụ (Class o f Service) cùa gói tin - Flow label (20 bit): Nhãn luồng sừ dụng bời nút nguồn để tham chiếu đến chuỗi gói tin nhàm xác định luồng mà địi hỏi việc xừ lý gói tin riêng biệt bời định tuyến dọc theo tuyến đường tới đích Nhãn luồng nên tạo ngẫu nhiên để hỗ trợ việc thực chức khóa băm định tuyến trung gian Giả thiết thời điểm nút nguồn không sử dụng giá trị nhãn luồng cho hai luồng khác Lưu ý rằng, việc sử dụng trường chủ yếu thứ nghiệm - Payload length (16 bit): Trường chì độ dài tải trọng (khơng bao gồm tiêu đề gói tin) Chú ý độ dài tiêu đề mờ rộng có độ dài tải trọng - Next header (8 bit): Trường nhận dạng tiêu đề theo sau tiêu đề gói tin IPv6 Điều tạo linh hoạt việc thêm vào tiêu đề tùy chọn sừ dụng chuỗi tiêu đề nối tiếp - Hop limit (8 bit): Trường giảm sau lần gói tin chuyển tiếp nút mạng Khi trường gói tin bị loại - Source Address: Gồm 128 bit địa chi nguồn gói tin IPv6 - Destination Address: Gồm 128 bit địa chi đích gói tin IPv6 Qua đó, thấy tiêu đề gói tin IPvó cố định (khơng có tùy chọn) có độ dài 40 byte so với tiêu đề 20 byte gói tin IPv4 Độ dài tiêu đề gói tin tăng lên trở ngại mạng cảm biến không dây sử dụng chuẩn truyền thông vật lý IEEE 802.15.4 Đây lý nhóm làm việc 6LoWPAN quy định chế nén tiêu đề khác nhằm giảm kích thước tiêu đề Trái ngược với IPv4, khơng có trường tổng kiểm tra tiêu đề gói tin IPv6 N hư tất giao thức lớp giao vận phải tính tốn tổng kiêm tra có tính đến tiêu đề gói tin IPv6 Điều thực UDP Do vậy, tổng kiểm tra UDP (tùy chọn IPv4) bát buộc 100 IPv6 Đối với IPv4, tất giao thức lớp cao sử dụng 32 bit địa IPv4 để tính tốn tổng kiểm tra chúng Vì giao thức cần thay đổi để sử dụng 128 bit địa chi IPv6 4.2.2 Tiêu đề mở rộng (Extended Header) IPv6 có tiêu đề cố định theo sau chuỗi nối tiếp tiêu đề tùy chọn gọi tiêu đề m rộng Các tiêu đề tùy chọn theo sau tiêu đề cố định đứng trước tiêu đề lớp giao vận Giá trị trường tiêu đề chì đom giản để xác định loại tiêu đề theo sau Chúng ta quan tâm đến ví dụ m inh họa hình 4.2 Trong trường hợp đầu tiên, giá trị trường tiêu đề 6, chi tiêu đề TCP theo sau tiêu đề cố định (khơng có tiêu đề mở rộng trường hợp đơn vị liệu gói tin lớp giao vận PDƯ theo sau tiêu đề cố định) Trong trường hợp thứ ba có ba tiêu đề m rộng theo sau tiêu đề IPv6 cố định tạo thành chuỗi nối tiếp Giá trị tiêu đề IPv6 43 tiêu đề m rộng tiêu đề định tuyến Ta thấy tiêu đề chứa m ột trường tiêu đề với giá trị 51 cho biết diện tiêu đề nhận thực Case 1: no extended header Next header = 6(TCP) n TCP header + payload ĩ a S S 5i Case 2' with a routing header - £9 ■~T4ềề^ấ Next header = 43{rout!ng) Next header s (TCP) TCP header * payload Case 3: vvith a routing headerand authentication headers Hình 4.2: M ột tiêu đề IPv6 m rộng 101 Tiêu đề lóp giao vận quy định giá trị (ám đên TCP) trirờng tiêu đề tiêu đề nhận thực Cơ chế tạo kiến trúc linh hoạt chi thêm tiêu đề cần thiết Lưu ý ràng tiêu đề phải xuất theo thứ tự rõ ràng không xử lý bời định tuyến trung gian dọc theo tuyến đường liệu ngoại trừ tiêu đề tùy chọn bước nhảy (hop-by-hop) Tiêu đê bước nhảy tiêu đề cần phải xử lý tất định tuyến dọc theo tuyển đường từ nguồn đến đích Đỏ lý xuất hiện, phải theo sau tiêu đề cố định (sự có mặt chi định giá trị trường tiêu đề cúa tiêu đề cố định) Tất cà việc triển khai IPv6 phải hỗ trợ tiêu đề mở rộng sau đây: - Các tùy chọn bước nhảy - Định tuyến (loại 0) - Phân mành - Các tùy chọn điểm đến - Nhận thục - Đóng gói tải bảo mật (Encapsulating security payload) Các tùy chọn tiêu đề: Có hai tiêu đề mờ rộng (tiêu đề tùy chọn bước nhày tiêu đề tùy chọn điểm đến) mang số giá trị tùy chọn định dạng TLVs (Type-Length-Values) thay đổi cho phép xác định số tùy chọn cho tiêu đề Trường nhận dạng kiểu tùy chọn (giá trị T - 8bit) xác định kiều tùy chọn hai bit thứ tự cao để xác định mà nút thực tùy chọn không nhận bỏ qua, âm thầm loại bò, loại bỏ gửi gói tin ICMP (Internet Control Message Protocol), Bit cao thứ xác định xem liệu dừ liệu tùy chọn thay đổi dọc theo tuyến đường liệu hay không Trường độ dài (giá trị L - bit) xác định độ dài liệu tùy chọn tính bàng đơn vị octet 4.2.3 Tiêu đề tùy chọn buóc nhảy (Hop-by-Hop Option Header) Các tiêu đề tùy chọn bước nhảy sứ dụng để mang thông tin bồ sung phải xử lý bời tất cá định tuyến dọc theo tuyến đường gói tin bao gồm nguồn đích đến cùa gói tin IP cấu trúc cùa mơ tả hình 4.3 Ta thấy bit xác định tiêu đề kế 102 tiếp, theo sau m ột trường bit xác định độ dài tài trọng không bao gồm bit đâu tiên, theo sau tải trọng có độ dài thay đổi bao gồm tập hợp giá tri chọn định dạng TLVs 4.2.4 Tiêu đề định tuyến (R outing Header) Tiêu đề định tuyến sừ dụng để xác định tập họp nút mà gói tin phải qua dọc theo tuyến đường đến nút đích Hai trường hoàn toàn giống với hai trường tiêu đề tùy chọn bước nhảy Trường segm ent left cho biết số đoạn đường lại trước đến nút đích Trường type-specific data trường có độ dài thay đổi loại định tuyến xác định giá trị trường loại định tuyến (routing type) M ột ví dụ cụ thể tiêu đề định tuyến loại trình bày hình 4.3 Tiêu đề định tuyến loại chì mang địa chi unicast Việc xử lý tiêu đề định tuyến cần phải quan tâm bời khơng sừ dụng để liệt kê tập hợp nút cần phải qua mà lưu lại tập hợp nút qua IPv6 extended headers Hop-by-hop option heeder Option n r im im r r a g ? r r n iB " - r n r m ị Routing header T ýp » -s p *c M c < M a -N « d h w j0r I H d r « r tln f l» I A đ d re s s I SgqmenH Routing header type A d d re s s n Hình 4.3: Các tiêu đề định tuyến bước nhảy 103 Một hạn chế với tiêu đề định tuyến loại (RHO) vấn đề an ninh mạng Thật vậy, tiêu đề RHO có thê chứa nhiều định tuyến host trung gian phép chứa địa chi nhiều lần Điều có nghĩa gói tin chạy vịng xừ lý nhiều lần bới định tuyến host Điều dẫn đến khả cơng từ chối dịch vụ (DoS) Do đó, loại tiêu đề định tuyến khác sử dụng Tiêu đề định tuyến loại thử nghiệm tiêu đề định tuyến loại xác định cho IPv6 di động 4.2.5 Tiêu đề phân mảnh (Fragment Header) Trái ngược với IPv4 định tuyến dọc theo tuyến đường liệu không thực hình thức phân mảnh IPv6 yêu cầu liên kết phải có khả mang gói tin 1280 byte Điều khơng phù hợp mạng cảm biến không dây Cụ thể MTU liên kết IEEE 802.15.4 bàng 127 byte Trong trường hợp này, cần thiết phải thực phân mảnh tái tạo lại gói tin lớp liên kết Cơ chế mô tả chương IPv6 hỗ trợ chế để phát MTƯ tối thiểu liên kết dọc theo tuyến đường đến đích Điều thực bàng cách sử dụng thù tục gọi phát đơn vị truyền tài tối đa đường truyền (PMTƯ: Path Maximum Transmission nit Discovery) Nó sừ dụng chuỗi gói tin ICMP dọc theo tuyển đường phát MTU tối thiểu dọc theo tuyến đường Sau giá trị lưu trữ bảng host cùa điểm đến phải thuờng xuyên phát lại tuyến đường thay đổi phải định tuyến lại nút mạng bị lỗi Một nút nguồn IPv6 phân mảnh gói tin kích thước cùa lớn MTƯ nhị dọc theo tuyến đường đến đích Định dạng tiêu đề phân mành thể hình 3.5 Tiêu đề phân mảnh xác định giá trị 44 xuất trường tiêu đề cùa tiêu đề trước (có thể tiêu đề IPv6 cố định tiêu đề định tuyến, xuất hiện) Giá trị tiêu đề (next header) 104 giống với loại tiêu đề gói tin bị phân mảnh ban đầu Độ lệch phân manh (fragm ent offset) để xác định độ lệch phân mảnh (trong đơn vị octet) so với phan có thề phân mành gói tin ban đầu Trường nhận dạng (identiíĩcation) giá trị mă hóa 32 bit chọn bời nút nguồn đề nhận dạng gói tin bị phân mảnh tái tạo lại bời nút đích Mỗi lần nút nguồn phân mành gói tin sừ dụng số nhận dạng khác cho gói tin bị phân mành Nút nguồn giả thiết ràng sừ dụng m ột số nhận dạng cho gói tin gửi thời gian tồn dự kiến gói tin Một đếm vịng đơn giản thực chế m ã hóa 32 bit cho số nhận dạng Trường Reserved (2 bit) thiết lập bit M sừ dụng biết phân mảnh cuối hay chưa (M = 1: nhiều phân mành khác, M = 0: phân mảnh cuối cùng) Bây xem ví dụ minh họa q trình phân mảnh cùa m ột gói tin Gói tin ban đầu có phần không thề phân mành cấu thành từ tiêu đề ban đầu tiêu đề mở rộng cần phải xừ lý bời nút dọc theo tuyến đường đến đích Phần cịn lại cùa gói tin phần phân mành Định dạng cùa phân mành thể hình 4.4 Mỗi phân mãnh bao gồm phần khơng thể phân mảnh cùa gói tin ban đầu, tiêu đề phân m ảnh tải trọng cùa phân mảnh Nếu quan sát tiêu đề phân mảnh, thấy chứa giá trị tiêu đề để xác định tiêu đề phần phân mảnh gói tin ban đầu Trường tiêu đề tiêu đề cuối phần phàn mảnh thiết lập 44 Các phân mảnh bị mất, đặc biệt mạng cảm biến khơng dây có tỷ lệ lỗi bit (BER) cao liên kết không ổn định IPv6 yêu cầu tất cá phân manh phải nhận vòng 60 giây sau tiếp nhận phân m ánh Sau thời điểm hết hạn mà tất phân mành không nhận đầy đù thi thù tục đơn giàn dừng loại bỏ tất phân mảnh Sau m ột bàn tin báo lỗi ICMP gửi đến nguồn cùa gói tin Các trường hợp lỗi khác (ví dụ, độ dài gói khơng xác ) kiểm soát 105 FragmflMon procMi tM M v I hMnad M “ Opta M g E X Ịg Ongn* packai to ba tBgrmnM Ị U tagm rtẩếpl Ị Fi«gro»rth—dw Ị Pagimrti I Ị ÙrÉymnÌÉbpl ' Ị ỉnợ m tìm ắK ( Pngnart? I Ị Úr*yn»fÉÌbl»p«f1 I RỊgmrthãrig' Ị 'ãiọrmrtn ] Hình 4.4: Các tiêu đề phân mảnh 4.2.6 Tiêu đề tùy chọn đích (Destỉnation Option Header) Tiêu đề tuỳ chọn đích sử dụng để mang thơng tin tùy chọn xử lý bời nút đích đuợc nhận dạng trường tiêu đề tiêu đề trước giá trị 60 Định dạng tiêu đề tùy chọn đích tương đối dễ hiểu bao gồm: Một trường tiêu đề bit, theo sau bit trường độ dài xác định độ dài tiêu đề đon vị octet, không bao gồm octet Tài trọng bao gồm nhiều giá trị tùy chọn định dạng TLVs Thông tin tùy chọn mã hóa theo hai cách khác nhau: Bằng cách sử dụng tùy chọn định dạng TLV mang tiêu đề tùy chọn đích bàng cách xác định tiêu đề mở rộng Hai bit bậc cao sừ dụng để xác định hành vi cùa điểm đích khơng nhận diện tùy chọn 4.2.7 Tiêu đề nhận thực tiêu đề đóng gói bảo mật Tiêu đề nhận thực (giá trị = 51) tiêu đề đóng gói bảo mật (giá trị = 50) sử dụng IPSec đề xác thực, đảm bào tính tồn vẹn, tính bảo mật cùa gói tin để xác định thông tin liên quan đến mã hố liệu 106 4.2.8 Ticu đề kết thiíc (No Next Heađer) Tiêu đề (giá trị = 59) sử dụng đề cho thấy khơng có theo sau tiêu đề 4.3 KI ÉN T R Ú C ĐỊA C H Ỉ IPv6 4.3.1 Khái niệm Unicast, Anycast M ulticast Một địa unicast xác định m ột giao diện (interface) Một giao diện có nhiều địa unicast phải có địa liên kết cục Địa chi liên kết cục địa chi sừ dụng liên kết hai nút Trong m ột số trường hợp, địa chi liên kết cục đủ nút không cần phải gửi gói liệu vượt ngồi liên kết cục Lưu ý m ột nút gán địa unicast (hoặc tập hợp địa chi unicast) cho m ột giao diện chi xừ lý chúng giao diện xuất lớp mạng Điều hữu ích nhằm cân tài lưu lượng m ột tập họp giao diện vật lý Một địa anycast xác định tập giao diện: Một gói tin gửi đến địa chi anycast chi gửi tới giao diện tập hợp thường giao diện gần tính theo thước đo định tuyến Ngược lại, gói tin gửi tới địa chi multicast gửi đến tất cà giao diện xác định địa chi multicast Khơng có qng bá IPv6, địa multicast sừ dụng Ví dụ, gói tin điều khiển định tuyến IPv4 sử dụng địa chi quảng bá địa multicast lại sử dụng IPv6 4.3.2 Bicu diễn địa IPv6 Các địa chi IPv4 32 bit biểu diễn dạng sau đây: x.y.z.t (ví dụ: 124.4.12.3) Một phần cùa địa chi đại diện cho phần m ạng phần lại cùa địa chi đại diện cho phần host Các địa chi IPv6 128 bit thường biếu diễn dạng x: x: x: x: x: x: x: X X giá trị hệ số 16 (do biểu diễn dạng 16 bit) ví dụ: 2020:CA2S:0000:0000:0023:0222:0000:2900 107 Server Client I NON [ x a l l ] I GET / t e m p e r a t u r e I (Token 0x74) + > Hình 7.4: Yêu cầu đáp ứng không báo nhặn (NON) NON [ x b c ] 2.05 C ontent (T o k en 0x74) " 2 C" + I< Giao thức CoAP sừ dụng phương thức GET, PUT, POST DELETE tương tự giao thức HTTP Ý nghĩa phương thức trình bày mục 7.2.4 7.2.3 Định dạn g tin CoAP Các tin CoAP mã hóa dạng nhị phân Một tin bao gom tiêu đề CoAP có kích thước cố định, tùy chọn định dạng TLV (Type Length Value) tải trọng, số lượng tùy chọn xác định phần tiêu đề Phần tải trọng bao gồm byte theo sau phần tùy chọn (nếu có) Chiều dài phần tải trọng tính tốn từ chiều dài gói datagram 3 9 +- +- + - + +- + - +- + - +- +- + - + - + IVerl T I oc I Code I Options (if any) I Payload (if any) + +- +- +- +- + I + - + - +- +- + - +- + - + - + - +- + - + - + - +- + - + Message ID I +- +- +- +- + M e ssag e +- +- + +- +- +- +- +- + F o rm a t Hình 7.5: Định dạng tin CoAP Hình 7.5 minh họa định dạng cùa bàn tin CoAP Các trường phần tiêu đề định nghĩa sau: 226 •• Trường phiên (Version - Ver): Có độ dài bit, thuộc kiểu số nguyên không dấu Trường cho biết phiên bàn CoAP Trong phiên trướng phải thiết lập giá trị Các giá trị khác dành cho phiên tương lai • » Trường kiều (Type - T): Có độ dài bit, thuộc kiểu số ngun khơng dấu Trường cho biết kiều tin - T=0: Coníìrm able - T = l: Non-Confirmable - T=2: Acknovvledgement - T=3: Reset •* Trường số tùy chọn (Option Count - OC): Có độ dài bit, thuộc kiểu số nguyên không dấu Truông cho biết số tùy chọn sau phần tiêu đề Nếu trường o c có giá trị bàng thỉ khơng có tùy chọn phần tải trọng theo sau phần tiêu đề • > Trường m ã (Code): bit, thuộc kiểu số nguyên không dấu Cho biết tin m ang m ột yêu cầu hay đáp ứng tin rỗng Nếu m ột tin mang u cầu trường code có giá trị ưong khoảng từ 1đến 31 N ếu m ột bàn tin đáp ứng trường có giá trị khoảng từ 64 đến 191 Nếu tin rỗng trường có giá trị (tất giá trị mã khác dự trữ) Trong truờng hợp yêu cầu, trường code sê chi phương thức yêu cầu, trường hợp m ột đáp ứng trường code cho biết mã đáp ứng • Trường nhận dạng tin (M essage ID): 16 bit, kiểu số nguyên không dấu, sử dụng để phát tin trùng lặp Trường dùng để nối tin kiểu ACK/Reset tin kiểu CON/NON Trong lóp liên kết cần làm cho kích thước gói tin CoAP đủ nhỏ đíể phù họp với gói tin lớp liên kết đặc điềm kỹ thuật CoAP hỗ trrợ giới hạn kích thước tin Việc bàn tin lớn so với plhân mảnh IP điều không mong m uốn q trình phân mảnh gói tin M lột tin CoAP đóng gói nên có kích thước nằm gói tiin IP (tức là, tránh việc phải thực phân mảnh IP) N eu đơn vị truyền dẫn tối đa MTU cùa tuyến đuờr.g tói đích đến klhơng biết trước nên giả định MTU 1280 227 byte Neu khơng có thơng tin kích thước tiêu đề giới hạn tốt 1152byte cho kích thước tin 1024 byte cho kích thước tài trọng 7.2.4 Các tin giao dịch giao thức CoAP CoAP sử dụng nhiều loại tin giao dịch khác Loại ban tin giao dịch xác định bời trường T phần tiêu đề CoAP Với loại bàn tin, mang thơng tin yêu cầu, đáp ứng bán tin rỗng Điều xác định trường Code phần tiêu đề CoAP liên quan đến mơ hình request/response Một tin rỗng trường cod e tiêu đề thiết lập Trường o c thiết lập khơng có byte xuất sau trường nhận dạng bàn tin Trong trường hợp này, trường o c byte theo sau tiêu đề cần phải bỏ qua bên nhận 7.2.4.1 Bản tin yêu cầu báo nhận (C O N ) Bản tin yêu cầu báo nhận CON (coníirm able) u cầu phải có tin trả lời báo nhận Khi khơng có gói tin bị thi bàn tin CON có tin trả tương ứng kiểu ACK Reset Bản tin CON luôn mang theo yêu cầu đáp ứng không phép trống 7.2.4.2 Bản tin kh ông yêu cầu báo nhận (N O N ) Bản tin không yêu cầu báo nhận NON (non-confírmable) khơng u cầu phải có tin trả lời báo nhận (ACK) Bản tin NON đặc biệt phù họp trường họp tin lặp lặp lại thường xuyên cho yêu cầu ứng dụng, chẳng hạn đọc lặp lặp lại từ cảm biến nhận kết đầy đủ Một tin NON mang theo yêu cầu đáp ứng không phép để trống 7.2.4.3 Bẩn tin báo nhận (A C K ) Một tin báo nhận ACK xác nhận rang tin CON (được xác định bnri trường nhận dạng tin) nhận Nó không cho biết thành công hay thất bại cùa bất kỉ yêu cầu 228 Bản tin ACK phản hồi lại m ột tin CON tin ACK phải mang mqột đáp ứng có the trống 7.L2.4.4 Bân tin th iế t lập lạ i(R S T ) Một bàn tin RST chi ràng tin CON NON nhận nhhưng thiéu m ột số nội dung để xử lý bàn tin cách Hiện tượng nàày thường xảy nút nhận khởi động lại quên số trạng thái đuược yêu cầu để xử lý tin Một tin RST phản hồi lại tin CON NON không đuược trống 7.12.5 Định nghĩa phương thức giao thức CoAP Trong phần này, phương thức định nghĩa với hoạt độộng cùa M ột yêu cầu với mã phương thức không nhận diậện không hỗ trợ đáp ứng 4.05 (M ethod Not Allovved) phriải tạo 7:2.5.1 Pbương thức GET Phương thúc GET lấy m ột biểu diễn thông in tương ứm g với nguồn tài nguyên xác định bời định danh tài n g u y ê n URI yêu cầu Sau đáp ứng thành cơng guri 7:2.5.2 Phưovg thức POST Phương thức POST yêu cầu biểu diễn kèm theo yêu cầu cầm xử lý Các hàm chức thực tế thực theo phương thiức POST xác định m áy chủ phụ thuộc vào tài nguyên mục tiêẻu cần xử lý Nó thường dẫn đến kết tài nguyên tạo tài nguyên mục tiêu cần xử lý cập nhật 2.5.3 Phương thức PƯT Phương thức PUT yêu cầu tài nguyên xác định bời định danh tàii nguyên URI cần phải cập nhật tạo với biểu diễn kètm theo Định dạng cùa biểu diễn kèm theo quy định cụ thể kiểu phiương tiện truyền thông Internet đưa tùy chọn nội dung 229 7.2.5.4 Phương thức D E L E T E Phương thức Delete yêu cầu tài nguyên xác định bời dịnh danh tai nguyên URI cần xóa 7.2.6 Ánh xạ C oA P H T T P 7.2.6.1 A n h x từ C o A P sa n g H T T P Nếu yêu cầu có chứa tùy chọn định danh tài nguyên ProxyURI "http" hay "https" URI điểm cuối nhận CoAP (được goi proxy) yêu cầu thực hoạt động quy định phương thức yêu cầu tài nguyên HTTP chi định trả kết v ề cho Client Làm để proxy đáp ứng u cầu từ phía Client ứì thực thi cụ thể Tuy nhiên, proxy thực việc biên dịch chuyển tiếp yêu cầu đển server HTTP gốc Vì HTTP CoAP chia sè tập phương thức yêu cầu nên việc thực yêu cầu CoAP tài nguyên HTTP không chác nhiều so với việc thực yêu cầu tài nguyên CoAP Nếu proxy không sẵn sàng phục vụ yêu cầu với định danh tài nguyên UR1 HTTP đáp ứng 5.05 (proxying not supportei) trả cho Client Neu proxy phục vụ yêu cầu cách tương tác v bên thứ ba (như server HTTP gốc) đạt kết rong khung thời gian hợp lý đáp ứng 5.04 (gateway timeout) trả cho Client Neu kết quà nhận khơng hiểu rõ đáp ứng 5.02 (bad gatevvay) trả cho Client Phương thức GET yêu cầu proxy trà biểu diễn tài nguyên HTTP xác định bời định danh tài nguyên URI yêu cầu Phương thức PUT yêu cầu proxy cập nhật tạo tài naiyên HTTP đirợc xác định bời định danh tài nguyên URI yêu cầu với biểu diễn kèm theo Phương thức DELETE yêu cầu proxy xóa tài nguyên HTTP đượỉ xác định bời định danh tài nguyên URI yêu cầu phía server HTTP gốc Phương thức POST yêu cầu biểu diễn kèm theo yêu cầi gửi tới proxy cần xử lý server HTTP gốc Hàm chức thực 230 phhương thức POST xác định server HTTP gốc phụ thuộc vào tàii nguyên xác định định dạng tài nguyên URI yêu cầu 2.6.2 A n h x từ H T T P san g C oA P Neu m ột yêu cầu HTTP chứa định dạng tài nguyên URI yêu cầu "C o A P " "CoAPS" thi điểm cuối HTTP (được gọi proxy) yêu cầiu thực hoạt động quy định phương thức yêu cầu tài nguyên C oA P định trả kểt cho Client Làm để proxy đáp ứng u cầu từ phía Client sẽỉ m ột thực thi cụ thể Tuy nhiên, proxy thực việc biên dịịch chuyến tiếp yêu cầu đến server CoAP gốc N eu proxy không sằn sàng phục vụ yêu cầu với rrnột định danh tài nguyên URI CoAP đáp ứng 5.01 (not implemented) đurợc trả cho C lien t N eu proxy phục vụ yêu cầu cách tương tác với nuột bên thứ ba (như server CoAP gốc) đạt kết qiuả khung thời gian hợp lý đáp ứng 5.04 (gateway timeout) đm ợc trả cho C lien t Nếu kết nhận nhung khơng hiểu rõ thìi đáp ứng 5.02 (bad gateway) trả cho Client Các phương thức OPTIONS TRACE không hỗ trợ bời giao thiức CoAP Vì vậy, đáp ứng 5.01 (not implemented) trả cho clỉient Phương thức GET yêu cầu proxy trà biểu diễn tài nguyên CoAP đuiợc xác định định danh tài nguyên ƯRI yêu cầu Phương thức HEAD giống với phương thức GET ngoại trừ việc se.Tver không trả lại phần thân bàn tin (message body) đáp ứng Phương thức POST yêu cầu biểu diễn kèm theo yêu cầu gửi tớri proxy cần xử lý bời server CoAP gốc Hàm chức thực phiương thức POST xác định server CoAP gốc phụ thuộc vào tàii nguyên xác định bời định dạng tài nguyên ƯRI yêu cầu Phương thức PUT yêu cầu proxy cập nhật tạo tài nguyên CcoAP xác định bời định danh tài nguyên URI yêu cầu với biểu diiễn kèm theo Phương thức DELETE yêu cầu proxy xóa tài nguyên CoAP xác địinh định danh tài nguyên ƯRI yêu cầu phía server CoAP gốc 231 7.3 M ỘT SÔ ĐẢNH GIÁ HIỆU NĂNG CỦA GIAO THỨC CoAP C H O M ẠNG CẢM BIÉN K H Ô N G DÂY Mục đưa số đánh giá hiệu cúa giao thức CoAP Đe đánh giá ưu điểm giao thức CoAP mạng cảm biến không dây, so sánh hiệu cùa với giao thức HTTP Các tiêu chí để đánh giá hiệu xác định số byte chuyển giao m ột giao dịch Client - server thơng qua phân tích định lượng nhằm mục đích làm giảm lượng tiêu thụ thời gian đáp ứng Để đánh giá hiệu hai giao thức CoAP HTTP, vài thực nghiệm thực cặp Client - server CoAP Client - server HTTP Server CoAP thực bời nút cảm biến chạy hệ điều hành Contiki với lớp mạng 6LoW PAN/RPL lớp ứng dụng giao thức CoAP Client CoAP thực thi bàng cách chạy libcoap m áy Linux Ưbuntu với USB Contiki-gatevvay giao tiếp với mạng cảm biến không dây Server HTTP thực từ nút cảm biến chạy hệ điều hành Contiki nạp server HTTP thay nạp server CoAP Client HTTP có cách thay libcoap cURL Đây chương trình dịng lệnh bao gồm chức HTTP Trong kịch Client - server CoAP HTTP Client gửi yêu cầu nhiệt độ độ ẩm tới server sau khoảng thời gian bàng Khi sừ dụng CoAP yêu cầu có định dạng sau: GET coap://[]:/readings Trong mote_ip address địa chi IPvó-của nút, p o rt number số cổng cùa nút readings tài nguyên mà Client yêu càu (trong truờng hợp nhiệt độ độ ẩm) Khi sử dụng H T JP u cầu có định dạng sau: GET http:///J: /readings Các tham số định dạng có ý nghĩa tương tự CoAP Trong hai trường hợp CoAP HTTP, server trả lời bàng cách gửì kết cảm biến đọc nhúng file JSON JSON định dạng văn nhẹ dựa chuẩn m cho việc chuyển đổi liệu Client server Ví dụ tải trọng đáp ứng sau: 232 {"sensor "0212:7400:0002:0202", "readings {"hum ":31, "temp ":23 l f l Trong đó, cảm biến xác định bời bốn nhóm số cuối địtịa chi IPv6 cùa nó, hum tài nguyên độ ẩm temp tài nguyên nhiệt độộ 7.Ĩ.3.I Số byte chuyển giao giao dịch client-server Đẻ định lượng liệu chuyển giao sừ dụng HTTP CoAP, chhúng ta phân tích giao dịch Client - server định lượng số byte đúược chuyển giao Giao dịch bắt đầu C lien t khởi tạo yêu cầu tài ngguyên kết thúc C lien t nhận đáp ứng tài nguyên Giao dịch đãã phân tích bang Wireshark Đây phân tích giao thức mạng cóó thể lưu giữ phân tích lưu lượng chạy mạng máy tính Bàảng 7.1 cho biết số byte số gói tin chuyển giao giao dịiịch CoAP HTTP B ảng 7.1: số byte chuyển giao giao dịch CoAP HTTP Protocol CoAP HTTP Bytes/transaction 184 1288 Packets/transaction 17 Như m inh họa bảng 7.1, giao dịch HTTP có số byte gói tin lớm nhiều so với giao dịch CoAP Đây kết cùa việc nén tiêu đề': thực CoAP Giao thức CoAP sử dụng tiêu đề có chiều dàiii cố định, nhị gọn \ớ i chi byte yêu cầu điển hình có tiêu đề tổng cộnng khoảng - byte Sau đóng gói tiêu đề lớp UDP, 6Lư>WPAN lớp MAC gói tin CoAP chuyển khuung MAC có kích thước bàng 127 byte 7.33.2 Năng lượng tiêu thụ Việc sứ dụng giao thức truyền tải ƯDP giảm kích thước tiêu đề gói tin đă cài thiện đáng kể lượng tiêu thụ tuôi thọ cùa pin mạng cảnm biến không dây 233 Hình 7.6 kết quà phương diện lượng tiêu thụ cua hai gio thức CoAP HTTP thực m ột loạt yêu cầu từ Client sòt khoảng thời gian 30 phút Khoảng thời gian đển yêu cầu từ pĩa Client lOs Năng lượng tiêu thụ tính tốn nút server tronị.4 chế độ hoạt động khác Chể độ nút server nhận gói tn, gọi chế độ RX Chế độ thứ nút server truyền gói tii, gọi chế độ TX Chế độ thứ nút server chế độ nhn rỗi gọi chế độ công suất thấp LPM (Lovver Power Mode) Chế lộ thứ xử lý trung tâm CPU nút server xừ lý gói tin, đực gọi chế độ CPU ■ 25ỠO CoAP 1-hop 2000 ■ HTTP l h op Ị1500 • CoAP 2-hop nHTTP ?-hop 1000 500 10 15 20 25 30 35 40 45 50 55 Hình 7.6: Sự tiêu thụ lượng nút server CoAP HTTP chế độ hoạt động N hư minh họa hình 7.6, số byte truyền pliên giao dịch HTTP (xem bàng 7.1) cao đồng nghĩa với việc hời gian mà nút gừi, nhận xử lý gói tin nhiều lượr.g iêu 234 thụụ cao chế độ RX, TX, CPU Ờ chế độ RX lươợng tiêu thụ sử dụng CoAP xấp xi nửa lượng tiêu thụ sử r dụng HTTP (0.43 mW s cho CoAP 0,85 mW s cho HTTP) Điều cũũng tương tự chế độ CPU: Năng lượng cân thiết đê xử lý gói tinn CoAP (0,14 m W s) bàng khoáng nừa lượng cần thiết để xử lý Ị gói tin HTTP (0,26 m W s) Ờ chế độ TX, lượng yêu cầu C ooA P thấp lần so với lượng yêu cầu HTTP (0,03 m\iW s cho CoA P 0,12 mW s cho HTTP) Ờ chế độ LPM, tiêu thụ năóng lượng cùa HTTP CoAP gần giống (0,159 mW s cho C ooAP 0,155 m W s cho HTTP) Đây kết nhận kịch bảnn sử dụng giao thức MAC (contikiM AC) thời gian dànnh cho chế độ nhàn rỗi xấp xi 7.33.3 T h ò i gian đ áp ứng Khi truy cập vào tài nguyên cảm biến thông qua dịch vụ web điềều quan trọng phải đảm bảo thời gian đáp ứng thấp Thời gian đáp ứng caao ảnh hưởng đến hiệu cùa số ứng dụng có yêu cầu nghiêm ngặặt độ trễ Ngoài ra, thời gian đáp ứng cịn tác động đến người sừ dụng (ví í dụ người dùng thừ truy cập vào liệu cảm biến gần thờời gian thực từ trình duyệt web) Thời gian đáp ứng định nghĩa khoảng thời gian tính từ thờời điểm khởi tạo yêu cầu thời điểm Client nhận đáp ứng với tài i tin Để so sánh thời gian đáp ứng cùa hai eiao thức CoAP HTTP, hai kịcch sau thiết lập Trong kịch bàn với bước nhảy, có kết t nối trực tiếp nút nhàảy C lien t nút server Trong kịch với hai bước n ú t s e r v e r k h ô n g n ằ m tr o n g p h m v i c ủ a C lient v d ữ liệ u p h ả i đưựợc định tuyến thông qua nút trung gian Cả hai kịch bàn thử nghhiệm với 55 yêu cầu CoAP HTTP Hình 7.7 kết so sánh thời gian đáp ứng hai giao thức HTTP ' CoAP hai trường hợp mạng có bước nhảy mạng có hai bướớc nhảy 235 4000 3500 Ị 3000 / v- v ' , 2500 I 2000 - ■ ■ ■ *.■ - ♦ CoAP 1-hop ■ HTTP h op Ị, 1500 • CoAP 2-hop ■ 1000 X HTTP 2-hop 500 10 15 20 25 SO 35 40 45 50 ss Hình 7.7: Thời gian đáp ứng HTTP CoAP hai trường hợp bước nhảy bước nhảy N hư kết quà hình 7.7, thấy khác biệt đáng kể thời gian đáp ứng giao thức CoAP so sánh với giao thức HTTP Với trường hợp bước nhảy thời gian đáp ứng trung binh tính tốn với 55 u cầu phía Client 184 ms giao thức CoAP 1,8 s giao thức HTTP Với trường hợp hai bước nhảy, giao thức CoAP có thời gian đáp ứng trung bình 336 ms giao thức HTTP 3,2 s Như bên cạnh việc giảm lượng tiêu thụ giao thức CoAP có thời gian đáp ứng tốt giao thức HTTP Đó kết việc sử dụng giao thức truyền tài UDP kết việc giảm kích thước tiêu đề gói tin Bên cạnh đó, hình 7.7 thấy giá trị thời gian đáp ứng sử dụng HTTP trường hợp bước nhảy cao (3,2 s) không chấp nhận nhiều ứng dụng TỐ N G K ÉT C H Ư Ơ N G Trong chương này, thảo luận giao thúc lớp ứng dụng CoAP dành cho thiết bị tài nguyên hạn chế nói chung