Luận văn Khảo sát mạng lan với các phần mở rộng không dây

thái kết nối khi MH di chuyển giữa các Cell. Vì vậy với mỗi kết nối TCP, trên SH sẽ luôn có 2 tiến trình chạy song song để quản lý đó là SH-TCP và M-TCP. SH-TCP nhận dữ liệu từ FH và khởi động tiến trình M-TCP để chuyển tiếp đến MH. Khác với I-TCP, SH-TCP không tạo ACK để gửi trả về FH mà chỉ nhận ACK từ MH. Tuy nhiên, để đề phòng FH không khởi động cơ chế chống tắc nghẽn khi chưa nhận được ACK phản hồi (có thể do MH bị disconnected tạm thời hoặc chưa nhận được dữ liệu), M-TCP điều khiển SH gửi gói tin "giả" với giá trị trường cửa sổ nhận 0 nhằm chuyển FH sang chế độ "đóng băng" -52- (Persist mode). Sau khi MH đã biên nhận và gửi ACK cho SH, SH gửi ACK này đến FH với giá trị trường cửa sổ nhận bằng giá trị như trước lúc FH chuyển sang chế độ "đóng băng". M-TCP nhận các gói tin ACK từ MH và truyền nó tới SH-TCP để chuyển tới FH. Kết nối M-TCP giữa SH và MH có một điểm khác biệt với TCP chuẩn đó là bổ sung thêm tính năng thông báo trạng thái kết nối theo từng thời điểm của MH với SH đang như thế nào (connecting/connected/disconnected). Nếu MH tạm thời mất kết nối (disconnected), M-TCP thông báo điều này cho SH- TCP để SH-TCP gửi gói tin "giả" như đã nói ở trên. Khi MH kết nối lại thành công (reconnected), M-TCP thông báo cho SH-TCP để SH-TCP cập nhật lại kích thước cửa sổ nhận rồi gửi tới FH. Mọi kết nối trở lại bình thường như lúc ban đầu. Như vậy, giao thứ M-TCP sẽ ổn định được thông lượng khi MH tạm thời bị mất kết nối và không cần chuyển giao khi MH di chuyển từ cell này sang cell khác. Tuy nhiên, giải pháp này chỉ phù hợp với các mạng không dây quy mô lớn nhiều cell và cấu trúc riêng biệt đòi hỏi khả năng xử lý trên SH rất lớn. -53- CHƯƠNG 4 ĐÁNH GIÁ BẰNG MÔ PHỎNG HIỆU SUẤT CỦA CÁC GIAO THỨC GIAO VẬN TRONG MẠNG CÓ PHẦN MỞ RỘNG KHÔNG DÂY Nói chung, hiệu suất là một trong hai nhân tố chính xác định năng suất tổng cộng của một hệ thống, phản ánh khả năng khai thác tài nguyên của hệ thống. Đối với một hệ thống tính toán, đánh giá hiệu suất (performance evaluation) là xác định về mặt định tính và định lượng chất lượng phục vụ của hệ thống tính toán đó với một loại bài toán nhất định. Đối với giao thức, đánh giá hiệu suất là xác định về mặt định tính và định lượng chất lượng truyền tải đối với một lưu lượng số liệu nhất định. Hiệu suất mạng chủ yếu được xác định bởi các nhân tố: tính sẵn sàng để dùng (availability), thông lượng (throughput), thời gian đáp ứng (response time), thời gian trễ (delay), độ tin cậy (reliability), tỉ suất lỗi (error rate) và hiệu suất của ứng dụng. Tùy thuộc vào từng loại hệ thống và mục đích sử dụng mà người ta có thể sử dụng các độ đo trên hoặc là sự kết hợp của một vài trong số đó. Người ta thường phân chia độ đo hiệu suất làm hai loại, đó là: Độ đo hướng đến người sử dụng và độ đo hướng tới hệ thống. [2] Các độ đo hướng tới người sử dụng: - Response time: Là khoảng thời gian từ khi có một yêu cầu (request) đến hệ thống cho đến khi nó được hệ thống thực hiện xong; thường được sử dụng trong các hệ thời gian thực hoặc các môi trường hệ thống tương tác. - System reaction time: Là khoảng thời gian tính từ khi input đến hệ thống cho đến khi yêu cầu chứa trong input đó nhận được khe thời gian (slice time) phục vụ đầu tiên; thường được sử dụng trong các hệ thống tương tác, thay cho response time. Độ đo này đo mức độ hiệu dụng của bộ lập lịch của hệ thống trong việc nhanh chóng cung cấp dịch vụ cho một yêu cầu mới đến. Trong mạng máy tính, các đại lượng trên đều được xem là các biến ngẫu nhiên, vì vậy người ta thường nói về phân bố, kỳ vọng, phương sai... của chúng. Các độ đo hướng tới hệ thống: - Throughput: Là số đơn vị thông tin tính trung bình được vận chuyển qua mạng trong một đơn vị thời gian. Đơn vị thông tin ở đây có thể là bit, byte hay gói số liệu,... Nếu các đơn vị thông tin đi vào mạng theo một cơ chế độc lập với trạng thái của mạng thì thông lượng cũng chính bằng tốc độ đến trung bình nếu -54- mạng vẫn còn có khả năng vận chuyển. Một số trường hợp người ta sử dụng đại lượng không thứ nguyên Hệ số sử dụng đường truyền (Line Utilization) hay còn gọi thông lượng chuẩn hoá, đó là tỉ số của thông lượng trên năng lực vận chuyển của đường truyền (line capacity).[2] - Transfer delay: Là thời gian trung bình để vận chuyển một gói số liệu qua mạng, từ nguồn tới đích. Người ta cũng có thể dùng thời gian trễ chuẩn hóa, là tỉ số của thời gian trễ trên một tham số thời gian nào đó, thí dụ như thời gian cần thiết để truyền một gói tin lên đường truyền (packet transmission time). - Tỉ lệ lỗi truyền số liệu: Là số lượng số gói tin bị lỗi trên tổng số gói tin được đưa lên đường truyền. - Thời gian xử lý, khắc phục lỗi,… Các phương pháp đánh giá hiệu suất của hệ thống mạng Có nhiều phương pháp đánh giá hiệu suất mạng máy tính, mỗi phương pháp có các thế mạnh riêng phụ thuộc vào mục tiêu nghiên cứu cụ thể, điều kiện và khả năng của người sử dụng. Người ta chia các phương pháp đánh giá hiệu suất mạng làm ba loại [3]: mô hình Giải tích (Analytic Models), mô hình Mô phỏng (Simulation Models) và Phương pháp Đo (Measurement). Trong đó, phương pháp mô hình Mô phỏng có nhiều ưu điểm vượt trội so với hai phương pháp còn lại, đó là chi phí thấp, nhanh chóng và chính xác. Phương pháp mô hình Giải tích bảo đảm hiệu quả, dễ thay đổi với chi phí thấp. Tuy nhiên, phải cụ thể hóa các mối quan hệ trên mạng thông qua các hàm số với nhiều tham số rồi giải, việc này đòi hỏi khả năng Toán học tốt. Phương pháp Đo trên mạng thực cho kết quả chính xác nhưng thường có chi phí cao về thiết bị, thời gian và khó có khả năng thực hiện hơn vì vấn đề sở hữu đối với hệ thống mạng muốn đo. 4.1. Giới thiệu bộ mô phỏng mạng NS-2 NS (Network Simulator) là một phần mềm mô phỏng mạng, được Bộ Quốc phòng Mỹ phát triển từ bộ mô phỏng REAL (Realistic and Large) của S.Keshav năm 1989. Các phiên bản 2.xx của NS ra đời sau năm 1997, từ đó người ta thường gọi là bộ mô phỏng NS-2. Bộ mô phỏng được vận hành theo cơ chế sử dụng các sự kiện rời rạc, có thứ tự. Người sử dụng có thể thay đổi cấu hình và mở rộng mô hình mạng rất dễ dàng bằng cách lập trình thêm vào một số modul chương trình. -55- NS là bộ mô phỏng hướng sự kiện viết bằng C++, với một trình thông dịch OTCL giao tiếp với người sử dụng. Những đối tượng được biên dịch này sẽ được kết nối tới bộ thông dịch OTCL qua trình liên kết OTCL. Các đối tượng OTCL tương ứng với mỗi đối tượng trong C++ và ngược lại các hàm và biến trong đối tượng C++ chuyển thành các hàm và biến trong đối tượng OTCL tương ứng. Hình 4.1: Sự kết hợp giữa C++ và OTCL trong NS NS có thể mô phỏng các mạng LAN, mạng không dây, mạng hỗn hợp (có dây và không dây), mạng vệ tinh. NS thực thi các giao thức mạng như TCP, UDP; các nguồn sinh lưu lượng của các ứng dụng như FTP, Telnet, Web, với tốc độ bit cố định (CBR) và Tốc độ bit thay đổi (VBR); các kỹ thuật quản lý hàng đợi như Vào trước Ra trước (FIFO / Drop Tail), loại bỏ sớm ngẫu nhiên (RED) và phục vụ theo mức ưu tiên dựa trên việc phân lớp - CBQ; các thuật toán định tuyến như Dijkstra… NS cũng thực thi phương thức đánh địa chỉ multicasting và vài giao thức lớp Điều khiển truy cập đường truyền (MAC) đối với mô phỏng LAN. Hình 4.2: Tổng quan về NS dưới góc độ người dùng − OTcl Script Kịch bản OTcl − Simulation Program Chương trình Mô phòng − OTcl Bộ biên dịch Tcl mở rộng hướng đối tượng − NS Simulation Library Thư viện Mô phỏng NS -56- − Event Scheduler Objects Các đối tượng Bộ lập lịch Sự kiện − Network Component Objects Các đối tượng Thành phần Mạng − Network Setup Helping Modules Các mô đun Trợ giúp Thiết lập Mạng − Plumbling Modules Các mô đun Plumbling − Simulation Results Các kết quả Mô phỏng − Analysis Phân tích − NAM Network Animator Minh họa Mạng NAM Trong hình trên, NS là Bộ biên dịch Tcl mở rộng hướng đối tượng; bao gồm các đối tượng Bộ lập lịch Sự kiện, các đối tượng Thành phần Mạng và các mô đun Trợ giúp thiết lập mạng (hay các mô đun Plumbing). Để sử dụng NS-2, người sử dụng lập trình bằng ngôn ngữ kịch bản OTcl. Người sử dụng có thể thêm các mã nguồn Otcl vào NS-2 bằng cách viết các lớp đối tượng mới trong OTcl. Những lớp này khi đó sẽ được biên dịch cùng với mã nguồn gốc. Kịch bản OTcl có thể thực hiện những việc sau: o Khởi tạo Bộ lập lịch Sự kiện o Thiết lập Mô hình mạng dùng các đối tượng Thành phần Mạng o Báo cho nguồn traffic khi nào bắt đầu truyền và ngưng truyền packet trong Bộ lập lịch Sự kiện Thành phần lớn khác của NS bên cạnh các đối tượng Thành phần Mạng là Bộ lập lịch Sự kiện. Bộ lập lịch Sự kiện trong NS-2 thực hiện những việc sau: o Tổ chức bộ định thời Mô phỏng o Huỷ các sự kiện trong hàng đợi sự kiện o Triệu gọi các thành phần mạng trong mô phỏng Phụ thuộc vào mục đích của người sử dụng đối với kịch bản mô phỏng OTcl mà kết quả mô phỏng có thể được kết xuất ra tệp vết các sự kiện (trace file). Tệp vết sẽ được các ứng dụng khác đọc và sử dụng để thực hiện phân tích: o File nam trace (file.nam) được dùng cho công cụ quan sát hoạt động của mạng bằng đồ họa NAM. o File Trace (file.tr) được dùng cho người nghiên cứu phân tích và kết xuất kết quả bằng các công cụ khác nhau, thí dụ bằng chương trình Perl, Awk, C++ ... -57- Hình 4.3: Luồng các sự kiện mô phỏng được kết xuất ra file − NAM Visual Simulation Mô phỏng ảo NAM − Tracing and Monitoring Simulation Mô phỏng Lần vết và Giám sát 4.1.1. Mô phỏng mạng LAN Trong NS2, cấu hình OTcl và giao diện cho LanNode (là một nút đặc biệt để mô phỏng đường truyền chung trong mạng Ethernet) có trong các file tcl/lan/vlan.tcl, tcl/lan/ns-ll.tcl và tcl/lan/ns-mac.tcl trong thư mục NS chính: 4.1.1.1. Cấu hình Tcl Trong giao diện cho việc tạo và cấu hình một mạng LAN thì ở mức trên cùng, lớp OTcl “Simulator” đưa ra một phương thức mới gọi là make-lan. Tham số của phương thức này chỉ nhận một danh sách các nút như là một tham số đơn (trong duplex-link thì hai tham số): Simulator instproc make-lan {nodes bw delay lltype ifqtype mactype chantype} Những tham số tùy chọn trong make-lan xác định kiểu của các đối tượng được tạo ra cho lớp liên kết (LL), giao diện hàng đợi, lớp MAC và lớp vật lý (Channel). Tạo một mạng LAN với lớp liên kết, hàng đợi drop-tail và CSMA/CD MAC như sau: $ns make-lan “$n1 $n2” $bw $delay LL Queue/DropTail Mac/Csma/Cd 4.1.1.2. Các thành phần của một mạng LAN LanLink nắm giữ chức năng của ba lớp thấp nhất trong chồng giao thức mạng: • Lớp liên kết (Link layer-LL) -58- • Lớp điều khiển truy cập đường truyền (MAC) • Lớp vật lý (PHY) Hình 4.4: Minh họa ngăn xếp mạng dùng cho LAN Ngăn xếp mạng (network stack) làm cho việc mô phỏng mạng LAN có thể thực hiện được trong NS. Một gói được gửi xuống các luồng ngăn xếp qua các lớp liên kết (Queue và LL), lớp MAC (Mac) và lớp vật lý (Channel tới Classifier/Mac). Sau đó gói đi lên ngăn xếp qua lớp MAC và LL. Ở phía dưới của ngăn xếp, lớp vật lý bao gồm hai đối tượng mô phỏng: Channel và Classifier/Mac. Đối tượng Channel mô phỏng đường truyền dùng chung và hỗ trợ kỹ thuật truy cập đường truyền của đối tượng MAC ở phía gửi khi truyền thông. Ở phía nhận, Classifier/Mac có nhiệm vụ phân phối và trả lời các gói (nếu cần) cho đối tượng nhận MAC. Tùy thuộc vào kiểu lớp vật lý, lớp MAC cần phải chứa một tập các chức năng như: cảm nhận sóng mang (carrier sense), phát hiện xung đột (collision detection), tránh xung đột (collision avoidance)… Vì những chức năng này ảnh hưởng đến cả hai phía gửi và nhận nên chúng được thực thi trong một đối tượng Mac đơn. Để gửi, đối tượng Mac phải tạo ra một giao thức truy cập đường truyền trước khi truyền một gói lên kênh truyền. Để nhận, lớp MAC có nhiệm vụ phân phối gói về cho lớp liên kết. Ở trên lớp MAC, lớp liên kết có hai thành phần: Queue và LL (link-layer). Đối -59- tượng Queue, mô phỏng giao diện hàng đợi, phụ thuộc vào lớp Queue, đối tượng LL thực thi một giao thức liên kết dữ liệu. 4.1.1.3. Định tuyến LANs và NS Khi một mạng LAN được tạo ra bằng cách sử dụng make-lan hay newLan thì một nút LAN ảo (“virtual LAN node”) LanNode được tạo. LanNode giữ tất cả các đối tượng được chia sẻ trên LAN: Channel, Classifier/Mac và LanRouter. Sau đó, với mỗi nút trên LAN thì một đối tượng LanIface sẽ được tạo ra. LanIface gồm tất cả các đối tượng cần thiết cho mỗi nút cơ bản: một Queue, một lớp liên kết (LL), Mac, một ID nhận được từ không gian Node ID. Nếu việc định tuyến kế thừa được sử dụng, LanNode phải được chỉ định một địa chỉ kế thừa giống như những nút khác. Theo cách nhìn của việc định tuyến NS (tĩnh) thì LanNode chỉ là một nút kết nối trực tiếp tới mọi nút trên LAN. Những liên kết kết nối LanNode với các nút trên LAN có thể là liên kết ảo (Vlink). Chi phí định tuyến mặc định của một liên kết là ½ do đó chi phí đi qua hai Vlink (ví dụ n1 -> LAN -> n2) được đếm như chỉ là một trạm. Hình 4.5: Thực tế kết nối và thể hiện định tuyến trên NS2 Vlink không gây ra bất kỳ sự trễ nào trên các gói và chỉ đáp ứng cho một mục đích là cài đặt giao diện LAN thay vì những liên kết thông thường ở bộ phân loại của các node. 4.1.2 Mô phỏng WLAN Để mô phỏng mạng WLAN, ngoài các đối tượng như trong mô phỏng LAN (ở phần trên), NS thêm đối tượng nsNode cơ sở cùng với các chức năng như di chuyển, khả năng truyền và nhận trên một kênh cho phép tạo môi trường mobile, môi trường mô phỏng wireless. WLAN sử dụng lớp MobileNode với các đặc tính hỗ trợ thêm vào cho phép mô phỏng mạng multi-hop với thủ tục ad- -60- hoc, mạng WLAN, … MobileNode là một đối tượng tách biệt bao gồm các tính năng mobile như: di chuyển, cập nhập vị trí định kỳ, duy trì đường biên của topo,… Chúng được thực thi trong C++ trong quá trình dò tìm các thành phần của mạng bên trong của MobileNode (như các phân lớp, LL, Mac, Channel,…). Node mobile có khả năng nhận và truyền các tín hiệu đến hoặc từ một kênh wireless. Do bản chất của mô phỏng giữa mạng WLAN và LAN là tương đồng nhau, NS2 thay đổi một số yếu tố của các thành phần dùng cho mô phỏng LAN để phù hợp với WLAN như: Định tuyến, thêm mô hình lỗi vào đường truyền dành cho truyền dẫn không dây, thay đổi tọa độ. NS hỗ trợ mô phỏng cả 2 loại WLAN đó là Ad-Hoc và Infrastructure-based. Một số khác biệt so với mô phỏng LAN như sau: 4.1.2.1. Định tuyến trong mô phỏng WLAN kiểu Ad-hoc Định tuyến: Hiện NS2 (phiên bản ns-2.30) hỗ trợ bốn giao thức định tuyến Ad-hoc đó là: DSDV, DSR, TORA, và AODV. DSDV Trong giao thức định tuyến này, meassage được chuyển đổi giữa các nút (mobilenode) lân cận, chúng thường xuyên cập nhật thông tin định tuyến khi có một trong những nút lân cận thay đổi bảng định tuyến. Một gói tin được gửi theo tuyến đến đích của nó không biết được nó đã được lưu tạm trong buffer trước khi nó được gửi đến node tiếp theo. Do vậy, tại các node, bộ nhớ đệm (buffer) phải có kích thước đủ lớn để lưu các gói tin cho đến khi nút đó nhận được hồi đáp route-replies của đích (định tuyến đã hoàn tất), gói tin lưu tạm đó sẽ bị hủy. Tất cả các gói tin di chuyển qua mobilenode được định tuyến trực tiếp bằng địa chỉ dmux của nút nguồn đến cổng dmux của nút đích, cổng dmux sẽ điều khiển các gói tin đến các agent đích tương ứng. Cổng 225 được gắn kèm với định tuyến agent trong mobilenodes, các mobilenodes cũng sử dụng đích mặc định (default-target) trong phân lớp của nó. Trong trường hợp đích của gói tin không tìm thấy trong phân lớp (có thể ngẫu nhiên xảy ra khi đích không phải là mobilenode), gói tin đó sẽ được dùng để chỉ ra đích mặc định trong định tuyến agent, định tuyến agent gán địa chỉ hop kế tiếp vào gói tin (xem hop đó là đích đến) và gửi nó xuống lớp link. [16] -61- Giao thức định tuyến này chủ yếu được thực thi trong C++. Tham khảo chi tiết vấn đề thực thi giao thức DSDV đối với mạng Ad-hoc trong ~ns/dsdv và ~ns/tcl/mobility/dsdv.tcl DSR DSR là giao thức định tuyến động, khác với DSDV sử dụng mobilenode thì DSR sử dụng SRNode cho việc định tuyến. Điểm vào của SRNode (The SRNode’s entry_ points) chỉ đến quá trình định tuyến agent của DSR, vì vậy tất cả các gói tin đã nhận được bởi node buộc phải truyền với định tuyến agent. Mô hình này cần thiết cho thông tin định tuyến sau này (trong tương lai) trên các gói tin data, ngược lại sẽ không qua quá trình định tuyến agent. Agent DSR kiểm tra dữ liệu gói tin để lấy thông tin định tuyến rồi chuyển tiếp (forward) gói tin dựa trên thông tin định tuyến vừa tìm được. Trong trường hợp nó không tìm thông tin định tuyến trong gói tin thì nó sẽ cung cấp tuyến đường trước đó (nếu nó xác định được) hoặc chỉ lưu trữ gói tin đó để chờ các phản ứng tiếp theo và gửi truy vấn để tìm đường đến đích (nếu nó chưa xác định được) mà không yêu cầu phải biết đích. Tóm lại, quá trình định tuyến DRS luôn dựa vào dữ liệu của gói tin tại nút đó mà không cần biết đích đến của gói tin, sau đó nút này sẽ gửi broadcast đến tất cả các nút lân cận của nó và tìm định tuyến đến đích dựa trên các phúc đáp Route-reply từ các nút trong mạng. Xem chi tiết phương thức định tuyến DSR ở thư mục ~ns/dsr và ~ns/tcl/mobility/dsr. TORA Tora là giao thức định tuyến phân cấp dựa trên thuật toán “link reversal” (liên kết ngược). Tại mỗi nút một bản sao tách biệt của TORA được sử dụng cho mỗi đích. Khi một nút cần được định tuyến để truyền gói tin đến một đích, nó gửi broadcast thông điệp QUERY có chứa địa chỉ đích. Gói này di chuyển qua mạng cho tới khi tìm được đích hay nút trung gian mà từ đó có thể đến nút đích. Sau đó nút này sẽ gửi broadcast gói tin UPDATE để cập nhật đường đi đến đích của nó trên bảng định tuyến của các nút còn lại. Khi nhận được thông tin của nút này, các nút còn lại sẽ cập nhập giá trị cao hơn giá trị của lân cận (neighbour) từ giá trị mà nó nhận được trong UPDATE. Điều này có nghĩa là đường đi từ một nút nguồn được xây dựng bằng cách tăng dần "bước đi" (từ nút nguồn đó đến nút lân cận tiếp theo), đồng thời từ phía đích sẽ "lùi" một bước (từ nút đích về lân cận của đích). Như vậy, việc định tuyến này được xây dựng từ "vết bước đi" -62- của nút nguồn và "vết lùi về" của nút đích và kết quả của quá trình này là một chuỗi các link trực tiếp xuất phát từ nút có câu hỏi truy vấn QUERY sang nút đích. Nếu có nút đích mà nó không thể đến được thì nó sẽ đánh dấu để tuyến không đi qua nút này, Trong trường hợp nút không thể tìm thấy được bất kỳ lân cận nào có giới hạn WRT (Wireless Router Time) để đến đích, nó sẽ cố gắng tìm một tuyến mới. Trong trường hợp phân vùng mạng, nút sẽ gửi broadcast thông điệp CLEAR để thiết lập lại tất cả các tuyến và yêu cầu mạng gỡ bỏ các tuyến không hợp lệ đã được thiết lập trước đó. TORA hoạt động trên IMEP (Internet MANET Encapsulation Protocol) nên nó cung cấp cơ chế phân phát an toàn các thông điệp định tuyến và đưa ra giao thức định tuyến trong bất kỳ sự thay đổi nào của đường truyền từ nút đó đến lân cận của nó; để giảm chi phí định tuyến IMEP cố gắng kết hợp hai thông điệp IMEP và TORA trong một gói hay block; để duy trì trạng thái kết nối giữa 1 nút và lân cận, IMEP gửi thông điệp BEACON và các nốt nghe thấy thông điệp này sẽ phải trả lời bằng thông điệp “Hello”. (quá trình thực thi TORA trong NS được diễn tả kỹ trong thư mục ns/tora và ns/tcl/mobility/tora.tcl). AODV AODV là giao thức kết hợp của hai giao thức DSR và DSDV; nó dựa vào cơ chế khám phá tuyến (route-discovery) duy trì tuyến của DSR và sử dụng phương pháp định tuyến hop-by-hop, chỉ số tuần tự và thông tin chỉ dẫn định tuyến của DSDV. Một nút nếu muốn biết tuyến đến đích thì nó tạo ROUTE REQUEST rồi thông qua các nút trung gian để dò tìm đích và nó cũng sẽ nhận được thông tin của liên kết ngược của đích gửi trở về cho nó. Khi nút đó có yêu cầu đến một nút khác với tuyến xác định, nó tạo ra ROUTE REPLY gồm có chỉ số của các hop cần thiết để đến được đích. Tất cả các nút tham gia trong quá trình chuyển tiếp reply đến đích này tạo ra đường đi của tuyến từ nút gửi yêu cầu định tuyến đến đích. Trạng thái tạo ra ở mỗi node từ nguồn đến đích là trạng thái hop-by-hop (theo chặng) và không phải theo toàn bộ tuyến mà nó tổng hợp được sau khi gửi ROUTE REQUEST và nhận thông tin phản hồi ở bước dò tìm trước đó. (Xem ns/aodv và ns/tcl/lib/ns-lib.tcl để biết chi tiết của AODV) 4.1.2.2. Nút và mô hình di chuyển trong WLAN Sự di chuyển của nút mạng là một trong những đặc tính của mạng WLAN. Trong NS, các nút mạng có thể di chuyển được trong không gian 3 -63- chiều, vị trí của nó được xác định bởi 3 tọa độ (x, y, z) trong không gian. Tuy nhiên, cho đến nay, NS2 mới chỉ hỗ trợ việc mô phỏng chuyển động trong 1 mặt phẳng, với Z lúc nào cũng bằng 0. Sau đây là 3 mô hình chuyển động đã được đưa vào NS2 để mô phỏng các kiểu chuyển động của mobilenode: Mô hình di chuyển của nút mạng khi biết trước vị trí đầu và cuối: Đường đi của nút được chỉ dẫn (directive) một cách rõ ràng trong các file mô tả sự di chuyển riêng biệt. Vị trí bắt đầu và đích tương lai của mobilenode có thể được thiết lập bằng cách sử dụng lệnh thiết lập sau: $node set X_ $node set Y_ $node set Z_ $ns at $time $node setdest Tại $time (tính bằng giây - sec), mobilenode sẽ bắt đầu di chuyển (moving) từ vị trí bắt đầu của nó là (x1,y1) chuyển tiếp sang đích (x2,y2) với tốc độ (speed) xác định với đơn vị là m/s. Mô hình nút di chuyển CMU: Là một phiên bản của hệ thống setdest (chi tiết ở ~ns/indep-utils/cmu-scen-gen/setdest), setdest tạo ra các biến ngẫu nhiên bằng cách thực hiện các lời gọi chức năng này ở thư viện initstate (), điều này đã thay thế cho một "máy phát" số ngẫu nhiên trong lớp RNG. Cấu hình di chuyển của nút được thiết lập như sau: ./setdest [-n num_of_nodes] [-p pausetime] [-s maxspeed] [-t simtime] \ [-x maxx] [-y maxy] > [outdir/movement-file] Trong đó: -n num_of_nodes: Số nút di chuyển -p pausetime: Thời gian tạm dừng trung bình giữa 2 lần di chuyển -s maxspeed: Tốc độ tối đa của di chuyển -t simtime: Thời gian chạy mô phỏng - x maxx và -y maxy: Ranh giới di chuyển trên mặt phẳng theo tọa độ x và y (không xét tọa độ z và đã xem z = 0) Mô hình di chuyển ngẫu nhiên: Cơ chế này, NS khởi tạo mobilenode ($mobilenode start) với một vị trí ngẫu nhiên và thường cập nhập để thay đổi -64- hướng và tốc độ của node. Giá trị tọa độ đích di chuyển đến và tốc độ được tạo ra ngẫu nhiên. Quá trình di chuyển của mobilenode có sử dụng thủ tục như sau: proc log-movement {} { global logtimer ns_ ns set ns $ns_ source ../mobility/timer.tcl Class LogTimer -superclass Timer LogTimer instproc timeout {} { global opt node_; for {set i 0} {$i < $opt(nn)} {incr i} { $node_($i) log-movement } $self sched 0.1 } set logtimer [new LogTimer] $logtimer sched 0.1 } (Vị trí của mobilenode sẽ được cập nhật sau mỗi 0.1 giây.) Hình 4.6: Lược đồ của một mobile node chuẩn 802.11 của Monarch trong NS. -65- 4.1.2.3. Ngăn xếp mạng của mobilenode trong WLAN Ngăn xếp mạng đối với một mobilenode gồm có lớp link (LL), modul RP kết nối đến LL, một hàng đợi có ưu tiên tại giao diện mạng IFq (Interface Priority queue), lớp MAC, giao diện mạng netIF (net interface), tất cả được kết nối đến channel. (Hình 4.6) Link Layer LL có module ARP để giải quyết tất cả các quá trình chuyển đổi địa chỉ IP sang địa chỉ MAC và Routing Agent. (chi tiết có ở trong ~ns/ll.{cc,h} và ~ns/tcl/lan/ns-ll.tcl ). ARP là giao thức phân giải địa chỉ (Address Resolution Protocol) thực thi ở dạng BSD (implemented in BSD style) nhận các câu hỏi từ lớp Link. Nếu ARP biết được địa chỉ MAC của đích đến, nó ghi địa này vào header của gói tin tầng MAC và thêm vào hàng đợi tại giao diện mạng (interface queue) của hop đó. Ngược lại, nó gửi broadcasts truy vấn ARP và tạm giữ ở bộ nhớ đệm của Mobilenode. (chi tiết có ở trong ~ns/arp.{cc,h} và ~ns/tcl/lib/ns-mobilenode.tcl). Interface Queue được thực thi như một hàng đợi có ưu tiên đưa ra các quyền ưu tiên để định tuyến các gói tin. (chi tiết trong ~ns/priqueue.{cc,h}). Mac Layer IEEE 802.11 theo cơ chế Chức năng cộng tác phân tán - DCF - là giao thức MAC được thực thi bởi CMU, sử dụng khuôn dạng RTS/CTS/DATA/ACK cho tất cả các gói tin unicast và broadcast. (chi tiết có ở trong ~ns/mac-802_11.{cc,h}). Network Interfaces (giao tiếp mạng) đáp ứng giao tiếp phần cứng (hardware interface) sử dụng bởi mobilenode để truy xuất đến kênh truyền thông. (chi tiết có ở trong ~ns/phy.{cc.h} and ~ns/wireless-phy.{cc,h}) Mô hình truyền bá Radio Sử dụng công thức tính sự suy giảm năng lượng tín hiệu truyền đối với các khoảng cách gần là 1/r2 và đối với khoảng cách xa là 1/r4 (chi tiết có ở trong ~ns/tworayground.{cc,h}). Antenna (Antenna omni-directional) được sử dụng với mục đích chung bởi mobilenodes. (chi tiết có ở trong ~ns/antenna.{cc,h}). 4.1.2.4. Mô hình lỗi của NS-2 Trong NS2, mô hình lỗi (ErrorModel) được áp dụng vào các thủ tục tạo ra lỗi để tác động trực tiếp vào đường truyền nhằm mô tả các tình huống lỗi có thể xảy ra ở mạng thực. Các đơn vị lỗi được NS2 sử dụng là byte, gói tin hoặc thời gian. -66- Lớp ErrorModel có nguồn gốc từ lớp cơ sở Connector. Vì vậy nó kế thừa một vài phương thức để kết nối các đối tượng như target hay drop-target. Nếu drop-target tồn tại, nó sẽ nhận các gói tin bị sai lệch từ ErrorModel. Có 2 mô hình lỗi được sử dụng trong NS2 đó là mô hình lỗi đồng đều (Uniform) và mô hình lỗi đa trạng thái. Đối với mô hình lỗi đồng đều, tỉ lệ gói tin lỗi được người sử dụng tự đặt tùy vào thí nghiệm và nó được tính bởi số gói tin lỗi trong 1 giây. Đối với mô hình lỗi đa trạng thái, số gói tin lỗi được phân bố theo xác suất và được tính thông qua ma trận chuyển trạng thái cấp N với N là số trạng thái (tôi đã trình bày nội dung này ở phần 1.2.1). Ví dụ quá trình tạo ra một mô hình lỗi đồng đều (Uniform) với tỉ lệ gói lỗi là 1% (0.01), được viết bằng đoạn mã sau: # tạo một modul loss_ và thiết lập tỉ lệ gói lỗi là 1% set loss_module [new ErrorModel] $loss_module set rate_ 0.01 #Tuỳ chọn: thiết lập đơn vị tính lỗi và biến ngẫu nhiên $loss_module unit pkt ; # đơn vị lỗi: các packet (theo mặc định) $loss_module ranvar [new RandomVariable/Uniform] # thiết lập target cho các packet bị huỷ $loss_module drop-target [new Agent/Null] Ví dụ quá trình tạo ra một mô hình lỗi 3 trạng thái # Tạo 3 mô hình lỗi đồng đều có một 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] # Tạo mô hình lỗi 3 trạng thái # Tạo mảng các trạng thái set m_states [list $tmp $tmp1 $tmp2] # Thiết lập thời gian đường truyền nằm ở mỗi trạng thái set m_periods [list 0 .0075 .00375] # Thiết lập ma trận chuyển trạng thái set m_transmx { {0.95 0.05 0} {0 0 1} {1 0 0}} # Thiết lập đơn vị tính là gói tin set m_trunit pkt # Chuyển trạng thái theo thời gian set m_sttype pkt set m_nstates 3 set m_nstart [lindex $m_states 0] -67- set em_s_r($i) [new ErrorModel/MultiState $m_states $m_periods $m_transmx $m_trunit $m_sttype $m_nstates $m_nstart] Sử dụng mô hình lỗi trong mô phỏng mạng Để sử dụng mô hình lỗi cho mạng, đầu tiên NS phải thêm vào một đối tượng SimpleLink (vì SimpleLink là một đối tượng hoàn chỉnh, thuận tiện cho các thao tác mô phỏng đường truyền đơn công - dùng trong mạng không dây). Nút đích Đối tượng Hàng đợi Đối tượng trễ Vị trí 1 Vị trí 3 Vị trí 2 Nút nguồn Đường truyền đơn công Hình 4.7: Các vị trí chèn lỗi khi mô phỏng mạng không dây. Mô hình lỗi có thể được chèn vào nhiều vị trí trên đường truyền đơn công (SimpleLink), hiện tại NS hỗ trợ các phương thức để chèn mô hình lỗi vào ba vị trí khác nhau trên đường truyền đơn: Bảng so sánh các vị trí chèn lỗi Vị trí chèn lỗi Loại đường truyền sẽ chèn lỗi Vị trí so với đối tượng hàng đợi Vị trí so với đối tượng trễ Các trường hợp ứng dụng để mô phỏng mạng thực Vị trí 1 Đơn công Trước Trước Đường truyền bị nghẽn, Gói tin bị quá TTL và bị drop Vị trí 2 Đơn công Sau Trước Gói tin bị quá TTL Vị trí 3 Đơn công Sau Sau Gói tin bị quá TTL -68- 4.2. Đánh giá hiệu suất giao thức TCP, UDP trong mạng LAN Mục đích: Khảo sát, đánh giá khả năng thích ứng với lỗi nảy sinh trên đường truyền và hệ số sử dụng đường truyền của mạng LAN khi truyền thông đồng thời luồng TCP và UDP; đánh giá độ trễ trung bình của gói tin, độ lệch chuẩn của độ trễ của luồng TCP và tỉ lệ phân phát gói tin TCP thành công. Mô hình khảo sát: Mạng LAN khảo sát có tô-pô và cấu hình như sau: S0 S2 S1 S3 SinkS4 S5 NullS6 10Mbps, 5ms Vị trí chèn lỗi đường truyền TCPFTP UDPCBR Hình 4.8: Mô hình khảo sát mạng LAN Trong mô hình (hình 4.8): S0..S6 là các nút mạng. S2, S3 có thể xem là các switch, giữa S2 và S3 hình thành bus. Tất cả các kết nối trong mạng (kể cả bus) đều có bandwidth và độ trễ bằng nhau (10Mbps, 5ms). FTP và CBR là các nguồn sinh lưu lượng. Sink là đích của nguồn FTP, Null là đích của nguồn CBR. Trong thí nghiệm này, tôi đã sử dụng mô hình lỗi đồng đều (Uniform Model) với tỉ lệ lỗi (error rate) = 0.001, đơn vị tính là gói tin (pkt), tỉ lệ lỗi này ứng với BER = 10-7. Kích thước của gói tin cố định 576 bytes và kích thước cửa sổ phát được đặt là 64 KB. Kịch bản: Nguồn CBR được cố định với kích thước gói tin là 512 bytes, tốc độ phát 1Mbps và CBR phát trước để chiếm dụng đường truyền trước. Sau đó, TCP truyền gói tin, sẽ có sự cạnh tranh để chiếm dụng đường truyền trên chặng đường truyền dùng chung nối s2 và s3. Với sự xuất hiện của lỗi, một số gói tin của TCP và UDP sẽ không đến được đích. Giao thức UDP hầu như không có "động thái" nào để thích ứng với lỗi nên vẫn truyền đều với kích thước -69- gói tin và tốc độ phát như đã định trước. Giao thức TCP sẽ thích ứng với đường truyền để sử dụng tốt nhất phần dải thông còn lại trong khoảng thời gian nguồn UDP phát. Các thông số và kịch bản của thí nghiệm được tóm tắt ở bảng 1 Bảng 1: Thông số của thí nghiệm Băng thông của đường truyền (Mbps) 10 Độ trễ (ms) 5 Tỉ lệ lỗi đường truyền (gói tin) 0,001 BER (tỉ lệ bít lỗi) 10-7 Thời gian mô phỏng (s) 12 Tham số nguồn UDP Tốc độ phát của CBR (Mbps) 1 Kích thước gói tin UDP (byte) 512 Nguồn - Đích S1 - S6 Thời gian phát Từ 0,3s đến 10,7s của thời gian mô phỏng Tham số nguồn TCP Kích thước cực đại cửa sổ phát (KB) 64 Kích thước gói tin 576 Thời gian phát Từ 0,7s đến 11,7s của thời gian mô phỏng Nguồn - Đích S0 - S4 Kết quả thí nghiệm: Với mục đích của thí nghiệm là xác định và vẽ đồ thị sự thay đổi theo thời gian mô phỏng của hệ số sử dụng đường truyền của kết nối TCP khi dùng chung một đường truyền với luồng UDP, tôi đã sử dụng bước thời gian là 0,7s. Đồ thì sẽ mịn hơn nếu bước thời gian càng nhỏ, tuy nhiên với bước thời gian này thì hình dạng của đồ thị vẫn có thể phản ánh đúng kết quả và tính chất đặc thù của thí nghiệm. Kết quả 1: Hệ số sử dụng đường truyền của luồng TCP so với băng thông Thời điểm (s) Thông lượng TCP (bps) Thông lượng UDP (bps) Băng thông còn lại (Mbps) Hệ số sử dụng TCP (%) 0.7 0,000 555885,714 9,44411 0,00 -70- 1,4 6878537,143 994742,857 9,00526 61,94 2,1 6962560,000 1000594,286 8,99941 62,66 2,8 3245440,000 1000594,286 8,99941 29,21 3,5 3548160,000 994742,857 9,00526 31,95 4,2 2984960,000 1000594,286 8,99941 26,86 4,9 3604480,000 1000594,286 8,99941 32,44 5,6 3104640,000 1000594,286 8,99941 27,94 6,3 2147200,000 994742,857 9,00526 19,34 7 3329920,000 1000594,286 8,99941 29,97 7,7 3329920,000 994742,857 9,00526 29,99 8,4 5660160,000 1000594,286 8,99941 50,94 9,1 4597120,000 1000594,286 8,99941 41,37 9,8 5068800,000 1000594,286 8,99941 45,62 10,5 5005440,000 1000594,286 8,99941 45,05 11,2 5385600,000 304274,286 9,69573 52,22 11,732 6005120,000 0,000 10,00000 60,05 Kết quả 2: Các kết quả khác Độ trễ trung bình của các gói tin (s) 0,017463 Độ lệch chuẩn của độ trễ luồng gói tin TCP (s) 0,001414 Số gói tin TCP gửi 10081 Số gói tin TCP đến đích 10068 Tỉ lệ phân phát gói tin thành công (%) 99,87 Phân tích kết quả mô phỏng: Với mọi trạng thái của đường truyền, nguồn UDP luôn phát với tốc độ và kích thước gói tin không đổi. Nguồn UDP phát trước (tại thời đểm 0,3s) và đạt tốc độ tối đa (1Mbps) cho đến 0,7s - khi TCP bắt đầu phát. Tại thời điểm 0,7s đã có sự tranh chấp đường truyền, nguồn TCP lập tức phát với kích thước cửa sổ lớn nhằm tận dụng hết băng thông còn lại (khoảng 9Mbps), thậm chí muốn tranh luôn phần băng thông mà nguồn UDP đang truyền. Vì vậy tại thời điểm 0,7s số gói tin được đưa vào đường truyền tăng đột biến, băng thông của nguồn UDP có nguy cơ bị thu hẹp (sự thật đã bị thu hẹp về chỉ còn 555,885Kbps). Sau đó nguồn TCP vẫn tăng với tốc độ chậm để dò tìm để tận dụng hết phần băng thông -71- còn lại, sự chiếm dụng này sẽ đạt cực đại tại lân cận thời điểm 2,1s. Hình dạng của tỉ lệ luồng TCP sử dụng phần còn lại của đường truyền được thể hiện ở đồ thị hình 4.9. Khi thông lượng nguồn TCP đã đạt cực đại, để giảm nguy cơ gây nên tắc nghẽn, giao thức TCP khởi động thuật toán Congestion Avoidance để tăng từ từ kích thước cửa sổ phát nhằm dò tìm và tận dụng hết đường truyền, như có thể thấy trên đồ thị, đoạn có ghi nhãn 61,94 đến 62,66. Khi có dấu hiệu tắc nghẽn (mất gói tin), TCP lại giảm cửa sổ phát theo thuật toán SS (giảm tối đa tại lân cận thời điểm 6,3s) sau đó lại tăng từ từ kích thước cửa sổ. Quá trình này được lặp đi lặp lại cho cho đến khi đường truyền ổn định (không có biến động đột biến). Sau thời điểm 10,7s, nguồn UDP ngừng phát, nguồn TCP tăng dần thông lượng để tận dụng đường truyền. 19,34 0 52,22 45,05 60,05 45,62 41,37 50,94 29,97 29,9927,94 32,44 26,86 31,95 29,21 61,94 62,66 0 10 20 30 40 50 60 70 0.7 1,4 2,1 2,8 3,5 4,2 4,9 5,6 6,3 7 7,7 8,4 9,1 9,8 10 ,5 11 ,2 11 ,73 2 Thời gian phát Tỉ lệ % Hình 4.9: Kết quả mô phỏng TCP trong mạng LAN Tuy tỉ lệ lỗi bít trong đường truyền có dây của mạng LAN là rất nhỏ (cỡ 10-7) nhưng ở thí nghiệm này, tôi cũng đã thử cho thay đổi tỉ lệ lỗi và nhận thấy rằng: Giao thức TCP phản ứng tích cực với lỗi bằng cách giảm tốc độ truyền của nguồn sinh lưu lượng khi tỉ lệ lỗi tăng (tỉ lệ nghịch với nguồn sinh lưu lượng), điều này rất phù hợp với lý thuyết. Khi đường truyền có lỗi, nếu trong mạng có cả nguồn phát CBR và FTP thì FTP phải giảm lưu lượng (vì CBR sử dụng giao thức UDP nên giữ nguyên tốc độ truyền tin). Để thích ứng với đường truyền, giao thức TCP sẽ điều chỉnh lưu lượng (giảm) để phòng tránh tắc nghẽn. Với giao thức UDP, khi đường truyền có lỗi, nguồn lưu lượng vẫn giữ nguyên tốc độ phát (số gói tin phát đi là không đổi). Với các tỉ lệ lỗi tăng dần thì -72- số lượng gói tin UDP bị mất (không đến đích) sẽ tăng theo tỉ lệ thuận (lỗi tăng thì gói tin bị lỗi trên đường truyền tăng). Điều này phù hợp với lý thuyết. Trong thí nghiệm này, với các thông số đầu vào như trên thì tỉ lệ phân phát gói tin TCP thành công đạt 99,87% (một số gói tin bị drop do TTL quá hạn trong và trước hàng đợi) còn tỉ lệ phân phát gói tin UDP thành công đạt 99,88% (2540 gói gửi, 2537 gói đến đích). Với đường truyền phù hợp (theo nghĩa nguy cơ khả năng phát sinh lỗi thấp) thì hiệu suất về thông lượng và độ trễ của UDP có thể đạt được cao hơn của TCP. Tuy nhiên, trên thực tế, TCP vẫn được đánh giá tốt hơn và được sử dụng để vận chuyển phần lớn thông tin trên Internet vì TCP có đặc tính tự thích ứng với đường truyền, trong khi UDP không có. Do vậy, khi đường truyền có nhiều lỗi nảy sinh. Chất lượng của UDP sẽ kém hơn nhiều so với TCP. 4.3. Đánh giá hiệu suất giao thức TCP, UDP trong mạng hỗn hợp Mục đích: Đánh giá độ đo hiệu suất mạng hướng tới hệ thống như: tỉ lệ gói tin được truyền thành công, độ trễ trung bình của các gói tin, độ lệch chuẩn của độ trễ, ảnh hưởng của kích thước hàng đợi (KTHĐ) của AP đến hiệu suất của mạng hỗn hợp. Tô-pô và cấu hình: Tô-pô mạng (ở hình 4.10) sử dụng cho thí nghiệm mô phỏng này gồm 2 phần: phần có dây (gồm các nút gửi S0, S1, S2 và AP), phần không dây (gồm các nút nhận S3, S4 kết nối không dây với AP). Như vậy các thực thể gửi đều nằm trên FH và các thực thể nhận (sink, null) nằm trên MH. S0 S2 S1 AP TCPFTP Sink UDPCBR Phần không dây (WLAN) Phần có dây S3 Hình 4.10: Tô-pô mạng hỗn hợp WLAN + Internet khi truyền TCP, UDP Các đường truyền trong mạng LAN và WLAN có băng thông và độ trễ như nhau (10Mbps, 5ms). Băng thông và độ trễ của chặng LAN - WAN phụ thuộc vào khoảng cách giữa trạm phát và trạm nhận trong mỗi thí nghiệm. (LAN+WAN) Hàng Đợi Đường truyền internet NullS4 Vị trí chèn lỗi đường truyền -73- Kịch bản mô phỏng: Sử dụng 2 nguồn phát TCP và UDP để truyền dữ liệu đến các đích khác nhau, trên đường đi, 2 luồng này sẽ tranh chấp tài nguyên mạng. Thay đổi băng thông và độ trễ đường truyền Internet để thể hiện sự thay đổi tương ứng với khoảng cách truyền từ trạm phát đến trạm nhận trong 3 trường hợp: gần, trung bình, xa. Dựa trên sự tranh chấp đường truyền từ nguồn đến đích của các luồng TCP và UDP để đánh giá hiệu năng của luồng TCP và UDP qua các tham số như: độ trễ trung bình của các gói tin các luồng, tỉ lệ gói tin được truyền thành công, độ lệch chuẩn của độ trễ. Điều chỉnh KTHĐ (ngẫu nhiên và tăng dần) để khảo sát, đánh giá mức độ ảnh hưởng của nó đến các độ đo hiệu suất mạng. Kết quả: Bảng kết quả số liệu khảo sát mạng hỗn hợp khi sử dụng TCP và UDP Các thông số đầu vào Kích thước cửa sổ phát (Kb) 64 Các link LAN, WLAN 10Mbps, 5ms Giới hạn hàng đợi (gói tin) Min = 1, Max = 512 Khoảng cách node-AP (m) 20 Thời gian khảo sát (s) 200 TCP hoạt động Giây thứ 10 đến giây thứ 180 của thời gian mô phỏng Kích thước gói tin TCP (byte) 576 UDP hoạt động Giây thứ 5 đến giây thứ 160 của thời gian mô phỏng Kích thước gói tin UDP (byte) 276 Tốc độ phát UDP (Mbps) 0,5 Mô hình lỗi Markov 2 trạng thái với ma trận lỗi {0,6 0,4 / 0 1} Đường truyền WAN 1,5Mbps, 10ms 1,5Mbps, 20ms 1,5Mbps, 40ms 1. Kết quả khảo sát giao thức TCP (với KTHĐ = 4 Kb) Số gói tin gửi 4527 4412 4327 Số gói tin đến đích 4352 4259 4206 -74- Tỉ lệ truyền thành công (%) 96,13 96,63 97,2 Độ trễ TB của gói tin (s) 0,206495 0,216458 0,236791 Độ lệch chuẩn của độ trễ (s) 0,036483 0,03704 0,038039 2. Kết quả khảo sát giao thức UDP (với KTHĐ = 4 Kb) Số gói tin gửi 37842 Số gói tin đến đích 35877 35865 35837 Tỉ lệ truyền thành công (%) 94,81 94,78 94,70 Độ trễ TB của gói tin (s) 0,164316 0,172097 0,195475 Độ lệch chuẩn của độ trễ (s) 0,062362 0,070207 0,073675 3. Ảnh hưởng của KTHĐ đến tham số hiệu năng. Kích thước cửa sổ phát (Kb) 64 Các link LAN, WLAN 10Mbps, 5ms Giới hạn hàng đợi (gói tin) Min = 1, Max = 512 Khoảng cách node-AP (m) 20 Thời gian khảo sát (s) 200 TCP hoạt động Giây thứ 10 đến giây thứ 180 của thời gian mô phỏng Kích thước gói tin TCP (byte) 576 UDP hoạt động Giây thứ 5 đến giây thứ 160 của thời gian mô phỏng Kích thước gói tin UDP (byte) 276 Tốc độ phát UDP (Mbps) 0,5 Mô hình lỗi Markov 2 trạng thái với ma trận lỗi {0,6 0,4 / 0 1} Đường truyền WAN 1,5 Mbps, độ trễ 10ms Kích thước hàng đợi (Kb) 1 2 4 6 8 - Kết quả các tham số hiệu năng của luồng TCP Số gói tin gửi 3130 4277 4527 4594 4594 Số gói tin đến đích 2876 4094 4352 4421 4421 Tỉ lệ truyền thành công (%) 91,88 95,72 96,13 96,23 96,23 Độ trễ TB của gói tin (s) 0,200776 0,205143 0,206495 0,206197 0,206197 Độ lệch chuẩn của độ trễ (s) 0,035497 0,036139 0,036483 0,036987 0,036987 - Kết quả các tham số hiệu năng của luồng UDP Số gói tin gửi 37842 Số gói tin đến đích 36661 36143 35865 35799 35799 Tỉ lệ truyền thành công (%) 96,88 95,51 94,78 94,6 94,6 -75- Độ trễ TB của gói tin (s) 0,139079 0,162137 0,164316 0,194240 0,194240 Độ lệch chuẩn của độ trễ (s) 0,089828 0,075027 0,062362 0,070071 0,070071 Phân tích kết quả mô phỏng: Trong thí nghiệm này, việc truyền tin trên đường truyền hỗn hợp được thể hiện ở chỗ các thực thể gửi của các giao thức đều nằm trên FH (ở phần đường truyền có dây) còn các thực thể nhận nằm trên các MH (ở phần đường truyền không dây). Các trạm gửi, nhận gói tin TCP và UDP thông qua nhiều chặng truyền trong đó có chặng Internet, vì vậy mạng được xem là WAN trong đó bao gồm cả LAN và WLAN. Với các mạng LAN và WLAN, độ trễ đường truyền sẽ nhỏ hơn nhiều so với mạng WAN. Theo thí nghiệm mô phỏng thì với đường truyền T1 của mạng WAN thì băng thông có thể đạt đến 1,5 Mbps và độ trễ của gói tin tùy thuộc vào khoảng cách giữa trạm phát và nhận (là gần, trung bình và xa tương ứng với độ trễ là 10ms, 20ms và 40ms). Khi truyền tin bằng giao thức TCP và UDP, với đường truyền hỗn hợp và có độ dài lớn (thể hiện ở độ trễ của chặng Internet) thì nguy cơ gặp lỗi trên đường truyền của các gói tin là rất lớn. Các lỗi này chủ yếu do chặng không dây. Trong thí nghiệm, tôi đã sử dụng mô hình lỗi đồng đều cho chặng có dây (LAN và WAN) và mô hình lỗi Markov 2 trạng thái cho chặng không dây (WLAN) cho 2 luồng TCP và UDP. Các kết quả của thí nghiệm cho thấy rằng: khả năng thích ứng với đường truyền của giao thức TCP cao hơn UDP điều này thể hiện qua tỉ lệ phân phát gói tin thành công. Khi tăng trễ chặng Internet thì tỉ lệ phân phát gói tin luồng TCP tăng còn luồng UDP thì ngược lại. Ngoài ra việc tăng trễ này có tác động tỉ lệ thuận đến độ trễ trung bình của các gói tin và độ lệch chuẩn của độ trễ của luồng TCP và UDP, điều này phù hợp với lý thuyết. Ảnh hưởng của KTHĐ của AP đến hiệu suất của mạng hỗn hợp: Hàng đợi cho thí nghiệm mô phỏng này có dạng RED (Random Early Detection). Giới hạn nhỏ nhất của kích thước hàng đợi trung bình trong các gói -76- tin (thresh_ ) là 2 byte, giới hạn lớn nhất (maxthresh_ ) là 512 byte. Ước lượng kích thước gói tin trung bình (mean_pktsize_) là 500 byte và dùng để cập nhật việc tính toán kích thước hàng đợi trung bình sau thời gian nhàn rỗi. Như vậy, với dạng hàng đợi này, các gói tin được phát hiện và loại bỏ 1 cách ngẫu nhiên (khác với Drop tail là kiểu FIFO) Lúc KTHĐ đợi nhỏ (1Kb), thời gian trễ trung bình của các gói tin (cả TCP và UDP) là thấp do không tốn thời gian chờ khi ở trong hàng đợi. Theo thí nghiệm thì các gói tin TCP có kích thước 576 byte (64 byte header), UDP là 276 byte (20 byte header) và có hiện tượng "nút cổ chai" khi đường truyền chuyển từ LAN, WLAN (10Mbps) sang WAN (1,5Mbps) nhưng hầu như được truyền thẳng 1 mạch từ nguồn đến đích do băng thông chung khá lớn (tính theo băng thông của đường truyền bé hơn (của WAN). Với giao thức TCP: Khi tăng KTHĐ, các nguồn phát TCP phản ứng với đường truyền bằng cách tăng dần số lượng gói tin phát để tận dụng thông lượng đường truyền và khả năng xử lý của mạng. Theo thí nghiệm, tỉ lệ phân phát gói tin thành công và độ trễ trung bình của các gói tin luồng TCP giá trị cực đại và bão hòa khi KTHĐ trong khoảng lân cận 6Kb, sau đó nó sẽ giảm tốc độ phát để tiến về giá trị bão hòa. Lúc này, mạng sẽ hoạt động ổn định. Với việc tăng kích thước hàng đợi, hiệu suất đường truyền (với độ đo là tỉ lệ gói tin đến đích) được cải thiện rõ rệt thể hiện ở chỗ càng tăng KTHĐ thì tỉ lệ gói tin đến đích càng tăng nhưng rõ ràng là thời gian trễ trung bình cũng tăng đồng biến. Trong thực tế, kích thước hàng đợi phải đủ lớn nhưng không thể quá lớn vì có thể nó là nguyên nhân gây nên các gói tin drop do quá TTL. Tuy nhiên, lúc KTHĐ đạt đến giá trị bão hòa (như thí nghiệm là 6Kb hoặc lân cận giá trị này sai số <1Kb) thì tăng KTHĐ hầu như không có tác dụng gì trong vấn đề cải thiện hiệu năng đường truyền (tôi đã thí nghiệm với việc tăng KTHĐ thành 7Kb, 8Kb, 16Kb, 32Kb). -77- Như vậy, đối với mạng hỗn hợp việc tăng KTHĐ của AP đến một giá trị nhất định để cải tiến hiệu năng đường truyền là một hướng đúng cho các cải tiến TCP (đại diện là Snoop-TCP), điều này đúng với các lý thuyết hàng đợi. Với giao thức UDP: Nguồn UDP phát trước TCP với tốc độ phát 0,5Mbps, kích thước mỗi gói tin là 267 byte, KTHĐ = 1Kb (tương đương với gần 4 gói tin) và thông lượng đường Bus (giữa S2 và AP) chỉ 1,5Mbps nên các gói tin UDP hầu như được truyền đi mà không bị lỗi (do quá TTL). Theo thí nghiệm tỉ lệ phân phát gói tin đạt giá trị cao nhất (96,88%) với KTHĐ là 1Kb. Khi tăng dần KTHĐ, tỉ lệ phân phát gói tin UDP thành công bị giảm dần (nghịch biến) và độ trễ trung bình của các gói tin UDP tăng đồng biến, điều này hoàn toàn với lý thuyết. Do giao thức UDP không có cơ chế điều khiển và phòng chống tắc nghẽn và tốc độ truyền tin là cố định nên không có khả năng thích ứng với biến động trên đường truyền. Do đó khi tăng KTHĐ, nguy cơ các gói tin bị drop do quá TTL là rất cao, với kiểu hàng đợi RED số gói tin bị loại bỏ trước khi vào hàng đợi sẽ tăng lên; những gói tin UDP được phân phát thành công cũng sẽ có độ trễ trung bình lớn (nhỏ hơn TTL) và tăng đồng biến với KTHĐ. Việc giảm tỉ lệ phân phát gói tin thành công và tăng độ trễ trung bình của luồng UDP sẽ bão hòa khi KTHĐ = 6Kb (hoặc lân cận giá trị này sai số <0,5Kb). Tôi đã thí nghiệm với các kích thước 6,5Kb, 7Kb, 8Kb, 9Kb, 12Kb nhưng kết quả vẫn không thay đổi. Như vậy, trong mạng hỗn hợp với giao thức UDP thì tăng KTHĐ không phải là một giải pháp tốt nhằm nâng cao hiệu suất sử dụng mạng. -78- KẾT LUẬN 1. Các vấn đề được tìm hiểu trong luận văn. - Tìm hiểu sự ra đời của mạng máy tính, LAN, WLAN, Internet; giao thức MAC của mạng LAN, WLAN; nghiên cứu đặc điểm của đường truyền không dây làm cơ sở để nghiên cứu, đánh giá hiệu suất mạng. - Cơ chế điều khiển lưu lượng của mạng bằng giao thức TCP/IP và phản ứng sai lầm của mạng với sự mất mát gói tin do lỗi; nghiên cứu các cải tiến TCP áp dụng cho mạng hỗn hợp LAN và WLAN. - Tìm hiểu sâu ảnh hưởng của lỗi trên đường truyền không dây đến các tham số hiệu suất chính của các ứng dụng sử dụng giao thức giao vận TCP và UDP trên mạng WLAN kết nối với Internet. - Tìm hiểu phần mềm Mô phỏng NS2 sử dụng để mô phỏng mạng LAN, WLAN và Internet; mô phỏng một số thí nghiệm để đánh giá hiệu suất của giao thức giao vận TCP và UDP trong mạng có phần mở rộng không dây để kiểm chứng các vấn đề được nghiên cứu ở phần lý thuyết. 2. Hướng nghiên cứu tiếp theo. - Nghiên cứu định lượng các tham số ảnh hưởng đến lỗi trên đường truyền phần không dây của mạng hỗn hợp để đóng góp vào nhóm giải pháp cải tiến giao thức TCP/IP nâng cao hiệu suất cho mạng hỗn hợp có dây và không dây nói chung. - Các vấn đề liên quan đến Roaming client giữa các cell nhằm tối ưu hóa hiệu suất của mạng không dây. - Tối ưu hóa hiệu suất đường truyền hỗn hợp có chặng WiMax, vệ tinh. -79- TÀI LIỆU THAM KHẢO. [1] Vũ Duy Lợi (2002), "Mạng thông tin máy tính", Nhà xuất bản Thế giới. [2] Nguyễn Đình Việt (2008), "Đánh giá hiệu năng mạng máy tính" (dành cho các lớp Cao học) – Đại học Công nghệ, Đại học Quốc gia Hà Nội. [3] Nguyễn Đình Việt (2003), “Đánh giá hiệu suất mạng thông tin máy tính”, Luận án tiến sỹ toán học. [4] Nguyễn Hồng Sơn, “Giáo trình hệ thống mạng máy tính, CCNA Semester 1”, NXB Lao động- Xã hội, 2005. [5] Nguyễn Đình Việt, (2002) "TCP Enhancements and Performance over Networks with Wireless Links" [6] Dang-Hai Hoang. "Quality of Service Control in the Mobile Wireless Environments". PETER LANG Publisher, Frankfurt/M-Berlin-Bern-Bruxelles-New York-Oxford-Wien, ISBN 3-531-50578-7, US–ISBN 08204-6402-3, 2003. [7] Cao Huy Phương, Hoàng Đăng Hải. "Congestinon Control in NGN - All IP network", tháng 10 năm 2005. [8] L. Kalampoukas, A. Varma, and K. K. Ramakrishnan. "Explicit window adaptation: A method to enhance TCP performance. IEEE/ACM Transactions on Networking" 10(3):338–350, June 2002. [9] D. Katabi, M. Handley, and C. Rohrs. "Congestion control for high bandwidth-delay product networks". Proceedings of ACM SIGCOMM’02, August 2002. [10] M. Savori. "Improving congestion control in IP-based networks using feedback from routers". Technical Report TKN-04-008, July 2004 [11] Swastik Kopparty, Srikanth V. Krishnamurthy, Michalis Faloutsos, Satish K. Tripathi. "Split TCP for Mobile Networks". [12] A. K. Jain and S. Floyd. "Quick-start for TCP and IP" drafts/draft-amit quickstart-02.txt, work in progress, Oct. 2002. [13] D-M. Chiu and R. Jain. "Analysis of the Increase and Decrease Algorithms for Congestion Avoidance in Computer Network. Computer Networks and ISDN Systems", 1989. [14] Elan Amir, Hari Balakrishnan, Srinivasan Seshan and Randy Katz, "Improving TCP/IP performance over wireless networks" Proc. 1st ACM Int'l Conf on Mobile Computing and Networking (Mobicom), November 95. [15] "Network advanced modeling in NS-2", Giovanni Perbellini, 2005. [16] Kevin Fall and Kannan Varadhan “The NS Manual”. Jnly 23, 2008 -80- [17] Miguel A. Labrador. Pedro M. Wightman “Topology Control in Wireless Sensor Networks” [18] Xylomenos&polyzos (2001) "TCP Performance Issues Over Wireless Link" [19] Balakrishnan (1997) "A Comparison of Mechanisms for Improving TCP Performance over Wireless Links" [20] Jacobson (1988) "Congestion Avoidance and Control " [21] Fall&Floyd (1996) "Simulation-based Comparisons of Tahoe, Reno, SACK TCP" [22] Bikram S.Bakshi, P.Krishna, N.H.Vaidya, D.K.Pradhan "Improving Performance of TCP over Wireless Networks" [23] Các Website tiếng Việt. - - - - - - [24] Các Website tiếng Anh - (Wireless Networking in the Developing World) - - index.html - - - -