NGHIÊN cứu ẢNH HƯỞNG của lỗi ĐƯỜNG TRUYỀN lên kết nối INTERNET QUA ĐƯỜNG TRUYỀN vệ TINH

Người đầu tiên đã nghĩ ra vệ tinh nhân tạo dùng cho truyền thông là nhà viết truyện khoa học giả tưởng Arthur C. Clarke vào năm 1945. Ông đã nghiên cứu về cách phóng các vệ tinh, quỹ đạo của chúng và nhiều khía cạnh khác cho việc thành lập một hệ thống vệ tinh nhân tạo bao phủ thế giới. Ông cũng đề xuất việc sử dụng 3 vệ tinh địa tĩnh (geostationary) cho một hệ thống viễn thông, đủ để phủ sóng cho toàn bộ Trái Đất. Vệ tinh nhân tạo đầu tiên là SPUTNIK 1 được Liên bang Xô viết phóng lên ngày 4 tháng 10 năm 1957 đã chứng minh cho ý tưởng của Arthur C. Clarke. Sự kiện này là một là động lực thúc đẩy lớn lao đối với truyền thông vệ tinh của cả thế giới. Về mặt công nghệ, SPUTNIK không thể so sánh được với các vệ tinh hiện đại ngày nay. Nó chỉ đơn thuần phát ra các tín hiệu radio “bíp bíp” một cách đều đặn. Thế nhưng, đó quả thực là một bước tiến to lớn của con người trong việc chinh phục không gian. Chỉ ba năm sau vào năm 1960, vệ tinh ECHO của Mĩ trở thành vệ tinh truyền thông thực thụ đầu tiên của nhân loại với khả năng tiếp nhận và phản hồi lại các tín hiệu radio. Tiếp theo ECHO, vệ tinh địa tĩnh đầu tiên SYNCOM ra đời năm 1963 với ưu điểm lớn nhất là giữ được vị trí tương đối cố định so với mặt đất. Khả năng tuyệt vời này đặt nền tảng cho việc phủ sóng các chương trình thời sự toàn nước Mĩ tại thời đó. Sau đó, hàng loạt các vệ tinh thương mại được đưa lên quỹ đạo như INTELSAT1, vệ tinh nặng 68 kg này cung cấp 240 kênh điện thoại song công tương đương với một kênh truyền hình. Vệ tinh INTELSAT2 và INTELSAT3 với số kênh thoại lên tới 1200 kênh. Tới năm 1976 ra đời của MARISAT cung cấp dịch vụ truyền thông cho các phương tiện giao thông đường thủy, từ đó người ta thấy các ăngten parabol bắt đầu xuất hiện trên tầu thuyền, giúp các tầu thuyền có thể liên lạc thường xuyên với nhau và liên lạc với đất liền trong các hành trình khắp nơi trên thế giới. Hệ thống điện thoại vệ tinh di động đầu tiên, INMARSATA, được giới thiệu vào năm 1982. Sáu năm sau là INMARSATC. Đến năm 1993, các hệ thống điện thoại vệ tinh được số hóa toàn bộ. Năm 1998 đánh dấu thế hệ truyền thông vệ tinh mới với sự ra đời của các tổ hợp vệ tinh Iridium, đây là dự án đầy tham vọng của Motorola nhằm xây dựng một hệ thống vệ tinh thông tin di động phủ sóng khắp toàn cầu. Ban đầu dự án Iridium được thiết kế bao gồm 77 vệ tinh tạo thành một mạng lưới mà khi hoàn thành sẽ cho phép 2 điểm bất kỳ trên trái đất có thể liên lạc được với nhau. Tên của hệ thống (Iridium) được đặt theo tên của nguyên tố thứ 77 trong bảng hệ thống tuần hoàn, 77 vệ tinh quay quanh trái đất như 77 electron quay quanh hạt nhân nguyên tố Iridium. Khi triển khai thực tế, vì lý do kinh tế nên số vệ tinh được tính toán lại và chỉ còn là 66 vệ tinh, tuy nhiên tên của hệ thống vẫn được đặt như ban đầu. Khi đưa vào vận hành, hệ thống vệ tinh Iridium đã được coi như một thành tựu sáng chói của khoa học kỹ thuật. Một hệ thống vệ tinh đáng chú ý khác là hệ thống Globalstar, với 48 vệ tinh cung cấp các kênh truyền thương mại cho thấy sự phát triển thật ấn tượng của truyền thông vệ tinh chỉ sau hơn 30 năm kể từ ngày ra đời.

Mục lục

L

ời c ám ơ n 1

L ời c am đoa n 2

M ục l ụ c 3

D anh mục c á c hình vẽ 7

Ch ư ơng 1 Đặc t rư ng lỗi c ủ a đ ư ờng t r uyền vệ tin h 9

1 1 L ịch sử p h át t r iển và ư u nh ư ợc điểm của t r uyền thông vệ tin h 9

1 1 1 L ịch sử p h át t r iển của t r uyền thông vệ tin h 9

1 1 2 Ứng dụng c ủ a t r uyền thông vệ tinh 10

1 2 Đặc điểm lỗi đ ư ờng t r uyền vệ tinh 10

1 2 1 C ác số liệu thống kê c ác đ ặ c điểm lỗi đ ư ờng t r uyền vệ tin h 10

1 2 2 C ác mô hình lỗi t r ên đ ư ờng t r uyền vệ tin h 13

1 2 2 1 M ô hình lỗi đồng đ ều ( Uni f o r m Err or Model ) 14

1 2 2 2 M ô hình lỗi Ma r kov hai t r ạng thái (T wo - sta l e M a r kov Err or Mo d el ) 14

1 2 2 3 M ô hình lỗi Ma r kov hai t r ạng thái cải tiế n 15

1 2 2 4 M ô hình lỗi Ma r kov đa t r ạng thái ( Multi- s tate e rr or mo d el ) 15

Ch ư ơng 2 Giao th ứ c T CP và c á c c ơ c hế đ i ều khiển tắc nghẽ n 17

2 1 T ổng quan về g i ao th ứ c T CP 17

2 1 1 T ổng qua n 17

2 1 2 Cấu t r úc gói tin T C P 18

2 1 3 Cơ chế hoạt động c ủ a T C P 19

2 2 T CP và cơ chế điều khiển t ắc ng h ẽ n 21

2 2 1 Quá t r ình slow - sta r t v à c ongestion avoida n c e 21

2 2 2 Quá t r ình F ast - Ret r a n smi t 22

2 2 3 Quá t r ình F ast - R e cove r y 22

2 3 Một số ph i ên b ản T CP 23

2 3 1 T CP T ahoe 23

2 3 2 T CP Reno 24

2 3 3 T CP New - Ren o 25

2 3 4 T CP S ACK 25

2 4 Nh ữ ng vấn đề c ủa T CP t r ong môi t rư ờng mạng không dâ y 28

Ch ư ơng 3 Một số ph ư ơng pháp nâng c ao hiệu n ăng T CP t r ong mạng không d â y 29

3 1 L ink laye r 29

3 1 1 S noo p 30

3 1 2 W T C P 31

3 1 3 Kết luận 34

3 2 Chia kết nố i 35

3 2 1 I ndi r ect T CP (I - T C P ) 35

3 2 2 Kết luận 39

3 3 Cơ chế c ả nh báo t ư ờng minh E N (E xplicit No f itication ) 39

3 3 1 I CMP M e s sag e 39

3 3 2 P h ư ơng pháp thông báo mất dữ l i ệu t ư ờng minh EL N (E xplicit L oss

Noti f ication) 40

3 3 3 P h ư ơng pháp đ ếm s ynd r om e 41

3 3 4 P h ư ơng pháp A CK t h ành phần ( pa r tial A CK ) 41

3 3 5 Kết luận 42

3 4 P h ư ơng pháp E nd to E nd 42

3 4 1 Fr eeze T C P 43

3 4 2 T C P - W e stwood 44

Ch ư ơng 4 Giải p h áp PE P với g i ao th ứ c X CP và thí nghiệm mô phỏn g 52

4 1 T ổng q u át về T CP với XCP và giải pháp PE P 52

4 1 1 Giới thiệu về T CP 52

4 1 2 G i ao th ứ c X CP 53

4 1 3 Giải pháp sử dụng Pr oxy để nâng c ao hiệu s uất T CP - PEP s (P e rf o r mance E nhance m ent Pr oxies s olution ) 54

4 2 Giới thiệu bộ phần mềm mô phỏng NS 55

4 2 1 Bộ mô phỏng mạng NS ( Netwo r k S imulato r ) 55

4 2 2 S ử dụng phần mềm mô phỏng NS để mô phỏng đ ư ờng t r uyền vệ tin h 55

4 2 3 Cài đặt v ệ tinh và c ác t r ạm m ặt đấ t 56

4 2 4 Kết nối vệ tin h 57

4 2 5 Hỗ t r ợ theo dõi 58

4 3 Giới th i ệu thiết lập mô phỏng, kết luận v à h ư ớng l àm vi ệ c t r ong t ư ơng l a i 60

T ài liệu tham khả o 61

Danh mục các kí hiệu, các chữ viết tắt

AIMD additive increase multiplicative decrease

ARP Address Resolation Protocol

ATM Asynchronous Transfer Mode

BER Bit Error Rate

BWE Bandwidth Estimate

CWD Current window size

FTP File Transfer Protocol GEO

Geostationary Earth Orbit GSO Geo-Stationary Earth Orbit

HTTP Hypertext Transfer Protocol

IP Internet Protocol

I-TCP Indirect- TCP

LAN Local Area Network

LEO Low Earth Orbit

MAC Media Access Control

MIMD multiplicative increase multiplicative-decrease

MSR Mobile support router

PEP Performance Enhancement Proxy

RTO Retransmit time-out

RTO Retransmit Timeout

SACK Selective Acknowedgment options

TCL Tool Command Language

TCP Transmission Control Protocol

UDP User Datagram Protocol

URG User Datagram Protocol

VJCC Van Jacobson Congestion Control

WLAN Wireless Local Area Network

WTCP Wireless Transmission Control Protocol

XCP eXplicit Control protocol

4ZWA Zero Window AdvertisementZWP Zero Window Probe

Danh mục các hình vẽ

Hình 1 1 Mô hình mạng vệ tin h 11

Hình 1 2 Mô hình lỗi M a r kov h ai t r ạng t h á i 14

Hình 1 3 Mô hình lỗi M a r kov h ai t r ạng t h ái c ải tiế n 15

Hình 2 1 Gói s ố liệu T CP với p h ần tiêu đề gi ả 18

Hình 2 2 Cấu t r úc gói số liệu T CP 19

Hình 2 3 P h ư ơng th ứ c bắt tay b a b ư ớc- th i ết lập kết nối, c hấm d ứ t ph i ên làm việ c 20

Hình 2 4 Cơ chế quản lý g ử i dữ liệu theo c ử a s ổ c ủ a T C P 20

Hình 2 5 Quá t r ình slows t a r t và cong e stion avoid n c e 22

Hình 2 6 Quá t r ình F ast - Ret r a n smi t 23

Hình 2 7 Lư u đổ giải th u ật sl o wsta r t 23

Hình 2 8 Lư u đồ chi tiết T C P - T ah o e 24

Hình 2 9 Lư u đồ điểu khiển T C P - R en o 25

Hình 2 10 P h ư ơng th ứ c hoạt động S AC K 26

Hình 2 11 Option thông báo cơ c h ế điều khiển S AC K 26

Hình 2 12 Option thông tin S ACK 26

Hình 2 13 Q u á t r ình khai báo sử dụng S AC K 27

Hình 3 1 Lư ợc đồ p h ân loại c á c g i ải pháp tối ư u h ó a T CP t r ong môi t rư ờng không dâ y 29

Hình 3 2 Mô hình mạng không d ây với BS đóng vai t r ò S noo p 30

Hình 3 3 Lư u đồ S noop xử lý n h ận dữ liệu từ F H tại B S 31

Hình 3 4 Lư u đồ S noop xử lý khi nhận ACK từ M H t ại B S 31

Hình 3 5 Mô hình xử lý W T C P 31

Hình 3 6 Lư u đồ W T CP xử lý khi nhận dữ liệ u 32

Hình 3 7 Lư u đồ W T CP chu y ển tiếp gó i 33

Hình 3 8 Lư u đồ W T CP xử lý khi nhận AC K 34

Hình 3 9 Mô hình ch i a kết nối 35

Hình 3 10 Mô hình I - T C P 36

Hình 3 11 BS đóng vai t r ò như Pr oxy t r ong I-T C P 36

Hình 3 12 Quá t r ình xử lý chu y ển vùng ( hando ff ) c ủa I-T C P 37

Hình 3 13 C á c b ư ớc th ự c hiện t r ong quá t r ình hando f f của I - T C P 39

Hình 3 14 Mô hình xử lý A CK t h ành phầ n 42

Hình 3 15 Qui t r ình xử lý fr eeze T C P 43

Hình 3 16 Lư u đồ g i ải thuật T C P W tính s ố l ư ợng s egment đ ư ợc x ác nhậ n 46

Hình 3 17 Lư u đồ giải th u ật T C P W xử lý N du p ACKs tổng q u á t 47

Hình 3 18 Lư u đồ giải th u ật T C P W xử lý 3- dupAC K s th ự c nghiệ m 48

Hình 3 19 Lư u đồ giải th u ật T C P W xử lý timeout tổng quá t 49

Hình 3 20 Lư u đồ giải th u ật T C P W xử lý timeout th ự c nghiệ m 50

Hình 4 1 Cấu t r úc c ủa bộ mô phỏng N S -2 55

Hình 4 2 C á c thành phần chính c ủa mạng v ệ tin h 57

Hình 4 3 Cấu t r úc tập vết thông th ư ờng c ủa N S 58

6Hình 4 4 Mô hình mô phỏn g 60

Chương 1 Đặc trưng lỗi của đường truyền vệ tinh

1.1 Lịch sử phát triển và ưu nhược điểm của truyền thông vệ tinh

1.1.1 Lịch sử phát triển của truyền thông vệ tinh

Người đầu tiên đã nghĩ ra vệ tinh nhân tạo dùng cho truyền thông là nhà viết truyện khoa học giả tưởng Arthur C Clarke vào năm 1945 Ông đã nghiên cứu về cách phóng các vệ tinh, quỹ đạo của chúng và nhiều khía cạnh khác cho việc thành lập một hệ thống vệ tinh nhân tạo bao phủ thế giới Ông cũng đề xuất việc sử dụng 3 vệ tinh địa tĩnh (geostationary) cho một hệ thống viễn thông, đủ để phủ sóng cho toàn bộ Trái Đất Vệ tinh nhân tạo đầu tiên là SPUTNIK 1 được Liên bang Xô viết phóng lên ngày 4 tháng 10 năm 1957 đã chứng minh cho ý tưởng của Arthur C Clarke Sự kiện này là một là động lực thúc đẩy lớn lao đối với truyền thông vệ tinh của cả thế giới Về mặt công nghệ, SPUTNIK không thể so sánh được với các vệ tinh hiện đại ngày nay Nó chỉ đơn thuần phát ra các tín hiệu radio “bíp bíp” một cách đều đặn Thế nhưng, đó quả thực là một bước tiến to lớn của con người trong việc chinh phục không gian Chỉ ba năm sau vào năm 1960, vệ tinh ECHO của Mĩ trở thành vệ tinh truyền thông thực thụ đầu tiên của nhân loại với khả năng tiếp nhận và phản hồi lại các tín hiệu radio Tiếp theo ECHO, vệ tinh địa tĩnh đầu tiên SYNCOM ra đời năm 1963 với ưu điểm lớn nhất là giữ được vị trí tương đối cố định so với mặt đất Khả năng tuyệt vời này đặt nền tảng cho việc phủ sóng các chương trình thời sự toàn nước Mĩ tại thời đó

Sau đó, hàng loạt các vệ tinh thương mại được đưa lên quỹ đạo như INTELSAT-1,

vệ tinh nặng 68 kg này cung cấp 240 kênh điện thoại song công tương đương với một kênh truyền hình Vệ tinh INTELSAT-2 và INTELSAT-3 với số kênh thoại lên tới 1200 kênh Tới năm 1976 ra đời của MARISAT cung cấp dịch vụ truyền thông cho các phương tiện giao thông đường thủy, từ đó người ta thấy các ăng-ten parabol bắt đầu xuất hiện trên tầu thuyền, giúp các tầu thuyền có thể liên lạc thường xuyên với nhau và liên lạc với đất liền trong các hành trình khắp nơi trên thế giới Hệ thống điện thoại vệ tinh di động đầu tiên, INMARSAT-A, được giới thiệu vào năm 1982 Sáu năm sau là INMARSAT-C Đến năm 1993, các hệ thống điện thoại vệ tinh được số hóa toàn bộ Năm 1998 đánh dấu thế

hệ truyền thông vệ tinh mới với sự ra đời của các tổ hợp vệ tinh Iridium, đây là dự án đầy tham vọng của Motorola nhằm xây dựng một hệ thống vệ tinh thông tin di động phủ sóng khắp toàn cầu Ban đầu dự án Iridium được thiết kế bao gồm 77 vệ tinh tạo thành một mạng lưới mà khi hoàn thành sẽ cho phép 2 điểm bất kỳ trên trái đất có thể liên lạc được với nhau Tên của hệ thống (Iridium) được đặt theo tên của nguyên tố thứ 77 trong bảng

hệ thống tuần hoàn, 77 vệ tinh quay quanh trái đất như 77 electron quay quanh hạt nhân nguyên tố Iridium Khi triển khai thực tế, vì lý do kinh tế nên số vệ tinh được tính toán lại

và chỉ còn là 66 vệ tinh, tuy nhiên tên của hệ thống vẫn được đặt như ban đầu Khi đưa vào vận hành, hệ thống vệ tinh Iridium đã được coi như một thành tựu sáng chói của khoa học kỹ thuật Một hệ thống vệ tinh đáng chú ý khác là hệ thống Globalstar, với 48 vệ tinh cung cấp các kênh truyền thương mại cho thấy sự phát triển thật ấn tượng của truyền thông vệ tinh chỉ sau hơn 30 năm kể từ ngày ra đời

1.1.2 Ứng dụng của truyền thông vệ tinh

Hiện nay, vệ tinh được sử dụng trong các lĩnh vực sau:

? Nghiên cứu khoa học: Do có diện tích quan sát rộng nên vệ tinh đã được sử dụng

rộng rãi trong nghiên cứu trái đất, môi trường cũng như dự báo thời tiết Sử dụng các công nghệ hiện đại, vệ tinh còn có khả năng nhìn sâu vào trong lòng đất phục vụ các nghiên cứu địa chất, thăm dò tài nguyên Ngoài ra, với ưu điểm không bị cản trở bởi tầng khí quyển, các vệ tinh đã tỏ ra rất hiệu quả trong nghiên cứu thiên văn, vũ trụ

? Định vị: Các hệ thống định vị và định vị toàn cầu sử dụng vệ tinh đã trở nên phổ

? Thông tin liên lạc: Vệ tinh có điểm ưu việt mà không một hệ thống ăng ten hay

truyền

hình cáp nào có được là bán kính phủ sóng rộng lớn Chỉ có truyền thông vệ tinh mới phủ sóng được tới các vùng xa xôi như các hải đảo, các vùng cực, Đối với truyền thông di động, những ưu điểm của truyền thông vệ tinh được đặc biệt phát huy

? Làm đường trục cho điện thoại toàn cầu: Ngay từ khi ra đời truyền thông vệ tinh

đã

đóng vai trò quan trọng trong liên lạc toàn cầu, đường truyền vệ tinh có băng thông rộng,

có thể truyền được rất nhiều kênh truyền điện thoại

? Kết nối tới những vùng xa xôi hẻo lánh: Nhiều khu vực trên thế giới khó có thể

với vệ tinh địa tĩnh

1.2 Đặc điểm lỗi đường truyền vệ tinh

1.2.1 Các số liệu thống kê các đặc điểm lỗi đường truyền vệ tinh

Tỷ suất lỗi cao: Các hệ thống vệ tinh phát triển từ những vệ tinh truyền thông thế

hệ trước có tỷ suất lỗi bit BER (Bit Error Rate) cao gây ra bởi các chuẩn truyền thông:

10trung bình là 10-7 và 10-4 trong trường hợp xấu nhất Nguyên nhân là do các chuẩn trên được tối ưu hóa cho việc truyền tín hiệu âm thanh và hình ảnh analog Với các kỹ thuật điều biến và mã hóa mới cùng với vệ tinh có công suất phát cao hơn, tỷ suất lỗi thông thường sẽ đạt được rất thấp (đạt tới 10-10

) khi sử dụng vệ tinh địa tĩnh Đối với các hệ thống vệ tinh quỹ đạo thấp, tỷ suất lỗi có thể biến động nhưng với các công nghệ hiện đại các hệ thống này sẽ được phát triển để đạt tới chất lượng truyền cũng như độ ổn định không thua kém đường truyền cáp quang Các nguyên nhân gây lỗi là do nhiễu và suy giảm tín hiệu truyền Do tín hiệu vệ tinh là sóng điện từ truyền trong không gian nên thường bị hấp thụ và suy yếu khi đi qua sương mù, mây, và đặc biệt là mưa

Độ trễ: Do có sự hạn chế về tốc độ truyền và độ cao của các vệ tinh Các thiết vị

thông tin liên lạc được đặt tại vệ tinh địa tĩnh GSO với độ cao là 36.000km Ở độ cao đó, vận tốc góc của vệ tinh bằng vận tốc góc của trái đất quay quanh trục của nó Do đó mỗi trạm ở mặt đất luôn có thể nhìn thấy các vệ tinh ở cùng một vị trí trên bầu trời, nghĩa là các vệ tinh đứng yên so với mặt đất Thời gian truyền tín hiệu radio giữa 2 trạm mặt đất qua vệ tinh chuyển tiếp gấp 2 lần thời gian truyền từ trạm mặt đất tới vệ tinh, bằng239,6ms

Hình 1.1 Mô hình mạng vệ tinh

Đối với các trạm ở rìa của vùng của các vệ tinh (foot print) khoảng cách là 2*41,576km,

do đó thời gian truyền lớn hơn, bằng 2*279=558 ms (RTT) Ngoài sự trễ truyền, còn có

sự trễ khác, như trễ do phát gói tin lên đường truyền, trễ lan truyền trong mạng mặt đất

và độ trễ hàng đợi trong cổng kết nối vệ tinh Kênh truyền vệ tinh được chi phối bởi hai đặc điểm cơ bản như mô tả dưới đây:

Tiếng ồn: Cường độ của tín hiệu vô tuyến giảm theo khoảng cách truyền Đối với

một liên kết vệ tinh khoảng cách là lớn và do đó tín hiệu sẽ trở nên yếu thậm chí rất yếu khi đến đích của nó Kết quả là tỉ số tín hiệu trên bị nhiễu SNR (Signal to Noise Ratio) bị suy giảm Một số tần số đặc biệt nhạy cảm với các hiện tượng xảy ra trong khí quyển như

sự suy giảm cường độ tín hiệu do mưa, sương mù Đối với các ứng dụng di động, kênh

vệ tinh đặc biệt nhạy cảm với hiện tượng truyền đa đường, gây ra sai lệch méo tín hiệu

Tỷ lệ lỗi bit BER cho một liên kết vệ tinh ngày nay là khoảng một lỗi trên 10 triệu bit (1x10-7) hoặc ít hơn Các kỹ thuật kiểm soát lỗi và mã hóa nâng cao có thể được thêm vào các dịch vụ truyền thông vệ tinh hiện nay Tuy nhiên, nhiều hệ thống vệ tinh sẽ tiếp tục có BER cao hơn so với các hệ thống vệ tinh mới và các kênh truyền trên mặt đất

Băng thông: Tài nguyên phổ tần số radio có giới hạn, do đó chỉ có một số lượng

giới hạn băng thông sẵn có được cấp phép sử dụng cho các hệ thống truyền thông vệ tinh Điều này gây khan hiếm băng thông cho các ứng dụng thương mại khác Tần số sóng mang điển hình cho truyền vệ tinh, theo phương thức điểm-tới-điểm là 6GHz (uplink) và

4 GHz (downlink), còn được biết đến với tên gọi là băng tần C, và 14/12 GHz (được gọi

là băng tần Ku) Một dịch vụ đường truyền vệ tinh mới là 30/20 GHz (băng tần Ka) sẽ xuất hiện trong vài năm tới đây Các bộ lặp radio vệ tinh cơ bản được biết đến như là các

bộ tiếp sóng (transponder) Băng tần truyền thống C có băng thông thường là 36MHz, đáp ứng được cho việc truyền một trong những kênh truyền hình màu (hoặc 1.200 kênh thoại) băng tần Ku thường có dải tần nằm xung quanh rộng 50MHz Hơn nữa một vệ tinh có thể mang theo vài chục transponders Băng thông cho truyền vệ tinh không chỉ bị hạn chế do giới hạn có thể sử dụng được của nó, mà việc phân bổ cũng bị hạn chế bởi các thỏa thuận quốc tế để nguồn tài nguyên khan hiếm này có thể sử dụng bởi nhiều ứng dụng khác nhau Kênh vệ tinh có một vài điểm khác biệt với kênh mặt đất Nhưng các đặc điểm này

có thể làm suy giảm hiệu suất của giao thức TCP Những đặc điểm này bao gồm:

Trễ phản hồi dài: Do sự trễ truyền của một số kênh vệ tinh (ví dụ khoảng 250ms

trên một vệ tinh địa tĩnh) có thể khá lớn, người gửi TCP phải đợi một khoảng thời gian lớn mới xác định được một gói đã gửi đã được nhận thành công tại điểm đến cuối cùng hay chưa Việc chậm trễ này ảnh hưởng lớn đến các ứng dụng như telnet, cũng như một

số thuật toán điều khiển tắc nghẽn TCP

Độ trễ lớn và băng thông: Tích số của dải thông và độ trễ xác định số lượng dữ

liệu một giao thức có thể gửi đi liên tiếp để sử dụng toàn bộ dung lượng của các kênh sẵn

có Độ trễ sử dụng ở đây là khoảng thời gian khứ hồi RTT (Round Trip Time) và băng thông là dung lượng (capacity) của liên kết nút cổ chai trong đường dẫn mạng Bởi vì độ trễ trong môi trường vệ tinh là rất lớn, TCP sẽ cần phải duy trì được một số lượng lớn các gói tin trên đường truyền thì việc sử dụng kênh truyền vệ tinh mới có hiệu quả cao

Truyền lỗi: Các kênh truyền hình vệ tinh có một tỷ lệ lỗi bit (BER) cao hơn các

kênh truyền trong mạng mặt đất đang được sử dụng phổ biến Giao thức TCP sử dụng dấu hiệu về các gói bị hủy bỏ (mất) như là một tín hiệu về sự tắc nghẽn mạng và phản ứng bằng cách giảm kích cỡ cửa sổ phát để cố gắng giảm bớt tắc nghẽn Trong trường hợp không biết nguyên nhân vì sao một gói tin bị hủy bỏ (có thể là do tắc nghẽn) TCP đều cho rằng là nguyên nhân là do tắc nghẽn và gọi phương thức điều khiển tránh tắc nghẽn

để tránh sự sụp mạng

Bất đối xứng: Do chi phí là rất lớn nếu sử dụng thiết bị để gửi dữ liệu từ máy tính

của người sử dụng đến vệ tinh, cho nên mạng truyền thông vệ tinh không đối xứng thường được xây dựng Ví dụ, một máy tính kết nối với một mạng sử dụng vệ tinh sẽ gửi tất cả thông tin đi (request) thông qua một liên kết mặt đất (uplink) có tốc độ truyền thấp (như kênh mô hình quay số) và nhận được lưu lượng cần truy cập qua kênh vệ tinh

12(downlink) có tốc độ truyền cao Điều này chính là tính không đối xứng về độ trễ và dải thông, có thể tác động xấu vào hiệu suất TCP.

Thời gian khứ hồi biến đổi (Variable Round Trip Times): Trong một số mạng vệ

tinh, chẳng hạn như mạng sử dụng vệ tinh quỹ đạo thấp LEO, sự trễ truyền đến và đi từ các vệ tinh thay đổi liên tục theo thời gian

Kết nối liên tục: Trong mạng không sử dụng vệ tinh địa tĩnh, kết nối TCP phải

được chuyển giao từ một vệ tinh này tới vệ tinh khác hay từ một trạm mặt đất này tới một trạm mặt đất khác theo thời gian Việc này có thể gây ra mất gói tin nếu không được thực hiện đủ nhanh, khi đó kết nối sẽ bị gián đoạn Hầu hết các kênh vệ tinh chỉ có một số trong những đặc điểm trên

1.2.2 Các mô hình lỗi trên đường truyền vệ tinh

Trong mục này, tôi xin trình bày các vấn đề về mô hình lỗi (Error Model) trong bộ

mô phỏng mạng NS2 Mô hình lỗi mô phỏng các lỗi truyền hoặc mất ở từng mức liên kết hoặc bằng cách đánh dấu cờ lỗi của gói tin hoặc hủy gói tin tới đích Trong giả lập, các lỗi

có thể được tạo ra từ một mô hình lỗi đơn giản như tỉ lệ lỗi của gói tin, hoặc phức tạp hơn

từ những mô hình thống kê và những mô hình thực nghiệm Để hỗ trợ cho những mô hình

mở rộng, đơn vị lỗi có thể sử dụng tỉ lệ lỗi gói tin, tỉ lệ lỗi bit hoặc khoảng thời gian giữa hai lỗi liên tiếp

Lớp mô hình lỗi là xuất phát từ lớp cơ sở kết nối Kết quả là nó được thừa kế một vài phương thức cho việc tìm kiếm các đối tượng như đích và hủy đích Nếu hủy đích tồn tại, nó sẽ nhận một gói tin tạo ra từ mô hình lỗi Nói cách khác, mô hình lỗi đánh dấu vào

cờ lỗi error_flag trong phần tiêu đề (header) của gói tin, do đó, cho phép các tác nhân (agents) điều khiển việc loại bỏ gói lỗi Mô hình lỗi cũng định nghĩa thêm vào phương thức Tcl để chỉ ra đơn vị của lỗi và chỉ ra các biến ngẫu nhiên để tạo ra các lỗi Nếu không chỉ ra, đơn vị lỗi sẽ ở trong các gói tin và biến ngẫu nhiên sẽ được chỉ định là 0 hoặc 1 Dưới đây là một ví dụ đơn giản của việc tạo ra một mô hình lỗi với tỷ lệ lỗi gói tin

là 1%

# tạo ra một loss_module và thiết lập tỷ lệ lỗi gói tin đến 1%:

loss_module [new Error Model]

$loss_module set rate_ 0.01

# Tùy chọn: thiết lập các đơn vị tính lỗi và biến ngẫu nhiên

$loss_module unit pkt ;

# error unit: packets (the default)

$loss_module ranvar [new RandomVariable/Uniform]

# set target for dropped packets

$loss_module drop-target [new Agent/Null]

Để tạo mô hình lỗi cho mạng không dây, mỗi node (nút điểm) có thể được thêm vào một mô hình thống kê cho lỗi cho cả các kênh (đường truyền) ra và kênh vào (đến) Đặc biệt, mô hình lỗi sẽ nằm giữa tầng MAC và NET nếu các mô đun đã mô tả Đối với đường truyền (link) ra, mô đun lỗi sẽ chỉ ra bởi đích của mô đun MAC ở trên trong khi đối với link vào nó sẽ chỉ ra liên kết bởi đích trên của mô đun NET ở dưới Và trong mỗi trường hợp đích của các mô đun lỗi chỉ ra bởi tương ứng cả NET hay MAC Sự khác biệt đặt trong hai địa điểm khác nhau là đối với điểm ra tất cả các máy nhận đều nhận được các gói dữ liệu bị cùng một mức độ sai sót kể từ khi lỗi được xác định trước khi mô đun của các kênh không dây sao chép gói tin Mặt khác, các mô đun lỗi đến cho phép người nhận nhận được các gói tin bị hỏng với mức độ khác nhau của lỗi vì lỗi là tính độc lập trong mỗi module lỗi.

Việc chèn mô hình lỗi vào đường truyền không dây có thể được thực hiện bằng cách gọi lệnh node-config với hai lựa chọn là IncommingErrProc và OutgoingErrProc Chúng ta có thể sử dụng hai lựa chọn cùng một lúc hoặc mỗi một cách riêng biệt Ví dụ một đoạn code TCL đơn giản:

$ns node-config -IncomingErrProc UniformErr -OutgoingErrProc UniformErr

proc UniformErr

set err [new ErrorModel]

$err unit packet

return $err

1.2.2.1 Mô hình lỗi đồng đều (Uniform Error Model)

Đây là mô hình lỗi đơn giản nhất, trong đó lỗi được phân bố đều Đơn vị tính lỗi có thể là gói tin, cũng có thể là byte hay bit Mô hình này có nhược điểm là không phản ánh được tính bùng nổ của lỗi đường truyền không dây Chính vì vậy, nó thường chỉ được sử dụng trong các nghiên cứu nhằm đạt được các kết quả có tính chất định tính

1.2.2.2 Mô hình lỗi Markov hai trạng thái (Two-stale Markov Error Model)

Hình 1.2 Mô hình lỗi Markov hai trạng thái

Mô hình lỗi Markov hai trạng thái được thể hiện trên hình 1.2 theo mô hình này, đường truyền có hai trạng thái là tốt - Good và xấu - Bad Trọng trạng thái Good, tất cả các gói tin đi qua đường truyền đều không bị lỗi; còn trong trạng thái xấu, tất cả các gói tin đi qua đường truyền đều bị lỗi Nếu độ dài trung bình của trạng thái Good là LG (bằng số gói tin liên tiếp truyền thành công), ở trạng thái Bad là LB (bằng số gói tin liên tiếp truyền bị lỗi) thì các xác suất chuyển trạng thái được tính như sau:

- Xác xuất chuyển từ trạng thái Good sang trạng thái Bad: PGB = 1/LG

- Xác xuất chuyển từ trạng thái Bad sang trạng thái tốt Good: PBG = 1/LB

Các xác suất chuyển là không nhỏ, nhờ tính chất quan trọng này mà trong mô hình, việc chuyển trạng thái có thể thực hiện đối với từng gói tin Mô hình lỗi Markov hai trạng thái

mô tả được tính bùng nổ của lỗi đường truyền không dây, chính xác hơn mô hình lỗi đồng đều; tuy nhiên, mô hình này cũng chưa mô tả được chính xác tất cả các trạng thái lỗi đường truyền Do tính đơn giản nên mô hình lỗi Markov hai trạng thái thường được sử dụng trong nghiên cứu, kể cả nghiên cứu bằng mô phỏng

1.2.2.3 Mô hình lỗi Markov hai trạng thái cải tiến

Mô hình lỗi Markov hai trạng thái cải tiến được minh họa trên hình 1.3 Mô hình này có hai trạng thái là tốt- Good và xấu- Bad Trong trạng thái Good, các gói tin đi qua đường truyền vẫn có thể bị lỗi với một giá trị trung bình và theo một phân bố nhất định, được chỉ rõ Tương tự như vậy, trong trạng thái Bad, không phải 100% gói tin đi qua đường truyền đều bị lỗi

Hình 1.3 Mô hình lỗi Markov hai trạng thái cải tiến

Các tham số của mô hình lỗi Markov hai trạng thái cải tiến có ý nghĩa như sau:

là tốc độ đến trung bình của gói số liệu bị lỗi khi đường truyền ở hai trạng thái tương ứng là Good và Bad, chúng có một phân bố nào đó, thí dụ phân bố đều hoặc phân

bố hàm mũ

TG và TB là độ dài trung bình của các trạng thái tương ứng Good và Bad TG và TB tương

tự LG và LB trong mô hình lỗi Markov hai trạng thái, có đơn vị đo là gói tin (nên >=1)

PGB = 1/TG là xác suất chuyển từ trạng thái Good sang trạng thái Bad

PGG = 1- PGB là xác suất ở lại trạng thái Good

PBG = 1/TB là xác suất chuyển từ trạng thái Bad sang trạng thái Good

PBB = 1- PBG là xác suất ở lại trạng thái Bad

1.2.2.4 Mô hình lỗi Markov đa trạng thái (Multi-state error model)

Mô hình lỗi đa trạng thái thực hiện dựa trên chuyển đổi trạng thái lỗi dựa trên cơ

sở thời gian (time-based) Quá trình chuyển đổi trạng thái lỗi tiếp theo xảy ra vào cuối của thời kỳ trạng thái lỗi hiện tại Trạng thái lỗi tiếp theo sau đó được chọn bằng cách sử dụng

ma trận chuyển trạng thái

Để tạo ra một mô hình lỗi nhiều trạng thái, các thông số sau đây cần được cung cấp (như quy định tại ns / tcl / lib / ns-errmodel.tcl):

States: một dãy các trạng thái (các mô hình lỗi)

Periods: một dãy các thời kỳ trạng thái

Trans: ma trận chuyển trạng thái

Transunit: đơn vị tính tỉ lệ lỗi, có thể là một trong các đơn vị: pkt/byte/time

Sttype: loại chuyển trạng thái, sử dụng thời gian hay pkt

Nstates: số các trạng thái

Start: bắt đầu trạng thái

Dưới đây là một kịch bản ví dụ đơn giản để tạo ra một mô hình lỗi nhiều trạng thái:

set tmp [new ErrorModel/Uniform 0 pkt]

set tmp1 [new ErrorModel/Uniform 9 pkt]

set tmp2 [new ErrorModel/Uniform 5 pkt]

# Array of states (error models)

set m_states [list $tmp $tmp1 $tmp2]

# Durations for each of the states, tmp, tmp1 and tmp2, respectively

set m_periods [list 0 0075 00375]

# Transition state model matrix

set m_transmx { {0.95 0.05 0}

{0 0 1}

{1 0 0}

set m_trunit pkt

# Use time-based transition

set m_sttype time

set m_nstates 3

set m_nstart [lindex $m_states 0]

set em [new ErrorModel/MultiState $m_states $m_periods $m_transmx

$m_trunit $m_sttype $m_nstates $m_nstart]

? phải quản lý đúng số tuần tự tính theo byte của dòng số

liệu

? phải tối ưu hóa hiệu suất truyền bằng cách giám sát và điều khiển lưu lượng gửi tin từ thực thể gửi tới thực thể nhận, đảm bảo tự thích ứng với trạng thái của đường truyền được chia sẻ với các kết nối khác

? phải đảm bảo trao đổi số liệu tin cậy và chính xác giữa thực thể cuối của mạng chính

nhờ các yếu tố sau đây:

o Đối thoại khi thu phát: Mỗi khi gửi một gói số liệu, bên nhận phải thông báo nhận

đúng sau một khoảng thời gian nhất định Nếu không, gói số liệu được coi là nhận sai

và được phát lại

o Kiểm tra số liệu thu phát: Số liệu gửi được kiểm tra bằng thuật toán quy định Các

byte kiểm tra (Checksum) được gửi cùng với số liệu phát và được so sánh với các byte kiểm tra tính lại khi thu Trong trường hợp sai lệch, có nghĩa là có lỗi xảy ra trên đường truyền, thực thể thu thông báo kết quả thu cho thực thể phát và yêu cầu gửi lại

o Kiểm tra số tuần tự: Vì các gói TCP được truyền thành các gói IP và các gói IP có

thể đến đích không theo thứ tự phát (IP là giao thức không hướng kết nối) nên thực thể TCP nhận phải lập lại trật tự các gói số liệu thu được, hủy bỏ các gói số liệu trùng lặp khi cần và chuyển các gói số liệu đó theo đúng trật tự phát cho các ứng dụng

o Điều khiển lưu lượng: Mỗi thực thể của kết nối TCP đều có một vùng đệm hạn chế

Thực thể TCP nhận chỉ cho phép thực thể phát gửi một lượng số liệu đủ với vùng đệm thu của mình Điều này sẽ ngăn cản thực thể TCP phát truyền quá nhanh, làm tràn vùng đệm của thực thể TCP thu nhận Các thực thể ứng dụng sử dụng dịch vụ truyền dẫn tin cậy của TCP mô tả ở trên để trao đổi số liệu Chú ý rằng, thực thể ứng dụng và thực thể TCP có bộ đệm riêng của mình để lưu giữ tạm thời số liệu trong quá trình xử

lý Cách thức chuyển tiếp số liệu giữa hai bộ đệm trên là yếu tố quyết định hiệu suất chuyển tiếp số liệu của hệ thống TCP Số liệu có thể truyền toàn bộ hoặc một phần từ

bộ đệm ứng dụng tới bộ đệm TCP, trước khi quá trình phát được khởi động; số liệu thu

từ kết nối TCP có thể chuyển tiếp tức thời từ bộ đệm thu TCP tới bộ đệm ứng dụng hoặc chỉ khi tỷ lệ phần bộ đệm bị chiếm dụng so với tổng dung lượng bộ đệm đạt tới một giá trị nào đó Các giao thức vận chuyển quy định về cách thức trao đổi số liệu giữa các thực thể cùng mức chức năng, chứ không quy định việc thực hiện cụ thể như thế nào

2.1.2 Cấu trúc gói tin TCP

Hình 2.1 Gói số liệu TCP với phần tiêu đề giả

Cấu trúc gói số liệu TCP gồm phần tiêu đề TCP “giả” (Pseudo header TCP) mô

tả trong hình 2.1 và gói số liệu TCP “thực” (TCP Segment) được mô tả trong hình 2.2 Phần tiêu đề giả cần thiết cho việc xây dựng gói số liệu IP, bao gồm các thông tin về địa chỉ IP nguồn, địa chỉ IP đích, số liệu thuộc giao thức TCP (trường protocol có giá trị 0x06) và độ dài của gói TCP thực:

Ý nghĩa của các trường của gói số liệu TCP thực:

? Soure Port: Số hiệu cổng TCP bên

phát

? Destination Port: Số hiệu cổng TCP bên đích; các số hiệu cổng cùng với địa chỉ

IP nguồn và địa chỉ IP đích trong gói số liệu IP định danh duy nhất hai tiến trình ở hai đầu kết nối TCP

? Sequence number: Số tuần tự phát, định danh byte đầu tiên của phần số liệu

thuộc

gói số liệu TCP trong luồng số liệu từ thực thể TCP gửi đến thực thể TCP nhận Số tuần tự phát là khoảng cách tương đối của byte đầu tiên phần số liệu với byte đầu tiên của dòng byte; đó là số không dấu 32 bit, có giá trị nằm trong khoảng từ 0 đến 232

-1

o Nếu ta coi dòng byte là luồng số liệu một chiều từ một ứng dụng này tới ứng dụng

kia thì TCP đánh số tất cả các byte với các giá trị gọi là số tuần tự (sequence number).

o Khi một kết nối được thiết lập trường số tuần tự chứa giá trị khởi tạo ISN (Initial Sequence Number) được thực thể TCP chọn cho kết nối này Byte số liệu đầu tiên sẽ

? FLAGs: Có 6 bit cờ trong phần tiêu đề TCP Một hay nhiều cờ có thể được thiết

lập tại cùng một thời điểm

o URG = 1: Thông báo giá trị trường Urgent Pointer đúng

o ACK = 1: Thông báo giá trị trường Acknowledgment đúng

o PSH = 1: Thực thể nhận phải chuyển số liệu này cho ứng dụng tức thời

o RST = 1: Tái khởi tạo kết nối

o SYN = 1: Đồng bộ trường số thứ tự, dùng để thiết lập kết nối TCP

o FIN = 1: Thông báo thực thể gửi đã kết thúc gửi số liệu

? Windows size: Độ lớn cửa sổ bên thu, quy định tổng số byte số liệu mà thực thể

thu có thể nhận được (đồng nghĩa với độ lớn bộ đệm thu) tính khởi đầu từ giá trị trường số tuần tự thu (Acknowlegment Number)

? Checksum: tổng kiểm tra, là giá trị bù 1 của tổng các nhóm 16-bit trong phần đầu

và

phần số liệu TCP Giá trị này tính cả 12 byte tiêu đề giả của TCP

? Urgent Pointer: Vị trí tương đối của byte trong trường số liệu TCP cần được xử

lý đầu tiên Giá trị trường này đúng khi bit cờ URG = 1

? Options: Tuỳ chọn thường được dùng hiện nay là quy định về độ dài lớn nhất

Hình 2.2 Cấu trúc gói số liệu TCP

2.1.3 Cơ chế hoạt động của TCP

Thiết lập kết nối

Kết nối TCP được thiết lập trên cơ sở phương thức bắt tay ba bước Tiến trình bắt đầu khi trạm làm việc (Agent A) yêu cầu thiết lập một kết nối TCP bằng cách gửi một gói TCP với cờ SYN = 1, gọi tắt là gói điều khiển SYN, và giá trị khởi tạo số tuần

tự ISN của mình Giá trị ISN là số 32 bit và được tăng mỗi khi có một kết nối mới được yêu cầu tạo ra (giá trị này quay về 0 khi nó đạt tới giá trị 232) Trong gói điều khiển SYN này còn chứa số hiệu cổng TCP của phần mềm dịch vụ mà tiến trình trạm làm việc muốn kết nối (bước 1) Mỗi thực thể kết nối TCP đều có một giá trị ISN mới,

số này được tăng theo thời gian Vì một kết nối TCP mới có thể dùng lại số hiệu cổng

và địa chỉ IP đã được sử dụng trước đó, do đó việc thay đổi giá trị ISN giúp các kết nối

có cùng một địa chỉ kết nối tránh được việc dùng lại các số liệu đã ôi (stale) vẫn còn đang được truyền trong mạng Internet nhưng thuộc một kết nối cũ

Hình 2.3 Phương thức bắt tay ba bước - thiết lập kết nối Sau khi nhận được gói điều

21khiển SYN và ở trạng thái sẵn sàng chấp nhận kết nối, thực thể TCP nhận của phần

mềm dịch vụ (Agent B) gửi lại gói SYN với giá trị ISN của mình, và đặt bit cờ ACK=1 để thông báo rằng thực thể nhận đã nhận được giá trị ISN của thực thể gửi (bước 2) Cuối cùng, Agent A trả lời Agent B khi nhận được tín hiệu SYN của Agent

B bằng một ACK cuối cùng, khẳng định đã nhận được giá trị ISN của Agent B Bằng cách này, các thực thể TCP trao đổi một cách tin cậy các giá trị ISN của nhau và sẵn sàng trao đổi số liệu Chú ý rằng không có gói điều khiển SYN nào trong 3 bước trên chứa số liệu của thực thể ứng dụng, tất cả các số liệu điều khiển được trao đổi đều nằm trong phần tiêu đề của gói điều khiển TCP (bước 3)

Chấm dứt phiên làm việc

Để chấm dứt phiên làm việc, thực thể TCP (Agent A trên hình 2.3) gửi yêu cầu chấm dứt kết nối với cờ FIN cho đối tác truyền thông của nó Vì kết nối TCP là song công nên mặc dù nhận được yêu cầu chấm dứt phiên làm việc (mà thực chất là thông báo hết số liệu để gửi), thực thể đối tác (Agent B trên hình 2.3) vẫn có thể tiếp tục truyền

số liệu cho đến khi không còn số liệu để gửi và thông báo cho thực thể TCP rằng yêu cầu kết thúc kết nối với cờ FIN của mình Tóm lại, kết nối TCP chỉ thực sự kết thúc khi thực thể nhận yêu cầu chấm dứt kết nối gửi trả lại cho thực thể yêu cầu một gói tin cũng với cờ FIN

Hình 2.3 Phương thức bắt tay ba bước- thiết lập kết nối, chấm dứt phiên làm việc

Cơ chế điều khiển tránh tắc nghẽn TCP gắn liền với việc điều khiển luồng TCP xác lập một cửa sổ cho việc điều khiển Bằng cách so sánh giá trị cần quan tâm hiện tại với phạm vị cửa sổ (trong phạm vi, vượt trên hay thấp hơn) để đưa ra các quyết định điều khiển khác nhau Giá trị thực hiện tại được gọi là cwnd (current window size)

Hình 2.4 Cơ chế quản lý gửi dữ liệu theo cửa sổ của TCP

Quá trình điều khiển luồng nguyên thủy của TCP chỉ đơn giản chấp nhận mức tối đa cửa sổ thu và cho phép đầu phát gửi một gói mới khi nhận được ACK từ đầu thu Điều này đã gây nên hiện tượng tắc nghẽn Vào cuối thập niên 80, nó trở thành một vấn đề thật sự Từ 1988, Tahoe TCP ra đời đánh dấu một bước khởi đầu cho các giải thuật điều khiển tắc nghẽn của TCP Giải thuật tránh tắc nghẽn nguyên thủy của TCP thực chất bao gồm các thuật toán sau: slow-start (khởi đầu chậm), congestion avoidance

23(tránh tắc nghẽn) và Fast-Retransmit (truyền lại nhanh) Năm 1990, Reno TCP ra đời

và bổ sung một quá trình xử lý mới được gọi là Fast-Recovery (khôi phục nhanh)

Kể từ khi Tahoe ra đời, bên cạnh giá trị cửa sổ đầu thu (hay còn gọi là cửa sổ quảng bá đầu thu – awnd), một giá trị cửa sổ khác được định nghĩa cho mục đích điều khiển tắc nghẽn phía thu, đó là congestion window (cửa sổ điều khiển tắc nghẽn), cwnd, và giá trị ngưỡng cho quá trình slow-start : sstrhresh (slow-start threshold) Khi đó, cửa sổ phát , được định nghĩa: w = min (cwnd, awnd)

Mục đích của cwnd là ngăn đầu phát phát quá mức dữ liệu so với khả năng đáp ứng của đầu thu Việc điều khiển tắc nghẽn được thực hiện bằng cách thay đổi cwnd Trong thực tế, việc thay đổi này được thực hiện khi có gói bị mất Việc phát hiện mất gói có thể thông qua time-out hay nhận được duplicate ACKs (nhập các gói ACK giống nhau) – dupACKs tại đầu phát

Time-outs: liên kết với mỗi gói là một đồng hồ - timer Nếu hết thời hiệu (time-out)

mà không nhận được ACKs từ đầu thu, đầu phát sẽ tiến hành gửi lại gói này Giá trị của bộ định thời còn được gọi là RTO (Retransmit time-out), được tính dựa trên giá trị thời gian khứ hồi trung bình RTT (round time-trip) Tuy nhiên giá trị của RTT không thể biết được trong thực tế, nó được đo thông qua giải thuật Jacobson/Karels

Duplicate ACKs: khi một gói bị mất, đồng nghĩa với việc đầu thu không nhận được gói đó Nó phá vỡ sự tuần tự các gói nhận được ở đầu thu Lúc này, đầu thu liên tục gửi ACK với cùng một giá trị để biên nhận cho các gói tin không lỗi đến sau gói tin bị mất Đây là căn cứ cho đầu phát biết đã có mất gói

2.2 TCP và cơ chế điều khiển tắc nghẽn

2.2.1 Quá trình slow-start và congestion avoidance

Trong quá trình slow-start, khi mà kết nối vừa được thiết lập, cwnd được thiết lập giá trị là 1 Sau mỗi gói “ACK mới” nhận được:

Việc tăng tuyến tính này được tiếp tục cho tới khi có gói bị mất hoặc đạt ngưỡng ssthresh Trong trường hợp có gói bị mất, ssthresh = cwnd/2 và cwnd được trả về bằng

1 Trong trường hợp cwnd đạt ngưỡng ssthresh, thực thể gửi TCP chuyển sang quá trình congestion avoidance Khi này, thay vì tăng theo hàm mũ cơ số 2, cwnd tăng tuyến tính: cwnd = cwnd + 1/cwnd Việc tăng này sẽ tiếp tục cho đến khi có gói bịmất

Quá trình slow-start nhằm mục đích “thăm dò” khả năng của đường truyền hiện tại Mặc dầu được thiết lập ở mức thấp (cwnd =1), song lại tăng rất nhanh tương tự như quá trình hiệu chỉnh thô khả năng phát gói Khi xảy ra tắc nghẽn, quá trình congestion avoidance lại giống như quá trình hiệu chỉnh tinh, đồng thời, cũng là để hạn chế tắc nghẽn Mục đích cuối cùng của cả hai quá trình là đảm bảo việc phát gói ở mức cao nhất có thể được

Hình 2.5 Quá trình slowstart và congestion avoidnce

2.2.2 Quá trình Fast-Retransmit

Mục đích của Fast-Retransmit là tăng tốc quá trình truyền lại bằng cách cho phép đầu gửi truyền lại gói bị mất càng sớm càng tốt ngay khi có đủ căn cứ về việc mất gói Có nghĩa là thay vì phải chờ đến khi time-out, đầu phát có thể truyền lại ngay khi cần thiết, đó là khi nhận được liên tiếp 3 biên nhận lặp (dupAcks)

2.2.3 Quá trình Fast-Recovery

Với Tahoe TCP, kết nối luôn trở về quá trình slow-start ngay khi phát hiện mất gói Tuy nhiên, nếu như window size lớn và tỉ lệ mất gói là ít khi xảy ra, thì việc đó là không cần thiết vì hoàn toàn có thể chuyển sang trạng thái congestion avoidance Mục đích của Fast-Recovery nhằm thực hiện ý tưởng trên Trong quá trình Fast-Retransmit, bên gửi ghi nhận lại gói truyền lại Sau khi gói đã truyền lại, giá trị của ssthresh và cwnd sẽ được hiệu chỉnh theo nguyên tắc:

Điều này đồng nghĩa với kết nối sẽ tiếp tục với quá trình congestion avoidance, với giá trị cửa sổ phát cwnd giảm xuống còn bằng một nửa chứ không phải xuống bằng 1

Hình 2.7 Lưu đổ giải thuật slowstart

Hình 2.8 Lưu đồ chi tiết TCP-Tahoe

Tương ứng w (cửa sổ phát) cũng sẽ tăng lên 1 lượng n dupACKs đúng bằng số gói đã gửi thành công cho tính từ lúc có hiện tượng mất gói Do đó, luồng phát được duy trì Khi có một ACK mới, cwnd được trả về mức ssthresh và bắt đầu quá trình congestion avoidance

Trong giai đoạn Fast-Recovery, nếu nhận được một ACK mới, có hai trường hợp xảy

ra Thứ nhất, nếu ACK cho biết tất cả các dữ liệu được xác nhận, thì New-Reno hoạt động giống như Reno Trong trường hợp ngược lại (gọi là Partial ACK), suy ra rằng,

có nhiều hơn một gói bị mất Trong trường hợp này, có nhiều cách xử lý khác nhau, nhưng nhìn chung, New-Reno tiến hành gửi lại gói mất cho đến khi tất cả các outstanding segment được xác nhận Chi tiết về thuật toán này được mô tả trong RFC

3782 Hạn chế của New-Reno là mặc dù hỗ trợ gửi lại nhiều gói, nhưng phải mất một khoảng thời gian RTT để New-Reno phát hiện ra mỗi gói mất

2.3.4 TCP SACK

SACK được công bố bởi M.Mathis, J.Mahdavi, S.Floy và A.Romanow và được mô tả trong RFC2018 vào tháng 10 năm 1996 SACK là thuật ngữ viết tắt của Selective Acknowedgment Options – nghĩa là ACK có lựa chọn

Khác với cơ chế gửi ACK như Tahoe, Reno, hay NewReno (còn gọi là cơ chế cumulative acknowledgment – ACK tích lũy), SACK không gửi ACK cho từng segment đến mà gửi ACK cho một nhóm các segment Trong đó, có các thông tin về các khối segment liên tiếp Từ đó, có thể suy ra được các segment mất Hình 2.10 dưới đây minh họa phương thức hoạt động của SACK

Hình 2.10 Phương thức hoạt động SACK

Trong ví dụ trên, đầu nhận báo SACK với CACK (cumulative acknowledgment) 2, và

3 khối segment liên tục [1:1], [3:3], [5:6] Điều này cho biết, các gói 2, 4 đã bị mất

Ưu điểm của SACK so với CACK là SACK cho phép nguồn phát phát hiện ra đồng thời nhiều segment bị mất mà CACK không làm được

SACK là một option (tùy chọn) mở rộng của TCP Thông tin option của SACK chỉ được hiện hữu trên các gói ACK Có 2 loại option dành cho SACK, Option với type 4 dùng để báo hiệu cho phép SACK và option type 5 dùng để chứa thông tin SACK (cáckhối segment liên tiếp) Cấu trúc các option:

Hình 2.11 Option thông báo cơ chế điều khiển SACK

Hình 2.12 Option thông tin SACK

29Với option 5 (option có type = 5), các block (khối) segment liên tục được lưu thành từng cặp (left, right) liên tục Vậy có n blocks được mô tả trong thông tin của option 5 Kích thước của option 5 là 8*n+2 Do đó, với 40 bytes mà TCP dành cho option có thì

có tối đa 4 blocks Nếu Option Timestamp cũng được dùng thì n tối đa chỉ còn là 3 Giai đoạn thiết lập kết nối cũng là giai đoạn để đầu phát và đầu thu thỏa thuận về việc

có sử dụng SACK hay không

Hình 2.13 Quá trình khai báo sử dụng SACK

TCP SACK là một cải tiến của Reno và dựa trên cơ chế SACK TCP SACK giải quyết vấn đề truyền lại nhiều gói đồng thời mà Reno hay New-Reno không giải quyết được Trong một RTT, TCP Sack truyền lại nhiều hơn một gói

TCP SACK kế thừa slow-start và Fast-Retransmit của Reno và cơ chế hết giờ (time- out) của Tahoe trong trường hợp gói bị mất không phát hiện được bởi SACK Các block trong option của SACK cung cấp thông tin cho đầu gửi biết được các gói mất, các gói outstanding để có thể gửi lại Khi bắt đầu thời kỳ Fast-Recovery, đầu thu ghi nhận lại số lượng dữ liệu outstanding (biến pipe) Đồng thời giảm đi cwnd còn một nửa Mỗi khi nhận được ACK, pipe giảm đi 1 và khi truyền lại một segment, biến pipe được tăng lên 1 Bất cứ khi nào pipe trở nên nhỏ hơn cwnd, đầu phát kiểm tra những segment nào chưa được gửi và gửi chúng đi Khi không còn các outstanding segment,

dữ liệu mới sẽ được gửi đi Như vậy, trong khoảng thời gian 1 RTT, có nhiều hơn một segment được truyền lại Trong quá trình truyền lại, nếu tiếp tục có sự mất, segment mất sẽ được phát hiện bởi đồng hồ phát lại (retransmition time-out) Khi xảy ra retransmtion time-out, SACK thực thi slow-start

2.4 Những vấn đề của TCP trong môi trường mạng không dây

Chất lượng của TCP trong môi trường không dây thấp hơn mạng có dây Nguyên nhân chính của việc này là do TCP không nhận ra được chính xác nguyên nhân gây mất gói mà tất cả quy về là do tắc nghẽn trong mạng Trong khi đó, việc mất gói trong môi trường không dây không chỉ là do tắc nghẽn mà còn có thể là lỗi đường truyền

Gói dữ liệu TCP cũng có thể mất nếu chất lượng môi trường truyền thấp, tầng liên kết (link layer) không có một giao thức điều khiển có độ tin cậy cao Sau một số lần cố gắng truyền lại, tầng liên kết chuyển giao việc xử lý lỗi cho TCP Tình trạng chuyển giao (handover) kết nối cũng có thể gây ra tình trạng mất dữ liệu, và có thể mất dữ liệu trong

cả cửa sổ phát Việc mất dữ liệu do giao thức tầng liên kết không tin cậy hay handover có thể gây ra tình trạng timeout dẫn đến TCP phải quay về pha slow-start; hoặc đầu phát nhận được ba gói ACK trùng lặp kết quả là dẫn đến việc thực hiện Fast-Recovery và Fast- Retransmit Trong một số trường hợp, TCP thực thi cơ chế tránh tắc nghẽn không cần thiết Sau khi xảy ra tình trạng mất gói, chất lượng môi trường truyền có thể phục hồi trạng thái tốt rất nhanh chóng, hoặc sau khi handover việc truyền thông giữ thiết bị và BS không gặp phải vấn đề gì

Nếu độ trễ đường truyền đủ dài, gây ra tình trạng timeout ở đầu phát Kết quả là kích hoạt việc truyền lại không cần thiết Độ trễ đường truyền gây ra do nhiều nguyên nhân: băng thông thấp, tầng liên kết hoạt động không tốt, môi trường truyền không tốt hoặc do các bộ đệm chờ xử lý ở các thiết bị trung gian Đồng thời, độ trễ lớn cũng làm cho RTO tăng cao Kết quả là TCP phản ứng chậm chạp khi mất dữ liệu thật sự

o Cải tiến TCP có khả năng phân biệt nguyên nhân mất gói

o Có phương thức hoạt động hợp lý trong trường hợp mất gói không phải do tắc nghẽn

o Phát hiện mất kết nối tạm thời hoặc di động để có phương thức xử lý tối ưu

Độ trễ cao làm TCP hoạt động không hiệu quả, giải pháp đưa ra là cố gắng tối ưu hóa độ trễ, tránh việc tăng RTT không cần thiết Giải pháp cho vấn đề này thông thường là các giải pháp hỗ trợ tầng liên kết hoặc tính băng thông hợp lý thay cho việc giảm cửa sổ phát một cách không có căn cứ

Đảm bảo độ công bằng trong cải tiến giải thuật (fairness)

Chương 3 Một số phương pháp nâng cao hiệu năng TCP trong

mạng không dây

Có nhiều cách tiếp cận để nâng cao hiệu năng của TCP, và được chia làm bốn nhóm chính: giải pháp ở tầng liên kết dữ liệu (link layer), giải pháp chia kết nối, giải pháp thông báo tường minh (explicit notification), và giải pháp đầu cuối (end-to-end)

Hình 3.1 Lược đồ phân loại các giải pháp tối ưu hóa TCP trong môi trường không dây

3.1 Link layer

Ý tưởng chính là nâng cao khả năng TCP bằng cách hỗ trợ ở lớp data link bên dưới Thay

vì sử dụng phương thức hoạt động truyền lại end-to-end tại tầng giao vận của TCP, phương pháp này áp dụng việc truyền lại cục bộ ở tầng link Khi hoạt động trong môi trường lỗi nhiều như môi trường không dây, việc truyền lại từng chặng tại tầng data link giúp tránh được việc phải truyền lại dữ liệu trên một quãng đường dài

3.1.1 Snoop

Snoop sử dụng cơ chế truyền lại của tầng link để nâng cao độ tin cậy cho mạng không dây tránh cho TCP phải truyền lại không cần thiết Snoop thực thi như là một agent (tác tử) trong một BS Snoop đệm lại các frame ở tầng liên kết và xem xét nội dung của TCP header mà không cần TCP phải được thực thi trong BS Việc truyền lại thông qua kết nối không dây được kích hoạt ở BS nếu xảy ra timeout ở tầng liên kết hoặc nhận được các dupACKs từ MH Khi dupACKs đầu tiên đến, BS tiến hành truyền lại Khi những dupACKs khác đến, BS hủy các dupACKs này để ngăn đầu phát không thực thi Fast- Recovery và Fast-Retransmit trong khi tầng link đang thực thi truyền lại

Hình 3.2 Mô hình mạng không dây với BS đóng vai trò Snoop

Snoop quản lý luồng dữ liệu từ FH đến MH thông qua việc đệm lại những gói TCP chưa được xác nhận (ACK) và thực thi truyền lại cục bộ dựa trên hai tiến trình: Snoop_ACK()

và Snoop_Data() Đối với luồng dữ liệu từ MH đến FH, snoop phát hiện gói mất và áp dụng cơ chế NACK