QoScho dịch vụ IPTV

tài nguyên mạng. 3.2.2. Đánh giá chất lượng dịch vụ IPTV: Đối với IPTV giai đoạn hiện tại, các dịch vụ chủ yếu đước triển khai là dịch vụ liên quan đến video, do đó, chất lượng dịch vụ IPTV có thể được đánh giá qua việc đo lường chất lượng các dịch vụ này. Việc đo lường QoS ngoài việc đánh giá chất lượng dịch vụ còn có ý nghĩa quan trọng hơn là giúp theo dõi, phát hiện, định vị và xử lý khi có sự cố xảy ra làm ảnh hưởng đến chất lượng dịch vụ. 3.2.2.1. Mô hình đo lường QoS ITU-T: Một mô hình IPTV đơn giản bao gồm 3 phần: Head-end, mạng truyền dẫn và thiết bị đầu cuối khách hàng CPE (Customer Premise Equipment). + Head-end: bao gồm tất cả các thiết bị và ứng dụng cần thiết để tạo ra tín hiệu video và đưa chúng vào mạng truyền dẫn. + Mạng truyền dẫn: truyền tín hiệu video đến các CPE. + CPE: Là kết thúc của mạng IP (thường là STB), giải mã tín hiệu video và hiển thị video trên màn hình TV thông thường. Mô hình đo lường chất lượng được xây dựng dựa trên ba thành phần này. Hình 3.10: Mô hình đo lường chất lượng hệ thống IPTV Mô hình này có 4 điểm tham chiếu: + A: mã hóa video + B: Lớp IP ở head-end + C: Lớp IP ở CPE + D: giải mã video 3.2.2.2. Đo lường chất lượng Head-end Giả định rằng chất lượng tín hiệu video đầu vào là thuộc trách nhiệm của head-end. Chất lượng video đầu vào trước hết phụ thuộc vào chất lượng nguồn video (độ phân giải, kích thước ảnh, tốc độ frame… đã được đưa ra trong các chuẩn video). Dữ liệu được nén, mã hóa và đưa vào mạng IP phải đảm bảo tuân theo các quy tắc thích hợp. Những quy tắc này gồm có: số lượng gói tối đa cho mỗi dòng video, số lượng luồng video tối đa, băng thông tối đa cho mỗi dòng video, giao thức được sử dụng ở lớp transport, kích thước khung, kích thước gói. Việc đo lường các thông số của head-end giúp khoanh vùng các vấn đề QoS. Mạng IP chịu trách nhiệm đảm bảo cấp độ chất lượng thích hợp của luồng video được truyền tới khách hàng. 3.2.2.3. Đo lường chất lượng end-to-end: Thực hiện ở bộ giải mã của STB. Việc xác định chất lượng video ở STB sẽ cho phép đánh giá gần đúng nhất chất lượng mà user thật sự nhận được. Ngoài ra, end-to-end còn cho phép ước tính khả năng, chất lượng của mạng truyền dẫn IP, cung cấp khả năng tính toán hiệu suất mạng bất kỳ mức nào, ở điểm tập trung… dựa vào phân tích và sao sánh tương quan các số liệu thu được. Tham số Giá trị Thiết bị Mục đích Phương pháp đo lường. Vị trí đo lường Tốc độ frame của video Được yêu cầu trong các chuẩn video STB Chất lượng hình ảnh + Bằng các biện pháp mã hóa và giải mã đặc biệt trong khi dịch vụ đang hoạt động. + Lấy mẫu From A to D Buffer underflows N/A STB Chất lượng hình ảnh, chơi mượt +Khi dịch vụ đang hoạt động + Lấy mẫu + Đo lường các sự kiện underflow và tỉ lệ thời gian STB trong trạng thái underflow. D Tràn bộ đệm N/A STB Chất lượng hình ảnh, chơi mượt +Khi dịch vụ đang hoạt động + Lấy mẫu + Đo lường các sự kiện overflow và tỉ lệ thời gian STB trong trạng thái overflow. D Các tham số mã hóa N/A STB Chất lượng hình ảnh/ chất lượng dịch vụ +Khi dịch vụ đang hoạt động + Lấy mẫu N/A Bảng 3.6 : Các tham số đo lường chất lượng end-to-end Một số nhà cung cấp dịch vụ tích hợp chương trình đo lường chất lượng trong STB. Dựa vào các phản hồi (feedback) của STB gửi về định kỳ mà thu thập thông tin nhằm quản lý chất lượng dịch vụ. 3.2.2.4. Đo lường QoS của mạng IP: Mạng IP là một mạng đa điểm, đôi khi rất phức tạp với những kỹ thuật truyền dẫn khác nhau. Trong chồng giao thức TCP/IP, mạng IP gồm các giao ở lớp Internet và Network Access. Đo lường các tham số chất lượng của lớp IP cho phép xác định các giá trị yêu cầu của mạng từ đó tìm công nghệ truyền dẫn thích hợp để cung cấp chất lượng end-to-end . Việc đo lường ở lớp IP không liên quan đến FEC hay bất kỳ kỹ thuật sửa lỗi nào ở lớp trên, nó là các thông số khả năng mạng trước khi thực hiện các biện pháp sửa lỗi ở tầng trên. Các tham số QoS IP được lựa chọn để đo lường chất lượng cho IPTV được cho trong bảng sau: Tham số Thiết bị Mục đích Monitoring method Tỉ lệ mất gói (PLR). CPE (STB) Chất lượng hình ảnh, dự đoán thông tin bị mất của video. + Khi dịch vụ dang hoạt động thông qua kiểm tra các luồng RTP/RTCP hoặc số thứ tự (sequence number) của header gói tin. + Tổng hợp và báo cáo PLR định kỳ, khoảng 1 lần/1 phút. +Đê đo được PLR đòi hỏi phải phân tích số lượng gói tin lớn hơn 10 lần giá trị PLR dự đoán. Trễ mạng Đo ở CPE hoặc càng gần điểm truy nhập của user càng tốt Khả năng chơi mượt Kiểm tra luồng dữ liệu Jitter CPE (STB) Khả năng chơi mượt Kiểm tra luồng dữ liệu RTP/RTCP dựa vào định thời của header gói tin Thông lượng hướng xuống CPE (STB) Giám sát chất lượng Kiểm tra tín hiệu trong trường hợp chất lượng mã hóa xấu nhất hoặc đo thông lượng. Thông lượng hướng lên CPE (STB) Giám sát chất lượng. Đo thông lượng Bảng 3.7: Các tham sô đo lường chất lượng mạng IP 3.2.2.5. Một vài khái niệm thường dùng để đánh giá chất lượng IPTV: Trong cố gắn đánh giá chất lượng dịch vụ IPTV (chủ yếu là chất lượng các dịch vụ liên quan đến video), nhiều tổ chức đã đưa ra các mô hình và định nghĩa để đo lường chất lượng dịch vụ này. Các khái niệm thường gặp là V-Factor, điểm trung bình chất lượng MOS và chỉ số truyền thông MDI (Media Delivery Index). V-Factor: do MPQM nghiên cứu nhằm mô phỏng cảm nhận của con người về một dịch vụ video. MOS là đánh giá của người xem về chất lượng video. Cả hai khái niệm này đều dựa vào đo lường chất lượng video, độc lập với môi trường truyền dẫn và đều được dùng để thể hiện QoE của dịch vụ. Tuy nhiên, dựa vào các giá trị này, người ta có thể phần nào dự đoán được QoS của hệ thống. MDI là khái niệm được đưa ra để đánh giá riêng cho các dịch vụ video trên nền IP, đo lường MDI được xem là biện pháp đo lường chất lượng được sử dụng phổ biến nhất hiện nay cho IPTV. MDI gồm hai tham số chính: tỉ lệ mất mát truyền thông MLR (Media Loss Rate) và yếu tố trễ DF (Delay Factor). Giá trị MDI thường được biểu diễn là “DF:MLR”. MLR là số gói mất trong một đơn vị thời gian (thường là 1 giây) còn DF là jitter của hệ thống. Các tham số MDI là 2 trong các tham số NP, và là các tham số QoS IP có ảnh hưởng lớn nhất đến dịch vụ video, do đó, việc đo lường MDI cho phép đánh giá khả năng mạng để dùng cho dịch vụ IPTV. Kết hợp MDI với MOS hoặc V-Factor cho phép kiểm soát chất lượng dịch vụ, giám sát, phát hiện và định vị lỗi gây giảm chất lượng dịch vụ . 3.3. Giải pháp QoS cho dịch vụ IPTV: Để đảm bảo QoS cho IPTV cần phải dựa vào các yêu cầu chất lượng của dịch vụ này. Như đã nói ở trên, đối với IPTV trong thời điểm hiện tại, chất lượng IPTV chủ yếu là chất lượng các dịch vụ liên quan đến video. Cấu trúc mạng cung cấp dịch vụ IPTV gồm 4 phần (chương 1): mạng nội dung (head-end), mạng truyền tải (network), mạng gia đình (home network) và mạng quản lý (Middle ware). Hình 3.11 : Các thành phần của IPTV Về lý thuyết các biện pháp nhằm đảm bảo chất lượng dịch vụ cho IPTV cần được thực hiện trên tất cả các thành phần của của mạng này, tuy nhiên thực tế, kỹ thuật QoS thường tập trung ở mạng truyền tải, và đôi khi, người ta xem QoS chỉ gồm các kỹ thuật nhằm cải thiện khả năng của mạng. 3.3.1. Các biện pháp đảm bảo QoS IPTV ở Head-end : Việc đảm bảo chất lượng ở video head-end phải xuất phát từ chất lượng video và audio nguồn. Chất lượng video là vấn đề mang tính thương mại nhiều hơn kỹ thuật, đòi hỏi nhà cung cấp dịch vụ phải liên kết với đài truyền hình, nhà sản xuất nội dung để có được chất lượng đầu vào tốt nhất. Các source này sau đó được chuyển thành các định dạng chuẩn (SDTV, HDTV…) với các tỉ lệ màn hình khác nhau (4:3 hoặc 16:9) để tương thích với TV của khách hàng. Sử dụng các kỹ thuật nén là phương pháp quan trọng được sử dụng ở head-end, vừa đảm bảo chất lượng video, vừa đảm bảo lưu lượng luồng video/audio không quá lớn. Nhà cung cấp dịch vụ cần lựa chọn kỹ thuật nén và cấu hình phù hợp với yêu cầu dịch vụ cũng như khả năng của mạng truyền dẫn. Kỹ thuật nén thường được sử dụng đối với video là MPEG 4 part 2 và H.264. Với ưu thế có tỉ lệ nén cao, nhiều cấu hình lựa chọn, H.264 đang là giải pháp được sử dụng rộng rãi. Về nén audio, các kỹ thuật có thể được sử dụng bao gồm: Dolby Digital (AC-3) cho HDTV và AAC cho SDTV. Trong gói PES của video và audio có trường sync code (3 bit) nhằm phục vụ mục đích đồng bộ video và audio. Sử dụng RTP/RTCP cho phép quản lý phát hiện mất mát dữ liệu. 3.3.2. Các biện pháp đảm bảo QoS ở mạng quản lý: Middle ware là một phần vô cùng quan trọng để đảm bảo chất lượng dịch vụ của khách hàng, middle ware phải cung cấp các tính năng bảo mật, xác nhận, tính cước, giám sát hệ thống, đồng thời phải cung cấp một EPG đầy đủ tiện ích và thân thiện với người dùng. Mạng quản lý còn phải đảm bảo cung cấp đa dịch vụ và khả năng mở rộng. Sử dụng các software thích hợp để là biện pháp hữu hiệu nhất để đạt được các yêu cầu này. Các software thường được sử dụng bao gồm: MHP, GEM. OCAP, ACAP, ARIB B23. 3.3.3. Các biện pháp đảm bảo QoS ở Home network: Yếu tố ảnh hưởng lớn nhất đến chất lượng IPTV trong mạng gia đình là STB. Chất lượng STB sẽ quyết định cái mà khách hàng được xem. Một STB có chất lượng tốt phải có khả năng xử lý nhanh, chạy mượt, lướt lỗi, có thể giải mã được các chuẩn video khác nhau, hỗ trợ giải các kỹ thuật giải nén, cung cấp khả năng sửa lỗi, hoạt động ổn định, ngoài ra, còn phải có khả năng đáp ứng EPG, dễ sử dụng, dễ điều khiển… Mã sửa lỗi FEC được xem là một biện pháp rất hữu hiệu nhằm giảm tác động của lỗi truyền dẫn đối với dữ liệu thời gian thực IPTV, nơi mà TCP không thể dùng được. Nguyên tắc của FEC là thêm vào dữ liệu một chuỗi số “thừa”, bằng các tính toán thích hợp người ta có thể khôi phục lại bit lỗi trong một giới hạn lỗi nào đó. Mã FEC có thể là các mã truyền thống như Reed-Solomon, mã vòng CRC… hoặc các mã mới được đưa ra dùng cho IPTV (ex: DF Digital Fountain). Để sử dụng FEC đồi hỏi STB phải có khả năng hỗ trợ giải mã FEC. Khả năng của STB cũng tỉ lệ với giá thành, do đó, nhà cung cấp dịch vụ cần phải lựa chọn STB sao cho đáp ứng được yêu cầu của hệ thống mà vẫn có tính kinh tế. Tuy nhiên, đôi khi, STB là do khách hàng tự lựa chọn, trong trường hợp này, nhà cung cấp dịch vụ cần tiến hành tư vấn để khách hàng có sự lựa chọn tốt nhất. 3.3.4. Các biện pháp đảm bảo QoS ở mạng truyền dẫn: 3.3.4.1. NP và các biện pháp cải thiện NP: Các tham số NP được quan tâm bao gồm: băng thông, trễ, biến động trễ (jitter) và mất gói. Băng thông: IPTV được xem là một ứng dụng “ngốn băng thông”. Hình 3.12 : Băng thông của mạng truyền dẫn Băng thông lớn nhất của tuyến được xác định bằng băng thông của đường truyền yếu nhất (có băng thông nhỏ nhất). Các biện pháp nhằm tăng băng thông có thể dùng cho một dịch vụ: + Nâng cấp đường truyền: đây được xem là phương pháp hiệu quả nhất nhưng cũng là phương pháp tốn kém nhất. + Sử dụng các QoS class để phân luồng ưu tiên lưu lượng. Đây được xem là biện pháp hữu hiệu nhất, nhiều cơ chế khác nhau đã được đưa ra để thực hiện phương pháp này: Hàng đợi ưu tiên PQ (Priority Queuing), Hàng đợi tự chọn CQ (Custom Queuing), phân phối ToS trên cơ sở nhóm QoS hoặc trên cơ sở hàng đợi cân bằng trọng số WFQ (Weighted Fair Queuing), hàng đợi dựa theo lớp cân bằng trọng số CBWFQ (Class Base Weighted Fair Queuing), hàng đợi trễ thấp LLQ (Low Latency Queuing). + Nén frame dữ liệu ở layer 2: biện pháp này có hiệu quả tuy nhiên làm tăng thời gian trễ do tính phức tạp của các giải thuật nén. + Nén Header, đây cũng là một phương pháp rất hiệu quả nhất là trong trường hợp các gói tin có tỉ số dữ liệu/header nhỏ (RTP). Trễ đầu cuối đến đầu cuối (end-to-end delay): Trễ bao gồm trễ mạng cố định và trễ mạng biến đổi. Trễ có thể chia làm 4 loại: trễ xử lý (phụ thuộc vào tốc độ CPU, chế độ chuyển mạch IP, cấu trúc router, cấu hình của các giao diện vào và ra), trễ hàng đợi ( phụ thuộc vào số lượng và kích thước của các gói tin, băng thông của giao diện và cơ chế xếp hàng), trễ tuần tự (thời gian để frame có thể được đưa vào đường truyền vật lý), trễ lan truyền (thời gian để truyền gói tin qua môi trường vật lý). Hình 3.13 : Các loại trễ Các ứng dụng thời gian thực rất nhạy cảm với trễ, các dịch vụ như TV, VoD không quá nhạy cảm với trễ, tuy nhiên, trễ có ảnh hưởng rất lớn đến thời gian chuyển kênh của TV và các các lệnh play/pause/stop của VoD. Để giảm trễ thì người ta cũng dùng các biện pháp: nâng cấp đường truyền, phân lớp lưu lượng, nén frame và nén header. + Nâng cấp đường truyền, nâng cao băng thông giúp giảm thời gian trễ tuần tự do gói tin không phải chờ đợi để được đưa vào đường truyền. + Phân lớp lưu lượng: các ứng dụng nhạy cảm hơn với trễ sẽ được ưu tiên truyền trước. + Nén frame và nén header: giảm kích thước file, kích thước gói do đó thời gian truyền sẽ giảm xuống. Mất gói (Packet Loss): Có rất nhiều nguyên nhân dẫn đến mất gói, trong đó nguyên nhân chủ yếu là tràn bộ đệm của hàng đợi, ngoài ra, những nguyên nhân khác gồm có: bỏ gói ở hàng đợi đầu vào, router không nhận gói, overrun và lỗi frame. Hình 3.14: Mất gói do tràn bộ đệm hàng đợi Các dịch vụ của IPTV vô cùng nhạy cảm với mất gói. Mất gói sẽ dẫn đến suy giảm chất lượng video/audio nghiêm trọng. Nghẽn là nguyên nhân chính gây mất gói, các biện pháp giảm mất gói chủ yếu tập trung ngăn chặn nghẽn: + Nâng cấp đường truyền: băng thông đường truyền càng tăng thì nghẽn càng ít xảy ra, mất gói giảm. + Sử dụng các pháp phân lớp lưu lượng đảm bảo băng thông cho các dịch vụ nhạy cảm với mất gói. + Tăng kích thước bộ đệm hàng đợi: giảm mất gói nhưng lại làm tăng trễ. + Sử dụng phương pháp quản lý hàng đợi tích cực AQM (Active Queue Management):bao gồm kỹ thuật loại bỏ gói sớm ngẫu nhiên RED (Random Early Detection) và kỹ thuật loại bỏ gói sớm ngẫu nhiên theo trọng số WRED (Weight Random Early Detection). + Định hình lưu lượng (Traffic Shaping): tương tự như WRED nhưng gói tin không bị loại bỏ mà được gây trễ. + Chính sách lưu lượng: giới hạn tốc độ của các dịch vụ ít quan trọng nhằm phục vụ tốt nhất cho các dịch vụ nhạy cảm với mất gói. Biến động trễ (Jitter): Jitter gây ra do các gói tin đi trên mạng theo những đường khác nhau và được đối xử khác nhau, vì vậy mà thời gian trễ của chúng khi đến đầu thu cũng khác nhau. Phương pháp tốt nhất để giảm jitter là dùng bộ đệm giảm jitter, nơi mà các gói tin trễ ít hơn sẽ bị giữ lại để “chờ” các gói tin bị trễ nhiều hơn. Kết quả của việc này là làm tăng thời gian trễ. Với biện pháp này, jitter hầu như không còn ảnh hưởng đối với các dịch vụ không tương tác, tuy nhiên, đối với một dịch vụ mang tính tương tác, thời gian thực và cận thời gian thực như IPTV thì khi áp dụng phương pháp này cần phải có sự cân nhắc giữa jitter và delay. Phải lựa chọn kích thước bộ đệm sao cho cân bằng giữa hai giá trị này. 3.3.4.2. Các biện pháp đảm bảo QoS liên quan đến xử lý lưu lượng: Các biện pháp đảm bảo QoS liên quan đến xử lý lưu lượng là các biện pháp được xem là hiệu quả nhất và được sử dụng rộng rãi nhất. Đôi khi, khái niệm QoS còn được định nghĩa là: “Khả năng phân biệt đối xử với các lưu lượng khách nhau” (theo Cisco). Các biện pháp này còn được gọi là cơ chế QoS hay kỹ thuật QoS. 3.4. Kỹ thuật QoS: 3.4.1. Sự cần thiết của kỹ thuật QoS đối với dịch vụ IPTV: IPTV là một bước phát triển tiến lên hội tụ mạng viễn thông trên nền mạng IP, hội tụ đồng nghĩa với trong mạng sẽ có nhiều loại dữ liệu khác nhau của các dịch vụ có đặc điểm khác nhau. Hình 3.15: Mạng trước và sau hội tụ Trước khi diễn ra hội tụ, truyền hình và điện thoại có mạng truyền dẫn dành riêng, với chi phí đầu tư lớn, giá thành cao, bù lại có thể đảm bảo chất lượng dịch vụ cung cấp cho khách hàng. Sau khi hội tụ, IPTV và VoIP là những dịch vụ có yêu cầu chất lượng mạng đặt biệt cao (về thời gian trễ, băng thông…) và các dữ liệu khác được truyền qua chung trên một mạng, nếu tất cả dữ liệu trong mạng này đều được phục vụ theo “best effort” thì chất lượng của IPTV và VoIP sẽ không được đảm bảo. Vì vậy, các các cơ chế QoS là yêu cầu không thể thiếu để có thể việc triển khai dịch vụ. Việc thực hiện các cơ chế QoS có thể so sánh với các biện pháp giảm ùn tắc giao thông. Hình 3.16: Cơ chế QoS và các chính sách điều khiển giao thông Các cơ chế thường được dùng là phân luồng (giới hạn băng thông) và đặt chế độ ưu tiên. 3.4.2. Các bước thực hiện QoS: Quá trình thực hiện kỹ thuật QoS gồm 3 giai đoạn: + Xác định lưu lượng và yêu cầu ứng với lưu lượng đó: việc xác định có thể được xét trên mạng, mục đích kinh doanh và dựa vào SLA (Service Levels Agreement). + Chia lưu lượng thành các lớp QoS: ứng với các yêu cầu của từng loại lưu lượng. + Xác định chính sách QoS cho các lớp lưu lượng: đặt chế độ bảo vệ băng thông nhỏ nhất, thiết lập giá trị băng thông lớn nhất, xác định ưu tiên cho mỗi lớp, sử dụng các cơ chế QoS (ví dụ: cơ chế xếp hàng) để kiểm soát nghẽn. 3.4.3. Các cơ chế QoS: Các cơ chế QoS gồm có: chia lớp (classification), đánh dấu (Marking), quản lý nghẽn (congestion management), tránh nghẽn (congestion avoidance), lập chính sách và định hình lưu lượng (policing and shahing), tăng hiệu quả đường truyền (link efficiency). 3.4.3.1. Chia lớp: Xác định và chia lưu lượng thành các lớp khác nhau, việc chia lớp dựa trên rất nhiều yếu tố, các công cụ chia lớp thông thường là công nhận ứng dụng cơ sở mạng NBAR (Network-Based Application Recognition), định tuyến theo chính sách lưu lượng PBR (Policy-based routing), hoặc chia lớp dịch vụ dựa vào giao diện lệnh CLI ( Command-line Interface). Hình 3.17: Chia lớp lưu lượng 3.4.3.2.Đánh dấu: Hình 3.18 : Đánh dấu gói tin Đánh dấu còn được gọi là “tô màu” cho gói tin, đánh dấu mỗi gói tin như một thành phần của lớp QoS nhờ đó gói tin có thể nhanh chóng được nhận ra và truyền qua phần còn lại của mạng. Việc đánh dấu được thực hiện bằng cách thay đổi các bit trong DSCP, các bit trong trường tham chiếu IP hoặc các bit CoS. 3.4.3.3. Quản lý nghẽn: Phương pháp được sử dụng chủ yếu là dùng hàng đợi, dựa vào đánh dấu lớp QoS của gói tin mà xác định hàng đợi phù hợp. Hình 3.19 : Cơ chế quản lý nghẽn Dựa vào các thuật toán xếp hàng mà người ta đưa ra cấu trúc hàng đợi cho phép các gói tin nhạy cảm với thời gian như IPTV, VoIP được truyền trước. Một số thuật toán xếp hàng thường gặp: FIFO (Fist In Fist Out): đơn giản nhất và kém hiệu quả nhất, với một hàng đợi duy nhất, gói tin vào trước sẽ được truyền đi trước. Hình 3.20 : Thuật toán xếp hàng FIFO Hàng đợi ưu tiên PQ: Sử dụng nhiều hàng đợi, khá đơn giản, các hàng đợi có thứ tự ưu tiên khác nhau, gói tin của một hàng đợi chỉ được truyền khi các hàng đợi có mức ưu tiên cao hơn nó trống. Thuật toán xếp hàng này có thể khiến cho các hàng đợi có mức ưu tiên thấp bị “bỏ lại”. Hình 3.21: Thuật toán xếp hàng PQ Hàng đợi Round Robin (RB): sử dụng nhiều hàng đợi, không có tính ưu tiên, lần lượt từng packet của mỗi hàng đợi được truyền đi. Hình 3.22: Thuật toán xếp hàng RB Hàng đợi Round Robin có trọng số WRR (Weighted Round Robin): tương tự RB nhưng cho phép đặt chế độ ưu tiên, hàng đợi có mức ưu tiên cao hơn sẽ được truyền nhiều gói tin hơn. Hình 3.23: Thuật toán xếp hàng WRR Hàng đợi cân bằng trọng số WFQ (Weighted Fair Queuing): gần giống với PQ, tuy nhiên, băng thông được chia cho các hàng đợi theo tỉ lệ trọng số (mức độ ưu tiên) do đó tránh được trường hợp “đói” băng thông của các dữ liệu có độ ưu tiên thấp. Hàng đợi cân bằng trọng số phân lớp CBWFQ (Class-Based Weighted Fair Queuing): cùng cơ chế với PQ, tuy nhiên, cho phép phân chia băng thông theo các lớp dịch vụ đã được xác định. Mỗi hàng đợi tương ứng với một lớp dịch vụ. Hàng đợi hạn chế trễ LLQ (Low Latency Queuing): là hàng đợi CBWFQ với thêm một hàng đợi ưu tiên dành cho lưu lượng thời gian thực, hàng đợi này được bảo đảm trễ lan truyền thấp và băng thông ổn định. Hàng đợi này cũng được giữ ổn định để không gây ra nghẽn, nó không thể vượt quá băng thông giới hạn. LLQ là hàng đợi được sử dụng nhiều nhất, nó là sự kết hợp giữa PQ và CBWFQ cho phép đạt được các yêu cầu chất lượng của các dịch vụ thời gian thực thời gian thực của IPTV. 3.4.3.4. Tránh lỗi: Cơ chế tránh lỗi có thể được thực hiện bằng cách loại bỏ một số gói tin từ một hàng đợi chọn trước khi lưu lượng tăng cao theo sắp gây ra nghẽn. Hình 2.24: Cơ chế tránh lỗi Có hai cơ chế tránh lỗi phổ biến là loại bỏ gói ngẫu nhiên RED (Random Early Detection) và loại bỏ gói ngẫu nhiên theo trọng số WRED (Weighted Random Early Detection) và cảnh báo lỗi ECN (Explicit Congestion Notification). RED: là cơ chế bỏ gói ngẫu nhiên trước khi bộ đệm của một hàng đợi bị đầy. RED loại bỏ gói ngẫu nhiên, không có cơ chế phân biệt giữa các loại lưu lượng. RED dựa vào tỉ lệ giữa chiều dài trung bình trọng số của hàng đợi với kích thước bộ đệm mà đưa ra quyết định loại bỏ gói. RED dùng một cấu hình chung cho tất cả các hàng đợi: Hình 2.25 : Cấu hình RED WRED: phát triển từ RED, sử dụng các cấu hình loại bỏ gói khác nhau đối với các hàng đợi khác nhau theo mức độ ưu tiên, WRED là RED kết hợp với trường ưu tiên IP, DSCP. Ngoài ra, WRED còn có thể liên kết với CBWFQ tạo thành loaị bỏ gói ngẫu nhiên phân lớp CB-WRED ( Class-Based Weightd Random Early Drop). Số gói bị loại bỏ của các hàng đợi có ưu tiên cao hơn sẽ ít hơn ở các hàng đợi có ưu tiên thấp. Cấu hình loại bỏ gói của CB-WRED như sau: Hình 2.26: Cấu hình loại bỏ gói của CB-WRED Thông thường, các dịch vụ của IPTV được xếp và lớp có độ ưu tiên cao, do đó, CB-WRED rất thích hợp để đảm bảo QoS. ECN: sử dụng 2 bit trong trường ToS để cảnh báo về nguy cơ nghẽn. 3.4.3.5. Lập chính sách (policy) và định hình lưu lượng: Cơ chế lập chính sách và định hình lưu lượng thường được dùng để thay đổi điều kiện của lưu lượng trước khi truyền hoặc sau khi đã nhận được. Policy: khống chế lưu lượng mạng để đảm bảo rằng một loại lưu lượng nào đó nhận đúng băng thông của nó. Công cụ để thực hiện policy bao gồm policing phân lớp và cam kết tốc độ truy nhập CAR( Committed Access Rate). Hình 2.27 : Cơ chế lập chính sách cho lưu lượng Định hình: là cơ chế dùng để giới hạn tốc độ của luồng dữ liệu bằng cách sử dụng các hàng đợi, thường được sử dụng khi dữ liệu đi từ đường truyền có tốc độ cao đến đường truyền có tốc độ thấp. Hình 2.28 : Cơ chế định hình cho lưu lượng 3.4.3.6. Nâng cao hiệu quả đường truyền: Các cơ chế nén header, đặc biệt hiệu quả đối với header RTP, do đó, rất thích hợp với IPTV. Mô hình ứng dụng đảm bảo QoS mạng IP: Mô hình nỗ lực tốt nhất (Best Effort): là mô hình không có cơ chế QoS nào được áp dụng, chất lượng hoàn toàn phụ thuộc vào khả năng truyền dẫn của mạng. Mô hình tích hợp dịch vụ IntServ (Intergrated Services): ứng dụng thông báo với mạng về yêu cầu QoS của mình. Mô hình phân biệt dịch vụ DiffServ (Difference Services): mạng nhận dạng dữ liệu và yêu cầu QoS ứng với dữ liệu đó. IntServ: Mô hình tích hợp dịch vụ là một cấu trúc cho phép đảm bảo chất lượng cho các dịch vụ có yêu cầu đặc biệt về băng thông và độ trễ, chẳng hạn các dịch vụ video của IPTV. IntServ còn được biết đến là QoS “cứng” (Hard Qos), gồm 2 thành phần chính là giao thức dành trước tài nguyên RSVP (Resource Reservation Protocol) và Điều khiển quản lý cuộc gọi CAC (Cal Control Adminssion). RSVP: được xem là trung tâm của mô hình IntServ. Nó được dùng để một dịch vụ thông báo về yêu cầu của mình, mạng xác định tài nguyên có đủ cung cấp hay không và nếu có đủ thì cho phép dịch vụ “giành trước” tài nguyên. RSVP hỗ trợ các loại bản tin: PATH, RESV, Error and Confirmation, Teardown Hình 2.29: Các bản tin RSVP Bản tin dẫn đường PATH (Path messages): bản tin dùng để lưu lại trạng thái đường truyền ở mỗi node, giúp định tuyến cho các bản tin yêu cầu chiếm dụng ở hướng ngược lại. Bản tin yêu cầu chiếm dụng RESV (Reservation-request messages): bản tin được đầu nhận (receiver) gửi trở lại cho đầu gửi (sender), bản tin phải được gửi đến sender qua các tuyến có trạng thái chiếm dùng được với mục đích yêu cầu thiết lập trạng thái “giành” tài nguyên. Bản tin báo lỗi và xác nhận (Error and Comfirmation messages): gồm các bản tin trả lời cho RESV và PATH. RESV: bản tin xác nhận được gửi đi cho biết đường truyền có khả năng đáp ứng và có thể bắt đầu thực hiện “giành trước” tài nguyên. Các bản tin lỗi bao gồm: gửi thất bại, không đủ băng thông, dịch vụ không cho phép, luồng dữ liệu không phù hợp và đường đi không xác định. PATH: chỉ được trả lời khi xảy ra lỗi trong quá trình truyền từ sender đến receiver. Bản tin xóa chiếm dùng TearDown: là bản tin dùng để gỡ bỏ trạng thái chiếm dùng, có thể được gửi đi bởi một ứng dụng hay hệ thống ở cả sender và receiver, gồm có bản tin xóa trạng thái dẫn đường (path-teardown messages) và bản tin xóa trạng thái chiếm dùng (reservation-request teardown message). CAC được dùng để đảm bảo không có lưu lượng mới chiếm phần tài nguyên đã được giành trước. Hình 3.30: Mô hình ứng dụng chất lượng dịch vụ IntServ IntServ có thể được ví như sử dụng máy bay hay xe tải riêng cho việc vận chuyển hàng hóa, nó an toàn, hiệu quả nhưng rất tốn kém. Trong mô hình IntServ, RSVP có thể dùng kết hợp với các cơ chế xếp hàng thông minh để cung cấp các cấp độ cho dịch vụ: Best-Effort: không sử dụng các cơ chế QoS Đảm bảo tốc độ (Guaranteed-rate) theo cấp độ dịch vụ: cho phép dịch vụ sử dụng đủ băng thông để đảm bảo yêu cầu chất lượng của nó. Đảm bảo tốc độ được thực hiện bằng cách kết hợp RSVP với hàng đợi LLQ. Điều khiển tải (Controlled-load) theo cấp độ dịch vụ: cho phép các dịch vụ đạt được trễ nhỏ và thông lượng lớn, thậm chí trong thời gian xảy ra nghẽn. RSVP và WRED được sử dụng kết hợp để cung cấp điều khiển tải. Nhược điểm của IntServ là chi phí cao và không có khả năng mở rộng (RSVP là tín hiệu liên tục, đảm bảo QoS cho một các dòng dữ liệu trên mạng diện rộng sẽ tạo ra hàng nghìn dòng tín hiệu RSVP). DiffServ: Là mô hình QoS khắc phục được những nhược điểm của cả Best-Effort và IntServ. Cung cấp “gần như đảm bảo” QoS, trong khi vẫn giữ được chi phí hợp lý và có khả năng mở rộng. DiffServ còn được gọi là QoS “mềm” (Soft QoS). Với Soft QoS, các cơ chế QoS được thực hiện mà không sử dụng báo hiệu. Các tham số QoS (ví dụ băng thông và trễ) được quản lý theo chính sách độc lập ở từng vùng của mạng mà không được quản lý end-to-end. Lưu lượng trên mạng được chia thành các lớp trên cơ sở các yêu cầu về kinh tế, mỗi lớp được chỉ định một cấp độ dịch vụ, khi gói tin được truyền qua mạng, các thiết bị mạng xác định gói tin đó thuộc lớp nào mà có cách “đối xử” phù hợp. Có thể liên hệ DiffServ với dịch vụ vận chuyển bưu kiện, đường đi, phương tiện vận chuyển và “cách đối xử” đối với gói tin là do khách hàng lựa chọn, nếu muốn bưu kiện được gửi nhanh và an toàn thì khách hàng phải chấp nhận chi phí cao hơn. DiffServ có thể cung cấp rất nhiều lớp dịch vụ khác nhau và có khả năng triển khai diện rộng, tuy nhiên, nhược điểm của DiffServ là chất lượng dịch vụ không được bảo đảm end-to-end và đòi hỏi các cơ chế hoạt động phức tạp. Các gói tin thường được phân lớp dựa vào trường DSCP (Differential Service Code Point), DSCP (trường gồm 6 bit) thay thế IP Precedence. Hình 3.31: DSCP Những gói tin được chia vào cùng lớp tạo thành nhóm hành vi BA (Behavior Aggregate), mỗi nhóm hành vi này được chỉ định cách “đối xử” tại Hop PHB (Per Hop Behavior), mỗi PHB sử dụng một hay một nhóm các cơ chế QoS. Hình 3.32 : DSCP và các PHB Các PHP dùng trong DiffServ: PHB mặc định (Default PHB): FIFO, loại bỏ gói tin mới đến, sử dụng dịch vụ Best-Effort. Chuyển tiếp khẩn cấp EF (Expedited Forwarding PHB): sử dụng cho các dịch vụ nhạy cảm với trễ. Chuyển tiếp đảm bảo AF (Assured Forwarding PHB): sử dụng cho những dịch vụ cần băng thông ổn định Chon lớp (Class-selector PHB): sử dụng đối với các thiết bị không hỗ trợ DiffServ. Trong mô hình QoS DiffServ, mạng được chia thành các miền QoS (QoS Domain), mỗi miền QoS có các router biên và router lỗi, router biên chịu trách nhiệm nhận lưu lượng, dựa vào Code point (mã điểm) QoS trong DSCP ban đầu của nó mà ấn định một code point mới (code point riêng) phù hợp với khả năng phục vụ của miền, router lõi chỉ chứa các bảng PHB để có cách ứng xử phù hợp với các gói tin có code point khác nhau. Hình 3.33: Mô hình DiffServ Quá trình xử lý gói tin ở Edge được thực hiện ở khối điều khiển lưu lượng, sử dụng các biện pháp đo lường khác nhau để “đo đạt” tình trạng mạng và áp dụng chính sách phù hợp đối với gói tin. Code point của một gói tin có thể được giữ nguyên hay bị thay đổi tùy theo khả năng phục vụ của mạng. Hình 3.34: Khối điều khiển lưu lượng DiffServ Mô hình kết hợp: Thực tế, người ta có thể dùng kết hợp Intserv và Diffserv: Hình 3.35: Mô hình kết hợp IntServ và RSVP Mô hình này vừa tận dụng được khả năng bảo đảm QoS end-to-end của IntServ vừa cho phép mở rộng và giảm chi phí. CHƯƠNG 4: MÔ PHỎNG CƠ CHẾ QOS WRED CHO IPTV BẰNG PHẦN MỀM NS2 Sử dụng NS2 kết hợp với bộ công cụ Evalvid cho phép mô phỏng và đánh giá chất lượng các dịch vụ video của IPTV. Thực hiện so sánh chất lượng dịch vụ trước và sau khi áp dụng các mô hình QoS để thấy được hiệu quả của các mô hình này. 4.1. Phần mềm NS2 (Network Simulation Version 2): 4.1.1. Giới thiệu: NS2 là phiên bản thứ hai của phần mềm mô phỏng mạng NS (Network Simulator). NS 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 (discrete event object-oriented) được phát triển tại UC Berkely, viết bằng ngôn ngữ C++ và OTcl. NS2 là phần mềm mã nguồn mở được xây dựng trên cơ sở hệ điều hành UNIX/LINUX. NS2 được sử dụng chủ yếu cho mục đích nghiên cứu và học thuật, bao gồm rất nhiều gói được phân phối bởi các nhóm phát triển phi lợi nhuận. NS2 cung cấp khả năng thiết kế giao thức mới, so sánh các giao thức cũ, cho phép mô hình các mạng lớn mà gần như không thể thực thi trong thực tế. Tuy nhiên, vì là mã nguồn mở, độ tin cậy của NS2 không cao và vẫn đang được cải thiện. 4.1.2. Cấu trúc của NS2: Có thể tưởng tượng user đang đứng ở góc trái bên dưới, thiết kế và chạy các mô phỏng bằng Tcl (Tool Command Language). Tcl dùng các đối tượng mô phỏng trong OTcl (Object Tcl). Các đối tượng lịch sự kiện (Event Scheduler) và hầu hết các đối tượng thành phần mạng (network components) thực thi bằng C++ và được liên kết với OTcl qua TclCL. Hình 4.1: Cấu trúc NS2 NS2 xử lý các câu lệnh trong kịch bản Tcl và đưa ra kết quả là file “dấu vết” (Trace File). Để đạt được yêu cầu mô phỏng, file trace này phải được xử lý bằng công cụ thích hợp. Có nhiều công cụ được đưa ra để xử lý file trace, tùy theo nhu cầu mà sử dụng các ngôn ngữ grep, awk (xử lý lọc, tính toán), NAM ( minh họa), hoặc Xgraph (vẽ đồ thị)… Hình 4.2: Quá trình mô phỏng NS2 4.2. Bộ công cụ Evalvid: 4.2.1. Giới thiệu bộ công cụ Evalvid: Evalvid là bộ công cụ được phát triển bởi nhóm mạng viễn thông TKN (Telecommunication Networks Group) thuộc đại học kỹ thuật Berlin (Technical University of Berlin). Evalvid cung cấp một bộ công cụ hoàn chỉnh để đánh giá chất lượng truyền dẫn video qua mạng thực tế hoặc mạng mô phỏng Hình 4.3: Hoạt động của bộ công cụ Evalvid Để đánh giá chất lượng video qua mạng, tồn tại hai phương pháp: đánh giá video ở đầu thu (đánh giá chỉ dựa vào video thu được – không thể đánh giá chính xác ảnh hưởng của mạng truyền dẫn đối với video), đánh giá ở đầu phát (so sánh video ở đầu thu và đầu phát (phải truyền lại video đầu thu về đầu phát – rất tốn băng thông, không khả thi). Evalvid là biện pháp cho phép đánh giá bằng so sánh ở đầu phát mà chỉ cần truyền một phần nhỏ thông tin từ đầu thu trở lại. Thông tin được truyền là file chứa dấu thời gian (time-stamp) và loại packet (type) thu được ở đầu thu (dùng TCPdump). Tại đầu phát, Evalvid dựa vào file này mà tiến hành tái tạo (ước lượng) video để so sánh và đánh giá chất lượng đưa ra các tham số QoS (loss, jitter) hoặc QoE (MOS). Bản chất, Evalvid là một bộ các chương trình độc lập để tái tạo so sánh đánh giá video: VS, ET, FV, PSNR, MOS. 4.2.2. Sử dụng Evalvid kết hợp với NS2: Sử dụng Evalvid với mạng truyền video là mạng mô phỏng NS2. Tracefile của NS2 có chứa time-stamp và type của packet, do đó, NS2 rất phù hợp với Evalvid. Ngoài ra, nhóm TKN còn đưa ra NS2 model để chuyển video thành trace file đầu vào và truyền qua mạng mô phỏng (cần phải đưa model này vào cấu trúc cua NS2). Dựa vào kết quả mô phỏng (tracefile ở đầu ra) là có thể tái tạo và đánh giá chất lượng video thu được sau khi truyền qua mạng. Hình 4.4: Sử dụng Evalvid kết hợp với NS2 4.3. Mô hình mô phỏng: Thực hiện mô phỏng với phần mềm NS2.34 kết hợp bộ công cụ Evalvid chạy trên hệ điều hành Ubuntu. Model Evalvid được đưa vào và cài đặt trong NS2.34. Hình 4.5: Mô hình mô phỏng Mô hình đơn giản gồm 13 node mạng, giả sử trong mạng chỉ có 4 loại lưu lượng: unicast VoD, multicast LiveTV, TCP và UDP. 4.3.1. Nguồn Video: Node n0 và n3 được xem như server LiveTV và VoD, nguồn video là các clip coastguard, flower, và football kích thước 352x288 (cif) được lấy từ “Hội kỹ sư truyền thông hình ảnh động” SMPTE (Society of Motion Picture Television Engineers). Các clip này được cung cấp dưới dạng YUV file (file raw: hình ảnh động được lưu trữ với 3 thành phần: một thành phần chói Y và hai thành phần màu U, V). Hình 4.6: Tốc độ bit LiveTV video clip Coastguard Hình 4.7: Tốc độ bit VoD video clip flower Để đưa các file YUV này vào mạng mô phỏng NS2 cần tiến hành các bước sau: sử dụng ffmpeg (chương trình nén phát triển trên Linux) nén file YUV bằng kỹ thuật nén H.264, đóng gói dữ liệu đã nén vào container MP4 (dùng MP4Box của Evalvid) và chuyển thành file trace để đưa vào NS2 (dùng mp4trace của Evalvid). Coastguard làm nguồn LiveTV, flower và football làm nguồn VoD. Tốc độ các luồng video sau khi mã hóa được ước lượng bằng chương trình BitrateViewer như sau: Hình 4.8: Tốc độ bit VoD video clip Football UDP và TCP ở đây được xem là các lưu lượng kém ưu tiên hơn trong mạng. TCP là giao thức truyền đảm bảo do đó, lưu lượng của nó kém ưu tiên hơn. Còn UDP ở đây đại diện cho các dịch vụ video streaming không ưu tiên (video là dịch vụ ngốn băng thông, do đó, đối với internet video streaming, người ta thường đặt mức ưu tiên rất thấp nhằm hạn chế tắt nghẽn do luồng video gây ra). 4.3.2. Điểm truy cập khách hàng: Các node n1, n2, n13 được xem là 3 điểm truy cập khách hàng. Các khách hàng cùng lúc sử dụng dịch vụ IPTV: LiveTV, VoD và các dịch vụ khác (UDP/CBR, TCP/FTP). Khách hàng 1: (n2) bắt đầu sử dụng dịch vụ LiveTV, VoD và 1 dịch vụ UDP/CBR tốc độ 1.8Mbps ở mốc thời gian 0.0s. Khách hàng 2: (n3) bắt đầu sử dụng dịch vụ LiveTV ở mốc 1.0s đồng thời sử dụng 1 dịch vụ UDP/CBR tốc độ 2Mbps từ mốc 0.0s Khách hàng 3: (n13): sử dụng LiveTV ở mốc 2.0s, VoD ở 1.5s, TCP/FTP ở mốc 3.0s và UDP/CBR tốc độ 1.5Mbps ở mốc 4.0s Hình 4.9: Biểu đồ thời gian mô phỏng các dịch vụ 4.3.3. Mạng truyền dẫn: Gồm ba node mạng lõi n6, n7, n8 (tất cả lưu lượng đều phải qua 3 nốt này và một số node trung gian (n4, n5, n11, n12). Với mốc thời gian bắt đầu các dịch vụ như trên, lưu lượng qua lõi tại thời điểm max vào khoảng: 838kbps + 1031kbps + 891kbps + 1.8Mbps + 2Mbps + 1.4Mbps ≈ 8Mbps. Với tốc độ đường truyền ở lõi là 5Mbps, nghẽn cổ chai xảy ra dẫn đến mất gói, dùng hàng đợi là phương pháp giảm mất gói tuy nhiên làm tăng trễ, độ dài hàng đợi càng lớn mất gói càng ít, trễ càng nhiều. Ở đây, chọn độ dài hàng đợi là 100 packet. 4.3.4. Mô phỏng cơ chế QoS WRED: 4.3.4.1. QoS dùng mô hình DiffServ với PHB cơ chế cơ chế WRED: NS2 hỗ trợ mô hình DiffServ cho phép khoanh vùng QoS với các node core và edge. Trong bài toán này, để đảm bảo tính đơn giản, vùng QoS được xem là bắt đầu từ router biên và kết thúc ở đầu cuối khách hàng. Node n4, n5 được xem là các node Edge, các node còn lại là các node Core. Hình 4.10: Miền DiffServ mô phỏng Cấu hình PHB trong NS2 bao gồm các tham số: hàng đợi (tương ứng với 1 hoặc 1 vài codepoint), ngưỡng nhỏ nhất (min threshold), ngưỡng lớn nhất (max threshold), và tỉ lệ rớt gói. Các tham số này được sử dụng trong WRED như sau: Hình 4.11: Sử dụng các tham số PHB cho cơ chế WRED Các packet mang code point có ngưỡng càng nhỏ, tỉ lệ rớt càng cao thì khả năng bị loại bỏ (drop) trước khi xảy ra càng lớn. Trong trường hợp của bài mô phỏng, UDP là lưu lượng có ngưỡng nhỏ nhất, kế đến là TCP, VoD, LiveTV là lưu lượng được ưu tiên nhất. Trong bài toán mô phỏng này, do có rất ít lưu lượng, để thấy rõ tác dụng của QoS, cần chọn các ngưỡng này có khoảng cách xa. Từ min/max 100/100, tỉ lệ rớt 0.001 đối với LiveTV đến min/max 5/10 tỉ lệ rớt 0.8 (80%) đối với UDP. Trong thực tế, các ngưỡng này thường gần nhau hơn. 4.3.4.2. Cơ chế WRED ưu tiên theo ảnh: Đối với video, có một điểm đặt biệt là dữ liệu thuộc các ảnh khác nhau thì có độ ảnh hưởng khác nhau đến chất lượng trải nghiệm: “không phải tất cả các gói tin đều bằng nhau” mà phụ thuộc vào nó chứa gì bên trong. Mất cùng một lượng dữ liệu nhưng ảnh hưởng sẽ nghiêm trọng hơn nếu nó là dữ liệu của ảnh I. Để giải thích điều này, cần quay lại cấu trúc GOP và đặt tính tham chiếu của các ảnh. Ảnh I là ảnh tham chiếu cho cả GOP, do đó, mất ảnh I sẽ gây ảnh hưởng đến tất cả các ảnh khác trong GOP, tương tự, ảnh P cũng là ảnh tham chiếu của các ảnh trong GOP, ảnh hưởng của mất gói tin ảnh P là nặng hay nhẹ phụ thuộc vào tính chất của video (chuyển động hay tĩnh…), còn ảnh B là ảnh hầu như không dùng để tham chiếu cho ảnh khác (đối với H.264, ở một số profile, ảnh B cũng được dùng làm ảnh tham chiếu, tuy nhiên, không giữ vai trò chính), do đó, mất ảnh B, vùng ảnh hưởng sẽ hẹp lại so với các ảnh khác. Hình 4.12: Vùng tác động của mất gói ảnh I và ảnh P Mất gói tin ảnh I thường gây ra nổ pixel “pixelization”, gãy hình “artifacts”, còn mất ảnh B thường gây tạm “dừng hình”, tuy nhiên, vì phạm vi tác động khác nhau, nên về phương diện người xem, mất ảnh B dễ chấp nhận hơn mất ảnh I. Đặt cho ảnh I một ưu tiên cao hơn ảnh B giúp tăng chất lượng trải nghiệm cho dịch vụ video. Hình 4.13: Tỉ lệ về dung lượng giữa các ảnh I, P và B trong video clip Football Hàng đợi WRED ưu tiên theo ảnh drop gói tin của ảnh B khi lưu lượng mạng tăng, nhờ đó mà giảm được tỉ lệ rớt gói tin của các ảnh khác. Ảnh B thường chiếm 1 tỉ lệ rất nhỏ về dung lượng trong một luồng video, do đó, phương pháp này không đem lại kết quả cao và rõ ràng. Tuy nhiên, việc kết hợp phương pháp này với các cơ chế QoS khác có thể giúp nâng cao chất lượng của các dịch vụ video. 4.4. Kết quả mô phỏng: 4.4.1. Mô hình QoS DiffServ cơ chế WRED: Hình 4.14:Mạng mô phỏng mô hình DiffServ cơ chế WRED Với cùng sơ đồ mạng, thực hiện mô phỏng với hai kịch bản khác nhau, có sử dụng mô hình QoS DiffServ (qos.tcl) và không sử dụng mô hình QoS DiffServ (nonqos.tcl). Sử dụng code gawk để tính mất gói và trễ từ trace file thu được. Sử dụng các chương trình có sẵn trong bộ công cụ Evalvid để khôi phục video ở đầu nhận, tính các tham số tỉ số tín hiệu trên lỗi PSRN (Peak Signal-to-Roise Ratio), ước lượng MOS. Việc đánh giá chủ yếu tập trung vào dữ liệu video LiveTV. 4.4.1.1. Tỉ lệ mất gói: Từ tracefile thu được, dựa vào ngôn ngữ xử lý text gawk có thể tính được tỉ lệ mất gói trong hai trường hợp: Không dùng DiffServ Sử dụng DiffServ Reiceive loss sent lossratio reiceive loss sent lossratio LiveTV 1045 331 1376 0.240552 1371 5 1376 0.003634 VOD1 1027 364 1391 0.261682 922 469 1391 0.337168 VOD3 359 82 441 0.185941 439 2 441 0.004535 UDP2 928 876 1804 0.485588 765 1039 1804 0.575942 UDP3 1085 1319 2404 0.548669 1104 1300 2404 0.540765 UDP1 851 1313 2164 0.606747 806 1358 2164 0.627542 TCP3 45 8 53 0.150943 21 11 32 0.34375 All 5340 4293 9633 0.445656 5428 4184 9612 0.435289 Bảng 4.1: Kết quả mô phỏng tỉ lệ mất gói mô hình DiffServ cơ chế WRED Hình 4.15 : Biểu đồ tỉ lệ mất gói mô hình DiffServ cơ chế WRED Dựa vào kết quả này có thể thấy: tỉ lệ mất gói tổng cộng ở 2 trường hợp là gần bằng nhau, tuy nhiên, tỉ lệ mất gói tin LiveTV (được ưu tiên cao nhất) ở trường hợp dùng QoS DiffServ thấph hơn rất nhiều trường hợp không sử dụng. Bù lại, tỉ lệ mất gói của các dữ liệu khác đặt biệt là UDP trong trường hợp có sử dụng QoS tăng cao. 4.4.1.2. Trễ lan truyền gói tin và biến động trễ: Sử dụng gawk cho phép tính được trễ lan truyền của từng gói tin, dùng xgraph để vẽ biểu đồ trễ, từ đó suy ra được biến động trễ. Trễ của LiveTV giảm đáng kể và cả trễ của UDP cũng giảm. Hình 4.16: Kết quả mô phỏng trễ lan truyền và biến động trễ của lưu lượng LiveTV mô hình DiffServ cơ chế WRED Hình 4.17: Kết quả mô phỏng trễ và biến động trễ của lưu lượng UDP mô hình QoS DiffServ cơ chế WRED Trễ trung bình trong trường hợp sử dụng mô hình QoS DiffServ cơ chế WRED thấp hơn so với trường hợp không dùng QoS. Nguyên nhân là WRED giúp giảm thời gian chờ đợi của các gói tin được ưu tiên bằng việc drop các gói tin không được ưu tiên trước khi xảy ra nghẽn. 4.4.1.3. PSNR, MOS: Tỉ số PSNR được tính bằng cách so sánh file video thu được với file video đầu phát ở dạng raw. File raw ở đầu thu được ước lượng bằng cách kết hợp file trace của NS2 với file video ban đầu (sử dụng chương trình etmp4 của bộ công cụ Evalvid), file ước lượng này được giải nén thành file raw (sử dụng ffmpeg) rồi so sánh với file raw ban đầu để tính được PSNR (sử dụng chương trình psnr của Evalvid). PSNR nonQoS ảnh minh họa PSNR QoS ảnh minh họa LiveTV khách hàng 1 coastgaurd 16.67 24 VoD khách hàng 1 flower 9.94 14.22 VoD khách hàng 3 football 16.48 20.32 Bảng 4.2: Kết quả mô phỏng PSNR của video mô hình QoS DiffServ cơ chế WRED Chất lượng video đặc biệt là đối với LiveTV được nâng cao rõ rệt cho thấy tác dụng của mô hình QoS DiffServ. Evalvid cũng cung cấp một công cụ ước lượng MOS của dịch vụ video dựa vào các tham số PSNR (dùng chương trình MOS). Để ước lượng được MOS, chương trình này đòi hỏi phải có PSNR tham chiếu (nghĩa là PSNR của file video sau khi nén). Chỉ tiến hành ước lượng MOS của LiveTV video coastguard theo quan điểm của khách hàng thứ nhất. Chương trình MOS cho kết quả như sau: Hình 4.18: Kết quả mô phỏng MOS của video mô hình QoS DiffServ cơ chế WRED MOS phụ thuộc vào rất nhiều yếu tố, ở đây, video tham chiếu chỉ có MOS ở mức Fair, nguyên nhân là do video nguồn không phải là video chất lượng cao và việc nén video cũng làm giảm chất lượng video một cách đáng kể (H.264 là phương pháp nén có tổn hao). 4.4.2. Cơ chế WRED ưu tiên theo ảnh: Vẫn sử dụng mô hình mạng như trên, tuy nhiên, các nguồn UDP/TCP không được kích hoạt, trong mạng chỉ có lưu lượng LiveTV và VoD. Băng thông các kênh truyền giảm xuống nhằm tạo ra hiện tượng nghẽn khi lưu lượng đã giảm. Ở kịch bản mô phỏng này, cơ chế ưu tiên vẫn là WRED, gói tin của ảnh B sẽ bị “drop” trước khi có nghẽn xảy ra để nhường lại tài nguyên mạng cho các gói tin của ảnh I. Trong QoS ưu tiên theo ảnh, bản thân thành phần không ưu tiên (ảnh B) cũng là một phần nội dung của luồng dữ liệu cần đảm bảo QoS. Đặt biệt khi sử dụng WRED, nếu thiết lập ngưỡng min, ngưỡng max quá nhỏ, có thể làm mất quá nhiều dữ liệu của luồng video, ảnh hưởng nghiêm trọng đến chất lượng luồng video, do đó, cần có sự tính toán cẩn thận nhằm đưa ra các con số thích hợp. 4.4.2.1. Mất gói: Dùng WRED ưu tiên theo ảnh Không dùng WRED ưu tiên theo ảnh receive loss sent lossratio receive loss sent Lossratio LiveTV 1315 61 1376 0.044331 1300 76 1376 0.055233 VoD1 1317 74 1391 0.053199 1326 65 1391 0.046729 VoD2 419 22 441 0.049887 433 8 441 0.018141 All 3051 157 3208 0.04894 3059 149 3208 0.046446 Bảng 4.3 : Kết quả mô phỏng tỉ lệ mất cơ chế WRED ưu tiên theo ảnh Tỉ lệ mất gói không thay đổi nhiều vì mục đích chủ yếu của phương pháp này là thay đổi tỉ lệ gói tin bị mất của các ảnh. Nếu tỉ lệ mất gói tăng cao có nghĩa các tham số ngưỡng max và min được chọn quá nhỏ dẫn đến gói tin bị drop khi quá sớm khi mạng chưa xảy ra nghẽn. 4.4.2.2. Trễ lan truyền và biến động trễ (Jitter): Trễ lan truyền và biến động trễ không có sự thay đổi đáng kể. Hình 4.19: Kết quả mô phỏng trễ và biến động trễ cơ chế WRED ưu tiên theo ảnh Do tính đặt biệt của phương pháp này, kết quả chỉ thấy được ở cấp độ cảm nhận người dùng (QoE), các biện pháp đánh giá chất lượng truyền thống dựa trên paket loss, trễ và jitter không thể cho thấy được hiệu quả của phương pháp này. 4.4.2.3. PSNR/MOS: Không dùng WRED ưu tiên theo ảnh Sử dụng WRED ưu tiên theo ảnh PSNR MOS ảnh minh họa PSRN MOS ảnh minh họa LiveTV khách hàng 1 coastgaurd 21.32 1.89 20.49 1.90 VoD khách hàng 1 flower 18.27 1.68 17.88 1.68 VoD khách hàng 3 football 21.44 1.82 20.08 1.82 Bảng 4.4: Kết quả mô phỏng PSNR/MOS của video cơ chế WRED ưu tiên theo ảnh Chất lượng video có tăng lên nhưng không nhiều. Phương pháp này được xem là một phương pháp hỗ trợ nhằm nâng cao chất lượng dịch vụ và đặt biệt có hiệu quả trong trường hợp lưu lượng video ưu tiên tăng cao. 4.5. Ứng dụng: Việc cân bằng, lựa chọn các tham số cũng như cơ chế QoS là vấn đề rất quan trọng trong cấu hình thực tế, đặc biệt đối với các dịch vụ video, khi mà chất lượng không thể được đánh giá qua các tham số chất lượng mạng thông thường (jitter, delay, …). Dùng NS2 với các mô hình QoS kết hợp với bộ công cụ Evalvid có thể giúp ước lượng được chất lượng video truyền qua mạng (có thể đưa video vào mạng mô phỏng và xem thử video đầu ra), điều này rất hữu ích trong quá trình thiết kế mạng cung cấp dịch vụ IPTV. KẾT LUẬN Có những ưu thế nổi bật, vượt trội so với các công nghệ truyền hình khác, IPTV hứa hẹn sẽ mở ra một kỷ nguyên truyền hình mới, đem lại những khoảng lợi nhuận khổng lồ cho các nhà cung cấp dịch vụ. Mặc dù vậy, để IPTV thật sự phát triển, chất lượng dịch vụ là một vấn đề cần phải quan tâm, công nghệ càng phát triển, cạnh tranh càng lớn thì đòi hỏi của khách hàng sẽ ngày càng khắt khe hơn. Do đó, cần phải có sự kết hợp chặt chẽ giữa các nhà sản xuất chương trình, nhà cung cấp dịch vụ và các công ty cung cấp hạ tầng mạng để có thể đem đến cho khách hàng trải nghiệm tốt nhất. Để đảm bảo chất lượng dịch vụ, trước hết, cần đánh giá được nó, có rất nhiều phương pháp và tiêu chuẩn khác nhau để đánh giá chất lượng dich vụ IPTV, mỗi phương pháp đều có ưu điểm và nhược điểm riêng, kết hợp các phương pháp này là hướng tốt để đánh giá chất lượng IPTV. Ở phương diện hạ tầng mạng, mô hình DiffServ cùng với các cơ chế QoS khác nhau đang ngay càng được nghiên cứu, phát triển và triển khai mở rộng, đặt biệt với đặt thù cho phép xử lý ưu tiên của dữ liệu IPTV, việc thực hiện QoS cho dịch vụ IPTV có rất nhiều thuận lợi. Ở thời điểm hiện tại, với lượng thuê bao chưa nhiều so với mạng lõi có dung lượng rất lớn, việc tranh giành tài nguyên chưa gay gắt, chất lượng dịch vụ chủ yếu bị ảnh hưởng bởi chất lượng mạng truy nhập, tuy nhiên, trong thời gian tới, khi IPTV vào giai đoạn phát triển của nó, lưu lượng trên mạng tăng nhanh sẽ khiến cho kỹ thuật QoS trở thành chìa khóa đảm bảo lợi nhuận cho IPTV. HƯỚNG MỞ CỦA ĐỀ TÀI Nội dung thực hiện của đề tài: Chương 1: Định nghĩa, tìm hiểu cấu trúc và hoạt động tổng quát của IPTV. Chương 2: Giới thiệu các kỹ thuật nén video dùng trong IPTV, mô tả quá trình nén H.264. Chương 3: Định nghĩa QoS, tìm hiểu các biện pháp đánh giá và đảm bảo QoS cho IPTV Chương 4: Mô phỏng hệ thống truyền dẫn video multi/unicast đánh giá hiệu quả của cơ chế QoS WRED trong mô hình DiffServ, cơ chế WRED ưu tiên theo ảnh. Hạn chế của đề tài: Trong phạm vi ngắn gọn của đề tài, do chỉ tìm hiểu tổng quát về IPTV nên có nhiều khái niệm được nhắc đến nhưng chưa được đi sâu tìm hiểu và phân tích rõ ràng (ví dụ: các giao thức multicast, hoạt động của mạng lõi, mạng truy nhập, các chương trình quản lý, bảo an…) QoS là khái niệm phức tạp, các biện pháp đánh giá và đảm bảo QoS có rất nhiều và vẫn đang được nghiên cứu phát triển, các biện pháp được nêu trong đề tài chỉ là một phần nhỏ không thể mang tính đầy đủ. Chủ yếu tập trung vào lý thuyết của các cơ chế và mô hình QoS và khả năng sử dụng chúng đối với IPTV, chưa đi vào việc kết hợp vận dụng các cơ chế này. Phần mềm NS2 và bộ công cụ Evalvid là miễn phí, các module NS2 mang tính “mở”, do đó, khó có thể đảm bảo tính chính xác và tin cậy của mô hình mô phỏng. Mô hình DiffServ của phiên bản NS2 đang sử dụng không hỗ trợ khai báo lưu lượng không có node nguồn và node đích chính xác (multicast) ở Edge, do đó, lưu lượng LiveTV phải đưa vào Core). Hướng mở của đề tài: Đi sâu phân tích các yếu tố của dịch vụ IPTV Tìm hiểu các cơ chế QoS mới, cách kết hợp và vận dụng các cơ chế QoS . Sử dụng công cụ mô phỏng và tính toán tìm kiếm và đưa ra phương pháp xác định tham số dùng cho việc khai báo các chính sách QoS. TÀI LIỆU THAM KHẢO [1] Next Generation IPTV Service And Technologies – Genard O’DrisColl (2007). [2] Understanding IPTV – Gilbert Held (2007). [3] Implementing Cisco Multicast Version 1.0 – Cisco System (2003). [4] Implementing Cisco Quality of Service Volume 1 & 2 Version 2.2 – Cisco System (2006) [5] Not All Packets Are Equal Part 1 & 2 – Cisco System (2009) [6] EvalVid – A Framework for Video Transmission and Quality Evalutation – Jirka Klaue, Berthold Rathke, and Adam Wolisz (2003). [7] The NS Manual - Kevin Fall & Kannan Varadhan (2010) [8] Network performance objectives for IP-based services - ITU-T Recommendation Y.1541 (2006) [9] Quality of service ranking and measurement methods for digital video services delivered over broadband IP networks – ITU-T Recommendation J.241 (2005) [10] Framework and methodologies for the determination and application of QoS parameters – ITU-T Recommendation E.802 (2007) [11] Classification of IPTV services based on network QoS requirements – ITU-T FG IPTV C-0127 (2006) [12] Quality of experience requiemets for IPTV services – ITU-T G.1080 (2008) [13] IPTV Explained – Broadband Service Forum. [14] Online Seminar March 2007 – Ericsson. [12] The emerging H.264/AVC standard – Ralf Schafer, Thomas Wiegand and Heiko Schwarz (2003). [13] H.264 video compression standard – AXIS Communication (2008). [14] Slide môn học Xử lý âm thanh và hình ảnh – thầy Nguyễn Thanh Bình, khoa Điện tử 2, Học viện Công Nghệ Bưu Chính Viễn Thông cơ sở 2 tại Tp.HCM. [15] Thuyết minh dự thảo tiêu chuẩn “Dịch vụ IPTV trên mạng viễn thông công cộng – các yêu cầu” – Bộ thông tin và truyền thông (2010).