Tải bản đầy đủ (.pdf) (41 trang)

Nghiên cứu phương pháp tăng chất lượng dịch vụ truyền video trên mạng không dây

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (1.12 MB, 41 trang )

3


MỞ ĐẦU
Trong những năm gần đây, cùng với bƣớc tiến của ngành công nghệ thông tin và
truyền thông, mạng không dây ngày càng phát triển và tỏ ra là một trong những công
nghệ trong thời đại mới. Một trong những công nghệ mạng không dây đƣợc sử dụng
phổ biến và đƣợc triển khai nhiều tới các thiết bị đầu cuối hiện nay là IEEE 802.11
WLAN, cùng với xu hƣớng hội tụ các dịch vụ nó đã đem lại một thời kỳ phát triển rực
rỡ cho các thiết bị di động. Trên cùng một hạ tầng mạng sẽ truyền tải rất nhiều các
dịch vụ khác nhau vì thế cần có những cơ chế đảm báo chất lƣợng dịch vụ dựa trên
phân loại dịch vụ và theo độ ƣu tiên. Vì thế một tiêu chuẩn hỗ trợ những yêu cầu đa
dạng về chất lƣợng dịch vụ đã ra đời là IEEE 802.11e. Nó xác định bốn loại truy cập
có những ƣu tiên truyền dẫn khác nhau, và việc phân bổ dữ liệu vào các truy cập này
dựa trên đặc tính của dữ liệu truyền, đƣợc quy định thành bốn dạng: Voice, Video,
Best effort và Background. Cùng với sự phát triển của truyền thông thì nhu cầu truyền
dẫn Video trên mạng không dây ngày càng tăng, và với đặc thù của luồng dữ liệu cần
độ ƣu tiên cao thì khi truyền dịch vụ trên 802.11e là chƣa đủ, đòi hỏi những thuật toán
tối ƣu hơn để tăng chất lƣợng dịch vụ truyền Video. Đã có rất nhiều các bài báo khoa
học và công trình nghiên cứ về việc tối ƣu lại giao thức 802.11e cho việc truyền
Video nhƣng nổi bật nhất là hai thuật toán ánh xạ tĩnh và ánh xạ động, trong luận văn
này tôi xin đi sâu vào phân tích và so sánh hai thuật toán này đồng thời mô phỏng trên
phần mềm NS2 và tối ƣu hóa các tham số để có thể cải thiện đƣợc chất lƣợng truyền
Video tốt hơn.
4


Mục lục
MỞ ĐẦU 3
Danh mục các hình vẽ 5
Danh mục các ký hiệu và chữ viết tắt 6


CHƢƠNG 1: GIỚI THIỆU 7
CHƢƠNG 2: CƠ SỞ LÝ THUYẾT 8
2.1 CHUẨN NÉN MPEG-4 8
2.2 IEEE 802.11e EDCA (Enhanced Distributed Channel Access) 10
CHƢƠNG 3: THUẬT TOÁN ÁNH XẠ TĨNH VÀ ÁNH XẠ ĐỘNG 12
3.1 ÁNH XẠ TĨNH 12
3.2 ÁNH XẠ ĐỘNG 13
CHƢƠNG 4: MÔ PHỎNG 27
4.1 KỊCH BẢN MÔ PHỎNG 27
4.2 KẾT QUẢ MÔ PHỎNG 28
4.2.1 Truyền tải chỉ có Video 28
4.2.2 Truyền tải nhiều dạng dữ liệu 33
KẾT LUẬN 40
TÀI LIỆU THAM KHẢO 41


5


Danh mục các hình vẽ
Hình 1. Cấu trúc GOP 9
Hình 2. Ví dụ về GOP MPEG 10
Hình 3. Bốn loại truy cập trong IEEE 802.11e 11
Hình 4. Các hoạt động của IEEE 802.11e EDCA 12
Hình 5. Kiễn trúc xuyên lớp 13
Hình 6. Kiến trúc của ánh xạ xuyên lớp 14
Hình 7. Thuật toán ánh xạ động 18
Hình 8. Topology mạng đƣợc sử dụng trong các thử nghiệm mô phỏng 28
Hình 9. Mô phỏng với 2 gói Video 29
Hình 10. Lấy kết quả mô phỏng 30

Hình 11. Vẽ đồ thị 30
Hình 12. Kết quả mô phỏng truyền 2 gói Video sử dụng 802.11e EDCA 31
Hình 13. Kết quả truyền 2 gói Video sử dụng Ánh xạ tĩnh 32
Hình 14. Kết quả truyền 2 gói Video sử dụng Ánh xạ động 33

6


Danh mục các ký hiệu và chữ viết tắt
Chữ viết tắt
Ý nghĩa
AC
Access Cagegory: Truy cập
B
Bidirectional Predicted Picture: khung B trong Video
CWmin
Contention Window
DSM
Digital Storage Media: lưu trữ nội dung đa phương tiện
EDCA
Enhanced Distributed Channel Access: phương pháp điều khiển truy cập nâng cao
GOP
group of picture: Nhóm ảnh
I
Intra – Picture: khung I trong video
MPEG
Moving Picture Expert Group: Tiêu chuẩn Video
P
Predicted – Picture: Khung P trong video


7


CHƯƠNG 1: GIỚI THIỆU
Để hỗ trợ những yêu cầu đa dạng về chất lƣợng dịch vụ của những ứng dụng thế hệ
mới, một chuẩn mới là IEEE 802.11e đã đƣợc quy định. Nó xác định bốn loại truy cập
AC (Access Category) có những ƣu tiên truyền dẫn khác nhau. Ƣu tiên truyền dẫn là
xác suất thành công trong việc tìm kiếm cơ hội để truyền tải khi từng loại truy cập
đang cạnh tranh để truy cập vào các kênh không dây, ƣu tiên truyền dẫn càng cao thì
càng có cơ hội đƣợc dẫn cao hơn. Tuy nhiên, trong một kênh không dây, việc mất mát
và chậm trễ trong truyền dữ liệu, băng thông hạn hẹp là những thách thức lớn của hiệu
quả truyền tải dữ liệu đa phƣơng tiện. Do đó, một số cơ chế tiên tiến đã đƣợc đề xuất
dựa trên chuẩn 802.11e để hỗ trợ truyền tải đa phƣơng tiện và cụ thể là truyền tải
Video. Hầu hết các cơ chế đƣợc đề xuất cải thiện hiệu suất bằng cách điều chỉnh các
hoạt động của 802.11e MAC, chẳng hạn nhƣ kích cỡ Contention Window,
TXOPlimit, và tốc độ truyền tải dữ liệu. Tuy nhiên, các cơ chế này không tính đến
mức độ quan trọng của những dạng lƣu lƣợng khác nhau (chẳng hạn nhƣ video), do
đó hạn chế các cải tiến hiệu về suất có thể đạt đƣợc.
Đối với lƣu lƣợng video, độ quan trọng của các dữ liệu video đƣợc mã hóa khác nhau.
Việc truyền tải ƣu tiên của video đƣợc mã hóa phân sẽ mang một vai trò quan trọng
trong việc hỗ trợ các dịch vụ đa phƣơng tiện trong một mạng không dây. Tuy nhiên,
802.11e cung cấp QoS thông qua phân phối lƣu lƣợng ở đó tất cả các dữ liệu video
trong cùng một loại truy cập. Kết quả là, cơ chế truy cập kênh và chƣơng trình truyền
không tính đến các thông tin về độ quan trọng của dữ liệu video. Nếu cơ chế truyền
dẫn khai thác các đặc điểm của nội dung dữ liệu video bằng cách xem xét các thông
tin có ý nghĩa video đƣợc tạo ra từ các lớp ứng dụng, dữ liệu video sẽ có dịch vụ ƣu
tiên và chất lƣợng đƣợc cảm nhận ở bên nhận có thể đƣợc cải thiện.
Các cơ sở lý thuyết liên quan đƣợc trình bày trong chƣơng 2 và chƣơng 3 bao gồm
những lý thuyết về chuẩn nén Mpeg – 4, tiêu chuẩn 802.11e EDCA và các thuật toán
ánh xạ tĩnh và ánh xạ động.

Chƣơng 4 là phần chính của luận văn, tập trung vào việc mô phỏng truyền Video qua
3 thuật toán 802.11e EDCA, ánh xạ tĩnh và ánh xạ động qua đó đánh giá hiệu suất của
các thuật toán và đánh giá lại gia trị các tham số trong thuật toán ánh xạ động, nhằm
tối ƣu việc truyền tải Video
8



CHƯƠNG 2: CƠ SỞ LÝ THUYẾT
2.1 CHUẨN NÉN MPEG-4
Chuẩn MPEG (Moving Picture Expert Group) là chuỗi chuẩn video với mục
đích mã hóa tín hiệu hình ảnh và âm thanh cho DSM (Digital Storage Media) tốc độ
từ 1.5 đến 50 Mbit/s và đƣợc biết đến nhƣ là: MPEG-1, MPEG-2, MPEG-4 Các
chuẩn MPEG tiến tới tối ƣu hóa cho các ứng dụng video động và các đặc điểm của nó
cũng bao gồm một thuật toán cho việc nén dữ liệu Audio với tỷ lệ là 5:1 cho tới 10:1.
Trong chuẩn MPEG, ngƣời ta định nghĩa các loại ảnh khác nhau cho phép sự linh
hoạt để cân nhắc giữa hiệu quả mã hóa và truy cập ngẫu nhiên. Các loại ảnh đó nhƣ
sau:
 Ảnh loại I (Intra – Picture): là ảnh đƣợc mã hóa riêng, ảnh I chứa dữ liệu để tái
tạo lại toàn bộ hình ảnh vì chúng đƣợc tạo thành bằng thông tin của chỉ một
ảnh. Ảnh I cho phép truy cập ngẫu nhiên, tuy nhiên đạt đƣợc tỉ lệ nén thấp nhất
 Ảnh loại P (Predicted – Picture): là ảnh mã hóa có bù chuyển động từ ảnh I
hoặc ảnh P phía trƣớc (ảnh dự đoán trƣớc). Ảnh P cung cấp các hệ số nén cao
hơn ảnh I.
 Ảnh loại B (Bidirectional Predicted Picture): là ảnh đƣợc mã hóa sử dụng bù
chuyển động từ ảnh I và ảnh P phía trƣớc và sau (ảnh dự đoán hai chiều). Ảnh
B có tỉ lệ nén cao nhất.
 Nhóm ảnh GOP (group of picture): đối với chuẩn MPEG, chất lƣợng ảnh
không những phụ thuộc vào tỷ lệ nén trong từng khuôn hình mà còn phụ thuộc
vào độ dài của nhóm ảnh. Nhóm ảnh là một khái niệm cơ bản của MPEG, nó là

đơn vị mang thông tin độc lập của MPEG.
Công nghệ MPEG sử dụng 3 loại ảnh I, P và B. Trong đó ảnh P và B không
phải là một ảnh hoàn chỉnh, mà chỉ chứa thông tin về sự khác biệt giữa ảnh đó
và ảnh trƣớc đói (đối với ảnh P), hay sự khác biệt với cả ảnh trƣớc và ảnh sau
nó (đối với ảnh B). Để có một khuôn hình hoàn chỉnh, ảnh P và ảnh B cần có
dữ liệu từ các ảnh lân cận, vì vậy MPEG đã đƣa ra khái niệm GOP. Mỗi GOP
bắt buộc phải bắt đầu bằng một ảnh hoàn chỉnh I và tiếp sau đó là một loạt các
ảnh P và B. Nhóm ảnh có thể mở (Open) hoặc đóng (Closed)
9



Hình 1. Cấu trúc GOP
Nhóm ảnh mở luôn bắt đầu bằng một ảnh I và kết thúc ở một ảnh trƣớc ảnh I
tiếp theo, có nghĩa là ảnh cuối cùng của GOP dùng làm ảnh đầu tiên của GOP
tiếp theo làm ảnh chuẩn.
Đối với cấu trúc khép kín, việc dự đoán ảnh không sử dụng thông tin của các
GOP khác. Trong trƣờng hợp này theo quy định, ảnh cuối cùng của một GOP
bao giờ cũng là ảnh P.
Nhóm ảnh đƣợc xác định bởi 2 thông số M và N. Thông số M xác định số
khung hình P và khung hình B xuất hiện giữa hai khung hình I gần nhau nhất.
Số N xác định số khung B giữa hai khung P.
Tỉ lệ nén Video của MPEG phụ thuộc rất nhiều và độ dài của GOP. Tuy nhiên
GOP dài thƣờng gây khó khăn cho quá trình tua, định vị, sửa lỗi Do đó tùy
thuộc vào từng khâu (sản xuất, dựng, truyền dẫn, phát sóng ) mà ta chọn độ
dài GOP thích hợp. Trong sản xuất hậu kì, nếu yêu cầu truy cập ngẫu nhiên
vào bất cứ ảnh nào, điều đó có nghĩa là yêu cầu truy cập chính xác đến từng
ảnh, GOP khi đó chỉ có ảnh loại I, trƣờng hợp này sẽ cho tỉ lệ nén rất thấp. Để
tăng tỷ lệ nén, số lƣợng ảnh P và B phải tăng lên, lúc này sẽ không cho phép
việc sử dụng hình cũng nhƣ làm kỹ xảo trên chuỗi ảnh đó. Trong trƣờng hợp

này GOP có thể bao gồm 12 ảnh.
10



Hình 2. Ví dụ về GOP MPEG

2.2 IEEE 802.11e EDCA (Enhanced Distributed Channel Access)
IEEE 802.11e EDCA phân loại lƣu lƣợng truy cập thành bốn AC (nhƣ minh họa trong
hình 2). Bốn loại truy cập bao gồm AC _VO (lƣu lƣợng truy cập Audio), AC_VI (lƣu
lƣợng truy cập video), AC_BE (lƣu lƣợng best efford), và AC _BK (lƣu lƣợng nền
(background)). Để đơn giản hóa các ký hiệu, ta đặt AC_VO là AC3, AC_VI là AC2,
AC_BE là AC1, và AC_BK là AC0. Mỗi AC có hàng đợi đệm riêng của nó và hoạt
động nhƣ một thực thể backoff độc lập. Ƣu tiên giữa các AC sau đó đƣợc xác định
bởi các thông số riêng của từng AC, đƣợc gọi là bộ tham số EDCA. Bộ tham số
EDCA bao gồm kích thƣớc tối thiểu của Contention Window (CWmin), kích thƣớc
tối đa của Contention Window (CWmax), Arbitration Inter Frame Space (AIFS), và
giới hạn cơ hội truyền (TXOPlimit). Các giá trị đƣợc chuẩn này khuyến cáo cho từng
thông số của cơ chế đƣợc trình bày trong bảng dƣới.
11



Hình 3. Bốn loại truy cập trong IEEE 802.11e
Các tham số 802.11e EDCD.
Priority
AC
Designation
AIFSN
CWmin

CWmax
TXOPlimit
3
AC_VO
Voice
2
7
15
0.003008
2
AC_VI
Video
2
15
31
0.006016
1
AC_BE
Best Effort
3
31
1023
0
0
AC_BK
Background
7
31
1023
0


Hình 3 trình bày các hoạt động trong 802.11e EDCA. AC với AIFS nhỏ nhất có ƣu
tiên cao nhất, và một trạm cần phải đƣợc trì hoãn hoạt động cho khoảng AIFS tƣơng
ứng của nó. Giá trị tham số (nhƣ AIFS CWmin và CWmax) càng nhỏ thì xác suất
đƣợc truy cập vào môi trƣờng truyền tải càng lớn. Mỗi AC trong một trạm hoạt động
nhƣ một trạm ảo cá thể: nó cạnh tranh để truy cập vào môi trƣờng truyền dẫn và bắt
đầu thủ tục backoff của nó một cách độc lập sau khi phát hiện các kênh rỗi trong
khoảng thời gian ít nhất một AIFS. Khi AC đụng độ nhau trong cùng một trạm, AC
với ƣu tiên cao hơn đƣợc cấp cơ hội để truyền tải, trong khi AC với ƣu tiên thấp hơn
12


sẽ gặp phải một cuộc đụng độ ảo, tƣơng tự nhƣ một vụ đụng độ thực tế xảy ra bên
ngoài trạm.

Hình 4. Các hoạt động của IEEE 802.11e EDCA

CHƯƠNG 3: THUẬT TOÁN ÁNH XẠ TĨNH VÀ ÁNH XẠ ĐỘNG
3.1 ÁNH XẠ TĨNH
Để hỗ trợ việc truyền tải theo chất lƣợng dịch vụ của một video đƣợc mã hóa theo cấp
bậc trên một mạng IEEE 802.11e, một kiến trúc theo thiết kế đa lớp đã đƣợc đề xuất.
Nhƣ thể hiện trong hình 4, các tác giả của kiến trúc này đề xuất một thuật toán ánh xạ,
dựa trên các đặc điểm kỹ thuật về lƣu lƣợng truy cập của IEEE 802.11e EDCA, và dữ
liệu video đƣợc mã hóa H.264 đƣợc phân bổ vào các hàng đợi AC đƣợc ƣu tiên khác
nhau tùy theo độ quan trọng của mã hóa video. Tuy nhiên, thuật toán này có tính tĩnh
và không thích ứng cao. Khi tải mạng nhẹ, các dữ liệu video đƣợc ánh xạ tới AC với
ƣu tiên thấp hơn sẽ dẫn đến sự chậm trễ không đáng có trong truyền dẫn và tổn thất
gói. Theo đó, nếu luồng video MPEG-4 đƣợc truyền đi nhƣ là lƣu lƣợng truy cập cho
các thuật toán ánh xạ đƣợc đề xuất trong [2], khung I sẽ luôn luôn đƣợc ánh xạ tới AC
[2], trong khi khung P sẽ đƣợc ánh xạ tới AC [1] và B khung sẽ đƣợc ánh xạ tới AC

[0]. Nếu hàng đợi AC[2] là rỗng (có nghĩa là tải lƣu lƣợng video nhẹ) một thuật toán
ánh xạ tĩnh nhƣ vậy sẽ dẫn đến sự chậm trễ truyền dẫn không cần thiết cũng nhƣ khả
năng mất gói cao nếu AC[1] và AC[0] bị đầy gần nhƣ cùng một lúc.
13



Hình 5. Kiễn trúc xuyên lớp

3.2 ÁNH XẠ ĐỘNG
Chúng tôi đề xuất một thuật toán ánh xạ xuyên lớp có tính thích ứng cao để nâng cao
chất lƣợng truyền tải video MPEG-4 qua mạng không dây IEEE 802.11e [3]. Trong
cách tiếp cận đa lớp đƣợc đề xuất, gói video MPEG-4 đƣợc tự động ánh xạ đến AC
thích hợp dựa trên mức độ quan trọng của dữ liệu video và tải lƣu lƣợng mạng. Bằng
cách khai thác phƣơng pháp ánh xạ xuyên lớp, chúng ta có thể ƣu tiên việc truyền tải
dữ liệu video cần thiết và cải thiện việc tận dụng không gian hàng đợi.
14



Hình 6. Kiến trúc của ánh xạ xuyên lớp
Hình trên mô tả kiến trúc xuyên lớp, và hiển thị các thông tin về độ quan trọng của dữ
liệu video đƣợc truyền từ lớp ứng dụng tới lớp MAC. Để đảm bảo chất lƣợng của
video đƣợc truyền tải, thuật toán ánh xạ chủ động phân bổ các đoạn video cho AC
phù hợp nhất ở lớp MAC dựa theo cả độ quan trọng của các loại video và tải lƣu
lƣợng mạng. Đối với dòng video MPEG-4, sự mất mát của các khung hình video quan
trọng hơn sẽ làm xấu đi chất lƣợng video đƣợc truyền đi. Ví dụ, một khung I bị mất sẽ
gây ra tất cả các khung hình trong cùng một GOP trở nên không mã hóa đƣợc, cùng
lúc đó, một khung B bị mất chỉ ảnh hƣởng đến chính nó. Dựa trên độ quan trọng của
khung hình video, độ ƣu tiên của các kênh truy cập đƣợc sử dụng để ƣu tiên các cơ

hội truyền tải ở lớp MAC đƣợc thiết lập với các khung I là cao nhất, độ ƣu tiên của
các khung P dƣới I nhƣng trên B, và các khung B đƣợc thiết lập ở mức ƣu tiên thấp
nhất. Để phân bổ dữ liệu video quan trọng vào hàng đợi AC ƣu tiên cao hơn trong lớp
802.11e MAC càng nhiều càng tốt, chúng tôi cung cấp các xác suất ánh xạ khác nhau,
đƣợc định nghĩa là Prob_TYPE, cho các loại khung hình video khác nhau theo mã
15


hóa độ quan trọng của nó. Nếu phân bổ một khung vào một hàng đợi ƣu tiên thấp hơn
là không thể tránh khỏi, xác suất phân bổ truyền tải của khung hình có độ quan trọng
thấp hơn là cao hơn so với khung hình video có độ quan trọng cao hơn. Loại khung
video ít quan trọng hơn sẽ đƣợc chỉ định Prob_TYPE lớn hơn. Kết quả là, đối với các
codec MPEG-4, Prob_B> Prob_P> Prob_I, và tất cả các xác suất có giá trị nằm giữa 0
và 1.
Hơn nữa, để chủ động thích ứng với những thay đổi trong tải lƣu lƣợng mạng, ta sử
dụng chiều dài hàng đợi MAC nhƣ là một chỉ dấu về tải trọng lƣu lƣợng mạng lƣới
hiện tại. Theo các đặc điểm kỹ thuật IEEE 802.11e, khi truyền qua mạng không dây
IEEE 802.11e, gói video MPEG-4 đƣợc đặt trong AC2 với cơ hội tốt hơn để truy cập
vào kênh so với các AC có ƣu tiên thấp hơn. Tuy nhiên, khi video tăng dòng, hàng đợi
này nhanh chóng ùn tắc và mất hình xảy ra. Vì lý do này, các thuật toán ánh xạ sắp
xếp lại các gói video nhận đƣợc trong thời gian gần nhất vào hàng đợi khác có độ ƣu
tiên thấp hơn, trong lúc hàng đợi của AC2 đang bị đầy. Ở đây hai tham số đƣợc áp
dụng, đó là threshold_low và threshold_high, để dự đoán trƣớc nhằm tránh các tắc
nghẽn có thể xảy ra bằng cách thực hiện trƣớc việc quản lý hàng đợi. Hai thông số
trên đƣợc áp dụng trong thuật toán của biểu thức sau đây:


Trong hàm này, xác suất ánh xạ theo hƣớng đi xuống đƣợc xác định trƣớc ở thời điểm
ban đầu của từng loại khung hình video, Prob_TYPE sẽ đƣợc điều chỉnh tùy theo
chiều dài hàng đợi hiện tại và các giá trị ngƣỡng, và kết quả sẽ là một xác suất ánh xạ

xuống mới, Prob_New. Các giá trị Prob_New càng cao, càng có nhiều cơ hội cho các
gói tin đƣợc ánh xạ vào một hàng đợi với ƣu tiên thấp hơn. Bảng dƣới liệt kê các ký
hiệu đƣợc sử dụng trong thuật toán đề xuất ánh xạ đa lớp thích ứng cao.
Thông số ký hiệu trong thuật toán đề xạ thích ứng cao
Prob_TYPE
Xác suất phân bổ của các khung video
16


e.g. Prob_I, Prob_P, Prob_B
Prob_New
Xác suất đƣợc tính lại
threshold_low
Ngƣỡng dƣới của chiều dài hàng đợi
threshold_high
Ngƣỡng trên của chiều dài hàng đợi
qlen(AC[2])
Chiều dài hàng đợi của Truy cập AC2

Khi một khung Video đƣợc truyền tới:
if(qlen(AC[2]) < threshold_low)
video packet -> AC[2];
else if(qlen(AC[2]) < threshold_high) {

RN = a random number generated from Uniform function (0.0, 1.0);
if(RN > Prob_New)
video frame -> AC[2];
else
video frame -> AC[1];
}

else if(qlen(AC[2]) > threshold_high){
if(RN > Prob_TYPE){
video frame -> AC[1];
else
17


video frame -> AC[0];
}


Trong các thuật toán ánh xạ đƣợc hiển thị trong hình 6, khi một gói tin video đến, đầu
tiên chiều dài hàng đợi của AC2 (qlen (AC [2])) sẽ đƣợc kiểm tra và so sánh với các
các giá trị ngƣỡng threshold_high và threshold_low. Nếu chiều dài hàng đợi thấp hơn
giá trị ngƣỡng thấp hơn, threshold_low (tải nhẹ), các dữ liệu video sẽ đƣợc ánh xạ tới
AC [2] (áp dụng cho mọi loại dữ liệu video đƣợc chuyển). Nhƣng nếu chiều dài hàng
đợi lớn hơn giá trị ngƣỡng lớn hơn, threshold_high (lƣu lƣợng tải video nặng) các dữ
liệu video đƣợc ánh xạ trực tiếp đến hàng đợi có độ ƣu tiên thấp hơn, AC [1] hoặc AC
[0]. Tuy nhiên, trong khi chiều dài hàng đợi của AC [2] nằm giữa khoảng
threshold_high và threshold_low, quyết định ánh xạ đƣợc xác định dựa trên cả xác
suất ánh xạ (prob_TYPE) và hiện trạng kích thƣớc bộ đệm của hàng đợi nhƣ đƣợc
đƣa ra bởi công thức (1). Do đó, các gói tin dữ liệu video sẽ đƣợc ánh xạ tới AC [2],
AC [1] hoặc AC [0] theo khả năng ánh xạ có tính đi xuống. Bằng cách khai thác một
sơ đồ ƣu tiên và chiến lƣợc quản lý chiều dài hàng đợi, các truyền dẫn sẽ đƣợc ƣu tiên
và tỷ lệ mất hình video sẽ đƣợc giảm thiểu, cùng đó là sự hiệu quả trong tận dụng tài
nguyên mạng.
18


Gói tin vào

Prob_Type
Tính toán lại xác suất Prob_N
Qlen[AC_N]
Lấy thông số
chiều dài hàng
đợi hiện tại
Qlen[AC_N]
N=2
Phân bổ xuống
AC thấp hơn
AC[N-1]
Prob_b >= RN N-1>=0
N=2
Lấy giá trị chiều dài hàng đợi
hiện tại qlen[AC_N] và tính
xác suất Prob_N
N, Maxqlen N=2Cho vào hàng đợi AC [N]
Kết thúc
N=N-1
< Threshold_low >= Threshold_high
1. If N=0
2. if qlen[AC_N]<maxqlen
&& Prob_N<RN
Prob_Type= xác suất phân bổ của
các khung I, P, B
Prob_N: xác suất tính ra để phân
bổ vào AC[N]
Qlen[AC_N]: chiều dài của hàng
đợi AC_ N
Maxlen: chiều dài tối đa của

Buffer size
RN: Số ngẫu nhiên

Hình 7. Thuật toán ánh xạ động
# 802.11e
proc getopt {argc argv} {
global opt
lappend optlist nn
for {set i 0} {$i < $argc} {incr i} {
set opt($i) [lindex $argv $i]
19


}
}

#1 mapping type (0: 802.11e, 1: static mapping, 2: dynamic mapping);
#2 number of voice flows (AC_3) ;
#3 number of video flows (AC_2) ;
#4 number of TCP flows (AC_1) ;
#5 number of CBR flows (AC_0) ;

getopt $argc $argv


set packetSize 1500
set max_fragmented_size 1024

set val(chan) Channel/WirelessChannel ;# channel type
set val(prop) Propagation/TwoRayGround ;# radio-propagation model

set val(netif) Phy/WirelessPhy ;# network interface type
set val(mac) Mac/802_11e ;# MAC type
set val(ifq) Queue/DTail/PriQ ;# interface queue type
set val(ll) LL ;# link layer type
set val(ant) Antenna/OmniAntenna ;# antenna model
set val(ifqlen) 50 ;# max packet in ifq
set val(rp) AODV
set opt(choice) $opt(0)
set opt(voiceflow) $opt(1)
set opt(videoflow) $opt(2)
set opt(TCPflow) $opt(3)
set opt(CBRflow) $opt(4)

Mac/802_11e set dataRate_ 1.0e6 ;# 1Mbps
Mac/802_11e set basicRate_ 1.0e6 ;# 1Mbps
20



set ns [new Simulator]

set f [open test.tr w]
$ns trace-all $f


# set up topography object
set topo [new Topography]
$topo load_flatgrid 500 500

# Create God

create-god 2

# create channel
set chan [new $val(chan)]

$ns node-config -adhocRouting $val(rp) \
-llType $val(ll) \
-macType $val(mac) \
-ifqType $val(ifq) \
-ifqLen $val(ifqlen) \
-antType $val(ant) \
-propType $val(prop) \
-phyType $val(netif) \
-channel $chan \
-topoInstance $topo \
-agentTrace OFF \
-routerTrace OFF \
-macTrace OFF \
-movementTrace OFF

21


for {set i 0} {$i < 2} {incr i} {
set node_($i) [$ns node]
$node_($i) random-motion 0
}

#MH(0) > MH(1) only tow host
$node_(0) set X_ 30.0

$node_(0) set Y_ 30.0
$node_(0) set Z_ 0.0

$node_(1) set X_ 200.0
$node_(1) set Y_ 30.0
$node_(1) set Z_ 0.0

#1st priority traffic (VoIP)
for {set i 0} {$i < $opt(voiceflow) } {incr i} {
set udpA_($i) [new Agent/UDP]
$udpA_($i) set prio_ 0
$ns attach-agent $node_(0) $udpA_($i)
set nullA_($i) [new Agent/Null]
$ns attach-agent $node_(1) $nullA_($i)
$ns connect $udpA_($i) $nullA_($i)

set voip_($i) [new Application/Traffic/CBR]
$voip_($i) attach-agent $udpA_($i)
$voip_($i) set packet_size_ 160
$voip_($i) set rate_ 64k
$voip_($i) set random_ false
$ns at 5.0 "$voip_($i) start"
$ns at 50.0 "$voip_($i) stop"
}

22


#2nd priority traffic (Video, Foreman)
for {set i 0} {$i < $opt(videoflow) } {incr i} {

set udp($i) [new Agent/my_UDP]
$ns attach-agent $node_(0) $udp($i)
$udp($i) set packetSize_ $packetSize
$udp($i) set_filename sd_foreman_$i
set null($i) [new Agent/myEvalvid_Sink]
$ns attach-agent $node_(1) $null($i)
$ns connect $udp($i) $null($i)
$null($i) set_filename rd_foreman_$i

set original_file_name($i) foreman_qcif.st
set trace_file_name($i) video($i).dat
set original_file_id($i) [open $original_file_name($i) r]
set trace_file_id($i) [open $trace_file_name($i) w]

set pre_time 0
set totalByte_I 0
set totalByte_P 0
set totalByte_B 0
set totalPkt_I 0
set totalPkt_P 0
set totalPkt_B 0

while {[eof $original_file_id($i)] == 0} {
gets $original_file_id($i) current_line

scan $current_line "%d%s%d%d%f" no_ frametype_ length_ tmp1_ tmp2_
set time [expr int(($tmp2_ - $pre_time)*1000000.0)]

if { $frametype_ == "I" } {
set type_v 1

23


set prio_p 1
set totalByte_I [expr int($totalByte_I + $length_)]
set totalPkt_I [expr int($totalPkt_I + $tmp1_)]
}

if { $frametype_ == "P" } {
set type_v 2
set prio_p 1
set totalByte_P [expr int($totalByte_P + $length_)]
set totalPkt_P [expr int($totalPkt_P + $tmp1_)]
}

if { $frametype_ == "B" } {
set type_v 3
set prio_p 1
set totalByte_B [expr int($totalByte_B + $length_)]
set totalPkt_B [expr int($totalPkt_B + $tmp1_)]
}

if { $frametype_ == "H" } {
set type_v 1
set prio_p 1
set totalByte_I [expr int($totalByte_I + $length_)]
set totalPkt_I [expr int($totalPkt_I + $tmp1_)]
}

puts $trace_file_id($i) "$time $length_ $type_v $prio_p

$max_fragmented_size"
set pre_time $tmp2_
}

set totalPkt [expr int($totalPkt_I+$totalPkt_P+$totalPkt_B)]
24


set totalByte [expr int($totalByte_I+$totalByte_P+$totalByte_B)]

close $original_file_id($i)
close $trace_file_id($i)
set end_sim_time $tmp2_
puts "end_sim_time: $end_sim_time"

set trace_file($i) [new Tracefile]
$trace_file($i) filename $trace_file_name($i)
set video($i) [new Application/Traffic/myEvalvid]
$video($i) attach-agent $udp($i)
$video($i) attach-tracefile $trace_file($i)

$ns at [expr 10.0 ] "$video($i) start"
$ns at [expr 50.0] "$video($i) stop"
$ns at [expr 50.0] "$null($i) closefile"
$ns at [expr 50.0] "$null($i) printstatus"

}

#3rd priority traffic (CBR)
for {set i 0} {$i < $opt(CBRflow) } {incr i} {

set udpB_($i) [new Agent/UDP]
$udpB_($i) set prio_ 2
$ns attach-agent $node_(0) $udpB_($i)
set nullB_($i) [new Agent/Null]
$ns attach-agent $node_(1) $nullB_($i)
$ns connect $udpB_($i) $nullB_($i)

set cbr_($i) [new Application/Traffic/CBR]
$cbr_($i) attach-agent $udpB_($i)
$cbr_($i) set packet_size_ 200
25


$cbr_($i) set rate_ 125k
$cbr_($i) set random_ false
$ns at 20.0 "$cbr_($i) start"
$ns at 35.0 "$cbr_($i) stop"
}


#4th priority traffic (TCP)
for {set i 0} {$i < $opt(TCPflow) } {incr i} {
set tcp($i) [new Agent/TCP]
$tcp($i) set prio_ 3
$ns attach-agent $node_(0) $tcp($i)
set sink($i) [new Agent/TCPSink]
$ns attach-agent $node_(1) $sink($i)
$ns connect $tcp($i) $sink($i)
set ftp($i) [new Application/FTP]
$ftp($i) set type_ FTP

$ftp($i) attach-agent $tcp($i)
$ns at 15.0 "$ftp($i) start"
$ns at 30.0 "$ftp($i) stop"
}

set n0_ifq [$node_(0) set ifq_(0)]
$n0_ifq set choice $opt(choice)
$n0_ifq set threshold1 10 # low threshold of queue length
$n0_ifq set threshold2 40 # high threshold of queue length
$n0_ifq set prob0 0 # Prob_I
$n0_ifq set prob1 0.6 # Prob_P
$n0_ifq set prob2 0.9 # Prob_B

$ns at 0.0 "record4"

26


set f4 [open
queuelength_choice_$opt(choice)_voice_$opt(voiceflow)_video_$opt(videoflow)_FT
P_$opt(TCPflow)_CBR_$opt(CBRflow).txt w]

proc record4 {} {
global ns n0_ifq f4
set time 0.01
set now [$ns now]
set qlen0 0
set qlen1 0
set qlen2 0
set qlen3 0

puts $f4 "$now [$n0_ifq set qlen0] [$n0_ifq set qlen1] [$n0_ifq set
qlen2] [$n0_ifq set qlen3] "
$ns at [expr $now+$time] "record4"
}



for {set i 0} {$i < 2} {incr i} {
$ns initial_node_pos $node_($i) 30
$ns at 50.0 "$node_($i) reset";
}

$ns at 50.0 "finish"
$ns at 50.1 "puts \"NS EXITING \"; $ns halt"


#INSERT ANNOTATIONS HERE
proc finish {} {
global ns f
$ns flush-trace
27


close $f
}

puts "Starting Simulation "
$ns run




CHƯƠNG 4: MÔ PHỎNG
4.1 KỊCH BẢN MÔ PHỎNG
Để đánh giá hiệu suất của thuật toán ánh xạ xuyên lớp, tôi đã tiến hành mô phỏng
bằng cách sử dụng hệ thống mô phỏng mạng đƣợc áp dụng rộng rãi NS-2, và tích hợp
với EvalVid. Các kết quả của các thuật toán ánh xạ đƣợc so sánh với các kết quả rút
ra từ IEEE 802.11e EDCA [1] và các thuật toán ánh xạ tĩnh trong [2]. Nguồn video
đƣợc sử dụng trong mô phỏng là YUV QCIF (176 x 144), Foreman. Mỗi khung hình
video đƣợc chia nhỏ thành các gói dữ liệu trƣớc khi truyền, và kích thƣớc tối đa của
gói tin truyền tải qua mạng mô phỏng là 1000 byte. Bảng dƣới cho thấy số lƣợng
khung hình video và số lƣợng gói tin của video gốc. Hình 8 trình bày mô phỏng cấu
trúc liên kết trong các thí nghiệm. Có tám nút không dây ad-hoc, một trong đó là máy
chủ chủ và một cái khác là máy nhận video. Tốc độ truyền dữ liệu của liên kết không
dây là 1Mbps.
Số lƣợng khung hình video và các gói tin của video gốc.
Video
Format
Frame number
Total
Packet number
Total
I
P
B
I
P
B
Foreman
QCIF
45

89
266
400
237
149
273
659

×