2. Bố cục luận văn:
2.2.7.4. Các biện pháp đảm bảo Qo Sở mạng truyền dẫn:
2.2.7.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.
a. Băng thông: IPTV được xem là một ứng dụng “ngốn băng thông”.
Hình 2.19: 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).
b. 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 2.20: 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.
c. 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 2.21: 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.
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.
d. 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.
2.2.7.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.
2.2.8. 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 2.22: 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 2.23: 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.
2.2.9. 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.
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 đó.
2.2.9.1. 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.24: 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.
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 2.25: 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).
2.2.9.2. 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.
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 2.26: 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.
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 2.28: 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 2.29: Khối điều khiển lưu lượng DiffServ 2.2.9.3. Mô hình kết hợp:
Hình 2.30: 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í.
2.3. Các mô hình QoE:
2.3.1. Đo đạc và kiểm soát QoE:
Mặc dù mang tính chủ quan của người đánh giá, QoE cũng nên được lượng hóa đến một mức độ nhất định để có thể được sử dụng hữu ích cho các mục đích khác nhau như đưa vào hợp đồng thống nhất mức dịch vụ (Service Level Agreement - SLA) ký kết giữa nhà cung cấp và khách hàng, NSD. Phương pháp để đánh giá mức độ hài lòng QoE một mặt cần bao hàm những yếu tố mang tính tâm lý chủ quan của NSD, mặt khác cần phải đưa ra những kết quả sát thực tiễn và có thể tái dựng lại khi có nhu cầu. Điều này trước tiên đòi hỏi sự thấu hiểu về nhu cầu mà NSD đang có, nắm được yếu tố nào là nhân tố ảnh hưởng đến sự đánh giá chủ quan của NSD cho loại hình dịch vụ mà họ sử dụng.
Phát triển các phương pháp để có thể đo đạc, lượng hóa QoE không phải là vấn đề đơn giản vì ngoài các yếu tố thuần túy kỹ thuật (như trong trường hợp QoS) còn cần phải xem xét những yếu tố mang tính con người. Để đánh giá QoE có thể đi theo phương thức là tạo ra ánh xạ từ các thông số kỹ thuật thuần túy QoS sang thông số mang tính chủ quan QoE. Sau đó chỉ cần đo đạc và kiểm soát các thông số QoS để qua đó kiểm soát và điều chỉnh QoE. Khó khăn lớn nhất của phương thức này là tạo ra cách ánh xạ phản ánh được chân thực nhất những yếu tố mang tính chủ quan của NSD, ví dụ như những tính chất của hệ thị giác con người. Hơn thế nữa, phải tổng hợp nhiều tham số QoS mới có thể ánh xạ sang QoE một cách hợp lý. Sự ánh xạ đòi hỏi phải có sự đúc kết từ nhiều thử nghiệm thực tế. Bảng 2.8 là một ví dụ về cách ánh xạ từ các tham số QoS bao gồm độ trễ (end-to-end delay), tỷ lệ mất gói (packet loss ratio), thông lượng trung bình (mean throughput) sang các mức độ QoE bao gồm xuất sắc (excellent), rất tốt (very good), trung bình (average), tạm chấp nhận được (fair), và kém (poor), dùng cho dịch vụ truy nhập web sử dụng WAP/ xHTML trong mạng di động.
Bảng 2.8: Ánh xạ từ các tham số QoS sang QoE của dịch vụ truy nhập web sử dụng WAP/ xHTML trong mạng di động.
QoS KPLs QoE-subjective scale
Excellent Very good Average Fair Poor End-to-end delay (median) ≤2s ≤4s ≤8s ≤15s ≥15s Packet loss ratio ≤0% ≤0.1% ≤1% ≤5% ≥5% Mean throughput ≥200kb/s ≥120kb/s ≥60kb/s ≥20kb/s ≤20kb/s
QoE cho IPTV có thể được đánh giá bằng phương pháp mang tính chủ quan