Multicast 6LoWPANIPv6

ĐẠI HỌC QUỐC GIA TP.
HỒ CHÍ MINH
TRƯỜNG ĐẠI HỌC BÁCH KHOA
KHOA ĐIỆN – ĐIỆN TỬ
BỘ MÔN ĐIỆN TỬ
---------------o0o---------------
LUẬN VĂN TỐT NGHIỆP ĐẠI HỌC
Xây dựng hệ thống giám sát và điều khiển thông minh

sử dụng giao thức Multicast 6LoWPAN/IPv6
GVHD: TS. Võ Quế Sơn

SVTH: Văn Đình Triều
Trần Thanh Đăng Khoa
MSSV: 1414177
1411856
TP. HỒ CHÍ MINH, THÁNG 6 NĂM 2019

Đại Học Quốc Gia Tp.HCM CỘNG HÒA XÃ HỘI CHỦ NGHĨA VIỆT NAM
TRƯỜNG ĐẠI HỌC BÁCH KHOA Độc lập – Tự Do – Hạnh Phúc
-------------------- --------------------
Số: _____/ BKDT
NHIỆM VỤ LUẬN VĂN TỐT NGHIỆP
KHOA : ĐIỆN – ĐIỆN TỬ

BỘ MÔN : VIỄN THÔNG
HỌ VÀ TÊN : Văn Đình Triều MSSV : 1414177
Trần Thanh Đăng Khoa MSSV : 1411856
NGÀNH : Viễn thông Lớp : Viễn thông VP2014
1. Đầu đề luận án: Xây dựng hệ thống giám sát và điều khiển thông minh sử dụng giao
thức Multicast 6LoWPAN/IPv6.
2. Nhiệm vụ ( yêu cầu về nội dung và số liệu ban đầu )
- Nghiên cứu về khái niệm, tính chất của mạng cảm biến không dây (Wireless
Sensor Network), mạng Ipv6 và 6LowPAN. Các giải thuật multicast TM, SMRF,
ESMRF.
- Nghiên cứu sử dụng và thực hành nền tảng Contiki OS, công cụ mô phỏng Cooja
cũng như phần cứng CC2538dk.
- Tiến hành mô phỏng bằng công cụ Cooja các giải thuật Multicast và so sánh các
thông số: Tỉ lệ nhận gói, độ trễ mạng và năng lượng tiêu thụ.
- Xây dựng ứng dụng thực tiễn xoay quay phần cứng CC2538dk sử dụng một trong
các giải thuật Multicast đã nghiên cứu.
- Vận hành hệ thống trong thực tế. Đánh giá tính khả thi và hiệu năng của hệ thống.
3. Ngày giao nhiệm vụ luận án: 1/1/2019
4. Ngày hoàn thành nhiệm vụ: 21/6/2019
5. Họ tên người hướng dẫn: TS. Võ Quế Sơn
Nội dung và yêu cầu LATN đã được thông qua bộ môn.
Ngày 11 tháng 5 năm 2019

CHỦ NHIỆM BỘ MÔN GIÁO VIÊN
HƯỚNG DẪN
PGS.TS. Hà Hoàng Kha TS. Võ Quế Sơn

PHẦN DÀNH CHO KHOA, BỘ MÔN:
Người duyệt (chấm sơ bộ):.......................
Đơn vị:......................................................
Ngày bảo vệ : ...........................................
Điểm tổng kết: .........................................
1
LỜI CẢM ƠN
Trong thời gian thực hiện luận văn tốt nghiệp, chúng em đã nhận được nhiều
sự giúp đỡ từ các thầy cô, bạn bè và gia đình.
Đầu tiên, chúng em xin bày tỏ lòng kính trọng và biết ơn sâu sắc đến Thầy
Võ Quế Sơn, người đã tận tình trực tiếp hướng dẫn và tạo điều kiện tốt nhất cho
chúng em thực hiện luận văn này.
Trong suốt quá trình thực hiện luận văn, chúng em đã làm việc tại phòng thí
nghiệm Thông Tin của bộ môn Viễn thông, chúng em xin cảm ơn các anh chị cán
bộ phòng thí nghiệm đã hỗ trợ trang thiết bị vật tư để chúng em có thể làm luận
văn tại đây.
Bên cạnh đó, chúng em cũng xin chân thành cảm ơn quý thầy cô bộ môn
Viễn thông, cũng như quý thầy cô tham gia giảng dạy trong chương trình Kĩ sư
Chất lượng cao Việt Pháp – PFIEV đã cho chúng em những kiến thức nền tảng,
kiến thức chuyên ngành cũng như những kinh nghiệm quý báu để chúng em có thể
ứng dụng vào trong học tập và nghiên cứu sau này.
Một lần nữa chúng em xin chân thành cảm ơn!
Trân trọng,
Sinh viên
Trần Thanh Đăng Khoa
Văn Đình Triều
i
MỤC LỤC
Chương 1 Giới thiệu đề tài ................................................................................................. 1
1.1 Tổng quan về đề tài ........................................................................................................... 1
1.2 Nhiệm vụ luận văn............................................................................................................. 2
1.3 Nội dung luận văn ............................................................................................................. 3
Chương 2 Các khái niệm chung ........................................................................................ 4
2.1 Mạng cảm biến không dây - WSN .................................................................................. 4
2.1.1 Tổng quan về mạng cảm biến không dây ................................................................. 4
2.1.2 Cấu trúc mạng cảm biến không dây .......................................................................... 4
2.1.3 Kiến trúc và giao thức của mạng cảm biến không dây ........................................... 5
2.1.4 Ứng dụng của mạng cảm biến không dây................................................................. 6
2.2 IPv6 ..................................................................................................................................... 7
2.2.1 Tổng quan về IPv6 ....................................................................................................... 7
2.2.2 Các loại địa chỉ IPv6 .................................................................................................... 9
2.3 6LoWPAN .......................................................................................................................... 9
2.3.1 Tổng quan ..................................................................................................................... 9
2.3.2 Các đặc tính của 6LoWPAN: ................................................................................... 10
2.3.3 Kiến trúc của mạng 6LoWPAN ............................................................................... 10
2.3.4 Quá trình thiết lập và vận hành 6LoWPAN............................................................ 11
2.4 Continki OS ...................................................................................................................... 12
2.4.1 Tổng quan ................................................................................................................... 12
2.4.2 Giao thức MAC trong Contiki OS ........................................................................... 12
2.5 Giao thức định tuyến RPL .............................................................................................. 14
2.5.1 Tổng quan ................................................................................................................... 14
2.5.2 Quá trình xây dựng kết nối mạng............................................................................. 15
2.5.3 Các chế độ định tuyến trong giao thức RPL ........................................................... 17
Chương 3 Các giải thuật multicast................................................................................. 19
3.1 Thuật toán Trickle ........................................................................................................... 19
3.1.1 Tổng quan ................................................................................................................... 19
3.1.2 Các tham số và biến ................................................................................................... 19
3.1.3 Mô tả hoạt động.......................................................................................................... 20
3.2 MPL/TM ........................................................................................................................... 21
ii
3.2.1 Nội dung giải thuật..................................................................................................... 21
3.2.2 Đánh giá giải thuật ..................................................................................................... 23
3.3 Stateless multicast RPL forwarding – SMRF .............................................................. 24
3.4 Enhanced Stateless multicast RPL forwarding – ESMRF ......................................... 27
Chương 4 Mô phỏng so sánh các giải thuật multicast ............................................... 30
4.1 Mục tiêu mô phỏng.......................................................................................................... 30
4.2 Công cụ mô phỏng – Cooja ............................................................................................ 30
4.3 Thiết kế hệ thống mô phỏng........................................................................................... 31
4.3.1 Cài đặt mạng ............................................................................................................... 31
4.3.2 Thiết kế các sơ đồ mạng............................................................................................ 33
4.4 Kết quả mô phỏng và phân tích ..................................................................................... 35
4.4.1 Kết quả mô phỏng ...................................................................................................... 35
4.4.2 Phân tích số liệu ......................................................................................................... 37
4.4.2 Kết luận và khuyến nghị............................................................................................ 44
Chương 5 Thiết kế hệ thống giám sát và điều khiển .................................................. 46
5.1 Tổng quan ......................................................................................................................... 46
5.1.1 Yêu cầu và mục tiêu .................................................................................................. 46
5.1.2 Sơ đồ tổng quan của hệ thống .................................................................................. 47
5.2 Thiết kế phần cứng .......................................................................................................... 48
5.2.1 Sơ đồ khối tổng quan của phần cứng....................................................................... 48
5.2.2 Chi tiết phần cứng ...................................................................................................... 49
5.2.3 Thiết kế khối sink node – relay – nguồn ................................................................. 55
5.3 Thiết kế firmware ............................................................................................................ 56
5.3.1 Đề xuất framwork ...................................................................................................... 56
5.3.2 Cấu hình project-conf.h ............................................................................................. 58
5.3.3 Firmware cho Root node ........................................................................................... 59
5.3.4 Firmware cho sink node ............................................................................................ 63
iii
5.4 Thiết kế phần mềm .......................................................................................................... 66
5.4.1 Thiết kế Server ........................................................................................................... 68
5.4.2 Thiết kế gateway giữa 6LoWPAN và Internet ....................................................... 69
5.4.3 Thiết kế giao diện điều khiển qua smartphone (Android) .................................... 72
Chương 6 Kết quả thực hiện ứng dụng ......................................................................... 79
6.1 Sản phẩm phần cứng ....................................................................................................... 79
6.2 Kết quả thực hiện phần mềm và firmware ................................................................... 80
6.3 Kết quả range test ............................................................................................................ 82
Chương 7 Kết luận và hướng phát triển ....................................................................... 84
7.1 Kết luận ............................................................................................................................. 84
7.1.1 Đánh giá ...................................................................................................................... 84
7.1.2 Hạn chế ........................................................................................................................ 85
7.2 Hướng phát triển .............................................................................................................. 85
Tài liệu tham khảo ................................................................................................................ 86
Phụ lục ..................................................................................................................................... 87
A. Quá trình mô phỏng trên Contiki/Cooja ....................................................................... 87
B. Thiết kế chương trình xử lí dữ liệu đầu ra của quá trình mô phỏng.......................... 89
C. Tạo Mosquitto Broker bằng CloudMQTT ................................................................... 93
iv
DANH MỤC CÁC HÌNH
Hình 2.1 Cấu trúc mạng cảm biến không dây........................................................................... 5

Hình 2.2 Các thành phần của một nút cảm biến ....................................................................... 5
Hình 2.3 Kiến trúc mạng cảm biến không dây ......................................................................... 6
Hình 2.4 Thực trạng địa chỉ IPv4 hiện nay ............................................................................... 8
Hình 2.5 Kiến trúc mạng 6LowPAN........................................................................................ 10
Hình 2.6 Kiến trúc mạng 6LoWPAN....................................................................................... 11
Hình 2.7 Cơ chế hoạt động của ContikiMAC......................................................................... 13
Hình 2.8 ContikiMAC với trường hợp gửi broadcast ............................................................ 13
Hình 2.9 Mô hình DODAG ....................................................................................................... 15
Hình 2.10 RPL Non-storing mode ........................................................................................... 17
Hình 2.11 RPL Storing mode .................................................................................................... 18
Hình 3.1 Thuật toán Trickle ...................................................................................................... 21
Hình 3.2(A) xử lý gói MPL data message và (B) xử lý MPL control message ................. 22
Hình 3.3 Giải thuật SMRF ....................................................................................................... 26
Hình 3.4 Gói tin ICMPv6 "Multicast-on-behalf" .................................................................. 28
Hình 3.5 Quá trình gửi "Multicast-on-behalf" của ESMRF.................................................. 29
Hình 4.1 Giao diện Cooja simulator ........................................................................................ 31
Hình 4.2 Forward straight-line topology ................................................................................. 33
Hình 4.3 Backward straight-line topology .............................................................................. 34
Hình 4.4 Random topology ....................................................................................................... 34
Hình 4.5 Đầu ra của tool xử lý dữ liệu loglistener.txt ........................................................... 35
Hình 4.6 Quá trình khởi tạo của root ....................................................................................... 36
Hình 4.7 Quá trình khởi tạo của sink ....................................................................................... 36
Hình 4.8 Quá trình gửi và nhận gói .......................................................................................... 36
Hình 4.9 Giám sát năng lượng tiêu thụ .................................................................................... 37
Hình 4.10 PDR trong forward straight-line topology ............................................................ 38
Hình 4.11 Đỗ trễ trung bình trong forward straight-line topology....................................... 39
Hình 4.12 Năng lượng tiêu thụ trong forward straight-line topology .................................. 40
Hình 4.13 Tỉ lệ nhận gói trong backward straight-line topology ......................................... 41
Hình 4.14 Độ trễ trung bình trong backward straight-line topology .................................. 42
Hình 4.15 Năng lượng tiêu thụ trong backward straight-line topology............................... 42
Hình 4.16 Các đại lượng quan sát trong random topology ................................................... 43
Hình 5.1 Sơ đồ khối tổng quát của hệ thống ........................................................................... 47
Hình 5.2 Sơ đồ khối tổng quát phần cứng ............................................................................... 48
Hình 5.3 Raspberry Pi 3B+ ....................................................................................................... 49
Hình 5.4 Module Contiki 6LoWPAN CC2538dk .................................................................. 50
Hình 5.5 Module TTL CP2102 và sơ đồ nối chân ................................................................. 52
Hình 5.6 Module 1 relay 5V với opto cách ly ........................................................................ 53
v
Hình 5.7 Module nguồn AC-DC HLK-PM01 ........................................................................ 54
Hình 5.8 Sơ đồ nối mạch khối sink node-relay-nguồn .......................................................... 55
Hình 5.9 Protocol stack được sử dụng trong framework....................................................... 56
Hình 5.10(A)Chương trình chính; (B) chương trình cài đ ặt hệ thống tại root node .......... 60
Hình 5.11 Chương trình con xử lý lệnh tới root node............................................................ 60
Hình 5.12 Chương trình con xử lý ACK ................................................................................. 61
Hình 5.13 (A) Chương trình chính; (B) chương trình con cài đ ặt sink node ...................... 64
Hình 5.14 Sơ đồ thiết kế phần mềm ......................................................................................... 66
Hình 5.15 Kiến trúc mức cao MQTT ....................................................................................... 67
Hình 5.16 Sơ đồ giải thuật cho Raspberry .............................................................................. 71
Hình 5.17 Mô hình thiết kế ứng dụng Android ...................................................................... 73
Hình 5.18 Giao diện phần mềm: (A) Các nút điều khiển; (B) Popup chọn Group multicast;
(C) Đồ thị theo dõi nhiệt độ các nút ......................................................................................... 74
Hình 5.19 Sơ đồ giải thuật Main activity ................................................................................ 75
Hình 6.1 Phần cứng khối sink node ......................................................................................... 79
Hình 6.2 Lựa chọn nhóm điều khiển và phản hồi từ root...................................................... 80
Hình 6.3 Quá trình điều khiển................................................................................................... 81
Hình 6.4 Thu thập và biểu diễn nhiệt độ ................................................................................. 82
Hình 6.5 Sơ đồ thực hiện range test ......................................................................................... 83
vi
DANH MỤC CÁC BẢNG
Bảng 1 Các tham số mô phỏng ................................................................................................. 32

Bảng 2 Các số liệu trung bình ................................................................................................... 44
Bảng 3 Thông số kỹ thuật module CC2538dk........................................................................ 51
Bảng 4 Thông số kỹ thuật module Relay ............................................................................... 54
Bảng 5 Bảng thông số kỹ thuật module nguồn ....................................................................... 54
Bảng 6 Quy định nội dung gói tin gửi đi ................................................................................. 58
Bảng 7 Các thông số thiết kế cho CloudMQTT ..................................................................... 68
Bảng 8 Thông số thiết lập MQTT Client trong ứng dụng ..................................................... 77
Bảng 9 Thông số kỹ thuật khối sink node ............................................................................... 79
Bảng 10 Thông số kỹ thuật khối root node ............................................................................. 80
Bảng 11 Kết quả thực hiện range test ...................................................................................... 83
vii
DANH MỤC CHỮ VIẾT TẮT
6LoWPAN IPv6 over Low Power Wireless Area Network

LoWPAN Low Power Wireless Personal Area Network
IoT Internet of Thing
RFC Request for Comments
IEEE Institute of Electrical and Electronics Engineers
ACK Acknowledgement
DAG Directed Acyclic Graph
DAO Destination Advertisment Object
DIO DAG Information Object
DIS DAG Information Solicitation
GPIO General Purpose Input Output
IoT Internet of Things
LNN Low Power and Lossy Network
MPL Multicast Protocol for Low Power and Lossy Network
PC Power Consumption
PDR Package Delivery Rate
RDC Radio Duty Cycling
ROLL Routing Over Low Power and Lossy Network
RPL Ipv6 Routing Protocol For Low Power and Lossy Network
SoC System on Chip
TCC Trickle Consequence Check
UART Universal Asychronous Receiver Transmitter
viii
Chương 1: Giới thiệu đề tài
CHƯƠNG 1 GIỚI THIỆU ĐỀ TÀI
1.1 Tổng quan về đề tài
Trong lĩnh vực Internet kết nối vạn vật (IoT), mạng không dây công suất thấp
LoWPAN (Low Power Wireless Personal Area Network) là một trong những môi
trường quan trọng, có nhiều ứng dụng và triển khai thực tế. LoWPAN là một mạng
cho phép các ứng dụng, dịch vụ hoạt động thông qua kết nối không dây với công
suất và băng thông hạn chế. Mạng LoWPAN thường bao gồm các thiết bị phù hợp
với tiêu chuẩn IEEE 802.15.4, chúng có các đặc điểm như : sử dụng sóng ngắn, tốc
độ thấp, công suất thấp và giá thành thấp, hạn chế về năng lực tính toán, bộ nhớ…
Các giao thức phổ biến hiện đang được sử dụng để kết nối, trao đổi thông tin giữa
các thiết bị trong môi trường này là Z-Wave, ZigBee... Tuy nhiên các giao thức này
gặp phải một số vấn đề hạn chế như: triển khai cấu hình phức tạp, khả năng mở
rộng hạn chế, chưa có các cơ chế đảm bảo an toàn an ninh, chưa được chuẩn hóa,
khó khăn khi kết nối Internet.
Một kỹ thuật xuất hiện trong những năm gần đây và gây được nhiều sự chú ý
đó là sử dụng giao thức IPv6 trong mạng không dây công suất thấp - 6LoWPAN (
viết tắt của IPv6 over Low Power Wireless Personal Area Networks). Đây là giao
thức mạng cho phép truyền tải các gói tin IPv6 thông qua giao thức vô tuyến IEEE
802.15.4 (giao thức hỗ trợ gói tin có kích thước nhỏ hơn, cho phép các thiết bị trong
môi trường hạn chế sử dụng nguồn tài nguyên thấp như: bộ nhớ, CPU, công suất,
băng tần… có thể giao tiếp với nhau). Các giao thức trong 6LoWPAN đã được
chuẩn hoá trong các tiêu chuẩn RFC 4944, RFC 6282 và RFC 6775. Do đã được
chuẩn hoá nên các thiết bị 6LoWPAN dễ dàng kết nối và giao tiếp với nhau hơn,
đây là giao thức được đánh giá thực sự phù hợp cho IoT.
Trong 6LoWPAN, yếu tố tiết kiệm năng lượng, tiết kiệm băng thông luôn
được quan tâm hàng đầu, do đó các giao thức để tối ưu băng thông, giảm tiêu thụ
năng lượng được áp dụng nhiều trong 6LoWPAN. Giao thức phát đa hướng
1
(Multicast) là một trong những giao thức để giảm thiểu băng thông, giảm thiểu sự
truyền tải các gói tin giữa các nút cảm biến với nhau, khi mà một nút muốn gửi gói
tin đến nhiều nút khác cùng một lúc, nó không cần phải gửi từng gói đến mỗi nút
(Unicast) mà chỉ cần gửi một gói tin Multicast là đủ. Điều này giúp giảm đáng kể
gói tin truyền đi, nhất là đối với một mạng lưới chứa hàng trăm nút cảm biến. Có 3
giải thuật Multicast trong 6LoWPAN, đó là Trickle Multicast, Stateless Multicast
RPL Forwarding (SMRF) và Enhanced Stateless Multicast RPL Forwarding
(ESMRF).
1.2 Nhiệm vụ luận văn

Trong phạm vi của đề tài, các nội dung nghiên cứu của luận văn sẽ tập trung
vào ba giải thuật multicast hiện có là TM, SMRF và ESMRF. Nghiên cứu về các
lý thuyết và công cụ liên quan như Wireless Sensor Network, Contiki OS ,
6lowPAN/Ipv6, kit phát triển CC2538dk....Tìm hiểu chi tiết về các giải thuật
mulicast. Tiếp theo, thực hiện mô phỏng cả ba giải thuật multicast trên phần mềm
bằng công cụ mô phỏng để đánh giá các giải thuật. Sau đó so sánh hiệu năng của
chúng dựa vào các thông số có được từ mô phỏng. Cuối cùng là lựa chọn một trong
ba giải thuật muticast dựa vào kết quả của mô phỏng so sánh, đề xuất một ứng dụng
giám sát và điều khiển thông minh ứng dụng vào thực tế trên kit CC2538dk.
Tóm lại, nhiệm vụ luận văn bao gồm:
- Nghiên cứu lý thuyết về mạng cảm biến không dây (WSN), mạng Ipv6 và
6lowPAN. Thực hành sử dụng Contiki OS, công cụ mô phỏng Cooja, kit phát
tiển CC2538dk
- Nghiên cứu và đánh giá ba giải thuật multicast trong mạng 6lowPAN/Ipv6 hiện
có là TM, SMRF và ESMRF.
- Mô phỏng, so sánh các giải thuật multicast bằng công cụ phần mềm thông qua
các thông số: tỉ lệ nhận gói, độ trễ mạng và năng lượng tiêu thụ.
2
- Xây dụng ứng dụng thực tiễn trên phần cứng CC2538dk, sử dụng một trong
các giải thuật multicast đã nghiên cứu. Vận hành hệ thống trong thực tế để đánh
giá tính khả thi và hiệu năng của hệ thống.
1.3 Nội dung luận văn

Các nội dung được trình bày trong báo cáo bao gồm:
- Chương 1: Giới thiệu tổng quát về luận văn và nhiệm vụ.
- Chương 2: Các khái niệm chung về mạng cảm biến không dây, IPv6, 6LoWPAN.
- Chương 3: Trình bày các giải thuật multicast trong 6LoWPAN/IPv6.
- Chương 4: Mô phỏng các giải thuật bằng công cụ Cooja, so sánh, đưa ra khuyến
nghị.
- Chương 5: Thiết kế ứng dụng thực tế sử dụng một trong ba giải thuật multicast.
- Chương 6: Kết quả thực hiện thiết kế ứng dụng từ chương 5.
- Chương 7: Kết luận và hướng phát tiển
3
Chương 2: Các khái niệm chung
CHƯƠNG 2 CÁC KHÁI NIỆM CHUNG

Trong chương này, nhóm giới thiệu một số khái niệm liên quan đến đề tài
luận văn, đó là về Mạng cảm biến không dây (Wireless Sensor Network), đặc điểm
của địa chỉ IPv6, giới thiệu về những giao thức, tiêu chuẩn trong 6LoWPAN, các
giao thức MAC trong ContikiOS và giao thức định tuyến RPL.
2.1 Mạng cảm biến không dây - WSN

2.1.1 Tổng quan về mạng cảm biến không dây
Mạng cảm biến không dây (Wireless Sensor Network) là một tập hợp các
thiết bị sử dụng các liên kết không dây (vô tuyến, hồng ngoại hoặc quang học) để
phối hợp thực hiện nhiệm vụ thu thập dữ liệu với phạm vi lớn trong bất kì điều kiện
môi trường và địa lí nào. Các nút cảm biến không dây có thể được triển khai cho
các mục đích chuyên dụng như điều khiển giám sát và an ninh; kiểm tra môi trường;
tạo ra không gian sống thông minh; khảo sát đánh giá chính xác trong nông nghiệp;
trong lĩnh vực y tế. Lợi thế chủ yếu của chúng là khả năng triển khai hầu như trong
bất kì loại hình địa lý nào kể cả các môi trường nguy hiểm không thể sử dụng mạng
cảm biến có dây truyền thống.
2.1.2 Cấu trúc mạng cảm biến không dây
Một mạng cảm biến không dây bao gồm số lượng lớn các nút được triển khai
dày đặc bên trong hoặc ở rất gần đối tượng cần thăm dò, thu thập thông tin dữ liệu.
Vị trí các cảm biến không cần định trước vì vậy nó cho phép triển khai ngẫu nhiên
trong các vùng không thể tiếp cận hoặc các khu vực nguy hiểm. Khả năng tự tổ
chức mạng và cộng tác làm việc của các cảm biến không dây là những đặc trưng
rất cơ bản của mạng này.
4
Clients
Gateway
Sensor Node
Hình 2.1 Cấu trúc mạng cảm biến không dây
Hình 1.1 mô tả cấu trúc mạng cảm biến không dây, các nút cảm biến (sensor
node) được thiết lập trong một trường cảm biến. Mỗi nút cảm biến bao gồm bốn
thành phần cơ bản là: bộ cảm biến (Sensing unit), bộ xử lý (Processing unit), bộ
thu phát không dây (Tranceiver) và nguồn điện (Power generator). Tuỳ theo ứng
dụng cụ thể, nút cảm biến còn có thể có các thành phần bổ sung như hệ thống tìm
vị trí, bộ sinh năng lượng và thiết bị di động.
Hình 2.2 Các thành phần của một nút cảm biến[2]
2.1.3 Kiến trúc và giao thức của mạng cảm biến không dây
Kiến trúc giao thức được sử dụng trong bộ thu nhận (Sink) và tất cả các nút
cảm biến được thể hiện trên hình 1.3. Kiến trúc giao thức này phối hợp các tính
toán về định tuyến và năng lượng, kết hợp số liệu với các giao thức mạng, truyền
tin với hiệu quả về năng lượng thông qua môi trường không dây và tăng cường sự
5
hợp tác giữa các nút cảm biến. Kiến trúc giao thức bao gồm lớp ứng dụng
(Application Layer), lớp giao vận (Transport Layer), lớp mạng (Network Layer),
lớp liên kết dữ liệu (Datalink Layer), lớp vật lý (Physical Layer). Ngoài ra còn có
các lớp chéo (Cross layer) đè lên năm lớp trên: mặt phẳng quản lý năng lượng
(Power Management Plane), mặt phẳng quản lý di động (Mobility Management
Plane) và mặt phẳng quản lý nhiệm vụ (Task Management Plane).
Hình 2.3 Kiến trúc mạng cảm biến không dây[3]
2.1.4 Ứng dụng của mạng cảm biến không dây

a. Giám sát và điều khiển công nghiệp
Đặc thù của giám sát và điều khiển công nghiệp là môi trường nhiễu lớn,
không đòi hỏi lượng lớn dữ liệu thông tin được truyền tải nhưng yêu cầu rất cao về
độ tin cậy và đáp ứng thời gian thực. Mạng cảm biến không dây được ứng dụng
trong linh vực này chủ yếu phục vụ việc thu thập thông tin, giám sát trạng thái hoạt
động của hệ thống, như trạng thái các van, trạng thái thiết bị, nhiệt độ và áp suất
của nguyên liệu được lưu trữ.
b. Tự động hoá gia đình và điện dân dụng
Gia đình là không gian ứng dụng rất lớn cho các mạng cảm biến không dây.
SmartHome là thuật ngữ để chỉ một ngôi nhà thông minh với sự ứng dụng toàn
6
diện của các thiết bị cảm biến không dây. Mục đích lớn của các mạng cảm biến
không dây trong gia đình được mong chờ là mức tiêu thụ điện thấp và hoạt động
ổn định.
c. Ứng dụng trong quân sự
Các mạng cảm biến không dây là một phần không thể thiếu trong các ứng
dụng quân sự ngày nay với các hệ thống mệnh lệnh, điều khiển, thu thập tin tức
tình báo truyền thông, tính toán, theo dõi kẻ tình nghi, trinh sát và tìm mục tiêu.
Các đặc tính triển khai nhanh chóng, tự tổ chức và khả năng chịu đựng lỗi của các
mạng cảm biến cho thấy đây là một công nghệ đầy triển vọng trong lĩnh vực quân
sự.
d. Ứng dụng trong y tế
Một số ứng dụng trong y tế của mạng cảm biến không dây là cung cấp khả
năng giao tiếp cho người khuyết tật, kiểm tra tình trạng của bệnh nhân, chẩn đoán,
quản lý dược phẩm trong bệnh viện, kiểm tra sự di chuyển và các cơ chế sinh học
bên trong của côn trùng và các loài sinh vật nhỏ khác.
e. Ứng dụng trong môi trường và ngành nông nghiệp
Một số các ứng dụng về môi trường của mạng cảm biến không dây bao gồm
kiểm tra các điều kiện môi trường ảnh hưởng tới mùa màng và vật nuôi; tình trạng
nước tưới; phát hiện hóa học, sinh học; kiểm tra môi trường không khí, đất trồng,
biển; phát hiện cháy rừng; nghiên cứu khí tượng và địa lý; phát hiện lũ lụt; vẽ bản
đồ sinh học phức tạp của môi trường và nghiên cứu ô nhiễm môi trường.
2.2 IPv6
2.2.1 Tổng quan về IPv6

Địa chỉ IP hiện nay đa phần đang sử dụng là thuộc thế hệ 4 (IPv4), sử dụng
32 bit để mã hóa địa chỉ. Theo lý thuyết thì IPv4 chứa hơn 4 tỷ (232 ) địa chỉ và có
thể cạn kiệt trong tương lai gần. Chính điều này thúc đẩy sự ra đời một thế hệ địa
chỉ Internet mới IPv6. Hình 1.4 là thống kê từ Tổ chức cấp phát số hiệu
Internet (IANA, Internet Assigned Numbers Authority).
7
Hình 2.4 Thực trạng địa chỉ IPv4 hiện nay[4]
IPv6 ra đời với hi vọng khắc phục những hạn chế vốn có của địa chỉ IPv4 như
không gian địa chỉ, cấu trúc định tuyến và bảo mật, đồng thời đem lại những đặc
tính mới thỏa mãn các nhu cầu dịch vụ của thế hệ mạng mới (như khả năng tự động
cấu hình mà không cần hỗ trợ của máy chủ DHCP Server, cấu trúc định tuyến tốt
hơn, hỗ trợ Multicast, hỗ trợ bảo mật và di động tốt hơn). Hiện nay, IPv6 đang được
chuẩn hóa từng bước và đưa vào sử dụng thực tế. IPv6 ra đời không có nghĩa là
phủ nhận hoàn toàn IPv4. Vì là một phiên bản hoàn toàn mới của công nghệ IP,
việc nghiên cứu, ứng dụng vào thực tiễn luôn là một thách thức rất lớn liên quan
đến khả năng tương thích giữa IPv6 và IPv4, liên quan đến việc chuyển đổi từ IPv4
lên IPv6, làm thế nào mà người dùng có thể khai thác những thế mạnh của IPv6
nhưng không nhất thiết phải nâng cấp đồng loạt toàn bộ mạng (LAN, WAN,
Internet…) lên IPv6.
8
2.2.2 Các loại địa chỉ IPv6

Địa chỉ IPv6 được chia làm 3 loại chính [5]:
 Địa chỉ Unicast: được sử dụng để xác định một Interface. Một gói tin có đích
đến là một địa chỉ unicast thông qua Routing sẽ chuyển đến một Interface
duy nhất trong mạng.
 Địa chỉ Anycast: được sử dụng để xác định nhiều Interface. Tuy nhiên, gói
có địa chỉ đến là anycast sẽ thông qua routing để chuyển đến chỉ một node
trong số các Interface có cùng địa chỉ anycast, thông thường là Interface gần
nhất.
 Địa chỉ Multicast : được sử dụng để xác định nhiều Interface, một gói có địa
chỉ đến là địa chỉ multicast sẽ thông qua quá trình routing để chuyển đến tất
cả những interface có cùng địa chỉ multicast. Như vậy, trong IPv6 không có
địa chỉ Broadcast, vì Broadcast đã được bao gồm trong nhóm địa chỉ
Multicast.
2.3 6LoWPAN
2.3.1 Tổng quan
6LoWPAN [1, 6, 7] viết tắt của IPv6 over Low Power Wireless Area
Networks, là một chuẩn giao thức internet dành cho mạng cảm biến không dây,
hoạt động trên chuẩn IEEE 802.15.4. Giao thức 6LoWPAN có phạm vị ứng dụng
rộng rãi, trong nhiều mục đích ứng dụng khác nhau như điều khiển thiết bị trong
nhà, các thiết bị thể thao, thiết bị y tế, giám sát môi trường, tự động hoá trong công
nghiệp.
Kiến trúc mạng của giao thức 6LoWPAN như trong hình dưới:
9
Hình 2.5 Kiến trúc mạng 6LowPAN[1]
2.3.2 Các đặc tính của 6LoWPAN:
Các giao thức trong 6LoWPAN hỗ trợ cả hai phương thức đánh địa chỉ
64 bit và 16 bit theo chuẩn IEEE 802.15.4. 6LoWPAN được thiết kế để phù
hợp với các lớp liên kết năng lượng thấp như IEEE 802.15.4, những mạng
cảm biến năng lượng thấp, băng thông nhỏ, giao tiếp theo kiểu power -
line.
Ngoài ra, 6LoWPAN cũng có phương thức nén header hiệu quả, tự động cấu
hình mạng bằng cách sử dụng cơ chế neighbor discovery, hỗ trợ các phương
thức truyền multicast, unicast và broadcast.
2.3.3 Kiến trúc của mạng 6LoWPAN

Kiến trúc của mạng 6LoWPAN [1] cũng giống như mạng LoWPAN, chỉ khác
ở chỗ tất cả các nút trong mạng đểu sử dụng IPv6. Theo mô tả như hình 1.9, có 3
loại : Mạng LowPAN đơn giản (Simple LoWPAN), Mạng LowPAN mở rộng
(Extended LoWPAN), Mạng Ad hoc LoWPAN (Ad hoc LoWPAN).
Ad hoc LoWPAN không được kết nối đến Internet, nhưng bù lại nó vận hành
mà không cần bất cứ cơ sở hạ tầng cố định nào, giữa các nút có thể tự tạo kết nối
với nhau. Simple LoWPAN được kết nối đến mạng IP khác thông qua một Edge
Router. Extended LoWPAN chứa đựng các Simple LoWPAN, mỗi Edge Router
10
của nó sẽ được kết nối với nhau thông qua một backhaul (hay còn gọi là backbone),
sau đó từ backbone này sẽ được kết nối đến internet.
Hình 2.6 Kiến trúc mạng 6LoWPAN[1]
2.3.4 Quá trình thiết lập và vận hành 6LoWPAN

Các ứng dụng của 6LoWPAN thường liên quan đến các thiết bị và mạng hoàn
toàn tự động, điều đó có nghĩa chúng phải tự động cấu hình mà không cần sự can
thiệp của con người.
Để cho một mạng 6LoWPAN hoạt động, trước tiên phải thiết lập :
- Giao tiếp giữa các nút trong mạng ở lớp liên kết (Link layer): Để cho các
nút mạng có thể trao đổi thông tin với nhau, trước tiên, chúng phải tương
thích với nhau ở lớp vật lý cũng như là ở lớp liên kết.
11
- Cấu hình địa chỉ lớp mạng (Network layer), xác định các nút lân cận
(Neighbor Discovery): Khi lớp liên kết đã hoạt động và có thể liên lạc giữa
các thiết bị liền kề (one-hop), cơ chế 6LoWPAN Neighbor Discovery
(6LoWPAN-ND) được sử dụng để tự cấu hình và khởi động toàn bộ mạng.
- Thuật toán định tuyến (khởi tạo các đường định tuyến).
- Tiếp tục bảo trì cho các bước trên hoạt động đúng và ổn định.
2.4 Continki OS
2.4.1 Tổng quan
Hệ điều hành Contiki [1, 6] là một hệ điều hành mã nguồn mở phổ biến cho
các kiến trúc vi điều khiển nhỏ như AVR, 8051, MSP430, hoạt động dựa trên cơ
chế event - driven và có những đặc điểm phù hợp với các hệ thống nhúng và mạng
cảm biến không dây. Với Contiki, việc phát triển rất dễ dàng và nhanh chóng: Các
ứng dụng Contiki được viết bằng C tiêu chuẩn, với trình giả lập Cooja Mạng
Contiki có thể được mô phỏng trước khi ghi vào phần cứng và Instant Contiki cung
cấp toàn bộ môi trường phát triển trong một lần tải xuống.
Bên cạnh đó, Contiki còn cung cấp những công cụ hỗ trợ mô phỏng với giao diện
đơn giản, dễ sử dụng và hỗ trợ tốt những thiết bị trong thực tế, phục vụ những mục
đích nghiên cứu, mô phỏng và triển khai những giao thức mới.
2.4.2 Giao thức MAC trong Contiki OS

Một nhiệm vụ quan trọng của lớp MAC là kiểm soát truy nhập vào các kênh
truyền vô tuyến. Trong mạng cảm biến không dây, bộ vô tuyến cần phải được tắt
nhiều nhất có thể để tiết kiệm năng lượng. Điều này được thực hiện bởi các giao
thức RDC (Radio Duty Cycle) trong hệ điều hành Contiki. Hiện tại, hệ điều hành
Contiki đã thực thi một số giao thức RDC bao gồm các giao thức ContikiMAC,
XMAC, ngoài ra còn có NullRDC, một giao thức không thực hiện bất kì một cơ
chế xử lý nào ở lớp MAC. Trong luận văn này, nhóm sử dụng 2 giao thức MAC là
ContikiMAC và NullRDC để mô phỏng và tiến hành thực nghiệm.
a. Giao thức ContikiMAC
12
Cũng tương tự như XMAC, ContikiMAC [8] cũng sử dụng cơ chế thức dậy
định kì (perodical wake-up) để phát hiện sự truyền tin của các nút lân cận. Nếu
trong quá trình thức dậy, nút phát hiện có gói tin gửi đến, nó sẽ giữ trạng thái
wake-up để có thể nhận được hoàn toàn gói tin. Khi quá trình nhận đã hoàn thành,
nó gửi một gói tin ACK để xác nhận đến phía gửi.
Hình 2.7 Cơ chế hoạt động của ContikiMAC[8]
Để gửi một gói tin, phía gửi sẽ gửi lặp đi lặp lại gói tin đó đến khi nó nhận
được gói tin ACK từ phía nhận. Đối với trường hợp gói tin đó là gói tin quảng bá
(broadcast), phía gửi sẽ không nhận các gói ACK trả về, thay vào đó, để đảm bảo
tất cả các nút sẽ nhận được, nó sẽ liên tục gửi gói tin và đồng thời cũng ở trong
trạng thái luôn thức (full wake-up).
Hình 2.8 ContikiMAC với trường hợp gửi broadcast[8]
13
b. Giao thức NullRDC

NullRDC là giao thức mặc định trong ContikiOS stack layers, khi thực hiện
giao thức này, tất cả các nút đều trong trạng thái thức (always on), do đó nó không
tiết kiệm năng lượng, nhưng bù lại thì đảm bảo các gói tin nhận được sẽ không bị
drop. Ta sử dụng NullRDC trong các trường hợp testing hay để so sánh với các
giao thức RDC khác.
2.5 Giao thức định tuyến RPL

2.5.1 Tổng quan
Trong mô hình mạng không dây công suất thấp cũng cần phải có quá trình
định tuyến để đến đích. Nhằm đáp ứng các yêu cầu cho việc truyền dữ liệu trong
môi trường suy hao công suất thấp đối với mạng IPv6, giao thức định tuyến cho
mạng công suất thấp RPL đã được thiết kế.
RPL – IPv6 Routing Protocol for Low Power and Lossy Network là giao thức định
tuyến cho mạng tổn hao năng lượng thấp nói chung và mạng cảm biến không dây
nói riêng. RPL là giao thức định tuyến theo vector khoảng cách (distance-vector)
[9] nhưng có thêm một số cải tiến để hoạt động trọng môi trường LLN. Các yếu tố
cải tiến được sử dụng bao gồm:
 Sử dụng thuật toán “Trickle” để quảng bá thông tin định tuyến. Nguyên lí cơ
bản của thuật toán này là dựa vào trạng thái của mạng hiện tại và năng lực xử
lý của các node để điều chỉnh tần suất gửi thông tin quảng bá phù hợp.
 Phân tập theo không gian (Spatial diversity): Đặc điểm phân tập theo không
gian cho phép mỗi node có một tập các node mạng cha để sẵn sàng thay thế
lẫn nhau khi cần thiết. Nếu một nút mạng cha bị mất kết nối, nút mạng con
sẽ sử dụng parent node khác để đến gateway.
 Sử dụng giải pháp ước lượng bước truyền ETX (Estimated number of
Transmission) để tính toán metric động. Đối với giao thức RPL, mectric được
sử dụng là metric động vì là đại lượng thay đổi liên tục, có giá trị khác nhau
14
tại mỗi thời điểm tính toán. Việc sử dụng mectric động có ưu điểm hơn
mectric tĩnh vì phản ánh được trạng thái hiện tại của mạng.
2.5.2 Quá trình xây dựng kết nối mạng

RPL sử dụng bốn thành phần để nhận dạng và duy trì một toppo mạng bao
gồm: RPL instance ID, DAG ID, DODAG sequence number và Rank [7, 9, 10].
RPL xây dựng và sử dụng các DAG trong mạng để thực hiện quá trình định tuyến.
Trong đó, Directed Acyclic Graph – DAG là một topo mạng mà mọi liên kết giữa
các node trong DAG đều có hướng nhất định, hướng về một DAG ROOT và đảm
bảo không tạo ra các vòng lặp trong DAG.
Hình 2.9 Mô hình DODAG
DAG ID – DAG Identifier: mã nhận dạng của mỗi DAG trong mạng. Tất cả
các node trong mạng đều lưu DAGID của DAG mà nó là thành viên.
DAG ROOT là một node trong DAG, có chức năng tập trung và xử lý dữ liệu
từ các node khác trong mạng gửi đến. Mọi tuyến liên kết trong DAG đều hướng về
và kết thúc tại DAG ROOT.
15
Rank: là khái niệm chỉ vị trí của nút mạng đến các nút khác có liên quan
trong một DODAG và giá trị sẽ tăng theo hướng xuống và giảm theo hướng lên.
Object function (OF): là hàm chức năng cung cấp các phương thức cho phép
một node lựa chọn được DAG phù hợp, tính toán rank và lựa chọn các parent trong
DAG. Các OF được thiết kế theo những quy tắc cụ thể tùy theo mục đích và phương
thức định tuyến.
RPL Instance: là một tập hợp gồm một hoặc nhiều DAG có cơ chế định tuyến
giống nhau. Mỗi Instance chỉ sử dụng một Objective Function duy nhất để xây
dựng cấu trúc mạng.
DAG sequence number là một bộ đếm tuần tự được sử dụng trong quá trình
sửa chữa và làm mới DAG. Khi một DAG ROOT muốn xây dựng lại một DAG
mới, sequence number được tăng lên một đơn vị và quảng bá tới các node khác
trong mạng.
RPL sử dụng bốn loại bản tin điểu khiển (control message):
 DODAG Information Object (DIO), có ý nghĩa quan trọng nhất. Nó lưu
thông tin về vị trí (rank) hiện tại của node, RPL instance hiện tại, địa chỉ của
ROOT.
 Destination Advertisement Object (DAO): hỗ trợ lưu lượng hướng xuống và
được dùng cho node để yêu cầu một bản tin DIO từ neighbor.
 DODAG Information Solicitation (DIS): dùng để yêu cầu một bản tin DIO
từ neighbor.
 DAO-ACK: là bản tin phản hồi tương ứng của bản tin DAO.
Cấu trúc của mạng (topology) bắt đầu tại ROOT, nơi xuất phát của bản tin
DIO. Mỗi node nhận được message sẽ chạy thuật toán (Object Function) để chọn
nút mạng cha (PARENT) tương ứng. Sau đó, mỗi node sẽ tự tính toán rank của
chúng và gửi DIO message đến các neighbor tiếp theo.Topo mạng sẽ được hình
thành như hình 9.
16
Trong trường hợp định tuyến hướng lên (upward), các node chỉ quan tâm đến
các node cha, không cần quan tâm đến các node con. Trong quá trình này, bản tin
DIO đóng vai trò quan trọng nhất, là nguồn thông tin chính cần thiết cho quá trình
tạo thành topo mạng.
Đối với trường hợp định tuyến hướng xuống (downward) được sử dụng cho
trường hợp truyền tin dạng P2MP hoặc P2P. Khi tham gia vào quá trình định tuyến
hướng xuống, các node sử dụng bản tin DAO và DAO ACK. Định tuyến hướng
lên là quá trình node root gửi bản tin DIO đến các node kế cận nó, quá trình lặp lại
cho đến khi bản tin DIO đến node thấp nhất thì dừng lại, còn định tuyến hướng
xuống thì ngược lại, các node gửi bản tin DAO lên các node cha, quá trình lặp lại
cho đến khi bản tin DAO đến node ROOT thì dừng lại.
2.5.3 Các chế độ định tuyến trong giao thức RPL

RPL quy định hai chế độ hoạt động [9] hỗ trợ P2MP: non-storing mode và
storing mode.
Đầu tiên là chế độ non-storing. Trong chế độ này, mỗi node sẽ lan truyền danh
sách parent node đến root. Sau khi nhận được topo mạng, root sẽ tính toán đường
đi đến đích. Các bản tin DAO được gửi từ các node trong mạng trực tiếp đến node
ROOT (Hình 2.10).
1 DAO
Routing Table
Connectivity
2 3
5
4 6
Hình 2.10 RPL Non-storing mode
17
Chế độ thứ hai là storing mode, trong đó mỗi node phải duy trì bảng thông tin
định tuyến cho các đích. Các bản tin DAO được gửi theo từng chặng lần lượt đến
từng node cha (PARENT) trước khi đến node ROOT (Hình 2.11).
1 DAO
Routing Table
Connectivity
2 3
5
4 6
Hình 2.11 RPL Storing mode
18
Chương 3: Các giải thuật multicast
CHƯƠNG 3 CÁC GIẢI THUẬT MULTICAST

Mục tiêu chung của các giải thuật multicast là phân phối các gói tin multicast
tới tất cả các đối tượng có tham gia nhóm multicast đó. Trong giới hạn của luận
văn, nhóm sẽ thực hiện đánh giá 3 giải thuật Multicast cho mạng 6LoWPAN/IPV6
hiện có là MPL/TM, SMRF và ESMRF.
Trong phần này, đầu tiên thuật toán Trickle được sử dụng trong giải thuật MPL/TM
sẽ được trình bày một cách tổng quát. Sau đó lần lượt các giải thuật multicast sẽ
được mô tả. Cuối cùng là phần đánh giá và so sánh 3 giải thuật.
3.1 Thuật toán Trickle
3.1.1 Tổng quan

Thuật toán trickle cho phép các node trong mạng công suất thấp và mất mát
(low-power and lossy network) trao đổi thông tin với nhau một cách hiệu quả, tiết
kiệm năng lượng, đơn giản và khả năng mở rộng hệ thống linh hoạt [11]. Bằng cách
tự động điều chỉnh các biến số, Trickle tăng tốc độ truyền tin đột ngột để gửi thông
tin mới hoặc chỉ gửi một vài gói tin mỗi giờ khi không có gì thay đổi. Trong thuật
toán Trickle, toàn bộ các gói tin được gửi tới địa chỉ giao tiếp local.
Cách thức hoạt động của thuật toán trickle khá đơn giản: Sau một khoảng thời gian
nhất định không có gói tin nào được gửi chứa dữ liệu mới so với buffer được lưu
trữ của một node, node đó sẽ tiến hành gửi gói tin mà chính mình đang lưu trữ. Dữ
liệu trong gói tin này có thể là trạng thái định tuyến, phiên bản cập nhật phần mềm
và gói multicast gần nhất. Phương thức này cho phép Trickle mở rộng quy mô lên
hàng nghìn lần trong mật độ mạng, nhanh chóng quảng bá các cập nhật, phân phối
tải, linh hoạt trong xử lý ngắt kết nối tạm thời của một node [12]...
3.1.2 Các tham số và biến

Một bộ Trickle Timer chạy trong một khoản thời gian xác định bao gồm 3 tham số
sau [12]:
• Imin: khoảng interval nhỏ nhất, được xác định theo đơn vị thời gian
(millisecond, seconds,..). Ví dụ: 100ms.
19
• Imax: khoảng interval lớn nhất, được xác định bằng logarit cơ số 2 của
max/min
Ví dụ: một giao thức có Imax là 16 và Imin là 100ms, khoảng interval được
tính là 100 ms * 216, tương đương với 6,553.6 giây.
• Hằng số K, được xác định là một số tự nhiên lớn hơn 0. Dùng để giới hạn
số lần gửi gói tin khi hệ thống hoàn toàn ổn đinh và không có thay đổi trong
thời gian dài.
Ngoài 3 tham số trên, thuật toán trickle còn có 3 biến:

• I, khoảng interval hiện tại.
• t, thời điểm chính xác trong khoảng interval hiện tại.
• c, biến đếm.
3.1.3 Mô tả hoạt động

Một giải thuật chứa thuật toán Trickle hoạt động theo 6 nguyên tắc sau[12]:
i. Khi thuật toán bắt đầu thực thi, biến I được cài đặt trong khoảng
[Imin,Imax] và khoảng interval đầu tiên được khởi động.
ii. Khi khoảng interval I khởi động, biến c được đặt lại về 0 và t được chọn
ngẫu nhiên trong khoảng [I/2,I].
iii. Nếu Trickle phát hiện thấy một quá trình truyền tin “đồng bộ”, biến c được
tăng lên.
iv. Tại thời điểm t, Trickle sẽ kích hoạt các quá trình gửi gói tin khi và chỉ khi
c nhỏ hơn hằng số K.
v. Khi khoảngthực interval I kết thúc, Trickle tăng gấp đôi độ dài của khoảng
I. Nếu vược quá giá trị Imax, độ dài của khoảng I sẽ được cài đặt là Imax.
vi. Nếu Trickle phát hiện một quá trình tuyền tin “bất đồng bộ”, Trickle timer
sẽ được cài đặt lại bằng cách gán I bằng Imin và bắt đầu lại từ bước 2.
20
Hình 3.1 Thuật toán Trickle
3.2 MPL/TM
3.2.1 Nội dung giải thuật
Giao thức multicast cho mạng công suất thấp và mất mát (Multicast Protocol
for Low Power and Lossy networks – MPL) là một dạng mở rộng, phát triển của
giao thức RPL nhằm mục đích hỗ trợ khả năng multicast cho mạng WSN[13].
MPL sử dụng thuật toán Trickle để truyền gói tin đối với cả gói điều khiển và gói
dữ liệu, vì thế, giải thuật này còn được gọi là Trickle Multicast (TM). Trong luận
văn này, nhóm sử dụng MPL, TM một cách song song và thay thế cho nhau.
21
Trickle, là một phương pháp hiệu quả để trao đổi thông tin giữa hai node lân
cận mà không làm “flooding” toàn bộ mạng bằng cách kiểm soát tốc độ trao đổi
thông tin dựa trên so sánh trạng thái của hai node đó. Tốc độ này đạt mức tối đa
khi hai node không cùng trạng thái và tối thiểu khi có sự nhất quán giữa chúng.
Trong quá trình hoạt động, MPL tạo 2 loại gói tin là MPL data message và MPL
control messsage [14]. MPL data message là gói tin multicast được thêm phần mở
rộng lưu trữ thông tin source id và số thứ tự của gói. Thông tin của phần mở rộng
này duy trì không đổi trong quá trình truyền gói. Trong khi đó, MPL control
message là gói tin lưu trữ các source id đã gửi gói multicast và số thứ tự của gói đã
nhận được tương ứng. Đồng thời, mỗi node được cài đặt một buffer/cache để lưu
trữ thông tin được gửi đi trong MPL control message. Các quy định về MPL data
message và MPL control message được cung cấp tại tài liệu[14].
Giải thuật MPL thực hiện các tác vụ sau trong quá trình thực hiện multicast [14]:
Hình 3.2(A) xử lý gói MPL data message và (B) xử lý MPL control message
• Khi có một gói tin multicast cần được gửi đi trong mạng, Source node sẽ
khỏi tạo MPL data message – một gói tin chứa địa chỉ đích Ipv6, id của
22
nguồn gửi gói, một số thứ tự (sequence number) và dữ liệu cần gửi. Và gói
tin này được gửi đi trong mạng.
• Khi nhận được một gói MPL data message, các node sẽ xem xét id của
nguồn và số thứ tự trên gói để kiểm tra xem gói đã được nhận trước đó hay
chưa bằng cách so sánh với các giá trị tương ứng được lưu trong cache/buffer
của chính node đó. Nếu số thứ tự của gói tới nhỏ hơn số được lưu trong
buffer, node sẽ đánh dấu MPL data message là đã cũ. Ngược lại, node sẽ
đánh dấu gói là mới.
• Với mỗi gói MPL data message mới nhận được, các node sẽ cập nhận dữ
liệu trong buffer của nó và lưu MPL data message vào bộ nhớ thành
Buffered Message Set. Sau đó node sẽ xử lý nội dung gói và thực hiện
multicast gói MPL data message vài lần tới tất cả các node xung quanh nó.
• Các node có thể gửi tới node liền kề các gói tin MPL control message trao
đổi thông tin được lưu trữ trong buffer và Buffered Message Set để chắc
rằng tất cả các node trong mạng nhận được cùng một gói multicast. Quá
trình này xảy ra theo chu kì Trickle Consequence Check (TCC) và chỉ xảy
ra giữa các node cách nhau một bước nhảy thông qua gói tin ICMPv6.
• Với mỗi gói MPL control message nhận được, các node sẽ so sánh với buffer
của bản thân để kiểm tra xem liệu có tồn tại gói MPL data message nào mà
nguồn gửi gói MPL control message chưa nhận được hay không, nếu có, nó
sẽ tiến hành reset Trickle Timer để tăng tốc độ truyền gói multicast; ngược
lại, nó tăng TCC và Trickler timer dần dần nằm tránh “flooding” mạng.
3.2.2 Đánh giá giải thuật

 Ưu điểm: Độ tin cậy cao, không lặp gói, hoạt động đa hướng, khả năng mở rộng
hệ thống linh hoạt.
Nhờ vào việc sử dụng 2 loại gói tin và giao tiếp giữa các node liền kể,
MPL/TM có độ tin cậy cao khi lưu trữ dữ liệu và duy trì trạng thái gói tin trong
toàn mạng. Từ đó tăng tỉ lệ truyền gói (PDR). Hơn nữa, việc đánh dấu các gói dữ
23
liệu multicast bằng số thứ tự (sequence number), TM đảm bảo rằng mỗi gói tin chỉ
được nhận một lần duy nhất tại mỗi node, tránh lặp gói. MPL/TM cũng cung cấp
khả năng hoạt động linh hoạt khi có thể nhận và truyền gói từ tất cả các hướng.
Nghĩa là giải thuật multicast MPL/TM hoạt động độc lập với cây DODAG, không
cần thông tin về cây DODAG. Đồng thời, do không phụ thuộc RPL nên MPL/TM
có thể hoạt động song song với bất kì giao thức định tuyến nào [15].Giải thuật này
cho phép khả năng mở rộng linh hoạt cho hệ thống khi người dùng muốn thêm
hoặc loại bỏ node.
 Nhược điểm: Độ trễ end-to-end cao, độ phức tạp cao, tổn hao bộ nhớ khi hệ
thống lớn.
Chính vì phải lưu trữ các gói tin MPL data message và đợi MPL control
message, truyền cả 2 loại gói phải vào thời điểm t của thuật toán Trickle Interval
gây nên một cản trở khá lớn cho giải thuật là thời gian trễ gửi/nhận gói giữa nguồn
và đích khá lớn. Độ phức tạp của giải thuật cũng khá cao khi mỗi node phải duy trì
2 Trickler timers, một sliding window để lưu trữ gói MPL data message [16]. Đồng
thời, mỗi node đều phải có khả năng tạo và xử lý một loại gói ICMPv6 mới (MPL
control message) và một phần mở rộng. Khi có gói tin tới, node phải so sánh thông
tin từ gói với tất cả thông tin đã được lưu trữ. Mặc dù bỏ qua thông tin về cây
DODAG giúp giảm một phần nào đó bộ nhớ, tuy nhiên vấn đề này cần được xem
xét khi hệ thống tăng dần lượng node. Trong một mạng lưới có nhiều node, mỗi
node đều phải tăng bộ nhớ để lưu trữ các source id, số thứ tự gói tương ứng và
Buffered Message Set lớn.
3.3 Stateless multicast RPL forwarding – SMRF

SMRF là một giải thuật multicast được sử dụng thay cho MPL/TM khi nó
giúp cải thiện các yếu tố vốn là rào cản của MPL/TM như end-to-end delay. SMRF
được thiết kế cho mạng RPL và sử dụng chế độ hoạt động storing with multicast
được hỗ trợ trong Contiki OS. Trong chế độ hoạt động này, các gói tạo cây DODAG
24
– DAO được dử dụng để truyền thông tin về việc tham gia nhóm multicast của các
node lên cây DODAG [17].
Một node sẽ tham gia và quảng bá địa chỉ nhóm multicast của mình trong các
gói unicast DAO theo chiều lên trên cây DODAG. Nhờ vào đó, các nodes cha sẽ
biết địa chỉ multicast của các node con của nó và tạo một entry cho các địa chỉ này
trong bảng định tuyến. Entry này mang ý nghĩa là “một node bên dưới tôi trong cây
DODAG là thành viên của nhóm multicast này” [15]. Tiếp theo, node cha sẽ tiến
hành quảng bá các entry này lên phía root của cây DODAG. Nhờ vào việc sử dụng
các gói DAO, giải thuật SMRF vẫn có thể thực thiện multicast mà không cần phải
tạo một loại gói mới như ở MPL/TM. Các gói DAO này giống hệt với các gói DAO
thông thường dùng để truyền tải thông tin unicast, ngoại trừ được thêm vào phần
đầu một địa chỉ multicast Ipv6 dùng để định tuyến [15]. Giải thuật SMRF có thể
được mô tả bằng lưu đồ 3.3:
- Một node sẽ chấp nhận gói multicast khi và chỉ khi gói đó được gửi tới từ
preferred parent của nó. Ở đây, preferred parent nghĩa là node cha trực tiếp
của một node. Việc này được thực hiện bằng cách so sánh địa chỉ nguồn
link-layer của gói tin với địa chỉ link-layer của node cha trực tiếp được lưu
trong bộ nhớ của node.
- Trong trường hợp gói multicast không tới từ preferred parent, node sẽ loại
bỏ gói và không xử lý thêm.
- Sau đó nếu gói được chấp nhận, node sẽ kiểm tra địa chỉ multicast đích của
gói tin. Gói tin sẽ được xử lý nội dung nếu node thuộc nhóm multicast đích.
- Nếu gói multicast đã được chấp nhận, dù node có thuộc nhóm multcast đích
của gói tin hay không, gói đó vẫn sẽ được truyền xuống cây DODAG khi
tồn tại một entry trong bảng định tuyển của node thuộc về nhóm multicast.
Ngược lại, gói multicast sẽ bị loại bỏ.
25
Hình 3.3 Giải thuật SMRF [15]

- Ưu điểm: Tránh lặp gói, độ phức tạp thấp, độ trễ thấp, truyền gói chọn lọc.
Với giải thuật SMRF, vì mỗi node chỉ nhận gói được truyền từ node cha trực
tiếp và chỉ chuyển tiếp gói một lần duy nhất nên giải thuật đảm bảo mỗi gói dữ liệu
26
chỉ nhận được một trên mỗi gói. Việc này cũng giúp SMRF không yêu cầu một
phương pháp để đánh số các gói tin như ở SMRF. Các node không yêu cầu phải
tạo bất kỳ loại gói tin mới nào, đồng thời cũng không cần duy trì kiểm tra trạng thái
khi mỗi gói tin được gửi đi giúp giảm độ phức tạp của thuật toán. Quá trình quyết
định “loại bỏ hoặc chấp nhận” xảy ra khi gói tin tới mỗi node cũng như việc không
phụ thuộc vào trickle timer giúp giảm thời gian chờ từ đó giảm độ trễ end-to-end –
một nhược điểm khá lớn ở giải thuật MPL/TM [15]. SMRF phân biệt các node dựa
vào nhóm multicast được lưu trữ cùng với thông tin cây DODAG. Thay vì gửi
multicast tới tất cả các kết nối xung quanh nó như ở MPL/TM, các node chỉ gửi
đến kết nối có trong nhóm multicast một cách chọn lọc.
- Nhược điểm: Tính định hướng cao, không cung cấp khả năng hoạt động ngược.
Lưu ý rằng, giải thuật SMRF không có khả năng truyền gói lên trên cây
DODAG mà chỉ có thể truyền một chiều đi xuống. Tính năng này chỉ hữu dụng đối
với các ứng dụng dịch vụ hoặc quản lý mạng. Đây là nhược điểm lớn nhất của
SMRF trong khả năng hoạt động.
3.4 Enhanced Stateless multicast RPL forwarding – ESMRF

ESMRF là một giải thuật được cải tiến từ giải thuật SMRF với mục đích là
giải quyết vấn đề giới hạn hướng gửi gói tin của SMRF. Về cơ bản, ESMRF có tất
cả các tính chất và cách thức hoạt động của SMRF, điểm khác biệt duy nhất là khả
năng cho phép bất kỳ node nào trong cây DODAG có thể gửi gói theo cả 2 chiều
lên và xuống trong cây. Để làm được việc này, ESMRF đề xuất một tính năng mới
gọi là “multicast-on-behalf”[13].
Trong cây DODAG, một node chỉ lưu trữ những liên kết với các node nằm
phía dưới nó, chính điều này gây cản trở cho SMRF khi node hoàn toàn không biết
thông tin phía trên để gửi gói lên. Node duy nhất có thể quan sát được toàn bộ
DODAG là root node [13]. Vì thế root node là đối tượng có thể gửi gói multicast
27
tới toàn bộ các node khác mà không gặp cản trở nào. Lợi dụng yếu tố này,
“multicast-on-behalf” được đưa ra để giải quyết vấn đề truyền tải của SMRF.
Giải thuật ESMRF có quá trình nhận gói và xử lý gói hoàn toàn giống với giải
thuật SMRF. Quá trình gửi gói mới là điểm khác biệt giữa chúng. Trong SMRF,
khi một node có gói multicast cần gửi đi, nó sẽ gửi tới những node con của nó trong
cây DODAG. Trong khi đó đối với ESMRF, quá trình gửi một gói với “multicast-
on-behalf” được mô tả bởi hình 3.5 sau:
- Mỗi khi bất kì node nào có gói tin multicast cần gửi, đầu tiên nó sẽ kiểm tra
xem bản thân có phải là root node hay không bằng DODAG rank.
+ Nếu không phải là root của cây DODAG, nó sẽ tạo một gói tin ICMPv6
đặc biệt và gửi tới địa chỉ của root node. Gói tin này bao gồm các thành
phần như hình 3.4. Trong đó Multicast IP Address chứa địa chỉ nhóm
multicast cần được gửi tới và Multicast Payload nắm giữa dữ liệu của
gói.[13]
+ Nếu là root node, việc gửi gói tin được thực hình bình thường như ở
SMRF.
- Khi nhận root node nhận được gói ICMPv6 này, nó sẽ tiến hành tạo một gói
tin multicast mới theo các dữ liệu nhận được trong gói ICMPv6 và gửi gói
multicast xuống cây DODAG [13]. Lưu ý, vùng địa chỉ nguồn (Destination
address) của gói tin multicast vừa được khởi tạo bởi root node là địa chỉ của
node gửi yêu cầu “multicast-on-behalf”.
Hình 3.4 Gói tin ICMPv6 "Multicast-on-behalf" [13]
28
Hình 3.5 Quá trình gửi "Multicast-on-behalf" của ESMRF

Vì có nền tảng hoàn toàn giống SMRF, ESMRF sở hữu các tính chất ưu và nhược
điểm hoàn toàn tương tự với tiền thân của nó.
Đồng thời, nhờ vào tính năng được bổ sung “Multicast-on-behalf”, ESMRF đã khắc
phục được nhược điểm lớn nhất của SMRF là khả năng hoạt động hạn chế. Với
ESMRF, ta có một giải thuật SMRF có khả năng hoạt động ở cả hai chiều là lên và
xuống cây RPL.
29
Chương 4: Mô phỏng so sánh các giải thuật multicast
CHƯƠNG 4 MÔ PHỎNG SO SÁNH CÁC GIẢI THUẬT MULTICAST

4.1 Mục tiêu mô phỏng
Mục tiêu đầu tiên là kiểm tra hoạt động của 3 thuật toán multicast là SMRF,
ESMRF và TM với các sơ đồ khác nhau. Sau đó, đánh giá và so sánh độ hiệu quả
của 3 thuật toán trong các sơ đồ bằng các đại lượng được xem xét là:
- Tỉ lệ nhận gói (PDR): là phần trăm số gói nhận được của một sink node trong
tổng số gói được truyền đi bởi source node.
- Độ trễ (Delay): Là độ trễ end-to-end trung bình của một sink node tính từ
lúc một gói được gửi đi từ source node cho tới khi sink note nhận được gói
đó.
- Năng lượng tiêu thụ (Power Consumtion –PC): Là hiệu quả sử dụng năng
lượng của một node. Được đánh giá bằng thực hiện luân phiên hiệu quả việc
ngủ (Radio off) và thức (Radio on) của một node để quét tìm gói tin truyền
tới.
Trong luận văn này, Cooja Simulator sẽ được sử dụng để thực hiện việc mô
phỏng đánh giá.
4.2 Công cụ mô phỏng – Cooja
Nhằm đáp ứng nhu cầu nghiên cứu, mô phỏng, đánh giá các giao thức mạng,
Contiki tích hợp một số công cụ mô phỏng có giao diện trực quan, dễ sử dụng như
MSPsim emulator, Cooja simulator và Netsim simulator [18]. Những công cụ này
cho phép thay đổi các thông số của hệ thống như vị trí, phạm vi kết nối, tỉ lệ truyền
gói thành công,... Nhờ đó giúp người sử dụng mô phỏng và đánh giá tổng quan hệ
thống một cách chính xác nhất trước khi thực hiện trên phần cứng.
Trong đó, Cooja Simulator là trình giả lập được thiết kế dành riêng cho mạng
cảm biến không dây (WSNs) và tập trung vào các thiết bị IoT công suất thấp. Mỗi
node mạng được mô phỏng trong Cooja được gọi là Contiki Mote [19]. Một Contiki
Mote thực chất là firmware được biên dịch và thực thi trên thiết bị phần cứng thực
30
tế một cách chính xác nhất. Cooja cung cấp khả năng mô phỏng một mạng lưới
Contiki Mote lớn, nhỏ một cách linh hoạt.Trong cùng một mô phỏng có thể tồn tại
nhiều loại node khác nhau, đại diện cho các loại nút cảm biến khác nhau và thực
hiện chức năng khác nhau (mạng không đồng nhất) [19].
Hình 4.1 Giao diện Cooja simulator
4.3 Thiết kế hệ thống mô phỏng
Quá trình mô phỏng được thực hiện lần lượt với 3 topology, mỗi topology
thực hiện với 3 giải thuật multicast tương ứng để so sánh.
- Đầu vào: Các thông số cài đặt, giải thuật multicast, sink,c và root.c.
- Đầu ra: File loglistener.txt chứa quá trình truyền gói, file Power.txt chứa
mức tiêu thụ năng lượng của từng node.
Các bước thực hiện mô phỏng được mô tả trong phần phụ lục.
4.3.1 Cài đặt mạng

Trong mô hình mô phỏng gồm 20 sink node và 1 root node hoạt động như
một nút gốc của DODAG. Các node sử dụng ứng dụng sink.c và root.c tương ứng
31
được tạo sẵn cho các ví dụ về multicast của Contiki. Tham số của mô hình mô
phỏng được sử dụng cho cả 3 giải thuật được cài đặt như sau:
Bảng 1 Các tham số mô phỏng
Tham số Giá trị
Node Types 21 Sky nodes (1 root, 20 sink)
RDC Driver contikimac_driver
Traffic Unidirectional (from source to sinks)
Trafic Flow 1 Packet/s
Interations 1000
Message Size 4 Bytes (Application layer)
Node-to-node distance 40m
Transmission Range 50m
Interference Range 60m
Tx-Rx Ratio 100%-100%
TM, SMRF,ESMRF Parameters Default
Trong đó:
- RDC Driver xác định Radio Duty Cycling (RDC) layer. Quyết định driver
điều khiển quá trình on/off radio của note. Contikimac_driver cho hiệu suất
năng lượng cao khi cho phép các note on/off radio khi không hoạt động, tuy
nhiên nó làm tăng tỷ lệ mất gói.
- Traffic: Unidirectional (một chiều) để kiểm tra khả năng forward gói tin của
một sink node khi nó nhận được packet.
- Tham số Interations thể hiện số lần gửi gói tin multicast từ source (tổng
cộng 1000 gói).
32
- Khoảng cách giữa mỗi node là 40m, phạm vi truyền là 50m, vùng nhiễu
mỗi node tạo ra có bán kính 60m. Tỉ lệ truyền gói (Tx) và nhận gói (Rx) là
100%.
- Không giới hạn thời gian mô phỏng, việc mô phỏng hoàn thành khi gói thứ
1000 được nhận bởi node nhận cuối cùng.
4.3.2 Thiết kế các sơ đồ mạng

Để đánh giá một cách đầy đủ nhất về hoạt động của cả 3 giải thuật SMRF,
ESMRF, TM, sẽ có 3 sơ đồ (topology) được sử dụng lần lượt cho cả 3 giải thuật là:
forward straight-line topology, backward straight-line topology và random
topology [13].
 Forward straight-line topology
Đối với Forward Straight-line topology, node có id là 1 sẽ đóng vai trò là root
của cây DODAG, đồng thời cũng sẽ là source gửi gói multicast. Các node còn lại
sẽ là sink node, nhận, xử lý gói multicast và forward cho node bên dưới cây
DODAG. Forward Straigt-line Topology được sử dụng để đánh giá khả năng hoạt
động từ trên xuống dưới của các giải thuật multicast.
Hình 4.2 Forward straight-line topology
 Backward straight-line topology

Backward Straight-line Topology dùng để đánh giá khả năng hoạt động từ
dưới lên trên của giải thuât. Node có ID là 1 sẽ là root của cây DODAG. Tuy nhiên,
source gửi multicast packet sẽ là node có ID là 21. Các node ở giữa nhận và forward
multicast packet theo trình tự và hướng dựa vào giải thuật multicast. Nếu giải thuật
multicast là TM, sink node sẽ xử lý multicast packet và forward cho cả node nằm
33
trên và dưới liền kề. Nếu giải thuật multicast là ESMRF, các sink node sẽ không
xử lý packet mà forward thẳng lên root, sau đó root gửi multicast packet đó xuống
các sink node bên dưới. Đến lúc này, các sink node mới thực hiện xử lý packet và
forward multicast packet xuống node phía dưới. SMRF sẽ không hoạt động được
với topology này.
Hình 4.3 Backward straight-line topology

 Random topology
Cuối cùng là Random topology, một sơ đồ ngẫu nhiên duy nhất sẽ được sử
dụng đối với cả 3 giải thuật để đảm báo tính đồng nhất của kết quả mô phỏng. Sơ
đồ được tạo nên bằng cách để Cooja thiết lập vị trí một cách ngẫu nhiêu cho các
node trong một khoảng không gian 200m x 200m. Node id 1 vẫn sẽ giữ vai trò là
root của cây DODAG. Source node gửi multicast packet được chọn ngẫu nhiên là
node có id là 10. Các node còn lại giữ vai trò là sink node, xử lý và forward gói
multicast tới các node xung quanh theo chiều dựa vào giải thuật được sử dụng.
Hình 4.4 Random topology
34
4.4 Kết quả mô phỏng và phân tích
4.4.1 Kết quả mô phỏng

Một lần mô phỏng được đánh giá là thành công khi với mỗi một cặp topology
– giải thuật được kết thúc bằng việc sink node cuối cùng nhận gói thứ 1000
(0x000003E7) và đầu ra loglistener.txt và power.txt được ghi nhận.
File power.txt thống kê lượng năng lượng tiêu thụ của node trong suốt quá
trình mô phỏng.
File Loglistener.txt là file text chứa các thông số như time - thời gian diễn ra
sự kiện, mote – id của node diễn ra sự kiện và message – thông tin. Với mỗi mô
phỏng, file loglistenser.txt chứa trên 10 nghìn dòng dữ liệu. Vì thế, dữ liệu được
xử lý bằng công cụ lập trình sẵn của nhóm thực hiện luận văn. Với đầu vào là file
loglistener.txt, đầu ra là tỉ lệ nhận gói (PDR) và độ trễ trung bình (Average delay –
ms) của từng mote. Chi tiết hoạt động của công cụ được cung cấp tại phụ lục C.
Hình 4.5 Đầu ra của tool xử lý dữ liệu loglistener.txt
Hoạt động của một lần mô phỏng như sau:
35
Hình 4.6 Quá trình khởi tạo của root
Hình 4.7 Quá trình khởi tạo của sink
Hình 4.8 Quá trình gửi và nhận gói
36
Hình 4.9 Giám sát năng lượng tiêu thụ
4.4.2 Phân tích số liệu

Trong mô hình mô phỏng bao gồm 20 sink node và 1 root node. Source node
gửi 1000 gói tin tới các node trong nhóm multicast.
Để tính độ trễ (delay) của từng node, ta tính theo công thức:
∑𝑛 𝑇(𝑘) −𝑅(𝑘)
𝐷𝑒𝑙𝑎𝑦 = 𝑘=1 (ms) (5.1)
𝑛
Với: n: tổng số gói nhận được tại Sink
T(k): thời điểm source gửi gói thứ k
R(k): thời điểm sink node nhận được gói thứ k
Delay chỉ tính đối với các gói được nhận thành công tại sink node. Đối với
những gói bị mất, ta bỏ qua việc tính delay (delay = 0).
Để tính tỉ lệ nhận gói (PDR) tại một node, ta sử dụng công thức:
𝑛
𝑃𝐷𝑅 = ∗ 100 (%) (5.2)
𝐼
Với n: tổng số gói nhận được tại sink
I: tổng số gói gửi đi từ source
Để tính mức tiêu thụ năng lượng, ta sử dụng Powertrace của Contiki.
Sau khi thu thập đủ các dữ liệu từ mô phỏng và thực hiện tool xử lý số liệu,
ta có các số liệu thống kê:
37
a. Forward Straight-line Topology

 Tỉ lệ nhận gói (PDR):
Tỉ lệ nhận gói (PDR) - Forward Topology

100
90
80
70
60
PDR(%)
50
40
30
20
10
0
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
NODE ID
SMRF ESMRF Roll TM
Hình 4.10 PDR trong forward straight-line topology
Đối với Forward straight-line topology, biểu hiện khả năng truyền gói tin theo
chiều từ trên xuống dưới cây DODAG, biểu đồ cho thấy cả 3 giải thuật đều có nét
tương đồng trong hoạt động với PDR có xu hướng giảm dần khi số lượng bước
nhảy từ Source node tới Sink node càng nhiều.
ESMRF và SMRF cho kết quả về PDR tương tự nhau vì về cơ bản, cách
truyền từ trên xuống dưới của 2 giải thuật này là như nhau. Trong khi đó dựa theo
biểu đồ, TM từ root node tới node thứ 15 cho thấy PDR kém hơn ESMRF và SMRF,
tuy nhiên lại có xu hướng ổn định và tiệm cận PDR hơn khi số lượng node tăng
lên. Điều này có thể lí giải do TM khi nhận gói không yêu cầu là từ trực tiếp từ
node cha gần nhất, đồng bộ bằng timer và lưu gói multicast trong bộ nhớ giúp số
lượng bước nhảy từ source node tới sink node không ảnh hướng lớn đến PDR. Tuy
nhiên, chính việc nhận gói không thiết phải từ node cha gây ra việc sink node phải
xử lý cả gói tin multicast từ node con gửi lên. Do đó khi số lượng node hoạt động
38
nhỏ, TM kém hiệu quả hơn so với ESMRF và SMRF và ngược lại khi số lượng
node tăng.
 Độ trễ (delay)
Average Delay - Forward topology

30
25
20
Delay (s)
15
10
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Node ID
Roll TM SMRF ESMRF
Hình 4.11 Đỗ trễ trung bình trong forward straight-line topology

Độ trễ khi truyền gói của cả 3 giải thuật đều có xu hướng tuyến tính, tăng dần
khi số lượng node tăng dần. ESMRF và SMRF không có sự khác biệt trong độ trễ.
Chênh lệch độ trễ giữa TM và 2 giải thuật còn lại khá lớn và càng tăng khi số lượng
node tăng lên. Cho thấy tốc độ gửi và nhận gói tin của SMRF và ESMRF là tối ưu
hơn rất nhiều so với TM ( nhanh hơn 1.5 giây tại node 2, 15 giây tại node 12 và 23
giây tại node 21). Để giải thích hiện tượng này, do ESMRF và SMRF chỉ nhận gói
tin từ node cha trực tiếp của sink node và không xử lý các gói tin từ node con, nên
tốc độ gửi và nhận gói được tăng cao. Trong khi TM phải xử lý các gói tin như
nhiều hướng, và trong giải thuật tồn tại nhiều biến thời gian nên thời gian delay
tăng với tỉ lệ lớn hơn nhiều.
 Năng lượng tiêu thụ (PC)
39
Power Consumption - Forward topology

120.00%
100.00%
80.00%
PC(%)
60.00%
40.00%
20.00%
0.00%
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Node ID
Roll TM SMRF ESMRF
Hình 4.12 Năng lượng tiêu thụ trong forward straight-line topology
Tương tự như với delay và PDR, năng lượng tiêu thụ của ESMRF và SMRF
là như nhau và ít hơn khoảng 10% so với TM trong tổng thể. Lí do TM sử dụng
nhiều năng lượng là vì cần quan sát thông tin của gói tin và gửi gói tin nhiều hơn,
do đó thời gian radio ON tăng lên, tăng năng lượng sử dụng. Số lượng bước nhảy
tới source càng nhiều thì năng lượng sử dụng càng giảm, điều này có thể lí giải là
do số lượng gói nhận được và cần xử lý giảm dần khi bước nhảy tăng lên làm cho
thời gian Radio ON giảm đi, node ở trạng thái nghỉ lâu hơn từ đó giảm năng lượng
tiêu thụ.
b. Backward Straight-line Topology

Giải thuật SMRF không cho phép truyền gói tin theo hướng từ dưới lên trên trong
cây DODAG. Vì thế trong Backward straight-line topology, ta sẽ không tiến hành
phân tích hoạt động của SMRF, tất cả số liệu được để là 0.
 Tỉ lệ nhận gói (PDR)
40
Packet delivery ratio - Backward topopoly

100
90
80
70
60
PDR(%)
50
40
30
20
10
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Node ID
Roll TM SMRF ESMRF
Hình 4.13 Tỉ lệ nhận gói trong backward straight-line topology
Trong backward straight-line topology. TM cho hình dạng biểu đồ PDR tương
tự như với sơ đồ forward, có xu hướng tiệp cận PDR theo số lượng bước nhảy tới
source node tăng dần. Đối với ESMRF, tỉ lệ PDR có xu hướng giảm nhanh, đạt nhỏ
nhất tại node có số bước nhảy xa nhất tới root, đồng thời là node gần kề với source
node. Vì khả năng truyền gói theo chiều từ dưới lên cây DODAG dựa trên phương
pháp “Multicast-on-behalf”. Các node ở giữa sẽ không xử lý gói tin multicast nhận
được mà sẽ forward tới root, sau đó root thực hiện gửi gói tin multicast như với sơ
đồ forward topology. Điều này làm quãng được truyền đi của 1 gói tăng lên rất
nhiều so với forward, từ đó gây việc PDR có biểu đồ như đối với forward straight-
line topology và giảm nhanh từ root tới source node.
 Độ trễ (delay)
Ở biến quan sát độ trễ, TM cho số liệu về độ trễ và dạng biểu đồ ngược với
trường hợp forward straight-line topology vì với TM, không có khác biệt giữa
forward và backward topology. Điều dễ nhầm lẫn là ở độ trễ của ESMRF, khi node
gần source node nhất lại có độ trễ cao nhất (8.118 giây ở node 20). Tuy nhiên điều
này chính xác với mô hình “multicast-on-behalf” của ESMRF khi các node trung
41
gian sẽ không xử lý gói multicast ngay lập tức mà forward về root, và chỉ xử lý gói
tin đó khi root thực hiện gửi gói đó xuống cây DODAG. Đồng thời, mô hình này
cũng làm cho delay của ESMRF trong backward topology cao hơn so với forward
topology ( tăng trung bình 2.6 giây). Nhìn về tổng quan, với độ trễ trung bình của
ESMRF là 5.1 giây, của TM là 17.2 giây, ESMRF vẫn cho thây khả năng truyền
gói nhanh hơn nhiều so với TM.
Average Delay- Backward topology

30
25
20
Delay (s)
15
10
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Node ID
Roll TM SMRF ESMRF
Hình 4.14 Độ trễ trung bình trong backward straight-line topology
 Năng lượng tiêu thụ (PC)

Power Consumption - Backward topology
120%
100%
80%
PC (%)
60%
40%
20%
0%
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Node ID
Roll Tm SMRF ESMRF
Hình 4.15 Năng lượng tiêu thụ trong backward straight-line topology
42
Với năng lượng tiêu thụ, ở cả 2 giải thuật ESMRF và TM source node và root
node luôn hoạt động ở trạng thái radio on 100%, vì 2 node này đảm nhận nhiệm vụ
tương ứng là gửi gói multicast định kỳ và duy trì cây RPL. Giống như với trường
hợp Forward topology, lượng năng lượng sử dụng của ESMRF luôn thấp hơn
khoảng 10% so với TM (ESMRF trung bình 19.10%, TM trung bình 28%).
c. Random topology
Mục đích của Random topology là đánh giả khả năng hoạt động tổng thể của
giải thuật dựa trên một sợ đồ ngẫu nhiên, vì thế các đại lượng được quy về trung
bình của cả hệ thống thay vì cái đại lượng trung bình cho từng node cụ thể.
PDR, PC, Delay - Random topology

70% 10
60%
8
PDR-PC (%)
50%
Delay (s)
40% 6
30% 4
20%
2
10%
0% 0
Roll -Tm SMRF ESMRF
Algorithm
PDR Power Consumption Average Delay
Hình 4.16 Các đại lượng quan sát trong random topology
 Tỉ lệ nhận gói (PDR):

Tỉ lệ nhận gói của ESMRF trong mô phỏng đạt được hiệu quả cao nhất. Trong
khi đó, do chỉ có node 7,8 là node con của source node có id là 10 là nhận gói trong
SMRF, nên PDR trung bình toàn hệ thống của SMRF đạt dưới 10%.
 Độ trễ:
Tương tự như với các topology được mô phỏng trước, ở random topology, độ
trễ của ESMRF và SMRF nhỏ hơn rất nhiều so với TM ( 1.12 giây, 1.92 giây so
với 9.1 giây).
 Năng lượng tiêu thụ:
43
Lượng năng lượng tiêu thụ được mô phỏng đồng nhất về tương quang kết quả
giữa các topology. Với TM do một node phải xử lý nhiều gói tin hơn gây tăng năng
lượng tiêu thụ so với ESMRF và SMRF.
4.4.2 Kết luận và khuyến nghị

Cuối cùng, kết qua thu nhận được từ mô phỏng của cả 3 sơ đồ được tính trung
bình và được tổng hợp vào bảng sau. Lưu ý, đối với SMRF, số liệu được tổng hợp
là giá trị trung bình của forward straight-line topology và random topology.
Bảng 2 Các số liệu trung bình
Giải thuật
SMRF ESMRF TM
Đại lượng
Tỉ lệ nhận gói (%) 40 55.87 53.72
Mức độ tiêu thụ năng

11.59 15.09 30.01
lượng (%)
Độ trễ mạng (s) 1.46 2.94 14.26
Khi xét về hiệu quả hoạt động, ta có thể bỏ qua SMRF vì không cung cấp khả
năng hoạt động toàn vẹn từ dưới lên trên cây DODAG, đồng thời ESMRF cũng đã
bao gồm giải thuật này. Các đại lượng quan sát cho thấy ESMRF có hiệu quả hoạt
động vượt trội so với TM. Trong môi trường sử dụng contikiMac driver, hạn chế
năng lượng sử dụng nhưng làm giảm tỉ lệ PDR, ESMRF và TM có tỉ lệ nhận gói
(PDR) xấp xỉ khi xét cả 3 sơ đồ. Tuy nhiên, mức độ tiêu thụ năng lượng của TM
cao hơn 100% so với ESMRF. Thêm vào đó, độ trễ mạng cũng cao hơn gần 500%
so với ESMRF.
Qua các mô hình mô phỏng và phân tích đánh giá các số liệu, hiệu năng của
giải thuật multicast ảnh hưởng trực tiếp đến tỉ lệ nhận gói, mức độ tiêu thụ năng
lượng và độ trễ mạng của toàn hệ thống. Tùy vào từng trường hợp cụ thể mà nhóm
thực hiện luận văn có những đề xuất hoạt động khác nhau:
44
 Trong điều kiện hoạt động yêu cầu đáp ứng cao về độ tiết kiệm năng lượng và
thời gian phản hồi nhanh (mạng cảm biến không dây năng lượng thấp
6lowPAN), ESMRF là giải thuật phù hợp nhất.
 Trong điều kiện ứng dụng yêu cầu sử dụng các giải thuật định tuyến khác, giải
thuật MPL/TM là lựa chọn tối ưu vì nó hoạt động độc lập.
 Trong điều kiện hoạt động yêu cầu điều khiển và phản hổi chính xác của hệ
thống. Lúc này thay vì sử dụng contiki MAC driver, nhóm để xuất sử dụng null
RDC driver. Null RDC driver sẽ luôn giữ node ở chế độ radio ON, qua đó tỉ lệ
nhận gói (PDR) của cả 3 giải thuật đều đạt tiệm cận 100%, độ trễ mạng không
đổi. Đổi lại, mức độ tiêu thụ năng lượng cũng đồng thời là 100% cho toàn bộ
các giải thuật và node. Trong điều kiện này có thể sử dụng cả 2 giải thuật là
ESMRF và TM. Lúc này, chỉ còn đại lượng độ trễ mạng là cần phải xem xét
khi đưa ra lựa chọn.
45
Chương 5: Thiết kế hệ thống
CHƯƠNG 5 THIẾT KẾ HỆ THỐNG GIÁM SÁT VÀ ĐIỀU KHIỂN

Từ kết quả đạt được thông qua so sánh khả năng hoạt động của các giải thuật
multicast trong môi trường mô phỏng, việc thực hiện một hệ thống vận hành được
trên phần cứng và có ứng dụng cụ thể là cần thiết để kiểm tra tính khả thi của giải
thuật multicast trong thực tế.
Ở chương 5, Thiết kế hệ thống, nhóm sẽ trình bày mô hình hệ thống được
hướng đến thông qua việc thiết kế phần cứng, firmware và phần mềm.
5.1 Tổng quan

5.1.1 Yêu cầu và mục tiêu
Yêu cầu của đầu ra là lựa chọn sử dụng một cách hiệu quả 1 trong 3 giải thuật
SMRF, ESMRF và TM để xây dựng một hệ thống giảm sát và điều khiển thông
minh sử dụng giao thức multicast 6LoWPAN/IPV6.
Hệ thống đầu tiên phải đáp ứng được việc sử dụng giải thuật multicast cho
mạng cảm biến năng lượng thấp trong điều khiển, có nghĩa là từ Root node có thể
lựa chọn, ra lệnh cho sink node thuộc các nhóm multicast khác nhau để điều khiển
actuator. Để đám ứng được yêu cầu giám sát, các sink node cần phải có khả năng
gửi các gói tin chứa thông tin được thu thập của bản thân về cho root node. Ngoài
ra, một giải thuật acknowledgement (ACK) cần phải được bổ sung khi gói tin được
truyền đi để hạn chế tối đa ảnh hưởng của mất gói. Tất cả các tác vụ đều phải được
thực hiện trong môi trường mạng 6LoWPAN/IPV6. Toàn bộ hệ thống được giám
sát và điểu khiển thông qua một ứng dụng trực quan, dễ sử dụng.
Mục tiêu của thiết kế và hiện thực hệ thống nhằm:
- Kiểm tra khả năng hoạt động và triển khai vào thực tế của giải thuật multicast.
- Thực hiện áp dụng thực tế với các tính năng khả dụng cho hệ thống.
- Xem xét ảnh hướng của các yếu tố bên ngoài như nhiễu, môi trường nhiều loại
tín hiệu và khoảng cách truyền.
Với các yêu cầu và mục tiêu được để ra, nhóm đề xuất ứng dụng:
Hệ thống điều khiển đèn và giám sát nhiệt độ dùng trong nông nghi ệp.
46
5.1.2 Sơ đồ tổng quan của hệ thống
Hình 5.1 Sơ đồ khối tổng quát của hệ thống
Hình 4.1 mô tả sơ đồi khối tổng quát của hệ thống được thực hiện trong đề tài
luận văn. Hệ thống bao gồm 2 phần. Phần bên trong bao gồm các khối sink
node/actuator kết nối với root node bằng mạng 6LoWPAN/IPV6. Phần bên ngoài
là một ứng dụng trên nền tảng android dùng để điểu khiển các thiết bị bên trong
thông qua mạng internet tới root node. Các thiết bị đo và thiết bị điều khiển được
giám sát và điểu khiển bởi root node. Người dùng sử dụng ứng dụng android trên
thiết bị (điện thoại) để gửi các lệnh điểu khiển tương ứng tới root node như lựa
chọn nhóm multicast, kích hoạt actuator, thu thập dữ liệu... thông qua internet. Khi
root node nhận được lệnh từ ứng dụng, nó sẽ gửi các gói tin multicast chứa các lệnh
tương ứng tới các sink node và chờ ACK. Khi một sink node nhận được gói tin
đúng với nhóm multicast của nó, gói tin sẽ được xử lí và lện được thực thi. Ngược
lại, sink node sẽ truyền tiếp gói tin đi trong mạng mà không xử lý. Khi một gói tin
được xử lý tại sink node, sink node đó sẽ tiến hành gởi gói ACK về root. Nếu root
47
không nhận đủ số lượng gói ACK, quá trình gửi gói multicast sẽ được lặp lại tối đa
3 lần cho tới khi nhận đủ số gói ACK.
5.2 Thiết kế phần cứng

5.2.1 Sơ đồ khối tổng quan của phần cứng
Sơ đồ khối tổng quát của phần cứng nhìn chung có thể chia làm 2 khối chính
là : Raspberry + 6LoWPAN/IPV6 Root và 6LoWPAN/IPV6 sink + relay + thiết bị
điện, 2 khổi giao tiếp với nhau bằng giao thức 6LoWPAN/IPV6.
Hình 5.2 Sơ đồ khối tổng quát phần cứng
 Khối thứ nhất: Raspberry và 6LoWPAN/Ipv6 root node

Ở khối này, Raspberry được kết nối với Root node (SoC cc2538dk) thông qua
đường serial UART.
Raspberry kết nối với mạng WLAN trong nhà với chuẩn wifi để giao tiếp với
các thiết bị người dùng như điện thoại, laptop... nằm nhận lệnh điều khiển và truy
xuất dữ liệu nhiệt độ. Tiếp theo, raspberry đóng vài trò gateway của hệ thống, chịu
trách nhiệm trung gian nhận các lệnh được gửi tới từ ứng dụng, sau đó gửi lệnh tới
Root node thông qua Serial UART.
6LoWPAN/Ipv6 root node đóng vai trò xử lý lệnh, thực thi các tác vụ tương
ứng và chạy các giao thức mạng 6LoWPAN giao tiếp với các sink node.
48
 Khối thứ 2: 6LoWPAN/Ipv6 sink node + relay

Sink node (SoC cc2538dk), có bao gồm cảm biến nhiệt độ tích hợp sẵn, được
kết nối với Relay. Các sink node vừa có vai trò là bộ thu phát 6LoWPAN, repeater,
vừa có khả năng điều khiển các ngoại vi. Trong thiết kế của luận văn này, các sink
node sẽ giao tiếp với relay qua các port GPIO nhằm điều khiển thiết bị điện 220v
(đèn sưởi...).
5.2.2 Chi tiết phần cứng

a. Raspberry pi 3B+
Hình 5.3 Raspberry Pi 3B+
 Thông số kỹ thuật:
- CPU: Raspberry pi 3B sử dụng vi xử lý BCM2837B0 quad-core A53
(ARMv8) 64-bit @1.4GHz. đây là loại SoC, bao gồm các tích hợp: CPU
ARM Cortex-v8 4 nhân, 1 GB LPDDR2 RAM, Broadcom VideoCore-IV.
- Khe cắm thể micro SD: Raspberry không hỗ trợ ổ cứng, thay vào đó là thẻ
nhớ SD. Tất các dữ liệu sẽ được lưu trữ trên thẻ nhớ này. Cần dùng ít nhất
là thẻ 4GB class 4 (4MB/s) cho Raspberry Pi ( khuyên dùng 8GB class 10).
- 4 cổng USB 2.0, cổng Ethernet RJ45, HDMI
49
- Nguồn: cổng cấp nguồn micro USB. Sử dụng điện áp 5v (bắt buộc) và dòng
lớn hơn 1A. Lưu ý, nếu cấp nguồn lớn hơn 5v có khả năng làm cháy board
mạch.
- GPIO (General Purpose Input and Output): tương tự như các vi điều khiển
khác, các chân GPIO của raspberry được sử dụng để xuất tín hiệu tới các
thiết bị ngoại vi như led, actuator... và đọc tín hiệu từ cảm biến, nút bấm...
Một số chân được tích hợp các chuẩn truyền dữ liệu UART,I2C và SPI.
Raspberry bao gồm 40 chân GPIO.
 Mục đích sử dụng:
Trong phạm vi thiết kế của luận văn, raspberry pi 3B+ được sử dụng như một
máy tính nhúng có chức năng giao tiếp trung gian giữa root node và MQTT server.
Khi nhận được một lệnh từ ứng dụng, raspberry sẽ truyền chuỗi ứng với lệnh đó
tới root node thông qua kết nối Serial UART.
b. Module Contiki 6LoWPAN CC2538dk
CC2538Dk là module Contiki 6LoWPAN được sản xuất bởi hãng Texas
Instruments. Công nghệ Contiki 6LoWPAN được xây dựng dựa trên chuẩn IEEE
802.15.4. Nhờ khả năng truyền không dây khoảng các xa, ổn định, tiêu thụ năng
lượng cực thấp, công nghệ Contikiki 6LoWPAN trở nên thích hợp cho các ứng
dụng yêu cầu tiết kiệm năng lượng (nhà thông minh ...). CC2538dk được sử dụng
phổ biến trong các ứng dụng IoT.
Hình 5.4 Module Contiki 6LoWPAN CC2538dk
50
 Thông số kỹ thuật:
Bảng 3 Thông số kỹ thuật module CC2538dk
Chip ARM Cortex-M3® với tính năng prefech.

Tốc độ clock lên đến 32-MHz.
Flash nội 512KB.
Vi điều khiển
RAM 32 KB .
Hỗ trợ update firmware từ xa và debug thông qua JTAG và
cJTAG.
Bộ thu nhận RF hoạt động ở tần số 2.4-GHZ theo chuẩn
802.15.4
RF
Độ nhạy máy thu -97 dBm
Công suất phát tối đa 7 dBm.
Active-Mode RX (CPU Idle) : 20 mA.
Active-Mode TX (CPU Idle – 0 dBm) : 24 mA.
Power mode 1 (chế độ ngủ 4-µs, duy trì 32-KB RAM, full
thanh ghi): 0.6 mA.
Chế độ hoạt
động Power mode 2 (chế độ ngủ định kì, duy trì 16-KB RAM, hiệu
chính thanh ghi): 1.3 µA.
Power mode 3 (ngắt ngoài, duy trì 16-KB RAM, hiệu chỉnh
thanh ghi): 0.4 µA.
Dải điện áp hoạt động: 2V – 3.6V.
µDMA
4 x Timer dùng chung (32-bit hoặt 2 x 16-bit).
32-bit 32 kHz sleep Timer
12-bit ADC với 8 kênh và độ chia có thể điều chỉnh
Ngoại vi
Cảm biển nguồn và nhiệt độ on chip
2 x SPI, 2 x UART, I2C
32 chẩn GPIO ( 28 x 4 mA, 4 x 20 mA).
Watchdog timer
51
Hiện nay SoC CC2538 DK đang được cộng đồng hỗ trợ rất tốt, nó đang được
cộng đồng tích cực phát triển bởi cộng đồng developer trên toàn thế giới. Contiki
OS cũng đã phát triển sẵn các firrmware ví dụ dành riêng cho CC2538dk.
ContikiMAC và nullRDC hoạt động tốt trên CC2538dk. Lưu ý rằng không phải tất
cả các nền tảng đều hỗ trợ điều này.
Ngoài ra còn có tính năng Over the air update[20]. Đây là khả năng khá quan
trong khi làm việc với hệ thống chứa vài chục đến vài trăm node trong mạng,
firmware cần cập nhật và các node không cần phải kết nối trức tiếp vào PC để thực
hiện tải firrmware tuần tự.
Trong luận văn này, nhóm thực hiện sử dụng module chuyển đổi USB-UART
TTL CP2012 để nạp firmware cho CC2538dk.
 Mục đích sử dụng:

Module CC2538dk là module Contiki 6LoWPAN/Ipv6 chính của luận văn,
được sử dụng để thực hiện root node và các sink node. Đối với root node,
CC2538dk tạo cây DODAG, giao tiếp với các sink node, nhận lệnh từ raspberry và
truyền lệnh tới các sink node. Đối với sink node, module tham gia cây DODAG và
nhóm multicast, thực hiện mệnh lệnh nhận được đồng thời gửi phản hồi về cho root
node.
c. Module chuyển đổi USB-UART TTL CP2102
Hình 5.5 Module TTL CP2102 và sơ đồ nối chân
52
Module chuyển đổi USB-UART TTL CP2102 sử dụng chip CP2102 của
SILICON LABS chuyên chuyển đổi USB sang UART và ngược lại. Module hỗ trợ
được hầu hết các hệ điều hành hiện có trên thị trường. Chức năng chính của module
là hỗ trợ việc nạp chương trình cho vi điều khiển bằng việc kết nối các chân nguồn,
TX, RX.
 Mục đích sử dụng

Module CP2102 được sử dụng như mạch nạp (serial bootloader backdoor),
debug cho CC2538 trong quá trình làm việc, thiết kế phần mềm và nạp firmware
cho root node và các sink node.
d. Module Relay 5V với Opto cách ly
Hình 5.6 Module 1 relay 5V với opto cách ly
Module 1 Relay với opto cách ly nhỏ gọn, có opto và transistor cách ly giúp
cho việc sử dụng trở nên an toàn với board mạch chính, mạch được sử dụng để
đóng ngắt nguồn điện công suất cao AC hoặc DC, có thể chọn đóng khi kích
mức cao hoặc mức thấp bằng Jumper.
Tiếp điểm đóng ngắt gồm 3 tiếp điểm NC (thường đóng), NO(thường mở) và
COM(chân chung) được cách ly hoàn toàn với board mạch chính, ở trạng thái bình
thường chưa kích NC sẽ nối với COM, khi có trạng thái kích COM sẽ chuyển sang
nối với NO và mất kết nối với NC.
 Thông số kỹ thuật
53
Bảng 4 Thông số kỹ thuật module Relay
Nguồn cấp 5 VDC

Dòng tiêu thụ 80 mA
Điện thế đóng

AC 250V ~ 10A hoặc DC 30V ~ 10A
ngắt tối đa
Cách ly Photo Triac
Mức kích Có thể chọn mức kích 0 hoặc 1 qua jumper

Module relay được sử dụng để đóng ngắt thiết bị 220V. Được điểu khiển bằng
dòng điện đầu vào tích cực mức cao bởi sink node cc2538dk qua kết nối GPIO.
e. Module nguồn AC-DC HLK-PM01 5VDC 3W
Hình 5.7 Module nguồn AC-DC HLK-PM01
Module nguồn AC-DC Hi-Link HLK-PM01 5VDC 3W có thiết kế nhỏ gọn

với vỏ bọc nhựa an toàn, chuyên nghiệp, được sử dụng để chuyển nguồn xoay chiều
AC sang 5VDC công suất tối đa 3W cấp cho thiết bị, module được sản xuất bởi
hãng Hi-Link chuyên về các module nguồn được sử dụng trong công nghiệp với
độ bền, chống nhiễu tốt và độ an toàn cao.
 Thông số kỹ thuật
Bảng 5 Bảng thông số kỹ thuật module nguồn
Điện áp vào 100V ~ 240 VAC / 50~60 Hz
54
Điện áo ngõ ra 5 VDC

Dòng ra lớn nhất 600 mA
Công suất trung bình 3W
Độ gợn điện áp và nhiễu thấp.
Đặc tính kỹ thuật Tích hợp bảo vệ quá tải và ngắn mạch.
Tiêu thụ điên năng thấp, no-load loss < -0.1W.

Module nguồn được sử dụng để cấp nguồn cho các sink node và relay trực
tiếp từ nguồn 220V của thiết bị điện, không cần thiết phải sử dụng nguồn ngoài
như pin....
5.2.3 Thiết kế khối sink node – relay – nguồn

Một khối sink node – relay – nguồn được thiết kế đi dây như hình. Thiết bị
điện điều khiển được nhóm sử dụng là đèn sưởi 220 VAC. Sink node và relay sử
dụng chung nguồn 5 VDC được cấp từ module chuyển đổi AC-DC. Đồng thời,
Sink node điều khiển kích mức cao relay bằng chân GPIO PA2.
Hình 5.8 Sơ đồ nối mạch khối sink node-relay-nguồn
55
5.3 Thiết kế firmware
Trong phần mô phỏng, các firmware được chạy là firmware chuẩn được tạo
sẵn trong ví dụ của Contiki OS. Tuy nhiên trong phần này, firmware tại cả 2 loại
node cần phải được thiết kế lại và bổ sung các chức năng nhằm phục vụ mục đích,
yêu cầu của ứng dung.
Ở phần thiết kế firmware, nhóm đề xuất 1 framework chung cho ứng dụng,
bao gồm qui định tất cả các lớp trong mạng 6LoWPAN. Ngoài ra nhóm phải cấu
hình và viết driver giao tiếp với các ngoại vi (relay và raspberry).
5.3.1 Đề xuất framwork

Nhằm đáp ứng được các yêu cầu và mục tiêu đầu ra của hệ thống cũng như
hướng đến việc sử dụng một mạng lưới có khả năng mở rộng linh hoạt, một
framework thống nhất được đề xuất như hình sau (Hình 5.9).
Hình 5.9 Protocol stack được sử dụng trong framework
- Lớp Physhical
Để tránh va chạm và can nhiễu bởi các nguồn thiết bị không dây khác, đặc
biệt là lượng phủ mạng wifi dày đặt trong thực tế, nhóm cấu hình radio channel
ở kênh 26.
- Lớp Link
56
Lớp link bao gồm 3 tầng: Framer, RDC và MAC. Nhóm đề xuất cấu hình như
sau:
+ Ở tầng MAC, để có thể tránh xung đột khi truyền gói tin, hạn chế mất gói
trong mạng, ta sử dụng CSMA/CA. Tuy nhiên, thời gian trễ khi truyền gói tin
sẽ bị ảnh hưởng tiêu cực.
+ Ở tầng RDC, cấu hình được sử dụng là Null DRC để giảm thiểu tối đã khả
năng mất gói, đảm bảo tính ổn định và khả năng nhận gói khi hệ thống được
mở rộng gia tăng số node. Việc sử dụng năng lượng tối ưu không phải là yếu
tố quan trọng vì trong phần thiết kế phần cứng, sink node sẽ sử dụng nguồn
được chuyển đổi từ 220 VAC của thiết bị điện, trong khi đó root node sử dụng
nguồn trực tiếp từ raspberry.
+ Ở tần framer, nhóm gói khung bằng Contiki MAC framer.
- Lớp Adaptive Security
Sử dụng cấu hình mặc định bao gồm các phương pháp AKES, CCM*-MIC.
- Lớp Network
Với giao thức 6LoWPAN ở tầng Network và RPL giúp thực hiện mạng
6LoWPAN/Ipv6 đồng thời tạo cây DODAG cho hệ thống.
- Lớp Transport
UDP được sử dụng tại lớp transport. Vì UDP cung cấp khả năng tương đồng
với TCP, điểm khác biệt duy nhất là bên gửi sẽ không chờ xác nhận bên nhận đã
nhận được gói tin mà sẽ tiếp tục gửi gói tiếp theo. Đồng thời, UDP hỗ trợ các liên
kết 1-1, 1-n (Multicast) và là đặt trưng chính của giao thức UDP. Hơn nữa, UDP
chỉ có 8 byte header cho mỗi đoạn (20 byte với TCP). Chính những điều trên cho
thấy UDP hoàn toàn phù hợp với hệ thống mạng cảm biến không dây
- Lớp application
Giữ các cài đặt mặc định của contiki OS.
Tương tự như ở phần mô phỏng, payload length sẽ được thiết lập tối đa là 4
bytes. Với nội dung payload dành cho điều khiển thu thập dữ liệu và ACK được
quy định như sau:
57
Bảng 6 Quy định nội dung gói tin gửi đi
STT Nguồn Đích Mục đích Nội dung payload

1 0xX, với X là mã lệnh
Root node Sink node Điều khiển sink node
định sẵn.
2 0xY, với Y là id của sink
Sink node Root node Xác nhận Ack
node gửi gói.
3 0xZ, Z là giá trị nhiệt độ
từ cảm biến dời trái 1 bit
Sink node Root node Gửi dữ liệu cảm biến
sau đó thêm id của sink
node gửi gói theo sau.
5.3.2 Cấu hình project-conf.h

Trước khi thiết kế và firmware cho root node và sink node, việc đầu tiên cần
thực hiện là cấu hình cốt lõi cho toàn bộ hệ thống tại file project-conf.h
File project-conf.h là file header chứa các định nghĩa chung cho firmware của cả
root và sink node. Các định nghĩa quan trọng cần cấu hình như sau:
#define UIP_MCAST_CONF_ENGINE 3
#define NETSTACK_CONF_RDC nulldrc_driver /* RDC driver */
#define UIP_MCAST6_ROUTE_CONF_ROUTES 5
#define RPL_CONF_MOP 3
#define NBR_TABLE_CONF_MAX_NEIGHTBOORS 10
#define UIP_CONF_MAX_ROUTES 10
#define group_odd_nodes 2 /*suffix ABCD*/
#define group_even_node 1 /*suffix CDEF*/
- Giải thuật multicast được sử dụng trong hệ thống thực tế là ESMRF

(UIP_MCAST_CONF_ENGINE 3). Giải thuật ESMRF có tính khả thi cao nhất
khi cho khả năng hoạt động hoàn thiện trong các topology, vì thế trong firmware,
nhóm sẽ sử dụng ESMRF làm giải thuật multicast để xây dựng hệ thống ứng
dụng trong thực tế.
58
- RDC driver được sử dụng là Null RDC. Khác với mô phỏng, trong thiết kế phần
cứng, do các module CC2538dk được thiết kế sử dụng nguồn ổn định ( trực tiếp
từ raspberry với root node, chuyển đổi từ nguồn 220V với sink node) nên yếu tố
tối ưu năng lượng sử dụng có ưu tiên thấp hơn khả năng truyền và nhận gói.
- UIP_MCAST6_ROUTE_CONF_ROUTES 5. Định nghĩa này cho phép thay đổi
số lượng nhóm multicast tối đa, được lưu dưới dạng route tại routing table của
từng node.
- NBR_TABLE_CONF_MAX_NEIGHTBOOR, UIP_CONF_MAX_ROUTES:
thay đổi lượng node liền kề và số route tối đa mà một node có thể lưu trong bộ
nhớ. Tùy thuộc vào nhu cầu mà ta có thể tăng giảm cho phù hợp, tiết kiệm bộ
nhớ cho module.
- RPL_CONF_MOP 3 để thiết lập chế độ hoạt động storing with multicast. Vì ở
thiết kế, nhóm sử dụng giải thuật multicast ESMRF yêu cầu lưu trữ thông tin
cây DODAG, đồng thời các giải thuật multicast chỉ hoạt động với mode này.
Thêm vào đó, tại file rpl.c (~/contiki/core/net/rpl/rpl.c), RPL được thiết lập hoạt
động ở mode RPL_MODE_MESH, với mode này, mỗi node trong cây DODAG
chuyển gói tin cho các node và có thể được tương tác bởi các node khác.
- Group_odd_nodes và group_even_nodes là 2 cài đặt dùng để khai báo số lượng
node mỗi nhóm multicast. Với nhóm even có phần đuôi địa chỉ multicast là
0xABCD, nhóm odd có phần đuôi là CDEF.
Tóm lại, trong hệ thống đầu ra của luận văn, giải thuật multicast được sử
dụng là ESMRF, số nhóm multicast trong hệ thống là 3 ( 1 dành cho root, 2
dành cho các sink).
5.3.3 Firmware cho Root node

Nhìn chung, firmware được lập trình cho root node được mô tả bởi lưu đồ
chính và các lưu đồ con sau:
59
Hình 5.10(A)Chương trình chính; (B) chương trình cài đặt hệ thống tại root node
Hình 5.11 Chương trình con xử lý lệnh tới root node
60
Hình 5.12 Chương trình con xử lý ACK
 Quá trình hoạt động

Đầu tiên khi khởi động, Root node sẽ bắt đầu các quá trình cài đặt. Module
CC2538dk có 2 UART, UART-0 và UART-1. UART-0 được sử dụng cho việc
debug và nạp firmware và UART-1 có thể tùy biến. Để firmware đơn giản hơn,
nhóm sẽ lợi dụng giao tiếp UART-0 giữa Raspberry và cc2538dk để làm kênh giao
tiếp giữa chúng. NETSTACK_MAC của root được tắt nhằm đảm bảo root node
luôn hoạt động ở trạng thái radio on. Việc đảm bảo root node luôn hoạt động nhằm
giữ thông tin cây DODAG, liên lạc với các sink node, đồng thời luôn sẵn sàng nhận
và xử lý lệnh từ người dùng.
Tiếp theo, root node sẽ cài đặt các đặt các địa chỉ ipv6 global, local cho bản
thân (set_own_address()), tạo và lưu địa chi các nhóm multicast cho sink node
(prepare_mcast()). Root node được tham gia vào nhóm multicast đặc biệt chỉ bao
61
gồm chính nó (join_mcast_group()). Nhóm multicast này nhằm mục đích lợi dụng
khả năng forward gói từ dưới lên trên mà không qua xử lý của giải thuật ESMRF
để sử dụng cho giải thuật ACK. Khi các sink node nhận được gói tin từ root node,
chúng sẽ gửi gói tin tới địa chỉ multicast này, do không có sink node nào tham gia
nhóm nên chúng sẽ bỏ qua và forward thẳng tới root để đánh dấu ACK. Trong quá
trình thiết lập địa chỉ, root cũng tự động trở thành cây DODAG có ID là địa chỉ
global. Tất cả các địa chỉ global, local và multicast được thiết lập theo mặc định
của Contiki, riêng các địa chỉ multicast có 4 bit suffix được thay đổi để phân biệt
các group multicast.
Sau quá trình cài đặt hệ thống, root node tiến vào trạng thái chờ event. Khi có
event tới từ raspberry thông qua UART-0, root node chuyển dữ liệu về dạng integer
và lưu vào biến rxdata. Quá trình xử lý lệnh được mô tả trong chương trình con
Phân Tích Lệnh, tùy theo các mã được quy định sẵn mà các tác vụ khác nhau được
thực hiện. Khi mã được gửi tới là 1,2,3, root node sẽ chuyển mục tiêu điều khiển
tương ứng là nhóm multicast Even, Odd và cả 2 nhóm. Khi mã được gửi tới là 4,5
hoặc 6, root node sẽ gửi gói multicast có phần message tương ứng để điều khiển
sink node. Với mã 4/5, các message chứa gói tin dùng để chuyển đổi trạng thái
bật/tắt của Relay tại sink node và root node chờ một khoảng etimer để xác nhận
ACK. Nếu lệnh là mã 6, root sẽ gửi gói tin có message yêu cầu các sink node phản
hồi giá trị cảm biến nhiệt độ on chip và không có quá trình chờ xử lý ACK, các giá
trị cảm biến này được lưu vào một mảng để gửi tới raspberry. Trong trường hợp
gói yêu cầu phản hồi giá trị cảm biến bị lỗi, root node vẫn gửi mảng lưu với các giá
trị của sink node bị lỗi giữ nguyên của lần thu thập thành công trước, chỉ cập nhật
giá trị tại các vị trí không bị mất gói.
 Chương trình con xử lý ACK
Như đã nêu, chỉ khi mã lệnh được gửi tới là 4, 5 thì root node mới thực hiện
xử lý ACK. Khi bắt đầu một quá trình xử lý ACK, tùy theo đối tượng đang điều
khiển là nhóm multicast nào mà etimer và một mảng chứa ID của các sink node
mục tiêu được khởi tạo. Trong khi etimer chưa kết thúc, root node sẽ chờ
62
tcpip_event từ các sink node. Các gói tin được sink node gửi tới địa chỉ multicast
riêng biệt của root chứa message là id của chính nó. Root node nhận được gói tin
ACK, sẽ trích sink node id từ message, dò giá trị id đó trong mảng ACK và loại bỏ
ID đó.
Khi etimer kết thúc, Root node sẽ kiểm tra lại mảng ACK. Nếu mảng ACK
khác rỗng tại bất kì vị trí chứa id nào và biến đếm số lần lỗi liên tục nhỏ hơn 4, root
node sẽ gửi thông báo lỗi có bao gồm id của các sink node bị lỗi về raspberry đồng
thời gửi gói tin multicast lại lần nữa. Lúc này toàn bộ quá trình gửi multicast và xử
lý ACK được lặp lại. Ngược lại nếu mảng ACK hoàn toàn rỗng, việc gửi gói tin
thành công và quá trình kết thúc.
5.3.4 Firmware cho sink node

Firmware sink node được sử dụng chung cho tất cả các sink node kể cả khi
chúng thuộc các nhóm multicast khác nhau.
Điểm khác biệt duy nhất trong firmware của các sink node khác nhóm
multicast là id của sink node và biến lưu địa chỉ nhóm multicast của chính nó. Mỗi
sink node khi khởi tạo sẽ được cho sẵn một id duy nhất, id này cũng sẽ được cập
nhật vào mảng kiểm tra ACK và mảng lưu dữ liệu nhiệt độ của root node. Như đã
thống nhất ở các phần trước, hệ thống của luận văn bao gồm 2 nhóm multicast được
sử dụng cho các sink node:
 Nhóm Even: Gồm các sink node được đánh id là số chẵn, có phần đuôi địa
chỉ multicast là 0xABCD
 Nhóm Odd: gốm các sink node được đánh id là số lẽ, có phần đuôi địa chỉ
multicast là 0xCDEF
63
Hình 5.13 (A) Chương trình chính; (B) chương trình con cài đặt sink node
 Quá trình hoạt động

Tương tự như với root node, sink node yêu cầu một quá trình cài đặt hệ thống
trước khi tiến vào trạng thái chờ gói tin, sự kiện. Chương trình con 4.13(B) mô tả
quá trình cài đặt của sink node khi nó được khởi động. Đầu tiên là thiết lập chế độ
64
cho chân GPIO PA2 ở mode output nhằm điều khiển relay. Nếu đã có cây DODAG
tồn tại, sink node sẽ tự động tham gia cây theo quá trình đã nêu ở phần *. Tiếp theo,
một sink node sẽ tham gia nhóm multicast được cài đặt sẵn cho chính nó. Nếu việc
tham gia nhóm multicast gặp vấn đề, sink node sẽ kết thúc quá trình hoạt động. Và
nhằm mục đích gửi gói tin ACK về cho root node khi một gói tin multicast được
xử lý, sink node sẽ khởi tạo và lưu địa chỉ multicast riêng biệt của root node.
Sau khi hoàn thành việc cài đặt hệ thống, sink node bắt đầu một chu kỳ hoạt
động. Khi root node gửi gói tin multicast, các sink node nhận và xử lý gói tin trong
thời gian khá sát nhau. Do đó, nếu các sink node đồng loại gửi ACK hoặc gói tin
dữ liệu về cho root node, sẽ tồn tại khả năng root node đang xử lý gói khác mà bỏ
qua gói vừa tới. Để giải quyết vấn đề đó, khi bắt đầu mỗi chu kỳ mới, sink node sẽ
tạo ngẫu nhiên một số để quyết định khoản delay gửi gói tin về cho root node.
Khoảng delay cho mỗi sink node là từ 0 tới 1 giây tương ứng với số ngẫu nhiên r
từ 0 tới 10. Lưu ý rằng, khoảng delay này cho mỗi sink node là riêng biệt, không
cộng dồn lẫn nhau, do đó, bất kể số node trong mạng là bao nhiêu, thời gian tối đa
để toàn hệ thống gửi gói về cho root là 1 giây sau khi nhận được gói tin multicast.
Lúc này root node chờ một khoản thời gian tổng cộng là 1 giây thời gian delay của
mỗi sink node, thời gian truyền gói từ root tới sink xa nhất và ngược lại.
Khi nhận được gói tin có destination là địa chỉ multicast mà nó tham gia, sink
node sẽ ghi nhận gói tin dưới dạng tcpip_event và tiến hành phân tích mã lệnh từ
gói tin. Tương tự như ở root node và raspberry pi, các mã lệnh điều khiển được
định sẵn. Với mã 1 (2), sink node sẽ thay đổi trạng thái relay tương ứng bật (tắt)
thiết bị điện, sau đó gửi gói ACK chứa id của nó về cho root. Với mã 3, sink node
đọc giá trị cảm biến nhiệt độ on chip và tính toán gói tin dữ liều cần truyền theo
nội dung đã thống nhất ở phần 5.3.1. Cả hai quá trình với các mã đều phải chờ một
khoảng delay đã được ngẫu nhiên trước đó rồi mới tiến hành gửi gói tin về cho root
node.
65
5.4 Thiết kế phần mềm
Thiết kế phần mềm gồm các phần chính như trong hình 4.14 dưới đây:
Sơ đồ tổng quát thiết kế phần mềm
 Đảm bảo kết nối đến các client

Server  Chuyển tiếp gói tin từ smartphone đến
gateway
Raspberry -
Smart phone
Gateway
 Truyền gói tin từ Server  Điều khiển đèn

đến Root và ngược lại  Theo dõi nhiệt độ các nút
 Gửi gói tin đến server
Hình 5.14 Sơ đồ thiết kế phần mềm
Để thuận tiện trong quá trình thiết kế, nhóm sử dụng nhiều nền tảng có sẵn,
đã được phát triển và sử dụng rộng rãi hiện nay. Sau đây nhóm sẽ giới thiệu một số
nền tảng sử dụng trong luận văn này.
- Trong phần thiết kế gateway, nhóm thiết kế trên Hệ điều hành Raspbian của
Raspberry. Đây là hệ điều hành cơ bản, phổ biến và do chính Raspberry Pi
Foundation cung cấp. Dù có dung lượng nhỏ (khoảng 4GB sau khi giải nén),
nhưng hệ điều hành này cung cấp đầy đủ các tính năng như một máy tính thông
thường, hoạt động khá ổn định và được tích hợp sẵn Python, ngôn ngữ mà nhóm
sử dụng để lập trình phần giao tiếp giữa mạng 6LoWPAN và Server.
- Trong phần thiết kế Server, nhóm sử dụng mô hình kiến trúc mức cao của
MQTT (Message Queue Telemetry Transport), đây là một giao thức truyền thông
điệp (message) theo mô hình publish/subscribe, sử dụng băng thông thấp, độ tin
cậy cao và có khả năng hoạt động trong điều kiện đường truyền không ổn định.
66
Broker
message message
Clients
Publisher Subscriber
Hình 5.15 Kiến trúc mức cao MQTT
Kiến trúc của MQTT gồm 2 phần chính là Broker và Clients. Broker có
nhiệm vụ gửi tin nhắn (message) đến các Client dựa vào chủ để (topic) của thông
điệp đó. Broker được coi như trung tâm xử lý các message gửi từ các client. Client
được chia thành 2 nhóm là publisher và subscriber. Publisher đảm nhiệm chức năng
gửi message lên broker, subsciber đảm nhiệm chức năng nhận message từ broker.
Trong luận văn này, Raspberry và Smartphone đóng vai trò là Client.
Một số khái niệm trong giao thức MQTT:
- Message : trong giao thức MQTT, message còn được gọi là data hay payload,
có định dạng là plain-text.
- Topic : giống như là một kênh đăng kí cho các client, khi message được
publish vào một topic thì tất cả những subscriber của topic đó sẽ nhận được
message này.
- QoS (Quanlity of Service) : là tính năng đảm bảo sự chắc chắn trong việc gửi
nhận message giữa client và broker.
MQTT hỗ trợ 3 mức QoS:
- QoS – 0: mức thấp nhất, các message sau khi được gửi bởi publisher sẽ không
được kiểm tra xem đã đến broker hay chưa.
67
- QoS – 1: message được đảm bảo đã đến nơi nhận ít nhất một lần (tức là sự
trùng lặp vẫn có thể xảy ra)
- QoS – 2: là mức cao nhất, broker sẽ đảm bảo các message sẽ đến nơi nhận chỉ
1 lần duy nhất.
- Trong thiết kế ứng dụng Smart phone, nhóm lập trình trên hệ điều hành
Android, một hệ điều hành phát triển trên nền Linux của Google dành cho điện
thoại thông minh. Đây là hệ điều hành với nhiều ưu điểm: miễn phí, mã nguồn
mở, dễ sử dụng, hỗ trợ ngôn ngữ lập trình Java - ngôn ngữ lập trình phổ biến và
mạnh mẽ bậc nhất hiện nay.
Như vậy, nhóm đã giới thiệu tổng quan về các phần chính trong thiết kế phần
mềm, cũng như những nền tảng hỗ trợ. Phần tiếp theo, nhóm trình bày chi tiết về
nội dung thiết kế : Server, Gateway và Ứng dụng Android.
5.4.1 Thiết kế Server

Nhóm sử dụng Eclipse Mosquitto để làm server, Mosquitto là một broker mã
nguồn mở tích hợp giao thức MQTT phiên bản 5.0, 3.1.1 và 3.1, là một phần của
dự án IoT của Eclipse Foundation. Mosquitto có kích thước rất nhẹ và tương thích
cho mọi thiết bị, từ máy tính nhúng cấu hình thấp cho đến những chiếc máy trạm
đầy đủ chức năng. Có nhiều platform để khởi tạo và quản lí các Mosquitto server,
nhóm đã chọn CloudMQTT làm platforrm thiết kế server, với ưu điểm có gói miễn
phí, dễ sử dụng, hỗ trợ nhiều ngôn ngữ. Bảng 7 là các thông số của Broker mà
nhóm thiết kế, vì sử dụng gói miễn phí nên sẽ bị hạn chế về băng thông và số client
kết nối vào cùng một lúc.
Bảng 7 Các thông số thiết kế cho CloudMQTT
Gói sử dụng Cat (Miễn phí)
Datacenter Amazon Web Services US-East-1 (Northern Virginia)
URL m16.cloudmqtt.com
Port 12290
68
Băng thông tối đa 10 Kbit/s
Số kết nối tối đa 5
User sknweddk
Password WDBf0aSOTwfY
5.4.2 Thiết kế gateway giữa 6LoWPAN và Internet

Nút Root trong mạng 6LoWPAN được chọn làm gateway để kết nối đến
Broker. Một vấn đề đặt ra, đó là hiện tại Internet tại Việt Nam vẫn chưa tích hợp
IPv6 hoàn toàn cho người dùng, nên sẽ phải dùng IPv4 để đảm bảo tính ổn định.
Ta có thể sử dụng giao thức NAT64 để chuyển địa chỉ IPv6 của Root thành IPv4,
giao thức NAT64 sẽ được cấu hình tại thiết bị định tuyến (Router) nơi đặt Root. Có
một cách khác tiện lợi hơn, không cần phải can thiệp đến thiết bị mạng, đó là sử
dụng một máy tính nhúng, cụ thể ở đây là Raspberry.
Raspberry sẽ đóng vai trò là gateway giữa Root và Internet, ta sẽ không cần
phải quan tâm đến việc chuyển đổi giữa các chuẩn địa chỉ IP nữa, bởi vì trên
Raspberry và CC2538dk đều có cổng Serial Uart nên ta sẽ dùng cổng này để giao
tiếp với nhau, đồng thời kết nối với Broker thông qua card mạng tích hợp sẵn.
Raspberry nhận gói tin từ Broker (qua Ethernet hoặc Wifi) và chuyển tiếp đến Root
thông qua cổng Serial, tương tự cho chiều ngược lại.
 Giải thuật
Hình 5.16 là sơ đồ giải thuật được thiết kế cho Raspberry để đảm nhiệm chức
năng kể trên, giải thuật được viết bằng ngôn ngữ Python.
MQTT được triển khai trong Python qua thư viện paho-mqtt được phát triển
bởi Eclipse, một số thiết lập ban đầu như user, password, địa chỉ Broker sẽ có
dạng như sau:
69
import paho.mqtt.client as mqtt

mqttc = mqtt.Client("client-1")
mqttpac.username_pw_set("sknweddk", "123456789") #(user, password)
mqttc.connect("m16.cloudmqtt.com", 12290, 60)
Về phía Root, ta thiết lập giao tiếp uart bằng các tập lệnh của linux. Đầu tiên
ta phải cấp quyền cho Raspberry được ghi vào cổng serial, cụ thể ở đây là thêm
quyền đọc ghi file “/dev/ttyUSBx” (x có thể là 0,1,2,3 tuỳ thiết bị qui định). Sau
đây là lệnh cần được thực hiện trên terminal của Raspberry:
chmod o+rw /dev/ttusb0

Thư viện pyserial của Python hỗ trợ việc đọc ghi dữ liệu qua cổng serial:
import serial
ser = serial.Serial('/dev/ttyUSB0', 115200, timeout = 0.5)
Vì quá trình gửi dữ liệu lên và nhận dữ liệu xuống từ Broker có thể xảy ra
đồng thời, nên để đảm bảo sự hoạt động ổn định, nhóm sử dụng lập trình đa luồng
(Multithread) trong giải thuật. Cụ thể sẽ có 2 luồng : MQTT Thread - đóng vai trò
nhận và xử lí dữ liệu từ Broker về và chuyển tiếp cho Root, UART Thread - đóng
vai trò gửi dữ liệu từ Root đến Broker.
MQTT Thread: Chương trình sẽ luôn ở trạng thái chờ để nhận tin nhắn từ
cloud gửi đến. Tin nhắn gửi đến mang 2 thông số là topic và nội dung (payload), ta
sử dụng callback function on_message của thư viện paho để thực hiện bước này :
def on_message(client, userdata, msg):
print(msg.topic+" "+str(msg.payload))
command = msg.payload.decode("utf-8")
write_command_uart(command)
Nếu có tin nhắn đến, chương trình sẽ kiểm tra xem tin nhắn có đúng với cú
pháp lệnh đã được thiết đặt sẵn hay không, nếu đúng sẽ tiến hành gửi xuống Root,
nếu không sẽ huỷ bỏ gói tin.
70
Hình 5.16 Sơ đồ giải thuật cho Raspberry
Các lệnh được thiết lập sẵn là:

- “group1” : điều khiển nhóm multicast 1.
- “group2” : điều khiển nhóm multicast 2.
- “all” : điều khiển tất cả các nhóm multicast.
- “on” : lệnh bật đèn.
- “off” : lệnh tắt đèn.
- “temp”: lệnh lấy dữ liệu nhiệt độ của các nút cảm biến.
Để có thể nhận được những tin nhắn trên, client phải đăng kí (subscribe) kênh
(topic) chứa những tin nhắn đó, chẳng hạn tin nhắn “on ” sẽ đến từ topic “led” (theo
thiết lập của nhóm), thì client phải subscribe topic “led” này:
71
mqttc.subscribe("led", 0) # (topic, QoS)
Tin nhắn được gửi đến Root thông qua cổng serial, để đơn giản, ta có thể dùng lệnh
của linux để thực hiện :
import os
os.system( "echo group1 > /dev/ttyUSB0" )
UART Thread: Chương trình sẽ luôn trong trạng thái chờ để nhận tin nhắn
từ Root đến qua cổng Serial, sau đó sẽ xử lí tin nhắn rồi Publish đến Broker theo
những topic nhất định.
Tin nhắn thông qua bước xử lí để có thể Publish vào topic tương ứng, các topic
được thiết lập là:
- “led” : topic nhận dữ liệu điều khiển led

- “group” : topic nhận dữ liệu chọn group multicast
- “ack” : topic nhận tin nhắn feedback từ các node trong group khi gửi
một gói tin từ broker xuống.
- “sensor” : topic nhận giá trị cảm biến nhiệt độ của các nút cảm biến
Việc phân chia ra thành nhiều topic như vậy sẽ dễ quản lí các gói tin được gửi
đến broker, đồng thời cũng phân luồng các gói tin gửi đến, tránh được các trường
hợp các gói tin đến quá nhiều vào một topic khiến việc xử lí bị rối loạn.
Đoạn code mẫu publish một tin nhắn lên broker:
mqttc.publish("group", "group1") # (topic, payload)
5.4.3 Thiết kế giao diện điều khiển qua smartphone (Android)

Các chức năng cần thiết kế:
- Điều khiển đèn.
- Chuyển đổi các nhóm multicast.
- Hiển thị nhiệt độ của các nút cảm biến.
72
Ứng dụng sẽ thiết kế theo mô hình sau :
Mô hình phần mềm
View Layout Data layout
Main Main Chức năng DataManager Class

Layout Activity
MQTT SQLite database

Helper Class
Bắt các sự
kiện Chart Thao tác CRUD
Helper Class vào SQLite
Node Value
Class
Hình 5.17 Mô hình thiết kế ứng dụng Android
Cấu trúc phần mềm gồm 2 phần chính :
- View layout : Phần giao diện để người dùng thao tác trên đó, gồm 2 phần nhỏ
là Main layout và Main Activity. Main layout được viết ở dạng file xml, chức
năng tạo ra giao diện trực quan để người dùng tương tác (các nút bấm, chữ, màu
sắc, vị trí tương đối giữa chúng). Main Activity đảm nhiệm chức năng bắt các
sự kiện khi người dùng tương tác với Main layout, sau đó sẽ xử lí chúng tuỳ theo
ý của người lập trình.
- Data layout: Gồm 2 phần chính: DataManager chịu trách nhiệm xử lí database,
chẳng hạn như các thao tác CRUD vào SQLite database; Các chức năng như kết
nối với MQTT Cloud, xử lí dữ liệu để vẽ đồ thị sẽ được đưa vào trong các helper
class như MQTT Helper Class, Chart Helper Class. Và để quản lí dữ liệu của
các nút cảm biến, nhóm thiết kế một class NodeValue để tiện lưu trữ cũng như
sử dụng.
a. Thiết kế View layout
73
Giao diện chính Main layout được thể hiện trong hình 5.18, gồm:
- Một Text view để ghi lại nội dung gói tin trao đổi giữa ứng dụng và server.
- Các nút điều khiển :
 Group controling : chọn Group multicast, khi bấm vào nút này sẽ xuất hiện
popup hiện ra các mục để chọn.
 Light On : Bật đèn ở các node trong group multicast
 Light Off : Tắt đèn ở các node trong group multicast
 Temperature : Lấy giá trị nhiệt độ của các node để theo dõi
- Đồ thị biểu diễn giá trị nhiệt độ đo được tại các node: sau khi ấn nút
Temperature, ứng dụng gửi lệnh yêu cầu lấy nhiệt độ lên server, dữ liệu từ
server trả về sẽ được thể hiện ở đồ thị này.
Hình 5.18 Giao diện phần mềm: (A) Các nút điều khiển; (B) Popup chọn
Group multicast; (C) Đồ thị theo dõi nhiệt độ các nút
Đối với Main Activity, nhóm thiết kế các chức năng cho các sự kiện khi người
dùng tương tác trên giao diện. Hình 5.19 là sơ đồ giải thuật thiết kế Main Activity
của ứng dụng.
74
Tại thời điểm bắt đầu chạy, ứng dụng sẽ khởi tạo các thiết lập :
- Liên kết với từng thành phần của giao diện (các nút, biểu đồ, text view)
- Liên kết với SQLite database thông qua DataManager
- Khởi tạo biểu đồ thông qua ChartHelper
- Kết nối đến MQTT Cloud, thiết lập các thông số như Client ID, QoS, địa chỉ
server, username, password, port.
Hình 5.19 Sơ đồ giải thuật Main activity
75
b. Thiết kế Data layout

Data layout gồm 2 phần : DataManager và các Class đảm nhiệm các chức
năng riêng biệt.
 DataManager
Android Studio cung cấp gói thư viện SQLiteDatabase và SQLiteOpenHelper
để giúp người dùng khởi tạo database và thực hiện các thao tác với chúng. Dù là
đã có gói thư viện sẵn nhưng chỉ thuận lợi trong việc khởi tạo database, còn khi
thao tác đọc, ghi, xoá, sửa vẫn phải lập trình thêm để có thể duyệt từng hàng từng
cột trong database, dẫn đến đoạn code trở nên dài dòng phức tạp, khó quản lí và
kiểm tra sau này. Để giải quyết vấn đề trên, nhóm viết một class DataManager để
thực hiện các công việc trên, giảm thiểu tối đa các dòng code khi lập trình viên
muốn thao tác với database (mỗi chức năng chỉ cần gọi một hàm duy nhất, không
cần lập trình thêm nhiều). Dưới đây là mô tả khái quát cấu trúc của class
DataManager:
public class DBManager extends SQLiteOpenHelper {
// Create database
public DBManager(@Nullable Context context);
//Create table in database
public void onCreate(SQLiteDatabase db){};
// Write new values to database
public void AddValue(String dataStr){};
// Read database
public ArrayList<NodeValue> GetValuesByNodeID(int nodeId){}
public ArrayList<NodeValue> GetBottomValues(int
numberValues){};
};
 Các Class chức năng khác:

Cũng giống như DataManager Class, các Class chức năng này cũng giúp tối
ưu hoá quá trình thiết kế phần mềm, xây dựng các hàm chức năng riêng biệt dựa
trên gói thư viện có sẵn.
- MqttHelper Class
76
Tương tự như phần trên, MqttHelper là một class sử dụng thư viện paho
eclipse mqtt client để khởi tạo Client và kết nối đến Broker, thực hiện các lệnh gửi
và nhận gói tin từ Broker. Cấu trúc class MqttHelper sẽ có một constructer khởi
tạo Mqtt Client ID, các hàm để đăng kí (subscribe) một topic, huỷ đăng kí
(unsubscribe) một topic, gửi (publish) đến một topic. Các thông số thiết lập về
MQTT Client trong ứng dụng được mô tả ở bảng 6:
Bảng 8 Thông số thiết lập MQTT Client trong ứng dụng
Thông số Giá trị thiết lập

Client ID AndroidClient
Server URL : port tm16.cloudmqtt.com:12290
Phương thức giao vận TCP
QoS QoS-0
Dưới đây là cấu trúc của class MqttHelper:
public class MqttHelper{

public MqttHelper(Context context){};
public void subscribeToTopic(String subscribeTopic) {};
public void publishToTopic(String topic, String payload){};
public void unsubcribeToTopic(String unsubTopic){};
};
- ChartHelper Class
Thư viện MPAndroidChart cung cấp các hàm để xử lí và vẽ nhiều loại đồ thị
khác nhau trên ứng dụng di động. Nhóm khởi tạo một helper class
“BarChartHelper” chứa các lệnh để dựng đồ thị biểu diễn nhiệt độ. Cấu trúc của
class gồm có các hàm định dạng kiểu đồ thị, lấy dataset để vẽ đồ thị. Dưới đây là
cấu trúc của BarChartHelper
public class BarChartHelper {

public BarChartHelper(BarChart chart){};
public void setBarEntries(ArrayList<BarEntry> barEntries) {};
public void setBarDataSet(BarDataSet barDataSet) {};
public void DrawTempChart(){};
public void Refesh(){};}
77
- NodeValue Class
Một gói tin dữ liệu trả về gồm nhiều thông tin như ID của các nút, giá trị nhiệt
độ đo được tại nút tương ứng, và mỗi nút sẽ có một ID group multicast riêng. Nếu
xử lí thuần thì sẽ tốn nhiều biến để lưu giữ thông tin của các nút này, gây khó khăn
trong việc quản lí code và xử lí lỗi. Do vậy, class NodeValue được tạo ra để giải
quyết vấn đề trên. Lúc này, tất cả thông tin của một gói tin gửi về sẽ nằm trong một
biến duy nhất, rất dễ để quản lí và phát triển sau này. Cấu trúc NodeValue class
được mô tả sau đây:
public class NodeValue {

public NodeValue(int id, int group, int temperature){};
public int getId(){}
public void setId(int id){}
public int getGroup(){}
public void setGroup(int group){}
public int getTemperature(){}
public void setTemperature(int temperature){}
}
Như vậy, nhóm đã trình bày xong phần thiết kế phần mềm giao diện người
dùng của ứng dụng điểu khiển và giám sát đèn sử dụng giải thuật Multicast/
6LowPAN.
78
Chương 6: Kết quả thực hiện ứng dụng
CHƯƠNG 6 KẾT QUẢ THỰC HIỆN ỨNG DỤNG

Trong phần này, nhóm trình bày các kết quả đạt được của phần thiết kế ứng
dụng giám sát và điều khiển, bao gồm các kết quả thực hiện phần cứng, firmware
và phần mềm.Thêm vào đó, nhóm thực hiện kiểm thử trong môi trường thực tế để
kiểm tra tính khả thi của hệ thống thông qua tỉ lệ điều khiển thành công.
6.1 Sản phẩm phần cứng
- Khối Sink node cc2538dk – relay – nguồn. Phần cứng của khối bao gồm
CC2538DK điều khiển relay thông qua chân PA2. Relay điều khiển đóng ngắt
đèn sưởi 220v. Relay và CC2538dk được cấp nguồn chuyển trực tiếp từ nguồn
220V xuống 5v thông qua module giảm áp AC-DC.
Hình 6.1 Phần cứng khối sink node
Bảng 9 Thông số kỹ thuật khối sink node
Thiết bị chính CC2538dk – Relay.
Các ngoại vi khác Module chuyển nguồn AC-DC, đèn 220v.
Nguồn cấp Nguồn 220VAC.
Sink node, thu phát 6LoWPAN, điều khiển

Tính năng
.thiết bị điện, thu thập dữ liệu nhiệt độ.
79
Kích thước 8 x 8 x 13 cm.
Số lượng 4 (cái).
- Khối Raspberry Pi – CC2538dk. Phần cứng của khối bao gồm Raspberry Pi
3B+ được kết nối với CC2538dk thông qua module CP2102.
Bảng 10 Thông số kỹ thuật khối root node
Thiết bị chính CC2538dk – Raspberry Pi.

Các ngoại vi khác Module CP1202.
Nguồn cấp Adapter 220V-5V
Tính năng Root node, server, giao tiếp mạng internet.
Số lượng 1 cái.
6.2 Kết quả thực hiện phần mềm và firmware

 Quá trình chọn nhóm điều khiển
Hình 6.2 Lựa chọn nhóm điều khiển và phản hồi từ root
80
Lựa chọn nhóm là quá trình người dùng lựa chọn nhóm multicast để điều
khiển. Ứng dụng sẽ gửi một message đến topic “Group” trên Broker, sau đó Broker
gửi messsage này đến Raspberry, và được truyền đến Root thông qua cổng COM.
Khi lựa chọn thành công, root node sẽ phản hồi thông qua ứng dụng android (hình
6.2).
 Quá trình điều khiển

Sau khi chọn nhóm multicast, ta có thể thực hiện các thao tác điều khiển thiết
bị điện tại các sink node với 2 nút “Light On” và “Light Off”. Khi việc điều khiển
thành công, root node nhận đủ các ACK và kết thúc quá trình (hình 5.15 (A)). Nếu
có sink node bị lỗi gói, Root sẽ báo về ứng dụng android id của node bị lỗi (hình
5.15 (B)) đồng thời thực hiện lại việc gửi gói. Trong trường hợp thực hiện lại việc
gửi gói quá 3 lần vẫn không thể điều khiển, root node dừng quá trình và thông báo
lỗi (hình 5.15 (C)).
Hình 6.3 Quá trình điều khiển
 Thu thập dữ liệu nhiệt độ

Khi nhận được lệnh thu thập dữ liệu nhiệt độ, root node sẽ gửi gói tin multicast
yêu cầu dữ liệu tới tất cả các sink node. Sau đó, dữ liệu nhiệt độ sẽ được tổng hợp
và biểu hiện dưới dạng biểu đồ tại ứng dụng người dùng (hình 6.4).
81
Hình 6.4 Thu thập và biểu diễn nhiệt độ
6.3 Kết quả range test
Để kiểm tra khả năng hoạt động của ứng dụng được thiết kế, nhóm tiến hành
thực hiện range test với vị trí đặt các node trong khuôn viên trường Đại Học Bách
Khoa Tp.HCM như hình 5.14. Root node được đặt tại hành hành lang tòa nhà B3 (
phòng đào tạo sau đại học). 2 sink node thuộc nhóm multicast Odd được lần lượt
trước tòa nhà B4 và hành lang hội trường A5. Các sink node thuộc nhóm multicast
Even được đặt tại hồ nước đối diện tòa nhà B3 và hành lang B1.
Mục tiêu của range test là đánh giá khả năng hoạt động multihop của hệ thống
với các khoảng cách và điều kiện khác nhau dựa vào tỉ lệ điều khiển bật tắt led
thành công. Tỉ lệ điều khiển thành công được tính là số lần sink node thực hiện
đúng lệnh điều khiển trên 100 lần gửi lệnh. Lưu ý, đối với range test, nhóm thực
hiện khi CC2538dk chưa được đóng gói trong phần cứng.
Bảng 10 ghi nhận các thông số và kết quả của range test.
82
Hình 6.5 Sơ đồ thực hiện range test

Bảng 11 Kết quả thực hiện range test
Khoảng Số Tỉ lệ điều
Nhóm
Node Điểm đặt cách tới multihop khiển
multicast
root tới root thành công
Root node - Trước PĐT - - -
sau đại học
Sink Node Odd Trước B4 45m 1 87%
Sink node Odd Hành lang A5 90m 2 62%
Sink node Even Hồ nước 30m 1 93%
Sink node Even Hành lang B1 60m 2 77%
Qua kết quả thực hiện range test ở bảng 10, module CC2538dk hoạt động khả
tốt. Với các sink node có bước nhảy tới root node là 1, tỉ lệ điều khiển thành công
lên tới 90%. Tỉ lệ thành công giảm còn 69.5% khi số bước nhảy tới root tăng lên 2.
Vì trong môi trường thực nghiệm có nhiều vật cản (cây cối, các dãy phòng học...)
và có sự can nhiễu từ nhiều nguồn như sóng Wifi (phát hiện hơn 8 nguồn phát wifi
tại khu vực test) nên tỉ lệ thành công này thấp hơn so với khi thực hiện mô phỏng
với ESMRF sử dụng NullRDC. Tuy nhiên, kết quả này vẫn cho thấy tính khả quan
trong việc triển khai hệ thống sử dụng giao thức multicast cho mạng 6LoWPAN
trong thực tiễn.
83
Chương 7: Kết luận và hướng phát triển
CHƯƠNG 7 KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN
7.1 Kết luận

7.1.1 Đánh giá
Với những kết quả đạt được trong mô phỏng và ứng dụng đầu ra, ta nhận thấy
hệ thống multicast trong mạng 6LoWPAN/IPV6 cho các kết quả khả quan, có thể
áp dụng được thực tế với nhiền tính năng khả dụng: đo đạc các thông số cảm biến,
điều khiển các thiết bị điện AC, DC qua giao diện trực quan, sinh động và thông
qua mạng internet.
Đối với phần mô phỏng, luận văn đưa ra được các so sánh về hiệu quả hoạt
động của cả 3 giải thuật multicast hiện có là ESMRF, SMRF và MPL/TM. Theo
đó, SMRF cho khả năng hoạt động yếu nhất khi hạn chế chiều truyền gói. Việc sử
dụng ESMRF và Roll-TM được cân nhắc lựa chọn dựa vào tình huống thực tiễn
được đề xuất ở mục 5.1.2 với các thông số được đưa vào đánh giá là Tỉ lệ truyền
gói (PDR), độ trễ (delay) và năng lượng tiêu thụ (PC).
Đối với phần thực hiện thiết kế hệ thống, sản phẩm của luận văn đạt được các
mục tiêu đề đã đề ra là kiểm tra khả năng hoạt động của giải thuật multicast thông
qua hệ thống có các ứng dụng thực tế. Sản phẩm của luận văn với các phần liên kết
với nhau và hoạt động tốt. Các thông số đo đạc đều khả quan. Quá trình vận hành
hiện thực hóa được giải thuật multicast là ESMRF. Đồng thời tính năng ACK do
nhóm thiết kế hoạt động hiệu quả khi cung cấp thông tin về sink node bị lỗi gói cho
người điều khiển đồng thời tự động gửi lại gói tin bị lỗi lên đến 3 lần. Hệ thống có
thể tăng số lượng sink node một cách dễ dàng bằng cách nạp firmware cho
cc2538dk tại sink node và cập nhật số lượng node cũng như ID cho root. Tuy nhiên,
hệ thống điều khiển và giám sát thông mình sử dụng giao thức Multicast trong
6LoWPAN còn khá ít ứng dụng thực tế, sơ khai, cần bổ sung thêm để tăng tính ứng
dụng.
84
Chương 7: Kết luận và hướng phát triển
Với các kết quả trên nhóm đã hoàn thành các nhiệm vụ luận văn được giao.
Ngoài ra, nhóm còn bổ sung thêm phần Phụ lục, nơi các nghiên cứu , quá trình thực
hiện các bước với Contiki OS và các phần cứng được trình bày chi tiết.
7.1.2 Hạn chế

Vì giới hạn đề tài và thiết bị nên không thể áp dụng nhiều thiết bị hoạt động
cùng một lúc để có các thông số mạng khách quan hơn. Thiết kế hệ thống với quy
mô khá nhỏ khi chỉ có 4 sink node cho 2 nhóm multicast và 1 root node.
Chưa tận dụng được khả năng cập nhật firmware từ xa của CC2538dk để cập
nhật sink node khi có thay đổi trong firmware. Các thông số như Sink node ID, địa
chỉ nhóm multcast, mảng ACK trên root node và số lượng sink node lưu trên root
node còn phải khởi tạo thủ công trong firmware, chưa có phương pháp cập nhật
trực tiếp.
7.2 Hướng phát triển
Với các hạn chế của đề tài, nhóm sẽ cố gắng khắc phục trong tương lai cũng
như mở rộng mô hình này lên không chỉ trong hệ thống điều khiển và giám sát thiết
bị điện mà còn ở các dự án Smart Home, Smart Street, ...
 Phát triển phần cứng, firmware
+ Liên kết thêm nhiều ngoại vi, cảm biến khác với các phần cứng khác nhau,
thiết kế hộp thiết bị gọn hơn, đẹp hơn và có các led báo trạng thái hoạt động
của sink node.
+ Phát triển khả năng báo cáo vị trí sink node bị lỗi.
+ Có khả năng update firmare từ xa.
+ Khả năng điều khiển thay đổi nhóm multicast tại sink node từ xa.
 Phát triển phần mềm
+ Giám sát theo thời gian thực
+ Mô phỏng được sơ đồ các nút cảm biến
+ Phát triển trên nhiều nền tảng khác nhau: IOS, Android, We
85
Tài liệu tham khảo
TÀI LIỆU THAM KHẢO

[1] Z. Shelby and C. Bormann, "6LoWPAN: The Wireless Embedded Internet," ed:
WILEY, 2009.
[2] A. Moschitta and I. Neri, "Power consumption Assessment in Wireless Sensor
Networks," in ICT - Energy - Concepts Towards Zero, ed, 2014.
[3] A. A. A. Alkhatib and G. S. Baicher, "Wireless Sensor Network Architecture," 2012.
[4] IANA. (2019). IPv4 Address Report. Available: https://ipv4.potaroo.net/
[5] IETF, "RFC 4291: IP Version 6 Addressing Architecture," ed, 2006.
[6] A. L. Colina, A. Vives, M. Zennaro, A. Bagula, and E. Pietrosemoli, Internet of
Things in 5 days.
[7] T. Đ. Thuận, "Nghiên cứu, đánh giá hiệu năng của giao thức định tuyến cho mạng
Cảm biến không dây với hỗ trợ 6loWPAN," Trường Đại học Công nghệ, 2013.
[8] A. Dunkels, "The ContikiMAC Radio Duty Cycling Protocol," SICS Technical
Report T2011:132011.
[9] N. T. Giang, "Định tuyến RPL cho mạng không dây công suất thấp," Tạp chí Công
nghệ thông tin và Truyền thông, 4/2017.
[10] JP Vasseur, N. Agarwal, and J. Hui, "RPL: The IP routing protocol designed for low
power and lossy networks," 4/2011.
[11] ANRG. (November 2014, March 3, 2019). Trickle Library.
[12] IEFT, "The Trickle Algorithm," in Standard Track, ed: P. Levis, T. Clausen, J. Hui,
O. Gnawali, J. Ko, March 2011.
[13] K. Q. A. F. K. Elsayed, "ESMRF: enhanced stateless multicast forwarding for Ipv6 -
based Low-Power and lossy Networks," presented at the IETA2 Web of Objects
Project Egypt, May 2015.
[14] IETF, "Multicast Protocol for Low-power and Lossy Networks (MPL)," in RFC
7731, ed: J.Hui & R.Kelsey, February 2016.
[15] G. Oikonomou, "IPv6 Multicast Forwarding in RPL-Based Wireless Sensors
Networks," 2013.
[16] I. P. George Oikonomou, "Stateless Multicast Forwarding with RPL in 6LowPAN
Sensor Networks," in 8th IEEE International Workshop on Sensor Networks and
Systems for Pervasive Computing 2012, Lugano, March 19, 2012.
[17] G.Oikonomou. (2014, March 2019). Document: RPL. Available:
https://github.com/contiki-ng/contiki-ng/wiki/Documentation:-RPL
[18] O. schmidt. (2003, January 2019). Contiki: The Open Source OS for the Internet of
Things. Available: http://www.contiki-os.org/index.html
[19] G.Oikonomou. (2014, January 2019). An Introduction to Cooja. Available:
https://github.com/contiki-os/contiki/wiki/An-Introduction-to-Cooja
[20] T. Instrument, "CC2538 Powerful Wireless Microcontroller System-On-Chip for
2.4-GHz IEEE 802.15.4, 6LoWPAN, and ZigBee® Applications," ed, 2012.
86
Phụ lục
PHỤ LỤC
A. Quá trình mô phỏng trên Contiki/Cooja
Hình phụ lục A - 1 Tiến trình thực hiện mô phỏng
user@instant-contiki:~$ cd contiki/tools/cooja/
user@instant-contiki:~/contiki/tools/cooja$ ant run
Ứng dụng cooja được compile, tạo file một bản mô phỏng mới tại File > New
simulation... . Thay đổi các thiết lập của mô phỏng như sau và tiến hành create:
Hình phụ lục A - 1. Khởi tạo mô phỏng mới
Tại cửa sổ Network, View > Radio environment (UDGM), click phải vào cửa
số Network, chọn Change Transmission ranges, Change TX/RX success ratio để
thay đôi các thông số của hệ thống mô phỏng.
87
Phụ lục
Hình phụ lục A - 2. Cửa sổ thay đổi thông số mô phỏng
Tiếp theo, khởi tạo các node tương ứng tại Motes > Add motes > Create new
mote types > sky motes. Trong cửa sổ mới xuất hiện, load firmware tương ứng
root.c và sink.c tại thư mục: ~/contiki/examples/ipv6/multicast và tiến hành
compile. Sau đó create, nhập các thông số về số lượng, vị trí node và tiến hành tạo
node.
Hình phụ lục A - 3. Compile firmware và tạo node
88
Phụ lục
Sau khi đã hoàn tất thiết lập môi trường mô phỏng với Cooja, ta thay đối các
thông số cấn thiết trong firmware của root và sink, đồng thời thay đổi giải thuật
multicast trong file project-conf.h tại thư mục: ~/contiki/example/ipv6/multicast.
d. File root.c :
#define INTERATIONS 1000 /* change number of multicast packets */
#define SEND_INTERVAL CLOCK_SECOND /*Traffic Flow*/
#define START_DELAY 60 /* Start sending multicast packet after a delay */
Thay đổi thông số Interations để điều chỉnh số lượng multicast packet khảo
sát, send_interval để thay đổi tốc độ gửi multicast packet . Start_delay để đảm báo
việc routing và tạo cây DODAG hoàn thành trước khi gửi gói multicast.
e. File project-conf.h:
#define UIP_MCAST_CONF_ENGINE 1
#define NETSTACK_CONF_RDC contikimac_driver /* RDC driver */
#define ROLL_TM_CONF_IMIN_1 64
#define UIP_MCAST6_ROUTE_CONF_ROUTES 1
UIP_MCAST_CONF_ENGINE dùng để khai báo giải thuật multicast sử
dụng, các tùy chọn bao gồm: 1: SMRF; 2: TM; 3: ESMRF. RDC driver được lưu
tại khai báo NETSTACK_CONF_RDC, ROLL_TM_CONF_IMIN_: thay đổi giá
trị IMIN đối với giải thuật TM, sử dụng 64ms đối với Contiki MAC.
Sau khi đã hoàn tất các thiết lập và cài đặt, tại cửa số Simulation control của
Cooja, ta tiến hành Reload và bắt đầu mô phỏng, quan sát mức tiêu thụ năng lượng
của từng mode với tool Power Tracker. Kết thúc quá trình mô phỏng, tại cửa sổ
Mote Output, chọn file/save to file để lưu lại file loglistener.txt chứa các số liệu để
phân tích.
Quá trình này được lặp lại với 3 lần với mỗi topology, mỗi lần cho một giải
thuật multicast riêng biệt.
B. Thiết kế chương trình xử lí dữ liệu đầu ra của quá trình mô phỏng

Sau khi thực hiện mô phỏng trên Cooja, kết quả trả về là nội dung các message
của các node (hình phụ lục B-1). Để tính toán được average delay, packet delivery
89
Phụ lục
ratio (PDR) của từng node, ta phải thêm một giai đoạn xử lí đoạn output trên. Do
vậy, nhóm đã viết một tool nhỏ, lập trình bằng ngôn ngữ C, đầu vào là file text
chứa output của Cooja, đầu ra là file text chưa các giá trị delay, PDR của từng node.
Hình phụ lục B - 1 Output của các node sau khi mô phỏng bằng Cooja
Giải thuật của chương trình trên được minh hoạ theo sơ đồ hình B - 2. Ban
đầu, người dùng cần thiết lập các thông số như tổng số node trong mạng, ID của
Root, tổng số multicast packet Root gửi đi. Chương trình sẽ thực hiện duyệt từng
dòng file text đầu vào, dùng các hàm xử lý chuỗi để tách các thông số như thời gian
gửi/ nhận gói tin, tổng số gói tin đã nhận được, node ID. Các giá trị này được lưu
vào các mảng :
• TimeStart[ ] : lưu thời gian gửi gói tin của Root node, kích thước của mảng
bằng tổng số multicast packet Root gửi đi.
• Delay[ ] : lưu tổng thời gian trễ khi nhân từ lúc gửi đến lúc nhận gói tin
của từng node trong mạng, mảng này có kích thước bằng tổng số node
trong một mạng (ban đầu, tất cả phần tử trong mảng đều được gán bằng 0).
Delay  NoteID   time _ receive  TimeStart  packetID
Giá trị Average Delay của một node sẽ tính dựa trên giá trị Delay và số
packet nhận được của node đó:
90
Phụ lục
Delay  nodeID 
Average _ Delay  *100
Total _ packet
 PDR[ ] : lưu giá trị packet delivery ratio nhận được của từng node.
total _ packet _ received
PDR  nodeID   *100
total _ packet _ sended
Bắt đầu chương trình
Xác định Root ID,

tổng số node, tổng
số multicast packet
Duyệt từng
message trong file
text input
SAI
Xác định
TimeStart[], Delay[],
PDR[]
End of file?
ĐÚNG
Xuất kết quả

ra file text
Hình phụ lục B - 2 Giải thuật của chương trình
Sau khi chạy xong, chương trình sẽ xuất kết quả ra file text : Result.txt và màn
hình Console như hình B-3 và B-4 (Trong trường hợp ESMRF Forwarding) :
91
Phụ lục
Hình phụ lục B - 3 Kết quả trả về trên màn hình Console
Hình phụ lục B - 4 Kết quả dưới dạng text file
92
Phụ lục
C. Tạo Mosquitto Broker bằng CloudMQTT

CloudMQTT là một giải pháp hoàn hảo cho việc gửi gói tin giữa các cảm biến
năng lượng thấp hoặc các thiết bị di động như điện thoại, máy tính nhúng hoặc các
board sử dụng vi điều khiển như Arduino. CloudMQTT tự động hóa mọi phần thiết
lập và vận hành Broker Mosquitto của người dùng. Sau đây nhóm xin giới thiệu
cách để tạo một Broker trên CloudMQTT một cách miễn phí.
Trước tiên cần có một tài khoản trên trang https://www.cloudmqtt.com/, ta có thể
đăng kí mới hoặc sử dụng tài khoản có sẵn trên Google hay GitHub để đăng nhập.
Hình phụ lục C - 1 Màn hình đăng nhập trước khi khởi tạo Broker
Sau khi đăng nhập thành công, nó sẽ chuyển sang trang chính của
CloudMQTT với các thông tin về những Broker mình đã tạo. Tại đây ta bấm chọn
“Create new Instance” để tạo một Broker mới, các bước tạo broker được mô tả ở
các hình dưới đây.
93
Phụ lục
Hình phụ lục C - 2 Đặt tên và gói dịch vụ CloudMqtt (miễn phí hoặc trả phí)
Hình phụ lục C - 3 Chọn Data Center
94
Phụ lục
Hình phụ lục C - 4 Các nhận lại thông số cài đặt
Hình phụ lục C - 5 Kết quả sau khi cài đặt xong một MQTT Broker
Như vậy chỉ sau các bước đơn giản, ta đã khởi tạo thành công một MQTT
Broker, ưu điểm của phương pháp này là tính tự động hoá, không cần phải tự build
tay một server, và đặc biệt là miễn phí. Tuy nhiên đây cũng chính là một nhược
điểm khi chúng ta muốn phát triển thêm các tính năng khác cho server hay muốn
làm việc với database thì không thể làm được. Do đó tuỳ mục đích sử dụng mà ta
hãy chọn nền tảng hợp lí để thiết kế server.
95

Multicast 6LoWPANIPv6

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Multicast 6LoWPANIPv6

Uploaded by

Copyright:

Available Formats

ĐẠI HỌC QUỐC GIA TP.

LUẬN VĂN TỐT NGHIỆP ĐẠI HỌC

Xây dựng hệ thống giám sát và điều khiển thông minh

GVHD: TS. Võ Quế Sơn

TP. HỒ CHÍ MINH, THÁNG 6 NĂM 2019

NHIỆM VỤ LUẬN VĂN TỐT NGHIỆP

KHOA : ĐIỆN – ĐIỆN TỬ

Ngày 11 tháng 5 năm 2019

PGS.TS. Hà Hoàng Kha TS. Võ Quế Sơn

Văn Đình Triều

Hình 2.1 Cấu trúc mạng cảm biến không dây........................................................................... 5

Bảng 1 Các tham số mô phỏng ................................................................................................. 32

6LoWPAN IPv6 over Low Power Wireless Area Network

CHƯƠNG 1 GIỚI THIỆU ĐỀ TÀI

1.1 Tổng quan về đề tài

1.2 Nhiệm vụ luận văn

Tóm lại, nhiệm vụ luận văn bao gồm:

1.3 Nội dung luận văn

CHƯƠNG 2 CÁC KHÁI NIỆM CHUNG

2.1 Mạng cảm biến không dây - WSN

2.1.2 Cấu trúc mạng cảm biến không dây

Hình 2.1 Cấu trúc mạng cảm biến không dây

Hình 2.3 Kiến trúc mạng cảm biến không dây[3]

2.1.4 Ứng dụng của mạng cảm biến không dây

2.2.1 Tổng quan về IPv6

Hình 2.4 Thực trạng địa chỉ IPv4 hiện nay[4]

2.2.2 Các loại địa chỉ IPv6

2.3.1 Tổng quan

Hình 2.5 Kiến trúc mạng 6LowPAN[1]

2.3.2 Các đặc tính của 6LoWPAN:

2.3.3 Kiến trúc của mạng 6LoWPAN

Hình 2.6 Kiến trúc mạng 6LoWPAN[1]

2.3.4 Quá trình thiết lập và vận hành 6LoWPAN

2.4.2 Giao thức MAC trong Contiki OS

Hình 2.7 Cơ chế hoạt động của ContikiMAC[8]

Hình 2.8 ContikiMAC với trường hợp gửi broadcast[8]

b. Giao thức NullRDC

2.5 Giao thức định tuyến RPL

2.5.2 Quá trình xây dựng kết nối mạng

Hình 2.9 Mô hình DODAG

2.5.3 Các chế độ định tuyến trong giao thức RPL

Hình 2.10 RPL Non-storing mode

Hình 2.11 RPL Storing mode

CHƯƠNG 3 CÁC GIẢI THUẬT MULTICAST

3.1 Thuật toán Trickle

3.1.1 Tổng quan

3.1.2 Các tham số và biến

Ngoài 3 tham số trên, thuật toán trickle còn có 3 biến:

3.1.3 Mô tả hoạt động

Hình 3.1 Thuật toán Trickle

3.2.2 Đánh giá giải thuật

3.3 Stateless multicast RPL forwarding – SMRF

Hình 3.3 Giải thuật SMRF [15]

3.3.2 Đánh giá giải thuật

3.4 Enhanced Stateless multicast RPL forwarding – ESMRF

Hình 3.4 Gói tin ICMPv6 "Multicast-on-behalf" [13]

Hình 3.5 Quá trình gửi "Multicast-on-behalf" của ESMRF

3.4.2 Đánh giá giải thuật

CHƯƠNG 4 MÔ PHỎNG SO SÁNH CÁC GIẢI THUẬT MULTICAST

4.2 Công cụ mô phỏng – Cooja

Hình 4.1 Giao diện Cooja simulator

4.3 Thiết kế hệ thống mô phỏng

4.3.1 Cài đặt mạng

Bảng 1 Các tham số mô phỏng