Trong giảng dạy ở trường học, chúng ta có thể sử dụng video conference. Khi đó sẽ có thay đổi so với lớp học truyền thống. Có 2 trường hợp sử dụng phổ biến sau. Trường hợp đầu: Phía tham gia thêm vào lớp học có thể là một giảng viên nữa hoặc là đồng giảng viên. Trong trường hợp thứ hai, một giảng viên có thể giảng thêm cho một lớp học từ xa.
Hình 1.6. Nhiều giáo viên cùng giảng một lớp học sử dụng Video Conference
Hình 1.7. Một giáo viên giảng cho nhiều lớp học sử dụng Video Conference 1.5.3. Các cơ chế sử dụng trong Video Conference
Các cơ chế điều khiển hiển thị video
Voice Activated: Hình ảnh của bên đang nói được hiển thị tại tất cả các bên tham gia.
Continuous presence: Một bên tham gia có thể thấy tất cả các bên còn lại.
Các cơ chế điều khiển audio
Half duplex audio: Các bên chỉ có thể nghe thấy một người nói tại một thời điểm.
Full duplex audio: Mọi bên có thể nghe thấy tất cả các bên nói tại mọi thời điểm.
Không điều khiển: Sử dụng full duplex audio ở tất cả các bên tham gia. Trong trường hợp này, người đứng đầu được chọn do các bên tham gia tự thỏa thuận. Các bên tham gia có thể xem video theo kiểu voice-activated hoặc continuous presence.
Chair control: Quyền điều khiển được truyền qua cơ chế nào đó, thí dụ “biểu quyết bằng giơ tay”. Bên tham gia nắm quyền điều khiển sẽ được nhìn và nghe thấy bởi các bên cho tới khi quyền điều khiển được truyền cho người khác.
Lecture-style: Một biến thể của cơ chế chair control. Một bên được gán quyền điều khiển và có thể kích hoạt hoặc không kích hoạt quyền chair control.
1.6. Kết luận
Như vậy, chúng ta thấy rằng Video Conference là một ứng dụng rất hữu ích trong cuộc sống và đang được sử dụng rộng rãi trong các cơ quan Nhà nước, danh nghiệp... Video Conference giúp cho chúng ta có thể tổ chức hội họp, huấn luyện,.. mà không cần phải tập trung tại một vị trí nhất định, giảm thiểu tối đa thời gian phổ biến thông tin, tăng độ chính xác và nhanh chóng của các thông tin, giảm thiểu rủi ro về người và vật chất trong những cuộc hội họp,... đông phải di chuyển bằng phương tiện giao thông, giảm thiểu chi phí tài chính, nguồn lực cho việc đi lại, ăn ở, thông tin liên lạc bằng điện thoại, máy fax...
Để cho ứng dụng Video Conference phát huy được hiệu quả trong khai thác sử dụng thì yêu cầu về tài nguyên mạng cũng cần phải tốt để đảm bảo cho âm thanh và hình ảnh phải đạt được thời gian thực. Do vậy, để đạt được vấn đề này thì một số tham số liên quan đến chất lượng dịch vụ (mất gói tin, jitter và trễ) phải nằm trong một giới hạn cho phép. Thực tế, các thiết bị truyền hình của các hãng sẽ có giới hạn cụ thể đối với từng tham số này. Nhưng nhìn chung tỷ lệ mất gói tin không được quá 10% và độ trễ không quá 200ms thì chất lượng hình ảnh và âm thanh có thể chấp nhận được.
Trong chương tiếp theo, luận văn sẽ nghiên cứu các cơ chế để làm tăng chất lượng dịch vụ cho ứng dụng truyền thông đa phương tiện nói chung và ứng dụng Video Conference nói riêng.
Chƣơng 2
CÁC CƠ CHẾ ĐỂ LÀM TĂNG CHẤT LƢỢNG DỊCH VỤ CHO ỨNG DỤNG TRUYỀN THÔNG ĐA PHƢƠNG TIỆN
Như đã trình bày ở Chương 1, trong chương này, chúng tôi tập trung vào nghiên cứu và trình bày một số cơ chế đang được sử dụng trong mạng hiện nay để đảm bảo chất lượng dịch vụ truyền thông đa phương tiện được tốt trên mạng với đặc điểm Cố gắng tối đa,.... Dưới đây là chi tiết từng phần mà chúng tôi muốn trình bày trong chương này.
2.1. Những nhƣợc điểm của mạng IP với dịch vụ cố gắng tối đa
Dịch vụ cố gắng tối đa (best effort) được xây dựng dựa trên 3 nguyên tắc [7]:
1. Nhận tất cả các lưu lượng đưa vào mạng 2. Mọi lưu lượng được đối xử như nhau.
3. Mạng đảm bảo lưu lượng sẽ được truyền đi một cách tốt nhất mà nó có thể nếu có đủ tài nguyên.
Đặc điểm “cố gắng tối đa” có thể dẫn đến các nhược điểm sau:
- Mất mát gói tin: UDP là một trong những giao thức cốt lõi của giao thức TCP/IP. Dùng UDP, chương trình trên mạng máy tính có thể gửi những dữ liệu ngắn được gọi là datagram tới máy khác. Khi datagram truyền qua mạng, nó tới bộ đệm trong router. Có thể bộ đệm của rtouter đã đầy và không thể nhận datagram, khi đó nó bị loại bỏ, không tới được phía nhận và coi như bị mất.
Sự mất gói tin có thể được loại bỏ bằng cách gửi gói tin qua TCP. TCP sẽ truyền lại gói tin. Giao thức này đảm bảo chuyển giao dữ liệu tới nơi nhận một cách đáng tin cậy và đúng thứ tự. Tuy nhiên, cơ chế truyền lại là không thể chấp nhận được đối với ứng dụng thời gian thực như điện thoại internet bởi vì nó làm tăng độ trễ. Mặt khác, theo cơ chế điều khiển tắc nghẽn trong TCP, sau khi mất gói tin, tốc độ truyền tại phía gửi bị giảm đi, có thể thấp hơn tốc độ đọc phía nhận, điều này ảnh hưởng nghiêm trọng tới chất lượng âm thanh tại phía nhận. Vì vậy hầu hết ứng dụng điện thoại internet đều chạy trên UDP. Tuy nhiên, nếu đường truyền bị tắc nghẽn, tỉ lệ mất gói vượt quá một ngưỡng (ví dụ 10 – 20%) thì chất lượng âm thanh sẽ không chấp nhận được.
- Độ trễ end – to - end: Khoảng cách, tốc độ truyền dữ liệu và thời gian xử lý của các node mạng ảnh hưởng đến độ trễ này. Đây cũng là một nhược điểm của mạng IP với dịch vụ cố gắng tối đa
- Jitter: Là một trong những thành phần tạo nên độ trễ end – to – end, nó chính là sự biến động về độ trễ khi ta gửi các gói từ source đến destination. Đối với các ứng dụng như VoIP thì giá trị jitter càng nhỏ càng tốt.
Từ những nhược điểm nêu trên, các nhà thiết kế ứng dụng đã đưa ra các cơ chế làm tăng chất lượng của dịch vụ audio/video. Dưới đây luận văn sẽ trình bày các cơ chế này.
2.2. Sử dụng giao thức UDP ở tầng giao vận
Tầng giao vận trong mô hình kiến trúc TCP/IP có 2 giao thức chính là UDP và TCP. TCP là giao thức hướng kết nối, trong đó bao gồm các thành phần: điều khiển lỗi, điều khiển luồng, tránh tắc nghẽn. Đặc tính điều khiển lỗi của TCP yêu cầu tính đúng đắn và tính tuần tự của dữ liệu. Nghĩa là nếu một đoạn dữ liệu bị mất thì bên gửi sẽ phải gửi lại đến khi bên nhận thông báo là đã nhận được đoạn dữ liệu đó hoặc là nó hủy bỏ quá trình truyền và ngắt kết nối. Trong trường hợp xấu nhất thuật toán điều khiển tắc nghẽn của TCP sẽ coi gói tin bị mất như dấu hiệu của sự nghẽn mạng nên nó sẽ giảm tốc độ truyền bằng cách giảm kích thước cửa sổ nghẽn. Chính vì những lý do đó TCP sẽ làm tăng thời gian trễ của gói tin, tăng jitter trong luồng gói tin. Điều này đối với ứng dụng mạng thời gian thực là không chấp nhận được. Mặt khác TCP không hỗ trợ truyền multicast mà nhiều ứng dụng đa phương tiện như video conference có thể có nhiều người tham gia và cần có cơ chế truyền multicast [6].
Ngược lại với TCP, giao thức UDP là giao thức không có bộ điều khiển nghẽn, điều khiển lỗi, điều khiển luồng, là giao thức không tin cậy, không cung cấp thứ tự truyền nhận, là giao thức giao vận đơn giản. UDP chỉ cung cấp dịch vụ dồn kênh/phân kênh và phát hiện lỗi đơn giản. Các cơ chế truyền tin cậy đều do các dịch vụ ở tầng trên xử lý. Do đó bản thân giao thức này không gây trễ thêm như các thuật toán điều khiển nghẽn của TCP, và UDP hỗ trợ truyền multicast. Do đó UDP thích hợp trong việc truyền các dữ liệu đa phương tiện thời gian thực.
2.3. Loại bỏ jitter ở phía nhận
Đối với ứng dụng truyền thông đa phương tiện tương tác thời gian thực, chẳng hạn điện thoại Internet. Người nói chuyện trong điện thoại Internet tạo ra một tín hiệu audio gồm lúc nói lúc ngừng. Trong thời gian nói, người gửi tạo ra những byte với tốc độ là 8KBps (Bps: bytes/s), cứ 20ms người gửi nhóm các byte vào thành một đoạn (gói tin UDP hoặc TCP). Số lượng byte trong một đoạn là 20ms*8KBps = 160 Bytes. Một header đặc biệt được thêm vào mỗi đoạn. Mỗi đoạn cùng với header được đóng gói trong một đoạn UDP, rồi được gửi tới giao diện socket. Trong thời gian nói, cứ 20ms có một đoạn UDP được gửi đi. Tuy
nhiên, ở phía nhận, khoảng thời gian giữa các gói đến liên tiếp có thể hơn 20ms. Điều đó có thể giải thích như sau: giả sử gói đầu tiên đến khi hàng đợi đang trống, nên nó được xếp ở đầu hàng đợi của router, nhưng sau khi gói thứ nhất rời đi thì hàng đợi có nhiều gói từ các nguồn khác đến cùng hàng đợi đó. Do vậy khi gói thứ hai đến, hàng đợi đang có một số gói tin chờ được truyền đi, nó sẽ phải chịu độ trễ hàng đợi lớn hơn. Ngược lại trong trường hợp hai gói liên tiếp, trong đó gói thứ nhất đi vào phần cuối của hàng đợi đã có một số lượng lớn các gói, còn gói thứ hai đến hàng đợi trước khi các gói từ nguồn khác tới. Như vậy hai gói đang xét sẽ ở gần kề nhau trong hàng đợi và có thể hai gói sẽ cách nhau khoảng thời gian nhỏ hơn 20ms. Nếu chạy ngay những gói tin ngay khi nói tới phía nhận thì chất lượng audio thu được sẽ rất tồi. Vì vậy, phía nhận phải có các cơ chế để loại bỏ ảnh hưởng của jitter tại phía nhận: Phía nhận cố gắng cung cấp khả năng chạy đồng bộ các đoạn khi có xảy ra hiện tượng biến động trễ. Điều này có thể được thực hiện bằng cách kết hợp các cơ chế [6]:
Chèn số thứ tự vào mỗi đoạn, phía gửi sẽ tăng số thứ tự lên 1 khi có một gói tin được tạo ra;
Gán cho mỗi đoạn một nhãn thời gian. Phía gửi sẽ gán nhãn thời gian 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 được nhận trước khi 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.
Để làm trễ việc chạy phía nhận thường sử dụng hai phương pháp: làm trễ việc chạy với thời gian cố định và làm trễ việc chạy với thời gian thích nghi.
2.3.1. Làm trễ việc chạy với thời gian cố định
Phía nhận cố gắng thực hiện chạy mỗi đoạn đúng q(ms) sau khi đoạn đó
được tạo ra. Nếu nhãn của đoạn là t, trong trường hợp đoạn tới phía nhận trước thời điểm theo thứ tự nó được chạy, phía nhận sẽ chạy đoạn đó tại thời điểm
t+q, nếu nó tới sau thời điểm đó, nó bị coi như đã mất.
Trong cơ chế này, số thứ tự là không cần thiết. Điều cần quan tâm tới là giá trị q. Nếu q nhỏ hơn nhiều so với 400ms, rất nhiều gói tin có thể bị coi như là bị mất do jitter. Nếu độ trễ đầu cuối - đầu cuối lớn thì dùng q lớn, nếu độ trễ nhỏ và sự biến thiên độ trễ là nhỏ thì dùng q nhỏ chẳng hạn < 150ms.
Hình dưới đây minh họa mối quan hệ giữa thời gian làm trễ và sự mất gói tin (gói tin coi là mất khi nó tới phía nhận sau thời điểm được chạy theo lịch).
Hình 2.1. Sự phụ thuộc giữa tỉ lệ mất gói tin với thời gian làm trễ việc chạy q Hình vẽ thể hiện thời gian mà tại đó gói tin được tạo và được chạy. Phía gửi tạo gói tin cứ 20ms một lần. Gói tin đầu tiên tới phía nhận tại thời điểm r.
Theo cơ chế tạm ngừng thứ nhất, thời gian tạm ngừng là p-r, gói tin thứ 4 không tới phía nhận trước thời gian được lập lịch nên bị coi là mất. Trong khi đó ở cơ chế tạm ngừng thứ 2, thời gian tạm ngưng là p’-r, toàn bộ các gói tin đều tới
phía nhận trước thời gian lập lịch và coi như không có sự mất gói tin. 2.3.2. Làm trễ việc chạy với thời gian thích nghi
Với cơ chế làm trễ việc chạy với thời gian cố định, nếu thiết lập thời gian tạm ngừng lớn, các gói tin hầu như sẽ tới phía nhận trước thời gian chạy trong lịch nên không có mất mát gói tin. Tuy nhiên, với các ứng dụng tương tác thời gian thực như điện thoại Internet, Video Conference thì độ trễ lớn quá có thể khiến chất lượng không chấp nhận được. Vậy ta phải giảm thời gian tạm ngừng tới giá trị nhỏ nhất với ràng buộc là cho phép mất gói tin chỉ là vài phần trăm. Muốn vậy, ta cần đánh giá độ trễ mạng và sự biến thiên độ trễ (jitter), theo đó đ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. Cơ chế phía nhận thay đổi thời gian làm trễ được mô tả như sau:
Gọi ti là nhãn (thời điểm gói tin được tạo ra phía bên gửi) 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ễ đầu cuối - đầu cuối của gói tin thứ i là ri – ti. Tùy theo jitter, độ trễ này thay đổi khác nhau đối với mỗi gói tin. Gọi di là độ trễ trung bình cho tới gói tin thứ i. Chúng ta có thể sử dụng độ trễ trung bình được tính theo công thức sau: di = (1-u)di-1 + u(ri – ti) với u là hằng số nào đó (ví dụ u
= 0.1). Công thức này còn thường được gọi là bộ lọc thông thấp – LPF (Low
1 2 3 4 5
Pass Filter), có tác dụng làm giảm ảnh hưởng của các biến động tức thời của độ trễ đến độ trễ trung bình.
Gọi vi là độ lệch trung bình cho tới gói tin thứ i giữa độ trễ của gói tin thứ
i và độ trễ trung bình di.
vi= (1-u)vi-1 + u|ri-ti-di|
Các giá trị di, vi được tính cho mỗi gói tin nhận được tại phía nhận, để từ đó tính thời điểm chạy cho gói tin đầu tiên của mỗi đoạn thoại.
Sau khi tính các giá trị trên, giả sử gói tin thứ i là gói đầu tiên của đoạn
thoại nào đó, thời điểm chạy của nó tại phía nhận sẽ là pi=ti+di+Kvi, trong đó K là hằng số dương (ví dụ K = 4). Kvi được thêm vào để cho thời điểm chạy gói tin đủ lâu để các gói tin bị coi như bị mất là rất ít. Thời điểm chạy của các gói tin tiếp theo trong cùng đoạn thoại với gói tin đầu tiên sẽ là pj=tj+qi với 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). Trong cơ chế trên điều quan trọng là phải xác định đâu là đoạn đầu tiên của đoạn thoại. Nếu không có sự 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 nhãn của gói tin thứ i với nhãn 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 thoại. Nhưng khi việc mất gói tin xảy ra, thì khi ti-ti-1 > 20ms chưa chắc i đã là gói tin đầu tiên của đoạn thoại. Trong trường hợp này, 2 gói tin nhận được cũng có hiệu 2 nhãn lớn hơn 20ms. Vì thế, số thứ tự trong trường hợp này được sử dụng. Phía nhận có thể dùng số thứ tự để xác định trường hợp nào là gói tin đầu tiên, trường hợp nào là mất mát gói tin.
2.4. Khôi phục các gói tin bị mất tại phía nhận
Như đã nói ở phần trên chúng ta quan niệm rằng: Gói tin bị coi là mất nếu