Distributed Control Function (DCF).

Một phần của tài liệu đồ án kỹ thuật viễn thông BẢO CHẤT LƯỢNG DỊCH VỤ CHO VoIP TRONG WLAN (Trang 38)

Việc truy cập đường truyền chủ yếu dựng với CSMA/CA là Distributed Control Function (DCF) . DCF diễn tả tiến trình 1 client truyền các frame trên mạng vỏ cố gắng để không xảy ra xung đột . Có 1 số tùy chọn khác định nghĩa trong điều khiển truy cập đường truyền MAC , chúng ta sẽ tìm hiểu chúng ở phần sau , tuy nhiên DCF là chế độ hoạt động điển hình.

Các định nghĩa cơ bản trong DCF .

Để hiểu DCF hoạt động như thế nào , trước tiên chúng ta cần tìm hiểu qua 1 vài khái niệm:

Inter-Frame Spacing : đây là khoảng thời gian giữa những lần truyền frame . Thậm chí khi kênh truyền đang rỗi , bất kỳ client nào muốn gửi frame cũng phải đợi 1 trong những khoảng thời gian dưới đây trước khi bắt đầu truyền dẫn . Các khoảng thời gian này thay đổi tùy thuộc vào giao diện liên kết vô tuyến và loại frame nào được gửi đi . Có 3 khoảng thời gian Inter-Frame Spacing được định nghĩa trong DCF:

oShort Inter-Frame Spacing (SIFS) : là 1 khoảng thời gian cố định (10 µsec) mà 1 client phải đợi trước khi gửi thông điệp báo nhận ACK , clear-to-send (CTS) hoặc

các frame tiếp theo của 1 frame đã bị phân đoạn . Đây là inter-frame spacing ngắn nhất nên những thông điệp này có độ ưu tiên cao nhất để truy cập kênh truyền.

oDCF Inter-Frame Spacing (DIFS) : đây là khoảng thời gian 1 client phải đợi trước khi gửi frame dữ liệu , quản lý hoặc điều khiển , khoảng thời gian DIFS thì bằng 1 SIFS (10 µsec) cộng với 3 khe thời gian . Khe thời gian trong chuẩn 802.11b là 20 µsec , còn khe thời gian của chuẩn 802.11a và g là 9 µsec . Vậy khoảng thời gian tổng cộng là vào khoảng 70 µsec hoặc 37 µsec . Chú ý trong mạng hỗn hợp có cả thiết bị chạy chuẩn b và chuẩn g thì khe thời gian dài nhất phải được sử dụng . Nếu kênh truyền đang rỗi thì frame sẽ được gửi đi sau khoảng thời gian là 1 DIFS . Tuy nhiên nếu kênh truyền đang bận khi 1 client đang cố gắng gửi frame thì nó sẽ thiết lập bộ đếm back-off tức là bộ đếm chờ để truyền với 1 số khe thời gian ngẫu nhiên và bắt đầu giảm nó sau khoảng thời gian 1 DIFS sau khi kênh truyền trở về rỗi . Tiêu chuẩn của bộ đếm back- off counter cũng được diễn tả theo dải giá trị (từ CWmin đến CWmax).

Bảng 2.4: Dải giá trị từ CWmin đến Cwmax tùy theo chuẩn sử dụng.

oPoint Control Function Inter-Frame Spacing (PIFS) : Point Control Function là 1 cơ chế hiếm khi được sử dụng , dựng để hỗ trợ những lưu lượng của các ứng dụng nhạy cảm về mặt thời gian như video và voice . Trong PCF , access point nắm quyền điều khiển 1 cách định kỳ đối với kênh truyền . Khoảng thời gian này được gọi là khoảng thời gian không tranh chấp Contention-Free (CF) . Khoảng thời gian dựng để gửi các thông điệp điều khiển là PIFS . Khoảng thời gian PIFS thì bằng 1 PIFS cộng với 1 khe thới gian , nên nó dài hơn SIFS nhưng lại ngắn hơn DIFS . Trong suốt khoảng thời gian CF , access point thăm dò mỗi trạm với lưu lượng nhạy cảm về mặt thời gian , khi kết thúc khoảng thời gian CF mạng sẽ trở về chế độ hoạt động tranh chấp DCF.

Khoảng thời gian Cách tính 802.11b hay b/g

(µs)

802.11a hay g (µs)

SIFS 10 µsec 10 10

PIFS SIFS + 1 Time Slot 30 30

DIFS SIFS + 3 Time Slot 70 37

Bảng 2.5: Các khoảng thời gian của 802.11 Inter-Frame Spacing.

Contention Window (CW)/Back-off Window : đây là phần tử ngẫu nhiên hóa trong DIFS . Contention Window đóng vai trị trong 2 trường hợp:

o Khi 1 client cố gắng gửi frame nhưng không thành công.

Trong những trường hợp này , client muốn gửi hoặc gửi lại frame sẽ thiết lập khoảng thời gian chờ để truyền của bộ đếm back-off với 1 số khe thời gian ngẫu nhiên nằm giữa CWmin và CWmax . Sau đó client sẽ đợi khoảng thời gian 1 DIFS (1 SIFS cộng với 2 khe thời gian) sau khi kênh truyền trở về rỗi và bắt đầu giảm bộ đếm back- off của mình . Khi bộ đếm back-off kết thúc , trạm sẽ gửi frame ngay lập tức . Giá trị CW luôn luôn theo qui tắc nhân 2 cộng 1 (tức là có giá trị như sau : 31 , 63 , 127 , 255 , 511 và 1023) . Bộ đếm sẽ tăng lên con số lớn hơn tiếp theo với mỗi lần truy cập đường truyền không thành công của client.

Nếu kênh truyền được kích hoạt trong suốt thời gian back-off (tức là có 1 trạm bắt đầu sử dụng kênh truyền để truyền dẫn) thì tất cả các bộ đếm chờ để truyền back- off sẽ được đóng băng và bắt đầu chạy lại sau khoảng thời gian 1 DIFS sau khi kênh truyền trở về rỗi. Nếu như bộ đếm back-off không được đóng băng và vẫn còn chạy trong suốt 1 phiên truyền dẫn nào đó thì xung đột có thể xảy ra.

Network Allocation Vector (NAV) : NAV là vector cấp phát mạng hay bộ định thời trong mỗi trạm và được sử dụng cho virtual carrier sense . NAV được thiết lập nhờ giá trị duration trong mỗi frame header , nó làm cho trạm xem kênh truyền như là đang bận trong khoảng thời gian này dù cho nó cũng không cảm nhận được việc truyền dẫn . Trong PCF , AP dành sẵn 1 khoảng thời gian cho kênh truyền bằng cách gửi frame clear-to-send (CTS) để thiết lập giá trị NAV trong tất cả các trạm trên mạng . Khi giá trị NAV được thiết lập , trạm sẽ không cố gắng khởi tạo bất kỳ truyền dẫn nào trong khoảng thời gian đó và nếu có bất kỳ trạm nào đang chạy bộ đếm back-off thì bộ đếm này sẽ bị đóng băng.

Hoạt động của DCF .

Trong mạng 802.11 WLAN , 1 kênh tần số vô tuyến được sử dụng cho cả 2 hướng : hướng đi vào (tới AP) và hướng đi ra (từ AP) . Thậm chí mặc dù AP đóng vai trị là trạm điều khiển trong mô hình mạng BSS hoặc ESS WLAN thì nó vẫn tranh chấp quyền truy cập kênh truyền trên cùng cơ sở như tất cả các trạm khác

Hoạt động của DCF khi kênh truyền đang rỗi

Khi kênh truyền đang rỗi , quá trình làm việc cơ bản như sau :

[1] Trạm muốn gửi frame trước tiên phải xác định kênh truyền có rỗi hay không trước khi truyền . Nó sử dụng 2 cách sau để xác định việc này:

o Carrier Sense : cảm nhận hoạt động truyền dẫn trên kênh truyền vô tuyến.

o Virtual Carrier Sense : trạm sẽ tham khảo vector cấp phát mạng NAV của nó . Nếu NAV được thiết lập đến giá trị lớn hơn 0 thì trạm sẽ cho là kênh truyền đang bận trong khoảng thời gian đó

[2] Nếu trạm cảm nhận là không có hoạt động truyền dẫn nào trên kênh truyền và giá trị NAV là zero thì nó sẽ cho là kênh truyền đang rỗi.

[3] Một khi trạm đã xác định được kênh truyền là đang rỗi , nó phải đợi ít nhất 1 khoảng thời gian là 1 DIFS rồi sau đó mới truyền . Nếu 2 trạm cảm nhận kênh truyền chính xác tại cùng 1 thời điểm , chúng sẽ xung đột với nhau nhưng việc này hiếm khi xảy ra.

[4] Trạm nhận (receiving station) sẽ copy frame vào bộ nhớ đệm buffer và tính toán lại frame check sequence (32 bit CRC) để kiểm tra frame vừa nhận có lỗi hay không . Nếu frame không có lỗi , trạm nhận sẽ truyền gửi trở lại thông điệp báo nhận ACK (14 byte) sau 1 khoảng thời gian SIFS . Nếu phát hiện ra frame vừa nhận có lỗi trong frame (frame không đầy đủ hoặc FCS không chính xác) thì đơn giản là nó sẽ loại bỏ frame và không gửi thông điệp trả lời kiểu như NAK message. (adsbygoogle = window.adsbygoogle || []).push({});

[5] Nếu trạm gửi không nhận được thông điệp báo nhận ACK thì nó cho là có trục trặc hoặc xung đột xảy ra trên đường truyền . Do trạm không thể cảm nhận hay nghe đường truyền trong khi nó đang gửi frame nên nó phải xem là có xung đột hoặc trục trặc trong truyền dẫn xảy ra . Trong trường hợp đó trạm gửi sẽ thiết lập lại bộ đếm back-off của nó hay khởi động lại bộ đếm back-off sau khoảng thời gian 1 DIFS , rồi truyền lại ngay lập tức sau khi bộ đếm kết thúc . Nếu có bất kỳ trạm nào đó bắt đầu truyền trong khi bộ đếm đang chạy thì bộ đếm sẽ bị đóng băng và khởi chạy lại sau khoảng thời gian 1 DIFS sau khi kênh truyền trở về rỗi.

Thiết kế của hệ thống định thời (timer system) đảm bảo rằng 1 phiên truyền dẫn nào đó sẽ có độ ưu tiên hơn so với những phiên khác . Bất kỳ trạm nào muốn gửi frame cũng phải đợi ít nhất khoảng thời gian 1 DIFS , còn trạm muốn gửi thông điệp báo nhận ACK thì phải đợi khoảng thời gian là 1 SIFS . Cho nên nếu có 1 trạm đang đợi gửi frame và 1 trạm khác đang đợi gửi thông điệp báo nhận ACK thì thông điệp ACK sẽ luôn luôn được gửi đi trước.

Hoạt động của DCF khi kênh truyền đang bận.

Trong phần trước chúng ta đã tìm hiểu frame được gửi đi như thế nào khi 1 trạm tìm thấy kênh truyền đang rỗi . Khi kênh truyền đang bận , trạm muốn gửi dữ liệu sẽ trải qua thêm vài bước để tránh xảy ra xung đột . Quá trình làm việc như sau :

[1] Nếu kênh truyền đang bận , trạm muốn gửi dữ liệu sẽ thiết lập bộ đếm back-off với số ngẫu nhiên giữa 0 và CWmin để chỉ ra số khe thời gian cố định mà trạm sẽ phải đợi trước khi cố gắng truyền . Bộ đếm sẽ chưa bắt đầu chạy cho đến khi đợi hết khoảng thời gian 1 DIFS sau khi kênh truyền rỗi . Việc sử dụng các khoảng thời gian có độ dài khác nhau để truy cập kênh truyền sau 1 phiên truyền dẫn là 1 trong những cơ chế chính để tránh xung đột.

[2] Nếu trạm khác bắt đầu gửi frame trong khi bộ đếm back-off đang chạy thì bộ đếm sẽ dừng lại hay bị đóng băng trong khi việc gửi dữ liệu đang được tiến hành và khởi động lại 1 lần nữa sau 1 DIFS sau khi kênh truyền trở về rỗi . Trạm luôn luôn đợi

khoảng thời gian 1 DIFS trước khi khởi động lại bộ đếm để thông điệp báo nhận ACK được gửi đi.

[3] Khi bộ đếm kết thúc (đếm ngược trở về 0) , trạm lập tức gửi dữ liệu và sau đó đợi khoảng thời gian 1 SIFS cho thông điệp báo nhận ACK được gửi trở lại.

[4] Nếu không nhận được thông điệp báo nhận ACK , trạm sẽ cho là có trục trặc trong truyền dẫn hoặc có xung đột xảy ra . Sau đó nó sẽ thiết lập lại bộ đếm back-off với việc gia tăng đến số tiếp theo lớn hơn trong khoảng giá trị CWmin  CWmax (31 , 63 , 127 , 255 , 511 và 1023) và lập lại tiến trình trên . Bộ đếm back-off được thiết lập lại đến con số lớn hơn tiếp theo sau mỗi lần truyền dẫn thất bại.

Hình 2.20 Hoạt động của DCF khi kênh truyền đang bận.

2.1.6.2 RTS/CTS (request-to-send/clear-to-send).

Quá trình trì hoãn truyền dẫn của 1 trạm khi có trạm khác đang truyền được cho là trạm đó không thể nghe tất cả các trạm trên mạng wireless LAN của nó cho nên phải trì hoãn truyền dẫn khi kênh truyền đang bận . Tuy nhiên trạm không có khả năng cảm nhận tất cả truyền dẫn . Bằng cách thiết kế access point phải có khả năng nghe tất cả các trạm , nhưng 2 trạm thì có thể không nghe được lẫn nhau vì lý do khoảng cách giữa chúng hoặc do chướng ngại vật trên đường truyền

Hình 2.21 Vấn đề nút ẩn.

Tình huống mà 2 trạm đều có thể nghe được access point nhưng không thể nghe được lẫn nhau được gọi là vấn đề nút ẩn . Rắc rối với vấn đề nút ẩn là ở chỗ nó sẽ gia tăng khả năng xảy ra xung đột khi trạm này gửi dữ liệu trong khi trạm kia cũng đang

sử dụng kênh truyền để gửi dữ liệu . Để giải quyết vấn đề nút ẩn , người ta đưa ra cơ chế RTS/CTS (request-to-send/clear-to-send).

Hoạt động của RTS/CTS .

[1]Trạm muốn gửi dữ liệu trong chế độ RTS/CTS trước tiên phải gửi frame RTS (20 byte) sau khi đợi khoảng thời gian 1 DIFS sau khi kênh truyền trở về rỗi . Nếu kênh truyền đang bận , trạm sẽ gửi frame RTS theo qui tắc hoạt động của kênh truyền đang bận.

RTS là 1 thông điệp điều khiển mà gồm có địa chỉ của người gửi , địa chỉ của người nhận và giá trị duration là khoảng thởi gian mà nó có để gửi thông điệp này . Do trạm hoạt động trong chế độ RTS/CTS nên không thể nghe tất cả các truyền dẫn , thông điệp RTS có thể xung đột với các truyền dẫn khác nên trong trường hợp đó trạm sử dụng tiến trình back-off trước khi cố gắng gửi lại thông điệp RTS.

[2]Sau khoảng thời gian 1 SIFS , trạm vừa nhận thông điệp RTS sẽ trả về frame điều khiển CTS (16 byte) bao gồm địa chỉ trạm nhận và giá trị duration như hình vẽ dưới đây . Do thông điệp CTS được gửi đi sau khoảng thời gian 1 SIFS nên nó sẽ có độ ưu tiên hơn bất kỳ truyền dẫn mới nào.

Hình 2.22: Định dạng frame RTS/CTS

[3] Cả 2 thông điệp điều khiển RTS và CTS đều chứa giá trị duration . Do access point luôn luôn liên quan trong hoạt động RTS/CTS nên nó sẽ biết được lúc nào kênh truyền sẽ bận . Tất cả các trạm sử dụng giá trị duration để thiết lập NAV của chúng và trong suốt khoảng thời gian đó chúng sẽ không truy cập kênh truyền . Ngoài ra bất kỳ bộ đếm back-off nào đang chạy sẽ bị đóng băng và khởi chạy lại sau khoảng thời gian 1 DIFS sau khi NAV trở về zero tức là kênh truyền trở về rỗi.

[4] Trạm ban đầu gửi thông điệp RTS sau khi nhận được thông điệp CTS sẽ gửi trở lại thông điệp báo nhận ACK.

Một phần của tài liệu đồ án kỹ thuật viễn thông BẢO CHẤT LƯỢNG DỊCH VỤ CHO VoIP TRONG WLAN (Trang 38)