Đảm bảo chất lượng cho luồng âm thanh trực tuyến

Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên http://www.lrc-tnu.edu.vn/DTX Discontinuous Transmission Kỹ thuật truyền gián đoạn ETSI European telecommunications Standards Institu

Trang 1

Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên http://www.lrc-tnu.edu.vn/

ĐẠIHỌC THÁI NGUYÊN ĐẠI HỌC CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN

THÔNG

NGUYỄN VĂN TUÂN

ĐẢM BẢO CHẤT LƢỢNG CHO LUỒNG

ÂM THANH TRỰC TUYẾN

CHUYÊN NGÀNH: KHOA HỌC MÁY TÍNH

2012

Trang 2

LỜI CAM ĐOAN

Tôi xin cam đoan đây là công trình nghiên cứu của bản thân Các số liệu, kết quả trình bày trong luận văn là trung thực Nhưng tư liệu được sử dụng trong luận văn có nguồn gốc và trích dẫn rõ ràng, đầy đủ

Thái nguyên, tháng 9 năm 2012

HỌC VIÊN

Nguyễn Văn Tuân

Trang 3

LỜI CẢM ƠN

Trước hết, tôi xin bày tỏ lòng biết ơn sâu sắc và chân thành tới thầy giáo hướng dẫn TS Phạm Thanh Giang người đã tận tình chỉ bảo, hướng dẫn tôi trong suốt quá trình làm luận văn Sự giúp đỡ quý báu của thầy giáo đã tạo điều kiện về mặt khoa học và là nguồn động viên tinh thần rất lớn giúp tôi hoàn thành luận văn này

Tôi xin bày tỏ lòng biết ơn đến đồng nghiệp bạn bè đã tạo điều kiện cho tôi không những về thời gian mà còn những đóng góp quý báu cho luận văn

Tôi xin bày tỏ lòng biết ơn sâu sắc đến các thầy cô giáo đã giảng dạy và truyền thụ kiến thức cho tôi trong quá trình học tập tại trường Đại học Công nghệ Thông tin và Truyền thông – Đại học Thái Nguyên

Cuối cùng, tôi xin bày tỏ lòng kính trọng và biết ơn sâu sắc đến bậc sinh thành, người đã dưỡng dục và động viên con suốt tháng ngày qua Tôi xin cảm ơn

vợ và người thân trong gia đình đã là nguồn động viên tinh thần rất lớn đối với tôi

Nguyễn Văn Tuân

Trang 4

MỤC LỤC

LỜI CAM ĐOAN i

LỜI CẢM ƠN iii

MỤC LỤC iv

DANH MỤC CÁC KÝ HIỆU, CHỮ VIẾT TẮT vi

DANH MỤC CÁC BẢNG ix

DANH MỤC HÌNH VẼ x

MỞ ĐẦU 1

CHƯƠNG I: TỔNG QUAN VỀ CHẤT LƯỢNG DỊCH VỤ CỦA LUỒNG ÂM THANH TRỰC TUYẾN 3

1.1 Chất lượng dịch vụ (Quality of Service)trên Internet 3

1.1.1 Khái niệm về chất lượng dịch vụ (QoS) 3

1.1.2 Các tham số QoS 4

1.1.3 Các nguyên nhân ảnh hưởng đến chất lượng dịch vụ 5

1.1.3.1 Nguyên nhân trễ(Delay) 5

1.1.3.2 Nguyên nhân của biến thiên trễ(Jitter) 6

1.1.3.3 Nguyên nhân của mất gói(packet loss) 8

1.1.4 Những điều kiện QoS cho luồng âm thanh thời gian thực 9

1.1.4.1 Thông lượng(Throughput) 9

1.1.4.2 Trễ(Delay) 10

1.1.4.3 Biến thiên trễ(Delay Jitter) 11

1.1.4.4 Độ tin cậy (Reliability) 11

1.2 Giao thức đa phương tiện trên Internet 11

1.2.1 Giao thức TCP ( Transmision Control Protocol) 13

1.2.2 Giao thức UDP (USER DATAGRAM PROTOCOL) 16

1.2.3 Giao thức truyền thông thời gian thực RTP( Real-Time Transport Protocol) 17

1.3.4 Giao thức thời gian thực RTSP( Real Time Stream Protocol ) 20

1.3.5 Giao thức điều khiển truyền thông thời gian thực RTCP(Real-Time Transport Control Protocol) 23

CHƯƠNG II: CHẤT LƯỢNG DỊCH VỤ LUỒNG ÂM THANH TRÊN INTERNET 25

2.1 QoS lớp ứng dụng 25

2.1.1 Truyền gói 25

2.1.2 Điều chỉnh lỗi (Forward Error Correction) 27

2.1.3 Sự thích ứng (Adaptation) 28

2.1.4 Bộ đệm nhận(Receiver buffering) 29

2.2 QoS lớp mạng 30

Trang 5

2.2.1 Đánh dấu quyền ưu tiên tương đối 30

2.2.2 Dịch vụ đánh dấu 31

2.2.3 Dịch vụ tích hợp(IntServ) 31

2.2.3.1 Khái quát về IntServ 31

2.2.3.2 Thành phần và nguyên tắc hoạt động của IntServ 33

2.2.3.3 Điều khiển dịch vụ QoS 35

2.2.3.5 Giao thức giữ trước tài nguyên RSVP 35

2.2.3.6 RSVP và IntServ 41

2.2.3.7 Ưu điểm và Nhược điểm của IntServ/ RSVP 42

2.2.4 Dịch vụ phân biệt 42

2.2.4.1 Nguyên tắc cơ bản của DiffServ 42

2.2.4.2 Các mức chất lượng dịch vụ cung cấp bởi DiffServ 44

2.2.4.3 Khả năng linh hoạt của DiffServ 46

2.2.4.4 Mô hình của DiffServ 46

2.2.4.5 Tác động từng chặng 47

2.2.4.6 Vùng mạng dịch vụ phân biệt 50

2.2.4.7 Phân bổ băng thông 51

2.2.4.8 Ưu điểm & Nhược điểm của DiffServ 51

2.2.5 Chuyển mạch nhãn IP 52

CHƯƠNG III THỬ NGHIỆM ỨNG DỤNG WEBAUDIO VỚI GIAO THỨC RTSP 53

3.1 Mô hình ứng dụng Web Audio 53

3.2 Cấu hình hệ thống Web Audio 56

3.3 Đánh giá chất lượng hệ thống 60

3.4 Đánh giá kết quả thực nghiệm 68

KẾT LUẬN 69

TÀI LIỆU THAM KHẢO 70

Trang 6

DANH MỤC CÁC KÝ HIỆU, CHỮ VIẾT TẮT

ANSI American National Standards

ADPCM Adaptive Differential Pulse

Code Modulation điều xung mă (PCM) vi sai thích ứng

API Application Programming

ARJ Admission ReJect Từ chối yêu cầu đăng nhập

ARQ Admission ReQuest Yêu cầu đăng nhập

ATM Asynchronous Transfer Mode Phương thức truyền tải không đồng

bộ

CCS Common Channel Signaling Báo hiệu kênh chung

CELP Code Excited Linear

Prediction

Dự báo tuyến tính được thực hiện bằng mã

CODEC Code and DECodec Mã hoá và giải mã

CRC Cyclic Redundancy Check Kiểm tra độ dư thừa có chu kỳ

DCF Disengage ConFirm Xác nhận huỷ bỏ liên kết

DPCM Differential Pulse-Code

DNS Domain Name Server Máy chủ dịch vụ tên miền

Trang 7

DTX Discontinuous Transmission Kỹ thuật truyền gián đoạn

ETSI European telecommunications

Standards Institute Viện tiêu chuẩn viễn thông châu Âu FEC Forward Error Correction Hiệu chỉnh lỗi trước

FIFO

Queuing First In First Out Queuing Xếp hàng vào trước ra trước

FTP File Transfer Protocol Giao thức truyền file

GQOS Guaranteed Quality of Service Bảo đảm chất lượng dịch vụ

HTTP Hyper Text Transfer Protocol Giao thức truyền tải siêu văn bản

ICMP Internet Control Message

Protocol Giao thức bản tin điều khiển Internet

IP Internet Protocol Giao thức Internet

IRQ Information ReQuest Yêu cầu thông tin

ISDN integrated Service Digital

ISP Internet Service Provider Nhà cung cấp dịch vụ Internet

Kbps Kilobit per second Kilô bít trên giây

LAN Local Area Network Mạng nội hạt

LPC Line Predict Coder Bộ mã hoá dự báo tuyến tính

LRQ Location ReQuest Yêu cầu định vị

Mbps Megabit per second Mêga bít trên 1 giây

MOS Mean Opinion Score Điểm đánh giá trung bình

MPE MultiPulse Excite Bộ kích thích đa xung

MTU Maximum Transfer Unit Kích thước tối đa của một đơn vị

truyền tải NGN Next Generation Network Mạng thế hệ sau

OSI Open System Interconnection Mô hình kết nối các hệ thống mở

Trang 8

OSPF Open Shortest Path First Mở đường ngắn nhất đầu tiên

PCM Pulse Code Modulation Điều chế xung mã

PPP Point to Point Protocol Giao thức điểm tới điểm

PQ Priority Queuing Xếp hàng theo mức ưu tiên

QoS Quality of Service Chất lượng dịch vụ

RTCP Real Time Control Protocol Giao thức điều khiển thời gian thực RTP Real Time Protocol Giao thức thời gian thực

RTSP Real Time Stream Protocol Giao thức luồng thời gian thực RTSP RED Random Early Detection phát hiện sớm ngẫu nhiên

SDP Session Description Protocol Giao thức miêu tả phiên

SIP Session Initiation Protocol Giao thức khởi đầu phiên

SMTP Simple Mail Transfer Protocol Giao thức truyền tải mail

STM Synchronous Tranfer Mode Chế độ truyền tải đồng bộ

TCP Transmission Control Protocol Giao thức điều khiển truyền tải

VoIP Voice over Internet Protocol Thoại truyền qua giao thức Internet WFQ Weighted Fair Queuing Xếp hàng theo công bằng trọng số

Trang 9

DANH MỤC CÁC BẢNG

Bảng 1.1.4.1a: Chất lượng Voice mã hóa và thông lượng 10

Bảng 1.1.4.1b: Chất lượng CD mã hóa và thông lượng 10

Bảng 1.3.5: Mô hình phương thức RTSP, hướng đi và yêu cầu 23

Bảng 2.1.1: Gói tin Overhead của Mã hóa Audio khác nhau và cơ chế truyền 27

Bảng2.2.3.5a: Các kiểu và thuộc tính bảo lưu 39

Bảng 2.2.3.6a: Các tham số của các đối tượng CL khác nhau 42

Bảng2.2.3.6b: Các tham số của dịch vụ được cam kết Rspec 42

Bảng 2.2.4.5a: Các loại AF 49

Bảng 3.3a: Chất lượng truyền gói tin Demand 60

Bảng 3.3b Chất lượng âm thanh truyền nhận gói tin Broadcasting 60

Trang 10

DANH MỤC HÌNH VẼ

Hình 1.1.3.2: Phân cụm gói tin 6

Hình 2.1: Các giao thức và dịch vụ đa phương tiện 13

Hình 1.2.1a :Hoạt động của giao thức TCP trong việc cung cấp kết nối 13

Hình 1.2.1b :Khuôn dạng TCP Segment 14

Hình 1.2.2: Khuôn dạng UDP Datagram 16

Hình 1.2.3a: Khuôn dạng phần cố định gói tin RTP 18

Hình 1.2.3b: Khuôn dạng phần mở rộng RTP 19

Hình 2.1.4: ước tính phát lại gói tin 30

Hình 2.2.3.2a: Mô hình dịch vụ IntServ 33

Hình 2.2.3.2b: Kiến trúc IntServ 34

Hình 2.2.3.2c: Ví dụ về hoạt động của mạng IntServ 34

Hình 2.2.3.5a: Các chức năng RSVP tại Host và Router 36

Hình 2.2.3.5b: Hoạt động của RSVP 37

Hình 2.2.3.5c: Hoạt động của thuật toán gầu thẻ IP 40

Hình 2.2.3.5d: Hoạt động của gầu thẻ kết hợp với chỉnh sửa tốc độ đỉnh 41

Hình 2.2.3.5e: Phân loại bản tin cho luồng lưu lượng tuân thủ và các gói tin BE 41

Hình2.2.4.1a: Mô hình tổng quát của DiffServ 44

Hình 2.2.4.4a: Trường dịch vụ phân biệt DS 47

Hình 2.2.4.4b: Mô hình DiffServ tại biên và lõi mạng 47

Hình 2.2.4.5a: Chuyển tiếp nhanh mã hóa một lựa chọn hàng đợi đơn 48

Hình 2.2.4.5b: Chuyển tiếp được đảm bảo mã hóa lớp dịch vụ và mức ưu tiên loại bỏ gói 49

Hình 2.2.4.6a: Mạng dịch vụ phân biệt 50

Hình 2.2.4.6b: Phân loại gói tin và kiểm tra lưu lượng 50

Hình 3.1a: Mô hình tổng quan mô phỏng WebAudio 54

Hình 3.1b: Các giao thức hỗ trợ quá trình truyền nhận Audio 55

Trang 11

Hình 3.1c: Các kết nố ệc 55

Hình 3.2a: Ứng dụng tích hợp trong Apache 2.2 56

Hình 3.2b: Thông tin về tên máy chủ Mail quan trị 57

Hình 3.2c: Quá trình cài đặt Apache 2.2 thành công 57

Hình 3.2d: Phần mềm Navicat quản trị CSDL web_nhac 58

Hình 3.2e: Giao diện WebAudio 58

Hình 3.2f: LIVE555 Media Server 59

Hình 3.3a: Các gói tin bắt được bằng Wireshark 61

Hình 3.3b: Phân cấp giao thức sử dụng 61

Hình 3.3c: Gói tin RTSP 62

Hình 3.3d: Thông tin lọc gói tin giao thứcRTSP 62

Hình 3.3e: Truyền nhận trong RTSP 63

Hình 3.3f: Gói tin RTP 64

Hình 3.3g: Phân cấp gói tin theo giao thức RTP 64

Hình 3.3h: Các thông số thống kê về chất lượng gói tin 64

Hình 3.3i: Gói tin RTCP 65

Hình 3.3j: Thông số RTSP 66

Hình 3.3k: Các thông số gói tin RTP 66

Hình 3.4m: Kết quả truyền nhận RTCP 67

Hình 3.3l: Tỷ lệ truyền nhận gói tin TCP 67

Hình 3.3n: Phân cấp giao thức sử dụng trên Internet 67

Hình 3.4o: Truyền nhận các gói tin của trang Web trên Internet 68

Hình 3.4u: Truyền nhận các gói tin của luồng âm thanh trực tuyến 68

Trang 12

MỞ ĐẦU

1 CƠ SỞ KHOA HỌC VÀ TÍNH THỰC TIỄN CỦA ĐỀ TÀI

Mạng Internet hiện nay cung cấp các dịch vụ trên cơ sở phục vụ theo khả năng tối đa(best - offort), tức là không có bất cứ một cam kết nào được đưa ra từ nhà cung cấp dịch vụ Thay vào đó, tùy thuộc vào trạng thái cụ thể của mạng, mạng chủ sẽ thực hiện khả năng tốt nhất của mình để phục vụ cho lưu lượng dịch vụ[5].Vì vậy, việc thúc đẩy nghiên cứu QoS phục vụ cho những dịch vụ, ứng dụng và đặc biệt là dịch vụ đa phương tiện đang được phát triển mạnh mẽ

Các ứng dụng luồng truyền thông đa phương tiện còn được biết đến là ứng dụng truyền thông liên tục và trở nên phổ biến trên internet Trong đó, luồng âm thanh trực tuyến (Streamming) là một thành phần quan trọng của truyền thông đa phương tiện trên mạng Internet Tuy nhiên, vấn đề chất lượng dịch vụ (QoS - Quality of Service) trong truyền thông đa phương tiện nói chung và đối với luồng

dữ liệu âm thanh nói riêng vẫn chưa được quan tâm đúng mức

Trong đó kỹ thuật đảm bảo QoS cho phép mạng có thể ước lượng dự đoán từng thay đổi của dịch vụ về từng ứng dụng, lưu lượng và sử dụng nó để nâng cao tính năng như điều khiển nguồn tài nguyên dự trữ băng thông đáp ứng các yêu cầu đặc biệt QoS cũng góp phần nâng cao độ an toàn và tin cậy của mạng cũng như có thể mở rộng các dịch vụ mạng trong tương lai

Từ tính cấp thiết nêu trên tôi chọn đề tài “Đảm bảo chất lượng của luồng âm thanh trực tuyến” Luận văn sẽ đi sâu vào tìm hiểu những kiến thức cơ bản về chất lượng dịch vụ được áp dụng cho đa phương tiện nói chung và luồng âm thanh trực tuyến nói riêng Phân tích và đánh giá các mô hình, các công nghệ áp dụng cho luồng âm thanh trực tuyến

Nội dung được trình bày trong 3 chương:

CHƯƠNG I: TỔNG QUAN VỀ CHẤT LƯỢNG DỊCH VỤ

Các vấn đề về chất lượng dịch vụ nói chung và chất lượng dịch vụ của luồng

âm thanh thời gian thực:

- Các khái niệm về QoS và các tham số đánh giá chất lượng của dịch vụ mạng

- Phân tích các nguyên nhân ảnh hưởng đến chất lượng dịch vụ mạng nói chung và chất lượng dịch vụ của luồng âm thanh thời gian thực nói riêng

- Phân tích các giao thức truyền file để chỉ ra các giao phù hợp với mô hình truyền file thời gian thực Đặc biệt đi sâu phân tích là giao thức RTP và RTSP

CHƯƠNG II CHẤT LƯỢNG DỊCH VỤ CỦA LUỒNG ÂM THANH TRÊN INTERNET

- QoS lớp ứng dụng: Phân tích các cơ chế ảnh hưởng đến QoS ở cấp ứng dụng từ đó chỉ ra những đặc điểm quan trọng để lựa chọn khi tiến hành phát triển các ứng dụng đa phương tiện cho Internet Các đối tượng được xem xét và phân tích là: truyền gói, điều chỉnh lỗi, thích ứng, bộ đệm nhận

- QoS lớp mạng: Cung cấp cho người dùng các cơ chế khác nhau của lớp mạng để đạt được các mức QoS của mạng hoặc phân biệt các lớp QoS trong Internet Tiến hành phân tích những ưu nhược điểm của từng dịch vụ để đưa mô

Trang 13

hình chuẩn khi tiến hành cài đặt các dịch vụ truyền âm thanh thời gian thực Các dịch vụ được đề cập đến là: Đánh dấu quyền ưu tiên tương đối, dịch vụ đánh dấu, dịch vụ tích hợp, dịch vụ phân biệt, chuyển mạch nhãn

CHƯƠNG III THỬ NGHIỆM ỨNG DỤNG WEBAUDIO VỚI RTSP

- Trình bày bối cảnh, nhu cầu và lý do cần thiết lựa chọn phương án thực nghiệm Phân tích các giao thức để lựa chọn giao thức phù hợp tiến hành làm thực nghiệm

- Tiến hành cài đặt, thực thi, bắt gói tin và phân tích gói tin để thấy được cách thức hoạt động và chất lượng của giao thức từ đó đưa ra các đánh giá về mô hình thực nghiệm

Trang 14

CHƯƠNG I: TỔNG QUAN VỀ CHẤT LƯỢNG DỊCH VỤ CỦA LUỒNG ÂM

THANH TRỰC TUYẾN

Các ứng dụng trực tuyến đa phương tiện còn được biết đến như là các ứng dụng truyền thông liên tục và ngày càng trở nên phổ biến trên Internet Có ba yếu tố đáng chú ý quyết định đến sự phát triển Thứ nhất, ngày nay người dùng có cơ sở để

mở rộng đa phương tiện như âm thanh và hỗ trợ xây dựng video (ví dụ Card âm thanh, máy thu, thiết bị phần cứng và phần mềm) Thứ hai, công nghệ Internet hiện tại, bao gồm cả giao thức mới được thiết kế đặc biệt để truyền tải đa phương tiện (ví

dụ, RTP, RSVP và RTSP) và việc thử nghiệm các phần mềm đa phương tiện luôn sẵn sàng cho sự phát triển Thứ ba, sự phát triển nhanh chóng của Internet đặc biệt

là dịch vụ World Wide Web(WWW)đã thu hút con người tìm hiểu về các khả năng cũng như dịch vụ online mới lạ của Internet Đồng thời, họ cũng dành sự quan tâm ngày càng tăng cho các ứng dụng trực tuyến trên Internet

Internet ban đầu được thiết kế để truyền dữ liệu đơn giản, chẳng hạn như trao đổi tin nhắn (Email), chuyển tập tin (FTP) hoặc truy cập từ xa (Telnet) giữa các máy tính liên kết nối Các ứng dụng này yêu cầu tài nguyên hạn chế hoặc yêu cầu thời gian lỏng lẻo Điều này dẫn đến thiết kế cho mạng thường đơn giản và hạn chế các dịch vụ nỗ lực tối đa

Theo thời gian, Internet trở thành biểu tượng của sự phát triển Ban đầu nó là một mạng nghiên cứu của quân đội Sau đó Internet đã thu hút được nhiều người sử dụng và bây giờ người sử dụng biết đến với những dịch vụ tiện lợi của liên mạng trên toàn thế giới Lấy ý tưởng sử dụng Internet cho truyền thông âm thanh thời gian thực và video hoặc các ứng dụng theo yêu cầu, là kết quả tất yếu của sự phát triển Phần lớn Internet đã bị quá tải nặng bởi vì khi các dịch vụ nỗ lực tối đa chia sẻ băng thông công bằng lại trở nên tắc nghẽn Điều này làm gia tăng các biến thiên trễ

và được gọi là Jitter và mất gói(packit loss)

Khi mạng tắc nghẽn, các luồng trực tuyến thời gian thực là nguyên nhân chính tạo ra tắc nghẽn Bởi vì chúng cần băng thông rộng hơn các ứng dụng khác Các ứng dụng thời gian thực làm chậm mạng và việc truyền dữ liệu sẽ mất thời gian hơn cho tới khi hoàn thành Các ứng dụng khác, mất dữ liệu có thể truyền lại Các ứng dụng thời gian thực thì ngược lại, chúng có thể không sử dụng được dưới tải nặng Các ứng dụng thời gian thực mà chậm thì trở nên lỗi thời

1.1 Chất lượng dịch vụ (Quality of Service:QoS)trên Internet

QoS được cung cấp bởi các ứng dụng đa phương tiện trên Internet là một vấn

đề quan trọng đối với sự thành công của việc cung cấp dịch vụ

1.1.1 Khái niệm về chất lượng dịch vụ (QoS)

QoS nghĩa là giới thiệu một yếu tố dự đoán và nhất quán trong cách nhận biết

về mạng hiện tại Ở góc độ khác, nó có nghĩa là thu được hiệu quả truyền tải cao hơn thông qua mạng Trong trường hợp khác, QoS chỉ đơn giản là phương tiện phân

Trang 15

biệt lớp của dịch vụ dữ liệu Nó cũng có thể có nghĩa là để phù hợp với phân bổ tài nguyên mạng với đặc điểm của các dòng dữ liệu cụ thể

Để hiểu được QoS ta sẽ đi tìm hiểu kỹ hai từ chất lượng và dịch vụ

Chất lượng(Quality) trong hệ thống mạng thường được sử dụng để mô tả các quá trình cung cấp dữ liệu một cách nhất định, đôi khi đáng tin cậy hoăc đơn giản tốt hơn bình thường Nó bao gồm các khía cạnh của mất dữ liệu, trễ tối thiểu hoặc tiểm ẩn và biến đổi trễ Xác định việc sử dụng hiệu quả nhất của tài nguyên mạng, chẳng hạn như khoảng cách ngắn nhất hay con đường tối thiểu tắc nghẽn cũng là một vấn đề được thể hiện bằng chất lượng

Từ dịch vụ có nhiều nghĩa, nó được dùng để mô tả một cái gì đó cho người sử dụng cuối của một mạng Có thể cung cấp một loạt các dịch vụ, từ các dịch vụ mức ứng dụng như Email, WWW,… tới các mạng hoặc các dịch vụ mức liên kết như các dịch vụ kết nối đầu cuối

Có thể đưa ra được định nghĩa đơn giản nhất: QoS là thước đo mạng tốt như thế nào và phương tiện để xác định đặc tính của một dịch vụ mạng cụ thể Theo đó, chuẩn ISO định nghĩa QoS như một khái niệm để chỉ ra một dịch vụ mạng như thế nào là “tốt” Vì vậy, QoS cung cấp các phương tiện để đánh giá dịch vụ mạng

1.1.2 Các tham số QoS

Tham số QoS cung cấp phương tiện để xác định yêu cầu người sử dụng có thể hoặc không thể được hỗ trợ bởi các mạng cơ bản Một tập hợp các tham số QoS [1] phù hợp với đặc trưng chất lượng dịch vụ của kết nối hoặc luồng dữ liệu là các tham

số sau:

Độ trễ(Delay)

Độ trễ của gói tin là khoảng thời gian một gói tin đi từ người gửi thông qua mạng cho tới người nhận Độ trễ cao hơn giữa người gửi và người nhận, làm cho thông tin không nhảy cảm trở thành lặp phản hồi, do đó, giao thức trở nên ít nhạy cảm đối với thay đổi nhỏ ở trong mạng Đối với tương tác hoặc ứng dụng thời gian thực sự xuất hiện của trễ làm cho hệ thống không đáp ứng và trong nhiều trường hợp hệ thống không sử dụng được

Biến thiên trễ(Jitter)

Sự biến thiên trễ là sự khác biệt về trễ của các gói khác nhau trong cùng một luồng lưu lượng Biến thiên trễ chủ yếu do sự sai khác về thời gian xếp hàng của các gói liên tiếp trong một luồng gây ra và là một trong vấn đề quan trọng của QoS Khi biến thiên nằm vào khoảng dung sai định nghĩa trước thì nó không ảnh hưởng tới chất lượng dịch vụ, ngược lại biến thiên trễ quá lớn sẽ làm cho kết nối mạng bị ngắt quãng Đối với các ứng dụng thời gian thực không thể chấp nhận Jitter lớn Jitter lớn có được xử lý bằng cách tăng bộ đệm, song nó lại làm tăng Delay

Băng thông(Bandwidth)

Tốc độ truyền dữ liệu tối đa có thể được duy trì giữa hai điểm kết nối được gọi

là băng thông mạng(Bandwidth) Với lưu ý, băng thông không chỉ bị giới hạn bởi

cơ sở hạ tầng vật lý của giao thông mạng, mà còn cung cấp trên một ràng buộc băng thông sẵn có, nhưng cũng bị giới hạn bởi số luồng chia sẻ tài nguyên chung trên đường truyền Băng thông hữu hạn là sử dụng như một giới hạn trên của tốc độ

Trang 16

truyền dữ liệu, trong khi biểu thức thông lượng(Thoughtput) là được sử dụng như một phép đo tức thời của tỷ lệ trao đổi dữ liệu thực tế giữa hai thực thể Ví dụ, có một băng thông nhất định dùng trao đổi giữa hai nốt, nhưng số lượng dữ liệu mà chúng thực sự truyền được xác định bởi thông lượng của chúng Thông lượng dữ liệu của một ứng dụng thường xuyên thay đổi tuỳ thuộc vào nhu cầu sử dụng của ứng dụng

dữ liệu Thông thường, ghép dữ liệu trong bộ đệm, sẽ làm cho độ trễ tăng lên và vì vậy làm giảm độ đáp ứng

Các yêu cầu QoS cần phải được thoả thuận giữa người dùng đầu cuối tại thời điểm kết nối hoặc thiết lập luồng dữ liệu

1.1.3 Các nguyên nhân ảnh hưởng đến chất lượng dịch vụ

1.1.3.1 Nguyên nhân trễ(Delay)

Delay từ người gửi đến người nhận của một luồng dữ liệu là trễ tích luỹ thông qua toàn bộ lưu lượng dữ liệu dạng đường ống bao gồm việc mã hóa người gửi và tạo gói, truyền qua mạng truyền dẫn, tiếp nhận và giải mã

Các loại trễ như mã hoá và giải mã là một khoảng cố định trong khi các tính toán là không đơn định do sự thay đổi thường xuyên của mạng hoặc do điều kiện lập lịch của hệ thống

Trễ cực tiểu từ người gửi đến người nhận bao gồm tất cả thời gian bị trễ mà không thay đổi các đơn vị truyền nhận Trễ cực đại từ người gửi đến người nhận được xác định bằng tổng của trễ cực tiểu cộng với cực đại của jitter Ta có phương trình sau:

Min(Delay)≤ Delay≤Min(Delay) + Max(Jitter) (1.1)

Trễ truyền tải của các packet(hoặc Cell) trong mạng là sự tích luỹ của thời gian

xử lý trong tất cả các bộ định tuyến(Router) trung gian (hoặc Switch) giữa nút nguồn, nút đích và thời gian truyền trên các đường liên kết vật lý Thời gian truyền trên liên kết mạng phụ thuộc vào môi trường vật lý, các giao thức lớp liên kết, và các đặc điểm của lớp liên kết

Thời gian xử lý tại các nút mạng phụ thuộc vào cơ chế chuyển tiếp trong sử dụng Thiết bị chuyển mạch(Switch) hoặc thiết bị định tuyến(Router) xử lý các gói trong phần cứng đòi hỏi rất ít thời gian Những thiết bị như vậy được sử dụng trong mạng lõi mà ở đó các liên kết được tập trung Các giải pháp dựa trên phần mềm phụ thuộc vào việc triển khai thực hiện chúng và các công cụ xử lý

Trang 17

Thời gian xử lý đóng gói và mã hoá của người gửi, giải mã tại đầu người nhận phụ thuộc chính vào việc thực hiện của bộ xử lý và thuật toán mã hóa và giải mã Một vài cách thức mã hóa (ví dụ ADPCM) cần rất ít sự tính toán trong khi có các cách thức khác (ví dụ: GSM, mã hóa hội thoại [5]) cần nhiều sự xử lý Tùy theo lộ trình mã hóa, thời gian để mã hóa hệ thống media có thể thay đổi Tuy nhiên sự thay đổi này rất khó nhận biết

1.1.3.2 Nguyên nhân của biến thiên trễ(Jitter)

Khi sự bùng nổ lưu lượng, các gói tin phải xếp hàng chờ được lưu thông đó là nguyên nhân chính gây nên biến thiên trễ(Jitter) Tuy nhiên hàng đợi không phải là nguyên nhân duy nhất của biến thiên trễ Jilter cũng là tạo tác của quá trình lập lịch trong địa chỉ cuối và phần mềm cơ sở để chuyển tiếp gói tin trong bộ định tuyến

Hàng đợi gói tin(Packet Queuing)

Nếu các gói tin di chuyển dọc theo một đường và va chạm trên chiều dài hàng đợi Chúng bị trễ tương tự Trễ đầu cuối có thể là cao nhưng phương sai trễ là bằng không Như vậy jilter là nguyên nhân gây ra khi mà các gói liên tục trải qua các thời gian chờ đợi khác nhau ở trong hàng đợi

Hàng đợi tăng lên trong Switch và Router khi mà tổng tỷ lệ dữ liệu đến cho một liên kết đi lớn hơn băng thông của liên kết này gửi đi Trong trường hợp lưu lượng cùng truyền hàng loạt làm cho các băng thông liên kết sẵn có ảnh hưởng gọi

là phân cụm gói tin(packet clustering) [2] Luồng lưu lượng truyền loạt, cạnh tranh băng thông trên một liên kết mạng sẽ tạo ra hàng đợi trước giao diện đi của Router

Vì vậy một vài gói của luồng có thể đến trước trong khi các gói kia vẫn xếp hàng Các gói tin của gói tin phân cụm sẽ được gửi đi không lâu sau một gói khác Hình 1.1.3.2 Minh hoạ các sự phân cụm gói tin phát triển như thế nào Tại tất cả các bước truyền tiếp theo các gói tin đến đồng thời và chúng có thể lặp lại tương tự Vì vậy số cụm có thể tăng với số lượng các bước truyền dọc theo đường truyền

Hình 1.1.3.2: Phân cụm gói tin

Packet Clustering

Trang 18

Tác động của chiều dài đường dẫn đến biến đổi trễ đầu cuối rất phức tạp, biến đổi trễ cực đại tăng tuyến tính với các bước truyền trong đường dẫn Tuy nhiên, Jitter trung bình ít phụ thuộc vào số bước truyền khi mà thời gian chờ trong hàng đợi độc lập thường một phần triệt tiêu lẫn nhau

Nếu một gói tin được lập lịch theo kiểu vào trước, ra trước (FIFO), sự khác biệt trễ giữa hai gói tin liên tiếp là ít nhất có một hàng đợi tăng hoặc giảm đi trong thời gian chờ Giả định rằng hàng đợi là nguyên nhân duy nhất của Jitter Các biến đổi trễ cực đại được giới hạn chặt chẽ trong trường của hàng đợi FIFO Nó được xác định bằng tổng chiều dài cực đại của hàng đợi trên đường dẫn Khi sử dụng lập lịch cải tiến và cơ chế xếp hàng Một số luồng có thể không được phục vụ Sẽ dẫn đến các biến đổi trễ không bị giới hạn và phức tạp

Để khắc phục các vấn đề của biến đổi trễ gây ra bởi hàng đợi trong mạng Các ứng dụng nhạy cảm cần được triển khai các dịch vụ cho phép giới hạn tổng thời gian giành cho hàng đợi Có cơ chế đặt trước tài nguyên như RSVP

Lập lịch(Scheduling)

Ngoài Jitter tạo ra bởi hàng đợi, quá trình lập lịch trong máy người dùng và thiết bị chuyển mạch(Switch) hoặc định tuyến(Router) là một phần trong các biến thiên trễ

Hầu hết các hệ điều hành hiện tại cung cấp đa nhiệm Hệ điều hành đa nhiệm dựa trên một tiến trình lập lịch kích hoạt và vô hiệu hoá các quá trình riêng lẻ một cách thích hợp, điều này ngăn cản các ứng dụng quan trọng, hạn chế thời gian và các ứng dụng thời gian thực

Trong thực tế các ngắt phần cứng(ví dụ: ngắt từ thiết bị âm thanh) ngăn chặn

và xử lý trong không gian của nhân Quá trình xử lý có thể thực hiện dưới dạng xử

lý dữ liệu(ví dụ: các ứng dụng âm thanh có thể mã hoá và gửi dữ liệu âm thanh) không được lập lịch ngay Các khoảng thời gian giữa hai ngắt và khoảng thời gian lập lịch cũng gây ra các biến đổi trễ

Đối với âm thanh thời gian thực, thực nghiệm cho thấy biến thiên trễ tạo ra bởi lập lịch thiết bị người dùng rất lớn Các ứng dụng đòi hỏi trễ lớn nhất là vài trăm mili giây Khi truyền tải và xử lý các âm thanh trễ lớn nhất có thể chấp nhận được là vài trăm mili giây Trễ càng nhỏ càng tốt Ngoài ra trong trường hợp truyền thông

âm thanh trực tuyến, các gói âm thanh được chia thành các gói nhỏ thì thời gian khoảng 20ms đến 40 ms trên một mẫu âm thanh

Hệ điều hành đã phân biệt rất rõ ràng giữa nhân và không gian người dùng Có

ba chọn lựa cơ bản của vấn đề lập lịch Thứ nhất, có thể thay đổi không gian quá trình lập lịch cho nhân để có thể kiểm soát ngay trong khoảng thời gian khi có một

sự kiện quan trọng Thứ hai, giành sự ưu tiên và ưu tiên cao cho thời gian và các sự kiện quan trọng đó Thứ ba, thực hiện các ứng dụng trong không gian của nhân

Bù đắp Jitter

Biến đổi trễ tạo ra bởi các hàng đợi và bởi quá trình lập lịch làm toàn bộ trễ đầu cuối tăng lên trong quá trình truyền gói tin Khi triển khai các ứng dụng thời gian thực hoặc các ứng dụng có tính chất tương hỗ thì thuộc tính quan trọng nhất là trễ đầu cuối

Trang 19

Khi các gói tin bị lỡ thời điểm truyền lại(chỉ khoảng vài phần nghìn giây) ngay lập tức bị loại từ ứng dụng thu nhận Các gói dữ liệu chỉ đến chậm một chút làm cho bên nhận thích ứng với bộ đệm nhận để phù hợp với việc nhận các gói dữ liệu mới

Vì vậy, phát lại điểm trễ làm cải thiện chất lượng trễ Nhưng làm giảm các đáp ứng thời gian thực Điều này cho thấy sự cân bằng giữa tính tương tác và độ tin cậy có thể ảnh hưởng nhiều đến QoS của luồng âm thanh trực tuyến

1.1.3.3 Nguyên nhân của mất gói(packet loss)

Về bản chất mạng chuyển mạch gói thường không đáng tin cậy Những phần quan trọng của Internet bị ảnh hưởng của việc truyền dữ liệu sai lệch Đặc biệt là việc mất gói Các gói tin thường bị loại do tràn hàng đợi trong Router hoặc do máy của người dùng Dẫn đến tỷ lệ mất gói là thuộc tính quan trọng của QoS cho những ứng dụng đa phương tiện

Khi gói tin dữ liệu video bị mất Các ứng dụng video có thể cập nhật các khung hình video không đầy đủ Các hình ảnh cũng có thể trở nên không phù hợp hoặc hình ảnh có thể thay đổi đột ngột khi đến gói tin liên tiếp Tuy nhiên trong ứng dụng âm thanh mất gói tin dẫn đến tiếng kêu nổ nhỏ và các khoảng trống trong tín hiệu âm thanh dẫn đến bài phát biểu khó hiểu và âm nhạc trở lên không thú vị Mắt con người là sự tích hợp thông tin thị giác trong khi tai đóng vai trò như là một sự khác biệt Trong thực tế dữ liệu hình ảnh có tính chất dự phòng hơn tín hiệu âm thanh

Hơn nữa, những gói tin bị mất trong quá trình truyền từ nguồn tới đích còn do một số lý do sau:

- Tắc nghẽn trong hệ thống: Nếu một nút mạng ở ngoài không gian bộ đệm thì các gói tin sẽ bị loại bỏ Một Router thường có bộ đệm đến, bộ đệm hệ thống và bộ đệm giao diện đi Như vậy loại bỏ đầu vào xảy ra khi các bộ định tuyến không thể

xử lý các gói dữ liệu hàng đợi đến đủ nhanh Loại bỏ đầu ra thì ngược lại xảy ra khi các đường liên kết đi quá bận Đây rõ ràng không phải là một vấn đề về định tuyến

mà là vấn đề về băng thông mạng trong liên kết

- Router sử dụng việc loại bỏ các gói tin như là cơ chế để tránh tắc nghẽn mạng và ngăn cản tràn hàng đợi Kỹ thuật như vậy gọi là cơ chế phát hiện sớm ngẫu nhiên(Random Early Detection: RED) Bằng cách loại bỏ các gói tin khi hàng đợi đạt giới hạn cao nhất

- Các gói dữ liệu hỏng là kết quả của truyền dữ liệu sai bị loại bỏ Bít lỗi được

sử dụng để kiểm tra và được đặt trong phần tiêu đề gói tin

Tầm quan trọng của mất gói phụ thuộc vào ứng dụng, trong các ứng dụng không gấp về thời gian, mất gói có thể được phục hồi bởi phương tiện truyền lại Tuy nhiên với ứng dụng không cho phép hạn chế về thời gian thì việc bổ sung, mất

gói tin trở nên khó khăn Một cơ chế Forward Error Correction (FEC) được phát

triển để phục hồi mất gói tin Đây là cơ chế sửa lỗi trong băng tần nhằm phục hồi sự mất gói bằng cách dự phòng và do đó chỉ thực hiện tốt chừng nào mất gói bị cô lập

ở một mức độ nào đó

Delay, Jitter and Packet Loss

Trang 20

Trong phạm vi QoS các thuộc tính như: Delay, Jitter and Packet Loss cần có

sự tương quan Trong mạng chuyển mạch gói như mạng Internet các thuộc tính QoS phải được chú trọng

Với mong muốn tỷ lệ mất gói của các luồng càng cao thì Jitter cao Trong thực

tế điều này đúng với trường hợp nghẽn mạng nặng nhưng trong một số trường hợp gói tin đến tỷ lệ mất gói cao nhưng Jitter không nhất thiết phải cao hoặc cũng có trường hợp tỷ lệ các luồng dữ liệu tỷ lệ mất gói thấp nhưng Jitter cao

Giả sử Jitter được tạo ra do phần lớn các gói tin xếp hàng trong các nút mạng,

là kết quả của quá trình truyền loạt các gói và quá trình phân cụm, và rõ ràng rằng không có mối quan hệ tiềm ẩn nào giữa mất gói và biến đổi trễ cho nghẽn đường truyền thấp Hàng đợi đầy không dẫn đến Jitter, nó là sự lớn lên và co lại của chiều dài hàng đợi được mô tả trong biến thiên trễ Vì vậy các luồng truyền loạt cạnh tranh băng thông trên liên kết ra là nguyên nhân của biến thiên trễ mà không phụ thuộc vào mức độ tắc nghẽn Ngay cả khi băng thông hầu như không được sử dụng, cũng có thể có biến đổi trễ gây ra bởi cách truyền loạt

1.1.4 Những điều kiện QoS cho luồng âm thanh thời gian thực

1.1.4.1 Thông lƣợng(Throughput)

Các yêu cầu thông lượng của ứng dụng âm thanh trực tuyến phụ thuộc hoàn toàn vào chương trình mã hoá được sử dụng cho truyền tải Các định dạng mã hóa thường được xác định bởi các yêu cầu chất lượng âm thanh của ứng dụng

Mã hoá giọng nói:

Kỹ thuật mã hoá giọng nói truyền thống là kỹ thuật số, với 64 kbps gọi là Điều chế xung mã(Pulse Code Modulation : PCM) Tương đương với hệ thống âm thanh của điện thoại Vì thế, có thể gọi là chất lượng âm thanh điện thoại Các lược đồ mã hóa được định nghĩa trong tiêu chuẩn G.711 ITU Các tín hiệu mono tương tự được lấy mẫu 8000 lần mỗi giây, mỗi mẫu được mã hóa trong 8 bit và sử dụng không nén Tỷ lệ bit âm thanh chất lượng điện thoại là 8bits × 8000Hz = 64kbps

Từ những năm 1980, một số kỹ thuật mã hoá và nén được phát triển cho phép

mã hoá kỹ thuật số hiệu quả hơn so với G.711 Chất lượng điện thoại cũng đạt tới 32kbps, chỉ đơn giản là bằng cách áp dụng các kỹ thuật mã hoá tinh vi hơn như Điều chế mã xung vi sai(Differential pulse code modulation: DPCM) Chất lượng

âm thanh cũng có thể được cung cấp thấp hơn với Sự điều chế mã xung vi sai tương hợp ADPCM (adaptive differential pulse code modulation) với 40,32 ,24,16 kbps Các thuật toán mã hoá như Linear Predictive Coding (LPC) or Code Excited Linear Prediction (CELP) có thể làm giảm tỷ lệ bit thấp là 2.4 hoặc 4,8 kbps cho âm kỹ thuật số

Trang 21

Bảng 1.1.4.1a: Chất lượng Voice mã hóa và thông lượng

 Mã hoá âm thanh chất lƣợng cao

Chất lượng CD(compact discs) thường được công nhận là một mã hóa âm thanh chất lượng cao.Tiêu chuẩn đĩa CD âm thanh được dựa trên lấy mẫu tín hiệu tương tự ở 44.1 kHz, mỗi mẫu được mã hóa với 16 bit Kết quả 705,6 kbps cho một kênh đơn âm Một đĩa CD âm thanh nổi, yêu cầu để truyền tải đầy đủ âm thanh nổi trong một đĩa CD chất lượng là 1.411,2 kbps

Ngày nay, phát triển một số kỹ thuật nén hoặc mã hoá cho chất lượng đĩa CD

ví dụ MPEG Layer-1 cho phép mã hoá âm thanh nổi với tốc độ 384kbps Cả hai kênh được ghép trên cùng một luồng Với sự ra đời chương trinh MUSICMA cho MPEG Layer-2 cho phép mã hoá chất lượng âm thanh đĩa CD với tỷ lệ trung bình

248 hoặc 192 kbps Việc mã hoá càng phát triển với MPEG Layer-3 chất lượng âm thanh đĩa CD đạt được tới 64kbps trên một kênh âm thanh

Bảng 1.1.4.1b: Chất lượng CD mã hóa và thông lượng

1.1.4.2 Trễ(Delay)

Các yêu cầu chuyển tiếp trễ cho truyền tải của luồng âm thanh liên tục phụ thuộc vào các ứng dụng đa phương tiện Trong phân phối dữ liệu âm thanh thuần tuý ( truyền đơn hướng ) có thể chịu được trễ kéo dài Bộ đệm nhận lớn có thể bù đắp biến đổi trễ lớn trong hệ thống mạng và hệ thống đầu cuối Điều này dĩ nhiên không phải là trường hợp của các ứng dụng tương tác như điện thoại Internet hoặc các hội nghị âm thanh trực tuyến Là các ứng dụng đòi hỏi tính đáp ứng cao Vì vậy, tính hai chiều hoặc trễ đi đến của các ứng dụng trực tuyến là rất quan trọng

Việc nhận xét của người dùng đối với các ứng dụng thời gian thực là rất chủ quan Nghiên cứu ITU cho thấy rằng hầu hết những người sử dụng điện thoại thì trễ giữa hai đầu máy lớn hơn khoảng 300ms với các kết nối đơn chưa nói kết nối song công Tuy nhiên tuỳ thuộc vào nhận thức của người sử dụng Thông thường người

sử dụng có thể chấp nhận trễ trong khoảng 300-800ms[7] Trong các cuộc hội thoại trực tuyến người sử dụng không thể chấp nhận trễ đến gần một giây

Trang 22

Với truyền dẫn song công, một khó khăn kỹ thuật nằm ở chỗ sóng phản hồi có thể nghe được Nếu trễ khứ hồi của người gửi đến người nhận lớn hơn một ngưỡng nhất định nào đó mà không có biện pháp cụ thể để làm giảm tiếng vang ITU đã xác định 24ms là giới hạn trên của truyền tải trễ có thể huỷ bỏ được

1.1.4.3 Biến thiên trễ(Delay Jitter)

Luồng âm thanh trực tuyến có thể là phương tiện truyền thông nhạy cảm nhất của biến thiên trễ Nếu những gói mang thông tin âm thanh phân bổ rộng tạo ra trễ lan truyền, hệ thống thu nhận cần chờ đủ thời gian, gọi là vùng đệm hay trễ phát lại, trước khi phát lại dữ liệu để đảm bảo hầu hết các khối đến trễ trong thời gian đó Nếu không một số đáng kể các gói tin có thể đến trễ, tạo ra những khoảng trống trong các tín hiệu dẫn đến âm thanh bị biến dạng, và chất lượng âm thanh không thể chấp nhận được

Bộ đệm nhận có cơ chế lưu trữ tạm thời các gói dữ liệu đến cho đến thời điểm chúng được đọc lại Các gói tin có thể được đọc lại một cách suôn sẻ mà không có khoảng trống trong các tín hiệu Cơ chế bộ đệm cũng thường gọi là sự bù trễ Cơ chế bù trễ có ưu điểm Nhưng có nhược điểm như sau: Thứ nhất, trễ được bổ sung thêm ở người nhận Thứ hai, bộ nhớ đệm cần phải có hệ thống tiếp nhận

Quá trình xác định vùng đệm tốt nhất hoặc trễ phát lại(Playout delay) được gọi

là phát lại trễ ước tính và được quyết định bởi hai tham số sau: Giá trị cực đại toàn

bộ trễ mà ứng dụng hoặc người dùng có thể cho phép Khả năng bộ đệm của hệ thống tiếp nhận

1.1.4.4 Độ tin cậy (Reliability)

Lỗi bít thường làm mất các gói tin trong giao tiếp vì vậy khi mất gói cần phải kiểm tra các yêu cầu độ tin cậy của các luồng ứng dụng Lỗi bít thường được xử lý trên lớp giao vận chứ không phải xem xét các ứng dụng

Khi truyền tải âm thanh sai lệch con người thường nhạy cảm hơn là truyền tải video Điều này là do việc xử lý âm thanh và hình ảnh khác nhau vì vậy yêu cầu QoS của âm thanh là rất khắt khe Tỷ lệ lỗi tối đa chấp nhận được trong truyền thông âm thanh phụ thuộc nhiều vào các ứng dụng, chương trình mã hoá, sự nhạy cảm của người sử dụng

Các nghiên cứu [9] cho thấy rằng 5% dữ liệu sự sai lệch về âm thanh có thể được sử dụng trong giao tiếp giữa con người Tỷ lệ mất gói 1% là có tạp âm Tỷ lệ mất gói càng cao tạp âm càng nhiều và giao tiếp càng khó hiểu Tỷ lệ mất gói 25% truyền vô ích

Mất gói tin không chỉ đơn giản được giải quyết bằng phương pháp truyền lại Nếu chỉ mất một vài gói ta có thể dùng phương pháp phát lại một số Frame Nhưng cũng có một phương pháp khác đó cho phép ngoại suy các Frame bằng cách xác định giá trị xấp xỉ từ các Frame trước đây đã nhận Và cũng có một cách khác là nội suy các Frame từ Frame trước nó và Frame sau nó Cả hai ngoại suy và nội suy được gọi là kỹ thuật tiên đoán, tiếp cận chúng là để cung cấp các ước tính cho thông tin bị mất Triển khai các nguyên tắc của các kỹ thuật tiên đoán cho việc phục hồi lỗi truyền dẫn thường được gọi là lỗi che giấu

1.2 Giao thức đa phương tiện trên Internet

Trang 23

Giao thức Internet hiện nay được thiết kế để sử dụng trong kết nối hệ thống của mạng chuyển mạch gói Chức năng hoặc mục đích của nó là di chuyển các gói thông qua một tập hợp các kết nối của mạng Điều này được thực hiện bằng cách chuyển gói dữ liệu từ một mô đun Internet khác cho đến đích Lựa chọn đường truyền và chuyển tiếp các gói tin theo đường truyền đó được gọi là định tuyến Các gói tin được chuyển modul Internet tới điểm khác dựa trên viêc thông dịch địa chỉ Internet trong gói tin

Trong những ứng dụng truyền thông đa phương tiện, yêu cầu đảm bảo khắt

khe về thời gian thực (không cho phép có thời gian trễ lớn, jitter) Việc các gói tin

đến không liên tục, đều đặn làm cho chất lượng hình ảnh, hoặc âm thanh thu được thấp Rất có thể gây ra vấp hình, méo tiếng Để đáp ứng được những yêu cầu này, một giao thức thời gian thực cần có các yếu tố:

- Hộ trợ việc định tuyến muticast: Với các ứng dụng tryền thông đa phương

tiện đòi hỏi thời gian thực, có sự phân phối giống dữ liệu từ một nguồn tới nhiều

đầu cuối nhận dữ liệu thì việc hỗ trợ multicast là rất cần thiết Đây là một yêu cầu

rất quan trọng Khi đó, sẽ tồn tại 1 nguồn phát và rất nhiều nguồn thu, một máy chủ xuất luồng dữ liệu thời gian thực đến rất nhiều máy khách Nếu ta sử dụng truyền unicast, tải trọng tác động lên máy chủ rất lớn Trong khi đó, nếu mạng có hỗ trợ truyền multicast, ta chỉ việc xuất một luồng duy nhất từ máy chủ tới một địa chỉ multicast Sau đó tại các nốt mạng, luồng dữ liệu sẽ được nhân lên và chuyển tiếp tới những địa chỉ đích

- Chấp nhận một số gói tin bị lỗi: Không thể đợi để truyền lại các gói, đoạn,

gam dữ liệu bị thất lạc Việc truyền lại các dữ liệu bị thất lạc hoặc bị lỗi sẽ chiếm khá nhiều thời gian Nó sẽ làm tăng lượng tải trên đường truyền đồng thời kéo dài thời gian trễ của các gói tin

- Cần kết hợp với một thông số về thời gian (nhãn thời gian) kèm theo gói dữ liệu: Với các tín hiệu thời gian thực, đặc biệt là tín hiệu video, việc khôi

phục đồng bộ tại phía thu là rất quan trọng, do đó đòi hỏi nhãn thời gian kèm theo

để phục vụ cho việc tái tạo lại dữ liệu tại nơi nhận Đặc biệt, khi tín hiệu video được

mã hoá theo từng khung hình, mỗi khung hình được vận chuyển trong nhiều gói RTP Khi đó nhãn thời gian sẽ giúp ta phân định từng nhóm gói tin tương ứng với một hình một cách dễ dàng

Sau đây ta sẽ đi phân tích một số giao thức:

Trang 24

IP Dadalink Physical

Receiving

TCP End to End Commmunication Router Router

Hình 2.1: Các giao thức và dịch vụ đa phương tiện

1.2.1 Giao thức TCP ( Transmision Control Protocol)

TCP là một giao thức kiểu có liên kết (Connection – Oriented), tức là phải có

giai đoạn thiết lập liên kết giữa một cặp thực thể TCP trước khi truyền dữ liệu TCP thiết lập kết nối hai đường giữa hai hệ thống cần trao đổi thông tin với nhau, thông tin trao đổi giữa hai hệ thống được chia thành các gói TCP có những đặc điểm sau:

Sự bắt tay: Hai hệ thống cần kết nối với nhau cần phải thực hiện một loạt

các sự bắt tay để trao đổi những thông tin về việc chúng muốn kết nối

Xác nhận: Trong phiên truyền thông, hệ thống nhận dữ liệu cần phải gửi các

xác nhận cho hệ thống phát để xác nhận rằng nó đã nhận được dữ liệu

Trật tự: Các gói tin có thể đến đích không theo thứ tự sắp xếp của dòng dữ

liệu liên tục bởi các gói tin đi từ cùng một nguồn tin theo những đường dẫn khác nhau để đi tới cùng một đích

Phát lại: Khi phát hiện gói tin bị lỗi thì nơi gửi chỉ phát lại những gói tin bị

lỗi nhằm để tránh loại bỏ toàn bộ dòng dữ liệu

Hình 1.2.1a :Hoạt động của giao thức TCP trong việc cung cấp kết nối

Trang 25

Cấu trúc đơn vị truyền tải TCP:

Đơn vị dữ liệu sử dụng trong giao thức TCP được gọi là Segment Khuôn

dạng của Segment được mô tả như hình sau:

Các tham số của khuôn dạng trên có ý nghĩa nhƣ sau:

Source Port (16 bits): Số hiệu của cổng nguồn

Destination Port (16 bits): Số hiệu cổng của trạm đích Số hiệu này là địa chỉ

thâm nhập dịch vụ lớp giao vận (CCISAP Addess) cho biết dịch vụ mà TCP cung cấp là dịch vụ gì

Sequence Number (32 bits): Số hiệu của Byte đầu tiên của Segment trừ khi

bit SYN được thiết lập Nếu bit SYN được thiết lập thì Sequence Number là số hiệu tuần tự khởi đầu (ISN) và Byte dữ liệu đầu tiên là ISN+1 Tham số này có vai trò như tham số N(S) trong HDLC

Acknowledgment Number (32 bits): Số hiệu của Segment tiếp theo mà

trạm nguồn đang chờ để nhận Data offset (4bits): Số lượng từ 32 bit trong TCP

header (Tham số này chỉ ra vùng bắt đầu của vùng dữ liệu )

Reserved (6 bits): Dành để dùng trong tương lai

Control bits: Các bits điều khiển Nếu tính từ trái sang phải:

URG : Vùng con trỏ khẩn có hiệu lực

ACK : Vùng báo nhận (ACK number) có hiệu lực

PSH: Chức năng PUSH

RST: Khởi động lại (reset) liên kết

SYN : Đồng bộ các số liệu tuần tự (sequence number)

FIN : Không còn dữ liệu từ trạm nguồn

Window (16bits): Cấp phát credit để kiểm soát luồng dữ liệu (cơ chế cửa

sổ) Đây chính là số lượng các Byte dữ liệu bắt đầu từ Byte được chỉ ra trong vùng ACK number, mà trạm nguồn đã sẵn sàng để nhận

Checksum (16bits): Mã kiểm soát lỗi (theo phương pháp CRC) cho toàn bộ

Segment

Urgent Pointer (16 bits) : Con trỏ này trỏ tới số liệu tuần tự của Byte đi theo

sau dữ liệu khẩn, cho phép bên nhận biết được độ dài của dữ liệu khẩn Vùng này

chỉ có hiệu lực khi bit URG được thiết lập

Trang 26

Option (độ dài thay đổi): Khai báo các option của TCP, trong đó có độ dài

tối đa của vùng TCP data trong một Segment

Padding (độ dài thay đổi): Phần chèn thêm vào Header để bảo đảm phần

Header luôn kết thúc ở một mốc 32 bits Phần thêm này gồm toàn số 0

Việc kết hợp địa chỉ IP của một máy trạm và số cổng được sử dụng tạo thành

mét Socket Các máy gửi và nhận đều có Socket riêng Số Socket là duy nhất trên

mạng

Điều khiển luồng dữ liệu:

Phương pháp cửa sổ trượt cho phép nới gửi (Sender) có thể gửi đi nhiều gói

tin rồi sau đó mới đợi tín hiệu báo nhận ACK (Acknowledgement) của nơi nhận

(Receiver).Với phương pháp cửa sổ trượt khi cần truyền các gói tin, giao thức sẽ đặt một cửa sổ có kích cố định lên các gói tin Những gói tin nào nằm trong vùng cửa

sổ ở một thời điểm nhất định sẽ được truyền đi

Thiết lập và huỷ bỏ liên kết:

Thiết lập liên kết TCP:

Một liên kết có thể được thiết lập theo một trong hai cách chủ động (active)

và bị động (passive) Nếu liên kết được thiết lập theo cách bị động thì đầu tiên TCP tại trạm muốn thiết lập liên kết sẽ nghe và chờ yêu cầu liên kết từ một trạm khác Tuỳ trường hợp của lời gọi hàm mà người sử dụng phải chỉ ra cổng yêu cầu kết nối hoặc có thể kết nối với một cổng bất kỳ

Với phương thức chủ động thì người sử dụng yêu cầu TCP thử thiết lập một liên kết với một Socket nào đó với một mức ưu tiên và độ an toàn nhất định Nếu trạm ở xa kia đáp lại bằng một hàm Passive open tương hợp hoặc đã gửi một active open tương hợp thì liên kết sẽ được thiết lập Nếu liên kết được thiết lập thành công thì hàm Open success primitive được dùng để thông báo cho người sử dụng biết (cũng được sử dụng trong trường hợp Passive Open) còn nếu thất bại thì hàm Open failure primitive được dùng để thông báo

Huỷ bỏ một liên kết:

Khi không còn nhu cầu trao đổi dữ liệu nữa thì liên kết TCP có thể được huỷ

bỏ Liên kết có thể được huỷ bỏ theo hai cách:

Liên kết được huỷ bỏ một cách bình thường khi toàn bộ dữ liệu đã được truyền hết Tức là hai bên không còn nhu cầu trao đổi dữ liệu nữa

Liên kết có thể bị huỷ bỏ một cách bất thường vì một lý do nào đó Toàn bộ

dữ liệu đang truyền có thể bị mất

Truyền và nhận dữ liệu:

Sau khi liên kết được thiết lập giữa một cặp thực thể TCP thì có thể tiến hành việc truyền dữ liệu Khi nhận được một khối dữ liệu cần chuyển đi từ người sử dụng, TCP sẽ lưu giữ nó tại bộ đệm gửi Nếu cờ PUST được dựng thì toàn bộ dữ liệu trong bộ đệm sẽ được gửi đi hết dưới dạng các TCP Segment Còn nếu cờ PUST không được dựng thì toàn bộ dữ liệu vẫn được lưu giữ trong bộ đệm để chờ gửi đi khi có cơ hội thích hợp

Tại bên nhận, dữ liệu gửi đến sẽ được lưu giữ trong bộ đệm nhận Nếu dữ liệu đệm được đánh dấu bởi cờ PUST thì toàn bộ dữ liệu trong bộ đệm nhận sẽ được

Trang 27

gửi lên cho người sử dụng Còn nếu dữ liệu không được đánh dấu với cờ PUST thì chúng vẫn được lưu trong bộ đệm Nếu dữ liệu khẩn cần phải chuyển gấp thì cờ URGENT được dùng và đánh dấu dữ liệu bằng bit URG để báo rằng dữ liệu khẩn cần được chuyển gấp

Như vậy đây là một giao thức kiểu có liên kết (Connection – Oriented), tức là phải có giai đoạn thiết lập liên kết giữa một cặp thực thể TCP trước khi truyền dữ liệu Trong khi truyền dữ liệu giao thức TCP phải đảm bảo các cơ chế xác nhận việc gởi dữ liệu, đảm bảo xắp xếp đúng thứ tự các gói tin tại bên nhận, phát lại các gói tin bị lỗi hoặc thất lạc Do việc phải đảm bảo những cơ chế này gây lên thời gian trễ lớn, nên giao thức TCP không thể dùng được trong những ứng dụng thời gian thực Ngoài ra với tính chất vốn có của mình, TCP là giao thức được sử dụng để truyền dữ liệu theo kiểu điểm tới điểm, hay nói cách khác TCP chỉ được dùng cho truyền unicast, không thể sử dụng cho truyền multicast

Với những đặc điểm trên, TCP không nên được sử dụng trong việc truyền dữ liệu mang tính thời gian thực

1.2.2 Giao thức UDP (USER DATAGRAM PROTOCOL)

UDP (User Datagram Protocol) là một giao thức kiểu không kết nối, được sử dụng trong một số yêu cầu ứng dụng thay thế cho TCP UDP không thực hiện các giai đoạn thiết lập và huỷ bỏ liên kết, không có các cơ chế báo nhận (Acknowledgement) như trong TCP UDP cung cấp các dịch vụ giao vận không đáng tin cậy Dữ liệu có thể bị mất, bị lỗi hay bị truyền luẩn quẩn trên mạng mà không hề có thông báo lỗi đến nơi gửi hoặc nơi nhận Do thực hiện ít chức năng hơn TCP nên UDP chạy nhanh hơn, nó thường được sử dụng trong các dịch vụ không đòi hỏi độ tin vậy cao Ngoài ra, giao thức UDP còn có thể sử dụng cho truyền multicast

Khuôn dạng của UDP Datagram cụ thể như hình:

UDP Source Port UDP Destination Port

Data

Hình 1.2.2: Khuôn dạng UDP Datagram

Trong đó ý nghĩa của các trườnglà:

UDP Source Port (16 bits) : Cho biết địa chỉ cổng của trạm nguồn Nếu nó

không được chỉ ra thì trường này được thiết lập là 0

UDP Destination Port (16 bits) : Cho biết địa chỉ cổng của trạm đích

UDP Message Length (16 bits): Cho biết kích thước của một UDP Datagram

(kể cả phần Header)

UDP Checksum (16 bits): Là mã kiểm soát lỗi theo phương pháp CRC

Lớp UDP được đặt trên lớp IP, tức là UDP Datagram khi chuyển xuống tầng dưới sẽ được đặt vào IP Datagram để truyền trên liên mạng IP Datagram này được ghép vào một khung tin rồi được gửi tới liên mạng đến trạm đích Tại trạm đích các

Trang 28

PDU được gửi từ dưới lên trên, qua mỗi tầng phần Header của PDU được gỡ bỏ và cuối cùng chỉ còn lại phần dữ liệu như ban đầu được chuyển cho người sử dụng

Do vậy UDP có thể được sử dụng để truyền các dữ liệu thời gian thực Tuy nhiên để đảm bảo đáp ứng được các yêu cầu của các ứng dụng thời gian thực, giao thức UDP phải được kết hợp với một giao thức lớp trên, đó là giao thức RTP

1.2.3 Giao thức truyền thông thời gian thực RTP( Real-Time Transport Protocol)

RTP là một giao thức dựa trên giao thức IP tạo ra các hỗ trợ để truyền tải các

dữ liệu yêu cầu thời gian thực với các yêu cầu:

- Liên tục: Các gói tin phải được sắp xếp theo đúng thứ tự khi chúng đến bên nhận, nếu gói tin bị mất thì bên nhận phải dò tìm hay bù lại sự mất các gói tin này

- Sự đồng bộ: Các khoảng lặng trong tiếng nói được triệt và nén lại để giảm thiểu băng thông cần thiết, tuy nhiên khi đến bên nhận, thời gian giữa các khoảng lặng này phải được khôi phục một cách chính xác

- Sự đồng bộ giữa các phương thức truyền thông: Các tín hiệu tiếng và hình phải được đồng bộ một cách chính xác

- Sự nhận diện phương thức truyền tải: Trong Internet, thông thường cần thay đổi sự mã hoá cho phương thức truyền tải (payload) trên hành trình truyền để hiệu chỉnh thay đổi độ rộng băng thông sẵn sàng hoặc đủ khả năng cho người dùng mới kết nối vào nhóm Một vài cơ chế cần được sử dụng để nhận diện sự mã hoá cho mỗi gói đến

Các dịch vụ cung cấp bởi RTP bao gồm:

- Đa phát đáp thân thiện: (multicast – friendly): RTP và RTCP là kỹ thuật cho

đa phát đáp, cung cấp khả năng mở rộng cuộc hội thoại nhiều bên

- Độc lập thiết bị: RTP cung cấp các dịch vụ cần thiết chung cho phương thức truyền thông thời gian thực nói chung như thoại, video hay bất kỳ một bộ mã hoá, giải mã cụ thể nào có sự định nghĩa các phương thức mã hoá và giải mã riêng bằng các thông tin tiêu đề và định nghĩa

- Các bộ trộn và chuyển đổi: Các bộ trộn là thiết bị nắm giữ phương thức truyền thông từ một vài người sử dụng riêng lẻ, để trộn hoặc nối chúng vào các luồng phương thức truyền thông chung, chuyển đổi chúng vào khuôn dạng khác và gửi nó ra Các bộ chuyển đổi có ích cho sự thu nhỏ băng thông yêu cầu của luồng số liệu từ luồng số liệu chung trước khi gửi vào từng kết nối băng thông hẹp hơn mà không yêu cầu nguồn phát RTP thu nhỏ tốc độ bit của nó Điều này cho phép các bên nhận kết nối theo một liên kết nhanh để vẫn nhận được truyền thông chất lượng cao

- Mã hoá thành mật mã: Các luồng phương thức truyền thông RTP có thể mã

hoá thành mật mã dùng các khoá, việc mã hoá đảm bảo cho việc thông tin trên mạng được an toàn hơn

Các gói tin truyền trên mạng Internet có trễ và jitter không dự đoán được Nhưng các ứng dụng đa phương tiện yêu cầu một thời gian thích hợp khi truyền các

dữ liệu và phát lại RTP cung cấp các cơ chế bảo đảm thời gian, số thứ tự và các cơ

Trang 29

chế khác liên quan đến thời gian Bằng các cơ chế này RTP cung cấp sự truyền tải

dữ liệu thời gian thực giữa các đầu cuối qua mạng

Bản thân RTP không cung cấp một cơ chế nào cho việc bảo đảm phân phối kịp thời các dữ liệu tới các trạm mà nó dựa trên các dịch vụ của tầng thấp hơn để thực hiện điều này RTP cũng không đảm bảo việc truyền các gói theo đúng thứ tự Tuy nhiên, số thứ tự trong RTP header cho phép bên thu xây dựng lại đúng thứ tự các gói của bên phát

Hoạt động của RTP được hỗ trợ bởi một giao thức khác là RTCP để nhận các thông tin phản hồi về chất lượng truyền dẫn và các thông tin về thành phần tham dự các phiên hiện thời

Khuôn dạng bản tin RTP:

RTP header bao gồm một phần cố định có ở mọi gói RTP và một phần mở rộng phục vụ cho các mục đích nhất định

Hình 1.2.3a: Khuôn dạng phần cố định gói tin RTP

Phần cố định của đơn vị dữ liệu RTP

- Version (2 bits): Chỉ ra version của RTP

- Padding (1 bit): Nếu bit này được đặt, sẽ có thêm một vài octets thêm vào

cuối gói dữ liệu Các octets này không phải là thông tin, chúng được thêm vào để nhằm mục đích:

- Phục vụ cho vài thuật toán mã hoá thông tin cần kích thước của gói cố định

- Dùng để cách ly các gói RTP trong trường hợp có nhiều gói thông tin được mang trong cùng một đơn vị dữ liệu của giao thức ở tầng dưới

- Extension (1 bit): nếu bit này được đặt, thì theo sau phần header cố định sẽ

là một header mở rộng

- Contributing Sources Count (4 bits): số lượng các thành phần nhận dạng

nguồn CSRC nằm trong phần header gói tin Số này lớn hơn một nếu các gói tin RTP đến từ nhiều nguồn

- Marker (1 bit): mang ý nghĩa khác nhau, tuỳ theo từng trường hợp cụ thể,

được chỉ ra trong profile đi kèm

Trang 30

- Payload Type (7 bits): chỉ ra loại tải trọng mang trong gói Các mã sử

dụng trong trường này ứng với các loại tải trọng được quy định trong một profile đi kèm

- Sequence Number (16 bits): mang số thứ tự của gói RTP Số này được

tăng thêm một sau mỗi gói RTP được gửi đi Có thể được sử dụng để phát hiện được sự mất gói và khôi phục mất gói tại đầu thu Giá trị khởi đầu của trường này

là ngẫu nhiên

- Time stamp (tem thời gian, 32 bits): Phản ánh thời điểm lấy mẫu của octet

đầu tiên trong gói RTP Thời điểm này được lấy từ một đồng hồ tăng đều đặn và tuyến tính theo thời gian để cho phép việc đồng bộ và tính toán độ jitter Tần số đồng hồ này không cố định, tuỳ thuộc vào loại tải trọng Giá trị khởi đầu được chọn ngẫu nhiên Một vài gói RTP có thể mang cùng một giá trị “Tem thời gian” nếu như chúng được phát đi cùng lúc về mặt logic Nếu gói dữ liệu được phát ra đều đặn thì “tem thời gian” được tăng một cách đều đặn Trong trường hợp khác thì giá trị

“tem thời gian” tăng không đều

“Tem thời gian” là thành phần thông tin quan trọng nhất trong các ứng dụng thời gian thực Người gửi thiết lập các “tem thời gian” ngay thời điểm octet đầu tiên của gói được lấy mẫu “Tem thời gian” tăng dần theo thời gian đối với mọi gói Sau khi nhận được gói dữ liệu, bên thu sử dụng các “tem thời gian” này nhằm khôi phục thời gian gốc để chạy các dữ liệu này với tốc độ thích hợp

- Synchronization Source Identifier (SSRC, 32 bits): chỉ ra nguồn đồng bộ

của gói RTP, số này được chọn ngẫu nhiên Trong một phiên RTP có thể có nhiều hơn một nguồn đồng bộ Mỗi một nguồn phát ra một luồng RTP Bên thu nhóm các gói của cùng một nguồn đồng bộ lại với nhau để phát lại tín hiệu thời gian thực

- Contributing Source Identifier (CSRC, từ 0-15 mục, mỗi mục 32 bits): chỉ

ra những nguồn đóng góp thông tin vào phần tải trọng của gói giúp bên thu nhận biết được gói tin này mang thông tin của những nguồn nào

Phần mở rộng: có độ dài thay đổi, sự tồn tại phụ thuộc vào bit Extension của

phần cố định

Hình 1.2.3b: Khuôn dạng phần mở rộng RTP

- 16 bit đầu tiên được sử dụng với mục đích riêng cho từng ứng dụng được định nghĩa bởi profile Thường được dùng để phân biệt các loại header mở rộng

- Length (16 bits): giá trị chiều dài phần header mở rộng tính theo đơn vị 32

bit, không bao gồm 32 bit đầu tiên của phần header mở rộng Cơ chế mở rộng của RTP cho phép các ứng dụng riêng lẻ của giao thức RTP thực hiện được với những chức năng mớ ỏi những thông tin thêm vào phần header của gói

Trang 31

Cơ chế này được thiết kế để một vài ứng dụng có thể bỏ qua phần header mở rộng này (mà vẫn không ảnh hưởng tới hoạt động) trong khi một số ứng dụng khác lại có thể sử dụng được phần đó Bộ phận nhận dạng tải xác định kiểu định dạng của tải tin cũng như cách mã hoá và nén Từ các bộ phận định dạng này, các ứng dụng phía thu biết cách phân tích và chạy các ứng ụng dữ liệu tải tin Tại một thời điểm bất kỳ trong quá trình truyền tin, các bộ phát RTP chỉ có thể gửi một dạng của tải tin cho dù dạng của tải tin có thể thay đổi trong thời gian truyền (thay đổi để thích ứng với sự tắc nghẽn của mạng)

Một chức năng khác của RTP là xác định nguồn: cho phép phía thu biết được

Mạng Internet hiện nay vẫn chưa thể đáp ứng được đầy đủ các yêu cầu của các dịch vụ thời gian thực Các dịch vụ RTP yêu cầu băng thông cao có thể làm giảm chất lượng các dịch vụ khác trong mạng đến mức nghiêm trọng Trong quá trình triển khai phải chú ý đến giới hạn băng thông sử dụng của các ứng dụng trong mạng

1.3.4 Giao thức thời gian thực RTSP( Real Time Stream Protocol )

Streaming Real Time Protocol (RTSP) [12] là một khung mở rộng để kiểm soát cung cấp các phương tiện truyền thông thời gian thực dữ liệu, chẳng hạn như

âm thanh và video

Mục tiêu giao thức:

RTSP được thiết kế như là một giao thức báo hiệu cho thiết lập và kiểm soát một hoặc nhiều luồng đồng bộ thời gian của các phương tiện truyền thông liên tục

Có thể so sánh RTSP với một thiết bị thế giới thực là điều khiển từ xa VCR RTSP

có thể được sử dụng để bắt đầu, dừng, và tạm dừng các media clip "kiểm soát Internet từ xa" hỗ trợ hoạt động để kiểm soát dữ liệu trực tiếp hoặc lưu trữ media clip

RTSP thường bị hiểu lầm là một giao thức vận chuyển Tuy nhiên, nó không phải tham gia vào quá trình vận chuyển của các luồng liên tục Nó cung cấp một phương tiện để đàm phán các cơ chế vận chuyển nên được đưa vào cung cấp phương tiện truyền thông RTSP chính nó là độc lập của bất kỳ cơ chế vận chuyển

cụ thể Internet hiện tại tất cả các cơ chế vận chuyển, cụ thể là UDP, TCP, và on-UDP được hỗ trợ Báo hiệu kênh RTSP là độc lập với các giao thức vận chuyển,

RTP-cả UDP và TCP đều được hỗ trợ

Việc thiết kế giao thức cơ bản rất tương tự như trong cú pháp và hoạt động HTTP/1.1 Những lợi ích của quyết định thiết kế này là: có thể tránh được nhiều sai lầm , được thực hiện trong HTTP, và thứ hai, chấp thuận các tính năng của việc

Trang 32

thực hiện HTTP và mở rộng các cơ chế có thể được tái sử dụng Ngoài các thuộc tính thiết kế mô tả, RTSP có thể được mô tả theo các tính năng thiết kế sau đây:

- Chức năng nhiều máy chủ : Streams của máy chủ Media có thể được điều khiển cùng một lúc Đồng bộ hóa được thực hiện ở cấp ứng dụng,

- Proxy và tường lửa thân thiện: Khi RTSP đã thừa hưởng các định dạng giao thức HTTP, chỉ có một vài thay đổi đơn giản proxy và hệ thống tường lửa cho phép

xử lý đúng đắn tín hiệu RTSP trong các hệ thống này Ngoài ra, bằng cách phân tích các phương pháp SETUP, tường lửa có thể dễ dàng tìm ra cổng vận chuyển được sử dụng bởi các luồng phương tiện truyền thông và mở "Cổng" cho các lưu lượng truy cập các phương tiện truyền thông tương ứng

- Hỗ trợ cân bằng tải: RTSP có thể chuyển hướng các yêu cầu để đạt được cân bằng tải trên các máy chủ phương tiện truyền thông

- Mở rộng: Các phương pháp mới và các thông số có thể được dễ dàng thêm vào giao thức Chỉ có vài thay đổi cần phải làm là phân tích cú pháp HTTP để RTSP tương thích

Trình bày mô tả trung lập: Các giao thức không cố định cho trình bày cụ thể

mô tả định dạng Thời gian chính xác cao: RTSP phù hợp cho các ứng dụng chuyên nghiệp (ví dụ, kỹ thuật số chỉnh sửa từ xa) do hỗ trợ của nhãn thời gian với khung

Mời truy cập hội thảo của server media:

Một máy chủ phương tiện truyền thông có thể được "mời" tham gia một hội nghị hiện có để phát lại media bổ sung hoặc ghi lại các luồng media được thể hiện liên tục

Bổ sung của Media vào các thể hiện đang tồn tai:

RTSP máy chủ có khả năng thông báo cho khách hàng nếu các luồng media mới cung cấp Điều này rất hữu ích cho các bài trình diễn trực tiếp

Phương thức và trạng thái

Kiểm soát luồng phức tạp đòi hỏi phải thao tác để SETUP, PLAY, RECORD, PAUSE,STOP luồng Media Khi một số hoạt động kiểm soát, chẳng hạn như Play hoặc Record không phải là tạm thời, nhưng đòi hỏi liên tục, máy chủ RTSP phải duy trì trạng thái phiên Trạng thái phiên phía Server cung cấp cũng là một phương tiện để kiểm tra tính hợp lệ của các yêu cầu kiểm soát Một yêu cầu điều khiển pause chỉ là hợp lý nếu luồng hoặc là PLAY hoặc RECORD Khi thiết lập ban đầu, các máy chủ RTSP tạo ra một phiên id được gán cho một phiên làm việc mới Các phiên id phục vụ như là một định danh duy nhất cho phiên làm việc và được sử dụng để tham khảo các trạng thái phiên mới được giao trong máy chủ Tất cả RTSP

Trang 33

và đáp ứng yêu cầu tiếp theo bao gồm các phiên id như là một định danh phiên trong tiêu đề giao thức Khi một yêu cầu RTSP, máy chủ hoặc khách hàng có thể dễ dàng xác định các phiên để đáp ứng yêu cầu kiểm soát

Phương pháp tác động đến tình trạng phía Server của một luồng được mô tả:

DESCRIBLE: Đây là một lệnh yêu cầu server gửi mô tả chi tiết về đối tượng

được yêu cầu

SETUP: Lệnh này chứa một vài thành phần quan trọng của thông tin như một

URL của nội dung được yêu cầu và một chỉ số cổng để sử dụng trao đổi dữ liệu Server phản hổi lại sau khi nhận được lệnh này và cấp phát tài nguyên hợp lý để stream đến client

PLAY: Mỗi lần lệnh SETUP đã được xử lý lệnh PLAY được sử dụng để

khởi động truyền nội dung yêu cầu Trong trường hợp bình thường nội dung video

sẽ được chơi qua mạng từ đầu đến cuối

PAUSE: Như tên của nó lệnh này yêu cầu tạm dừng việc gửi nội dung yêu

cầu từ server tới client

RECORD: Lệnh này được sử dụng để ghi lại một nội dung Audio đến một

loại thiết bị lưu trữ riêng

PPARAMETER GET / SET cho phép các thông số được trao đổi

TEARDOWN: Khi nhận được lệnh này phiên streaming kết thúc mọi tài

nguyên đă cấp phát đều được giải phóng

Trang 34

Bảng 1.3.5: Mô hình phương thức RTSP, hướng đi và yêu cầu

Cú pháp của yêu cầu RTSP:

Request = Request-Line *( General-Header | Request-Header | Entity-Header ) CRLF [ Message-Body ]

Request-Line = Method SP RTSP-URL SP RTSP-Version CRLF

Method = GET | HEAD | POST | extension-method

1.3.5 Giao thức điều khiển truyền thông thời gian thực RTCP(Real-Time Transport Control Protocol)

- RTCP (Real-time Transport Control Protocol) là giao thức hỗ trợ cho RTP cung cấp các thông tin phản hồi về chất lượng truyền dữ liệu

Gói RTCP góp phần làm tăng nghẽn mạng Băng thông yêu cầu bởi RTCP là 5% tổng số băng thông phân bổ cho phiên Khoảng thời gian trung bình giữa các gói RTCP được đặt tối thiểu là 5s Các loại thông báo điều khiển chính được RTCP cung cấp là:

- SR (Sender Report): chứa các thông tin thống kê liên quan tới kết quả truyền như tỷ lệ tổn hao, số gói dữ liệu bị mất, khoảng trễ Các thông báo này phát

ra từ phía phát trong 1 phiên truyền thông

Trang 35

- RR (Receiver Report): Chứa các thông tin thống kê liên quan tới kết quả nhận, được phát từ phía thu trong 1 phiên truyền thông

- SDES (Source Description): thông số mô tả nguồn (tên, vị trí…)

- APP (Application): cho phép truyền các dữ liệu ứng dụng

- BYE: chỉ thị sự kết thúc tham gia vào phiên truyền

Giá trị của trường PT (Packet Type) ứng với mỗi loại gói được liệt kê trong bảng sau

Mỗi gói thông tin RTCP bắt đầu bằng 1 phần tiêu đề cố định giống như gói RTP thông tin Theo sau đó là các cấu trúc có chiều dài thay đổi theo loại gói nhưng luôn bằng số nguyên lần 32 bit Các gói thông tin RTCP có thể gộp lại với nhau thành các hợp gói (compound packet) để truyền xuống lớp dưới mà không phải chèn thêm các bit cách ly Số lượng gói trong hợp gói tuỳ thuộc vào chiều dài đơn

- Nếu số lượng các nguồn lớn hơn 31 (không vừa trong một gói SR hoặc RR) thì các gói RR thêm vào sẽ theo sau gói thống kê đầu tiên Việc bao gồm gói thống

kê (RR hoặc SR) trong mỗi hợp gói nhằm thông tin thường xuyên về chất lượng thu của những người tham gia Việc gửi hợp gói đi được tiến hành một cách đều đặn và thường xuyên theo khả năng cho phép của băng thông

- Trong hợp có gói SDES nhằm thông báo về nguồn phát

- Các gói APP nằm ở vị trí bất kỳ trong hợp gói

- Gói BYE nằm ở vị trí cuối cùng

Trang 36

CHƯƠNG II: CHẤT LƯỢNG DỊCH VỤ LUỒNG ÂM THANH TRÊN

INTERNET 2.1 QoS lớp ứng dụng

Phần này mô tả một vài cơ chế ở cấp ứng dụng, có giá trị khi tiến hành phát triển các ứng dụng thời gian thực cho Internet Những kỹ thuật này được thiết kế để đạt được các dịch vụ ứng dụng có chất lượng cao và tăng sự hài lòng của người dùng cuối

2.1.1 Truyền gói

Đối với việc truyền gói tin, sự tương tác các luồng ứng dụng thời gian thực có

sự lựa chọn về cơ chế vận chuyển

Chọn giao thức vận chuyển

Giao thức UDP và TCP được sử dụng khi có yêu cầu xử lý thời gian thực Như ta đã biết TCP có nhược điểm khi sử dụng với lưu thông giới hạn thời gian

Trang 37

Đầu tiên, để đạt được độ tin cậy TCP sẽ sử dụng cả hai kỹ thuật là truyền lại và bộ đệm Tuy nhiên, khi đưa vào thì trễ vẫn không được cải thiện Thứ hai, các ứng dụng luồng truyền thông thời gian thực phải kiểm soát tốc độ truyền tải của chúng

và là trách nhiệm của giao thức vận chuyển hơn là ý nghĩa của QoS

Kết quả là các luồng ứng dụng thời gian thực sử dụng chủ yếu giao thức không kết nối đơn giản UDP như là một giao thức vận chuyển Nó cho phép các ứng dụng tự do kiểm soát tốc độ truyền Hơn nữa, các luồng ứng dụng thời gian thực rất có lợi từ khả năng truyền Multicast của MBONE(Multicast Backbone) Trong trường hợp các luồng thời gian thực có cơ chế luồng lựa chọn là RTP-on-UDP RTP trên Header của UDP sẽ thêm các luồng thông tin hữu ích như: timestamps, session id, sequence numbers,… của các gói dữ liệu Kênh thông tin phản hồi của RTP, cụ thể là RTCP có thể được sử dụng để gửi QoS thông tin lại cho người gửi Các thông tin phản hồi QoS đặc biệt có giá trị nếu thích ứng và được triển khai trong các ứng dụng của người gửi

Kích thước gói

Bên cạnh việc lựa chọn giao thức thích hợp, kích thước gói được sử dụng để truyền tải luồng phương tiện truyền thông đóng vai trò quan trọng đối với trễ truyền tải người dùng đầu cuối

Trong trường hợp của âm thanh hoặc luồng video kích thước tải trọng là bội

số của kích thước khung truyền thông Ví dụ: Đọc từ thiết bị âm thanh một đoạn Frame(khung) âm thanh Số lượng các mẫu âm thanh trong một khung âm thanh phụ thuộc vào cấu hình thiết bị Nếu trễ đầu cuối tối thiểu như trong trường hợp các ứng dụng tương tác thời gian thực, kích thước khung hình nên nhỏ và tải trọng nên bao gồm khung càng ít càng tốt để giảm thiểu sự trễ do đóng gói Điển hình ứng dụng âm thanh trực tiếp sử dụng khung mà bao gồm 20 hoặc 40 ms của dữ liệu âm thanh

FrameSize được xác định bởi các định dạng âm thanh thu được từ thiết bị âm thanh Phương trình 2.1.1 cho thấy làm thế nào để tính toán FrameSize nói chung.Ví

dụ, mã hóa 40 ms 4 đơn âm kHz audio1 trong 16 mẫu bit kết quả trong một rameSize F 640 byte

FrameSize = Channels × SampleSize × SampleRate × Time (2.1.1a)

Kích thước tải trọng gói dữ liệu được xác định bởi số lượng khung được gửi đi mỗi gói dữ liệu và chương trình nén hoặc mã hóa Ví dụ, nếu chúng ta xem xét các gói tin mạng GSM dữ liệu mã hóa âm thanh mono, 16 bit PCM khung hình, kết quả kích thước tải trọng vào 65 byte

PayloadSizeGS M = Frames × (CompressionRate × F rameSize) (2.1.1b) Nói chung, nếu các thuật toán nén tinh vi như GSM, CELP, MPEG, vv, được

sử dụng để mã hóa các dữ liệu truyền thông, kích thước của một tải trọng của khung truyền là rất nhỏ Chuyền gói dữ liệu với một kích thước tải trọng trong kích thước nhỏ hơn 100 byte có vẻ là không hiệu quả xem xét các headers gói tin trong trường hợp của UDP / IP, RTP / UDP / IP có kích thước lớn Công thức sau đây được đưa ra để tính toán chi phí gói tin:

Trang 38

Bảng sau đây cho thấy tổng phí gói ở trên lớp liên kết của một mono 16 bit khung PCM sử dụng âm thanh không nén và âm thanh nén mã hoá GSM Điều minh họa trên không phụ thuộc nhiều vào các giao thức vận chuyển và giao thức ứng dụng được sử dụng Mặc dù tổng chi phí gói cho các gói tin âm thanh nhỏ là rất cao, giá được chi trả nếu trễ đầu cuối tối thiểu

Bảng 2.1.1: Gói tin Overhead của Mã hóa Audio khác nhau và cơ chế truyền

Để giảm thiểu Overhead, hay nói cách khác để tối đa hoá việc sử dụng mạng Nghiên cứu về nén Header cho thấy khi truyền tải chỉ các đối tượng thông tin Header thay đổi( ví dụ: sequence numbers, timestamp, checksum…) Vì vậy Overhead có thể giảm nhiều

Traffic Shaping(Định hình lưu lượng )

Kỹ thuật được sử dụng để cải thiện chất lượng truyền dẫn đối với việc truyền tải gói tin được gọi là Traffic shaping Nguyên tắc chung của Traffic shaping là thay đổi các đặc tính truy cập của luồng ra của các gói(hoặc tế bào) trên các kết nối ảo trong việc tối ưu hoá sử dụng tài nguyên mạng

Trong Internet ngày nay, mất gói tin có tính chất truyền loạt Do tràn hàng đợi hoặc do thiết bị định tuyến trung gian Vì vậy các ứng dụng cho luồng truyền thông trực tiếp cần hình thành các luồng đi ra cho các gói như là các gói dữ liệu truyền đồng thời theo thời gian, chứ không phải là sự truyền loạt Mặc dù gói tin mất ít hơn dự tính khi mà các ứng dụng đã áp dụng Traffic Shaping để truyền dữ liệu Với Traffice shaping thì truyền dữ liệu trong các nút mạng sẽ hiệu quả hơn nhiều

2.1.2 Điều chỉnh lỗi (Forward Error Correction)

Forward Error Correction (FEC) đã phát triển cho các gói của luồng truyền thông đó là một cách tiếp cận khác nhau để giải quyết vấn đề mất gói trong giao tiếp Internet

Trong các cơ chế lặp khép kín, chẳng hạn cơ chế Yêu cầu lặp tự động (Automatic Repeat Request: ARQ) được sử dụng để phục hồi các gói bị mất do phương thức truyền lại Cơ chế lặp mở, chẳng hạn như cơ chế FEC truyền tải thông tin dự phòng với các dữ liệu truyền thông ban đầu để các gói dữ liệu bị mất có thể được phục hồi từ sự thích nghi cơ chế ARQ Tuy nhiên, sẽ là không phù hợp để phục hồi nếu là dữ liệu thời gian thực được truyền trong mạng diện rộng, chẳng hạn

Trang 39

như Internet Việc truyền lại làm cho độ trễ quá lớn Ngoài ra cơ chế ARQ không phù hợp với kiểu truyền dữ liệu Multilcast

Cơ chế FEC được đề xuất gửi các gói tin “dư thừa” tất cả các gói tin thứ n thu được bằng cách loại bỏ n gói tin khác Cơ chế này cho phép phục hồi mất mát từng thông tin trong một thông tin gói n Nó làm tăng tốc độ dữ liệu r chỉ ra bởi r/n Nhưng nếu một gói bị mất cần được phục hồi thì người nhận cần phải chờ đến gói tin “dư thừa” tiếp theo Như vậy, cơ chế làm tăng đáng kể trung bình trễ đầu cuối khi mà tỷ lệ mất gói thường xuyên

FEC là cơ chế đặc biệt giải quyết vấn đề mất gói tin liên tiếp Ý tưởng là thêm các bản sao nén ở mức cao vào trước khung k của các gói hiện tại Nếu gói tin thứ n( n là thứ tự gói tin) bị mất Thì bất kỳ các gói tin sau n+1, n+2, n+3,…n+k phải được nhận thành công Như vậy, mất gói tin kế tiếp của k có thể cho được phép khi mà chất lượng thay thế thấp Sự lựa chọn tối ưu của k là sự điều hòa giữa việc mất gói tin liền kề trong mạng và băng thông sẵn có Sự gia tăng của tốc độ dữ liệu được tạo ra bởi các thông tin dư thừa phụ thuộc vào các chương trình nén Nếu các

bộ mã hóa băng thông thấp được sử dụng cho các Frame dư thừa, tốc độ dữ liệu tăng không đáng kể, ngay cả khi k được thiết lập một vài Frame Tuy nhiên, việc dự phòng nhiều cũng tác động tiêu cực đến tắc nghẽn mạng nhưng cũng tạo độ tin cậy cho mạng hơn

Trong trường hợp luồng thời gian thực có giá trị tối đa của k thêm vào là trễ trong mã hóa FEC và giải mã FEC, thì cơ chế này bổ sung ít nhất k Frame trễ cho trễ đầu cuối Vì vậy giá trị của k phải được lựa chọn cẩn thận để ngăn chặn trễ bổ sung của các gói tin phát lại do đến chậm và do sắp xếp lôn xộn Cách tiếp cận này

có ưu điểm độ trễ bổ sung tại thời điểm nhận phụ thuộc hoàn toàn vào gói tin bị mất liên tiếp Nếu không có sự mất gói xảy ra, không có sự bổ sung trễ được đưa vào Nếu chỉ có một gói tin bị mất thì sự phục hồi có thể đạt được ngay sau khi gói tin

kế tiếp đến Do đó, độ trễ của người nhận sẽ tăng lên với số lượng gói tin bị mất

2.1.3 Sự thích ứng (Adaptation)

Cơ chế để cung cấp dịch vụ liên tục ngay cả khi điều kiện thay đổi bên ngoài (tức là tắc nghẽn mạng, tràn hàng đợi bộ định tuyến và xử lý tình trạng quá tải) thường được gọi là cơ chế thích ứng QoS Các ứng dụng thích ứng có thể thích ứng với những dịch vụ chất lượng tùy thuộc vào QoS nhận được từ mức dịch vụ cấp thấp Ngay cả khi dịch vụ biến động nghiêm trọng cũng vẫn có thể được cung cấp bằng cách thông qua các cơ chế thích ứng của QoS Tuy nhiên trong các trường hợp như vậy nó thường được tích hợp để thông báo cho các ứng dụng biết sự xuống cấp dịch vụ để có thể điều chỉnh QoS mới Nếu các hoạt động chuyển giao vi phạm các thỏa thuận QoS (ví dụ, QoS dành riêng bằng bằng giao thức RSVP), người dùng có thể lựa chọn để có một số hành động khắc phục (tức là điều chỉnh trạng thái ứng dụng để phù hợp điều kiện tải các hiện hành, thương lượng lại của luồng QoS, ngắt kết nối từ dịch vụ)

Các mức ứng dụng QoS thích ứng chủ yếu là làm tăng hoặc giảm các thuộc tính QoS của ứng dụng phụ thuộc vào các biến đổi đặc tính trong mạng Thích ứng,

ví dụ, thay đổi các luồng truyền thông (tức là chất lượng âm thanh, định dạng mã

Trang 40

hóa), khả năng dự phòng cho luồng dữ liệu, hoặc điều chỉnh kích thước bộ đệm người nhận(ví dụ: tính toán các điểm phát lại) để cho người sử dụng nghĩ rằng chất lượng dịch vụ mạng của họ liên tục Đây là một thủ thuật, tuy nhiên, chỉ làm việc

“thực” khi QoS được cung cấp bởi một mạng cơ bản trong một phạm vi nhất định Nếu QoS “thực” giảm dưới mức “giới hạn thích ứng” thích ứng hoạt động không đúng nữa và chất lượng dịch vụ kém

Nếu mạng được cung cấp bởi phương pháp dành riêng tài nguyên, các ứng dụng có thể đảm bảo được tài nguyên cho những luồng truyền thông, và vì vậy, không cần thích ứng với đặc tính QoS mạng Như vậy, trong một môi trường mà ở

đó sẵn có việc dành riêng tài nguyên Thích ứng chỉ là của người bắt đầu sử dụng

Trong một so sánh giữa Best-Effort(nỗ lực tối đa) so với dành riêng tài nguyên(resource reservation ), chỉ ra rằng cơ chế thích ứng cho phép các ứng dụng

đa phương tiện vượt qua mạng Best-Effort tương tự như các ứng dụng sử dụng dành riêng tài nguyên

Tóm lại, chúng ta có thể kết luận rằng các ứng dụng thích ứng cải thiện đáng

kể hiệu suất dưới trung bình đến cao tải mạng

2.1.4 Bộ đệm nhận(Receiver buffering)

Bộ đệm nhận là yêu cầu để bù đắp cho biến thiên trễ còn được gọi là Jitter,

đã được giới thiệu và được sử lý trong các hệ thống đầu cuối Và rất quan trọng để giải quyết vấn đề truyền dữ liệu sai, chẳng hạn như sắp xếp lại gói tin Nhiệm vụ của bộ đệm nhận là để đánh giá tối ưu của phát lại trễ Cần thiết để tính toán thời gian bộ đệm và quản lý xếp hàng của các gói tin nhận được cho đến trước thời điểm phát lại Thời gian phát cho mỗi gói tin thường được quyết định bởi nhãn thời gian được chỉ định bởi người gửi và ước tính của mạng và trễ xử lý

TPlayback= TRecording + DNetword + DProcessing

DProcess ước tính cho xử lý trễ( nghĩa là giải mã, sự giải nén, lập lịch ) tại người nhận Khi người nhận không thể phân biệt được được trễ (hoặc Jiter) được tạo ra do người gửi hoặc do mạng Ước tính trễ của mạng DNetwork xác định gói tin trễ đến người nhận

Phát lại trễ có thể được được thực hiện liên tục trong xuốt phiên hoặc có thể được điều chỉnh thích nghi trong phiên truyền Việc điều chỉnh phát lại các thích ứng có thể được thực hiện trên cơ sở mỗi Talkspurt hoặc mỗi packit Trong mỗi trường của gói Audio việc dự tính thời gian phát lại trễ cho gói đầu tiên của Talkspurt là rất quan trọng bởi vì nó quyết định thời gian phát lại của các gói tiếp theo của Talkspurt Lưu ý là những khoảng phát lại trong tín hiệu Audio được nhận diện ngay lập tức và nghe như tiếng nổ lách tách Trong trường hợp phát lại trễ video thực hiện điều chỉnh trên cơ sở mỗi packet nếu Video và Audio chỉ được kết hợp một cách lỏng lẻo, hoặc nếu Video được phát riêng một mình Khi nhận dạng hình ảnh, con người thường không nhận thấy sự thay đổi nhỏ trong thời gian hiển thị trên một khung hình riêng

Một ví dụ về vấn đề ước tính phát lại gói luồng Audio Phát lại trễ của gói thứ

i là dpi bằng tổng trễ của mạng di và thời gian bộ đệm bi

di= ai – ti