Luận văn Đảm bảo chất lượng phục vụ cho truyền video streaming trong mạng không dây 802.11

à luân phiên thay thế nhau. Mỗi chu kỳ tranh chấp được bắt đầu bằng việc AP sẽ gửi một khung beacon là một khung quản lý đặc biệt, trong khung này cĩ chứa giá trị CFP-MaxDuration là khoảng thời gian tối đa của chu kỳ khơng tranh chấp. Bởi vì việc truyền khung beacon cĩ thể 22 bị trễ do kênh truyền bận (frame trong chu kỳ DCF đang được gửi), cho nên chu kỳ khơng tranh chấp cĩ thể bị thu ngắn lại. 2.1.3.2. Thủ tục truy cập PCF Hình 2.5. Thủ tục DCF Các trạm và PC khơng sử dụng RTS/CTS trong chu kỳ khơng tranh chấp. Ở thời điểm bắt đầu mỗi CFP, PC sẽ cảm nhận kênh truyền, khi kênh truyền được xác định là rỗi AP sẽ đợi một khoảng PIFS, sau đĩ PC sẽ truyền khung quản lý Beacon chứa thơng tin CFPMaxDuration. Các trạm khi nhận được khung Beacon sẽ điều chỉnh giá trị NAV (network allocation vector) của chúng theo giá trị CFPMaxDuration. Điều này ngăn cản các trạm chiếm quyền điều khiển kênh truyền trong CFP. Việc thiết lập NAV cũng làm giảm nguy cơ trạm ẩn. Sau khi gửi khung beacon, PC sẽ chờ ít nhất một khoảng thời gian SIFS trước khi nĩ truyền khung thăm dị hoặc dữ liệu đến các trạm. PC sẽ duy trì một danh sách thăm dị và sẽ thăm dị lần lượt các trạm trong danh sách đĩ. PC sẽ nhìn vào danh sách thăm dị của nĩ, và nếu nĩ kiểm tra thấy trong bộ đệm cĩ dữ liệu cần truyền cho trạm mà nĩ định thăm dị, PC sẽ gửi cho trạm đĩ khung: Data + CF-Poll (khung thăm dị), trong trường hợp PC cĩ dữ liệu cần gửi cho trạm, ngược lại nếu khơng cĩ dữ liệu thì PC chỉ gửi khung thăm dị CF-Poll. Trạm được thăm dị sẽ trả lời với khung Data/ACK sau khoảng SIFS đến PC hoặc đến các trạm khác ở trong mạng. Nếu sau khoảng PIFS mà khơng thấy trả lời, PC sẽ giành quyền điều khiển và tiến hành thăm dị trạm tiếp theo trong danh sách thăm dị. Đối với trạm khơng trả lời thì ở lần thăm dị tiếp theo, PC sẽ gửi lại dữ liệu. 23 Đối với các trạm được thăm dị kể trên, nếu cĩ dữ liệu trạm sẽ trả lời với khung Data + CF-ACK cịn nếu khơng cĩ dữ liệu để gửi thì nĩ sẽ trả lời với khung CF-ACK. Quá trình thăm dị, gửi dữ liệu và trả lời này sẽ tiếp tục cho đến khi PC khơng cĩ khung dữ liệu nào để gửi và khơng cĩ trạm nào để thăm dị. Khi đĩ PC sẽ gửi một khung kết thúc CF-End hoặc CF-End +CF-ACK (nếu cần xác nhận dữ liệu) để thơng báo kết thúc chu kỳ khơng tranh chấp CFP. Lúc đĩ, tất cả các trạm sẽ xác lập lại giá trị NAV của chúng và chu kỳ tranh chấp CP sẽ bắt đầu. 2.2. Chuẩn IEEE 802.11e Chuẩn IEEE 802.11e là một biến thể của chuẩn 802.11. Nĩ định nghĩa một tập hợp các cải tiến đảm bảo chất lượng chất lượng dịch vụ cho mạng khơng dây WLAN thơng qua các sửa đổi trong tầng MAC. Chuẩn này cĩ tầm quan trọng và cần thiết cho các ứng dụng yêu cầu thời gian thực cũng như độ chậm trễ thấp như voice over IP, streaming multimedia. IEEE 802.11e đảm bảo chất lượng dịch vụ cơ bản dựa trên phân biệt lưu lượng, bằng việc bổ sung thêm trường QoS trong cấu trúc khung dữ liệu MAC. Hình 2.6. Frame IEEE 802.11e Việc bổ sung thêm trường “QoS Control” trong khung dữ liệu đã giúp cho IEEE 802.11e cĩ thể cung cấp việc đảm bảo chất lượng dịch vụ . IEEE 802.11e cung cấp sự ưu tiên thơng qua phân biệt định danh của các luồng và chỉ rõ ưu tiên. 2.2.1. Chức năng phối hợp lai (Hybrid Coordination Function - HCF) Trong IEEE 802.11e cơ chế truy cập kênh truyền được sử dụng là HCF (Hybrid coordination function). Cơ chế này được gọi là cơ chế lai bởi vì nĩ cĩ cả hai phương thức truy cập kênh truyền cĩ tranh chấp và khơng tranh chấp. HCF sử dụng phương thức truy cập kênh truyền dựa trên tranh chấp là EDCF (Enhance distributed channel access), nĩ là một sự mở rộng của phương thức DCF được áp dụng trong IEEE 802.11 MAC. Hoạt động đồng thời với EDCF là cơ chế truy cập kênh truyền cĩ điều khiển 24 dựa trên kỹ thuật thăm dị HCCA(HCF controlled channel access), cơ chế này cĩ thể sử dụng trong cả chu kỳ tranh chấp lẫn chu kỳ khơng tranh chấp. 2.2.1.1. EDCF (Enhanced Distributed Coordinated Function) Trong chuẩn IEEE 802.11e mỗi station sẽ phân loại các dịch vụ thành 4 nhĩm sự phân chia này dựa trên quyền truy cập đường truyền. Tức là mỗi frame được các tầng trên gửi xuống tầng MAC sẽ được phân vào một AC (Access categories) tương ứng với độ ưu tiên của frame đĩ theo bảng dưới đây. Bảng 2.1. Độ ưu tiên các dịch vụ Ở đây độ ưu tiên 0 (thấp nhất) nằm giữa độ ưu tiên 2 và 3 là do tuân thủ theo chuẩn IEEE 802.11d. Về đơn giản sự khác biệt của các AC này dựa trên các tham số : AIFSD[AC], CWMin[AC], CWMax[AC] tương ứng với các tham số DIFS, CWMin, Cwmax trong DCF. Các tham số trên là khác nhau với mỗi AC, từ đĩ mức độ ưu tiên để truy cập đường truyền của các AC cũng sẽ thay đổi theo giá trị của chúng. Giá trị của AIFSD[AC] được xác định thơng qua cơng thức : AIFSD[AC] = SIFS + AIFS[AC] * SlotTime AIFS[AC] là một số nguyên cĩ giá trị lớn hơn 0. Tức là độ ưu tiên của một AC sẽ được quy định bởi 3 tham số đĩ là : AIFS[AC], CWMin[AC], CWMax[AC]. Đây cũng là ba tham số chính trong chuẩn EDCF, chúng được cung cấp cho các trạm từ AP 25 thơng qua khung beacon. AP cĩ thể tự động tính tốn các giá trị này thơng qua việc xem xét điều kiện của mạng. Hình 2.7. Bốn Access Categories trong EDCF Hình trên mơ tả bốn hàng đợi trong tầng MAC thể hiện cho bốn AC, các khung dữ liệu từ tầng trên gửi đến tùy thuộc vào độ ưu tiên của nĩ sẽ được sắp xếp vào một hàng đợi tương ứng. Mỗi hàng đợi này được coi như là một trạm ảo, tức là nĩ sẽ cĩ giá trị AIFS[AC], CWMin[AC], CWMin[AC] riêng và khi muốn truyền dữ liệu chúng cũng sẽ thực thi các thủ tục backoff dựa vào các tham số này, và nếu như cĩ nhiều hơn một AC chọn cùng giá trị backoff thì sẽ xảy ra hiện tượng xung đột và người ta gọi hiện tượng này là hiện tượng xung đột ảo. Trong chuẩn IEEE 802.11e người ta đưa ra một khái niệm mới đĩ là cơ hội truyền (XTOP - Transmission Opportunity). XTOP là khoảng thời gian một trạm cĩ quyền được truyền, nĩ được xác định bởi thời gian bắt đầu và thời gian kết thúc truyền của trạm đĩ, chính dựa vào điều này mà các trạm khác trong mạng cĩ thể xác định được một cách chính xác thời gian mà trạm này sử dụng kênh truyền. Nếu trạm đang được cấp phát XTOP đã thực hiện xong việc truyền, trạm cĩ thể truyền tiếp các khung tiếp theo, nhưng phải đảm bảo rằng việc truyền các khung cũng như nhận ACK tương ứng của các khung này là khơng vượt quá thời gian cịn lại. 26 Quá trình thực thi EDCF được mơ tả như sau : Hình 2.8. Thực thi EDCF Cách thực thi EDCF cũng giống như thực thi DCF, chỉ cĩ một số khác biệt đĩ là mỗi trạm bây giờ sẽ tương ứng với 4 trạm ảo, và mỗi trạm này sẽ tự thực thi các cơ chế backoff, tranh chấp đường truyền một cách độc lập, tuy nhiên khi chọn giá trị random để tính giá trị backoff thì giá trị random này sẽ là một số nguyên nằm trong khoảng [1, 1+ CW[AC]] (ở DCF là khoảng [0,CWMin]). Thêm vào đĩ, mỗi khi một khung nào đĩ khơng thành cơng thì thay vì tăng giá trị của cửa sổ tranh chấp lên gấp đơi thì trong EDCF cĩ thay đổi chút ít. Nếu như giá trị CW[AC] hiện tại là nhỏ hơn CWMax[AC] thì giá trị CW[AC] sẽ được thay đổi theo cơng thức : CW[AC](new) = (CW[AC](old) + PF[AC]) * 2 – 1 Trong đĩ PE[AC] là một nhân tố cố định, trong chuẩn IEEE 802.11 thì PE là cố định và nhận giá trị là 2, tuy nhiên trong 802.11e giá trị này thơng thường là khác nhau ở mỗi AC, điều này làm tăng sự khác nhau giữa các giá trị CW của các AC. Nhưng, nếu giá trị CW[AC] đã đạt ngưỡng CWMax[AC] thì nĩ vẫn giữ nguyên giá trị đĩ khơng thay đổi cho tới khi khung được truyền đi thành cơng thì mới gán lại giá trị CW[AC]. Trong trường hợp xảy ra va chạm ảo (các AC truyền khung tại cùng một thời điểm) thì cơ hội truyền (XTOP) sẽ được cấp phát cho AC cĩ độ ưu tiên cao hơn, và các AC cịn lại được xem như gặp trường hợp truyền khung khơng thành cơng và phải chọn lại giá trị CW cũng như lặp lại thủ tục backoff. 27 2.2.1.2. HCCA(HCF controlled channel access) HCCA làm việc hầu như giống với chức năng điều phối điểm (Point Coordination Function). Tuy nhiên, trái ngược với PCF, ở đây khoảng cách giữa hai khung cảnh báo được chia thành hai giai đoạn của CFP và CP, HCCA cho phép CFPs được khởi động tại gần như bất cứ lúc nào trong một CP. Đây là một loại CFP được gọi là giai đoạn kiểm sốt truy cập (Coltrolled Access Phase - CAP) trong IEEE 802.11e. Một CAP được khởi tạo bởi các AP, bất cứ khi nào nĩ muốn gửi một frame đến một trạm, hay nhận được một frame từ một trạm, trong một kiểu cạnh tranh tự do. Trong thực tế, CFP cũng là một CAP. Trong một CAP, các điều phối Hybrid (HC) - cũng là AP - kiểm sốt truy cập điểm giữa. Trong CP, tất cả các trạm chức năng bên trong EDCA. Sự khác biệt với PCF là lớp lưu lượng (TC) và luồng lưu lượng (TS) được định nghĩa. Điều này cĩ nghĩa là HC khơng giới hạn hàng đợi trên từng trạm và cĩ thể cung cấp một loại dịch vụ cho mỗi phiên. Ngồi ra, HC cĩ thể phối hợp các luồng hoặc các phiên với kiểu bất kỳ mà nĩ chọn (khơng chỉ round-robin). Hơn nữa, các trạm cung cấp thơng tin về độ dài của hàng đợi cho từng lớp lưu lượng (TC). HC cĩ thể sử dụng thơng tin này ưu tiên cho một trong những trạm phát qua các trạm khác, hoặc tốt hơn cơ chế điều chỉnh lịch trình của nĩ. Sự khác biệt khác là các trạm đưa ra một TXOP: chúng cĩ thể gửi nhiều gĩi tin trong một hàng, trong một thời gian nhất định được lựa chọn bởi các HC. Trong CP, HC cho phép các trạm gửi dữ liệu bởi việc gửi các khung tin CF-Poll. HCCA thường được coi là chức năng phối hợp tiên tiến và phức tạp nhất . Với HCCA, QoS cĩ thể được cấu hình với độ chính xác tuyệt vời. QoS cho phép các trạm cĩ khả năng truyền tải các thơng số yêu cầu cụ thể (tỷ lệ jitter dữ liệu, vv) mà cĩ thể cho phép các ứng dụng nâng cao như VoIP và video để làm việc hiệu quả hơn trên một mạng khơng dây. Hỗ trợ HCCA khơng bắt buộc cho các điểm truy cập theo chuẩn 802.11e. Thực tế, cĩ rất ít( thậm chí khơng cĩ) các AP hỗ trợ HCCA. Tuy nhiên, thực hiện HCCA khơng địi hỏi nhiều các yêu cầu trên, vì về cơ bản sử dụng cơ chế DCF hiện tại cho truy cập kênh (khơng cĩ thay đổi để DCF hoặc hoạt động EDCA là cần thiết). Đặc biệt, việc thực hiện phía điểm phát sĩng là rất đơn giản như trạm chỉ cần để cĩ thể trả lời tin nhắn thăm dị. Về phía AP, lẽ dĩ nhiên, việc lập lịch và sử dụng hàng đợi là cần thiết. Cĩ ý kiến cho rằng, AP đã được trang bị tốt hơn là một trạm thu phát, điều này nên là một vấn đề khác. 28 2.3. Truyền video streaming trong mạng khơng dây IEEE 802.11e Việc truyền video streaming trong mạng khơng dây trước đây gặp nhiều vấn đề do phải tranh chấp với các luồng dữ liệu khác. Do đĩ việc truyền video rất bị hạn chế và cho kết quả thấp. Với việc áp dụng chuẩn IEEE 802.11e việc truyền video streaming trong mạng khơng dây đã cĩ nhiều cải thiện và đạt được hiệu quả cao hơn. Việc IEEE 802.11e phân biệt các dịch vụ khác nhau ở tầng MAC từ đo phân chia chúng vào các AC khác nhau cĩ độ ưu tiên khác nhau dẫn tới việc các dịch vụ truyền video cũng như audio khơng bị tranh chấp bởi các dịch vụ khác như các ứng dụng web hay là các ứng dụng truyền file… Chuẩn IEEE 802.11e định nghĩa bốn loại truy cập tương ứng với bốn độ ưu tiên khác nhau dành cho các nhĩm dịch vụ. Dịch vụ truyền video streaming được xếp vào nhĩm dịch vụ cĩ độ ưu tiên cao. Tức là các khung dữ liệu của nĩ từ tầng trên đẩy xuống sẽ được xếp vào hàng đợi tương ứng với AC cĩ độ ưu tiên cao. Từ đĩ dẫn đến việc xác xuất được truyền đi của các khung này là được tăng lên. Và kết quả là chất lượng dịch vụ được tăng lên. Bên cạnh đĩ do cĩ tính chất cơ hội truyền (TXOP) nếu như AC được cấp phát TXOP mà sau khi gửi khung thành cơng AC vẫn cĩ thể truyền tiếp những khung dữ liệu tiếp theo trong hàng đợi. Điều này giúp cho dịch vụ video streaming cĩ thể gửi một loạt các gĩi tin liên tiếp nhau. Điều này sẽ làm cho sự duy trì dịch vụ là được tăng cường. Tuy nhiên chuẩn IEEE 802.11e lại chỉ hướng vào việc đảm bảo chất lượng dịch vụ cho nhĩm dịch vụ. Tức là một khung dữ liệu bất kỳ khi cĩ dữ liệu đẩy xuống tầng MAC thì ứng với dịch vụ của khung đĩ MAC sẽ cấp phát cho nĩ độ ưu tiên cố định và đẩy nĩ vào hàng đợi tương ứng với độ ưu tiên đĩ. Nhưng với video streaming cơ chế phân tầng của nĩ sẽ tạo ra nhiều luồng dữ liệu cĩ tốc độ khác nhau cũng như độ quan trọng khác nhau. Việc giải mã dữ liệu của các tầng mở rộng trong video streaming phải luơn phụ thuộc và dữ liệu của tầng cơ bản và tầng cơ bản là nhân tố đầu tiên để dịch vụ video streaming cĩ thể được duy trì vì thế tầng cơ bản luơn luơn phải được ưu tiên cao nhất sau đĩ thứ tự ưu tiên giảm dần theo thứ tự luồng mở rộng 1, luồng mở rộng 2… Vì thế đĩ nếu như việc phân phối độ ưu tiên của các luồng này luơn luơn duy trì bằng nhau như trong chuẩn MAC thì việc phân biệt mức độ quan trọng của các luồng dữ liệu xem như là khơng được hỗ trợ. 29 Do vậy phải cĩ một cơ chế nào đĩ để giải quyết vấn đề này nhằm hỗ trợ tốt hơn cho việc đảm bảo chất lượng dịch vụ video streaming. Và đĩ cũng sẽ là nội dung của chương tiếp theo. 30 Chương 3. Giải pháp gán độ ưu tiên động cho các luồng video streaming trong mạng IEEE 802.11e 3.1. Vấn đề nghiên cứu 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 (a) Trường hợp độ ưu tiên như nhau ; (b) Trường hợp độ ưu tiên khác nhau 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 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à hồn tồ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. 3.2. Giải pháp gán độ ưu tiên động cho các luồng video streaming Dịch vụ truyền video streaming luơn luơn bị ảnh hưởng bởi tác động của mơi trường bên ngồi. Cĩ lúc thì các luồng video tương ứng với các tầng nên cĩ cĩ cùng độ ưu tiên ở mức cao, cĩ lúc lại nên cĩ độ ưu tiên khác nhau. Mà trong chuẩn IEEE 802.11e khơng hỗ trợ việc thay đổi độ ưu tiên cho các luồng dữ liệu. Nhu cầu đảm bảo dịch vụ cũng như chất lượng video streaming là rất cần thiết, do đĩ phải cĩ một giải pháp nào đĩ hỗ trợ sâu hơn cho việc truyền video streaming trong mạng khơng dây. Trong khĩa luận này tơi muốn tập trung cho việc duy trì sự tồn tại của dịch vụ, cũng như tăng cường chất lượng dịch vụ cho việc truyền video streaming trong mạng khơng dây. Và giải pháp tơi đưa ra ở đây là gán độ ưu tiên động cho các luồng video streaming. Giải pháp này của tơi được hình thành trong quá trình nghiên cứu, đo đạt và thí nghiệm trên các luồng video streaming trong IEEE 802.11e mà rút ra. Trong chuẩn IEEE 802.11e, mỗi luồng dữ liệu luơn duy trì một độ ưu tiên cố định từ khi bắt đầu khởi tạo cho đến khi kết thúc việc truyền. Giá trị độ ưu tiên này phụ thuộc vào dịch vụ sử dụng ở tầng ứng dụng. Việc làm này tạo ra được sự phân biệt giữa các nhĩm dịch vụ với nhau. Với việc áp dụng chuẩn IEEE 802.11e, dịch vụ video streaming sẽ gán độ ưu tiên của các luồng dữ liệu ở mức cao, từ đĩ cơ hội truyền của các khung dữ liệu tương ứng với dịch vụ này là cao hơn một số dịch vụ khác như web,fpt… 38 Tuy nhiên với sự phân tầng trong video streaming, mỗi một video gốc sẽ được mã hĩa thành nhiều tầng video với tốc độ nén và mức độ quan trọng khác nhau. Với việc mỗi dịch vụ chỉ cĩ thể tương ứng với một độ ưu tiên, hậu quả là tất cả các luồng dữ liệu của dịch vụ video streaming ở tất cả các tầng đều cùng cĩ một độ ưu tiên. Việc này làm giảm đi tính năng mềm dẻo của sự đảm bảo chất lượng dịch vụ, vì mức độ quan trọng của mỗi tầng trong video streaming là khác nhau. Cùng với đĩ mơi trường truyền khơng dây luơn ở trạng thái cĩ thể thay đổi bất cứ lúc nào. Phương pháp gán độ ưu tiên động cho các luồng video streaming đơn giản là kiểm tra giám sát mơi trường mạng, từ đĩ tính tốn một cách hợp lý để thay đổi giá trị độ ưu tiên của các luồng dữ liệu tương ứng với các tầng trong video streaming một cách phù hợp với sự thay đổi của mơi trường truyền. Như ta đã xét, tác nhân gây ra sự mất ổn định trong việc truyền video streaming là sự thay đổi của mơi trường truyền. Vậy muốn khắc phục điều này trước hết ta phải cĩ một cơ chế để kiểm tra mơi trường truyền, từ đĩ cĩ cơ chế thay đổi độ ưu tiên phù hợp. Vậy việc đầu tiên là làm sao để biết được mơi trường rỗi hay bận, mức độ rỗi, bận như thế nào. Sau đĩ dựa vào các tham số đĩ tùy chỉnh độ ưu tiên cho các luồng dữ liệu một cách phù hợp. 3.2.1. Các tham số đánh giá mơi trường truyền. Trong mơi trường khơng dây các trạm hay nĩi đúng hơn là các AC (chuẩn IEEE 802.11e) đều tranh chấp với nhau để giành được cơ hội truyền. Việc tranh chấp này dựa vào cách chọn thời gian backoff. AC nào cĩ giá trị backoff giảm tới 0 nhanh nhất thì được quyền chiếm kênh truyền. Khi mạng rảnh rỗi các AC cĩ thể chỉ backoff một hay một số nhỏ lần để giành được cơ hội truyền, ngược lại khi mạng bận, một khung dữ liệu trên một AC cĩ thể phải backoff nhiều lần để cĩ thể truyền đi. Điều này thể hiện rõ nhất trên các AC cĩ độ ưu tiên thấp. Vậy tham số tổng thời gian backoff trung bình của một khung dữ liệu ở một AC là một giá trị gián tiếp thể hiện độ nhàn rỗi của mơi trường. Một mặt nữa, trong những thí nghiệm ở mục 3.1 ta cĩ thể nhận thấy rằng, trong khi mơi trường truyền rỗi, thì hầu như tất cả các gĩi tin gửi từ bên gửi đều đến được bên nhận. Trong khi đĩ với mạng bận thì các gĩi tin gửi đi cĩ thể bị hủy và khơng bao giờ đến được bên nhận. Điều này là do băng thơng tối đa của mạng khơng đáp ứng đủ yêu cầu của các trạm nên một số gĩi tin phải bị hủy. Do đĩ, tiêu chí tiếp theo để đánh giá mơi trường truyền là tỉ lệ gĩi tin bị hủy trong khi truyền. 39 Các thơng số khác như độ trễ gĩi tin và thơng lượng cũng phản ảnh tình trạng mơi trường truyền nhưng chúng khơng xác định được ở bên gửi cho nên các tham số này sẽ khơng được đề cập trong phương pháp. Vậy ta cĩ thể đánh giá mơi trường truyền thơng qua hai tham số là tổng thời gian backoff của một khung dữ liệu và tỉ lệ mất gĩi tin. Dựa vào chúng ta sẽ nhận ra được những thay đổi của mơi trường truyền, từ đĩ điều chỉnh việc truyền dữ hợp lý. 3.2.2. Mơ tả giải pháp. Định nghĩa một số tham số : - ∆t : khoảng thời gian sử dụng để xem xét đường truyền. Ta sẽ tính các thơng số về thời gian backoff trung bình, cũng như tỉ lệ gĩi tin bị hủy trong khoảng thời gian này để đánh giá mơi trường. - ][ACebackoffTim : Là giá trị trung bình backoff time của mỗi khung tính trong khoảng thời gian ∆t trên mỗi AC. - dropRatio[AC] : Là tỷ lệ khung bị hủy trên mỗi AC trong khoảng thời gian ∆t. - backoffThresholdDown[AC] : là ngưỡng backoff time trên mỗi AC. Nếu giá trị ][ACebackoffTim tăng vượt quá ngưỡng này thì ta phải thực hiện cơ chế chuyển các luồng dữ liệu video streaming xuống AC cĩ độ ưu tiên thấp hơn AC hiện thời. - backoffThresholdUp[AC] : Cũng là ngưỡng backoff time trên mỗi AC. Nếu giá trị ][ACebackoffTim giảm xuống quá ngưỡng này, thì ta sẽ thực hiện cơ chế chuyển các luồng dữ liệu video streaming từ AC cĩ độ ưu tiên nhỏ hơn lên AC hiện thời. - dropThresholdDown[AC] : Là ngưỡng của tỷ lệ hủy gĩi tin trên mỗi AC. Nếu giá trị ratioDrop tăng vượt ngưỡng này, ta phải thực hiện cơ chế chuyển các luồng dữ liệu video streaming xuống AC cĩ độ ưu tiên thấp hơn AC hiện thời. - dropThresholdUp[AC] : Cũng là ngưỡng của tỷ lệ hủy gĩi tin trên mỗi AC. Nếu giá trị ratioDrop giảm xuống quá ngưỡng này, thì ta sẽ thực hiện cơ chế chuyển các luồng dữ liệu video streaming từ AC cĩ độ ưu tiên nhỏ hơn lên AC hiện thời. - numberFlow[AC] : là số lượng luồng dữ liệu video streaming đang cĩ độ ưu tiên tương ứng với AC. Trong phương pháp này. Ban đầu vẫn giữ nguyên như trong chuẩn IEEE 802.11e, ứng dụng video streaming sẽ gán độ ưu tiên của tất cả các luồng ứng với các 40 tầng của nĩ cùng một giá trị (vì là video streaming nên độ ưu tiên là là ở mức cao prio=1). Mỗi một AC ở các trạm, sẽ luơn luơn theo dõi giá trị backoff time trung bình của các khung dữ liệu và tỷ lệ gĩi tin bị hủy trong một khoảng ∆t và xem xét xem nếu như giá trị backoff time trung bình vượt quá ngưỡng backoff time cho phép, hoặc tỷ lệ hủy gĩi tin vượt quá ngưỡng cho phép của AC đĩ, thì sẽ thực hiện cơ chế chuyển độ ưu tiên của các luồng dữ liệu. Cơ chế đĩ được mơ tả trong giải thuật sau for (int i = 1; i < 3; i++){ if( ][iebackoffTim > backoffThresholdDown[i] || dropRatio[i] < dropThresholdDown[i]) { if( numberFlow[i] >1 || (numberFlow[i] == 1 && i != 1)){ Chuyển luồng ứng với tầng cĩ mức độ quan trọng nhỏ nhất đang cịn tồn tại trong AC[i] xuống AC[i+1] } } } Tức là sau mỗi thời gian ∆t, kiểm tra tất cả các AC xem nếu ở AC đĩ cĩ một hoặc nhiều hơn một luồng dữ liệu của dịch vụ video streaming chạy, và giá trị backoff time trung bình của AC vượt ngưỡng backoffThresholdDown[AC] của nĩ, hoặc tỷ lệ hủy khung dữ liệu vượt quá giá trị dropThresholdDown[AC], thì một luồng trong đĩ sẽ được chọn để đẩy xuống AC cĩ độ ưu tiên thấp hơn. Tiêu chí để chọn là luồng cĩ độ quan trọng thấp nhất với dịch vụ video streaming. Độ quan trọng này sắp theo thứ tự giảm dần theo thứ tự: luồng cơ bản, luồng mở rộng 1, luồng mở rộng 2… Nhưng nếu AC là AC cĩ độ ưu tiên nhận giá trị là 1 (prio = 1) và nĩ chỉ cĩ một luồng dữ liệu cịn lại thì khơng được đẩy luồng này xuống vì đĩ là luồng cơ bản(tình trạng này chỉ gặp khi mạng quá bận, và dịch vụ video streaming khơng thể duy trì được với bất cứ cách thức nào). Nhưng nếu chỉ cĩ cơ chế chuyển các luồng xuống các AC cĩ độ ưu tiên thấp hơn khi mạng được xác định là bận thì chưa đủ. Bởi vì như kết luận ở phần 3.1 ta cĩ: với trường hợp mạng rỗi nên gán độ ưu tiên của các luồng 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. Như vậy song song với cơ chế đẩy các luồng xuống các AC cĩ độ ưu tiên thấp khi mạng 41 bận thì phải cĩ cơ chế kéo các luồng lên các AC cĩ độ ưu tiên cao hơn khi tình trạng mạng là rảnh rỗi hơn. Do đĩ giải thuật trên cần viết lại như sau : for (int i = 1 ; i < 3; i++){ if( ][iebackoffTim > backoffThresholdDown[i] || dropRatio[i] < dropThresholdDown[i]) { if( numberFlow[i] >1 || (numberFlow[i] == 1 && i != 1)){ Chuyển luồng ứng với tầng cĩ mức độ quan trọng nhỏ nhất đang cịn tồn tại trong AC[i] xuống AC[i+1] } } if( ][iebackoffTim < backoffThresholdUp[i] || dropRatio[i] < dropThresholdUp[i] ){ Chuyển luồng ứng với tầng cĩ mức độ quan trọng cao nhất đang cịn tồn tại trong AC[i+1] lên AC[i] } } Việc chọn các ngưỡng để chuyển các luồng lên hay xuống các AC cĩ độ ưu tiên cao hay thấp hơn AC hiện tại là khác nhau thay vì gán chung một ngưỡng để quy định luồng dữ liệu tụt xuống hay kéo lên giữa các AC. Bởi vì điều này làm giảm thiểu khả năng một luồng nào đĩ cứ bị chuyển đi chuyển lại liên tục giữa các AC do các thơng các thơng số đánh giá tăng giảm quanh ngưỡng chung. Mặt khác khi cĩ thay đổi thể hiện thơng qua tham số đánh giá ta khơng chuyển một cách đột ngột và ồ ạt các luồng dữ liệu xuống các tầng thấp mà chuyển một cách từ từ từng luồng một để hợp lý dần sự phân bố các luồng ở các AC sao cho phù hợp nhất với độ thay đổi của mơi trường truyền. 3.3. Phân tích đánh giá Giải pháp gán độ ưu tiên động cho các luồng video thực sự cĩ tác dụng trong mơi trường mạng khơng ổn định như trong mạng khơng dây. Sự biến đổi của của mơi trường truyền là thường xuyên diễn ra. Do đĩ việc thay đổi linh động độ ưu tiên các luồng với mục đích đảm bảo duy trì dịch vụ cũng như chất lượng dịch vụ là cần thiết và cĩ hữu ích. 42 Nếu như mơi trường mạng ban đầu đang rỗi. các luồng dữ liệu của video đều được truyền ở AC cĩ độ ưu tiên cao, điều này làm cho dịch vụ video streaming cĩ thể đạt được chất lượng tốt do cĩ sự kết hợp của các luồng mở rộng và luồng cơ bản. Tuy nhiên nếu như tình trạng mạng chuyển sang bận, lúc này nếu các luồng vẫn giữ nguyên độ ưu tiên của nĩ. Thì tình trạng tranh chấp sẽ xảy ra thường xuyên đồng thời là việc tranh chấp giữa các trạm với nhau. Điều đĩ làm cho tất cả các luồng kể cả luồng cơ bản cũng như các luồng mở rộng đều bị giảm tốc độ truyền cũng như tăng độ trễ một cách mạnh mẽ. Điều này gây ra việc dịch vụ video streaming sẽ khơng duy trì được ngay cả với chất lượng thấp. Việc áp dụng giải pháp gán độ ưu tiên động sẽ giải quyết được trường hợp này bởi vì khi tình trạng mạng là bận, các luồng mở rộng sẽ bị chuyển dần xuống các AC cĩ độ ưu tiên thấp hơn. Do đĩ luồng cơ bản và cĩ thể thêm một số luồng mở rộng thấp (các luồng mở rộng ứng với các tầng ở gần tầng cơ bản nhất) sẽ khơng phải chịu tranh chấp với các luồng mở rộng cao (các luồng mở rộng ứng với các tầng ở xa so với tầng cơ bản). Do đĩ chúng cĩ điều kiện truyền tốt hơn. Từ đĩ dịch vụ sẽ được đảm bảo hơn. 43 Chương 4. Đánh giá giải pháp độ ưu tiên động cho các luồng video streaming trong mạng IEEE 802.11e 4.1. Mơi trường mơ phỏng 4.1.1. Xây dựng chương trình mơ phỏng. Mơ phỏng thực hiện trên bộ mơ phỏng NS-2. NS-2 là phần mềm mơ phỏng mạng điều khiển sự kiện riêng rẽ hướng đối tượng, được phát triển tại UC Berkely, viết bằng ngơn ngữ C++ và OTcl. NS rất hữu ích cho việc mơ phỏng mạng diện rộng (WAN) và mạng local (LAN). Bốn lợi ích lớn nhất của NS-2 phải kể đến đầu tiên là: • Khả năng kiểm tra tính ổn định của các giao thức mạng đang tồn tại • Khả năng đánh giá các giao thức mạng mới trước khi đưa vào sử dụng • Khả năng thực thi những mơ hình mạng lớn mà gần như ta khơng thể thực thi được trong thực tế • Khả năng mơ phỏng nhiều loại mạng khác nhau NS-2 (Network Simulator version 2.xx) là một trong các bộ mơ phỏng mạng mã nguồn mở, tự do, được sử dụng rộng rãi nhất trong các trường đại học (cĩ giảng dạy về mạng) trên thế giới. NS-2 đặc biệt mạnh trong việc mơ phỏng để nghiên cứu về các giao thức mạng, từ tầng MAC cho đến tầng Transport. Sử dụng NS-2 cĩ thể mơ phỏng các mạng cĩ dây (Wired Networks), khơng dây (Wireless Networks), mạng di động khơng dây đặc biệt - MANET (Mobile Adhoc Networks), hỗn hợp, v.v. Các sự kiện xảy ra trong mạng mơ phỏng và một số tham số cần nghiên cứu thường được kết xuất ra “tệp vết” (Trace file) hoặc một số tệp dạng văn bản. Để nhận được các kết quả mong muốn cần phải xử lý các tệp kết quả này và biểu diễn kết quả thu được, thường là dưới dạng đồ thị. NS thực thi các giao thức mạng như Giao thức điều khiển truyền tải (TCP) và Giao thức gĩi người dùng (UDP); các dịch vụ nguồn lưu lượng như Giao thức truyền tập tin (FTP), Telnet, Web, Tốc độ bit cố định (CBR) và Tốc độ bit thay đổi (VBR) ; các kỹ thuật quản lý hàng đợi như Vào trước Ra trước (Drop Tail), Dị sớm ngẫu nhiễn (RED) và CBQ; các thuật tốn định tuyến như Dijkstra… NS cũng thực thi multicasting và vài giao thức lớp Điều khiển truy cập đường truyền (MAC) đối với mơ phỏng LAN. 44 Hình 4.1. Tổng quan về NS dưới gĩc độ người dùng OTcl Script Kịch bản OTcl Simulation Program Chương trình Mơ phịng OTcl Bộ biên dịch Tcl mở rộng hướng đối tượng NS Simulation Library Thư viện Mơ phỏng NS Event Scheduler Objects Các đối tượng Bộ lập lịch Sự kiện Network Component Objects Các đối tượng Thành phần Mạng Network Setup Helping Modules Các mơ đun Trợ giúp Thiết lập Mạng Plumbling Modules Các mơ đun Plumbling Simulation Results Các kết quả Mơ phỏng Analysis Phân tích NAM Network Animator Minh họa Mạng NAM Trong hình trên, NS là Bộ biên dịch Tcl mở rộng hướng đối tượng; bao gồm các đối tượng Bộ lập lịch Sự kiện, các đối tượng Thành phần Mạng và các mơ đun Trợ giúp Thiết lập Mạng (hay các mơ đun Plumbing). Để sử dụng NS-2, người dùng lập trình bằng ngơn ngữ kịch bản OTcl. User cĩ thể thêm các mã nguồn Otcl vào NS-2 bằng cách viết các lớp đối tượng mới trong OTcl. Những lớp này khi đĩ sẽ được biên dịch cùng với mã nguồn gốc. Bộ mơ phỏng NS-2 sử dụng trong khĩa luận là phiên bản ns2-2.28 và được cài thêm bộ hỗ trợ chuẩn ieee 802.11e. Dựa trên bộ mơ phỏng ns2 này ta sẽ đánh giá độ 45 hiệu quả của giải pháp gán độ ưu tiên động cho các luồng video streaming so với chuẩn 802.11e. Để làm việc này ta cần phải xây dựng một kịch bản rõ ràng và phù hợp sao cho việc đánh giá là cơng bằng và cho ra kết quả là chuẩn xác. 4.1.2. Kịch bản mơ phỏng Mơ hình mơ phỏng sẽ bao gồm 3 máy trạm và một access point sử dụng mạng khơng dây theo chuẩn ieee 802.11e như hình dưới. Hình 4.2. Mơ hình thí nghiệm Với mơ hình mơ phỏng này ta sẽ đi xét những thí nghiệm để so sánh độ hiệu quả của giải pháp độ ưu tiên động cho các luồng so với chuẩn cũ trong 802.11e. Đầu tiên ta sẽ quy định một số tham số chung để thực hiện mơ phỏng. 4.1.2.1. Các tham số mơi trường Dựa trên mơ hình 802.11 MAC, các tham số PHY trong mơ hình mơ phỏng EDCF được thiết lập như sau: - SlotTime: 16µs - SIFS: 8µs - PIFS: 12µs - DIFS: 16µs Băng thơng chung của mạng là 2Mb/s. kích cỡ của mỗi gĩi tin của tầng ứng dụng là 1kB. Tham số về CW, PF, AIFS của IEEE 802.11e chuẩn dùng để mơ phỏng tuân theo các giá trị ở bảng sau 46 Bảng 4.1. Các tham số mơ phỏng AC PF AIFS CW_MIN CW_MAX TXOPLimit 0 2 2 7 15 0.003264s 1 2 2 15 31 0.006016s 2 2 3 31 1023 0 3 2 7 31 1023 0 4.1.2.2. Thơng số tại các trạm Trạm thứ nhất (station 1) sẽ là trạm sử dụng để thực hiện việc streaming video và cũng là trạm để ta quan sát và đánh giá. Ở trạm này, tầng ứng dụng sẽ sử dụng 3 luồng dữ liệu cbr để gửi dữ liệu cho AP các luồng này tương ứng là luồng cơ bản, luồng mở rộng 1 và luồng mở rộng 2 được tạo ra do cơ chế phân tầng của dịch vụ video streaming. Các luồng dữ liệu này tương ứng sẽ cĩ tốc độ là 128kbps, 256kbps và 512kbps. Trạm thứ hai (station 2) và trạm thứ 3 (station 3) sẽ là hai trạm sử dụng để làm mơi trường. Hai trạm này sẽ gây ra cho mạng tình trạng nghẽn hay rảnh rỗi bằng cách thay đổi tốc độ truyền dữ liệu của các luồng cbr của nĩ. Mỗi trạm sẽ cĩ 3 luồng dữ liệu cbr gửi cho AP các luồng này ban đầu sẽ cĩ tốc độ truyền bằng nhau và nhận giá trị là 100kbps, các luồng dữ liệu này sẽ được xếp vào 3 AC cĩ độ ưu tiên khác nhau với giá trị là 1,2 và 3. Trạm 2 và trạm 3 sẽ truyền dữ liệu trong suốt thời gian chạy mơ phỏng sau đĩ 10 giây (giây thứ 10 trong khoảng thời gian mơ phỏng) trạm 1 sẽ bắt đầu truyền dữ liệu. Đến giây thứ 250 thì trạm 1 dừng việc truyền dữ liệu và mơ phỏng sẽ kết thúc ở giây thứ 300 Để gây sự mất ổn đinh cho mạng, trong quá trình truyền tốc độ của các luồng dữ liệu ở trạm 2 và trạm 3 sẽ được thay đổi đồng loạt tại một số thời điểm. Cụ thể là : - giây thứ 40 : Tăng tốc độ truyền từ 100kbps lên 200kbps - Giây thứ 70 : Tăng tốc độ truyền từ 200kbps lên 400kbps - Giây thứ 100 : Tăng tốc độ truyền từ 400kbps lên 600kbps - Giây thứ 130 : Tăng tốc độ truyền từ 600kbps lên 700kbps 47 - Giây thứ 160 : Giảm tốc độ truyền từ 700kbps xuống 150kbps - Giây thứ 190 : Giảm tốc độ truyền từ 150kbps xuống 50kbps - Giây thứ 210 : Tăng tốc độ truyền từ 50kbps lên 650kbps Bây giờ, dựa trên mơ hình trên ta sẽ thực hiện hai thí nghiệm. Tương ứng với hai trường hợp : sử dụng cơ chế IEEE 802.11e chuẩn và cơ chế áp dụng giải pháp gán độ ưu tiên động cho các luồng dữ liệu. Kết quả sẽ được so sánh và phân tích ở trên hai phương diện chính là băng thơng và độ trễ. 4.2. Kết quả mơ phỏng 4.2.1. Đánh giá về thơng lượng Sau khi thực hiện hai thí nghiệm với mơ hình như mơ tả ở phần 4.1.2 tương ứng với hai trường hợp sử dụng cơ chế chuẩn 802.11e và cơ chế áp dụng giải thuật gán độ ưu tiên động cho các luồng dữ liệu. Ta cĩ đồ thị mơ tả thơng lượng của các luồng dữ liệu ở station 1 như sau : (a) 48 (b) Hình 4.3. Thơng lượng của các luồng dữ liệu video streaming (a) Sử dụng cơ chế 802.11e chuẩn ; (b) Sử dụng cơ chế gán độ ưu tiên động Dựa vào hai đồ thị trên ta cĩ dễ dàng thấy rằng. Với phương pháp gán độ ưu tiên động luồng dữ liệu ứng với tầng cơ bản (luồng cơ bản) luơn luơn duy trì mức thơng lượng cố định là 128kbps để đảm bảo rằng bên nhận luơn luơn duy trì được dịch vụ với bất kỳ thay đổi nào của mơi trường truyền. Trong khi đĩ với trường hợp sử dụng cơ chế 802.11e chuẩn thì thơng lượng của tất cả các luồng trong đĩ cả luồng cơ bản là khơng ổn định và tăng, giảm phụ thuộc vào độ rỗi, bận của bận của mơi trường. Việc này gây ra tình trạng dịch vụ video streaming sẽ khơng ổn định. Do gán cùng độ ưu tiên và cố định chúng trong suốt thời gian truyền do đĩ kể cả những lúc mạng bận lưu lượng của các luồng mở rộng vẫn lớn hơn luồng cơ bản (trường hợp cơ chế 802.11e chuẩn) điều này là một lãng phí bởi vì trong khi luồng cơ bản cĩ thơng lượng nhỏ, việc giải mã các luồng mở rộng lại phụ thuộc vào luồng cơ bản. Do đĩ thơng lượng của các luồng mở rộng trở nên hoang phí và khơng cĩ ích gì. Trong hai đồ thì trên ta cũng cĩ thể nhận thấy rằng trong điều kiện mạng rảnh rỗi (từ giây thứ 10 đến giây thứ 40 và từ giây thứ 190 đến giây thứ 210) cả hai phương pháp đều cho kết quả là 3 luồng dữ liệu video đều cĩ thơng lượng đạt mức cao do đĩ chất lượng video ở bên nhận cĩ được cĩ chất lượng tốt. Song khi mạng bắt đầu trở nên 49 bận ví dụ như khoảng thời gian từ giây thứ 40 đến giây thứ 70 thì ở trường hợp sử dụng cơ chế 802.11e chuẩn cả ba luồng dữ liệu sẽ đồng loạt giảm thơng lượng, trong khi đĩ ở trường hợp sử dụng cơ chế độ ưu tiên động. luồng mở rộng 2 sẽ giảm nhanh thơng lượng trong khi đĩ luồng mở rộng 1 và luồng cơ bản vẫn duy trì được thơng lượng ở mức cao. Tức là chất lượng video ở bên nhận sẽ vẫn nhận được tín hiệu tốt do sự kết hợp giữa luồng cơ bản và luồng mở rộng 1. Ta cũng cĩ biểu đồ cột so sánh tổng số gĩi tin nhận được của mỗi luồng dữ liệu như sau. Hình 4.4. Biểu đồ so sánh tổng số gĩi tin Biểu đồ so sánh tổng số gĩi tin cho ta thấy rằng. với phương thức gán độ ưu tiên động luồng mở rộng 2 ở bên nhận thu được số lượng gĩi tin ít hơn so với trường hợp sử dụng cơ chế 802.11e chuẩn. Tuy nhiên bù vào đĩ hai luồng cịn lại (luồng cơ bản và luồng mở rộng 1) của thí nghiệm trong trường hợp sử dụng độ ưu tiên động lại cĩ kết quả là số lượng gĩi tin truyền tới đích lớn hơn so với trường hợp sử dụng cơ chế 802.11e chuẩn. Mà trong video streming thì hai luồng này là quan trọng hơn luồng mở rộng 2 do đĩ cĩ thể nhận thấy việc phương pháp độ ưu tiên động hướng tới việc duy trì dịch vụ hơn là phương pháp 802.11e chuẩn (tỷ lệ gĩi tin truyền được chỉ tỷ lệ với tốc độ truyền của luồng dữ liệu mà khơng quan tâm tới việc đảm bảo chất lượng cho các luồng quan trọng). 4.2.2. Đánh giá về độ trễ Ta sẽ đi so sánh độ trễ của các gĩi tin trong cả hai trường hợp; sử dụng cơ chế 802.11e chuẩn và cơ chế độ ưu tiên động cho các luồng. Để đánh giá xem phương pháp độ ưu tiên động cĩ đem lại hiệu quả về độ trễ hay khơng. 50 Độ trễ của các luồng dữ liệu video tương ứng với cả hai trường hợp được thể hiện bởi hai đồ thị dưới đây. (a) (b) Hình 4.5. Độ trễ của các luồng dữ liệu video streaming (a) Sử dụng cơ chế 802.11e chuẩn ; (b) Sử dụng cơ chế gán độ ưu tiên động 51 Dựa vào hai biểu đồ độ trễ của các luồng dữ liệu trên ta cĩ thể nhận thấy, với phương pháp sử dụng độ ưu tiên chuẩn, độ trễ của các gĩi tin tương ứng với 3 luồng dữ liệu video streaming là đồng đều trong mọi trường hợp khác nhau của mơi trường mạng. Phần lớn trong số các gĩi tin nhận được ở bên nhận cĩ độ trễ lớn hơn 0.6s và hơn một nửa cĩ độ trễ lớn hơn 0.8s. Một số dịch vụ video streaming cĩ yêu cầu độ trễ rất thấp, thì với độ trễ tầm 0.6s hoặc 0.8s trở lên khơng thể đáp ứng được yêu cầu này do đĩ cĩ thể dịch vụ sẽ bị gián đoạn và khĩ duy trì được trong tình trạng sử dụng cơ chế này. Trong khi đĩ ở trường hợp sử dụng cơ chế gán độ ưu tiên động. Giá trị độ trễ của các gĩi tin ở luồng cơ bản luơn duy trì ở mức 0.015s cho dù cĩ bất kỳ sự thay đổi nào của mơi trường. Luồng mở rộng 1 cĩ độ trễ khá cao thường thì các gĩi tin của nĩ cĩ độ trễ vào khoảng 2s đến 3s. Luồng mở rộng 2 cĩ độ trễ thay đổi nhiều và cĩ thể ở mức rất cao. Tuy là hai luồng mở rộng cĩ độ trễ cao nhưng bù vào đĩ độ trễ luồng cơ bản luơn luơn ở mức thấp, cho nên bất kỳ dịch vụ video nào cho dù là dịch vụ yêu cầu độ trễ video ở mức thấp đi nữa. Cơ chế này vẫn đảm bảo duy trì được dịch vụ. Trong những trường hợp mạng rảnh rỗi, tức là khoảng từ gĩi tin thứ 1 đến gĩi tin thứ 6000 và khoảng từ gĩi tin thứ 69000 tới gĩi tin thứ 73000 thì cả hai trường hợp đều duy trì độ trễ của 3 luồng ở mức thấp tức là lúc này dịch vụ video streaming sẽ cho chất lượng tốt nhất với độ trễ ba luồng hầu như khơng đáng kể. Do đĩ ở khoảng này dịch vụ video cung cấp sẽ cĩ chất lượng tốt vì video cuối sẽ là sự kết hợp của cả ba luồng dữ liệu. Nhưng ngồi khoảng thời gian mạng rảnh rỗi này ở hình (b) ta cĩ thể thấy rằng trong khoảng từ gĩi tin thứ 6000 đến gĩi tin thứ 13000 và khoảng từ gĩi tin thứ 62500 tới gĩi tin thứ 69000 luồng mở rộng 1 cĩ độ trễ nhỏ do đĩ khoảng thời gian này dịch vụ video streaming cĩ thể cĩ kết quả là video ở đầu cuối là sự kết hợp của luồng cơ bản và luồng mở rộng 1. Qua kết quả của hai thí nghiệm trên ta cĩ thể thấy được rằng. Phương pháp phân phối độ ưu tiên động cho các luồng là khá linh động và thích hợp hơn với tình trạng mạng khơng ổn định một thuộc tính cố hữu và cơ bản của mạng khơng dây. 52 Chương 5. Kết luận 5.1. Kết luận Khĩa luận đưa ra giải pháp gán độ ưu tiên động cho các luồng video streaming nhằm tăng cường việc đảm bảo chất lượng dịch vụ video streaming trong mạng khơng dây 802.11. Với việc gán độ ưu tiên cho các luồng tương ứng với các tầng của video streaming một cách linh động dựa theo tình trạng của mơi trường. Dựa vào chuẩn 802.11e giải pháp cĩ những sửa đổi để tăng thêm khả năng chống chịu với sự thay đổi mơi trường truyền. Giải pháp cĩ khá nhiều ưu điểm như là Tận dụng được băng thơng lúc mạng rảnh rỗi để truyền dữ liệu bằng việc gán độ ưu tiên của các luồng là bằng nhau và ở mức cao. Nhưng cũng cĩ sự điều chỉnh phù hợp độ ưu tiên của các luồng khi tình trạng tắc nghẽn xảy ra sao cho trung hịa giữa việc đảm bảo rằng các luồng dữ liệu quan trong của video streaming được đảm bảo tốt về băng thơng, độ trễ và tỷ lệ mất gĩi tin ngay cả khi mạng cĩ tình trạng tắc nghẽn cũng như cố gắng cung cấp chất lượng tốt nhất cĩ thể của video đầu cuối. 5.2. Hướng phát triển tiếp theo Kết quả mơ phỏng đã làm rõ được những đặc điểm tốt của giải pháp tuy nhiên việc chọn các giá trị ngưỡng của backoff time cũng như tỷ lệ hủy gĩi tin vẫn chỉ dựa trên các thí nghiệm mơ phỏng đơn thuần đưa ra. Vậy hướng tiếp theo để phát triển giải pháp là tìm cách để chọn những giá trị ngưỡng một cách phù hợp nhất để cĩ thể cĩ những bước chuyển độ ưu tiên cho các luồng một cách hợp lý Một mặt nữa đĩ là giải pháp mới chỉ được đánh giá bằng cách mơ phỏng trên bộ mơ phỏng ns-2 chứ chưa cĩ một kết quả thí nghiệm thực tế nào. Nên việc tiếp theo là nên xây dựng được những thí nghiệm thực tế để đánh giá một cách trực quan từ đĩ cĩ thể thu được những kết luận chính xác mà bộ mơ phỏng khơng cĩ được. 53 Tài liệu tham khảo [1] Allen Miu, John G.Apostolopouslos, Wai-tian Tan and Mitchell Trott : “Low- latency wireless video over 802.11 networks using path diversity” [2] D. J. Leith, P. Clifford, D. Malone, and A. Ng “TCP fairness in 802.11e WLANs” [3] Gilles Berger-Sabbatel, Andrzej Duda, Olivier Gaudoin, Martin Heusse, Franck Rousseau “Fairness and its impact on delay in 802.11 network” [4] IEEE Std 802.11e (2007), Part 11: “Wireless LAN medium access control (MAC) and physical layer (PHY) specifications” [5] Pierre Ansel, Qiang Ni and Thierry Turletti “FHCF : A simple and eficient scheduling scheme for IEEE 802.11e wireless LAN” [6] Stefan Mangold, Sunghyun Choi, Peter May, Ole Klein, Guido Hiertz, Lothar Stibor : “IEEE 802.11e wireless LAN for quality of service” [7] Sunghyun Choi, Javier del Prado, Sai Shankar, Stefan Mangold : “IEEE 802.11e contention-base channel access (EDCF) performance evaluation” [8] Wu Dapeng, Hou Yiwei Thomas, Zhu Wenwu, Zhang Ya-Qin, Peha Jon M. (2001); “Streaming Video over the Internet: Approaches and Directions”. [9] Yang Xiao, Haizhon Li, Sunghyun Choi “Protection and guarantee for voice and video traffic in IEEE 802.11e wireless LANs” Website: