Tiểu luận môn: Mạng và kỹ thuật truyền dữ
liệu
Đề tài:

THỰC HIỆN PHÂN TÍCH TCP SỬ DỤNG GIAO THỨC ĐỊNH
TUYẾN AODV TRÊN MẠNG MANET

1


TÓM TẮT
TCP là giao thức điều khiển truyền dựa trên truyền tải đáng tin cậy đầu đến
cuối. Đặc biệt thành phần mạng trở thành mạng không dây và mạng di động từ
mạng có dây đã đề xuất nhiều thuật toán TCP được tối ưu hoá trong môi trường
đa dạng. Tuy nhiên, khi TCP được tạo ra, nó được thiết kế dựa trên liên kết có
dây, liên kết không dây gây ra lỗi đường truyền nhiều hơn liên kết có dây [1].
Vấn đề của mạng tuỳ biến không dây là sự thay đổi đường đi, mờ dần, nhiễu,
ngắt kết nối và thiết bị đầu cuối ẩn đi. Lỗi đường truyền trong mạng tuỳ biến
không dây chưa chắc là do dấu hiệu tắc nghẽn không dây. Các thuật toán điều
khiển tắc nghẽn của TCP đôi khi tỏ ra kém hiệu quả trong mạng không dây. Vì
vậy người ta đưa vào mạng không dây một số giao thức định tuyến để khắc phục
các vấn đề nói trên. Trong bài viết này, chúng tôi tìm hiểu và phân tích hoạt động
của giao thức định tuyến AODV trên TCP.
I. GIỚI THIỆU
Gần đây, việc sử dụng mạng không dây là phổ biến. Giao tiếp sử dụng bộ
cảm biến nhỏ được gọi là công nghệ chính cho sự phát triển phổ biến các mạng
cảm biến có môi trường mạng tuỳ biến mà các nút di động kết nối mạng và tự
cấu hình với nhau. Do đó, có nhiều nghiên cứu về môi trường của mạng cảm
biến và mạng tuỳ biến được thực hiện. Tuy nhiên, mạng tuỳ biến không dây đã
mất định tuyến, mờ dần, ồn ào, nhiễu, cắt kết nối và vấn đề thiết bị đầu cuối bị
ẩn. Nó cấu hình mô hình động từ các nút di chuyển, sự mất mát gói tin do lỗi

đường truyền thì thường xuyên hơn. Nguyên nhân của lỗi đường truyền trong
mạng tuỳ biến không dây thường không phải do dấu hiệu của tắc nghẽn mạng [2]
[3].
Tình huống này gây ra sự xuống cấp về hiêu suất TCP[4]. Trong bài viết
này, chúng tôi tìm hiểu thuật toán điều khiển tắc nghẽn của TCP và vấn đề về cơ
chế trong mạng tuỳ biến không dây và sau đó, chúng tôi nghiên cứu hoạt động
của giao thức định tuyến AODV trên nền TCP trong mạng tùy biến không dây.
II. THUẬT TOÁN TẮC NGHẼN TCP
TCP sử dụng thuật toán điều khiển luồng và kiểm soát tắc nghẽn, xử lý lưu
lượng truy cập dữ liệu trong mạng. Thuật toán điều khiển tắc nghẽn TCP gồm có
bắt đầu chậm, tránh tắc nghẽn, truyền lại nhanh và phục hồi nhanh.

2


II.1. TCP Tahoe

Hình 1: Điều khiển tắc nghẽn của TCP-Tahoe

Khi hết thời gian chờ hoặc xảy ra sự mất mát gói tin, biến ngưỡng(ssthresh)
được thiết lập để được một nữa kích thước cửa sổ hiện tại. Sau đó, cwnd thiết lập
lại bằng 1. Khi nơi gửi nhận được tín hiệu ACK, Cwnd tăng lên từ 1 cho đến khi
đạt đến ngưỡng. Giai đoạn này được gọi là giai đoạn phục hồi tắc nghẽn. Kích
thước cửa sổ tăng lên theo cấp số nhân trong suốt giai đoạn phục hồi tắc nghẽn
và sau đó kích thước cửa sổ được tăng lên theo tuyến tính trong suốt giai đoạn
tránh tắc nghẽn.
II.2. TCP Reno
TCP Reno thực hiện tốt hơn so với TCP Tahoe. TCP Reno có 2 giai đoạn là
giai đoạn tránh tắc nghẽn và giai đoạn bắt đầu chậm nếu hết thời gian chờ ACK
và bắt đầu chậm được sử dụng như TCP Tahoe. Mặt khác, khi bên gửi nhận

được 3 bản sao ACK, kích thước cửa sổ tắc nghẽn được thiết lập bằng một nữa
của Cwnd và bắt đầu giai đoạn tránh tắc nghẽn. Sự phục hồi của TCP Reno trong
cửa sổ tắc nghẽn được tối ưu hoá. TCP Reno đã làm mất nhiều gói tin trong cửa
sổ tắc nghẽn gây nên hiệu suất kém. Bởi vì gói tin TCP Reno có thể chỉ truyền
lại một gói tin cho mỗi một RTT(round trip time).
II.3. TCP new Reno
TCP new Reno là một phiên bản cải tiến của Reno nhằm tránh sự suy giảm
của Cwnd khi một vài phân đoạn từ cùng một cửa sổ của dữ liệu bị mất[5].
Giống như TCP Reno, TCP new Reno cũng tham gia vào việc truyền lại nhanh
3


khi nhận được các gói tin trùng lặp. Tuy nhiên nó khác với TCP Reno ở chổ nó
không thoát khỏi việc phục hồi nhanh cho tới khi tất cả các tài liệu được ghi
nhận và phục hồi nhanh. Vì vậy nó khắc phục những vấn đề phải đối mặt với
TCP Reno là giảm Cwnd mạnh.
Giai đoạn truyền tải nhanh thì giống như TCP Reno. Sự khác biệt trong giai
đoạn phục hồi nhanh cho phép truyền lại trong TCP Reno, bất cứ khi nào TCP
Reno đi vào việc phục hồi nhanh thì lưu ý đoạn lớn nhất là chưa thực hiện xong.
TCP new Reno thực tế cho phép là 1 RTT để phát hiện ra những gói tin bị mất.
Khi tín hiệu trả về cho đoạn truyền lại đầu tiện nhận được, sau đó ta có thể suy ra
những đoạn khác đã bị mất.
II.4. TCP Vegas
TCP Vegas có thể dự đoán các điều kiện sử dụng băng thông mạng. Sự công
bằng và hiệu quả của nó thì tốt hơn so với giải thuật TCP khác [6]. Sự khác biệt
giữa thông lượng trông đợi (expected throughput) với thông lượng thực tế
(actual throughput). Thuật toán TCP Vegas có thể ước lượng được bang thông
mạng có sẵn. Nếu actual throughput và expect throughput quá gần thì giá trị của
delta là tương đối ít. Ta có thể xem xét việc ùn tắc không xảy ra trên mạng. Nếu
actual throughput rất nhỏ so với expected throughput , giá trị của delta là tương

đối lớn, do vậy, mạng có thể tắc nghẽn. Tuy nhiên, TCP Vegas phụ thuộc vào tỷ
lệ trông đợi trong việc tính toán băng thông.
III. TCP TRONG MẠNG TUỲ BIẾN KHÔNG DÂY.
Trong mạng tuỳ biến không dây, sự thay đổi thường xuyên của mô hình
mạng tuỳ biến có thể làm cho TCP đầu đến cuối kiểm soát trở nên khó khăn.
Mạng tuỳ biến không dây có tỷ lệ lỗi bít cao do các vấn đề như mất định tuyến,
sự mờ dần, tiếng ồn, nhiễu, ngắt kết nối và vấn đề thiết bị đầu cuối ẩn. Mạng tuỳ
biến không dây cấu hình theo cấu trúc động bỡi các nút có thể di động được. Tỷ
lệ lỗi bít cao của kênh không dây có nhiều loại khác nhau. Các liên kết và các
tuyến đường bất đối xứng ảnh hưởng tới hiệu suất TCP. Trong 1 kết nối TCP, lien
kết và tuyến đường thường xuyên thay đổi, quá trình định tuyến lại mất quá
nhiều thời gian, thời gian này có thể vượt quá giá trị thời gian chờ TCP, kết quả
làm giảm cửa sổ tắc nghẽn và hiệu suất TCP. Vì vậy thuật toán điều khiển tắc
đạt hiệu suất kém.
Từ nguồn tới đích, các tuyến đường thường xuyên thay đổi do mỗi nút di
chuyển trong môi trường không dây. Giao thức định tuyến tuỳ biến không dây sử
4


dụng giao thức định tuyến theo yêu cầu. Từ nguồn đến đích, tuyến đường có
nhiều con đường, gói tin có thể đi qua nhiều con đường khác nhau để tới đích,
nếu các thuộc tính không được xử lý, các gói tin được sắp xếp có thể kích hoạt
truyền lại giả mạo và gây nhầm lẫn trong điều khiển tắc nghẽn TCP. Việc nhận
được gói có trật tự, người gửi có thể nhận được 3 bản sao ACK, rồi có thể gây ra
hiệu suất kém sau khi thực hiện cơ chế kiểm soát tắc nghẽn.
IV. HOẠT ĐỘNG CỦA GIAO THỨC AODV( Adhoc On – Deman Distant
Vector)
AODV (Ad Hoc On-Demand Distance Vector) là giao thức dựa trên thuật
toán vector khoảng cách. AODV tối thiểu hoá số bản tin quảng bá cần thiết bằng
cách tạo ra các tuyến trên cơ sở theo yêu cầu. Quá trình định tuyến của giao thức

AODV có thể mô tả bằng sơ đồ sau:

Khi một nút nguồn muốn gởi một bản tin đến một nút đích nào đó và không
biết rằng đã có một tuyến đúng đến đích đó, nó phải khởi đầu một quá trình
khám phá đường truyền. Nó phát quảng bá một gói yêu cầu tuyến (RREQ) đến
các nút lân cận. Các nút lân cận này sau đó sẽ chuyển tiếp gói yêu cầu đến nút
5


lân cận khác của chúng. Quá trình cứ tiếp tục như vậy cho đến khi có một nút
trung gian nào đó xác định được một tuyến “đủ tươi” để đạt đến đích. AODV sử
dụng số thứ tự đích để đảm bảo rằng tất cả các tuyến không lặp và chứa hầu hết
thông tin tuyến hiện tại. Mỗi nút duy trì số tuần tự của nó cùng với một ID quảng
bá. ID quảng bá được tăng lên mỗi khi nút khởi đầu một RREQ, và cùng với địa
chỉ IP của nút, xác định duy nhất một RREQ. Cùng với số tuần tự và ID quảng
bá, nút nguồn bao gồm trong RREQ hầu hết số tuần tự hiện tại của đích mà nó
có. Các nút trung gian có thể trả lời RREQ chỉ khi nào chúng có một tuyến đến
đích mà số tuần tự đích tương ứng lớn hơn hoặc bằng số tuần tự chứa trong
RREQ.
Trong suốt quá trình chuyển tiếp RREQ, các nút trung gian ghi vào Bảng
định tuyến của chúng địa chỉ của các nút lân cận từ khi nhận được bản sao đầu
tiên của gói quảng bá, theo đó thiết lập được một đường dẫn theo thời gian. Nếu
các bản sao của cùng một RREQ được nhận sau đó, các gói này sẽ bị huỷ bỏ.
Một khi RREQ đã đạt đến đích hay một nút trung gian với tuyến “đủ tươi”, nút
đích (hoặc nút trung gian) đáp ứng lại bằng cách phát đơn phương một gói đáp
ứng tuyến (RREP) ngược về nút lân cận mà từ đó nó thu được RREQ. Khi RREP
được định tuyến ngược theo đường dẫn, các nút trên đường dẫn đó thiết lập các
thực thể tuyến chuyển tiếp trong Bảng định tuyến của chỉ nút mà nó nhận được
RREP. Các thực thể tuyến chuyển tiếp này chỉ thị tuyến chuyển tiếp tích cực.
Cùng với mỗi thực thể tuyến là một bộ định thời tuyến có nhiệm vụ xoá các thực

thể nếu nó không được sử dụng trong một thời hạn xác định. Do một RREP
chuyển tiếp trên đường dẫn được thiết lập bởi một RREQ nên AODV chỉ hỗ trợ
việc sử dụng đường truyền đối xứng.
Trong AODV, các tuyến đươc duy trì điều kiện như sau: Nếu một nút nguồn
chuyển động, nó phải khởi động lại giao thức khám phá tuyến để tìm ra một
tuyến mới đến đích. Nếu một nút trên tuyến chuyển động, nút lân cận luồng lên
của nó chú ý đến chuyển động đó và truyền một bản tin “Khai báo sự cố đường
thông” (một RREP không xác định) đến mỗi nút lân cận tích cực luồng lên để
thông báo cho các nút này xoá phần tuyến đó. Các nút này thực chất truyền một
“Thông báo sự cố đường thông” đến các nút lân cận luồng lên. Quá trình cứ tiếp
tục như vậy cho đến khi đạt đến nút nguồn. Nút nguồn sau đó có thể chọn khởi
6


động lại một quá trình khám phá tuyến cho đích đó nếu một tuyến vẫn cần thiết
[4].
Ngoài ra, giao thức này sử dụng bản tin HELLO được phát quảng bá định
kỳ bởi một nút để thông báo cho tất cả các nút khác về những nút lân cận của nó.
Các bản tin HELLO có thể được sử dụng để duy trì khả năng kết nối cục bộ của
một nút. Tuy nhiên, việc sử dụng bản tin HELLO là không cần thiết. Các nút
lắng nghe việc truyền lại gói dữ liệu để đảm bảo rằng vẫn đạt đến chặng kế tiếp.
Nếu không nghe được việc truyền lại như thế, nút có thể sử dụng một trong số
các kỹ thuật, kể cả việc tiếp nhận bản tin HELLO. Các bản tin HELLO có thể liệt
kê các nút khác mà từ đó nút di động đã nghe tin báo, do đó tạo ra khả năng liên
kết lớn hơn cho mạng.

V. THỰC HIỆN PHÂN TÍCH TCP SỬ DỤNG GIAO THỨC ĐỊNH TUYẾN
AODV

Hình 2. Mô hình mô phỏng


Để đánh giá hiệu suất của mỗi thuật toán TCP, chúng tôi thực hiện một mô
phỏng NS2 trên mô hình mạng đơn giản. Như thể hiện trong hình 2, nút 1 là
nguồn, nút 5 là nút đích. Ngoài ra có nhiều nút di động như là bộ định tuyến giữa
nút 1 và nút 5. Lưu lượng dữ liệu thí nghiệm là phiên FTP trên TCP. Kích thước
gói tin TCP là 1040 byte và TCP ACK là 60 byte. Các lớp liên kết sử dụng IEEE
802.11 giao thức MAC [8] và băng thông là 10Mbps. Thời gian trì hoãn đường
truyền là 10ms, sử dụng giao thức định tuyến AODV.
7


Như thể hiện trong hình 2, bắt đầu thời gian mô phỏng là 10 giây và sau đó
nút 3 rời khỏi phạm vi giữa nút 2 và nút 4 sau 70 giây. Khi mô phỏng 120 giây,
tuyến đường sẽ được thiết lập lại bỡi vì nút 3 được đặt giữa nút 4 và nút 5, thời
gian kết thúc mô phỏng là 150 giây.
Khi lớp vận chuyển chọn TCP Tahoe, TCP Reno, TCP new Reno và TCP
vegas trong mạng tuỳ biến không dây. Hình 3 cho thấy số thứ tự của gói tin
ACK.

Trong hình 2, kích thước cấu trúc liên kết thiết lập 800m. Mô phỏng so sánh
hiệu suất của mỗi thuật toán TCP.
Mạng tuỳ biến không dây không có tuyến đường cố định và cấu hình cấu
trúc liên kết động do các nút di động. Như thể hiện trong hình 2(b), số thứ tự của
mỗi TCP là không tăng sau 70 giây bỡi vì con đường bị cắt do nút 3 di chuyển.
Con đường định tuyến lại sau 120 giây. Nhưng TCP Tahoe có số thứ tự không
tăng cho đến khi ACK được đến bỡi gói chuyển tiếp, TCP Tahoe không gửi các
gói tin khác nên số thứ tự không được tăng lên. TCP new Reno cho biết con số
thấp hơn hoàn toàn so với thuật toán TCP khác. TCP new Reno hứng chịu thực tế
là 1 RTT khi nó phát hiện ra gói tin bị mất. Kết quả là TCP new Reno tạo ra hiệu
suất kém. Nhưng TCP Reno có hiệu suất tốt nhất so với thuật toán TCP khác.

Mặc dù lỗi đường truyền gây ra mất mát nhiều gói tin trong mạng tuỳ biến không
dây, khi bên gửi nhận được 3 bản sao ACK kích thước cửa sổ được thiết lập là

8


một nữa của Cwnd và bắt đầu giai đoạn tránh tắc nghẽn. Có thể cho TCP Reno
thực hiện thông lượng cao trong mạng tuỳ biến không dây.

Từ hình 4(a) đến 4(d) cho thấy kích thước cửa sổ của mỗi TCP. Ở hình 4(d),
kích thước cửa sổ tắc nghẽn của TCP Vegas có thay đổi nhỏ bỡi vì kích thước
cửa sổ tăng hoặc giảm nhiều như một đoạn theo tỷ lệ trông đợi, cái mà gửi đi sự
tính toán của đoạn.

9


Thể hiện trong hình 4(a) đến 4(c), đường dẫn bị cắt do nút di chuyển sau 70
giây, TCP thiết lập để được một nữa của kích thước cửa sổ tắc nghẽn và kích
thước cửa sổ tắc nghẽn thiết lập lại một, sau đó bắt đầu khởi động chậm. Mô
phỏng về thuật toán TCP là tương tự như cơ chế kiểm soát tắc nghẽn TCP. Khi
con đường bị cắt là 70 giây, kích thước cửa sổ tắc nghẽn của mỗi thuật toán TCP
thiết lập một nữa của Cwnd. Sau khi con đường định tuyến là 120 giây, kích
thước cửa sổ tắc nghẽn tăng theo cấp số nhân, nó bắt đầu khởi động chậm. TCP
công nhận tình huống tắc nghẽn mạng để định tuyến lại bỡi nút di động. Tóm lại,
nó được coi là kết quả của tình huống là thực hiện thuật toán điều khiển tắc
nghẽn khi kích thước của nó trở thành một. Cuối cùng thuật toán TCP kích hoạt
thuật toán điều khiển tắc nghẽn không cần thiết gây ra hiệu suất kém.

Hình 5:Thông lượng của TCP Tahoe và TCP new Reno


Hình 5 cho thấy thông lượng của TCP Tahoe và TCP new Reno. Như hình 3
và 4, thuật toán TCP Tahoe và TCP new Reno thực hiện kém hơn so với thuật
toán TCP khác. TCP Tahoe tăng việc truyền lại do nhiều gói tin bị mất bỡi nút di
động. Khi TCP Tahoe thực hiện việc truyền lại thì nó không có hiệu quả cho bộ
đếm thời gian truyền dẫn không được sử dụng. Mặc dù TCP new Reno trở nên
khó khăn trong một kết nối TCP, tuyến đường và sự lien kết thường xuyên thay
đổi, quá trình định tuyến lại thường mất nhiều thời gian, thời gian này có thể
vượt quá giá trị của thời gian chờ TCP, kết quả là phải giảm cửa sổ tắc nghẽn, tỷ
lệ lỗi bít cao…tiến hành hồi phục ở cuối thời gian mô phỏng nhưng nói chung nó
vẫn có hiệu suất kém. Từ khi TCP new Reno xảy ra nhiều tổn thất gói tin, nó
10


cũng có nhiều RTT. Có thể TCP new Reno không chính xác trong mạng tuỳ biến
không dây, nơi mà sự bùng nổ về tổn thất gói tin thường xuyên xảy ra.

Hình 6: Thông lượng của TCP Reno và TCP Vegas

Hình 6 cho thấy thông lượng của TCP Reno và TCP Vegas. TCP Reno và
TCP Vegas thực hiện tốt hơn so với TCP Tahoe và TCP new Reno. Đặc biệt TCP
Reno đã tăng tương đối tại thời điểm bắt đầu. Tuy nhiên TCP Reno tạo ra hiệu
suất không tốt như TCP Vegas do gói tin bị tổn thất thường xuyên. Tuy nhiên,
TCP Reno thực hiện thông lượng tốt hơn TCP khác sau 120 phút. Thuật toán
TCP Vegas dự đoán trước về tốc độ truyền. Bỡi vì TCP Vegas không thể dự đoán
chính xác sự tắc nghẽn của mạng trong mạng tuỳ biến không dây, nơi mà sự
bùng nổ về tổn thất gói tin thường xuyên xảy ra. Thông lượng TCP Vegas tương
đối thấp hơn TCP Reno.

11



VI. XÂY DỰNG MÔ HÌNH MÔ PHỎNG TRÊN NS2
Mô hình1:

Đây là mô hình chính của đề tài nhằm mô phỏng quá trình định tuyến lại trong
mạng tùy biến không dây, sử dụng giao thức định tuyến AODV khi các nút di
chuyển. Trong mô hình trên node 0 là node nguồn, node 4 là node đích. Các
node còn lại đóng vai trò là router khi giao thức định tuyến gọi đến. Phạm vi
mạng là 800x100m, kích thước các gói tin là 1040byte. Thời gian trễ của hệ
thống là 2ms, Thời gian mô phỏng rút gọn là 3.2s.
Quá trình truyền bắt đầu từ 0s. Đến 0.7s, node 2 và node 3 di chuyển và đổi chổ
cho nhau. Kết quả là từ giây thứ 0.7 trở đi, các giao thức thực hiện định tuyến lại
và đến giây thứ 1.8, Việc định tuyến lại mới kết thúc và các giao thức bắt đầu
truyền lại các gói tin. Kết quả mô phỏng cũng tương tự như trong đề tài đưa ra.

12


Mô hình 2:

Mô hình này nhằm khảo sát quá trình định tuyến lại khi node đích di chuyển ra
xa ngoài phạm vi truyền của node nguồn. Trong mô hình trên, node 3 là node
nguồn còn node 0 là đích. Các node còn lại đóng vai trò router khi giao thức
AODV yêu cầu định tuyến lại. Phạm vi mạng là 700x200. Kích thước gói tin là
210byte. Thời gian trễ của hệ thống là 2ms. Thời gian mô phỏng là 4s.
Quá trình truyền bắt đầu từ 0s. Lúc đầu, node 0 còn ở trong phạm vi truyền của
node 3, node3 sẽ truyền trực tiếp các gói tin cho node0 mặc dù node4 nằm giữa
phạm vi node 3 và node0. Sau 0.5s, node0 di chuyển ra ngoài phạm vi truyền,
giao thức AODV tiến hành định tuyến lại đường truyền từ 3 2 0. Đến giây

thứ 1.5, việc định tuyến này kết thúc và bắt đầu truyền lại. Sau 2.0s, node0 lại di
chuyển ra xa phạm vi node2, quá trình định tuyến lại được kích hoạt và đường
truyền được xác định là từ 3210.
Nhận xét: Ở lần định tuyến lại đầu tiên, thời gian để định tuyến rất nhiều. Bởi ở
lần này, giao thức phải tạo ra bảng định tuyến cho tất cả các node. Ở lần 2, việc
định tuyến diễn ra nhanh hơn do chỉ cập nhật lại thông tin. Chúng ta thấy ở lần
định tuyến này, mặc dù đường đi 3410 ngắn hớn đường đi 3210
nhưng AODV vẫn không chọn. Theo dõi quá trình mô phỏng ta sẽ thấy việc định
tuyến lại ở lần thứ 2 xuất phát từ node2 _ node cuối cùng trao đổi với node đích.
Node 2 gửi một gói tin quảng bá và tìm đường đi đến node0. Như vậy việc định
13


tuyến có thể nhanh hơn, tuy nhiên, phương án định tuyến chưa chắc là đường đi
ngắn nhất.

14


VII. KẾT LUẬN VÀ HƯỚNG NGHIÊN CỨU
Trong bài viết này, chúng tôi nghiên cứu mỗi thuật toán điều khiển tắc
nghẽn của TCP và vấn đề hiệu suất của TCP trong mạng tuỳ biến không dây.
Việc thực hiện của TCP ảnh hưởng trực tiếp tới thông lượng TCP và hiệu quả
truyền thông của mạng. Bỡi vì TCP được thiết kế để làm việc trong mạng có dây.
Hiệu quả của nó thật tồi tệ khi sử dụng trong mạng tuỳ biến không dây. Sự thay
đổi thường xuyên của mô hình mạng tuỳ biến không dây có thể gây ra TCP đầu
cuối kiểm soát trở nên khó khăn. Trong một kết nối TCP, tuyến đường và liên kết
thường xuyên thay đổi, quá trình định tuyến lại thường mất nhiều thời gian, thời
gian này có thể vượt quá giá trị của thời gian chờ, kết quả là phải giảm cửa sổ tắc
nghẽn, tỷ lệ lỗi bít cao của kênh không dây có các vấn đề khác nhau gồm mất

định tuyến, mờ dần, tiếng ồn, nhiễu, mất kết nối và vấn đề thiết bị đầu cuối ẩn.
Các tuyến đường và lien kết bất đối xứng đã ảnh hưởng tới hiệu suất TCP. Vì
vậy, trong bài viết này chỉ ra rằng mạng tuỳ biến không dây có tác dụng tên thuật
toán điều khiển tắc nghẽn. Sử dụng NS2 khi các nút di chuyển trong mạng tuỳ
biến không dây. Chúng tôi đã nghiên cứu số thứ tự của các gói ACK, kích thước
cửa sổ tắc nghẽn và thông lượng của mỗi thuật toán TCP. Kết quả mô phỏng cho
thấy, TCP Reno cung cấp hiệu suất tốt hơn TCP Tahoe, TCP New Reno và TCP
Vegas trong mạng tuỳ biến không dây. TCP Reno đã nhận được các gói dữ liệu
ổn định trong môi trường tuỳ biến không dây. Mặc dù TCP Reno có thông lượng
kém trong quá trình các nút di chuyển, nhưng TCP Reno cho thấy tỷ lệ gói tin
nhận được cao hơn các thuật toán TCP khác. Nhưng mạng tuỳ biến không dây
xem xét nhiều vấn đề gồm NLOS, thiết bị đầu cuối ẩn. Do đó thuật toán TCP
phải nghiên cứu liên tục để TCP đáng tin cậy và thích nghi.
Đề tài đã tìm hiểu và xây dựng được mô hình mô phỏng quá trình định
tuyến lại của mạng tùy biến không dây.
Trong quá trình xây dựng, đề tài đã đưa ra được một số nhận xét về đặc
điểm của giao thức định tuyến AODV, đồng thời so sánh kết quả giữa các giao
thức TCP sử dụng giao thức định tuyến AODV.
Tuy nhiên, do trình độ bản thân và thời gian hạn hẹp nên đề tài chưa xây
dựng được các chỉ tiêu hợp lý để đánh giá các giao thức trên. Vì vậy, nếu được
tiếp tục thì chúng tôi sẽ tìm hiểu về đánh giá mạng, đồng thời đưa ra những tiêu
chí để đánh giá sự khác nhau giữa các giao thức TCP khi kết hợp với giao thức
định tuyến AODV. Đồng thời chúng tôi cũng sẽ tìm hiểu kỹ hơn thuật toán định
15


tuyến của AODV và một số giao thức định tuyến khác trên mạng Adhoc để hoàn
thiện thêm đề tài nay.

16



17


MỤC LỤC
I. GIỚI THIỆU.................................................................................................................................................2
II. THUẬT TOÁN TẮC NGHẼN TCP.................................................................................................................2
II.1. TCP Tahoe..........................................................................................................................................3
II.2. TCP Reno............................................................................................................................................3
II.3. TCP new Reno....................................................................................................................................3
II.4. TCP Vegas...........................................................................................................................................4
III. TCP TRONG MẠNG TUỲ BIẾN KHÔNG DÂY..............................................................................................4
IV. HOẠT ĐỘNG CỦA GIAO THỨC AODV( Adhoc On – Deman Distant Vector)...........................................5
V. THỰC HIỆN PHÂN TÍCH TCP SỬ DỤNG GIAO THỨC ĐỊNH TUYẾN AODV................................................7
VI. XÂY DỰNG MÔ HÌNH MÔ PHỎNG TRÊN NS2.......................................................................................12
VII. KẾT LUẬN VÀ HƯỚNG NGHIÊN CỨU...................................................................................................15
....................................................................................................................................................................17

18