Đặc trưng lỗi của đường truyền vệ tinh
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
Arthur C Clarke, nhà văn khoa học giả tưởng, là người đầu tiên đề xuất ý tưởng về vệ tinh nhân tạo cho truyền thông vào năm 1945, nghiên cứu cách phóng và quỹ đạo của chúng để xây dựng hệ thống vệ tinh toàn cầu Ông đã đề xuất sử dụng ba vệ tinh địa tĩnh để phủ sóng toàn bộ Trái Đất Vệ tinh nhân tạo đầu tiên, SPUTNIK 1, được Liên bang Xô viết phóng lên vào ngày 4 tháng 10 năm 1957, đã khẳng định ý tưởng của Clarke và trở thành động lực cho sự phát triển của truyền thông vệ tinh toàn cầu Mặc dù công nghệ của SPUTNIK chỉ phát ra tín hiệu radio đơn giản, nhưng nó đánh dấu bước tiến lớn trong việc chinh phục không gian Đến năm 1960, vệ tinh ECHO của Mỹ trở thành vệ tinh truyền thông đầu tiên với khả năng tiếp nhận và phản hồi tín hiệu Vệ tinh địa tĩnh đầu tiên, SYNCOM, ra đời vào năm 1963, giữ vị trí cố định so với mặt đất, tạo điều kiện cho việc phát sóng các chương trình thời sự trên toàn nước Mỹ.
Từ những năm 1960, các vệ tinh thương mại như INTELSAT-1 đã được đưa lên quỹ đạo, với INTELSAT-1 nặng 68 kg cung cấp 240 kênh điện thoại tương đương một kênh truyền hình Tiếp theo, INTELSAT-2 và INTELSAT-3 đã mở rộng số kênh thoại lên tới 1200 kênh Năm 1976, MARISAT ra đời, cung cấp dịch vụ truyền thông cho phương tiện giao thông đường thủy, giúp các tàu thuyền liên lạc thường xuyên với nhau và với đất liền 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, theo sau là INMARSAT-C vào năm 1988, và đến năm 1993, các hệ thống điện thoại vệ tinh đã được số hóa hoàn toàn Năm 1998, dự án Iridium của Motorola ra mắt với 66 vệ tinh, cho phép kết nối toàn cầu, mặc dù ban đầu dự kiến 77 vệ tinh Hệ thống Iridium được xem là một thành tựu nổi bật trong lĩnh vực khoa học kỹ thuật Một hệ thống vệ tinh quan trọng khác là Globalstar, với 48 vệ tinh, đã chứng minh sự phát triển ấn tượng của truyền thông vệ tinh chỉ sau hơn 30 năm kể từ khi 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:
Vệ tinh đóng vai trò quan trọng trong nghiên cứu trái đất, môi trường và dự báo thời tiết nhờ diện tích quan sát rộng lớn Sử dụng công nghệ hiện đại, vệ tinh có khả năng thăm dò sâu vào lòng đất, hỗ trợ nghiên cứu địa chất và khai thác tài nguyên Hơn nữa, với ưu điểm không bị cản trở bởi khí quyển, vệ tinh cũng rất hiệu quả trong nghiên cứu thiên văn và vũ trụ.
Các hệ thống định vị toàn cầu sử dụng vệ tinh đã trở nên phổ biến trong đời sống hàng ngày, góp phần quan trọng vào nhiều lĩnh vực kinh tế xã hội như tránh tắc nghẽn giao thông và xác định vị trí trên đất liền cũng như trên biển.
Quân sự là một trong những ứng dụng đầu tiên của vệ tinh, được sử dụng cho nhiệm vụ trinh sát, chụp ảnh do thám, gây nhiễu và phá hủy hạ tầng truyền thông của đối phương Ngoài ra, thông tin liên lạc quân sự qua vệ tinh cũng mang lại sự an toàn hơn trước các cuộc tấn công bằng vũ khí thông thường của kẻ thù.
Vệ tinh mang lại lợi thế vượt trội với bán kính phủ sóng rộng lớn, cho phép kết nối đến những khu vực hẻo lánh như hải đảo và vùng cực, điều mà các hệ thống ăng ten hay truyền hình cáp không thể thực hiện Đặc biệt, trong lĩnh vực truyền thông di động, những ưu điểm của truyền thông vệ tinh được phát huy tối đa.
Truyền thông vệ tinh đã từ lâu giữ vai trò quan trọng trong việc kết nối toàn cầu, với khả năng cung cấp đường truyền băng thông rộng cho điện thoại Công nghệ này cho phép truyền tải nhiều kênh điện thoại, tạo điều kiện thuận lợi cho liên lạc trên toàn thế giới.
Kết nối các vùng xa xôi hẻo lánh là một thách thức lớn do những nguyên nhân chính trị, quân sự và yếu tố địa lý Trong những trường hợp này, đường truyền vệ tinh trở thành giải pháp lý tưởng để đảm bảo kết nối thông tin.
�Thông tin di động toàn cầu: thường sử dụng vệ tinh quỹ đạo thấp vì độ trễ nhỏ hơn so với vệ tinh địa tĩnh.
Đặ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 trong các hệ thống vệ tinh là một vấn đề lớn, với tỷ suất lỗi bit (BER) trung bình từ 10^-7 đến 10^-4, do các chuẩn truyền thông cũ được tối ưu hóa cho tín hiệu âm thanh và hình ảnh analog Tuy nhiên, nhờ vào 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, tỷ suất lỗi có thể giảm xuống tới 10^-10 với vệ tinh địa tĩnh Đối với các hệ thống vệ tinh quỹ đạo thấp, mặc dù tỷ suất lỗi có thể biến động, công nghệ hiện đại đang giúp cải thiện chất lượng truyền và độ ổn định không thua kém cáp quang Nguyên nhân gây lỗi chủ yếu là do nhiễu và suy giảm tín hiệu, đặc biệt khi tín hiệu vệ tinh bị hấp thụ bởi sương mù, mây và mưa Thêm vào đó, độ trễ trong truyền tín hiệu cũng là một yếu tố cần lưu ý, với các vệ tinh địa tĩnh GSO ở độ cao 36.000 km, dẫn đến thời gian truyền tín hiệu radio giữa hai trạm mặt đất qua vệ tinh gấp đôi thời gian truyền từ trạm mặt đất tới vệ tinh, vào khoảng 239,6 ms.
Mô hình mạng vệ tinh cho thấy rằng các trạm ở rìa vùng phủ sóng của vệ tinh có khoảng cách lên đến 2*41,576 km, dẫn đến thời gian truyền tín hiệu lớn hơn, khoảng 2*279U8 ms (RTT) Ngoài độ trễ truyền, còn có các loại độ 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 tại 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 quan trọng.
Tiếng ồn trong truyền tín hiệu vô tuyến tăng lên khi khoảng cách truyền xa, đặc biệt là trong các liên kết vệ tinh, làm cho cường độ tín hiệu yếu đi đáng kể Điều này dẫn đến việc tỷ số tín hiệu trên nhiễu (SNR) bị suy giảm Một số tần số rất nhạy cảm với các yếu tố khí quyển như mưa và sương mù, gây ra sự suy giảm cường độ tín hiệu Đối với các ứng dụng di động, kênh vệ tinh cũng dễ bị ảnh hưởng bởi hiện tượng truyền đa đường, dẫn đến méo tín hiệu.
Tỷ lệ lỗi bit (BER) cho các liên kết vệ tinh hiện nay khoảng 1 lỗi trên 10 triệu bit (1x10^-7) hoặc thấp hơn Các kỹ thuật kiểm soát lỗi và mã hóa tiên tiến có thể được tích hợp vào dịch vụ truyền thông vệ tinh hiện tại Tuy nhiên, nhiều hệ thống vệ tinh vẫn sẽ có tỷ lệ BER cao hơn so với các hệ thống mới và các kênh truyền trên mặt đất.
Băng thông là tài nguyên có giới hạn trong phổ tần số radio, dẫn đến việc chỉ một số lượng băng thông nhất định được cấp phép cho các hệ thống truyền thông vệ tinh Điều này tạo ra tình trạng khan hiếm băng thông cho các ứng dụng thương mại khác Tần số sóng điển hình cho truyền vệ tinh, theo phương thức điểm-tới-điểm, là 6GHz cho uplink.
Băng tần vệ tinh bao gồm 4 GHz (băng tần C), 14/12 GHz (băng tần Ku) và sắp tới sẽ có băng tần Ka 30/20 GHz Các bộ lặp radio vệ tinh, hay còn gọi là bộ tiếp sóng (transponder), cho phép truyền tải dữ liệu Băng tần C có băng thông 36MHz, đủ để truyền một kênh truyền hình màu hoặc 1.200 kênh thoại, trong khi băng tần Ku có dải tần rộng khoảng 50MHz Một vệ tinh có thể mang theo hàng chục transponders, nhưng băng thông truyền vệ tinh bị hạn chế do giới hạn tài nguyên và các thỏa thuận quốc tế Kênh vệ tinh khác với kênh mặt đất, nhưng những đặc điểm này có thể ảnh hưởng đến hiệu suất của giao thức TCP.
Trễ phản hồi trong giao thức TCP do độ trễ truyền của các kênh vệ tinh, như vệ tinh địa tĩnh với khoảng 250ms, khiến người gửi phải chờ lâu để xác nhận gói tin đã được nhận Sự chậm trễ này ảnh hưởng tiêu cực đến các ứng dụng như telnet và các thuật toán điều khiển tắc nghẽn TCP Hơn nữa, tích số của băng thông và độ trễ, với độ trễ là thời gian khứ hồi (RTT) và băng thông là dung lượng của liên kết nút cổ chai, xác định khả năng gửi dữ liệu liên tiếp Trong môi trường vệ tinh, độ trễ lớn yêu cầu TCP phải duy trì nhiều gói tin trên đường truyền để tối ưu hóa việc sử dụng kênh truyền.
Các kênh truyền hình vệ tinh thường có tỷ lệ lỗi bit (BER) cao hơn so với các kênh truyền trong mạng mặt đất Giao thức TCP sử dụng thông tin về các gói tin bị mất như tín hiệu để phát hiện tắc nghẽn mạng Khi phát hiện tắc nghẽn, TCP sẽ giảm kích thước cửa sổ phát để cố gắng giảm thiểu tình trạng này Nếu không xác định được nguyên nhân mất gói tin, TCP mặc định cho rằng nguyên nhân là do tắc nghẽn và áp dụng phương thức điều khiển tránh tắc nghẽn để bảo vệ mạng khỏi sụp đổ.
Mạng truyền thông vệ tinh không đối xứng thường được xây dựng do chi phí cao khi 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 Trong ví dụ này, máy tính kết nối với mạng vệ tinh sẽ gửi tất cả thông tin yêu cầu qua một liên kết mặt đất có tốc độ truyền thấp, như kênh mô hình quay số, và nhận lưu lượng cần truy cập qua kênh vệ tinh.
(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) là hiện tượng thường gặp trong các mạng vệ tinh, đặc biệt là mạng sử dụng vệ tinh quỹ đạo thấp (LEO), nơi mà độ trễ truyền tín hiệu đến và đi từ các vệ tinh liên tục thay đổi 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 yêu cầu việc chuyển giao kết nối TCP giữa các vệ tinh hoặc trạm mặt đất theo thời gian Nếu quá trình này không được thực hiện nhanh chóng, có thể dẫn đến mất gói tin và gián đoạn kết nối Hầu hết các kênh vệ tinh chỉ sở hữu một số đặc điểm cần thiết cho việc này.
1.2.2 Các mô hình lỗi trên đường truyền vệ tinh
Trong bài viết này, tôi sẽ trình bày về mô hình lỗi (Error Model) trong bộ mô phỏng mạng NS2 Mô hình lỗi này giúp mô phỏng các lỗi truyền hoặc mất gói tin ở từng mức liên kết, thông qua việc đánh dấu cờ lỗi hoặc hủy gói tin đến đích Trong quá trình giả lập, các lỗi có thể được tạo ra từ mô hình lỗi đơn giản như tỉ lệ lỗi gói tin, hoặc từ các mô hình thống kê và thực nghiệm phức tạp hơn Để hỗ trợ cho các 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 kế thừa từ lớp cơ sở kết nối, cho phép tìm kiếm đối tượng như đích và hủy đích Khi hủy đích tồn tại, nó nhận gói tin từ mô hình lỗi, đánh dấu cờ lỗi error_flag trong tiêu đề gói tin, giúp các tác nhân điều khiển việc loại bỏ gói lỗi Mô hình lỗi cũng định nghĩa phương thức Tcl để chỉ ra đơn vị lỗi và biến ngẫu nhiên tạo ra lỗi, với đơn vị lỗi mặc định trong gói tin và biến ngẫu nhiên được chỉ định là 0 hoặc 1 Ví dụ, một mô hình lỗi có tỷ lệ lỗi gói tin 1% có thể được tạo ra.
# 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]
# Tùy chọn: thiết lập các đơn vị tính lỗi và biến ngẫu nhiên
# error unit: packets (the default)
$loss_module ranvar [new RandomVariable/Uniform]
# set target for dropped packets
Để xây dựng mô hình lỗi cho mạng không dây, mỗi node có thể được tích hợp vào một mô hình thống kê cho cả kênh ra và kênh vào Mô hình lỗi sẽ nằm giữa tầng MAC và NET, với mô đun lỗi cho kênh ra được xác định bởi đích của mô đun MAC và cho kênh vào bởi đích của mô đun NET Điều này tạo ra sự khác biệt trong cách mà các gói dữ liệu bị lỗi được xử lý; trong trường hợp kênh ra, tất cả các máy nhận đều nhận các gói dữ liệu với mức độ lỗi giống nhau, trong khi ở kênh vào, các gói tin bị hỏng có thể được nhận với mức độ lỗi khác nhau do tính độc lập của các mô đun lỗi.
Việc chèn mô hình lỗi vào đường truyền không dây có thể thực hiện thông qua lệnh node-config với hai tùy chọn là IncommingErrProc và OutgoingErrProc Cả hai tùy chọn này có thể được sử dụng đồng thời hoặc riêng biệt Dưới đây là một đoạn code TCL đơn giản minh họa cho việc này.
$ns node-config -IncomingErrProc UniformErr -OutgoingErrProc UniformErr proc UniformErr set err [new ErrorModel]
$err unit packet return $err
Giao thức TCP và các cơ chế điều khiển tắc nghẽn
Tổng quan về giao thức TCP
TCP là giao thức truyền thông tin đáng tin cậy và hướng kết nối, yêu cầu thiết lập một kết nối ảo giữa hai máy tính trước khi bắt đầu truyền dữ liệu Sự phức tạp của giao thức TCP chủ yếu đến từ
�phải quản lý đúng số tuần tự tính theo byte của dòng số liệu.
Để tối ưu hóa hiệu suất truyền, cần giám sát và điều chỉnh lưu lượng gửi tin từ thực thể gửi đến thực thể nhận Điều này đảm bảo khả năng tự thích ứng với trạng thái của đường truyền, nhất là khi chia sẻ với các kết nối khác.
Để đảm bảo trao đổi số liệu tin cậy và chính xác giữa các thực thể cuối trong mạng chính, cần thực hiện các yếu tố sau: Đối thoại khi thu phát yêu cầu bên nhận thông báo đúng sau một khoảng thời gian nhất định, nếu không sẽ coi gói số liệu nhận sai và phát lại Kiểm tra số liệu thu phát được thực hiện bằng cách gửi các byte kiểm tra (Checksum) cùng với số liệu và so sánh chúng khi thu Kiểm tra số tuần tự là cần thiết để đảm bảo các gói TCP được sắp xếp đúng thứ tự, loại bỏ các gói trùng lặp Điều khiển lưu lượng giúp hạn chế lượng số liệu mà thực thể phát gửi, nhằm tránh tràn bộ đệm của thực thể 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 để trao đổi số liệu, với mỗi thực thể có bộ đệm riêng để lưu giữ tạm thời số liệu Cách thức chuyển tiếp số liệu giữa các bộ đệm này ảnh hưởng lớn đến hiệu suất của hệ thống TCP.
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 bao gồm phần tiêu đề TCP “giả” và gói số liệu TCP “thực” Tiêu đề giả, cần thiết cho việc xây dựng gói số liệu IP, chứa 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 Các trường trong gói số liệu TCP thực mang ý nghĩa quan trọng trong việc truyền tải dữ liệu.
�Soure Port: Số hiệu cổng TCP bên phát.
Cổng đích TCP là số hiệu cổng xác định tại điểm đến; cùng với địa chỉ IP nguồn và địa chỉ IP đích, các số hiệu cổng này tạo thành một định danh duy nhất cho hai tiến trình ở hai đầu kết nối TCP.
Số tuần tự phát (sequence number) là định danh byte đầu tiên trong phần số liệu của gói TCP, thể hiện khoảng cách tương đối của byte đầu tiên với dòng byte trong luồng dữ liệu từ thực thể TCP gửi đến thực thể TCP nhận Đây là một số không dấu 32 bit, có giá trị từ 0 đến 2^32 - 1 Trong một kết nối TCP, khi thiết lập, trường số tuần tự sẽ chứa giá trị khởi tạo ISN (Initial Sequence Number) do thực thể TCP chọn, và byte dữ liệu đầu tiên sẽ có số tuần tự là ISN + 1.
Vị trí tương đối của byte cuối cùng đã được nhận chính xác bởi thực thể nhận cộng thêm 1, và giá trị của trường này được gọi là số tuần tự thu Trường này sẽ đúng khi bit cờ ACK bằng 1.
Trường dữ liệu Offset trong TCP xác định khoảng cách giữa trường số liệu và phần tiêu đề TCP, được tính theo từ 32 bit Giá trị phổ biến của trường này thường là 5, tương ứng với độ dài tiêu chuẩn của phần tiêu đề TCP là 20 bytes.
�Reserved: Luôn được đặt là 0, để dùng cho tương lai.
Trong tiêu đề TCP có 6 bit cờ, cho phép một hoặc nhiều cờ được thiết lập đồng thời Cờ URG = 1 cho biết giá trị trường Urgent Pointer là chính xác, trong khi cờ ACK = 1 xác nhận giá trị trường Acknowledgment đúng Cờ PSH = 1 yêu cầu thực thể nhận chuyển dữ liệu ngay lập tức cho ứng dụng Cờ RST = 1 được sử dụng để tái khởi tạo kết nối, còn cờ SYN = 1 đồng bộ hóa trường số thứ tự nhằm thiết lập kết nối TCP Cuối cùng, cờ FIN = 1 thông báo rằng thực thể gửi đã hoàn tất việc gửi dữ liệu.
Kích thước cửa sổ bên thu xác định tổng số byte dữ liệu mà thực thể thu có khả năng nhận, tương đương với kích thước bộ đệm thu, bắt đầu từ giá trị của trường số tuần tự thu (Số xác nhận).
Checksum, hay 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, bao gồm 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 MSS
(Maximum Segment Size) của một gói số liệu TCP; có thể khai báo tuỳ chọn SACK tại trường này.
�Pad: Độn thêm vào phần tiêu đề, để độ lớn của nó là bội của 4 byte.
�Data: Số liệu của ứng dụng TCP.
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
Kết nối TCP được thiết lập thông qua phương thức bắt tay ba bước, bắt đầu khi trạm làm việc (Agent A) gửi gói TCP với cờ SYN = 1, gọi là gói điều khiển SYN, cùng với giá trị khởi tạo số tuần tự ISN của mình ISN là số 32 bit, tăng lên mỗi khi có một kết nối mới được yêu cầu và quay về 0 khi đạt giá trị 2^32 Gói điều khiển SYN cũng chứa số hiệu cổng TCP của dịch vụ mà trạm làm việc muốn kết nối Mỗi kết nối TCP có giá trị ISN riêng, giúp tránh việc sử dụng lại số liệu cũ (stale) từ các kết nối trước đó, ngay cả khi địa chỉ IP và số hiệu cổng đã được sử dụng.
Phương thức bắt tay ba bước trong giao thức TCP bắt đầu khi thực thể TCP nhận gói điều khiển SYN và sẵn sàng thiết lập kết nối Sau đó, phần mềm dịch vụ (Agent B) gửi lại gói SYN kèm theo giá trị ISN của mình và đặt bit cờ ACK=1 để xác nhận đã nhận giá trị ISN từ thực thể gửi (bước 2) Cuối cùng, Agent A sẽ phản hồi lại Agent B khi nhận được tín hiệu SYN từ Agent B.
B xác nhận đã nhận giá trị ISN của Agent B bằng một ACK cuối cùng, cho thấy sự trao đổi tin cậy giữa các thực thể TCP Điều này cho phép các thực thể sẵn sàng trao đổi số liệu Lưu ý rằng không có gói điều khiển SYN nào trong ba bước trên chứa dữ liệu của ứng dụng, mà tất cả thông tin điều khiển đều nằm trong phần tiêu đề của gói điều khiển TCP trong bước 3.
Để chấm dứt phiên làm việc, thực thể TCP (Agent A) gửi yêu cầu kết thúc kết nối với cờ FIN đến đối tác truyền thông (Agent B) Kết nối TCP là song công, nên mặc dù Agent B nhận yêu cầu chấm dứt, họ vẫn có thể tiếp tục truyền dữ liệu cho đến khi không còn dữ liệu để gửi Cuối cùng, kết nối TCP chỉ thực sự kết thúc khi Agent B phản hồi lại yêu cầu chấm dứt kết nối bằng một gói tin cũng có 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
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:
Tăng tuyến tính sẽ tiếp tục cho đến khi có gói tin bị mất hoặc đạt ngưỡng ssthresh Khi xảy ra mất gói, giá trị ssthresh sẽ được tính bằng một nửa cwnd, và cwnd sẽ được thiết lập lại tương ứ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 "thăm dò" khả năng của đường truyền hiện tại với việc thiết lập cwnd ở mức thấp (cwnd = 1), nhưng tăng nhanh như quá trình hiệu chỉnh thô phát gói Khi tắc nghẽn xảy ra, quá trình congestion avoidance hoạt động giống như hiệu chỉnh tinh, giúp hạn chế tắc nghẽn Mục tiêu cuối cùng của cả hai quá trình là đảm bảo phát gói ở mức cao nhất có thể.
Hình 2.5 Quá trình slowstart và congestion avoidnce
Mục đích của Fast-Retransmit là tăng tốc quá trình truyền lại gói bị mất bằng cách cho phép đầu gửi thực hiện việc truyền lại ngay khi nhận được ba biên nhận lặp (dupAcks), thay vì phải chờ đến khi hết thời gian chờ (time-out) Điều này giúp cải thiện hiệu suất truyền tải dữ liệu và giảm độ trễ trong mạng.
Với Tahoe TCP, khi phát hiện mất gói, kết nối sẽ trở về quá trình slow-start Tuy nhiên, nếu kích thước cửa sổ lớn và tỉ lệ mất gói thấp, việc quay lại slow-start là không cần thiết, vì có thể chuyển sang trạng thái congestion avoidance Mục đích của Fast-Recovery là thực hiện ý tưởng này Trong quá trình Fast-Retransmit, bên gửi ghi nhận gói truyền lại, và sau khi gói được truyền lại, giá trị của ssthresh và cwnd sẽ được điều chỉnh Điều này có nghĩa là kết nối sẽ tiếp tục ở trạng thái congestion avoidance, với giá trị cwnd giảm xuống còn một nửa thay vì xuống bằng 1.
Một số phiên bản TCP
TCP Tahoe, được đề xuất bởi Jacobson vào năm 1988, là thuật toán điều khiển tắc nghẽn đầu tiên, bao gồm ba giai đoạn: slow-start, congestion avoidance và Fast-Retransmit Ban đầu, Tahoe chỉ xác nhận mất gói thông qua sự kiện hết giờ (time-out), không dựa vào lặp dupACKs, dẫn đến việc phát hiện mất gói chậm và phản ứng kém với tắc nghẽn Khi một gói bị mất, Tahoe phải chờ đến khi hết thời gian chờ, gây lãng phí băng thông trong khi đường truyền vẫn rảnh Do đó, một trong những cải tiến của Tahoe là công nhận việc nhận ba lần dupACKs như một dấu hiệu cho thấy gói đã bị mất.
Hình 2.7 Lưu đổ giải thuật slowstart
Hình 2.8 Lưu đồ chi tiết TCP-Tahoe
TCP Reno được cải tiến từ TCP Tahoe (Jacobson 1990) TCP Reno định nghĩa giai đoạn Fast-Recovery Giai đoạn này được bắt đầu khi đầu phát nhận được 3 dupACKs
Trong trường hợp này, việc không trở về chế độ slow-start là do nhận được các dupACKs, cho thấy rằng các gói TCP đã được nhận thành công ở đầu thu Điều này cho thấy luồng dữ liệu vẫn được duy trì giữa đầu phát và đầu thu, và TCP không muốn giảm đột ngột lưu lượng khi chuyển về slow-start Giai đoạn Fast-Retransmit và Fast-Recovery được thực hiện đồng thời, được gọi là FR/FR Khi nhận được dupACKs thứ ba liên tiếp, giá trị ssthresh sẽ giảm xuống còn một nửa giá trị cwnd, nhưng không nhỏ hơn 2 Quá trình retransmit sẽ được thực hiện để gửi lại gói bị mất, đồng thời cwnd sẽ được gán giá trị bằng ssthresh cộng với kích thước 3 segment hoặc 3 gói Điều này gián tiếp điều khiển cửa sổ phát (w = min(awnd, cwnd)), và với mỗi dupACK nhận được, cwnd sẽ tăng thêm một.
Khi xảy ra mất gói, cửa sổ phát (cwnd) sẽ tăng thêm một lượng n, tương ứng với số lượng ACKs đã nhận cho các gói đã gửi thành công Điều này giúp duy trì luồng phát Khi nhận được một ACK mới, cwnd sẽ trở về mức ssthresh và bắt đầu quá trình tránh tắc nghẽn (congestion avoidance).
Hình 2.9 Lưu đồ điểu khiển TCP-Reno
TCP New-Reno là một phiên bản cải tiến của Reno, có khả năng phát hiện mất nhiều gói trong cùng một cửa sổ Tương tự như Reno, New-Reno khởi động giai đoạn Fast-Retransmit khi nhận được các dupACKs, nhưng không rời khỏi giai đoạn Fast-Recovery cho đến khi tất cả các gói tin chưa được biên nhận được xác nhận Nhờ đó, New-Reno khắc phục vấn đề giảm cwnd nhiều lần khi xảy ra mất mát nhiều gói.
Trong giai đoạn Fast-Recovery, khi nhận được một ACK mới, có hai trường hợp xảy ra: nếu ACK xác nhận tất cả dữ liệu, New-Reno hoạt động giống như Reno Ngược lại, nếu nhận được Partial ACK, điều này cho thấy có nhiều hơn một gói bị mất Trong tình huống này, New-Reno sẽ gửi lại các gói mất cho đến khi tất cả các segment chưa được xác nhận được xác nhận Chi tiết về thuật toán này được mô tả trong RFC.
Hạn chế của New-Reno là mặc dù nó hỗ trợ gửi lại nhiều gói dữ liệu, nhưng cần một khoảng thời gian RTT để phát hiện và xử lý mỗi gói bị mất.
SACK, short for Selective Acknowledgment Options, was introduced by M Mathis, J Mahdavi, S Floy, and A Romanow and detailed in RFC 2018 in October 1996 This protocol enhances the acknowledgment process in data transmission by allowing selective acknowledgment of received packets.
Khác với cơ chế gửi ACK của Tahoe, Reno, hay NewReno, SACK không gửi ACK cho từng segment mà gửi ACK cho một nhóm các segment, bao gồm thông tin về các khối segment liên tiếp Điều này cho phép suy ra các segment bị mất Hình 2.10 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à
Ba khối segment liên tục [1:1], [3:3], [5:6] cho thấy rằng các gói 2 và 4 đã bị mất Một trong những ưu điểm nổi bật của SACK so với CACK là khả năng phát hiện đồng thời nhiều segment bị mất, điều mà CACK không thể thực hiện.
SACK là một tùy chọn mở rộng của TCP, chỉ xuất hiện trên các gói ACK Có hai loại tùy chọn SACK: loại 4 để báo hiệu cho phép SACK và loại 5 để chứa thông tin SACK, bao gồm các khối segment liên tiếp Cấu trúc của các tùy chọn này rất quan trọng trong việc cải thiện hiệu suất truyền tải dữ liệu.
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
Với option 5 (option có type = 5), các khối segment được lưu thành từng cặp (left, right) liên tục, với 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, cho phép tối đa 4 blocks với 40 bytes mà TCP dành cho option này Tuy nhiên, nếu sử dụng Option Timestamp, n tối đa chỉ còn lại 3 Giai đoạn thiết lập kết nối là thời điểm để đầ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 giao thức Reno, dựa trên cơ chế SACK, nhằm khắc phục vấn đề truyền lại nhiều gói đồng thời mà Reno và New-Reno không thể giải quyết Với TCP SACK, trong một vòng thời gian RTT, khả năng truyền lại nhiều gói dữ liệu được cải thiện đáng kể.
TCP SACK kế thừa các cơ chế slow-start và Fast-Retransmit từ Reno, cùng với cơ chế hết giờ (time-out) của Tahoe để xử lý các gói bị mất không được phát hiện Các block trong tùy chọn SACK cung cấp thông tin về các gói đã mất và các gói outstanding để đầu gửi có thể gửi lại Khi bắt đầu giai đoạn Fast-Recovery, đầu thu ghi nhận số lượng dữ liệu outstanding (biến pipe) và giảm cwnd xuống một nửa Mỗi khi nhận được ACK, biến pipe giảm đi 1, trong khi khi truyền lại một segment, pipe được tăng lên 1 Khi pipe nhỏ hơn cwnd, đầu phát sẽ kiểm tra và gửi những segment chưa được gửi Khi không còn segment outstanding, dữ liệu mới sẽ được gửi Như vậy, trong một khoảng thời gian RTT, có thể truyền lại nhiều hơn một segment Nếu có sự mất gói trong quá trình truyền lại, segment mất sẽ được phát hiện qua đồng hồ phát lại (retransmission time-out), và khi xảy ra sự kiện này, SACK sẽ thực hiện slow-start.
Những vấn đề của TCP trong môi trường mạng không dây
Chất lượng của giao thức TCP trong môi trường không dây thường thấp hơn so với mạng có dây Nguyên nhân chủ yếu là do TCP không phân biệt được nguyên nhân gây mất gói, mà chỉ cho rằng đó là do tắc nghẽn mạng Trong khi đó, mất gói trong môi trường không dây có thể xảy ra không chỉ do tắc nghẽn mà còn do lỗi đường truyền.
Gói dữ liệu TCP có thể bị mất do chất lượng môi trường truyền kém và việc thiếu giao thức điều khiển tin cậy ở tầng liên kết Khi xảy ra lỗi, tầng liên kết sẽ chuyển giao xử lý cho TCP sau một số lần cố gắng truyền lại Handover kết nối cũng có thể dẫn đến mất dữ liệu, ảnh hưởng đến cả cửa sổ phát Mất dữ liệu từ giao thức không tin cậy hoặc handover có thể gây timeout, buộc TCP quay về pha slow-start hoặc thực hiện Fast-Recovery và Fast-Retransmit khi nhận được ba gói ACK trùng lặp Đôi khi, TCP áp dụng cơ chế tránh tắc nghẽn không cần thiết Tuy nhiên, sau khi mất gói, chất lượng môi trường truyền có thể nhanh chóng phục hồi, và việc truyền thông giữa thiết bị và BS có thể diễn ra mà không gặp vấn đề gì.
Độ trễ đường truyền dài có thể dẫn đến tình trạng timeout ở đầu phát, kích hoạt việc truyền lại không cần thiết Nguyên nhân của độ trễ này bao gồm băng thông thấp, tầng liên kết hoạt động kém, môi trường truyền không thuận lợi, và các bộ đệm chờ xử lý ở thiết bị trung gian Hơn nữa, độ trễ lớn cũng làm tăng RTO, khiến TCP phản ứng chậm khi xảy ra mất dữ liệu thực sự.
Như vậy theo một khảo sát nghiên cứu [6], vấn đề của các giải thuật TCP truyền thống mắc phải trong môi trường không dây là:
Việc mất gói dữ liệu trên đường truyền không dây có thể do môi trường truyền không tốt, mất kết nối tạm thời hoặc di chuyển Trong những trường hợp này, TCP thường phản ứng như khi có tắc nghẽn Để tối ưu hóa TCP, cần cải tiến khả năng phân biệt nguyên nhân mất gói, áp dụng phương thức hoạt động hợp lý cho các tình huống mất gói không phải do tắc nghẽn, và phát hiện kịp thời các trường hợp mất kết nối tạm thời hoặc di động để xử lý một cách tối ưu.
Độ trễ cao gây ảnh hưởng đến hiệu suất của TCP, vì vậy việc tối ưu hóa độ trễ và tránh tăng RTT không cần thiết là rất quan trọng Giải pháp hiệu quả thường liên quan đến việc cải thiện các phương thức ở tầng liên kết hoặc tính toán băng thông hợp lý, thay vì giảm cửa sổ phát một cách tùy tiện.
• Đảm bảo độ công bằng trong cải tiến giải thuật (fairness)
Một số phương pháp nâng cao hiệu năng TCP trong mạng không dây
Link layer
Ý tưởng chính là cải thiện khả năng của TCP bằng cách hỗ trợ ở lớp liên kết dữ liệu Thay vì áp dụng phương thức truyền lại end-to-end trong tầng giao vận của TCP, phương pháp này thực hiện việc truyền lại cục bộ tại tầng liên kết Trong môi trường có nhiều lỗi như mạng không dây, việc truyền lại từng đoạn ở tầng liên kết giúp giảm thiểu việc truyền lại dữ liệu qua quãng đường dài.
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, giúp TCP tránh việc truyền lại không cần thiết Là một tác tử trong BS, Snoop đệm các frame ở tầng liên kết và kiểm tra nội dung của TCP header mà không cần thực thi TCP trong BS Việc truyền lại qua kết nối không dây được kích hoạt khi có timeout ở tầng liên kết hoặc nhận được dupACKs từ MH Khi nhận dupACK đầu tiên, BS sẽ tiến hành truyền lại, trong khi các dupACK khác sẽ bị hủy để ngăn chặn việc thực thi Fast-Recovery và Fast-Retransmit trong khi tầng link đang thực hiện 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 giữa FH và MH bằng cách đệm các gói TCP chưa được xác nhận (ACK) và thực hiện truyền lại cục bộ thông qua 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 bị mất và áp dụng cơ chế NACK để xử lý.
Hình 3.3 Lưu đồ Snoop xử lý nhận dữ liệu từ FH tại BS
Hình 3.4 Lưu đồ Snoop xử lý khi nhận ACK từ MH tại BS
Thí nghiệm mô phỏng đã chứng minh rằng Snoop cho phép TCP hoạt động với throughput cao hơn, dẫn đến hiệu năng cao hơn cho giao thức TCP.
Hình 3.5 Mô hình xử lý WTCP
WTCP cung cấp cơ chế trung gian cho điều khiển TCP Với WTCP, hai đầu cuối là FH và
MH không cần thay đổi giao thức, mà chỉ cần điều chỉnh ở phía máy chủ Ý tưởng chính của WTCP tương tự như Snoop, với vai trò là trung gian, WTCP sẽ lưu trữ và nhớ đệm các gói tin đang chờ xử lý.
Khi nhận gói từ FH, WTCP kiểm tra số tuần tự trong TCP header (seq_no) Nếu seq_no đúng thứ tự, WTCP tăng số byte đã nhận (pkt_size) và cập nhật seq_no mong đợi Dữ liệu nhận được được lưu vào bộ đệm và thời gian đến (arrival time) được ghi nhận Nếu seq_no lớn hơn mong đợi do mất dữ liệu, thời gian cũng được ghi nhận và dữ liệu được lưu vào bộ đệm, nhưng seq_no mong đợi không thay đổi Nếu seq_no nhỏ hơn mong đợi, gói sẽ bị bỏ qua Cơ chế xử lý này được minh họa qua lưu đồ giải thuật.
Hình 3.6 Lưu đồ WTCP xử lý khi nhận dữ liệu
WTCP hoạt động độc lập với cơ chế điều khiển luồng không dây, thực hiện việc đệm các gói song song với việc gửi đến MH Hệ thống duy trì thông tin kết nối không dây như cửa sổ truyền (transmission window), số thứ tự (sequence number) và số thứ tự của ACK cuối cùng từ MH Các gói đệm trong bộ đệm được truyền trong khoảng thời gian t_window, với mỗi gói gửi đến MH được tính lại stamptime bằng cách cộng thời gian hiện tại với thời gian mà gói đã ở trong bộ đệm (residence-time) Khi một segment được gửi, BS sẽ tính lại thời gian timeout nếu không có quá trình nào đang chờ xử lý.
Hình 3.7 Lưu đồ WTCP chuyển tiếp gói
Cơ chế timestamp và tính lại timestamp của WTCP giúp tính toán RTT một cách chính xác và loại bỏ độ trễ BS chỉ xác nhận một segment khi MH đã xác nhận segment đó Tùy thuộc vào timeout hoặc dupACKs, BS sẽ áp dụng các cơ chế truyền lại khác nhau Trong trường hợp timeout, cửa sổ phát giảm xuống còn 1 segment, khiến WTCP rơi vào trạng thái "bad state" Khi được xác nhận, WTCP sẽ trở lại trạng thái "good state" với cửa sổ phát bằng cửa sổ quảng bá ban đầu (awnd).
Hình 3.8 Lưu đồ WTCP xử lý khi nhận ACK
Mục tiêu của nhóm giải pháp này là giảm thiểu số lượng gói bị mất trong truyền thông giữa FH và MH thông qua việc truyền lại ở tầng liên kết và cơ chế đệm gói tại BS Tuy nhiên, việc thực hiện phương pháp này gặp khó khăn do tất cả các gói dữ liệu gửi và xác nhận phải đi qua cùng một BS hoặc thiết bị trung gian Đặc biệt, với Snoop và WTCP, base station cần phải biết thông tin trong TCP Header, yêu cầu mỗi TCP segment phải được đóng gói trong một frame của tầng link Điều này thường xảy ra trong WLAN nhưng không phải trong tất cả các mạng không dây Nếu khung dữ liệu tầng liên kết qua giao diện sóng radio không đủ lớn để đóng gói một segment, đặc biệt trong mạng WWAN, Snoop và WTCP sẽ không thể hoạt động hiệu quả Ngoài ra, trong trường hợp dữ liệu được mã hóa bằng các cơ chế bảo mật như Ipsec, việc đọc header của TCP tại thiết bị trung gian sẽ trở nên không khả thi.
Một điểm quan trọng của các giải thuật nhóm là cơ chế đệm gói, trong đó một segment chỉ được xóa khỏi bộ đệm khi được xác nhận Điều này dẫn đến việc nếu nhiều luồng dữ liệu cùng đi qua BS, BS sẽ cần một lượng lớn bộ nhớ để lưu trữ Tuy nhiên, các thuật toán hiện tại không có cơ chế quản lý bộ đệm hiệu quả.
Chia kết nối
Ý tưởng chính của nhóm giải thuật này là phân chia kết nối thành hai phần riêng biệt thông qua một nốt mạng trung gian Kết nối ban đầu được tách thành hai kết nối, tương tự như phương pháp hỗ trợ link layer, nhưng với sự khác biệt là các xử lý diễn ra ở tầng TCP.
Hình 3.9 Mô hình chia kết nối
I-TCP đề xuất chia kết nối từ một MH đến một thiết bị FH thành hai kết nối riêng biệt: một kết nối giữa MH và một thiết bị định tuyến hỗ trợ di động (mobile support router – MSR) thông qua kết nối không dây và kết nối còn lại giữa MSR đến FH trong mạng có dây MSR trong trường hợp này tương ứng với một BS, hay nói cách khác là BS có tích hợp MSR Việc chia kết nối giúp tách biệt hai môi trường truyền dẫn với những đặc tính khác nhau là không dây và có dây Từ đó, dễ dàng hơn cho việc giải quyết vấn đề từng kết nối một cách độc lập Ở tầng giao vận (transport), việc chia kết nối mang lại những lợi ích như:
Chức năng điều khiển luồng và điều khiển tắc nghẽn trong môi trường không dây cần được tách biệt với môi trường truyền có dây do sự khác biệt về đặc điểm giữa hai loại môi trường này Môi trường có dây, như kết nối ethernet hay ATM, cung cấp đường truyền nhanh, băng thông lớn và độ tin cậy cao, trong khi đó, môi trường không dây thường chậm hơn và dễ gặp lỗi do nhiễu tín hiệu, như fading và tỷ lệ lỗi cao.
Kết nối mạng không dây giúp xác định chính xác nguyên nhân gây ra sự kiện mất gói tin, bao gồm mất kết nối do lỗi đường truyền, di chuyển của nút mạng, và các đặc điểm khác liên quan đến kết nối không dây.
I-TCP cho phép trạm cơ sở (BS) có hỗ trợ MSR quản lý nhiều kết nối giữa thiết bị di động (MH) và trạm phát (FH) hơn BS có thể hoạt động như một proxy đại diện cho MH, thực hiện các giao thức phức tạp, từ đó đơn giản hóa các thao tác cho MH, đặc biệt khi MH chỉ là những thiết bị đơn giản.
Khi một MH muốn liên lạc với FH qua I-TCP, yêu cầu sẽ được gửi đến MSR để mở kết nối Sau khi nhận được yêu cầu thiết lập kết nối từ MH, MSR sẽ tiến hành tạo kết nối với FH tương ứng.
Hình 3.11 BS đóng vai trò như Proxy trong I-TCP
MSR hoạt động như một proxy, cho phép mở đồng thời hai kết nối qua hai socket Khi thiết bị di động (MH) di chuyển, MSR đảm nhận vai trò điều khiển quá trình chuyển giao (handoff) và truyền tải thông tin sang MSR mới.
Hình 3.12 Quá trình xử lý chuyển vùng (handoff) của I-TCP
Trong ví dụ này, MH đầu tiên kết nối với FH qua MSR-1 và di chuyển vào vùng phủ sóng của MSR-2 Khi MH yêu cầu kết nối I-TCP với FH trong vùng MSR-1, MSR-1 tạo một socket cho MH (socket MH) để quản lý kết nối.
MH và socket cho FH (MH socket) quản lý kết nối với MH Khi MH di chuyển vào vùng MSR-2, trạng thái kết nối I-TCP tại MSR-1 được chuyển sang MSR-2, nơi tạo hai socket mới với cùng tham số đã thiết lập Khi các đầu cuối đã kết nối, thành phần cố định của kết nối I-TCP (FH) không thay đổi khi FH di chuyển, do đó không cần kết nối lại với MSR mới, đảm bảo kết nối TCP hoàn toàn trong suốt với FH.
Giải pháp chia đôi kết nối của I-TCP làm mất đi ngữ nghĩa end-to-end của TCP, khiến thực thể gửi gói tin biên nhận không nhất thiết phải là thực thể nhận TCP Mặc dù hầu hết các ứng dụng như FTP có cơ chế khôi phục lỗi, I-TCP gặp khó khăn trong việc xác định liệu dữ liệu đã đến đích hay chưa, do đó không thể thực hiện chức năng khôi phục một cách hiệu quả Hơn nữa, I-TCP không cung cấp cơ chế cảnh báo cho tầng ứng dụng, dẫn đến việc các ứng dụng dựa vào I-TCP phải phụ thuộc vào MSR và kết nối giữa MSR và MH Quá trình handoff được thực hiện như sau:
1 Một tín hiệu (beacon) được nhận bởi MH từ MSR mới.
2 Tiến trình mhmicp thiết lập MSR mới thành bộ định tuyến mặc định và gửi thông điệp chào (greeting) đến MSR chứa các kết nối I-TCP hiện tại và địa chỉ của MSR cũ (MSR-1).
3 Tiến trình msrmicp ở MSR-2 gửi xác nhận cho thông điệp greeting từ MH (grack)
4 Tiến trình msrmicp (cần chọn chỗ nào thích hợp giải thích từ viết tắt này và ý nghĩa của vấn đề liên quan) tại MSR-2 gửi thông điệp “MHIn” tới I-TCP daemon cục bộ chứa danh sách của các kết nối I-TCP nhận được từ MH
5 I-TCP deamon thiết lập socket cho cả kết nối trên mạng không dây và mạng có dây và chuẩn bị yêu cầu I-TCP handoff cho MSR-1 Deamon gửi ACK đến msrmicp.
6 Msrmicp gửi một gửi con trỏ (forwarding pointer) đến MSR-1, thông báo cho MSR-1 biết MSR nào sẽ quản lý MH
7 Msrmicp tại MSR-1 xác nhận (ACK)
8 Msrmicp tại MSR-1 gửi thông điệp MHOut đến deamon của nó với địa chỉ của
MH đã di chuyển ra ngoài để thông báo MH đã di chuyển ra ngoài.
9 Khi nhận thông điệp MHOut, I-TCP deamon đóng băng tất cả các kết nối liên quan tới MH Đồng thời gửi thông điệp yêu cầu handoff đến deamon của MSR-2 để đảm bảo rằng đã sẵn sàng và gửi trạng thái của các kết nối I-TCP sang MSR-2 (MHState)
1 I-TCP deamon tại MSR-2 nhận trạng thái kết nối đồng thời khởi động lại từng kết nối Sau đó, gửi ACK cho MSR-1 thông báo hoàn tất quá trình handoff (Ack).
Hình 3.13 Các bước thực hiện trong quá trình handoff của I-TCP
Cơ chế cảnh báo tường minh EN (Explicit Nofitication)
TCP thường cho rằng mất dữ liệu trên đường truyền là do tắc nghẽn mạng, nhưng điều này không đúng với mạng không dây Để giải quyết vấn đề này, các cơ chế EN đã được phát triển nhằm giúp nguồn phát TCP nhận diện nguyên nhân thực sự của việc mất dữ liệu Ý tưởng chính là gửi thông báo trên đường truyền để thông báo cho nguồn phát về việc mất dữ liệu do lỗi trên mạng không dây.
3.3.1 ICMP Message Ý tưởng chính của phương pháp này là sử dụng gói ICMP để chuyển tải thông điệp cho biết tình trạng mất gói Tiêu chí của phương pháp:
Thông điệp ICMP giúp TCP phân biệt nguyên nhân mất gói, cho phép xác định liệu sự cố xảy ra do lỗi trên đường truyền không dây hay do nghẽn mạng trên mạng có dây Theo quy ước, mất gói trên đường truyền không dây được coi là do lỗi đường truyền, trong khi mất gói trên mạng có dây thường là do nghẽn mạng.
Thông điệp ICMP đóng vai trò quan trọng trong việc giúp giao thức TCP tránh xung đột giữa các cơ chế truyền lại của tầng liên kết và tầng chuyển vận.
Để cải thiện chức năng truyền dữ liệu, giao thức ICMP-DEFER đã được thiết kế, cho phép gửi thông điệp khi nỗ lực truyền đầu tiên trên đường truyền không dây không thành công Điều này giúp TCP nhận được ACK hoặc thông điệp ICMP trong khoảng thời gian RTT, ngăn chặn việc bắt đầu quá trình truyền lại khi tầng liên kết đang thực hiện truyền lại Nếu cả ACK và ICMP không đến đầu phát, điều này cho thấy có tình trạng tắc nghẽn, cho phép đầu phát nhận diện vấn đề Thông điệp ICMP chứa thông tin về IP và TCP, giúp xác định gói dữ liệu bị mất, và việc không truyền lại ICMP cùng với lượng tiêu đề thấp là những ưu điểm của phương pháp này.
Khi nhận thông điệp ICMP-DEFER, TCP tạm ngưng bộ định thời phát lại gói để tránh xung đột với tầng liên kết Nếu segment cần truyền lại đã nhận ICMP-DEFER, việc truyền lại vẫn diễn ra mà không giảm cwnd Sau vài lần truyền lại không thành công ở tầng liên kết, BS sẽ gửi thông điệp ICMP-RETRANSMISSION cho TCP để thực hiện truyền lại đầu cuối – đầu cuối.
Thông điệp ICMP mới bao gồm ICMP-DEFER và ICMP-RETRANSMISSION, có thể gây khó khăn cho các đầu cuối trong việc hiểu Khi gặp phải tình huống này, các thông điệp ICMP sẽ bị bỏ qua và quá trình truyền dữ liệu sẽ diễn ra theo phương thức truyền thống của TCP.
3.3.2 Phương pháp thông báo mất dữ liệu tường minh ELN (Explicit Loss
Phương pháp này áp dụng khi MH là nguồn phát, trong đó BS gửi một ELN cho MH nếu dữ liệu bị mất trong quá trình truyền không dây BS sẽ kiểm tra tiêu đề TCP và lưu lại số thứ tự tuần tự Một khoảng trống trong dãy số thứ tự sẽ được đánh dấu để chỉ ra rằng dữ liệu đã bị mất từ MH đến BS Khi xảy ra mất gói, FH sẽ gửi các dupACKs về cho MH như thường lệ.
BS, BS bật cờ ELN và chuyển tiếp các dupACKs này về MH MH truyền lại các gói có ELN mà không giảm cửa sổ tắc nghẽn
Phương pháp đếm syndrome, được phát triển từ phương pháp ELN, cho phép bác sĩ (BS) theo dõi số lượng gói tin mà họ chuyển tiếp qua từng kết nối Mỗi gói tin sẽ có giá trị bộ đếm được thêm vào tiêu đề TCP như một phần mở rộng Syndrome được xác định bởi cặp giá trị (số thứ tự, giá trị đếm của BS), từ đó có thể suy ra nguyên nhân gây mất gói Sự xuất hiện của khoảng trống trong chuỗi số thứ tự hoặc giá trị đếm cho thấy có sự mất mát dữ liệu Để hỗ trợ việc phát hiện mất gói, syndrome định nghĩa khái niệm khoảng trống G.
G được tính với từng gói Gọi:
• seq_num: số tuần tự segment
• max_seq_seen : seq_num lớn nhất được ghi nhận
• n: khoảng các giữa hai segment dữ liệu nhận được liên tục Nếu n = 0, không có gói nào bị mất ở khoảng giữa các gói vừa nhận được.
Cặp giá trị (Gn, Gm) cho biết tình trạng mất gói và nguyên nhân gây ra Trong đó, Gn đại diện cho sequence number và Gm là bộ đếm của BS Có ba trường hợp có thể xảy ra liên quan đến việc mất gói.
• (G0, G0): không xảy ra mất gói
• (Gm, Gm): có m gói bị mất và tất cả mất trên đường không dây
• (Gn, Gm) với n>m>=0 : có n gói bị mất, trong đó có m gói mất trên đường truyền không dây.
Trong trường hợp có mất gói do đường truyền không dây, ELN được sử dụng bởi đầu thu để báo hiệu cho đầu phát.
3.3.4 Phương pháp ACK thành phần (partial ACK)
Phương pháp này đề xuất sử dụng hai loại ACK khác nhau: ACK xác nhận đầu cuối – đầu cuối (complete ACK – Ac) và ACK dành cho đầu phát – BS (partial ACK – Ap) Giải thuật này phân chia kết nối end-to-end thành hai chặng về mặt logic.
Hình 3.14 Mô hình xử lý ACK thành phần
Ac hoạt động như ACK bình thường được sử dụng trong các phiên bản TCP truyền thống
AP được sử dụng bởi BS để gửi tín hiệu đến FH Nếu không có mất dữ liệu trong quá trình truyền tải, nguồn phát sẽ nhận được hai loại ACK: Ap từ BS và Ac từ MH Trong trường hợp chỉ có Ap được gửi đến FH, FH sẽ xác nhận tình trạng mất gói dữ liệu trên đường truyền không dây Nếu không nhận được ACK, điều này có thể chỉ ra vấn đề trong quá trình truyền.
FH xác nhận mất gói do tắc nghẽn.
Phương pháp cảnh báo tường minh khác biệt với các phương pháp khác bởi sự phối hợp xử lý giữa đầu phát và đầu thu dựa trên thông tin đường truyền Đầu phát có nhiệm vụ phân biệt loại tắc nghẽn dựa trên dữ liệu từ đầu thu, mang lại ưu điểm là thuật giải đơn giản và độc lập với cơ chế điều khiển TCP Hướng tiếp cận này cũng hiệu quả trong việc phân loại mất gói Tuy nhiên, nó vẫn gặp phải những hạn chế khiến không thật sự khả thi.
Thông điệp thông báo về việc mất gói tin có thể được gửi kèm theo các gói dữ liệu hoặc qua giao thức ICMP Tuy nhiên, trong môi trường không dây với độ tin cậy thấp, phương pháp này không hiệu quả do khả năng mất gói tín hiệu hoặc ICMP.
• EN đòi hỏi BS phải có khả năng hoạt động ở tầng transport (ngoại trừ ICMP)
• Trong trường hợp sử dụng giao thức bảo mật IpSec, EN không thể hoạt động
Phương pháp End to End
Hướng tiếp cận cải tiến giao thức TCP giữ nguyên tính chất end-to-end, khác với các phương pháp yêu cầu xử lý ngoài hoặc thiết bị trung gian hỗ trợ Giải pháp này giúp TCP hoạt động hiệu quả hơn trong môi trường không dây mà không làm mất đi thuộc tính quan trọng của nó.
Freeze TCP hỗ trợ khả năng di động và tình trạng mất sóng tạm thời cho thiết bị di động trong quá trình truyền dữ liệu TCP Ý tưởng chính của Freeze TCP là tạm thời "đóng băng" kết nối khi tín hiệu bị gián đoạn, giúp duy trì tính liên tục trong việc truyền tải dữ liệu.
Freeze TCP không yêu cầu sự hỗ trợ từ thiết bị trung gian, mà cần sự phối hợp chặt chẽ giữa hai đầu cuối trong quá trình truyền tải Khi tín hiệu không tốt, hệ thống sẽ tạm dừng cho đến khi tín hiệu trở lại tốt, sau đó tiếp tục truyền dữ liệu.
Freeze yêu cầu đầu thu (MH) phát hiện và dự đoán khả năng mất kết nối, đồng thời gửi tín hiệu cảnh báo đến đầu phát Khi có nguy cơ mất kết nối, đầu thu sẽ gửi ít nhất một gói ACK kèm theo thông tin cửa sổ quảng bá bằng không, gọi là ZWA (zero window advertisement) Tín hiệu này khiến đầu phát "đóng băng" và chuyển sang trạng thái "thăm dò cửa đóng" (Zero Window Probe - ZWP) Trong giai đoạn này, kích thước cửa sổ cwnd không bị giảm, và các gói thăm dò sẽ được gửi đi cho đến khi nhận được tín hiệu phản hồi từ đầu thu.
Nếu mất kết nối quá lâu, quá trình backoff sẽ kéo dài thời gian tái kết nối Khi đầu thu nhận tín hiệu thăm dò từ đầu phát, nó phải chờ tín hiệu tiếp theo để tái kết nối Để giải quyết vấn đề này, một bản sao của ACK cuối cùng được gửi dưới dạng 3-dupACKs ngay sau khi đầu thu tái kết nối, nhằm kích hoạt kết nối ở đầu phát (Triplicate reconnection ACK - “TR-ACKs”).
Freeze TCP cung cấp giải pháp khắc phục tình trạng mất kết nối tạm thời trong môi trường không dây, nhưng hiệu quả của nó phụ thuộc vào khả năng phát tín hiệu cảnh báo đúng lúc của đầu phát Nếu tín hiệu được phát quá sớm, sẽ gây ra tình trạng rỗi không cần thiết; ngược lại, nếu quá muộn, sẽ dẫn đến việc giảm cwnd ở đầu phát Trạng thái lý tưởng là phát tín hiệu kịp thời trong khoảng thời gian một RTT.
Hình 3.15 Qui trình xử lý freeze TCP
3.4.2 TCP-Westwood Được phát triển trên nền TCP-Reno, TCP Westwood (TCPW) tăng cường xử lý cho TCP dựa trên sự thăm dò băng thông đường truyền để có phương pháp ứng xử hợp lý Khác với các phiên bản khác của TCP như TCP Tahoe, Reno, hay SACK, chỉ đơn thuần giảm cwnd một cách máy móc TCP Westwood đo lường băng thông thông qua tần số ACK và qua hàm lọc thông thấp (low-pass filter) Hàm lọc thông thấp cho phép việc đo lường tránh được những biến đổi đột ngột đồng thời cho phép có cái nhìn về xu hướng hiện tại của mạng (do tổng hợp từ dữ liệu trong hiện tại và quá khứ) Từ kết quả về đo luờng băng thông, TCP Westwood đưa ra quyết định về lượng cwnd cần thiết cho điều khiển tắc nghẽn.
TCP Westwood giữ nguyên phương thức xử lý tương tự như các phiên bản TCP cho mạng có dây, bắt đầu với Slow-start, thực hiện Congestion avoidance khi cwnd vượt quá ssthresh, và áp dụng Fast-Recovery / Fast-Retransmit khi xảy ra mất dữ liệu Điểm nổi bật của TCP Westwood là cơ chế xử lý mất gói, cho phép nó hoạt động linh hoạt hơn và phù hợp hơn với tình trạng mạng hiện tại thông qua việc đo lường băng thông.
Cơ chế quan trọng nhất trong cải tiến TCP WestWood là khả năng đo lường băng thông thông qua các ACK phản hồi mà không cần sự hỗ trợ phức tạp từ đầu thu hoặc các thiết bị trung gian.
Lượng băng thông, được tính từ thời điểm nhận ACK hiện tại trở về lần nhận ACK trước đó, được gọi là băng thông mẫu (sample_BWE - sample bandwidth estimate).
• acked: số lượng segment được xác nhận trong khoảng thời gian từ lần ack trước đến ack hiện tại
• pkt_size: kích thước một segment tính theo byte
• now: thời điểm hiện tại (s)
• last_ack_time: thời điểm ACK lần trước
• sample_BWE: băng thông lấy mẫu (bit/s)
Một hàm lọc thông thấp dùng để ước lượng băng thông được tính:
• BWE: lượng băng thông ước lượng
• k và k-1 dùng cho chỉ định giá trị hiện tại và giá trị lần tính trước đó
Như vậy BWE sẽ được dùng như một giá trị tham chiếu cho lượng băng thông hiện tại TCPW điều khiển tốc cửa sổ tắc nghẽn cwnd theo BWE
Trong đó, RTTmin là khoảng thời gian RTT tối thiểu đo tính bởi nguồn phát Cửa số phát được tính như thông thường:
Vấn đề khó khăn ở công thức trên là khi tính trong trường hợp có dupACKs, ACK tích lũy (Cumulative ACK - CACK) và delayed ACK.
• Với dupACKs, dupACKs cũng được dùng để tính băng thông và được xem như có một gói dữ liệu
• Với CACK, cũng chỉ được xem như có 1 gói dữ liệu (gói được truyền lại thành công)
Delayed ACK là cơ chế mà nguồn phát gửi lại gói ACK sau khi nhận được gói dữ liệu hoặc sau 200ms Thay vào đó, nguồn phát sẽ gửi ACK sau mỗi k segment dữ liệu nhận được Khi delayed ACK và CACK hoạt động cùng nhau, điều này có thể gây nhầm lẫn trong quá trình xử lý.
Giải thuật thường được dùng để tính lượng segment được xác nhận như sau:
Hình 3.16 Lưu đồ giải thuật TCPW tính số lượng segment được xác nhận
• Accounted_for: số lần xảy ra dupACKs, cũng là số lượng dupACKs Accounted_for dùng để lưu vết xác dupACKs, dùng cho phân biệt CACK và delayed ACK
• Cumul_ACK cho biết lượng segmenty được xác nhận (CACK) kiểu tích lũy (CACK).
• Kết quả trả về là số lượng segment được xác nhận tính từ lần xác nhận trước.
Khi phát hiện mất gói, TCPW có các xử lý khác nhau trong hai trường hợp dupACKs và timeout.
Hình 3.17 Lưu đồ giải thuật TCPW xử lý N dupACKs tổng quát
Khi nhận được n-dupACKs, TCPW sẽ phân loại thành hai tình huống: đang thực hiện Slow-Start và đang thực hiện Congestion avoidance Hai hàm tùy chọn f1 và f2 được áp dụng cho từng trường hợp Trong thực tế, hàm f1 thường được sử dụng.
Trong đó tham số a được tăng dần trong khoảng 1 đến 4, mỗi bước nhảy là 0.25 cho mỗi lần thực thi f2, và trả về 1 nếu không thực thi.
Hình 3.18 Lưu đồ giải thuật TCPW xử lý 3- dupACKs thực nghiệm
Trong giai đoạn Slow Start, TCP thăm dò băng thông mạng thông qua việc theo dõi số lần nhận dupACKs Sự gia tăng số lượng dupACKs sai cho thấy ước lượng băng thông không chính xác, dẫn đến việc tăng dần lượng a để hạ thấp ước lượng băng thông Tuy nhiên, trong quá trình Congestion Avoidance (CA), việc điều chỉnh này không cần thiết vì giá trị ssthresh đã được xác định chính xác.
Hình 3.19 Lưu đồ giải thuật TCPW xử lý timeout tổng quát
Các hàm f3, f4, f5, f6 cũng là những hàm tùy chọn Trong thực tế, các hàm được chọn:
Tham số a trong f5 được tính giống như f2, tuy nhiên, bước nhảy của a là 1 thay vì 0.25:
Hình 3.20 Lưu đồ giải thuật TCPW xử lý timeout thực nghiệm
TCPW cải thiện hiệu suất trong môi trường không dây bằng cách ước lượng băng thông liên tục và điều chỉnh quá trình phát gói mà không giảm đột ngột cwnd khi nhận được 3 dupACKs Cơ chế điều khiển phục hồi nhanh hơn giúp TCPW hoạt động hiệu quả hơn so với các thuật toán truyền thống, đặc biệt khi xảy ra mất gói do lỗi đường truyền, bởi vì nó chỉ điều chỉnh cwnd dựa trên băng thông ước lượng hiện tại Đây là một ưu điểm nổi bật của TCPW trong các tình huống không dây.
Bảng 3-1 Bảng thống kê so sánh các phương pháp
Snoop WTCP I-TCP ICMP ELN Syndrome Westwood Freeze TCP Đòi hỏi thiết bị trung gian hoạt động được ở lớp
Hoạt động với cơ chế bảo mật
Cần xử lý ở BS BS BS + endpoints Endpoints
End-to-end có không Không Không Có
Xử lý handoff không Có Không Có
Xử lý lỗi cao Có Có Có Hạn chế Có Không