Việc truyền video streaming trong mạng không dây gặp nhiều khó khăn, bởi vì những ràng buộc của video streaming rất khó ñáp ứng trong ñiều kiện mạng không dây. Tuy chuẩn IEEE 802.11e ñã phần nào khắc phục ñược một số vấn ñề ñó bằng cách cho phép các dịch vụ gán ñộ ưu tiên khác nhau. Tuy nhiên, như thế là chưa ñủ ñể ñảm bảo ñược chất lượng truyền video, bởi vì với việc phân tầng trong video streaming, các tầng khác nhau sẽ có ñộ ưu tiên khác nhau khi truyền.
Trong video streaming tầng cơ sở luôn luôn phải ñược ưu tiên ñầu tiên sau ñó là các tầng mở rộng theo thứ tự tăng dần của chúng. Chuẩn IEEE 802.11e chỉ dừng lại ở mức hỗ trợ chất lượng dịch vụ hướng nhóm dịch vụ. Tức là, mỗi một dịch vụ nhất ñịnh như video streaming chẳng hạn thì chỉ tương ứng với một mức ưu tiên. Dẫn tới việc, các tầng khác nhau trong video streaming vẫn sẽ cùng ñộ ưu tiên, và dĩ nhiên là các gói tin của chúng từ tầng trên gửi xuống sẽ cùng nằm trong một hàng ñợi trong số bốn hàng ñợi ở tầng MAC (tương ứng với 4 AC). Điều này sẽ ñồng nhất các khung dữ liệu của tất cả các tầng trong việc phân tầng của video streaming là như nhau khi truyền.
Vấn ñề nảy sinh khi tình trạng mạng là bận, khi mạng bận các tầng video với các luồng dữ liệu tương ứng lại cùng ñược truyền với ñộ ưu tiên giống nhau, hậu quả là ñộ trễ của dữ liệu từ tác tầng gửi ñi sẽ tương ñương nhau và dĩ nhiên là ñộ trễ này sẽ lớn, ñồng thời thông lượng của tất cả các luồng dữ liệu cũng ñều giảm xuống. Điều này ñi ngược với tinh thần của việc phân tầng trong video streaming, việc phân tầng là giúp cho việc truyền video có thể tương thích với sự thay ñổi tình trạng mạng, nhằm có một hiệu quả truyền tốt nhất trong ñiều kiện có thể. Tức là nếu tình trạng mạng bận thì việc truyền dữ liệu của tầng cơ sở phải ñược ñặt lên hàng ñầu. Và nhất thiết là phải truyền dữ liệu này với ñộ trễ ñủ nhỏ và thông lượng ñảm bảo sao cho vẫn duy trì ñược dịch vụ. Còn với các tầng khác thì có thể truyền một cách cố gắng tối ña.
Sau ñây ta sẽ ñi xét một vài thí nghiệm ñể kiểm chứng xem sự bất nảy sinh khi truyền video streaming trong IEEE 802.11e như ñã nói ở trên.
Môi trường thực nghiệm ở ñây là dựa trên bộ mô phỏng ns2-2.28 (ñã cài thêm bộ hỗ trợ ñể có thể sử dụng ñược chuẩn IEEE 802.11e). Mô hình mô phỏng sẽ gồm 3 máy trạm và một AP. Trong 3 trạm này ta sẽ xét 1 trạm ñể ñánh giá còn hai trạm kia
31
chỉ là hai trạm ñể làm môi trường. Trạm ñược xét là trạm 1, nó sẽ bao gồm ba luồng dữ liệu tương ứng với 3 tầng của dịch vụ video streaming (tầng cơ bản, tầng mở rộng 1 và tầng mở rộng 2). Các luồng này sẽ có tốc ñộ truyền tương ứng là 128kb/s, 256kb/s và 512kb/s. Hai trạm còn lại là trạm 2 và trạm 3 mỗi trạm sẽ bao gồm ba luồng dữ liệu tương ứng với ba ñộ ưu tiên nhận giá trị từ 1 tới 3. Sơ ñồ thí nghiệm như sau :
Hình 3.1. Mô hình thí nghiệm
a. Trường hợp mạng bận
Đầu tiên, ta sẽ ñi xét trường hợp mạng bận. Để mạng bận thì tổng số tốc ñộ truyền phải lớn hơn băng thông cực ñại có thể của kênh truyền (2mb/s), nên ta sẽ cho các luồng dữ liệu có ñộ ưu tiên 1, 2, 3 trong trạm 2 và 3 nhận tốc ñộ truyền bằng nhau và bằng 400kb/s. Trong trường hợp mạng bận, ta sẽ ñi xem xét hai trường hợp con, là trường hợp ở trạm 1 các luồng video streaming nhận cùng giá trị ñộ ưu tiên là 1 (tuân thủ chuẩn IEEE 802.11e), và trường hợp khác là ta sẽ gán các luồng tương ứng với các ñộ ưu tiên khác nhau. Luồng cơ bản sẽ nhận ñộ ưu tiên là 1 luồng mở rộng 1 sẽ là 2 và luồng mở rộng 2 sẽ là 3. Sau khi chạy chương trình mô phỏng ta có một số nhận xét sau.
Thứ nhất về ñộ trễ. Khi gán ñộ ưu tiên của các luồng như nhau. Độ trễ trung bình của các gói tin trong các luồng này sẽ nhận ñược sẽ xấp xỉ nhau và xấp xỉ giá trị 0.778s. Trong khi ñó, với trường hợp gán ñộ ưu tiên khác nhau, thì ñộ trễ trung bình
32
của hai luồng tuy khá cao, nhưng ñộ trễ trung bình của luồng cơ bản chỉ là 0.04s. Và ta cũng có ñồ thị so sánh ñộ trễ luồng cơ bản của hai thí nghiệm như sau:
Hình 3.2. Biểu ñồ so sánh ñộ trễ luồng cơ bản khi mạng bận trong hai trường hợp gán ñộưu tiên bằng nhau và gán ñộưu tiên khác nhau
Ta có thể thấy ñược rằng trong trường hợp mạng bận nếu giữ nguyên ñộ ưu tiên các luồng bằng nhau và ở mức ưu tiên cao thì các luồng sẽ cùng có giá trị ñộ trễ và giá trị này là khá lớn. Trong khi ñó nếu phân phối các luồng ở mức ưu tiên khác nhau thì ñộ trễ của luồng cơ bản sẽ ñược ñảm bảo ở mức thấp và giá phải trả là ñộ trễ ở các luồng kia phải tăng lên.
Tiếp theo, ta xét ñến thông lượng của các luồng. Với trường hợp ñộ ưu tiên của các luồng như nhau số gói tin nhận ñược trên các luồng theo thứ tự luồng cơ bản, luồng mở rộng 1 và luồng mở rộng 2 là 1110 (packet), 1718(packet), 2876(packet). Và trong trường hợp ñộ ưu tiên khác nhau thì kết quả là 1440(packet), 2228(packet), 601(packet). Mà tổng số gói tin gửi ñi từ trạm 1 tương ứng với các luồng cơ bản, luồng mở rộng 1, luồng mở rộng 2 lần lượt là 1440(packet), 2880(packet) và 5760(packet). Nhìn vào số liệu này ta có: với trường hợp ñộ ưu tiên của các luồng như nhau, số lượng gói tin của từng luồng nhận ñược tính theo phần trăm thứ tự là 77,1%, 59,65% và 49,93% tương ứng với luồng cơ bản, luồng mở rộng 1 và luồng mở rộng 2. Với dịch vụ video streaming ñộ mất mát này là khó có thể chấp nhận ñược. Còn trường hợp ñộ ưu tiên của các luồng khác nhau, tuy luồng mở rộng 2 chỉ gửi tới ñích ñược một số ít gói tin so với số lượng gói tin mà bên nhận gửi. Nhưng bù lại luồng cơ bản
33
nhận ñược 100% số gói tin và luồng mở rộng hai cũng nhận ñược nhiều gói tin hơn (77,36%). Điều này ñủ ñể ñảm bảo duy trì dịch vụ video streaming.
Mặt khác, ta cũng có thông lượng của các luồng ñược biểu thị như sau.
(a)
(b)
Hình 3.3. Thông lượng trong trường hợp mạng bận
34
Dễ dàng thấy rằng, thông lượng của luồng cơ bản trong trường hợp ñộ ưu tiên của các luồng bằng nhau là không ổn ñịnh và chủ yếu là nằm dưới 100kb/s. Còn với trường hợp ñộ ưu tiên khác nhau thì thông lượng luôn duy trì ở mức 128kb/s mặt khác luồng mở rộng 1 trong trường hợp ñộ ưu tiên khác nhau cũng có thông lượng khá cao (nằm từ khoảng một nửa thời gian duy trì mức lớn hơn 200kb/s và ít khi thông lượng tụt xuống dưới ngưỡng 150kb/s).
Thông qua việc xem xét hai thí nghiệm trên ta có thể thấy ñược rằng, với trường hợp mạng bận thì việc gán ñộ ưu tiên của các luồng khác nhau tùy theo mức ñộ quan trọng của nó là tốt hơn so với việc gán chung ñộ ưu tiên cho tất cả các luồng. Điều này thể hiện rõ trên cả hai phương diện ñộ trễ cũng như thông lượng. Vậy trong trường hợp mạng rỗi thì sao? Ta sẽ ñi xem xét thông qua thí nghiệm các sau.
b. Trường hợp mạng rỗi :
Để mạng rỗi thì ngược lại với trường hợp mạng bận tổng số tốc ñộ truyền phải
nhỏ hơn băng thông cực ñại có thể của kênh truyền (2mb/s) nên ta sẽ cho các luồng dữ liệu có ñộ ưu tiên 1, 2, 3 trong trạm 2 và 3 nhận tốc ñộ truyền bằng nhau và bằng 100kb/s. Ta cũng sẽ ñi xem xét hai trường hợp con như ñã xét trong trường hợp mạng bận
Thứ nhất về ñộ trễ. Khi gán ñộ ưu tiên của các luồng như nhau. Độ trễ trung bình của các gói tin trong các luồng này sẽ lần lượt nhận giá trị là 0.00855(s), 0.01233(s) và 0.01554(s). Trong khi ñó với trường hợp gán ñộ ưu tiên khác nhau thì ñộ trễ trung bình của các luồng là 0.00894(s), 0.01383(s) và 0.02191(s). Độ trễ trung bình của các gói tin của luồng cơ bản ở cả hai trường hợp là tương ñương nhau. Nhưng ñộ trễ các gói tin ở hai luồng mở rộng là có sự khác biệt. Ta có thể nhận thấy rõ hơn thông qua ñộ thị so sánh ñộ trễ luồng mở rộng 2 trong hai trường hợp như hình dưới ñây.
35
Hình 3.4. Biểu ñồ so sánh ñộ trễ luồng mở rộng hai khi mạng bận trong hai trường hợp gán ñộ ưu tiên bằng nhau và gán ñộưu tiên khác nhau (adsbygoogle = window.adsbygoogle || []).push({});
Từ biểu ñồ trong hình 3.3 ta có thể thấy rằng, ñộ trễ của các gói tin luồng mở rộng 2 trong trường hợp gán ñộ ưu tiên các luồng như nhau (màu ñỏ) hầu như luôn nằm dưới ngưỡng 0.02s, và chủ yếu là nhỏ hơn 0.01s. Trong khi ñó, ñộ trễ của các gói tin cũng ở luồng mở rộng 2 nhưng với trường hợp gán ñộ ưu tiên các luồng khác nhau (màu xanh), phân nửa có giá trị lớn hơn 0.02s và có những lúc vọt lên tới giá trị 0.08s.
Điều này chứng tỏ rằng khi mạng rảnh rỗi nếu xếp ñộ ưu tiên của các luồng video streaming là khác nhau, thì ñộ trễ ở các luồng phía dưới (các luồng mở rộng ở bậc cao) sẽ bị tăng lên và ñiều này là hoàn toàn không hợp lý.
36
(a)
(b)
Hình 3.5. Thông lượng trong trường hợp mạng rỗi
(a) Trường hợp ñộưu tiên như nhau ; (b) Trường hợp ñộưu tiên khác nhau
Dễ dàng thấy rằng với cả hai trường hợp luồng cơ bản ñều có thông lượng như nhau. Tuy nhiên với trường hợp ñộ ưu tiên khác nhau hai luồng mở rộng ñều có thông lượng là không ổn ñịnh bằng thông lượng của chúng ở trong trường hợp ñộ ưu tiên giống nhau. Với luồng mở rộng 1 trường hợp ñộ ưu tiên của các luồng bằng nhau
37
thông lượng luôn duy trì ở mức 256kb/s, còn trường hợp ñộ ưu tiên các luồng khác nhau, một số thời ñiểm thông lượng của luồng này bị thay ñổi một ít. Còn với luồng mở rộng hai, ñộ sai lệch lên xuống của thông lượng trong trường hợp ñộ ưu tiên các luồng giống nhau là ít hơn, so với trường hợp ñộ ưu tiên các luồng khác nhau.
Từ việc xét hai thí nghiệm trong trường hợp mạng rỗi này ta có thể nhận ra ñược rằng trong trường hợp mạng rỗi các luồng dữ liệu streaming việc gán cùng ñộ ưu tiên ở mức cao ñể cho kết quả tốt hơn là gán chúng ở các ñộ ưu tiên khác nhau.
Vậy ta có thể kết luận rằng trong trường hợp mạng bận ta nên gán ñộ ưu tiên của các luồng dữ liệu tương ứng với các tầng trong cơ chế phân tầng của video streaming là khác nhau. Để ñảm bảo duy trì ñược luồng dữ liệu quan trọng hơn từ ñó ñảm bảo cho việc duy trì dịch vụ. Còn với trường hợp mạng rỗi nên gán ñộ ưu tiên của các luồng này là bằng nhau và ở mức cao ñể có thể ñảm bảo cung cấp ñược dịch vụ video streaming với chất lượng tốt hơn.