(123doc) Dinh Tuyen Cho Mang Internet of Things

BỘ GIÁO DỤC VÀ ĐÀO TẠO
TRƢỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI

---------------------------------------
NGUYỄN HẢI NAM
ĐỊNH TUYẾN CHO MẠNG INTERNET OF THINGS
Chuyên ngành : Kỹ thuật máy tính
LUẬN VĂN THẠC SĨ KỸ THUẬT

KỸ THUẬT MÁY TÍNH
NGƢỜI HƢỚNG DẪN KHOA HỌC
Hà Nội – 2017
CỘNG HÒA XÃ HỘI CHỦ NGHĨA VIỆT NAM
Độc lập – Tự do – Hạnh phúc
BẢN XÁC NHẬN CHỈNH SỬA LUẬN VĂN THẠC SĨ

Họ và tên tác giả luận văn: Nguyễn Hải Nam
Đề tài luận văn: Định tuyến cho mạng Internet of Things
Chuyên ngành: Kỹ thuật máy tính
Mã số SV: CB140334
Tác giả, Ngƣời hƣớng dẫn khoa học và Hội đồng chấm luận văn xác nhận
Tác giả luận bổ sung luận văn theo biên bản họp Hội đồng ngày 28 tháng
10 năm 2017 nhƣ sau
- Bổ sung nội dung: mục “Một số giao thức định tuyến trong Internet of
Things” và mục “Đánh giá kết quả mô phỏng”
- Sửa đổi nội dung: mục “Kết luận và hƣớng phát triển”
Ngày tháng năm 2017

Giáo viên hƣớng dẫn Tác giả luận văn
Chủ tịch hội đồng

MỤC LỤC
LỜI CẢM ƠN ......................................................................................................... I
LỜI CAM ĐOAN ..................................................................................................II
DANH MỤC TỪ VIẾT TẮT ............................................................................... III
DANH MỤC BẢNG ............................................................................................ IV
DANH MỤC HÌNH VẼ ........................................................................................ V
MỞ ĐẨU ............................................................................................................. VII
CHƢƠNG 1: TỔNG QUAN VỀ IOT.................................................................... 1
1.1. Định nghĩa IoT.......................................................................................... 1
1.2. Tầng giao thức trong IoT .......................................................................... 2
1.2.1. Tầng Physical (vật lý) ........................................................................ 3
1.2.2. Tầng Data Link (liên kết dữ liệu) ...................................................... 4
1.2.3. Tầng Network (mạng) ........................................................................ 5
1.2.3.1. 6LoWPAN .................................................................................. 5
1.2.3.2. RPL ............................................................................................. 8
1.2.4. Tầng Transport (vận chuyển)............................................................. 9
1.2.5. Tầng Application (ứng dụng) ............................................................ 9
1.3. Một số giao thức định tuyến trong IoT ................................................... 10
1.3.1. AOMDV-IoT ................................................................................... 10
1.3.2. SMRP ............................................................................................... 11
1.3.3. PAIR ................................................................................................ 12
1.3.4. REL .................................................................................................. 13
1.3.5. RPL .................................................................................................. 14
1.3.6. Kết luận ............................................................................................ 14
CHƢƠNG 2: TỔNG QUAN VỀ RPL, CONTIKI RPL VÀ HOẠT ĐỘNG CỦA
RPL TRÊN CONTIKI.......................................................................................... 16
2.1. Tổng quan về RPL .................................................................................. 16
2.1.1. Khái niệm, thuật ngữ sử dụng trong RPL ........................................ 17
2.1.2. Các bản tin điều khiển trong RPL .................................................... 20
2.1.3. Bản tin DIS ...................................................................................... 21
2.1.4. Bản tin DIO ...................................................................................... 22
2.1.4.1. Cấu trúc bản tin DIO ................................................................. 22
2.1.4.2. Các luật của bản tin DIO ........................................................... 23
2.1.4.3. Cấu trúc sub-option trong DIO ................................................. 24
2.1.4.4. Bộ định thời DIO ...................................................................... 26
2.1.4.5. Nhận và xử lý bản tin DIO ........................................................ 28
2.1.5. Bản tin DAO .................................................................................... 28
2.1.5.1. Cấu trúc bản tin DAO ............................................................... 29
2.1.5.2. Truyền bản tin DAO ................................................................. 30
2.1.6. Quá trình khởi tạo mạng .................................................................. 31
2.1.7. Quá trình định tuyến upward ........................................................... 31
2.1.7.1. DODAG parent và preferred parent .......................................... 32
2.1.7.2. Quản lý neighbor, khám phá DODAG và lựa chọn DODAG
parent…… .................................................................................................. 32
2.1.7.3. Tính toán rank và sự di chuyển của các node ........................... 33
2.1.8. Truyền gói ........................................................................................ 34
2.2. Tổng quan về Contiki RPL và hoạt động của RPL trên Contiki ............ 36
2.2.1. Hệ điều hành Contiki ....................................................................... 36
2.2.2. Contiki RPL ..................................................................................... 37
2.2.3. Định tuyến trong Contiki RPL ......................................................... 41
2.2.3.1. Những yêu cầu cần đạt đƣợc khi triển khai Contiki RPL ......... 42
2.2.3.2. Hoạt động của DODAG root / UDP-Server ............................. 42
2.2.3.3. Hoạt động của các node client trong DODAG / UDP-client .... 44
2.2.3.4. Cơ chế xử lý bản tin DIO và xây dựng DODAG...................... 45
CHƢƠNG 3: MÔ PHỎNG HOẠT ĐỘNG CỦA RPL TRÊN CONTIKI RPL .. 48
3.1. Mục tiêu mô phỏng ................................................................................. 48
3.2. Tham số cài đặt mô phỏng...................................................................... 48
3.3. Kịch bản mô phỏng................................................................................. 49
3.4. Phân tích ................................................................................................. 49
3.4.1. Kịch bản 1: 1 Instance – 1 DODAG root – 15 Node client ................ 49
3.4.1.1. Quá trình hình thành topo mạng ............................................... 49
3.4.1.2. Tỉ lệ truyền gói thành công ....................................................... 54
3.4.1.3. Chi phí truyền gói ..................................................................... 55
3.5. Đánh giá kết quả mô phỏng .................................................................... 70
3.6. Kết luận................................................................................................... 71
TÀI LIỆU THAM KHẢO .................................................................................... 73
PHỤ LỤC ............................................................................................................. 75
LỜI CẢM ƠN
Để hoàn thành luận văn này, tôi xin bày tỏ lòng biết ơn sâu sắc tới PGS. TS
Ngô Quỳnh Thu đã tận tình hƣớng dẫn tôi trong suốt quá trình thực hiện nghiên
cứu và thử nghiệm. Tôi xin chân thành cảm ơn các thầy, cô trong Viện Công
Nghệ Thông Tin và Truyền Thông - Đại học Bách Khoa Hà Nội đã giảng dạy,
truyền đạt cho tôi những kiến thức quý báu và tạo mọi điều kiện để tôi hoàn
thành khóa học và thực hiện luận văn này.
Tôi cũng xin gửi lời cảm ơn đến các anh, các chị, các bạn học viên trong đội
ngũ Lab của PGS.TS Ngô Quỳnh Thu đã chia sẻ nhiều tài liệu và kinh nghiệm
quý giá liên quan đến vấn đề nghiên cứu của luận văn.
Tôi cũng xin cảm ơn gia đình, bạn bè đã chia sẻ, giúp đỡ tôi trong suốt quá
trình học tập nghiên cứu thực hiện luận văn.
Xin trân trọng cảm ơn!

Hà Nội, ngày tháng năm 2017
Ngƣời thực hiện
Nguyễn Hải Nam
Học viên thực hiện: Nguyễn Hải Nam – CB140334 I

LỜI CAM ĐOAN
Luận văn đề tài “Định tuyến cho mạng Internet of Things” thực hiện dƣới sự
hƣớng dẫn của PGS. TS Ngô Quỳnh Thu, nghiên cứu, mô phỏng, đánh giá về
quá trình định tuyến RPL trọng mạng Internet of Things bằng công cụ mã nguồn
mở Cooja chạy trên nền tảng Contiki 3.0
Tôi cam kết đây là công trình nghiên cứu, phát triển của bản thân, dựa trên các
công cụ, phần mềm mã nguồn mở hợp pháp, các tài liệu tham khảo, nội dung
trích dẫn đƣợc ghi rõ nguồn gốc, không sao chép, vi phạm bản quyền của bất cứ
cá nhân, tổ chức nào khác.
Hà Nội, ngày tháng năm 2017

Ngƣời thực hiện
Nguyễn Hải Nam
Học viên thực hiện: Nguyễn Hải Nam – CB140334 II

DANH MỤC TỪ VIẾT TẮT
IoT Internet of Things
IEEE Institute of Electrical and Electronics Engineers
IETF Internet Engineering Task Force
W3C World Wide Web Consortium
RPL Routing Protocol for Low Power and Lossy Network
DODAG Destination Oriented Directed Acyclic Graph
DIS DODAG Information Solicitation
DIO DODAG Information Object
DAO Destination Advertisement Object
Học viên thực hiện: Nguyễn Hải Nam – CB140334 III

DANH MỤC BẢNG
Bảng 1.1. IoT protocol stack .................................................................................. 2
Bảng 1.2. Băng tần và tốc độ dữ liệu của IEEE 802.15.4[6] ................................... 4
Bảng 1.3. Kênh truyền và tần số trong IEEE 802.15.4[6] ....................................... 4
Bảng 1.4. So sánh giữa các giao thức .................................................................. 14
Bảng 3.1. Tham số mô phỏng .............................................................................. 48
Bảng 3.2. Tỉ lệ truyền gói thành công của các node trong DODAG ................... 54
Bảng 3.3. Tỉ lệ truyền gói thành công trung bình tại các rank ............................. 54
Bảng 3.4. Bản tin đã gửi trong các node mạng .................................................... 55
Bảng 3.5. Tỉ lệ truyền gói thành công của các node trong DODAG ................... 59
Bảng 3.6. Tỉ lệ truyền gói thành công trung bình tại các rank ............................. 59
Bảng 3.7. Bản tin đã gửi trong các node mạng .................................................... 60
Bảng 3.8. Các bản tin DATA gửi tới node 1 ....................................................... 66
Bảng 3.9. Các bản tin DATA gửi tới node 17 ..................................................... 67
Bảng 3.10. Tỉ lệ truyền gói thành công của các node trong DODAG ................. 68
Bảng 3.11. Tỉ lệ truyền gói thành công trung bình tại các Rank ......................... 68
Bảng 3.12. Bản tin đã gửi trong các node mạng .................................................. 70
Học viên thực hiện: Nguyễn Hải Nam – CB140334 IV

DANH MỤC HÌNH VẼ
Hình 1.1. So sánh tầng giao thức của mạng internet truyền thống và mạng IoT ... 2
Hình 1.2. Cấu trúc header của cơ chế UDP/IPv6 64bit ......................................... 7
Hình 1.3. Cấu trúc header của cơ chế UDP/6LoWPAN ........................................ 7
Hình 1.4. Sự khác nhau về cấu trúc bản tin giữa UDP/IPv6 và UDP/6LoWPAN 8
Hình 2.1. Mô hình RPL DODAG ........................................................................ 17
Hình 2.2. RPL instance và DODAG sequence number ....................................... 19
Hình 2.3. Cấu trúc bản tin điều khiển RPL .......................................................... 21
Hình 2.4. Cấu trúc bản tin DIS ............................................................................. 21
Hình 2.5. Cấu trúc bản tin DIO ............................................................................ 22
Hình 2.6. Cấu trúc sub-option .............................................................................. 24
Hình 2.7. Cấu trúc DIO – Pad 1 ........................................................................... 24
Hình 2.8. Cấu trúc DIO – Pad N .......................................................................... 25
Hình 2.9. Cấu trúc DIO-metric container ............................................................ 25
Hình 2.10. Cấu trúc DIO – Destination Prefix ..................................................... 26
Hình 2.11. Cấu trúc DODAG Configuration ....................................................... 26
Hình 2.12. Cấu trúc bản tin DAO ........................................................................ 29
Hình 2.13. Kiến trúc giao thức mạng của Contiki RPL ....................................... 38
Hình 2.14. Cấu trúc Contiki RPL ......................................................................... 38
Hình 2.15. Quá trình hoạt động của DODAG root .............................................. 43
Hình 2.16. Cơ chế điều khiển sự kiện của DODAG root .................................... 43
Hình 2.17. Pha khởi tạo của những node udp-client ............................................ 44
Hình 2.18. Cơ chế điều khiển sự kiện của udp-client .......................................... 45
Hình 2.19. Quá trình xử lý bản tin DIO ............................................................... 46
Hình 3.1. Phân bố các node trong mạng .............................................................. 49
Hình 3.2. node 2 gửi bản tin DIS tới các node hàng xóm .................................... 50
Hình 3.3. node 5 nhận đƣợc bản tin DIS từ các node hàng xóm ......................... 51
Hình 3.4. Các node gửi bản tin DIS tới các node hàng xóm................................ 51
Hình 3.5. DODAG root gửi bản tin DIO tới các node hàng xóm ........................ 52
Học viên thực hiện: Nguyễn Hải Nam – CB140334 V

Hình 3.6. Thông tin bản tin DIO gửi từ DODAG root tới các node hàng xóm ... 52
Hình 3.7. Quá trình hình thành DODAG ............................................................. 53
Hình 3.8. Topo mạng của DODAG ..................................................................... 56
Hình 3.9. Gói tin RPL trong node 15 ................................................................... 57
Hình 3.10. Quá trình hình thành DODAG ........................................................... 61
Hình 3.14. Topo mạng của DODAG ................................................................... 64
Hình 3.15. Gói tin node 21 ................................................................................... 65
Học viên thực hiện: Nguyễn Hải Nam – CB140334 VI

MỞ ĐẨU
a. Lý do chọn đề tài
“Tất cả những thứ đƣợc kết nối với internet đều có sự sống” sẽ là một quy
luật mới trong tƣơng lai. Tƣơng lai chính là Internet of Things (IoT), chúng ta
đang tiến đến nó với những bƣớc nhảy lớn. Thông thƣờng con ngƣời sẽ là đối
tƣợng sử dụng internet, từ giờ trở đi các thiết bị mới là những đối tƣợng sử dụng
chính của hệ sinh thái IoT. Những hoạt động nghiên cứu gần đây đang tận dụng
những công nghệ mới nhất để xây dựng một IoT có khả năng mở rộng. Tuy
nhiên, sự hiểu biết về khuôn khổ của IoT đang bị chậm lại do một số yếu tố,
trong số đó chỉ trích nhiều nhất đó là vấn đề định tuyến. Định tuyến là một vấn
đề hết sức quan trọng, không những làm tăng hiệu năng hoạt động của mạng mà
còn giúp các ứng dụng trong mạng cảm biến trở nên tin cậy hơn.
Xuất phát từ tồn tại này, tôi đã lựa chọn, nghiên cứu các vấn đề về định tuyến
trong IoT, từ đó triển khai mô phỏng đánh giá giao thức định tuyến phổ biến RPL
thông qua Contiki RPL nhằm có sự hiểu biết nhất định về định tuyến trong IoT
nói chung và giao thức định tuyến RPL nói riên và đóng góp nhất định vào việc
phát triển hệ sinh thái IoT
b. Lịch sử nghiên cứu
Đã có những nghiên cứu về định tuyến trong IoT đƣợc đƣa ra trƣớc đây, nhƣ
trong bài báo: Routing Issues in Internet of Things của các tác giả Amol
Dhumane, Rajesh Prasad, Jayashree Prasad hay quyển sách Routing in the
Internet of Things của tác giả Lotte Steembrink đã đƣa ra các khái niệm cơ bản về
IoT cũng nhƣ định tuyến trong IoT. Tuy nhiên vẫn thiếu đi việc mô phỏng, đánh
giá một hoặc hiều giao thức cụ thể.
c. Mục đích nghiên cứu
- Tìm hiểu về IoT (khải niệm, kiến trúc, hoạt động, các giao thức . . .)
- Tìm hiểu sâu về giao thức RPL trong IoT
- Mô phỏng, đánh giá giao thức RPL
d. Đối tƣợng nghiên cứu
Học viên thực hiện: Nguyễn Hải Nam – CB140334 VII

- Môi trƣờng định tuyến trong IoT
- Các thuật toán định tuyến trong IoT
- Hoạt động của giao thức RPL trong IoT
e. Phạm vi nghiên cứu
Nghiên cứu các bài báo sẵn có và hoàn thiện các thành phần
- Hoạt động của giao thức RPL
- Mô phỏng thông qua Contiki RPL
f. Tóm tắt nội dung, kết quả thu đƣợc
Luận văn tìm hiểu lý thuyết về IoT và giao thức định tuyến RPL trong IoT
nhƣ cách giao tiếp, thuật toán, quá trình hình thành topo mạng. Bên cạnh đó
thực hiện mô phỏng giao thức RPL trên Contiki để đánh giá giao thức trên hai
cơ sở tỉ lệ truyền gói thành công và chi phí truyền gói.
g. Phƣơng pháp nghiên cứu
Quá trình nghiên cứu đƣợc chia thành các thành phần lý thuyến và thực
nghiệm sau:
- Tìm hiểu lý thuyết chung về IoT
- Tìm hiểu lý thuyết về định tuyến trong IoT
- Tìm hiểu lý thuyết về giao thức RPL
- Mô phỏng, xây dựng môi trƣờng, kịch bản thử nghiệm, thu thập kết
quả và đanh giá giao thức RPL.
Học viên thực hiện: Nguyễn Hải Nam – CB140334 VIII

CHƢƠNG 1: TỔNG QUAN VỀ IOT
IoT là khái niệm đƣợc sử dụng rộng rãi do đó có rất nhiều khái niệm đi theo.
Từ khi thời đại công nghệ bùng nổ, định nghĩa của “Things” đã đƣợc thay đổi,
mục tiêu chính là làm cho việc thu thập dữ liệu từ vạn vật trể nên dễ dành trong
khi không cần tác động của con ngƣời. Có nhiều nhà nghiên cứu đã cố gắng để
định nghĩa IoT. Một trong số ít đáng chú ý sẽ đƣợc liệt kê dƣới đây.
1.1. Định nghĩa IoT
Theo nhƣ nguồn [1], IoT đại diện cho một mạng lƣới toàn cầu mà trong đó
các đồ vật đƣợc kết nối vƣới nhau thông các giao thức giao tiếp tiêu chuẩn.
Theo nhƣ nhóm nghiên cứu các dự án IoT ở châu Âu trong nguồn [2], Các đồ
vật là những đối tƣợng tham gia chủ động trong công việc trao đổi dữ liệu, thu
thập thông tin của môi trƣờng mà chúng đƣợc cho phép tƣơng tác khi có hoặc
không có sự can thiệp của con ngƣời.
Ủy ban Châu Âu trong nguồn [3] lại định nghĩa IoT, Nguồn gốc ngữ nghĩa
của sự miêu tả này đƣợc gói gọn trong hai từ: Internet và Things. Internet đƣợc
định nghĩa nhƣ một mạng lƣới toàn cầu của các mạng lƣới máy tính dựa trên giao
thức tiêu chuẩn (bộ giao thức internet TCP/IP) đƣợc kết nối với nhau, trong khi
Things ám chỉ đồ vật đƣợc định danh chính xác. Vì vậy theo ngữ nghĩa, Internet
of Things nghĩa là mạng lƣới toàn cầu của các đồ vật đƣợc kết nối với nhau dựa
trên các giao thức định tuyến tiêu chuẩn.
Trong nguồn [4] O. Vermesan và các tác giả định nghĩa IoT là, Một loại cơ sở
hạ tầng mạng toàn cầu năng động với khả năng tự cấu hình dựa trên các tiêu
chuẩn và các giao thức giao tiếp tƣơng thích. Trong đó vật chất thực và vật chất
“ảo” đƣợc định danh trong mạng lƣới thông tin.
Trong tất cả, định nghĩa đƣợc công nhận rộng rãi đƣợc đƣa ra bởi P.
Guillemin và P. Friess trong nguồn [5] là, IoT cho phép con ngƣời và đồ vật
đƣợc sử bất kì phƣơng thức nào và dịch vụ nào để kết nối với nhau mọi lúc, mọi
nơi.
Học viên thực hiện: Nguyễn Hải Nam – CB140334 1

1.2. Tầng giao thức trong IoT
Trong một vài yếu tố, IoT rất khác với internet truyền thống chính vì vậy việc
tùy chỉnh tầng giao thức trong IoT là rất cần thiết. Ví dụ nhƣ giao thức IEEE
802.15.4 thuộc tầng Data Link đã đƣợc tùy chỉnh để phù hợp với các thiết bị có
nguồn và chi phí thấp bằng một số phƣơng pháp nhƣ giảm MTU (Maximum
Transmission Unit) xuống còn 127 byte khi kết hợp với 6LowPAN
Hình 1.1. So sánh tầng giao thức của mạng internet truyền thống và mạng IoT
Các tổ chức lớn trên thế giới nhƣ IEEE, IETF hay cả W3C đã chuẩn hóa các
giao thức của họ nhƣ 6LowPAN, CoAP. . .
OSI Layer IoT Layer IoT Technology Testing System

Application Application CoAP, CoAPs Client - Server
Transport Transport UDP UDP
Net layer IPv6 IPv6
Network ICMP RPL, IPsec RPL
Adaption layer 6LoWPAN 6LoWPAN
MAC layer 802.15.4 MAC Un-beacon mode
Data link CSMA
RDC layer (none) ContikiMAC
Physical PHY layer 802.15.4 PHY Framer 802.15.4
Bảng 1.1. IoT protocol stack

Do nội luận văn luận tập trung nghiên cứu và đánh giá giao thức định tuyến
RPL trong IoT, cho nên luận văn chỉ đƣa ra các khái niệm cơ bản cho các tiêu
chuẩn, giao thức khác trong các tầng application, transport, network, data link,
physical.
1.2.1. Tầng Physical (vật lý)
IEEE 802.15.4 là tiêu chuẩn trong IoT đƣợc sử dụng phổ biết nhất cho tầng
vật lý (PHY) và lớp MAC (Media Access Control). Nó đƣợc chuẩn hóa bởi IEEE
(viện điện điện tử). Nó định nghĩa một định dạng khung, trong đó trƣờng tiêu đề
có chứa địa chỉ nguồn và địa chỉ đích đồng thời chỉ ra phƣơng pháp để các node
có thể giao tiếp với nhau nhƣ thế nào. Trong năm 2008, IEEE 802.15.4e đƣợc
đƣa ra thay thế cho IEEE 802.15.4 truyền thống để hỗ trợ mạng tổn hao năng
lƣợng thấp. IEEE 802.15.4e sử dụng hai cơ chế đồng bộ thời gian (time
synchronization) và kênh (channel hopping) để cho phép các yêu cầu về độ tin
cậy cao, chi phí thấp để đáp ứng yêu cầu truyền thông trong IoT. Các tính năng
cụ thể của IEEE 802.15.4e có thể đƣợc tóm tắt nhƣ sau:
Slotframe Structure: cấu trúc khung của IEEE 802.15.4e đƣợc thiết kế để tạo
ra các lịch trình đồng bộ và thông báo cho các node hàng xóm biết cần phải làm
gì. Một node có thể có một trong ba trạng thái ngủ, gửi bản tin hoặc nhận bản tin.
Trong chế độ ngủ, node tắt bộ thu phát sóng vô tuyến để tiết kiệm tài nguyên và
lƣu trữ tất cả các tin nhắn mà nó cần gửi ở trạng thái tiếp theo. Khi truyền, một
node sẽ gửi dữ liệu và chờ xác nhận. Khi nhận, node thực hiện sẽ bật bộ thu phát
sóng vô tuyến trƣớc thời gian nhận lịch trình, nhận dữ liệu, gửi xác nhận, tắt bộ
thu phát sóng vô tuyến và trở lại về trạng thái ngủ
Scheduling: node quản lý có trách nhiệm xây dựng lịch trình đồng thời thông
báo cho các node về tiến độ và các node khác đó sẽ chỉ theo lịch biểu mà node
quản lý đã đƣa ra
Synchronization: trong IoT việc đồng bộ hóa là rất cần thiết để duy trì kết nối
của các node tới các hàng xóm của nó cũng nhƣ tới node quản lý. Có hai cơ chế
đồng bộ hóa đƣợc sử dụng: đồng bộ hóa acknowledgement-based hoặc frame-

based. Trong cơ chế acknowledgement-based, các node đã đƣợc đăng kí sẽ duy
trì kết nối bằng cách gửi các bản tin acknowledgement. Trong cơ chế frame-
based, các node gửi định kì (khoảng 30 giây) các frame trống
IEEE 802.15.4 có thể hỗ trợ những gói tin có kích thƣớc tải từ 80 đến 100
byte. IEEE 802.15.4 cung cấp 3 dải tần số và 27 kênh truyền trên các dải tần số
khác nhau:
Tốc độ Tốc Tốc độ ký
PHY Băng tần
chip Điều chế độ bit tự Ký tự
(MHz) (MHz)
(Kchip/s) (Kb/s) (ksymbol/s)
868 868-868.6 300 BPSK 20 20 Nhị phân
915 902-928 600 BPSK 40 40 Nhị phân
2450 2400-2486.5 2000 O-QPSK 250 62.5 Hệ 16
Bảng 1.2. Băng tần và tốc độ dữ liệu của IEEE 802.15.4[6]
Tần số trung tâm Số lƣợng kênh Kênh Tần số kênh trung tâm
(MHz) (N) (MHz)
868 1 0 868.3
915 10 1 - 10 906 + 2(k-1)
2450 16 11 – 26 2405 + 5(k-11)
Bảng 1.3. Kênh truyền và tần số trong IEEE 802.15.4[6]
1.2.2. Tầng Data Link (liên kết dữ liệu)
RDC (Radio Duty-Cycle) layer: điện năng tiêu thụ là một vấn đề quan trọng
đối với các node cảm biết trong IoT. Để các node có thể hoạt động bền bỉ trong
nhiều năm thì việc sử dụng phần cứng thu bắt sóng vô tuyến công suất thấp là
chƣa đủ bởi vì các máy thu phát sóng radio hiện này cần rất nhiều năng lƣợng khi
sử dụng, ví dụ nhƣ bộ thu phát sóng vô tuyến CC2420 đƣợc sử dụng trong bản
mạch Tmote Sky cần khoảng 60 miliwatt. Với việc tiêu thụ nhƣ vậy, năng lƣợng
pin sẽ cạn kiệt trong vài ngày. Chính vì vậy, để đạt đƣợc tuổi thọ dài, các node
phải tắt bộ phát sóng vô tuyến càng nhiều càng tốt. Nhƣng bộ thu phát sóng vô
tuyến bị tắt, các node sẽ không thể gửi hoặc nhận bất cứ bản tin nào. Do đó cần

phải có cơ chế điều khiển các node mở bộ thu phát sóng vô tuyến trong lúc giao
tiếp và tắt bộ phát song vô tuyến trong lúc không cần thiết. Nắm bắt đƣợc xu
hƣớng phát triển này, ContikiMac đã ra đời phục vụ rất hiệu quả việc quản lý
việc tắt, bật các bộ thu phát sóng của các node. ContikiMac sử dụng cơ chế đồng
bộ thời gian để duy trì một thời gian biểu giao tiếp giữa các node. Giao thức sẽ
bật bộ thu phát sóng vô tuyến vào một thời điểm đã biết để các node hàng xóm
có thể truyền các gói tin vào thời điểm này.
1.2.3. Tầng Network (mạng)
1.2.3.1. 6LoWPAN
6LoWPAN là tên viết tắt của IPv6 protocol over low-power wireless PANs
(sử dụng giao thức IPv6 trong các mạng PAN không dây công suất thấp).
6LoWPAN đƣợc phát triển bởi hiệp hội đặc trách kỹ thuật Internet IETF
(Internet Engineering Task Force), cho phép truyền dữ liệu qua các giao thức
IPv6 và IPv4 trong các mạng không dây công suất thấp với các cấu trúc mạng
điểm - điểm (P2P: point to point) và dạng lƣới (mesh). 6LoWPAN là giao thức
mạng, cho phép quy định cơ chế đóng gói bản tin và nén header. Đặc biệt, IPv6
là sự kế thừa của IPv4 và cung cấp khoảng 5 x 1028 địa chỉ cho tất cả mọi đối
tƣợng trên thế giới, cho phép mỗi đối tƣợng là một địa chỉ IP xác định để kết nối
với Internet. Đƣợc thiết kế để gửi các bản tin IPv6 qua mạng IEEE802.15.4
và các tiêu chuẩn IP mở rộng nhƣ: TCP, UDP, HTTP, COAP, MQTT và
Websocket, là các tiêu chuẩn cung cấp nodes end-to-end, cho phép các router kết
nối mạng tới các IP.
Các đặc tính của 6LoWPAN:
- Hỗ trợ cả hai phƣơng thức đánh địa chỉ 64 bit và 16 bit của chuẩn IEEE
802.15.4.
- 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.

- Có phƣơng thức nén header hiệu quả. Trong 6LoWPAN sử dụng địa chỉ
IPv6 cơ bản, kết hợp các header mở rộng và các UDP header.
- 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.
- Hỗ trợ chia 1280 byte IPv6 MTU thành các khung 127 byte của 802.15.4.
- Hỗ trợ định tuyến IP (ví dụ định tuyến trong IETF RPL).
Phƣơng thức đánh địa chỉ trong 6LoWPAN:
- Nguyên tắc đánh địa chỉ:
 Không gian địa chỉ phẳng, mỗi mạng chỉ có một subnet.
 Kết hợp với địa chỉ MAC của mỗi thiết bị.
- Các địa chỉ IPv6 đƣợc nén trong 6LoWPAN bằng những phƣơng thức nén
sau:
 Lƣợc bỏ global prefix - vì tất cả các node trong cùng một mạng đều
cùng global prefix.
 Lƣợc bỏ link - local prefix - đƣợc chỉ ra trong định dạng nén
header.
 Nén phần IID - Interface ID: lƣợc bỏ các giao tiếp trực tiếp, nén địa
chỉ mutihop des/src.
 Nén địa chỉ multicast.
Cấu trúc gói tin trong 6LoWPAN:

Hình 1.2. Cấu trúc header của cơ chế UDP/IPv6 64bit
Hình 1.2 cho biết cấu trúc gói tin với cơ chế UDP-CLIENT/IPv6 64bit. Với
cơ chế UDP/6LoWPAN, các thành phần header đƣợc nén một cách tối ƣu, với
chiều dài header chỉ 6 Byte trong hình 1.3
Hình 1.3. Cấu trúc header của cơ chế UDP/6LoWPAN

Sự khác nhau giữa 2 cơ chế thể hiện qua mối tƣơng quan giữa chiều dài
header và kích thƣớc tải tin nhƣ trong hình 1.4

Hình 1.4. Sự khác nhau về cấu trúc bản tin giữa UDP/IPv6 và UDP/6LoWPAN
1.2.3.2. RPL
RPL là giao thức sủ dụng distance-vector có khả năng tƣơng thích cao với các
giao thức tầng data link (bao gồm các giao thức đƣợc đƣa ra ở phần trƣớc). Nó
xây dựng mạng DODAG (Destination Oriented Directed Acyclic Graph) với
hƣớng duy nhất truyền tin về node gốc (root). Đầu tiên, mỗi node sẽ gửi bản tin
DODAG Information Object (DIO) quảng cáo chính nó nhƣ là root tới các node
hàng xóm. Khi giao tiếp, các node gửi bản tin Destination Advertisement Object
(DAO) đến node parent của nó. Khi một nút mới muốn tham gia vào mạng, nó sẽ
gửi bản tin DODAG Information Solicitation (DIS) để tham gia vào mạng và
root sẽ trả lời lại với một bản tin DAO Acknowledgement (DAO-ACK) xác nhận
tham gia. Chỉ có node root mới có bảng định tuyến của toàn DODAG. Do đó, tất
cả các truyền thông đi qua root trong mọi trƣờng hợp. Khi triển khai một mạng
RPL, mỗi RPL Instance đƣợc thiết lập với một hoặc một số DODAG root. Các
thông số định tuyến đƣợc thiết lập phù hợp với mục đích triển khai. Những
DODAG root tự động thiết lập rank bằng 1 (Root RANK), sau đó chúng định
thời quảng bá các bản tin DIO đến những node xung quanh để xây dựng
DODAG của bản thân.

CORPL là phiên bản mở rộng của RPL, nhƣng vẫn đang trong quá trình hoàn
thiện, với hai sửa đổi. Đầu tiên CORPL sử dụng chuyển tiếp cơ hội để chuyển
tiếp gói tin bằng cách chọn nhiều node chuyển tiếp (forwarder set) và việc chọn
tuyến đƣờng tốt nhất dựa vào cơ chế best-next-hop. DODODAG đƣợc xây dựng
theo cùng cách với RPL. Mỗi node duy trì một bộ chuyển tiếp, khi có sự thay đổi
những node này sẽ cập nhật lại với các node hàng xóm của nó bằng bản tin DIO.
Dựa trên thông tin cập nhật, mỗi node tự động cập nhật các ƣu tiên hàng xóm của
mình để xây dựng bộ forwarder.
1.2.4. Tầng Transport (vận chuyển)
UDP (User Datagram Protocol) cũng giống nhƣ TCP, nó là một tầng trên của
tầng IP trong mô hình chồng giao thức. Trong khi TCP là một giao thức
connection-oriented, UDP không hoạt động theo cách đó. UDP không mang lại
sự tin cậy và thứ tự các phân đoạn nhƣ TCP, các gói dữ liệu có thể đến không
đúng thứ tự hoặc bị mất mà không có phản hồi nào. Để gửi dữ liệu, ứng dụng chỉ
đơn giản cần đƣợc cung cấp IP của đích và số cổng, sau đó dữ liệu đƣợc gửi đi
một cách dễ dàng. Để nhận dữ liệu UDP, ứng dụng chỉ cần lắng nghe một cổng
cụ thể. Nhƣng bù lại, UDP là một giao thức truyền tải nhẹ hơn, nhan hơn so với
TCP, thích hợp với môi trƣờng hạn chế của các thiết bị cảm ứng.
1.2.5. Tầng Application (ứng dụng)
CoAP (Constrained Application Protocol) là giao thức ràng buộc ứng dụng
của tập đoàn CoRE (Constrained Resource Environments) IETF. Giống nhƣ
HTTP. CoAP là một giao thức truyền tải tài liệu. Không giống nhƣ HTTP, CoAP
đƣợc thiết kế cho nhu cầu các thiết bị ràng buộc. Các gói CoAP nhỏ hơn nhiều so
với HTTP TCP. Các gói rất đơn giản có thể đƣợc tạo ra và phân tích tại chỗ mà
không tốn thêm RAM trong các thiết bị bị hạn chế. CoAP chạy trên UDP, không
chạy trên TCP. Client và máy chủ giao tiếp thông qua các gói kết nối. Việc loại
bỏ TCP cho phép kết nối mạng IP đầy đủ trên các vi điều khiển nhỏ. CoAP cho
phép phƣơng thức gửi UDP broadcast và multicast. CoAP theo mô hình
client/server. Client gửi các yêu cầu đến máy chủ, máy chủ gửi lại phản hồi.

Client có thể Get, Put, Post và Delete các tài nguyên. CoAP đƣợc thiết kế để
tƣơng thích với HTTP và các web REDful rộng lớn thông qua các proxy đơn
giản. Bởi vì CoAP dựa trên cơ sở gói dữ liệu datagram, nó có thể đƣợc dùng ở
đầu bản tin và các giao thức truyền dữ liệu gói khác.
1.3. Một số giao thức định tuyến trong IoT
1.3.1. AOMDV-IoT
AOMDV-IoT (Ad-hoc on demand multipath Distance Vector routing
protocol for IoT) là giao thức tạo ra kết nối giữa các node internal (không có kết
nối với internet) với các node external (có kết nối internet). Mọi node sẽ chứa hai
bản định tuyến, bản định tuyến kết nối internet ICT (Internet Connecting Table)
và bảng định tuyến của chính nó. Việc chứa cả hai bản định tuyến dẫn đến một
chút dƣ thừa cho bộ nhớ của các node. Khi một node có ý định thiết lập kết nối
internet, nó sẽ có địa chỉ IP của đích đến nhƣ là một liên kết internet ILA
(Internet Link Address). Tiếp theo nó sẽ tìm kiếm bên trong bảng định tuyến ICT
để tìm ra node có kết nối internet. Nếu trong bản định tuyến ICT có chứa node
phù hợp thì địa chỉ ILA này sẽ đƣợc thay thế bằng địa chỉa IP của node đích. Nếu
không, node nguồn sẽ phát bản tin RREQ (Route Request) làm mới nội dung của
bản định tuyến và các bảng ICT. Đây là giao thức bị động tìm kiếm con đƣờng
theo yêu cầu. Giao thức đó sử dụng bốn loại thông điệp sau trong quá trình giao
tiếp:
- RREQ: để tìm kiếm lộ trình điểm đến
- RREP (Route Reply): node đích gửi RREP đến node nguồn để phản hồi
lại thông điệp RREQ, giống nhƣ thông điệp ACK
- RERR (Route Error): bản tin đƣợc gửi từ các node trong mạng tới các
node hàng xóm khi tuyến đƣờng định tuyến của nó không còn khả dụng
- HELLO: định kì đƣợc gửi từ các node trong mạng tới các node hàng xóm
của nó để quảng bá sự tồn tại của node đó
Ƣu điểm của AOMDV-IoT
- Định tuyến đa điểm

- Chất lƣợng liên kết tốt
Nhƣợc điểm của AOMDV-IoT
- Không có cơ chế an toàn trong định tuyến dữ liệu
- Giao thức không hỗ trợ bối cảnh, không tối ƣu hóa các tuyến đƣờng định
tuyến dựa theo năng lƣợng còn lại trong node
- Sử dụng thuật toán định tuyến distance vector đó là định tuyến dữ liệu dựa
theo số hop tối thiểu
1.3.2. SMRP
SMRP (Secure Multihop Routing Protocol) là giao thức tập trung vào bảo mật
dữ liệu bằng cách ngăn chặn các cuộc tấn công độc hại. Trong giao thức này các
đơn vị sở hữu của từng mạng lƣới IoT phải đăng ký ứng dụng, địa chỉ mạng và
địa chỉ liên kết dữ liệu của riêng họ cho nhà cung cấp dịch vụ hợp pháp. Dựa
theo các thông tin đăng ký, trƣớc khi tạo mạng lƣới, nhiệm vụ của nhà cung cấp
dịch vụ là tạo lập một file mã hóa và cài đặt nó cho mọi thiết bị cá nhân.
Tƣơng tự nhƣ các giao thức định tuyến khác, các thiêt bị IoT phát ra thông
điệp HELLO sau mỗi khoảng thời gian bằng nhau. Khi mội thiết bị (tb1) đi vào
vùng phát sóng của thiết bị khác (tb2), đoạn đầu của thông điệp HELLO nhận
đƣợc từ tb2 sẽ đƣợc so sánh với đoàn đầu của thông điệp HELLO của tb2. Nếu
trùng khớp nhau thì các thiết bị sẽ giao tiếp, không trùng khớp sẽ không giao
tiếp.
Nếu thiết bị x (tbx) muốn kết nối tới một mạng IoT, nó sẽ gửi đề nghị tới thiết
bị y (tby). Sao đó tby kiểm tra địa chỉ mạng và địa chỉ liên kết dữ liệu của tbx
trên file mã hóa đối với danh sách các thiết bị cho phép. Nếu tbx đƣợc cho phép
tham gia mạng và các ứng dụng đang chạy trên nó trùng với các ứng dụng chạy
trên tby. Một khi bộ định thời đƣợc đồng bộ với tất cả các thiết bị IoT đạt tới giá
trị đƣợc gán trƣớc, nó kích hoạt module xáo trộn để thay đổi chuỗi các bit đã đặt
trƣớc để tăng cƣờng an ninh
Ƣu điểm của SMRP
- Là giao thức đa điểm

- Cung cấp mức độ bảo mật tốt cho dữ liệu trƣớc các cuộc tấn công độc hại,
bảo mật đƣợc tăng cƣờng bằng cách xáo trộn các chuỗi bit đã đặt trƣớc
trong thông điệp HELLO
Nhƣợc điểm của SMRP
- Không là giao thức nhận thức bối cảnh. Nó không bảo tồn năng lƣợng của
các node khi đang định tuyến. Nó có thể gây ra việc tiêu tốn tài nguyên
của mạng
- Yêu cầu bộ nhớ cao hơn khi cần lƣu trữ file mã hóa trên mọi thiết bị và về
sau có thể tạo ra rào cản trong vấn đề mở rộng mạng lƣới. Bởi vì nếu có ít
thiết bị hơn trong mạng IoT, file mã hóa cũng phải có kích thƣớc nhỏ hơn
và ngƣợc lại
- Số lƣợng thiết bị trong mạng IoT thuộc về một đơn vị sở hữu cụ thể, cần
đƣợc thông báo trƣớc khi thiết lập mạng lƣới thực tế.
1.3.3. PAIR
PAIR (Pruned Adaptive IoT Routing) là giao thức cung cấp một mô hình định
giá giúp cho các node có một số lợi ích về giá trị khi nó tận dụng nguồn tài
nguyên của nó để chuyển tiếp. Mô hình định giá của giao thức PAIR đƣợc dựa
vào các thông số sau tại mỗi node
- Năng lƣợng còn lại và mức tiêu hao
- Lặng tải hiện tại và khoảng trống bộ nhớ tạm
- Khoảng cách tới các node hàng xóm của nó
PAIR hoạt động theo hai giai đoạn: tiến và lùi. Trong giai đoạn tiến, thông
điệp cài đặt (chứa chi phí từ nó tới các node khác) đƣợc phát đi từ node nguồn tới
tất cả các node hàng xóm của nó. Khi các node hàng xóm nhận đƣợc thông điệp
đến node đích. Node đích gửi thông điệp xác nhận (ACK) theo lộ trình đƣợc lựa
chọn tốt nhất dựa theo các giá trị đƣợc thu thập của các thông số chi phí từ thông
điệp cài đặt
Nếu thông điệp xác nhận gặp sự gián đoạn trong lộ trình của nó tại node I nào
đó, thì nó sẽ đƣợc chuyển đổi thành thông điệp cài đặt (đƣợc gọi là I_setup) và

đƣợc chuyển tiếp tới các hàng xóm của I với mục đích tìm kiếm tuyến đƣờng.
Sau khi thấy thông điệp I_setup, lộ trình chủ động đƣợc xây dựng giữa nguồn và
điểm đến và vận chuyển dữ liệu có thể đƣợc bắt đầu
Ƣu điểm của PAIR
- Là giao thức định tuyến đa điểm và nhận thức bối cảnh
- Giúp giải quyết vấn đề kết hợp giữa các node của các mạng không đồng
nhất
Nhƣợc điểm của PAIR
- Bảo mật dữ liệu kém
- Yêu cầu bộ nhớ có thể cao vì nó phải tạm lƣu dữ liệu trên node chuyển
tiếp hiện tại để tìm một lô trình thay thế khi bị mất liên kết
1.3.4. REL
Giao thức REL (Routing protocol based on Energy and Link Quality) sử dụng
hai tham số: chất lƣợng liên kết của các liên kết không dây và năng lƣợng còn lại
để lựa chọn tuyến đƣờng tối ƣu nhất
Phân tích một liên kết đơn, REL dựa vào các công cụ xác định chất lƣợng liên
kết LQI (Link Quality Indicator). Hệ đo lƣờng này đƣợc cung cấp bởi lớp vật lý
của tiêu chuẩn IEEE 802.15.4. REL lƣu trữ n tuyến đƣờng khả thi tiến đến điểm
đến và lựa chọn một tuyến đƣờng dựa trên các tiêu chí sau:
- Chất lƣợng của các liên kết không dây dựa theo hệ đô lƣờng các liên kết
yếu
- Năng lƣợng còn lại
- Số hop để tránh các lộ trình dài và không hiệu quả
Quá trình lựa chọn lộ trình dựa vào hai ngƣỡng: ngƣỡng số lƣợng hop lớn
nhất cho phép Hcdiff và ngƣỡng năng lƣợng Eth. Ngƣỡng năng lƣợng đƣợc sử
dụng trong việc lựa chọn tuyến đƣờng bằng cơ chế cân bằng tải. Trong trƣờng
hợp tối ƣu hóa cân bằng tải, Eth trao đổi sự điều phối của các mức năng lƣợng tại
từng node. Nó tính toán sự khác biệt giữa mức năng lƣợng hiện tại E(t) và mức
năng lƣợng tại thời điểm E (t - 1) trƣớc đó. Nếu sự khác biệt giữa chúng lớn hơn

Eth thì nó sẽ gửi bản tin thông báo về giá trị mới có của nó tới các node hàng
xóm, qua đó các node hàng xóm sẽ cân nhắc việc sử dụng tuyến đƣờng này. Các
giá trị Eth thấp cho thấy mức tiêu hao năng lƣợng đồng đều trong khi giá trị cao
cho thấy sự khác biệt lớn trong việc tiêu hao năng lƣợng của các node.
Ƣu điểm của REL
- Đánh giá chất lƣợng liên kết trƣớc khi lựa chọn tuyến đƣờng cho định
tuyến
- Chất lƣợng liên kết tốt hơn đồng nghĩa với với khả năng vận chuyển thông
tin thành công hơn, giúp tích kiệm nhiều năng lƣợng hơn bằng cách giảm
số lƣợng khối thông tin phải truyền tải, dẫn tới sự tối đa hóa tuổi thọ của
mạng lƣới
- Cơ chế cân bằng tải tránh việc sử dụng quá đà của một lộ trình hoặc một
node, có thể giúp nhiều trong việc giảm bớt các điểm nóng hoặc các lỗ
hổng năng lƣợng trong mạng lƣới dẫn tới tận dụng năng lƣợng đồng đều
hơn trong toàn mạng
Nhƣợc điểm của REL
- Cơ chế bảo mật kém
1.3.5. RPL
Giao thức RPL (Routing Protocol for Low Power and Lossy Network) sẽ
đƣợc trình bày tại Chƣơng 2 của luận văn này.
1.3.6. Kết luận
Bảng dƣới liệt kê, so sánh một số thông số giữa các giao thức trong IoT đƣợc
nêu phần trên.
Nhận thức Định tuyến Hỗ trợ cấu trúc Chất lƣợng
Giao thức Bảo mật
bối cảnh đa điểm liên kết động liên kết
AOMDV- Không Không Có Tốt
IoT
SMRP Không Có Có Tốt
PAIR Có Không Có Có Tốt
REL Có Không Có Kém
RPL Có Có Có Có Tốt
Bảng 1.4. So sánh giữa các giao thức

Dựa vào bảng 1.4 đƣa ra sự so sánh các thông số, tính năng của một số giao
thức định tuyến trong IoT có thể nói giao thức RPL là giao thức hỗ trợ nhiều tính
năng nhất từ việc nhận thức bối cảnh, bảo mật, định tuyến đa điểm, hỗ trợ cấu
trúc liên kết động cho đến việc chất lƣợng liên kết tốt. Bên cạnh đó giao thức
RPL còn có một số ƣu điểm khác đƣợc nêu cụ thể ở chƣơng 2 của luận văn này
nhƣ: có khả năng mở rộng (số lƣợng, quy mô), hỗ trợ tính di động, có cấu trúc
mạng động, hỗ trợ định tuyến theo nhiều metric khác nhau, dùng đƣợc trong
mạng cảm biến nguồn thấp, chi phí rẻ, kết hợp với 6LowPan có cơ chết nén
header hiệu quả. . .
Đặc biệt hơn là giao thức RPL đƣợc đƣa ra và phát triển bởi tổ chức uy tín
IETF và đƣợc sự quan tâm của các tổ chức lớn, có các công cụ mô phỏng, đánh
giá đƣợc cộng đồng quốc tế phát triển. Qua đó có thể thấy đƣợc RPL là giao thức
hứa hẹn sẽ phát triển mạnh và có tiềm năng lớn cho việc định tuyến trong IoT.

CHƢƠNG 2: TỔNG QUAN VỀ RPL, CONTIKI RPL VÀ HOẠT ĐỘNG
CỦA RPL TRÊN CONTIKI
2.1. Tổng quan về RPL
RPL là giao thức định tuyến cho mạng tổn hao năng lƣợng thấp nói chung và
IoT nói riêng. Dự thảo đầu tiên về RPL đƣợc IETF đƣa ra vào tháng 8/2009.
Hiện nay, giao thức RPL đang trong quá trình dần hoàn thiện, với mục tiêu phát
triển thành một chuẩn định tuyến trong tƣơng lai. Quá trình phát triển RPL cũng
nhận đƣợc sự quan tâm, đóng góp của nhiều tổ chức, cá nhân đến từ những tổ
chức nghiên cứu khoa học, các trƣờng đại học, viện nghiên cứu trên toàn thế
giới.
Theo nguồn [7], [8] và [9] RPL đƣợc phát triển trên nền IPv6 nhằm đạt đƣợc
những yêu cầu định tuyến sau:
- Có khả năng mở rộng (số lƣợng, quy mô).
- Định tuyến dựa trên những thông số bị giới hạn nhƣ mức năng lƣợng,
dung lƣợng bộ nhớ.
- Hỗ trợ tính di động.
- Hỗ trợ khả năng tự cấu hình và cấu hình từ bên ngoài.
- Hỗ trợ truyền tin multicast và anycast.
- Hỗ trợ các luồng thông tin định hƣớng đến một node trong mạng.
- Có cấu trúc mạng động.
- Hỗ trợ định tuyến theo nhiều metric khác nhau.
- Có khả năng hội tụ về thời gian. Giao thức định tuyến có tính hội tụ về
thời gian khi nó đáp ứng đƣợc những mức thời gian trễ cụ thể tƣơng ứng
với những điều kiện xác định.
- Có khả năng quản lý. Khi một node mới tham gia vào mạng, node đó phải
tự động cấu hình và tham gia vào mạng mà không cần sự can thiệp của
con ngƣời.
- Hỗ trợ truyền gói theo mức độ ƣu tiên và có độ tin cậy cao.
- Hỗ trợ các phƣơng thức bảo mật.

2.1.1. Khái niệm, thuật ngữ sử dụng trong RPL
RPL xây dựng và sử dụng các DAG (Directed Acyclic Graph) trong mạng để
thực hiện quá trình định tuyến. Trong đó, DAG là một cấu trúc 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.
DAG Root: 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 DAG 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.
DODAG (Destination-Oriented DAG) là một DAG chỉ có một node đích, ví
dụ nhƣ chỉ có một DAG root (trong trƣờng hợp này gọi là DODAG root)
Hình 2.1. Mô hình RPL DODAG

DODAG root: một DODAG root là DAG root của một DODAG. DODAG
root có thể là router biên cua một DODAG

Virtual DODAG root: Một DODAG root ảo là kết quả của hai hoặc nhiều bộ
định tuyến RPL, điều phối để đồng bộ hóa DODAG state và diễn ra nhƣ thể
chúng là một DODAG root duy nhất
DODAGID (DODAG Identifier): mã nhận dạng của mỗi DODAG root trong
mạng. Tất cả các node trong mạng đều lƣu DODAGID của DODAG mà nó là
thành viên.
DODAG Rank: là thông số cho biết vị trí tƣơng đối của node so với DODAG
root. Những node càng xa DODAG root thì có rank càng cao. Rank của node có
thể đƣợc tính thông qua khoảng cách hình học giữa node và DODAG root, hoặc
có thể đƣợc tính toán thông qua những hàm chức năng khác. Trong RPL,
DODAG root luôn có rank bằng 1. Rank đƣợc sử dụng để đánh giá mối quan hệ
parent-sibling-children giữa các node trong cùng một DODAG, từ đó tránh các
vòng lặp có thể xảy ra khi truyền gói đến DODAG root. Hình 2.1 cho thấy rank
của các node trong DODAG khi rank đƣợc tính bằng số chặng (hop) tối thiểu đến
DODAG root.
DODAG Parent: trong cùng một DODAG, node A đƣợc gọi là parent của
node B khi A có khả năng kết nối trực tiếp đến B và A có rank thấp hơn B. Khi
đó A có thể đóng vai trò là next-hop của B trong quá trình truyền gói về DODAG
root và B là một node children của A.
DODAG Sibling: node A là một sibling của node B trong một DODAG nếu
chúng có cùng rank trong DODAG đó. Ví dụ, trong hình 2.1, các node (3.2) và
(3.4) là sibling của node (3.3); mặt khác, node (3.3) nhận các node (2.1), (2.2),
(2.3) là các parent.
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 DODAG phù hợp, tính toán rank và lựa chọn các parent
trong DODAG. 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.

Object Code Point (OCP): là mã nhận dạng tƣơng ứng với một OF cụ thể.
OCP đƣợc sử dụng trong quá trình kiểm tra các bản tin trong mạng và quá trình
tìm kiếm những DODAG phù hợp.
RPL Instance: là một tập hợp gồm một hoặc nhiều DODAG có cơ chế định
tuyến giống nhau. Mỗi instance chỉ sử dụng một OF duy nhất để xây dựng cấu
trúc mạng.
RPL Instance ID: mã nhận dạng của các Instance, tƣơng ứng với các OF cụ
thể.
DODAG 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 DODAG. Khi một DODAG root muốn xây dựng lại
một DODAG 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.
Hình 2.2. RPL instance và DODAG sequence number

DODAG Interaction: mỗi DODAG ID và DODAG sequence number cho
phép xác định một DODAG interaction. Khái niệm này cho phép mỗi node trong
mạng phân biệt các DODAG mà node đã tham gia với một DODAG mà node

chƣa từng là thành viên. Đồng thời khái niệm DODAG interaction cũng cho phép
cơ chế tránh các vòng lặp hoạt động hiệu quả hơn.
Trong RPL đề cập đến hai hƣớng định tuyến: upward và downward. Upward
là chiều đi từ các node ở xa DODAG root hƣớng về DODAG root. Downward là
chiều ngƣợc lại, hƣớng từ DODAG root đến các node ở xa hơn.
RPL Goal: là một host hoặc một tập hợp gồm nhiều host có khả năng đáp ứng
đƣợc các OF, phục vụ việc tập trung dữ liệu từ các DODAG hoặc tạo kết nối
giữa các DODAG với các mạng và ứng dụng ngoài.
DODAG Grounded: một DODAG gọi là grounded nếu DODAG root có khả
năng giao tiếp với một Goal thích hợp.
DODAG Floating: một DODAG gọi là là trôi nổi khi không thể chuyển dữ
liệu hoặc kết nối đến một Goal phù hợp.
RPL sử dụng ba loại bản tin điều khiển gồm DODAG Information
Solicitation (DIS), DODAG Information Object (DIO), Destination
Advertisement Object (DAO) để quảng bá các thông tin định tuyến trong mạng.
DIO là bản tin mang thông tin về DODAG, đƣợc gửi từ các parent đến các node
children và đƣợc sử dụng để xây dựng DODAG. DIS chỉ thực hiện nhiệm vụ
quảng bá sự xuất hiện của node và yêu cầu những node khác phản hồi bằng các
bản tin DIO. DAO là bản tin đƣợc gửi từ một children đến các parent nhằm
quảng bá khả năng tham gia định tuyến theo chiều downward của các node trong
mạng.
2.1.2. Các bản tin điều khiển trong RPL
Giao thức RPL sử dụng ba loại thông điệp điều khiển để xây dựng và duy trì
các DODAG trong mạng, bao gồm: DIS (DODAG Information Solicitation),
DIO (DODAG Information Object – bản tin quảng bá DODAG), DAO
(Destination Advertisement Object – bản tin quảng bá đích).
Qua quá trình gửi-nhận và xử lý các bản tin ICMP, mỗi node có thể quản lý
thông tin các node hàng xóm của nó trong phạm vi kết nối, đƣa ra quyết định

tham gia vào DODAG phù hợp, lựa chọn các parent, sibling, xác định next-hop
và gửi gói đến DODAG root.
Hình 2.3. Cấu trúc bản tin điều khiển RPL

Trƣờng Type của các bản tin RPL-ICMP đƣợc quy định bằng 155, sử dụng để
phân biệt bản tin RPL-ICMP với bản tin của các giao thức khác. Trƣờng Code
đƣợc sử dụng để phân biệt các bản tin RPL-ICMP và đƣợc định nghĩa nhƣ sau:
- Code = 0x01: DODAG Information Solicitation (DIS).
- Code = 0x02: DODAG Information Object (DIO).
- Code = 0x04: Destination Advertisement Object (DAO).
RPL sử dụng các bộ định thời để quản lý tốc độ gửi và số lƣợng bản tin ICMP
trong mạng. Những bộ định thời này hoạt động kết hợp giữa chế độ định thời và
chế độ sự kiện. Do đó, không những làm giảm số lƣợng những bản tin ICMP mà
vẫn đảm bảo tính linh động của mạng.
2.1.3. Bản tin DIS
Bản tin DIS đƣợc gửi từ những node tự do trong mạng nhằm quảng bá sự
xuất hiện của node, thăm dò sự xuất hiện của các node hàng xóm và yêu cầu
những node khác phản hổi bằng các bản tin DIO. Bản tin DIS đƣợc gửi multicast
khi node ở trạng thái tự do và đƣợc gửi unicast đến một parent trong DODAG
khi muốn nhận lại một bản tin unicast DIO nhằm cập nhật các thông tin DODAG
của parent đó.
Hình 2.4. Cấu trúc bản tin DIS

Trƣờng Instance ID cho biết instance mà node gửi DIS tham gia định tuyến.
Khi một node trong mạng nhận đƣợc một bản tin DIS, nó chỉ gửi lại bản tin DIO
phản hồi khi có khả năng định tuyến cho Instance ID đó. Nhờ đó, khi triển khai
mạng có nhiều instance, có thể giảm đáng kể số lƣợng bản tin điều khiển trong
mạng, tiết kiệm năng lƣợng và thời gian xử lý của các node.
2.1.4. Bản tin DIO
DIO là bản tin đƣợc tạo ra tại các DODAG root, mang những thông tin định
tuyến của DODAG nhƣ instance, rank, metric, . . . DIO đƣợc sử dụng để quảng
bá các thông tin định tuyến của một DODAG xác định trong mạng, phục vụ quá
trình xây dựng DODAG và định tuyến upward. Quá trình nhận và xử lý bản tin
DIO cho phép một node nhận diện và tham gia vào DODAG phù hợp. Từ đó lựa
chọn các parent, xác định các thông số cấu hình và tiếp tục quảng bá thông tin
DODAG đến các node khác trong mạng.
2.1.4.1. Cấu trúc bản tin DIO
Cấu trúc của một bản tin DIO gồm hai phần chính: các trƣờng điều khiển và
các sub-option
Hình 2.5. Cấu trúc bản tin DIO

Các trƣờng điều khiển gồm các cờ trạng thái và các thông số phục vụ cho quá
trình xây dựng DODAG:
- Cờ G (grounded): cho phép xác định khả năng kết nối đến một grounded
DODAG của node gửi DIO. Nếu cờ G bằng 0, node gửi DIO là thành viên
của một floating DODAG. Ngƣợc lại, nếu cờ này khác 0 cho biết node gửi
DIO là thành viên của một grounded DODAG.

- Cờ A (Destination Advertisement Supported): cho biết khả năng hỗ trợ cơ
chế quảng bá đích trong quá trình định tuyến downward của DODAG.
Nếu A khác 0, DODAG root có khả năng hỗ trợ cơ chế quảng bá đích và
các node trong DODAG có thể tham gia quá trình định tuyến downward.
Nếu A bằng 0, các node trong DODAG chỉ có thể tham gia định tuyến
upward.
- Cờ T (Destination Advertisement Trigger): đƣợc sử dụng để làm mới quá
trình định tuyến downward. Nếu T bằng 0, quá trình định tuyến downward
hoạt động bình thƣờng. Khi T khác 0, các node trong DODAG sẽ thực
hiện quá trình làm mới các tuyến downward.
- Cờ S (Destination Advertisement Stored): nếu cờ S bằng 0, chỉ DODAG
root đƣợc phép lƣu các thông tin định tuyến downward từ các bản tin
DAO. Nếu S khác 0, node gửi DIO có thể lƣu các thông tin định tuyến từ
DAO.
- Trƣờng prf (DODAG preference): sử dụng 3 bit kiểu số nguyên dƣơng
cho biết độ ƣu tiên giữa các DODAG root trong cùng một Instance. Miền
giá trị của prf từ 0x00 đến 0x07. Nếu prf bằng 0x07, DODAG root sẽ có
độ ƣu tiên cao nhất, giá trị mặc định của prf là 0.
- Sequence number: sử dụng 8-bit kiểu số dƣơng là giá trị sequence number
đƣợc thiết lập tại DODAG root, đƣợc sử dụng trong quá trình tái xây dựng
DODAG.
- Rank: rank của node gửi DIO.
- RPL Instance: cho biết RPL Instance mà DODAG tham gia định tuyến.
- Destination Advertisement Trigger Sequence Number (DTSN): đƣợc thiết
lập tại node phát ra bản tin DIO, sử dụng trong quá trình duy trì các thông
số định tuyến theo hƣớng downward.
- DODAGID: là một địa chỉ Ipv6 có độ dài 128 bit và đƣợc thiết lập tại
DODAG root.
2.1.4.2. Các luật của bản tin DIO

- Nếu cờ A của bản tin DIO bằng 0 thì cờ T cũng phải bằng 0
- Đối với cờ G, A, T, trƣờng Prf, Sequence, RPLInstanceID, DODAID, nếu
nhƣ node không phải là DODAG root thì cần phải quảng bá các giá trị
giống với node parent của nó. Chình vì vậy nếu nhƣ DODAG root mà
không thay các giá trị trên thì tất cả cá node cũng phải quảng bá các giá trị
nhƣ vậy.
- Một node có thể cập nhập cờ S, trƣờng Rank và DTSN tại mỗi bƣớc nhẩy
- Trƣờng DODAGID của mỗi DODAG root phải là duy nhất trong một
instance
2.1.4.3. Cấu trúc sub-option trong DIO
Các sub-option trong DIO bao gồm năm loại: Pad 1, Pad N, DODAG Metric
Container, DODAG destination prefix, DODAG Configuration. Tùy theo mục
đích sử dụng, các sub-option đƣợc chèn vào cấu trúc DIO một cách hợp lý.
Cấu trúc chung của các sub-option, gồm 3 phần:
- Type: 1 byte, dùng để phân biệt các sub–option.
- Length: 2 bytes, cho biết chiều dài sub–option.
- DATA: chiều dài thay đổi, lƣu các thông tin của sub–option.
Hình 2.6. Cấu trúc sub-option

Pad 1: có cấu trúc chỉ gồm 1 byte có type bằng không, đƣợc sử dụng nhằm
chèn một hoặc hai byte trống vào bản tin DIO.
Hình 2.7. Cấu trúc DIO – Pad 1

Pad N: đƣợc sử dụng nhằm chèn N byte trống vào bản tin DIO.

Hình 2.8. Cấu trúc DIO – Pad N
Metric Container đƣợc sử dụng để lƣu trữ thông tin các Metric đƣợc hỗ trợ
trong DODAG. Metric container có thể bao gồm một số các metric nhƣ thông số
liên kết, băng thông, độ trễ, các thông số về tuyến đƣờng, . . . Quá trình xử lý và
quảng bá các thông tin trong Metric container tuân theo các OF cụ thể đƣợc thiết
kế trong quá trình triển khai.
Hình 2.9. Cấu trúc DIO-metric container

Destination prefix: là sub-option đƣợc sử dụng để theo dõi khả năng kết nối
đến một nhóm các node trong mạng thông qua DODAG root hoặc qua một
parent nằm gần DODAG root của nhóm node mạng đó. Sự theo dõi trở lên hữu
ích khi trong mạng có nhiều hơn một DODAG root và đáp ứng các ứng dụng
khác nhau. Khi đó, nhờ quá trình theo dõi các destination prefix đƣợc cung cấp
bởi các DODAG, một node có thể đƣa ra các quyết định tham gia vào nhiều
DODAG khác nhau, nhằm đáp ứng các mục đích riêng biệt. Nếu trong một bản
tin DIO cần theo dõi khả năng kết nối đến nhiều đích khác nhau, các trƣờng
destination prefix có thể đƣợc lặp lại để lƣu các thông tin đó.

Hình 2.10. Cấu trúc DIO – Destination Prefix
DAD Configuration là sub-option mang các thông tin phục vụ các quá trình
cấu hình trong DODAG. Các thông tin này đƣợc tạo ra tại DODAG root và
không bị thay đổi tại các node khác trong DODAG.
Hình 2.11. Cấu trúc DODAG Configuration

Các trƣờng DIO Interval Min, DIO Interval Doubling đƣợc sử dụng để cấu
hình các bộ định thời quản lý việc gửi các bản tin DIO trong DODAG.
Các trƣờng Max Rank Inc và Min Hop Rank Inc đƣợc sử dụng để cung cấp
các miền giới hạn về rank khi các node trong DODAG tính toán và thiết lập rank.
2.1.4.4. Bộ định thời DIO
Vấn đề quảng bá các bản tin DIO là vấn đề quan trọng nhất trong quá trình
triển khai và xây dựng DODAG. Do đó, mỗi node trong mạng luôn duy trì một
bộ định thời quản lý tốc độ quảng bá các bản tin DIO đến các node khác trong
mạng.
Mỗi bộ định thời DIO luôn duy trì các thông số:
- I (Current Interval): Khoảng thời gian hiện hành đƣợc sử dụng trong việc
xác định khoảng thời gian định thời cho DIO.
- T (Timer): khoảng thời gian định thời có giá trị ngẫu nhiên trong khoảng
[I/2; I].

- C (Counter): bộ đếm đƣợc sử dụng trong cơ chế quản lý các bản tin DIO
dƣ thừa, nhƣ các bản tin DIO đƣợc quảng bá từ các node có cùng rank
hoặc từ những node có rank cao hơn. Cơ chế này làm giảm số lƣợng bản
tin phải xử lý và giảm dƣ thừa thông tin.
- I-min: khoảng thời gian định thời nhỏ nhất đƣợc tính bằng mili giây (ms).
Giá trị này đƣợc quy định bởi các DODAG root và bằng lũy thừa cơ số
hai của thông số DIO Interval Min trong bản tin DIO gửi từ DODAG root.
- I-doublings: số lần giá trị I đƣợc phép tăng gấp đôi trƣớc khi đƣợc thiết
lập lại giá trị ban đầu.
Khi một node tham gia vào một DODAG, node sẽ thực hiện việc kích hoạt bộ
định thời DIO để quản lý tốc độ quảng bá các bản tin DIO tới những node xung
quanh.
Các thông số khởi tạo đƣợc thiết lập chung cho toàn DODAG nhƣ sau:
- I-min và I-doubling bằng các giá trị tạo bởi DODAG root.
- C đƣợc thiết lập bằng 0.
- I thiết lập bằng I-min.
- T đƣợc chọn ngẫu nhiên trong khoảng [I/2; I].
Sau mỗi lần gửi DIO, bộ định thời DIO tự động nhân đôi khoảng thời gian I
và lựa chọn một thời gian định thời T mới thuộc khoảng [I/2; I].
Khi bộ định thời DIO đƣợc khởi động lại, các giá trị định thời đƣợc đƣa về
giá trị khởi tạo mặc định trong DODAG.
Bộ định thời DIO đƣợc reset trong các trƣờng hợp sau:
- Khi node tìm thấy một thay đổi có ảnh hƣởng đến vị trí của node trong
DODAG:
 Khi node tham gia vào một DODAG mới trong mạng.
 Khi node thay đổi rank trong DODAG.
 Khi node nhận đƣợc một bản tin DIO từ một parent có sự thay đổi
về rank, DODAG.

 Khi node nhận đƣợc một gói dữ liệu từ một parent và các xung đột
trong quá trình truyền gói.
- Khi node nhận một bản tin multicast DIS.
- Khi node di chuyển từ DODAG này sang DODAG khác.
2.1.4.5. Nhận và xử lý bản tin DIO
DIO đầu tiên đƣợc tạo ra tại DODAG root, sau đó đƣợc quảng bá đến các
node khác trong mạng. Các node thành viên trong DODAG sử dụng các bản tin
DIO nhận đƣợc để cập nhật thông tin DODAG, lựa chọn parent và quảng bá vị trí
của nó trong DODAG.
Các phƣơng thức xử lý DIO phải tuân theo những nguyên tắc sau:
- Một node chỉ tạo và gửi bản tin DIO sau khi tham gia một DODAG xác
định.
- Những node không phải DODAG root, chỉ đƣợc phép thay đổi giá trị các
cờ điều khiển S (Destination Advertisements Stored), DTSN và DODAG
rank trong bản tin DIO nhận đƣợc từ DODAG root.
- DIO là hợp lệ nếu có Instance ID đƣợc đáp ứng.
Khi một node nhận đƣợc một bản tin DIO từ trong mạng, node phải thực hiện
kiểm tra tính hợp lệ của DIO đó. Nếu bản tin DIO đƣợc đáp ứng, node mới tiếp
tục thực hiện những hành động tiếp theo.
2.1.5. Bản tin DAO
DAO là bản tin đƣợc sử dụng để quảng bá thông tin của các đích, đƣợc gửi từ
những node có rank cao hơn đến những node có rank thấp hơn dọc theo
DODAG. DAO đƣợc sử dụng nhằm phục vụ cho những ứng dụng đòi hỏi luồng
lƣu lƣợng kiểu P2MP và P2P. Thông qua việc xử lý thông tin của những bản tin
DIO nhận đƣợc, DODAG root và những node ở gần root có thể quản lý, cập nhật
thông tin của những node nằm ở những rank cao hơn trong DODAG. Từ đó, có
thể đƣa ra những giải pháp định tuyến theo hƣớng downward. Do nội dung luận
văn chủ yếu tập trung nghiên cứu quá trình xây dựng DODAG và đánh giá khả

năng định tuyến upward của giao thức, nên luận văn chỉ đƣa ra những khái niệm
cơ bản về DAO và quá trình định tuyến downward.
2.1.5.1. Cấu trúc bản tin DAO
Hình 2.12. Cấu trúc bản tin DAO

Cấu trúc DAO gồm các trƣờng sau:
- DAO sequence: số bản tin DAO đƣợc một node gửi vào mạng.
- DAO rank: rank của node tạo bản tin DAO.
- RPL Instance ID: Instance của node tham gia định tuyến.
- Route Tag: đƣợc sử dụng để cung cấp thứ tự ƣu tiên khi lƣu thông tin các
prefix.
- Prefix Length: chiều dài prefix.
- Rrcount: cho biết số mục trong Reverse Route Stack-ngăn xếp lƣu các
mục định tuyến theo hƣớng downward.
- DAO life time: thời gian sống hiệu lực của prefix, phục vụ cho việc xác
định khả năng kết nối đến prefix.
- Destination Prefix: là một trƣờng có chiều dài thay đổi, đƣợc sử dụng để
nhận dạng một địa chỉ đích, một prefix, hoặc một nhóm địa chỉ multicast
trong mạng.

- Reverse Route Stack: là trƣờng có chiều dài có thể thay đổi, đƣợc sử dụng
để lƣu thông tin của những địa chỉ prefix tham gia định tuyến. Khi một
node thêm vào Reverse Route Stack, prefix của node đƣợc thêm vào danh
sách, đồng thời tăng giá trị RRcount.
- Các sub-option đƣợc sử dụng nhằm mở rộng các thành phần của bản tin
DAO, tùy theo mục đích nghiên cứu và triển khai.
2.1.5.2. Truyền bản tin DAO
Các bản tin DAO đƣợc truyền từ các node ở rank cao đến các node ở rank
thấp theo chiều upward, nhằm quảng bá các trạng thái định tuyến downward cho
những prefix của những nhóm hoặc những Sub-DODAG bên trong DODAG. Cơ
chế định tuyến với DAO chỉ có thể hoạt động khi node đã tham gia ít nhất một
DODAG trong mạng.
Cơ chế định tuyến và sử dụng DAO có thể chỉ đƣợc sử dụng trong từng
DODAG, đƣợc quyết định bởi DODAG root. Việc nhận dạng cơ chế này đƣợc
xác định thông qua một số tham số cấu hình đƣợc tạo trong bản tin DIO truyền đi
từ DODAG root.
Khi cơ chế này đƣợc sử dụng, trong DODAG phải có ít nhất một số các node
có khả năng lƣu những thông tin từ DAO, bao gồm DODAG root. Khi cơ chế
này không đƣợc sử dụng, các node trong DODAG không đƣợc phép tạo và xử lý
các bản tin DAO.
Bản tin DAO đƣợc gửi từ node đến một hoặc một nhóm các DODAG parent
của node trong DODAG. Những node có khả năng tham gia định tuyến, thực
hiện lƣu các thông tin trạng thái lấy đƣợc từ Reverse Route Stack vào bảng định
tuyến. Mỗi mục trong bảng định tuyến cho biết những thông tin trạng thái của
các prefix nhƣ: địa chỉ Ipv6, địa chỉ Interface, DAO sequence, DAO rank, DAO
life time, … Nhờ đó, một node có thể xác định trạng thái của những prefix:
- CONNECTED: trạng thái của bản thân node.
- REACHABLE: trạng thái của một neighbor, gồm 2 trạng thái:

 Confirmed: neighbor đƣợc kích hoạt, đã đƣợc xác nhận và có khả
năng định tuyến.
 Pending: neighbor đƣợc kích hoạt, đang trong quá trình xác nhận,
tuy nhiên vẫn có thể sử dụng. Khi đó một bộ đếm Retry Counter
đƣợc sử dụng để kiểm tra trạng thái của node.
- UNREACHABLE: mục có trạng thái không thể kết nối và bị loại bỏ.
Thông qua việc quản lý trạng thái kết nối của các prefix đƣợc cập nhật bởi cơ
chế quảng bá đích, các node có rank thấp có thể xác định tuyến đƣờng kiểu
downward nhằm phục vụ cho những ứng dụng đòi hỏi giao tiếp kiểu point-to-
multipoint hoặc point-to-point.
2.1.6. Quá trình khởi tạo mạng
Khi triển khai một mạng RPL, mỗi RPL Instance đƣợc thiết lập với một hoặc
một số DODAG root. Các thông số định tuyến đƣợc thiết lập phù hợp với mục
đích triển khai. Những DODAG root tự động thiết lập rank bằng 1(Root RANK),
sau đó chúng định thời quảng bá các bản tin DIO đến những node xung quanh để
xây dựng DODAG của bản thân.
Trong pha khởi tạo, những node khác trong mạng có thể lựa chọn một trong
hai chế độ: hoặc chúng giữ trạng thái silent và không gửi bất kỳ bản tin DIO nào
cho đến khi chúng tham gia vào một DODAG xác định; hoặc ngay lập tức tự
thiết lập là DODAG root của một floating DODAG, sau đó gửi multicast các bản
tin DIO đến các node khác trong mạng.
Trong quá trình này, mỗi node cũng có thể gửi multicast DIS đến các node
xung quanh hoặc chờ nhận những bản tin DIO đƣợc gửi đến. Khi triển khai
mạng, cần thiết kế để các node trong mạng có khả năng đáp ứng đƣợc những cơ
chế trên. Điều đó giúp cho quá trình khởi tạo nhanh chóng và linh động hơn.
2.1.7. Quá trình định tuyến upward
Trong RPL, quá trình định tuyến upward có vai trò then chốt, quyết định tính
chất, hiệu năng hoạt động của mạng. Quá trình này dựa trên việc xử lý các bản
tin DIO, xây dựng, xác định và duy trì các DODAG, từ đó mỗi node trong

DODAG có thể xác định tuyến đƣờng tối ƣu để gửi dữ liệu về DODAG root một
cách nhanh chóng và hiệu quả.
2.1.7.1. DODAG parent và preferred parent
Trong RPL sử dụng ba khái niệm thể hiện mối quan hệ logic giữa các node
trong mạng, bao gồm: neighbor, DODAG parent và preferred parent. Trong đó
preferred parent của một node là một trong số những DODAG parent có các
thông số định tuyến tốt nhất. Phƣơng thức lựa chọn preferred parent đƣợc quy
định bởi các hàm OF. Preferred parent sẽ đƣợc chọn là next-hop trong quá trình
truyền gói.
2.1.7.2. Quản lý neighbor, khám phá DODAG và lựa chọn DODAG parent
Trong RPL, mỗi node trong mạng tìm kiếm và quản lý các node neighbor
[10]
trong phạm vi kết nối thông qua cơ chế “neighbor discovery in IPv6” . Theo
đó, mỗi node trong mạng sẽ quản lý đƣợc các thông số trạng thái của những node
xung quanh nhƣ khả năng kết nối, địa chỉ, tình trạng, …
Khi một node đƣợc khởi tạo với vai trò DODAG root, node sẽ thực hiện việc
tạo những bản tin DIO với rank bằng một và quảng bá chúng đến các node xung
quanh. Những node gần root nhất khi nhận đƣợc DIO từ DODAG root sẽ tham
gia vào DODAG, cập nhật thông tin trong DIO và xác định rank của bản thân
trong DODAG. Sau đó node định thời chuyển tiếp các bản tin DIO đến những
node xung quanh, quảng bá vị trí và DODAG mà nó tham gia. Quá trình này
đƣợc các thành viên trong DODAG lặp lại liên tục tại những thời điểm định thời.
Do đó, quy mô DODAG đƣợc xây dựng mở rộng tới những node ở xa DODAG
root, những node trong DODAG cập nhật đƣợc thông tin của các thành viên xung
quanh trong DODAG.
Khi một node ở trạng thái tự do (chƣa tham gia DODAG), node sẽ định thời
gửi các bản tin DIS tới các neighbor để quảng bá instance mà nó có khả năng
tham gia. Đồng thời yêu cầu những node đáp ứng đƣợc phản hồi lại những thông
tin về DODAG mà chúng tham gia. Khi một neighbor nhận đƣợc bản tin DIS,
nếu đã tham gia một DODAG phù hợp với Instance trong DIS, nó sẽ phản hồi

bằng một bản tin DIO tới node gửi DIS. Sự phản hồi này sẽ diễn ra ngay sau thời
điểm xử lý bản tin DIS mà không đợi tới thời điểm định thời DIO tiếp theo. Bên
cạnh đó, nếu DIS chứa địa chỉ multicast, node sẽ khởi động lại bộ định thời DIO
để giảm thời gian gửi DIO tiếp theo. Cơ chế này giúp sự quảng bá DODAG linh
động và hiệu quả hơn.
Khi trong phạm vi kết nối của node xuất hiện nhiều hơn một DODAG có khả
năng đáp ứng instance mà node tham gia, cơ chế lựa chọn DODAG là sự kết hợp
giữa cơ chế so sánh độ ƣu tiên của các DODAG và các quy luật đƣợc quy định
trong OF. Độ ƣu tiên của các DODAG đƣợc thể hiện thông qua trƣờng DODAG
preferred trong bản tin DIO đƣợc gửi bởi các DODAG root. Nhờ đó, mỗi node
trong mạng đều có thể lựa chọn những DODAG đƣợc ƣu tiên nhất và thỏa mãn
tốt nhất những yêu cầu định tuyến đƣợc đặt ra.
Quá trình lựa chọn DODAG phải tuân theo một số quy tắc sau:
- DODAG tham gia phải đáp ứng instance của node.
- DODAG tham gia phải có độ ƣu tiên cao nhất và node có rank thấp nhất.
- DODAG tham gia phải thỏa mãn các OF của node.
Sau quá trình khám phá và tham gia vào DODAG trong mạng, mỗi node xử
lý những thông tin trong DIO mà chúng nhận đƣợc, cập nhật rank và chọn những
parent từ những node thành viên xung quanh của DODAG. Các parent của một
node phải thỏa mãn những tính chất sau:
- Là một neighbor của node.
- Là thành viên trong cùng DODAG với node.
- Có rank thấp hơn rank của node.
2.1.7.3. Tính toán rank và sự di chuyển của các node
Lựa chọn rank là quá trình xác định vị trí của node so với DODAG root trong
DODAG, đồng thời có ảnh hƣởng đến mối quan hệ của node với các node khác
trong mạng. Quy tắc tính toán rank đƣợc quy định trong các hàm OF tƣơng ứng
với mỗi Instance cụ thể. Tuy nhiên, Rank của node phải thỏa mãn những quy tắc
sau:

- Rank của node trong mạng luôn lớn hơn 1 và nhỏ hơn giới hạn lớn nhất
(Rank Max) đƣợc quy định tùy theo quy mô và mục đích triển khai.
- Rank của node phải luôn lớn hơn rank của tất cả các parent của node.
- Node có thể quảng bá rank thấp hơn hoặc cao hơn rank mà nó quảng bá
trong các bản tin trƣớc đó. Sự thay đổi đó phụ thuộc sự thay đổi rank của
các parent trong DODAG.
- Node có thể quảng bá rank bằng rank max tại mọi thời điểm. Khi một
node quảng bá rank bằng rank max, tƣơng đƣơng với sự kiện node không
là thành viên của bất kỳ DODAG nào trong mạng.
- Tại mọi thời điểm, node có thể tham gia vào một DODAG mới trong cùng
RPL Instance và thay đổi rank phù hợp. Trong thời gian trƣớc khi node
quảng bá các bản tin DIO cho DODAG mới, node vẫn tiếp tục gửi các gói
đến các parent trong DODAG cũ.
Quá trình di chuyển trong DODAG kéo theo sự thay đổi rank của các node,
khi node có khả năng kết nối tới những node gần DODAG root hơn hoặc khi
node không thể kết nối đến các parent và buộc phải kết nối với DODAG thông
qua những node có rank cao hơn.
Khi một node dịch chuyển theo hƣớng upward, node phải cập nhật, thay đổi
các thông số và mối quan hệ của các parent, sibling cũ, đồng thời thiết lập các
mối quan hệ parent và sibling mới. Trong quá trình này, node không cần phải
tách ra khỏi DODAG.
Khi một node trong mạng phải di chuyển theo hƣớng downward, do mất kết
nối với tất cả các node parent hiện tại, trƣớc hết node phải tách ra khỏi DODAG
mà node đang là thành viên. Sau đó thực hiện quá trình tái tham gia DODAG,
cùng với những lựa chọn parent, sibling và rank mới.
2.1.8. Truyền gói
Sau quá trình tham gia và xây dựng DODAG, các node trong DODAG tạo
các gói dữ liệu và bắt đầu gửi gói đến DODAG root. Để gửi gói đến DODAG
root, node phải lựa chọn một node trong route table làm next-hop và gửi gói đến

next-hop đƣợc chọn. Việc lựa chọn next-hop phải tuân theo những quy luật cụ
thể, nhằm mục đích truyền gói hiệu quả, giảm khả năng mất gói, tránh các vòng
lặp và các xung đột trong mạng.
Các quy tắc lựa chọn next-hop đƣợc quy định nhƣ sau:
- Next-hop là một node đã tham gia một DODAG đáp ứng đƣợc RPL
Instance ID trong header của gói tin đƣợc forward.
- Nếu một node hoạt động với giao thức định tuyến đƣợc ƣu tiên hơn RPL
thì chọn node đó làm next-hop.
- Nếu node là thành viên của một DODAG và có một parent là default route
thì chọn parent đó là next-hop.
- Nếu node là thành viên của một DODAG và tất cả các parent tạm thời
không thể kết nối đƣợc, node chọn một trong số các sibling làm next-hop.
Nếu không có sibling, gói sẽ bị hủy.
- Node không đƣợc chọn các node có rank cao hơn làm next-hop.
Khi truyền gói, tham số Time to live (TTL) đƣợc sử dụng để theo dõi và loại
bỏ những gói không truyền đƣợc tới đích, đồng thời hạn chế các vòng lặp có thể
xảy ra. Tại mỗi node gói tin đƣợc forward, TTL đƣợc giảm 1 đơn vị. Khi TTL
bằng 0, gói sẽ bị hủy mà không đƣợc truyền đến DODAG root.

2.2. Tổng quan về Contiki RPL và hoạt động của RPL trên Contiki
Hiện nay, giao thức RPL đang trong quá trình hoàn thiện nhằm tạo ra một
chuẩn giao thức định tuyến mới, có nhiều đặc tính tối ƣu hơn các giao thức định
tuyến trƣớc đây. Do đó, việc xây dựng những chƣơng trình mô phỏng, đánh giá
các đặc tính, hiệu năng của RPL có ý nghĩa đặc biệt quan trọng.
Với mục đích đó, nhóm phát triển Contiki đã nghiên cứu và triển khai xây
dựng module Contiki RPL nhằm đáp ứng nhu cầu nghiên cứu của những ngƣời
đang sử dụng Contiki làm công cụ tìm hiểu, đánh giá RPL. Phiên bản Contiki
RPL đầu tiên đƣợc đƣa ra vào 5/5/2010, cung cấp những hỗ trợ đầu tiên cho
ngƣời nghiên cứu RPL và đang tiếp tục nhận đƣợc sự đóng góp của cộng đồng sử
dụng Contiki trên toàn thế giới.
2.2.1. Hệ điều hành Contiki
Hệ điều hành Contiki là hệ điều hành mã nguồn mở, đƣợc nghiên cứu, thiết
kế và phát triển bởi một nhóm các nhà khoa học tại Viện Khoa học máy tính
Thụy Điển SICS (Swedish Institute of Computer Science), ngƣời đứng đầu là
Adam Dunkels. Nhóm phát triển Contiki gồm nhiều thành viên đến từ SICS,
CISCO, cùng nhiều tổ chức và các trƣờng đại học khác trên thế giới. Hệ điều
hành Contiki đƣợc thiết kế cho các vi điều khiển có bộ nhớ nhỏ, với thông số
2KB RAM và 40KB ROM. Nhờ đó, Contiki đƣợc sử dụng cho các hệ thống
nhúng và các ứng dụng trong mạng cảm biến không dây. Contiki bắt đầu đƣợc
nghiên cứu từ năm 2001 và phát hành phiên bản đầu tiên Contiki 1.0 năm 2003.
Phiên bản hiện nay của Contiki là 3.0, với nhiều thay đổi, bổ sung và phát triển
vƣợt bậc. Trong thực tế, Contiki đã đƣợc ứng dụng trong nhiều dự án nhƣ giám
sát đƣờng hầm xe lửa, theo dõi nƣớc trong biển Baltic, … Nhiều cơ chế, ý tƣởng
trong Contiki đã đƣợc ứng dụng rộng rãi trong công nghiệp. Điển hình nhƣ mô
hình uIP đƣợc phát hành năm 2001 đã đƣợc sử dụng trong hệ thống ứng dụng
của hàng trăm công ty trong các lĩnh vực hàng hải, thông tin vệ tinh, khai thác
dầu mỏ, … mô hình Protothreads đƣợc công bố lần đầu tiên năm 2005, đến nay

đã đƣợc sử dụng trong nhiều ứng dụng nhƣ bộ giải mã kỹ thuật số và thiết bị cảm
biến rung không dây.
Hệ điều hành Contiki đƣợc lập trình bằng ngôn ngữ C, 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:
- Contiki đƣợc chia thành nhiều module hoạt động độc lập. Nhờ đó các ứng
dụng có thể sử dụng các module một cách linh động và chỉ load những
module cần thiết.
- Cơ chế hoạt động điều khiển sự kiện làm giảm năng lƣợng tiêu hao và hạn
chế dung lƣợng bộ nhớ cần sử dụng.
- Có thể sử dụng IP trong mạng cảm biến thông qua uIP stack đƣợc xây
dựng dựa trên nền TCP/IP.
- Có những module cho phép ƣớc lƣợng và quản lý năng lƣợng một cách
hiệu quả.
- Các giao thức tƣơng tác giữa các lớp và các node trong mạng dễ dàng hơn.
- Sử dụng RIME stack phục vụ các giao thức dành cho mạng năng lƣợng
thấp một cách hiệu quả.
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.2.2. Contiki RPL
Contiki RPL là một bộ phận trong stack uIP, hoạt động trên IPv6 và sử dụng
giao thức truyền tin không tin cậy UDP/IP trên nền 6LoWPAN.

Hình 2.13. Kiến trúc giao thức mạng của Contiki RPL
Hình 2.14. Cấu trúc Contiki RPL

Hình 2.14 cho thấy cấu trúc và các module của Contiki RPL. Contiki RPL
bao gồm những module chính:
- Neighbor: quản lý thông tin về các node trong phạm vi kết nối, đồng thời
quản lý mối quan hệ trong cùng DODAG của node với các neighbor trong
danh sách. Các mối quan hệ cùng DODAG gồm: parent, sibling, chidrent.
Những thông tin đƣợc theo dõi của mỗi neighbor gồm: DODAG tham gia,
DODAG Rank, địa chỉ Ipv6 của mỗi neighbor trong mạng.

- RPL-ICMP: module quản lý các bản tin điều khiển RPL – ICMP gồm 3
loại bản tin chính: DIS, DIO, DAO. Đồng thời quản lý các chức năng
kiểm tra xử lý các bản tin ICMP đầu vào, tạo và gửi các bản tin ICMP đầu
ra.
 uip_rpl_input(void): kiểm tra bản tin đầu vào, phân loại bản tin
RPL-ICMP và gọi các hàm xử lý tƣơng ứng.
 dis_input(void): hàm đƣợc gọi khi bản tin nhận đƣợc là DIS, xử lý
các thông tin trong DIS nhận đƣợc và gọi những hàm xử lý cần
thiết.
 dis_output(void): tạo một bản tin DIS, sau đó gửi multicast hoặc
unicast tới những node khác trong mạng.
 dio_output(void): tạo mới một bản tin DIO và gửi tới những node
khác trong mạng.
 dio_input(void): hàm xử lý và lƣu những thông tin trong bản tin
DIO nhận đƣợc.
 dao_output(void): tạo bản tin DAO, gửi tới những node parent
trong DODAG. Bản tin DAO chỉ đƣợc gửi sau khi node đã là thành
viên của một DODAG cụ thể.
 dao_input(void): hàm kiểm tra và lƣu những thông tin trong bản tin
DAO nhận đƣợc từ những node khác trong mạng.
- Timer: là module quản lý những bộ định thời trong Contiki RPL, bao gồm
4 bộ định thời chính, đƣợc xây dựng dựa trên những bộ định thời sẵn có
của Contiki
 Periodic Timer: có chức năng định thời kiểm tra và làm mới bảng
định tuyến, xóa những node trong bảng định tuyến có lifetime bằng
0.
 DIS Timer: quản lý gửi các bản tin DIS. Khi hoạt động định thời
diễn ra, DIS timer sẽ gọi hàm dis_output() để tạo một bản tin DIS
và gửi vào mạng.

 DIO Timer: định thời gửi bản tin DIO vào mạng, nhằm xây dựng
và duy trì DODAG trong mạng, xác định mối quan hệ giữa các
node. Khi bộ định thời hết hạn sẽ gọi hàm dio_output() để tạo và
gửi DIO tới những node khác trong mạng.
 DAO Timer: Định thời tạo và gửi bản tin DAO sau khi node đã
tham gia vào một DODAG trong mạng.
- DODAG: module chính, quản lý các yếu tố ảnh hƣởng đến quá trình tham
gia, xây dựng, duy trì DODAG. Module này cung cấp những phƣơng thức
quản lý DODAG, xử lý thông tin, tìm kiếm, xây dựng bảng định tuyến:
 DODAG OF: cung cấp phƣơng thức xác định Object function của
DODAG mà node tham gia, cung cấp các phƣơng thức so sánh, xác
định vị trí và các thông số của node trong DODAG: rank, OCP,
hàm lựa chọn best-parent → next-hop.
 Routing Table: cung cấp các phƣơng thức xây dựng bản định
tuyến, lựa chọn default route, lọc các route mất kết nối. Ví dụ:
rpl_set_default_route(), poison_routes(), . . .
 Các phƣơng thức thao tác với DODAG: rpl_join_DODAG(),
rpl_free_DODAG(), rpl_find_DODAG(), rpl_get_DODAG(), . . .
 Các phƣơng thức sửa chữa, duy trì DODAG: global_repair(),
rpl_repair_DODAG(), . . .
 Các phƣơng thức xử lý thông tin: rpl_process_dio().
 Các phƣơng thức quản lý các quan hệ trong neighbor:
rpl_remove_neighbor(),rpl_find_neighbor(),
rpl_ds6_neighbor_callback(), rpl_find_best_parent(), . . .
- RPLSTAT: module đƣợc xây dựng phục vụ mục đích thống kê, lƣu các
thông số định tuyến nhƣ số lƣợng gói tin, số lƣợng các bản tin thất lạc.
Qua đó, ngƣời sử dụng có thể đánh giá đƣợc một số những tiêu chí nhƣ
Packet Delevery Rate (PDR), Packet Delevery Cost (PDC), …

2.2.3. Định tuyến trong Contiki RPL
Trong một mạng triển khai Contiki RPL định nghĩa hai loại thiết bị: udp-
client và udp-server, hoạt động theo kiểu truyền tin không tin cậy UDP. Trong
pha đầu tiên khi triển khai mạng, một số node trong mạng đƣợc cấu hình là
những bộ tập trung dữ liệu - DODAG root cho những RPL Instance cụ thể.
Những node khác trong mạng là những node udp-client, không thực hiện chức
năng thu thập dữ liệu mà thực hiện chức năng tạo và forward gói về DODAG
root. Những node trong mạng Contiki RPL hoạt động tuân theo những ràng buộc
sau:
- Tất cả các node trong mạng đều phải có địa chỉ IPv6 riêng biệt, đƣợc thiết
lập bởi uIP stack trong Contiki. Với 64bit đầu tiên là global prefix đƣợc sử
dụng để phân biệt các mạng, 64 bit còn lại đƣợc dùng định địa chỉ của
node (kết hợp với địa chỉ MAC của thiết bị).
- Các udp-server phải là các DODAG root của các DODAG trong mạng.
Các udp-server chỉ đáp ứng một RPL Instance theo mục đích triển khai và
có một mã nhận dạng DODAGID duy nhất. DODAGID là một địa chỉ
IPv6 đƣợc thiết lập trƣớc. Các DODAGID có thể đƣợc lặp lại ở những
RPL Instance khác nhau.
- Tất cả các node trong mạng đều có khả năng tạo, gửi, nhận và xử lý các
bản tin ICMP.
- Các node trong mạng có khả năng hoạt động theo cả hai cơ chế: gửi DIS
hoặc chờ nhận DIO trong pha khởi động.
- Mỗi udp-client chỉ đáp ứng một loại RPL Instance. Vấn đề triển khai một
node có khả năng đáp ứng nhiều RPL Instance khác nhau vẫn đang trong
quá trình nghiên cứu và phát triển.
- Các udp-client tìm kiếm và chỉ gia nhập những DODAG tƣơng thích với
RPL Instance mà node có khả năng đáp ứng.
- Các node trong mạng tự động cấu hình và xây dựng DODAG. Từ đó định
tuyến và truyền gói về DODAG root dọc theo DODAG.

- Các udp-client tạo và truyền các gói multihop trong DODAG. Mỗi gói tin
chỉ đƣợc gửi đến một DODAG parent duy nhất trong DODAG và không
đƣợc gửi lại nếu bị mất gói.
- Tất cả các node không bao giờ đƣợc gửi gói tin đến những node có rank
cao hơn trong cùng một DODAG.
- Các node trong mạng đều có khả năng gửi các bản tin ICMP đến các địa
chỉ unicast, multicast trong mạng.
- Các node có khả năng sử dụng cơ chế Neighbor Discovery trong IPv6 để
quản lý sự xuất hiện của các node khác trong phạm vi kết nối.
2.2.3.1. Những yêu cầu cần đạt đƣợc khi triển khai Contiki RPL
Ngoài những yêu cầu cơ bản trong định tuyến, một mạng Contiki RPL cần đạt
đƣợc một số yêu cầu sau:
- Mỗi mạng Contiki RPL có thể gồm nhiều RPL Instance, mỗi RPL
Instance có thể có nhiều DODAG.
- Mạng phải có khả năng tự cấu hình, xây dựng DODAG.
- Các DODAG trong mạng phải có khả năng tự sửa chữa và duy trì
DODAG.
2.2.3.2. Hoạt động của DODAG root / UDP-Server
Trong pha đầu tiên khi khởi tạo mạng, những node đƣợc lựa chọn làm
DODAG root thực hiện quá trình thiết lập địa chỉ IPv6, cổng kết nối và những
thông số định tuyến của DODAG nhƣ DODAGID, RPLInstanceID, Object
function, … (hình 2.15). Những thông tin của DODAG đƣợc DODAG root đƣa
vào bản tin DIO và quảng bá tới những node khác trong mạng. Sau khi xây dựng
DODAG, DODAG root nhận các gói tin đƣợc gửi về từ những node khác trong
DODAG.

Hình 2.15. Quá trình hoạt động của DODAG root
Sau quá trình khởi tạo, DODAG root hoạt động theo cơ chế event-driven, tùy
theo những sự kiện đến cụ thể, DODAG root đƣa ra những hoạt động tƣơng ứng.
Cơ chế hoạt động event-driven của DODAG root nhƣ trong hình 2.16.
Hình 2.16. Cơ chế điều khiển sự kiện của DODAG root

2.2.3.3. Hoạt động của các node client trong DODAG / UDP-client
Trong pha khởi tạo, những udp-client thực hiện quá trình thiết lập địa chỉ
IPv6 và khởi động bộ định thời handle-periodic-timer có chức năng định thời gửi
các bản tin DIS tới các node khác trong mạng khi node chƣa tham gia vào bất kỳ
DODAG nào.
Hình 2.17. Pha khởi tạo của những node udp-client

Sau pha khởi tạo, mỗi node đã thiết lập đƣợc những thông tin ban đầu và bắt
đầu nhận và xử lý những bản tin ICMP trong mạng. Khi đó node tham gia những
DODAG hỗ trợ và hoạt động theo cơ chế điều khiển sự kiện. Các hoạt động của
node theo những sự kiện đến nhƣ: nhận các bản tin ICMP, nhận gói từ node khác
trong mạng, các sự kiện định thời. Các hoạt động tƣơng ứng của node đƣợc chỉ ra
trong hình 2.18:

Hình 2.18. Cơ chế điều khiển sự kiện của udp-client
2.2.3.4. Cơ chế xử lý bản tin DIO và xây dựng DODAG
Hoạt động gửi, nhận, xử lý bản tin DIO là hoạt động quan trọng nhất, quyết
định đến khả năng xây dựng DODAG và định tuyến của một mạng RPL. Trong
Contiki RPL, quá trình tạo và gửi DIO đƣợc bắt đầu tại những DODAG root.
Quá trình nhận và xử lý DIO giúp cho các node trong mạng nhận dạng những
DODAG phù hợp, tham gia DODAG và lựa chọn parent trong DODAG.

Hình 2.19. Quá trình xử lý bản tin DIO
Một số nguyên tắc khi xử lý bản tin DIO:
- Bản tin DIO phải có Instance ID đƣợc node hỗ trợ thì mới đƣợc tiếp tục
xử lý.

- Khi node chƣa tham gia bất kỳ DODAG nào thì tham gia vào DODAG
của node gửi DIO.
- Nếu bản tin DIO của một DODAG mà node không phải thành viên và nếu
việc tham gia vào DODAG mới khiến node có rank thấp hơn thì node sẽ
gia nhập DODAG mới.
- Nếu DIO đến từ một node trong cùng một DODAG và sequence number
đã đƣợc tăng lên thì node tham gia quá trình sửa chữa DODAG.
- Nếu DIO trong cùng DODAG, quảng bá rank thấp hơn rank của node
nhƣng chƣa có trong danh sách parent thì thêm node gửi DIO làm parent,
sau đó cập nhật vị trí của node trong DODAG.
- Nếu DIO từ một parent trong DODAG, trƣớc hết cần cập nhật thông tin
của parent, sau đó tùy thuộc vào sự thay đổi của các parent đƣa ra hành
động phù hợp.
- Khi rank thay đổi, phải reset bộ định thời DIO.
- Chỉ chuyển lên rank cao hơn theo một parent khi không còn parent thay
thế.
- Best parent là node thuộc DODAG có thứ tự ƣu tiên cao nhất và có rank
thấp nhất.

CHƢƠNG 3: MÔ PHỎNG HOẠT ĐỘNG CỦA RPL TRÊN CONTIKI RPL
3.1. Mục tiêu mô phỏng
Trong quá trình thực hiện mô phỏng, luận văn hƣớng tới các mục tiêu sau:
- Phân tích quá trình gửi nhận các bản tin (DIS, DIO) qua đó đánh giá quá
trình hình thành topo mạng
- Đánh giá độ tin cậy của giao thức RPL thông qua tỉ lệ truyền gói thành
công – Packet Delivery Ratio (PDR)
- Đánh giá mức tiêu thụ năng lƣợng thông qua chi phí truyền gói – Packet
Delivery Cost (PDC)
3.2. Tham số cài đặt mô phỏng
STT Nội dung Tham số
1 Thời gian mô phỏng 5400(s)
2 Diện tích mô phỏng 58500 m2
3 Cự ly giữa các node Nhỏ hơn 50 m so với node parent của nó
4 Node mô phỏng Thiết bị Zolertia z1
Số lƣợng node Tối thiểu 15 node đóng vai trò client và 1 node
5
đóng vai trò DODAG root
Vị trí node Phân bố ngẫu nhiên nhƣng phải đảm bảo khoảng
6 cách các node nhỏ hơn 50m so với node parent
của nó
Định tuyến Tối thiểu hóa số chặng truyền gói tin từ các node
7
tới DODAG root
Tham gia DODAG Tại một thời điểm, trong một instance, mỗi node
8
của node chỉ tham gia một DODAG trong instance đó
Thời gian gửi bản 60s + Random(1:60)(s)
9
tin DATA
Thời gian gửi bản Mặc định
10
tin điều khiển
11 Kích thƣớc gói tin Mặc định
Bảng 3.1. Tham số mô phỏng

3.3. Kịch bản mô phỏng
Trong phần này luận văn sẽ đƣa ra 3 kịch bản mô phỏng
- Kịch bản 1: 1 Instance – 1 DODAG root – 15 node client
Từ 3 kịch bản mô phỏng, luận văn sẽ đƣa ra các kết luận
- RPL là giao thức có các thông số hiệu năng tốt và đáng tin cậy thông qua
việc phân tỉ lệ truyền gói thành công PDR và chi phí truyền gói PDC
- Khi trong mạng có nhiều Instance, các node trong mạng có khả năng xác
định DODAG nó sẽ tham gia. Nhờ đó, quá trình định tuyến trở nên hiệu
quả, giảm các bản tin dƣ thừa trong mạng.
3.4. Phân tích
3.4.1. Kịch bản 1: 1 Instance – 1 DODAG root – 15 Node client
3.4.1.1. Quá trình hình thành topo mạng
a. Quá trình gửi nhận bản tin DIS
Trong phần này luận văn tiến hành mô phỏng với một mạng gồm 1 DODAG
root và 15 node đóng vai trò là những client tham gia quá trình định tuyến. Vị trí
các node trong mạng đƣợc phân bố nhƣ hình 3.1
Hình 3.1. Phân bố các node trong mạng

Sau quá trình khởi tạo mạng các node gửi bản tin multicast DIS tới các node
hàng xóm để đƣợc xin tham gia vào DODAG. Các bản tin này sẽ bị các node từ
chối do các node chƣa tham gia vào một DODAG nào cụ thể.
Hình 3.2. node 2 gửi bản tin DIS tới các node hàng xóm

Hình 3.3. node 5 nhận được bản tin DIS từ các node hàng xóm
Hình 3.4. Các node gửi bản tin DIS tới các node hàng xóm
b. Quá trình downward
Đầu tiên, DODAG root sẽ gửi bản tin multicast DIO tới các node hàng xóm
của nó để quảng bá. Cụ thể ở ví dụ này là từ node 1 tới node 5, 8, 11

Hình 3.5. DODAG root gửi bản tin DIO tới các node hàng xóm
Note 1 gửi bản tin DIO tới node 5, 8, 11 với các giá trị
Hình 3.6. Thông tin bản tin DIO gửi từ DODAG root tới các node hàng xóm

Tƣơng tự, sau khi tham gia vào DODAG node 5, node 8, node 11 sẽ giửi
multicast tới các node hàng xóm của nó là các node 2, 3, 6, 9, 12, 14, 15. Cứ nhƣ
vậy DODAG đƣợc hình thành.
Hình 3.7. Quá trình hình thành DODAG

3.4.1.2. Tỉ lệ truyền gói thành công
Tỉ lệ truyền gói thành công (PDR) đƣợc tính nhƣ sau:
PDR   DATA  packet  received  at  root

 DATA  packet  sent  at  node
Các số liệu đƣợc thống kê từ chƣơng trình mô phỏng với 1 DODAG root và
15 client trong thời gian 5400 giây. Các bảng thông kê số lƣợng gói truyền tại
các node và số gói nhận tƣơng ứng tại DAG root nhƣ sau:
Số bản tin
STT Rank Node ID Số bản tin gửi PDR
đến Root
1 1 2 89 89 1.000
2 1 5 89 89 1.000
3 1 8 89 89 1.000
4 1 11 89 89 1.000
5 1 14 89 89 1.000
6 2 3 89 89 1.000
7 2 6 89 89 1.000
8 2 9 89 89 1.000
9 2 12 89 89 1.000
10 2 15 89 88 0.989
11 3 4 89 87 0.978
12 3 10 89 87 0.978
13 3 16 89 89 1.000
14 4 7 89 89 1.000
15 4 13 89 89 1.000
Bảng 3.2. Tỉ lệ truyền gói thành công của các node trong DODAG
STT Rank Tổng số bản tin gửi Tổng số bản tin đến Root PDR
1 1 445 445 1.000
2 2 445 444 0.997
3 3 267 263 0.985
4 4 178 178 1.000
Bảng 3.3. Tỉ lệ truyền gói thành công trung bình tại các rank
Tỉ lệ truyền gói thành công của toàn mạng:
Từ các bảng 3.2 và bảng 3.3, và tỉ lệ truyền gói thành công PDR = 0.9963 có
thể thấy tỉ lệ truyền gói thành công là khá cao và tƣơng đối đồng đều giữa các

rank trong DODAG. Qua đó có thể thấy độ tin cậy khi gửi gói trong mạng RPL
trong kịch bản này là khá cao và ổn định.
3.4.1.3. Chi phí truyền gói
Chi phí truyền gói (PDC) đƣợc tính nhƣ sau:
PDC   All  kind  of  packet

 DATA  packet  received  at  root
Chức năng Node ID Bản tin DATA Bản tin ICMP Tổng số bản tin
DAG root 1 0 17 17
Client 2 89 125 214
Client 3 89 121 210
Client 4 89 144 233
Client 5 89 132 221
Client 6 89 112 201
Client 7 89 118 207
Client 8 89 117 206
Client 9 89 131 220
Client 10 89 131 220
Client 11 89 133 222
Client 12 89 135 224
Client 13 89 126 215
Client 14 89 125 214
Client 15 89 114 203
Client 16 89 123 212
Tổng số bản tin 1335 1904 3239
Bảng 3.4. Bản tin đã gửi trong các node mạng
Bảng 3.4 thống kê số bản tin DATA đƣợc gửi từ các node trong mạng đến
DODAG root trong thời gian mô phỏng 5400 giây.
- Số bản tin DATA nhận đƣợc tại DODAG root trong thời gian mô phỏng
5400 giây: 1330 (gói tin).
- Tổng tất cả các loại bản tin đƣợc gửi trong mạng: 3239 (bản tin).
Chi phí truyền gói

Có thể nhận thấy, PDC cho toàn mạng RPL là khá thấp. Do đặc điểm định
thời gửi các bản tin ICMP đã làm giảm số lƣợng bản tin điều khiển trong mạng.
Điều này cho thấy RPL là giao thức có các thông số hiệu năng tốt và đáng tin cậy
Tƣơng tự nhƣ kịch bản số 1, các node sẽ lần lƣợt gửi các bản tin DIS, DIO để
xây dựng topo mạng.
Hình 3.8. Topo mạng của DODAG

Nhƣng khác so với kịch bản 1, kịch bản hai có sự xuất hiện của 2 DODAG
root trong cùng 1 Instance nên dẫn tới việc các node sẽ lựa chọn nhƣ nào để tham
gia vào DODAG phù hợp

Hình 3.9. Gói tin RPL trong node 15
Dựa vào hình 3.9 có thể thấy đƣợc quá trình tham gia vào DODAG của node
15 trong kịch bản 1 Instance – 2 DODAG root
- Node 15 nhận bản tin DIO từ node 14 (fe80::c30c:0:0:e)
 Kiểm tra thông tin tham gia vào DODAG của node 14. Cụ thể với
Instance ID = 30, DODAG root là node 1
 Nhận node 14 làm DODAG parent
 Chỉ Default Route về node 14
- Node 15 nhận bản tin DIO từ node 13 (fe80::c30c:0:0:d)
 Kiểm tra thông tin thấy node 13 cùng DODAG và có rank thấp hơn
 Nhận node 13 làm Candidate parent

- Node 15 nhận bản tin DIO từ node 19 (fe80::c30c:0:0:13)
 Kiểm tra thông tin thấy node 19 không cùng Instance ID (30 # 46)
 Từ chối tham gia vào DODAG mới
Tƣơng tự nhƣ node 15, 29 node còn lại sẽ có các quá trình thực hiện tƣơng tự
để xây dựng DODAG.
Thông qua quá trình hình thành topo và truyền dữ liệu, có thể kết luận nhƣ
sau
- Trong cùng một Instance khi một node đã tham gia vào một DODAG nếu
nhƣ quá trình kết nối tới các node hàng xóm hoặc node root không bị gián
đoạn thì node đó sẽ không tham gia vào DODAG khác
- Tất cả các node trong mạng chỉ truyền gói tin về root mà nó đang là thành
viên.
Các số liệu đƣợc thống kê từ chƣơng trình mô phỏng với 1 Instance 2
DODAG root và 30 client trong thời gian 5400 giây. Các bảng thông kê số lƣợng
gói truyền tại các node và số gói nhận tƣơng ứng tại DAG root nhƣ sau:
Số bản tin
đến Root
1 1 3 89 89 1.000
2 1 8 89 89 1.000
3 1 14 89 89 1.000
4 1 13 89 88 0.989
5 1 18 89 89 1.000
6 1 23 89 87 0.978
7 1 28 89 88 0.989
8 2 5 89 88 0.989
9 2 4 89 87 0.978
10 2 10 89 88 0.989
11 2 9 89 89 1.000
12 2 15 89 87 0.978
13 2 19 89 87 0.978
14 2 24 89 88 0.989
15 2 29 89 89 1.000
16 3 6 89 88 0.989
17 3 11 89 89 1.000

Số bản tin
đến Root
18 3 17 89 89 1.000
19 3 16 89 89 1.000
20 3 20 89 87 0.978
21 3 25 89 89 1.000
22 3 30 89 84 0.944
23 4 7 89 89 1.000
24 4 12 89 89 1.000
25 4 22 89 89 1.000
26 4 21 89 89 1.000
27 4 26 89 88 0.989
28 4 31 89 85 0.955
29 5 27 89 89 1.000
30 5 32 89 89 1.000
1 1 623 619 0.994
2 2 712 703 0.987
3 3 623 615 0.987
4 4 534 529 0.990
5 5 178 178 1.000
Bảng 3.6. Tỉ lệ truyền gói thành công trung bình tại các rank
Từ các bảng 3.5 và bảng 3.6, và tỉ lệ truyền gói thành công PDR = 0.9903 có
thể thấy tỉ lệ truyền gói thành công là khá cao và tƣơng đối đồng đều giữa các
DODAG root 1 0 20 31
Client 3 89 117 182
Client 4 89 121 188
Client 5 89 115 179

Client 6 89 113 176
Client 7 89 121 188
Client 8 89 112 174
Client 9 89 117 182
Client 10 89 128 199
Client 11 89 115 179
Client 12 89 115 179
Client 13 89 115 179
Client 14 89 126 196
Client 15 89 124 193
Client 16 89 113 176
Client 17 89 113 176
Client 18 89 117 182
Client 19 89 131 204
Client 20 89 126 196
Client 21 89 139 216
Client 22 89 130 202
Client 23 89 106 165
Client 24 89 119 185
Client 25 89 128 199
Client 26 89 133 207
Client 27 89 124 193
Client 28 89 106 165
Client 29 89 121 188
Client 30 89 128 199
Client 31 89 121 188
Client 32 89 126 196
5400 giây: 2008 (gói tin).

Giống nhƣ kịch bản số 1, dựa vào thông số PDC bằng 2.835 ta có thể thấy
đƣợc trong kịch bản này chi phí truyền gói tƣơng đối thấp, giao thức RPL có hiệu
năng tốt.
Tƣơng tự nhƣ kịch bản số 1 và 2, trong kịch bản này các node sẽ lần lƣợt gửi
các bản tin DIS, DIO để xây dựng topo mạng với 2 Instance khác nhau
Instance 0:
Root:
Client:
Instance 1:
Root:
Client:


Thông qua hình 3.10, 3.11, 3.12, 3.13 cho thấy quá trình xây dựng DODAG
có các thông tin nhƣ sau:
- Gồm 2 Instance, mỗi Instance có 1 DODAG root và 15 node client
- Các node từ 2 tới 16 thuộc Instance 0 với DODAG root là node số 1
- Các node từ 18 tới 31 thuộc Instance 1 với DODAG root là node số 17
Dựa vào quá trình hình thành topo mạng có thể kết luận, khi trong mạng có
nhiều Instance, các node trong mạng có khả năng xác định DODAG nó sẽ tham
gia. Nhờ đó, quá trình định tuyến trở nên hiệu quả, giảm các bản tin dƣ thừa
trong mạng.
Bên cạnh đó, thông qua topo mạng mô phỏng, có thể thấy một số đặc điểm
của giao thức RPL nhƣ sau:
- Nếu mỗi node chỉ hỗ trợ một Instance, thì node thuộc Instance này không
thể tham gia vào những DODAG thuộc Instance khác.
- Các DODAG thuộc mỗi Instance đƣợc phân biệt rõ ràng, đƣợc các node
trong mạng tự động nhận diện trong quá trình xây dựng cấu trúc mạng.

- Tất cả các node trong mạng chỉ truyền gói có Instance mà mình đáp ứng,
và chỉ truyền về DODAG root của DODAG mà nó đang là thành viên.
Để làm rõ hơn các kết luận trên, luận văn sẽ đƣa ra các hình ảnh mô phỏng cụ
thể.
Xét node 21
- Thông số đầu vào:
 Thuộc Instance 1 với node 17 làm root
 Có node hàng xóm thuộc cùng Instance là node 25
 Nằm trong phạm vi kết nối của các node thuộc Instance khác nhƣ
node 1 (root), 5, 9
Hình 3.14. Topo mạng của DODAG

- Quá trình:
 Nhận đƣợc các bản tin DIO từ các node 1, 5, 9 nhƣng node 21 nhận
thấy không thuộc cùng Instance nên không tham gia vào DODAG
 Chỉ sau khi nhận đƣợc bản tin DIO từ node 25, kiểm tra thấy thuộc
cùng Instance nên mới tham gia vào DODAG với node 17 làm
DODAG root

Hình 3.15. Gói tin node 21
- Kết luận: Nếu mỗi node chỉ hỗ trợ một Instance, thì node thuộc Instance
này không thể tham gia vào những DODAG thuộc Instance khác
Xét node 1 và 17
- Thông số đầu vào
 Hai node là 2 DODAG root thuộc 2 Instance khác nhau
 Node 1 là DODAG root của Instance 0
 Node 17 là DODAG root của Instance 1
 Xét trong một khoảng thời gian nhất định
- Quá trình
 Dựa vào bảng 4.1 và 4.2 thấy đƣợc các node từ 2-16 chỉ gửi bản tin
DATA về node 1. Tƣơng tự nhƣ vậy, các node từ 18 tới 31 chỉ gửi
bản tin DATA về node 17.
Thời gian Node Bản tin DATA
01:04.2 ID:1 DATA recv 'Hello 1 from the client with rank 3' from 10

Bảng 3.8. Các bản tin DATA gửi tới node 1

Bảng 3.9. Các bản tin DATA gửi tới node 17
- Kết luận: Tất cả các node trong mạng chỉ truyền gói có Instance mà mình
đáp ứng, và chỉ truyền về DODAG root của DODAG mà nó đang là thành
viên
Các số liệu đƣợc thống kê từ chƣơng trình mô phỏng với 2 Instance 2
DODAG root và 30 node client trong thời gian 5400 giây. Các bảng thông kê số
lƣợng gói truyền tại các node và số gói nhận tƣơng ứng tại DAG root nhƣ sau:
Số bản tin
đến Root
1 1 2 89 87 0.978
2 1 5 89 89 1.000

Số bản tin
đến Root
3 1 27 89 89 1.000
4 1 30 89 89 1.000
5 2 3 89 89 1.000
6 2 8 89 89 1.000
7 2 9 89 89 1.000
8 2 26 89 89 1.000
9 2 24 89 89 1.000
10 3 4 89 87 0.978
11 3 10 89 87 0.978
12 3 12 89 88 0.989
13 3 14 89 87 0.978
14 3 31 89 89 1.000
15 3 32 89 89 1.000
16 4 6 89 89 1.000
17 4 7 89 89 1.000
18 4 13 89 86 0.966
19 4 15 89 89 1.000
20 4 11 89 85 0.955
21 4 28 89 89 1.000
22 4 29 89 89 1.000
23 5 16 89 89 1.000
24 5 23 89 88 0.989
25 5 22 89 89 1.000
26 6 20 89 88 0.989
27 7 18 89 89 1.000
28 7 25 89 89 1.000
29 8 19 89 87 0.978
30 8 21 89 85 0.955
1 1 356 354 0.994
2 2 445 445 1.000
3 3 534 527 0.987
4 4 623 616 0.989
5 5 267 266 0.996
6 6 89 88 0.989
7 7 178 178 1.000
8 8 178 172 0.966
Bảng 3.11. Tỉ lệ truyền gói thành công trung bình tại các Rank

Từ các bảng 3.10 và bảng 3.11, và tỉ lệ truyền gói thành công PDR = 0.9910
có thể thấy tỉ lệ truyền gói thành công là khá cao và tƣơng đối đồng đều giữa các
Client 2 89 135 224
Client 3 89 140 229
Client 4 89 142 231
Client 5 89 147 236
Client 6 89 129 218
Client 7 89 144 233
Client 8 89 163 252
Client 9 89 140 229
Client 10 89 129 218
Client 11 89 144 233
Client 12 89 135 224
Client 13 89 142 231
Client 14 89 146 235
Client 15 89 139 228
Client 16 89 124 213
Client 18 89 153 242
Client 19 89 152 241
Client 20 89 143 232
Client 21 89 156 245
Client 22 89 158 247
Client 23 89 126 215
Client 24 89 141 230
Client 25 89 146 235
Client 26 89 133 222
Client 27 89 135 224
Client 28 89 149 238
Client 29 89 146 235
Client 30 89 140 229

Client 31 89 147 236
Client 32 89 124 213
5400 giây: 2646 (gói tin).
Trong kịch bản này chi phí truyền gói (2.632) nhỏ hơn chi phí truyền gói của
kịch bản số 2 (2.835) và lớn hơn chi phí truyền gói của kịch bản số 1 (2.435)
3.5. Đánh giá kết quả mô phỏng
Về Topo mạng
- Cả 3 kịch bản đều có kết quả hình thành topo mạng trong thời gian ngắn
từ 2-3 phút qua đó thấy đƣợc giao thức RPL có hiệu năng tốt trong việc
hình thành topo mạng.
- Cả 3 kịch bản đƣa ra đều thỏa mãn yêu cầu của mục tiêu mô phỏng: tối
thiểu hóa số chặng truyền gói tin từ các node tới DODAG root
- Riêng kịch bản 2 và 3 còn chỉ rõ hơn kết quả tại một thời điểm, trong một
instance, mỗi node chi tham gia vào một DODAG trong instance đó và chỉ
gửi bản tin về DODAG root nó tham gia
Về chỉ số PDR và PDC
- Tỉ số PDR kịch bản 1 cao hơn hai kịch bản còn lại, bên cạnh đó chi phí
truyền gói PDR của kịch bản 1 thấp hơn 2 kịch bản còn lại. Qua đó thấy
đƣợc PDR và PDC phụ thuộc vào số lƣợng node trong mạng, số lƣợng
node càng ít thì PDR càng tăng và PDC càng giảm. Có nhiều nguyên nhân

để dẫn đến kết quả này nhƣng một trong những nguyên nhân chính là do
lƣợng bản tin ICMP ít hơn.
- Kịch bản 2 và 3 số lƣợng root và client bằng nhau (2 root và 30 client)
nhƣng cấu trúc mạng khác nhau (“1 instance – 2 root” và “2 instance – 2
root”). Dựa vào kết quả trong các phần trên thấy đƣợc tỉ lệ PDR của kịch
bản 3 cao hơn kịch bản 2 mà tỉ lệ PDC của kịch bản 3 lại thấp hơn kịch
bản 2. Qua đó có thể tạm kết luận kịch bản 3 cho hiệu năng tốt hơn kịch
bản 2. Có thể dựa vào kết quả này để lựa chọn mô hình phù hợp hơn, hiệu
năng tốt hơn khi triển khai mô hình thật trong lƣơng lai.
3.6. Kết luận
Trong chƣơng này luận văn đã mô phỏng một số kịch bản và kết quả về hoạt
động của giao thức RPL dựa vào Contiki RPL. Kết quả mô phỏng cho thấy:
thông qua việc xây dựng các DODAG, mỗi node trong mạng có khả năng xác
định vị trí gần Root nhất, tối ƣu khoảng cách truyền gói về bộ tập trung dữ liệu
với số hop nhỏ nhất. Hơn nữa, cơ chế tự cấu hình mạng linh động và có độ tin
cậy cao khi truyền gói.
Tuy nhiên, do thời gian hạn hẹp, trong chƣơng trình mô phỏng chƣa xây dựng
đƣợc chƣơng trình có khả năng hỗ trợ nhiều Instance cho mỗi node trong mạng.
Vì vậy, quá trình nghiên cứu tiếp theo sẽ thực hiện một số vấn đề sau:
- Xây dựng chƣơng trình hỗ trợ nhiều Instance cho mỗi node trong mạng,
đánh giá các kết quả.
- Triển khai thử trên node thật, đánh giá các kết quả thu đƣợc.

KẾT LUẬN VÀ HƢỚNG PHÁT TRIỂN
Khái niệm mạng cảm biến đang ngày càng trở lên quen thuộc hơn với cuộc
sống hiện đại, khi những ứng dụng ngày càng trở nên phong phú, đa dạng, đòi
hỏi tính linh động cao hơn. Với những tính năng ƣu việt và ứng dụng đa dạng,
mạng cảm biến sẽ không ngừng đƣợc nghiên cứu và phát triển trong tƣơng lai.
Trong luận văn này, tôi đã tìm hiểu và trình bày những khái niệm tổng quan
về một giao thức định tuyến mới và hiện đang trong quá trình nghiên cứu, phát
triển: RPL – Routing Protocol for Low Power and Lossy Network. Đồng thời, tôi
cũng đã tiến hành mô phỏng RPL trên Contiki nhằm mục đích đánh giá hiệu
năng của mạng khi sử dụng giao thức này. Dƣới đây là một số công việc tôi đã
thực hiện trong quá trình hoàn thành luận văn:
- Nghiên cứu, tìm hiểu các khái niệm, nguyên lý, hoạt động trong giao thức
RPL.
- Tìm hiểu, cài đặt Contiki, các công cụ Eclipse, Cooja, . . .
- Xây dựng chƣơng trình mô phỏng với những chức năng: xây dựng topo
mạng, nhận dạng DODAG root, multi DODAG root, phân biệt Instance,
lọc bản tin ICMP, DATA
- Thống kê số liệu, tổng hợp, đánh giá một số thông số định tuyến của giao
thức RPL: Packet delivery ratio, Packet Delivery Cost.
Trong tƣơng lai cần nghiên cứu, phát triển:
- Xây dựng chƣơng trình hỗ trợ nhiều Instance cho mỗi node trong mạng,
đánh giá các kết quả. Việc lựa chọn DODAG của các node cần linh động
hơn khi dựa vào tổng hợp nhiều yếu tố nhƣ khoảng cách (hop count), năng
lƣợng còn lại trong node, chất lƣợng đƣờng truyền . . .
- Đánh giá nguyên nhân mất gói và cách khắc phục
- Triển khai thử trên node thật, đánh giá các kết quả thu đƣợc.

TÀI LIỆU THAM KHẢO
[1] INFSO D.4 Networked Enterprise RFID INFSO G.2 Micro Nanosystems
in Co-operation with the Working Group RFID of the ETP EPOSS, “Internet of
Things in 2020, Roadmap for future, Version 1.1”, European Commission,
Information Society and Media, Tech. Rep., May 2008.
[2] H. Sundmaeker, P. Guillemin, P. Friess, S. Woelffle, “Vision and
Challenges for Realizing the Internet of Things”, The Cluster of European
Research Projects on the Internet of Things-CERP IoT, 2010.
[3] European Commission, “Internet of Things in 2020 Road Map for The
Future”, Working Group RFID of the ETP EPOSS, Tech. Rep., May2008,
[4] O. Vermesan, P. Friess, P. Guillemin, S. Gusmeroli, et al., “Internet of
Things Strategic Research Agenda”, Chapter 2 in Internet of Things Global
Technological and Societal Trends, River Publishers, 2011.
[5] P. Guillemin and P. Friess, “Internet of Things Strategic Research
Roadmap”, The Cluster of European Research Projects, Tech. Rep., September
2009.
[6] Ngô Quang Anh, nghiên cứu chuẩn kết nối không dây ZIGBEE/IEEE
802.15.4, 2005.
[7]. http://tools.ietf.org/html/draft-ietf-roll-home-routing-reqs-11, truy cập lần
cuối ngày 03/03/2017.
[8]. http://tools.ietf.org/html/rfc5673, truy cập lần cuối ngày 03/03/2017.
[9]. http://tools.ietf.org/html/rfc5548, truy cập lần cuối ngày 03/03/2017.
[10]. T. Narten, IBM, E. Nordmark, Sun Microsystems, W. Simpson,
Daydreamer, H. Soliman, RFC 4861 neighbor discovery for IP version 6 (IPv6),
September, 2007.
[11]. Nicolas Tsiftes, Joakim Eriksson, and Adam Dunkels, Poster Abstract:
Low-Power Wireless IPv6 Routing with ContikiRPL. In Proceedings of
ACM/IEEE IPSN'10.

[12] J. Tripathi, J. deOliveira, Drexel University, JP. Vasseur, Cisco Systems,
Performance Evaluation of Routing Protocol for Low Power and Lossy Networks
(RPL), draft-tripathi-roll-rpl-simulation-03, March23,2010.

PHỤ LỤC
Mặc định cấu hình (code) của Contiki RPL 3.0 sẽ bị giới hạn một số điểm
nhƣ: không vẽ ra topo mạng (trên phần annotate), không hiện vị trí tƣơng đối của
client với root, không hỗ trợ nhiều hơn 1 Instance . . . Chính vì vậy tôi cần phải
thay đổi một số thông số (code) để thực hiện luận văn. Một số thay đổi lớn nhƣ
1. Vẽ topo mạng trên annotate
Trong file ~/contiki/examples/ipv6/rpl-udp/project-conf.h thêm
#define TCPIP_CONF_ANNOTATE_TRANSMISSIONS 1
2. Hiện rank của node trên annotate

Trong file ~/contiki/core/net/rpl/rpl-dag.c sau dùng 848 thêm code
PRINTF("#A rank=%u\n", best_dag->rank);
return best_dag;
3. Hiện rank của node trên Mote Output

Việc hiện rank của node cho thấy đƣợc vị trí tƣơng đối của node so với
DODAG root, mặc định DODAG root là 1 các node lần lƣợt sẽ tăng thêm 1 đơn
vị theo rank. Trong file ~/contiki/examples/ipv6/rpl-udp/udp-client.c thêm
#include "net/rpl/rpl.h"
#include "net/rpl/rpl-private.h"
Sửa code
static void
send_packet(void *ptr)
{
static int seq_id;
char buf[MAX_PAYLOAD_LEN];
seq_id++;
PRINTF("DATA send to %d 'Hello %d'\n",
server_ipaddr.u8[sizeof(server_ipaddr.u8) - 1],
seq_id);
sprintf(buf, "Hello %d from the client", seq_id);
uip_udp_packet_sendto(client_conn, buf, strlen(buf),
&server_ipaddr, UIP_HTONS(UDP_SERVER_PORT));
}
Thành

static void
send_packet(void *ptr)
{
char buf[MAX_PAYLOAD_LEN];
#ifdef SERVER_REPLY
uint8_t num_used = 0;
uip_ds6_nbr_t *nbr;
nbr = nbr_table_head(ds6_neighbors);
while(nbr != NULL) {
nbr = nbr_table_next(ds6_neighbors, nbr);
num_used++;
}
if(seq_id > 0) {
ANNOTATE("#A r=%d/%d,color=%s,n=%d %d\n", reply, seq_id,
reply == seq_id ? "GREEN" : "RED",
uip_ds6_route_num_routes(), num_used);
}
#endif /* SERVER_REPLY */
rpl_dag_t *dag = rpl_get_any_dag();

uint8_t withRank = DAG_RANK(dag->preferred_parent->rank,
dag->instance);
seq_id++;
PRINTF("DATA send to %d 'Hello %d' with rank %u\n",
server_ipaddr.u8[sizeof(server_ipaddr.u8) - 1], seq_id,
withRank);
sprintf(buf, "Hello %d from the client with rank %u",
seq_id, withRank);
uip_udp_packet_sendto(client_conn, buf, strlen(buf),
&server_ipaddr, UIP_HTONS(UDP_SERVER_PORT));
}
4. Tạo 2 DODAG root trong 1 Instance

Copy file udp-server.c trong đƣờng dẫn ~/contiki/examples/ipv6/rpl-udp/
thành hai file udp-server1.c và udp-server2.c
Trong file udp-server1.c sửa code
uip_ds6_addr_add(&ipaddr, 0, ADDR_MANUAL);

root_if = uip_ds6_addr_lookup(&ipaddr);
if(root_if != NULL) {
rpl_dag_t *dag;
dag = rpl_set_root(RPL_DEFAULT_INSTANCE,(uip_ip6addr_t
*)&ipaddr);
uip_ip6addr(&ipaddr, UIP_DS6_DEFAULT_PREFIX, 0, 0, 0, 0,
0, 0, 0);
rpl_set_prefix(dag, &ipaddr, 64);
PRINTF("created a new RPL dag\n");
} else {
PRINTF("failed to create a new RPL DAG\n");
}
Thành
rpl_dag_t *dag;
dag = rpl_set_root(0x1e,(uip_ip6addr_t *)&ipaddr);
0, 0, 0);
} else {
}
Trong file udp-server2.c sửa code

rpl_dag_t *dag;
dag = rpl_set_root(RPL_DEFAULT_INSTANCE,(uip_ip6addr_t
*)&ipaddr);
0, 0, 0);
} else {
}
Thành

rpl_dag_t *dag;
dag = rpl_set_root(0x2e,(uip_ip6addr_t *)&ipaddr);
0, 0, 0);
} else {
}
Sau đó thực hiện compile code cho hai file udp-server1.c và udp-server2.c
nhƣ bình thƣờng.
5. Tạo 2 Instance và 2 DODAG root
Trong file ~/contiki/examples/ipv6/rpl-udp/project-conf.h thêm
#define TCPIP_CONF_ANNOTATE_TRANSMISSIONS 1
#define RPL_CONF_MAX_INSTANCES X
Với X là số Instance cần thêm, trong luận văn này X = 2

Trong file ~/contiki/core/net/rpl/rpl-conf.h sửa giá trị
#define RPL_DEFAULT_INSTANCE 0x1e
#define RPL_MAX_INSTANCES 2
Trong file ~/ contiki/core/net/rpl/rpl-icmp6.c sửa code

i = 0;
buffer = UIP_ICMP_PAYLOAD;
dio.instance_id = buffer[i++];
dio.version = buffer[i++];
dio.rank = get16(buffer, i);
i += 2;
PRINTF("RPL: Incoming DIO (id, ver, rank) = (%u,%u,%u)\n",

(unsigned)dio.instance_id,
(unsigned)dio.version,
(unsigned)dio.rank);
dio.grounded = buffer[i] & RPL_DIO_GROUNDED;

dio.mop = (buffer[i]& RPL_DIO_MOP_MASK) >>
RPL_DIO_MOP_SHIFT;
dio.preference = buffer[i++] & RPL_DIO_PREFERENCE_MASK;
dio.dtsn = buffer[i++];
Thành
i = 0;
i += 2;
if (dio.instance_id != 0x1e)
goto discard;


RPL_DIO_MOP_SHIFT;
Thực hiện compile code cho 2 file udp-server.c và udp-client.c ra đƣợc 2 file
có định dạng udp-server.* và udp-client.* (cụ thể trong luận văn là udp-server.z1
và udp-client.z1). Sau đó copy 2 file udp-server.z1 và udp-client.z1 ra một folder
khác folder gốc.
Trong file ~/contiki/core/net/rpl/rpl-conf.h sửa giá trị
#define RPL_DEFAULT_INSTANCE 0x2e
Trong file ~/contiki/examples/ipv6/rpl-udp/rpl-icmp6.c sửa code

i = 0;

i += 2;
goto discard;


RPL_DIO_MOP_SHIFT;
Thành
i = 0;
i += 2;
goto discard;


RPL_DIO_MOP_SHIFT;

Thực hiện compile code cho 2 file udp-server.c và udp-client.c ra đƣợc 2 file
có định dạng udp-server.* và udp-client.*

(123doc) Dinh Tuyen Cho Mang Internet of Things

Uploaded by

Document Information

Original Title

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

(123doc) Dinh Tuyen Cho Mang Internet of Things

Uploaded by

Copyright:

Available Formats

BỘ GIÁO DỤC VÀ ĐÀO TẠO

TRƢỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI

NGUYỄN HẢI NAM

ĐỊNH TUYẾN CHO MẠNG INTERNET OF THINGS

Chuyên ngành : Kỹ thuật máy tính

LUẬN VĂN THẠC SĨ KỸ THUẬT

NGƢỜI HƢỚNG DẪN KHOA HỌC

BẢN XÁC NHẬN CHỈNH SỬA LUẬN VĂN THẠC SĨ

Ngày tháng năm 2017

Chủ tịch hội đồng

Xin trân trọng cảm ơn!

Nguyễn Hải Nam

Học viên thực hiện: Nguyễn Hải Nam – CB140334 I

Hà Nội, ngày tháng năm 2017

Nguyễn Hải Nam

Học viên thực hiện: Nguyễn Hải Nam – CB140334 II

Học viên thực hiện: Nguyễn Hải Nam – CB140334 III

Học viên thực hiện: Nguyễn Hải Nam – CB140334 IV

Học viên thực hiện: Nguyễn Hải Nam – CB140334 V

Học viên thực hiện: Nguyễn Hải Nam – CB140334 VI

Học viên thực hiện: Nguyễn Hải Nam – CB140334 VII

Học viên thực hiện: Nguyễn Hải Nam – CB140334 VIII

Học viên thực hiện: Nguyễn Hải Nam – CB140334 1

OSI Layer IoT Layer IoT Technology Testing System

Học viên thực hiện: Nguyễn Hải Nam – CB140334 2

Học viên thực hiện: Nguyễn Hải Nam – CB140334 3

Học viên thực hiện: Nguyễn Hải Nam – CB140334 4

Học viên thực hiện: Nguyễn Hải Nam – CB140334 5

Học viên thực hiện: Nguyễn Hải Nam – CB140334 6

Hình 1.3. Cấu trúc header của cơ chế UDP/6LoWPAN

Học viên thực hiện: Nguyễn Hải Nam – CB140334 7

Học viên thực hiện: Nguyễn Hải Nam – CB140334 8

Học viên thực hiện: Nguyễn Hải Nam – CB140334 9

Học viên thực hiện: Nguyễn Hải Nam – CB140334 10

Học viên thực hiện: Nguyễn Hải Nam – CB140334 11

Học viên thực hiện: Nguyễn Hải Nam – CB140334 12

Học viên thực hiện: Nguyễn Hải Nam – CB140334 13

Học viên thực hiện: Nguyễn Hải Nam – CB140334 14

Học viên thực hiện: Nguyễn Hải Nam – CB140334 15

Học viên thực hiện: Nguyễn Hải Nam – CB140334 16

Hình 2.1. Mô hình RPL DODAG

Học viên thực hiện: Nguyễn Hải Nam – CB140334 17

Học viên thực hiện: Nguyễn Hải Nam – CB140334 18

Hình 2.2. RPL instance và DODAG sequence number

Học viên thực hiện: Nguyễn Hải Nam – CB140334 19

Học viên thực hiện: Nguyễn Hải Nam – CB140334 20

Hình 2.3. Cấu trúc bản tin điều khiển RPL

Hình 2.4. Cấu trúc bản tin DIS

Học viên thực hiện: Nguyễn Hải Nam – CB140334 21

Hình 2.5. Cấu trúc bản tin DIO

Học viên thực hiện: Nguyễn Hải Nam – CB140334 22

Học viên thực hiện: Nguyễn Hải Nam – CB140334 23

Hình 2.6. Cấu trúc sub-option

Hình 2.7. Cấu trúc DIO – Pad 1

Học viên thực hiện: Nguyễn Hải Nam – CB140334 24

Hình 2.9. Cấu trúc DIO-metric container

Học viên thực hiện: Nguyễn Hải Nam – CB140334 25

Hình 2.11. Cấu trúc DODAG Configuration

Học viên thực hiện: Nguyễn Hải Nam – CB140334 26

Học viên thực hiện: Nguyễn Hải Nam – CB140334 27

Học viên thực hiện: Nguyễn Hải Nam – CB140334 28

Hình 2.12. Cấu trúc bản tin DAO

Học viên thực hiện: Nguyễn Hải Nam – CB140334 29