CHƯƠNG 2: SỬ DỤNG NĂNG LƯỢNG TRONG BLE
2.3. Các chế độ năng lượng trong BLE
Trong chế độ Active, là chế độ giống như Bluetooth cổ điển, thiết bị tham gia hoạt động trên kênh sóng radio, Master sắp xếp các quá trình truyền phát dữ liệu, các gói tin được chuyển phát trên những băng tần được xác định
và Slave phải lắng nghe các gói tin ở những khe thời gian được dành riêng cho chúng. Chế độ này là một tiêu chuẩn kỹ thuật để so sánh với hiệu năng của những chế độ năng lượng thấp bởi vì nó không những tiêu tốn hầu hết năng lượng mà còn có thông lượng dữ liệu truyền phát. Sự tiêu thụ năng lượng của thiết bị phụ thuộc nhiều vào nhà sản xuất thiết bị và ứng dụng đang chạy trên đó.
Những ứng dụng mà thích hợp với chế độ Active thì sẽ không có lợi hoặc không thể sử dụng bất kỳ chế độ năng lượng thấp nào khác (hold, sniff, park). Một ứng dụng có nhu cầu tần số dữ liệu truyền phát cao thì khó có thể tiết kiệm năng lượng bởi vì nó cần năng lượng cho máy truyền phát sóng radio cho phần lớn chu kỳ hoạt động. Tương tự những ứng dụng yêu cầu độ trễ cực thấp cũng không thích hợp để sử dụng những chế độ năng lượng thấp.
2.3.2. Hold mode
Đây là chế độ cơ bản (nhưng khó thiết lập và sử dụng) trong những chế độ năng lượng thấp của BLE. Master và Slave sẽ thỏa thuận với nhau trong suốt thời gian mà thiết bị Slave ở trong chế độ này. Khi một kết nối thiết lập trong chế độ này, nó không hỗ trợ những gói dữ liệu trên kết nối đó và có thể tiết kiệm năng lượng, lắng nghe định kỳ một khoảng thời gian lâu hơn hoặc cũng có thể tham gia vào một piconet mới. Điều quan trọng là thời gian Hold sẽ được thỏa thuận trước mỗi khi chế độ Hold được thiết lập.
Hình. 2.1. Hold Mode Interaction
Hình trên cho thấy sự tương tác giữa những thiết bị sử dụng chế độ Hold. Một khía cạnh quan trọng hơn của chế độ Hold là mỗi lần chế độ này được thiết lập nó sẽ không bị hủy bỏ, và khoảng thời gian Hold phải kết thúc trước khi sự truyền thông có thể tái kích hoạt trở lại.
Hold mode thuận lợi cho những ứng dụng dự báo và điều khiển thời gian cho lần truyền dữ liệu kế tiếp. Khi mà khoảng thời gian giữa 2 lần truyền được thương lượng một cách độc lập bởi lần tiếp theo thì chế độ này vô cùng thích hợp để ứng dụng giám sát thường xuyên kết nối và có thể tăng hoặc giảm “thời gian ngủ” (sleep time) cho phù hợp. Hold mode không thể tự biến mất và do đó không nên dùng cho những ứng dụng có nhu cầu khắt khe về độ trễ.
2.3.3. Sniff mode
Hình. 2.2. Sniff Mode Interaction
Chế độ năng lượng thấp này tiết kiệm năng lượng bằng cách giảm số lượng khe thời gian mà Master bắt đầu quá trình truyền phát dữ liệu và do đó cũng giảm số khe thời gian mà Slave phải lắng nghe. Slave sẽ lắng nghe một cách định kỳ số slot và điều này làm cho sniff mode đặc biệt thuận lợi hơn đối với những ứng dụng mà dữ liệu đòi hỏi được truyền ở những khoảng thời gian cách đều.
Tsniff làkhoảng thời gian giữa những khe thời gian được thỏa thuận giữa Mastervà Slave khi chế độ Sniff được thiết lập. Khi Slave lắng nghe trên kênh truyền, nó làm việc trong những khe Nsniff attempt, sau đó có thể giảm năng lượng cho đến cuối khoảng thời gian Sniff hiện thời. Thời gian tiếp nhận gói dữ liệu cuối cùng dành cho Slave rất quan trọng, vì vậy Slave phải lắng nghe trong khoảng thời gian Nsniff timeout ngắn nhất sau khi gói tin cuối cùng được nhận xong
Hình 2.2. A cho thấy số lượng khe thời gian mà Slave phải lắng nghe.
Trongtrường hợp này Slave chỉ lắng nghe trong khoảng thời gian Nsniff attempt. Điều này xảy ra nếu Slave nhận được gói tin cuối cùng khi có nhiều hơn những khe Nsniff timeout trong Sniff attempt. Slave chỉ lắng nghe trong phần lớn khoảng thời gian Sniff attempt, sau đó giảm năng lượng.
Hình 2.2. B cho thấy Slave đang lắng nghe trong một khoảng thời gian mởrộng. Trong trường hợp này Slave lắng nghe khe Nsniff attempt, sau đó nhận một gói tin và lắng nghe thêm những khe thời gian Nsniff timeout.
Điều này cho thấy Slave phải lắng nghe thêm những khe thời gian Nsniff timeout nếu gói tin được nhận khi có ít hơn những khe Nsniff timeoutởbên trái khoảng thời gian Sniff attempt. Nếu Slave tiếp tục nhận những
gói tin, nó sẽ lắng nghe tiếp tục những khe Nsniff timeout sau khi gói tin cuối cùng được nhận, vì vậy nếu Master vẫn giữ nguyên quá trình truyền phát thì Slave vẫn hoạt động.
Slave có thể thay đổi hoạt động của nó chỉ từ những khe Nsniff attempt thông qua những khe (Nsniff attempt +Nsniff timeout) và thậm chí tiếp tục hoạt động mà không cần thỏa thuận lại một vài tham số. Bằng cách chọn lựa những giá trị thích hợp cho khoảng thời gian Sniff và số lượng khe mà Slave phải lắng nghe, đạt được hiệu quả tiết kiệm năng lượng mà không ảnh hưởng bất lợi đến hiệu năng của ứng dụng.
Chế độ Sniff thì linh hoạt hơn chế độ Hold bởi vì Master hoặc Slave có thể giải phóng chế độ này. Bởi vì chế độ Sniff đòi hỏi thiết bị Slave thay đổi trạng thái hoạt động một cách định kỳ nên nó thích hợp cho những ứng dụng có sự truyền phát dữ liệu cách đều nhau.
Chế độ này thì không thích hợp cho những ứng dụng đòi hỏi thường xuyên truyền phát dữ liệu lớnmột cách liên tục vì điều này bắt buộc thiết bị phải giữ nguyên hình trạng awake.
2.3.4. Park mode
Chế độ Park (chế độ dừng) là một chế độ năng lượng thấp cho phép tiết kiệm năng lượngnhất. Chế độ này thuận lợi nhất đối với những ứng dụng có mô hình lưu lượng ngẫu nhiên(không thể dự đoán trước) và độ trễ của việc thiết lập kết nối được cho phép là khá lớn.
Chế độ Park tạm thời dừng kết nối với các thiết bị slave để cho phép loại bỏ hẳn một số slave ra khỏi quá trình truyền thông. Khi các slave muốn tham gia trở lại cần thiết lập lại địa chỉ và các tham số truyền thông. Do đó kéo dài thời gian tiết kiệm năng lượng. Khi các lệnh từ master yêu cầu slave
“dừng”, các slave sẽ định kỳ được đánh thức và lắng nghe tín hiệu đồng bộ dẫn đường quảng bá (beacon signal) từ master unit. Nếu tín hiệu dẫn đường chứa địa chỉ của thiết bị đang bị “dừng”, thiết bị đó sẽ được tái khởi động để tham gia trở lại vào piconet.
Trong chế độ này, một số Slavekhông tham gia vào Piconet, tuy nhiên nó vẫn đồng bộ với kênh truyềntrong Piconet thông qua tín hiệu đồng bộ dẫn đường quảng bá beacon signal.Chế độ này có thêm một thuận lợi là cho phép Master hỗ trợhơn 7 thiết bị Slave bằng cách đưa những thiết bị còn lại vào trạng thái Parktrong khi những thiết bị khác đang hoạt động trong trạng thái Active.
Khi thiết kế ứng dụng, chúng ta phải chọn khoảng thời gian tín hiệu chính xác để tiết kiệm năng lượng trong khi duy trì thời gian hồi đáp có thể
chấp nhận. Thời gian phản hồi chịu ảnh hưởng bởi Slave cần bao lâu để yêu cầu Unpark, hoặc Master cần bao lâu để Unpark cho Slave. Cả 2 trường hợp trên điều bị chi phối bởi thời gian tín hiệu Park.
Nếu Slave trong chế độ Park mất sự đồng bộ, nó sẽ ngừng hồi đáp đến Master và có thể hoàn toàn mất kết nối. Sau đó Master sẽ khôi phục kết nối bằng cách gửi tín hiệu Paging đến Slave, rồi lại đặt nó vào chế độ Park lần nữa. Rõ ràng đây là sự hao phí vô ích. Vì vậy những thiết bị trong chế độ Park trong phần lớn thời gian hoạt động nên có những khoảng thời gian báo hiệu để mà nếu Slave bị nhỡ một tín hiệu, nó có thể được tái đồng bộ ở lần kế tiếp. Nói chung, để Master có thể gửi dữliệu đến Slave thì trước tiên Slave phải được Unpark.
Rõ ràng là chế độ Park tiết kiệm năng lượng nhất nhưng quá trình tái khởi tạo địa chỉ, tham số để tham gia lại vào piconet của các slave làm tăng thời gian trễ. Do vậy, mạng cảm biến hoặc các ứng dụng yêu cầu thời gian trễ thấp thì không thích hợp sử dụng chế độ Park.
Hình 2.3. Ví dụ về các chế độ tiết kiệm năng lượng của BLE
Hình 2.3 thể hiện các chế độ tiết kiệm năng lượng trong BLE. Chúng ta có thể thấy sniff là chế độ cân bằng nhất giữa tiêu chí tiết kiệm năng lượng và đảm bảo độ trễ giới hạn.