pháp định tuyến đa đường cải tiến dựa trên RPL 4.1Hệ thống mô phỏng Omnet++
OMNeT++ là viết tắt của cụm từ Objective Modular Network Testbed trong ngôn ngữ C++. OMNeT++ là một ứng dụng cung cấp cho người sử dụng môi trường để tiến hành mô phỏng hoạt động của mạng. Mục đích chính của ứng dụng là mô phỏng hoạt động mạng thông tin, tuy nhiên do tính phổ cập và linh hoạt của nó, OMNeT++ còn được sử dụng trong nhiều lĩnh vực khác như mô phỏng các hệ thống thông tin phức tạp, các mạng kiểu hàng đợi (queueing networks) hay các kiến trúc phần cứng...
OMNeT++ cung cấp sẵn các thành phần tương ứng với các mô hình thực tế. Các thành phần này (còn được gọi là các module) được lập trình theo ngôn ngữ C++, sau đó được tập hợp lại thành những thành phần hay những mô hình lớn hơn bằng một ngôn ngữ bậc cao (NED). OMNeT++ hỗ trợ giao diện đồ hoạ, tương ứng với các mô hình cấu trúc của nó đồng thời phần nhân mô phỏng (simulation kernel) và các module của OMNeT++
cũng rất dễ dàng nhúng vào trong các ứng dụng khác.
Các thành phần chính của OMNeT++:
• Thư viện phần nhân mô phỏng (simulation kernel)
• Trình biên dịch cho ngôn ngữ mô tả hình trạng (topology description language) - NED (nedc)
• Trình biên tập đồ hoạ (graphical network editor) cho các file NED (GNED)
• Giao diện đồ hoạ thực hiện mô phỏng, các liên kết bên trong các file thực hiện mô phỏng (Tkenv)
• Giao diện dòng lệnh thực hiện mô phỏng (Cmdenv)
• Công cụ (giao diện đồ hoạ) vẽ đồ thị kết quả vector ở đầu ra (Plove)
• Công cụ (giao diện đồ hoạ) mô tả kết quả vô hướng ở đầu ra (Scalars)
• Công cụ tài liệu hoá các mô hình
• Các tiện ích khác
• Các tài liệu hướng dẫn, các ví dụ mô phỏng…
Định tuyến đa đường cho Internet of Things GVHD: PGS.TS Ngô Quỳnh Thu
Học viên thực hiện Nguyễn Văn Bình – CB 130015 – KTMT&TT 2013B 51 Hình 29 Giao diện chương trình mô phỏng Omnet ++4.4 IDE
4.2Tìm hiểu quá trình mô phỏng và đánh giá kết quả
Để so sánh giữa các giao thức, chúng ta xét trên cụm đường truyền như bảng dưới với việc cụm đường truyền được thêm một lớp mới cho mô hình phân lớp IoT và giữa lớp vật lý và lớp MAC. Nó đảm nhận việc truyền frame và kích hoạt bộ thu vào thời điểm nhận các bản tin đến.
IOT layer Testing system Application Client – Server Transport UDP
Network
IPv6/RPL 6LoWPAN
Data link Un-beacon mode CSMA ContikiMAC
Physical Framer802.15.4/cc2420 driver Bảng 3: chuẩn hệ thống truyền thông
Định tuyến đa đường cho Internet of Things GVHD: PGS.TS Ngô Quỳnh Thu
Học viên thực hiện Nguyễn Văn Bình – CB 130015 – KTMT&TT 2013B 52 Hệ thống mô phỏng đã được triển khai trong OMNET++ và phân cấp hệ thống như sau:
- Thư mục mô phỏng gồm cấu hình hệ thống (omnetpp.ini, WSN.ned) và thư mục kiểm tra kết quả (result).
+ File mô phỏng/omnetpp.ini: gồm cấu hình mạng.
+ file mô phỏng/WSN.ned gồm cụm đường truyền của mỗi modul.
- Thư mục src: gồm mã nguồn
+ Thư mục src/package: có 5 thư mục con (dữ liệu, phân khúc, gói, khung, tín hiệu tra cứu) định dạng gói tin tại mỗi lớp.
▪ Dữ liệu
▪ Phân đoạn
▪ Gói
▪ Khung
+ Thư mục src/util gồm 3 modul: mô hình thống kê, quản lý thế giới, quản lý tín hiệu.
+ Thư mục src/apps gồm mã nguồn cho các ứng dụng Client – server.
+ Thư mục src/core gồm mã nguồn cho mỗi lớp điều khiển và các tiện ích.
▪ Có 5 lớp trong chương trình được đưa ra ứng với mỗi mã nguồn và tên tương ứng: transport, net, mac, rdc, radio và bổ sung khung 802.15.4.
▪ Modul giải phóng năng lượng là module sử dụng thuật toán capsule để ước lượng thời gian xử lý CC240 và sau đó tính toán năng lượng tiêu thụ của mỗi node cảm biến.
+ Thư mục src/mote gồm hai tập tin client.ned và server.ned mô tả các thiết bị của node cảm biến và trạm gốc và thiết lập kết nối giữa chúng.
4.3 Đánh giá hiệu năng 4.3.1 Thiết lập mạng
Hệ thống được phân tách đường truyền trong IPv6 cho hệ mô phỏng WSN Omnet++ như sau:
UDP trong lớp giao vận, Ipv6/RPL/6Lowpan trong lớp mạng, chế độ không đèn hiệu CSMA và ContikiMAX trong lớp dữ liệu UDP in Transport layer, IPv6 / RPL / 6lowpan trong lớp liên kết dữ liệu, node cảm biến mô phongrkhung 802.15.4/CC240 trong
Định tuyến đa đường cho Internet of Things GVHD: PGS.TS Ngô Quỳnh Thu
Học viên thực hiện Nguyễn Văn Bình – CB 130015 – KTMT&TT 2013B 53 lớp vật lý trong mạng với chế độ không đèn hiệu CSMA và contikiMac trong lớp liên kết dữ liệu và frame 802.15.4/cc2420 trong lớp vật lý.
Để tìm hiểu và đánh gía hiệu năng của các giao thức, chương trình được mô phỏng với 144 node cảm biến; triển khai trên diện tích 420x420m, mỗi node có range là 30m và được gắn với 2 pin AA với dung lượng khoảng 1000 mAh; điện áp hoạt động là 1,5V; năng lượng của các node chỉ được thiết lập khoảng 0,3% để nhanh chóng quan sát ảnh hưởng của ELB và ELB-FLR. Đề án lấy mẫu mô phỏng là để lấy mẫu nhiệt độ, độ ẩm và ánh sáng ở khoảng thời gian 60 giây cho mỗi mẫu và dữ liệu là 8 byte. Các chương trình chạy trong khoảng thời gian một giờ. Các chương trình chạy trong 3600 giây, độ trễ là 80 giây.
Để làm nổi bật các vấn đề cần quan tâm trong mạng cảm biến không dây qua việc tìm hiểu các giao thức nâng cao dựa trên RPL tôi so sánh các giao thức trong cùng điều kiện như nhau trên các chỉ số đó là:
- Tải dữ liệu dựa trên số bản tin ICMP.
- Độ trễ trung bình của gói tin là tỉ lệ giữa tổng độ trễ của giao thức trên tổng số gói tin nhận được của lớp ứng dụng.
- Mức năng lượng của các node sau khi truyền dữ liệu.
- Độ tin cậy của giao thức (tỉ lệ giữa gói nhận được với gói gửi đi bởi lớp ứng dụng).
4.3.2 Phân tích kết quả
4.3.2.1 Đánh giá các giao thức qua tỷ lệ từng loại gói tin
Hình 30 Tỷ trọng của từng gói NET
55758 55388 55772 55806
15876 14112 13524 13524
8649 8873 8930 8981
RPL ELB FLR ELB-FLR
Data payload DIS
DIO
Định tuyến đa đường cho Internet of Things GVHD: PGS.TS Ngô Quỳnh Thu
Học viên thực hiện Nguyễn Văn Bình – CB 130015 – KTMT&TT 2013B 54 Qua kết quả được thể hiện trên biểu đồ, tải dữ liệu của ELB-FLR là tốt nhất, số bản tin điều khiển (DIS) của nó là ít nhất (ít hơn 2000 bản tin so với RPL) đồng nghĩa với việc nó tiêu thụ năng lượng ít nhất khi không phải phát bản tin nhằm duy trì định tuyến mà quá trình này làm tăng lưu lượng truy cập, dễ dẫn tới xung đột, tăng độ trễ thậm trí mất gói. Tiếp theo đó là ELB và FLR. RPL tiêu hao năng lượng nhiều nhất khi có số lượng phát bản tin ICMP (DIS) nhiều nhất.Kết quả như vậy là do FLR và ELB-FLR sử dụng các thuật toán sửa chữa cục bộ, trong đó khai thác các node sibling để chuyển tiếp các gói trong trường hợp tuyến đường bị lỗi mà không quảng bá bản tin DIS và chờ đợi tin DIO.
ELB-FLR có số bản tin DIO nhiều nhất đồng nghĩa với hội tụ mạng của nó là nhanh nhất. Tiếp theo lần lượt là FLR, ELB và RPL.
Một lợi ích khác của việc tăng cường này đang được cải thiện trên QoS của mạng, tức là độ tin cậy và độ trễ. Do hao phí trong việc quảng bá bản tin ICMPv6 rất lớn, các node cảm biến trong RPL tăng lưu lượng truy cập và xung đột tín hiệu dẫn tới nhiều khả năng mất gói tin. Do đó, gói tin được chia nhỏ để truyền nhằm tránh tắc nghẽn, điều này làm gia tăng độ trễ của toàn bộ mạng lưới.
4.3.2.2 Độ trễ gói tin
Hình 31Tương quan độ trễ giữa các giao thức
115 116 117 118 119 120 121 122 123 124
RPL ELB FLR ELB-FLR
Millisecond
Delay (second)
Định tuyến đa đường cho Internet of Things GVHD: PGS.TS Ngô Quỳnh Thu
Học viên thực hiện Nguyễn Văn Bình – CB 130015 – KTMT&TT 2013B 55 RPL là yếu nhất với độ trễ là 123.01 mili giây, các giao thức còn lại có độ trễ nhỏ hơn đáng kể so với RPL. ELB, FLR và ELB-FLR có độ trễ lần lượt là 119.95;120.97 và 120.75 mili giây tương ứng.
Như đã đề cập ở phần trên, RPL cần phải gửi nhiều thông điệp ICMPv6 để duy trì việc định tuyến của mình. Do đó, các dữ liệu cần phải chờ đợi cho những bản tin ICMPv6 trong gói hàng đợi. Trong khi đó với ELB có hiệu suất tốt hơn so với RPL vì ELB đã thực hiện cơ chế luân phiên cân bằng tải giữa các node parent mỗi khi hoàn thành việc truyền tải. Vì vậy, một số node có rank cao không nhận được yêu cầu từ node neighbor của mình, nhưng những node parent khác có cơ hội để được chọn là node parent ưu tiên dẫn tới các gói tin không phải đợi, vì vậy độ trễ giảm đáng kể.
4.3.2.3 Tỉ lệ giao gói
Hình 32Tỉ lệ chuyển gói tin
Qua dữ liệu trên biểu đồ cho thấy tỷ lệ chuyền gói tin (PDR) của ELB-FLR tốt nhất với 81.21%; Ba giao thức còn lại lần lượt RPL, ELB, FLR tương ứng 79.98%, 81.20%, 81.20%.
Lý giải cho điều này là do RPLsử dụng bản tin ICMPv6 quảng bá nhiều hơn, nhờ đó truyền tải trong một khoảng thời gian truyền theo ContikiMAC và điều này rất dễ dẫn đến việc xung đột, tắc nghẽn và có thể mất gói tin. Hơn nữa, ELB có cơ chế chuyển đổi node parent, trong đó cung cấp một sự cân bằng năng lượng giữa các node parent nên làm giảm chi phí. Do đó, một node sẽ có tải thấp hơn và do đó thực hiện tốt
79,2 79,4 79,6 79,8 80 80,2 80,4 80,6 80,8 81 81,2 81,4
RPL ELB FLR ELB-FLR