1.

Giới thiệu
a. Mạng M2M:
● Mạng này cần tiết kiệm NL để hđ trong nhiều năm, nên báo đề xuất
dùng hàng đợi phân tán ( Distributed Queuing - DQ), chia cây (tree-
splitting) để cho các máy tắt đi và thức dậy định kỳ truyền dữ liệu tới
thiết bị điều phối.
● So sánh với sơ đồ truy cập truyền thống Frame slotted aloha (FSA),
thuật toán cây tranh chấp Contention Resolution Algorithm
● Kết quả mô phỏng trên máy cho thấy DQ giảm 50% mức tiêu thụ NL
so với truyền thống.
● Medium Access Control khác với địa chỉ MAC (Media Access
Control), nó là 1 phần của tầng liên kết dữ liệu trong mô hình OSI để
quyết định các thiết bị có thể truy cập và sử dụng kênh truyền thông
chung
Do số lượng thiết bị phản hồi đồng thời với bộ điều phối có thể rất lớn nên
cần có giao thức Kiểm soát truy cập phương tiện (MAC) hiệu quả để tránh
xung đột và quản lý quyền truy cập vào phương tiện dùng chung. Có 2 giao
thức chính: giao thức truy cập ngẫu nhiên và giao thức dựa trên đặt trước.
M2M dày đặc và thay đổi nên giao thức đặt trước ko khả thi
b. Giao thức truy cập ngẫu nhiên
2 cách xử lý xung đột
● Frame Slotted-ALOHA
● tree-splitting algorithm based on the Contention Tree Algorithm (CTA)
c. Mục tiêu: tập trung vào việc tìm hiểu những điều kiện nào Distributed Queue -
DQ có thể cải thiện hiệu quả năng lượng của mạng M2M dày đặc đối với các
phương pháp tiếp cận truyền thống dựa trên FSA hoặc CTA

2. Mô hình
Xem xét 1 mạng không dây 1 chặng gồm 1 thiết bị điều phối và n thiết bị phụ. Có 4
chế độ hoạt động: Truyền, nhận, nghe không tải, ngủ. Tương ứng với các mức NL ❑tx, ❑rx,
❑❑ , ❑sleep .
Giả định:
 thời gian và năng lượng cần thiết để chuyển đổi giữa chế độ ngủ và chế độ
hoạt động là không đáng kể
 ρσ = ρrx
 Các thiết bị ngủ trong thời gian xác định trước và thức dậy định kỳ để nghe
lệnh.
 mạng có một số phương tiện hoạt động theo chu kỳ nhiệm vụ được đồng bộ
hóa
 Bộ điều phối gửi gói Yêu cầu dữ liệu (Request for Data RFD) định kỳ để bắt
đầu truyền gói dữ liệu từ mỗi slave. Giả định rằng các slave đang nghe kênh
khi bộ điều phối gửi RFD.
 Giả định rằng tất cả các gói luôn được truyền đi mà không có lỗi truyền và
khi hai hoặc nhiều gói va chạm nhau thì không có gói nào liên quan đến
xung đột có thể được giải mã.
 Sau khi giải mã RFD, các thiết bị phụ được đồng bộ hóa theo mẫu khung
thời gian chung nơi chúng truyền gói dữ liệu của mình theo các quy tắc của
cơ chế giải quyết tranh chấp.
  Một slave thành công khi gói dữ liệu của nó được bộ điều phối giải mã và
xác nhận thành công.
 Để giảm mức tiêu thụ năng lượng, các thiết bị phụ chuyển sang chế độ
ngủ trong khoảng thời gian mà họ không phải truyền cũng như không nghe
kênh
 Quá trình kết thúc khi bộ điều phối có thể giải mã chính xác một gói dữ liệu
từ mỗi slave.
3. 3 cơ chế giải quyết tranh chấp
a. Khung có rãnh ALOHA
 FSA bao gồm một chuỗi các khung được chia thành m khe. Mỗi Slave
chọn ngẫu nhiên một trong các khe của khung để truyền gói dữ liệu
của nó.
 Các thiết bị phụ không đánh giá trạng thái kênh. Cho nên 1 khe có 1
trong 3 trạng thái: thành công (chỉ 1 tk truyền), trống, xung đột (>2 tk
truyền)
 Điều phối viên truyền gói phản hồi (feedback packet FBP) sau mỗi
khung để thông báo trạng thái của từng khe. Thành công thì thôi,
xung đột thì truyền lại.
b. Thuật toán cây tranh chấp (CTA)
Chia các slaves thành các nhóm phụ để giảm va chạm trên mỗi khung (nhìn
hình vẽ mới hiểu được – hình 2). Sau mỗi khung, sẽ có FBP được truyền,
nếu có khe tranh chấp, các slave trong khe đó được đưa vào khung mới để
truy cập lại, do đó có xung đột trong k khe thì k khung mới được tạo ra.
c. Hàng đợi phân tán (Distributed Queuing)
Ý tưởng: khung của DQ được chia làm 2 phần: m khe tranh chấp, 1 khe
truyền dữ liệu. Sau mỗi khùng, FBP sẽ được truyền để thông báo trạng thái
của các slave (thành công thì vào hàng đợi DTQ, tranh chấp thì vào hàng đợi
CRQ).
Có ví dụ cụ thể, xem hình sẽ dễ hiểu hơn.

Vì DTQ, CRQ giảm dần theo từng khung hình, nên các slave chỉ cần nhận
FBP trong các khung nơi chúng đang truyền là được, vì vậy chúng có thể ngủ
ở những khung mà chúng không phải truyền dữ liệu, từ đó tiết kiệm được
năng lượng.

4. Đánh giá hiệu suất

a. Kịch bản, thông số
 Đánh giá hiệu suất năng lượng của DQ, sử dụng các tham số hệ
thống dựa trên Chuẩn IEEE 802.15.4 (quy định tại Bảng I) nhằm xác
định các tiêu chí để tối đa hóa hiệu quả năng lượng.
 so sánh hiệu suất năng lượng của DQ với FSA và CTA trong mạng
M2M dày đặc
b. Khe tranh chấp để giảm mức tiêu thụ năng lượng (chắc là giải pháp)
Năng lượng trung bình tiêu thụ của bộ điều phối và slave được biểu diễn
bằng hàm số của m khe và xem xét với trường hợp số slave n = 50 và n =
100.
 Từ đồ thị ta thấy được các vị trí mà năng lượng min.
 Đối với hình 5, năng lượng của bộ điều phối: DQ và CTA min tại m =
3, FSA min với m trong khoảng từ (n/2, n).
 Hình 6, năng lượng của slave: CTA, DQ min khi m = 10; FSA min khi
m gần tới n.
c. Tiêu thụ năng lượng trong mạng M2M dày đặc
Đánh giá năng lượng tiêu thụ bởi bộ điều phối và slave dưới dạng hàm của n
slave (500 tới 1000 slave). m được sử dụng ở giá trị tối ưu (=10 với CTA và
DQ, =n với FSA)
Thu được: năng lượng tiêu thụ của bộ điều phối và slave trong DQ thấp hơn
nhiều so với CTA và FSA.
d. Wi-Fi công suất thấp so với các thiết bị IEEE 802.15.4 sử dụng DQ
Xem xét m = 10 và tải trọng dữ liệu là 1024 byte. Năng lượng tiêu thụ của
slave ở hai công nghệ rất giống nhau.

Mức tiêu thụ điện năng cao hơn của Wi-Fi công suất thấp được bù đắp bằng
thời gian truyền ngắn hơn do tốc độ dữ liệu cao hơn. Tuy nhiên, Wi-Fi công
suất thấp hoạt động tốt hơn IEEE 802.15.4, giúp giảm 90% năng lượng tiêu
thụ của điều phối viên.
5. Kết luận
 Số lượng khe cắm tối ưu giúp giảm thiểu mức tiêu thụ năng lượng
trong DQ và CTA bất kể số lượng thiết bị. Ngược lại, trong FSA nó
cần được tối ưu hóa theo số lượng thiết bị.
 Trong mọi trường hợp, DQ giảm mức tiêu thụ năng lượng hơn 50%
so với CTA và FSA, do đó trở thành ứng cử viên sáng giá cho mạng
M2M dày đặc.
 So sánh hiệu suất năng lượng của DQ khi sử dụng Wi-Fi công suất
thấp và các thiết bị thương mại IEEE 802.15.4. Kết quả cho thấy Wi-Fi
công suất thấp hoạt động tốt hơn IEEE 802.15.4 trong các trường
hợp được thử nghiệm.

sao báo
mà lại có lỗi ri nhờ 5 -> 15 mới đúng