Do đặc điểm của tín hiệu thoại là khác biệt so với các lại tín hiệu được truyền tải trên đường truyền nên khi nói đến vấn đề QoS cho tín hiệu thoại cần chú ý những vấn đề sau:
− Các gói tin IP của dịch vụ thoại cần được đánh dấu trong trường DiffServ với giá trị DSCP là EF.
− Tỉ lệ mất gói không được vượt quá 1%. − Trễ một chiều phải nhỏ hơn 150 ms.
− Jitter trung bình một chiều phải nhỏ hơn 30ms.
− Băng thông được đảm bảo độ ưu tiên đối với mỗi một cuộc gọi nằm
trong khoảng 21kbps đến 320kbps (tùy thuộc vào tốc độ lấy mẫu, codec và phần đầu của bản tin media lớp 2).
Bảng 3-2 Bảng tham số thoại của Cisco VoIP Bandwidth 21 tới 320kbps Delay (1 chiều) <150ms Jitter <30ms Packet loss <1% 3.2.2. Dịch vụ IPTV
3.2.2.1. Khuyến nghị của ITU-T
Theo khuyến nghị G.1010:
Về chất lượng của video nói chung có thể được chia ra làm 6 mức khác nhau (khuyến nghị ITU-T F.700), các dịch vụ có liên quan đến video sẽ dựa vào đó để xác định xem dịch vụ nào sẽ sử dụng mức độ nào cho phù hợp.
Với videophone
Dịch vụ videophone nói ở đây là hệ thống full-duplex, nó bao gồm cả video và audio và được sử dụng trong môi trường hội thoại. Vì vậy, về mặt nguyên tắc thì yêu cầu về độ trễ giống như âm thanh thoại, ví dụ như không có tiếng vọng, ngoài ra đồng bộ giữa âm thanh và hình ảnh phải nằm trong một giới hạn để đảm bảo “lip- synch”.
Do đặc điểm của thị giác nên ở một mức độ nào đó, việc mất một số gói tin vẫn có thể chấp nhận được tùy thuộc vào việc sử dụng bộ coder cũng như bộ sửa lỗi phù hợp. Người ta mong muốn rằng các chuẩn mã hóa hình ảnh MPEG-4 mới nhất sẽ cho chất lượng hình ảnh chấp nhận được với tỉ lệ mất khung hình lên đến 1%.
Với One-way video
Đặc điểm chính của one-way video là nó không có yếu tố thoại 2 chiều, điều này dẫn đến yêu cầu về độ trễ không quá khắt khe và có thể áp dụng chuẩn giống như streaming audio. Các chuẩn tham số video được trình bày trong bảng 3-3.
Bảng 3-3 Các tham số video của ITU-T Phương tiện Ứng dụng Cách thức Tốc độ Giá trị One-way delay Delay variation Informatio n loss (Note 2) Khác Video Videophon e Two-way 16- 384 kbit/s <150ms preferred <1% packet loss ratio (PLR) Lip- synch: <80ms
Video One-way One-way 16-
384 kbit/s
<10s <1% PLR
3.2.2.2. Khuyến nghị của Cisco
Hiện tại có 2 kiểu lưu lượng video cơ bản là Interactive-Video (videconferencing) và Streaming-Video (bao gồm cả unicast và multicast). Mỗi loại dịch vụ cần có những tiêu chí về QoS khác nhau.
Với Interactive-Video:
− Các gói tin IP của dịch vụ Interactive-Video nên được đánh dấu trong trường DiffServ với giá trị DSCP là AF41, nếu lưu lượng lớn có thể chọn lựa AF42 hoặc AF43.
− Tỉ lệ mất gói không được vượt quá 1%.
− Trễ một chiều phải nhỏ hơn 150ms.
− Jitter trung bình một chiều phải nhỏ hơn 30ms.
− Các gói tin Interactive-Video được gửi đến hàng đợi ưu tiên mức 1
hoặc mức 2 (nếu được hỗ trợ). Khi sử dụng IOS LLQ của Cisco thì băng thông cần được đảm bảo ở mức băng thông của phiên cộng thêm 20% (ví dụ: một phiên videconferencing 384kbps cần được đảm bảo băng thông ở mức 460kbps)
Với Streaming-Video:
− Các gói tin của Streaming-Video (unicast hoặc multicast) nên được chọn tương ứng với DSCP CS4.
− Tỉ lệ mất gói không quá 5%.
− Độ trễ không được lớn quá 4s đến 5s (tùy thuộc vào khả năng của bộ đệm).
− Không có yêu cầu về jitter.
− Yêu cầu về đảm bảo băng thông tùy thuộc vào dạng mã hóa và tốc độ
truyền video.
− Do việc truyền Streaming-Video chủ yếu là truyền đơn hướng nên các router nhánh ở xa không cần phải dự phòng cho lưu lượng Streaming- Video trên mạng WAN hoặc VPN biên.
− Với các ứng dụng Streaming-Video không cần mức độ ưu tiên cao như
các dịch vụ phim truyện giải trí, thì có thể chọn DSCP là CS1, tức là ở mức ưu tiên và băng thông thấp hơn.
Tùy thuộc vào các loại dịch vụ Streaming-Video khác nhau để xác định mức độ ưu tiên khác nhau tức là dựa vào đó để xác định xem liệu ứng dụng video đó có cần phải đảm bảo về QoS hay không.
3.3. Chất lượng dịch vụ IPTV. Giải pháp nâng cao chất lượng dịch vụ IPTV: 3.3.1. Mạng tổng thể IPTV
Sơ đồ khối biểu thị các chức năng của dịch vụ IPTV như hình 3.7. Từ nguồn nội dung tới đầu cuối người dùng có thể chia làm: mạng cung cấp và giới thiệu các nội dung, mạng chuyển tải, mạng tiếp nối đầu cuối và mạng quản trị.
Hình 3.7. Sơ đồ khối chức năng của dịch vụ IPTV
3.3.1.1. Mạng nội dung:
Mạng này cung cấp và giới thiệu nội dung gồm xử lý nội dung truyền hình trực tiếp/truyền hình VOD (theo điểm) và xử lý, giới thiệu các ứng dụng gia tăng (phục vụ tin tức, điện thoại có hình, email, nhắn tin...). Nguồn nội dung truyền hình trực tiếp/truyền hình VOD không qua hệ thống xử lý nội dung được mã hóa để phù hợp với luồng media theo yêu cầu qua mạng chuyển tải đưa các luồng này cung cấp tới các người dùng đầu cuối.
3.3.1.2. Mạng truyền tải:
Đây là mạng cáp IP. Đối với luồng media có hình thức nghiệp vụ không giống nhau có thể dùng phương thức chuyển đa hướng (multicast), cũng có thể chuyển theo phương thức đơn kênh. Thông thường, truyền hình quảng bá BTV truyền đa hướng tới user đầu cuối, truyền hình theo yêu cầu VOD thông qua mạng
cáp phân phát nội dung CDN (Content Distribution Network) tới địa điểm người dùng đầu cuối.
3.3.1.3. Mạng đầu cuối (còn gọi là mạng cáp gia đình).
Theo các nhà khai thác viễn thông, thì mạng này là mạng tiếp nối băng rộng xDSL, FTTx+LAN hoặc WLAN.
3.3.1.4. Bộ quản trị:
Bộ quản trị bao gồm quản lý nội dung, quản lý cáp truyền, tính cước phí, quản lý các thuê bao, quản lý các hộp ghép nối STB.
Ta thấy trong mạng IPTV có 3 dạng luồng tín hiệu: luồng quảng bá BTV, luồng truyền đến địa điểm theo yêu cầu VOD và luồng nghiệp vụ giá trị gia tăng. Như biểu diễn trên hình 3.7. Ta xét các phương thức truyền tín hiệu thị tần. Có 3 phương thức truyền trực tiếp hiện trường, truyền quảng bá có định thời gian và truyền tới điểm VOD. Khi truyền hình trực tiếp đồng thời ta lấy nội dung này lưu vào bộ nhớ để phát lại vào truyền hình quảng bá định thời gian hoặc làm nguồn các tiết mục cho truyền hình VOD. Đối với tiết mục quảng bá có định thời IPTV dùng phương pháp truyền phát đa điểm IP có tiết kiệm băng tần tức là phương thức multicast. Phương thức này thực hiện "nhất phát, đa thu". Dùng phương thức này, mỗi tiết mục chỉ phát một luồng số liệu thời gian thực (real time) không liên quan tới số người xem tiết mục này. Phương thức này có thể truyền phát cho hàng nghìn thuê bao.
IPTV cung cấp đồng thời hình ảnh (video) và âm thanh (audio) trên mạng cáp. Để đảm bảo chất lượng của 2 loại tín hiệu trên IPTV dùng phương pháp đồng bộ A/V thông qua một server duy nhất thu thập các dữ liệu tại hiện trường, văn bản sử dụng theo khuyến nghị truyền dẫn thời gian thực RTP. IPTV dùng kỹ thuật nén thị tần có hiệu suất cao nên băng tần truyền dẫn tại 800 kbit/s có thể tiếp cận với băng tần thu DVD nên tạo điều kiện cho các nhà khai thác dễ dàng phát triển các dịch vụ video. Mạng truyển tải CDN gồm nhiều server cache phân bố tại các khu vực tập trung thuê bao, Khi có yêu cầu của thuê bao, cache server chuyển lên VOD
server trong mạng nguồn cung cấp, tìm nội dung phù hợp và chuyển tải cho thuê bao sự hoạt động của các server trong mạng chuyển tải dựa trên kỹ thuật cân bằng phụ tải toàn cục (GSLB). Trong quá trình truyền đưa multimedia IPTV có thể dùng khóa mật mã đảm bảo độ an toàn của nội dung truyền dẫn.
IPTV áp dụng các khuyến nghị quốc tế về tiêu chuẩn, như khuyến nghị về truyền dẫn thời gian thực (RTP), khuyến nghị về khống chế thời gian thực (RTCP)...
IPTV cũng cùng làm việc với máy tính dùng hệ điều hành UNIX, VIC/VAT, Apple và Quick Time.
Hiện nay cách thức mã hóa video của luồng chủ của IPTV theo MPEG-2, MPEG-4, H.264/AVC; Real Microsoft UWMV-9. Trong đó, MPEG-2 và MPEG-4 được phát triển mạnh. H.264 là luật mã hóa thị tần của ITU-T đề xuất thích hợp cho các hệ thống công cộng. Do đó H.264 có khả năng thành cách mã hóa chính của IPTV.
3.3.2. Đề xuất giải pháp QoS3.3.2.1. Đặt vấn đề 3.3.2.1. Đặt vấn đề
Tuy hiện tại mạng VNPT có thể đáp ứng hết các dịch vụ hiện có nhưng không vì thế mà coi nhẹ thiết kế QoS cũng như việc quản lý các vấn đề QoS do chất lượng của mạng sẽ bị biến động do các tác động khác nhau nhất là tải của mạng.
Việc triển khai các cơ chế QoS phức tạp có thể chưa cần gấp ở giai đoạn này nhưng về lâu dài cần hết sức chú ý nhất là mong muốn hướng đến việc cung cấp chất lượng dịch vụ theo thoả thuận chất lượng (SLA).
Việc xác định khả năng của mạng trong việc hỗ trợ QoS nhằm đưa ra giải pháp có tính lâu dài cho vấn đề này.
Từ phần phân tích công nghệ triển khai trên mạng NGN của VNPT hiện tại có thể thấy giải pháp QoS trên mạng dạng này sẽ sử dụng kết hợp giữa MPLS,
Diffserv và kỹ thuật lưu lượng (TE). Hướng tìm kiếm giải pháp về QoS đối với mạng VNPT sẽ trong khoảng từ Diffserv đến H-QoS.
Hình 3.8. Thiết kế QoS với mạng VNPT
Diffserv được sử dụng trên nền MPLS là mặc định, các kỹ thuật bổ trợ như TE sẽ giúp cải thiện QoS.
3.3.2.2. Khuyến nghị
Để giải quyết vấn đề QoS end-to-end , khuyến nghị: − Toàn mạng nên có chung các Profile QoS
Hình 3.9. Toàn mạng nên sử dụng chung các Profile QoS
− Do tính độc lập của mỗi miền mạng metro/core nên trong nội miền
(MAN-E hoặc core) hãng cung cấp có thể sử dụng các biện pháp kỹ thuật riêng để tạo ra các Profile QoS. Tại biên giới các miền Core/MEN cần thống nhất việc sử dụng các mã DSCP của Diffserv.
Việc ánh xạ DSCP(Diffserv) sang EXP (MPLS) và các cơ chế tránh/quản lý tắc nghẽn Hãng chủ động đề xuất .
Hình 3.10. Các đối tượng và chức năng thực hiện
− Việc ánh xạ từ dịch vụ/ứng dụng cụ thể sang các QoS profile do bản thân các nhà tổ chức dịch vụ (SP) thực hiện (có thể tham khảo khuyến nghị của các Hãng và tổ chức). Các SP này có thể thuộc hoặc không thuộc VNPT.
− Sẽ sử dụng TE một cách linh hoạt (FRR, Load sharing, Band width
guarantee..)
3.3.2.3. Xây dựng các Profile QoS cơ bản và quy ước sử dụng DSCP
Trên mạng có thể tạo ra vô vàn các đối tượng (các kết nối) giữa các điểm, sự phân biệt các đối tượng này không chỉ ở vị trí kết nối, số điểm mà còn bao gồm cả các thuộc tính. Hai khía cạnh đối tượng và thuộc tính kết hợp với nhau theo dạng ma trận 2 chiều.
Đối tượng được tạo ra dưới yêu cầu từ khách hàng còn các thuộc tính có sẵn của mạng do tổ chức mà có (thể hiện bởi các Profile).
Xác định đối tượng là vấn đề đầu tiên cần làm trước khi áp QoS cho chúng. Đối tượng có thể là các flow, các trunk, các path, VPN... Miền biên mạng phải có cơ chế phân biệt được các đối tượng khác nhau (Classification), số đối tượng này phụ thuộc năng lực của mạng
Khuyến nghị trên mạng VNPT nên tổ chức thành một số Profile cơ bản sau:
3.3.2.4. Network control profile
Network control profile được dùng cho lưu lượng báo hiệu giữa các nút mạng sinh ra bởi các giao thức báo hiệu/điều khiển như OSPF, ISIS, RSVP, BGP, LDP... Các giao thức này có nhiệm vụ duy trì cấu trúc logic của mạng và là các giao thức quan trọng nhất trong của mạng, quan trọng hơn cả lưu lượng thời gian thực của khách hàng. Nếu các giao thức này bị ảnh hưởng thì nó có thể ảnh hưởng tới tất cả các lưu lượng của người sử dụng đi qua node mạng. Profile này phải được cấu hình một lượng băng thông tối thiểu để phân phát dữ liệu trong mọi điều kiện và
yêu cầu mất gói rất nhỏ [3.2-RFC 4594]
3.3.2.5. Reatime Voice profile
Reatime Voice profile được áp dụng cho các ứng dụng có yêu cầu rất nhỏ về độ trễ, jitter và mất gói để giữ cho nguồn lưu lượng có tốc độ phát sinh đều (constant bit rate)
Ứng dụng cho các yêu cầu chuyển tiếp các gói gần-thời-gian-thực với nguồn lưu lượng ổn định và tỷ lệ mất gói rất thấp. Các ứng dụng bao gồm broadcast TV, truyền phát trực tiếp video và audio, một số ứng dụng VoD và giám sát video
3.3.2.7. Data 1 Profile (Crictical)
Sử dụng cho các ứng dụng yêu cầu mất gói thấp và tương đối nhạy cảm với độ trễ ví dụ như các giao thức OAM (Operations, Administration, and Management): SNMP (Simple Network Management Protocol), FTP/SCP và SSH.
3.3.2.8. Data 2 Profile
Sử dụng cho các ứng dụng có các nguồn phát sinh lưu lượng có sự biến đổi, hay các luồng TCP long-lived (ví dụ các ứng dụng: lưu trữ và chuyển tiếp, truyền file, Email.. ) và thường có yêu cầu High-Throughput
3.3.2.9. Standard Profile
Standard Profile này được áp cho lưu lượng thông tin “best-effort” chẳng hạn các ứng dụng DNS, DHCP, BootP hay bất kỳ một luồng ứng dụng/ gói chưa được phân biệt nào được truyền qua mạng Diffserv.
3.3.3. Các phép ánh xạ QoS
3.3.3.1. Ánh xạ các QoS profile vào DSCP code
Hình 3-11 là việc ánh xạ các QoS Profile sang DSCP code được sử dụng làm chuẩn chung. Huawei và Cisco sẽ cần thống nhất theo quy ước này
Hình 3.11. Thống nhất việc ánh xạ các QoS Profile sang DSCP Chi tiết theo như bảng 3-5:
Bảng 3-5. Bảng ánh xạ QoS Profile sang DSCP
QoS Profile DiffServ
Codepoint
Value
Network Control CS-6 48
REALTIME-VOICE EF 46
REALTIME-VIDEO AF41
DATA1 (CRICTICAL) AF31
DATA2 (ASSURED ELASTIC) AF32
STANDARD (ELASTIC) BE
Phần này khuyến nghị trong việc triển khai cho các dịch vụ ứng dụng (VoIP, IPTV, HSI..)
Profile A Profile B Profile C Profile …n
VPN VoIP HIS IPTV
3.3.3.3. Ánh xạ từ Diffserv code sang MPLS EXP code
Sử dụng bảng ánh xạ
Bảng 3-6 Bảng ánh xạ từ Diffserv sang MPLS EXP
DSCP PHB EXP value CS7(111000) 111 CS6(110000) 110 EF(101110) 101 AF4X(100xx0) 100 AF3X(011xx0) 011 AF2X(010xx0) 010 AF1X(001xx0) 001 Best Effort 000
3.3.4. Cấu hình QoS trong MAN-E
Để đảm bảo dịch vụ, khuyến nghị cấu hình QoS trên 2 loại interface: • Interface kết nối đến các thiết bị khác trong mạng MAN • Interface kết nối đến các thiết bị khách hàng
Hình 3.12. Mô hình kết nối end-to-end
Trên các interface kết nối đến các thiết bị khác trong mạng MAN-E, các cơ chế QoS được cấu hình như hình vẽ 3-13:
Hình 3.13. Cơ chế QoS trong MAN-E
Congestion Advoice (Chống tắc nghẽn)
Phương pháp chống tắc nghẽn WRED và Tail Drop sẽ được sử dụng để chống tắc nghẽn trong mạng MAN-E của VNPT.
WRED cung cấp giải pháp để chống tắc nghẽn. Công nghệ này cho phép theo dõi tải lưu lượng để chống lại tắc nghẽn xảy ra tại điểm nút chai. Chống tắc
nghẽn được thực hiện trước khi tắc nghẽn xảy ra, ngược lại với quản lí tắc nghẽn thực hiện điều khiển tắc nghẽn khi có tắc nghẽn xảy ra
WRED được thiết kế để chống tắc nghẽn trong mạng trước khi nó có vấn đề. Nó kế thừa khả năng theo dõi lưu lượng của giao thức TCP. WRED theo dõi tải lưu lượng tại một điểm trong mạng và discard gói tin nếu tắc nghẽn bắt đầu xuất hiện. Kết quả là bên gửi nhận thấy lưu lượng bị drop và bắt đầu giảm tốc độ truyền. WRED tương tác với các phương pháp QoS khác để xác định loại dịch vụ trong luồng lưu lượng. Nó thực hiện drop gói tin từ thứ tự ưu tiên thấp tới ưu tiên cao, đảm bảo rằng các gói tin ưu tiên cao tránh ảnh hưởng do tắc nghẽn