Đảm bảo chất lượng dịch vụ trong mạng chuyển mạch nhãn đa giao thức

Ứng dụng trong công nghệ mới với sự ra đời của các mô hình ứng dụng đã giải quyết được bài toán đa dịch vụ nhưng vẫn đảm bảo được yêu cầu về chất lượng dịch vụ đề ra.. Khái niệm về chất

-[[ \\ -NguyÔn h÷u kh¸ng

ĐẢM BẢO CHẤT LƯỢNG DỊCH VỤ TRONG MẠNG

CHUYỂN MẠCH NHÃN ĐA GIAO THỨC

Họ và tên: Nguyễn Hữu Kháng Giới tính: Nam

Sinh ngày: 20 tháng 02 năm 1977

Nơi sinh (Tỉnh mới): Nghệ An

Quê quán: xã Thanh tường, Thanh chương, Nghệ an

Chức vụ: Chuyên viên Trung tâm tin học

Đơn vị công tác: Viễn Thông Nghệ An

Chỗ ở riêng hoặc địa chỉ liên lạc: Trung tâm tin học – Vễn Thông Nghệ an số 2 Minh Khai - Vinh Điện thoại CQ: 0383594612 Điện thoại NR: 0388909909 Điện thoại di động: 09146066228 Fax: E-mail: khangnh.nan@vnpt.vn

II Quá trình đào tạo:

1 Trung học chuyên nghiệp (hoặc cao đẳng):

- Hệ đào tạo(Chính quy, tại chức, chuyên tu) ….… Thời gian đào tạo: từ / đến ……

- Trường đào tạo …… ………

- Ngành học: ………… Bằng tốt nghiệp đạt loại …

2 Đại học:

- Hệ đào tạo: Chính quy Thời gian đào tạo: từ năm 1996 đến năm 2001

- Trường đào tạo: Đại học Bách Khoa Hà Nội

- Ngành học: Điện tử viễn thông Bằng tốt nghiệp đạt loại: Khá

3 Thạc sĩ:

- Hệ đào tạo: Chính quy Thời gian đào tạo: từ Tháng 03 năm 2010 đến tháng 04 năm 2012

- Chuyên ngành học: Kỹ thuật điện tử viễn thông

- Tên luận văn: Đảm bảo chất lượng dịch vụ trong mạng chuyển mạch nhãn đa giao thức

- Người hướng dẫn Khoa học: Phó Giáo sư – Tiến sỹ Nguyễn Hữu Thanh

4 Trình độ ngoại ngữ (Biết ngoại ngữ gì, mức độ nào): Tiếng Anh B1 Châu Âu

III Quá trình công tác chuyên môn kể từ khi tốt nghiệp đại học:

ảnh 4x6

IV Các công trình khoa học đã công bố:

Tôi cam đoan những nội dung viết trên đây là đúng sự thật

Ngày tháng năm 2012

NGƯỜI KHAI KÝ TÊN

Nguyễn Hữu Kháng

LỜI CAM ĐOAN

Em xin cam đoan nội dung của đồ án này không là bản sao chép của bất kì đồ

án hay công trình nghiên cứu nào đã có từ trước Nếu vi phạm em xin chịu hoàn toàn trách nhiệm

Hà Nội, ngày 20/3/2012

Học viên

Nguyễn Hữu Kháng

MỤC LỤC

MỤC LỤC 1 

TỪ VIẾT TẮT 4 

DANH MỤC BẢNG BIỂU 6 

DANH MỤC HÌNH VẼ 6 

LỜI NÓI ĐẦU 9 

CHƯƠNG I: 11 

CHẤT LƯỢNG DỊCH VỤ TRONG MẠNG TRUYỀN THÔNG 11 

1.1.  Khái niệm về chất lượng dịch vụ: 12 

1.2.  Các thông số QoS: 14 

1.2.1.  Băng thông 15 

1.2.2.  Trễ 16 

1.2.3.  Jitter (Biến động trễ) 17 

1.2.4.  Mất gói 18 

1.2.5.  Tính sẵn sàng (Độ tin cậy) 19 

1.2.6.  Bảo mật: 20 

1.3.  Yêu cầu QoS đối với các dịch vụ khác nhau: 21 

1.3.1.  Ứng dụng E-mail, FTP: 21 

1.3.2.  Ứng dụng Streaming, âm thanh hình ảnh lưu trước: 22 

1.3.3.  Ứng dụng Streaming cho âm thanh, hình ảnh sống 23 

1.3.4.  Ứng dụng Hình ảnh âm thanh tương tác thời gian thực 24 

1.3.5.  Ví dụ về điện thoại VOIP: 24 

1.3.6.  Các lớp dịch vụ 34 

1.4.  Một số kỹ thuật hỗ trợ chất lượng dịch vụ 36 

CHƯƠNG II: 39 

CÁC KỸ THUẬT ĐẢM BẢO CHẤT LƯỢNG DỊCH VỤ 39 

2.1.  Kỹ thuật đo lưu lượng và mầu hóa lưu lượng 39 

2.2.  Đánh dấu ba mầu tốc độ đơn 39 

2.3.  Đánh dấu ba mầu hai tốc độ 42 

2.4.  Kỹ thuật quản lý hàng đợi tích cực 44 

2.4.1.  Kỹ thuật loại bỏ gói ngẫu nhiên sớm RED 44 

2.4.2.  Kỹ thuật loại bỏ gói sớm theo trọng số WRED 46 

2.4.3.  Thông báo tắc nghẽn hiện ECN 46 

2.5.  Lập lịch gói: 47 

2.5.1.  FIFO 48 

2.5.2.  Hàng đợi ưu tiên PQ 49 

2.5.3.  Hàng đợi công bằng FQ 50 

2.5.4.  Vòng quay trọng số Robin (WRR) 51 

2.5.5.  Hàng đợi công bằng có trọng số WFQ 53 

2.5.6.  Hàng đợi công bằng có trọng số dựa trên cơ sở lớp (CB WFQ) 55 

2.6.  Trafic Shaping 57 

2.6.1.  Bộ định dạng lưu lượng thường 57 

2.6.2.  Bộ định dạng lưu lượng gáo rò 58 

CHƯƠNG 3: 61 

CHẤT LƯỢNG DỊCH VỤ TRONG MẠNG IP 61 

3.1.  Các dịch vụ tích hợp 61 

3.2.  Giao thức dành riêng tài nguyên (RSVP) 61 

3.2.1.  Tổng quan về RSVP 61 

3.2.2.  Hoạt động của RSVP 62 

3.2.3.  Các kiểu RSVP dành riêng 63 

3.2.4.  Các ví dụ về IntSer 64 

3.3.  Các dịch vụ phân biệt 68 

3.3.1.  Tổng quan DiffServ 68 

3.3.2.  Cấu trúc DiffServ 70 

3.3.3.  Đánh dấu gói DiffServ 72 

3.3.4.  Cư sử từng chặng (PHB) 75 

3.3.5.  Ví dụ về Differentiated Services 79 

CHƯƠNG 4: 82 

QoS TRONG GIAO THỨC CHUYỂN MẠCH NHÃN MPLS 82 

4.1.  Cơ sở lý thuyết của MPLS 82 

4.1.1.  Sự chuyển tiếp gói IP thông thường 82 

4.1.2.  Các cải tiến của MPLS 83 

4.1.3.  Kiến trúc MPLS 84 

4.2.  Mã hóa nhãn: 85 

4.2.1.  MPLS shim header 85 

4.2.2.  Mã hóa nhãn qua mạng ATM 86 

4.3.  Hoạt động của MPLS 88 

4.3.1.  Ánh xạ nhãn 88 

4.4.  Giải pháp cung cấp QoS trong MPLS 90 

4.5.  Giải pháp định tuyến QoS 92 

4.5.1.  Điều khiển gán nhãn độc lập và theo yêu cầu 93 

4.5.2.  Phát hiện và chống vòng lặp 94 

4.5.3.  Các thuật toán định tuyến QoS trong MPLS 104 

4.6.  Giải pháp báo hiệu đảm bảo QoS 106 

4.6.1.  Mô hình IntServ và MPLS 106 

4.6.2.  Mô hình DiffServ và MPLS 113 

KẾT LUẬN LUẬN VĂN 117 

TÀI LIỆU THAM KHẢO 118 

TỪ VIẾT TẮT

Từ viết tắt Giải nghĩa tiếng anh Giải nghĩa tiếng việt

AF Assured Forwarding Chuyển tiếp đảm bảo

AQM Active Queue Management Quản lý hàng đợi hoạt động ATM Asychronous Transfer Mode Phương thức truyền không

đồng bộ

BA Behavior Aggressive Kết hợp hành vi

B-ISDN Broadband ISDN Mạng tích hợp dịch vụ băng

rộng CBR Constant Bit Rate Tốc độ bít cố định

CBS Committed Burst Size Kích thước bùng nổ cam kết CIR Committed Information Rate Tốc độ thông tin cam kết CoS Class of Service Lớp dịch vụ

DiffServ Differential Service Dịch vụ phân biệt

DLL Data Link Layer Lớp liên kết dữ liệu

DS Different Service Dịch vụ phân biệt

DSCP Differential Service Code Point Điểm mã dịch vụ phân biệt ECN Explicit Congestion Notification Thông báo tắc nghẽn

EF Expedited Forwarding Chuyển tiếp nhanh

FIFO First In First Out Hàng đợi vào trước ra trước

FQ Fair Queueing Hàng đợi ngang bằng

GoS Grade of Seviche Cấp độ dịch vụ

IETF Internet Engineering Task Force Ủy ban kỹ thuật thực thi

Internet IntServ Intergrated Service Dịch vụ tích hợp

IPLR IP Loss Rate Tỷ lệ tổn thất gói tin IP IPTD IP Packet Transfer Delay Truyền tải gói tin IP

IPER IP Error Rate Tỷ lệ lỗi gói tin IP

ISO International Standard Organization Tổ chức tiêu chuẩn quốc tế

ITU-T International Telecommunication

Union

Hiệp hội viễn thông quốc tế

MF Multi Fields Phân loại đa đường

MoS Mean of Score Giá trị trung bình

MPLS Multi Protocol Label Switching Chuyển mạch nhãn đa giao

thức

NL Network Layer Lớp mạng

NNI Network Node Interface Giao diện node mạng

PBS Packet Burst Size Kích thước bùng nổ gói

PHB Per Hop Behavior Hành vi kế tiếp

PIR Peak Information Rate Tốc độ thông tin đỉnh

PQ Priority Queueing Hàng đợi ưu tiên

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

RED Random Early Discardin Loại bỏ gói sớm ngẫu nhiên RFC Request For Comments Các yêu cầu cần trả lời

RSVP Resource reservation protocol Giao thức dành trước tài

nguyên RSVP-TE RSVP- Traffic Engineering RSVP- lưu lượng

SLA Service Level Argreement Thoa thuận dịch vụ

srTCM Single rate Three Color Marker Bộ đánh dấu 3 màu tốc độ đơn TCA Traffic Conditioning Agreement Thỏa thuận điều kiện lưu lượng ToS Type of Service Kiểu dịch vụ

trTCM Two rate Three Color Marker Bộ đánh dấu 3 màu hai tốc độ WFQ Weighted Fair Queueing Hàng đợi cân bằng trọng số WRED Weighted Random Early Discard Loại bỏ gói sớm theo trọng số WRR Weighted Round Robin Quay vòng theo trọng số

DANH MỤC BẢNG BIỂU

Bảng 1.1: Sáu thông số của QoS 14 

Bảng 1.2: Các ứng dụng và yêu cầu về chất lượng dịch vụ 34 

Bảng 1.3 : Các mức chất lượng dịch vụ 35 

Bảng 3.1: Các bit IP precedence 73 

Bảng 3.2: Các chỉ thị về hiệu năng 73 

Bảng 3.3: Các khối giá trị DSCP 74 

Bảng 3.4: Các DSCP của AF 77 

Bảng 4.1 : DiffServ PHB ánh xạ tới EXP 116 

DANH MỤC HÌNH VẼ Hình 1.1 (a) băng thông , (b) trễ 16

Hình 1.2: FTP truyền file giữa các hệ thống 22

Hình 1.3: Phân loại các kỹ thuật sửa đổi dữ liệu phía người gửi 28

Hình 1.4: Sửa đổi dữ liệu sử dụng FEC 29

Hình 1.5: Sửa chữa sử dụng FEC phụ thuộc vào môi trường 30

Hình 1.6: Các khối được đan xen trong nhiều gói 32

Hình 1.7: Phân loại các kỹ thuật che dấu lỗi 34

Hình 2.1: Khoảng thời gian đo CBS và CIR 40

Hình 2.2a: Gáo C và Gáo E ở chế độ mù màu 40

Hình 2.2b: srTCM ở chế độ mù màu 41

Hình 2.3: srTCM ở chế độ rõ mầu 42

Hình 2.4a: Gáo rò C và P trong trTCM .43

Hình 2.4b: trTCM ở chế độ mù màu 43

Hình 2.5: Chế độ rõ mầu với trTCM 44

Hình 2.6: Sơ đồ nguyên lý hoạt động của RED 45

Hình 2.7: Hồ sơ RED 46

Hình 2.8: Khái niệm ECN 47

Hình 2.9: Biểu đồ khái niệm của Lập lịch gói 48

Hình 2.11: Hàng đợi ưu tiên (PQ) 50

Hình 2.12: Ảnh hưởng của kích thước gói với phân bố băng thông 51

Hình 2.13: WRR 52

Hình 2.14: Vòng quay Robin trọng số theo từng Bit 54

Hình 2.15: WFQ 55

Hình 2.16: CB WFQ 56

Hình 2.17: Bộ định dạng lưu lượng thường 58

Hình 2.18: Gáo rò token traffic shaper 59

Hình 3.1: Hoạt động của RSVP 62

Hình 3.2: Các kiểu dành riêng của RSVP 63

Hình 3.3: Các ống chia sẽ được dành riêng 63

Hình 3.4: Ví dụ 1 về RSVP trong IntSer 65

Hình 3.5: Ví dụ 2 về RSVP trong IntSer 66

Hình 3.6: Ví dụ về RSVP Style 66

Hình 3.7: Dành riêng Wildcard filter 67

Hình 3.8: Dành riêng fixed filter 68

Hình 3.9: Dành riêng Shared-explicit 68

Hình 3.10: Các bước của DiffServ 69

Hình 3.11: Miền IP 70

Hình 3.12: Một miền DS và các mạng con 70

Hình 3.13: Miền DiffServ 71

Hình 3.14: Vùng DS 71

Hình 3.15: IPv4 Header 24 byte 72

Hình 3.16: Trường TOS trong IPv4 header 73

Hình 3.17: IPv6 Header 48 byte 73

Hình 3.18: Trường DS 74

Hình 3.19: Ví dụ về cài đặt EF 76

Hình 3.20: Một ví dụ cài đặt AF 79

Hình 3.21: Ví dụ về DiffServ 80

Hình 4.1: Chức năng định tuyến IP chuẩn 83

Hình 4.2: Khiến trúc của MPLS 85

Hình 4.3: Đầu mào MPLS 86

Hình 4.4: Xếp chồng nhãn độ sâu m 86

Hình 4.5: MPLS LSP sử dụng ATM SVC 87

Hình 4.6: MPLS LSP sử dụng ATM SVP 87

Hình 4.7: MPLS LSP sử dụng ATM SVP mã hóa đa điểm 88

Hình 4.8: Ánh xạ nhãn vào 88

Hình 4.9: Ánh xạ FTN 88

Hình 4.10: Trao đổi nhãn 89

Hình 4.11: Đẩy nhãn 90

Hình 4.13: Kiến trúc MPLS 92

Hình 4.14: Điều khiển độc lập 94

Hình 4.15: Điều khiển theo yêu cầu 94

Hình 4.16: Giao thức LDP với các giao thức khác 97

Hình 4.17: Thủ tục phát hiện LSR lân cận 99

Hình 4.18: Các kịch bản phân phối nhãn 101

Hình 4.19: Thủ tục LSR hướng xuống (downstream) 104

Hình 4.20: Thực hiện phân bổ nhãn qua RSVP-TE 107

Hình 4.21: Nhãn phân phối trong bảng tin RESV 109

Hình 4.22: Cấu trúc báo hiệu 115

Hình 4.23: Ánh xạ của Diffserv PHB sang bit EXP MPLS 116

LỜI NÓI ĐẦU

Ngày nay, Viễn thông phát triển nhanh chóng và không ngừng cùng với đó là sự phát triển bùng nổ các loại hình dịch vụ để thỏa mãn nhu cầu công tác cũng như giải trí của con người Kéo theo đó hàng loạt các công nghệ và các giải pháp mới được ra đời nhằm nâng cao chất lượng dịch vụ mạng, đây là vấn đề luôn được quan tâm của

cả người sử dụng và cả nhà cung cấp dịch vụ Việc đảm bảo chất lượng dịch vụ mạng luôn được đặt lên làm tiêu chí hàng đầu của nhà cung dịch vụ mạng đồng thời với đó sự phát triển mạnh mẽ của đa dịch vụ trên nền IP Yêu cầu càng lớn hơn cho nhà cung cấp dịch vụ cần có các giải pháp kỹ thuật để cải thiện chất lượng dịch vụ được ưu tiên hàng đầu

Đảm bảo chất lượng dịch vụ là điều quan trọng trong việc cung cấp dịch vụ mạng giữa nhà cung cấp với người sử dụng Ứng dụng trong công nghệ mới với sự ra đời của các mô hình ứng dụng đã giải quyết được bài toán đa dịch vụ nhưng vẫn đảm bảo được yêu cầu về chất lượng dịch vụ đề ra

MPLS là một trong những công nghệ mới được phát triển tại Việt Nam Trong giới hạn chuyên đề này em xin được trình bày phần mô hình chất lượng dịch vụ IP trong MPLS dưới các mô hình ứng dụng và các giải pháp cũng như các kỹ thuật để đảm bảo tốt nhất chất lượng dịch vụ trên công nghệ MPLS

Luận văn bao gồm 4 chương chính:

Chương 1: Chất lượng dịch vụ trong mạng truyền thông Chương này trình

bày một cách khái quát và đơn giản nhất về chất lượng dịch vụ IP

Chương 2: Các kỹ thuật đảm bảo chất lượng dịch vụ Chương này trình bày

các kỹ thuật, mô hình để đảm bảo và nâng cao chất lượng dịch vụ trong môi trường

truyền

Chương 3: Chất lượng dịch vụ trong mạng IP Chương này trình bầy hai mô

hình triển khai IP QoS khác nhau đó là: IntServ và DiffServ

Chương 4: QoS trong mạng chuyển mạch nhãn đa giao thức MPLS Chương

này trình bày về các mô hình và các giải pháp để đảm bảo chất lượng dịch vụ trong mạng chuyển mạch nhãn đa giao thức

Do còn hạn chế về thời gian và kiến thức nên nội dung luận văn vẫn còn nhiều hạn chế và thiếu sót mong các thầy góp ý thêm và thông cảm, trong quá trình làm luận văn đã được thầy Nguyễn Hữu Thanh hưỡng dẫn nhiệt tình và chu đáo, xin chân thành cãm ơn thầy đã giúp em hoàn thành luận văn này

IP thì khác, nó ra đời với mục đích truyền tải dữ liệu

Đối với mạng điện thoại, khi thiết lập một cuộc gọi mạng sẽ phải dành riêng một kênh kết nối trong suốt quá trình hội thoại Khi cuộc gọi kết thúc, các kênh này

sẽ được tiếp tục sử dụng cho một cuộc gói khác Có thể đưa ra hai phép đo chính đối với chất lượng dịch vụ trong mạng điện thoại, thứ nhất là tỷ lệ thiết lập cuộc gọi thành công và thứ hai là chất lượng các cuộc gọi, những vấn đề này sẽ chịu ảnh hưởng bởi dung lượng truyền dẫn trung kế của mạng và các vấn đề như lỗi đường truyền hay nhiễn mạch

Với đặc tính như vậy, mạng điện thoại đã được thiết kế với hai vấn đề chính, thứ nhất là làm sao để cung cấp đủ các mạch trung kế phục vụ cho nhiều cuộc gọi đồng thời qua đó nâng cao tỷ lệ kết nối thành công Thứ hai là phải tối ưu mạng để giảm tối đa những vấn đề như suy hao, nhiễu, vọng và trễ Thoại là một loại dịch vụ thời gian thực và nó không cần hàng đợi để lưu trữ tín hiệu âm thanh

Mạng IP ra đời có rất nhiều điểm khác so với mạng điện thoại Thứ nhất mạng

IP được thiết kế để truyền tải dữ liệu Thứ hai các dịch vụ truyền dữ liệu đa phần là các dịch vụ không thời gian thực, dữ liệu có thể được lưu lại trong mạng và truyền đi sau, khi dữ liệu truyền đi bị lỗi nó có thể được truyền lại Các dịch vụ truyền dữ liệu còn được gọi là dịch vụ “lưu và chuyển tiếp” Mô hình hoạt động của mạng IP như vậy sẽ được gọi là best-effort

Việc thiết kế các mạng khác nhau sẽ tạo ra những vấn đề như kinh phí đầu tư

hạ tầng sẽ lớn, khi kết nối các mạng với nhau sẽ trở nên phức tạp Vào giữa những

năm 90 các nhà thiết kế mạng đã đưa ra một ý tưởng là tạo ra một mạng duy nhất dựa trên chuyển mạch gói để truyền tải cả âm thanh và dữ liệu Và mạng này thường được gọi là mạng thế hệ mới Next-Generation-Network Mạng này được thiết kế chủ

yế dựa trên nền mạng IP, nhưng những nhược điểm của mô hình best-effort của mạng IP không phù hợp với các loại dịch vụ âm thanh, hình ảnh, đa phương tiện cần thời gian thực Để khắc phục những hạn chế này, các mô hình chất lượng dịch vụ trong mạng IP đã phát triển và đóng một vai trò then chốt trong vấn đề phát triển mở rộng của mạng cũng như khả năng cung cấp các loại dịch vụ khác nhau trên cùng một hạ tầng mạng

Những nghiên cứu dưới đây sẽ đi vào những vấn đề mà mạng IP cần quan tâm

đề đảm bảo chất lượng dịch vụ

1.1 Khái niệm về chất lượng dịch vụ:

Chất lượng dịch vụ là một vấn đề rất khó để định nghĩa chính xác, nó được bắt nguồn từ việc đáp ứng các nhu cầu đòi hỏi của người sử dụng dịch vu còn gọi la QoE, bởi vì đối với các dịch vụ khác nhau yêu cầu về chất lượng dịch vụ khác nhau

Ví dụ như với dịch vụ thoại chất lượng dịch vụ cung cấp tốt khi thoại được rõ ràng, tức là chúng ta phải đảm bảo tốt về giá trị tham số trễ, biến động trễ Nhưng giá trị tham số mất gói thông tin về một tỉ lệ tổn thất nào đó có thể chấp nhận được

Nhưng giả dụ, đối với khách hàng là người sử dụng trong truyền số liệu ở ngân hàng thì điều tối quan trọng là độ tin cậy, họ có thể chấp nhận trễ lớn, độ biến động trễ lớn, nhưng thông số mất gói, độ bảo mật kém thì họ không thể chấp nhận được v.v

Từ các yêu cầu của khách hàng Nhà cung cấp dịch vụ mạng cần phải đảm bảo chất lượng dịch vụ để cung cấp cho khách hàng, và thực hiện các biện pháp để duy trì mức QoS khi điều kiện mạng bị thay đổi vì các nguyên nhân như nghẽn, hỏng hóc thiết bị hay lỗi liên kết, v v QoS cần được cung cấp cho mỗi ứng dụng

Chất lượng dịch vụ chỉ có thể được xác định bởi người sử dụng, vì chỉ người

sử dụng mới có thể biết được chính xác ứng dụng của mình cần gì để hoạt động tốt Tuy nhiên, không phải người sử dụng tự động biết được mạng cần phải cung cấp

những gì cần thiết cho ứng dụng, họ phải tìm hiểu các thông tin cung cấp từ người quản trị mạng và chắc chắn rằng, mạng không thể tự động đặt ra QoS cần thiết cho một ứng dụng của người sử dụng Để giải quyết vấn đề đó nhà cung cấp và khách hàng lập ra một bản cam kết, trong đó nhà cung cấp phải thực hiện đầy đủ cung cấp các thông số thoả mãn chi tiết bản cam kết đặt ra Còn phía đối tác cũng phải thực hiện đầy đủ điều khoản của mình

Nếu một mạng được tối ưu hoàn toàn cho một loại dịch vụ, thì người sử dụng

ít phải xác định chi tiết các thông số QoS Ví dụ, với mạng PSTN, được tối ưu cho thoại, không cần phải xác định băng thông hay trễ cần cho một cuộc gọi Tất cả các cuộc gọi đều được đảm bảo QoS như đã được quy định trong các chuẩn liên quan cho điện thoại

Nếu nhìn từ góc độ mạng thì bất cứ một mạng nào cũng bao gồm:

- Hosts (chẳng hạn như: Servers, PC…)

- Các bộ định tuyến và các thiết bị chuyển mạch

- Đường truyền dẫn

Nếu nhìn từ khía cạnh thương mại:

- Băng thông, độ trễ, jitter, mất gói, tính sẵn sàng và bảo mật đều được coi là tài nguyên của mạng Do đó với người dùng cụ thể phải được đảm bảo sử dụng các tài nguyên một cách nhiều nhất

- QoS là một cơ chế quản lý tài nguyên tiên tiến và tối ưu nhất của mạng để đảm bảo

có một chính sách ứng dụng thỏa mãn được các yêu cầu từ phía người sử dụng

Vậy định nghĩa chính xác QoS là rất khó khăn nhưng ta có thể hiểu chúng gần như là khả năng cung cấp dịch vụ (ở lớp phần tử mạng, vvv ) đưa ra cho khách hàng thông qua những yêu cầu chính xác (trên khả năng thực tế hay lý thuyết) có thể đáp ứng dựa trên bản hợp đồng về thoả thuận lưu lượng Sự định nghĩa khuôn dạng của

nó kết thành chất lượng dịch vụ của lớp mạng do sự phân phát chất lượng dịch vụ của peer-to-peer (ngang hàng) edge-to-edge (biên tới biên) hay end-to-end (đầu cuối tới đầu cuối) Lẽ tự nhiên những yêu cầu này có thể thay đổi từ phía ứng dụng cho ứng dụng hay từ phân phối dịch vụ

Vậy trong tất cả những điều đã nêu về cấp QoS, đảm bảo chất lượng và Service Level Agreement SLA thỏa thuận mức độ dịch vụ, để thoả mãn ta phải làm như thế nào? Vấn đề là bản chất định hướng IP là một mạng nỗ lực tối đa do đó

“không tin cậy" khi yêu cầu nó đảm bảo về QoS Cách tiếp cận gần nhất để các nhà cung cấp dịch vụ IP có thể đạt tới đảm bảo QoS hay SLA giữa khách hàng và ISP là với dịch vụ mạng IP được quản lý Thuật ngữ được quản lý ở đây là bất cứ cái gì mà nhà cung cấp dịch vụ quản lý thay mặt cho khách hàng , điều đó cũng làm nâng cao được chất lượng dịch vụ

1.2 Các thông số QoS:

Để đáp ứng được các yêu cầu từ phía ngời sử dụng dịch vụ QoE, thì các nhà cung cấp dịch vụ cần phải phân tích các dịch vụ mà mình cung cấp để chuyển các yêu cầu đó thành các thông số của mạng Đây được gọi là các thông số QoS của mạng Có sáu thông số chung về chất lượng dịch vụ như sau:

Các giá trị ví dụ, được liệt kê trong Bảng 1.1

Thông số QoS Các giá trị ví dụ

Bảo mật Mã hoá và nhận thực trên tất cả các luồng lưu lượng

Bảng 1.1: Sáu thông số của QoS

Để làm rõ hơn về sáu thông số QoS này ta đi vào tìm hiểu chi tiết của từng thông số như sau

1.2.1 Băng thông

Băng thông là thông số quan trọng nhất, nếu chúng ta có băng thông dùng rộng rãi thì mọi vấn đề gần như không cần phải quan tâm đến nhiều, như nghẽn, kỹ thuật lập lịch, phân loại, trễ….tuy nhiên điều này rất khó để đạt được trong một mạng có quy mô lớn và có nhiều người sử dụng

Băng thông chỉ đơn giản là thước đo số lượng bit trên giây mà mạng sẵn sàng cung cấp cho các ứng dụng Các ứng dụng bùng nổ (bursty) trên mạng chuyển mạch gói có thể chiếm tất cả băng thông của mạng nếu không có ứng dụng nào khác cùng bùng nổ với nó Khi điều này xảy ra, các bùng nổ phải được đệm lại và xếp hàng chờ truyền đi, do đó tạo ra trễ trên mạng Để giải quyết hạn chế về băng thông này đã có nhiều giải pháp tiết kiệm, hay tối ưu băng thông đã được đưa ra

Khi được sử dụng như là một thông số QoS, băng thông ở mức tối thiểu mà một ứng dụng cần để hoạt động Ví dụ, thoại PCM 64 kb/s cần băng thông là 64 kb/s Điều này không tạo ra khác biệt khi mạng xương sống có kết nối 45 Mb/s giữa các nút mạng lớn Băng thông cần thiết được xác định bởi băng thông nhỏ nhất sẵn có trên mạng Nếu truy nhập mạng thông qua một MODEM V.34 hỗ trợ chỉ 33.6 kb/s, thì mạng xương sống 45 Mb/s sẽ làm cho ứng dụng thoại 64 kb/s không hoạt động được Băng thông QoS nhỏ nhất phải sẵn sàng tại tất cả các điểm giữa các người sử dụng Các ứng dụng dữ liệu được lợi nhất từ việc đạt được băng thông cao hơn Điều này được gọi là các “ứng dụng giới hạn băng thông”, bởi vì hiệu quả của ứng dụng

dữ liệu trực tiếp liên quan tới lượng nhỏ nhất của băng thông sẵn sàng trên mạng Mặt khác, các ứng dụng thoại như thoại PCM 64 kb/s được gọi là các “ứng dụng giới hạn trễ” Thoại PCM 64 kb/s này sẽ không hoạt động tốt hơn chút nào nếu có băng thông 128 kb/s Loại thoại này phụ thuộc hoàn toàn vào thông số QoS trễ của mạng

để có thể hoạt động đúng đắn

1.2.2 Trễ

Trễ có liên quan rất chặt chẽ với băng thông Với các ứng dụng giới hạn băng thông thì băng thông càng lớn trễ sẽ càng nhỏ Đối với các ứng dụng giới hạn trễ, như là thoại PCM 64 kb/s, thông số QoS trễ xác định trễ lớn nhất các bit gặp phải khi truyền qua mạng Tất nhiên là các bit có thể đến với độ trễ nhỏ hơn

Trễ được định nghĩa là khoảng thời gian chênh lệch giữa hai thời điểm của cùng một bít khi đi vào mạng (thời điểm bít đầu tiên vào với bít đầu tiên ra)

Với băng thông có nhiều cách tính, giá trị băng thông có thể thường xuyên thay đổi Nhưng thông thường giá trị băng thông được định nghĩa là số bit của một khung chia cho thời gian trôi qua kể từ khi bit đầu tiên rời khỏi mạng cho đến khi bit cuối cùng rời mạng

Hình 1.1 (a) băng thông , (b) trễ Mối quan hệ giữa băng thông và trễ trong mạng được chỉ ra trong hình 1.1 Trong phần (b), t2 – t1 = số giây trễ Trong phần (a), X bit/ (t3 - t2) = bit/s băng thông

Băng thông lớn hơn có nghĩa là nhiều bit đến hơn trong một đơn vị thời gian, trễ tổng thể sẽ nhỏ hơn Đơn vị của mỗi thông số, bit/s với băng thông hay giây với trễ, cho thấy mối quan hệ hiển nhiên giữa băng thông và trễ

Các mạng chuyển mạch gói cung cấp cho các ứng dụng các băng thông biến đổi phụ thuộc vào hoạt động và bùng nổ của ứng dụng Băng thông biến đổi này có nghĩa là trễ cũng có thể biến đổi trên mạng Các nút mạng được nhóm với nhau cũng

có thể đóng góp vào sự biến đổi của trễ Tuy nhiên, thông số QoS trễ chỉ xác định trễ lớn nhất và không quan tâm tới bất kỳ giới hạn nhỏ hơn nào cho trễ của mạng Nếu cần trễ ổn định, thì một thông số QoS khác cần phải quan tâm đến, đó chình là biến động trễ Jitter sẽ được trình bày sau đây

Một số nguyên nhân gây ra trễ trong mạng IP:

Trễ do quá trình truyền trên mạng

Trễ do xử lý gói trên đường truyền

Trễ do xử lý hiện tượng biến động trễ jitter

Trễ do việc xử lý sắp xếp lại gói đến (xử lý tại đích)

1.2.3 Jitter (Biến động trễ)

Như đã được nói đến ở trên, biến động trễ là sự khác biệt về độ trễ của các gói tin khác nhau trong cùng một dòng lưu lượng Biến động trễ có tần số cao được gọi

là jitter với tần số thấp gọi là eander Nguyên nhân chủ yếu gây ra hiện tượng jitter

do sự sai khác trong thời gian xếp hàng của các gói liên tiếp nhau trong một hàng gây ra.Trong mạng IP jitter ảnh hưởng rất lớn tới chất lượng dịch vụ của tất cả các dịch

vụ Thông số QoS jitter thiết lập giới hạn lên giá trị biến đổi của trễ mà một ứng dụng có thể gặp trên mạng Jitter không đặt một giới hạn nào cho giá trị tuyệt đối của trễ, nó có thể tương đối thấp hoặc cao phụ thuộc vào giá trị của thông số trễ

Jitter theo lý thuyết có thể là một giá trị thông số QoS mạng tương đối hay tuyệt đối Ví dụ, nếu trễ mạng cho một ứng dụng được thiết lập là 100 ms, jitter có thể đặt là cộng hay trừ 10 phần trăm của giá trị này Theo đó, nếu mạng có trễ trong khoảng 90 đến 110 ms thì vẫn đạt được yêu cầu về jitter (trong trường hợp này, rõ ràng là trễ không phải là lớn nhất) Nếu trễ là 200 ms, thì 10 phần trăm giá trị jitter sẽ cho phép bất kỳ trễ nào trong khoảng 180 đến 220 ms Mặt khác, jitter tuyệt đối giới hạn cộng trừ 5 ms sẽ giới hạn jitter trong các ví dụ trên trong khoảng từ 95 tới 105

ms và từ 195 tới 205 ms

Các ứng dụng nhạy cảm nhất đối với giới hạn của jitter là các ứng dụng thời gian thực như thoại hay video, ví dụ như dịch vụ IPTV Nhưng đối với các trang Web hay với truyền tập tin qua mạng thì lại ít quan tâm hơn đến jitter Internet, là

gốc của mạng dữ liệu, có ít khuyến nghị về jitter Các biến đổi của trễ tiếp tục là vấn

đề gây bực mình nhất gặp phải đối với các ứng dụng video và thoại dựa trên Internet

1.2.4 Mất gói

Mất thông tin là một thông số QoS không được đề cập thường xuyên như là băng thông và trễ, đặc biệt đối với mạng Internet Đó bởi vì bản chất tự nhiên được thừa nhận của mạng Internet là "cố gắng tối đa" Nếu các gói IP không đến được đích thì Internet không hề bị đổ lỗi vì đã làm mất chúng Điều này không có nghĩa là ứng dụng sẽ tất yếu bị lỗi, bởi vì đối với những dịch vụ khác nhau đều đặt ra giá trị ngưỡng của riêng mình Nếu các thông tin bị mất vẫn cần thiết đối với ứng dụng thì

nó sẽ yêu cầu bên gửi gửi lại bản sao của thông tin bị mất Bản thân mạng không quan tâm giúp đỡ vấn đề này, bởi vì bản sao của thông tin bị mất không được lưu lại tại bất cứ nút nào của mạng

Thực ra Internet là mạng của các mạng và không có cơ chế giám sát đầy đủ nào đảm bảo chất lượng thông tin truyền Hiện tượng mất gói tin là kết quả của rất nhiều nguyên nhân :

• Quá tải lượng người truy nhập cùng lúc mà tài nguyên mạng còn hạn chế

• Hiện tượng xung đột trên mạng LAN

• Lỗi do các thiết bị vật lý và các liên kết truy nhập mạng

Cho một ví dụ nếu một kết nối bị hỏng, thì tất cả các bit đang truyền trên liên kết này sẽ không, và không thể, tới được đích Nếu một nút mạng ví dụ như bộ định tuyến hỏng, thì tất cả các bit hiện đang ở trong bộ đệm và đang được xử lý bởi nút đó

sẽ biến mất không để lại dấu vết Do những loại hư hỏng này trên mạng có thể xảy ra bất cứ lúc nào, nên việc một vài thông tin bị mất do lỗi trên mạng là không thể tránh khỏi

Tác động của mất thông tin là tuỳ thuộc vào ứng dụng Điều khiển lỗi trên mạng là một quá trình gồm hai bước, mà bước đầu tiên là xác định lỗi Bước thứ hai

là khắc phục lỗi, nó có thể đơn giản là bên gửi truyền lại đơn vị bị mất thông tin Một vài ứng dụng, đặc biệt là các ứng dụng thời gian thực, không thể đạt hiệu quả khắc phục lỗi bằng cách gửi lại đơn vị tin bị lỗi Các ứng dụng không phải thời gian thực

thì thích hợp hơn đối với cách truyền lại thông tin bị lỗi, tuy nhiên cũng có một số ngoại lệ (ví dụ như các hệ thống quân sự tấn công mục tiêu trên không thể sử dụng hiệu quả với cách khắc phục lỗi bằng truyền lại)

Vì những lý do này, thông số QoS mất thông tin không những nên định rõ một giới hạn trên đối với ảnh hưởng của lỗi mà còn nên cho phép người sử dụng xác định xem có lựa chọn cách sửa lỗi bằng truyền lại hay không Tuy nhiên, hầu hết các mạng (đặc biệt là mạng IP) chỉ cung cấp phương tiện vận chuyển thụ động, còn xác định lỗi, khắc phục lỗi thường được để lại cho ứng dụng (hay người sử dụng)

1.2.5 Tính sẵn sàng (Độ tin cậy)

Là tỉ lệ thời gian mạng hoạt động để cung cấp dịch vụ Yếu tố này bất kỳ nhà cung cấp dịch vụ nào tối thiểu cũng phải có Tổn thất khi mạng bị ngưng trệ là rất lớn Tuy nhiên, để đảm bảo được tính sẵn sàng chúng ta cần phải có một chiến lược đúng đắn, ví dụ như: định kỳ tạm thời tách các thiết bị ra khỏi mạng để thực hiện các công việc bảo dưỡng, trong trường hợp mạng lỗi phải chuẩn đoán trong một khoảng thời gian ngắn nhất có thể để giảm thời gian ngừng hoạt động của mạng Tất nhiên, thậm chí với một biệt pháp bảo dưỡng hoàn hảo nhất cũng không thể tránh được các lỗi không thể tiên đoán trước

Đối với mạng PSTN vì là mạng thoại nên điều này luôn luôn chiếm một vị trí quan trọng Mạng đảm bảo hoạt động 24/24 trong ngày , tất cả những ngày lễ, kỉ niệm, khi nhu cầu lớn hay ngay cả khi nhu cầu giảm xuống rất thấp Thông thường tỉ

lệ thời gian hoạt động là 99,999%

Mạng dữ liệu thực hiện công việc đó dễ hơn Hầu hết mạng dữ liệu dành cho kinh doanh, và do đó hoạt động trong những giờ kinh doanh, thường là từ 8 giờ sáng đến 5 giờ chiều, từ thứ Hai đến thứ Sáu Hoạt động bổ trợ có thể thực hiện "ngoài giờ", và một tập kiểm tra đầy đủ với mục đích phát hiện ra các vấn đề có thể chạy trong ngày nghỉ

Internet và Web đã thay đổi tất cả Mọi mạng toàn cầu phải giải quyết vấn đề rằng thực sự có một số người luôn cố gắng truy nhập vào mạng tại một số địa điểm

Và thậm chí Internet có thể có ích ở nhà vào 10 giờ tối hơn là ở cơ quan vào 2 giờ chiều

Tuy nhiên, nếu người sử dụng nhận thức rõ rằng họ không thể có mạng như mong muốn trong tất cả thời gian, và thông số QoS khả dụng thường được quy cho mỗi vị trí hoặc liên kết riêng lẻ

1.2.6 Bảo mật:

Bảo mật là một thông số mới trong danh sách thông số QoS, nhưng lại là một thông số quan trọng Thực tế, trong một số trường hợp độ bảo mật có thể được xét ngay sau băng thông Gần đây, do sự đe doạ rộng rãi của các hacker và sự lan tràn của virus trên mạng Internet toàn cầu đã làm cho bảo mật trở thành vấn đề hàng đầu

Hầu hết vấn đề bảo mật liên quan tới các vấn đề như tính riêng tư, sự tin cẩn

và xác nhận khách và chủ Các vấn đề liên quan đến bảo mật thường được gắn với một vài hình thức của phương pháp mật mã, như mã hoá và giải mã Các phương pháp mật mã cũng được sử dụng trên mạng cho việc xác nhận (authentication), nhưng những phương pháp này thường không liên quan chút nào đến vấn đề giải mã

Toàn bộ kiến trúc đều xuất phát từ việc bổ sung thêm tính riêng tư hoặc bí mật

và sự xác nhận hoặc nhận thực cho mạng Internet Giao thức bảo mật chính thức cho

IP, gọi là IPSec, đang trở thành một kiến trúc cơ bản để cung cấp thương mại điện tử trên Internet và ngăn ngừa gian lận trong môi trường VoIP Thật trớ trêu là mạng Internet công cộng toàn cầu, thường xuyên bị coi là thiếu bảo mật nhất, đã đưa vấn

đề về bảo mật trở thành một phần của IP ngay từ khi bắt đầu Một bit trong trường loại dịch vụ (ToS) trong phần tiêu để gói IP được đặt riêng cho ứng dụng để có thể bắt buộc bảo mật khi chuyển mạch gói Tuy nhiên lại nảy sinh một vấn đề là không

có sự thống nhất giữa các nhà sản xuất bộ định tuyến khi sử dụng trường ToS

Người sử dụng và ứng dụng có thể thêm phần bảo mật của riêng mình vào mạng, và trong thực tế, cách này đã được thực hiện trong nhiều năm Nếu có chút nào bảo mật mạng, thì nó thường dưới dạng một mật khẩu truy nhập vào mạng Các mạng ngày nay cần một cơ chế bảo mật gắn liền với nó, chứ không phải thêm vào một cách bừa bãi bởi các ứng dụng

Một thông số QoS bảo mật điển hình có thể là "mã hoá và nhận thực đòi hỏi trên tất cả các luồng lưu lượng" Nếu có lựa chọn, thì truyền dữ liệu có thể chỉ cần

mã hoá, và kết nối điện thoại Internet có thể chỉ cần nhận thực để ngăn gian lận

1.3 Yêu cầu QoS đối với các dịch vụ khác nhau:

1.3.1 Ứng dụng E-mail, FTP:

E-mail là một dịch vụ phổ biến nhất trên Internet trước khi World Wide Web

ra đời, nó được đưa ra để người sử dụng trên mạng có thể trao đổi các thông báo cho nhau trên phạm vi thế giới Bằng dịch vụ này, mọi người sử dụng máy tính kết nối với Internet đều có thể trao đổi thông tin với nhau Đây là một dịch vụ mà hầu hết các mạng diên rộng đều cài đặt và cũng là dịch vụ cơ bản nhất của một mạng khi gia nhập Internet Nhiều người sử dụng máy tính tham gia mạng chỉ dùng duy nhất dịch

vụ này Dịch vụ này sử dụng giao thức SMTP (Simple Mail Transfer Protocol) trong

họ giao thức TCP/IP

Một điểm mạnh của thư điện tử là nó là phương thức trao đổi thông tin nhanh chóng và thuận tiện Người sử dụng có thể trao đổi những bản tin ngắn hay dài chỉ bằng một phương thức duy nhất Rất nhiều người sử dụng thường truyền tập tin thông qua thư điện tử chứ không phải bằng các chương trình truyền tập tin thông thường Đặc điểm của dịch vụ thư điện tử là không tức thời (off-line) - tất cả các yêu cầu gửi đi không đòi hỏi phải được xử lý ngay lập tức Khi người sử dụng gửi một bức thư, hệ thống sẽ chuyển thư này vào một vùng riêng (gọi là spool) cùng với các thông tin về người gửi, người nhận, địa chỉ máy nhận Hệ thống sẽ chuyển thư đi bằng một chương trình không đồng bộ (background) Chương trình gửi thư này sẽ xác định địa chỉ IP máy cần gửi tới, tạo một liên kết với máy đó Nếu liên kết thành công, chương trình gửi thư sẽ chuyển thư tới vùng spool của máy nhận Nếu không thể kết nối với máy nhận thì chương trình gửi thư sẽ ghi lại những thư chưa được chuyển và sau đó sẽ thử gửi lại một lần nó hoạt động Khi chương trình gửi thư thấy một thư không gửi được sau một thời gian quá lâu (ví dụ 3 ngày) thì nó sẽ trả lại bức thư này cho người gửi Với cơ chế hoạt động như trên thì rõ ràng đối với dịch vụ E-mail không đòi hỏi yếu tố thời gian thực do vậy yêu cầu QoS đòi hỏi không quá lớn

Khi mạng xẩy ra tắc nghẽn các mail có thể ngừng chuyển đi mà có thể đợi khi mạng rỗi trở lại thì thực hiện truyền đi Tuy nhiên một yêu cầu đối vơi E-mail đó là độ tin cậy, các gói gửi đi phải đảm bảo đến đích và nội dung cần phải chính xác hòan toàn

Do vậy đòi hỏi mạng không bị mất gói, hoặc khi có xẩy ra mất gói thì phải có cơ chế truyền lại an toàn do vậy E-mail sử dụng TCP

FTP (File Transfer Protocol) là giao thức truyền một file từ một host tới một host khác Hình 1.2 diễn tả tổng quan về FTP

Hình 1.2: FTP truyền file giữa các hệ thống Dịch vụ FTP có những yêu cầu giống với dịch vụ E-mail về chất lượng truyền dẫn, nó không đòi hỏi nhiều về độ trễ hay jitter, các file có thể đến đích nhanh khi có nhiều băng thông hay chậm khi băng thông bị hạn chế nhưng quan trọng các gói nhận được phải đầy đủ và không có lỗi FTP cũng sử dụng giao thức TCP để khi có mất gói hay lỗi gói thì có sự truyền lại

1.3.2 Ứng dụng Streaming, âm thanh hình ảnh lưu trước:

Có rất nhiều ứng dụng khác nhau chạy trên nền mạng Internet như Streaming, Stored Audio và video Trong các ứng dụng này, các client đưa ra yêu cầu các file

âm thanh hình ảnh nén được lưu trữ trong máy chủ Các file âm thanh được lưu trước

có thể gồm thu thanh bài giảng của một giáo sư, một bài hát, một bản giao hưởng, nội dung từ một kênh radio quảng bá, hoặc một đoạn ghi âm lịch sử Các file video

Truy n file

FTP server 

Giao tiếp người dùng FTP

File hệ thống remote

được lưu trước có thể gồm có các video về một bài giảng của giáo sư, đủ một bộ phim, các chương trình tivi đã ghi lại từ trước, phim tài liệu, các hình ảnh về các sự kiện lịch sử, các clip nhạc hình hay hoạt hình Có ba đặc tính quan trọng để phân biệt các lớp ứng dụng này

Stored Media: các nội dung media đã được ghi trước và được lưu tại máy chủ

Do vậy, người dùng có thể tạm dừng, tua lại và tua nhanh cũng như chọn điểm em của chương trình Thời gian từ khi một client đưa ra yêu cầu đến khi hình ảnh hiện ra tại client vào khoảng 1 tới 10 giây là có thể chấp nhận được

Streaming: Trong hầy hết các ứng dụng âm thanh, hình ảnh một máy khách

bắt đầu hiển thị các âm thanh hình ảnh sau khi nó nhận file từ máy chủ Bằng cách này mà máy khách sẽ hiển thị được hình ảnh, âm thanh từ chỗ trong file trong khi nó vẫn nhận phần còn lại của file từ máy chủ Kỹ thuật này gọi là streaming, để tránh việc phải dowload toàn bộ file (và phải chịu độ trễ lớn) trước khi bắt đầu hiển thị ra

Có nhiều sản phẩm phần mền phục vụ cho streaming đa phương tiện, gồm có RealPlayer của hãng RealNetwork vàWindows Media của Microsoft Tuy nhiên cũng có các ứng dụng như Napster yêu cầu tòan bộ file phải được dowload trước khi bắt đầu hiện thị

Continuous phayout: Khi bắt đầu hiển thị một hình ảnh, nên bắt đầu dựa vào

định thời gốc của hình ảnh Cách này tạo ra một độ trễ đáng kể cho việc phân phát dữ liệu Dữ liệu phải được nhận từ máy chủ kịp thời cho việc hiển thị ở máy khách; ngược lại thì mọi thứ trở nên vô nghĩa Trễn end to end là bắt buộc đối với streaming, stored media thường ít liên tục hơn so với các chương trình trực tuyến, các ứng dụng tương tác như là thoại trên internet và hội nghị truyền hình

1.3.3 Ứng dụng Streaming cho âm thanh, hình ảnh sống

Lớp ứng dụng này tương tự như các chương trình radio và tive quản bá cổ điển, ngoại trừ việc truyền dẫn là thông qua Internet Các ứng dụng này cho phép một người dùng nhận live radio hoặc tivi truyền từ bất cứ nơi nào trên thế giới Có thể xen trên Yahoo !Broadcast 2000 và Netradio 2000 trên Internet

Bởi vì streaming của âm thanh hình ảnh sống không được lưu trước, một máy khách không thể tua nhanh Hơn nữa với phần dữ liệu đã được lưu trong bộ nhớ của máy khách, thì các hành động tương tác như là dừng và tua lại là có thể thực hiện ở một số ứng dụng Các ứng dụng sống, quảng bá online thường có nhiều máy khách nhận cùng một chương trình Việc phân bố ânh thanh/ hình ảnh tới nhiều nơi nhận có thể đạt được bằng kỹ thuật multicast

1.3.4 Ứng dụng Hình ảnh âm thanh tương tác thời gian thực

Lớp ứng dụng này cho phép người dùng sử dụng âm thanh hình ảnh để kết nối với người khác theo thời gian thực Âm thanh tương tác thời gian thực thường được

đề cập tới là điện thoại Internet, theo quan điểm từ phía người dùng, nó tương đương như dịch vụ điện thoại chuyển mạch kênh cổ điển Điện thoại internet có thể cung cấp bằng các tổng đài nội bộ PBX, dịch vụ điện thoại đường dài với giá cả thấp Nó cũng cung cấp cả dịch vụ tích hợp điện thoại máy tình, kết nối nhóm thời gian thực, các dịch vụ chuyển huớng, định danh người gọi, lọc người gọi và nhiều dịch vụ khác Hiện nay đã có nhiều sản phẩn điện thoại Internet Với các video tương tác hay còn gọi là hội nghị truyền hình thì có sản phẩm NetMeeting của Microsoft Chú ý rằng các ứng dụng âm thanh hình ảnh tương tác, một user có thể nói hoặc di chuyển bất cứ lúc nào Với một cuộc hội thoại tương tác giữa nhiều người, trễ từ lúc một người nói

và di chuyển cho tới khi hành động đó được chuyển tới đầu nhận nên nhỏ hơn một vài trăm ms Với âm thanh, độ trễ nhỏ hơn 150ms là không thể cảm nhận được đối với người nghe Độ trễ từ 150ms tới 400ms là có thể chấp nhận được, và độ trễ lớn hơn 400ms là có thể dẫn đến cuộc hội thoại mà các bên không hiểu nhau nói gì

1.3.5 Ví dụ về điện thoại VOIP:

Tầng IP cung cấp các dịch vụ best-effort Với best-effort các gói được truyền

đi từ nguồn tới đích một cách nhanh nhất có thể Hơn nữa, best-effort không đảm bảo bất cứ điều gì về độ trễ end to end của các gói, hay biến động trễ hay việc mất gói trong luồng dữ liệu

Các ứng dụng đa phương tiện tương tác thời gian thực, như là điện thoại internet và hội nghị truyền hình thời gian thực thường rất nhẩy cảm với trễ gói, biến

động trễ và mất gói Chính vì vậy cần phải có các kỹ thuật để đảm bảo các ứng dụng

âm thanh hình ảnh khi truyền qua mạng mà các giá trị về trễ, jitter và mất gói không vượt quá mức quy định Chúng ta sẽ xem xét một kỹ thuật trong ngữ cảnh là ứng dụng điện thoại Internet và trong hội nghị truyền hình thời gian thực thì cũng tương

tự

Một người gọi điện trong ứng dụng VOIP sinh ra một tín hiệu âm thanh gồm

có khoảng có âm và các khoảng lặng Để tiết kiệm băng thông, ứng dụng điện thoại internet chỉ sinh ra các gói trong khi nói Trong khi nói người gửi sinh ra các byte với tốc độ 8Kbyte/s, và cứ 20 ms người gửi tập hợp các byte thành các đoạn Bởi vậy, số lượng byte trong một đoạn là (20ms).(8byte)=160 byte Một đoạn mào đầu được gắn vào mỗi đoạn Các đoạn và mào đầu của nó được đóng gói trong khung UTP, rồi các khung UTP được gửi tới giao diện Socket Bởi vậy trong quá trình nói, một khung UTP được gửi định kỳ 20ms

Nếu như mỗi gói truyền tới phía nhận với độ trễ cố định, các gói được nhận ở phía người nghe định kỳ 20ms trong quá trình nói Trong điều kiện lý tưởng, phía nhận có thể nghe lại các đoạn một cách đơn giản Nhưng, một số gói có thể bị mất và các gói sẽ không có cùng độ trễ, đặc biệt trong khi xẩy ra tắc nghẽn trên mạng Vì vậy phía nhận phải quan tâm tới việc xác định khi nào diễn tả lại đoạn và xác định làm gì với các đoạn mất

Hạn chế của dịch vụ Best-effort

Như đã đề cập dịch vụ best-effort có thể dẫn đến mất gói, trễ lớn và biến động trễ lớn Bây giời ta sẽ xem xét vấn đề này một cách chi tiết hơn

Mất gói: Giả sử một khung UDP được sinh ra bởi ứng dụng VOIP Các khung

UDP được đóng gói trong IP packet Khi các packet truyền đi trong mạng, nó phải đi qua các buffer (hành đợi) trong các router để đi tới đường ra Hoàn toàn có thể là một hoặc nhiều hàng đợi trong router bị đầy và không thể tiếp nhận các IP packet Trong trường hợp này, các IP packet sẽ bị loại bỏ và phía nhận sẽ không thể nhận được

Mất gói có thể loại bỏ bằng cách gửi các gói thông qua TCP mà không dùng UDP Bởi TCP truyền lại các gói không nhận được từ phía đích Hơn nữa, kỹ thuật

truyền lại không phù hợp với các ứng dụng tương tác thời gian thực như là VOIP bởi

vì chúng sẽ tăng độ trễ Hơn nữa, bởi vì đặc tính điều khiển tắc nghẽn của TCP, sau khi gói mất tốc độ truyền tại phía gửi có thể giảm và làm cho tốc độ này nhỏ hơn tốc

độ ở phía nhận Điều này có thể có một số trở ngại trong vấn đề nhận dạng âm thanh tại phía thu Với lý do đó, hầu hết các ứng dụng VOIP thường chạy trên UDP và không thực hiện việc truyền lại gói tin

Thực ra vấn đề mất gói không nghiêm trọng như chúng ra nghĩ Thực ra, tỷ lệ mất gói nằm trong khoảng từ 1% đến 20% có thể chấp nhận được, dựa vào cách mà

âm thanh mã hóa và truyền đi, và cách mà mất gói có thể che giấu ở phía thu Ví dụ, forward error correction (FEC) có thể giúp cho việc che giấu được sự mất gói Với FEC, các thông tin dư thừa được truyền cùng với thông tin gốc để mà một số dữ liệu gốc lỗi có thể khôi phục lại từ các dữ liệu dư thừa Tuy nhiên, nếu một hoặc một số đường link giữa người nhận và người gửi có tắc nghẽn, các gói mất vượt quá 20% thì khó có thể đảm bảo chất lượng âm thanh

Trễ end to end:

Trễ end to end là gồm có trễ xử lý và trễ hàng đợi trên router, trễ lan truyền,

và các trễ xử lý tại đầu cuối dọc theo đường từ nguồn tới đích Với những ứng dụng tương tác cao, như là VOIP, trễ end to end nhỏ hơn 150ms thì người nghe sẽ không cảm nhận được; trễ giữa 150ms và 400ms có thể chấp nhận được nhưng chưa lý tưởng; và trễ vượt quá 40 ms sẽ làm hỏng các cuộc hội thoại tương tác bằng âm thanh

Biến động trễ :

Một thành phần chủ yếu đối với trễ end to end là trễ hành đợi ngẫu nghiên trong một router Bởi vì trễ là khác nhau trong mạng, thời gian từ lúc một gói được sinh ra ở nguồn cho đến khi nó nhận ở phía thu có thể giao động giữa các gói với nhau Hiện tượng này được gọi là jitter

Một ví dụ, giả sử hai gói liên tiếp nhau trong lúc phát tiếng nói đi vào ứng dụng VOIP Người gửi gửi gói thứ hai 20ms sau khi gửi gói thứ nhất Nhưng ở phía nhận, khoảng thời gian giữa các gói có thể lên đến hơn 20ms Để làm rõ điều này, giả

sử gói đầu tiên ở gần hàng đợi trống của router, nhưng sau khi gói thứ nhất rời đi thì tại hàng đợi có nhiều gói từ nguồn khác đến cùng hàng đợi đó Do vậy gói thứ hai phải chịu độ trễ hàng đợi lớn hơn, gói thứ nhất và thứ hai trở nên xa nhau hơn 20ms Khoảng thời gian giữa các gói cũng có thể nhỏ hơn 20ms Để thấy rõ điều này, lại giả sử hai gói liên tiếp trong đó gói thứ nhất đi vào phần cuối của hàng đợi với một

số lượng lớn các gói, và gói thứ hai đến hàng đợi trước khi các gói từ nguồn khác tới Trong trường hợp này, hai gói đang xét sẽ ở gần kề nhau trong hàng đợi Nếu như thời gian để truyền một gói trong đi ra ngoài nhỏ hơn 20ms thì gói thứ nhất và thứ hai sẽ cách nhau khoảng thời gian nhỏ hơn 20ms

Nếu như phía nhận bỏ qua sự tồn tại của jitter, và khôi phục các đoạn như là những gì nhận được, khi đó sẽ dẫn đến chất lượng âm thanh trở nên không nhận ra tại phía thu Tuy nhiên jitter có thể được loại bỏ bằng cách sử dụng sequence number, timestamps và plauout delay

Loại bỏ jitter tại đầu thu đối với âm thanh

Đối với ứng dụng âm thanh như VOIP hoặc âm nhạc theo yêu cầu, phía nhận nên cung cấp khả năng phát đồng bộ các đoạn âm thanh khi mà vẫn tồn tại jitter mạng Điều này thực hiện được bằng việc kết hợp ba kỹ thuật sau :

Gán vào mỗi đoạn một số liên tục Người gửi tăng dãy số liên tục lên một đối với các gói tin sinh ra

Gán cho mỗi đoạn một nhãn thời gian Phía gửi gán mỗi đoạn một thời gian cho mỗi đoạn được sinh ra

Hiển thị trễ các đoạn ở phía nhận Hiển thị trễ các đoạn âm thanh nhận được phải đủ dài để cho các gói nhận được trước khi lên lịch hiển thị Trễ hiển thị có thể được cố định trong khoảng thời gian trong suốt toàn bộ thời gian hội nghị, hoặc có thể thay đổi tùy biến trong thời gian hội nghị Các gói không đến được trước khi thời gian lên lịch hiển thị sẽ bị coi là mất; như đã đề cập, phía nhận có thể sử dụng một số dạng nội suy tiếng nói để cố gắng làm ẩn đi sự mất gói

Khôi phục lại gói mất:

Chỉnh sửa dữ liệu phía người gửi (Sender-Based Repair)

Một số kỹ thuật chỉnh sửa dữ liệu với sự tham gia của bên gửi luồng dữ liệu

có thể để phục hồi các gói bị mất Các kỹ thuật này có thể chia thành hai loại: sự truyền lại tích cực và mã hoá kênh thụ động Mã hoá kênh thụ động lại được chia làm hai dạng là sửa lỗi trước (FEC: Forward Error Correction) và sự sắp xếp đan xen FEC có thể là : không phụ thuộc môi trường (media-independent) hay phụ thuộc môi trường (media-specific) Sự phân loại này được thể hiện ở hình 1.3

Hình 1.3: Phân loại các kỹ thuật sửa đổi dữ liệu phía người gửi

Để đơn giản cho thảo luận tiếp theo chúng ta tách biệt khái niệm đơn vị dữ liệu và gói dữ liệu Một đơn vị là một khoảng thời gian dữ liệu về âm thanh, chúng được lưu trữ ở thiết bị đầu cuối tại công cụ audio Một gói bao gồm một hay nhiều đơn vị liên kết với nhau để truyền dẫn trên mạng

- Sửa lỗi trước (Forward Error Correction)

Một số kỹ thuật hiệu chỉnh lỗi trước đã được phát triển để khắc phục sự mất mát dữ liệu trong thời gian truyền dẫn Bằng cách đưa thêm dữ liệu vào luồng gửi đi

ta có thể phục hồi được nội dung của các gói bị mất

+ FEC độc lập với môi trường (Media-independent FEC)

Có nhiều phương pháp mã hoá FEC không phụ thuộc vào dữ liệu như là mã hoá đại số hay mã khối để thêm vào các gói tin trong quá trình truyền dẫn giúp chúng

Sửa lỗi dựa trên người gửi

Phụ thuộc môi trường

Độc lập môi trường

ta hiệu chỉnh sự mất gói Mỗi mã có một từ mã riêng và kết hợp với k gói dữ liệu để tạo ra n-k gói kiểm tra, kết quả là số gói được truyền trên mạng là n gói

Hình 1.4: Sửa đổi dữ liệu sử dụng FEC

Có rất nhiều cách mã hoá khối song ở đây chỉ đề cập đến hai cách là : mã hoá chẵn lẻ và mã Reed-Solomon Các cách mã hoá khối này đầu tiên được sử dụng để phát hiện và hiệu chỉnh các lỗi trong luồng bít truyền dẫn bằng cách tạo ra các bít kiểm tra từ các bít dữ liệu Một luồng các gói được truyền đi chúng ta quan tâm tới

sự mất mát các gói tin của nó vì vậy chúng ta phải áp dụng cách mã hoá khối thông qua các các bít trong các khối của các gói tin

Trong mã hoá chẵn lẻ các thao tác XOR được áp dụng cho một nhóm các gói

để tạo ra các gói tin chẵn lẻ phù hợp Trong giản đồ hình 1.4 thì cứ n-1 gói dữ liệu lại truyền đi một gói chẵn lẻ Với điều kiện chỉ mất một gói trong n gói dữ liệu được truyền đi thì gói mất đó sẽ được phục hồi lại Có nhiều cách mã hoá chẵn lẻ khác nhau bắt nguồn từ sự tổ hợp khác nhau về XOR của các gói Một vài cách mã hoá kiểu này được đề cập bởi Budge và đã được tổng kết bởi Rosenberg và Schulzrinne

Mã Reed- Solomon (RS) rất nổi tiếng về việc hiệu chỉnh các lỗi Việc mã hoá dựa trên thuộc tính của các đa thức Bản chất của mã hoá RS là lấy một số từ mã và

sử dụng chúng làm hệ số của đa thức f(x)

Phương pháp FEC có nhiều ưu điểm Trước tiên, về cách mã hoá độc lập với môi trường, các thao tác của FEC không phụ thuộc vào nội dung gói tin và khi sửa

chữa sẽ lập lại chính xác vị trí của gói tin bị mất Các thao tác tính toán nhằm khắc phục gói tin bị mất và khôi phục chúng là rất đơn giản Nhược điểm của phương pháp này là thêm độ trễ, tăng băng thông và công cụ mã hoá khó khăn

+ FEC phụ thuộc vào môi trường (Media-specific FEC)

Một cách đơn giản để chống lại sự mất gói tin là truyền mỗi khối audio trong nhiều gói Nếu một gói bị mất thì nội dung của gói khác có khối tương tự sẽ khôi phục lại gói bị mất đó Nguyên lý này được minh hoạ trong hình 1.5 Cách làm này được đề nghị bởi Hardman và Bolot và được mở rộng bởi Podolsky

Hình 1.5: Sửa chữa sử dụng FEC phụ thuộc vào môi trường

Bản sao truyền dẫn đầu tiên của dữ liệu audio được truyền như là mã hoá chính và sau đó truyền tiếp theo như là mã hoá phụ Ta có thể gửi lược đồ mã hoá phụ giống như lược đồ mã hoá chính Nhưng thường thì sơ đồ mã hoá phụ có băng thông nhỏ hơn và chất lượng thấp hơn sơ đồ mã hoá chính

Lựa chọn sơ đồ mã hoá là vấn đề khó khăn và phụ thuộc vào cả yêu cầu băng thông và độ phức tạp tính toán của bộ mã hoá (Erdol sử dụng phương pháp mã hóa

và giải mã thông qua việc đo và thống kê các bit 0 (zero) trong khoảng thời gian ngắn)

Ưu điểm của việc sử dụng sơ đồ này là ít phải thực hiện tính toán và có thể nhanh chóng được mã hoá Hardman và Bolot đề nghị sử dụng cách mã hoá phân

tích-tổng hợp tốc độ bít thấp chẳng hạn như LPC (2,4-5,6 kb/s) và mã hoá GSM toàn tốc (13kb/s)

Nếu bộ mã hoá chính dùng bộ xử lý mạnh để cho ta chất lượng vừa phải và băng thông thấp thì bộ mã hoá phụ có thể sử dụng giống như bộ mã hoá chính Một

ví dụ của trường hợp này là bộ mã hoá G.723.1 của hiệp hội viễn thông quốc tế ITU

sử dụng một phần lớn sức mạnh tính toán của bộ xử lý cá nhân, nó cho ta độ rộng băng thông thấp (5,3/6,3 kb/s)

Sử dụng FEC phụ thuộc vào môi trường thì ta phải chịu một tiêu đề gói lớn Trong ví dụ sử dụng 8 kHz PCM (64 kb/s) như là sơ đồ mã hoá chính và GSM (13 kb/s ) làm mã hoá phụ thì kết quả là kích thước của gói dữ liệu sẽ tăng thêm 20% Giống như sơ đồ FEC độc lập với môi trường thì tiêu đề của FEC phụ thuộc vào môi trường có thể thay đổi Tuy nhiên, không giống như các giản đồ mã hoá khác, tiêu đề của gói tin trong FEC phụ thuộc vào môi trường có thể giảm đi mà vẫn có thể phục hồi được gói bị mất nhưng với mức chất lượng thấp hơn Giảm tiêu đề gói đã được

sử dụng cho các ứng dụng audio

Khác với nhiều công nghệ phía đầu gửi khác đã được thảo luận, sử dụng FEC phụ thuộc vào môi trường có ưu điểm là độ trễ thấp chỉ có độ trễ gói đơn được thêm vào Điều này phù hợp cho các ứng dụng mang tính tương tác

- Đan xen (Interleaving)

Khi kích thước của khối nhỏ hơn kích thước của gói tin và trễ từ đầu cuối tới đầu cuối là không quan trọng, đan xen (interleaving) là kỹ thuật hữu ích cho việc giảm hiệu ứng mất gói Trước khi truyền các khối được sắp xếp lại Các khối cạnh nhau được tách ra xa nhau với khoảng cách đảm bảo trong luồng được truyền dẫn và lập lại thứ tự các gói tin tại bên nhận Đan xen làm giảm hiệu ứng mất gói Nếu cho

ví dụ các khối có chiều dài là 5ms và các gói chiều dài 20 ms (tức là 4 khối trong một gói) thì gói thứ nhất chứa các khối 1, 5, 9, 13; các khối của gói thứ hai là 2, 4, 6, 14 Thí dụ minh hoạ được thể hiện trên hình 1.6

Hình 1.6: Các khối được đan xen trong nhiều gói Khi xuất hiện mất một gói đơn từ dòng lưu lượng được đan xen thì kết quả là tạo ra nhiều các khe nhỏ trong dòng dữ liệu khôi phục, khác với xuất hiện một khe lớn trong dòng dữ liệu không đan xen

Nhược điểm của đan xen là nó làm tăng thêm độ trễ Đây là giới hạn của sử dụng kỹ thuật cho các ứng dụng tương tác Bởi vậy nó thường chỉ được sử dụng cho các ứng dụng không tương tác Ưu điểm chính của đan xen là nó không yêu cầu dùng thêm băng thông cho dòng dữ liệu truyền

- Sự phát lại gói tin (Retransmission)

Các ứng dụng audio tương tác bị giới hạn độ trễ và yêu cầu trễ từ đầu cuối tới đầu cuối nhỏ hơn 250 ms Đây là lý do không thể sử dụng việc truyền lại cho các gói

bị mất Nếu trễ từ đầu cuối tới đầu cuối nhỏ thì vẫn có thể chấp nhận được Sơ đồ multicast tin cậy được phát triển rộng khắp dựa trên việc truyền lại các gói bị mất là SRM (Scaleble Reliable Multicast) Khi các phần tử của một SRM phát hiện ra mất gói, nó sẽ đợi một khoảng thời gian ngẫu nhiên xác định bởi khoảng cách từ nguồn

có dữ liệu bị mất và sau đó truyền đa hướng các yêu cầu sửa chữa

Trong khi các giao thức SRM và tương tự sẽ phù hợp cho truyền đa hướng tin cậy của dữ liệu, chúng không phù hợp cho các luồng đa phương tiện chẳng hạn như

là audio Điều này là bởi vì chúng không giới hạn trễ truyền dẫn và khắc phục gói bị

mất có thể lấy một lượng bất kỳ của thời gian Một số lượng lớn các giao thức truyền

đa hướng tin cậy Có rất nhiều các giao thức truyền đa hướng tin cậy đã được biết tới nhưng mà không phù hợp cho luồng đa phương tiện do đó sẽ không được nghiên cứu

ở đây Lý do tương tự như vậy TCP là không phù hợp cho audio truyền đẫn đơn hướng Nói như vậy không có nghĩa là các giản đồ truyền lại gói tin không được sử dụng cho luồng đa phương tiện, Các giao thức có thể được sử dụng để truyền dẫn lại nhưng giới hạn cho phép yêu cầu truyền lại cho một khối dữ liệu Giản đồ truyền dẫn lại làm việc tốt khi tỉ lệ mất gói là tương đối nhỏ Khi tỉ lệ mất gói tăng lên thì yêu cầu truyền dẫn lại gói tin tăng lên

Việc truyền đẫn lại một khối tín hiệu audio không cần thiết phải truyền dẫn gói tin nguồn mà khối có thể mã hoá lại với băng thông nhỏ hơn Có sự tương đồng

về truyền lại và truyền thêm thông tin dư thừa và một giao thức có thể có cả truyền dẫn lại và truyền dẫn dư thừa thông tin Điều này cho phép bên nhận không tham gia vào việc xử lý các gói tin truyền lại nếu trễ xuất hiện là lớn

Các kỹ thuật sửa lỗi phía người nhận (Receiver-based repair)

Chúng ta có một số kỹ thuật để che giấu lỗi có thể sử dụng tại bên nhận của dòng audio và không yêu cầu sự giúp đỡ từ bên gửi Kỹ thuật này sử dụng khi sơ đồ phục hồi ở bên gửi thất bại trong hiệu chỉnh tất cả các lỗi hoặc khi bên gửi của dòng

dữ liệu không thể tham gia vào quá trình phục hồi

Sơ đồ che giấu lỗi dựa vào kết quả lặp lại gói tin bị lỗi trong luồng lưu lượng truyền dẫn Điều này có thể thực hiện được với tín hiệu âm thanh Kỹ thuật này sử dụng cho luồng lưu lượng có tỉ lệ mất gói nhỏ (<15%) và dùng cho các gói nhỏ (4-40 ms) Khi mà gói tin có độ dài lớn thì kĩ thuật này sẽ không áp dụng được vì nó gây lỗi ở phía người nghe

Phân loại kỹ thuật phục hồi phía nhận được thể hiện trong hình 1.7 Các kỹ thuật này được phân làm 3 loại:

Hình 1.7: Phân loại các kỹ thuật che dấu lỗi

Chèn: Sửa chữa trên cơ sở chèn (Insertion-Based) được thực hiện chèn bằng

cách chèn các gói lấp đầy vào các vị trí gói mất Các gói được sử dụng để chèn có thể là khoảng lặng, tiếng ồn hoặc gói nhận được trước đó Với kỹ thuật lặp sẽ thay thế các gói bị mất bằng các gói ngay trước gói đó Nó có độ phức tạp thấp và thực hiện dễ dàng Trong một số trường hợp phương pháp này có thể cho kết quả tốt

Nội suy: Phương pháp này sử dụng một vài dạng tính toán và nội suy để đưa

ra được gói tin tương tự như gói bị mất Các kỹ thuật này gặp nhiều khó khăn trong thực hiện và yêu cầu tính toán nhiều so với sơ đồ chèn

Tái tạo lại: Máy thu sẽ tìm cách tái tạo lại gói tin bị mất từ các gói tin nhận

được Cách này cũng khó thực hiện nhưng nó có thể cho kết quả tốt

1.3.6 Các lớp dịch vụ

Dưới đây là bảng phân ra một số loại ứng dụng phổ biến cũng như các yêu cầu tài nguyên của chúng

Bảng 1.2: Các ứng dụng và yêu cầu về chất lượng dịch vụ

STT Tên ứng dụng Mất gói Băng thông Nhậy cảm với trễ

và Jitter

1 Truyền file

FTP

Không mất gói

Không đòi hỏi cố định

Không

2 Email Không mất Không đòi hỏi cố Không

ở một mức nhất định

Đòi hỏi cố định

Âm thanh: từ vài Kb đến 1Mb

Hình ảnh: từ 10Kb đến

ở một mức nhất định

Đòi hỏi cố định

Âm thanh: từ vài Kb đến 1Mb

Hình ảnh: từ 10Kb đến

8Mb

Có, khoảng vài Giây

6 Game tương

tác

Có thể mất gói

ở một mức nhất định

7 Ứng dụng tài

chính

Không mất gói

Không đòi hỏi cố định

Đối với các loại giao dịch thì có

Đối với các trao đổi dữ liệu thì không

Tất cả các ứng dụng đều yêu cầu một mức chất lượng dịch vụ nhất định, mỗi úng dụng đều có một số đặc tính cơ bản khác nhau Để nhận biết các các yêu cầu chất lượng dịch vụ, hệ thống thường nhận biết qua các lớp dịch vụ Theo quan điểm của ITU-T, khuyến nghị I-1541 các lớp dịch vụ được chia thành các mức như trên bảng 1.3 dưới đây:

Bảng 1.3 : Các mức chất lượng dịch vụ

Lớp QoS Các đặc tính QoS

0 Thời gian thực, nhậy cảm với jitter, tương tác cao

1 Thời gian thực, nhậy cảm với jitter, tương tác

2 Dữ liệu chuyển giao, tương tác cao

3 Dữ liệu chuyển giao, tương tác

4 Tổn hao thấp (chuyển giao ngắn, dữ liệu video)

5 Các ứng dụng nguyên thủy của IP

Như vậy tham số thời gian thực và tương tác cao được đặt lên hành đầu đối với mạng IP, phần lớn các ứng dụng thực hiện tốt trong các mạng chuyển mạch hướng kết nối (chuyển mạch kênh và ATM) đáp ứng tốt được các yêu cầu này Trong khi mạng IP truyền thống không hỗ trợ QoS cho các dịch vụ thời gian thực

1.4 Một số kỹ thuật hỗ trợ chất lượng dịch vụ

Phân loại-Nhận dạng luồng: Để cung cấp sự ưu tiên cho một số luồng nhất

định, thì luồng phải được nhận dạng và nếu cần còn phải đánh dấu Hai nhiệm vụ này lại thường liên quan đến việc phân loại luồng Khi gói được nhận dạng nhưng không được đánh dấu, thì phân loại được gọi là trên cơ sở từng chặng Đó là khi việc phân loại chỉ liên quan đến thiết bị chứa gói đó mà không được chuyển tới bộ định tuyến

Xếp hàng: Do bản chất cụm của lưu lượng audio/video/data, thỉnh thoảng lưu

lượng vượt quá tốc độ của đường truyền (hay băng thông), ở trường hợp này thì bộ định tuyến sẽ phải làm gì? Một cách để các phần tử mạng giải quyết vấn đề tràn lưu lượng là sử dụng thuật toán hàng đợi để sắp xếp lưu lượng và sau đó xác định một số phương pháp để ưu tiên ở đầu ra hàng đợi Một số cơ chế hàng đợi hiện nay là:

Xếp hàng theo nguyên tắc vào trước ra trước (FIFO)