WSN (Demo) (Recovered)

ĐẠI HỌC QUỐC GIA TP.
HỒ CHÍ MINH
TRƯỜNG ĐẠI HỌC BÁCH KHOA
KHOA ĐIỆN – ĐIỆN TỬ
BỘ MÔN VIỄN THÔNG
---------------o0o---------------
BÁO CÁO BÀI TẬP LỚN

MẠNG CẢM BIẾN KHÔNG DÂY & ỨNG DỤNG
RPL Border Router

1. Nguyễn Công Đoàn 1810111
2. Nguyễn Thị Mỹ Thu 1814215
3. Nguyễn Hoàng Nhâ ̣t Long 1810295
Sinh viên thực hiện:
4. Trương Minh Long 1810309
5. Cao Vũ Thức 1810577
2.
11
TP. HỒ CHÍ MINH, THÁNG 5 NĂM 2021
1|Wireless Sensor Network

Contents
LÝ THUYẾT............................................................................................................3
1. RPL - Routing Protocol for Low Power and Lossy Network..............................3
1.1 Giao thức.......................................................................................................3
1.1.1 Tổng quan về RPL...............................................................................3
1.1.2 Mô hình RPL DAG..............................................................................3
1.1.3 Các khái niệm......................................................................................4
1.1.4 Các bảng tin điều khiển.......................................................................5
1.2 Quá trình định tuyến...................................................................................10
1.2.1 Quá trình khởi tạo mạng...................................................................10
1.2.2 Các quy tắc trong quá trình lựa chọn DAG......................................11
1.2.3 Tính toán rank và sự di chuyển của các node trong DAG................11
1.2.4 Truyền dữ liệu....................................................................................11
2. RPL trong Contiki...........................................................................................12
2.1 Cấu trúc.......................................................................................................12
2.2 Thuật toán định tuyến với Contiki RPL......................................................13
2.2.1 Quá trình hoạt động của DAGROOT:...............................................13
2.2.2 Quá trình hoạt động của các node thành viên..................................15
2.2.3 Cơ chế xử lý bản tin DIO và xây dựng DAG.....................................16
2.2.4 Cơ chế điều khiển sự kiện của UDP-client........................................18
3. Border Router......................................................................................................19
4. UDP.....................................................................................................................22
4.1 Khái niê ̣m......................................................................................................22

4.2 Các đă ̣c tính của UDP....................................................................................22
4.3 Cấu trúc của UDP..........................................................................................22
4.3.1 Tiêu đề UDP...........................................................................................22
4.3.2 Dữ liê ̣u (data).........................................................................................23
4.4 Ứng dụng của UDP.......................................................................................24
MÔ PHỎNG/KIỂM TRA KẾT QUẢ..................................................................25
5. Những chương trình được sử dụng khi mô phỏng RPL Border Router..............25
5.1 Phân tích chương trình border-router.c.........................................................25
5.2 Phân tích các khối chương trình chính trong udp-server.c............................33
5.3 Phân tích file makefile...................................................................................36
5.4 httpd-simple.c..............................................................................................38
5.5 slip-bridge.c................................................................................................45
5.6 SLIP (Serial Line Internet Protocol – Giao thức Internet nối tiếp).............48
6. Mô phỏng.............................................................................................................50
6.1 Tutorial về sử dụng Simulator (cooja)...........................................................50
6.1.1 Cài đặt InstantContiki 2.7...................................................................50
6.1.2 Cooja simulator...................................................................................50
6.2 Tutorial về sử dụng Tunslip utility................................................................64
6.2.1 Định nghĩa về Tunslip utility.........................................................................64
6.2.2 Tutorial về Tunslip utility..............................................................................65

.................................................................................................................................68
 Quay lại Cooja simulator, nhìn vào hô ̣p thoại Serial Socket, thông báo đã đổi
thành: Client connected: /127.0.0.1 sau khi kết nối................................................68

.................................................................................................................................69
7. Kiểm tra kết quả..............................................................................................70
Để kiểm tra kết nối của địa chỉ, ta dùng lê ̣nh PING. PING (Packet InterNet
Grouper) là mô ̣t câu lê ̣nh được sử dụng trên webtool IPv6 online, để kiểm tra xem
mô ̣t máy chủ cụ thể có thể truy câ ̣p được qua mạng IP hay không. Nó hoạt đô ̣ng
bằng cách gửi các gói “echo request” đến địa chỉ đích và chờ nhâ ̣n phản hồi “echo
response” của ICMP. Lê ̣nh PING sẽ cho ta biết thời gian phản hồi (được tính bằng
ms), kiểm tra nếu như có packet loss nào xảy ra và sẽ ghi lại tóm tắt thống kê khi
hoàn tất. Dưới đây là ví dụ minh họa cho mô phỏng ở trên....................................70
 Ta có thể kiểm tra kết nối của địa chỉ bằng lê ̣nh ping6 aaaa::212:7401:1:101
trong Terminal.........................................................................................................70

.................................................................................................................................70
 Ta cũng có thể kiểm tra kết nối của các node khác, ví dụ như node 2............70
.................................................................................................................................71
 Kiểm tra bằng trình duyê ̣t web: Truy câ ̣p vào trình duyê ̣t web, nhâ ̣p địa chỉ
của 1 node. Trình duyê ̣t sẽ hiển thị kết quả như bên dưới.......................................71

.................................................................................................................................71

LÝ THUYẾT
1. RPL - Routing Protocol for Low Power and Lossy
Network
1.1 Giao thức
1.1.1 Tổng quan về RPL
Trong hệ thống mạng LLN, quá trình định tuyến rất khó khăn do công suất thấp và
tín hiệu truyền yếu, nguồn năng lượng pin hạn chế, nhiều hop tham gia vào mạng
và các hop này liên tục thay đổi vị trí. Một giải pháp được phát triển thành công
bởi IETF là RPL dựa trên IPv6 giúp giải quyết vấn đề định tuyến này.
RPL có thể hỗ trợ nhiều tầng liên kết khác nhau, bao gồm các thiết bị hạn chế về
tài nguyên, mất mát dữ liệu,… như tự động trong xây dựng, môi trường công
nghiệp, ứng dụng đô thị. RPL giúp nhanh chóng tạo một hệ thống mạng và truyền
thông tin đến một số lượng lớn các node.
Trong cấu hình thiết lập RPL, các node trong mạng được kết nối thông qua một
đường truyền để đến được thiết bị root. Thiết bị root có trách nhiệm thu thập và
phân phối dữ liệu. Mỗi hệ thống gồm các node và thiết bị root như vậy, ta gọi là
một Destination Oriented Directed Acyclic Graph (DODAG). Đồ thị này được
hình thành bằng cách tính toán các chi phí đường đi sao cho tối ưu nhất.

RPL truyền các thông tin định tuyến qua một lượng lớn các node. Nó hỗ trợ lưu
lượng Multipoint-to-Point (MP2P), Point-to-Multipoint (P2MP), và Point-to-Point
(P2P).
1.1.2 Mô hình RPL DAG
DAG là một topo mạng mà mọi liên kết giữa các node trong DAG đều có xu
hướng nhất định, hướng về một DAGROOT và đảm bảo không tạo ra các vòng lặp
trong DAG.
Hình 1. Mô hình RPL DAG
1.1.3 Các khái niệm

DAG Rank: là thông số cho biết vị trí tương đối của node so với DAG ROOT.
Những node càng xa DAG ROOT thì có rank càng cao. Trong RPL, DAG ROOT
luôn có rank bằng 1.

DAG ROOT: là một node trong DAG, có chức năng tập trung và xử lý dữ liệu từ
các node khác trong mạng gửi đến. Mọi tuyến liên kết trong DAG đều hướng về
và kết thúc tại DAG ROOT.
DAG parent: trong cùng một DAG, 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 đó, node B được
gọi là children của node A.
DAG sibling: node A là một sibling của node B trong một DAG nếu chúng có
cùng rank trong DAG đó.
DODAG: là một DAG đứng riêng lẻ.
DODAG ID: địa chỉ Ipv6 của DAG ROOT.
GROUNDED: Root có kết nối ra bên ngoài, cho phép các node trong DAG giao
tiếp với bên ngoài.
FLOATING: ngược lại với grounded, floating chỉ cho các node giao tiếp trong
phạm vi DAG.
STORING: Các node có lưu trữ bảng định tuyến trên chính node đó. Ngược lại
nếu node không lưu trữ bảng định tuyến thì ta gọi là non-storing.
1.1.4 Các bảng tin điều khiển
Trong RPL đề cập đến 2 hướng định tuyến:
 Upward: chiều đi từ các node ở xa DAGROOT hướng về DAGROOT.
 Downward: chiều đi từ DAGROOT đến các node ở xa hơn.
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, duy trì các DAG, từ đ1o mội node trong DAG có thể xác định đường tối
ưu để gửi dữ liệu về DAGROOT một cách nhanh chóng và hiệu quả.
RPL sử dụng ba loại bản tin điều khiển để quảng bá các thông tin định tuyến trong
mạng gồm:
 DIS
 DIO
 DAO
DIS – DAG Information Solicitation
Bản tin DIS được gửi từ những node tự do trong mạng (các node chưa tham gia
DAG) 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
neighbor 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 trong khi node đang ở trạng thái tự do và được gửi unicast đến
một parent trong DAG 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 DAG của parent đó.
10 | W i r e l e s s S e n s o r N e t w o r k
Cấu trúc bản tin DIS:
Hình 2. Cấu trúc bản tin DIS
DIO – DAG Information Object

DIO là bản tin được tạo ra tại các DAGROOT, mang những thông tin định tuyến
của DAG, được sử dụng để quảng bá các thông tin định tuyến của một DAG 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 DAG phù hợp. Từ đó lựa chọn parent, xác định các thông số
cấu hình và tiếp tục quảng bá thông tin DAG đến các node khác trong mạng.
Cấu trúc của một gói tin DIO gồm hai phần chính:
 Các trường điều khiển: gồm các flag, trường preference, sequence
number, RPL instance, DTSN, DAGID.
 Các sub-option.
Hình 3. Các sub-option
Các trường điều khiển

 Trường prf (DAG preference): sử dụng 3 bit kiểu số nguyên dương cho biết
độ ưu tiên giữa các DAG trong cùng một instance. Miền giá trị của prf từ 0
đến 7. Nếu prf bằng 7, DAG sẽ có độ ưu tiên cao nhất, giá trị mặc định của
prf là 0.
 Sequence number: là giá trị sequence number được thiết lập tại DAG
ROOT, được sử dụng trong quá trình tái xây dựng lại DAG; là một bộ đếm
tuần tự được sử dụng trong quá trình sửa chữa và làm mới DAG. Khi một
DAG ROOT muốn xây dựng lại một DAG mới, sequence number được
tăng lên 1 đơn vị và quảng bá đến các node trong mạng.
 Rank: rank của node gửi DIO.
 RPL Instance ID: cho biết RPL Instance mà DAG tham gia định tuyến.
 DTSN: được thiết lập tại node gửi gói tin DIO, sử dụng trong quá trình duy
trì các thông số định tuyến theo hướng downward.
 DAGID: là một địa chỉ IPv6 có độ dài 128 bit và được thiết lập tại DAG
ROOT.
Các cờ trạng thái của DAG:
 Flag G: cho phép xác định khả năng kết nối đến một grounded DAG 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 DAG. Ngược lại, nếu cờ này khác không cho biết node gửi DIO là
thành viên của một grounded DAG.
 Flag A: cho biết khả năng hỗ trợ cơ chế quảng bá đích trong quá trình định
tuyến downward của DAG. Nếu A khác 0, DAG ROOT có khả năng hỗ trợ
cơ chế quảng bá đích và các node trong DAG có thể tham gia quá trình định
tuyến downward. Nếu A bằng không, các node trong DAG chỉ có thể tham
gia định tuyến upward.
 Flag T: đượ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 DAG sẽ thực hiện quá trình làm mới các tuyến
downward.
 Flag S: nếu flag S bằng 0, chỉ có DAG ROOT được phép lưu trữ các thông
tin định tuyến downward từ các gói tin DAO. Nếu S khác 0, node gửi DIO
có thể lưu trữ các thông tin định tuyến từ DAO.
Các sub-option được dùng để chèn các byte trống vào các gói tin DIO.
Có 5 loại sub-option bao gồm: Pad 1, Pad N, DAG Metric Container, DAG
destination prefix, DAG Configuration. Tùy theo mục đích sử dụng mà các sub-
option được chèn vào DIO một cách hợp lý. Cấu trúc 1 sub-option cơ bản như sau:
Suboption Suboption Length Suboption DATA

Type
Nguyên lý gửi, nhận và xử lý thông tin DIO:

DIO đầu tiên được tạo ra tại DAG ROOT, sau đó được quảng bá đến các node
trong mạng. Các node thành viên trong DAG sử dụng gói tin DIO nhận được để
cập nhật thông tin DAG, lựa chọn parent và quảng bá vị trí của mình trong DAG.
Node xử lý DIO phải tuân theo các nguyên tắc sau:
 Một node chỉ tạo và gửi bản tin DIO sau khi tham gia một DAG xác định.
 Những node không phải DAG ROOT, chỉ được phép thay đổi giá trị các
flag S, DTSN và rank trong gói tin DIO.
 DIO là hợp lệ nếu có Instance ID hợp lệ. Khi một node nhận được một gói
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 hợp lệ, thì node mới thực hiện các hành động tiếp
theo.
DAO – Destination Advertisment Object
DAO là gói tin được 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 DAG.
DAO được được sử dụng nhằm mục đích cho những ứng dụng đòi hỏi lưu lượng
kiểu P2MP và P2P. Thông qua xử lý thông tin nhận được từ DIO, DAG 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 DAG. Từ đó, đưa ra các tuyến tối ưu cho hường
downward.
Gói tin DAO có cấu trúc như sau:
Hình 4. Cấu trúc gói tin DAO
DAO Sequence: số gói tin DAO được một node gửi vào mạng.
DAO rank: rank của node tạo gói 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 lifetime: thời gian sống hiệu lực của prefix, phục vụ cho việc xác định khả
năng sống của 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 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ị của
RR count.
Các sub-option được sử dụng nhằm mở rộng các thành phần của gói tin DAO, tùy
theo mục đích nghiên cứu và triển khai.
Nguyên lý truyền gói tin DAO:
Các gói tin Dao được truyền từ các node ở rank cao đến những node ở rank thấp
nhằm quảng bá các trạng thái định tuyến downward cho từng prefix của những
nhóm hoặc những Sub-DAG bên trong DAG. Cơ chế định tuyến với DAO chỉ có
thể hoạt động khi node đã tham gia ít nhất một DAG trong mạng.
Cơ chế định tuyến với DAO chỉ có thể được sử dụng trong từng DAG, được bởi
DAG ROOT. Việc xác định cơ chế này thông qua Flag A của gói tin DIO truyền
đi từ ROOT DAG.
Khi cơ chế này được sử dụng, trong DAG 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 DAG ROOT. Khi cơ chế này không
được sử dụng, các node không được phép tạo và xử lý các gói tin DAO.
Gói tin DAO được gửi từ node đến một hoặc một nhóm các DAG parent của node
trong DAG. 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 prefix như: địa chỉ
IPv6, địa chỉ Interface, DAO sequence, DAO rank, DAO lifetime,.. Nhờ đó, một
node có thể xác định trạng thái của những prefix.
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 DAO,
các node rank thấp có thể định tuyến nhằm phục vụ cho những ứng dụng kiểu
P2MP hoặc P2P.
1.2 Quá trình định tuyến
1.2.1 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ố DAG 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 DAG 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 các node xung quanh để xây
dựng DAG của bản thân.
Trong pha khởi tạo, những node trong mạng có thể lựa chọn một trong hai chế độ
hoặc chúng giữ trạng thái im lặng và không gửi bất kì gói tin DIO nào cho đến khi
chúng tham gia và một DAG xác định; hoặc ngay lập tức thiết lập là DAG ROOT
của một floating DAG, 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 gói 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 các yêu cầu trên.
Những node gần root nhất khi nhận được DIO từ DAG ROOT sẽ tham gia vào
DAG, cập nhật thông tin trong DIO và xác định rank của bản thân trong DAG.
Node định thời chuyển tiếp các gói tin DIO đến những node xung quanh, quảng bá
vị trí và DAG mà nó đang tham gia.
Quá trình trên được các thành viên trong DAG lặp đi lặp lại liên tục tại những thời
điểm định thời. Do đó, quy mô DAG được mở rộng tới những node ở xa DAG
ROOT và những node trong DAG cập nhật được thông tin của những thành viên
xung quanh trong DAG.
Một node ở trạng thái tự do (chưa tham gia vào DAG) sẽ định kỳ gửi các gói 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 thông tin về DAG (DIO) mà chúng
tham gia.
Khi một neighbor nhận được bản tin DIS, nếu đã tham gia vào một DAG 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 khi thời điểm xử lý bản tin DIS mà không chờ
đến 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á DAG linh động và hiệu quả hơn.
1.2.2 Các quy tắc trong quá trình lựa chọn DAG
Cơ chế lựa chọn DAG là sự kết hợp giữa cơ chế so sánh độ ưu tiên của các DAG
và các luật được quy định trong Object function. Độ ưu tiên của các DAG được
thể hiện thông qua trường DAG preferred trong gói tin DIO được gửi bởi
DAGROOT. Nhờ đó, mỗi node trong mạng đều có thể lựa chọn những DAG đượ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 đưa ra.
 DAG tham gia phải đáp ứng instance của một node.
 DAG tham gia phải có độ ưu tiên cao nhất và node có rank thấp nhất.
 DAG tham gia phải thỏa mãn các object function của node.
Sau quá trình khám phá và tham gia DAG trong mạng, mỗi node xử lý các thông
tin trong DIO à 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 DAG.
1.2.3 Tính toán rank và sự di chuyển của các node trong DAG
Lựa chọn rank là quá trình xác định vị trí tương đối của node so với DAGROOT
trong DAG, đồ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 Object function
ứng với mỗi Instance cụ thể.
Rank của node phải đảm bảo các 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 gói tin trước đó. Sự thay đổi đó phụ thuộc vào rank của các parent
trong DAG.
 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 DAG nào trong mạng.
 Tại mọi thời điểm, node có thể tham gia vào một DAG mới trong cùng RPL
Instance và thay đổi rank phù hợp. Trong thời gian trước khi quảng bá các
gói tin DIO cho DAG mới, node vẫn tiếp tục gửi các gói tin đến các parent
trong DAG cũ.
1.2.4 Truyền dữ liệu
Sau quá trình xây dựng DAG, các node trong DAG tạo các gói dữ liệu và bắt đầu
gửi gói tin đến DAGROOT. Để gửi gói đến DAGROOT, 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 lựa chọn. Việc
lựa chọn next-hop phải tuân theo các 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:
 Next-hop là một node đã tham gia vào một DAG đá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
(OSPF,EIGRP,…) thì node đó được chọn làm next-hop.
 Nếu node là thành viên của một DAG 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 DAG 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 tin không thể 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 DAG
ROOT.
2. RPL trong Contiki

2.1 Cấu trúc
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 không tin cậy UDP/IP trên nền 6LoWPAN.
Kiến trúc giao thức mạng của Contiki RPL như trong hình sau:
Hình 5. Kiến trúc giao thức mạng Contiki RPL
Cấu trúc Contiki RPL:
Hình 6. Cấu trúc Contiki RPL
2.2 Thuật toán định tuyến với Contiki RPL

Trong pha đầu tiên khi khởi tạo mạng, những node được lựa chọn làm DAGROOT 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 DAG
như DAGID, RPLInstanceID, Object function,… Những thông tin của DAG được
DAGROOT đư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 DAG, DAGROOT nhận các gói tin được gửi về từ những node khác trong
DAG.
2.2.1 Quá trình hoạt động của DAGROOT:
Hoạt động của DAGROOT được sơ đồ hóa như sau:
Hình 7. Hoạt đô ̣ng của DAGROOT

DAGROOT hoạt động theo cơ chế event-driven, tùy theo những sự kiện
đến cụ thể, DAGROOT đưa ra những hoạt động tương ứng.
Hình 8. Cơ chế điều khiển sự kiêṇ của DAGROOT
2.2.2 Quá trình hoạt động của các node thành viên
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 khi node chưa tham gia vào bất kỳ DAG nào.
Hình 9. Pha khởi tạo của những note UDP-client
2.2.3 Cơ chế xử lý bản tin DIO và xây dựng DAG
Hình 20. Cơ chế xử lý bản tin DIO
Cơ chế xử lý bản tin DIO dựa trên một số nguyên tắc cơ bản như sau:
 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 vào bất kỳ DAG nào thì tham gia vào DAG của
node gửi DIO
 Nếu nhận được bản tin DIO của một DAG mà node không phải thành viên
và nếu việc tham gia vào DAG này khiến node có rank thấp hơn thì node sẽ
gia nhập DAG mới.
 Nếu DIO đến từ một node trong cùng một DAG và sequence number đã
được tăng lên thì node tham gia quá trình sửa chữa DAG.
 Nếu DIO trong cùng DAG, 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 DAG.
 Nếu DIO từ một parent trong DAG, trước hết cần phải 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 nào thay
thế.
 Best parent là node thuộc DAG có thứ tự ưu tiên cao nhất và có rank thấp
nhất.
2.2.4 Cơ chế điều khiển sự kiện của 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 đ1o node tham gia những
DAG 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.
Hình 31. Cơ chế điều khiển sự kiêṇ UDP-client
3. Border Router
Border router (hay edge router) thường là thiết bị nằm ở biên mạng của chúng ta, cho
phép giao tiếp với các mạng bên ngoài bằng giao diện mạng tích hợp của nó, chẳng hạn
như Wifi, Ethernet, Serial,… Ví dụ trong Contiki, border router sẽ được sử dụng để định
tuyến dữ liệu giữa WSN (mạng RPL) và mạng IP bên ngoài.
Hình 42. Ví dụ về Border-Router
Trong hầu hết ứng dụng dùng border router triển khai một giao diện gọi là SLIP, cho
phép kết nối một vi mạch nhất định với máy chủ lưu trữ bằng cách sử dụng các tập lệnh
được Contiki cung cấp như tunslip6 qua cổng nối tiếp, tạo một cầu nối mạng được cấp
tiền tố IPv6 để đặt địa chỉ IPv6 toàn cầu.
Có thể hình dung hoạt động của tunslip6 như sau: Các gói IPv6 mà máy chủ nhận được
là chuyển tiếp qua kết nối USB tới border router qua tunslip6 và sau đó tất cả các gói
không dây 6LoWPAN được border router chuyển tiếp tới máy chủ lưu trữ dưới dạng gói
IPv6 thông qua kết nối USB thông qua tunslip6.
Hình 53. Border Router trong Contiki
4. UDP
4.1 Khái niệ m
UDP (User Datagram Protocol) là một trong những giao thức cốt lõi của giao thức
TCP/IP. Dùng UDP, chương trình trên mạng máy tính có thể gửi những dữ liệu ngắn
được gọi là datagram tới máy khác. UDP không cung cấp sự tin cậy và thứ tự truyền nhận
mà TCP làm; các gói dữ liệu có thể đến không đúng thứ tự hoặc bị mất mà không có
thông báo. Tuy nhiên UDP nhanh và hiệu quả hơn đối với các mục tiêu như kích thước
nhỏ và yêu cầu khắt khe về thời gian. Do bản chất không trạng thái của nó nên nó hữu
dụng đối với việc trả lời các truy vấn nhỏ với số lượng lớn người yêu cầu.
Những ứng dụng phổ biến sử dụng UDP như DNS (Domain Name System), ứng dụng
streaming media, Voice over IP, Trivial File Transfer Protocol (TFTP), và game trực
tuyến.
4.2 Các đặ c tính của UDP

 Định hướng giao dịch, không đảm bảo việc phân phối và bảo vệ trùng lặp.
 Sử dụng mô hình truyền đơn giản, không sử dụng các hộp thoại bắt tay để đảm
bảo tính tin cậy. Trật tự và tính vẹn toàn dữ liệu.
 Cung cấp Datagram.
 Không có độ trễ.
4.3 Cấu trúc của UDP

4.3.1 Tiêu đề UDP
UDP là giao thức hướng thông điệp nhỏ nhất của tầng giao vận hiện được mô tả trong
RFC 768 của IETF.
Trong bộ giao thức TCP/IP, UDP cung cấp một giao diện rất đơn giản giữa tầng mạng
bên dưới (thí dụ, IPv4) và tầng phiên làm việc hoặc tầng ứng dụng phía trên.
UDP không đảm bảo cho các tầng phía trên thông điệp đã được gửi đi và người gửi cũng
không có trạng thái thông điệp UDP một khi đã được gửi (Vì lý do này đôi khi UDP còn
được gọi là Unreliable Datagram Protocol).
UDP chỉ thêm các thông tin multiplexing và giao dịch. Các loại thông tin tin cậy cho việc
truyền dữ liệu nếu cần phải được xây dựng ở các tầng cao hơn.
Tiêu đề UDP gồm 4 trường: cổng nguồn (source port), cổng đích (destination port), độ
dài (length), checksum. Mỗi trường đều chiếm 2 byte (16 bits), cụ thể:
Hình 64. Cấu trúc gói tin UDP
Phần header của UDP chỉ chứa 4 trường dữ liệu, trong đó có 2 trường là tùy chọn (ô nền
đỏ trong bảng).
Source port
Trường này xác định cổng của người gửi thông tin và có ý nghĩa nếu muốn nhận thông
tin phản hồi từ người nhận. Nếu không dùng đến thì đặt nó bằng 0.
Destination port
Trường xác định cổng nhận thông tin, và trường này là cần thiết.
Length
Trường có độ dài 16 bit xác định chiều dài của toàn bộ datagram: phần header và dữ liệu.
Chiều dài tối thiểu là 8 byte khi gói tin không có dữ liệu, chỉ có header.
Checksum
Trường checksum 16 bit dùng cho việc kiểm tra lỗi của phần header và dữ liệu. Phương
pháp tính checksum được định nghĩa trong RFC 768.
4.3.2 Dữ liệ u (data)

Dữ liệu thì tùy thuộc vào ở giao thức Ipv4 hay Ipv6 mà có độ dài khác nhau (đã được liệt
kê ở phần độ dài).
Hình 15. Gửi gói tin UDP
4.4 Ứng dụng của UDP

Do thiếu tính tin cậy, các ứng dụng UDP nói chung phải chấp nhận mất mát, lỗi hoặc
trùng dữ liệu. Một số ứng dụng như TFTP có nhu cầu phải thêm những kỹ thuật làm tin
cậy cơ bản vào tầng ứng dụng. Hầu hết các ứng dụng UDP không cần những kỹ thuật làm
tin cậy này và đôi khi nó bị bỏ đi. Streaming media, game trực tuyến và voice over IP
(VoIP) là những thí dụ cho các ứng dụng thường dùng UDP. Nếu một ứng dụng đòi hỏi
mức độ cao hơn về tính tin cậy, những giao thức như TCP hoặc mã erasure có thể được
sử dụng để thay thế.
Thiếu những cơ chế kiểm soát tắc nghẽn và kiểm soát luồng, các kỹ thuật dựa trên mạng
là cần thiết để giảm nguy hiệu ứng cơ tắc nghẽn dây chuyền do không kiểm soát, tỷ lệ tải
UDP cao. Nói cách khác, vì người gởi gói UDP không thể phát hiện tắc nghẽn, các thành
phần dựa trên mạng như router dùng hàng đợi gói (packet queueing) hoặc kỹ thuật bỏ gói
như là những công cụ để giảm tải của UDP. Giao thức Datagram Congestion Control
Protocol (DCCP) được thiết kế như một giải pháp cho vấn đề bằng cách thêm hành vi
kiểm soát tắc nghẽn cho thiết bị đầu cuối cho các dòng dữ liệu UDP như streaming
media.
Mặc dù tổng lượng lưu thông của UDP trên mạng thường chỉ vài phần trăm, nhưng có
nhiều ứng dụng quan trọng dùng UDP, bao gồm DNS, SNMP, DHCP và RIP.
MÔ PHỎNG/KIỂM TRA KẾT QUẢ
5. Những chương trình được sử dụng khi mô phỏng
RPL Border Router
- border-router.c
- udp-server.c (hoă ̣c udp-client.c, nhưng trong báo cáo này, nhóm sử dụng udp-server.c)
- slip-bridge.c (đây là chương trình chứa callback function để xử lý mô ̣t gói tin SLIP
connection request (Serial Line Interface Protocol)
- httpd-simple.c (mô ̣t server web đơn giản)
5.1 Phân tích chương trình border-router.c

Border-router.c là chương trình dùng để cấu hình mô ̣t nút mạng trở thành mô ̣t border
router. Trong chương trình này, nút mạng sẽ chờ để được gán prefix. Khi nút mạng nhâ ̣n
được prefix, border router sẽ được thiết lâ ̣p và bắt đầu gán prefix cho các nút mạng khác.
Chương trình border-router.c giúp cho border router giao tiếp được với các nút trong
mạng RPL, đồng thời đóng vai trò là cầu nối giữa mạng RPL và mạng ngoài (trong mô
phỏng này là mạng Internet).
Tiếp theo, nhóm sẽ phân tích các khối chương trình chính được sử dụng trong file border-
router.c.
Đầu tiên, các thư viê ̣n và header files cần thiết sẽ được khai báo trong chương trình:
contiki.h, dev/slip.h, stdio.h,… .
Hình 16. Khai báo thư viên và header files trong border-router.c
Theo mă ̣c định, border router sẽ quản trị mô ̣t trang web đơn giản. Tuy nhiên, tính năng
này có thể tắt bằng cách định nghĩa WEBSERVER như trong chương trình bên dưới.
Trang web này sẽ hiển thị khi nhâ ̣p địa chỉ IPv6 của border router vào trình duyê ̣t. Hình
dưới đây là phần chương trình liên quan đến WEBSERVER trong file border-router.c:
Hình 17. Khối chương trình liên quan đến WEBSERVER

Hai process chính ở trong chương trình border-router.c là border_router_process và
webserver_nogui_process. Hình bên dưới là đoạn chương trình
webserver_nogui_process:
Hình 18. Webserver-nogui-process
Kế đến là border_router_process, process này chứa vòng lă ̣p thực hiê ̣n chức năng của
border router, bao gồm nhâ ̣n prefix, gán prefix và định tuyến các nút trong mạng RPL.
Hình 19. Border-router-process

Trong quá trình đợi prefix được gửi thông qua kết nối SLIP, thiết bị có thể tham gia mô ̣t
DAG có sẵn. Kết nối này sẽ bị cắt khi border router nhâ ̣n được prefix từ kết nối SLIP.
Viê ̣c này tránh được hiê ̣n tượng thiết bị tự ngắt sóng radio trong quá trình thiết lâ ̣p mạng.
Ngoài ra còn có các chương trình khác được định nghĩa trong border-router.c:
 Request_prefix(): Yêu cầu prefix thông qua kết nối SLIP máy tính
Hình 20. Hàm request_prefix()
 Set_prefix_64(): Tạo prefix cho mạng RPL
Hình 21. Hàm thiết lâ ̣p prefix, tạo mô ̣t RPL dag mới từ prefix nhâ ̣n được
 Print_local_addresses(): in các địa chỉ có trong mạng RPL
Hình 22. Hàm in địa chỉ IPv6
 Ipaddr_add(): Thêm mô ̣t địa chỉ IPv6 mới vào trong mạng
Hình 23. Ippaddr_add()

 Tiến trình tạo routes tới các nút trong mạng
Hình 24. Mô ̣t phần của chương trình tạo route tới các nút mạng
5.2 Phân tích các khối chương trình chính trong udp-server.c
Nhiê ̣m vụ của mô ̣t nút mạng udp-server là tạo mô ̣t DAG với border router. Border router
sau đó sẽ nhâ ̣n prefix thông qua kết nối SLIP (Serial Line Interface Protocol) và giao tiếp
với các nút khác trong mạng RPL
Hình 25. udp-server.c flow chart
Phân tích cụ thể các code block có trong udp-server.c:
Đầu tiên, thiết lâ ̣p khởi đô ̣ng UDP server:
Hình 26. Khởi đô ̣ng UDP server

Các khối chương trình tạo địa chỉ IPv6 cho UDP server. Địa chỉ IPv6 này có dạng
aaaa::/64
Hình 27. Khởi tạo RPL DAG
Khối chương trình thiết lâ ̣p kết nối UDP giữa server và client (nếu có):
Hình 28. Tạo kết nối UDP
Gửi và nhâ ̣n gói tin TCP/IP:
Hình 29. Nhâ ̣n gói tin TCP/IP
Hình 30. Nhâ ̣n và in dữ liêụ đã nhâ ̣n
5.3 Phân tích file makefile

Muốn chạy được project ta cần có mô ̣t file makefile để khai báo các thông số cần thiết
của project này. Trong RPL border router, file makefile có thể chia làm 2 khối chính:
khối 1 bao gồm viê ̣c đă ̣t tên project và đường dẫn, khối 2 dùng để khai báo mô ̣t số giá trị
sử dụng trong chương trình chính.
Hình 31. Phần chương trình khai báo tên project và sourfiles
Có thể thấy, ở trong makefile đã định nghĩa sẵn PREFIX=aaaa::1/64, WEBSERVER=1
(tức là sẽ chạy internal webserver) và các đường dẫn liên quan tới tunslip6.
Hình 32. Phần còn lại của makefile
5.4 httpd-simple.c
🡪 “Tạo trang chuyển tiếp máy chủ web đơn giản đến luồng protothread”
🡪 Mục đích của chương trình này là để chạy web server nhỏ và nhận HTTP request
từ udp-server node
Đầu tiên, cần thêm file từ “httpd-simple.h” cũng như định nghĩa về một số biến sẽ sử
dụng như URLCONV (0), STATE_OUTPUT (1), …
Hình 33
1 số hàm được sử dụng trong chương trình:
Hình 34. Mô ̣t số hàm được sử dụng
Để gửi 1 chuỗi qua protothread, dùng PT_THREAD(send_string(struct httpd_state *s,

const char *str))
Khai báo char http_content_type_html cho content JSON. Sau đó dùng
PT_THREAD(send_headers(struct httpd_state *s, const char *statushdr)) để dán
vào HTTP header.
Hình 35
Để xử lý output và đưa lên web server, dùng PT_THREAD(handle_output(struct

httpd_state *s)), nếu không tìm thấy script, web server hiện “404 - NOT FOUND”, nếu
nhận được script thì hiện “200 OK”.
Hình 36
Hình 37
PT_THREAD(handle_input(struct httpd_state *s)) xử lý phần input bằng cách đối

chiếu input với char “GET ” khai báo sẵn, sau đó tiến hành đổi input sang link file URL
có chiều dài bằng với chiều dài của input buffer
Hình 38
Sau đó, filename URL ở trên sẽ được publish lên log file của web server, đưa vào trạng
thái sẵn sàng (STATE_OUTPUT = 1)
Hình 39
Hàm handle_connection kiểm tra trạng thái sẵn sàng trong protothread handle_input để
có thể tiếp tục chạy protothread handle_output
Hình 40
Hàm httpd_init được sử dụng để nghe port TCP, với số của port là số sau khi chuyển đổi
số 16 bit từ số byte host theo thứ tự sang số byte mạng (host byte order to network byte
order), đồng thời kích hoạt chuyển đổi URL sang filename.
Hình 41
Hàm httpd_appcall chứa structure xử lý kết nối UIP, kiểm tra các trường hợp nếu kết
nối bị gián đoạn, quá thời gian quy định hoặc không có để giải phóng bộ nhớ hoặc đưa
vào trạng thái chờ kết nối để thử lại cho tới khi kết nối được, và ghi lại tất cả vào log file
nếu có lỗi xuất hiện và reset lại webserver (như lỗi “không có vùng nhớ” (no memory
block) và lỗi “quá thời gian” (timeout))
Hình 42
5.5 slip-bridge.c
🡪 Chứa hàm gọi lại (callback function – hàm được truyền vào một hàm khác như
một tham số đầu vào và được gọi kích hoạt bên trong hàm này) để xử lý một yêu cầu kết
nối SLIP.
Hình 43
Hàm init khởi tạo trình điều khiển SLIP và cổng RS232 với baudrate được set ở 115200,
đồng thời gọi hàm slip_input_callback với nhiệm vụ phát hiện gateway node trên giao
diện SLIP.
Hình 44
Hàm output so sánh đoạn tin vừa gửi có khớp với đoạn tin có trong bộ đệm hay không,
tránh việc gói tin bị trả ngược qua SLIP nếu gói tin đó đã được nhận qua SLIP, nếu có thì
đưa ra thông báo: “Điểm đến nằm ngoài liên kết nhưng không có tuyến đường”, còn
không thì sẽ gửi đi gói tin IP từ bộ đệm uIP bằng SLIP.
Hàm slip_input_callback chịu trách nhiệm nhận các packet thông qua SLIP, tạo prefix
và kiểm tra hoạt động, ngoài ra còn lưu lại đoạn tin đã nhận qua SLIP để tránh gửi ngược
về nguồn phát nếu như không tìm thấy tuyến đường.
Hình 45
5.6 SLIP (Serial Line Internet Protocol – Giao thức Internet nối
tiếp)
Giao thức SLIP được quy định bởi tiêu chuẩn RFC 1055. SLIP là một giao thức
rất đơn giản, được sử dụng để truyền các gói của lớp mạng. Được thiết kế để hoạt động
trên các cổng nối tiếp (Serial ports) và kết nối bộ định tuyến (Router connections), cho
phép 2 máy tính kết nối với nhau qua đường tuần tự (RS232), dùng để truy cập từ xa
hoặc trao đổi thông tin giữa hai mạng.
SLIP sửa đổi sơ đồ dữ liệu TCP / IP tiêu chuẩn bằng cách
• Chia một gói dữ liệu IP thành từng byte.
• Thêm vào một byte "END" (có mã ASCII là “192”) vào byte cuối hoặc thêm byte
END vào trước byte đầu tiên để phân biệt ranh giới datagram trong luồng byte.
• Nếu byte END xuất hiện trong dữ liệu, chuỗi hai byte ESC, ESC_END sẽ được
gửi thay thế.
• Nếu byte ESC xuất hiện trong dữ liệu, chuỗi hai byte ESC, ESC_ESC sẽ được gửi
thay thế.
• Các biến thể của giao thức có thể bắt đầu hoặc kết thúc các gói tin bằng END.
• Ký tự ESC của SLIP không giống với ký tự ESC trong ASCII. Cả hai đều thực
hiện một thao tác "thoát" nhưng không liên quan đến nhau
Tóm lại, quy trình sửa đổi của SLIP được biểu diễn như hình sau:
Hình 46
Ký tự “END” (mã hex C0h) ; byte nhiễu (màu đỏ 03h)
SLIP đòi hỏi cấu hình cổng nối tiếp gồm 8bit dữ liệu, không có tính chẵn lẻ, điều khiển
luồng bằng phần cứng EIA hoặc cài đặt UART ở chế độ CLOCAL.
Tuy nhiên, SLIP cũng có một số nhược điểm:
 Chỉ truyền được gói IP, không truyền được các giao thức khác
 Không có khả năng tự xác định được địa chỉ IP máy đối diện
 Không có cơ chế tự sửa đổi, truyền không tốt khi đường truyền bị nhiễu
SLIP cũng không phải giao thức chuẩn của TCP/IP, tuy nhiên vẫn được dùng khá phổ
biến cho truy cập từ xa
6. Mô phỏng
6.1 Tutorial về sử dụng Simulator (cooja)
6.1.1 Cài đặt InstantContiki 2.7
 Contiki là một phần mềm khá dễ dàng để sử dụng, dễ Download và cài đặt.
 Truy cập vào đường link https://sourceforge.net/projects/contiki/files/Instant
%20Contiki/
 Download Contiki2.7, kích thước của phần mềm khoảng hơn 1GB. Khi
download xong, giải nén file zip.
 Tiến hành cài đặt Contiki trên VMWare.
+ Boot Ubuntu. Tiến hành chạy Contiki2.7.vmx. Đợi cho máy ảo Ubuntu
Linux khởi động xong.
+ Login vào Ubuntu với password là user
 Sau khi Contiki đã chạy, chúng ta sẽ tiến hành thao tác trên Cooja.
6.1.2 Cooja simulator

 Để vào Cooja ta mở terminal, gõ câu lệnh: cd contiki/tools/cooja
 Bắt đầu Cooja với dòng lệnh: ant run
Hình 47. Run cooja

 Đợi để Cooja khởi động, khi Cooja hoàn tất quá trình khởi động ta sẽ thấy cửa
sổ màu xanh trống hiện ra.
 Hoă ̣c ta có thể mở Cooja bằng cách mở biểu tượng Cooja trên màn hình.
Hình 48. Cửa sổ Cooja

 Tạo một môi trường giả lập.
+ Click vào File -> New simulation
+ Cửa sổ Create new simulation hiện ra, đặt tên và nhấn Create.
Hình 49. Tạo New Simulator
 Cửa số môi trường giả lập hiện ra, có những thành phần sau:
+ Network: hiện ra mạng lưới giả lập
+ Timeline: hiện ra tất cả các giao tiếp
+ Mote output: in ra tất cả các output
+ Notes: có thể ghi chú lại những gì cần thiết.
+ Simulation Control: chúng ta có thể có những lựa chọn start, pause, reload.
Hình 50. Cửa sổ giả lập
 Thêm mote vào mô hình giả lập
Trước khi giả lập mô hình mạng chúng ta cần phải thêm mote. Ta thực hiện
chuỗi thao tác sau:
Vào menu mote -> Add mote …-> Create new mote type… -> Sky mote…
(Tạo chế độ giả lập Skype mote)
Hình 71. Tạo Sky mote
 Tạo mote type:
Cửa sổ Create mode type hiện ra, chúng ta có thể đặt tên cho mote. Browse…
button để chọn ứng dụng example Contiki.
Hình 52. Cửa sổ Create Mote Type
 Tìm mô phỏng Border Router: Chúng ta truy câ ̣p vào đường link /contiki-
2.7/examples/ipv6/rpl-border-router.
 Chọn file border-router.c. Click vào button Open chọn file.
Hình 53. Chọn example Contiki
- Chạy ứng dụng Contiki: click vào button Compile. Trong quá trình compile,
output complile sẽ hiện trên cửa sổ.
Hình 54. Bắt đầu Compile
Hình 55. Kết quả sau khi compile
- Click vào button Create để hoàn tất quá trình tạo mote type.
- Thêm mote vào trình giả lập: Sau khi hoàn thành quá trình tạo mote type,
Cooja sẽ hỏi thêm mote vào trình giả lập, chúng ta thay đổi Number of new
motes sau đó nhấn vào button Add motes.
Hình 56. Thêm mote
- Bắt đầu chạy giả lập: Sau khi Add motes ta sẽ thấy số node hiện ra trên cửa sổ
Network.
Hình 57. Kết quả sau khi add motes
 Tương tự, chúng ta truy câ ̣p vào đường link /contiki-2.7/examples/ipv6/rpl-
udp.
 Chọn file udp-server.c. Click vào button Open chọn file. Compile, Create và
Add motes như trên. Ở đây ta lấy ví dụ 4 motes, linear positioning.
Hình 58. Chọn example Contiki
Hình 59. Kết quả sau khi compile
Hình 60. Thêm mote
Hình 61. Kết quả sau khi add motes
 Chọn 1 node bất kỳ, chọn More tools for border router -> Serial Socket
(SERVER). Ta sẽ nhâ ̣n được thông báo như hình dưới
Hình 62. Serial Socket (SERVER)
 Ta click vào button Start trong cửa sổ Simulator control để bắt đầu chạy giả lập.
Output sẽ hiện ra ở cửa sổ Mote output. Cửa sổ Network sẽ hiện ra giao tiếp trên
mạng. Cửa sổ Timeline sẽ hiện thời gian giao tiếp giữa các node cũng như địa
chỉ MAC của các node.
Hình 63. Màn hình chạy giả lập
Để dừng tạm thời quá trình giao tiếp này ta có thể nhấn vào button Pause.
 Hoàn thành: chúng ta đã hoàn thành quá trình giả lập giữa các node trong
Contiki
6.2 Tutorial về sử dụng Tunslip utility
6.2.1 Định nghĩa về Tunslip utility

Như đã được đề cập trong phần giới thiệu, RPL Border Router giúp kết nối một
mạng lưới này với mạng lưới khác. Trong ví dụ này, RPL Border Router được
dùng để xác định dữ liệu giữa RPL Border Router và một mạng ở bên ngoài. Ở
phần trên, ta chỉ mới tạo mạng RPL. Bây giờ, việc cần làm là mô phỏng mạng
RPL được liên kết với mạng lưới bên ngoài đó. Ta sẽ dùng Tunslip utility của
Contiki và trong ví dụ này, Tunslip sẽ tạo ra kết nối giữa mạng lưới RPL và máy
chủ.
6.2.2 Tutorial về Tunslip utility
 Mở terminal, gõ câu lệnh: cd /contiki2.7/tools
Hình 64
 Gõ câu lệnh: make tunslip6 để compile tunslip
Hình 65
 Thực hiê ̣n kết nối giữa RPL và máy chủ qua câu lê ̣nh: sudo ./tunslip6 -a
127.0.0.1 aaaa::1/64
Hình 66
 Nhâ ̣p password user , màn hình terminal hiển thị như hình bên dưới, thông báo
đã kết nối thành công.
Hình 67. Kết nối thành công
 Quay lại Cooja simulator, nhìn vào hô ̣p thoại Serial Socket, thông báo đã đổi
thành: Client connected: /127.0.0.1 sau khi kết nối
Hình 68. Serial Socket (SERVER) sau khi kết nối
7. Kiểm tra kết quả
Để kiểm tra kết nối của địa chỉ, ta dùng lê ̣nh PING. PING (Packet InterNet
Grouper) là mô ̣t câu lê ̣nh được sử dụng trên webtool IPv6 online, để kiểm tra xem
mô ̣t máy chủ cụ thể có thể truy câ ̣p được qua mạng IP hay không. Nó hoạt đô ̣ng bằng
cách gửi các gói “echo request” đến địa chỉ đích và chờ nhâ ̣n phản hồi “echo
response” của ICMP. Lê ̣nh PING sẽ cho ta biết thời gian phản hồi (được tính bằng
ms), kiểm tra nếu như có packet loss nào xảy ra và sẽ ghi lại tóm tắt thống kê khi
hoàn tất. Dưới đây là ví dụ minh họa cho mô phỏng ở trên.
 Ta có thể kiểm tra kết nối của địa chỉ bằng lê ̣nh ping6 aaaa::212:7401:1:101
trong Terminal
Hình 69. Kiểm tra kết nối

 Ta cũng có thể kiểm tra kết nối của các node khác, ví dụ như node 2
Hình 70. Kiểm tra kết nối
 Kiểm tra bằng trình duyê ̣t web: Truy câ ̣p vào trình duyê ̣t web, nhâ ̣p địa chỉ của 1
node. Trình duyê ̣t sẽ hiển thị kết quả như bên dưới
Hình 71. Kiểm tra kết nối trên trình duyêṭ web

WSN (Demo) (Recovered)

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

WSN (Demo) (Recovered)

Uploaded by

Copyright:

Available Formats

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

BÁO CÁO BÀI TẬP LỚN

RPL Border Router

TP. HỒ CHÍ MINH, THÁNG 5 NĂM 2021

1|Wireless Sensor Network

2|Wireless Sensor Network

3|Wireless Sensor Network

4|Wireless Sensor Network

5|Wireless Sensor Network

6|Wireless Sensor Network

7|Wireless Sensor Network

8|Wireless Sensor Network

Hình 1. Mô hình RPL DAG

1.1.3 Các khái niệm

9|Wireless Sensor Network

Hình 2. Cấu trúc bản tin DIS

DIO – DAG Information Object

Các trường điều khiển

Suboption Suboption Length Suboption DATA

Nguyên lý gửi, nhận và xử lý thông tin DIO:

2. RPL trong Contiki

Cấu trúc Contiki RPL:

2.2 Thuật toán định tuyến với Contiki RPL

Hình 7. Hoạt đô ̣ng của DAGROOT

2.2.3 Cơ chế xử lý bản tin DIO và xây dựng DAG

IPv6 thông qua kết nối USB thông qua tunslip6.

4.2 Các đặ c tính của UDP

4.3 Cấu trúc của UDP

4.3.2 Dữ liệ u (data)

4.4 Ứng dụng của UDP

5.1 Phân tích chương trình border-router.c

Hình 17. Khối chương trình liên quan đến WEBSERVER

Hình 18. Webserver-nogui-process

Hình 19. Border-router-process

 Print_local_addresses(): in các địa chỉ có trong mạng RPL

Hình 23. Ippaddr_add()

Hình 26. Khởi đô ̣ng UDP server

Hình 28. Tạo kết nối UDP

Gửi và nhâ ̣n gói tin TCP/IP:

Hình 30. Nhâ ̣n và in dữ liêụ đã nhâ ̣n

5.3 Phân tích file makefile

Hình 32. Phần còn lại của makefile

1 số hàm được sử dụng trong chương trình:

Để gửi 1 chuỗi qua protothread, dùng PT_THREAD(send_string(struct httpd_state *s,

Để xử lý output và đưa lên web server, dùng PT_THREAD(handle_output(struct

PT_THREAD(handle_input(struct httpd_state *s)) xử lý phần input bằng cách đối

6.1.2 Cooja simulator

Hình 47. Run cooja

Hình 48. Cửa sổ Cooja

Hình 54. Bắt đầu Compile

Hình 59. Kết quả sau khi compile

6.2 Tutorial về sử dụng Tunslip utility

6.2.1 Định nghĩa về Tunslip utility

 Gõ câu lệnh: make tunslip6 để compile tunslip

Hình 69. Kiểm tra kết nối

You might also like