CHƢƠNG 1 GIỚI THIỆU
1.3 Dịch vụ cố gắng tối đa (Best Effort) và truyền thông đa phƣơng tiện
1.3.2 Tổng quan các phƣơng pháp đảm bảo QoS cho truyền thông
1.3.2.1 Loại bỏ jitter ở phía nhận [4, 12]
Với một ứng dụng tiếng nói nhƣ điện thoại Internet…, phía nhận cố gắng cung cấp khả năng chạy đồng bộ các đoạn khi có jitter. Điều này có thể đƣợc thực hiện bằng cách kết hợp ba cơ chế sau:
Chèn một số tuần tự vào mỗi đoạn, phía gửi sẽ tăng số tuần tự lên 1 khi có một gói tin đƣợc tạo ra.
Gắn thêm một nhãn thời gian (timestamp) cho mỗi đoạn; phía gửi sẽ gán nhãn cho mỗi đoạn chính là thời điểm mà đoạn đó đƣợc tạo ra.
Làm trễ việc chạy ở phía nhận. Thời gian làm trễ phải đủ lâu để các gói tin phải đƣợc nhận trƣớc khi tới lƣợt (thứ tự) chúng đƣợc lập lịch chạy. Việc làm trễ có thể theo khoảng thời gian cố định hoặc thay đổi. Các gói tin không tới đƣợc phía nhận trƣớc thứ tự chạy của chúng đƣợc xem nhƣ là bị mất.
Có 2 phƣơng pháp làm trễ việc chạy ở phía nhận: tạm dừng cứng và tạm dừng thích
nghi.
Tạm dừng cứng (fixed playout delay)
Phía nhận thực hiện chạy mỗi đoạn đúng q ms sau khi đoạn đó đƣợc tạo ra. Nếu timestamp của một đoạn là t, phía nhận sẽ chạy đoạn đó tại thời điểm t + q (giả sử đoạn
30
tới phía nhận trƣớc thời điểm theo thứ tự nó đƣợc chạy), nếu đoạn có timestamp t đến sau thời điểm t+q, nó bị coi nhƣ đã mất.
Trong chiến lƣợc này, số tuần tự là không cần thiết. Việc quan trọng là lựa chọn đƣợc giá trị q tốt nhất. Nhƣ phần 1.3.1.2 đã trình bày, với ứng dụng điện thoại internet độ trễ cho phép lên tới 400 ms, còn đối với các ứng dụng audio tƣơng tác thì yêu cầu q nhỏ hơn.
Nếu tăng q thì tỉ lệ mất gói tin giảm (tốt), nhƣng QoS giảm điều này chúng ta cần phải cân nhắc
Nếu độ trễ E2E lớn thì dùng q lớn, nếu độ trễ nhỏ và jitter nhỏ thì dùng q nhỏ Nếu q << 400 ms, rất nhiều gói tin có thể bị coi nhƣ là bị mất, dù vẫn đến đích.
Hình 1.6: Mối quan hệ giữa thời gian tạm dừng và sự mất mát gói tin
Hình 1.6 minh họa mối quan hệ giữa thời gian tạm dừng và sự mất mát gói tin (gói tin bị coi là mất khi nó tới phía nhận sau thời điểm đƣợc chạy). Hình vẽ thể hiện thời gian mà tại đó gói tin đƣợc tạo và đƣợc chạy. Hai lựa chọn khác nhau về thời gian chạy đƣợc xét.
Đƣờng bậc thang bên trái: thời gian các gói tin đƣợc tạo ra và gửi đi, cách nhau 20ms.
Đƣờng bậc thang ở giữa: Trƣờng hợp làm trễ với thời gian ngắn (= p-r), gói tin thứ 4 tới phía nhận sau thời gian đƣợc lập lịch nên bị coi là mất.
Đƣờng bậc thang bên phải: Trƣờng hợp làm trễ với thời gian dài hơn (= p’-r) (p’
> p): toàn bộ các gói tin đều tới phía nhận trƣớc thời gian đƣợc lập lịch và đƣợc
31
Làm trễ thích nghi (adaptive playout delay)
Với chiến lƣợc tạm dừng cứng nêu ở trên, khi ta thiết lập một thời gian tạm ngừng lớn thì gần nhƣ tất cả các gói tin đều đƣợc gửi tới ngƣời nhận mà không xảy ra sự mất mát gói tin nào, tùy nhiên điều này sẽ làm cho độ trễ là lớn. Với các ứng dụng thoại internet thì độ trễ cao là điều không thể chấp nhận đƣợc, vì vậy cần có những biện pháp để để giảm tối đa thời gian trễ và vẫn đảm bảo sự mất mát gói tin là chấp nhận đƣợc.
Để giải quyết vấn đề trên, ta phải ƣớc lƣợng đƣợc độ trễ và jitter, từ đó điều chỉnh thời gian làm trễ tại lúc bắt đầu mỗi cuộc hội thoại. Sau đây là thuật toán mà phía nhận dùng để hiệu chỉnh thời gian làm trễ (playout delay) theo sự thay đổi của độ trễ và jitter.
Gọi ti là timestamp (thời điểm gói tin đƣợc sinh ra) của gói tin thứ i, ri là thời điểm gói tin thứ i tới phía nhận, pi là thời điểm gói tin thứ i đƣợc chạy ở phía nhận. Khi đó, độ trễ end-to-end của gói tin thứ i là ri – ti (giá trị này có thể đƣợc thay đổi với tùy gói tin). Gọi di là độ trễ trung bình cho tới khi nhận đƣợc gói tin thứ i, di đƣợc tính theo công thức:
di = (1-u) di-1 + u (ri - ti), với u là một hằng số (ví dụ u = 0.01).
Nhƣ vậy di chính là giá trị trung bình đã đƣợc làm trơn của các độ trễ r1 – t1, r2 – t2,.... ri - ti. Gọi vi là độ lệch trung bình giữa độ trễ và độ trễ trung bình, vi đƣợc tính theo công thức:
vi = (1-u) vi-1 + u | ri - ti - di |
di, vi đƣợc tính cho mỗi gói tin nhận đƣợc, mặc dù chúng chỉ đƣợc dùng để tính thời điểm chạy cho gói tin đầu tiên của mỗi đoạn hội thoại.
Sau khi tính đƣợc các ƣớc lƣợng này, phía nhận sẽ dùng thuật toán sau để tính thời điểm chạy cho các gói tin: Nếu gói tin i là gói tin đầu tiên của một đoạn hội thoại, thời điểm chạy của nó đƣợc tính theo công thức: pi = ti + di + K*vi trong đó K là hằng số dƣơng (ví dụ K = 4). K*vi đƣợc thêm vào để thiết lập thời gian chạy đủ lâu để chỉ một phần nhỏ các gói tin bị coi là mất do đến muộn. Thời điểm chạy của các gói tin trong đoạn đƣợc tính bằng timestamp của nó cộng với khoảng thời gian từ khi gói đầu tiên đƣợc sinh ra tại phía gửi đến lúc nó đƣợc chạy tại phía nhận. Cụ thể nhƣ sau: Đặt qi = pi - ti là thời gian từ khi gói tin đầu tiên đƣợc tạo ra (bên gửi) cho tới khi nó đƣợc chạy (bên nhận). Khi đó gói tin thứ j trong đoạn sẽ đƣợc chạy tại thời điểm pj = tj + qj.
Trong thuật toán trên ta đã giả sử rằng phía nhận biết đƣợc gói tin nào là gói tin đầu tiên đƣợc tạo ra. Nếu không có sự mất mát gói tin, phía nhận có thể xác định đƣợc điều này bằng cách so sánh timestamp của gói tin thứ i với timestamp của gói tin thứ i-1. Nếu ti - ti-1 > 20ms, thì phía nhận sẽ biết rằng gói tin thứ i là gói tin đầu tiên của đoạn hội
32
thoại. Nhƣng việc mất gói tin là hoàn toàn có thể xảy ra. Trong trƣờng hợp này, 2 gói tin nhận đƣợc trong cùng một đoạn cũng có hiệu 2 timestamp lớn hơn 20ms. Khi đó, số tuần tự trở nên hữu ích. Phía nhận có thể dùng số tuần tự để xác định khi hiệu hai timestamp > 20 ms, đâu là trƣờng hợp do gói tin đầu tiên đƣợc phát ra, đâu là trƣờng hợp do đã có sự mất mát gói tin. Cụ thể là: nếu ti - ti-1 > 20ms, và hai gói tin có số tuần tự liên tiếp nhau thì gói tin thứ i là gói tin đầu tiên của đoạn hội thoại, ngƣợc lại nếu hai gói tin không liên tiếp thì chắc chắn là có sự mất mát gói tin.
1.3.2.2 Khôi phục các gói tin bị mất
Nhƣ chúng ta đã nói ở phần 1.3 việc truyền lại gói tin bị mất là không phù hợp với ứng dụng thời gian thực nhƣ điện thoại Internet, vì có thực hiện truyền lại gói tin thì khi đến đích cũng đã quá hạn (deadline), gói tin đến sau thời điểm này là không có ý nghĩa. Có 2 kiểu lƣợc đồ lƣờng trƣớc mất mát là: sửa lỗi ở phía trƣớc - FEC và xen kẽ
(interleaving) [4, 12].
Sửa lỗi ở phía trƣớc - FEC
Ý tƣởng của FEC là thêm các thông tin bổ sung vào gói tin ban đầu, các thông tin này có thể đƣợc dùng để khôi phục các gói tin bị mất. Hiện nay ngƣời ta dùng 2 cơ chế FEC. Cơ chế thứ nhất: gửi một đoạn chứa thông tin bổ sung đƣợc mã hoá sau n đoạn. Đoạn chứa thông tin bổ sung đó thu đƣợc bằng cách thực hiện phép XOR n đoạn ban đầu. Theo cơ chế này, nếu một gói tin nào đó trong n + 1 gói tin bị mất, phía nhận có thể khôi phục hoàn toàn lại gói tin đó. Nhƣng nếu có hai hay nhiều gói tin bị mất, phía nhận sẽ không thể tái tạo lại đƣợc. Nếu để cỡ của khối đó (tức là n + 1) nhỏ, một phần lớn các gói tin bị mất có thể đƣợc khôi phục. Tuy nhiên, cỡ khối càng nhỏ, băng thông đƣờng truyền càng phải đƣợc tăng lên. Cụ thể, băng thông đƣờng truyền tăng theo hệ số 1/n. Ví dụ nếu n = 4, băng thông phải đƣợc tăng 25%. Lƣợc đồ này cũng làm tăng độ trễ bởi vì phía nhận phải nhận toàn bộ khối gói tin xong mới có thể thực hiện chạy chúng đƣợc. Cơ chế FEC thứ hai là gửi kèm một luồng âm thanh chất lƣợng thấp hơn luồng ban đầu nhƣ là luồng thông tin bổ sung (xem hình 1.3). Chẳng hạn, phía gửi tạo một luồng bình thƣờng (đƣợc mã hóa PCM với tốc độ 64Kbps) và một luồng tốc độ bit thấp (đƣợc mã hóa GSM, có tốc độ 13 Kbps). Phía gửi sẽ tạo ra gói tin thứ n bằng cách lấy đoạn thứ n của luồng bình thƣờng và đoạn thứ n-1 của luồng bổ sung. Khi có sự mất gói tin không liên tục, phía nhận có thể chạy đoạn mã hóa tốc độ bit thấp trong gói tin kế tiếp. Hiển nhiên là đoạn tốc độ bit thấp cho chất lƣợng âm thanh thấp hơn đoạn bình thƣờng, nhƣng trên tổng thể gồm nhiều đoạn tốc độ cao, một vài đoạn tốc độ thấp và không có sự mất mát các đoạn thì vẫn cho chất lƣợng âm thanh tốt. Trong lƣợc đồ này, phía nhận chỉ phải nhận 2 gói tin trƣớc khi thực hiện chạy chúng, vì thế phần độ trễ tăng thêm là nhỏ. Hơn
33
nữa, nếu mã hóa tốc độ bit thấp chiếm ít hơn nhiều so với mã hóa bình thƣờng, tốc độ truyền tăng không đáng kể.
Hình 1.3: Cơ chế thứ 2 của FEC
Để xử lý sự mất gói tin liên tiếp, một biến thể của cơ chế trên có thể đƣợc sử dụng. Thay vì chèn đoạn tốc độ bit thấp thứ n-1 vào đoạn bình thƣờng thứ n, phía gửi sẽ chèn đoạn tốc độ bit thấp thứ n-1 và n-2 , hoặc chèn đoạn tốc độ bít thấp thứ n-1 và thứ
n-3. Việc chèn càng nhiều đoạn bổ sung vào giúp cho các ứng dụng có thể đáp ứng đƣợc
trong nhiều môi trƣờng best-effort, tuy nhiên nó cũng làm tang băng thông cần sử dụng và làm tăng độ trễ.
Cơ chế xen kẽ (Interleaving)
Ứng dụng điện thoại Internet có thể gửi âm thanh theo kiểu xen kẽ, phía gửi sẽ xếp lại thứ tự các phần tử dữ liệu âm thanh trƣớc khi truyền, các phần tử sát nhau sẽ đƣợc xếp cách một khoảng cố định trong luồng truyền đi. Cơ chế này có thể làm giảm ảnh hƣởng của việc mất gói tin. Việc mất gói tin sẽ chỉ làm cho mỗi đoạn nhận đƣợc sau khi đƣợc khôi phục lại giảm chất lƣợng đi chút ít. Hình 1.4 minh hoạ cho cơ chế này. Mỗi đoạn chứa 4 phần tử, đoạn đầu tiên chứa các phần tử thứ: 1, 5, 9, 13; đoạn thứ 2 chứa phần tử thứ: 2, 6, 10, 14,.. Giả sử đoạn thứ 3 bị mất, các đoạn sau đó đƣợc tạo lại và mỗi đoạn bị mất đi một phần tử (phần tử thứ 3); chất lƣợng mỗi đoạn thu đƣợc chỉ bị giảm đi chút ít.
34
Hinh 1.4: Cơ chế xen kẻ
Cơ chế trên có thể cải thiện đáng kể chất lƣợng luồng nhận đƣợc. Bất lợi dễ thấy là tăng độ trễ bởi vì tất cả các đoạn cần phải đƣợc tạo lại trƣớc khi chạy. Đây là hạn chế của nó khi áp cho các ứng dụng tƣơng tác thời gian thực nhƣ điện thoại Internet; tuy nhiên nó thực hiện tốt cho các ứng dụng truyền audio/video đƣợc lƣu trữ trên server. Thuận lợi là nó không yêu cầu tăng băng thông.