Luận văn thạc sĩ Khoa học máy tính: Thử nghiệm mô hình mạng LoRaWAN với giao thức định tuyến heat

Giới thiệu

LoRaWAN

Phần này tóm lược một số thông tin cơ bản về LoRaWAN, chủ yếu trích dẫn từ trang web của LoRa Alliance [6] và bài tóm tắt của nhóm tác giả J Haxhibeqiri,

LoRaWAN là một đặc tả được phát triển và duy trì bởi LoRa Alliance® về một mô hình mạng diện rộng năng lượng thấp với giao thức được thiết kế để kết nối các thiết bị không dây chạy pin vào internet trong phạm vi khu vực, quốc gia, hoặc toàn cầu, và tập trung vào các yêu cầu chính của IoT như là giao tiếp hai chiều, bảo mật kết nối, tính di động, và các dịch vụ bản địa Đặc tả của LoRaWAN cũng định nghĩa các tham số lớp vật lý giữa các thiết bị với hạ tầng mạng cũng như giao thức mạng Nhờ đó, các nhà sản xuất thiết bị có thể tương tác với nhau một cách liền mạch, như được mô tả trong chương trình chứng nhận thiết bị (device certification program [8]) của LoRa Alliance

Tuy nhiên, LoRaWAN chỉ định nghĩa về kỹ thuật mà không định nghĩa bất kì mô hình thương mại hay loại hình triển khai nào (công cộng, chia sẻ, riêng tư, doanh nghiệp), vì thế cho phép sự tự do đổi mới, sáng tạo trong cách mà nó được sử dụng

1.1.1.2 Cấu trúc liên kết mạng

Mạng LoRaWAN có cấu trúc liên kết là một mạng hình sao của các hình sao như được mô tả trong Hình 1.1 dưới đây

Hình 1.1 Cấu trúc liên kết mạng LoRaWAN

Trong đó các gateways có vai trò chuyển tiếp các gói tin giữa các thiết bị đầu cuối với một máy chủ mạng trung tâm Các gateways được kết nối với máy chủ mạng bằng các kết nối theo chuẩn IP, và hoạt động như một cầu nối trong suốt, chỉ đơn thuần chuyển đổi các gói tin vô tuyến sang các gói tin chuẩn IP và ngược lại Các thiết bị đầu cuối trong mạng có thể kết nối trực tiếp đến một hoặc nhiều gateways nhờ vào lợi thế tầm xa của lớp vật lý LoRa Tất cả các chế độ hoạt động của mạng đều hỗ trợ giao tiếp hai chiều và multicast 1 cho phép sử dụng hiệu quả phổ sóng

1 Gửi các gói tin từ một thiết bị cùng lúc đến nhiều thiết bị khác trong mạng vô tuyến cho những tác vụ như cập nhật firmware từ xa qua kết nối không dây hoặc các tác vụ khác cần broadcast 2

Hình 1.2 Mô hình mạng LoRaWAN

1.1.1.3 Các lớp thiết bị đầu cuối

Hoạt động của các thiết bị đầu cuối trong mạng LoRaWAN được chia thành ba lớp phù hợp với nhu cầu của những loại hình ứng dụng khác nhau

Lớp A: Mức năng lượng tiêu thụ thấp nhất cho giao tiếp hai chiều

Là lớp mặc định phải được hỗ trợ bởi tất cả các thiết bị đầu cuối LoRaWAN, giao tiếp trong lớp A luôn được khởi đầu bởi thiết bị đầu cuối và hoàn toàn bất đồng bộ Mỗi lượt truyền lên đều có thể được thực hiện ở bất cứ thời điểm nào và theo sau đó là hai windows cho việc truyền xuống 3 cho phép việc giao tiếp hai chiều hoặc gửi những lệnh điều khiển mạng khi cần Đây là một giao thức dạng ALOHA 4 Thiết bị đầu cuối có thể vào chế độ ngủ năng lượng thấp tuỳ thuộc vào ứng dụng mà không có yêu cầu nào về mạng phải đánh thức thiết bị một cách định kỳ Điều này khiến lớp A trở thành chế độ hoạt động tiêu tốn ít năng lượng nhất

2 Gửi các gói tin từ một thiết bị cùng lúc đến tất cả các thiết bị khác trong một nhóm nhất định

3 Khoảng thời gian mà thiết bị đầu cuối đợi dữ liệu truyền xuống từ máy chủ mạng

4 Một giao thức đơn giản mà trong đó thiết bị sẽ gửi dữ liệu ngay khi cần mà không quan tâm đến tính sẵn có của kênh truyền, nếu việc gửi bị đụng độ, thì (các) gói tin sẽ được gửi lại sau một khoảng thời gian ngẫu nhiên nhưng vẫn cho phép truyền lên tại mọi thời điểm Còn việc truyền xuống, do chỉ có thể được thực hiện ngay sau các lượt truyền lên, các lượt truyền xuống đều phải được đệm ở máy chủ mạng để chờ đợi lượt truyền lên tiếp theo

Lớp B: Giao tiếp hai chiều với độ trễ truyền xuống xác định

Bên cạnh những windows truyền xuống sau mỗi lần truyền lên như được định nghĩa bởi lớp A, các thiết bị lớp B còn được đồng bộ với mạng bằng các beacons 5 một cách định kỳ và mở những “ping-slot” 6 tại những thời điểm đã được lên lịch trước Điều này giúp cho máy chủ mạng có thể thực hiện việc truyền xuống với độ trễ xác định nhưng cũng làm cho thiết bị đầu cuối tiêu tốn thêm năng lượng Độ trễ này có thể lập trình được và lên tới 128 giây để phù hợp với những ứng dụng khác nhau, và lượng năng lượng phát sinh thêm vẫn đủ thấp cho các thiết bị chạy pin

Lớp C: Cho phép giao tiếp hai chiều với độ trễ thấp nhất

Các thiết bị đầu cuối hoạt động ở lớp C giảm độ trễ truyền xuống từ máy chủ mạng bằng cách luôn sẵn sàng nhận dữ liệu trong toàn bộ thời gian mà nó không thực hiện việc truyền lên Nhờ đó, máy chủ mạng có thể khởi tạo lượt truyền xuống bất cứ lúc nào Tuy nhiên, với cách hoạt động như vậy, các thiết bị đầu cuối hoạt động ở lớp C tiêu tốn khá nhiều năng lượng Do đó, lớp C thường chỉ phù hợp khi có nguồn năng lượng liên tục Trong trường hợp thiết bị đầu cuối được cấp nguồn bằng pin, thiết bị vẫn có thể tạm thời hoạt động ở lớp C khi cần, sau đó chuyển chế độ hoạt động về lại lớp A

1.1.1.4 Cơ chế Adaptive Data Rate (ADR) Được hiện thực để quản lý động các tham số tốc độ truyền và công suất phát sóng của các thiết bị đầu cuối nhằm tăng tỉ lệ nhận gói ở gateway Nếu thiết bị đầu cuối muốn cho phép máy chủ mạng LoRaWAN quản lý các tham số phát sóng của nó, nó sẽ đặt mức cao cho bit ADR trong các gói tin truyền lên Ngược lại, các thiết

6 Khe thời gian dùng để ping / có thể ping được bị đầu cuối cũng có thể tự quản lý các tham số này bằng một phiên bản đơn giản của cơ chế ADR được hiện thực cục bộ Như vậy, cơ chế ADR có hai phần, chạy bất đồng bộ với nhau ở máy chủ mạng và ở thiết bị đầu cuối

Cơ chế ADR được đặc tả chi tiết trong LoRaWAN Specification [9]

LoRaWAN đặc tả hai lớp bảo mật:

- Một khoá Network Session duy nhất dài 128 bit được chia sẻ giữa thiết bị đầu cuối với máy chủ mạng

- Một khoá Application Session (AppSKey) duy nhất dài 128 bit được chia sẻ ở mức ứng dụng

Thuật toán AES được sử dụng cho việc xác thực và kiểm tra / đảm bảo toàn vẹn gói tin đối với máy chủ mạng và để mã hoá dữ liệu đối với máy chủ ứng dụng Bằng cách cung cấp hai lớp bảo mật như vậy, người ta có thể hiện thực mạng chia sẻ giữa nhiều người thuê mà vẫn đảm bảo được bảo mật dữ liệu

Ngoài ra, việc tham gia vào mạng LoRaWAN của một thiết bị đầu cuối còn được quản lý nghiêm ngặt bằng một số cơ chế, được đặc tả trong LoRaWAN Specification.

Một số giải thuật định tuyến

Định tuyến là cơ chế giúp chuyển tiếp dữ liệu từ node nguồn đến node đích theo một tuyến đường nhất định tại mỗi thời điểm Các giao thức định tuyến trong mạng lưới không dây 7 có thể được chia thành các giao thức định tuyến chủ động (proactive), các giao thức định tuyến theo nhu cầu (on-demand, hay reactive), và các giao thức kết hợp giữa các loại hình trên (hybrid)

Trong các giao thức định tuyến chủ động, các tuyến đường giữa các nodes bất kì sẽ được thiết lập và duy trì liên tục, bất kể các tuyến đường đó có cần thiết hay có

7 từ ngữ tiếng Anh chuyên ngành là “wireless mesh network” được sử dụng hay không Chúng còn được gọi là các phương pháp định tuyến dựa trên các bảng (table-driven), liên tục đánh giá các tuyến đường đến tất cả các nodes có thể truy cập và duy trì thông tin định tuyến một cách nhất quán, cập nhật

Do đó, ưu điểm chính của các giao thức định tuyến chủ động là các nodes có thể nhanh chóng có được thông tin về các tuyến đường trong mạng để sử dụng ngay khi cần Một số giao thức định tuyến chủ động phổ biến có thể kể đến như là Destination Sequenced Distance-Vector Routing (DSDV), Cluster Head Gateway Switch Routing (CGSR), Optimized Link State Routing Protocol (OLSR) và HEAT [5]

Trong các giao thức định tuyến theo nhu cầu, các tuyến đường chỉ được xác định khi cần Quá trình khai phá 8 các tuyến đường chỉ bắt đầu khi node nguồn cần gửi dữ liệu đến node đích Quá trình này kết thúc khi một tuyến đường đã được tìm thấy hoặc không có tuyến đường nào khả dụng sau khi kiểm tra tất cả các tuyến Trong mạng di động 9 , các tuyến đường đang hoạt động có thể bị ngắt kết nối do tính di động của node Tuy nhiên, trong các mạng lưới không dây, các nodes thường ít di động, vì vậy các giao thức định tuyến theo nhu cầu có khả năng mở rộng tốt hơn các giao thức định tuyến chủ động Một số giao thức định tuyến theo nhu cầu phổ biến có thể kể đến như là Dynamic Source Routing (DSR), Ad-hoc

On Demand Distance Vector (AODV), Link Quality Source Routing Algorithm (LQSR) và Temporally Ordered Routing Algorithm (TORA)

Các giao thức định tuyến hybrid kết hợp ưu điểm của các giao thức định tuyến chủ động và các giao thức định tuyến theo nhu cầu bằng cách khắc phục các nhược điểm của chúng và tìm các tuyến đường hiệu quả mà không cần nhiều sự kiểm soát Nó sử dụng các giao thức định tuyến đa dạng trong các phần khác nhau của cơ sở hạ tầng mạng lưới không dây, cụ thể là sử dụng các giao thức định tuyến theo nhu cầu cho khu vực ad-hoc và áp dụng các giao thức định tuyến chủ động cho backbone

8 từ ngữ tiếng Anh chuyên ngành là “network discovery"

9 từ ngữ tiếng Anh chuyên ngành là “cellular network"

Tiểu mục này khái quát lại một số giao thức / giải thuật định tuyến dựa trên bài tóm tắt của nhóm tác giả K Vijayakumar, P Ganeshkumar and M Anandaraj [10] và bài báo về giải thuật định tuyến HEAT của nhóm tác giả R Baumann, S Heimlicher, V Lenders and M May [5]

1.1.2.1 Một số giao thức định tuyến chủ động

DSDV là giao thức được phát triển dựa trên giải thuật Bellman-Ford trong đó mỗi node duy trì một bảng định tuyến có chứa đường đi ngắn nhất đến mọi nodes đích có thể đến được trong mạng và số bước nhảy đến đích như được thể hiện trong Hình 1.3 dưới đây

Hình 1.3 Minh họa giao thức định tuyến DSDV

Các mã số sequence 10 được các nodes sử dụng để phân biệt các tuyến đường cũ với các tuyến đường mới thành lập và để tránh việc lặp vòng Thông tin broadcast một tuyến đường mới bao gồm:

10 Từ ngữ tiếng Anh chuyên ngành là “sequence number”, dùng để đánh số thứ tự cho các gói tin trong mạng

- Số sequence của thông tin về node đích và một mã sequence mới duy nhất đối với gói broadcast

Việc cập nhật bảng định tuyến được thực hiện định kỳ nhằm duy trì bảng một cách nhất quán Bảng định tuyến chứa địa chỉ đích, node kế tiếp, số hops đến đích, và số sequence như trong Bảng 1.1

Có hai cách cập nhật bảng:

- Cập nhật toàn bộ dữ liệu của bảng (Full Dump)

- Chỉ cập nhật những thay đổi so với trước đó (Incremental)

Bảng 1.1 Minh họa bảng định tuyến tại một node trong mạng sử dụng DSDV

Clusterhead Gateway Switched Routing (CGSR)

CGSR là một giao thức được hiện thực lên trên giao thức DSDV đã trình bày (nói cách khác, DSDV là giao thức lớp dưới của giao thức này) CGSR là một giao thức định tuyến phân cấp Trong đó các nodes được phân thành các cụm (cluster) và mỗi cụm như vậy lại có một đầu cụm (cluster head) điều khiển một nhóm các nodes không dây và vì vậy hình thành một mô hình cây khung phân cấp có thể phân biệt bằng mã giữa các cụm với nhau, truy cập kênh truyền, định tuyến, và cấp phát băng thông Khi một cụm được hình thành, một thuật toán phân tán sẽ được sử dụng để lựa chọn ra node đầu cụm như được mô tả trong Hình 1.4 Đầu cụm có thể được thay thế thường xuyên và điều này ảnh hưởng đến hiệu năng của hệ thống do các nodes dành nhiều thời gian để lựa chọn node đầu cụm hơn là thời gian để chuyển tiếp các gói tin Để vượt qua vấn đề này, giải thuật Least Cluster Change (LCC) được áp dụng Trong đó, đầu cụm chỉ thay đổi khi hai đầu cụm chạm nhau (trong vùng phủ sóng lẫn nhau), hoặc khi một node nào đó di chuyển ra ngoài tầm phủ của tất cả các đầu cụm Trong CGSR, mỗi node duy trì một bảng thành viên cụm (cluster member table) và một bảng định tuyến nhằm xác định đầu cụm gần nhất dọc theo tuyến đường đến đích và node tiếp theo phải đi qua để đến được đích

Hình 1.4 Mô hình mạng sử dụng giao thức định tuyến CGSR

Như thể hiện trong Hình 1.4, khi gửi một gói tin, node nguồn (node 1) gửi dữ liệu đến đầu cụm của nó (node 2) rồi từ đó gói tin lại được gửi tiếp đến node 4 là node trung chuyển qua cụm lân cận Sau đó node 4 lại chuyển tiếp gói tin cho đầu cụm tiếp theo là node 5 Node 5 lại chuyển gói tin đó cho node 7 để node 7 gửi tiếp cho đầu cụm tiếp theo (node 8) Quá trình tương tự tiếp diễn đến khi gói tin đến được node đích là node 12

Một mạng lưới không dây được chia thành nhiều cụm nhỏ để kiểm soát tải Một đầu cụm phải ước lượng tải trong cụm của nó Khi tải ước lượng tăng lên, đầu cụm tăng chỉ số định tuyến 11 của tuyến đường đi ngang qua cụm đó Dựa trên chỉ

11 Từ ngữ tiếng Anh chuyên ngành là “routing metrics” số định tuyến, lưu lượng người dùng 12 chọn một tuyến đường thay thế để tránh các khu vực bị quá tải, và kết quả là mạng lưới không dây đạt được cân bằng tải toàn cục CGSR sử dụng thời gian truyền kỳ vọng (expected transmission time) làm thước đo cho việc định tuyến

OLSR cũng là một giao thức định tuyến chủ động Mỗi node đều quảng bá thông tin trạng thái kết nối 13 của nó đến tất cả các nodes trong mạng Hoạt động của OLSR chủ yếu bao gồm việc cập nhật và duy trì thông tin trong bảng 1 hop, 2 hops lân cận và bảng định tuyến OLSR sử dụng HELLO MESSAGES cho thông tin trạng thái kết nối Rơle đa điểm 14 (MPR) là một khái niệm quan trọng của giao thức OLSR Một rơle đa điểm cho một node N là một tập hợp con của các nodes lân cận của N, chúng chịu trách nhiệm phát tán các gói tin trong quá trình flooding thay vì mọi nodes liền kề của N đều phải thực hiện điều đó Khi một node phát tán một thông điệp, tất cả các nodes liền kề đều sẽ nhận được nhưng chỉ có những nodes trong MPR mà trước đó chưa từng nhận được thông điệp này thì mới lan truyền những thông điệp đó đi tiếp Vì thế, chi phí phát sinh khi flooding có thể được giảm xuống

Vấn đề và hướng cải thiện

Trong mô hình liên kết mạng Hình 1.1, tất cả các cảm biến và thiết bị chấp hành đều được thiết kế để kết nối trực tiếp với các gateway giúp độ trễ khi gửi dữ liệu lên xuống giữa các nodes với gateway được đảm bảo thấp nhất có thể

Tuy nhiên, trên thực tế triển khai các mô hình mạng cảm biến không dây, nếu dữ liệu từ các nodes cảm biến chỉ được gửi trực tiếp về gateway (single hop), thì buộc tất cả các nodes cảm biến đều phải được bố trí trong tầm phủ sóng của gateway Như vậy, mạng sẽ cần có rất nhiều gateway Mỗi gateway trong mạng như vậy đóng vai trò là một node trung tâm của một cụm cảm biến Do đó vị trí bố trí gateway phụ thuộc nhiều vào vị trí bố trí của các nodes cảm biến Trong khi đó, thường các gateway lại cần có nguồn điện và kết nối internet ổn định, do đó không dễ triển khai như các nodes cảm biến Để giải quyết vấn đề này, nhiều giải pháp kỹ thuật đã được đặt ra Một trong những giải pháp đơn giản nhất là sử dụng kỹ thuật “flooding” Theo đó, khi một node bất kỳ cần gửi dữ liệu lên gateway, nó chỉ cần gửi gói tin quảng bá ra xung quanh Các nodes khi nhận được những gói tin quảng bá chứa dữ liệu từ node khác, nó sẽ lại tiếp tục quảng bá những gói tin này ra những nodes lân cận nữa

Bằng cách này, trong trường hợp nodes cảm biến có nằm ngoài tầm phủ sóng của gateway đi nữa, thì dữ liệu cần gửi vẫn có thể “lan tràn” đến gateway thông qua những nodes khác

Hình 1.14 thể hiện một mô hình mạng cảm biến không dây với 1 gateway và 10 nodes Trong đó, chỉ có 3 nodes gồm Node 0, Node 1, và Node 2 là các nodes nằm trong tầm phủ sóng của gateway Tất cả các nodes còn lại muốn gửi được dữ liệu đến gateway đều phải nhờ Node 0, Node 1, hoặc Node 2 chuyển tiếp

Hình 1.14 Mô hình mạng có một số nodes nằm ngoài vùng phủ sóng của gateway

Các đường tròn nét đứt thể hiện đường bao phạm vi phủ sóng của node / gateway đặt tại tâm đường tròn Các đoạn thẳng nối giữa các nodes thể hiện khả năng kết nối trực tiếp giữa các nodes đó do nằm trong vùng phủ sóng của nhau

Khi sử dụng kỹ thuật “flooding”, giả sử có một gói tin được tạo ra và gửi đi từ Node 4 thì Node 3 sẽ nhận được rồi tiếp tục quảng bá ra xung quanh Sau đó, do Node 0 và Node 5 đều nằm trong vùng phủ sóng của Node 3 nên cả hai nodes đều sẽ nhận được gói tin rồi lại thực hiện chuyển tiếp, nhờ đó gói tin được chuyển tiếp từ Node 0 đã đến được gateway Mặt khác, ở nhánh còn lại, gói tin được chuyển tiếp từ Node 5 cũng sẽ đến được Node 6, sau đó là Node 1, và cuối cùng cũng đến được gateway

Có thể thấy ngay, ưu điểm của phương pháp này là một gói tin có thể đến được gateway theo rất nhiều con đường khác nhau, giúp gói tin đến đích sớm nhất có thể Trong ví dụ vừa rồi, con đường ngắn nhất để chuyển gói tin từ Node 4 đến gateway là thông qua Node 3 và Node 0

Tuy nhiên, khi sử dụng kỹ thuật “flooding”, số lượng gói tin phát sinh trong mạng sẽ rất lớn, rất nhiều gói tin dư thừa làm lãng phí băng thông mạng và tăng xác suất đụng độ Khi tần suất phát sinh và gửi dữ liệu tăng lên, tần suất đụng độ cũng tăng lên và làm mạng nhanh chóng bị nghẽn Ta cũng thấy trong ví dụ trên, mặc dù gói tin đã đến được gateway thông qua Node 0 rồi, nhưng các bản sao của nó vẫn tiếp tục được phát tán trong mạng Kết quả là mặc dù nhiều nodes chẳng liên quan nhưng nodes nào trong mạng cũng sẽ nhận được gói tin, lại còn phải lưu lại lịch sử chuyển tiếp gói tin trong một giới hạn nhất định để chống lặp gói Ở phía gateway cũng vậy, nó sẽ nhận được nhiều bản sao của một gói tin qua nhiều đường khác nhau, nên cũng phải chạy giải thuật loại bỏ gói tin bị trùng lặp tương tự như ở các nodes Chưa kể, nếu mạng có nhiều gateways, thì việc loại bỏ trùng lặp còn phải tiến hành cả trên máy chủ IoT Việc tiết kiệm năng lượng tiêu thụ bằng cách đặt module giao tiếp không dây vào chế độ ngủ hoặc chế độ năng lượng thấp khi không dùng đến cũng trở nên bất khả thi đối với mạng sử dụng kỹ thuật “flooding” do các nodes lúc nào cũng phải hoạt động để đảm bảo luôn sẵn sàng chuyển tiếp gói tin Để hiện thực được việc gửi gói tin đến gateway qua nhiều hops nhưng vẫn có thể hạn chế hoặc tránh được các vấn đề nói trên, người ta đã hiện thực nhiều giải thuật tìm đường khác nhau Trong mạng cảm biến không dây có sử dụng kỹ thuật tìm đường, mỗi gói tin sẽ chỉ được chuyển đến đích trên một con đường duy nhất xác định bởi giải thuật định tuyến Khi đó, nếu không có các sự cố như một node đã gửi gói tin sang node khác thành công nhưng vẫn cố gửi lại do gói ACK bị mất, thì trong mạng sẽ hoàn toàn không có sự trùng lặp các gói tin như trong mạng sử dụng kỹ thuật “flooding” Tuy không thể loại bỏ hoàn toàn nguy cơ trùng lặp gói, nhưng việc sử dụng kỹ thuật tìm đường giúp giảm tải đáng kể cho các nodes, cho phép các nodes tạm tắt module giao tiếp không dây khi không dùng đến để tiết kiệm năng lượng, đồng thời giảm thiểu đụng độ, giúp mạng có khả năng đáp ứng được tần suất phát sinh và gửi dữ liệu cao hơn Đây chính là những ưu điểm chính của việc sử dụng các giải thuật tìm đường vào các mạng cảm biến không dây thay vì phương pháp “flooding” Đã có nhiều giải thuật định tuyến cho các mạng cảm biến không dây như OLSR, DSR, DSDV, AODV, hay ZRP, v.v… Những giải thuật này mặc dù đều có những ưu, nhược điểm khác nhau, và do đó phù hợp với những loại hình ứng dụng khác nhau, nhưng đều là những giải thuật dùng để tìm ra tuyến đường end-to-end 24 tốt nhất giữa các cặp node bất kỳ trong mạng Đặc điểm của những giải thuật định tuyến thuộc nhóm này là overhead (chi phí phát sinh) cao do mỗi node đều phải duy trì bảng dữ liệu liên quan đến tất cả các nodes khác trong mạng, dẫn đến khó mở rộng

Trong khi đó, trong mô hình mạng LoRaWAN, các nodes trong mạng chủ yếu gửi dữ liệu lên gateway và nhận dữ liệu từ gateway gửi xuống mà không có nhu cầu giao tiếp giữa các cặp nodes bất kỳ Thậm chí, đối với bài toán quan trắc đơn thuần, mạng cũng chỉ cần hỗ trợ uplink 25 mà không cần hỗ trợ downlink 26 , hoặc chỉ cần hỗ trợ downlink một cách rất hạn chế 27 Vì vậy, ta hoàn toàn có thể sử

24 end-to-end: từ đầu này sang đầu kia (từ node này sang node khác)

25 uplink: đường truyền lên, theo hướng từ node lên gateway

26 downlink: đường truyền xuống, theo hướng gateway xuống node

27 hỗ trợ downlink một cách hạn chế được hiểu là tuy vẫn hỗ trợ nhưng không tốt bằng uplink, giải pháp cụ thể sẽ được đề cập sau trong Luận Văn dụng những giải thuật định tuyến khác chỉ hỗ trợ giao tiếp giữa 1 node bất kỳ với

1 gateway dễ tiếp cận nhất để giảm bớt overhead và tăng khả năng mở rộng mạng

Bài toán nói trên có rất nhiều điểm tương đồng với vấn đề mà nhóm tác giả Baumann và cộng sự đã đề cập trong công trình nghiên cứu của mình [5] Mặc dù giao thức định tuyến HEAT do nhóm tác giả đưa ra có nhiều ưu điểm nhưng vẫn còn các nhược điểm cần cải thiện như đã trình bày trong tiểu mục 1.1.2.1

1.1.3.2 Hướng cải thiện Đề tài Luận Văn này đề xuất 2 nội dung cải thiện chính:

(1) Cải thiện giải thuật HEAT bằng cách sử dụng các thông số thực tế hơn để đánh giá khả năng gửi được gói tin của một node đến gateway (năng lực vận chuyển) thay cho đại lượng vô hướng “nhiệt độ”, đưa ra khái niệm định tuyến dựa trên chất lượng dịch vụ của node lân cận

(2) Áp dụng mô hình mạng mesh 28 sử dụng giải thuật định tuyến đã đề xuất giúp các nodes ngoài tầm phủ sóng của gateway vẫn có thể gửi dữ liệu lên internet

Cũng với mô hình mạng được mô tả trong Hình 1.14, các nodes ngoài tầm phủ sóng của gateway sẽ gửi dữ liệu về gateway thông qua tuyến đường có khả năng cao nhất thay vì broadcast ra xung quanh như khi áp dụng kỹ thuật “flooding”

Hình 1.15 Tình trạng mạng minh họa 10 nodes 1 gateway khi chỉ có gateway và các Node 0, 1, 2, 3, 5, và 8 hoạt động Để ví dụ, giả sử tại một thời điểm nào đó mạng chỉ có gateway và các Node 0, 1,

Khái quát ý tưởng

Chiến lược tìm đường

Chiến lược tìm đường được sử dụng trong Luận Văn này là chiến lược chung của tất cả các giao thức định tuyến dựa trên (các) trường giá trị 29 , bao gồm cả HEAT, được mô tả ngắn gọn như sau:

- Gửi dữ liệu trực tiếp đến gateway (nếu có thể) hoặc chuyển tiếp dữ liệu đến gateway thông qua node nào có tuyến đường đến gateway tốt nhất (node có trường giá trị lớn nhất 30 ) trong tất cả các nodes lân cận trực tiếp của node gửi

- Liên tục cập nhật lại hiểu biết của các nodes về giá trị (các) trường của các nodes lân cận trực tiếp

Tuy nhiên, Luận Văn này đề xuất một sự thay đổi về trường dữ liệu được sử dụng để so sánh chất lượng các tuyến đường thông qua các nodes như sẽ được mô tả trong các tiểu mục 1.2.2 và 1.2.3 dưới đây

Bên cạnh đó, Luận Văn còn bổ sung thêm cơ chế cập nhật lại giá trị của các trường này theo sự kiện ngoại lệ như lúc đang giao tiếp thì (các) trường của node nhận có sự thay đổi, thay vì chỉ cập nhật định kỳ như HEAT và một số giao thức định tuyến khác cũng dựa trên (các) trường giá trị (exceptional update trong Hình 1.29).

Khái niệm “heat” mới

Giải thuật định tuyến được đề xuất trong Luận Văn này được phát triển từ ý tưởng của giải thuật định tuyến HEAT Trong giải thuật định tuyến HEAT, khả năng vận chuyển được dữ liệu đến gateway của mỗi node được đại diện bởi một giá trị vô hướng là “nhiệt độ” của node đó Gateway được coi là nguồn nhiệt và có nhiệt độ cao nhất, đại diện cho năng lực vận chuyển được dữ liệu đến gateway 31 là tuyệt đối (vì nó chính là gateway) Các nodes càng xa gateway, thuộc tính “nhiệt độ”

29 từ ngữ tiếng Anh chuyên ngành là “field-based routing”

30 đối với giải thuật định tuyến HEAT nguyên bản [5] thì giá trị đó là “nhiệt độ”

31 “năng lực chuyển được dữ liệu đến gateway” sẽ được đề cập nhắn gọn là “năng lực vận chuyển” trong suốt phần còn lại của Luận Văn của nó càng thấp so với nguồn nhiệt, tương ứng với năng lực vận chuyển giảm xuống khi di chuyển ra xa Cách tính toán giá trị “nhiệt độ” như trong lưu đồ Hình 1.5 cũng khá hợp lý khi xét tới cả cơ hội gửi được dữ liệu đến gateway qua nhiều con đường khác nhau Tuy nhiên, hệ số truyền nhiệt k được sử trong công thức lại là một đại lượng vô hướng, không có mối liên hệ cụ thể với các thuộc tính của mạng, do đó không có sự linh hoạt thích ứng với sự thay đổi của các thông số trong mạng theo các kịch bản khác nhau

Hình 1.18 Ví dụ về giá trị của trường "nhiệt độ" trong mạng sử dụng giao thức định tuyến HEAT

Trong ví dụ Hình 1.18, Node0 và Node1 có cùng giá trị “nhiệt độ” là 500, nhưng rõ ràng Node0 phải chịu tải lớn hơn nhiều so với Node1 và do đó dễ rơi vào trạng thái quá tải hơn Khi đó, mặc dù khả năng chuyển tiếp được dữ liệu về gateway thông qua Node0 đã giảm, nhưng miễn việc cập nhật giá trị “nhiệt độ” giữa Node0 với gateway vẫn còn diễn ra được thì giá trị “nhiệt độ” của Node0 vẫn là 500, không đúng với tình hình thực tế của mạng

Trong Luận Văn này, khái niệm “nhiệt độ” của một node được thay thế bằng một cặp giá trị thể hiện thời gian và tỉ lệ thành công khi gửi dữ liệu đến gateway của node đó và từ “heat” sẽ được sử dụng để đề cập đến cặp giá trị này trong suốt phần còn lại của báo cáo Luận Văn như là một cách để ghi nhận lại ý tưởng ban đầu của giải thuật Cặp thuộc tính này cũng có tính chất lan truyền từ gateway ra xung quanh, nhưng không lan truyền theo hệ số vô hướng như đối với “nhiệt độ”, mà lan truyền theo kiểu cộng dồn về mặt thời gian và nhân tích lũy về mặt tỉ lệ gửi thành công

// Cặp giá trị thay thế cho giá trị “nhiệt độ” heat {

PRR (%) // tỉ lệ gửi thành công đến gateway latency (s) // độ trễ khi gửi đến gateway

PRR(n) là tỉ lệ gửi thành công gói tin đến gateway qua n hops prr i là tỉ lệ thành công của lần gửi thứ i trước khi gói tin đến gateway t radio là thời gian gửi dữ liệu qua sóng vô tuyến của một lần gửi t_queue i là thời gian chờ của gói tin từ lúc nó được nhận đến lúc nó được gửi đi tiếp trong lần chuyển tiếp thứ i trước khi đến gateway

Ví dụ, giả sử ta có các Node A, B, C với Node A có “heat” như sau:

Theo đó tỉ lệ để Node A gửi thành công một gói tin đến gateway là 97% và khoảng thời gian kể từ khi Node A bắt đầu gửi đến khi gateway nhận được là 25.1 giây

Nếu Node A nói trên tiếp nhận chuyển tiếp dữ liệu từ Node B và Node C đến gateway, và:

- Node B có tỉ lệ gửi gói thành công đến Node A là 100% với thời gian là 0.1 giây trong trường hợp thành công Sau khi gói tin từ Node B đến được Node A, gói tin sẽ phải nằm trong hàng đợi 15 giây trước khi nó được Node A gửi đi tiếp

- Node C có tỉ lệ gửi gói thành công đến Node A là 99% với thời gian cũng là 0.1 giây trong trường hợp thành công Nhưng sau khi gói tin từ Node C đến được Node A, nó chỉ phải đợi trong hàng đợi 5 giây trước khi nó được Node A gửi đi tiếp

Nếu Node B và Node C chọn gửi gói tin đến gateway thông qua Node A, thì:

- Tỉ lệ gửi thành công của Node B đến gateway thông qua Node A là 100% x 97% = 97% với thời gian là 0.1 + 15 + 25.1 = 40.2 (giây) trong trường hợp thành công Giả sử Node B không còn node lân cận nào khác, giá trị “heat” của nó là {97%, 40.2 giây}

- Tỉ lệ gửi thành công của Node C đến gateway thông qua Node A là 99% x 97% = 96.03% nhưng với thời gian là 0.1 + 5 + 25.1 = 30.2 (giây) trong trường hợp thành công Giả sử Node C không còn node lân cận nào khác, giá trị “heat” của nó là {96.03%, 30.2 giây} Ở đây, mặc dù giá trị “heat” của Node A là giá trị đặc trưng cho năng lực vận chuyển của nó Nhưng vấn đề là khi một node nào đó muốn gửi được dữ liệu về gateway thông qua Node A thì phải gửi được cho Node A Do đó, tỉ lệ gửi gói thành công đến Node A là một thông số quan trọng để định tuyến Bên cạnh đó, đối với các Node B và C, thông tin về giá trị “heat” của Node A là chưa đủ để định tuyến vì chúng không thể biết được gói tin chúng gửi đến Node A sẽ phải đợi bao lâu trước khi được chuyển tiếp (do Node A quyết định), trong khi phần thời gian này cũng là một trong những yếu tố đáng cân nhắc Vì vậy, để có thể định tuyến chính xác, Node B và Node C phải có đủ những thông tin gồm:

1) Hai trường trong giá trị “heat” của Node A bao gồm NodeA.heat.PRR 97% và NodeA.heat.latency = 25.1

2) Thời gian phải xếp trong hàng đợi của các gói tin từ sau khi đến được Node

A đến trước khi chúng được chuyển tiếp, trong ví dụ trên là 15 giây đối với các gói tin đến từ Node B, và 5 giây đối với các gói tin đến từ Node C 3) Tỉ lệ gửi thành công gói tin đến Node A của Node B và Node C, lần lượt là 100% và 99% sau đó tính toán và xác định được độ tốt của tuyến đường gửi dữ liệu về gateway thông qua Node A như đã trình bày Để giúp Node B và Node C biết được những thông số cần thiết như đã liệt kê, Node A sẽ cần phải thực hiện “quảng bá” những thông số của mình Đây chính là ý tưởng chính của khái niệm “định tuyến dựa trên chất lượng dịch vụ của node lân cận” sẽ được trình bày ở tiểu mục 1.2.5

Khi sử dụng cơ chế phân chia thời gian như được đề xuất trong Luận Văn này, thời gian gửi gói tin qua sóng vô tuyến sẽ bị lược bỏ vì nó đã được bù trừ khi tính thời gian gói tin được xếp trong hàng đợi Chi tiết được trình bày trong các phần sau của Luận Văn.

So sánh giá trị “heat” mới

Để chọn được tuyến đường tốt nhất đến gateway, ta cần phải so sánh được các cặp PRR và latency đã mô tả Tùy theo ứng dụng cụ thể trong thực tế mà PRR và latency có thể có hệ số thể hiện độ quan trọng khác nhau Tuy nhiên, trong giới hạn nghiên cứu chiến lược tìm đường, Luận Văn này đề xuất sử dụng PRR là tiêu chí chính để so sánh Khi PRR bằng nhau thì các tuyến đường mới được so sánh dựa vào latency

Link1= {PRR1, latency1} Link2= {PRR2, latency2}

- Nếu △ > 0: Link1 tốt hơn Link2

- Nếu △ < 0: Link2 tốt hơn Link1

- Nếu △ = 0: Link1 và Link2 tốt như nhau

Xác định giá trị “heat”

Thông thường, khi tính xác suất gửi thành công một gói tin đến gateway của một node, ta cần phải tính dựa trên tất cả các cơ hội mà node đó có

Chẳng hạn, một node có 2 tuyến đường để gửi được dữ liệu đến gateway Tuyến đường thứ nhất có xác suất thành công 97% với thời gian 25.1 giây trong trường hợp gửi được, tuyến đường thứ hai có xác suất thành công 95% với thời gian 15 giây trong trường hợp gửi được Nếu node đó được lập trình để ưu tiên sử dụng tuyến đường thứ nhất và khi gửi thất bại thì chuyển qua sử dụng tuyến đường còn lại, xác suất gửi được dữ liệu thành công đến gateway của node đó là:

Về mặt thời gian, có một chút rắc rối khi tính thời gian gửi trung bình nếu cố xét hết tất cả các cơ hội gửi gói đến gateway của một node Bởi vì trong trường hợp tuyến đường thứ nhất thất bại, gói tin đã gửi thất bại sẽ phải đợi thêm một khoảng thời gian nữa (tùy theo kỹ thuật đa truy cập 32 được sử dụng) thì mới có thể được gửi lại qua tuyến đường thứ hai Trong ví dụ vừa rồi, giả sử sau khi gửi qua tuyến đường thứ nhất thất bại, gói tin sẽ phải đợi thêm 20 giây trước khi nó được gửi lại

32 đa truy cập (multiple access): là kỹ thuật phân phối kênh truyền dễ bị đụng độ cho các lượt truy cập khác nhau vào cùng một điểm qua tuyến đường thứ hai, thì node này có xác suất gửi dữ liệu thành công như đã tính ở trên và với thời gian trung bình là:

Cách tính như vậy cũng có điểm hợp lý, tương đối phù hợp với lý thuyết xác suất và thống kê, nhưng:

1) Nó làm cho kết quả tính xác suất gửi dữ liệu thành công về gateway của mỗi node tiến đến hoặc tiệm cận 100% dẫn đến việc so sánh PRR không còn nhiều ý nghĩa, trong khi đó ngay tại thời điểm gửi dữ liệu qua tuyến đường tốt nhất bị thất bại, việc gửi lại dữ liệu qua các tuyến đường khác cũng không thể tiến hành ngay lập tức, nên con số tỉ lệ thành công gần 100% đã tính không phải là tỉ lệ thành công cho một lần gửi, không phù hợp với khái niệm tuyến đường tốt nhất, mà đúng hơn là một node nhờ node khác thử gửi qua nhiều tuyến đường khác nhau

2) Trong ví dụ trên, mặc dù tỉ lệ gửi dữ liệu thành công về gateway qua tuyến đường thứ nhất lên đến 97%, nhưng một khi tuyến đường đó đã có sự cố, thì hàng loạt lượt gửi kế tiếp theo tuyến đường này đều sẽ thất bại, tất cả chúng đều sẽ phải đợi 20 giây trước khi được gửi lại, và mỗi lần gửi lại cũng phải tốn 15 giây, dẫn đến chi phí trung bình về thời gian để gửi lại thành công lượng lớn gói tin như vậy vào tuyến đường khác sẽ rất cao chứ không đúng với kết quả tính toán như trên là 25.397 giây

Vì vậy, ta sẽ dùng một lựa chọn tốt hơn là mỗi node sẽ lấy giá trị “heat” là thông số của tuyến đường tốt nhất mà nó đang có để gửi được dữ liệu về gateway , nếu tuyến đường này gặp sự cố, thì giá trị “heat” sẽ được cập nhật lại theo thông số của tuyến đường tốt nhất tại thời điểm sau đó, giúp giá trị “heat” có ý nghĩa cập nhật tức thời hơn về tình hình của mạng Như trong ví dụ vừa rồi, khi tuyến đường thứ nhất vẫn còn khả dụng, thì giá trị “heat” của node đó là {97%, 25.1 giây} Còn khi tuyến đường này xảy ra sự cố hoặc đã được khai thác hết thông năng, toàn bộ luồng dữ liệu sẽ được chuyển hết sang tuyến đường thứ hai thì lúc này giá trị “heat” sẽ được cập nhật lại thành {95%, 15 giây}

PRR = bestLink().PRR latency = bestLink().latency

Vẫn cần phải nhắc lại để lưu ý rằng giá trị “heat” này là “năng lực vận chuyển” của Node A, chứ không phải độ tốt của tuyến đường đi từ Node B hay Node C và thông qua Node A để tới được gateway Để tránh nhập nhằng, khái niệm “chất lượng tuyến đường” được đưa ra Nó thể hiện tỉ lệ gửi được gói tin thành công đến gateway thông qua một node và thời gian ước tính kể từ khi bắt đầu gửi qua node đó cho đến khi gói tin đến được gateway Cách phân biệt hai khái niệm giá trị “heat” và “chất lượng tuyến đường 33 ” được mô tả như trong Bảng 1.3 dưới đây

Bảng 1.3 Phân biệt khái niệm giá trị "heat" với "chất lượng tuyến đường"

Giá trị “heat” Chất lượng tuyến đường Thuộc tính của một node Thuộc tính của tuyến đường đi qua một node lân cận

Xác định bằng chất lượng tuyến đường tốt nhất node đó có

- Giá trị heat của node lân cận

- Thời gian gói tin sẽ phải chờ tại node lân cận

- Tỉ lệ gửi thành công đến node lân cận

33 “chất lượng tuyến đường”: đầy đủ là “chất lượng tuyến đường gửi dữ liệu về gateway”

Định tuyến dựa trên chất lượng dịch vụ của node lân cận (Adjacent-QoS-based

Xuất phát từ ý tưởng của giải thuật định tuyến HEAT, Luận Văn này đề xuất một giải thuật định tuyến dựa trên “chất lượng dịch vụ của node lân cận”, tiếng Anh:

“Adjacent-QoS-based Routing” - (AQoSR) Trong đó, mỗi node không chỉ đọc cảm biến, tạo gói tin để gửi về gateway, mà còn đóng vai trò là một nhà cung cấp dịch vụ vận chuyển dữ liệu cho các nodes lân cận nếu nó có tuyến đường tốt hơn để gửi dữ liệu về gateway Một node là khách hàng sử dụng dịch vụ của một node khác vẫn có thể là nhà cung cấp dịch vụ cho những nodes khác nữa, tương tự như mô hình thuê rồi cho thuê lại

Ví dụ ta có các Node D, E, F như trong Hình 1.19

Hình 1.19 Ví dụ về mô hình sử dụng dịch vụ và cung cấp lại dịch vụ vận chuyển dữ liệu về gateway

Node D nằm ngoài tầm phủ sóng của gateway, nhưng lại có thể gửi được dữ liệu về gateway thông qua Node E Ta nói Node E là nhà cung cấp dịch vụ còn Node

D là khách hàng Mặt khác, Node F không nằm trong vùng phủ sóng của cả gateway lẫn Node E, nhưng lại trong vùng phủ sóng của Node D, nên nó có thể gửi được dữ liệu về gateway thông qua Node D Như vậy, Node F là khách hàng, còn Node D lại là nhà cung cấp dịch vụ vận chuyển dữ liệu về gateway Điều đó có nghĩa là, Node D sử dụng dịch cung cấp bởi Node E, rồi lại cung cấp dịch vụ cho Node F

Tương tác giữa các nodes liên thuộc trong mạng gồm các hoạt động chính:

(1) Node nào có tuyến đường để gửi được dữ liệu về gateway thì nó sẽ liên tục quảng bá ra các nodes trong phạm vi phủ sóng về khả năng của mình (2) Mỗi node nhận được gói tin quảng bá sẽ khởi tạo quá trình thiết lập giao tiếp với node gửi quảng bá nếu còn có thể 34

(3) Các nodes định kì gửi gói tin cập nhật lại khả năng gửi được dữ liệu đến gateway của mình cho các nodes đã thiết lập giao tiếp

(4) Mỗi node gửi dữ liệu nó đang có qua tuyến đường vận chuyển dữ liệu đến gateway tốt nhất mà nó biết Nếu bị từ chối, node gửi sẽ thử lại với tuyến đường tốt nhất trong những tuyến đường còn lại Trong trường hợp không nhận được hồi âm trong một thời gian nhất định (do gói tin gửi đi hoặc gói tin phản hồi bị mất), node gửi sẽ thử lại vài lần trước khi chuyển luồng dữ liệu sang tuyến đường khác

(5) Mỗi node đều có thể tiếp nhận hoặc từ chối gói tin dữ liệu node khác nhờ vận chuyển đến gateway Nếu tiếp nhận, nó sẽ phản hồi bằng một gói tin ACK với nội dung xác nhận Nếu vì lý do gì đó không thể tiếp nhận, nó cũng sẽ phản hồi bằng một gói tin từ chối

34 Trong một số tình huống, có node tuy nhận được gói tin quảng bá của node khác nhưng không thể thiết lập được giao tiếp do một trong hai nodes đã đạt số lượng giao tiếp tối đa hoặc lượt thiết lập giao tiếp đã bị node khác chiếm

Hình 1.20 Ví dụ về tương tác giữa các nodes trong mạng

Trong ví dụ Hình 1.20, ban đầu gateway sẽ quảng bá ra xung quanh bộ thông số là {100%, 0 giây} do nó chính là đích đến của tất cả các gói tin trong mạng Sau khi tiếp nhận được thông tin này, Node 0 và Node 1 thực hiện thiết lập giao tiếp với gateway Tiếp theo, Node 0 và Node 1 lúc này đã có thể gửi được dữ liệu đến gateway với tỉ lệ thành công 100% (giả sử tín hiệu ổn định) và độ trễ chỉ bằng thời gian thu phát không dây – cỡ dưới 0.1 giây, chúng bắt đầu phát đi những gói tin quảng bá về năng lực vận chuyển cùng với thời gian mà mỗi node “khách hàng” sẽ phải đợi trong mỗi lần gửi dữ liệu nhờ vận chuyển

Khi Node 1 quảng bá năng lực vận chuyển của nó, cả gateway, Node 0, và Node

2 đều sẽ nhận được thông tin Tuy nhiên, gateway sẽ không có bất cứ phản hồi nào vì vốn dĩ nó đã có kết nối với Node 1 rồi Node 2 trước đó chưa thiết lập giao tiếp với Node 1 nên nó sẽ khởi tạo quá trình thiết lập giao tiếp với Node 1 và nhờ đó có được tuyến đường gửi được dữ liệu đến gateway thông qua Node 1 Node

0 mặc dù đã có giao tiếp trực tiếp với gateway nhưng vẫn sẽ thiết lập giao tiếp với Node 1 để hỗ trợ cân bằng tải trong trường hợp cần thiết

Khi Node 0 quảng bá năng lực vận chuyển của nó, các Node 2, 3, 4, 5 (chưa có khả năng gửi được dữ liệu đến gateway) đều sẽ nhận được và thực hiện khởi tạo giao tiếp với Node 0

Như vậy, tất cả các nodes trong mạng đều đã có tuyến đường có thể gửi được dữ liệu đến gateway Tuy nhiên, có thể thấy, các Node 3, 4, và 5 muốn chuyển được dữ liệu đến gateway thì đều phải gửi qua Node 0 trong khi Node 2 lại có hai sự lựa chọn là gửi qua Node 0 hoặc Node 1 Lúc này nếu tần suất phát sinh và gửi dữ liệu của các nodes tăng lên thì Node 0 sẽ dễ quá tải hơn Node 1 Hiện tượng quá tải có thể xảy ra theo nhiều cách (ví dụ như kênh truyền gần như luôn bận; hoặc hàng đợi gần như luôn đầy do gói tin đến quá nhiều, đẩy đi không xuể;…) nhưng đều dẫn đến một kết quả như nhau, là xảy ra hiện tượng mất gói

Lại giả sử, Node 2, khi gửi dữ liệu đến Node 1, thì gói tin sẽ phải đợi trong hàng đợi 10 giây, trong khi đó nếu gửi đến Node 0 thì gói tin chỉ cần đợi 5 giây trước khi nó được chuyển tiếp đến gateway Rõ ràng, nếu tỉ lệ chuyển gói tin thành công đến gateway thông qua Node 0 và qua Node 1 là như nhau, thì tuyến đường đi qua Node 0 là tốt hơn Thế nhưng, do Node 0 là điểm trung chuyển duy nhất mà các Node 3, 4, và 5 phải gửi dữ liệu qua thì mới gửi được dữ liệu đến gateway, nên nếu tần suất phát sinh và gửi dữ liệu của các nodes đủ dày, nó sẽ bị quá tải Trong trường hợp Node 0 quá tải, dẫn đến một số gói gửi đến Node 0 bị mất, làm cho tỉ lệ gửi thành công gói tin đến gateway thông qua Node 0 bị giảm xuống, thì lúc này tuyến đường gửi dữ liệu về gateway thông qua Node 1 được xem là tuyến đường tốt hơn

Tuyến đường nào mà qua đó tỉ lệ gửi được dữ liệu đến gateway cao hơn thì tốt hơn Nếu tỉ lệ gửi được dữ liệu đến gateway là như nhau, thời gian gửi qua tuyến đường nào ngắn hơn thì tuyến đường đó tốt hơn và Định tuyến dựa vào chất lượng dịch vụ của node lân cận đơn giản là lựa chọn node lân cận cung cấp được dịch vụ vận chuyển tốt nhất (tuyến đường đi qua đó là tốt nhất) để nhờ chuyển tiếp dữ liệu về gateway.

Thiết kế

Chống đụng độ

Trong một mạng đa truy cập như được mô tả trong Luận Văn này, các cơ chế chống đụng độ là không thể thiếu Phần này trình bày hai kỹ thuật chống đụng độ đơn giản để hiện thực được giải thuật định tuyến dựa trên chất lượng dịch vụ của node lân cận là phân chia thời gian và nhảy tần

1.3.1.1 Phân chia thời gian Ý tưởng phân chia thời gian Để hạn chế đụng độ, mỗi node chỉ duy trì giao tiếp với một số lượng giới hạn n node lân cận, và việc giao tiếp với mỗi node lân cận sẽ được thực hiện trong một khung thời gian dành riêng cho node đó Cách làm này được gọi là slotted transmission – một kỹ thuật đa truy cập phân chia thời gian 35 đơn giản

Tại mỗi node, thời gian được chia thành các khung thời gian đều nhau, thời điểm bắt đầu các khung thời gian được căn chỉnh đồng bộ giữa các nodes, mỗi khung thời gian được dành riêng để giao tiếp với một node lận cận như trong Hình 1.21 dưới đây:

35 Time Division Multiple Access (TDMA)

Hình 1.21 Ví dụ về kỹ thuật định thời giao tiếp bằng các khung thời gian

Trong ví dụ này, mỗi node sử dụng 6 khung thời gian được đánh số từ 1 đến 6 để giao tiếp với tối đa 6 nodes lân cận ( trong mô hình mạng mô phỏng, số khung thời gian là 10 ) Việc giao tiếp với mỗi node lân cận sẽ được thực hiện trong một khung thời gian riêng biệt Chẳng hạn, Node 4 dành riêng khung thời gian số 5 của nó để giao tiếp với Node 2, và Node 2 cũng dành riêng khung thời gian số 3 của nó để giao tiếp với Node 4 Như vậy, Node 2 và Node 4 sẽ chỉ giao tiếp với nhau trong khung thời gian số 5 đối với Node 4, và cũng là khung thời gian số 3 đối với Node 2 Những khung thời gian còn lại chưa thiết lập giao tiếp với node nào được gọi là những khung thời gian trống Định thời việc chuyển tiếp dữ liệu và thời gian xếp hàng đợi tại các nodes

Trong kỹ thuật phân chia thời gian như đang được mô tả, luồng dữ liệu và việc định thời chuyển tiếp các gói tin được thực hiện như trong Hình 1.22 dưới đây

Hình 1.22 Ví dụ về luồng dữ liệu và định thời chuyển tiếp dữ liệu trong mạng sử dụng kỹ thuật phân chia thời gian

Các mũi tên theo chiều lên minh họa cho việc một node gửi dữ liệu cho một node khác mà qua đó tuyến đường gửi dữ liệu đến gateway là tốt nhất, các mũi tên theo chiều xuống tượng trưng cho gói tin xác nhận về việc đã nhận dữ liệu Theo thiết kế hiện tại, mạng chỉ hỗ trợ uplink, không hỗ trợ downlink Vì vậy, sẽ không có gói tin xác nhận gửi xuống từ gateway xuống tận các nodes không có giao tiếp trực tiếp, mà chỉ có gói tin xác nhận của node trực tiếp nhận gói tin để chuyển đi Một node được xem là hết trách nhiệm với một thông điệp mang dữ liệu khi nó đã gửi dữ liệu đó cho node khác và được chấp thuận

Dữ liệu gửi lên từ một node có thể là dữ liệu do chính node đó tạo ra (dữ liệu cảm biến), hoặc là dữ liệu từ node khác gửi đến để chuyển tiếp Tất cả những dữ liệu này đều được đẩy vào một hàng đợi để chuyển tiếp qua tuyến đường tốt nhất Trong ví dụ ở Hình 1.22, tại thời điểm t = t10, Node 4 gửi toàn bộ dữ liệu trong hàng đợi của nó cho Node 2 Sau đó, tại thời điểm t = t12, Node 2 gửi toàn bộ dữ liệu trong hàng đợi của Node 2 lên Gateway, bao gồm cả dữ liệu đã nhận từ Node

4 trong khung thời gian từ t10 đến t11 Tương tự, tại thời điểm t = t18, Node 2 lại gửi toàn bộ dữ liệu trong hàng đợi của nó lên Gateway, bao gồm cả dữ liệu nó đã nhận trước đó từ Node 3 và Node 4 trong các khung thời gian (t13 – t14) và (t16 – t17)

Như vậy, ta có thể thấy cả Node 3 và Node 4 đều có giao tiếp được thiết lập với Node 2 và đều có thể gửi dữ liệu cho Node 2 để Node 2 chuyển tiếp đến Gateway Nhưng do Node 2 lại chỉ có thể gửi được những dữ liệu này đến Gateway trong khung thời gian số 5 của nó (cũng là khung thời gian số 2 đối với Gateway), nên những gói tin đến Node 2 vào các khung thời gian khác đều phải đợi Cụ thể, tại Node 2, những gói tin đến từ Node 3 phải đợi khoảng năm khung thời gian thì mới được chuyển tiếp, còn những gói tin đến từ Node 4 chỉ cần đợi khoảng hai khung thời gian Vậy nên, theo góc nhìn của Node 3 và Node 4, năng lực vận chuyển của Node 2 không chỉ được phản ánh bởi giá trị “heat” của Node 2, mà còn phụ thuộc vào việc gói tin chúng gửi sang Node 2 phải đợi bao lâu trước khi được Node 2 gửi đi, và tỉ lệ gửi thành công khi gửi dữ liệu đến Node 2 là bao nhiêu, như đã được mô tả trong tiểu mục 1.2.2

Thực ra cách tính này cũng chỉ là tính xấp xỉ Sở dĩ nói “xấp xỉ” là do thời điểm mà gói tin đến được Node 2 không phải ngay điểm bắt đầu khung thời gian tương ứng, mà phải sau một khoảng thời gian ngắn truyền qua sóng vô tuyến nữa (ngắn hơn nhiều so với độ dài của một khung thời gian) Chưa kể, tại khung thời gian để chuyển gói tin đi, tùy vào độ dài hàng đợi của node gửi mà các gói tin còn có thể được gửi sớm hoặc muộn Để cho đơn giản, các nodes sẽ tính thời gian đợi của các gói tin sau khi đến là bằng tổng độ dài các khung thời gian từ khi gói tin đến cho đến trước khung thời gian chúng được chuyển tiếp Cụ thể, thời gian chờ đối với các gói tin đến từ Node 3 là khoảng 25 giây, còn thời gian chờ đối với các gói tin đến từ Node 4 là khoảng 10 giây

Cách thiết lập giao tiếp theo các khung thời gian

Nếu một node có n khung thời gian và đã thiết lập giao tiếp với k nodes (k < n), thì node đó sẽ có e = n – k khung thời gian trống Trong mỗi khung thời gian trống như vậy, node sẽ phát đi một gói tin quảng bá bao gồm những thông tin cơ bản nhất về năng lực vận chuyển của nó

Hình 1.23 Minh họa việc các nodes quảng bá khung thời gian trống

Xét ví dụ minh họa trong hình Hình 1.23, trong khoảng thời tgian từ t10 đến t14, Node 0 đã có tuyến đường gửi được dữ liệu đến gateway và có các khung thời gian trống là 3, 4, và 6 Vì vậy, nó tiến hành gửi các gói tin quảng bá năng lực vận chuyển của nó ra xung quanh trong các khung thời gian trống này

Thông tin mà Node 0 quảng bá trong mỗi khung thời gian trống là giá trị “heat” của nó sau khi đã cộng thêm thời gian mà các gói tin phải chờ trước khi được chuyển tiếp nếu chúng đến vào khung thời gian tương ứng (tương tự như cách tính vừa được trình bày ở trang trước) Giả sử Node 0 có thể gửi được dữ liệu đến gateway với tỉ lệ thành công là 97% và trong khoảng thời gian là 0.1 giây trong trường hợp gửi được, thì trong khung thời gian số 3, Node 0 sẽ quảng bá bộ thông số là {PRR = 97%, latency = 10.1} với ý nghĩa: Nếu gửi dữ liệu về gateway qua Node 0 vào khung thời gian số 3 của nó thì tỉ lệ thành công là 97% và tốn thời gian khoảng 10.1 giây nếu gửi được Tương tự, nếu một gói tin đến được Node 0 vào khung thời gian số 6 của Node 0, thì gói tin sẽ phải đợi trong hàng đợi khoảng 25 giây thì mới được chuyển tiếp Do đó Node 0 sẽ quảng bá bộ thông số {PRR = 97%, latency = 25.1}, có nghĩa là nếu gửi dữ liệu về gateway thông qua Node 0 vào khung thời gian số 6 của nó thì tỉ lệ thành công là 97% và tốn thời gian khoảng 25.1 giây nữa để đến được gateway

Tại thời điểm t10, cả Node 1 và Node 2 đều nhận được gói tin quảng bá từ Node 0 và sau đó đều phản hồi bằng một gói tin đăng ký thiết lập khung thời gian giao tiếp với Node 0 Do đặc trưng của mạng không dây và sự tương đồng về phần cứng giữa các nodes, khi hai gói tin đăng ký thiết lập giao tiếp từ Node 1 và Node

2 cùng đến Node 0 thì Node 0 không thể nhận được gói nào do xung đột tín hiệu Nhưng trong ví dụ này giả sử tại Node 0 có cường độ tín hiệu của Node 1 là mạnh hơn, Node 0 sẽ chỉ nhận được gói tin đến từ Node 1 và tiến hành thiết lập giao tiếp với Node 1 Đến thời điểm t11, Node 0 cũng có một khung thời gian trống nữa là khung thời gian số 4 Tuy nhiên, do trong khoảng thời gian này tất cả các nodes khác đều bận nên không có node nào phản hồi gói tin quảng bá của nó cả Sau đó, đến khung thời gian số 6, cả hai Node 1 và 2 đều đang có khung thời gian trống, nhưng lần này Node 1 sẽ không đăng ký thiết lập giao tiếp nữa vì giao tiếp giữa Node 1 và Node 0 đã được thiết lập trước đó Lúc này chỉ có Node 2 đăng ký thiết lập giao tiếp với Node 0 nên dễ dàng thiết lập thành công

Quá trình các nodes giao tiếp để thiết lập giao tiếp được diễn tả như trong Hình 1.24 dưới đây:

Hình 1.24 Quá trình hai node thiết lập khung thời gian dành riêng để giao tiếp với nhau

Duy trì mạng

1.3.2.1 Dữ liệu duy trì tại mỗi node trong mạng

Tại mỗi thời điểm, các nodes đều sẽ duy trì một bảng thông tin về các nodes lân cận, với các trường như được đặc tả trong Hình 1.27 sau:

Hình 1.27 Các trường trong bảng dữ liệu được duy trì trong các nodes

- address: Địa chỉ của node lân cận

- forwardAddress: Địa chỉ của node mà node lân cận sẽ chuyển tiếp gói tin đi tiếp (dùng để chống loopback 37 về sau)

37 Loopback: quay ngược trở lại

- percentToGW: Tỉ lệ thành công khi chuyển một gói tin đến gateway thông qua node lân cận

𝑝𝑒𝑟𝑐𝑒𝑛𝑡𝑇𝑜𝐺𝑊 = 𝑝𝑒𝑟𝑐𝑒𝑛𝑡𝑇𝑜𝑁𝑜𝑑𝑒 × 𝑁𝑜𝑑𝑒 𝑃𝑅𝑅 với percentToNode là tỉ lệ gửi gói tin thành công từ node hiện tại đến node lân cận trong 100 lần gửi gần nhất và Node.PRR là tỉ lệ gửi thành công đến gateway của node đó

Ví dụ, giá trị “heat” của node lân cận là {97%, 25.1s} và tỉ lệ gửi gói tin thành công từ node hiện tại đến node lân cận đó là 90%, thì:

- timeToGW: Thời gian dự kiến cần để chuyển một gói tin đến gateway thông qua node lân cận, do node đó tự tính và gửi sang

- slot: Số hiệu cục bộ của khung thời gian mà node hiện tại dành riêng ra để giao tiếp với node lân cận

- lastState: Mảng lưu kết quả thành công/thất bại của 100 lần gửi gần nhất đến node lân cận

- updateFirst: Dùng để xác định xem có nhường cho node lân cận gửi gói tin cập nhật trước hay không

- seqNum: Sequence number 38 của gói tin cuối cùng đã gửi cho node lân cận, dùng để so sánh với sequence number trong gói ACK 39 trả về

- sentPacket : Số gói tin đã gửi cho node tương ứng, chỉ dùng để thống kê, gỡ lỗi

- ackPacket : Số gói tin đã được ACK bởi node tương ứng, chỉ dùng để thống kê, gỡ lỗi

- r_packet : Số gói tin chuyển tiếp đã nhận được từ node tương ứng, chỉ dùng để thống kê, gỡ lỗi

38 Sequence number: Mã số được gắn thêm vào gói tin để xác định thứ tự gửi đi hoặc để đối chiếu với gói tin ACK

39 ACK: Viết tắt của từ acknowledgement, dùng để chỉ loại gói tin xác nhận trong mạng máy tính

Hình 1.28 Ví dụ về bảng dữ liệu các nodes lân cận tại một node

Cập nhật dữ liệu mạng giữa các nodes

Mặc dù trong lúc thiết lập các kết nối và hình thành mạng, các nodes đã có được những dữ liệu về chất lượng tuyến đường đi qua các nodes lân cận rồi, nhưng những dữ liệu này còn thay đổi liên tục theo thời gian, theo tình huống thực tế của mạng Vì vậy luôn cần phải có những gói tin cập nhật qua lại thường xuyên

Việc cập nhật dữ liệu mạng giữa hai nodes được tiến hành trong khung thời gian mà hai nodes đó dành riêng để giao tiếp với nhau như đã được mô tả trong trong Hình 1.29 dưới đây:

Hình 1.29 Giao tiếp giữa hai nodes trong khung thời gian dành riêng

Tại thời điểm bắt đầu của mỗi khung thời gian, một trong hai nodes (theo giao ước giữa chúng lúc khởi tạo giao tiếp với nhau, trong ví dụ này là Node 0) sẽ khởi tạo quá trình cập nhật dữ liệu thông thường bằng cách gửi một gói conventional update chứa những thông tin gồm:

} để cho Node 1 có thể tính được chất lượng tuyến đường đi qua Node 0 Sau đó, Node 1 sẽ phản hồi lại với những thông tin tương ứng, quá trình cập nhật được hoàn tất, và hai node bắt đầu gửi dữ liệu người dùng

Giả sử chiều của dữ liệu trong trường hợp này là Node 0 gửi dữ liệu cho Node 1 để nhờ Node 1 chuyển tiếp Nếu trong lúc Node 0 đang gửi dữ liệu, Node 1 vì lý do nào đó tuy vẫn nhận được gói tin từ Node 0 nhưng không thể tiếp nhận, Node

1 sẽ gửi lại cho Node 0 một gói tin từ chối đồng thời cập nhật lại thông tin mới nhất về tuyến đường đi qua Node 1 cho Node 0 được biết, gọi là một exceptional update Sau khi Node 0 nhận được exceptional update, nó cũng sẽ phản hồi lại cho Node 1 biết liệu rằng nó sẽ tiếp tục gửi dữ liệu đi qua Node 1 nữa hay không Nếu có, nó sẽ tiếp tục gửi dữ liệu cho đến hết khung thời gian Ngược lại, Node 1 sẽ nhanh chóng đi vào chế độ ngủ để tiết kiệm năng lượng

Trong trường hợp conventional update bị thất bại, sau khi hoàn tất gửi dữ liệu người dùng, hai nodes sẽ cố thử thực hiện lại quá trình cập nhật này cho đến khi thành công hoặc đến hết khung thời gian

Hình 1.30 Lưu đồ giải thuật việc cập nhật dữ liệu mạng giữa các nodes

Tham gia và rời mạng

Một node khi vừa được khởi động lên, nó sẽ có một trục thời gian với tất cả các khung thời gian đều trống; ngay sau đó, nó bắt đầu lắng nghe các gói tin quảng bá về các khung thời gian trống của gateway và của các nodes đang có trong mạng để đồng bộ trục thời gian và để thiết lập các khung thời gian giao tiếp riêng với những nodes này

Với cách hoạt động như vậy, mỗi khi một node mới được khởi động, nó có thể dễ dàng nhanh chóng “hòa mạng”, và thời gian hòa mạng của node đó được xác định từ khi node được khởi động cho đến khi nó có tuyến đường có thể gửi được gói tin đến gateway

Sau khi hoàn tất hòa mạng, node mới bắt đầu quảng bá khung thời gian trống của nó nếu còn.

Chuyển tiếp dữ liệu

Một cách tổng quát, mỗi node trong mạng đều sẽ cố gắng gửi tất cả những dữ liệu người dùng mà nó có về gateway thông qua con đường tốt nhất mà nó có Ngay cả khi một node có giao tiếp trực tiếp với gateway, nếu tồn tại tuyến đường gián tiếp tốt hơn tuyến đường trực tiếp thì nó vẫn chọn tuyến đường gián tiếp để gửi

Hình 1.31 Ví dụ về trường hợp gửi gián tiếp tốt hơn gửi trực tiếp

Trong ví dụ Hình 1.31, tuy Node A và Gateway nằm trong vùng phủ sóng của nhau nhưng kết nối lại rất chập chờn do vị trí của chúng nằm ở khu vực biên của vùng phủ Trong khi đó, kết nối giữa Node A với Node B và giữa Node B với Gateway đều rất ổn định Trong trường hợp này, Node A gửi dữ liệu về Gateway gián tiếp thông qua Node B mặc dù tốn thêm thời gian nhưng đem lại tỉ lệ thành công cao hơn

Giả sử kết nối giữa Node A và Gateway trong Hình 1.31 là hoàn toàn ổn định, vẫn còn một trường hợp nữa mà Node A phải gửi dữ liệu về Gateway thông qua Node B đó là khi thời lượng của một khung thời gian giao tiếp giữa Node A với Gateway chỉ đủ để gửi một số lượng gói tin nhất định nhưng trên thực tế mỗi chu kỳ xoay vòng, Node A lại phải tiếp nhận số lượng gói tin nhiều hơn

Hình 1.32 Ví dụ về trường hợp tuyến đường tốt nhất đã được khai thác hết thông năng

Xét Node A trong Hình 1.32 Vào các khung thời gian 5, 6, và 1, nó đã tiếp nhận một lượng lớn dữ liệu từ một số nodes khác trong mạng Đến khung thời gian số

3, Node A có khoảng 5 giây để giao tiếp với Gateway tính cả thời gian trao đổi các gói tin cập nhật Trong khi đó, lượng dữ liệu mà Node A đang có là nhiều hơn hẳn so với số gói tin mà Node A có thể gửi được cho Gateway trong một khung thời gian 5 giây Vậy thì, để hạn chế mất gói, Node A hoặc là phải từ chối nhận thêm gói tin khi số gói đã nhận chạm tới số lượng tối đa có thể gửi được trong một khung thời gian, hoặc là phải tìm thêm đường khác để gửi, mà trong trường hợp này cụ thể là qua Node B Với cách làm thứ nhất, khi số gói tin Node A tiếp nhận đã chạm tới giới hạn số gói tin có thể gửi được trong một khung thời gian, luồng dữ liệu đi đến Node A buộc phải bị chuyển hướng trong khi Node A vẫn còn khả năng gửi được các gói tin qua Node B Cách làm này gây lãng phí khung thời gian giao tiếp đã thiết lập giữa Node A với Node B và giữa Node B với Gateway Cách làm thứ hai là một cách làm tốt hơn, giúp các nodes muốn gửi dữ liệu thông qua Node A có nhiều lựa chọn hơn Khi hàng đợi để gửi trực tiếp từ Node A đến Gateway đã đầy, Node A lập tức cập nhật lại giá trị “heat” của chính nó theo thông số của tuyến đường tốt nhất còn khả dụng, đồng thời thông báo tới các nodes “khách hàng” của nó về sự thay đổi này Khi đó, các nodes “khách hàng” của Node A có thể so sánh và lựa chọn giữa việc tiếp tục gửi dữ liệu qua Node A với việc chuyển luồng dữ liệu sang node khác Nếu tuyến đường đi qua Node A mặc dù đã giảm chất lượng nhưng vẫn là tuyến đường tốt nhất trong tất cả các tuyến đường còn lại, các nodes “khách hàng” của Node A vẫn sẽ tiếp tục gửi luồng dữ liệu đi qua Node A Ngược lại, nếu tuyến đường đi qua Node A lúc này không còn tốt bằng những tuyến đường khác, thì các nodes “khách hàng” của Node A sẽ chuyển luồng dữ liệu sang tuyến đường tốt nhất chúng có thông tin

Như vậy, Node A cần phải duy trì ít nhất hai hàng đợi, một hàng đợi dùng để chứa những gói tin sẽ được gửi trực tiếp cho Gateway và một hàng đợi khác dùng để chứa những gói tin sẽ được chuyển đến Gateway thông qua Node B Trong trường hợp tổng quát thì Node A sẽ duy trì cho mỗi node lân cận một hàng đợi, khi gói tin được sắp xếp gửi sang node nào để chuyển tiếp thì chúng sẽ được đẩy vào hàng đợi tương ứng dành cho node đó Mỗi khi có gói tin mới (tự tạo ra hoặc nhận từ node khác), Node A sẽ phân phối những gói tin này vào các hàng đợi theo thứ tự ưu tiên những hàng đợi ứng với những tuyến đường tốt nhất trước Hình 1.33 dưới đây giải thích kỹ hơn về mô hình này

Hình 1.33 Mô hình phân phối và chuyển tiếp các gói tin

Trong hình, mũi tên màu đỏ, dày nhất, chỉ vào hàng đợi của tuyến đường tốt nhất (ứng với Node 3, còn khả dụng), thể hiện độ ưu tiên cao nhất khi điều phối các gói tin vào các hàng đợi gửi đi Khi hàng đợi của Node 3 không còn tiếp nhận gói tin nữa, thì các bộ điều phối mới chuyển dòng các gói tin sang hàng đợi ứng với tuyến đường có chất lượng tốt thứ hai, là tuyến đường đi qua Node 6 Tương tự, khi hàng đợi của Node 6 cũng ngừng nhận thêm gói, các gói tin còn lại mới được đẩy vào hàng đợi để gửi qua Node 5

Ngoài ra, trong mỗi khung thời gian, cũng sẽ có một bộ gửi thực hiện chức năng lấy các gói tin đang có trong hàng đợi để gửi đi Trong trường hợp đang gửi mà việc gửi bị thất bại hoặc tuyến đường bị giảm chất lượng làm cho nó không còn là tuyến đường tốt nhất, các bộ gửi sẽ chuyển những dữ liệu còn lại trong hàng đợi về cho bộ điều phối để tiến hành điều phối lại Sau đó, node sẽ đi vào chế độ ngủ để tiết kiệm năng lượng

Lưu đồ giải thuật của các bộ điều phối (dispatcher) và các bộ gửi (deliverer) được thể hiện lần lượt trong các Hình 1.34 và Hình 1.35 sau đây:

Hình 1.34 Lưu đồ giải thuật bộ điều phối gói tin (Dispatcher)

Hình 1.35 Lưu đồ giải thuật bộ gửi (Deliverer)

Cấu trúc các tin nhắn

Cấu trúc tổng quát

Hình 1.36 Cấu trúc tổng quát của một thông điệp

Trong Hình 1.36 trên đây, một thông điệp có cấu trúc gồm 2 phần, là header và payload Trong đó, phần header chứa những thông tin về địa chỉ nguồn (địa chỉ nơi gói tin được tạo ra), địa chỉ đích (địa chỉ cuối cùng gói tin cần được gửi tới), kích thước tin nhắn tính bằng byte (tính cả header và payload), số hops mà gói tin đã đi qua, và một byte check-sum dùng để kiểm tra tính toàn vẹn của thông điệp Phần payload chứa thông tin về loại thông điệp và nội dung của thông điệp đó.

Các loại gói tin

Các thông điệp trong mạng đều có cấu trúc như được mô tả trong Hình 1.36 Theo đó, phần header của các thông điệp đều như nhau, còn phần payload sẽ khác nhau tùy theo loại thông điệp Phần này trình bày sự khác nhau trong cấu trúc payload của các loại thông điệp

1.4.2.1 Nhóm 1: Các gói tin dùng để thiết lập khung thời gian giao tiếp

FREE_SLOT: Gói tin quảng bá khung thời gian trống, dùng để quảng bá với các nodes lân cận về khung thời gian mà node gửi còn chưa sử dụng để giao tiếp riêng với nodes nào Đồng thời, gói tin quảng bá cũng mang theo những thông tin cần thiết để node nhận có thể tính toán được chất lượng tuyến đường đi qua node này

Bảng 1.4 Cấu trúc gói tin FREE_SLOT msgType FREE_SLOT startTimeSlot - startSendTime - percentToGW [percent]

TimeToGW [time] slot [slot] data - seqNum -

Trong đó, thông số percentToGW chính là heat.PRR của node gửi và timeToGW bằng heat.latency của node gửi cộng với thời gian phải chờ tính từ khung thời gian này đến khung thời gian sẽ gửi dữ liệu đi tiếp

REQUEST_SLOT: Gói tin đăng ký khung thời gian giao tiếp riêng, dùng để đăng ký sử dụng khung thời gian giao tiếp giữa hai nodes, gửi trong khung thời gian trống, khi nhận được gói tin quảng bá khung thời gian trống từ node khác

Bảng 1.5 Cấu trúc gói tin REQUEST_SLOT msgType REQUEST_SLOT startTimeSlot - startSendTime - percentToGW -

TimeToGW - slot [slot] data - seqNum -

ACK_REQUEST_SLOT_SUCCESS: Gói tin xác nhận việc đăng ký khung thời gian giao tiếp thành công, gửi khi chấp nhận thiết lập khung giao tiếp với một node khác

Bảng 1.6 Cấu trúc gói tin ACK_REQUEST_SLOT_SUCCESS msgType ACK_REQUEST_SLOT_SUCCESS startTimeSlot [time] startSendTime - percentToGW -

ACK_REQUEST_SLOT_FAIL: Gói tin từ chối thiết lập khung thời gian giao tiếp, gửi khi một khung thời gian đã quảng bá trước đó đã được đăng ký để giao tiếp với một node mà còn nhận được đăng ký từ một node khác

Bảng 1.7 Cấu trúc gói tin ACK_REQUEST_SLOT_FAIL msgType ACK_REQUEST_SLOT_FAIL startTimeSlot - startSendTime - percentToGW -

1.4.2.2 Nhóm 2: Duy trì dữ liệu định và cấu trúc mạng

UPDATE_HEAT_VALUE: Gói tin gửi giá trị HEAT của một node đến tất cả các nodes lân cận Sau một khoảng thời gian, node sẽ tạo ra gói tin này, và lên lịch gửi đến tất cả các nodes lân cận của nó theo các khung thời gian đã thiết lập với những nodes này

Bảng 1.8 Cấu trúc gói tin UPDATE_HEAT_VALUE msgType UPDATE_HEAT_VALUE startTimeSlot - startSendTime [time] percentToGW [percent]

TimeToGW [time] slot [slot] data - seqNum -

1.4.2.3 Nhóm 3: Các thông điệp mang nội dung cần gửi đến gateway

FORWARD_PACKET: Gói tin mang dữ liệu cần gửi đến gateway Có thể là gói tin do node tự tạo ra hoặc chuyển tiếp giúp node khác

Bảng 1.9 Cấu trúc gói tin FORWARD_PACKET msgType FORWARD_PACKET startTimeSlot - startSendTime - percentToGW -

TimeToGW - slot [slot] data [data] seqNum [number]

ACK_PACKET_TO_GW: Khi một node (sau đây gọi là node gửi) gửi một thông điệp đến gateway thông qua một node khác (sau đây gọi là node chuyển tiếp), thì node gửi sẽ hết trách nhiệm với thông điệp ngay khi node chuyển tiếp xác nhận đã nhận được bằng cách gửi lại thông điệp ACK_PACKET_TO_GW cho node gửi Cấu trúc payload của thông điệp ACK_PACKET_TO_GW như sau:

Bảng 1.10 Cấu trúc gói tin ACK_PACKET_TO_GW msgType ACK_PACKET_TO_GW startTimeSlot - startSendTime - percentToGW -

TimeToGW - slot [slot] data - seqNum [number]

ACK_PACKET_FAIL_TO_GW: Dùng để từ chối tiếp nhận thêm dữ liệu từ một node “khách hàng” khi tuyến đường đang sử dụng để chuyển tiếp dữ liệu lại không còn khả dụng nữa Thông tin về tuyến đường thay thế cũng sẽ được bao gồm trong gói tin này để node “khách hàng” có thể tính toán lại chất lượng tuyến đường đi qua node nó đang giao tiếp sau khi có sự thay đổi, từ đó quyết định có gửi tiếp hay không

Bảng 1.11 Cấu trúc gói tin ACK_PACKET_FAIL_TO_GW msgType ACK_PACKET_FAIL_TO_GW startTimeSlot - startSendTime - percentToGW [percent]

TimeToGW [time] slot - data - seqNum [number]

2 Mô phỏng và đo lường

Nội dung

Mô hình mạng mô phỏng

Hình 2.1 Mô hình mạng mô phỏng với 10 nodes và 1 gateway

Hình 2.2 Mô hình mạng mô phỏng với 20 nodes và 2 gateways

Trong Luận Văn này, hai mô hình mạng như trong các Hình 2.1 và Hình 2.2 sẽ được tiến hành mô phỏng và so sánh một số chỉ số khi áp dụng giải thuật định tuyến AQoSR được đề xuất bởi Luận Văn với khi áp dụng giao thức định tuyến HEAT nguyên bản [5] và khi áp dụng kỹ thuật flooding

Trong Hình 2.1, mạng có 10 nodes và 1 gateway Trong đó có một số nodes đặc biệt như là:

- Node 0 là điểm nóng trung chuyển dữ liệu về gateway Do đó, nó thường xuyên vào trạng thái quá tải, buộc lòng các nodes xung quanh nó (như các Node 3, Node 7, Node 9) phải chuyển luồng dữ liệu qua hướng khác

- Khi tình huống mạng thay đổi, một node trước đó là nhà cung cấp dịch vụ cho node khác, sau đó vẫn có thể quay lại trở thành “khách hàng” sử dụng dịch vụ vận chuyển cung cấp bởi “khách hàng cũ” Ví dụ như Node 7 và Node 0 trong Hình 2.1, có lúc Node 7 đóng vai trò là khách hàng còn Node

0 là nhà cung cấp dịch vụ vận chuyển cho Node 7 Lúc này, Node 7 sẽ gửi những gói tin nó có cho Node 0 để Node vận chuyển tiếp về gateway Nhưng khi Node 0 quá tải, Node 7 lại có thể tiếp nhận một số gói tin từ Node 0 và vận chuyển chúng đến gateway thông qua Node 2

Ta có thể quan sát số gói tin mà các nodes trong mạng đã gửi qua gửi lại trong suốt quá trình mô phỏng để xác định tính đúng đắn của hành vi của chúng

Ngoài ra, nhờ vào công cụ thống kê, ta cũng đánh giá được độ hiệu quả của mạng thông qua một số thông số như tỉ lệ gửi gói thành công đến gateway, thông năng, độ trễ, và năng lượng tiêu thụ của các nodes

Mô hình mạng có 20 nodes và 2 gateways như được mô tả Trong Hình 2.2 dùng để mô phỏng một trường hợp phức tạp hơn – sự xuất hiện của gateway thứ hai với số lượng nodes trong mạng cũng lớn hơn Đối với mô hình này, kết quả kỳ vọng là tải của mạng sẽ đổ về cả hai gateways ở hai bên Cách quan sát hành vi của mạng cũng tương tự như đối với mô hình mạng

10 nodes 1 gateway Bên cạnh đó, một số thông số cơ bản giúp đánh giá hiệu quả của giải thuật cũng sẽ được thống kê và nhận xét.

Cấu hình mạng mô phỏng

Hình 2.1 và Hình 2.2 đã thể hiện sơ đồ tổng quan vị trí của các nodes trong mô hình mạng được mô phỏng trong nghiên cứu này Các đường nối giữa các nodes thể hiện khả năng kết nối vật lý giữa chúng Các Bảng 2.1 và Bảng 2.2 dưới đây thể hiện khoảng cách các nodes trong các mô hình mạng nói trên

Bảng 2.1 Khoảng cách giữa các nodes trong mô hình mô phỏng mạng với 10 nodes và 1 gateway

Bảng 2.2 Khoảng cách giữa các nodes trong mô hình mạng mô phỏng với 20 nodes và 2 gateways

Trong nghiên cứu này, thư viện OMNeT++ FLoRa được sử dụng để mô phỏng lớp radio của LoRa Mặc dù thư viện chưa hỗ trợ mô phỏng đầy đủ các thuộc tính, nhưng cũng đã cho phép cấu hình một số thông số cơ bản nhất như Spread Factor (SF), Transmission Power (TP – công suất phát), Carrier Frequency (CF – tần số sóng mang), Bandwidth (BW – băng thông), và Code Redundancy (CR)

Các nodes và gateways trong các mô hình mạng mô phỏng trong nghiên cứu này có các thông số được cài đặt như trong đoạn mã dưới đây:

**.Gateway[*].**initialLoRaTP = 14dBm #transmission power

Mặc dù năng lượng phát sóng đã được cài đặt trong phần cấu hình radio (mục 2.1.2.2), nhưng để đo lường được năng lượng tiêu thụ của từng nodes trong mạng, cần đặc tả rõ hiệu điện thế cung cấp cho các nodes và cường độ dòng điện tiêu thụ của chúng tại các thời điểm khác nhau Trong Luận Văn này, các nodes sẽ được giả định sử dụng nguồn 3.3V, cường độ dòng điện tiêu thụ lúc nhận dữ liệu là 9.7 mA, cường độ dòng điện khi gửi là 44 mA (ứng với công suất phát 14 dbm), và cường độ dòng điện lúc nghỉ (sleep) là khoảng 0.0002 mA Đoạn mã dưới đây là đặc tả cấu hình năng lượng của node theo giả định trên theo cú pháp quy định bởi thư viện FLoRa:

Nội dung đo lường

Nhằm đánh giá độ hiệu quả của giải thuật đã đề xuất, các chỉ số cơ bản bao gồm tỉ lệ gửi gói thành công đến gateway, thông năng, độ trễ, và năng lượng tiêu thụ sẽ được đo lường Tuy nhiên các chỉ số này còn phụ thuộc vào nhiều yếu tố như số lượng node, vị trí tương đối giữa các nodes, … Do đó, chúng chỉ có giá trị đánh giá khi so sánh trên cùng một mô hình mạng giữa các kỹ thuật được áp dụng khác nhau Vì vậy các kết quả khi áp dụng giải thuật AQoSR đã đề xuất với kết quả khi áp dụng giao thức định tuyến HEAT nguyên bản [5], cũng như khi áp dụng kỹ thuật flooding cũng sẽ được so sánh để làm rõ các cải thiện và hạn chế Phần này giải thích ý nghĩa và phương pháp đo lường các thông số nói trên

2.1.3.1 Tỉ lệ gửi gói thành công đến gateway và thông năng của mạng

Với mỗi mô hình mạng đã đề cập trong tiểu mục 2.1.1, các mô phỏng sẽ được lặp đi lặp lại nhiều lần với những tần suất tạo và gửi gói khác nhau Các gói tin đến được gateway sẽ được ghi nhận lại và thống kê theo địa chỉ nguồn nơi chúng được tạo ra Từ đó đối chiếu với số lượng gói tin mà mỗi node đã tạo và gửi trong suốt quá trình mô phỏng, ta sẽ tính toán được tỉ lệ gửi gói tin thành công đến gateway của từng node với một số tần suất tạo và gửi gói khác nhau, giúp đánh giá được khả năng của mạng trên phương diện nỗ lực đưa được gói tin đến gateway

Mặc dù trong mô hình mạng này, mỗi node trong mạng đều có thể đóng vai trò là node chuyển tiếp dữ liệu cho node khác, nhưng chúng cũng là những nodes cảm biến Như vậy, mỗi node trong mạng vừa đóng vai trò là một phần của “nhà cung cấp” dịch vụ vận chuyển các thông điệp đến gateway, cũng vừa là một khách hàng Như vậy, ta cần xác định được thông năng mà mạng cung cấp cho một node; nói cách khác là số gói tin trên một đơn vị thời gian mà mạng có thể giúp mỗi node vận chuyển thành công đến gateway là bao nhiêu Để đo được thông năng, ta sẽ tăng dần tần suất tạo và gửi gói tin của các nodes cho đến khi tỉ lệ gửi thành công dữ liệu đến gateway có dấu hiệu sụt giảm đáng kể Khi đó, thông năng mà mạng cung cấp cho một node được ghi nhận bằng số gói tin cao nhất trên một đơn vị thời gian mà mạng vẫn còn đáp ứng được với tỉ lệ mất gói thấp

2.1.3.2 Độ trễ Độ trễ từ khi một gói tin được tạo ra tại node cảm biến cho đến khi nó được gửi thành công đến gateway là một thông số quan trọng để có thể đánh giá khả năng đáp ứng của mạng đối với các ứng dụng đòi hỏi tính chất thời gian thực

Trong nghiên cứu này, độ trễ khi gửi một gói tin được xác định là khoảng thời gian từ lúc gói tin được tạo ra cho đến khi nó thành công đến được gateway

2.1.3.3 Năng lượng tiêu thụ trên các nodes

Như đã phân tích, việc áp dụng giải thuật định tuyến vào giao tiếp nhiều hops 40 giúp giảm đụng độ, giảm số gói tin dư thừa, cho phép các nodes có thể vào chế độ ngủ khi không có tải, nhờ đó giảm năng lượng tiêu thụ trên những nodes nhẹ tải Nhằm làm rõ hơn mức độ tiết kiệm năng lượng khi sử dụng giải thuật được đề xuất so với khi sử dụng kỹ thuật flooding, tổng năng lượng tiêu thụ của từng

40 multihop communication node trong suốt thời gian từ lúc bắt đầu đến lúc kết thúc mô phỏng sẽ ghi nhận lại để thống kê, so sánh.

Phương pháp lấy kết quả, xử lý số liệu, và thực hiện thống kê

2.1.4.1 Đối với dữ liệu dùng để đo tỉ lệ gửi gói thành công đến gateway và thông năng của mạng

Các nodes và gateways trong mạng mô phỏng được lập trình để xuất dữ liệu ra cửa sổ text của OMNeT++ khi kết thúc mô phỏng với nội dung chính như sau (một số đoạn text dư thừa đã được lược bỏ):

3 The number of packets that I generated is 7839

Trong đó, mỗi nodes sẽ in ra:

1) Địa chỉ MAC của nó

2) Năng lượng mà nó đã tiêu thụ, tính bằng Joules

3) Số lượng gói tin nó đã tạo ta và gửi trong thời gian từ đầu đến cuối mô phỏng (thời lượng mô phỏng là 86400 giây, tương ứng với 1 ngày)

4) Bảng thông tin các nodes lân cận

Gateway cũng sẽ in ra địa chỉ MAC, năng lượng tiêu thụ, bảng thông tin các nodes lân cận tương tự như các nodes Và ngoài ra nó còn in thêm một bảng thống kê số lượng các gói tin nó đã nhận theo địa chỉ nguồn nơi mà gói tin đó được tạo ra

Nhờ vào những dữ liệu này, ta có thể xác định được những nodes nào có thiết lập giao tiếp với nhau, đã có những luồng dữ liệu giữa những nodes nào, số lượng gói tin mà mỗi node đã gửi thành công đến gateway là bao nhiêu,…

Ngoài ra, để có thể dễ dàng tổng hợp nhiều kết quả mô phỏng khác nhau, một đoạn chương trình Python đơn giản đã được viết để xử lý dữ liệu đầu ra dạng text như đã nêu trên: outputSet = "10n1gw" timeInterval = "10s" inFileName = outputSet + "/" + timeInterval + ".txt" inFile = open(inFileName, "r")

# should not be mentioned in the thesis report def main(): lines = readFile() nodes = getNodesList(lines) countGeneratedPackets(nodes, lines) gwDataLines = gwDataFilter(lines) lookupAndLog(nodes, gwDataLines) calculatePRR(nodes) for node in nodes: print(node) exportCSV(nodes) inFile.close() pass main()

Sau khi chạy xong mô phỏng, lấy đoạn text thu được từ phần mềm OMNeT++ chèn vào file 10n1gw/10s.txt rồi chạy đoạn mã Python nói trên, ta được kết quả như sau:

Hình 2.3 Kết quả xử lý dữ liệu đầu ra của chương trình mô phỏng

Mỗi lần đo đạc với một tần suất gửi dữ liệu khác nhau của các nodes, một bộ kết quả như được mô tả trong Hình 2.3 sẽ được lưu để so sánh

2.1.4.2 Đối với dữ liệu dùng để xác định độ trễ khi gửi gói Để đo được độ trễ của từng gói tin kể từ khi chúng được tạo ra cho đến khi chúng đến được gateway, mỗi gói tin sẽ được gắn kèm một nhãn thời gian ghi lại thời điểm nó được tạo ra Khi gói tin đến được gateway, gateway sẽ dựa vào nhãn thời gian này để xác định độ trễ của gói tin tương ứng Sở dĩ có thể làm được như vậy là nhờ gateway và tất cả các nodes trong OMNeT++ đều có thể tham chiếu đến cùng một trục thời gian Điều này tuy phi thực tế nhưng trong môi trường mô phỏng thì lại là một điểm lợi có thể khai thác nhằm đơn giản hóa việc thống kê

Dữ liệu độ trễ của từng gói tin khi đến được gateway là đủ nhiều để khiến việc in chúng ra màn hình để đọc trở nên cực kì bất tiện Do đó, một chức năng của OMNeT++ đã được sử dụng để ghi lại những dữ liệu này rồi xuất ra dạng các vectors

Hình 2.4 dưới đây thể hiện các vector độ trễ của các gói tin chia theo số hop mà nó đã đi qua

Hình 2.4 Các vectors lưu thông tin độ trễ của các gói tin khi đến được gateway, phân loại theo số hop chúng đã đi qua

Sau khi trích xuất các vectors trên ra tệp tin, ta có dữ liệu thô chứa thông tin chi tiết độ trễ của từng gói tin như trong Hình 2.5 sau:

Hình 2.5 Dữ liệu thô độ trễ của từng gói tin đến được gateway sau khi trích xuất từ các vectors của OMNeT++

Kế đến, một đoạn chương trình python được sử dụng để duyệt qua nội dung tệp, trích xuất, tổng hợp những thông tin có ý nghĩa đánh giá như:

- Độ trễ trung bình đến gateway của các gói tin

- Độ trễ trung bình qua một hop

- Phân bổ số gói tin theo số hop

Mô phỏng được thực hiện đi thực hiện lại nhiều lần để đo được các thông tin trên ứng với nhiều tần suất tạo và gửi gói khác nhau Mỗi lần chạy mô phỏng ở một tần suất tạo và gửi gói nào đó, ta lại có được những dữ liệu như được mô tả trong Hình 2.6 dưới đây

(a) Độ trễ trung bình đến gateway và độ trễ trung bình qua một hop khi các nodes tạo và gửi gói mỗi 10 giây một lần

(b) Bảng phân bổ số gói tin theo số hop mà chúng đã đi qua để đến gateway

Hình 2.6 Dữ liệu có được sau mỗi lần mô phỏng với một tần suất tạo và gửi gói nhất định

Cuối cùng, dữ liệu của nhiều lần chạy mô phỏng sẽ được gom lại và thể hiện ở dạng bảng và biểu đồ như trong các phần 2.2.1 và 2.2.2 để tiện quan sát, nhận xét, đánh giá

2.1.4.3 Đối với năng lượng tiêu thụ của mạng

Tương tự như tỉ lệ gửi gói thành công đến gateway, năng lượng tiêu thụ trên từng nodes tính từ lúc bắt đầu đến khi kết thúc mô phỏng cũng được in ra màn hình và dễ dàng được tổng hợp lại bằng một đoạn chương trình python đơn giản def recogConsumedPW(nodes, lines): for line in lines: if " 2 Total energy comsumed: " in line and "Node" in line: # code to remove redundant text (not presented here) nodeName = line.split(":")[0] energy = float(line.split(":")[1]) for node in nodes: if node.name == nodeName: node.energyConsumed = energy

Dữ liệu về năng lượng tiêu thụ trên từng nodes trong một lần mô phỏng được tổng hợp thành dạng bảng như trong Hình 2.7 sau:

Hình 2.7 Năng lượng tiêu thụ của các nodes trong một lần chạy mô phỏng

Những dữ liệu thu được từ nhiều lần mô phỏng khác nhau sau đó lại được tiếp tục tổng hợp để vẽ đồ thị.

Kết quả đo lường

Kết quả đo lường với mạng 10 nodes, 1 gateway

Như đã đề cập, trong mô hình mạng này, Node 0 là một điểm nóng trung chuyển dữ liệu (hình vẽ không có tiêu đề sau đây thể hiện lại Hình 2.1 cho tiện đối chiếu, phân tích)

Khi tần suất tạo và gửi gói tin của các nodes trong mạng thấp, Node 0 sẽ không bị quá tải và nó chỉ đơn giản nhận dữ liệu từ các nodes lân cận rồi chuyển thẳng cho gateway

0A-AA-00-00-0B: Gateway 0A-AA-00-00-08: Node 7 0A-AA-00-00-0B: Node 3 0A-AA-00-00-0A: Node 9

Hình 2.8 Bảng dữ liệu mạng của Node 0 khi tần suất tạo và gửi gói tin của các nodes trong mạng là 1 gói mỗi 15 giây khi áp dụng giao thức định tuyến AQoSR

Trong Hình 2.8, ta thấy Node 0 không gửi bất cứ gói tin nào cho các Node 3, 7, và 9 mà chỉ nhận dữ liệu từ những nodes này và chuyển thẳng cho gateway

Bảng dữ liệu mạng trên cũng thể hiện rằng ngoài cách gửi thẳng cho gateway, Node 0 còn có thể gửi dữ liệu thông qua Node 7 với tỉ lệ thành công lên đến 100% Điều này là hoàn toàn hợp lý vì Node 7 có kết nối trực tiếp với Node 2, mà Node

2 lại có thể giao tiếp trực tiếp với Gateway Mặc dù vậy, trong điều kiện bình thường, Node 0 vẫn sẽ ưu tiên đường thẳng để gửi thay vì đường vòng

Tuy nhiên, trong một mô phỏng khác, khi tần suất tạo và gửi gói của các nodes trong mạng được điều chỉnh lên tới 1 gói mỗi 10 giây, thì bảng dữ liệu mạng của Node 0 như được thể hiện trong Hình 2.9

0A-AA-00-00-0B: Gateway 0A-AA-00-00-08: Node 7 0A-AA-00-00-04: Node 3 0A-AA-00-00-0A: Node 9

Hình 2.9 Bảng dữ liệu mạng của Node 0 khi tần suất tạo và gửi gói tin của các nodes trong mạng là 1 gói mỗi 10 giây khi áp dụng giao thức định tuyến AQoSR

Lúc này, ta thấy rõ là trong quá trình mô phỏng đã có những thời điểm mà khung thời gian giao tiếp giữa Node 0 và Gateway là không đủ để Node 0 kịp chuyển toàn bộ dữ liệu nó có trực tiếp cho Gateway Do đó nó phải dồn những dữ liệu còn lại qua đường khác nên ta thấy có sự thay đổi luồng dữ liệu Tuy chưa thể kiểm chứng được tất cả các trường hợp, nhưng những trường hợp phổ biến đã cho thấy các nodes mạng hoạt động đúng theo thuật toán đã mô tả Các thông số chi tiết hơn sẽ được trình bày trong các tiểu mục tiếp theo

2.2.1.2 Tỉ lệ gửi gói thành công đến gateway và thông năng

Nhằm làm rõ sự ảnh hưởng của tần suất tạo và gửi gói đến tỉ lệ gửi gói thành công đến gateway, 27 mô phỏng đã được thực hiện với 27 tần suất khác nhau Kết quả được thể hiện trong biểu đồ Hình 2.10 và Bảng 2.3

Hình 2.10 Tỉ lệ gửi gói thành công đến gateway của các nodes trong mạng 10 nodes 1 gateway với những tần suất gửi khác nhau khi áp dụng giao thức định tuyến AQoSR

Tỉ lệ gửi gói thành công đến gateway của các nodes trong mô hình mạng này duy trì gần như tuyệt đối đối với tần suất tạo và gửi gói từ 1 gói/900 giây đến khoảng

1 gói/8 giây Nếu tần suất tạo và gửi gói của các nodes trong mạng cao hơn 1 gói/8 giây, tỉ lệ gửi gói thành công đến gateway của các nodes bắt đầu bị giảm mạnh Như vậy, có thể nói, mạng cho phép các nodes gửi dữ liệu lên gateway với tần suất tối đa là 1 gói tin/8 giây.

Bảng 2.3 Tỉ lệ (phần trăm) gửi dữ liệu thành công về gateway của các nodes trong mạng 10 nodes 1 gateway với một số khoảng cách giữa hai lần gửi liên tiếp khác nhau (giây) khi áp dụng giao thức định tuyến AQoSR

2.2.1.3 Độ trễ Độ trễ trung bình đến gateway của các gói tin và độ trễ trung bình qua một hop được thể hiện trong các Hình 2.11 và Bảng 2.4 sau:

Hình 2.11 Độ trễ trung bình đến gateway và độ trễ trung bình qua một hop của các nodes trong mạng 10 nodes 1 gateway với những tần suất tạo và gửi gói khác nhau khi áp dụng giao thức định tuyến AQoSR

Kết quả đo lường với mạng 20 nodes, 2 gateways

Bảng 2.6 và Bảng 2.7 dưới đây thể hiện kết quả thống kê các gói tin từ các nodes đã đến được một trong hai gateways

Bảng 2.6 Thống kê số gói tin nhận được tại Gateway[0] trong mạng 20 nodes 2 gateways từ đầu đến cuối mô phỏng

Bảng 2.7 Thống kê số gói tin nhận được tại Gateway[1] trong mạng 20 nodes 2 gateways từ đầu đến cuối mô phỏng

Hình vẽ không có tiêu đề dưới đây tái hiện tại Hình 2.2 để tiện đối chiếu:

Có thể thấy, các nodes ở gần gateway nào hơn thì sẽ có luồng dữ liệu đi về phía gateway đó lớn hơn Một số node ở khu vực trung tâm có luồng dữ liệu khá linh hoạt, như Node 8 (0A-AA-00-00-00-09), có luồng dữ liệu đi về hai phía khá đồng đều Như vậy mạng đã hoạt động theo đúng như thiết kế

2.2.2.2 Tỉ lệ gửi gói thành công đến gateway

Hình 2.20 Tỉ lệ gửi gói thành công đến gateway của các nodes trong mạng 20 nodes 2 gateways với những tần suất gửi khác nhau khi áp dụng giao thức định tuyến AQoSR

Hình 2.21 Độ trễ trung bình đến gateway và độ trễ trung bình qua mỗi hop của các nodes trong mạng 20 nodes 2 gateways với những tần suất gửi khác nhau khi áp dụng giao thức định tuyến AQoSR

Hình 2.22 Năng lượng tiêu thụ của từng nodes trong mạng 20 nodes 2 gateways với nhiều tần suất tạo và gửi gói khác nhau khi áp dụng giao thức định tuyến AQoSR

3 Kết luận Định tuyến trong mạng cảm biến không dây không phải là một vấn đề mới mà từ lâu, nhiều kỹ sư, nhà khoa học đã quan tâm nghiên cứu Tuy nhiên, sự phát triển nhanh chóng và không ngừng của đời sống xã hội đã xúc tiến quá trình phát sinh thêm nhiều nhu cầu mới Cách tiếp cận của Luận Văn này là vận dụng, cải tiến cái cũ để giải quyết vấn đề mới, đáp ứng nhu cầu mới và đã tìm thấy một bối cảnh mà ở đó việc tìm hiểu, cải tiến, và vận dụng giải thuật định tuyến HEAT vào mở rộng khu vực biên LoRaWAN có thể đem lại lợi ích

Với cách tiếp cận đó, Luận Văn đã đưa ra khái niệm “định tuyến dựa trên chất lượng dịch vụ node lân cận” phát triển từ một phần ý tưởng ban đầu của giải thuật định tuyến HEAT Sau đó, giải thuật “định tuyến dựa trên chất lượng dịch vụ node lân cận”, qua quá trình nhiều bước thiết kế, đã được định nghĩa đầy đủ Mô hình mạng mô phỏng cũng đã cho thấy những dấu hiệu khả quan về tiềm năng ứng dụng thực tế của giải thuật được đề xuất Những chỉ số về tỉ lệ nhận gói thành công, độ trễ, và năng lượng tiêu thụ đã chỉ ra rằng giải thuật đã đề xuất là phù hợp để triển khai các ứng dụng quan trắc trên diện rộng, năng lượng thấp, không yêu cầu tính thời gian thực nghiêm ngặt Giải pháp đề xuất bởi Luận Văn này sẽ đặc biệt phát huy tác dụng khi có một số điểm quan trắc quan trọng nhưng lại không thể bố trí được gateway phủ sóng trực tiếp Ngoài ra, giải thuật định tuyến này còn hứa hẹn mang lại một giải pháp dễ tiếp cận để triển khai một mạng mesh, không đòi hỏi người dùng phải có kiến thức chuyên sâu về mạng máy tính Do đó, trong tương lai gần, giải thuật này sẽ được tiếp tục thử nghiệm và hoàn thiện Ý tưởng sơ bộ của đề tài cũng đã được ghi nhận và trình bày tại hội nghị “2022

6th International Conference on Information Technology, Information Systems and Electrical Engineering (ICITISEE)” (chi tiết tại: Danh mục công trình khoa học)

Một vài hướng phát triển tiếp theo đối với đề tài này như sau:

- Hoàn thiện cơ chế đa truy cập để giảm đụng độ hơn nữa

- Đưa vào thử nghiệm trên thực tế thay vì môi trường mô phỏng

- Tích hợp vào một hệ thống LoRaWAN

- Phát triển một board mạch “cắm và chạy” chuyên dùng để triển khai các nodes quan trắc có yêu cầu về mạng phù hợp

DANH MỤC CÔNG TRÌNH KHOA HỌC

1 H.-K Huynh and H.-A Pham, "HEAT Routing Algorithm for Multi-hop Communication in IoT-enabled LoRa-based Wireless Mesh Networks," in

2022 6th International Conference on Information Technology, Information Systems and Electrical Engineering (ICITISEE), Yogyakarta,

HEAT Routing Algorithm for Multi-hop Communication in IoT-enabled LoRa-based

Ho Chi Minh City University of Technology (HCMUT)

Vietnam National University Ho Chi Minh City (VNU-HCM)

Ho Chi Minh City, Vietnam khahuynh@hcmut.edu.vn

Ho Chi Minh City University of Technology (HCMUT) Vietnam National University Ho Chi Minh City (VNU-HCM)

Ho Chi Minh City, Vietnam Corresponding author: anhpham@hcmut.edu.vn

Abstract—There may be many routing algorithms that could be employed in a wireless mesh network Each algorithm has its own advantages and disadvantages While proactive routing algorithms can quickly provide up-to-date routing information which helps reduce the routing latency, reactive routing algorithms help reduce routing overhead but instead increase the routing time.

On the other hand, some routing algorithms try to provide end- to-end communications despite the high routing overhead and low scalability but some others are designed for the ease of scaling up without providing end-to-end communications This paper presents a revised HEAT routing algorithm for multi-hop communication in LoRa-based wireless mesh networks expected to provide higher scalability for IoT-based applications Both software and hardware are also implemented for performance investigation.

Index Terms—HEAT Algorithm, Routing Algorithm, Multi- hop Communication, Wireless Mesh Networks, LoRa

It has been estimated that there will be around 75 billion

Internet of Things connected devices on over the world by

2025 [1] According to that enormous number, the need for low-power wide-area (LPWA) connections between ”things” are rapidly increasing Many LPWA technologies have been developed, but each has its own dominant advantages The

LoRa (short for long-range) is one of the leading LPWA technologies It provides long-range and low-power consumption, a low data rate, and secure data transmission.

In LoRaWAN, end-devices can easily communicate with a logic server via a standard IP connection after a single-hop communication with the gateway However, if end-devices are set scattered, and there is an insufficient number of gateways, the network’s capability could reduce A mesh network with multi-hop communication [2] could be considerable and suit- able for this scenario.

In mesh networks, routing is essential in forwarding data packets from the source to the destination node Basically, there are two types of wireless mesh routing protocols: proactive routing and reactive routing In proactive routing protocols, paths are established to all the destination nodes regardless of whether or not the routes are required to transmit data These so-called table-driven methods maintain consistent and up-to-date routing information by continuously evaluating routes to all reachable nodes Thus, the primary benefit of proactive protocols is that nodes can quickly obtain route information and establish a path Destination-Sequenced Distance- Vector Routing (DSDV) [3], Cluster Head Gateway Switch Routing (CGSR) [4], Optimized Link State Routing (OLSR) [5] and Scalable Routing using HEAT [6] are well-known proactive protocols.

Routes are established on demand in reactive routing protocols, referred to as on-demand methods When a source node needs a path to a destination node, the route discovery process begins and continues until a route is found or no route is available after reviewing all route possibilities Active routes in mobile networks may be disconnected owing to node movement However, reactive routing algorithms scale better than proactive routing protocols because node mobility is low in wireless mesh networks Dynamic Source Routing (DSR), Ad-hoc On-Demand Distance Vector (AODV), Link Quality Source Routing Algorithm (LQSR), and Temporally Ordered Routing Algorithm (TORA) are some well-known reactive routing protocols [7].

Proactive and reactive routing protocols both have their drawbacks, but combining them allows hybrid routing methods to discover the most effective routes with minimal manage- ment overhead For example, in the ad-hoc network area, these protocols use reactive routing protocols, while the wireless backbone uses proactive protocols.

In this study, we choose to implement a proactive anycast routing algorithm named HEAT because this routing algorithm is the best fit with our proposed network model.

• Firstly, the proposed network does not tend to provide end-to-end communications Traffics in this network are mostly upstream from sensor nodes to internet gateways. This property of this network is the same to which is suggested by HEAT.

• Secondly, the HEAT routing algorithm is a fully dis- tributed one This characteristic leads to the high scalability of the network.

2022 6th International Conference on Information Technology, Information Systems and Electrical Engineering (ICITISEE)

• Thirdly, the HEAT routing algorithm is field-based It uses only information of direct neighbors for routing.

This allows using low-cost hardware for nodes, fits with the desire of providing a cheap and easy to deploy networking solution for IoT.

Fig 1 shows a mesh of clusters of sensor nodes Each cluster has a cluster head node called a mesh node that represents other nodes to communicate on the mesh network by forwarding packets of sensor nodes to the internet gateway based on a routing mechanism Sensor nodes can freely and actively choose a mesh node to register as a cluster member.

Tiêu đề	Thử nghiệm mô hình mạng LoRaWAN với giao thức định tuyến HEAT
Tác giả	Huỳnh Hoàng Kha
Người hướng dẫn	TS. Phạm Hoàng Anh
Trường học	Đại học Quốc gia TP. HCM
Chuyên ngành	Khoa học máy tính
Thể loại	Luận văn thạc sĩ
Năm xuất bản	2023
Thành phố	Tp. Hồ Chí Minh

Định dạng
Số trang	132
Dung lượng	8,67 MB