Tầng IP cung cấp các dịch vụ best-effort. Với best-effort các gói đƣợc truyền đi từ nguồn tới đích một cách nhanh nhất có thể. Hơn nữa, best-effort không đảm bảo bất cứ điều gì về độ trễ end to end của các gói, hay biến động trễ hay việc mất gói trong luồng dữ liệu.
Các ứng dụng đa phƣơng tiện tƣơng tác thời gian thực, nhƣ là điện thoại internet và hội nghị truyền hình thời gian thực thƣờng rất nhẩy cảm với trễ gói, biến động trễ và mất gói. Chính vì vậy cần phải có các kỹ thuật để đảm bảo các ứng dụng âm thanh hình ảnh khi truyền qua mạng mà các giá trị về trễ, jitter và mất gói không vƣợt quá mức quy định. Chúng ta sẽ xem xét một kỹ thuật trong ngữ cảnh là ứng dụng điện thoại Internet và trong hội nghị truyền hình thời gian thực thì cũng tƣơng tự.
Một ngƣời gọi điện trong ứng dụng VOIP sinh ra một tín hiệu âm thanh gồm có khoảng có âm và các khoảng lặng. Để tiết kiệm băng thông, ứng dụng điện thoại internet chỉ sinh ra các gói trong khi nói. Trong khi nói ngƣời gửi sinh ra các byte với tốc độ 8Kbyte/s, và cứ 20 ms ngƣời gửi tập hợp các byte thành các đoạn. Bởi vậy, số lƣợng byte trong một đoạn là (20ms).(8byte)=160 byte. Một đoạn đầu mào đƣợc gắn vào mỗi đoạn. Các đoạn và đầu mào của nó đƣợc đóng gói trong khung UTP, rồi các khung UTP đƣợc gửi tới giao diện Socket. Bởi vậy trong quá trình nói, một khung UTP đƣợc gửi định kỳ 20ms.
Nếu nhƣ mỗi gói truyền tới phía nhận với độ trễ cố định, các gói đƣợc nhận ở phía ngƣời nghe định kỳ 20ms trong quá trình nói. Trong điều kiện lý tƣởng, phía nhận có thể nghe lại các đoạn một cách đơn giản. Nhƣng, một số gói có thể bị mất và các gói sẽ không có cùng độ trễ, đặc biệt trong khi xẩy ra tắc nghẽn trên mạng. Vì vậy phía nhận phải quan tâm tới việc xác định khi nào diễn tả lại đoạn và xác định làm gì với các đoạn mất.
Hạn chế của dịch vụ Best-effort
Nhƣ đã đề cập dịch vụ best-effort có thể dẫn đến mất gói, trễ lớn và biến động trễ lớn. Bây giời ta sẽ xem xét vấn đề này một cách chi tiết hơn
Mất gói: Giả sử một khung UDP đƣợc sinh ra bởi ứng dụng VOIP. Các khung UDP đƣợc đóng gói trong IP packet. Khi các packet truyền đi trong mạng, nó phải đi qua các buffer (hành đợi) trong các router để đi tới đƣờng ra. Hoàn toàn có thể là một hoặc nhiều hàng đợi trong router bị đầy và không thể tiếp nhận các IP packet. Trong trƣờng hợp này, các IP packet sẽ bị loại bỏ và phía nhận sẽ không thể nhận đƣợc.
Mất gói có thể loại bỏ bằng cách gửi các gói thông qua TCP mà không dùng UDP. Bởi TCP truyền lại các gói không nhận đƣợc từ phía đích. Hơn nữa, kỹ thuật truyền lại không phù hợp với các ứng dụng tƣơng tác thời gian thực nhƣ là VOIP bởi vì chúng sẽ tăng độ trễ. Hơn nữa, bởi vì đặc tính điều khiển tắc nghẽn của TCP, sau khi gói mất tốc độ truyền tại phía gửi có thể giảm và làm cho tốc độ này nhỏ hơn tốc độ ở phía nhận. Điều này có thể có một số trở ngại trong vấn đề nhận dạng âm thanh tại phía thu. Với lý do đó, hầu hết các ứng dụng VOIP thƣờng chạy trên UDP và không thực hiện việc truyền lại gói tin.
Thực ra vấn đề mất gói không nghiêm trọng nhƣ chúng ra nghĩ. Thực ra, tỷ lệ mất gói nằm trong khoảng từ 1% đến 20% có thể chấp nhận đƣợc, dựa vào cách mà âm thanh mã hóa và truyền đi, và cách mà mất gói có thể che giấu ở phía thu. Ví dụ, forward error correction (FEC) có thể giúp cho việc che giấu đƣợc sự mất gói. Với FEC, các thông tin dƣ thừa đƣợc truyền cùng với thông tin gốc để mà một số dữ liệu gốc lỗi có thể khôi phục lại từ các dữ liệu dƣ thừa. Tuy nhiên, nếu một hoặc một số đƣờng link giữa ngƣời nhận và ngƣời gửi có tắc nghẽn, các gói mất vƣợt quá 20% thì khó có thể đảm bảo chất lƣợng âm thanh.
Trễ end to end:
Trễ end to end là gồm có trễ xử lý và trễ hàng đợi trên router, trễ lan truyền, và các trễ xử lý tại đầu cuối dọc theo đƣờng từ nguồn tới đích. Với những ứng dụng tƣơng tác cao, nhƣ là VOIP, trễ end to end nhỏ hơn 150ms thì ngƣời nghe sẽ không cảm nhận đƣợc; trễ giữa 150ms và 400ms có thể chấp nhận đƣợc nhƣng chƣa lý tƣởng; và trễ vƣợt quá 40 ms sẽ làm hỏng các cuộc hội thoại tƣơng tác bằng âm thanh.
Biến động trễ :
Một thành phần chủ yếu đối với trễ end to end là trễ hành đợi ngẫu nghiê trong một router. Bởi vì trễ là khác nhau trong mạng, thời gian từ lúc một gói đƣợc sinh ra ở nguồn cho đến khi nó nhận ở phía thu có thể giao động giữa các gói với nhau. Hiện tƣợng này đƣợc gọi là jitter.
Một ví dụ, giả sử hai gói liên tiếp nhau trong lúc phát tiếng nói đi vào ứng dụng VOIP. Ngƣời gửi gửi gói thứ hai 20ms sau khi gửi gói thứ nhất. Nhƣng ở phía nhận, khoảng thời gian giữa các gói có thể lên đến hơn 20ms. Để làm rõ điều này, giả sử gói đầu tiên ở gần hàng đợi trống của router, nhƣng sau khi gói thứ nhất rời đi thì tại hàng đợi có nhiều gói từ nguồn khác đến cùng hàng đợi đó. Do vậy gói thứ hai phải chịu độ trễ hàng đợi lớn hơn, gói thứ nhất và thứ hai trở nên xa nhau hơn 20ms. Khoảng thời
gian giữa các gói cũng có thể nhỏ hơn 20ms. Để thấy rõ điều này, lại giả sử 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 với một số lƣợng lớn các gói, và gói thứ hai đến hàng đợi trƣớc khi các gói từ nguồn khác tới. Trong trƣờng hợp này, hai gói đang xét sẽ ở gần kề nhau trong hàng đợi. Nếu nhƣ thời gian để truyền một gói trong đi ra ngoài nhỏ hơn 20ms thì gói thứ nhất và thứ hai sẽ cách nhau khoảng thời gian nhỏ hơn 20ms.
Nếu nhƣ phía nhận bỏ qua sự tồn tại của jitter, và khôi phục các đoạn nhƣ là những gì nhận đƣợc, khi đó sẽ dẫn đến chất lƣợng âm thanh trở nên không nhận ra tại phía thu. Tuy nhiên jitter có thể đƣợc loại bỏ bằng cách sử dụng sequence number, timestamps và plauout delay.
Loại bỏ jitter tại đầu thu đối với âm thanh
Đối với ứng dụng âm thanh nhƣ VOIP hoặc âm nhạc theo yêu cầu, phía nhận nên cung cấp khả năng phát đồng bộ các đoạn âm thanh khi mà vẫn tồn tại jitter mạng. Điều này thực hiện đƣợc bằng việc kết hợp ba kỹ thuật sau :
Gán vào mỗi đoạn một số liên tục. Ngƣời gửi tăng dãy số liên tục lên một đối với các gói tin sinh ra.
Gán cho mỗi đoạn một nhãn thời gian. Phía gửi gán mỗi đoạn một thời gian cho mỗi đoạn đƣợc sinh ra.
Hiển thị trễ các đoạn ở phía nhận. Hiển thị trễ các đoạn âm thanh nhận đƣợc phải đủ dài để cho các gói nhận đƣợc trƣớc khi lên lịch hiển thị. Trễ hiển thị có thể đƣợc cố định trong khoảng thời gian trong suốt toàn bộ thời gian hội nghị, hoặc có thể thay đổi tùy biến trong thời gian hội nghị. Các gói không đến đƣợc trƣớc khi thời gian lên lịch hiển thị sẽ bị coi là mất; nhƣ đã đề cập, phía nhận có thể sử dụng một số dạng nội suy tiếng nói để cố gắng làm ẩn đi sự mất gói.
Khôi phục lại gói mất:
• Chỉnh sửa dữ liệu phía người gửi (Sender-Based Repair)
Một số kỹ thuật chỉnh sửa dữ liệu với sự tham gia của bên gửi luồng dữ liệu có thể để phục hồi các gói bị mất. Các kỹ thuật này có thể chia thành hai loại: sự truyền lại tích cực và mã hoá kênh thụ động. Mã hoá kênh thụ động lại đƣợc chia làm hai dạng là sửa lỗi trƣớc (FEC: Forward Error Correction) và sự sắp xếp đan xen. FEC có thể là : không phụ thuộc môi trƣờng (media-independent) hay phụ thuộc môi trƣờng (media-specific). Sự phân loại này đƣợc thể hiện ở hình 1.3.
Sửa lỗi dựa trên ngƣời gửi
Chủ động Thụ động
Truyền lại Đan xen Sửa lỗi trƣớc
Phụ thuộc môi
trƣờng Độc lập môi trƣờng
Hình 1.3: Phân loại các kỹ thuật sửa đổi dữ liệu phía người gửi
Để đơn giản cho thảo luận tiếp theo chúng ta tách biệt khái niệm đơn vị dữ liệu và gói dữ liệu. Một đơn vị là một khoảng thời gian dữ liệu về âm thanh, chúng đƣợc lƣu trữ ở thiết bị đầu cuối tại công cụ audio. Một gói bao gồm một hay nhiều đơn vị liên kết với nhau để truyền dẫn trên mạng.
- Sửa lỗi trƣớc (Forward Error Correction)
Một số kỹ thuật hiệu chỉnh lỗi trƣớc đã đƣợc phát triển để khắc phục sự mất mát dữ liệu trong thời gian truyền dẫn. Bằng cách đƣa thêm dữ liệu vào luồng gửi đi ta có thể phục hồi đƣợc nội dung của các gói bị mất.
+ FEC độc lập với môi trƣờng (Media-independent FEC)
Có nhiều phƣơng pháp mã hoá FEC không phụ thuộc vào dữ liệu nhƣ là mã hoá đại số hay mã khối để thêm vào các gói tin trong quá trình truyền dẫn giúp chúng ta hiệu chỉnh sự mất gói. Mỗi mã có một từ mã riêng và kết hợp với k gói dữ liệu để tạo ra n-k gói kiểm tra, kết quả là số gói đƣợc truyền trên mạng là n gói.
1 2 3 4 Luồng gốc 1 2 3 4 FEC 1 2 4 FEC 1 2 3 4 Hiệu chỉnh lỗi trƣớc Mất gói Luồng khôi phục
Hình 1.4: Sửa đổi dữ liệu sử dụng FEC
Có rất nhiều cách mã hoá khối song ở đây chỉ đề cập đến hai cách là : mã hoá chẵn lẻ và mã Reed-Solomon. Các cách mã hoá khối này đầu tiên đƣợc sử dụng để phát hiện và hiệu chỉnh các lỗi trong luồng bít truyền dẫn bằng cách tạo ra các bít kiểm tra từ các bít dữ liệu. Một luồng các gói đƣợc truyền đi chúng ta quan tâm tới sự mất mát các gói tin của nó vì vậy chúng ta phải áp dụng cách mã hoá khối thông qua các
Trong mã hoá chẵn lẻ các thao tác XOR đƣợc áp dụng cho một nhóm các gói để tạo ra các gói tin chẵn lẻ phù hợp. Trong giản đồ hình 1.4 thì cứ n-1 gói dữ liệu lại truyền đi một gói chẵn lẻ. Với điều kiện chỉ mất một gói trong n gói dữ liệu đƣợc truyền đi thì gói mất đó sẽ đƣợc phục hồi lại. Có nhiều cách mã hoá chẵn lẻ khác nhau bắt nguồn từ sự tổ hợp khác nhau về XOR của các gói. Một vài cách mã hoá kiểu này đƣợc đề cập bởi Budge và đã đƣợc tổng kết bởi Rosenberg và Schulzrinne.
Mã Reed- Solomon (RS) rất nổi tiếng về việc hiệu chỉnh các lỗi. Việc mã hoá dựa trên thuộc tính của các đa thức. Bản chất của mã hoá RS là lấy một số từ mã và sử dụng chúng làm hệ số của đa thức f(x).
Phƣơng pháp FEC có nhiều ƣu điểm. Trƣớc tiên, về cách mã hoá độc lập với môi trƣờng, các thao tác của FEC không phụ thuộc vào nội dung gói tin và khi sửa chữa sẽ lập lại chính xác vị trí của gói tin bị mất. Các thao tác tính toán nhằm khắc phục gói tin bị mất và khôi phục chúng là rất đơn giản. Nhƣợc điểm của phƣơng pháp này là thêm độ trễ, tăng băng thông và công cụ mã hoá khó khăn.
+ FEC phụ thuộc vào môi trƣờng (Media-specific FEC)
Một cách đơn giản để chống lại sự mất gói tin là truyền mỗi khối audio trong nhiều gói. Nếu một gói bị mất thì nội dung của gói khác có khối tƣơng tự sẽ khôi phục lại gói bị mất đó. Nguyên lý này đƣợc minh hoạ trong hình 1.5. Cách làm này đƣợc đề nghị bởi Hardman và Bolot và đƣợc mở rộng bởi Podolsky.
1 2 3 4 Luồng gốc
1 1 2 2 3 3 4
1 1 2 3 4
1 2 3 4
Môi trƣờng riêng FEC
Mất gói
Khôi phục luồng
Hình 1.5: Sửa chữa sử dụng FEC phụ thuộc vào môi trường.
Bản sao truyền dẫn đầu tiên của dữ liệu audio đƣợc truyền nhƣ là mã hoá chính và sau đó truyền tiếp theo nhƣ là mã hoá phụ. Ta có thể gửi lƣợc đồ mã hoá phụ giống nhƣ lƣợc đồ mã hoá chính. Nhƣng thƣờng thì sơ đồ mã hoá phụ có băng thông nhỏ hơn và chất lƣợng thấp hơn sơ đồ mã hoá chính.
Lựa chọn sơ đồ mã hoá là vấn đề khó khăn và phụ thuộc vào cả yêu cầu băng thông và độ phức tạp tính toán của bộ mã hoá (Erdol sử dụng phƣơng pháp mã hóa và giải mã thông qua việc đo và thống kê các bit 0 (zero) trong khoảng thời gian ngắn).
9 10 12
chóng đƣợc mã hoá. Hardman và Bolot đề nghị sử dụng cách mã hoá phân tích-tổng hợp tốc độ bít thấp chẳng hạn nhƣ LPC (2,4-5,6 kb/s) và mã hoá GSM toàn tốc (13kb/s).
Nếu bộ mã hoá chính dùng bộ xử lý mạnh để cho ta chất lƣợng vừa phải và băng thông thấp thì bộ mã hoá phụ có thể sử dụng giống nhƣ bộ mã hoá chính. Một ví dụ của trƣờng hợp này là bộ mã hoá G.723.1 của hiệp hội viễn thông quốc tế ITU sử dụng một phần lớn sức mạnh tính toán của bộ xử lý cá nhân, nó cho ta độ rộng băng thông thấp (5,3/6,3 kb/s).
Sử dụng FEC phụ thuộc vào môi trƣờng thì ta phải chịu một tiêu đề gói lớn. Trong ví dụ sử dụng 8 kHz PCM (64 kb/s) nhƣ là sơ đồ mã hoá chính và GSM (13 kb/s ) làm mã hoá phụ thì kết quả là kích thƣớc của gói dữ liệu sẽ tăng thêm 20%. Giống nhƣ sơ đồ FEC độc lập với môi trƣờng thì tiêu đề của FEC phụ thuộc vào môi trƣờng có thể thay đổi. Tuy nhiên, không giống nhƣ các giản đồ mã hoá khác, tiêu đề của gói tin trong FEC phụ thuộc vào môi trƣờng có thể giảm đi mà vẫn có thể phục hồi đƣợc gói bị mất nhƣng với mức chất lƣợng thấp hơn. Giảm tiêu đề gói đã đƣợc sử dụng cho các ứng dụng audio.
Khác với nhiều công nghệ phía đầu gửi khác đã đƣợc thảo luận, sử dụng FEC phụ thuộc vào môi trƣờng có ƣu điểm là độ trễ thấp chỉ có độ trễ gói đơn đƣợc thêm vào. Điều này phù hợp cho các ứng dụng mang tính tƣơng tác.
- Đan xen (Interleaving)
Khi kích thƣớc của khối nhỏ hơn kích thƣớc của gói tin và trễ từ đầu cuối tới đầu cuối là không quan trọng, đan xen (interleaving) là kỹ thuật hữu ích cho việc giảm hiệu ứng mất gói. Trƣớc khi truyền các khối đƣợc sắp xếp lại. Các khối cạnh nhau đƣợc tách ra xa nhau với khoảng cách đảm bảo trong luồng đƣợc truyền dẫn và lập lại thứ tự các gói tin tại bên nhận. Đan xen làm giảm hiệu ứng mất gói. Nếu cho ví dụ các khối có chiều dài là 5ms và các gói chiều dài 20 ms (tức là 4 khối trong một gói) thì gói thứ nhất chứa các khối 1, 5, 9, 13; các khối của gói thứ hai là 2, 4, 6, 14. Thí dụ minh hoạ đƣợc thể hiện trên hình 1.6.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Luồng ban đầu
1 5 9 13 2 6 10 14 3 7 11 15 4 8 12 16
1 5 9 13 2 6 10 14 4 8 12 16
Đan xen luồng
Mất gói
Khi xuất hiện mất một gói đơn từ dòng lƣu lƣợng đƣợc đan xen thì kết quả là tạo ra nhiều các khe nhỏ trong dòng dữ liệu khôi phục, khác với xuất hiện một khe lớn trong dòng dữ liệu không đan xen.
Nhƣợc điểm của đan xen là nó làm tăng thêm độ trễ. Đây là giới hạn của sử dụng kỹ thuật cho các ứng dụng tƣơng tác. Bởi vậy nó thƣờng chỉ đƣợc sử dụng cho các ứng dụng không tƣơng tác. Ƣu điểm chính của đan xen là nó không yêu cầu dùng