BỘ GIÁO DỤC VÀ ĐÀO TẠO TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI PHẠM HỒNG THỊNH NÂNG CAO CHẤT LƯỢNG TRUYỀN VIDEO THÍCH NGHI HTTP TRÊN MẠNG ĐIỀU KHIỂN BẰNG PHẦN MỀM (SDN) LUẬN ÁN TIẾN SĨ KỸ THUẬT VIỄN THÔNG Hà Nội – 2021 BỘ GIÁO DỤC VÀ ĐÀO TẠO TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI PHẠM HỒNG THỊNH NÂNG CAO CHẤT LƯỢNG TRUYỀN VIDEO THÍCH NGHI HTTP TRÊN MẠNG ĐIỀU KHIỂN BẰNG PHẦN MỀM (SDN) Ngành: Kỹ thuật vi ễn thông Mã số: 9520208 LUẬN ÁN TIẾN SĨ KỸ THUẬT VIỄN THÔNG NGƯỜI HƯỚNG DẪN KHOA HỌC: PGS.TS TRƯƠNG THU HƯƠNG PGS.TS PHẠM NGỌC NAM Hà Nội – 2021 LỜI CAM ĐOAN Tôi xin cam đoan kết khoa học trình bày luận án thành nghiên cứu thân suốt thời gian làm nghiên cứu sinh chưa xuất công bố tác giả khác Các tài liệu tham khảo trích dẫn đầy đủ, rõ ràng trung thực Hà Nội, ngày tháng năm 2021 TM Tập thể hướng dẫn Tác giả luận án PGS.TS Trương Thu Hương Phạm Hồng Thịnh LỜI CẢM ƠN Trước hết, xin bày tỏ lời cảm ơn sâu sắc đến PGS.TS Trương Thu Hương PGS.TS Phạm Ngọc Nam trực tiếp hướng dẫn, định hướng khoa học, dành nhiều thời gian tâm huyết giúp đỡ tơi mặt để hồn thành luận án Tôi xin gửi lời cảm ơn đến thành viên nhóm HTTP/SDN Lab ESRC Lab Future Network Trường Đại học Bách Khoa Hà Nội hỗ trợ thực số thí nghiệm luận án Qua đây, xin cảm ơn Viện Điện tử Viễn thông, Phòng Đào Tạo, Trường Đại học Bách Khoa Hà Nội tạo điều kiện thuận lợi cho nghiên cứu sinh suốt trình nghiên cứu, học tập thực luận án Xin chân thành cảm ơn quan tâm, giúp đỡ, động viên đồng nghiệp, nhóm Nghiên cứu sinh – Viện Điện tử Viễn thơng dành cho Chân thành cảm ơn Khoa Kỹ thuậ t Công nghệ, Trường Đại học Quy Nhơn tạo điều kiện thuận lợi cho NCS tập trung nghiên cứu thời gian qua Cuối cùng, xin dành lời yêu thương đến với gia đình, vợ Sự động viên, giúp đỡ hy sinh nhiều h ọ thời gian vừa qua động lực to lớn để vượt qua khó khăn hồn thành luận án Xin chân thành cảm ơn! Hà Nội, ngày tháng năm 2021 i MỤC LỤC MỤC LỤC i DANH MỤC CÁC TỪ VIẾT TẮT iv DANH MỤC HÌNH VẼ vi DANH MỤC BẢNG BIỂU viii MỞ ĐẦU CHƯƠNG TỔNG QUAN VỀ KỸ THUẬT TRUYỀN VIDEO QUA GIAO THỨC HTTP VÀ M ẠNG ĐIỀU KHIỂN BẰNG PHẦN MỀM SDN 1.1 Đặt vấn đề .8 1.1.1 Vấn đề HTTP streaming 1.1.2 Kỹ thuật streaming video chuẩn 10 1.1.3 Vấn đề thích ứng tốc độ HTTP streaming 12 1.1.4 HTTP streaming theo cảm nhận người dùng QoE .13 1.2 Truyền video qua giao thức HTTP .14 1.2.1 Mơ hình truyền video thích ứng động giao thức HTTP (DASH) 14 1.2.1.1 Khái quát chung .14 1.2.1.2 Tệp Media Presentation Description (MPD) 16 1.2.2 Kỹ thuật mã hóa video 17 1.2.3 Các tham số ảnh hưởng đến chất lượng trải nghiệm QoE 19 1.2.4 Giới thiệu mơ hình QoE 22 1.3 Mạng điều khiển phần mềm SDN 23 1.3.1 Khái niệm chung 23 1.3.2 Kiến trúc SDN 24 1.3.3 Một số ưu điểm SDN 25 1.3.4 So sánh SDN mạng truyền thống .26 1.3.5 Giao thức OpenFlow 27 1.3.5.1 Khái niệm .27 1.3.5.2 Các thành phầ n OpenFlow/ SDN 28 1.3.6 Triển khai mạng SDN 34 1.3.6.1 Triển khai đồ hình mạng 35 1.3.6.1 Triển khai điều khiển - Controller 36 1.4 Kết luận chương 39 CHƯƠNG TRUYỀN VIDEO CBR THÍCH NGHI GIAO THỨC HTTP DỰA TRÊN KỸ THUẬT ĐỊNH TUYẾN CỦA SDN .40 ii 2.1 Giới thiệu chương .40 2.2 Các cơng trình nghiên cứu liên quan 40 2.3 Vấn đề thích nghi tốc độ bit 42 2.3.1 Lựa chọn thời khoảng cho phân đoạn video 42 2.3.2 Các phương pháp thích ứng tốc độ bit 43 2.3.2.1 Phương pháp dựa vào thông lượng 44 2.3.2.2 Phương pháp dựa vào đệm .45 2.4 Kỹ thuật định tuyế n cho luồng video mạng SDN 46 2.4.1 Xây dựng kiến trúc điều khiển đề xu ất 47 2.4.2 Tính tốn băng thông mạng SDN 50 2.4.3 Lưu đồ thuật toán điều khiể n SDN 51 2.5 Thuật tốn thích ứng tốc độ bit với chế định tuyến đề xuất 52 2.6 Thiết lập thí nghiệm kịch đánh giá 55 2.6.1 Thiết lập thí nghiệm 55 2.6.2 Các kịch thí nghiệm .56 2.6.2.1 Kịch băng thông hai mức 56 2.6.2.2 Kịch băng thông thực tế 57 2.7 Đánh giá kết thảo luận .58 2.8 Kết luận chương 61 CHƯƠNG GIẢI PHÁP CẢI THIỆN QoE TRONG STREAMING VIDEO VBR QUA GIAO THỨC HTTP DỰA TRÊN SDN 62 3.1 Giới thiệu chương .62 3.2 Các cơng trình liên quan đến giải pháp đề xuất 62 3.3 Kiến trúc đề xu ất cho streaming video VBR qua HAS SDN 65 3.4 Truyền video VBR qua giao thức HTTP d ựa kỹ thuật định tuyến định kỳ thích nghi SDN 66 3.4.1 Vấn đề biến đổi thông lượng lựa chọ n tốc độ bit tối ưu cho video VBR 66 3.4.2 Đề xuất thuật tốn thích nghi VBR kết hợp với định tuyế n dựa SDN (VASR) 68 3.4.3 Kỹ thuật định tuyến định kỳ định tuyến thích nghi dựa SDN đề xuất 71 3.4.3.1 Định tuyến định kỳ dựa SDN (SPR) 71 3.4.3.2 Định tuyến thích nghi dựa SDN khơng có giám sát (SAR) .73 3.4.3.3 Định tuyến thích nghi dựa SDN có giám sát (SARM) 74 iii 3.4.4 Thực nghiệm đánh giá kết 75 3.4.4.1 Thiết lập thực nghiệm .75 3.4.4.2 Các kịch thí nghiệm 78 3.4.4.3 Đánh giá kết 79 3.5 Giải pháp cải thiện QoE cho video VBR qua giao thức HTTP dựa SDN 87 3.5.1 Ước tính thơng lượng mức đệm cho giải pháp đề xuất 87 3.5.2 Thuật toán thích nghi đề xuất MUNTH 89 3.5.3 Đánh giá hiệu 92 3.5.3.1 Thiết lập thí nghiệm kịch 92 3.5.3.2 Lựa chọn ngưỡng đệm tốt 93 3.5.3.3 So sánh, đánh giá phương pháp 96 3.6 Kết luận chương .100 CHƯƠNG GIẢI PHÁP PHÂN BỔ BĂNG THÔNG VÀ CẢI THIỆN QoE TRONG STREAMING VIDEO CHO ĐỒNG THỜI NHIỀU NGƯỜI DÙNG 102 4.1 Giới thiệu chương .102 4.2 Các vấn đề liên quan ý tưởng xây dựng giải pháp .102 4.3 Kiến trúc phân bổ băng thông đề xuất dựa SDN cho nhiều người dùng đồng thời truy cập 105 4.4 Đề xuất giải pháp phân bổ băng thông công SDN (MSMA-0) 107 4.5 Đề xuất giải pháp phân bổ băng thơng thích ứng SDN (MSMA-1) 110 4.6 Thiết lập thí nghiệm kịch 113 4.6.1 Thiết lập thí nghiệm 113 4.6.2 Các kịch thí nghiệm .114 4.7 Đánh giá kết thảo luận 115 4.7.1 Tham số công bằ ng (fairness), hiệu (efficiency) ổn định (stability) 115 4.7.2 Đánh giá hiệu 116 4.8 Kết luận chương .122 KẾT LUẬN .124 DANH MỤC CÁC CƠNG TRÌNH ĐÃ CƠNG BỐ CỦA LUẬN ÁN 126 TÀI LIỆU THAM KHẢO 127 iv DANH MỤC CÁC TỪ VIẾT TẮT Từ viết tắt Ý nghĩa tiếng Anh AGG_DF Aggressive Default AGG_RR Aggressive Rerouting API Application Programing Interface ARP Address Resolution Protocol BBA CBR CDF Buffer-based Algorithms Constant Bit Rate Cumulative Distribution Function CDN DASH FIFO GPS HAS HDS Content Delivery Networks Dynamic Adaptive Streaming over HTTP First-In First-Out Global Positioning System HTTP-based Adaptive Streaming HTTP Dynamic Streaming (HDS) Ý nghĩa tiếng Việt Phương pháp Aggressive mặc định Phương pháp Aggressive có định tuyến lại dựa SDN Giao diện lập trình ứng dụng Giao thức để tìm địa phần cứng (địa MAC) Thuật toán dựa vào đệm Tốc độ bit cố định Hàm phân phối tích lũy Mạng phân phối nội dung Streaming thích ứng động qua HTTP Vào trước trước Hệ thống định vị tồn c ầu Streaming thích ứng qua HTTP Streaming động qua HTTP phát triển hệ thống Adobe Streaming trực tiếp qua HTTP Giao thức truyền siêu văn Giao thức Internet LLDP developed by Adobe Systems HTTP Live Streaming Hypertext Transfer Protocol Internet Protocol International Organization of Standardization International Telecommunication Union Link Layer Discovery Protocol MAC Media Access Control MPD Media Presentation Description MPEG MSMA Moving Picture Expert Group Nhóm chun gia hình ảnh động Streaming đa phương tiện đa Media Streaming Multiple Access truy cập iMpede sUspend and attaiN Phịng tránh đóng băng lựa poTential patH chọn tuyến tốt OpenFlow Switch Bộ chuyển mạch OpenFlow Open Networking Foundation Tổ chức chuẩn hóa mạ ng mở HLS HTTP IP ISO ITU MUNTH OFS ONF Hiệp hội Tiêu chuẩ n quốc tế Liên hiệp viễn thông quốc tế Giao thức khám phá l ớp liên kết Điều khiển truy cập môi trường (gọi địa MAC) Mơ tả trình diễn đa phương tiện v QP Open vSwitch Database management Protocol Probe AND Adapt Quality of Experience Quality of Service Quantization Parameter RTCP Real-Time Control Protocol RTMP Real-Time Messaging Protocol RTP Real-time Transport Protocol RTSP Real-Time Streaming Protocol RTT Round-Trip Time SDN-Assisted Novel QoE control method for DASH (HTTP/3) SDN-based Adaptive Routing without monitoring OVSDB PANDA QoE QoS Giao thức cấu hình OpenFlow SARA Segment-aware Rate Adaptation SARM SDN-based Adaptive Routing with Monitoring SDN Software-Defined Network SPR SDN-based Periodical Routing SSL Secure Sockets Layer SVC TBF TC TCP TLS URL Scalable Video Coding Token Bucket Filter Traffic Control Transmission Control Protocol Transport Layer Security Uniform Resource Locator Thăm dị thích ứng Chất lượng trải nghiệ m Chất lượng dịch vụ Tham số lượng tử Giao thức điều khiển th ời gian thực Giao thức tin thời gian thực Giao thức truyền tải th ời gian thực Giao thức streaming th ời gian thực Thời gian trọn vòng Phương pháp kiểm sốt QoE cho DASH (HTTP/3) có h ỗ trợ SDN Định tuyến thích ứng d ựa SDN khơng giám sát Thích ứng tốc độ cảm nhận phân đoạn Định tuyến thích ứng d ựa SDN có giám sát Mạng điều khiển phần mềm Định tuyến định kỳ dựa SDN Tiêu chuẩn bảo mật an toàn lớp ứng dụng Mã hóa video có th ể mở rộng Bộ lọc nhóm mã thơng báo Điều khiển lưu lượng Giao thức điều khiển truyền vận Bảo mật tầng truyề n tải Địa web VASR VBR Adaptation algorithm crosslayered with SDN-based Routing Variable Bit Rate Video on Demand Extensible Markup Language Định tuyến thích nghi cho video VBR dựa SDN Tốc độ bit biến đổi Video theo yêu cầu Ngôn ngữ đánh dấu mở rộng SAND/3 SAR VBR VoD XML vi DANH MỤC HÌNH VẼ Hình 1.1 Các loại thiết bị khác kết n ối với máy chủ streaming Hình 1.2 Hệ thống HTTP streaming Hình 1.3 Các hướng tiếp cận liên quan đến HTTP Streaming .9 Hình 1.4 Mơ hình truy ền video DASH 16 Hình 1.5 Cấu trúc tệp MPD [49] 17 Hình 1.6 Tốc độ bit chất lượng tức thời củ a video (a) CBR (b) VBR 18 Hình 1.7 Kiến trúc l ớp SDN .25 Hình 1.8 Cấu trúc môi trường OpenFlow [73] .29 Hình 1.9 So sánh cấu trúc chuyển mạch truyền thống (a) cấu trúc OFS (b) 29 Hình 1.10 Các thành phần OpenFlow switch [74] 29 Hình 1.11 Luồng xử lý gói tin OpenFlow Switch [74] 31 Hình 1.12 Cơng cụ triển khai đồ hình mạng SDN .35 Hình 1.13 Kiến trúc củ a Floodlight Controller [83] .37 Hình 2.1 Kiến trúc điều khiển đề xuất .47 Hình 2.2 Quá trình thi ết lập đường dẫn 49 Hình 2.3 Lưu đồ thuậ t tốn điều khiển SDN 51 Hình 2.4 Lưu đồ thuậ t tốn streaming video thích ứng qua HTTP SDN 53 Hình 2.5 Sơ đồ mạng s dụng thí nghiệ m 55 Hình 2.6 Băng thông thực tế hai đường d ẫn triển khai thí nghiệm 57 Hình 2.7 Kết so sánh với trường hợp băng thông hai mức 59 Hình 2.8 Kết so sánh với trường hợp băng thông thực tế 60 Hình 3.1 Kiến trúc đề xuất cho streaming video thích ứng HTTP qua SDN .65 Hình 3.2 Sự biến độ ng tốc độ bit mức chất lượng video VBR .67 Hình 3.3 Lưu đồ thuật toán định tuyến đị nh kỳ 72 Hình 3.4 Lưu đồ thuật tốn định tuyến thích nghi 73 Hình 3.5 Lưu đồ thuật tốn định tuyến thích nghi có giám sát 74 Hình 3.6 Sơ đồ mạng thí nghiệm 76 Hình 3.7 Các kịch băng thơng đường dẫn sử dụng thí nghiệm 78 Hình 3.8 Kết thích nghi cho phương pháp non-SDN 80 Hình 3.9 Kết thích nghi cho phương pháp “SARA” .80 Hình 3.10 Kết thích nghi cho phương pháp “SDN-based SARA” 80 Hình 3.11 Kết thích nghi cho giải pháp đị nh tuyến định kỳ với SDN (SPR) 81 Hình 3.12 Kết định tuyến thích nghi khơng có q trình giám sát (SAR) 81 Hình 3.13 Kết định tuyến thích nghi có q trình giám sát (SARM) 81 Hình 3.14 Kết tốc độ bit thực tế tất phương pháp 83 vii Hình 3.15 Kết mức chất lượng tất phương pháp 83 Hình 3.16 Kết mức đệm tất phương pháp 84 Hình 3.17 Hàm phân phối tích lũy (CDF) tốc độ bit phương pháp 85 Hình 3.18 Hàm phân phối tích lũy (CDF) tốc độ tải phương pháp 85 Hình 3.19 Kết thí nghiệm cho phương pháp MUNTH ( = 10 ) 93 Hình 3.20 Kết thí nghiệm cho phương pháp MUNTH ( = 15 ) 94 Hình 3.21 Kết thí nghiệm cho phương pháp MUNTH ( = 20 ) 94 Hình 3.22 Kết thí nghiệm cho phương pháp MUNTH ( = 25 ) 94 Hình 3.23 Lựa chọn điểm tốt cho ngưỡng đệm 96 Hình 3.24 Mức đệm c tất phương pháp 97 Hình 3.25 Tốc độ bit tốc độ tải phương pháp 97 Hình 3.26 Hàm phân phối tích lũy tốc độ bít (a) tốc độ tải (b) phương pháp 98 Hình 3.27 Chỉ số QoE dự đoán tất phương pháp 100 Hình 4.1 Kiến trúc đề xuất cho vấn đề bottleneck bước hoạt động 105 Hình 4.2 Định dạng bả n tin Packet-in [8] 107 Hình 4.3 Lưu đồ thuậ t tốn MSMA-0 đề xuất .109 Hình 4.4 Sơ đồ mạng s dụng thí nghiệ m 113 Hình 4.5 Tốc độ tải, mức đệm tốc độ bit trung bình tất phương pháp liên kết thắt cổ chai với 4Mbps trườ ng hợp video VBR 117 Hình 4.6 Tốc độ tải, mức đệm tốc độ bit trung bình tất phương pháp liên kết thắt cổ chai với 4Mbps trườ ng hợp video CBR 118 Hình 4.7 So sánh tính cơng (a), hiệu (b) ổn định (c) tất phương pháp 119 viii DANH MỤC BẢNG BIỂU Bảng 0.1 Tóm lượt đặc điểm giải pháp đề xuất với số nghiên cứu Bảng 1.1 Tính chuẩn truyền video dựa HTTP 12 Bảng 1.2 Chỉ số QoE thông thường .22 Bảng 1.3 Tóm tắt số tính chất mạng SDN mạng truy ền thống 27 Bảng 1.4 Các thành ph ần Flow entry 30 Bảng 1.5 Các loại tin Asynchronous 32 Bảng 1.6 Các tin Controller-to-Switch 32 Bảng 1.7 Các loại tin Symmectric 33 Bảng 1.8 Các mô đun Floodlight Controller 38 Bảng 2.1 Các ký hiệu sử dụng giải pháp ý nghĩa 43 Bảng 2.2 So sánh phương pháp thích ứng khác dựa sở đệm 46 Bảng 2.3 Bảng tin StatsResponse 50 Bảng 2.4 So sánh tham số chất lượng trường hợp băng thông hai mức .61 Bảng 2.5 So sánh tham số chất lượng trường hợp băng thông thực tế 61 Bảng 3.1 Thông tin mức chất lượng video thí nghiệm 76 Bảng 3.2 Các tham số đánh giá chất lượng video phương pháp 86 Bảng 3.3 So sánh giá trị BTh khác cho giải pháp MUNTH 95 Bảng 3.4 Các tham số đánh giá chất lượng giải pháp .99 Bảng 4.1 So sánh hiệu phương pháp vớ i video VBR 120 Bảng 4.2 So sánh hiệu phương pháp với video CBR 120 Bảng 4.3 Thống kê tham số chất lượng QoE phương pháp .121 MỞ ĐẦU Tính cấp thiết luận án Với xu hướng phát triển điện tốn đám mây cơng nghệ kết nối vạn vật IoT, thập kỷ vừa qua ch ứng kiến phát triển mạnh mẽ việc tiêu thụ nội dung đa phương tiện, đặc biệt video có độ phân giải cao Theo dự báo Cisco, truyề n phát video chiếm khoảng 82% tổng lưu lượng truy cập Internet toàn cầu [1] Các công nghệ mạng 4G, 5G hay đường truyền cáp quang làm cho nhà cung cấp dịch vụ Internet phần đáp ứng nhu cầ u 4.3 tỉ người dùng toàn cầu [2] Tuy nhiên liền với phát triển công nghệ truyền tải, nhà cung cấp nội dung cho nhiều nội dung đa phương tiện ngày đa dạng chất lượng Điển hình video thực tế ảo, để người dùng trải nghiệm xem t ốt cần truyền video 360 độ, độ phân giải 12K (12 288×6.480) tốc độ bit tương đương 5.2 Gbps [3] Điều thúc đẩy nhà nghiên cứu tìm phương pháp truyền nhằm cải thiện, nâng cao chất lượng nội dung truuyền tải video đến người dùng Trong năm qua, kỹ thuật phổ biến cho việc truyền phát video qua mạng Internet kỹ thuật streaming thích ứng qua giao thức truyền siêu văn HTTP, viết tắt HAS [4], [5] Bên cạnh đó, đời tảng truyền video thích ứng động HTTP (DASH) [6] phần làm điều đó, đồng thời xóa tan độc quyền phương thức truyền video t ồn từ lâu công ty gây khó khăn cho nhà cung cấp dịch vụ phải mã hóa, đóng gói video theo nhiều định dạng khác để phục vụ cho nhiều thiết bị, nhiều người dùng Về DASH giống công nghệ cũ điểm chia video thành nhiều đoạn nhỏ đoạn mã hóa theo mức chất lượng khác để máy khách u cầu Tuy nhiên chuẩn hóa tổ chức quốc tế hỗ trợ hầu hết phương pháp mã hóa video, audio thiết bị nhiều hãng khác nên DASH phương pháp sử dụng nhiều Internet Tuy nhiên, chưa có chuẩn cụ thể việc streaming video thích ứng HAS nên thực hi ện để nâng cao chất lượng trải nghiệm người dùng (QoE).Vì vậy, vấn đề thu hút quan tâm nghiên cứu nhà khoa học Từ khía cạnh khác, mạng điều ển phần mềm SDN [7] kiến trúc mạng mới, thành phần điều khiển mạng lập trình tách rời khỏi thành phần chuyển tiếp Giống công nghệ DASH, đời SDN giải xung đột từ nhà sản xuất thiết bị cho đế n giao diện thi ết bị, điều vốn gây khó khăn việc cấu hình có thiết bị tham gia vào mạng 2 Trong SDN, với thống mặt phẳng điều khiển xuyên suốt thiết bị thông qua giao thức OpenFlow [8] cho phép cấu hình thiết bị mạng cách tự động từ điểm thông qua phần mềm điều khiển Thêm vào đó, giao thức OpenFlow đảm bảo tính liên kết điều khiển thiết bị tầng vật lí, giúp thu thập thông tin mạng cách dễ dàng Bộ điều khiển SDN truy vấn, quản lý trạng thái hoạt động thiết bị mạng, thực việc điều khiể n cấu hình mạng Đặc biệt, điều khiển phát triển ứng dụng định tuyến phân bổ băng thơng cụ thể có nhiều ưu điểm so với phương pháp định tuyến “best-effort” hay phân bổ băng thông mạng truyền thống Với chế quản lý tập trung tính linh hoạt định tuyế n mà SDN cung cấp giúp tăng hiệu suất ứng dụng streaming video Từ nhu cầu thực tiễn streaming video Internet tiềm chưa khai thác hết hai công nghệ HAS SDN, luận án đề xuất giải pháp nhằm nâng cao chất lượng truyền video thích ứng qua giao thức HTTP dựa mạng điều khiển phần mềm SDN Những vấn đề tồn Để tăng thêm n hiều tính kỹ thuật truyền tải trước, tiêu chuẩn DASH đời để đối phó với biến động lớn việc phân phối nội dung đa phương tiện khác Trong vài năm qua, nhiều thuật tốn thích ứng tốc độ bit giới thiệu để cải thiện chất lượng trải nghiệm người dùng (QoE) Sự khác biệt phương pháp chủ yếu dựa vào thông tin đầu vào, từ đặc điểm mạng đế n tham số lớp ứng dụng đệm tốc độ tải xuống Trong nguyên lý HAS, tất thuật toán định tốc độ bit phân đoạn video tải xuống dựa biến đổi thông lượng mức đệm đo phía máy khách Cho đến nay, loại thuật tốn chia thành ba nhóm chính, bao gồm: nhóm dựa thơng lượng [5], [9-12]; nhóm dựa đệm [13-16] nhóm d ựa vào kết hợp hai thơng số [17-20] Trong tất cơng trình nghiên cứu trên, cho dù phương pháp thuộc nhóm có mục tiêu tải video có tốc độ bit cao hay mức chất lượng tốt nhằm nâng cao tham số chất lượng video, cải thiện trải nghiệm QoE người dùng Tuy nhiên, hầu hết thuật toán tập trung vào việc cải thiện chế thích ứng phía máy khách mà khơng xem xét tài nguyên sẵn có mạng để khai thác tối ưu Tại thời điểm bắt đầu nghiên cứu luận án, phía mạng, tác giả khảo sát số cơng trình định tuyến đường dẫn tối ưu dựa sở mạng SDN [21-28] Bằng việc sử dụng thông tin trạng thái ứng dụng quản lý tài nguyên mạng để tối ưu hóa trải nghiệm người dùng, số phương pháp phân loại luồng video vào lớp ưu tiên khác để thực sách định tuyến [21-23], [28] Với luồng có mức ưu tiên cao streaming vào đường dẫn khả thi lưu lượng cao liên kết xác định số lượng luồng phép streming Trong [24], [27] đưa kỹ thuật định hình lưu lượng truy cập động dựa SDN cho việc truyền phát video qua giao thức HTTP Các tác giả sử dụng mơ hình tối ưu hóa nhằm đạt thơng lượng tối đa dịch vụ DASH cách chọn đường dẫn tối ưu cho gói video truyền qua mạng SDN Với giải pháp [25], tác giả đề xuất kiến trúc SDN để giám sát điều kiện mạng luồng streaming thời gian thực thay đổi động đường dẫn định tuyến kỹ thuật chuyển mạch nhãn đa giao thức để cung cấp trải nghiệm xem video cách tin cậy Việc thực định tuyến dựa SDN/OpenFlow cho video mã hóa dạng SVC thích ứng đề xuất [26] Trong đó, mơ đun chức cho điều khiển SDN thiết kế để hỗ tr ợ hoạt động định tuyến mạng cách có hiệu Nhìn chung, nghiên cứu mang lại QoE hiệu phương pháp đinh tuyến truyền thống, nhiên chủ yếu tập trung khía cạnh định tuyến phía mạng mà khơng quan tâm đến vấn đề thích ứng chất lượng phía máy khách để phân bổ tài nguyên cho phù hợ p Cũng bối cảnh streaming video, có vài nghiên cứu vấn đề nhiều người dùng truy cập mạng chia sẻ cơng trình khoa học [29-34] Các phương pháp chủ yếu tập trung vấn đề chia sẻ băng thông cho nhiều máy khách đồng thời truy cập vào liên kết tắc nghẽ n thắt cổ chai Với mục tiêu xoay quanh vào ba tham số công (Fairness), hiệu (Efficiency) ổ n định (Stability) cho tất người dùng mà phương pháp khác khác Có số cơng trình tập trung vào tính cơng mà khơng quan tâm đến tính hiệ u ổn định [33] Một số cải thiện tính cơng hiệu mà khơng xem xét tính ổn định [32], thơng số quan trọng ảnh hưởng mạnh đến QoE Các tác giả [29], [31] nghiên cứu giải thuật thích ứng phía máy khách để cải thiện ba tham số đưa tập hợp phương pháp có hệ thống nhằm cố gắng đảm bảo đánh đổi tối ưu mục tiêu đề cập Tuy nhiên giải pháp không đề cập đến vấn đề phân chia băng thơng phía mạng Các cơng trình khác [32-34] thành công công việc phân bổ băng thông cho nhiều người dùng mạng cạnh tranh khơng biết tình trạng máy khách hoạt động Từ ưu điểm hạn chế cơng trình trên, vấn đề streming video qua Internet thu hút quan tâm đầu tư nhà nghiên cứu Và sở đó, để nâng cao chất lượng streaming video, luận án tập trung đề xuất giải pháp dựa vào số đặc điểm so với cơng trình nghiên cứu tồn phát họa Bảng 0.1 sau đây: Bảng 0.1 Tóm lượt đặc điểm giải pháp đề xuất với số nghiên cứu Giải pháp Cơng nghệ Thích ứng tốc độ bit Định tuyến Phân bổ băng thông [9] - [20] HAS Thông lượng/Mức đệm Truyền thống - [21] - [23] SDN - QoS - [24], [27] Lai DASH Định kỳ - [34] SDN DASH - Thích nghi [29], [31] HAS Thông lượng/Mức đệm - Công Đề xuất Lai Thông lượng/Mức đệm Linh hoạt - Đề xuất Lai Thơng lượng/Mức đệm - Cơng bằng/Thích nghi Mục tiêu nghiên cứu Xuất phát từ tình hình thực tế vấn đề tồn lĩnh vực video streaming, luận án đề mục tiêu cụ thể sau đây: - Đề xuất thực thuật tốn thích ứng chất lượng video CBR giao thức HTTP SDN nhằ m c ải thiện vài tham số ảnh hưởng đến QoE người dùng Tại phía máy khách, thuật tốn thích ứng tốc độ bit đề xuất nhằm mục đích lựa chọn mức chất lượng video tốt Tại phía mạng, điều khiển SDN tính tốn băng thơng khả dụng đường truyền để tìm đường dẫn tối ưu cho việc streaming từ máy chủ đến máy khách - Đề xuất thực thuật tốn thích ứng chất lượng streaming video VBR qua giao thức HTTP định tuyến động dựa SDN Thuật tốn thích ứng tốc độ đề xuất khơng ứng phó hiệu với biến động thơng lượng mạng mà cịn phải ứng phó với biến động tốc độ bit video dạng VBR, tránh tượng đóng băng video Hai kỹ thuật định tuyến đề xuất định tuyến định kỳ định tuyến thích nghi tích hợp điều khiển SDN để lựa chọn đường dẫ n tốt cho trình streaming video - Đề xuất thực phương pháp phân bổ băng thông liên kết thắt cổ chai dựa kỹ thuật SDN/OpenFlow với thuật tốn thích nghi tốc độ sở DASH nhằm cải thiện QoE người dùng Giải pháp đề xuất việc phân bổ băng thông công thích ứng điều khiển SDN kết hợp với thuật tốn thích ứng tốc độ phía máy khách Đề xu ất nhằm mục đích lựa chọn tốc độ bit video phù h ợp cho tất người dùng đồng thời streaming liên kết mạng thắt cổ chai, đảm bảo tính cơng bằng, ổn định hiệu sử dụng băng thông Đối tượng nghiên cứu Luận án tập trung nghiên cứu đối tượng sau đây: - Công nghệ HAS SDN/OpenFlow - Hệ thống streaming video thích ứng qua giao thức HTTP - Hệ thống streaming video thích ứng qua mạ ng điều khiển phần mềm SDN - Kết hợp công nghệ HAS SDN streaming video Phạm vi nghiên cứu Các nghiên cứu luận án gi ới hạn phạm vi đây: - Streaming video chia thành hai nhóm streaming tương tác streaming không tương tác Luận án tập trung vào streaming khơng tương tác máy khách chiều nh ận video từ máy chủ - Không giải toán streaming trực tiếp (Live Streaming) mà tập trung vào streaming video theo yêu cầu (VoD) - Thực giải pháp lớp ứng dụng, không can thiệp vào lớp lớp ứng dụng - Thực thuật tốn thích ứng chất lượng streaming video, khơng quan tâm đến q trình mã hóa giải mã liệu video - Tập trung vào giai đoạn streaming thực (máy khách nhận hiển thị liệu cách đồng thời), không tập trung vào giai đoạn nạp đệm ban đầu - Tỉ lệ gói thi ết lập 0% giả sử băng thông dùng thực nghiệm bao gồm biến động gây b ởi gói, trễ gói liệ u Phương pháp nghiên cứu Luận án sử dụng phương pháp tìm hiểu, nghiên cứu lý thuyết, xây dựng giải pháp đến thực nghiệm Trước hết, tác giả tìm kiếm tài liệu xem xét tất vấn đề lý thuyết giới có liên quan đến luận án, xây dựng mơ hình giải thuật sau thiết lập thí nghiệm, tiến hành đo đạc kết quả, so sánh đánh giá Những đóng góp luận án Luận án đạt số kết nghiên cứu định với đóng góp sau: - Đóng góp thứ nhất, luận án đề xuất kiến trúc SDN/OpenFlow mở r ộng kết hợp với công nghệ DASH việc streaming video dạng CBR Tại phía máy khách, phương pháp thực thuật tốn thích nghi tốc độ bit dựa ước lượng thông lượng đệm để định mức chất lượng video tốt Tại phía mạng, nhờ vào chế quản lý tập trung có nhìn tổng thể mạng SDN nên giải pháp xây dựng số mô đun điều khiển SDN để thực chức định tuyến đường dẫn tối ưu Kết thực nghiệm cho thấy giải pháp đề xuất cải thiện cách đáng kể tham số chất lượng video so với giải pháp không sử dụng mạng SDN Kết cơng bố cơng trình [C1], [J1] - Đóng góp thứ hai, luận án đề xuất hệ thống streaming video dạng VBR qua giao thức HTTP SDN Thuật tốn thích nghi tốc độ bit phía máy khách giải pháp đề xuất có th ể thích nghi tốt với dao động mạnh thông lượng mạng biến đổi liên tục tốc độ video dạng VBR Bên cạnh đó, điều khiển SDN, luận án xây dựng hai chế định tuyến, định tuyến định kỳ định tuyến thích nghi để tìm thấy đường dẫn tốt cho luồng video streaming Các kết đánh giá thực nghiệm giải pháp đề xuất nâng cao đáng kể chất lượng trải nghiệm QoE người dùng so với giải pháp tồn Kết cơng bố cơng trình [C2], [J2], [J3] - Đóng góp thứ ba đề xuất giải pháp phân bổ băng thông công thích ứng cho nhiều người dùng đồng thời truy cập mạng chia sẻ Chính sách phân bổ băng thơng dựa kiến trúc SDN/OpenFlow đề xuất với mục tiêu công bằng, hiệu ổn định cho tất người dùng chia sẻ tài nguyên tạ i nút thắt cổ chai, đồng thời tối đa hóa số máy khách truy cập tối thiểu hóa số máy khách giảm QoE Đề xuất giải pháp phân chia băng thơng kết hợp với thuật tốn thích ứng tốc độ, kết mơ cho thấy đóng góp giải pháp đạt tốc độ bit trung bình video cao hơn, tránh hi ện tượng đóng băng video cải thiệ n đáng kể QoE người dùng Kết cơng bố cơng trình [C3], [J3] Cấu trúc nội dung luận án Nội dung luận án trình bày chương tóm tắt sau: Chương Tổ ng quan kỹ thuật truyền video qua giao thức HTTP mạng điều khiển phần mềm SDN: Khái quát kỹ thuật HTTP streaming trình bày tổng quan kỹ thuật streming video thích ứng qua giao thức HTTP mà đặc trưng cơng nghệ DASH Phân tích ý nghĩa tham số ảnh hưởng đến QoE lĩnh vực stream video để làm sở đánh giá giải pháp đề xuất với phương pháp đối sánh khác Trong chương nêu khái niệm phân tích kiến trúc mạng điều khiển phần mềm SDN, ưu điểm mạng SDN so với mạng truyền thống Giao thức OpenFlow tiêu chuẩn cho việc xây dựng giải pháp SDN Triển khai mạng SDN thơng qua cơng cụ thí nghiệm cho đề xuất luận án đề cập đến Từ đặc điểm mạng SDN công nghệ HAS, luận án đề xuất giải pháp định tuyến phân bổ băng thông kết hợp với thuật tốn thích ứng tốc độ chương Chương Truyền video CBR thích nghi giao thức HTTP dựa kỹ thuật định tuyến SDN: Trong chương đề xuất kiến trúc cho điều khiển SDN nhằm thực sách định tuyến đường dẫn kết h ợp với thuật tốn thích ứng tốc độ bit phía máy khách để lựa chọn mức chất lượng video phù hợp Thiết lập thực nghiệm để đánh giá giải pháp đề xuất với tham số ảnh hưởng đến QoE tốc độ bit trung bình hay biên độ giảm mức chất lượng video Chương Giải pháp cải thiện QoE streaming video VBR qua giao thứ c HTTP dựa SDN: Đề xuất hai giải pháp truyền thích ứng video có tốc độ bit biến đổi VBR qua giao thức HTTP dựa kỹ thuật định tuyến định kỳ định tuyến thích nghi SDN - Trong giải pháp thứ sử dụng thuật tốn thích ứng tốc độ dựa thông lượng ngưỡng đệm linh hoạt để ứng phó với biến động mạnh củ a tốc độ bit video VBR Đồng thời dựa kỹ thuật định tuyến định kỳ định tuyến thích nghi cấu hình điều khiển SDN để lựa chọn đường dẫn tốt cho luồng video streaming - Trong giải pháp thứ hai cải tiến thuật tốn thích ứng tốc độ bit việc ước lượng trước mức đệm để tránh trường hợp video bị đóng băng Về phía mạng giải pháp định tuyến đường dẫn dựa vào tham số ràng buộc độ ổn định biên độ khả dụng băng thông nhằm lựa chọn tuyến tối ưu từ máy chủ đến máy khách Thiết lập thực nghiệm đánh giá kết cho hai giải pháp đề xuất với phương pháp tồn Chương Giải pháp phân bổ băng thông cải thiện QoE streaming video cho đồng thời nhiều người dùng: Chương đề xuất hai giải pháp, phân bổ băng thơng cơng phân bổ băng thơng thích ứng dựa cấu trúc SDN cho nhiều người dùng đồng thời truy cập liên kết tắc nghẽn Đề xuất thuật tốn thích ứng tốc độ bít áp dụng cho video CBR VBR Cuối thiết lập thí nghiệm đánh giá kết Kết luận chung luận án s ẽ tóm tắt lại đóng góp số kết đạt hướng phát triển đề tài tương lai 8 CHƯƠNG TỔNG QUAN VỀ KỸ THUẬT TRUYỀN VIDEO QUA GIAO THỨC HTTP VÀ MẠNG ĐIỀU KHIỂN BẰNG PHẦN MỀM SDN 1.1 Đặt vấn đề 1.1.1 Vấn đề HTTP streaming Ngày HTTP streaming công nghệ phổ biến mà nội dung đa phương tiện phân phố i liên tục từ máy chủ đến thiết bị cuối [4], [5], [35] Các phương thức streaming ngày cải thiện cách đáng kể khả mạ ng nhiều nhu cầu ứng dụng khác HTTP streaming đời sống Kết nối băng thông rộng v ới phát triển thiết bị di động hiệu suất cao tạo suy nghĩ rằng, người dùng xem mong muốn, lúc t ại địa điểm Như minh họa Hình 1.1, người dùng sử dụng nhiều loại thiết bị khác để truy cậ p vào số lượng l ớn nội dung đa phương tiện thông qua kết nối khác với tốc độ truy cập Internet khác Vì vậy, việc tạo kỹ thuật tự động cung cấp chất lượng tốt cho người tiêu dùng trở nên thách thức quan trọng cho nhà nghiên cứu Máy chủ streaming Hình 1.1 Các loại thiế t bị khác kết nối v ới máy chủ streaming Hình 1.2 thể cấu trúc HTTP streaming Hoạt động hệ thống tập hợp yêu cầ u phản hồi HTTP nội dung đa phương tiện cách Máy chủ web server tiêu chuẩn có chức tạo trình phương tiện khác HTTP streaming thích ứng Việc tạo trình phương tiện thực ngoại tuyến (chế độ tĩnh) theo yêu cầu (chế độ động) Trong chế độ tĩnh, tệp mơ tả (MPD) trình nội dung phương tiện tạo trước bắt đầu phiên HTTP streaming thích ứng Trong chế độ động, máy chủ tạo phân đoạn đa phương tiện dựa yêu cầu HTTP GET nhận Máy chủ HTTP Yêu cầu HTTP phân đoạn Đáp ứng HTTP phân đoạn Yêu cầu HTTP phân đoạn … Internet … Đáp ứng HTTP phân đoạn Yêu cầu HTTP phân đoạn n Yêu cầu HTTP phân đoạn n Đáp ứng HTTP phân đoạn n Đáp ứng HTTP phân đoạn n Tường lửa Máy khách HTTP Khối thích ứng tốc độ Hình 1.2 Hệ thống HTTP streaming Tại phía máy khách gửi loạt yêu cầu GET đến máy chủ, yêu cầu phân đoạn đa phương tiện đại diện Trong HTTP streaming thích ứng, máy khách thực điều chỉnh tốc độ cách xác định trình phương tiện phù hợp với dung lượng mạng cho phép Trong luận án này, việc thích ứng diễn lần trước yêu cầu phân đoạn phương tiện Từ hệ thống HTTP streaming trên, hướng tiếp cận liên quan đến vấn đề tập trung vào ba yếu tố Hình 1.3 Tại phía máy ch ủ HTTP lưu mức chất lượng nội dung đa phương tiện v ới tệp MPD để phân phối đến máy khách Tại phía máy khách HTTP, phát triển thuật tốn thích ứng tốc độ để định phân đoạn đa phương tiện s ẽ tải Tại phía mạng tập trung nghiên cứu giải pháp quản lý, giám sát, phân phối nguồn tài nguyên định tuyến đường cho luồng lưu lượng Mạng Máy khách HTTP HTTP Streaming Máy chủ HTTP Hình 1.3 Các hướng tiếp cận liên quan đến HTTP Streaming Vậy để nâng cao chất lượng streaming video, phạm vi luận án tiếp cậ n theo hướng phía máy khách phía mạng Tại phía máy khách, xem xét đề xuất thuật tốn thích ứng tốc độ để lựa chọn mức chất lượng video phù hợp Tại 10 phía mạng, tập trung vào vấn đề định tuyến đường tối ưu phân bổ băng thông hợp lý cho tất người dùng 1.1.2 Kỹ thuật streaming video chuẩn Video loại liệu đa phương tiện quan trọng lĩnh vực truyền thông giải trí Lưu lượng truy cập liệu video tăng trưởng nhanh chóng năm gần Vào thời kỳ đầu kỷ nguyên Internet, năm 1990, video truyền cơng nghệ chuyển mạch gói Dù vậy, truyền qua mạng Internet, người ta thường xuyên gặp yếu tố bất lợi băng thông, độ trễ gói tin Thơng thường, người dùng đọc video sau tải tồn video đĩa cứng máy Thế nhưng, bối cảnh video cung cấp dạng chất lượng cao thông qua Internet yêu cầu nhanh chóng, tiện dụng người dùng Internet đặt lên hàng đầu phương pháp khơng cịn hiệ u Từ đây, toán đặt nhằm truyền tải video đến người dùng cách nhanh chóng, thuận tiệ n mà đảm bảo chất lượng cần thiế t Ta có khái niệm “Streaming Video”, tức truyền liệu video cách liên tục từ nguồn đến hay nhiều đích thơng qua mạng Internet, cho phép liệu video xử lý trước nhận hoàn toàn Streaming video sử dụ ng cách thức phát lạ i đoạn video lưu trữ mạng tới người dùng đầu cuối mà khơng cần tải tồn đoạn video máy tính Về ch ất, streaming video trình chia nhỏ tệp video sau mã hóa thành phân đoạn (segment), gửi phân đoạn t ới đệm máy tính người xem để giải mã hiển thị nội dung phân đoạn Kỹ thuật streaming video sử dụng rộng rãi ứng dụng mạng như: phần mềm (các ứng dụng nghe nhạc, xem phim VLC, KMPlayer; hay trình duyệt web như: Internet Explorer, Google Chrome…) máy khách truy cập xem video từ máy chủ theo mơ hình máy chủ/máy khách; ứng dụ ng họp trực tuyến, đào tạo từ xa Các bước thực kỹ thuật streaming video sau: • Các liệu video sau mã hóa (encode) chia nhỏ thành phân đoạn lưu trữ máy chủ (streaming server) • Phần mềm máy khách (media player, web browser, ) cần kết nối xác định tệp video máy streaming server muố n xem • Yêu cầu streaming c video gửi tớ i máy chủ để tìm tệp video • Chương trình thực streaming chạy máy streaming server chia tệp video thành phân đoạn gửi phân đoạn tới máy khách yêu cầu sử dụng giao thức ràng buộc thời gian (RTSP, RTP, RTCP) 11 • Khi phân đoạ n video máy khách, lưu trữ đệm nội dung phân đoạn giải mã (decode) hiển thị thơng qua chương trình chơi video (Ví dụ: VLC, KMPlayer) Khi phân đoạn video máy khách, lưu trữ đệm nội dung phân đoạn giải mã (decode) hiển thị thơng qua chương trình chơi video (Ví dụ: VLC, KMPlayer) Về bản, streaming video chia thành hai dạng, là: - Video theo yêu cầu (Video on Demand – VoD): Là hệ thống cho phép người dùng lựa chọn xem nội dung video theo ý thích truy ền hình máy tính Video theo u cầu tính động cung cấp giao thức Internet VoD cung cấp cho người dùng tập video có sẵn để lựa chọn - Video thời gian thực hay gọi truyền hình trực tiếp (Live Streaming): Là video truyề n trực tiếp máy tính người dùng thông qua mạng Internet từ nơi diễn kiện b ằng thiết bị truyền thông đa phương tiện Luận án tập trung video theo yêu cầu VoD mà không quan tâm đến video theo thời gian thực Live Streaming Vì streaming video đóng vai trị ngày quan trọng truyền thơng Internet nên có nhiều giao th ức streaming video giới thiệu nay, bao gồm: • Real Time Transport Protocol (RTP) [36] – Giao thức truyền tải thời gian thực: phát triển Audio- Video Transport Working Group Internet Engineering Task Force, chạy giao thức UDP (User Datagram Protocol) • Real Time Messaging Protocol (RTMP) [37]: Được phát triển Macromedia, giao thức độc quyền Adobe Có chức giám sát thông tin truyền dẫn, chất lượng dịch vụ cho phép đồng hóa nhiều luồng đồng thời • HTTP Live Streaming (HLS) [38]: Được phát triển Apple, hoạt động giao thức HTTP Đây giao thức độc quyền Apple, sử dụng rộng rãi hỗ trợ nhiều tảng bao gồm SmartTV, trình duyệt Web, thiết bị di động Android iOS • Adobe HTTP Dynamic Streaming (HDS) [39]: Được phát triể n Adobe Giống HLS, giao thức hoạt động HTTP • IIS Smooth Streaming [40] : Giao thức độc quyền, phát triển Microsoft • MPEG-DASH [6]: Đây tiêu chuẩn quốc tế phê chuẩn MPEG ISO vào năm 2012 sửa đổi vào năm 2019 với tên gọi MPEG-DASH ISO/IEC 23009-1, gi ải pháp thay cho kỹ thuật streaming video độc quyền công nghiệp 12 Trong giao thức trên, RTP RTMP hoạt động tốt mạng IP quản lý Tuy nhiên, Internet ngày nay, mạng quản lý thay thế, nhiều mạng không hỗ trợ truyền phát RTP Ngồi ra, gói RTP RTMP thường khơng phép thơng qua tường lửa Các giao thức cịn lại dựa nề n tảng HTTP Với gia tăng băng thông Internet phát triển vượt bậc World Wide Web, nội dung đa phương tiện phân phối hiệu gói tin lớn sử dụng HTTP Truyền phát HTTP có số lợi ích sở hạ tầng Internet phát triển để hỗ trợ HTTP cách hiệu Ngoài ra, hầu hết tất tường lửa cấu hình để hỗ trợ kết nối HTTP Thêm vào đó, với HTTP Streaming, máy khách quản lý việc truyền phát mà không cần trì trạng thái phiên máy chủ Do đó, việc triển khai dịch vụ với số lượng lớn máy khách không gây tốn nên chủ yếu sử dụng giao thức hoạt động tảng HTTP để cung cấp dịch vụ streaming video Bảng 1.1 so sánh đặc điểm bật chuẩn truyền video dựa HTTP Bảng 1.1 Tính chuẩn truyền video dựa HTTP Tính Adobe HDS Apple HLS [39] [38] Triển khai máy ch ủ HTTP thông thường - Chuẩn quốc tế - Nhiều kênh audio (ngôn ngữ, thích, …) - IIS Smooth Streaming [40] DASH [6] - - - - Bảo mật nội dung linh hoạt Chuyển kênh nhanh Như thấy từ Bảng 1.1, tiêu chuẩn MPEG-DASH hỗ trợ nhiều tính hết so với chuẩ n khác hoạt động tảng HTTP 1.1.3 Vấn đề thích ứng tốc độ HTTP streaming Nhìn chung vấn đề nghiên cứu HTTP streaming đa phương tiện chủ yếu xoay quanh vào việc thích ứng tốc độ streaming đa phương tiện bao gồm khía cạnh sau: 13 - Thứ nhất, phương pháp thích ứng tốc độ phải triển khai với tiêu chí xác định xem tốc độ bit mức chất lượng đa phương tiện cụ thể có phù hợp với băng thơng mạng sẵn có hay khơng Tiêu chí dự đốn nhận định biến đổi thơng lượng điều kiện mạng dao động chế kiểm soát tắc nghẽn nhằm tránh tắc nghẽn HTTP streaming Để đạt tốc độ thích ứng hiệu quả, cần phải phản ứng kịp thời nhanh chóng với không phù hợp tốc độ bit mức chất lượng đa phương tiện băng thông mạng để đạt đến mức chất lượng tối ưu - Thứ hai, thuật tốn thích ứng tốc độ phải kiểm soát đệm máy khách để ngăn chặn đệm trố ng tràn, đệm bị cạn kiệt gây gián đoạn trình streaming tượ ng tràn dẫn đến lãng phí băng thơng - Thứ ba, thuật tốn thích ứng tốc độ phải tính đến thuộc tính hội tụ tốt ngăn ngừa biến động mức chất lượng đa phương tiện, đặc biệt băng thông khả dụng nằm phạm vi tốc độ bit hai mức chất lượng liền kề - Thứ tư, thời lượng phân đoạn đa phương tiện phải lựa chọn cách thích hợp để giảm thiểu overhead HTTP, giảm thiểu độ trễ trình xử lý truyền tải yêu cầu HTTP dẫn đến tối đa hóa tốc độ thích ứng Nhìn chung, giải thuật thích ứng tốc độ bit có ưu nhược khác Tùy vào giải pháp, luận án trình bày chi tiết chương Bên cạnh đó, việc thích ứng tốc đ ộ bit phía máy khách khơng nằm chuẩn MPEGDASH Do đó, việc nghiên cứu phát tri ển thuật toán thích nghi tốc độ bit nhằm đưa đến hiệu cho trình streaming video đượ c tập trung nghiên cứu cho nhà khoa học 1.1.4 HTTP streaming theo cảm nhận người dùng QoE Khái niệm chất lượng trải nghiệm (QoE) định nghĩa mức độ dễ chịu khó chịu người dùng ứng dụng hay dịch vụ Nó kết việc đáp ứng mong đợi người dùng tiện ích thích thú ứng dụng dịch vụ phụ thuộc vào tính cách trạng thái người dùng [41] Việc đánh giá QoE d ựa vào nhiều thông số hệ thống, ngữ cảnh hay người [42] Ta biết rằng, QoE ước tính cách kiểm tra cách chủ quan sử dụng mơ hình khách quan nhận thức người dùng Theo liên minh viễn thông quốc tế ITU, QoE định nghĩa chấp nhận tổng thể ứng dụng dịch vụ người dùng cuối cảm nhận, QoE bị ảnh hưởng kỳ vọng ngữ cảnh người dùng Đối với dịch vụ streaming OTT (Over-the-Top), kỹ thuật streaming phải thích ứng động nội dung đa phương tiện với điều kiện mạng để cải thiện QoE 14 Trong công nghệ HTTP Streaming, QoE người dùng với streaming video chủ đề quan tâm cho nhà nghiên cứu đánh giá dựa vào số lượng hạn chế thơng số khách quan có sẵn hệ thống Trong [43-47], nhà nghiên cứu HTTP streaming đưa số mơ hình QoE có xét đến tham số chất lượng video ảnh hưởng đến QoE Các phần giới thi ệu khái quát hai công nghệ HAS SDN lĩnh vực streaming video Từ sở lý thuyết hai công nghệ này, lu ận án tập trung đề xuất giải pháp nâng cao chất lượng truyền video thích ứng qua giao thức HTTP dựa mạng điều khiển bằ ng phần mềm SDN Đưa tham số ảnh hưởng đến chất lượng trải nghiệm người dùng video khảo sát nghiên cứu liên quan đến việc cải thiện QoE lĩnh vực streaming video Kết luận vấn đề: Từ nghiên cứu bối cảnh HTTP streaming đạt tới chuẩn công nghệ DASH, luận án đề xuất thuật tốn thích ứng tốc độ bit khơng ước tính trước thơng lượng mạng mà cịn dựa đệm thiết bị đầu cuối để lựa chọn mức chất lượng video tốt đến người dùng Tuy nhiên phía người dùng khơng biết tình trạng mạng để khai thác tối ưu nguồn tài ngun sẵn có Vậy để tăng tính linh động điều khiển, luận án kết hợp sử dụng mạng điều khiển phần mềm SDN (Software-Defined Networking) [7]là công nghệ mạng cho phép thay đổi giải pháp điều khiển cách linh hoạt nhằm hỗ trợ cho hệ thống HTTP Streaming, cải thiện QoE cho người dùng Đó động lực cho tác giả luận án đề xuất số giải pháp cho vấn đề “Streaming Video” trình bày chi tiết chương 1.2 Truyền video qua giao thức HTTP 1.2.1 Mơ hình truyền video thích ứng động giao thức HTTP (DASH) 1.2.1.1 Khái quát chung Truyền video dựa tảng HTTP trở nên phổ bi ến triển khai thương mại Các tảng truyền video HTTP Live Streaming (HLS) Apple [38], Smooth Streaming Microsoft [40] HTTP Dynamic c Adobe [39] dựa HTTP để truyền tải video Tuy nhiên, tảng sử dụng định dạng tệp khai báo phân đoạn khác nhau, để nhận video từ máy chủ, thiế t bị cần phải hỗ trợ giao thức độc quyền tương ứng cho máy khách Việc không đồ ng độc quyền công ty gây khó khăn cho nhà cung cấp dịch vụ video phải mã hóa, đóng gói video theo nhiều định dạng khác để có th ể phục vụ cho nhiều thiết bị, nhiều người dùng Điều thúc đẩy Nhóm chun gia hình ảnh động 15 MPEG (Moving Picture Experts Group) Hiệp hội Tiêu chuẩn quốc tế ISO (International Organization of Standardization) đưa tiêu chuẩn Truyền video thích ứng động giao th ức HTTP (Dynamic Adaptive Streaming over HTTP – DASH), hay gọi MPEG-DASH đời vào năm 2012 [6] Phiên thứ hai MPEG-DASH đời năm 2014 [48] Hiện tại, chuyên gia MPEG phát triển phiên thứ ba c chuẩn cho phép streaming đa hướng, triển khai công nghệ thực tế ảo video 360 độ công nghệ HAS MPEG-DASH hay DASH có lợi ích sử dụng sau: - Giảm độ trễ khởi động số lần đóng băng q trình phát video - Thích ứng liên tục với tình trạng băng thơng tạ i máy khách - Nguyên tắc truyền dựa theo tình trạng máy cho phép tối ưu việc mở rộng linh hoạt - Tận dụng mạng truyền tải nội dung CDN, proxy, cache có cách hiệu - Có khả vượt tường lửa, v.v Ngun tắc hoạt độ ng mơ hình truyền video thích ứng động DASH chia video thành phân đoạn nhỏ mã hóa nhiều mức chất lượng khác (khác tốc độ bit, độ phân giải) Các phân đoạn mã hóa lưu trữ máy chủ, máy khách tải theo yêu cầu qua giao thức HTTP Sau tải xong, máy khách lưu phân đoạ n video nhận vào đệm giải mã theo thứ tự phân đoạn hiển thị thiết bị người dùng Như mơ tả Hình 1.4, giả định máy chủ streaming cung cấp ba mức chất lượng khác video Tốt, Trung Bình, Thấp với phân đoạn có độ dài Phía máy khách thực thuật tốn thích ứng với tốc độ bit độ phân giải cho phân đoạn, gửi yêu cầu đến máy chủ Ví dụ, băng thơng mức cao, máy khách yêu cầu mức chất lượng Tốt phân đoạn Thu ật tốn thích ứng tốc độ bit phía máy khách có nhiệm vụ xác định mức chất lượng tốt phân đoạn cho thời gian truyền phân đoạn đến đích khơng q lâu Điều với mục đích tránh tình trạng đệm máy khách bị trống, khơng có liệu phân giải lên trình phát video, gây nên tượng “đóng băng video” Như vậy, tùy thuộc vào tình trạng mạng (băng thơng) mà phía máy khách liên tục tính tốn để u cầu mức chất lượng phù hợp củ a phân đoạn, nhằ m đem đến trải nghiệm t ốt cho người dùng 16 Nội dung video Phân đoạn video Biến động mạnh mạng Hiển thị Thích ứng tốc độ bit Mã hóa Video Bộ đệm Yêu cầu HTTP Chất lượng Giải mã Internet Chất lượng Chất lượng Máy chủ Đáp ứng HTTP Máy khách Hình 1.4 Mơ hình truy ền video DASH Để mô tả mối quan hệ thời gian cấu trúc gi ữa phân đoạn, MPEG-DASH giới thiệu tệp MPD sau 1.2.1.2 Tệp Media Presentation Description (MPD) Như đề cập trên, MPD tệp chứa thông tin mô tả độ phân giải, mức mã hóa chất lượng video, độ dài v ị trí phân đoạn video, đặc điểm khác video Trong MPEG-DASH, MPD lưu định dạng file ngôn ngữ đánh dấu mở rộng XML Hình 1.5 mơ tả cấu trúc tổ chức file MPD Tệp MPD có mơ hình liệu dạng phân cấp, tệp bao gồm nhiều Period Trong đó, Period chứa nội dung đa phương tiện, chẳ ng hạn nội dung video, video với góc nhìn khác cách mã hóa khác nhau; thành phần audio cho ngôn ngữ khác loại thơng tin khác (ví dụ: phụ đề) Các thành phần có đặc điểm định tốc độ bit, tốc độ khung hình, kênh audio, v.v khơng thay đổi Period Thêm vào đó, Period phân tách nội dung, chẳng hạn để chèn quảng cáo hay thay đổi góc camera truyền trận bóng đá trực tiếp Mỗi Period mang thông tin thời điểm bắt đầ u, thời lượng ho ặc số Adaption Set 17 Hình 1.5 Cấu trúc tệp MPD [49] Mỗi Adaptation Set cung cấp thông tin thành phần đa phương tiện mức mã hóa chất lượng video Các thành phần đa phương tiện có codec, ngơn ngữ, độ phân giải, định dạng kênh âm nằm Adaptation Set Cơ chế cho phép khách hàng loại bỏ loạt thành phần đa phương tiện không đáp ứng yêu cầu Mỗi Adaption Set bao gồm nhiều Representation, Representation stream streaming thích ứng Như Hình 1.5, Representation 5MB (5Mbps), Representation 2MB Mỗi Representation phân chia thành Segment Info Các Segment Info xếp theo thứ tự thời gian xuất video Mỗi Segment Info có URL – vị trí đánh địa máy chủ để tải xuống yêu cầu HTTP GET Trong MPEG-DASH, MPD file XML Chính điều cho phép trình phát video DASH dễ dàng xác định bắt đầu phát lại đoạn video, chuyển đổi đoạn video cầ n thiết Có điểm đáng ý việc phân phối file MPD hoạt động máy khách DASH nhằm thích ứng băng thơng khơng nằm phạm vi MPEG-DASH Do đó, nhà phát triển nghiên cứu áp dụng thuật tốn thích ứng băng thơng phía máy khách cho phù h ợp với ứng dụng 1.2.2 Kỹ thuật mã hóa video Hầu hết kỹ thuật nén video ngày kết hợp nén hình ảnh khơng gian bù chuyển động theo thời gian Khái niệm bù chuyển động kỹ thuật sử dụng để dự đốn khung hình đưa trước khung cách tính tốn chuyển động máy ảnh đ ối tượng video Sau mã hóa, video nén bao gồm khung hình I (Intra), khung dự đốn hai chiều B (Bidirectional) khung dự đoán P (Predicted) Khung hình I có dung lượng lớn chúng 18 sử dụng nén hình ảnh khơng gian (hoặc nén khung bên trong) Trong đó, khung B P nhỏ nhiều chúng sử dụng khung I trước khung P khác để dự đốn hình ảnh Một lần nữa, việc giảm kích thước chúng phụ thuộc vào chuyển động máy ảnh vật thể Do đó, chất lượng video khơng thay đổi, kích thước khung hình thay đổi tùy theo nội dung video, làm cho tốc độ bit video đầu (tính theo tốc độ bit giây) thay đổi tự nhiên Phương pháp mã hóa giữ cho chất lượng video ổn định gọi mã hóa có tốc độ bit biến đổi (VBR) Với cách mã hóa tốc độ bit biến đổi, cịn gọi VBR mức chất lượng, tham số lượng tử QP giữ cố định cịn khung hình mã hóa với dung lượng khác tùy thuộc vào nội dung video, làm cho chất lượng video đầu không thay đổi tốc độ bit video thay đổi cách tự nhiên Do đó, việc dự đốn tốc độ bit cho video dạng VBR tương đối phức tạp việc streaming video dạng VBR thách thức cho nhà nghiên cứu giải thuật thích nghi Bởi việc xác định tốc độ bit cho video VBR không dễ dàng, nên kỹ thuật mã hóa video có tốc độ bit không đổi (CBR) sử dụng nhiều nghiên cứu giải thuật thích nghi tốc độ bit MPEG-DASH Kỹ thuật mã hóa để giữ tốc độ bit video đầu gần không thay đổi thay thay đổi chất lượng video tồn phiên streaming video Các video CBR, nguyên mẫu lưu lượng dự đoán chúng làm cho tác vụ truyền phát video phân bổ tài nguyên mạng dễ dàng cho phép chất lượng video biến đổi Việc thích ứng chất lượng cho video CBR đơn giản so với video VBR mã hóa CBR hữu ích streaming nội dung đa phương tiện kênh truyền có dung lượng hạn chế cho biết tốc độ bit xác thay biết tốc độ bit trung bình Chính gần đây, nhiều dịch vụ thương mại Youtube [50], truyền phát trực tuyến Facebook [51] áp dụng chế độ mã hóa CBR cách rộng rãi Tuy nhiên, lo ại mã hóa có nhược điểm phân bổ liệu dư thừa cho cảnh đơn giản video, chẳng hạn cảnh tĩnh, đồng thời không phân đủ liệu cho cảnh có nhiều chuyển động nhanh liên tục, chất lượng video đầu không ổn định (a) (b) Hình 1.6 Tốc độ bit chất lượng tức thời củ a video (a) CBR (b) VBR 19 Hình 1.6 minh họa thay đổi tốc độ bit tức thời chất lượng tức thời video mã hóa hai chế độ Hai video mã hóa có tốc độ bit video trung bình Và dễ dàng thấy với tốc độ bit video trung bình tương đương với video VBR video CBR lại cung cấp mộ t chất lượng video thay đổi với tốc độ bit video không đổi 1.2.3 Các tham số ảnh hưởng đến chất lượng trải nghiệm QoE Trong công nghệ HAS, người dùng video streaming QoE vấn đề ln quan tâm cho nhà nghiên cứu đánh giá dựa vào số lượng hạn chế thơng số khách quan có sẵn Tuy nhiên, để đánh giá cách tiếp cận khác nhau, phải sử dụng thước đo tổng thể chất lượng video trải nghiệm người dùng bị ảnh hưởng mạnh mẽ mức chất lượng nhận Với mức chất lượng cao rõ ràng mang lại trải nghiệm tốt người dùng khơng hài lịng với chất lượng giảm đáng kể Ngồi QoE bị suy giảm đến mức tồi tệ việc ngừng video thường xuyên xảy điều kiện băng thông biến động Theo cơng trình nghiên cứu QoE [43], [52-54], yếu tố quan trọng ảnh hưởng đến QoE bao gồm: trễ khởi động (trễ đầu), chất lượng video, tượng đóng băng video, biến động • Trễ đầu ( - Initial Delay): Là khoảng thời gian từ lúc yêu cầu phân đoạn video phát video Độ trễ ban đầu xuất mộ t dịch vụ streaming đa phương tiện nói chung streaming video nói riêng Đó lượng liệu định phải nạp vào đệm trước trình giải mã bắt đầu streaming Giai đoạn gọi nạp đệm ban đầu Trong độ trễ đầu, máy khách không cần nạp vào đệm lượng lớn liệu, điều gây độ trễ ban đầu dài Các tác giả [55] cho thấy có mối quan hệ logarit thời gian chờ đợi trải nghiệm người dùng đương nhiên với mức nạp đệm ban đầu lớn giúp máy khách tránh tình trạng dừng video Do đó, số lượng li ệu ban đầu nạp vào đệm cần thỏa mãn thỏa hiệp độ trễ gián đoạn video Ảnh hưởng độ trễ ban đầu chất lượng cảm nhận video tương đối nhỏ phụ thuộc vào độ dài củ a khơng phụ thuộc vào thời lượng đoạn video Một hệ thống streaming video có hiệu thời gian chiếm dụng đệm tham số phải nhỏ nhiều so với mức đệm tối đa phía client Theo [46], trễ đầu phải nhỏ 6s video theo u cầu VoD tham số khơng ảnh hưởng nhiều so với yếu tố khác [56] (1.1) 20 • Chất lượng video: Để đánh giá chất lượng video, thông thường người ta dựa vào độ phân giải hay độ nét hình ảnh Đối với video CBR, tham số đặc trưng tốc độ bit cịn video VBR thể qua tham số lượng tử QP Trong công nghệ HAS, video có t ốc độ bit cao, QP thấp cho chất lượng video t ốt Một mục tiêu thuật tốn thích ứng tốc độ bit nhà nghiên cứu giải thuật tối đa hóa tốc độ bit trung bình video streaming Các tác giả [57] QoE có ả nh hưởng lớn đến chất lượng video đoạn streaming sau cùng, nghĩa chất lượng video vào cu ối phiên streaming cao dẫn đến trải nghiệm người dùng tốt Trong [52], [58] mức tăng hay giảm QoE tương ứng v ới việc tăng hay giảm chất lượng cảm nhận video Trong hệ thống DASH, nội dung video chia làm nhiều mức chất lượ ng khác nên tham số định nghĩa tổng chất lượng video trung bình tất phân đoạn video tả i (tức mức chất lượng trung bình video) Để có mơ hình QoE đầy đủ hơn, tham số phải kết hợp với nhiều tham số khác Giả sử luồng video bao gồm K phân đoạn phân đoạn mã hóa với L tốc độ bit tương ứng với L mức chất lượng, với l đại diện cho mức chất lượng cụ thể Khi đó, chất lượng video trung bình (AVQ - Average Video Quality) xác định sau: = ( ,) = , (1.2) với , , giá trị chất lượng phân đoạn thứ i mức chất lượng thứ l, chẳng hạn giá trị chất lượng phân đoạn thứ i với mức chất lượng cao nh ất • Hiện tượng đóng băng video: Là tượ ng video dừng phát video đệm bị cạn kiệt mà chưa tải nội dung yêu cầu Hay nói cách khác, kích thước đệm giảm xuống mức thấp cho phép mà chưa tải phân đoạn video chắc dừng video bị xảy Trong q trình streaming, thơng lượng thấp tốc độ bit video khoảng thởi gian định đệm bị cạn Điều có nghĩa khơng đủ liệu có sẵn b ộ đệm việc phát lại video tiế p tục Thông thường, tượng đóng băng video xảy tiếp sau giai đoạn nạ p đệm tr lại, tức máy khách ph ải nhanh chóng tải số lượng nội dung video định để tiếp tục phát So với trễ đầu tham số có ảnh hưởng xấu đến QoE nhiều trình xem mà video bị dừng gây khó chịu cho người dùng lúc chờ đợi ban đầu Khoả ng thời gian đóng băng video dài tần xuất gián đoạn lớn ảnh hưởng mạnh đến suy giảm QoE [59], [60] Một kiện dừng có khoảng thời gian dài dễ chấp nhận nhiều 21 kiện dừng có khoảng thời gian ngắn Trong [61], tác giả nghiên cứu việc đóng băng video vấn đề giảm tốc độ khung hình Họ việc gián đoạn video tệ việc giảm tốc độ khung hình Hơn nữa, việc đóng băng video khoảng thời gian khơng chất lượng việc gián đoạn có định kỳ vị trí dừng video khơng quan trọng Tổng số lần video bị đóng băng hay dừng ( number of video stalling) tính sau: với (1.3) = mức đệm tại, mức đệm nhỏ • Sự biến động chất lượng video (NVS - Number of Version Switch): Là thay đổi chất lượng video phiên streaming xác định cách đo số l ần thay đổi biên độ tần suất video [43], [62], [63] Tham số sử dụng kết hợp với tham số chất lượng video trung bình AVQ để đưa định lượng chất lượng cảm nhận Nếu luồng streaming video có chất lượng video trung bình AVQ luồng có NVS thấp người dùng cảm nhận tốt Sự thay đổi mức chất lượng video làm tăng giảm chất lượng thông qua hai tham số tốc độ bit QP hai phân đoạn video liên tiếp Các tác giả [52], [58] cho thấy ảnh hưởng QoE theo hướng thay đổi tốc độ bit hay mức chất lượng đánh giá việ c giảm tốc độ bit hay giảm mức QP video cho tác động mạnh so với chiều hướng tăng Nghiên cứu [64] đưa mô hình tương quan tần xuất chuyển mức chất lượng video QoE Mơ hình cho thấy tham số ảnh hưởng đáng kể đến QoE người dùng Trong [65] phân tích thay đổi cách từ từ chất lượng video sang mức trung bình tốt việc video đột ngột giả m xuống mức chất lượng thấp Tuy nhiên, chất lượng video tăng đột ngột lên mức chất lượng cao cải thiện QoE Do cần giảm số lần giảm mức chất lượng tăng QoE [57] Tổng khác biệt trung bình chất lượng phân đoạn video tải xuống liên tiếp định nghĩa sau: = 1 | , ,| (1.4) Để đo lường cách khách quan QoE người dùng, cơng trình [66], [67] đề cập đến yếu tố ảnh hưởng nhiều đến hệ thống DASH, chất lượng video (mức chất lượng video), s ố lần video bị đóng băng tức số lần video bị dừng suốt trình streaming, số lần thay đổi chất lượng video, tốc độ bit video, độ trễ khởi động công nút thắt chia sẻ Tuy nhiên, độ 22 trễ khởi động tính cơng chủ yếu liên quan đến video trực tiếp (Live Streaming) nên chúng coi quan trọng so với tham số khác [68] đề cập Từ phân tích tham số ảnh hưởng đến QoE ta k ết luận rằng, để tối đa hóa QoE cần: tránh kiện đóng băng video đồng nghĩa với việc giữ cho đệm mức ổn định không bị cạn kiệt, tăng tố c độ bit trung bình video, giảm số lần chuyển mức chất lượng xuống với việc giảm biên độ Vì vậy, để đánh giá đề xuất phương pháp cần so sánh luận án này, yếu tố tốc độ bit trung bình hay mức chất lượng trung bình, số lần đóng băng video, mức đệm trung bình, số lần giảm mức chất lượng hay biên độ giảm mức chất lượng xem thông số ảnh hưởng đến QoE Để đánh giá tất phương pháp nghiên cứu, QoE thường thể cách sử dụng mơ hình dự đốn điểm ý kiến trung bình MOS biến động từ “Bad” đế n “Excellent” [69], [70] chuyển đổi điểm số QoE thành mơ hình QoE thơng thường (N-QoE) [46] Bảng 1.2 Bảng 1.2 Chỉ số QoE thông thường QoE N-QoE Quality value > Excellent < value 4 Good < value 3 Average < value 2 Below Average Bad value 1.2.4 Giới thiệu mơ hình QoE Trong phần đưa mơ hình QoE sử dụng để đánh giá giải pháp đề xuất sử dụng mơ hình với phương pháp khác Trong [43] định nghĩa mơ hình QoE video HAS ph ụ thuộc vào chất lượng phân đoạn video trung bình độ lệch chuẩn Các hệ số mơ hình chất lượng trải nghiệm đề xuất điều chỉnh dựa kết thử nghiệm mang tính chất chủ quan Bên cạnh mức chất lượng trung bình hành vi chuyển mức chất lượng trên, đóng băng video xem tham số tác động mạnh đến QoE việc phân phối video Tuy nhiên, tham số không xem xét mơ hình De Vriendt cộng đề xuất [43] Trong [44] có xét đến tham số ảnh hưởng đóng băng video phụ thuộc vào số lần dừng video thời gian dừng Việc tính tốn đề xuất giải pháp sử dụng ba mức để đánh giá (thấp, trung bình cao) tần suất độ 23 dài đóng băng Dựa phép nội suy mức này, hàm liên tục xây dựng để đo lường tác động việc đóng băng video QoE Trên sở đó, Claeys cộng [45] xây dựng mơ hình QoE video HAS phụ thuộc vào ba khía cạnh trình phát video bao gồm ch ất lượng phân đoạn trung bình, số chuyển mức chất lượng đóng băng video Ảnh hưởng việc đóng băng video phụ thuộc vào tần suất đóng băng FF (frequency of freeze) thời gian đóng băng trung bình ATF (average time of freezes) thể Phương trình (1.5) Và tham số chuyển mức chất lượng hiển thị Phương trình (1.6) ln ( ) = × max + 1.0 = + × ×( S số phân đoạn video, ( × 15 , 15) (1.5) (1.6) 1) mức chất lượng cao nhất, số chuyển biên độ chuyển mức chất lượng trung bình mức chất lượng Cuối dựa vào [45] [20], mơ hình QoE cho việc streaming video HAS tính tốn Phương trình (1.7) sau: = 4.85 × 1.57 × 4.95 × + 0.5 (1.7) với AVQ mức chất lượng trung bình yêu cầu Phạm vi lý thuyết số liệu [3.76; 5.35] Tuy nhiên, phạm vi thực tế với mô phương trình [0.0, 5.35] Giới hạn tương ứng với mức MOS Tóm lạo, mơ hình QoE mơ tả Phương trình (1.7) cho thấy rằng, để nâng cao chất lượng trải nghiệm người dùng hay nâng cao QoE, máy khách phải giảm việc chuyển đổi mức chất lượng tần số biên độ tránh tượng đóng băng video 1.3 Mạng điều khiển phần mềm SDN 1.3.1 Khái niệm chung Mạng điều khiển phần mềm SDN [7], [71] kiến trúc mới, có tính linh hoạt, dễ quản lý, hiệu chi phí thích ứng Điều làm cho trở nên lý tưởng băng thông cao biến động ứng dụng SDN tách rời thành phần điều khiển mạng khỏi phần chuyển tiếp liệu cho phép lập trình điều khiển Ngồi ra, SDN cịn cho phép ảo hóa sở hạ tầng bên cho ứng dụng dịch vụ mạng 24 Trong mạng truyền thống, thiết bị mạng (bộ định tuyến, chuyển mạch, v.v.) đóng vai trò logic định tuyến, điều khiển hoạt động mạng lẫn chuyển tiếp gói tin, liệu Mỗi thiết bị có hai chức Với thiết bị từ nhà cung cấp khác nhau, việc cấu hình khác Do đó, cấu hình hệ thống mạng nhiều thành phần , quản trị viên phải cấu hình thủ cơng thiết bị tay Bởi vậy, cần điều chỉnh sở hạ tầng mạng, khối lượng công việc cần tiến hành lớn, gây khó khăn cho việc triển khai thay đổi hệ thố ng lớn Ngược lại, SDN cách tiếp cận theo hướng điện toán đám mây [72], tức tập trung hóa việc quản trị thiết bị mạng, giảm thiểu cơng việc riêng lẻ thiết bị cụ thể, tạo điều kiện thuận lợi cho việc n lý mạng cho phép cấ u hình mạng hiệu chương trình lập trình để cải thiện hiệu suất tăng cường khả giám sát mạng SDN nhằm mục tiêu giải vấn đề kiến trúc tĩnh, phi tập trung, phức tạp mạng truyền thống khơng phù hợp với u cầu tính linh hoạt xử lý cố dễ dàng hệ thống mạng Trong SDN, quản tr ị viên định hình lưu lượng mạng từ bảng điều khiển tập trung mà không cần phải động vào thiết bị chuyển mạch phân phối dịch vụ tới nơi mạng cần, với thiết bị cụ thể kết nối tới 1.3.2 Kiến trúc SDN Các nhà phát triển đưa nhiều mơ hình kiến trúc SDN, để hiểu cách đơn giản, SDN thực hi ện việc điều khiển mạng cách tập trung bằ ng cách tách phần điều khiển logic thiết bị mạ ng khỏi chuyển tiếp liệu đẩy lên mộ t thiết bị máy tính khác gọi Bộ điều khiển Tổ chức chuẩn hóa mạng mở ONF đưa kiến trúc tổng quan SDN Mơ hình gồm lớp riêng biệt như: Lớp ứng dụng, Lớp điều khiển Lớp sở hạ tầng (hay Lớp chuyển tiếp) Hình 1.7 • Lớp ứng dụng: Chứa chương trình ứng dụng, bao gồm qu ản lý mạng ứng dụng kinh doanh, giao tiếp v ới điều khiển thông qua giao diện lập trình ứng dụng API Các ứng dụng thu thập thông tin từ điều khiển để định cấu hình lại mạng • Lớp điều khiể n: Được xem “bộ não” kiến trúc SDN Bộ điều khiển nhận hướng dẫn yêu cầu từ lớp ứng dụng, xử lý đưa thông tin đến thành phần mạng Lớp điều khiển lấy thông tin mạng từ thiết bị mạng gửi lại lớp ứng dụng để có nhìn bao qt mạng Các thơng tin gồm kiện diễn thiết bị mạng, hay thông số chúng Mỗi mạng có nhiều điều khiển hoạt động liên kết với để quản lý Các điều khiển thường phần mềm lập trình được, cho phép quản trị mạng cấu 25 hình lại hoạt động mạng theo ý muốn Lớp điề u khiển dùng giao thức OpenFlow, OVSDB, Netconf, OF- Config để giao tiếp với sở hạ tầng mạng Lớp ứng dụng Ứng dụng điều hành mạng Giao diện Điều khiển - Ứng dụng Lớp điều khiển Phần mềm điều khiển SDN Dịch vụ mạng Giao diện Điều khiển - Dữ liệu (Ví dụ: OpenFlow) Lớp hạ tầng mạng Các thiết bị chuyển mạch Hình 1.7 Kiến trúc l ớp SDN • Lớp sở hạ tầng: Gồm thiết bị mạng thực tế (vật lý ảo hóa) định tuyến hay chuyển mạch nhằm thực việc chuyển tiếp gói tin xử lý liệu cho mạng theo yêu cầu điều khiển Tương ứng với việc lớp điều khiển có nhiều điều khiển, thiết bị mạng hoạt động kiểm soát nhiều điều khiển Ngồi ra, kiến trúc SDN cịn có giao diện lập trình ứng dụng, thường gọi giao diện phía Bắc giao diện phía Nam Giao diện phía Bắc định nghĩa kết nối điều khiển lớp ứng dụng, giao diện phía Nam kết nối điều khiển lớp sở hạ tầng Vì SDN kiến trúc ảo hóa, thành phần khơng thiết ph ải đặt chỗ 1.3.3 Một số ưu điểm SDN Mạng SDN dựa giao thức OpenFlow [8] cho phép giải vấn đề liên quan tới băng thông, thay đổi liên tục ứng dụng, chuyển đổi mạng cho phù hợp với yêu cầu làm việc giảm đáng kể độ phức tạp hoạt động điều hành quản lý mạng Các lợi ích đạt thơng qua kiến trúc mạng SDN dựa OpenFlow bao gồm: 26 Tập trung hóa điều khiển mơi trường mạng nhiều nhà cung cấp Phần mềm điều khiển SDN kiểm sốt thiết bị mạng hỗ tr ợ OpenFlow từ nhà cung cấp nào, bao gồm chuyển mạch, định tuyến chuyển mạch ảo Thay phải quản lý nhóm thiế t bị từ nhà cung cấp riêng lẻ, nhà quản lý sử dụng đồng thiết bị công cụ quản lý dựa SDN để nhanh chóng triển khai, cấu hình cậ p nhật thiết bị tồn mạng Giảm độ phức tạp thơng qua tự động hóa Mạng SDN dựa giao thức OpenFlow cung cấp cơng cụ giúp tự động hóa quản lý mạng cách linh hoạt Điều hỗ tr ợ nhà quản lý phát triển công cụ giúp thực tác vụ quản lý cách tự động hóa Tăng tính linh hoạt phát triển giải pháp điều khiển mạng Sử dụng mạng SDN làm tăng khả cấu hình linh hoạt phát triển giải pháp điều khiển mạng, cho phép nhà vận hành mạ ng thực lập trình theo th ời gian thực để đáp ứng yêu cầu công việc đặc biệt nhu cầu phát sinh người sử dụng, cách ảo hóa trừu tượng hóa sở hạ tầng mạng từ dịch vụ mạ ng Tăng cường độ tin cậy mạng SDN cho phép nhà quản lý tự định nghĩa cấu hình cấp cao sách mạng, điều chuyển xuống sở hạ tầng thông qua OpenFlow Kiến trúc mạng SDN dựa OpenFlow loại bỏ nhu cầu phải cấu hình lại cho thiết bị mạng đơn thiết bị đầu cuối có thay đổi Điều làm giảm thiểu khả phát sinh lỗi mạng xung đột cấu hình hoặ c sách Bộ điều khiển mạng SDN cung cấp khả hiển thị đầy đủ kiểm soát qua mạng Điều đảm bảo việc kiểm soát truy cập, lưu lượng, chất lượng dịch vụ, độ tin cậy sách khác thực thi quán sở hạ tầng mạng tổ chức Bởi vậy, giảm chi phí hoạt động, gặ p lỗi, thực thi sách cấu hình thống nh ất Trải nghiệm người dùng Bằng cách tập trung hóa điều khiển mạng đảm bảo thông tin trạng thái sẵn sàng cho ứng dụ ng cấp cao hơn, sở hạ tầng mạng SDN thích ứng tốt với nhu cầu đa dạng người dùng Với mạng SDN dựa OpenFlow, ứng dụng video tự nhận diện băng thông cho phép mạng theo thời gian thực tự động điều chỉnh độ phân giải video cho phù hợ p 1.3.4 So sánh SDN mạng truyền thống So sánh với mạng truyền thống, mạng điề u khiển phần mềm có số ưu điểm sau: 27 • Lập trình trực tiếp: Các sách mạng SDN lập trình trực tiếp chức điều khiển tách rời kh ỏi chức chuyển tiế p, cho phép mạng lập trình cấu hình theo chương trình cơng cụ mã nguồn mở độc quyền, bao gồm OpenStack, Puppet, Salt, Ansible Chef [71] • Linh hoạt: Tách phần điều khiển khỏi phận chuyển tiếp cho phép người quản trị tự động điều chỉnh lưu lượng băng thông mạng lưới rộng khắp để đáp ứng nhu cầu thay đổi cách nhanh chóng • Quản lý tập trung: “Bộ não” mạng tập trung điều khiển SDN giúp trì nhìn tổng thể v ề mạng, diễn ứng dụng thiết bị mạng • Thúc đẩy sáng tạo: SDN cho phép tổ chức tạo loại ứng dụng, dịch vụ mơ hình kinh doanh cung cấp nhiều giá trị từ mạng Các ý tưởng tiến hành triển khai thành chương trình mà khơng phụ thuộc vào phần mềm độc quyền Trong Bảng 1.3, đưa số tính chất mạng SDN mạng truyền thống Bảng 1.3 Tóm tắt số tính chấ t mạng SDN m ạng truyền thống SDN Đặc điểm Cấu hình Thực Mạng truyền thống Tách mặt phẳng điều khiển từ mặt Giao thức/vấn đề; điều khiển phẳng liệu; khả lập trình phức tạp Cấu hình tự động với xác nhận tập Cấu hình thủ cơng (dễ bị lỗi) trung Kiểm sốt động tổng thể xun qua Thơng tin giới hạn, cấu hình lớp thơng tin tương đối tĩnh Dễ dàng thực phần mềm cho Khó khăn thực phần cứng ý tưởng mới, đầy đủ thử nghiệm với cho ý tưởng mới, giới hạn mơi Tính mơi trường lập nhanh chóng trường thử nghiệm, trình triển khai sử dụng phần mềm nâng chuẩn hóa nhiều thời gian cấp 1.3.5 Giao thức OpenFlow 1.3.5.1 Khái niệm OpenFlow [8] th ực thể kiến trúc SDN, phát triển tổ chức chuẩn hóa mạng mở ONF Để biến khái niệm SND thành triển khai thực tế, hai yêu cầu phải 28 đáp ứng Đầu tiên, phải có kiến trúc logic chung tất b ộ chuyển mạch, định tuyến thiết bị mạng khác quản lý điều khiển SDN Kiến trúc logic triển khai theo cách khác thiết bị nhà cung cấp khác loại thiết bị mạng khác nhau, miễn điều khiển SDN nhận thấy chức chuyển đổi logic thống Thứ hai, giao thức chuẩn, an toàn điều khiển SDN thiết bị mạng Cả hai yêu cầu OpenFlow đáp ứng OpenFlow cho phép truy cập trực tiếp điều khiển mặt phẳng liệu thiết bị mạng định tuyến chuyển mạch, thiết bị v ật lý thiết bị ảo, chức điều khiể n mạng tách rời khỏi thiết bị này, đưa lên điều khiển Mạng có khả lập trình cần có phần tử chuyển mạch OpenFlow (OFS) có khả lập trình để xử lý gói tin cho nhiều thử nghiệm mạng đồng th ời không ảnh hưởng lẫn Openflow cho phép lập trình OFS Cốt lõi OpenFlow chuyển mạch ảo, chuyển mạch xử lý gói tin thơng qua nội dung gói trạng thái cấu hình OFS Giao thức OpenFlow dùng để chuyển kiện từ OFS lên điều khiển gửi thông tin cấu hình OFS từ điều khiển 1.3.5.2 Các thành phần OpenFlow/ SDN Trong giải pháp đề xuất luận án phải dựa vào thành phần OpenFlow để thực sách định tuyến phân bổ băng thơng Hình 1.8 minh họa cấu trúc chung hệ thống OpenFlow/SDN gồm có thành phần quan trọ ng là: Chuyển mạch OpenFlow, Giao thức OpenFlow Bộ điều khiển SDN OpenFlow cung cấp giao thức mở để tính tốn cấu hình lại Flow-table chuyển mạch định tuyến khác Người n trị mạng chia lưu lượng thành luồng cho mạng thông thường luồng cho việc nghiên cứu Bằng cách này, nhà nghiên cứu th giao thức định tuyến, mơ hình bảo mật, cách đánh địa mới, chí thay cho IP Bộ điều khiển OFS giao tiếp với thông qua kênh truyền bảo mật SSL sử dụng giao thức OpenFlow Kênh bảo mật kết nối SSL cho phép lệnh gói tin đượ c truyền qua lại Bộ điều khiển OFS Giao thức Openflow giao thức mở chuẩn hóa cho phép Bộ điều khiển giao tiếp với chuyển mạch Mỗi OFS chứa Flow-table gồm Flowentry, Flow-entry có nhiều action tương ứng, OFS nhận flow có đặc điểm giống mơ tả Flow-entry, OFS xử lý gói tin flow theo action tương ứng 29 Sự khác cấu trúc chuyển mạch truyền thống chuy ển mạch hỗ trợ cơng nghệ Openflow Hình 1.9 Ta dễ dàng thấy cấu trúc truyền thống thành phần điều khiển liệu chung khối (Hình 1.9a), cịn cấu trúc OFS phần điề u khiển tách riêng (Hình 1.9b) Hình 1.8 Cấu trúc môi trường OpenFlow [73] Điều khiển OpenFlow Giao thức OpenFlow (SSL/TCP) Điều khiển (Phần mềm) Dữ liệu (Phần cứng) (a) Điều khiển OpenFlow Dữ liệu (Phần cứng) (b) Hình 1.9 So sánh cấu trúc chuyển mạch truyền thống (a) cấu trúc OFS (b) Hình 1.10 Các thành phần OpenFlow switch [74] 30 a) Chuyển mạch OpenFlow (OFS) Khác với chuyển mạch thông thường hoạt độ ng độc lập với phần lại mạng, OFS hoạt động với tương tác từ Controller qua giao thức OpenFlow Các thành phần OFS minh họa Hình 1.10 Như thấy Hình 1.10, OFS gồm nhiều bảng luồng Flow Table, bảng Group Table thực tra cứu chuyển tiếp gói tin, thành phần OpenFlow Control Channel để giao tiếp với điều khiển Controller Flow Table Thành phần quan trọng OFS Flow-table Các bảng luồng Flowtable khớp gói tin đến với luồng cụ thể định hành động thực gói tin Mỗi OFS có nhiều Flow-table hoạt độ ng theo kiểu đường ống Hình 1.11 Mỗi gói tin vào OFS qua nhiều Flow-table Mỗi Flow-table gồm nhiều Flow-entry [74] Bảng 1.4 Các thành phần Flow entry Match Fields Priority Counters Instructions Timeouts Cookie Flags Mỗi Flow entry có thành phần Bảng 1.4 Trong đó: • Match Field: Chứa thơng tin để khớp gói tin Bao gồm thơng tin cổng vào, header gói tin, địa nguồn, địa đích, … • Priority: Giá trị ưu tiên Flow-entry • Counters: Các đếm, cập nhật gói tin khớp • Instructions: Chỉ dẫn thực gói tin khớp với trường Match Fileds • Cookie: Giá trị tối đa số lần dừng trước gói tin bị hủy • Flags: Cờ thay đổi cách quản lý Flow-entry Ví dụ cờ OFPFF_SEND_FLOW_REM yêu cầu flow loạ i bỏ tin nhắn cho flow entry Một Flow-entry xác định trường Match Fields Priority Mỗi cặp Match Fields Priority xác định Flow-entry Flow-table Flowentry mà có giá trị trường Priority 0, Match Fields ln khớp gọi Table-miss flow-entry Luồng xử lý gói tin chuy ển mạch OpenFlow Mỗi OFS có nhiều Flow Table Mỗi gói tin vào chuyển mạch trải qua trình xử lý tương tự Hình 1.11 Nếu chuyển mạch có Flow Table q trình giản lược nhiều Quá trình xử lý gói tin vào OFS sau: 31 • Xử lý đường ống ln bắt đầu bảng Flow-table (Các Flow-table đánh số theo thứ tự tăng dần) Hình 1.11 Luồng xử lý gói tin OpenFlow Switch [74] • Gói tin bóc tách phần header để lấy thơng tin cần thiết cho việc so sánh với trường Flow-entry Flow-table • Nếu Flow-entry tìm thấy, dẫn trường Instructions bao gồm Flow-entry thực thi Các dẫn định hướng gói tin đến đến bảng lưu lượng khác Tại quy trình tương tự lặp lại lần • Một Flow-entry hướng gói tin đến số Flow-table có thứ tự lớn bảng Flow-table tại, nói cách khác, trình xử lý đường ống tiến lên khơng lùi lại • Nếu Flow-entry tương ứng khơng hướng gói đến luồng khác, xử lý đường ống dừng bảng • Khi q trình xử lý đường ống dừng lại, gói xử lý với Action tương ứng thường chuyển tiếp • Nếu gói khơng khớp với Flow-entry Flow Table, table-miss Một table miss xử lý dựa cấu hình bảng Một Table-mis Flowentry Flow-table định cách xử lý gói khơng khớp Các tùy chọn bao gồm: drop gói tin, chuyển chúng sang bảng khác gửi chúng đến điều khiển qua kênh điều khiển thơng qua gói tin Packet-In Nếu gói tin khỏi b ảng cuối cùng, dẫn tiến hành, gói tin khỏi OFS qua Out Port b) Giao thức OpenFlow Giao thức OpenFlow mô tả thông báo trao đổi diễn điều khiển OFS Thông thường, giao thức triển khai SSL Lớp vận chuyển bảo mật (TLS), cung cấp kênh OpenFlow an toàn Giao thức OpenFlow cho phép điều khiển 32 thực hành động thêm, cập nhật xóa Flow-entry Flow-table chuyển mạch Nó hỗ trợ ba loại tin sau: - Bản tin Asynchronous: Các tin gửi mà khơng có yêu cầu từ điều khiển Bản tin Packet-in trường hợp loại tin này, gửi từ OFS tới điều khiển khơng có Flow-table khớp với gói tin Có bốn loại tin Asynchronous mô tả cụ thể Bả ng 1.5 - Bản tin Controller-to-Switch: Những tin khởi tạo điều khiển, số trường h ợp yêu cầu phản hồi từ chuyển mạch Chúng cho phép điề u khiển quản lý trạng thái logic OFS, bao gồm cấu hình Flow-table Group-table Bản tin Packet-out trường hợp loại tin Bản tin Packet-out sử dụng OFS gửi gói đến điều khiển điều khiển định khơng bỏ gói mà chuyển đến cổng đầu OFS Các tin thuộc loại mô tả chi tiết Bảng 1.6 Bảng 1.5 Các loại tin Asynchronous Bản tin Mô tả Chuyển gói tin đến điều khiển, trường hợp gói tin khơng match với Flow-table Tức trường hợp gói tin đến OpenFlow Packet-In Switch mà khơng khớp với entry phần tồn gói tin đóng gói tin Packet-in gửi lên điều khiển SDN để xử lý Thông báo cho điều khiển việc xóa Flow-entry Flow-Removed Flow-table Việc thường xảy thời gian tồn (Timeout) gói tin kết thúc Port-Status Error Thơng báo cho điều khiển thay đổi cổng OFS Thông báo cho điều khiển lỗi xảy Bảng 1.6 Các tin Controller-to-Switch Bản tin Features Configuration Mô tả Được gửi sau trình bắt tay điều khiển OFS để hỏi chức mà OFS hỗ trợ OFS phản hồi tin FeatureRep Thiết lập truy vấn tham số cấu hình OFS phản hồi với tham số thiết lập 33 Có chức thêm, sửa xóa một nhóm Flow-entry Modify-State thiết lập đặc tính cổng OFS Bao gồm tin FlowMod, GroupMod, PortMod, TableMod Packet-out Chuyển gói tin khỏi OFS cổng cụ thể để chuyển tiếp gói tin mà điều khiển nhận tin Packet-in Các tin nhắn yêu cầu/trả lời sử dụng điều khiển để đảm bảo Barrier ràng buộc tin đáp ứng đ ể nhận thơng báo cho hoạt động hồn thành Role-Request Thiết lập truy vấn vai trò OpenFlow channel Bản tin hữu dụng chuyển mạch kết nối với nhiều điều khiển Asynchronous- Thiết lập lọc cho tin không đồng truy vấn lọc Configuration Hữu dụng OFS kết nối với nhiều điều khiển Read-State Thu thập thông tin từ chuyển mạch, thơng số cấu hình tại, thơng số thống kê, khả OFS - Bản tin Symmetric: Các tin gửi mà khơng có yêu cầu từ điều khiển OFS để đồng kết nối Có tin loại mô tả Bảng 1.7 Bảng 1.7 Các loại tin Symmectric Bản tin Hello Echo Experiment Mô tả Được gửi qua lại điều khiển OFS kết nối thiết lập lần Được gửi từ OFS điều khiển, trả lời tin Echo reply Sử dụng cho chức khác c) Bộ điều khiển SDN (SDN Controller) Bộ điều khiển SDN/OpenFlow điều khiển tập trung, điều khiể n hoạt động mạng với chức định tuyến, phát công, phát tắc nghẽn, v.v Bộ điều khiển SDN xử lý tất giao tiếp lớp ứng dụng lớp thiết bị để quản lý điều chỉnh luồng liệu mạng đáp ứng yêu cầu cần có Bộ điều khiển chuyển tiếp thơng tin đến thiết bị chuyển tiếp qua giao diện lập trình ứng dụng API phía Nam, chuyển thơng tin lên ứng dụng qua API phía Bắc Một Bộ điều khiển OpenFlow loại Bộ điều khiển SDN sử d ụng giao thức OpenFlow để kết nối cấu hình thiết bị mạng Ngồi r a, cịn có số giao thức 34 SDN khác mà điều khiển sử dụng OpFlex, Yang hay NetConf, v.v Một Bộ điều khiể n OpenFlow tạo điểm quản lý tập trung để giám sát thành phần mạng có hỗ trợ giao thức OpenFlow Hiện nay, có nhiều mã nguồn mở cho Bộ điều khiển để ngườ i dùng khai thác phát triển như: • NOX [75]: NOX hệ thống điều khiển mạng cung cấp khả kiểm soát tổng thể cho mạng bao gồm OpenFlow switch NOX hỗ trợ ứng dụng viết ngôn ngữ C++, bao gồ m số ứng dụng Controller mẫu • POX [76] : Dự án POX trì tổ chức với NOX POX viết ngôn ngữ Python, giảm thời gian phát triển triển khai, so sánh với dự án viết C++ NOX POX cung cấp giao diện webbased • Beacon [77]: Beacon mã nguồn mở OpenFlow Controller viết ngơn ngữ Java • OpenDaylight [78]: Dự án OpenDayLight dự án mã nguồn mở quản lý The Linux Foundation Mã nguồn viết ngơn ng ữ Java • Floodlight [79], [80]: Là mã nguồn mở OpenFlow Controller viết ngôn ngữ Java, cấp phép Apache Floodlight hỗ trợ cộng đồng phát triển bao gồm kỹ sư Big Switchs Network Các tài liệu kèm với Floodlight cung cấp cách đầy đủ Big Switchs Network, công ty chủ yếu cung cấp giải pháp cho trung tâm liệu thương mại, cho cộng đồng nguồn mở Trong tất mã nguồn Floodlight ổn định phổ biến nên mã nguồn mở thường sử dụng giảng dạy nghiên cứu Floodlight cung cấp môi trường lập trình chức để dễ dàng thêm mô đun vào định thực thi chúng 1.3.6 Triển khai mạng SDN Trong luận án này, điều khiển SDN sử dụng Floodlight kết hợp với công cụ Mininet [81], [82] để mơ đồ hình mạng cho tất thí nghiệm Floodlight hỗ trợ giao thức OpenFlow cho phép trao đổi thông tin điều khiển thành phần chuyển tiếp gói tin routers hay switches Những thơng tin bao gồm vấn đề tìm hiểu đồ hình mạng, thay đổi Flow-table hay giám sát tài nguyên Về bản, để triển khai phần mạng kết nối máy khách (client) máy chủ (server) thực thao tác sau: 35 • Tạo đồ hình mạng chứa thiết bị chuyển mạch liên kết máy khách máy chủ • Khởi chạy điều khiển, thiết lập thuật toán định tuyến hay phân bổ băng thơng • Giả lập băng thơng cho đường liên kết có mạng 1.3.6.1 Triển khai đồ hình mạng Đồ hình mạng tạo công cụ Mininet Mininet chương trình giả lập mạng để chạy tập hợp host, switch (bộ chuyển mach), router (bộ định tuyến) liên kết kernel Linux Hình 1.12 Nó sử dụ ng ảo hóa để làm cho hệ thống trông giống mạng hoàn chỉnh, chạ y kernel, hệ thống mã người dùng Máy chủ lưu trữ Mininet (Mininet host) hoạt động giống máy thực Các chương trình chạy gửi gói tin (packet) thơng qua môi trường giao diện Ethernet với tốc độ liên kết độ trễ (delay) định Hình 1.12 Cơng cụ tri ển khai đồ hình mạng SDN Mininet tạo mạng ảo cách ảo hóa dựa theo tiến trình (process-based virtualization) khơng gian tên mạng (network namespaces) – tính có kernel Linux Trong Mininet, host giả lập tiến trình bash network namespace, đó, code chạy máy Linux thơng thường (ví dụ web server hay chương trình phía client) chạy host Mininet Các host Mininet có riêng giao diện mạng nhìn thấy tiến trình Các thiết bị chuyển mạch Mininet dựa phần mềm (software-based switch) Open vSwitch hay OpenFlow reference switch Các kết nối (link) ảo, tồn Linux kernel kết nối switch, host giả lập Dưới tính thành phần tổ ch ức mã nguồn Mininet • Một trình khởi chạy dịng lệnh (mn) để khởi tạo mạng • Python API để tạo mạng với kích thước cấu trúc khơng gian (topology) thay đổi • Các ví dụ (trong thư mục examples/) để bắt đầ u • Tài liệu Python API thông qua câu lệnh help(), khả tạo tài liệu PDF/HTML với lệnh make doc 36 • Các Topology cấu trúc hóa (thành subclass Topo) sử dụng đối tượng Mininet M ột Topology xây dựng cách dùng dòng lệnh mininet, sử dụng code python sử d ụng phần mềm MiniEdit • Một giao diện dòng lệnh cung cấp dòng lệnh chẩn đoán (như iperf ping), khả chạ y command node • Dịng lệnh “dọn dẹp” để dọn rác (giao diện, tiến trình, files tạm thời) cịn bị bỏ lại Mininet hay Linux: mn –c 1.3.6.1 Triển khai điều khiển - Controller Kiến trúc điều khiển Floodlight thể Hình 1.13 Cũng giống nhiều điề u khiển khác, Floodlight khởi động API phía bắc (Northbound) phía nam (Southbound) khởi động, tức điều khiển ứng dụng mô đun cấu hình chạy Các API REST phía bắc hiển thị tất mô đun chạy khả dụng thông qua cổng REST định Bất kỳ ứng dụng tương tác với điều khiển cách gửi yêu cầu HTTP Mặt khác, phía nam, mơ đun Provider Floodlight bắt đầu lắng nghe cổng TCP OpenFlow định cho kết nối từ chuyển mạch OpenFlow Phiên Floodlight v1.2, có hỗ trợ đầy đủ cho OpenFlow 1.0 1.3 với hỗ trợ thử nghiệm cho OpenFlow 1.1, 1.2 1.4 Với môi trường phát triển Java mở rộng công cụ lõi cấp doanh nghiệp, Floodlight vừa điều khiển SDN dễ sử dụng vừa mạnh mẽ Kiến trúc cốt lõi Floodlifht bao gồm mô đun khác Topology Manager, Device Manager, mô đun tính tốn đường dẫn, mơ đun cung cấp sở hạ tầng để truy cập web hệ thống lưu trữ trạng thái quản lý hệ thống quản lý mô đun Rest-API Based Applications: Floodlight kèm với số ứng d ụng sử dụng REST API sẵn có Một số ứng dụ ng tiêu chuẩn dựa REST API giao diện web Floodlight Thêm vào đó, ứng dụng tảng Python Circuit Pusher tận dụng REST API Floodlight để thiết lập đường dẫn hai thiết bị có địa IP cách thêm Flow-entry vào tất chuyển mạch có đường dẫn 37 Hình 1.13 Kiến trúc c Floodlight Controller [83] Module Applications: Khối chứa ứng dụng có tỷ lệ tương tác cao với điều khiển, ví dụ xử lý gói tin Packet-in: - Ứng dụng Forwarding, với tên gọi, chuyển tiếp gói tin hai thiết bị k ết nối với qua OpenFlow switch - Mô đun Learning Switch, xuất SDN Controller khác NOX, POX, hay Beacon - Ứng dụng Hub lưu trữ thông tin cặp c MAC gói tin trường hợp biết đích, trường hợp ngược lại, gói tin gửi đến tất cổng hoạt động khác - Ứng dụng Static-flow entry pusher thêm OpenFlow Flow-entry vào switch cụ thể, sử dụng tin Flow-mod - Ứng dụng Virtual Network Filter có chức phân lớp mạng dựa địa MAC 38 - Ứng dụng Firewall – tường lửa có chức áp dụng danh sách quy tắc kiểm soát truy cập – loạt điều kiên, để kiểm soát luồng lưu lượng dựa sách định Khối dịch vụ cốt lõi Floodlight Controller: Trong Hình 1.13, thành phần quan trọng nhấ t Floodlight Controller khối điều khiển Các mơ đun nhỏ khối thực nhiệm vụ cố t lõi dịch vụ mạng Các nhà phát tri ển dựa vào mô đun để thêm vào mô đun để thực nhiệm vụ theo ý muốn Để làm điều này, ta cần ý đến mô đun quan trọng miêu tả Bảng 1.8 Bảng 1.8 Các mô đun Floodlight Controller Mô đun Floodlight Provider Chức Cung cấp cách thức để module giám sát/điều chỉnh tin OpenFlow nhận gửi từ điều khiển Device Manager Quản lý host/thiết bị vị trí chúng kết nối vào mạng (gắn với chuyển mạch ảo nào) Link Discovery Tìm kiếm quản lý kết nối switch dùng Manager Topology Manager Thread Pool gói tin LLDP Quản lý topology dựa vào việc khám phá đồ hình kết nối switch Dùng để tạo thread chạy thời điểm định có chu kỳ Module Loading System: Floodlight sử dụng hệ thống mô đun để định xem mô đun chạy Hệ thống bao gồm: mô đun Loader, services, tệp cấu hình tệp chứa thơng tin mơ đun sử dụng Mục đích hệ thống định xem mô đun chạy cách sửa đổi tệp cấu hình, thay đổi việc triển khai mơ đun mà không làm ảnh hưởng đến mô đun khác tạo tả ng tốt với API để mở rộng Floodlight Khi triển khai điều khiển SDN/OpenFlow, giải pháp đề xuất chương tính tốn cấu hình lại mô đun chức cấu trúc Floodlight để tiến hành thí nghiệm việc tính tốn đường d ẫn tối ưu phân bổ băng thông 39 1.4 Kết luận chương Phần đặt vấn đề Chương đưa trạng HTTP streaming hướng đề xuất giải luận án Tiếp đế n giới thiệu kỹ thuật streaming video giao thức truyền video thường sử dụ ng Trong tất giao thức, luận án tậ p trung vào phương pháp truyền video thích ứng động tảng HTTP (DASH) số ưu điểm Phân tích tham số ảnh hưởng đến QoE lĩnh vực streaming video để làm sở đánh giá giải pháp đề xuất với phương pháp đối sánh khác Ngoài ra, nghiên cứu liên quan khảo sát phân tích phần vấn đề cịn tồn Trên sở đó, luận án kế thừa ưu điểm hạn chế nhược điểm để nghiên cứu đề xuấ t mơ hình giải thuậ t nhằm nâng cao chất lượng truyền video, cải thiện QoE người dùng thể chương Trong chương cung cấp khái niệm kiến trúc mạng điều khiển phần mềm SDN, ưu điểm mạng SDN so với mạng truyền thống Giao thức OpenFlow yếu tố tảng cho việc xây dựng giải pháp SDN Với lợi ích SDN/OpenFlow cho thấy kiến trúc mang tính cách mạng tương lai công nghệ mạng thời gian tới Cuối công cụ mô Mininet Floodlight giới thiệu để triển khai mạng SDN cho việc thí nghiệm tất đề xuất luận án 40 CHƯƠNG TRUYỀN VIDEO CBR THÍCH NGHI GIAO THỨC HTTP DỰA TRÊN KỸ THUẬT ĐỊNH TUYẾN CỦA SDN 2.1 Giới thiệu chương Như trình bày Chương 1, OpenFlow/SDN mơ hình mạng làm ảo hóa sở hạ tầng mạng việc tách bạch có logic mặt phẳng điều khiển khỏi mặt phẳng liệu thiết bị mạng truyền thống Bộ điều khiển SDN có nhìn tổng thể sơ đồ mạng so với mạng truyền thống cung cấp linh hoạt đến hoạt động mạng nhằm thực phương pháp định tuyến tối ưu đường dẫn cho dịch vụ truyền thông Tuy nhiên, điều khiển SDN bi ết trình hoạt động thông tin trạng thái máy khách Mặt khác, v ới xu hướng phát triển công nghệ video streaming qua HTTP dựa vào chuẩn MPEG-DASH Công nghệ cho phép máy khách thay máy chủ đưa định mức chất lượng nên lựa chọn cho phân đoạn video Trong phiên streaming, phía máy khách thuật tốn thiết lập có nhiệm vụ thích ứng chất lượng video tùy thuộc vào điều kiện mạng sẵn có Chính việc truyền video streaming qua HTTP giảm gián đoạn làm tăng chất lượng trải nghiệm so với phương pháp streaming tải lũy tiến trước Bên cạnh máy khách khơng thể nh ận biết tình trạng mạng sử dụng tài nguyên cho tối ưu Trong chương này, luận án đề xuất thuật toán thích ứng tốc độ bit tạ i phía máy khách thời gian thực kết hợp với lựa chọn đường dẫ n tối ưu sở SDN cho việc truyền t ải video CBR qua giao thức HTTP Các kết thí nghiệm cho thấy phương pháp đề xuất cung cấp cho người dùng chất lượng trải nghiệm (QoE) với số lần định tuyến lại thấp hơn, chất lượng video trung bình cao mượt mà so với phương pháp không dựa vào SDN tồn kịch khác biến động băng thơng 2.2 Các cơng trình nghiên cứu liên quan Truyền phát thích ứng HTTP (HAS) trở thành giải pháp cho truyền phát video Các nghiên cứu gần vấn đề cải thiện QoE ngườ i dùng, bao gồ m nhiều máy khách yêu cầu dịch vụ DASH tiến hành Như thảo luận [9] [12], tác giả đề xuất thuật tốn thích ứng tốc độ dựa thơng lượng ước tính, thơng lượng phân đoạn tải sau sử dụng làm thơng lượng ước tính Mức chất lượng tăng giả m tùy thuộc hồn tồn vào băng thơng ước 41 lượng Phương pháp định tốc độ bit dựa thơng lượng có ưu điểm thích ứng nhanh với điều kiện mạng dao động mạnh Các tác giả [5], [84] sử dụng thông lượng ước tính để định cho mức chất lượng video thơng lượng ước tính thơng lượng trung bình mộ t số phân đoạn video tải trước Phương pháp không phản ứng nhanh phương pháp trước ưu điểm phương pháp sử dụng thơng lượng trung bình giúp cho máy khách tránh việc ứng xử mộ t cách vội vàng có s ự thay đổi đột ngột thơng lượng Tại phía máy khách, bên cạnh phương pháp thích ứng tốc độ dựa vào thơng lượng, phương pháp thích ứng tốc độ dựa vào đệm máy khách nghiên cứu nhiều [13], [85-87] Các chế dựa đệm sử dụng ngưỡng đệm để định thay đổi tốc độ bit video So với phương pháp dựa thông lượng, phương pháp dựa đệm mang lại chất lượng video mượt mà streaming video theo yêu cầu Thông thường, phạ m vi mức đệm định, máy khách cố gắng trì tốc độ bit tại, dẫn đến tốc độ bit video ổn định Tuy nhiên, băng thông bị giảm mạnh, phương thức dựa đệm gây thay đổi đột ngột tốc độ bit Điều đương nhiên ln có đánh đổi tính ổn định chiếm dụng đệm độ mượt tốc độ bit video băng thông thay đổ i theo thời gian Về phía mạng, tác giả nghiên cứu [24] đưa định tuyến lại luồng video dựa SDN theo phân phân đoạn Khi máy khách yêu cầu phân đoạn video giải pháp tìm đường cho yêu cầu dựa vào nguồn tài nguyên mạng có Phương pháp cải thiện phần chất lượng video cho người dùng so với việc streaming video mạng truyền thống Tuy nhiên giải pháp không đề cập đến thuậ t tốn thích nghi tốc độ bit phía máy khách cách cụ thể mà dựa thích ứng tốc đ ộ cơng nghệ DASH có Mặt khác việc định tuyến cho phân đoạn làm tăng thời gian xử lý nhiều xảy tượng tải cho điều khiển SDN Dutra cộng [88] đề xuất giải pháp chất lượng dịch vụ đầu cuối (QoS) theo nguyên lý hàng đợi OpenFlow, cho phép nhà điều hành mạng với hỗ trợ SDN phân bổ hiệu tài nguyên mạng theo nhu cầu người dùng Tuy nhiên, tác giả đề cập đến vấn đề định tuyến đường dẫn dựa SDN mà khơng có chế thích nghi bitrate phía client Trong [89], tác giả trình bày phương pháp định tuyến đường dẫ n với thuật toán genetic nhằm nâng cao việc streaming video dựa SDN công việc cố gắng cải thiện việc phân phối video t khía cạnh định tuyến Từ mơi trường nghiên cứu tồn tại, nhìn chung phương pháp mà luận án khảo sát dựa công nghệ HAS tập trung thuật tốn thích ứng tốc độ để lựa chọn mức chất lượng video tốt mà khơng có nhìn tổng thể phía mạng Hoặc phương pháp tập trung tạ i phía mạng để lựa chọn đường dẫn tối ưu mà không 42 biết tình trạng phía máy khách Chính vậy, để có chất lượng video phù hợp đồng thời sử dụng tối ưu tài nguyên mạng có, đề xuấ t này, luận án xây dựng kiến trúc thực hiệ n kỹ thuật định tuyến động dựa điều khiển mạng SDN kết hợp với thích ứng tốc độ bit phía máy khách streaming video qua HTTP Mục đích giải pháp để cải thiện chất lượng streaming video CBR nhằm nâng cao chất lượng trải nghi ệm QoE người dùng Trong kiến trúc đề xuất, băng thơng thích ứng u cầu máy khách lớp ứng dụng đầu vào cho định định tuyến lớp mạng Do đó, kiến trúc đề xuất coi mơ hình tương tác lớp để streaming video thích ứng qua giao thức HTTP, nhằm đồng hóa yêu cầu thích ứng t ốc độ bit phía máy khách với đị nh định tuyến mạng truyền tải Kiến trúc giải pháp đề xuất xem xét tiêu chí chất lượng video ảnh hưởng đế n hài lòng người dùng với dịch vụ streaming video cung cấp 2.3 Vấn đề thích nghi tốc độ bit 2.3.1 Lựa chọn thời khoảng cho phân đoạn video Truyền phát thích ứng HTTP dựa chế yêu cầu – đáp ứng máy khách máy chủ Ở phía máy chủ, nội dung đa phương tiện lưu trữ dạng tập thích ứng khác chứa nội dung video, âm văn tập thích ứng bao gồm gói n ội dung đa phương tiện (đại diện) loại hình dịch vụ khác Một đại diện bao gồm nhiều phân đoạn có chứa nội dung đa phương tiện và/hoặ c metadata để giải mã trình bày nội dung streaming Các lựa chọn thời lượng phân đoạn thay đổi từ vài giây đến vài phút theo tiêu chí khác Thời lượng phân đoạn video thường thiết lập cố định từ đến 10 giây [5], [90] Sau phân đoạn tả i xuống, máy khách chọn mức chất lượng nội dung phù hợp cho phân đoạn sau đưa yêu cầu đến máy chủ [12] Ưu điểm thời lượng phân đoạn dài số lượng truy vấn giảm overhead, dẫn đến thông lượng tổng thể cao Tuy nhiên, máy khách thích ứng với thay đổi mạng nhận phân đoạn video đầy đủ, điều gây thời gian phản hồi chậm ổn định đệm Thời lượng phân đoạn dài dẫn đến độ trễ dài [91] Nếu sử dụng thời lượng phân đoạn ngắn lựa chọn đơn giản phải đánh đổi gia tăng đáng kể số lượng truy vấn gây gia tăng overhead Thêm vào thời khoảng phân đoạn ngắn gây phức tạp xử lý nút mạng giảm thông lượng tổng thể Do đó, tùy theo mục tiêu thuật tốn thích ứng tốc độ bit mà nhà khoa học nên lựa chọn thời khoảng phân đoạn video cho phù hợp Trong giải pháp đề xuất luận án không quan tâm đến số lượng truy vấn 43 máy khách máy chủ nên chọn thời gian streaming ngắn cho phân đoạ n video từ 1s đến 2s 2.3.2 Các phương pháp thích ứng tốc độ bit Bảng 2.1 Các ký hiệu sử dụng giải pháp ý nghĩa Ký hiệu Định nghĩa Ngưỡng đệm mức cao Băng thông khả dụng liên kết Băng thông khả dụng đường Băng thông khả dụng t ức thời đường dẫn p Băng thông lớn liên kết Băng thông thống kê phía máy khách Băng thơng tải liên kết Mức đệm Mức đệm ước lượng cho phân đoạn thứ i+1 Ngưỡng đệm mức thấp Kích thước đệm Ngưỡng đệm tốt Ngưỡng đệm động Chỉ số mức chất lượng phân đoạn thứ i Tốc độ bit mức chất lượng Tốc độ bit phân đoạn thứ i Tốc độ bit trung bình phân đoạn thứ i Tốc độ bit tối ưu cho phân đoạn thứ i+1 Thông lượng đo tải phân đoạn thứ i Thông lượng ước tính cho phân đoạn Thơng lượng trung bình phân đoạn khứ Liên kết thứ i đường dẫn C N P i+1 SD Dung lượng băng thông nút thắt cổ chai Số máy khách truy c ập Đường dẫn tối ưu định tuyến lại Độ dài (tính theo giây) phân đoạn video Tham số độ lệch thông lượng tốc độ bit Hiện có nhiều thuật tốn thích ứng tốc độ bit áp dụng cho máy khách cơng nghệ DASH Các thuật tốn thường xây dựng dựa vào tình trạng 44 phía máy khách, tình trạng băng thơng đo tình trạng đệm video phía người dùng 2.3.2.1 Phương pháp dựa vào thơng lượng Để thuận tiện cho việc trình bày theo dõi, Bảng 2.1 liệt kê ký hiệu ý nghĩa sử dụng tất giải pháp đề xuất lu ận án Thông lượng xác định tỉ số kích thước liệu phân đoạn khoảng thời gian tải phân đoạn [5] Và thời lượng truyền tải phân đoạn xác định từ lúc máy khách gửi yêu cầu HTTP đến lúc nhận byte cuối c phản hồi HTTP có chứa phân đoạn Như nói thuật tốn theo phương pháp dựa thông lượng ước tính để định tốc độ bit cho phân đoạn Sự khác biệt loại thuật tốn cách để ước tính thơng lượng sử dụng thông lượng Trong giải pháp đề xuất này, để ước tính thơng lượng cho phân đoạn tiếp theo, cách thức đơn giản ta lấy giá trị thông lượng phân đoạn trước cho phân đoạn sau: sử dụng thơng lượng ước tính (2.1) = Đã có số nghiên c ứu [9], [12] áp dụng phương pháp làm thuật tốn thích ứng tốc độ bit phía máy khách có tên gọi phương pháp Aggressive, mơ tả Thuật tốn 2.1 Thuật toán 2.1 Thuật toán Aggressive Input: , Output: For j downto then If (1 )× End if Thuật tốn Aggressive với đầu vào giá trị thông lượng phân đoạn thứ i Ti tập giá trị tốc độ bit sau mã hóa video mức chất lượng video Đầu ={ , ,…, } với n số giá trị mức chất lượng phân đoạn Thuật tốn Aggressive có đặc điểm sau: 45 • Chọn mức chất lượng cho phân đoạn dựa vào thông lượng quan sát tải xuống phân đoạn trước Thơng lượng ước tính có giá trị thơng lượng phân đoạn trước Bởi phương pháp nhạy cảm với băng thông biến động Khi băng thơng có giá trị thay đổi liên tục mức chất lượng phân đoạn tải xuống biến đổi liên tục • Giá trị cao nh ất tốc độ bit Rj tính dựa vào thơng lượng ước tính tham số an toàn μ Với μ thường chọn nằm khoảng [0; 0.5] Tham số nhằm đảm bảo tốc độ bit yêu cầu không vượt khả thực tế c mạng (1 )× (2.2) Lý để giải pháp lựa chọn phương pháp ước lượng thông lượng Aggressive cho thuật tốn thích ứng đề xuất phương pháp đơn giản có ưu điể m sử dụng hầu hết băng thơng có sẵn cung cấp cho máy khách Q trình streaming cách thích ứng với mức chất lượng phân đoạn video chất lượng cao để khơng vượt q băng thơng có sẵn 2.3.2.2 Phương pháp dựa vào đệm Các phương pháp thích ứng tốc độ bit dựa đệm xuất nhiều năm gần đây, chẳng hạn nghiên cứu [13], [85], [86] Các phương pháp có tính đến thơng lượng, đặc tính đệm yếu tố ưu tiên định tốc độ bit chủ yếu dựa đặc tính đệm Thông thường đệm chia thành nhiều phạm vi, ứng với phạm vi hành động khác áp dụng để đị nh tốc độ bit Nếu đệm có giá trị cao, phân đoạn chọn v ới giá trị tốc độ bit cao so với phân đoạn Nếu đệm mức trung bình giá trị tốc độ bit chọn không chênh lệch so với giá trị đệm mức thấp phân đoạn lựa chọn mức tốc độ bit thấp nhằm tránh tình trạng trống đệm, gây đóng băng video Vậy dựa vào cơng trình nghiên cứu trên, giải pháp chia đệm thành ) gọi ngưỡng nhiều giới hạn , , , (0 < < < < đệm Lưu ý giá trị cụ thể ngưỡng đệ m tùy thuộc vào phương pháp thích ứng khác Chẳng hạn nghiên cứu [87], hoạt động thích ứng tốc độ bit khác áp dụng mức đệm phạm vi khác khác tóm tắt Bả ng 2.2 Đánh giá cách sơ bộ, phương pháp tương tự trì tốc độ bit mượt Phương pháp dường ổn định tiêu chí để trì tốc độ 46 bit phụ thuộc vào phạ m vi mức đệm (được định nghĩa ngưỡng đo lường thông lượng phương pháp ) Với phương pháp 3, mức đệm khoảng 35% ~ 50% so mức tối đa, ước tính thơng lượng giống thơng lượng trước Còn mức đệ m giảm xuống dải thấp ước lượng thơng lượng với thơng lượng trước nhân với với hệ số tỷ lệ giảm Vì vậy, phương pháp thực mượt mà so với phương pháp dựa thông lượng tức thời Aggressive, ước lượng thơng lượng đơn giản với thông lượng phân đoạn trước Bảng 2.2 So sánh phương pháp thích ứng khác dựa sở đệm Mức đệm Phương pháp [13] Phương pháp [85] Phương pháp [86] Chuyển sang tốc độ bit Chuyển sang tốc độ bit Tốc độ bit ≤ thông ~ cao cao tố c lượng tức thời trước tốc độ bit thấp độ bit thấp thơng nhân với hệ số thông lượng tức thời lượng làm mượt trước ~ trước Duy trì tốc độ bit Giữ nguyên tốc độ bit thông lượng giảm tỷ lệ Tốc độ bit ≤ thơng lượng tức thời trước Chuyển sang tốc độ bit Chuyển sang tốc độ bit Tốc độ bit ≤ thông thấp thấp (cao hơn) lượng tức thời trước ~ tốc độ bit cao tốc đ ộ bit cao 0.5 lần thơng lượng tức (thấp hơn) so với thời trước thơng lượng tức thời trước 0~ Chuyển thấp đến bitrate Chuyển đến tốc độ bit Tốc độ bit ≤ thơng thấp lượng tức thời trước 0.3 lần 2.4 Kỹ thuật định tuyến cho luồng video mạng SDN Không giống mạng truyền th ống muốn thay đổi tuyến từ nguồn đến đích cần phải cấu hình thủ cơng, mạng SDN việc định tuyến thực dễ dàng đáp ứng theo yêu cầu dịch vụ lớp ứng dụng Chẳng hạn dịch vụ định tuyến theo số bước nhảy, theo băng thông tuyến hay tuyến có 47 trễ nhỏ v.v Trong phần này, giải pháp đề xuất chế định tuyến dựa vào băng thông khả dụng lớn nh ất tuyến mạng SDN Việc cung cấp chất lượng dịch vụ QoS từ đầu cuối đến đầu cuối cho ứng dụng video đòi hỏi mạng chọn đường tối ưu số nhiều đường để cải thiện hiệu suất ứng dụng Các giao thức điều khiển mạng không cài đặt đường QoS tối ưu cho ứng dụng video khơng có khả tìm đường dẫn thay dựa vào giao thức định tuyến lựa chọn đường dẫn cố định OpenFlow đưa mơ hình chủ yếu để giải nhược điểm cho phép xác định quy tắc định tuyến khác liên quan đến luồng liệu cho phân vùng bố trí mạng luồng lưu lượng điều chỉnh Thành phần điều khiển OpenFlow coi não mạng SDN, nơi mà thay đổi sách định tuyến xác định Do đó, thuật tốn khác điều khiển kết hợp với luồng liệu khác mang lại lựa chọn định tuyến khác Bộ điều khiển cung cấp truy cập vào bảng luồng quy tắc cho chuyển tiếp mạng làm để định hướng luồng lưu lượng video 2.4.1 Xây dựng kiến trúc điều khiển đề xuất Kiến trúc điều khiển đề xuất miêu tả Hình 2.1, cung cấp giao diện chức khác cho việc đị nh tuyến luồng video Một số thành phần kiến trúc đề xuất phần định tuyến mơ hình Internet truyền th ống Các giao diện điều khiển là: Ứng dụng c Dịch vụ video Giao diện Điều khiển - Ứng dụng Điều khiển Topology Manager Devices Manager Traffic Manager Route Manager Messages Observer Giao thức OpenFlow Giao diện Điều khiển - Chuyển tiếp Chuyển tiếp (Các liên kết, chuyển mạch) Hình 2.1 Kiến trúc điều khiển đề xuất 48 + Giao diện Điều khiển – Chuyển tiếp: Giao di ện hỗ trợ giao thức OpenFlow, giao thức cung cấp phương thức trao đổi thông tin cách an toàn điều khiển chuyển tiếp để gửi bảng luồng liên quan đến luồng liệu để phát đồ hình mạng, nhận thơng tin trạng thái tình trạng lưu lượng + Giao diện Điều khiển - Ứng dụ ng: Đây mộ t giao diện mở, giúp cho nhà cung cấp dịch vụ ứng dụng để đặt trước cách an toàn phân vùng liệu (riêng lẻ nhóm luồng liệu) xác định quy tắc đ ịnh tuyến liên quan đến việc phân vùng đặt trước Dựa kiến trúc tổng thể SDN, chức điều khiển đề xuất xây dựng số mơ đun sau: • Topology Manager: Kiểm sốt thơng tin v ề đồ hình mạng cho điều khiển tìm kiế m tuyến mạng Mơ đun thực tính tốn đồ hình dựa thơng tin nhận từ khối dịch vụ khám phá liên kết, khối có nhiệm vụ khám phá trì trạng thái đườ ng liên kết mạng thông qua giao thức khám phá lớp liên kết (LLDP) Tất thơng tin đồ hình lưu cấu trúc liệu Nếu đồ hình mạng có thay đổi liệu cập nhật lại • Devices Manager: Mơ đun giám sát tất host có mạng Mỗi host coi phối hợp v ới chuyển tiếp mà có kết nối trực tiếp Đây mơ đun mặc định kích hoạt khởi chạy điều khiển • Traffic Manager: Mơ đun thu thập liệu thống kê từ chuyển tiếp để xác định hiệu suất chuyển gói tin, thông tin sử dụng để định tính tốn tuyến • Route Manager: Mơ đun kết hợp với mô đun Topology Manager Traffic Manager để thực thuật toán định tuyến host tuyến thỏa mãn điều kiện ràng buộc Nó chịu trách nhiệm cài đặt quy tắc luồng vào định tuyến chuyển mạch • Messages Observer: Mơ-đun xử lý tin từ dịch vụ ứng dụng Khi điều khiển khởi động, mô đun Topology Manager mô đun Devices Manager bắt đầu lắng nghe kết nối từ chuyển tiếp OpenFlow Sau trao đổi thơng tin, đồ hình mạng OFS trạng thái liên kế t thu thập từ điều khiển Khi stream thiết lập, dịch vụ video thông báo cho điều khiển cách gửi tin khởi tạo xử lý mô đun Messages Observer Tại thời 49 điểm đó, mơ đun Route Manager xác định đường dẫn tốt để truyền gói tin máy chủ máy khách, sau cập nhật quy tắc bảng luồng Flow-Table cho chuyển tiếp OFS Bộ quản lý lưu lượng Traffic Manager kích hoạt để giám sát luồng liệu mạng Dựa vào chế định tuyến mà mơ đun Route Manager gọi để thực nhiệm vụ định tuyến trình truyền liệu video Nguyên lý hoạt động quy trình lựa chọn đường dẫn thể Hình 2.2 Khi máy khách yêu cầ u dịch vụ cho việc streaming video, gửi kết nối đến chuyển mạch Openflow gần Chuyển mạch này kiểm tra bảng định tuyến phát yêu cầu dịch vụ khơng có bảng chuyển tiếp cấu hình cho Sau đó, chuyển mạch Openflow mã hóa thơng tin yêu cầu tin Packet-in (được định nghĩa giao thức OpenFlow) gửi đến điều khiển SDN Dựa mô đun chức trên, điều khiể n SDN phân tích bả n tin này, kiể m tra trạng thái mạng tính tốn chế truyền phát video, bao gồm máy chủ video đường dẫn truyền phát cho máy khách Sau đó, điều khiển SDN mã hóa thông tin đường streaming thông điệp FlowMod (được định nghĩa giao thức OpenFlow), phân phối chúng cho chuyển mạch OFS liên quan để cài đặt đường dẫn tốt thông báo đến máy chủ đường dẫn từ máy khách đến máy chủ Khi đường dẫn thiết lập, nội dung video máy khách DASH máy chủ DASH đượ c phân phối chuỗi giao dịch yêu cầu - phản hồi HTTP Máy khách HTTP OFS Yêu cầu HTTP Bộ điều khiển SDN OFS Máy chủ HTTP Luồng tồn Đáp ứng HTTP Yêu cầu Bản tin PacketIn Cài đặt đường dẫn (Bản tin FlowMod) Cài đặt đường dẫn Thông báo dịch vụ (Bản tin FlowMod) Thiết lập đường dẫn Đáp ứng HTTP Hình 2.2 Quá trình thi ết lập đường dẫn 50 2.4.2 Tính tốn băng thơng mạng SDN Trong mơ hình mạng triển khai, điều khiển SDN sử dụng Floodlight Controller trình bày Chương Trước tiên, điều khiể n sử dụng mơ đun Topology Manager để xây dựng đồ hình có hướng = ( , ) mạng, với tập hợp node – tương ứng với OFS node chuyển tiếp khác Và kết thứ đường dẫ n đa liên kết , để lưu quy tắc tập liên kết node, liên kết đồ hình mạng là liên tập đường dẫn để luồng video qua, bao gồ m chuỗi node băng thông tối Gọi băng thông tải vào thời điểm băng thông khả dụng liên kết Giả sử giá trị băng thông tối đa c a m i liên k t điều khiển biết đến Bộ điều khiển tính tốn băng thơng sử dụng liên kết cách thống kê số lượng byte liệu đến cổng OFS Để làm việc này, điều khiể n định kỳ gửi xuống OFS tin StatsRequest sau giây để truy vấn thông số OFS Tiếp đến OFS phản hồi bả n tin StatsResponse, thơng tin cổng bao gồm số trường Bảng 2.3 Sau nhận tin phản hồi, điều khiển tính tốn lượng băng thơng sử dụng liên kết công thức (2.3) Bảng 2.3 Bảng tin StatsResponse port_no số hiệu cổng rx_packets số gói tin nhận tx_packet số gói tin gửi rx_bytes số byte nhận tx_bytes số byte gửi rx_dropped số gói tin nhận bị drop tx_dropped số gói tin gửi bị drop rx_error số gói tin nhận bị lỗi tx_error số gói tin gửi bị lỗ i ( )= ( ) ( ) (2.3) 51 với số byte liệu mà OFS gửi cổng tương ứng với liên kế t Vậy băng thông khả dụ ng liên kết tính bở i công thức (2.4): (2.4) = Dựa vào giá trị băng thông khả dụng liên kết thông khả dụng đường dẫn thắt cổ chai đường đó: ta xác định băng với băng thông khả dụ ng điểm (2.5) | = 2.4.3 Lưu đồ thuật toán điều khiển SDN Để thực sách định tuyến theo yêu c ầu, tức có u cầu từ phía máy khách cho việc định tuyến lại đường dẫn, giải pháp phải thiết lập trước thuật toán điều khiển SDN Lưu đồ thuật toán điều khiể n SDN xây dựng Hình 2.3 Bắt đầu Kết nối đường lên Cập nhật đồ hình mạng Cập nhật băng thông liên kết T Thông tin phản hồi từ OFS? F Tìm đường dẫn tối ưu T F Kết nối đường xuống? T = True: Đúng F = False: Sai F T Cập nhật đồ hình mạng Kết thúc Hình 2.3 Lưu đồ thuật tốn điều khiển SDN 52 Khi OFS kết nối đến điều khiển SDN tương ứng với kiện “kết nối đường lên” (Connection Up), điều khiển thực việc cập nhật đồ hình mạng tin LLDP Sự kiện Connection Up xuất kênh điều khiển với OFS thiết lập Sau đó, điều khiển định kỳ gửi tin StatsRequest sau giây để truy vấn số byte liệu mà OFS gửi/nhận tính tốn băng thơng khả dụng liên kết Vậy thông tin phản hồi lưu đồ Hình 2.3 byte liệu Bả ng 2.3 mà OFS gửi lên điều khiển SDN Đồng thời, điề u khiển tính tốn băng thơng mà cổng tương ứng với phía máy khách sử dụng, ký hiệu giá trị ngưỡng Khi thơng lượng ước tính phía máy khách ( thống kê phía máy khách < nhỏ ), tức điều khiển xét thấy băng thơng mức thấp (là mức băng thơng làm cho chất lượng video suy giảm nghiêm trọng) điều khiển thực việc định tuyến lại để tìm đường dẫn tối ưu cho luồng liệu video Tiếp đến kiể m tra kiện “kết nối đường xuống” (Connection Down) - kiện xuất mộ t kết nối đến OFS bị cắt đứt Vậy OFS ngắt kết nối với điều khiển thực cập nhật đồ hình mạng lặp lại bước Để tiến hành thí nghiệm cho mạng truyền thống (non-SDN) tất đề xuất luận án này, điều khiển SDN kích hoạt chế độ mặc định Khi việc định tuyến đường máy chủ HTTP máy khách HTTP thực theo thuật toán chọn đường ngắn Dijkstra Thuật toán Dijkstra mang tên nhà khoa học máy tính người Hà Lan – Edsger W Dijkstra, thuật toán giải toán đường ngắn đồ thị có hướng khơng có cạnh trọng số âm Ứng dụng lớn thuật tốn cơng nghệ Hệ thố ng định vị tồn cầu GPS [92] 2.5 Thuật tốn thích ứng tốc độ bit với chế định tuyến đề xuất Để lựa chọn mức chất lượng video phù hợp cho yêu cầu tiếp theo, việc cần thiết phải xây dựng thuật tốn thích nghi tố c độ bit phía máy khách Trong giải pháp đề xuất này, luận án thiết kế thuật tốn thích ứng tốc độ bit không dựa vào mức chiếm dụng đệm mà cịn tính đến thơng lượng ước lượng đo phía máy khách Bên cạnh thuật tốn đề xuất cịn phối hợp với điều khiển SDN để tìm đường tối ưu cho việ c streaming video Tức là, thông lượng phía máy khách giảm xuống mức định với ngưỡng đệm mức thấp máy khách phải thích nghi với mức chất lượng video thấp tương ứng Lúc máy khách khẩn cấp g ửi yêu cầu đến b ộ điều khiển SDN Ngay lập tức, điều khiển SDN phân tích, đánh giá cung cấp đường dẫn định tuyến tối ưu cho 53 máy khách Vậy giải pháp đề xuất kết hợp thuật tốn thích ứng tốc bit phía máy khách để lựa chọn mức chất lượng video phù hợp với việc định tuyến lại theo yêu cầu dựa SDN nhằm tìm thấy đường dẫn tối ưu cho việc streaming video từ máy chủ đến máy khách Trong đó, mạng truyề n thống, máy khách máy chủ trao đổi thông tin với qua HTTP theo quy tắc yêu cầu - đáp ứng để chọn mức chất lượng video phù hợp Đối với việc định tốc độ bit mới, phương pháp chia thành ba trường hợp, tăng mức chất lượng, trì mức chất lượ ng giảm mức chất lượng Dựa vào phương pháp sở đệm, thuật toán chia đệm thành ba ngưỡng giới hạn từ Blow đến Bmax (Blow < Bhigh < B max) Lưu đồ thuật tốn đề xuất biểu diễn Hình 2.4 chi ti ết thuật toán đề xuất trình bày Thuật tốn 2.2 Bắt đầu Đo Bi Bi ≥ Bhigh F T F F T T F Blow ≤ Bi (với giá trị thực nghiệm) tốc độ bit trung bình mức chất lượng không vượt tốc độ bit tối ưu ( < ) Thuật toán 3.1 Thuật toán VASR Input: , , , B i, , , P i+1 Output: // Trường hợp tăng mức chất lượng then 1: If then 2: If > ˄ < 3: = + 1; 4: Else 5: = ; 6: End if 7: // Trường hợp ổn định ) then 8: Else if [ , 9: = ; 10: End if 11: //Trường hợp giảm mức chất lượng 12: Else if [ , ) then 13: If < ˄( > ˅ > ) then 14: = – 1; 15: Else 16: = ; 17: End if 18: End if 19: // Trường hợp “nguy kịch có hỗ trợ SDN” then 20: Else if < 21: Yêu cầu định tuyến lại 22: For ( = Ii ; ≥ 1; ) then 23: If < 24: = 25: End if 26: End for; 27: End if 28: End if + Trường hợp gi ảm mức chất lượng mức đệm nằm khoảng từ mức ) Điểm đáng ý quan trọng làm thấp đến mức ngưỡng động [ < đảm bảo mức đệm đủ để khơng bị cạn kiệt thơng lượng tốc độ bit phân đoạn hoạt động trường hợp xấu Theo giải pháp đề xuất Chương 2, 70 luận án trình bày phương pháp để giải vấn đề cho video CBR nhận thấy hiệu trường hợp cho video VBR Khi có khác biệt đáng kể thông lượng tốc độ bit phân đoạn tức thời ngưỡng đệm động Dựa vào [18], giá trị ngưỡng đệm động phải gần sát với mức đ ệm cao xác định sau = ( (3.4) ) Tương tự trường hợp đầu (tăng mức chất lượng), máy khách phát giá trị độ lệch âm cách nghiêm trọng ( < ) mức chất lượng video có chất lượng với tốc độ bit trung bình cao so với tốc độ bit tối ưu ( > ) bối cảnh ngu ồn tài nguyên mạng giảm sút ( > ), máy khách giảm chất lượng mức theo yêu cầu [ + Trường hợp ổn định kích hoạt mức đệm nằm phạ m vi ) Giới hạn xem an tồn, máy khách giữ ngun mức chất , lượng cho yêu cầu Trong trường hợp tăng mức chất lượng trường hợ p giảm mức chất lượng, số điều kiện thuật toán khơng thỏa mãn chất lượng video trì + Cuối trường hợp nguy kịch có hỗ trợ SDN “SDN – Assisted switchdown” Đây trường hợp điều kiện mạng yếu nên phải có hỗ trợ mạng SDN cho trình streaming video Bộ điều khiển SDN kích hoạt mức đệm ), tức mức đệm nằm vùng bị nguy kịch, nhỏ mức thấ p ( < đệm bị cạn kiệt Đối với trường hợ p giảm mức chất lượng thông thường máy khách yêu cầ u giảm mức chất lượng, trường hợp “SDN – Assisted switch-down” khối thích ứng hạ chất lượng video xuống với mức phù hợp, thường mức chất lượng tốt mà mạng đáp ứng trường hợp ( < ) Từ “assisted -được hỗ trợ” ngụ ý nói rằ ng có hợp tác hỗ trợ kỹ thuật định tuyến thông qua cơng nghệ SDN Khi dịch vụ streaming thông báo cho điều khiển SDN việc giảm chất lượng video mức cho phù hợp Đầu tiên, máy khách gửi yêu cầu cho phân đoạn video đến máy chủ Sau trạng thái thuộc tính phân đoạn videođược chuyển đến điều khiển SDN Tiếp đến, điều khiển định đường dẫn mạng việc xem xét tốc độ bit phân đoạn yêu cầu băng thơng khả dụng trình bày Phần 3.4.3 Sau phát đường dẫn có khả phân phối luồng video theo yêu cầu, điều khiển SDN cài đặt quy tắc luồng để gói tin video theo đường dẫn 71 3.4.3 Kỹ thuật định tuyến định kỳ định tuyến thích nghi dựa SDN đề xuất Chúng ta nhìn thấy thuật tốn thích ứng VASR đề xuất, máy khách u cầu băng thơng (dịng 21 Thuật tốn 3.1), tài ngun có sẵn đường dẫn không phù hợp với băng thông này, đường dẫn tìm thấy b ởi hệ thống truyền tải SDN Trong phần này, giải pháp đề xuấ t mô tả cách định tuyến để tìm đường dẫn thực mạng truyền tải dựa SDN Kiến trúc điều khiển đề xuất mô tả Hình 2.1 Chương 2, cung cấp giao diện điều khiển-chuyển tiếp (ControllerForwarder) số chức khác Giao diện hỗ trợ giao thức OpenFlow, giao thức cung cấp phương thức trao đổi thông tin cách an toàn điều khiển chuyển tiếp chẳng hạn định tuyến chuyển mạch Giải pháp sử dụng kiến trúc bao gồm chức khám phá đồ hình mạng, sửa đổi bảng luồng giám sát tài nguyên Để đánh giá hiệu thuật tốn thích ứng VABR chế định tuyến dựa SDN, đề xuấ t luận án đưa ba chế khác nhau, là: định tuyến định kỳ dựa SDN viết tắt SPR (SDN-based Periodical Routing); định tuyến thích nghi dựa SDN mà khơng cần giám sát, ký hiệu SAR (SDN-based Adaptive Routing without monitoring) định tuyến thích ứng dựa SDN với trình giám sát, đặt tên SARM (SDN-based Adaptive Routing with Monitoring) 3.4.3.1 Định tuyến định kỳ dựa SDN (SPR) Cơ chế thực định tuyến đường dẫn định kỳ dựa SDN hiển thị lưu đồ thuật tốn Hình 3.3 Bộ điều khiển khơng thể xác định tình trạng liên kết khơng có gói tin qua liên kết Do gói tin video sử dụng để xác định băng thông tuyến Bộ điều khiển giải pháp triển khai với phương pháp Round-robin [100] Round-robin thuật toán sử dụng lập lịch mạng quy trình máy tính Khoảng thời gian gán cho quy trình theo phần theo thứ tự vòng tròn, xử lý tất quy trình mà khơng cần ưu tiên (cịn gọi thực thi theo chu kỳ) Trong giải pháp, gói tin video qua liên kết sử dụng để đo băng thông xấp xỉ, tức lượng liệu tối đa truyền đường dẫn thời điểm định Chính sách định tuyến định kỳ chia làm hai giai đoạn Hình 3.3 Trong giai đoạn chuyển mạch (Switching Stage), đường dẫn chọn luân phiên t giây (s) Bộ điều khiển lưu trữ băng thơng đo đường dẫn trước trước 72 gửi thông tin luồng c đường dẫn tới chuyển tiếp OFS Khi băng thông tất liên kết ước tính, điều khiển chọn đường dẫn có băng thơng khả dụng cao thời điểm để phục vụ Do đó, giai đoạn ổn định (Steady Stage) băng thông tối ưu tất đường dẫn xác định sau: = [ , ] { (3.5) } Đường dẫn có băng thơng cao trì khoảng thời gian ( × ) giây trước tồn quy trình lặp lại Tổng thời gian T cho thủ tục tính theo cơng thức: =( (3.6) + ) n tổng số đường dẫn có mạng, tham số ổn định đường dẫn cụ thể t thời gian chuyển mạch đị nh kỳ F Bắt Bắt đầu đầu streaming? streaming? Bắt Bắt đầu đầu T Giai đoạn chuyển mạch i= i=i+1 Thêm Thêm luồng luồng cho cho đường đường dẫn dẫn thứ thứ ii F Đo Hết Hết tt giây? giây? T F i = n? T I = IndexOf(max( Giai đoạn ổn định )) Cài đặt luồng cho đường dẫn I giây? giây? Hết F T F Dừng Dừng streaming? streaming? T Kết Kết thúc thúc Hình 3.3 Lưu đồ thuật tốn định tuyến định kỳ thời gian trì 73 Cần lưu ý thời gian chuyển đổi theo chu kỳ cần phải đủ dài để điều khiển xử lý truy vấn thống kê Các truy vấn tin OpenFlow mặc định sử dụng để trao đổi thông tin cổng vật lý chuyển mạch điều khiển Thơng thường, t lớn giây điều khiển đủ thời gian để xử lý Ngoài ra, điều khiể n cần truy vấn có định kỳ đếm bảng lưu lượng OFS để phát việc sử dụng băng thông liên kết Thêm vào đó, tính chất phân phối lưu lượng, cần có thêm hoạt động định hướng lại luồng, điều làm tăng số lượng tin Flow-mod truyền khối lượng công việc điều khiển chuyển mạch Bản tin Flow-mod định nghĩa giao thức OpenFlow phép điều khiển sửa đổi trạng thái chuyển mạch OpenFlow 3.4.3.2 Định tuyến thích nghi dựa SDN khơng có giám sát (SAR) Khơng giống trường hợp định tuyến định kỳ, ph ần điều khiển thực chế định tuyến thích ứng, tức không thay đổi đường dẫn host theo chu kỳ mà hoạt động theo chế thích nghi Đường dẫn yêu cầu Bắt đầu i=1 Thêm luồng cho đường dẫn thứ i F i=i+1 Hết t giây? Đo T F i = n? T I = IndexOf(max( )) Thiết lập luồng cho đường dẫn I Đường dẫn cài đặt Kết thúc Hình 3.4 Lưu đồ thuật tốn định tuyến thích nghi 74 Quy trình định tuyến lại chế định tuyến thích nghi thực điều khiển SDN phát có tượng tắc nghẽn đường dẫn Điều có nghĩa điều ển SDN chủ động tính tốn lại đường dẫn tối ưu đường dẫn yêu cầu Chính sách định tuyến lại giống với sách định tuyến định kỳ giai đoạn chuyển mạch, điều khiển thay đổi đường dẫn số đường dẫn có sẵn để phát đường dẫn tối ưu Sự khác biệt định tuyến định kỳ định tuyến thích nghi phát sinh giai đoạn ổn định (nghĩa khoảng thời gian tuyến đường cụ thể lựa chọn) Trong sách định tuyến thích nghi, điều khiển s ẽ giữ ổn định đường dẫn tối ưu có nhu cầu định tuyến lại từ máy khách Trong phương pháp định tuyến định kỳ phải chạy lại quy trình liên tục, điều có nghĩa điều khiển làm việc so với trường hợp định tuyến định kỳ Chính sách thể chi tiết bước tiến hành lưu đồ thuật tốn Hình 3.4 3.4.3.3 Định tuyến thích nghi dựa SDN có giám sát (SARM) Trong phần này, luận án đề xuất vấn đề định tuyến thích nghi có giám sát điều khiển SDN Tức là, việc theo dõi đường dẫn tại, điều khiển SDN lắng nghe yêu cầu từ phía máy khách Hình 3.5 Đường dẫn yêu cầu Bắt đầu i=1 Bắt đầu streaming? Thêm luồng cho đường dẫn thứ i F i=i+1 F T j = Chỉ số đường dẫn Hết t giây? Đo Đo (j) T F i = n? T I = IndexOf(max( T (j) < BWth? F )) Dừng streaming? Thiết lập luồng cho đường dẫn I Đường dẫn cài đặt T Kết thúc Quá trình giám sát Hình 3.5 Lưu đồ thuật tốn định tuyến thích nghi có giám sát F 75 Bình thường khơng có vấn đề tắc nghẽn liên kết mạng đề xuất SARM thực chế định tuyến thích nghi giống khơng có q trình giám sát SAR Vì tắc nghẽn đường liên kết mạng xảy vào thời điểm mà điều khiển chưa nhận yêu cầu từ máy khách nên việc chạy quy trình giám sát với q trình thích nghi điều cần thiết Quy trình định tuyến dựa SDN có giám sát SARM thực với hai nhiệm vụ chính: - Thứ nhất, trường hợp nguy kịch có hỗ trợ SDN (từ dịng 19 Thuật tốn VASR), phía máy khách mức đệm nhỏ ngưỡng đệm mức ), hệ thống phải tìm tuyến đường đáp ứng yêu cầu băng thấp ( < thông máy khách tương ứng - Thứ hai, trình giám sát, điều khiển SDN liên tục đo thông lượng đường dẫn phân phối liệu video Và thông lượng đường dẫn không đáp ứng (nhỏ hơn) thông lượng ngưỡng theo yêu cầu BW th, tức liên kết coi bị tắc nghẽn điều khiển thực tìm kiếm đường dẫn tối ưu để phục vụ mà không cầ n chờ đợi yêu cầu máy khách 3.4.4 Thực nghiệm đánh giá kết Trong phần này, để đánh giá kết quả, luận án so sánh giải pháp đề xuất với phương pháp khác tồn phương pháp Aggressive có sử dụng ngưỡng đệm đề xuất, đặt tên “non-SDN” [5] Tức phương pháp sử dụng thông lượng cuối làm thơng lượng ước tính k ết hợp với ngưỡng đệm để xây dựng thuật toán thích ứng tố c độ bit Phương pháp đối sánh thứ hai phương pháp thích ứng tốc độ cảm nhận phân đoạn, gọi "SARA" [19] Trong non-SDN, mức chất lượng tăng giảm tùy thuộc hoàn toàn vào giá trị băng thông ước lượng Cơ chế chuyển mức chất lượng non-SDN nhạy cảm với trường hợp băng thông tăng mạnh khoảng thời gian ngắn sau đột ngột giảm Khi máy khách yêu cầu mức chất lượng cao nhiên mức băng thông cao khơng trì đủ lâu để tải hết segment yêu cầu Điều gây việc đóng băng video q trình xem nên phải phối hợp với đệm phía máy khách để hạn chế vấn đề Thuật tốn thích nghi tốc độ bit SARA h ạn chế trạng thái đóng băng video đạt mức chất lượng tương đương so với phương pháp non-SDN SARA cho phép yêu cầu mức chất lượng, phương pháp non-SDN yêu cầu nhi ều mức chất lượng khác Tuy nhiên phương pháp SARA phải đánh đổi việc mức đệm thường mức thấp gây việc đóng băng cho video băng thông giảm đột ngột không đáp ứng yêu cầu người xem muốn tua nhanh video 3.4.4.1 Thiết lập thực nghiệm Sơ đồ mạng thực nghiệ m cho tất giải pháp chương minh họa Hình 3.6 Thuật tốn đề xuất mơ cơng cụ tạo mạng ảo Mininet [81] 76 để tạo cấu trúc liên kết mạng Trong có máy chủ DASH, máy khách DASH năm chuyể n mạch (sj , j = ÷ 5) Máy chủ thực để tạo mạng ảo Apache Webserver phiên 2.4.7 ch ạy Ubuntu 14.04 Các chuyển mạch OFS tạo nhiều đường dẫn từ máy khách đến máy chủ chúng kết nối với điều khiển - Floodlight Bộ điều khiển SDN đảm nhận công việc điều khiển luồng tính tốn tuyến lựa chọn đường dẫn tối ưu Bộ điều khiển SDN S5 Máy khách HTTP S1 S3 S2 Máy chủ HTTP S4 Hình 3.6 Sơ đồ mạ ng thí nghiệm Bảng 3.1 Thơng tin m ức chất lượng video thí nghiệm Chỉ số mức chất lượng QP Tốc độ bit trung bình (kbps) 46 354 43 472 40 638 37 882 34 1234 31 1779 28 2588 25 3823 22 5613 10 11 19 16 13 8028 11156 15227 Ở phía máy chủ DASH, video thí nghiệm phim hoạt hình ngắn có tên Elephants Dream [101], có độ dài với khoảng thời gian 10 phút 54 giây Video mã hóa dạng video có tốc độ bít biến đổi VBR sử dụng chuẩn H.264 phân 77 chia thành 12 mức chất lượng với tham số lượng tử hóa khác (QPs Quantization Parameters) Trong thí nghiệm, tập giá trị QP 13, 16, 19, 22, 25, 28, 31, 34, 37, 40, 43, 46 Tất mức chất lượng video phục vụ độ phân giải Full-HD (1920x1080) 24 khung hình giây Mỗi mức chất lượng chia thành phân đoạn video nh ỏ giây, điều có nghĩa có tổng số 327 phân đoạn tải xuống q trình tiế n hành mơ Tốc độ bit phân đoạn tất mức chất lượng video hiển thị Hình 3.2 Chỉ số mức chất lượng, tham số lượng tử QP tốc độ bit trung bình tương ứng mức chất lượng liệt kê Bảng 3.1 Tập tin mô tả manifest chứa thông tin tất mức chất lượng video [6] Máy khách DASH phải yêu cầu tệp miêu tả trình đa phương tiện MPD trước luồng video bắt đầu tả i xuống Máy khách DASH ví người chơi video thực theo tiêu chuẩn MPEG-DASH cách sử dụng thư viện libdash [94] Chức u cầu tệp manifest từ máy chủ, phát nội dung video điều chỉnh chất lượng video tùy theo điều kiện mạng Thuật tốn thích nghi tốc độ bit cài đặt khối thích ứng máy khách thuật tốn đề xuất , phụ thuộc vào thông lượng đệm video đo phía máy khách Như thấy Hình 3.6 , có bốn đườ ng dẫn cho gói tin truyền từ máy chủ đến máy khách sau: S2 S2 S2 S2 – S3 – S1 – S3 – S4 – S1 – S5 – S3 – S1 – S5 – S3 – S4 – S Trong thực tế, để xử lý băng thông dao động liên kết mạng, giải pháp sử dụng kỹ thuật điều khiển lưu lượng TC [102] giao diện mạng đường xuống dọc theo đường dẫn Điều khiển lưu lượng hoạt động dựa gói rời khỏi hệ thống Mã TC hoạt động lớp IP trình điều khiển phần cứng truyền liệu mạng Điều có nghĩa mơ-đun TC, tức lập lịch gói kích hoạt cố định phận kernel, không yêu cầu rõ ràng Theo mặc định, lập lịch trì hàng đợi First-In First- Out (FIFO) nghĩa gói đến gói truyền Tại lõi, TC bao gồm queuing disciplines qdisc đại diện sách lập lịch áp d ụng cho hàng đợi Trong trường hợp này, giải pháp triển khai lọc nhóm mã thơng báo TBF (Token Bucket Filter) gán mã thông báo cho qdisc để giới hạn tốc độ luồng Để tiến hành thí nghiệm lựa chọn đường dẫn tối ưu, giải pháp đề xuất giả định băng thông đường dẫn khác đánh giá biến động băng thông 78 bốn đường dẫn thực tế đường dẫn tốt Hình 3.7 (Path: 2-3-1, Path: 23-4-1, Path: 2-5-3-1, Path: 2-5-3-4-1 Best Path) Trong đó, đường (Best Path) đường dẫn v ới khả liên kết tốt th ời điểm định Cơ chế định tuyến động dựa SDN thực thí nghiệm mơ mơ tả Hình 3.3 Hình 3.4 Lưu đồ Hình 3.3 chia thành hai trạng thái: Trạng thái chuyển mạch trạng thái ổn định Các tham số biểu thức (3.6) thiết lập cố định với n = 4, α = 1, t = 2s Hình 3.7 Các kịch băng thơng đường dẫn sử dụng thí nghiệm 3.4.4.2 Các kịch thí nghiệm Để đánh giá hiệu việc triển khai sách định tuyế n khác dựa SDN, giải pháp đề xuất giới thiệu ba kịch bao gồm sáu thí nghiệm sau: Kịch 1: Bộ điều khiển kích hoạt với hành vi mặc định nó, biến đổi chuyển mạch OpenFlow (OFS) thành chuyển mạch truyền thống Trong loại mạng này, đường dẫn tốt hai host thường đường dẫn có số bước nhảy tối thiểu Kịch 2: Bộ điều khiển triển khai với sách định tuyến định kỳ Trong trường hợp này, điề u khiển bỏ qua yêu cầu định tuyến từ máy khách hoạt động độc lập cho toàn phiên streaming Kịch 3: Bộ điều khiển triển khai với sách định tuyến thích ứng Q trình giám sát có khơng kích hoạt Trong số ba kịch này, giải pháp tiến hành tổng cộng sáu thí nghiệm sau: • Thí nghiệm 1: Giải pháp “non-SDN” thí nghiệm với Kịch • Thí nghiệm 2: Giải pháp "SARA" thí nghiệm với Kịch Các tham số thuật toán SARA thiết lập cố định Bmin = 10s, Blow = 15s, Bhigh = 25s, 79 Bmax = 50s Các tham số lựa chọn dựa vào cơng trình [19] cho thí nghiệm • Thí nghiệm 3: Giải pháp “SDN-based SARA” thí nghiệm với Kịch Trong thí nghiệ m này, giải pháp kết hợp thuật tốn thích ứng tốc độ bit SARA với chế định tuyến định kỳ dựa SDN Chu kỳ chuyển mạch với thời lượng phân đoạn video (t = 2s) Đường dẫn tốt trì chu kỳ chuyển mạch ( = 1) Các tham số thuật toán SARA thiết lập cố định Bmin = 10s, Blow = 15s, Bhigh = 25s, Bmax = 50s • Thí nghiệm (Kịch 2): Chu kỳ chuyển mạch với th ời lượng phân đoạn video (t = 2s) Đường dẫn tốt trì chu k ỳ chuyển mạch ( = 1) Sự thích ứng tốc độ bit sử d ụng thuật tốn VASR đề xuất • Thí nghiệm (Kịch bả n 3): Chu kỳ chuyển mạch với thời lượng phân đoạn video (t = 2s) Quá trình giám sát khơng kích hoạt Sự thích ứng tốc độ bit sử dụng thuật toán VASR đề xuất • Thí nghiệm (Kịch bả n 3): Chu kỳ chuyển mạch với thời lượng phân đoạn video (t = 2s) Kích hoạt q trình giám sát ( = 1000 ) Sự thích ứng tốc độ bit sử dụng thuật toán VASR đề xuất Đối với tất trườ ng hợp, số lượng đường dẫn có bốn ( n = 4) Ở phía máy khách, thích ứng logic VBR sử dụng tham số sau: = 15 , = 0.5 Máy khách yêu cầu phân đoạn = 25 , = 50 video có mức chất lượng thấp 3.4.4.3 Đánh giá kết Có tham số đo đạc thể từ Hình 3.8 đến Hình 3.13, là: tốc độ tải, tốc độ bit trung bình (Avg.Bitrate – Average Bitrate), tốc độ bit thực tế (Act.Bitrate – Actual Bitrate) mức đệm Trong đó, Avg.Bitrate tốc độ bit trung bình video VBR tương ứng với mức chất lượng QP Bảng 3.1 Còn Act.Bitrate tốc độ bit thực tế video VBR đo máy khách Mức sử dụng đệm hiểu lượng video cịn lại đệm, thường tính đơn vị thời gian Hình 3.8 Hình 3.9 thể kết c Thí nghiệm (Kịch 1) cho việc streaming video VBR qua giao thức HTTP mạng chuyển mạ ch truyền thống (nonSDN) Như nêu trước đó, mạng non-SDN, gói liệu thường truyền dọc theo đường dẫn có số bước nhảy tối thiểu trường hợp đường dẫn 2s s s3 80 Hình 3.8 Kết thích nghi cho phương pháp non-SDN Hình 3.9 Kết thích nghi cho phương pháp “SARA” Hình 3.10 Kết thích nghi cho phương pháp “SDN-based SARA” 81 Hình 3.11 Kết thích nghi cho giải pháp định tuyến định kỳ với SDN (SPR) Hình 3.12 Kết định tuyến thích nghi khơng có q trình giám sát (SAR) Hình 3.13 Kết định tuyến thích nghi có q trình giám sát (SARM) 82 Từ kết Hình 3.8 Hình 3.9, ta quan sát thấy rằng, hình dạng tốc độ tải gần giống với băng thông đường dẫn s2 s s Vào thời điểm kết thúc ¼ phiên streaming (từ khoảng phân đoạn 80), đường dẫn ba chuyển mạch bị tắc nghẽn nghiêm trọng thông lượng chưa vượt q 500kbps Trong tình trạng này, khơng có chế định tuyến lại, trình phát phương tiện thích nghi cách tải xuống mức chất lượng video chất lượng Cho đến đoạn ¼ phiên streaming cuối cùng, kh ả lưu lượng đường dẫn phục hồi mức chất lượng video tốt yêu cầu trở lại Cả hai Thí nghiệm Kịch sử dụng chế định tuyến định kỳ điều khiển SDN Hình 3.10 cho kết chạy thuật tốn thích ứng tốc độ bit phía máy khách SARA dựa SDN (SDN-based SARA) Hình 3.11 kết cho trường hợp thực giải pháp thích ứng tốc độ bit kết hợp với định tuyến định kỳ (SPR) đề xuất luận án Trong kết Hình 3.10 ta thấy, tốc độ bit mức chất lượng video chạy thuật toán SDN-based SARA nâng cao nhiều so với trường hợp khơng có SDN Hình 3.9 Kịch cuối (Kịch 3) việc thực chế định tuyến thích ứng điều khiển SDN Nó chia thành hai trường hợp: có khơng có q trình tự giám sát Đối với trường hợp khơng có giám sát (SAR), điều khiển tính tốn đường dẫn dịch vụ streaming có yêu cầu Hình 3.12 kết trình giám sát khơng kích hoạt Như hình ta thấy, tín hiệu khoảng thời gian ¼ đoạn đầu đoạn cuối phiên streaming trơng giống với thí nghiệm khơng có diện điều khiển Điều điều kiện mạng đáp ứng yêu cầu máy khách mà không cần định tuyến lại điều khiển Ở đoạn giữa, thơng lượng đường ngắn gây tắc nghẽn nên lúc điều khiển thực định tuyến lại phát có nhu cầu từ máy khách chất lượng video cải thiện tốt so với thí nghiệm trước Từ cho thấy liệu video tải xuống đường dẫn ngắn chưa phải tốt mà phải thơng qua đường dẫn khác có hiệu suất tốt Đối với trường hợp có giám sát (SARM), điều khiển tự động tính tốn đường dẫn phát nút thắt cổ chai đường dẫn mà khơng cần u cầu từ phía máy khách (Hình 3.13) Từ kết Hình 3.13, ta thấy mức chất lượng video tốt tải xuống hầu hết toàn thời gian streaming video Chỉ có hai mức chất lượng rớt xuống mức thấp khoảng phân đoạn 52 phân đoạn 178, điều xảy lúc phân bổ lại đường dẫn Tiếp đến giải pháp minh họa số kết thấy khác biệt hiệu phương pháp Hình 3.14 mô tả tốc độ bit thực tế phân đoạn tải xuống Hình 3.15 kết số mức chất lượng tương ứng Khi bắt đầu phiên streaming, chế thích ứng t ốc độ bit giải pháp máy khách dựa đệm, phân đoạn video có tốc độ bit thấp tải xuống an tồn để chuyển sang mức video có chất lượng tốt Do đó, 16 giây đầu tiên, tương 83 ứng với phân đoạn đầu, tất phương pháp giống hệt Khi chuyển đổi mức chất lượng video, khối thích ứng thực chuyển mạch bước cách mượt mà mức chất lượng Đến phân đoạn thứ 25 tải xuống, tất phương pháp đạt đến mức chất lượng cao Từ phân đoạn trở đi, phương pháp tạo hành vi hoàn toàn khác Cho đến phân đoạn thứ 270, tấ t phương pháp hiển thị lại kết gần giống nhau, lý tất đường dẫn mạng đủ để cung cấp tốc độ bit phân đoạn cao cuối phiên streaming Từ kết hiển thị hai hình vẽ này, ta suy thí nghiệm mạng truyền thống (non-SDN, SARA) có kết thấp nhất, thấy rõ từ khoảng phân đoạn 80 phân đoạn 270, giải pháp định tuyến định k ỳ (SDN-based SARA, SPR) cho thấy số cải tiến tốt Hiệu tất cả, giải pháp định tuyến thích ứng cung cấp chất lượng video tốt nhất, đặc biệt với giải pháp đề xuất có quy trình giám sát (SARM) Hình 3.14 Kết tốc độ bit thực tế tất phương pháp Hình 3.15 Kết mứ c chất lượng tất phương pháp 84 Hình 3.16 Kết mức đệm t ất phương pháp Khi xem xét mức độ đệm (Hình 3.16), thí nghiệm định ến thích nghi (SAR, SARM) cho thấ y kết trội hết Đặc biệt khoảng thời gian từ phân đoạn 20 đến phân đoạn 40 từ phân đoạn 80 đến phân đoạn 140, phương pháp thích nghi tích lũy mức đệm cao trì chất lượng video tốt Điều có q trình giám sát tình trạng liên kết định tuyến động theo yêu cầu máy khách Các kịch khác cho thấy hành vi mức đệm thấp biến động mạnh Trong giai đoạn từ phân đoạn 140 đến phân đoạn 170, mức đệm tất phương pháp đề u bị giảm đáng kể Trong phiên streaming này, tính khả dụng c băng thơng mạng (Hình 3.7) khơng đủ để phân phối phân đoạn video với tốc độ bit cao cách hiệu Tức nhiều thời gian để tải phân đoạn phát Nhìn chung, thuật tốn thích ứng tốc độ bit dựa đệm - thông lượng nên mức độ đệm trường hợp đề u thể biến động lớn Ta sử dụng hàm phân phối tích lũy (CDF) tốc độ bit (Hình 3.17) tốc độ tải (Hình 3.18) để đánh giá hành vi tổng thể máy khách việc so sánh Từ Hình 3.17, dễ dàng nhìn thấy tốc độ bit phân đoạn phương pháp đề xuất SARM cao hết so với phương pháp cịn lại Cụ thể, SARM có khoảng 50% phân đoạn với bitrate lớn 8000kbps Còn giá trị CDF cho phương pháp SDN-based SARA, SPR SAR thấp nằm khoảng 28-46%, số cho phương pháp non-SDN SARA thấp mức 14-17% Chúng ta thấy Hình 3.18, giải pháp đề xuất (SARM, SAR, SPR) dựa SDN cung cấp tốc độ tải cao so với thuật toán với đường dẫn cố định Tỷ lệ phần trăm phân đoạn tải xuống với tốc độ tải 5000kbps 85 SARM, SAR, SPR SDN-based SARA 22%, 24%, 31% 32% Trong thông số non- SDN SARA với đường dẫn cố định cao nhiều khoảng 58-60% Với tốc độ tải lớn 10000kbps, sách định tuyến thích nghi phương pháp đề xuất khoảng 50% phân đoạn tải xuống Trong CDF cho thuật tốn khác khơng có chế định tuyến dựa SDN từ 13-22% Hình 3.17 Hàm phân phối tích lũy (CDF) tốc độ bit phương pháp Hình 3.18 Hàm phân phối tích lũy (CDF) tốc độ tải phương pháp Để giải thích rõ ràng hơn, Bảng 3.2 tóm tắt số thơng số chất lượng đáng ý phương pháp đưa thí nghiệm Qua số liệu thống kê bảng khẳng định phương pháp đề xuất mà đặc biệt phương pháp định tuyế n thích nghi có giám sát SARM cho chất lượng video tốt hết so với phương pháp khác Như hiển thị Bảng 3.2, phương pháp đề xuất có khả 86 nâng cao số thông số ảnh hưởng đến QoE cho người xem video Và để khảo sát kế t cách chi tiết, ta chia kịch thành ba nhóm: Thuật tốn thích nghi tốc độ bit không dựa vào SDN (non-SDN, SARA), định tuyến định kỳ với SDN (SDN-based SARA, SPR) định tuyến thích ứng với SDN (SAR, SARM) Bảng 3.2 Các tham số đánh giá chất lượng video phương pháp VASR đề xuất Non-SDN SARA SDN-based SARA SPR SAR SARM Tốc độ bít trung bình (kbps) 4435 3782 6864 8296 9404 10238 Chỉ số mức chất lượng trung bình 5.7 5.9 8.3 8.7 9.1 9.5 Mức đệm trung bình (s) 30 23 29 32 36 35 Tỷ lệ đệm < 15s (%) 7.6 23.2 2.4 4.5 3.3 2.7 Số lần giảm mức chất lượng 10 32 22 13 6 Thông số chất lượng Biên độ giảm chất lượng Đối với trường hợp định tuyến định kỳ SDN, chất lượng video tổng thể tốt trường hợp non-SDN SARA Tuy nhiên, phương pháp không đảm bảo việc cải thiện mức độ đệm so với phương pháp định tuyến thích ứng Mặt khác, phương pháp địi hỏi mộ t số lượng công việc lớn controller Ngược lại, phương pháp định tuyến thích ứng với trình giám sát (SARM) cung cấp tố c độ bit trung bình cao 10238kbps, lớn gấp đơi so với trường hợp khơng có định tuyến (3782kbps 4435kbps) Ngoài ra, số mức chất lượng trung bình, mức đệm trung bình tỷ l ệ trạng thái đệm mức thấp (nghĩa mức đệm nhỏ ngưỡng đệm mức thấp) toàn phiên streaming cho thấy hiệu suất trung bình phương pháp đề xuất tốt nh ất số tất phương pháp Tỷ lệ thời gian streaming mà mức đệm giảm xuống 15 giây (vùng nguy hiểm) SARM thấp 2.7% so với phương pháp khác Trong tiêu chí có phương pháp SARA dựa SDN thực tốt 2.4% Số lần giảm mức chất lượng phương pháp đề xuất SARM ghi lại số thấp 6, trường hợp khơng dựa SDN có số lần giảm chất lượng video lên đến 10 lần non-SDN 32 lầ n SARA tồn phiên streaming, điều có nghĩa video phân phố i đến máy khách phương pháp đề xuất mượt mà ổ n định Một tham số quan trọng khác biên độ giảm mức chất lượng (bước giảm mức chất lượng l ớn nhất), số mức chất lượng tối đa chuyển mức hai phân đoạn 87 liên tiếp Tham số nhỏ suy giảm chất lượng video thời điểm chuyển mức t ức thời mà chất lượng video giảm cách đột ngột mang lại khó chịu cho người xem Trong trường hợp khơng có chế định tuyến b ởi điều khiển SDN, bước nhảy lớn đo lường SARA, từ số mức chất lượng phân đoạn 75 xuống mức phân đoạn 76 Tuy nhiên, kết hợp với điều khiển, SDN-based SARA tham số thấp tất phương pháp Trong giải pháp đề xuất phần SPR, SAR and SARM có kích thước bước nhả y lớn chấp nhận 5, Vậy tham số xem hạn chế giải pháp đề xuất Từ phân tích trên, nhìn chung đề xuất định tuyến thích ứng với trình giám sát (SARM) mang lại hiệu suất tốt số tất phương pháp Nếu xét mức độ làm việc điều khiển SDN SAR làm việc (khoảng 62.95%), cịn điều khiển phương pháp SARM làm việc nhiều (kho ảng 66.96%) tồn phiên streaming Vì vậy, tính đến việc sử dụng điều khiển phương pháp định tuyến thích ứng khơng có giám sát SAR cải thiện số tham số QoE đáng kể trải nghiệm ngườ i dùng video so với SARM 3.5 Giải pháp cải thiện QoE cho video VBR qua giao thức HTTP dựa SDN Phần luận án đề xuất thuật tốn thích ứng tốc độ phương pháp ước lượng trước mức đệm t ại phía máy khách với việc định tuyến động dựa vào độ ổn định băng thông SDN Mục đích giải pháp nhằm tránh tình trạng đóng băng giảm băng thông đột ngột đảm bảo chất lượng video, cải thiện cách đáng kể QoE người dùng Để đạt điều giải pháp phải tiến hành cải thiện phương pháp ước lượng thơng lượng ước tính mức đệm phù hợp cho mức chất lượng video lựa chọn Bên cạnh để nâng cao chất lượng streaming video, dựa vào tham số ổn định băng thông biên độ khả dụng để lựa chọn tuyến tối ưu cho luồng streaming video Luận án dựa vào mô hình QoE trình bày Chương để đánh giá giải pháp đề xuất với phương pháp tồn 3.5.1 Ước tính thơng lượng mức đệm cho giải pháp đề xuất Ta biết rằng, thông lượ ng phân đoạn tính cách chia tổng dung lượng phân đoạn video nhận cho khoảng thời gian từ lúc bắt đầu máy khách gửi yêu cầu byte đến lúc nhận byte cuối video Để dự đốn thơng lượng phân đoạn tiếp theo, giải pháp đề xuất sử dụng phối hợp hai cách dự đốn thơng lượng trình bày cơng thức (2.1) (3.2) nhằm trì ổn định tốc độ bit thích ứng nhanh điều kiện mạng biến động Vậy thơng lượng 88 giá trị nhỏ nhấ t phân đoạn trước ước tính cho phân đoạn vừa tải xong thông lượng trung bình phân đoạn khứ sau: = (1 với ) × { , (3.7) } trọng số nằm khoảng [0;1] Phương pháp ước lượng thơng lượng đề xuất có hai ưu điể m Thứ nhất, hạn chế nhược điểm thơng lượng giảm thơng lượng sử dụng làm thơng lượng dự đốn nhằm thích ứng phân đoạn vừa tải xong nhanh với điều kiện mạng Thứ hai thông lượng tăng so với trước sử dụng làm thông lượng ước đó, tức > thơng lượng trung bình tính nhằm trì ổn định tốc độ bit thông lượng tăng nhanh Cùng với thông lượng ước tính, để lựa chọn mức chất lượng video cho phù hợp tránh tượng đóng băng, giải pháp cần phải dự đoán trước mức đệm phía máy khách Giả sử máy khách bắt đầ u nhận liệu thời điểm 0t thời điểm t1 bắt đầu tiêu thụ liệu từ đệm thu nhận Nếu thơng lượng đo phía máy khách với tỷ lệ phát video đệ m ổn định, mức chiếm dụng đệm bị biến động liên tục Giả định rằng: có i phân đoạn, V mức chất lượng tương ứng V tốc độ bít: = ; Lưu ý video mã hóa dạng VBR thì: , Tại thời điểm đó, sau tải hoàn thành phân đoạn mức chất lượng máy khách đị nh mức chất lượng cho N phân đoạn } Nếu mức đệm { , ,…, } tương ứng với tốc độ bit { , ,…, đủ lớn, với thơng lượng ước tính đủ đáp ứng máy khách lựa chọn mức chất lượng tốt Tuy nhiên, mức đệm thấp máy khách nên tích cực chuyển sang mức chất lượng thấp để tránh tượng cạn đệm Do đó, dựa vào tốc độ bít tức thời mức chất lượng, ta ước lượng mức đệm cho phân đoạn Trên sở mức đệm ước tính tương lai gần này, máy khách điều chỉnh mức chất lượng yêu cầu để tránh tượng cạn/tràn đệm Gọi tốc độ bit , thời gian để tải xuống phân đoạn thứ i với thơng lượng ước tính × , với SD thời khoảng phân đoạn Sau nhận đầy đủ phân đoạn đó, đệm nạp thêm phân đoạn Do đó, thay đổi mức đệm sau: = = × = × (3.8) 89 Vậy tương ứng với giá trị tốc độ bit , từ cơng thức (3.8) ta suy mức đệm ước lượng tính theo biểu thức (3.9) Cần lưu ý mức đệm ước lượng lớn ngưỡng đệm lựa chọn t ốt = × + (3.9) (3.10) Điều kiện: Trong đó, thời gian trọ n vịng RTT - khoảng thời gian xác định từ lúc máy khách gửi yêu cầu đến nhận byte c phân đoạn truy vấn Tham số đưa thêm vào mức đệm ước lượng an toàn Tuy nhiên, tham số RTT thường có giá trị nhỏ ảnh hưởng tính mức đệm ước lượ ng khoảng 40ms Ngưỡng đệm lựa chọn tốt Phần 3.5.3.2 3.5.2 Thuật tốn thích nghi đề xuất MUNTH Để khắc phục y ếu điểm thuật toán cho giải pháp trước, đề xuất đưa chế thích ứng tốc độ bit đượ c mơ tả Thuật tốn 3.2 Thuậ t toán đặt tên MUNTH (iMpede sUspend and attaiN poTential patH- phịng tránh đóng băng lựa chọn tuyến tốt) Đề xuất tập trung hạn chế việc xem video bị đóng băng lựa chọn tuyến linh động theo yêu cầ u máy khách Về cơ chế thích ứng thuật tốn có điểm đáng ý sau: • Khi giá trị thông lượng đo nhỏ giá trị thông lượng ngưỡng tương ứng với chất lượng video máy khách yêu cầu điều khiển SDN tìm tuyến nhằm đạt mức băng thông cao • Với mục đích tránh việc video bị đóng băng, giải pháp có hai chế đưa bao gồm chế ước lượng thông lượng chế chọn mức chất lượng phù hợ p Khi stream khởi tạo, dịch vụ video gửi tin khởi tạo đến điều khiển, điều khiển thông qua mô đun Route Mangager xác định tuyến đường ngắn máy khách máy chủ, đồng thời cập nhật Flow-table cho thiết bị chuyển tiếp OFS Mô đun Traffic Manager kích hoạt để giám sát luồng liệu mạng, mô đun Route Manager thực nhiệm vụ định tuyến trình truyền liệu video Cơ chế chọn tuyến giải pháp dựa vào Mục 3.4.3 để thực hai trường hợp định tuyến định kỳ định tuyến thích nghi sau: Định tuyế n định kỳ Nguyên lý định tuyến định kỳ để lựa chọn đường dẫn tối ưu đề xuất dựa vào lưu đồ thuật tốn Hình 3.3 Cứ sau T giây chu kỳ lặp lại, giá trị 90 băng thông tất tuyến khả dụng đo lưu lại hàng đợi m phần tử để phục vụ cho việc định tuyến Có nhiều tiêu chí khác để đưa sách định tuyến khác SDN như: định tuyến lại dựa vào tham số ràng buột mạng (băng thông, độ trễ, tỷ lệ gói, jitter) [103], dựa vào dung lượng liên kết, dung lượng mạng hay dựa vào đường dẫn có khoảng cách ngắ n Trong giải pháp đề xuất này, luận án dựa theo hai tiêu chí để đưa định tuyến mới, băng thông khả dụng tức thời độ ổn định băng thơng tất đường dẫn có mạng • băng thơng khả dụng tức thời đường dẫn đo điều khiển SDN Chỉ số p biểu diễn cho số đường dẫn n đường có sẵn (cố định từ 1-n) Nếu đường dẫn có nhiều đường liên kết gán cho băng thông nhỏ tất liên kết nằm tuyến = • Độ ổn định ( ) , = 1… (3.11) tuyến tham số xác định dựa m giá trị đo được thể gần băng thông tuyến thứ p Công thức xác định Phương trình (3.12), tử số giá trị độ lệch chuẩ n m băng thông đo trước T giây đường dẫn p, mẫu số tổng giá trị độ lệ ch chuẩn tất đường dẫn Giá trị biến thiên đoạn [0,1], lớn thể đường truyền không ổn định ( ) (3.12) = ( ) băng thơng đo đường dẫn p vị trí thứ i lưu hàng đợi cho tuyến từ máy khách Từ hai thông số trên, băng thông đại diện đến máy chủ phụ thuộc độ lớn lẫn độ ổn định xác định sau: (3.13) = (1 )× Cuối cùng, điều khiển chọn đường dẫn ổn định khả dụng Phương trình (3.14), tức tuyến lựa chọn tuyến có giá trị băng thơng đại diện lớn I số tuyến tối ưu chọn 91 = (3.14) ( Gọi thời gian tuyến cố định trước thời gian chuyển tuyến đi, tìm tuyến n số tuyến từ máy khách đến máy chủ Ta có chu kỳ định tuyến T xác định sau: = × (3.15) + Nếu có nhiều đường dẫn từ máy khách đến máy chủ, chế định tuyến định kỳ khoảng thời gian lớn để tính tốn xử lý điều khiển để chọn đường dẫn tối ưu Điều khắc phục cách tăng chu kỳ định tuyến T, nhiên giá trị băng thơng cách xa từ giá trị ảnh hưởng đến độ ổn định đường dẫn sử dụng Vậy để giải vấn đề nhằm giảm tải cho điều khiển, giải pháp đề xuất thuật toán định tuyến thích nghi MUNTH Thuật tốn 3.2 Thuật tốn thích ứng tốc độ bit đề xuất – MUNTH Input: , , , , , , Output: ) × { , } = (1 then If Yêu cầu định ến lại Else to : + If < (1 = 10 End if 11 End for 12 End if , × then )× Định tuyế n thích nghi – MUNTH Thuật toán MUNTH thực chế định tuyến lại băng thông mức tắc nghẽn, không đáp ứng nhu cầu dịch vụ streaming video Tại dịng Thuật tốn 3.2, máy khách gửi thông báo định tuyến lại tới điều khiển tốc độ tải xuống thấp ( ), với tốc độ ngưỡng gây tắc nghẽn Sau điều khiển chọn đường dẫn tối ưu có cao để phục vụ luồng Phương trình (3.16) Điều có ý nghĩa quan trọng việc giảm tải cho điều khiển phải thường xuyên định tuyến lại phương pháp định tuyến 92 theo chu kỳ Ngoài ra, MUNTH yêu cầu đổi đường dẫn từ máy chủ đến máy khách tốc độ tải thấp thiết thực so với phương pháp định kỳ, mà máy khách biế t rõ tình trạng điều kiện mạng nhận Những dòng thuật toán chế chọn mức chất lượng cho thỏa mãn điều kiện tốc độ bit trung bình phải nhỏ thơng lượng ước tính < (1 mức đệ m ước lượng phải )× lớn mức đệm ngưỡng lựa chọn tốt = ( (3.16) 3.5.3 Đánh giá hiệu 3.5.3.1 Thiết lập thí nghiệm kịch Sơ đồ mạng thí nghiệm để đánh giá giải pháp đề xuất Hình 3.6 Băng thơng mơ đường dẫn, nội dung video VBR thí nghiệm hồn tồn giống giải pháp phần 3.2 Phần ta đưa kịch thí nghiệm để đánh giá hiệu giải pháp đề xuất MUNTH so với cơng trình nghiên cứu liên quan tồn như: phương pháp Aggressive với đường dẫn mặc định viết tắt AGG_DF (Aggressive_Default), phương pháp SARA, BBA phương pháp Aggressive có định tuyến lại dựa kỹ thuật định tuyến định kỳ viết tắt AGG_RR (Aggressive_Rerouting) Kịch 1: Lự a chọn ngưỡng đệm t ốt • Thí nghiệm 1: Máy khách sử dụng thuật tốn thích ứng tốc độ bit đề xuất MUNTH với tham số BTh = 10s, 15s, 20s, 25s Bộ điều khiển thực việc định tuyến lại nhận yêu cầu máy khách (m=5) Kịch 2: So sánh hiệu • Thí nghiệm 2: Máy khách chạy thuậ t tốn thích ứng tốc độ bit Aggressive, phần mạng SDN, điều khiển kích hoạt trạng thái mặc định điều đồng nghĩa vớ i việc định tuyến máy khách máy chủ thực theo tiêu chuẩn đường có số bước nhảy theo thuật tốn Dijkstra • Thí nghiệm 3: Máy khách chạy thuật tốn thích ứng tốc độ bit SARA, phần mạng SDN thiế t lập hồn tồn giống thí nghiệm • Thí nghiệm 4: Máy khách chạy thuật tốn thích ứng tốc độ bit BBA, phần mạng SDN thiế t lập hồn tồn giống thí nghiệm • Thí nghiệm 5: Máy khách sử dụng thuật tốn thích ứng tốc độ bit Aggressive Việc định tuyến thực sau 20s theo thuật toán định tuyến định kỳ SDN 93 • Thí nghiệm 6: Máy khách sử dụng thuật tốn thích ứng tốc độ bit MUNTH với tham số = 20s lựa chọn qua Thí nghiệm Trong thí nghiệm điều khiển thực định tuyến lại lần có yêu cầu từ phía máy khách ( = 1000 ) Tham số an tồn µ thiết lập 0.1 tất thí nghiệ m 3.5.3.2 Lựa chọn ngưỡng đệm tốt Khi bắt đầu phiên streaming HAS, máy khách nạp vào đệ m lượng liệu định trước giải mã hiển thị liệu hình, giai đoạn nạp đệm ban đầu Sau đó, máy khách chuyển sang giai đoạn streaming ổn định (nhận hiển thị li ệu video đồng thời) Trong giai đoạn này, mức sử d ụng đệm đủ lớn, người dùng trải nghiệm video với chất lượng mượt mà bất chấp thông lượng mạng biến động mạnh Nếu mức sử dụng đệm thấp, khả gián đoạn video dễ xảy Đối với streaming trực tiếp, yêu cầu khắt khe độ trễ nên mức sử dụng đệm giới hạn, thường 10 giây [104] Đối với streaming video theo yêu cầu, mức sử dụng đệm không bị giới hạn Tuy nhiên, phiên streaming, người dùng dừng xem video lúc lượng lớn liệu đệm khơng sử dụng gây lãng phí tài nguyên mạng Do vậy, thực tế, kích thước đệm cho streaming theo yêu cầu VoD thường thiết lập từ 30 đến 50 giây [105], [106] Trong giải pháp đề xuất này, bốn giá trị 10s, 15s, 20s, 25s = 50 đưa để tiến hành thí nghiệm đánh giá kết Mụ c tiêu tìm ngưỡng đệm tốt để đưa đến định lựa chọn mức chất lượng video cho phù hợp để tránh tượng đóng băng video Từ Hình 3.19 đến Hình 3.22 thể kết thí nghiệm cho trường hợp ngưỡng đệm tương ứng Hình 3.19 Kết thí nghiệm cho phương pháp MUNTH ( = 10 ) 94 Hình 3.20 Kết thí nghiệm cho phương pháp MUNTH ( = 15 ) Hình 3.21 Kết thí nghiệm cho phương pháp MUNTH ( = 20 ) Hình 3.22 Kết thí nghiệm cho phương pháp MUNTH ( = 25 ) Trong q trình thí nghiệm thay đổi giá trị , rõ ràng với mức cao mức đệm phía máy khách thường xuyên trì mức cao tránh tượng đóng băng video q trình xem ngược lại Điều thể 95 rõ thí nghiệm tiến hành, chẳng hạn chọn mức đệm nhỏ với giá trị = 10 trình xem video bị đóng băng lần với tổng th ời gian dừng video 41.3s, điều ảnh hưởng lớn đến cảm nhận người xem Thêm vào việc đệm thường bị giữ mức thấp khiến máy khách khó thích ứng với trường hợp băng thông biến động mạnh Khi giá trị = 20 việc đóng băng q trình xem khơng cịn, vào phân đoạn 60-70, giá trị băng thơng biến động mạnh (Hình 3.21) máy khách u c ầu giá trị tốc độ bit cao mức đệm đủ để tải xuống hết phân đoạn video yêu cầu Tuy nhiên, mức cao, theo chế thích ứng tốc độ bit đề xuất máy khách khơng u cầu mức tốc độ bit cho chất lượng cao muốn đả m bảo mức đệm ổn định tránh bị đóng băng Điều thể rõ Bảng 3.3, ta thấy với = 25 có giá trị tốc độ bit trung 9575.02kpbs tỷ lệ ph ần trăm tốc độ bit ≥ 8000kbps 40.55% nhỏ tường hợp lại Tất kết Bảng 3.3 Hình 3.23 thể số thông số chất lượng thu thí nghiệm Dựa kết thực nghiệm cho thấy giá trị = 20s vừa đảm bảo người xem tr ải qua cảm giác khó chịu video bị đóng băng vừa có đượ c trải nghiệm xem tốt với mức chất lượng trung bình cao mức 10764.62kbps Thời gian dừng video 0, tỷ lệ phần trăm đệm ≤ 10s 1.83% (thấp so với ngưỡng đệm khác), tốc độ bit video tải ≥ 8000kbps 46.34% (cao tương đương với trường hợp =10s) Trong đạt giá trị đệm trung = 25s số lần giảm bình 31.45s gần với mức đệm 31.64s thí nghiệm mức chất lượng mức trung bình so với ngưỡng khác Bảng 3.3 So sánh giá trị B Th khác cho giải pháp MUNTH Tham số chất lượng Số lần dừng =10s =15s =20s =25s 2 Thời gian dừng (s) 43.1 38.9 21.45 Mức đệm ≤ 10s (%) 21.95 6.4 1.83 4.27 Mức đệm trung bình (s) 24.79 28.28 31.45 31.64 Tốc độ bit trung bình (kbps) 10613.64 10496.54 10764.62 9575.02 Tốc độ bit ≥ 8000kbps (%) 46.34 44.21 46.34 40.55 Số lần giảm mức chất lượng 42 33 39 44 96 Hình 3.23 Lựa chọn điểm tốt cho ngưỡng đệm = 20s cho Tóm lại, kết thí nghiệm cho thấy thuật tốn MUNTH đề xuất với phép máy khách lưu trữ đủ phân đoạn video đệm để tránh tượng đóng băng đạt chất lượng video tương đương so với ngưỡng đệm khác Vậy giá trị tốt cho ngưỡng đệm chọn cho giải pháp đề xuất = 20s 3.5.3.3 So sánh, đánh giá phương pháp Trong phần này, thuật toán MUNTH với = 20s đượ c so sánh với thuật toán khác liệt kê Kịch Hình 3.24 hiển thị chiếm dụng đệm cho phương pháp khác tương ứng Do thuật tốn AGG_DF khơng có chế để tránh biến động băng thơng mạnh nên phương pháp có nhiề u khoảng đệm bị cạn kiệt giai đoạn từ phân đoạn 50-100 200-250, tức kiện dừng xảy khoảng thời gian Bằng việc lựa chọn cách an toàn tốc độ bit mức chất lượng video mức đệm giai đoạn khởi động nhanh sử dụng tốc độ tải xuống phù hợp để tránh rơi vào bẫy đệm, kết giải pháp SARA cho thấy số lần đệm giảm sút so với AGG_DF Trong phương pháp BBA, mức đệm luôn mức nguy hiểm (15s) thuật tốn lựa chọn chất lượng video hàm chiếm dụng đệm hiệ n chọn tốc độ tối thiểu mức đệm nằm vùng thấp Mức đệm khởi đầu BBA đảm bảo cho việc tải phân đoạn có chất lượng thấp trước bị cạn kiệt nên phương pháp tránh kiện dừng video Cơ chế định tuyến định kỳ sử dụng thuật tốn thích ứng tốc độ Aggressive (AGG_RR) cho phép lựa chọn đường truyền phân đoạn đường dẫn tốt máy khách đạt luồng phát mượt mà so với AGG_DF Kết AGG_RR cho thấy khoảng thời gian t phân đoạn 50 đến 100 có kiện dừng xảy Giải pháp đề xuất MUNTH tránh thành công kiện bị dừng (0 97 lần) cách ước tính thơng lượng cách mượt mà lựa chọn tốc độ video phù Mức đệm (s) hợp để trì đệm đường dẫn tối ưu Phân đoạn Hình 3.24 Mức đệm tất phương pháp Tốc độ tải Thông lượng/Tốc độ bit (s) Tốc độ bit Phân đoạn (200-327) Hình 3.25 Tốc độ bit tốc độ tải phương pháp Hình 3.25 hiển thị tốc độ bit tốc độ tải xuống chọn năm phương pháp khác nhau, đường liền nét đường nét đứt tương ứng v ới tốc độ bit tốc độ tải xuống mức chất lượng lựa chọn Điều đáng ý từ Hình 3.25 MUNTH đạt mức chất lượng ổn định so với bốn phương pháp khác Từ phân đoạn 220 đến 327, MUNTH chọn mức chất lượng từ phân đoạn 280327 có biến động băng thơng cao BBA phương pháp dựa đệm, lựa chọn tốc độ bit không trực tiếp phụ thuộc vào điều kiện mạng, băng thơng 98 cao cho phép BBA yêu cầu mức tốc độ bit cao gia tăng mức chiếm dụng đệm Hai phương pháp Aggressive cho thấy biến động đáng kể mức chất lượng chế dựa thông lượng Với chế dựa thơng lượng đệm, SARA thích ứng tốt với biến động băng thông để đạt tốc độ bit ổn định Từ khía cạnh mạng, Hình 3.26 hiển thị Hàm phân phối tích lũy (CDF) tốc đ ộ tải xuống (Hình 3.26a) tốc độ bit (Hình 3.26b) suốt thời gian truyền video Với hình CDF tốc độ bit, ta thấy tỷ lệ phần trăm phân đoạn tải xuống tốc độ bit cao MUNTH lớn hết so với giải pháp cịn lại Cụ thể, khoảng 40% phân đoạn có tốc độ bit lớn 10000kbps Giá trị CDF cho AGG_DF, AGG_RR SARA cho kết thấp khoảng 20-25% số cho BBA cho kết thấp 10% Chúng ta thấy từ Hình 3.26b MUNTH AGG_RR cung cấ p tốc độ tải xuống cao so với thuật toán đường dẫn cố định Tỷ lệ phân đoạn tải xuống với tốc độ t ải xuống ≤ 5000kbps MUNTH AGG_RR vào khoảng 25% 40% Trong số AGG_DF, SARA BBA với đường dẫn cố định cao nhiều khoảng 60% Chính sách định tuyến thích ứng MUNTH cho phép khoảng 60% phân đoạn tải xuống với tố c độ tải xuống ≥ 10000kbps Trong khi, giá trị CDF cho thuật toán khác từ 20-35% Tốc độ bit (kbps) Tốc độ tải (kbps) Hình 3.26 Hàm phân phối tích lũy tốc độ bít (a) tốc độ tải (b) phương pháp Để giải thích rõ ràng hơn, Bảng 3.4 liệt kê số liệu cụ thể liên quan đến chất lượng video chất lượng trải QoE q trình thí nghiệm Vì AGG_DF sử dụng thuật tốn Aggressive đường dẫn cố định nên yêu cầu tốc độ bit cao thỏa mãn ràng buộc thông lượng mà liên quan đến mức đệm Từ bảng này, thấy AGG_DF có mức chất lượng trung bình so với phương pháp khác lại có tần suất đóng băng thời gian đóng băng cao SARA thuật tốn hốn hợp dựa thơng lượng đệ m 99 làm giảm kiện dừng video so với AGG_DF lại có tốc độ bit trung bình thấp Phương pháp BBA tránh thành cơng kiện dừng, nhiên tốc độ bit trung bình BBA thấp mức 3754.68kbps Bằng cách sử dụng sách đị nh tuyến có đị nh kỳ T giây, AGG-RR có tốc độ bit cao AGG_DF giảm tượng đóng băng video cách lựa chọn đường dẫn ổn định Giải pháp đề xuất MUNTH cho thấy kết vượt trội so với phương pháp khác Thứ nhất, thống kê mức đệm cho thấy MUNTH tránh kiện bị dừng chiếm giữ tỷ lệ đệm cao (Mức đệm trung bình = 31.50s) Thứ hai, sách định tuyến thích ứng, MUNTH đạt mức tốc độ bit trung bình cao (10734.18kbps) so với phương khác Mức tăng khoảng 69.5%, 80.3%, 185.9%, 21.79% so với AGG_DF, SARA, BBA AGG_RR tương ứng Một tham số chất lượng khác số lần giảm mức chất lượng video, người dùng nhạy cảm với tham số này, đặc biệt với mức chất lượng có tốc độ bit giả m đột ngột Đối với tham số xem đề xuất MUNTH hạn chế so vớ i SARA BBA Mặc dù MUNTH có số lần giảm mức chất lượng lớn so v ới BBA SARA đạt hiệu cao hẵn MUNTH có độ phức tạp tính tốn nhiều điều khiển so với phương pháp AGG_RR Bảng 3.4 Các tham số đánh giá chất lượng giải pháp Các tham số chất lượng AGG_DF SARA BBA AGG_RR MUNTH Thời gian dừng (s) 125.11 75.32 81.3 Số lần đóng băng 26 13 Mức đệm trung bình (s) 29.27 17.61 32.55 35.24 31.50 Mức đệm ≤ 10s (%) 20.43 42.07 1.83 13.72 1.83 Tốc độ bit trung bình (kbps) 6331.33 5953.73 3754.68 8800.26 10734.18 Tốc độ bit ≥ 8000kbps (%) 25.91 25.91 9.76 31.71 46.34 Số lần giảm mức chất lượng 79 21 25 105 39 - - - 23 0.84 1.32 3.19 1.98 4.32 Số lần định tuyến lại N-QoE Theo mơ hình QoE mơ tả Phương trình (1.7) Bảng 1.2, Bảng 3.4 Hình 3.27 tính tốn kết cho số QoE cuối từ MUNTH so với giải pháp khác AGG_DF, SARA, BBA, AGG_RR Trong MUNTH thể đạt điểm QoE cao (tức MOS) số phương pháp khác Hình 3.27 hiển thị QoE dự 100 đốn suốt q trình streaming video QoE giải pháp tăng dần lên băng thơng bị biến đổi mạnh gây đóng băng video mức chất lượng phân đoạn bị thay đổi Trong phần cịn lại đoạn video, với sách l ựa chọn đường dẫ n động thuật tốn thích ứng tốc độ bit phù hợp, MUNTH khơng giữ ổn định cho số QoE cao so với giải pháp khác mà đạt trải nghiệ m tốt từ phân đoạn 251 đến đến hết đoaạn vdeo BBA với phương pháp chuyển đổi chất lượng Chất lượng trải nghiệm (QoE) theo bậc tránh trường hợp đóng băng video sau đạt hiệu suất tốt so với AGG_DF, SARA AGG_RR Phân đoạn Hình 3.27 Chỉ số QoE dự đoán tất phương pháp 3.6 Kết luận chương Trong chương này, luận án xây dựng kiến trúc với kết hợp phía máy khách phía mạng để nâng cao trải nghiệm QoE người dùng việc streaming video qua giao thức HTTP dựa mạng điều khiển phần mềm SDN Từ cấu trúc này, Chương đưa hai đề xuất: - Đề xuất thứ trình bày phương pháp cho việc streaming video VBR thích ứng tốc độ qua giao thức HTTP dựa mức đệm linh hoạt thơng lượng ước tính mượ t mà kết hợp với việc định tuyến đường dẫn định kỳ thích nghi dựa SDN Giải pháp đề xuất thực số kịch thí nghiệm để đánh giá hiệ u thuật toán thích ứng VBR có khơng có diện SDN Kết thí nghiệm phương pháp đề xuất, đặc biệt với SARM vượt trội hẳn so với phương pháp non-SDN hiệ n có cải thiện lên tới 200% tốc độ bit video 101 - Đề xuất thứ hai dựa cấu trúc đề xuất này, từ phía máy khách thuật tốn thích ứng tốc độ đặt tên MUNTH, sử dụng chế ước lượng thông lượng chế ước lượng mức đệm để lựa chọn mức chất lượng video phù hợp giúp máy khách tránh kiện cạn kiệt đệm để phải dẫn đến đóng băng video Từ phía mạng, để phát triển hai sách tuyến định kỳ định tuyến thích nghi đề xuất thứ nhất, luận án đưa hai tham số độ ổ n định băng thông dụng băng thông khả sử dụng cho việc lựa chọn đường dẫn tối ưu từ máy khách đến máy chủ Thuật tốn MUNTH thể tích cực máy khách, có khả chủ động yêu cầu đường dẫn đáp ứng tốt điều ki ện mạng cho phép Kết thí nghiệm cho thấy rằng, đề xuất giải pháp cải thiện 21% đến 185% tốc độ bit trung bình so với số phương pháp có đạt trải nghiệm QoE tốt hế t so với phương pháp sử dụng Internet truyền thống 102 CHƯƠNG GIẢI PHÁP PHÂN BỔ BĂNG THÔNG VÀ CẢI THIỆN QoE TRONG STREAMING VIDEO CHO ĐỒNG THỜI NHIỀU NGƯỜI DÙNG 4.1 Giới thiệu chương Trong chương này, luận án theo định hướng triển khai kiến trúc streaming video kết hợp kỹ thuật MPEG-DASH kiến trúc SDN để gi ải toán tối ưu tài nguyên nâng cao chất lượng mạng Bài toán cụ thể mà luận án đề cập tới chương toán giải vấn đề cân đối đảm bảo nâng cao chất lượng đường truyền cho nhiều người dùng, đồng thời thỏa thuận tài nguyên đa người dùng chia sẻ nguồn tài nguyên mạng chung liên kết thắt cổ chai (bottleneck) Trong giải pháp đề cập chương này, phía máy khách, giải pháp thực triển khai thuật tốn thích ứng tốc độ bit video dựa vào đệm thơng lượng trình bày chương trước để sử dụng hầu hết băng thơng có sẵn, l ựa chọn mức chất lượng video phù hợp cho máy khách tăng QoE cho người dùng Tại phía mạng, điều khiển SDN, giải pháp thiết lập chế quản lý luồng theo dõi, kiểm sốt tình trạng mạng nhằm đảm bảo tính công tránh tắc nghẽn mạng không đủ băng thông để phục vụ yêu cầu luồng đến Trên sở đó, điều khiển SDN đề xuất tích hợp với cấu trúc gọi mô đun Truyền phát đa phương tiện (MSMA - Media Streaming Multiple Access) nhằm giám sát mạng truyền tải, phát số lượng máy khách streaming cách liên tục đưa định chia sẻ băng thông hợp lý cho tất máy khách đồng thời truy cập Ngồi ra, cấu trúc đề xuất phân bổ lại băng thông từ chối yêu cầu dịch vụ đến không đủ nguồn tài nguyên ngăn chặn tắc nghẽn liên kết thắt cổ chai (bottleneck) 4.2 Các vấn đề liên quan ý tưởng xây dựng giải pháp Trong năm gần đây, streaming thích ứng HTTP ngày áp dụng vào nhiều ứng dụng phổ biến, nghiên cứu gi ải pháp tăng chất lượng trải nghiệm người dùng cho hệ thống gồm nhiều máy khách yêu cầu dịch vụ DASH tiến hành Hầu hết nghiên cứu hướng tới mục tiêu tăng chất lượng trải nghiệm người dùng với tối ưu khả đường truyền Hiện có ba hướng giải 103 tốn cho trường hợp nhiều máy khách đồ ng thời truy cập liên kết thắt cổ chai Nhóm nhà nhiên cứu đưa thuật toán để giải vấn đề chia sẻ dịch vụ truyền phát video phía người dùng (nghĩa áp dụng thuật tốn phía người chơi) [29], [31] [107] Trong [29], tác giả đề xu ất thuật tốn để i thiện tính cơng bằng, hiệu ổn định (được đặt tên FESTIVE Fairness, Efficiency and Stability in http-based adapTIVE) b ằng cách cung cấp số phương pháp cố g ắng đảm bảo đánh đổi yếu tố Có thể nói thuậ t tốn FESTIVE thuật tốn thích ứng tốc độ bit phía máy khách biết đến thiế t kế dành riêng cho kịch nhiều máy khách Các tác giả FESTIVE đề xuất mơ hình thích ứng nhằm cải thiệ n tính cơng bằng, hiệu độ ổn định cách đưa hệ thống phương pháp cố gắng để đả m bảo trade-off yếu tố Thuật toán FESTIVE bao gồm ba thành phần chính: lập lịch xác định thời điểm bắt đầu tải xuống phân đoạn, thuật toán ước tính thơng lượng dựa tấ t phân đoạn tải xuống trước chế chọn tốc độ bit phân đoạn Tuy nhiên, với thuật toán FESTIVE, độ ổn định hệ thống giảm đáng kể số lượng máy khách tăng mạnh môi trường mạng cạnh tranh, điều ước tính băng thơng q cao Các tác giả [31] đề xu ất thuật tốn thích ứng tốc độ cho dịch vụ HAS phía máy khách dựa nguyên tắc thăm dò điều chỉnh cách phù hợp tốc độ bit với tên gọi PANDA (Probe AND Adapt) Cơ chế "thăm dị thích ứng" giống ngun tắc tăng/giảm hệ số phụ tr ợ sử dụng TCP PANDA thuật tốn thích ứng tốc độ phía máy khách HAS thiết kế gần để mang lại độ ổn định cao khả đáp ứng nhanh với biến đổi băng thông nhiều máy khách HAS chạy mạng liên k ết thắt cổ chai Để ước lượng băng thông sẵn có, PANDA thăm dị mạng cách tăng thêm tốc độ gửi bước thích ứng giảm hệ số phụ trợ tắc nghẽn phát hiện, đồng thời điều chỉnh tốc độ bit video cho phù hợp Thuật tốn PANDA cho phép máy khách HAS phản ứng nhanh v ới biến động băng thông đạt ổn định tốt Tuy nhiên, PANDA phân phối băng thông sẵn có cho tấ t người chơi điều không tốt môi trường khơng đồng mà máy khách có đặc tính yêu cầu khác A Mansy cộng [107] thiết kế triển khai khung streaming VHS (VideoHomeShaper) để đánh giá hiệu suất điểm truy cập cuối mạng nhà Tính ổn định, hiệu sử dụng tính cơng giới thiệu để đánh giá QoE cho máy khách cạnh tranh nghiên cứu Nhìn chung, nghiên cứu chủ yếu tập trung vào thuật tốn thích ứng 104 tốc độ bit phân bổ băng thơng phía máy khách để cải thiện tham số ảnh hưởng đến QoE người dùng mà không tác động đến phía mạng Nhóm thứ hai phương pháp tập trung vào phía máy chủ Theo hướng này, thông thường máy chủ coi điểm kiểm soát chịu trách nhiệm phân phối quản lý truyề n video cho tất người dùng Trong [108], tác giả giới thiệu chế thích ứng phía máy chủ sử dụ ng kỹ thuật TCP để giới hạn tốc độ bit video S Akhshabi cộng [109] đề xu ất giải pháp định hình lưu lượng dựa máy chủ, điểm đáng ý giảm biến động với chi phí tổ n thất nhỏ việc sử dụng băng thông Tuy nhiên, vấn đề tắc nghẽn băng thơng thực tế quan sát phía mạng; đó, máy chủ khơng thể xử lý nhiều máy khách lúc Cuối nhóm giải pháp phía mạng, sử dụng vấn đề phân bổ băng thông hoạt động để đạt công QoE cho nhiều người dùng Đã có số đề xuất gần việc phân bổ băng thông hợp lý cho người chơi liên kết thắt cổ chai Dựa công nghệ SDN, tác giả [32] tập trung vào kỹ thuật định hình lưu lượng phân tích luồ ng video ABR (adaptive bitrate) chia sẻ tài nguyên kết nối tắc nghẽn Trong phương pháp này, tất luồng video chia sẻ nút cổ chai có thơng lượng tổng băng thông gán cho tất máy khách không vượt q băng thơng có sẵn Phương pháp cải thiện phần QoE người dùng việc truyền phát video tính cơng bằng, hiệu chất lượng khơng đề cập đến tính ổn định video Trong [110], tác giả xem xét việc chia sẻ băng thông liên kết thắt cổ chai Tuy nhiên, mơ hình chia sẻ mạng này, việc chia sẻ mạng tính tốn định kỳ, không dựa sở yêu cầu Georgopoulos cộng [33] đề xuất kiến trúc phân bổ băng thông công QoE dựa giao thức OpenFlow Hệ thống quản lý trạng thái tất trình phát video phân bổ động tài nguyên mạng để tối ưu hóa công cấp độ người dùng cho tất máy khách cạnh tranh môi trường chia sẻ Nghiên cứu tập trung vào thông số công QoE mà chưa đề cập thông số khác tính hiệu tính ổn định Trong [46] [97], Bentaleb cộng đề xuất kiến trúc quản lý luồng dựa SDN phân bổ tài nguyên động cho hệ thố ng HAS, nhằm mục đích mở rộ ng hệ thống cải thiện QoE cho máy khách Các tác giả [111] đề xuất giải pháp với hỗ trợ SDN, sử dụng chế quản lý mạng tập trung để củng cố sách nhằm cải thiện QoE người dùng Tuy nhiên, công việc không xem xét trường hợp thiế u tài nguyên mạng nên chưa tối ưu hóa số người dùng truy cập 105 Tóm lại, chế phân bổ băng thông động dựa SDN cho thấy hiệu suất cao việc cải thiện chất lượng video Tuy nhiên, cơng trình liên quan chủ yếu tập trung vào việ c phân bổ băng thông khả tối ưu liên kết c người dùng phía mạng mà khơng xem xét thích nghi tốc độ bit phía máy khách nên điều chỉnh để nhận chất lượ ng trải nghiệm mong muốn dựa điều kiện thực tế máy khách Đồng thời tương tác vòng điều khiển phía máy khách vịng điều khiển phía mạng hệ thống nhiều người dùng chia sẻ liên kết thắt cổ chai chưa khai thác tốt mạng SDN Trong ba hướng giả i trên, hướng xử lý phía người dùng phía máy chủ có hạn chế khơng có nhìn tồn cảnh mạng để hoạt động cách linh hoạt Tuy nhiên, vấn đề tồn hai hướng giải lại dễ dàng triển khai, đánh giá phía mạng Các phương pháp giải phía mạng đạt tối ưu sử dụng tài nguyên mạng lại có độ phức tạp cao, gây khó khăn để triển khai Từ vấn đề tồn tại, luậ n án đề xuất giải pháp phân bổ băng thông tập trung phía mạng dựa sở SDN kết hợp với thuật tốn thích ứng tốc độ bit máy khách nhằm tối ưu QoE ngườ i dùng 4.3 Kiến trúc phân bổ băng thông đề xuất dựa SDN cho nhiều người dùng đồng thời truy cập Bộ điều khiển SDN MSMA (3) Thuật tốn thích ứng SS LNo rth bo un dI nte rfa ce ace erf Int d n ou stb We (2) Máy khách HTTP Thuật tốn thích ứng (1) Bottleneck (4) Máy khách HTTP (5) Máy chủ HTTP Yêu cầu-Đáp ứng HTTP Hình 4.1 Kiến trúc đề xuất cho vấn đề bottleneck bước hoạt động sau: Trong kiến trúc đề xuấ t (Hình 4.1), vai trò thành phần hệ thống - Tại phía máy khách (Client HTTP): Đóng vai trị người sử dụng dịch vụ video, tích hợp thuật tốn thích nghi tốc độ bit để yêu cầu mức chất lượng phù hợp từ phía máy ch ủ 106 - Tại phía máy chủ (Server HTTP): Làm nhiệm vụ đẩy nội dung video đến máy khách tương ứng với tốc độ bit mà máy khách yêu cầ u Tại điều khiển SDN (SDN controller): Chịu trách nhiệm việc phân bổ băng thơng cơng thích ứng đến tất người dùng đồng thời truy cập Trên điều khiển SDN, mô đun MSMA triển khai cho việc phân bổ băng thơng cơng thích nghi Thuật tốn thích ứng tốc độ bit phía máy khách dựa vào đề xuất Thuật toán 2.2 (dành cho video CBR) đề xuất Thuật toán 3.2 (dành cho video VBR) máy khách tương ứng để tìm mức chất lượng video phù hợp cho người dùng Trong kiến trúc đề xuất, chuyển mạ ch OpenFlow gần với máy khách (Edge Switch) giao tiếp với điều khiển SDN thông qua hai giao diện: chuẩn giao diện theo hướng Bắc (Northbound) Openflow kết nối OFS với điều khiển SDN qua giao th ức SSL giao diện hướ ng Tây (Westbound) Nguyên lý hoạt động kiến trúc đề xuất chia thành hai giai đoạn sau: Giai đoạn 1: Truy vấn tốc độ bit phù hợp theo yêu cầu máy khách Bước (1): Mỗ i máy khách tính tốn tốc độ bit mong muốn theo thuật tốn thích ứng tốc độ bit triển khai tạ i máy khách Tiếp đến máy khách gửi yêu cầu truyền phát (tức tốc độ bit mong muốn) đến chuyển mạch OFS gần Bước (2): Yêu cầu streaming sau chuyển tiếp đến điều khiển SDN thông qua OFS theo nguyên lý sau: Bộ chuyển mạch OFS đóng gói tin yêu cầu vào bả n tin Packet-in gửi lên điều khiển Bản tin Packet- in có định dạng Hình 4.2 Trong đó: - Giá trị in_port thể cổng mà gói tin nhận OFS - Trường reason mang thông tin lý gói tin lại chuyển lên điều khiển Ví dụ trường hợp giải pháp đề xuất lý gói tin gửi lên khơng tồn Flow-entry phù hợp bảng Flow-table OFS - Trường data mang toàn liệu gói tin ban đầu (gói tin mang yêu cầu từ máy khách đến OFS) Khi đến điều khiể n, tin Packet-in tách lấy liệu c gói tin ban đầu, nằm đặc tính payload tin Packet-in Từ đó, điều khiển xác định đặc điểm gói tin gốc như: - Loại gói tin: gói tin IPv4, gói tin ARP – giao thức mạng dùng để tìm địa phần cứng (địa MAC) thiết bị từ địa IP - Địa IP đích đến nguồn gửi gói tin 107 - Địa MAC nguồ n gửi (và đích đến có) gói tin 32 bits header buffer_id total_len reason pad in_port in_port data Hình 4.2 Định dạng tin Packet-in [8] Trong trường hợp giải pháp đề xuất, gói tin nguồn gói tin dạng ARP (do phía máy khách chưa biết vị trí đích đến, tức máy chủ mạng); gói tin IP máy khách biết vị trí máy chủ mạng, chưa có Flow-entry tương ứng Flow-table OFS Bước (3): Bộ điều khiển thông qua giao diện Hướng Bắc (Northbound) kết nối với chuyển mạch OFS gần nhất, nắm thông tin khả liên kết card mạng chuyển mạch tính tốn giá trị băng thơng mới, sau gửi thông tin đến máy khách thông qua giao diện Hướng Tây (Westbound) Giai đoạn 2: Yêu cầu tốc độ bit truy vấn cuối đến máy chủ Sau nhận thông tin băng thông từ điều khiển SDN, máy khách hoạt động sau: Bước (4): Giả định có N máy khách hoạt động liên tục gửi yêu cầu (i=1 đến N) đến máy chủ ứng dụng thông qua kết nối mở Máy khách mới thứ (N+1) gửi yêu cầu định điều khiển SDN đến máy chủ ứng dụng ), máy Bước (5): Khi nhận yêu cầu tốc độ bit (tương ứng với chủ ứng dụng đẩy phân đoạn mức chất lượng video phù hợp đến tất máy khách streaming 4.4 Đề xuất giải pháp phân bổ băng thông công SDN (MSMA-0) Trong giải pháp này, lu ận án sử dụng thuật tốn thích ứng tốc độ bit Thuật tốn 2.2 để tích hợp vào khối thích nghi máy khách Việc phân chia băng thông công bằ ng cho tất máy khách truy cập vào liên kết thắt cổ chai 108 thực mô đun MSMA điều khiển SDN đặt tên cho giải pháp MSMA-0 Với mục tiêu phân chia băng thông công máy khách ngang hàng tối đa hóa số lượng máy khách yêu cầu phục vụ Vấn đề hình thành giải pháp đề xuất phía mạng SDN miêu tả sau: Giả sử có N máy khách chia sẻ băng thông nút thắt cổ chai có dung lượng C Ký hiệu , lượng băng thông cung cấp cho máy khách thứ i thời điểm t Chính sách phân phối băng thông hàm ánh xạ tốc độ bit yêu cầu máy khách đến băng thơng thực tế cấp cho máy khách , , = (4.1) , tốc độ bit mà máy khách thứ i yêu cầu thời điểm t Và tốc độ bit mà máy khách mong muốn có từ đầu Nhưng băng thông tương ứng với tốc độ bit thực tế mà máy khách thích nghi sau điều khiển SDN xem xét lại Trong trường hợp tài nguyên băng thông đủ, tất máy khách giống với Trong trường hợp thiếu tài nguyên mạng mộ t số có khác với Nếu mạng hoạt động điều kiện giao thức HTTP lý tưởng, máy khách phân bổ băng thông tương tự nhau, tức là: , = , , (4.2) Tuy nhiên, thực tế, mạng TCP khơng lý tưởng máy khách yêu cầu tốc độ bit lớn phân bổ nhiều băng thông Theo [112], [113], với mạng hoạt động theo giao thức HTTP không lý tưởng, sách phân chia băng thơng có đặc điể m sau: - Nếu ri = r j fi (r) = f j(r); (4.3) - Nếu ri > r j fi(r) > f j (r); (4.4) - ( )> 0, ( ) ; (4.5) 0; (4.6) < C, - f( ) hàm đồng với r giá trị f không phụ thuộc vào thứ tự máy khách ( ) Do thực tế yêu cầu thường không đến OFS lúc, nên cách tự nhiên ta nghĩ đến hướng giải theo yêu c ầu đến Mỗi có yêu cầu đế n, hệ 109 thống xử lý xem xét nên có chấp nhận u cầu hay khơng để đảm bảm không xảy tắc nghẽn băng thông nút thắt cổ chai Điều cần thiết không gây đóng băng cho tồn yêu cầu đáp ứng đường liên kết Như trình bày Chương 1, video cơng nghệ DASH mã hóa theo tham số lượng tử (QP) khác nhau, tương ứng với tốc độ bit khác nhau, chia nhỏ thành phân đoạn Trong giải pháp đề xuất này, giải pháp dựa sở để phân chia băng thông thành nhiều mức khác tương ứng v ới mức chất lượng video xác định mức băng thông tối thiểu cần đáp ứng cho máy khách để q trình streaming video khơng bị gián đoạn Giá trị băng thơng tối thiểu tương ứng với giá trị tốc độ bit trung bình video v ới mức mã hóa cao QP lớn tốc độ bit trung bình thấp Giá trị tốc độ bit trung bình thấp ký hiệu R0 Hình 4.3 thể lưu đồ thuật tốn mơ đun MSMA-0 triển khai hệ thống đề xuất Nguyên tắc làm việc thuật tốn mơ tả sau: Bắt đầu Yêu cầu đến BWi ≥ R0 T F Loại bỏ yêu cầu thứ (N+1) Gửi BWi đến (N+1) luồng streaming Tất máy khách thích nghi với BWi Máy chủ đẩy phiên chất lượng đến tất máy khách Kết thúc Hình 4.3 Lưu đồ thuật tốn MSMA-0 đề xuất 1) Giả định có N máy khách streaming thời điểm có yêu cầu luồng thứ (N+1) đến, mô đun MSMA-0 triển khai điều khiển SDN tính tốn lại băng thơng trung bình (i = ÷ N+1) phân phố i cho (N+1) luồng theo Phương trình (4.7) đây: 110 = 2) Sau đó, điều khiển so sánh (4.7) +1 với tốc độ bit tối thiểu chấp nhận đượ c định hành động cần thực Bộ điều khiển thực hai hành động sau tùy thuộc vào kết so sánh 3) Thứ nhất, điều khiển thêm luồng cho luồng đến gửi luồng phát ≥ cho tất , tức băng thông mà máy khách nhận phải cao tốc độ bit mức chất lượng thấp đủ để truyền phát mức chất lượng video Theo đó, máy chủ cung cấp lại mức chất lượng video với mức chất lượng tương ứng cho tất máy khách 4) Thứ hai, điều khiển từ chối phục vụ yêu cầu đến < , tức băng thông mà máy khách nhận không đủ để streaming mức chất lượng thấp c video 5) Tất máy khách streaming thích ứng với nhận từ điều khiển SDN yêu cầu máy chủ gửi đế n tốc độ bit mong muốn Cuối máy chủ đẩy mức chất lượng cho tất máy khách streaming Tương tự vậy, có người dùng yêu cầu ngắt kết nối đế n máy chủ, điều gửi thông tin đến cho tất người dùng khiển tính tốn lại băng thơng cịn lại Những người dùng dựa thuật tốn thích ứng tốc độ bit để tính tốn lại mức chất lượng phân đoạn gửi đến máy chủ Máy chủ cung cấp lại phân đoạn video tương ứng cho tất máy khách Đồng thời máy khách gửi yêu cầu ngắt kết nối, điều khiển thực xóa Flow-entry tương ứng máy khách để đảm bảo máy khách muốn kết nối lại quy trình xử lý lặp lại theo trình tự lưu đồ thuật tốn 4.5 Đề xuất giải pháp phân bổ băng thơng thích ứng SDN (MSMA-1) Trong phần giải pháp đề xuất kết hợp thuật tốn thích ứng tốc độ bit (Thuật tốn 3.2) phía máy khách với mô đun MSMA triển khai điều khiển SDN (Thuật toán 4.1) đặt tên MSMA-1 Giải pháp sử dụng thuật tốn thích ứng tố c độ thành cơng việc tránh tượng đóng băng video thể phần đánh giá Chương Mục tiêu MSMA1 cải thiện chất lượng trải nghiệm tất máy khách dịch vụ streaming cách cung cấp tốc độ bit thích ứng mà máy khách yêu cầu cố gắng tăng số lượng máy khách truy cập vào hệ thống với nguồn tài nguyên hạn chế 111 Tại phía mạng, giải pháp phân bổ băng thơng động cho tất máy khách đồng thời truy cập nhằm mục đích tối đa hóa số người dùng truy cập hệ thống tối thiểu hóa số người dùng yêu cầu giảm mức chất lượng để thỏa mãn QoE cho tất máy khách truy cập Sự hình thành giải pháp mơ tả sau: Giả sử hệ thống có N máy khách streaming qua giao thức HTTP nút thắt c ổ chai có tổng dung lượng đường truyền C (Mbps) Tại phía máy khách, người dùng thực thuật tốn thích nghi tốc độ theo thuật tốn thích nghi tốc độ bit đề xuất Mỗi tốc độ bit tương ứng với mức chất lượng tương ứng mức chất lượng video hệ thống DASH lưu trữ máy chủ Khi có người dùng thứ (N+1) truy nhập vào hệ thống, máy khách tính tốn u cầu mức chất lượng video theo thuật toán tương ứng với tốc độ bit rN+1 Trong trường hợp tổng tốc độ bit yêu cầu (N+1) máy khách tương ứng với băng thông cấp cho máy khách mà nhỏ C điều khiển chưa kích hoạt Dĩ nhiên tốc độ bit cho máy khách thứ (N+1) phải lớn tốc độ bit thấp bảng mức chất lượng (rN+1 ≥ R0) Nếu tổng tốc độ bit điều khiển SDN nơi tập trung thông tin (N+1) u cầu máy khách, tính tốn lại u cầu băng thơng cấp cho máy khách Bộ điều khiển SDN đề xuấ t giải pháp hoạt động theo hai tiêu chí sau: Bộ điều khiển cố gắng giữ ổn định tốc độ bit ri yêu cầu máy khách nhiều tốt với mục tiêu thỏa mãn QoE máy khách Lựa chọn máy khách chiếm giữ tốc độ bit yêu cầu cao để hy sinh băng thông cho yêu cầu đến, đánh đổi giá trị QoE bù lại chia sẻ băng thơng cho máy khách thứ (N+1) với mục tiêu phục vụ nhiều máy khách tốt Thông thường, giải pháp MSMA-0 trước, ta đem tổng băng thông C chia cho tất (N+1) máy khách (N+1) máy khách bị suy giảm chất lượng QoE khơng mong muốn Vì vậy, giải pháp đề xuất MSMA-1 này, điều khiển SDN chọn số máy khách mang hy sinh băng thông tốt Chi tiết đề xuất miêu tả Thuật tốn 4.1 giải thích sau: Giả sử r tập tốc độ bit ri N máy khách hoạt động r = {r 1, r2, …, rN} (4.8) Trước hết, xếp tốc độ bit ri yêu cầu máy khách hoạt động theo thứ tự giảm dần, sau lấy tốc độ bit yêu cầu máy khách mức băng thơng cao hy sinh (dịng Thuật tốn 4.1) Khi việc 112 phân chia lại băng thông cho thỏa mãn tốc độ bit máy khách mang hy sinh máy khách thứ (N+1) công thức (4.9) (4.10) = + = bit + (4.9) × (4.10) × tốc độ bit yêu cầu máy khách với băng thông cao sau điều khiển SDN tính tốn lại Và tốc độ phần băng thơng cịn lại sau trừ tổng băng thơng cần dành riêng cho máy khách không bị đem hy sinh mà giữ nguyên tốc độ bit (4.11) = với n số máy khách mang để chia sẻ băng thông cho dịch vụ Trong trường hợp tốc độ bit máy khách thứ (N+1) chưa đạt giá trị nhỏ (rN+1 < R ) tiếp tục lấy tốc độ bit cao thứ hai mang phân chia lại theo tỷ lệ cho ba máy khách Quá trình tiếp diễn tất (N+1) máy khách đề u thỏa mãn tốc độ bit ri ≥ R0 (i = ÷ N+1) Thuật tốn 4.1 Thuật tốn phân bổ băng thơng thích nghi (MSMA-1) Input: r, , C, Output: For × = = × End for If ( ) then = Break = < ( )min th 10 Reject client (N+1) 11 End if 12 End if 13 End for then 113 4.6 Thiết lập thí nghiệm kịch 4.6.1 Thiết lập thí nghiệm Video streaming từ máy chủ đến máy khách HTTP có hai loại: video có tốc độ bit khơng đổi CBR tốc độ bit biến thiên VBR Ngoài ra, lưu lượng truy cập từ máy khách đến thiết bị khác (như chuyển mạch OFS điều khiển SDN) kiểm sốt thơng tin u cầ u tốc độ bit để thích ứng với mức chất lượng cần thiết Sơ đồ mạng thí nghiệm để đo kiểm giải pháp đề xuất hiển thị Hình 4.4 Trong sơ đồ này, giải pháp đề xuất sử dụng năm máy tính để tiến hành thử nghiệm: máy chủ phương tiện, máy để mô mạng truyền phát bao gồm chuyển mạch OpenFlow điều khiển SDN - Floodlight ba máy khách streaming video Một máy khách triển khai máy tính thực máy cịn lại máy ảo VMWare Do nguồn tài nguyên thử nghiệm hạn chế, hệ thống thiết lập cho ba máy khách Trong tương lai, luận án cải thiện để mở rộng hệ thống Về phía mạng, bao gồm hai chuyển mạch OpenFlow kết nối chúng mô liên kết thắt cổ chai Một chuyển mạch kết nối với ba máy khách kết nối khác đến máy chủ đa phương tiện Đối với thí nghiệm này, hệ thống sử dụng cơng cụ Mininet [81] để tạo mạng ảo thực tế thành phần Bộ điều khiển SDN Máy khách HTTP MSMA Máy chủ HTTP Thuật tốn thích ứng Thuật tốn thích ứng OFS OFS Thuật tốn thích ứng Hình 4.4 Sơ đồ mạng sử dụng thí nghiệm Có nhiều loại video khác sử dụng mô đánh giá, tất chúng tập trung vào hai loại video có tốc độ bit biến đổi VBR video có tốc độ bit khơng đổi CBR Trong thí nghiệm này, đại diện cho video VBR phim ngắn có tên Elephants Dream [101] mô tả chi tiết Chương đại diện cho video CBR đoạn phim Destiny [114] Đoạn phim ngắn chia thành 340 phân đoạ n, phân đoạn có độ dài giây với 16 mức chất lượng tương ứng vớ i 16 tốc độ bit khác nhau: 50, 100, 250, 400, 600, 800, 1000, 1200, 1600, 2000, 3000, 4000, 6000, 8000, 12000, 16000 (kbps) 114 4.6.2 Các kị ch thí nghiệm Trong giải pháp giải pháp đề xuất đưa thí nghiệm để đánh giá hệ thống đề xuất với phương pháp đối sánh sau: • Thí nghiệm 1: Dung lượng liên kết C nút thắt cổ chai 10Mbps, 7Mbps 4Mbps Bộ điều khiển sử dụng thuật toán MSMA-0 Máy khách bắt đầu truyền phát 110 giây (55 phân đoạn cho video VBR 110 phân đoạn cho video CBR) Sau 110 giây máy khách máy khách b đầu streaming 110 giây theo cách tương tự với máy khách • Thí nghiệm 2: Dung lượng liên kết nút cổ chai 10Mbps, 7Mbps 4Mbps Bộ điều khiển sử dụng thuật toán MSMA-1 Máy khách 1, máy khách máy khách bắt đầu truyền phát 110 giây theo thứ tự • Thí nghiệm 3: Nút thắt cổ chai có dung lượng 10Mbps, 7Mbps 4Mbps Các thuật toán Aggressive, SARA, BBA PANDA tiế n hành Thuật tốn MSMA khơng kích hoạt Các client yêu cầu truyền video VBR CBR theo thứ tự: máy khách máy khách máy khách 3, u cầu cách 110 giây • Thí nghiệm 4: Nút thắt cổ chai có dung lượng C = 500kbps Bộ điều khiển SDN chạy thuật toán MSMA-0 Các máy khách u cầu streaming video VBR • Thí nghiệm 5: Nút thắt cổ chai có dung lượng C = 500kbps Bộ điều khiển SDN khơng chạy thuật tốn MSMA-0 Các máy khách yêu cầu streaming video VBR Thuật tốn thích ứng t ốc độ bit thiết lập với biên an tồn µ 0.2 Mỗi thí nghiệm lặp lại lần lấy kết trung bình Trong thí nghiệm trên, ba thí nghiệm nhằm đánh giá tính cân bằng, ổn định chất lượng video máy khách chia sẻ tài nguyên mạng liên k ết thắt cổ chai Thí nghiệm nhằm kiểm tra hoạt động thuật toán MSMA-0 băng thơng có sẵn khơng đủ đáp ứng tất c ả u cầu đến Với thí nghiệm 4, = 354kbps tốc độ bít tương ứng với mức chất lượng thấp nên điều khiển chấp nhận yêu cầu kết nối máy khách thứ nhất, máy khách truyền video với t ốc độ bit trung bình nhỏ với số lần đóng băng video lần phân đoạn có mức tốc độ bit cao so v ới trung bình Theo thuật tốn đề xuất, u cầu từ máy khách máy khách không chấp nhận để cung cấp dịch vụ Với thí nghiệm 5, điều khiển khơng chạy thuật tốn MSMA0 ba yêu cầu từ ba máy khách chấp nhận Cả ba máy khách tham gia chia sẻ băng thơng, mức băng thơng sẵn có khơng đủ để cung cấp cho ba nên tất máy khách đề u bị đóng băng sau 115 kết nối Điều cho thấy trường hợp băng thơng thấp nhất, giải pháp đề xuất phục vụ số lượng máy khách cách hạn chế, thay phương pháp khác khơng có người dùng phụ c vụ 4.7 Đánh giá kết thảo luận Vấn đề thích nghi tốc độ bit phân bổ băng thông động giải pháp đề xuất chương nhằm cải thiện QoE người dùng khơng ngồi ba mục tiêu sau: - - Tính hiệu quả: Tất người dùng video tham gia vào hệ thống lựa chọn cho mức chất lượng video cao t ốt Tính cơng bằng: Khi có nhiều máy khách lúc truy cập vào liên kết thắt cổ chai tất phải phân chia nguồn tài ngun mạng sẵn có cách cơng Tính ổn định: Tức máy khách nên tránh trường hợp dừng video hay chuyển mức chất lượng không cần thiết, điều làm ảnh hưởng xấu đến chất lượng trải nghiệm người dùng Nhằm đánh giá hiệu giải pháp đề xuất, dựa vào [115] [29], tác giả sử dụng ba thơng số tính cơng bằng, hiệu ổn định để so sánh Và từ tham số chất lượng video, rút chất lượng trải nghiệm QoE người dùng cho tất phương pháp 4.7.1 Tham số công (fairness), hiệu (efficiency) ổn định (stability) Trong mạng chia sẻ nguồn tài nguyên, số người dùng thấy tốc độ bit cho video thấp người dùng khác lại thấy chất lượng cao Vấn đề ln ln xảy cho nhóm người dùng chia sẻ băng thông Internet Akhshabi cộng [29] sử dụng khác biệt tốc độ bit cho hai người dùng để tính tốn không công người dùng với Gọi số cơng tính theo tốc độ bit cho tất người dùng sau: | = , | , số cơng , (4.12) tốc độ bit video cung cấp cho máy khách thứ i thời điểm t Chỉ nằm khoảng từ đến 1, số gần hệ thống 116 Tham số hiệu sử dụng phân phối băng thông tính cơng thức (4.13), C băng thông khả dụng c kết nối chia sẻ Chỉ số gần trình sử dụng hệ thống hiệu | = , | (4.13) Đối với tham số ổn định , nghiên cứu cho thấy người dùng nhạy cảm với chuyển mức chất lượng hay tốc độ bít cách thường xuyên đáng kể [116] Theo [29], tính ổn định cho người dùng thứ i thời điểm t định nghĩa Phương trình (4.14), ( ) = hàm trọng số quan sát vòng k giây cuối chọn 20s (tức 10 phân đoạn với video VBR 20 phân đoạn với video CBR) tiến đến hệ thống ổn định =1 | , | ( ) ( ) , , (4.14) 4.7.2 Đánh giá hiệu Trong phần giải pháp so sánh hai phương đề xuất MSMA-0 MSMA-1 v ới phương pháp có PANDA, BBA, SARA Aggressive ( viết tắt AGG) Tốc độ tải xuống, mức đệm tốc độ bit trung bình (Avg.Bitrate) tương ứng với mức chất lượng lựa chọn tất phương pháp hiển thị Hình 4.5 (với video VBR) Hình 4.6 (với video CBR) Khi tiến hành thử nghiệm nhiều lần cho trường hợp 4Mbps, 7Mbps 10Mbps, kết cho thấy hành vi tương tự hiệu suất phương pháp tốc độ tải xuống mức chất lượng, kết lấy trường hợp 4Mbps làm đại diện cho đánh giá Như Hình 4.5, thấy trường hợp sử dụng điều khiển SDN với thuật toán MSMA-0, chất lượng video máy khách ổn định hầu hết toàn phiên streaming video so với phương pháp khác Đặc biệt từ phân đoạn 90 trở video ổn định tuyệt đối có mức chất lượng Điều ưu điểm chế thích nghi tốc độ đề xuất Thuật toán 2.2 Trong thuật toán sử dụng thơng lượng ước tính thơng lượng trước với ngưỡng đệm linh hoạt để thích ứng tốc độ bit Tuy nhiên giải pháp có tốc độ bit trung bình thấp nhiều so với giải pháp đề xuấ t MSMA-1 Còn phương pháp tồn khác có mức chất lượng video trung bình tương đối tương tự Đối với MSMA-1 BBA, có chế ước lượng trước mức đệm nên không để xảy trường hợp đệ m cạn kiệt Điều có nghĩa video khơng bị đóng băng Đối v ới phương pháp khác video gần bị dừng số lần Giải pháp MSMA-0 có mức đệm bị giảm xuống phân đoạn từ 68-78 Trong 117 PANDA, video bị gián đoạn từ phân đoạn 60 đến phân đoạn 78 Trong SARA, mức đệm trung bình thấp có hai lần gián đoạn video, khoảng phân đoạn 110 từ phân đoạn 174 đến 198 Trong phương pháp AGG, chất lượng video dao động liên tục bị dừng từ phân đoạn 66 đến 78 Kết thí nghiệ m cho video CBR (Hình 4.6) cho thấy giải pháp đề xuất hi ệu phương pháp đối sánh Như hình vẽ ta thấy, MSMA-1 MSMA-0 có mức chất lượng bằ ng phẳng nhiều Với video CBR mã hóa với nhiều mức chất lượng video VBR nên khơng phù hợp với thuật tốn SARA làm cho tốc độ bit trung bình biến động đột ngột (a) MSMA-1 (b) MSMA-0 (c) PANDA (d) BBA (e) SARA (f) AGG Hình 4.5 Tốc độ tải, m ức đệm tốc độ bit trung bình tất phương pháp liên kết thắt cổ chai với 4Mbps trường hợp video VBR Tóm lại, với trường hợp điều khiển SDN sử dụng thuật toán MSMA, mức chất lượng video máy khách ổn định thời gian khơng có u cầu kết nối 118 tới Ngược lại trường hợp điều khiển khơng sử dụng thuật tốn MSMA, trường hợp non-SDN mức chất lượng video máy khách biến động liên tục Tình trạng máy khách trường hợp tải video CBR ổn định so với tải video VBR kích thước phân đoạn video CBR đồng phân đoạn video VBR biến động khó lường trước (a) MSMA-1 (b) MSMA-0 (c) PANDA (d) BBA A đệm tốc độ bit trung bình t(f) Hình 4.6 Tốc độ(tả)i,SA m ức ất cAGG ả phương pháp liên kết thắt cổ chai với 4Mbps trường hợp video CBR Để đánh giá tham số hiệu năng, giải pháp lựa chọn thời điểm mà tất máy khách bắt đầu streaming lúc Lượng thời gian mà kết thực để đánh giá 20 giây (10 phân đoạn) Hình 4.7 so sánh hiệu suấ t giải pháp đề xuất (MSMA-0 MSMA-1) v ới PANDA, BBA, SARA AGG ba tham số đánh tính cơng bằng, hiệu ổn định Để đánh giá xác hơn, 119 Hình 4.7 này, giải pháp lấy trung bình cho ba trường h ợp có dung lượng liên kết 4Mbps, 7Mbps 10Mbps Giá trị trung bình đặt ba lần chạy cho ba người chơi thời gian thực Từ kết thí nghiệm ta thấy rằng, giá trị tính cơng bằng, hiệu qu ả tính ổn định thu phương pháp có thấp nhiều so với giá trị thu sử dụng giải pháp đề xuất Việc so sánh độ ổn định trung bình ba máy khách tất phương pháp minh họa Hình 4.7c Chúng ta thấy ổn định phương pháp đề xuất tốt so với phương pháp khác (a) Fairness (b) Efficiency (c) Stability Hình 4.7 So sánh tính cơng (a), hiệu qu ả (b) ổn định (c) tất phương pháp Tuy nhiên, chế thích ứng t ốc độ dựa cảm nhận phân đoạn SARA, Hình 4.6a, cơng phân đoạn từ đến 7, SARA hoạt động tốt tất chế khác Phương pháp không sử dụng băng thơng đường dẫn ước tính chiếm dụng đệm mà cịn kích thước phân đoạn để dự đoán thời gian cần thiết để tải xuống phân đoạn Do điều đảm bảo công tất máy khách khoảng Sử dụng giải pháp streaming có PANDA, BBA, SARA AGG, tính cơng trường hợp thay đổi từ 0.634 đế n 0.860 có giá trị trung bình 0.699, 0.723, 0.77 0.687 Trong thí nghiệm, với việc sử dụng kiến trúc đề xuất, số công MSMA-1 cải 120 Bảng 4.1 So sánh hiệu phương pháp với video VBR Thông số Fairness MSMA -1 MSMA-0 PANDA BBA SARA AGG 0.816 0.785 0.699 0.723 0.775 0.687 Efficiency 0.830 0.781 0.654 0.655 0.602 0.604 Stability 0.962 0.977 0.911 0.920 0.723 0.675 Bảng 4.2 So sánh hiệu phương pháp với video CBR Thông số Fairness MSMA -1 MSMA-0 PANDA BBA SARA AGG 0.971 0.965 0.764 0.713 0.716 0.873 Efficiency 0.879 0.796 0.904 0.665 0.726 0.708 Stability 0.975 0.957 0.931 0.949 0.826 0.703 thiện cách đáng kể Đặc biệt, giá trị nằm khoảng từ 0.791 đến 0.863 có trung bình 0.816 cao hết Hiệu việc phân bổ băng thông phương pháp đối sánh cho hiệu thấp Giá trị từ 0.488 đến 0.761 có trung bình 0.654, 0.655, 0.602 0.604 Các giá trị tham số hiệu sử dụng với MSMA-1 thay đổi từ 0.716 đến 0.970 có trung bình 0.830 Nhìn chung việc đánh giá phương pháp ln có đánh đổi gi ữa ba tham số Có phương pháp với tính cơng tốt lại hiệu sử dụng băng thông lại thấp ngược lại Chẳng hạn SARA cơng so với phương pháp khác đoạn từ 4-7 lại không hiệu đoạn Bảng 4.1 Bảng 4.2 cho kết ba tham số công bằng, hiệu ổn định phương pháp đề xuất với phương pháp đối sánh Kết liệu đo đạt lúc tất máy khách đồng thời truy cập lấy khoảng 20 giây (10 phân đoạn) cho video VBR 20 giây (20 phân đoạn) cho video CBR Đối với video VBR Bảng 4.1, kết liệt kê tóm tắt theo tỷ lệ phần trăm củ a MSMA-1 so sánh với phương pháp MSMA-0, PANDA, BBA, SARA AGG cách tương ứng sau: 1) MSMA-1 vượt trội so với giải pháp liệt kê mức độ công tăng 3.9%, 16.7%, 12.9%, 5.3% 18.8% 2) MSMA-1 cải thiện việc sử dụng băng thông hiệu 3.3%, 26.9%, 26.7%, 37.8% 37.4% 3) MSMA-1 tăng độ ổn định video lên -1.5%, 5.6%, 4.6%, 33.1% 42.5% 121 Bảng 4.3 Thống kê tham số chất lượng QoE phương pháp Các tham số chất lượng MSMA-1 MSMA-0 PANDA BBA SARA AGG 2445.6 1199.6 1389.5 44.6 35.8 34.2 27.7 11.6 36.4 Số lần video dừng 12 17 11 Chỉ số mức chất lượng trung bình 4.5 5.1 5.2 Số lần giảm mức chất lượng 21 17 20 40 N-QoE 4.1 3.6 3.5 3.6 2.9 2.7 Tốc độ bit trung bình (kbps) Mức đệm trung bình (s) 1788.7 1717.4 1461.0 MSMA-1 cải thiện hai tham số tính cơng hiệu so với MSMA-0 MSMA-0 lại có độ ổn định tốt MSMA-1 máy khách MSNA-1 tự điều chỉnh tốc độ bit chúng dựa thông lượng Và thơng lượng khơng đáp ứng u cầu máy khách gửi yêu cầu đến điều khiển SDN Sau điều khiển SDN chịu trách nhiệm việc phân bổ lại băng thông cho máy khách truy cập thơng qua nút để máy khách u cầu nhận băng thơng giữ đượ c mức chất lượng video phù hợp Đối với MSMA-0, sử dụng thuật tốn thích ứng tố c độ với chế ước tính thơng lượng Aressive dựa băng thông chia từ điều khiển nên ổn định việc chọn mức chất lượng video Đối với video CBR, ta so sánh cách tương tự Bảng 4.2, ta thấy hai giải pháp đề xuất MSMA-1 MSMA-0 cho kết vượt trội so với phương pháp lại Mặc khác, so với tải video VBR tải video CBR có tham số Stability ổn định Bảng 4.3 số liệu thống kê tham số chất lượng từ thí nghiệm Như hiển thị bảng, giải pháp đề xuất MSMA-1 nhận kết vượt trội so với phương pháp khác Đầu tiên, với chế ước lượng thông lượng dựa đệm hợp lý, MSMA-1 tránh kiện dừng video giữ tỷ lệ chiếm dụng đệm trung bình cao (44.6s) Thứ hai, thuật tốn phân bổ băng thơng động, MSMA-1 đạt tốc độ bit trung bình cao mức 2445.6kbps - nâng cao lên khoảng 103.8%, 76%, 36.7%, 42.4% 67.3% so với MSMA- 0, PANDA, BBA, SARA AGG cách tương ứng Theo cơng thức tính QoE đưa Phương trình (1.7) Bảng 1.2, cuối giải pháp đề xu ất tính tốn số N-QoE thu từ MSMA-1 MSMA-0 so với bốn giải pháp khác PANDA, BBA, SARA, AGG Bảng 4.3 Từ bảng 122 cho thấy giải pháp đề xuất đạt điểm N-QoE cao (tức MOS) số giải pháp tồn Đối với thuật toán AGG, cách yêu cầu tốc độ bit cao theo thông lượng mà không phụ thuộc vào đệm tại, chất lượng video trung bình thấp số lần giảm mức chất lượng lớn số tất phương pháp Mặt khác, AGG có QoE thấp (chỉ 2.7) SARA thuật tốn thích nghi dựa đệm thơng lượng, có chất lượng video trung bình QoE cao AGG, mức trung bình so với thuật tốn khác Cịn BBA thuật toán dựa đệm đạt mức tương đối, nhiên BBA tránh thành công kiện dừng video yếu tố gây khó chịu cho người xem Tốc độ bit trung bình BBA mức trung bình 1788.7kbps QoE mức tốt (3.6) Bằng cách ước tính băng thơng sẵn có, PANDA lợi dụng chế thăm dò để tăng nhẹ giảm mạnh tốc độ gửi trường hợp tắc nghẽn PANDA có tốc độ bit trung bình mức 1389.5kbps số lần giảm mức chất lượng tương đối thấp (7 lần) Chỉ số QoE củ a PANDA đạt điểm số tốt 3.5 Đối với thuật toán đề xuất MSMA-0, tốc độ bit trung bình thấp mô đun MSMA điều ển tập trung thực sách phân chia băng thơng cơng cho tất máy khách Tuy nhiên, MSMA-0 có số l ần giảm mức chất lượng thấp có lần suốt đoạn phát video Bên cạnh đó, QoE MSMA-0 đạt đượt chất lượng tốt tương đương với BBA (tức điểm 3.6) Có thể nói rằng, thật khó để cải thiện cho tất tham số chất lượng dịch vụ (QoS) tham số liên quan đến chất lượng trải nghiệm (QoE) streaming video Trên thực tế, tất giải pháp đề xuất cần có đánh đổi tham số để cải thiện chất lượng streaming video Tuy nhiên, giải pháp đề xuất MSMA-0 MSMA-1 cải thiện cách đáng kể chất lượng video trung bình, đảm bảo QoE trung bình cao so với phương pháp có Đặc biệt, MSMA-1 tăng điểm số QoE 14%, 17%, 14%, 41% 52% so v ới MSMA-0, PANDA, BBA, SARA AGG cách tương ứng 4.8 Kết luận chương Trong chương này, luận án đề xuất giải pháp streaming thích ứng cho nhiều máy khách đồng thời truy cập liên kết thắt cổ chai Đó kết hợp thuật tốn thích ứng tốc độ bit phía máy khách phân bổ tài nguyên dựa điều khiển SDN tập trung để giải vấn đề Kết thí nghiệm cho thấy, giải pháp đề xuất cung cấp chất lượng trải nghiệm QoE vượt trội so với phương pháp tồn tạ i Kiến trúc đề xuất bao gồm thích ứng tốc độ bit phía máy khách trình quản lý luồng SDN để đảm bảo tính cơng bằng, hiệu ổn định băng 123 thơng Cơ chế thích ứng tốc độ yêu cầu cách mượt mà mức chất lượng video không vượt băng thông mạng cung cấ p Bộ điều khiển SDN tích hợp vớ i mô đun MSMA giám sát nguồn tài nguyên mạng, nắm bắt số lượng máy khách streaming cách liên tục để phân phối băng thông công cho máy khách (MSMA-0) Một đóng góp chương giải pháp đề xuất MSMA-1, điều khiển SDN phân bổ băng thơng thích ứng nhằm tối đa hóa số người dùng truy cập đảm bảo QoE cho nhiều máy khách tốt Ngoài ra, phương pháp từ chối dịch vụ yêu cầu đến không đủ băng thông ngăn chặn tắc nghẽn cách kịp thời Hạn chế chương tiến hành thực nghiệm với cấu hình thấp, phía máy khách có thí nghiệm cho ba người dùng Tuy nhiên, việc thực nghiệm cấu hình cao việc tăng khả mở rộng hệ thống Phương pháp đề xuất chương áp dụng cho hệ thống thực tế hay lớn tăng tuyến tính tốc độ xử lý máy chủ không bị tăng độ phức tạp tính tốn 124 KẾT LUẬN Nội dung luận án tập trung nghiên cứu kỹ thu ật streaming video thông qua hai công nghệ HAS SDN Phân tích chi tiết yếu tố tác động đến QoE xây dựng mơ hình đánh giá dựa cơng trình khoa học trước Luận án đề xuất giải pháp thích ứng chất lượng video ngữ cảnh quan trọng đầy thách thức streaming video qua giao thức HTTP dựa mạng điều khiển phần mềm SDN Luận án đạt số kết nghiên cứu định đề xuất số hướng nghiên cứu tương lai, tóm tắt sau: Một số kết đạt luận án - Luận án xây dựng hệ thống việc streaming video kết hợp hai kỹ thuật HAS SDN Trên lớp ứng dụ ng mà cụ thể phía máy khách, luận án đề xuất thuật tốn thích ứng tốc độ bit dựa thơng lượng ước tính đệm để định mức chất lượng video phù hợp tải Tại phía mạng, thiết kế kiến trúc cho điều khiển SDN để phân bổ băng thông định tuyến đường dẫn t ối ưu - Đề xuất thực giải pháp sử dụng kỹ thuật định tuyến theo u cầu từ phía máy khách dựa vào băng thơng khả d ụng đồ hình mạng để tìm đường dẫn tối ưu với thuật tốn thích ứng tốc độ nhằm nâng cao chất lượng streaming video dạng CBR Kết đánh giá thể Chương - Đề xuất thực giải pháp thích ứng chất lượng để cải thiện QoE streaming video dạng VBR qua giao thức HTTP dựa kỹ thuật định tuyến SDN Hai kỹ thuật định tuyến đề xuất định tuyến định kỳ định tuyến thích nghi tích hợp điều khiển SDN để lựa chọn đường dẫn tối ưu từ máy chủ đến máy khách Thuật tốn thích ứng tốc độ đề xuất khơng đối phó với biến độ ng mạnh thơng lượng mạng mà cịn thích ứng với biến động mạnh tốc độ bit video VBR, tránh tượng tràn trống đệm Mô hình QoE đánh giá giải pháp đề xuất cải thiện cách đáng kể chất lượng trải nghiệm người dùng so với phương pháp tồn Kết nghiên cứu thể Chương luận án - Đề xuất thực giải pháp phân bổ băng thông cải thiện QoE cho nhiều người dùng đồ ng thời truy cập qua đường truyền có băng thơng hạn chế, thể qua Chương luận án Trong giải pháp này, mô đun chức MSMA đề xuất điều khiển SDN chịu trách nhiệm phân bổ băng thông công thích nghi cho tất người dùng đồng thời truy cập Mô đun MSMA SDN với thuật tốn thích ứng tốc độ tích hợp máy khách nhằ m lựa chọn mức chất lượng video phù hợp đả m bảo tính cơng bằng, hiệu sử dụng băng thông ổn định cho tất người dùng đồng thời streaming video liên kết tắc nghẽn 125 Hướng phát triển luận án Do giới hạn điều kiện triển khai, thực mô nghiên cứu với số mơ hình phức tạp mà luận án chưa thực đượ c Vậy để tiếp tục phát triển kết mà luận án đạt được, giải vấn đề hạn chế, mở rộng phạm vi nghiên cứu, hướng luận án đề xuất sau: - Mở rộng kiến trúc hệ thống, xây dựng nhiều điều khiển SDN/OpenFlow để quản lý giám sát mơi trường mạng diện rộng Tích hợp giải thuật định tốc độ bit, phân bổ băng thơng mơ hình ước lượng QoE tối ưu sử dụng kỹ thuật Reinforcement Learning cho điều khiển SDN - Xây dựng mơ hình thích ứng chất lượng cho nhiều máy khách có nhiều đặc tính khác Thực sách định tuyến theo nhiều tham số ràng buột khác - Tiếp tục đề xuất giải pháp cải thiện QoE việc triển khai công nghệ thực tế ảo VR, video 360 độ video Live Streaming qua giao thức HTTP SDN 126 DANH MỤC CÁC CƠNG TRÌNH ĐÃ CƠNG BỐ CỦA LUẬN ÁN A Các cơng trình cơng bố kết trự c tiếp luận án [C1] Hong Thinh Pham, Duc An Nguyen, Nguyen Thoa, Huong Truong Thu, & Ngoc Nam Pham (2017), “Adaptation method for streaming of CBR video over HTTP based on software defined networking”, International Conference on Advanced Technologies for Communications (ATC), IEEE, pp 16-20 [J1] Pham Hong Thinh, Nguyen Duc An, Tran Duc Tan, Truong Thu Huong, Pham Ngoc Nam (2018), “SDN-based Adaptive Routing for Video Streaming over HTTP”, Journal of Science & Technology, No 131, pp 69-75 [J2] Pham Hong Thinh, Pham Ngoc Nam, Nguyen Huu Thanh, Alan Marshall, Truong Thu Huong (2019), “A Hybrid of Adaptation and Dynamic Routing based on SDN for Improving QoE in HTTP Adaptive VBR Video Streaming”, IJCSNS International Journal of Computer Science and Network Security (ESCI), Vol 19, Issue 7, pp 51-64 [C2].Thinh Pham Hong, Dat Nguyen Thanh, Nam Pham Ngoc, Thanh Nguyen Huu, & Huong Truong Thu (2019), “QoE-Aware Video Streaming over HTTP and Software Defined Networking”, In International Conference on Industrial Networks and Intelligent Systems Springer, Cham pp 40-52 [C3] Pham Hong Thinh, Pham Ngoc Nam, Nguyen Huu Thanh, Truong Thu Huong (2019), “SDN–based Dynamic Bandwidth Allocation for Multiple Video-onDemand Players over HTTP”, International Conference on Information and Communication Technology Convergence (ICTC), IEEE, pp 163-168 [J3] Pham Hong Thinh, Nguyen Thanh Dat, Pham Ngoc Nam, Nguyen Huu Thanh, Nguyen Minh Hien & Truong Thu Huong (2020), “ An Efficient QoE-Aware HTTP Adaptive Streaming over Software Defined Networking”, Journal of Mobile Networks and Applications, Springer (SCIE), pp 1-13 B Các cơng trình cơng bố có liên quan đến luận án [J4] Nguyen Thi Kim Thoa, Nguyen Minh, Nguyen Hai Dang, Pham Hong Thinh, Pham Ngoc Nam (2017), “Adaptation method for streaming of VBR video over HTTP/2”, Journal of Science & Technology, No 120, pp 128-133 [J5] Nguyen Thi Kim Thoa, Pham Hong Thinh, Pham Ngoc Nam (2018), “QoE Optimization Based on Quality-delay Trade-off Model for Adaptive Streaming with Multiple VBR Videos”, Journal of Science & Technology, No 131, pp 5561 127 TÀI LIỆU THAM KHẢO [1] Cisco, “Cisco Visual Networking Index: Forecast and Trends, 2017–2022’, White Paper, Cisco Forecast and Methodology [2] “DIGITAL 2019: GLOBAL INTERNET USE ACCELERATES.” https://wearesocial.com/blog/2019/01/digital-2019-global-internet-use-accelerates (accessed Jun 06, 2020) [3] “Immersive VR and 360 video at streamable bitrates: Are you crazy?” https://blog.beamr.com/2016/10/28/immersive-vr-and-360-video-at-streamablebitrates-are-you-crazy/ (accessed Jun 06, 2020) [4] A Begen, T Akgul, and M Baugher (2011), “Watching video over the web: Part 1: Streaming protocols”, IEEE Internet Comput., vol 15, no 2, pp 54–63 [5] T C Truong, D Q Ho, J W Kang, A T Pham, and S Member (2012), “Adaptive Streaming of Audiovisual Content using MPEG DASH”, IEEE Trans Consum Electron., vol 58, no 1, pp 78–85 [6] T Stockhammer (2011), “Dynamic Adaptive Streaming over HTTP – Standards and Design Principles”, Proc Second Annu ACM SIGMM Conf Multimed., no i, pp 133–143 [7] Open Networking Foundation (ONF) (2012), “Software Defined Networking: the new norm for network”, White paper [8] N McKeown et al (2008), “OpenFlow: Enabling Innovation in Campus Networks”, ACM SIGCOMM Comput Commun Rev, vol 38, no 2, pp 69–74 [9] L R Romero (2011), “A Dynamic Adaptive HTTP Streaming Video Service for Google Android”, M.S Thesis, R Inst Technol (KTH), Stock, p 148 [10] C Liu, I Bouazizi, and M Gabbouj (2011), “Rate Adaptation for Adaptive HTTP Streaming”, Proc Second Annu ACM Conf Multimed Syst, pp 169–174 [11] B Zhou, J Wang, Z Zou, and J Wen (2012), “Bandwidth estimation and rate adaptation in HTTP streaming”, IEEE Int Conf Comput Netw Commun ICNC’12, pp 734–738 [12] T C Truong, H T Le, H X Nguyen, A T Pham, J W Kang, and Y M Ro (2013), “Adaptive Video Streaming over HTTP with Dynamic Resource Estimation”, J Commun Networks, vol 15, no 6, pp 635–644 [13] K Miller, E Quacchio, G Gennari, and A Wolisz (2012), “Adaptation Algorithm for Adaptive Streaming over HTTP”, 2012 19th Int Pack Video Work (PV), Munich, pp 173–178 [14] T.-Y Huang, R Johari, and N McKeown (2013), “Downton abbey without the hiccups: Buffer-based rate adaptation for http video streaming”, Proc ACM SIGCOMM Work Futur human-centric Multimed Netw., pp 9–11 [15] T.-Y Huang, R Johari, N McKeown, M Trunnell, and M Watson (2014), “Using the Buffer to Avoid Rebuffers: Evidence from a Large Video Streaming Service”, arXiv Prepr arXiv1401.2209, [Online] Available: http://arxiv.org/abs/1401.2209 [16] T.-Y Huang, R Johari, M Watson, M Trunnell, and N McKeown (2015) , “A buffer-based approach to rate adaptation: Evidence from a large video streaming service”, ACM SIGCOMM Comput Commun Rev., vol 44, no 4, pp 187–198 [17] Y Zhou, Y Duan, J Sun, and Z Guo (2014), “Towards simple and smooth rate adaption for VBR video in DASH”, IEEE Vis Commun Image Process Conf 128 VCIP, pp 9–12, 2015 [18] H N Nguyen, T Vu, H T Le, N N Pham, and T C Truong (2016), “Smooth quality adaptation method for VBR video streaming over HTTP”, Int Conf Comput Manag Telecommun ComManTel, pp 184–188 [19] P Juluri, V Tamarapalli, and D Medhi (2015), “SARA: Segment aware rate adaptation algorithm for dynamic adaptive streaming over HTTP,” IEEE Int Conf Commun Work ICCW, pp 1765–1770 [20] S Latré, J Famaey, F De Turck, M Claeys, and S Petrangeli, “QoE-Driven Rate Adaptation Heuristic for Fair Adaptive Video Streaming (2015)”, ACM Trans Multimed Comput Commun App, vol 12, no 2, pp 1–24 [21] M Jarschel, F Wamser, T Hohn, T Zinner, and P Tran-Gia (2013), “SDN-based application-aware networking on the example of youtube video streaming”, Proc 2nd Eur Work Softw Defin Networks, EWSDN, pp 87–92 [22] H E Egilmez, S Civanlar, and A M Tekalp (2013), “An optimization framework for QoS-enabled adaptive video streaming over openflow networks”, IEEE Trans Multimed., vol 15, no 3, pp 710–715 [23] H E Egilmez and A M Tekalp (2014), “Distributed QoS architectures for multimedia streaming over software defined networks”, IEEE Trans Multimed., vol 16, no 6, pp 1597–1609 [24] C Cetinkaya, E Karayer, M Sayit, and C Hellge (2014), “SDN for Segment based Flow Routing of DASH”, IEEE Fourth Int Conf Consum Electron Berlin, pp 74– 77 [25] H Nam, K Kim, J Y Kim, and H Schulzrinne (2014), “Towards QoE-aware Video Streaming using SDN”, IEEE Glob Commun Conf., pp 1317–1322 [26] N Xue et al (2015), “Demonstration of OpenFlow-Controlled Network Orchestration for Adaptive SVC Video Manycast”, IEEE Trans Multimed., vol 17, no 9, pp 1617–1629 [27] H Owens and A Durresi (2015), “Video over Software-Defined Networking (VSDN)”, Comput Networks, vol 92, pp 341–356 [28] C Hue, Y J Chen, and L C Wang (2015), “Traffic-aware networking for video streaming service using SDN”, IEEE 34th Int Perform Comput Commun Conf IPCCC, pp 1-5 [29] J Jiang (2012), “Improving Fairness, Efficiency, and Stability in HTTP-based Adaptive Video Streaming with FESTIVE”, Proc 8th Int Conf Emerg Netw Exp Technol., pp 97–108 [30] S Akhshabi, L Anantakrishnan, A Begen, and C Dovrolis (2012), “What happens when HTTP adaptive streaming players compete for bandwidth? Cited by me”, Proc 22nd, pp 1–6 [31] Z Li et al (2014), “Probe and Adapt : Rate Adaptation for HTTP Video Streaming At Scale”, IEEE J Sel Areas Commun 32(4), pp 719–733 [32] J J Quinlan, A H Zahran, K K Ramakrishnan, and C J Sreenan (2015), “Delivery of adaptive bit rate video: Balancing fairness, efficiency and quality”, IEEE Work Local Metrop Area Networks, pp 1–6 [33] P Georgopoulos, Y Elkhatib, M Broadbent, M Mu, and N Race (2016), “Towards Network- wide QoE Fairness Using OpenFlow-assisted Adaptive Video Streaming”, pp 15–20 [34] R M Abuteir, A Fladenmuller, and O Fourmaux (2016), “SDN based architecture 129 to improve video streaming in home networks”, pp 220–226 [35] A C Begen, T Akgul, and M Baugher (2011), “Watching video over the web: Part 2: Applications, standardization, and open issues”, IEEE Internet Comput., vol 15, no 3, pp 59–63 [36] V Jacobson and V J H Schulzrinne, S Casner, R Frederick (2003), “RTP: A Transport Protocol for Real-Time Applications”, https://tools.ietf.org/html/rfc3550 (accessed Jun 06, 2020) [37] H Parmar and E M Thornburgh (2012), “Adobe’s Real Time Messaging Protocol”, https://www.adobe.com/devnet/rtmp.html (accessed Jun 06, 2020) [38] “Inc., A Apple http live streaming.” https://developer.apple.com/streaming/ (accessed Jun 06, 2020) [39] “Inc., A Adobe http dynamic streaming (hds) technology center”, https://www.adobe.com/devnet/hds.html (accessed Jun 06, 2020) [40] “Corporation, M Microsoft silverlight smooth streaming”, https://www.microsoft.com/silverlight/smoothstreaming (accessed Jun 06, 2020) [41] S P Le Callet, P.; Möller (2014), “Qualinet White Paper on Definitions of Quality of Experience To cite this version : HAL Id : hal-00977812 Qualinet White Paper on Definitions of Quality of Experience Output from the fifth Qualinet meeting”, Novi Sad [42] Ulrich Reiter et al (2014), “Factors Influencing Quality of Experience,” Springer Int Publ., pp 55–72 [43] J De Vriendt, D De Vleeschauwer, D Robinson, and B Labs (2013), “Model for estimating QoE of video delivered using HTTP adaptive streaming”, IFIP/IEEE Int Symp Integr Netw Manag., pp 1288–1293 [44] R K P Mok, E W W Chan, and R K C Chang (2011), “Measuring the Quality of Experience of HTTP Video Streaming”, Computer (Long Beach Calif), vol 1, pp 485–492 [45] M Claeys, S Latré, J Famaeya, T Wu, W Van Leekwijck, and F De Turck (2014), “Design and optimization of a (FA)Q-learning-based HTTP adaptive streaming client”, Connect Sci., pp 27–45 [46] A Bentaleb, A C Begen, and R Zimmermann (2016), “SDNDASH : Improving QoE of HTTP Adaptive Streaming Using Software Defined Networking”, ACM Multimed., pp 1296–1305 [47] A Bentaleb, A C Begen, S Member, R Zimmermann, and S Member (2018), “QoE-Aware Bandwidth Broker for HTTP Adaptive Streaming Flows in an SDNEnabled HFC Network ”, IEEE Trans Broadcast., vol 64, no 2, pp 575–589 [48] I 23009-1:2014, “Information technology — Dynamic adaptive streaming over HTTP (DASH) — Part 1: Media presentation description and segment formats”, https://www.iso.org/standard/65274.html (accessed Jun 06, 2020) [49] P K R Reuban Gnana Asir, Kishore Kumar C (2014), “MPEG-DASH Enhanced Multimedia Streaming”, Int J Adv Res MPEG-DASH Enhanc Multimed Streaming, vol 4, no 3, pp 848–851 [50] Youtube, “Live encoder settings, bitrates, and resolutions”, https://support.google.com/youtube/answer/2853702?hl=en (accessed Jun 06, 2020) [51] “Live Videos from Publishing Tools”, https://www.facebook.com/facebookmedia/get-started/live (accessed Jun 06, 130 2020) [52] Y Liu, Y Shen, Y Mao, J Liu, Q Lin, and D Yang (2013), “A study on Quality of Experience for adaptive streaming service”, IEEE Int Conf Commun Work ICC, pp 682–686 [53] W Song and D W Tjondronegoro (2014), “Acceptability-based QoE models for mobile video, IEEE Trans Multimed., vol 16, no 3, pp 738–750 [54] M Seufert, S Egger, M Slanina, T Zinner, T Hossfeld, and P Tran-gia (2015), “A Survey on Quality of Experience of HTTP Adaptive Streaming”, IEEE Commun Surv Tutorials, vol 17, no 1, pp 469–492 [55] A R and S Egger (2014), “Quality and Quality of Experience’ in Quality of Experience: Advanced Concepts, Applications and Methods”, New York, NY, USA Springer-Verlag, [Online] Available: http://link.springer.com/10.1007/978-3-31902681-7 [56] T De Pessemier, K De Moor, W Joseph, L De Marez, and L Martens (2013), “Quantifying the influence of rebuffering interruptions on the user’s quality of experience during mobile video watching”, IEEE Trans Broadcast, vol 59, no 1, pp 47–61 [57] M Zink, J Schmitt, and R Steinmetz (2005), “Layer-encoded video in scalable adaptive streaming”, IEEE Trans Multimed., vol 7, no 1, pp 75–83 [58] B Lewcio, B Belmudez, A Mehmood, M Waltermann, and S Moller (2011), “Video quality in next generation mobile networks Perception of time-varying transmission”, IEEE Int Work Tech Comm Commun Qual Reliab, pp 1–6 [59] Q Yining and D Mingyuan (2006), “The effect of frame freezing and frame skipping on video quality”, Proc Int Conf Intell Inf Hiding Multimed Signal Process IIH-MSP, pp 423–426 [60] T Hossfeld and D Strohmeier (2013), “Pippi Longstocking calculus for temporal stimuli pattern on YouTube QoE: 1+ 1= and 1· 4≠ 4· 1”, Proc 5th …, pp 37–42 [61] H T Quan and M Ghanbari (2008), “Temporal aspect of perceived quality in mobile video broadcasting”, IEEE Trans Broadcast, vol 54, no 3, pp 641–651 [62] O Oyman and S Singh (2012), “Quality of experience for HTTP adaptive streaming services” IEEE Commun Mag., vol 50, no 4, pp 20–27 [63] M Claeys, S Latré, J Famaey, T Wu, W Van Leekwijck, and F De Turck (2013), “Design of a Q-learning-based client quality selection algorithm for HTTP adaptive video streaming”, AAMAS 2013 Work Adapt Learn Agents, pp 30-37 [64] D Z Rodríguez, Z Wang, L Rosa, and G Bressan (2014), “The impact of videoquality-level switching on user quality of experience in dynamic adaptive streaming over HTTP”, Eurasip J Wirel Commun Netw., vol 2014, no 1, pp 1-15 [65] R K P Mok, X Luo, E W W Chan, and R K C Chang (2012), “QDASH: A QoE-aware DASH system”, MMSys - Proc 3rd Multimed Syst Conf , pp 11–22 [66] F De Turck, S Petrangeli, J Van Der Hooft, and T Wauters (2018), “Quality of experience-centric management of adaptive video streaming services: Status and challenges”, ACM Trans Multimed Comput Commun Appl., vol 14, no 2s [67] S Timmerer, Christian and Maiero, Matteo and Rainer, Benjamin and Petscharnig, Stefan and Weinberger, Daniel and Mueller, Christopher and Lederer (2015), “Quality of Experience of Adaptive HTTP Streaming in Real-World Environments”, IEEE Comsoc MTC E-Letter, vol 10, no [68] T De Pessemier, K De Moor, W Joseph, L De Marez, and L Martens (2013), 131 “Quantifying the influence of rebuffering interruptions on the user’s quality of experience during mobile video watching”, IEEE Trans Broadcast., vol 59, no 1, pp 47–61 [69] International Telecommunication Union (1996), “Methods for subjective determination of transmission quality”, Int Telecommun Union, Geneva, Switzerland, ITU-Recommendation, vol 800, p 22 [70] ITU-T Recommendation P.800.1, “Mean Opinion Score (MOS) terminology” [71] SDN, “What Is Software Defined Networking (SDN)?” https://www.sdxcentral.com/networking/sdn/definitions/what-the-definition-ofsoftware-defined-networking-sdn/ (accessed Jun 06, 2020) [72] “Software-Defined Networking (SDN) Definition” https://www.opennetworking.org/sdn-definition/ (accessed Jun 06, 2020) [73] J Naous, D Erickson, and G A Covington (2008), “Implementing an OpenFlow Switch on the NetFPGA platform”, ANCS, San Jose, CA, USA [74] Open Networking Foundation (2015), “OpenFlow Switch Specification (Version 1.5.1),” Current, vol 0, [Online] Available: https://www.opennetworking.org/images/stories/downloads/sdn-resources/onfspecifications/openflow/openflow-switch-v1.5.1.pdf [75] “The NOX Controller”, https://github.com/noxrepo/nox (accessed Jun 06, 2020) [76] “The POX network software platform”, https://github.com/noxrepo/pox (accessed Jun 06, 2020) [77] D Erickson (2013), “The Beacon OpenFlow controller”, Proc 2013 ACM SIGCOMM Work Hot Top Softw Defin Networking, HotSDN, pp 13–18 [78] T L F Project, “Opendaylight controller”, https://www.opendaylight.org/ (accessed Jun 06, 2020) [79] “Floodlight SDN OpenFlow Controller”, https://github.com/floodlight/floodlight (accessed Jun 06, 2020) [80] “Project Floodlight”, http://www.projectfloodlight.org/floodlight/ (accessed Jun 06, 2020) [81] “Mininet”, http://mininet.github.io/ (accessed Jun 06, 2020) [82] B Lantz, B Heller, and N McKeown (2010), “A Network in a Laptop: Rapid Prototyping for Software-Defined Networks”, Proc Ninth ACM SIGCOMM Work Hot Top Networks - Hotnets, pp 1–6 [83] M Bredel (2013), “OpenFlow and the Floodlight OpenFlow Controller”, ADMIN Netw Secur n, no 17, [Online] Available: https://www.adminmagazine.com/Archive/2013/17/OpenFlow-and-the-Floodlight-OpenFlowController [84] S Akhshabi, A C Begen, and C Dovrolis (2012), “An Experimental Evaluation of Rate-Adaptation Algorithms in Adaptive Streaming over HTTP”, Signal Process Image Commun 27(4), pp 271–287 [85] S Akhshabi, A C Begen, and C Dovrolis (2011), “An Experimental Evaluation of Rate-Adaptation Algorithms in Adaptive Streaming over HTTP ”, MMSys ’11 Proc Second Annu ACM Conf Multimed Syst., pp 157–168 [86] C Müller, S Lederer, and C Timmerer (2012), “An evaluation of dynamic adaptive streaming over HTTP in vehicular environments”, Proc 4th Work Mob Video, p 37-42 [87] T C Truong, H T Le, A T Pham, and Y M Ro (2014), “An evaluation of bitrate 132 adaptation methods for HTTP live streaming”, IEEE J Sel Areas Commun., vol 32, no 4, pp 693–705 [88] D L C Dutra, M Bagaa, T Taleb, and K Samdanis (2018), “Ensuring End-toEnd QoS Based on Multi-Paths Routing Using SDN Technology”, IEEE Glob Commun Conf GLOBECOM - Proc., pp 1–6 [89] Y S Yu and C H Ke (2018), “Genetic algorithm-based routing method for enhanced video delivery over software defined networks” Int J Commun Syst., vol 31, no 1, pp 1–13 [90] J Ozer, “What’s the right keyframe interval?” https://streaminglearningcenter.com/blogs/whats-the-right-keyframe-interval.html (accessed Jun 06, 2020) [91] S Wei and V Swaminathan (2014), “Low Latency Live Video Streaming over HTTP 2.0”, Proc ACM NOSSDAV, pp 37–42 [92] “Dijkstra Shortest Path Algorithm Using Global Positioning System”, https://www.techrepublic.com/resource-library/whitepapers/dijkstra-shortest-pathalgorithm-using-global-positioning-system/ (accessed Jun 06, 2020) [93] L Rizzo (1997), “Dummynet: A Simple Approach to the Evaluation of Network Protocols”, ACM SIGCOMM Comput Commun Rev., vol 27, no 1, pp 31–41 [94] Bitmovin, “Libdash - bitmovin”, https://github.com/bitmovin/libdash (accessed Jun 06, 2020) [95] C Mueller, S Lederer, C Timmerer and H Hellwagner (2012), “Dynamic Adaptive Streaming over HTTP Dataset”, Proc - IEEE Int Conf Multimed Expo , pp 89 94 [96] T Vu, H T Le, D V Nguyen, N N Pham, and T C Truong (2015), “Future buffer based adaptation for VBR video streaming over HTTP”, IEEE 17th Int Work Multimed Signal Process MMSP, pp – [97] A Bentaleb, A C Begen, R Zimmermann, and S Harous (2017), “SDNHAS: An SDN-enabled architecture to optimize QoE in HTTP adaptive streaming”, IEEE Trans Multimed., vol 19, no 10, pp 2136–2151 [98] E Liotou, K Samdanis, E Pateromichelakis, N Passas, and L Merakos (2018), “QoE-SDN APP: A Rate-guided QoE-aware SDN-APP for HTTP Adaptive Video Streaming”, IEEE J Sel Areas Commun., vol 8716, no c, pp 1–17 [99] L Guillen, S Izumi, and T Abe (2019), “SAND/3 : SDN-Assisted Novel QoE Control Method for Dynamic Adaptive Streaming over HTTP/3”, Electron Multidiscip Digit Publ Inst., vol 8, no 8, pp 1–17 [100] Wikipedia (2018), “Round-robin scheduling”, https://en.wikipedia.org/wiki/Round-robin_scheduling (accessed Jun 06, 2020) [101] O O M P Studio (2009), “Elephants dream”, https://orange.blender.org/ (accessed Jun 06, 2020) [102] Cisco, “Comparing Traffic Policing and Traffic Shaping for Bandwidth Limiting”, https://www.cisco.com/c/%0Aen/us/support/docs/quality-of-service-qos/qospolicing/%0A19645-policevsshape.html (accessed Feb 03, 2019) [103] O Younis and S Fahmy (2003), “Constraint-based routing in the internet: Basic principles and recent research”, IEEE Commun Surv Tutorials, vol 5, no 1, pp 2–13 [104] H T Le (2017), “Quality Improvement for HTTP Adaptive Streaming over Mobile Networks”, Ph.D Thesis , Univ Aizu 133 [105] Z Li, A C Begen, J Gahm, Y Shan, B Osler, and D Oran (2014), “Streaming video over HTTP with consistent quality”, Proc 5th ACM Multimed Syst Conf MMSys, pp 248–258 [106] K Miller, A K Al-Tamimi, and A Wolisz (2016), “QoE-based low-delay live streaming using throughput predictions”, ACM Trans Multimed Comput Commun Appl., vol 13, no 1, pp 1–41 [107] A Mansy (2015), “Network-layer Fairness for Adaptive Video Streams”, IEEE, IFIP Netw Conf (IFIP Networking), pp 1–9 [108] M Ghobadi and M Mathis (2012), “Trickle : Rate Limiting YouTube Video Streaming”, Present as part {USENIX} Annu Tech Conf ({USENIX}{ATC} 12), pp 191–196 [109] S Akhshabi, L Anantakrishnan, C Dovrolis, and A C Begen (2013), “ServerBased Traffic Shaping for Stabilizing Oscillating Adaptive Streaming Players” Proceeding 23rd ACM Work Netw Oper Syst Support Digit audio video, pp 19– 24 [110] S Ramakrishnan, X Zhu, F Chan, and K Kambhatla (2015), “SDN Based QoE Optimization for HTTP-Based Adaptive Video Streaming”, IEEE Int Symp Multimed., pp 120–123 [111] A Ahmad, A Floris, and L Atzori (2019), “Towards Information-centric Collaborative QoE Management using SDN”, IEEE Wirel Commun Netw Conf., pp 1–6 [112] T Y Huang, N Handigol, B Heller, N McKeown, and R Johari (2012), “Confused, timid, and unstable: Picking a video streaming rate is hard ”, Proc ACM SIGCOMM Internet Meas Conf IMC, pp 225–238 [113] X Yin, M Bartulovic, V Sekar, and B Sinopoli (2017), “On the efficiency and fairness of multiplayer HTTP-based adaptive video streaming”, Proc Am Control Conf., pp 4236–4241 [114] S W V D Fabien Weibel, Manuel Alligne (2012), “Destiny” http://fweibel.com/destiny (accessed Jun 06, 2020) [115] W R Jain, Rajendra K and Chiu, Dah-Ming W and Hawe (1984), “A quantitative measure of fairness and discrimination for resource allocation in shared computer system”, East Res Lab Digit Equip Corp Hudson, MA, pp – 37 [116] R K P Mok, E W W Chan, X Luo, and R K C Chang (2011), “Inferring the QoE of HTTP video streaming from user-viewing activities”, Proc 1st ACM SIGCOMM Work Meas Up Stack, W-MUST, pp 31–36 ... ĐÀO TẠO TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI PHẠM HỒNG THỊNH NÂNG CAO CHẤT LƯỢNG TRUYỀN VIDEO THÍCH NGHI HTTP TRÊN MẠNG ĐIỀU KHIỂN BẰNG PHẦN MỀM (SDN) Ngành: Kỹ thuật vi ễn thông Mã số: 9520208 LUẬN... rằng, để nâng cao chất lượng trải nghi? ??m người dùng hay nâng cao QoE, máy khách phải giảm việc chuyển đổi mức chất lượng tần số biên độ tránh tượng đóng băng video 1.3 Mạng điều khiển phần mềm SDN... tầng mạng Lớp ứng dụng Ứng dụng điều hành mạng Giao diện Điều khiển - Ứng dụng Lớp điều khiển Phần mềm điều khiển SDN Dịch vụ mạng Giao diện Điều khiển - Dữ liệu (Ví dụ: OpenFlow) Lớp hạ tầng mạng