Hệ điều hành Contiki

Một phần của tài liệu (LUẬN văn THẠC sĩ) nghiên cứu đánh giá giao thức thu thập dữ liệu cho mạng lưới đồng hồ nước thông minh (Trang 56)

3.1.1. Giới thiệu chung

Contiki [10] là một hệ điều hành mã nguồn mở được thiết kế cho các hệ thống mạng nhúng nói chung và mạng lưới các thiết bị đo nói riêng. Hệ điều hành Contiki được phát triển bởi Adam Dunkels và phiên bản đầu tiên được phát hành vào năm 2003. Nhóm phát triển Contiki gồm nhiều thành viên đến từ SICS, CISCO, cùng nhiều tổ chức và các trường đại học khác trên thế giới. Hệ điều hành Contiki được thiết kế cho các vi điều khiển có bộ nhớ nhỏ, với thông số 2KB RAM và 40KB ROM. Nhờ đó, Contiki có thể được sử dụng cho các hệ thống nhúng. Trong thực tế, Contiki đã được ứng dụng trong nhiều dự án như giám sát đường hầm xe lửa, theo dõi nước trong biển Baltic…

Hệ điều hành Contiki cùng đi kèm với công cụ mô phỏng Cooja/MSPSim. Công cụ mô phỏng này cho phép các đoạn mã chương trình viết trên nền hệ điều hành Contiki có thể được mô phỏng, thử nghiệm trước khi triển khai.

3.1.2. Ngăn xếp truyền thông trong hệ điều hành Contiki

Contiki cung cấp các ứng dụng trên nền IP gồm cả IPv4 và IPv6 thông qua 2 ngăn xếp truyền thông: uIP và Rime. Các ứng dụng có thể hoạt động trên một trong hai giao thức uIP hoặc Rime, hoặc đồng thời trên cả hai giao thức. Bên cạnh đó, các ứng dụng uIP có thể hoạt động dựa trên Rime và ngược lại, các ứng dụng trên nền Rime cũng có thể hoạt động dựa trên nền uIP. Sơ đồ hoạt động của các ứng dụng trong Contiki được chỉ ra trong hình 3.2.

Hình 3.2: Sơ đồ hoạt động các ứng dụng trong Contiki.

3.1.2.1. Ngăn xếp truyền thông uIP

Ngày nay, cùng với sự thành công của Internet, giao thức TCP/IP đã trở thành tiêu chuẩn toàn cầu trong truyền thông. TCP/IP là giao thức cơ bản được sử dụng cho các ứng dụng truyền tải các trang Web, gửi - nhận email, gửi file và những mạng Peer - to - Peer thông qua mạng Internet. Đối với các hệ thống nhúng, nếu sử dụng được TCP/IP sẽ có khả năng kết nối hệ thống trực tiếp đến một mạng nội bộ, hoặc thậm chí là một mạng toàn cầu. Những thiết bị nhúng có khả năng đáp ứng được đầy đủ những đặc tính của TCP/IP sẽ là những thiết bị có tính ưu việt, có khả năng giao tiếp một cách đầy đủ với tất cả các thiết bị khác trong mạng. Tuy nhiên, sự triển khai giao thức TCP/IP truyền thống đòi hỏi quá nhiều tài nguyên gồm cả dung lượng mã và bộ nhớ sử dụng, không thể được đáp ứng trong các hệ thống nhúng 8 hoặc 16 bit.

Hình 3.3: Ngăn xếp truyền thông uIP.

Xuất phát từ ý tưởng đó, ngăn xếp truyền thông uIP (hình 3.3) được thiết kế với mục tiêu tối ưu hóa các đặc tính cần thiết cho một ngân xếp TCP/IP đầy đủ. uIP chỉ có thể hoạt động với một giao diện mạng duy nhất và bao gồm các giao thức: IP, ICMP, UDP, TCP. uIP được lập trình bằng ngôn ngữ C bởi Adam Dunkels – một thành viên trong tổ chức nghiên cứu và phát triển Contiki.

3.1.2.2. Ngăn xếp truyền thông Rime

Ngăn xếp truyền thông RIME là một cấu trúc phân tầng giao thức trong mạng truyền thông không dây, từ việc phát quảng bá đơn giản cho tới các giao thức định tuyến phức tạp hơn trong mạng. Ngăn xếp truyền thông RIME thực thi các giao thức phức tạp với nhiều thành phần, mỗi phần lại gồm nhiều mô đun được tạo nên từ những mô đun nhỏ lẻ đơn giản hơn. Dưới đây là toàn thể tổ chức của ngăn xếp truyền thông RIME.

Hình 3.4: Tổ chức của RIME. Đặc điểm của ngăn xếp truyền thông RIME:

 Phân chia thành nhiều mô đun khá đơn giản với kích thước nhỏ.

 Xây dựng nhiều mô đun giao tiếp đơn giản: - Broadcast, unicast single hop.

- Định tuyến multihop: mesh, collect.

 Các chức năng phức tạp được thực hiện qua các phân lớp đơn giản.

 Sử dụng các hàm callback để thực hiện các hàm xử lý khi nhận được gói tin, bộ định thời hết hạn, kết nối lỗi,…

 Kết nối phải được khởi tạo trước khi sử dụng.

 Sử dụng một bộ đệm gói cho tất cả các gói đến và gửi đi (hình 3.5). Khi gửi gói, các ứng dụng lưu gói vào bộ nhớ đệm và gọi các hàm xử lý liên quan để gửi gói đi. Khi nhận được một gói, gói nhận được được lưu trong bộ đệm gói, đồng thời ngăn xếp RIME gọi các hàm callback tương ứng để xử lý gói đầu vào.

Hình 3.5: Bộ đệm và Thao tác gói trong RIME.

3.2. Thực thi giao thức CTP trên hệ điều hành Contiki

3.2.1. Các module truyền thông được sử dụng trong giao thức CTP

Giao thức cây thu thập dữ liệu CTP được xây dựng trên ngăn xếp truyền thông RIME trong hệ điều hành Contiki như được minh họa ở hình 3.6.

Các thành phần chính của ngăn xếp truyền thông RIME được sử dụng trong giao thức CTP bao gồm:

Mô đun runicast (Reliable unicast): Là mô đun truyền thông unicast tin cậy giữa 2 nút. Runicast sử dụng việc truyền lại và các bản tin xác nhận ACK để đảm bảo rằng nút lân cận nhận được bản tin thành công. Khi phía thu có một gói tin được xác nhận thì mô đun runicast thông báo đến ứng dụng gửi thông gọi hàm callback. Mô đun runicast sử dụng mô đun stubborn single-hop unicast để thực hiện việc truyền lại. Do vậy mô đun runicast không phải quản lý chi tiết việc thiết lập các bộ định thời và thực hiện việc truyền lại nhưng có thể tập trung giải quyết vấn đề xác nhận gói tin.

Mô đun runicast thêm vào gói tin hai thuộc tính là: Kiểu gói tin single-hop và nhận dạng (ID) gói tin single-hop. Mô đun runicast sử dụng thuộc tính packet ID như là số thứ tự để xác nhận gói tin tương ứng với gói dữ liệu.

Ứng dụng hoặc giao thức sử dụng mô đun runicast có thể xác định cụ thể số lần truyền tối đa mà mô đun runicast nên thử trước khi thông báo gói tin bị hết hạn (timeout). Nếu một gói tin timeout thì ứng dụng hoặc giao thức gửi gói tin đó sẽ được thông báo bằng một hàm callback.

Hình 3.6: Giao thức CTP được xây dựng trên ngăn xếp truyền thông RIME trong Contiki.

Mô đun stunicast (stubborn unicast): Mô đun stunicast gửi lặp lại các bản tin đến một nút lân cận sử dụng mô đun unicast. Mô đun stunicast gửi và gửi lại các gói tin cho đến khi lớp trên hoặc giao thức lớp trên dừng việc truyền dẫn.

Trước khi mô đun stunicast gửi một gói tin thì nó khởi tạo một bộ đệm hàng đợi mà các thuộc tính gói tin và dữ liệu lớp ứng dụng được sao chép lại và thiết lập bộ định thời. Khi bộ định thời hết hạn thì mô đun stunicast sao chép bộ đệm hàng đợi vào bộ đệm ngăn xếp truyền thông RIME rồi gửi gói tin đi sử dụng mô đun unicast. Mô đun stunicast thiết lập số lần truyền lại cho gói tin như là một thuộc tính của các gói tin gửi đi.

Mô đun Unicast: Mô đun unicast gửi một gói tin đơn chặng đến một nút lân cận cho trước. Mô đun unicast sử dụng mô đun broadcast và thêm vào thuộc tính địa chỉ của nút nhận cho các gói tin gửi đi. Với các gói tin đến, mô đun unicast kiểm tra thuộc tính địa chỉ nút nhận và loại bỏ gói tin nếu địa chỉ đó không khớp với địa chỉ của nó.

Mô đun Broadcast: Mô đun này gửi các gói tin đến tất cả các nút lân cận trong phạm vi phủ sóng. Mô đun này thêm địa chỉ nút gửi như là một thuộc tính của các gói tin gửi đi. Tất cả các mô đun trong RIME cần xác định nút gửi trong các gói tin gửi đi sử dụng mô đun broadcast hoặc trực tiếp hoặc gián tiếp thông qua bất kỳ một mô đun truyền thông nào khác dựa trên mô đun broadcast.

Mô đun Anonymous broadcast (abc): Mô đun này gửi các gói tin đến tất cả các nút lân cận. Mô đun abc thêm tiêu đề cho các gói tin được gửi đi.

3.2.2. Các thành phần trong giao thức CTP

Giao thức này bao gồm một số thành phần mức cao sau [11]:

Thành phần định tuyến (tạo cây): Các nút tự tổ chức thành một cấu trúc dạng cây và dữ liệu luôn được gửi về nút Parent cho đến khi đến được đỉnh của cây (nút Sink). Nút Sink được gán là đỉnh của cây và tất cả các nút khác được khởi tạo là các nút lá. Dần dần các nút sẽ cập nhật vị trí của nó trong cây và quá trình này được lan truyền rộng từ nút Sink.

Quản lý và khám phá các nút lân cận: Các nút lân cận thông báo sự hiện diện của chúng thông qua việc gửi định kỳ các bản tin điều khiển. Các bản tin điều khiển được sử dụng để điền các thông tin của các nút lân cận vào bảng định tuyến.

Ước lượng liên kết: Dựa trên sự xác nhận ở lớp liên kết cho các bản tin dữ liệu được gửi bởi mỗi nút thì giá trị ETX của mỗi nút trong bảng định tuyến sẽ được cập nhật mỗi khi có sự xác nhận hoặc hết hạn đối với mỗi bản tin dữ liệu.

Bộ lọc các bản tin bị trùng lặp và gói tin hết thời hạn truyền trong mạng: Các gói tin được chuyển tiếp bởi các nút cho đến khi đến được nút Sink. Để tránh việc trùng lặp gói tin xảy ra thì mỗi nút sẽ kiểm tra lại gói tin cần được chuyển tiếp với các gói tin mới được chuyển tiếp gần nhất. Nếu gói tin đã được chuyển tiếp thì nó sẽ được loại bỏ. Hơn nữa, để tránh việc các gói tin được chuyển tiếp mãi trong mạng thì các gói tin sẽ được loại bỏ nếu nó vượt quá số bước nhảy tối đa cho trước.

3.2.3. Hoạt động của giao thức CTP

Giao thức thu thập Contiki thực thi cơ chế thu thập dữ liệu tin cậy từng bước nhảy (hop-by-hop). Dữ liệu được gửi qua một cấu trúc cây đến nút Sink.

Hình 3.7 minh họa quá trình xử lý một số sự kiện: Sự kiện nhận bản tin dữ liệu, sự kiện nhận bản tin ACK hoặc timeout, sự kiện Timer 1 kết thúc, Timer 2 kết thúc và sự kiện gửi một bản tin từ lớp ứng dụng sử dụng giao thức Collect.

3.2.2.1. Khởi tạo

Khi giao thức thu thập được khởi tạo thì kết nối runicast được thiết lập, giá trị rtmetric của tất cả các nút được khởi tạo và việc khám phá các nút lân cận được bắt đầu (bởi việc đăng ký với mô đun phát bản tin điều khiển) trên một kênh riêng biệt. Một nút trong mạng được gán làm nút Sink bằng việc gọi hàm collect_set_sink

trên nút đó.

3.2.2.2. Gửi các bản tin

Thuật toán gửi bản tin dữ liệu hoạt động như sau (hình 3.7):

 Đầu tiên tất cả các thuộc tính của giao thức thu thập được thiết lập.

 Sau đó mỗi nút gửi bản tin dữ liệu đến nút cha sử dụng reliable unicast. Lớp reliable unicast sẽ gửi một bản tin dữ liệu đến nút lân cận, tức là nó sẽ cố gắng chuyển phát một bản tin đến nút lân cận thông qua việc cố gắng truyền lại một số lần lớn nhất có thể cho đến khi nhận được bản tin xác nhận ACK. Nếu thành công, nó sẽ thông báo cho lớp trên (trong trường hợp này là giao thức thu thập). Nếu không thành công (tức là gói tin không nhận được ACK sau một số lần truyền) tức là bản tin dữ liệu bị quá hạn và sự quá hạn này được thông báo cho lớp trên.

Nút cha được xác định để chuyển tiếp bản tin dữ liệu là nút lân cận tốt nhất trong bảng định tuyến. Nếu không tìm được nút lân cận nào tốt nhất (tức là bảng định tuyến rỗng) thì gói tin được loại bỏ và nút đó sẽ chủ động lắng nghe các bản tin điều khiển để phát hiện các nút lân cận tiềm năng.

Chức năng gửi sẽ không được thực hiện nếu nút đó là nút Sink và khi đó chức năng nhận của ứng dụng sử dụng giao thức Collect sẽ được gọi đến.

 Khi bản tin dữ liệu gửi đi nhận được bản tin xác nhận ACK bởi nút cha thì giá trị rtmetric của nút nhận và ETX của nút cha sẽ được cập nhật.

3.2.2.3. Nhận các bản tin

Có hai loại bản tin có thể nhận được đó là: Các bản tin dữ liệu và các bản tin điều khiển.

Khi một nút nhận được một bản tin dữ liệu (hình 3.7) thì:

 Đầu tiên thực hiện lọc bản tin trùng lặp: Bản tin được kiểm tra lại với các bản tin vừa mới được chuyển tiếp. Nếu ID (thuộc tính EPACKET_ID) và địa chỉ nút khởi nguồn (thuộc tính ESENDER) giống nhau thì bản tin sẽ bị loại bỏ. Nếu bản tin không bị trùng lặp thì ID và địa chỉ nút khởi nguồn sẽ được lưu vào trong bảng các bản tin mới được chuyển tiếp gần đây.

 Nếu nút nhận được bản tin là nút Sink thì ứng dụng sử dụng giao thức thu thập được thông báo về sự tiếp nhận một bản tin. Địa chỉ khởi nguồn, ID của bản tin và số bước nhảy đã qua của bản tin được cung cấp như các tham số. Nếu nút nhận bản tin không phải là nút Sink thì bản tin sẽ được chuyển tiếp. - Nếu trường TTL nhỏ hơn hoặc bằng 1 thì bản tin bị loại bỏ.

- Trường HOP count được tăng lên một và trường TTL giảm đi một.

- Bản tin được chuyển tiếp đến nút cha của nó sử dụng kiểu truyền thông reliable unicast. Việc lựa chọn nút cha giống như phần gửi các bản tin đã được mô tả ở trên.

Các bản tin điều khiển:

Khi một nút nhận được một bản tin điều khiển (hình 3.8) thì:

 Nút lân cận gửi bản tin điều khiển được kiểm tra lại trong bảng định tuyến. Nếu nút lân cận này chưa có trong bảng định tuyến thì nó sẽ được thêm vào bảng định tuyến. Nếu nút này đã có trong bảng định tuyến thì giá trị rtmetric của nó sẽ được cập nhật trong bảng định tuyến. Nếu bảng định tuyến đầy thì nút lân cận kém nhất trong bảng định tuyến bị loại bỏ và thay thế vào đó là một nút lân cận mới. Nút lân cận kém nhất được xác định là nút có thước đo định tuyến (rtmetric) đến sink là lớn nhất và lớn hơn rtmetric của nút mới thêm vào.

 Nút nhận được gói tin thông báo sẽ cập nhật giá trị rtmetric của nó.

3.3. Thực thi giao thức RPL trên hệ điều hành Contiki

3.3.1. Cấu trúc các thành phần trong ContikiRPL

Hình 3.9 minh họa mô hình cấu trúc thực thi giao thức RPL trên hệ điều hành Contiki.

Lớp ứng dụng

Lớp giao vận (TCP/UDP)

Ngăn xếp truyền thông uIPv6

Lớp MAC, PHY theo chuẩn IEEE

802.15.4

ContikiRPL

ICMPv6 (DIO, DIS, DAO)

Tìm kiếm các nút lân cận

Thiết lập tuyến đường

Các gói tin dữ liệu và điều khiển

Khối ước lượng chất lượng liên kết

Thông tin phản hồi về chất lượng liên kết

ETX

Hình 3.9: Thực thi giao thức RPL trên hệ điều hành Contiki [12].

Ngăn xếp truyền thông uIPv6 gọi đến module ContikiRPL khi nhận được bản tin ICMPv6 (DIO, DIS, DAO) hoặc khi cần tìm kiếm các nút lân cận. Module ContikiRPL gọi đến ngăn xếp truyền thông uIPv6 để thiết lập tuyến đường trong các bảng định tuyến. Module ContikiRPL sử dụng thước đo định tuyến chất lượng

liên kết ETX (Expected Transmission) để thiết lập truyến đường trong mạng. Thông tin phản hồi về chất lượng liên kết được thực hiện bời khối ước lượng chất lượng liên kết (Link Estimator).

Hình 3.10 minh họa cấu trúc các thành phần trong module ContikiRPL.

ContikiRPL

Quản lý cấu trúc liên kết DAG

Quản lý các bản tin điều khiển

Quản lý các

nút lân cận Hàm mục tiêu Quản lý các

bộ định thời

Hình 3.10: Cấu trúc các thành phần trong module Contiki RPL. Contiki RPL bao gồm các thành phần chính:

 Quản lý cấu trúc liên kết DAG: Khối này quản lý quá trình tham gia, xây dựng, duy trì DAG. Khối này cung cấp những phương thức quản lý DAG

Một phần của tài liệu (LUẬN văn THẠC sĩ) nghiên cứu đánh giá giao thức thu thập dữ liệu cho mạng lưới đồng hồ nước thông minh (Trang 56)

Tải bản đầy đủ (PDF)

(87 trang)