Mục đích thiết kế

Một phần của tài liệu Mã hóa mạng không dây sử dụng giao thức ALOHA (Trang 43)

MC LC

3.2.1. Mục đích thiết kế

Để xây dựng một hệ thống có tính thực tế, chúng ta phải quyết định một số tiêu chí. a) Tính trong suốt: COPE không mong muốn có bất cứ thay đổi nào với các lớp ở trên và ở dưới nó. Mục đích thiết kế cơ bản là có thể thêm COPE vào bất cứ mạng nào. Điều này nghĩa là, dù sẽ có lợi khi điều chỉnh lớp định tuyến hoặc lớp vật lý, COPE lựa chọn không làm vậy vì tính mô đun và sự đơn giản trong thiết kế.

b) Độ trễ: Như sẽ thấy ở sau, COPE có thể tăng thông lượng bởi làm trễ gói tin trong hàng đợi. Nhưng để tránh những hậu quả không mong muốn với những ứng dụng cần thời gian nhanh, COPE không bao giờ có ý định làm trễ gói tin.

c) Truyền tin cậy: COPE cố gắng bảo đảm mức độ tin cậy tới mọi gói tin được mã hóa cũng như các gói tin khi được truyền riêng rẽ.

Các mục dưới đây sẽ xem những mục đích thiết kế này ảnh hưởng như thế nào tới thiết kế thực tế của COPE.

3.2.2. ô đun ã hóa/ Giải mã

Mô đun mã hóa/ giải mã xử lý công việc nhận biết cơ hội để mã hóa nhiều gói tin với nhau và gửi chúng trong cùng một lần truyền. Nó cũng thực hiện nhiệm vụ giải mã ở bên nhận. Mô đun giúp duy trì hàng đợi đầu ra FIFO, nơi các gói tin không mã hóa và các gói vừa giải mã được thêm vào. Khi lớp MAC thông báo một cơ hội để gửi dữ liệu, nếu có thể, nó lựa chọn những gói tin từ lối ra của hàng đợi để mã hóa và truyền đi. Câu hỏi đặt ra là: Những gói tin nào sẽ được mã hóa với nhau từ đầu ra hàng đợi? Nhớ lại mục 3.1 rằng để mã hóa n gói tin với nhau, một nút phải bảo đảm rằng n hop kế tiếp phải có đủ n-1 gói tin còn lại. Nhưng sự lựa chọn gói tin mã hóa phụ thuộc vào 3 yếu tố: mục đích thiết kế, trạng thái lân cận và kích thước gói tin.

3.2.2.1. ơ hội mã hóa

Một trong những mục đích thiết kế là không làm trễ gói tin cần truyền. Do đó, với COPE, bất cứ khi nào kênh vô tuyến sẵn sàng, nút sẽ lấy gói tin tại đỉnh hàng đợi, kiểm tra các gói khác trong hàng đợi có thể mã hóa với gói này không, XOR những gói này với nhau, và quảng bá gói tin kết quả. Nếu không có cơ hội mã hóa, nút này không làm trễ gói tin để chờ sự xuất hiện của các gói tin khác có thể được mã hóa cùng với gói tin tại đỉnh hàng đợi. Do đó, COPE cho các nút cơ hội để truyền thêm thông tin trong mỗi lần truyền mỗi khi có thể nhưng sẽ không đợi các gói tin có thể mã hóa thêm tới.

3.2.2.2. ã hóa cực đại xác suất giải mã

COPE cố gắng đảm bảo mỗi lân cận có xác suất giải mã được là lớn nhất. Cho rằng một nút đã mã hóa n gói tin. Gọi xác suất hop kế tiếp nhận được gói iPi thì xác suất PD

mà nút đó có thể giải mã được bằng xác suất mà nó nhận được tất cả n-1 gói tin:

PD = P1 x P2 x …x Pn-1

Giả sử ta đã XOR n-1 gói tin, và đang xem xét để XOR gói tin thứ n với chúng. Thuật toán mã hóa sẽ kiểm tra mỗi n hop kế tiếp xem xác suất mã hóa PD sau khi XOR gói tin thứ n sẽ vẫn lớn hơn một ngưỡng G (giá trị mặc định G = 0,8). Nếu điều kiện trên đạt được, mỗi hop kế tiếp có thể giải mã được với xác suất thấp nhất là G. Cuối cùng, chúng ta lưu ý đối với sự công bằng, chúng ta lặp lại trên tập hợp của các nút lân cận theo một hoán vị ngẫu nhiên.

Do đó, với mỗi gói trong hàng đợi, ta cần ước lượng xác suất mà các lân cận đã nhận được gói tin. Mô đun mã hóa/ giải mã tra cứu mô đun học để nhận được xác suất này. Giá trị xác suất này có thể tính từ hai nguồn:

a) Thông báo nhận: Khi mô đun học đã có thông báo nhận từ một lân cận về một gói nào đó, hoặc nếu là hop trước của gói tin thì mô đun dự đoán có thể chắc chắn rằng lân cận đã nhận được gói tin. Vì vậy, trong trường hợp này giá trị xác suất là một.

b) Dự đoán: Khi mô đun học không có thông tin xác định, nó sẽ phải dự đoán. Xác suất truyền được tính bởi giao thức định tuyến. Nó ước lượng xác suất lân cận có gói tin như xác suất truyền giữa hop kế trước của gói tin và lân cận. Nó thông báo xác suất truyền này tới mô đun mã hóa, sử dụng để bảo đảm rằng các gói tin mã hóa là có thể giải mã được bởi tất cả các hop tiếp theo của chúng với xác suất cao.

Một kết quả thú vị của điều kiện ở trên là COPE sẽ không bao giờ mã hóa cùng nhau hai hoặc nhiều hơn các gói tin tới cùng hop kế tiếp, vì hop kế tiếp sẽ không thể giải mã chúng. Do đó, trong khi mã hóa, chúng ta chỉ cần xem xét các gói tin tới những hop khác nhau.

3.2.2.3. ã hóa các gói tin có cùng độ dài

COPE ưu tiên XOR các gói tin có cùng độ dài, bởi vì XOR những gói tin nhỏ với gói lớn hơn làm giảm băng thông tiết kiệm được. Những nghiên cứu thực nghiệm chỉ ra rằng phân bố kích thước gói tin trên Internet có hai đỉnh là 40 byte tương ứng với gói ATM và 1500 byte tương ứng với gói Ethernet [27]. Do đó, ta có thể giới hạn để tìm các gói tin với kích thước được phân biệt giữa gói nhỏ và lớn. Ta có thể vẫn phải XOR các gói tin với độ dài khác nhau. Trong trường hợp này, gói tin ngắn hơn sẽ được thêm vào các bit 0. Nút nhận có thể loại bỏ phần thêm vào bởi kiểm tra trường kích thước file trong phần header IP của gói tin gốc. Do đó, COPE duy trì hai hàng đợi ảo với mỗi nút, một cho gói tin nhỏ và một cho gói tin lớn (Mặc định sử dụng ngưỡng 100 byte). Khi

một gói mới được thêm vào hàng đợi, một mục cũng được thêm vào hàng đợi ảo thích hợp dựa trên kích thước và hop kế tiếp của gói tin.

3.2.2.4. Cấu trúc dữ liệu và thuật toán mã hóa

Mỗi nút duy trì cấu trúc dữ liệu như sau:

 Mỗi nút có một hàng đợi FIFO của gói tin cần truyền.

 Với mỗi lân cận, nút duy trì hai hàng đợi ảo, một cho gói tin nhỏ (nhỏ hơn 100 byte) và một cho gói tin lớn. Hàng đợi ảo cho một lân cận A chứa con trỏ tới những gói trong hàng đợi mà hop kế tiếp là A.

 Thêm vào đó, nút giữ một bảng hash, thông tin gói, chứa ID của gói. Với mỗi gói trong hàng đợi, bảng cho biết xác suất của mỗi hàng xóm có gói tin.

Bất cứ khi nào MAC báo hiệu một cơ hội gửi gói tin, nút thực hiện thủ tục minh họa như dưới đây:

Pick packet p at the head of the output queue. Natives = {p}

Nexthops = {nexthop(p)}

ifsize(p) > 100 bytes then

which queue = 1

else

which queue = 0

end if

for Neighbor i = 1 to M do

Pick packet pi, the head of virtual queue Q(i, which_ queue)

ifn ∈ Nexthops ∪{i}, Pr[n can decode ppi] ≥ G then

p = ppi Natives = Natives ∪{pi} Nexthops = Nexthops ∪{i} end if end for which_queue = !which_queue for Neighbor i = 1 to Mdo

Pick packet pi, the head of virtual queue Q(i, which_ queue)

ifn ∈ Nexthops ∪{i}, Pr[n can decode ppi] ≥ G then

p = ppi

Nexthops = Nexthops ∪{i}

end if end for

return p

Việc tìm gói tin thích hợp để mã hóa hiệu quả là nhờ vào hàng đợi ảo. Khi quyết định mã hóa, COPE lấy gói tin ở đỉnh hàng đợi FIFO và xác định nó là gói nhỏ hay lớn. Tùy vào kích thước gói, nó tìm ở hàng hàng đợi ảo tương ứng. Ví dụ, nếu gói tin là gói nhỏ, COPE tìm trong hàng đợi ảo của các gói nhỏ. COPE chỉ tìm tại đỉnh của hàng đợi ảo để hạn chế sắp xếp lại các gói tin. Sau khi tìm kiếm hàng đợi ảo ở một kích thước nào đó, thuật toán sẽ chuyển sang tìm hàng đợi ảo cho các gói kích thước khác. Do đó để tìm gói phù hợp cho mã hóa, trong trường hợp xấu nhất COPE phải tìm 2M gói với M là số lân cận của một nút.

Ở đây đưa ra một khái niệm khác là sắp xếp lại gói. Ta sẽ chỉ sắp xếp lại các gói trong cùng một luồng bởi vì TCP xem nó như là lỗi tắc nghẽn tín hiệu. Do vậy, phải luôn luôn xem xét các gói theo trật tự của chúng trong hàng đợi. Tuy nhiên vẫn có thể sắp xếp lại gói để mã hóa các gói tin có cùng kích thước. Trên thực tế, cần hạn chế việc sắp xếp lại gói tin bởi vì phần lớn các gói trong luồng TCP là đủ lớn để được xếp trong hàng đợi gói lớn và do đó sẽ được xem xét theo thứ tự. Tuy nhiên trong mục 3.2.3 ta sẽ thấy rằng sắp xếp lại có thể thực hiện bởi một vài lý do khác, đặc biệt là yêu cầu truyền lại gói tin bị mất do dự đoán sai nên nút lân cận không giải mã được. Do vậy, ta sẽ giải quyết bất kỳ sự sắp xếp lại trật tự gói có thể xảy ra tại bất cứ đâu trong mạng tại phía nhận. COPE có một mô đun xếp các gói TCP theo thứ tự trước khi chuyển chúng tới lớp giao vận sẽ trình bày trong mục 3.2.3.

3.2.2.5. Thuật toán giải mã

Giải mã gói tin tương đối đơn giản. Khi một nút nhận gói tin mã hóa gồm n gói tin gốc, nút sẽ xem xét ID của các gói tin gốc từng cái một. Trong đó, có n-1 gói tin khác biệt với gói còn lại được gửi cho nó. Nó sẽ cố để thu được n-1 gói từ mô đun lắng nghe và XOR n-1 gói này với gói tin mã hóa đã nhận để thu được gói tin gốc có ý nghĩa với nó. Nếu mô đun lắng nghe không có đủ n-1 gói tin, gói tin mã hóa sẽ bị loại bỏ. Chú ý là gói tin không giải mã được lúc này nhưng có thể giải mã được về sau khi có đủ các gói tin cần thiết nhưng để đơn giản COPE lựa chọn xóa bỏ gói tin.

3.2.3. Độ tin cậy

COPE cố gắng cung cấp mức độ tin cậy như nhau tới cả gói tin mã hóa và không mã hóa. Trước hết ta thảo luận cách hệ thống vô tuyến 802.11 cung cấp truyền tin cậy lớp liên kết và sau đó chỉ ra tại sao nó vẫn chưa đủ với COPE. Chúng ta cũng giải thích giải pháp đưa ra và thảo luận về một số vấn đề khác.

3.2.3.1. Độ tin cậy của 802.11

Lớp MAC mạng 802.11 có hai mô đun: unicast và broadcast. Trong mode unicast của mạng 802.11, các gói tin được xác nhận bởi ACK ngay lập tức bởi hop kế tiếp nhận được gói tin. Các giao thức mạng 802.11 bảo đảm độ tin cậy bằng cách truyền lại gói tin tại lớp MAC với một số lần nhất định cho tới khi nhận được đồng bộ ACK. Khi chưa nhận được ACK nút gửi sẽ xem như tín hiệu xung đột và tạm ngừng trong một khoảng thời gian, cho phép nhiều nút cùng chia sẻ đường truyền.

Ngược lại, với mode 802.11 broadcast sẽ không có truyền tin cậy và tạm ngừng (back-off). Một gói tin broadcast có nhiều nút nhận và sẽ không phân biệt được ACK của nút nào. Vì không có ACK, mô đun broadcast không truyền lại và kết quả là độ tin cậy rất thấp. Hơn nữa, nguồn broadcast không thể phát hiện xung đột và do đó không tạm ngưng truyền. Nếu nhiều nút chia sẻ kênh quảng bá, và mỗi nút tiếp tục truyền với tốc độ cao, kết quả là thông lượng sẽ rất thấp do tỉ lệ xung đột cao.

3.2.3.2. Đặt vấn đề

COPE quảng bá các gói tin mã hóa tới các hop kế tiếp. Nhưng như đã thảo luận, mô đun broadcast của 802.11 không cung cấp truyền tin cậy và tạm ngưng truyền. Lý tưởng nhất là sẽ thiết kế một MAC mới phù hợp cho truyền quảng bá, nhưng hiện nay, một số tác giả [4] đang quan tâm đến việc thực hiện mô hình kiến trúc COPE có thể được áp dụng trong tương lai gần cho các mạng dựa trên giao thức 802.11.

Giải pháp khả quan là sử dụng mô đun unicast 802.11, cung cấp đồng bộ ACK, truyền lại và tạm ngưng. Điều này là đủ cho các gói tin không mã hóa, còn một gói tin mã hóa sẽ được truyền tin cậy tới hai hoặc nhiều hop. Mô đun unicast 802.11 có thể bảo đảm truyền tin cậy tới chỉ một trong các nút đó. Vì vậy cần một kỹ thuật mới để bảo đảm truyền tin cậy.

COPE đã đề xuất giải quyết vấn đề này nhờ hai kỹ thuật: Quảng bá giả (Pseudo-broadcast) và đồng bộ ACK và truyền lại (Asynchronous ACKs and Retransmissions). Cả hai kỹ thuật này được trình bày ở mục dưới đây.

3.2.3.3. Giải pháp

Quảng bá giả: dựa trên mô đun unicast 802.11 cho kỹ thuật truyền tin cậy và truyền lại. Quảng bá giả truyền gói tin unicast cần cho broadcast. Trường đích trong lớp liên kết dữ liệu là địa chỉ MAC của một trong những nút nhận. Tiêu đề XOR được thêm vào sau tiêu đề lớp liên kết, liệt kê tất cả các hop kế tiếp của gói tin. Vì tất cả các nút sẽ ở trong hình thức pha tạp chúng có thể nhận được các gói tin không gửi cho chúng. Khi một nút nhận một gói tin với địa chỉ MAC khác với của nó, nó kiểm tra tiêu đề XOR xem có là hop kế tiếp không. Nếu đúng, nó tiếp tục xử lý gói tin, còn không nó lưu gói tin trong bộ đệm. Vì tất cả các gói được gửi sử dụng unicast 802.11, MAC có thể dò xung đột và thuộc tính ngưng truyền trong một khoảng thời gian.

Quảng bá giả cũng tin cậy hơn quảng bá đơn thuần. Gói tin được truyền lại nhiều lần cho tới khi nút nhận có MAC phù hợp nhận được gói tin và gửi lại ACK hoặc số lần truyền lại vượt quá một giới hạn nào đó. Việc truyền lại có một hiệu quả mong đợi là nút có nhiều cơ hội hơn để nhận được các gói tin trong khi lắng nghe đường truyền. Tuy nhiên, quảng bá giả không giải quyết được triệt để vấn đề truyền tin cậy, ta sẽ thảo luận trong mục tiếp theo.

Đồng bộ A K và truyền lại: Gói tin mã hóa yêu cầu tất cả các hop kế tiếp xác nhận đã nhận được các gói tin gốc do hai lý do. Thứ nhất, gói tin mã hóa gửi tới nhiều hop nhưng phía gửi chỉ nhận đồng bộ ACK lớp MAC từ hop được đặt như đích lớp liên kết của gói. Vẫn có khả năng mất gói tại các hop không nhận đồng bộ ACK. Thứ hai, COPE có thể dự đoán một hop có đủ thông tin để giải mã một gói tin XOR nhưng thực tế nó không giải mã được.

Giải pháp của vấn đề mất gói trong vô tuyến là đánh dấu khi loại bỏ gói bởi tái tạo gói tin đã mất cục bộ nhờ xác nhận và truyền lại [16]. COPE sử dụng phương thức truyền lại cục bộ để xử lý vấn đề này, bên gửi mong muốn hop kế tiếp giải mã được gói tin XOR để thu được gói tin gốc và ACK ngược trở lại. Nếu bất cứ gói tin gốc nào không ACK trong một khoảng thời gian xác định, gói tin được truyền lại, có thể được mã hóa với những gói tin gốc khác.

Chúng ta thực hiện ACK giữa các hop như thế nào? Với các gói tin không mã hóa, ta đơn giản sử dụng đồng bộ ACK theo chuẩn 802.11. Tuy nhiên, việc mở rộng phương pháp đồng bộ ACK với gói tin mã hóa sẽ rất không hiệu quả, vì phần phụ thêm cho việc gửi ACK trong mỗi gói tin với tiêu đề IP và WiFi là khá lớn. Do đó, với COPE các gói tin mã hóa là ACK bất đồng bộ.

Một phần của tài liệu Mã hóa mạng không dây sử dụng giao thức ALOHA (Trang 43)

Tải bản đầy đủ (PDF)

(77 trang)