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 Hình 2.17: Gói tin truyền tải phải đủ dài để nó khơng nằm giữa các CCA kế
tiếp nhau.
Yêu cầu về ti và tc cũng đặt u cầu trên kích thước gói tin ngắn nhất mà ContikiMAC có thể hỗ trợ, như trong hình 2.17.
Đối với ContikiMAC, để hai CCA có thể phát hiện được gói tin dữ liệu thì khơng thể truyền gói tin ngắn đến mức để gói tin dữ liệu rơi vào khoảng giữa các CCA. Đặc biệt, thời gian truyền của gói ngắn nhất (ts), phải lớn hơn tr + tc + tr.
Khi một CCA đã phát hiện một gói tin dữ liệu được truyền dẫn thì ContikiMAC sẽ giữ cho kênh trên để có thể nhận được đầy đủ gói tin dữ liệu. Khi nhận được đầy đủ gói tin, một bản tin xác nhận được truyền đi. Thời gian cần thiết cho một gói tin xác nhận được truyền đi (ta) và thời gian cần cho một gói xác nhận được phát hiện (td), thiết lập giới hạn dưới cho khoảng thời gian tc.
Như vậy, các ràng buộc thời gian trong ContikiMAC đầy đủ là:
ta + td< ti < tc < tc+ 2tr < ts (2.1) Với lớp liên kết IEEE 802.15.4 và bộ thu phát vơ tuyến cụ thể, một số biến trong phương trình 2.1 được đưa ra dưới dạng hằng số. Đầu tiên, ta thời gian giữa nhận gói và gửi gói xác nhận, được xác định bởi đặc tả IEEE 802.15.4 như 12 ký hiệu. Trong IEEE 802.15.4, một ký hiệu dài 4/250 ms, 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 đó ta xác định được ta= 48/250 = 0,192 ms. Thứ hai, một bộ thu IEEE 802.15.4 có thể phát hiện việc xác nhận đáng tin cậy sau đoạn mở đầu dài 4 byte và bắt đầu phân tách khung 1 byte, mất 40/250 ms. Như vậy, td = 40/250 ms. Cuối cùng, tr được đưa ra bởi khung dữ liệu của bộ thu phát vô tuyến CC24200 là 192 ms. Với các hằng số thay thế, phương trình 1 trở thành:
0.352 < ti < tc < tc+ 0.384 < ts (2.2) Các biến còn lại ti, tc và ts có thể được lựa chọn. Phương trình 2.2 cho một giới hạn đối với khoảng thời gian ts> 0.736 ms, từ đó thiết lập một giới hạn về kích thước gói nhỏ nhất đối với giao thức ContikiMAC. Với tốc độ bit là 250 kbps, điều này có nghĩa là các gói phải dài ít nhất 23 byte, bao gồm cả phần mở đầu, bắt đầu của dấu phân cách khung và trường độ dài, và còn lại 16 byte dữ liệu.
Để đảm bảo rằng tất cả các gói lớn hơn kích thước gói nhỏ nhất, các gói có thể được bổ sung thêm phần đệm để đảm bảo kích thước gói tối thiểu. Ngồi ra, nếu lớp mạng có thể đảm bảo rằng các gói khơng bao giờ thấp hơn một kích thước nhất định, thì khơng cần thiết phải thêm phần đệm khung. Ví dụ, trong trường hợp lớp mạng IPv6, các gói có tiêu đề IPv6 đầy đủ sẽ ln dài hơn kích thước gói ContikiMAC nhỏ nhất trên lớp liên kết IEEE 802.15.4. Với kỹ thuật nén tiêu đề IPv6, gói tin có thể trở nên nhỏ hơn, để đảm bảo kích thước gói nhỏ nhất thì đơn giản là khơng nén tiêu đề của gói IPv6 nhỏ hơn ngưỡng cho trước.
Việc triển khai ContikiMAC trong Contiki sử dụng cấu hình sau: ti = 0.4 ms.
tc = 0.5 ms. ts = 0.884 ms.
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ế CCA trong ContikiMAC không phát hiện được sự truyền tải các gói tin một cách tin cậy bởi vì nó chỉ phát hiện được cường độ tín hiệu vơ tuyến ở trên một ngưỡng cho trước. Việc phát hiện tín hiệu vơ tuyến có thể do một nút lân cận đang truyền một gói tin cho nút nhận, người hàng xóm kia đang truyền với một thiết bị thu khác hoặc cũng có thể do một vài thiết bị khác đang bức xạ ra năng lượng vô tuyến và được phát hiện bởi cơ chế CCA. ContikiMAC phải có khả năng phân biệt giữa các sự kiện này và phản ứng đúng cách. Nếu một nút lân cận đang truyền một gói tin cho nút nhận thì nút nhận phải thức giấc (bật bộ vơ tuyến) để nhận đầy đủ gói tin và truyền lại một bản tin xác nhận. Các nút lân cận khác phát hiện được gói tin thì có thể nhanh chóng chuyển sang chế độ ngủ (tắt bộ vô tuyến) một lần nữa. Tuy nhiên, những nút nhận tiềm năng khơng thể nhanh chóng chuyển sang chế độ ngủ, vì chúng phải bật bộ vơ tuyến để có thể nhận được đầy đủ gói tin đó. Cách đơn giản để xác định khoảng thời gian có thể bật bộ vô tuyến khi một CCA đã phát hiện hoạt động vô tuyến là bật bộ vô tuyến trong khoảng thời gian tl + ti + tl, trong đó tl là thời gian truyền của gói tin dài nhất có thể. Điều này đảm bảo rằng nếu CCA được bật trong khoảng thời gian bắt đầu gói tin, thì nút nhận sẽ nhận được gói tin đầy đủ.
Hình 2.18: Tối ưu hóa chuyển sang chế độ ngủ nhanh trong ContikiMAC: nếu một khoảng thời gian im lặng không được phát hiện trước tl, nút nhận quay
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 trở lại trạng thái ngủ. Nếu khoảng thời gian im lặng dài hơn ti, nút nhận quay
trở lại trạng thái ngủ. Nếu khơng nhận được gói nào sau khoảng thời gian im lặng, ngay cả khi phát hiện hoạt động vô tuyến, nút nhận trở lại trạng thái ngủ.
Việc tối ưu hóa giấc ngủ nhanh cho phép nút nhận tiềm năng chuyển sang trạng thái ngủ sớm hơn nếu CCA được bật do nhiễu vơ tuyến giả. Việc tối ưu hóa giấc ngủ nhanh mang lại hiệu quả trong việc xác định mơ hình truyền dẫn ContikiMAC cụ thể như sau: Thứ nhất, nếu CCA phát hiện hoạt động vơ tuyến, nhưng hoạt động vơ tuyến có thời lượng dài hơn độ dài gói tối đa tl, khi đó CCA đã phát hiện ra nhiễu và có thể quay trở lại trạng thái ngủ. Thứ hai, nếu hoạt động vô tuyến được theo sau một khoảng thời gian im lặng và hoạt động này dài hơn khoảng thời gian giữa hai lần truyền liên tiếp ti, thì nút nhận có thể quay lại chế độ ngủ. Thứ ba, nếu chu kỳ hoạt động theo sau bởi một chu kỳ im lặng có độ dài chính xác, tiếp theo là hoạt động, nhưng không phát hiện được sự bắt đầu một bản tin, thì nút nhận có thể quay trở lại trạng thái ngủ. Quá trình này được minh họa ở hình 2.18.
2.3.2.3. Xác định pha truyền dẫn
Nếu chúng ta giả định rằng mỗi nút nhận có khoảng thời gian định kỳ thức giấc ổn định thì nút gửi có thể sử dụng những nhận biết về pha thức giấc của nút nhận để tối ưu hóa việc truyền của nó. Nút gửi có thể tìm hiểu pha thức giấc của nút nhận bằng cách ghi lại thời gian mà tại đó nó nhận được một bản tin xác nhận của lớp liên kết từ nút nhận.
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.19: Xác định pha truyền dẫn: Sau khi truyền thành công, nút gửi đã
xác định được pha thức giấc của nút nhận, do đó cần gửi bản tin với số lần truyền ít hơn.
Vì nút nhận cần phải bật bộ thu phát vơ tuyến để có thể nhận được gói, nên nút gửi có thể giả định rằng việc tiếp nhận một bản tin xác nhận lớp liên kết đồng nghĩa với việc nút gửi đã truyền thành cơng gói tin trong cửa sổ thức giấc của nút nhận. Do vậy, nút gửi xác định được pha thức giấc của nút nhận. Sau khi nút gửi đã xác định được pha thức giấc của nút nhận, nút gửi có thể bắt đầu truyền liên tiếp bản tin dữ liệu cho nút nhận ngay trước khi nút nhận dự định sẽ bật bộ thu phát vơ tuyến. Q trình này được minh họa trong hình 2.19.
2.3.2.4. Thực thi giao thức ContikiMAC trong hệ điều hành Contiki
Việc thực thi giao thức ContikiMAC trong hệ điều hành Contiki sử dụng bộ định thời thời gian thực của Contiki (rtimer) để lên lịch các lần đánh thức định kỳ nhằm đảm bảo một hành vi ổn định ngay cả khi nhiều tiến trình cơ bản đang chạy. Các bộ định thời thời gian thực ưu tiên bất kỳ tiến trình
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 Contiki nào tại một thời điểm chính xác mà chúng được lập lịch. Cơ chế đánh thức ContikiMAC chạy như một protothread và được lập lịch bởi một bộ định thời thời gian thực định kỳ. Protothread này thực hiện việc đánh thức định kỳ và thực hiện tối ưu hóa việc chuyển sang chế độ ngủ nhanh. Các quá trình truyền được điều khiển bởi một tiến trình Contiki thơng thường. Nếu việc đánh thức được lập lịch xảy ra khi đường truyền vô tuyến đang bận trong quá trình truyền thì bộ định thời sẽ lập lịch lại một đánh thức mới sau một khoảng thời gian mà một lập lịch đánh thức khác không được thực hiện.
Cơ chế xác định pha truyền dẫn được thực hiện như một mô-đun riêng biệt trong ContikiMAC, để cho phép nó được sử dụng bởi các cơ chế tiết kiệm năng lượng khác ở lớp MAC. Cơ chế xác định pha truyền dẫn duy trì một danh sách các nút lân cận và các pha thức giấc của chúng. Khối logic truyền dẫn ContikiMAC ghi lại thời gian truyền dẫn của mỗi gói tin. Khi nhận được một bản tin xác nhận lớp liên kết, nó sẽ thơng báo thời gian truyền của gói tin cuối cùng tới mô-đun xác định pha truyền dẫn. Thời gian này được sử dụng như là pha thức giấc gần đúng của nút nhận.
Trước khi bắt đầu một truyền dẫn, khối logic truyền dẫn ContikiMAC gọi tới mô-đun xác định pha truyền dẫn để kiểm tra xem có một pha thức giấc của nút nhận dự định đã được ghi lại chưa. Nếu một pha thức giấc đã được ghi lại thì gói tin được truyền đi được đưa vào hàng đợi truyền và thiết lập bộ định thời ctimer tại thời điểm thức giấc dự kiến của nút nhận. ContikiMAC sẽ tiếp tục truyền dẫn bản tin khi sự kiện với bộ định thời ctimer xuất hiện. Sự truyền dẫn sau đó sẽ ngắn hơn đáng kể so với truyền dẫn thông thường thường, bởi vì nó xảy ra ngay trước khi nút lân cận dự kiến sẽ thức giấc. Việc giảm thời gian truyền dẫn cũng làm giảm tắc nghẽn đường truyền vơ tuyến.
Nếu một nút lân cận có pha thức giấc được khởi động lại, hoặc chu kỳ thức giấc của nó đã thay đổi nhiều so với pha thức giấc đã được xác định
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 trước đây thì việc truyền dẫn cho nút lân cận sẽ thất bại. Để giải quyết vấn đề này, ContikiMAC duy trì số lần truyền khơng thành cơng cho mỗi nút lân cận đã biết. Sau một số cố định lần truyền tải không thành công, nút lân cận sẽ bị xóa khỏi danh sách những nút lân cận đã biết. Tương tự như vậy, nếu không nhận được bản tin xác nhận ở lớp liên kết trong một khoảng thời gian cố định (30s trong Contiki), với bất kỳ số lần truyền nào thì nút lân cận cũng sẽ bị xóa khỏi danh sách.
2.3.3. Thực thi giao thức XMAC
2.3.3.1. Mục tiêu thiết kế giao thức XMAC
Mục tiêu thiết kế của giao thức X-MAC cho mạng cảm biến không dây là:
Hiệu quả năng lượng.
Đơn giản, chi phí thấp, thực hiện phân tán. Độ trễ thấp.
Thông lượng cao.
Có khả năng ứng dụng trên tất cả các loại gói tin.
Đối với nhiều ứng dụng, các kỹ thuật chu kỳ làm việc khơng đồng bộ thích hợp hơn so với kỹ thuật đồng bộ về mặt tiêu thụ năng lượng, độ trễ và thông lượng do chúng khơng phát sinh chi phí cho việc đồng bộ hóa. Ngồi ra, các kỹ thuật không đồng bộ không phải chia sẻ thông tin lập lịch và chỉ thức giấc trong khoảng thời gian đủ để lấy mẫu kênh truyền trừ khi chúng đang nhận hoặc truyền dữ liệu. Do đó, thời gian thức giấc có thể ngắn hơn đáng kể so với phương pháp đồng bộ. Với thời gian thức giấc ngắn hơn, các giao thức khơng đồng bộ có thể bật bộ thu phát vơ tuyến thường xuyên hơn trong khi vẫn duy trì chu kỳ làm việc thấp. Điều này cũng có thể cho phép giảm độ trễ và tăng thơng lượ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 Hình 2.20: XMAC sử dụng một chuỗi báo hiệu để thông báo một truyền dẫn.
XMAC sử dụng một số cơ chế khác nhau để truyền unicast và broadcast một bản tin. Khi phía thu nhận được một bản tin báo hiệu thì nó trả lời lại một bản tin xác nhận ACK. Sau đó, phía gửi dừng việc gửi bản tin báo hiệu và tiến hành gửi một bản tin dữ liệu. Cơ chế này được thể hiện ở hình 2.20.
Việc truyền dẫn sẽ thất bại nếu xảy ra một trong các điều kiện sau đây: Khơng có bản tin xác nhận báo hiệu (strobe-ACK) nào nhận được sau
một khoảng thời gian tương đương với khoảng thời gian thức giấc. Khơng có bản tin xác nhận dữ liệu (data-ACK) nào nhận được sau khi
truyền dẫn khung dữ liệu.
Trong cả hai trường hợp, việc thực hiện truyền lại sẽ được thực hiện ở lớp cao hơn. Như vậy, giao thức XMAC giúp giảm thời gian lắng nghe, giảm được độ trễ và năng lượng tiêu thụ.
Trong giao thức XMAC, mỗi nút phải định kỳ thức giấc và bật bộ vô tuyến trong suốt một khoảng ngắn thời gian. Trong suốt khoảng thời gian này, nút mạng lắng nghe các gói tin đến tiềm năng. Nếu khơng có gói tin nào được truyền dẫn thì nút mạng sẽ chuyển sang trạng thái ngủ. Độ dài khoảng thời gian bật bộ vô tuyến thông thường chiếm 5% - 10% khoảng thời gian đánh thức. Khoảng thời gian đánh thức thông thường là 125ms. Thời gian bật bộ vơ tuyến có thể được kéo dài nếu nút mạng vẫn tham gia vào việc truyền dẫn ở cuối chu kỳ.
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.3.2. Thực thi giao thức XMAC trong hệ điều hành Contiki
Việc thực thi giao thức XMAC trong hệ điều hành Contiki có một số đặc điểm khác biệt so với giao thức XMAC ban đầu. Một số điểm khác biệt chính có thể kể đến như sau:
Tối ưu hóa về thời gian truyền nhận: Việc thực thi giao thức XMAC trong hệ điều hành Contiki sử dụng một cơ chế tương tự như cơ chế xác định pha truyền dẫn trong giao thức ContikiMAC. Cơ chế này sẽ cho phép phía gửi tìm hiểu được thời điểm bật bộ vơ tuyến của phía nhận. Điều này cho phép việc truyền dẫn có thể thực hiện được với việc chỉ cần trung bình hai bản tin thăm dị.
Truyền dẫn dữ liệu tin cậy: Việc thực thi giao thức XMAC trong Contiki sử dụng một cờ. Cờ này được thiết lập để thông báo sự cần thiết phải xác nhận cho bản tin dữ liệu. Đây là một tùy chọn đối với giao thức XMAC ban đầu. Điều này giúp việc truyền dữ liệu tin cậy