2.2.1.3. Giao thức ContikiMAC
ContikiMAC là giao thức quản lý bộ thu phát vô tuyến thông qua việc định kỳ bật bộ thu phát vơ tuyến để lắng nghe các gói tin được truyền tải từ các nút lân cận. Hình 2.11 minh họa hoạt động của giao thức ContikiMAC.
Số hóa bởi Trung tâm Học liệu và Cơng nghệ thông tin – ĐHTN http://lrc.tnu.edu.vn Hình 2.11: Cơ chế hoạt động của giao thức ContikiMAC.
Để gửi một bản tin dữ liệu, phía gửi sẽ gửi lặp đi lặp lại cùng một bản tin cho đến khi nhận được một bản tin xác nhận. Các nút trong mạng tắt bộ vô tuyến trong phần lớn thời gian và định kỳ bật bộ vô tuyến để kiểm tra kênh truyền. Nếu phát hiện một bản tin dữ liệu đang được truyền trên kênh truyền thì phía thu sẽ ln bật bộ vơ tuyến để nhận được bản tin dữ liệu. Nút nhận sẽ kiểm tra bản tin dữ liệu, nếu bản tin dữ liệu gửi cho nó thì nó sẽ xác nhận lại phía gửi bằng một bản tin xác nhận ACK.
Như vậy, giao thức ContikiMAC được thiết kế đơn giản, dễ thực thi và không cần phải sử dụng các bản tin báo hiệu gửi cũng như các tiêu đề bổ sung.
2.2.2. Các giao thức đồng bộ thời gian
Mặc dù các giao thức tiết kiệm năng lượng không đồng bộ như LPL rất hữu ích bởi sự đơn giản của chúng, nhưng hiệu năng của chúng có thể được cải thiện bằng cách thực hiện đồng bộ giữa chúng. Các giao thức đồng bộ được xây dựng trên sự đồng bộ rõ ràng về thời gian. Các giao thức tiết kiệm năng lượng không đồng bộ thực hiện đồng bộ các nút một cách ngầm định đối
Số hóa bởi Trung tâm Học liệu và Công nghệ thông tin – ĐHTN http://lrc.tnu.edu.vn với mọi sự truyền dẫn dữ liệu, nhưng các giao thức đồng bộ thực hiện đồng bộ các nút một cách rõ ràng trước khi gửi các gói dữ liệu thực sự.
Với việc đồng bộ thời gian, thì một giao thức đồng bộ có thể giảm thời gian mà giao thức này phải giữ bộ vô tuyến ở trạng thái bật và làm giảm năng lượng tiêu thụ tổng thể. Một ví dụ về giao thức đồng bộ thời gian là giao thức TSMP [6]. TSMP là cơ sở của hai chuẩn mạng cảm biến công nghiệp là WirelessHART và ISA100a. Ngoài việc cho phép kéo dài khoảng thời gian tồn tại của mạng bằng cách tắt bộ vô tuyến càng nhiều càng tốt thì TSMP cũng đạt được độ tin cậy cao bằng cách liên tục chuyển đổi tần số vơ tuyến vật lý mà các gói tin được gửi đi. Tồn mạng được quản lý tập trung do vậy toàn bộ mạng được lập lịch bởi nhà quản lý mạng (một máy chủ nhỏ đặt gần mạng).
Hình 2.12: Với một giao thức đồng bộ thời gian chẳng hạn như TSMP thì các nút cần phải bật bộ vơ tuyến với thời gian ít hơn, bởi vì chúng biết chính xác
khi nào phía gửi có thể truyền dữ liệu.
Trong giao thức TSMP, tất cả các nút được đồng bộ thời gian trong vịng 50μs. Thời gian được chia thành các khe có độ dài 10ms. Ở mỗi khe thời gian, một nút hoặc là lắng nghe (việc truyền dẫn hồn tồn có thể nếu nút có dữ liệu để truyền), hoặc ngủ. Khi lắng nghe, nút lắng nghe trong một thời gian ngắn ở thời điểm bắt đầu của khe thời gian 10ms. Nếu một nút đang truyền dữ liệu trong khe thời gian này, thì việc truyền dữ liệu sẽ bắt đầu trong vịng
Số hóa bởi Trung tâm Học liệu và Công nghệ thông tin – ĐHTN http://lrc.tnu.edu.vn 100μs. Vì vậy, phía thu khơng cần giữ bộ vô tuyến ở trạng thái bật dài hơn 100μs trong các khe thời gian 10ms mà nó có thể nhận được một gói tin.
Quá trình đồng bộ thời gian được chỉ ra trong hình 2.12. Phía gửi chỉ cần gửi một byte đồng bộ rất ngắn trước khi gửi gói tin của nó, bởi vì phía thu có thể nhanh chóng xác định dù là một gói tin được truyền hay khơng được truyền.
2.3. Thực thi một số giao thức tiết kiệm năng lượng ở lớp MAC trên hệ điều hành Contiki điều hành Contiki
XMAC và ContikiMAC là hai giao thức khơng đồng bộ. Khơng có một kế hoạch lập lịch đánh thức nào được thiết lập giữa các nút. Thay vào đó, để một bản tin được truyền đi thì phía gửi cần được đồng bộ với phía nhận. Hai giao thức này đã được thực thi trong hệ điều hành Contiki. Phần dưới đây sẽ mô tả chi tiết về hệ điều hành Contiki và thực thi hai giao thức này trên hệ điều hành Contiki.
2.3.1. Hệ điều hành Contiki 2.3.1.1. Giới thiệu 2.3.1.1. Giới thiệu
Contiki là một mã nguồn mở, có tính di động cao, điều hành đa tác vụ cho hệ thống nhúng với bộ nhớ hạn chế được viết bởi Adam Dunkels đến từ nhóm Embedded Systems của Viện Khoa học Máy tính Thụy Điển [2]. 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. Contiki được thiết kế cho các hệ thống nhúng với một lượng nhỏ bộ nhớ. Một cấu hình điển hình Contiki là 2 kilobyte bộ nhớ RAM và 40 kilobytes ROM. Contiki bắt đầu được nghiên cứu từ năm 2001 và phát hành phiên bản đầu tiên Contiki 1.0 năm 2003.
Số hóa bởi Trung tâm Học liệu và Cơng nghệ thơng tin – ĐHTN http://lrc.tnu.edu.vn Hình 2.13: Lịch sử phát triển Contiki.
Hình 2.13 cho thấy lịch sử phát triển của Contiki trong những năm qua. Phiên bản hiện nay của Contiki là 2.6, với nhiều thay đổi, bổ sung và phát triển vượt bậc. Trong thực tế, Contiki đã được ứng dụng trong nhiều dự án như giám sát đường hầm xe lửa, theo dõi nước trong biển Baltic,… Nhiều cơ chế, ý tưởng trong Contiki đã được ứng dụng rộng rãi trong công nghiệp. Điển hình như mơ hình uIP được phát hành năm 2001 đã được sử dụng trong hệ thống ứng dụng của hàng trăm công ty trong các lĩnh vực hàng hải, thông tin vệ tinh, khai thác dầu mỏ,…; mơ hình Protothreads được cơng bố lần đầu tiên năm 2005, đến nay đã được sử dụng trong nhiều ứng dụng như bộ giải mã kỹ thuật số và thiết bị cảm biến rung không dây.
Hệ điều hành Contiki được lập trình bằng ngơn ngữ C và có những đặc điểm phù hợp với các hệ thống nhúng và mạng cảm biến không dây:
Contiki được chia thành nhiều module hoạt động độc lập. Nhờ đó các ứng dụng có thể sử dụng các module một cách linh động và chỉ nạp những module cần thiết.
Số hóa bởi Trung tâm Học liệu và Cơng nghệ thơng tin – ĐHTN http://lrc.tnu.edu.vn Cơ chế hoạt động điều khiển sự kiện làm giảm năng lượng tiêu hao và
hạn chế dung lượng bộ nhớ cần sử dụng.
Có thể sử dụng IP trong mạng cảm biến thông qua uIP stack được xây dựng dựa trên nền TCP/IP.
Có những module cho phép ước lượng và quản lý năng lượng một cách hiệu quả.
Có ngăn xếp truyền thơng RIME phục vụ các giao thức dành cho mạng năng lượng thấp một cách hiệu quả.
Bên cạnh đó, Contiki cịn cung cấp những cơng cụ hỗ trợ mô phỏng với giao diện đơn giản, dễ sử dụng và hỗ trợ tốt những thiết bị trong thực tế, phục vụ những mục đích nghiên cứu, mơ phỏng và triển khai những giao thức mới.
2.3.1.2. Cấu trúc hệ điều hành Contiki
Bất kỳ phiên bản Contiki nào cũng gồm 7 thư mục là: apps, core, cpu, docs, example, platform và tools.
Thư mục apps: Chứa các tập tin nguồn của các tiện ích phát triển cho
Contiki. Chúng có sẵn để sử dụng và bao gồm các thiết lập cơ bản của các ứng dụng cho mạng cảm biến không dây . Ứng dụng tiêu biểu trong thư mục này là trình duyệt web, máy chủ Web, FTP, email....
Thư mục Core: Như tên gọi cho thấy, nó chứa các hạt nhân của hệ
điều hành Contiki. Nó chứa khoảng 300 files, gần một nửa trong số đó là tập tin tiêu đề chứa các khai báo và còn lại là các tập tin nguồn chứa cài đặt.
Thư mục CPU: Chứa các bộ xử lý cụ thể cho việc thực hiện các chức
năng khác nhau được sử dụng trong hệ điều hành.
Thư mục Docs: Được sử dụng trong việc xây dựng tài liệu cho
Số hóa bởi Trung tâm Học liệu và Cơng nghệ thông tin – ĐHTN http://lrc.tnu.edu.vn Thư mục Examples: Chứa các chương trình ví dụ đơn giản bắt đầu với
“Hello-world”, như là bước đầu tiên hướng tới lập trình ứng dụng trên Contiki.
Thư mục Platform: Bao gồm thông tin cụ thể liên quan đến nền tảng
phần cứng cho các nút cảm biến như ESB, Tmote Sky…
Thư mục Tools: Là thư mục chứa các cơng cụ phần mềm đặc biệt. Ví
dụ như Cooja là một chương trình Java để mơ phỏng cho Contiki. Thư mục này cũng chứa các công cụ cho các nền tảng phần cứng cụ thể. Ví dụ điển hình là các cơng cụ cho nút cảm biến Tmote Sky của Sentilla.
2.3.1.3. 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 như hình 2.14.
Số hóa bởi Trung tâm Học liệu và Công nghệ thông tin – ĐHTN http://lrc.tnu.edu.vn 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 2.15.
Hình 2.15: Sơ đồ hoạt động các ứng dụng trong Contiki.
2.3.1.4. Các bộ định thời trong Contiki
Trong Contiki sử dụng 4 loại định thời:
Timer: là loại định thời thụ động, chỉ sử dụng để lưu lại vết các thời điểm khi bộ định thời hết hạn.
Rtimer: là loại định thời thời gian thực, sử dụng để gọi một hàm tại một thời điểm cụ thể nào đó.
Event timer (etimer): Được kích hoạt trong các Process và sử dụng để gửi một sự kiện đến Process khi bộ định thời hết hạn.
Callback timer (ctimer): Có thể được sử dụng ở bất kỳ vị trí nào trong chương trình, có chức năng gọi một hàm xử lý mỗi khi bộ định thời hết hạn. Ctimer được sử dụng trong mô đun RIME của Contiki.
Số hóa bởi Trung tâm Học liệu và Công nghệ thông tin – ĐHTN http://lrc.tnu.edu.vn
2.3.1.5. Các mơ hình lập trình trong Contiki
2.3.1.5.1. Lập trình Event-driven
Lập trình hướng sự kiện (Event-driven) là một mơ hình lập trình hiệu quả về bộ nhớ để viết phần mềm cho các nút cảm biến. Với kiểu lập trình này, phần mềm được viết như là các trình xử lý sự kiện: Các đoạn mã ngắn gọn mô tả làm thế nào mà hệ thống đáp ứng được các sự kiện. Ví dụ về các sự kiện như một gói tin vơ tuyến đến từ một nút lân cận, sự kiện đọc dữ liệu cảm biến từ một trong các bộ cảm biến và sự kiện từ bộ định thời. Khi sự kiện diễn ra, nút cảm biến đáp ứng bằng cách thực thi một đoạn chương trình phần mềm của nó.
Lập trình hướng sự kiện địi hỏi ít bộ nhớ hơn so với lập trình đa luồng bởi vì khơng có luồng nào u cầu ngăn xếp bộ nhớ. Tồn bộ hệ thống có thể chạy như một luồng duy nhất và chỉ yêu cầu một ngăn xếp duy nhất.
2.3.1.5.2. Lập trình Multithreads
Đa luồng (Multithreads) là một kỹ thuật lập trình cho phép nhiều chương trình có thể chạy đồng thời trên một bộ xử lý duy nhất. Trong lập trình đa luồng, mỗi chương trình được định sẵn một luồng điều khiển riêng và luồng đó chạy cùng với tất cả các luồng khác trong hệ thống. Mỗi luồng được định sẵn thời gian nhất định để chạy trên bộ vi xử lý. Để cho phép chạy nhiều chương trình cùng một lúc, hệ điều hành chuyển đổi giữa các luồng để chúng cùng nhau chia sẻ bộ vi xử lý.
Lập trình đa luồng được sử dụng rộng rãi trong các hệ điều hành thông dụng, ở đó các luồng tự bảo vệ lẫn nhau sao cho một luồng không thể tiếp cận một luồng khác mà không đi qua các giao diện đã quy định. Khi các luồng tự bảo vệ lẫn nhau, chúng thường được gọi là các tiến trình thay vì gọi là các luồng.
Số hóa bởi Trung tâm Học liệu và Công nghệ thông tin – ĐHTN http://lrc.tnu.edu.vn Đối với các nút cảm biến không dây, tồn tại một vấn đề đa luồng là mỗi luồng yêu cầu một phần bộ nhớ của riêng mình để giữ trạng thái của các luồng này, được gọi là ngăn xếp của luồng. Các ngăn xếp chứa các biến cục bộ mà luồng sử dụng và các giá trị trả về cho các hàm mà luồng gọi đến, nhưng cũng bao gồm một lượng tương đối lớn bộ nhớ không sử dụng. Bộ nhớ này phải được cấp phát bởi vì nó chưa biết trước được có bao nhiêu ngăn xếp bộ nhớ mà mỗi luồng cần dùng. Do đó, bộ nhớ ngăn xếp thường vượt quá sự cấp phát.
2.3.1.5.3. Lập trình Protothreads
Protothreads là một cách để kết hợp ưu điểm của các mơ hình lập trình hướng sự kiện và đa luồng. Protothreads là cơ chế lập trình được phát triển cho các hệ thống có bộ nhớ hạn chế, nó kết hợp mơ hình lập trình hướng sự kiện và đa luồng theo một phương thức hiệu quả về bộ nhớ. Với Protothreads, chương trình được cấu trúc theo tuần tự, giống như trong mơ hình đa luồng, nhưng sử dụng ít bộ nhớ tương tự như mơ hình hướng sự kiện. Protothreads có thể thực hiện được hiệu quả trong ngơn ngữ lập trình C mà khơng cần bất kỳ ngơn ngữ lập trình bậc thấp hay các thay đổi nào với trình biên dịch. Điều hạn chế là các lập trình viên phải lưu trữ các biến một cách rõ ràng khi các Protothreads dừng. Bởi vì các Protothreads được thực hiện bởi ngơn ngữ C, nên chúng rất tiện lợi trên các nền tảng phần cứng khác nhau.
2.3.2. Thực thi giao thức ContikiMAC
2.3.2.1. Tính tốn thời gian trong ContikiMAC
ContikiMAC có cơ chế đánh thức hiệu quả năng lượng dựa vào thời gian chính xác giữa các lần truyền. Thời điểm thức giấc trong ContikiMAC được xác định thông qua cơ chế đánh giá kênh CCA, sử dụng tín hiệu RSSI nhận được của bộ thu phát vơ tuyến để xác định các hoạt động thu phát sóng trên kênh truyền. Nếu tín hiệu RSSI ở dưới một ngưỡng nhất định, CCA trả
Số hóa bởi Trung tâm Học liệu và Công nghệ thông tin – ĐHTN http://lrc.tnu.edu.vn về dương, cho biết kênh đã được giải phóng. Nếu tín hiệu RSSI ở trên ngưỡng, CCA trả về âm, cho biết kênh đang được sử dụng. Việc tính tốn thời gian trong ContikiMAC được thể hiện như hình 2.16.
Các yêu cầu về thời gian được thể hiện trong hình vẽ bao gồm: ti: Khoảng thời gian giữa mỗi gói tin dữ liệu được truyền dẫn.
tr: Thời gian để có tín hiệu RSSI ổn định, cần thiết cho một CCA ổn định.
Hình 2.16: Việc truyền dẫn trong ContikiMAC và tính tốn thời gian. tc: Khoảng thời gian giữa mỗi CCA. tc: Khoảng thời gian giữa mỗi CCA.
ta: Khoảng thời gian giữa việc nhận một gói tin dữ liệu và gửi một bản tin xác nhận.
td: Thời gian cần thiết để phát hiện một bản tin xác nhận thành công từ nút nhận.
Việc tính tốn thời gian phải thỏa mãn một số ràng buộc. Đầu tiên, khoảng thời gian giữa mỗi bản tin truyền (ti) phải nhỏ hơn khoảng thời gian giữa mỗi CCA (tc). Đây là điều kiện để đảm bảo CCA thứ nhất hoặc thứ hai có thể nhận biết được sự truyền dẫn một gói tin dữ liệu. Nếu tc nhỏ hơn ti thì cả hai CCA sẽ khơng thể phát hiện được sự truyền dẫn gói tin dữ liệu một cách đáng tin cậy.
Số hóa bởi Trung tâm Học liệu và Công nghệ thông tin – ĐHTN http://lrc.tnu.edu.vn