Đánh giá thông lượng của các giao thức định tuyến trong mạng Ad hoc

ến từ các thủ tục khám phá tuyến trước đó hoặc là từ việc nghe lỏm được các thông tin định tuyến từ các gói tin khác) thì nó sẽ gửi ngay gói tin sử dụng tuyến mới đó. Nếu không nó sẽ thực hiện một thủ tục khám phá tuyến mới tới đích E nói trên AD HOC ON- DEMAND DISTANCE VECTOR ROUTING (AODV) AODV cho phép định tuyến nhiều bước giữa các nút mạng để thiết lập và duy trì mạng Ad hoc. AODV dựa trên thuật toán vector khoảng cách nhưng thuộc loại định tuyến theo yêu cầu, nó chỉ yêu cầu đường định tuyến khi cần thiết. Thuật toán định tuyến AODV khá phù hợp cho cấu hình mạng động. AODV đưa ra các tuyến không bị lặp ngay cả khi nó đang sửa các liên kết lỗi. Bởi vì giao thức này không yêu cầu quảng bá tuyến định kỳ trên toàn mạng, nên yêu cầu toàn bộ băng thông có sẵn cho một nút di động thực chất là thấp hơn so với các giao thức khác, những giao thức yêu cầu quảng bá. AODV sử dụng liên kết đối xứng giữa các hàng xóm. Gói tin không đi theo tuyến đường giữa các nút khi một trong những nút đó không nghe được từ các nút khác. Những nút không nằm trên các tuyến đường hoạt động; chúng sẽ không duy trì bất cứ thông tin định tuyến nào cũng như không tham gia vào bất kỳ sự trao đổi bảng định tuyến định kỳ nào. Hơn nữa, một nút không phải khám phá và duy trì một tuyến tới nút khác cho tới khi hai nút cần giao tiếp với nhau, trừ khi nút đó đóng vai trò như một trạm chuyển tiếp trung gian để duy trì kết nối giữa hai nút khác . Khi một kết nối cục bộ của nút di động được thiết lập, mỗi nút có thể nhận thấy các nút khác trong vùng lân cận của nó bằng một vài kĩ thuật, bao gồm quảng bá cục bộ các bản tin Hello. Bảng định tuyến của các nút trong vùng lân cận được tạo ra để tối ưu thời gian đáp ứng tới với sự di chuyển cục bộ và cung cấp thời gian đáp ứng nhanh cho các yêu cầu thiết lập tuyến mới. Mục tiêu chính của thuật toán AODV: Gửi broadcast các gói tin khám phá tuyến khi cần thiết. Phân biệt giữa phát hiện-quản lý kết nối cục bộ trong vùng lân cận với duy trì topo mạng chung. Quảng bá thông tin về sự thay đổi kết nối cục bộ tới các nút hàng xóm mà thực sự cần thông tin. AODV sử dụng một cơ chế Khám phá tuyến với sự cải biến của thuật toán DSR. Thay vì định tuyến nguồn, AODV tin tưởng vào sự thiết lập động các entry trong Bảng định tuyến ở các nút trung gian. AODV sử dụng số thứ tự ở nút mạng đích để giúp cho tuyến đường luôn cập nhật và không hình thành đường định tuyến khép kín. Hơn nữa, AODV cũng hỗ trợ định tuyến multicast và giải quyết được vấn đề đếm vô hạn trong thuật toán Bellman Ford. Khám phá tuyến Quá trình Khám phá tuyến được khởi tạo bất cứ khi nào một nút nguồn muốn giao tiếp với các nút mạng khác nhưng nó lại không có thông tin định tuyến trong Bảng định tuyến của nó. Mỗi nút duy trì hai bộ đếm: số thứ tự nút và broadcast ID. Nút nguồn khởi tạo Khám phá tuyến bằng cách quảng bá gói tin RREQ tới hàng xóm của nó. RREQ chứa các trường sau: Trong đó: source _addr: địa chỉ nguồn source sequence: số thứ tự nguồn broadcast_id: định danh của RREQ dest_addr: địa chỉ đích dest sequence: số thứ tự đích hop_cnt : số chặng Cặp được xác định duy nhất với mỗi bản tin RREQ. broadcast_id được tăng lên khi nút nguồn khởi tạo một RREQ mới. Mỗi nút hàng xóm khi nhận được bản tin RREQ sẽ gửi lại một bản tin RREP tới nút nguồn nếu nó biết một tuyến tới đích, hoặc tiếp tục quảng bá bản tin RREQ tới nút hàng xóm sau khi tăng hop_cnt. Chú ý rằng mỗi nút có thể nhận được nhiều bản sao của cùng một RREQ từ các hàng xóm. Khi một nút trung gian nhận được một RREQ, nếu nó đã nhận RREQ với cùng broadcast_id và địa chỉ đích, nó sẽ loại bỏ RREQ đó và không chuyển tiếp gói tin đó nữa. Nếu một nút không thể đáp ứng được RREQ, nó sẽ theo dõi các thông tin sau để thiết lập tuyến đường ngược cũng như thiết lập tuyến đường thuận để dành cho việc truyền gói tin RREP. Địa chỉ IP đích Địa chỉ IP nguồn Broadcast ID Thời gian hết hạn của entry tuyến đường ngược Số thứ tự của nút nguồn Thiết lập tuyến đường ngược Có hai số thứ tự được chứa trong một bản tin RREQ: số thứ tự nguồn và số thứ tự đích cuối cùng được biết bởi nguồn. Số thứ tự nguồn được sử dụng để duy trì thông tin mới về tuyến đường ngược tới nguồn, và số thứ tự đích chỉ ra rằng tuyến đường tới đích phải mới như thế nào để nó có thể được chấp nhận bởi nguồn. Khi bản tin RREQ được gửi từ nút nguồn tới các nút đích khác nhau, nó sẽ tự động thiết lập các tuyến đường ngược từ tất cả các nút đó tới nút nguồn. Để thiết lập tuyến đường ngược, mỗi nút phải ghi lại địa chỉ của hàng xóm mà từ đó nó nhận được bản sao đầu tiên của RREQ. Các entry tuyến đường ngược được duy trì trong khoảng thời gian vừa đủ để bản tin RREQ có thể truyền trên mạng và trả lời lại tới nút gửi. Hình 2.7 Thiết lập tuyến đường đi ngược Thiết lập tuyến đường thuận Cuối cùng, bản tin RREQ sẽ đến được một nút biết được tuyến tới nút đích. Đầu tiên, nút nhận được bản tin RREQ sẽ kiểm tra để chắc chắn rằng bản tin RREQ đã được nhận trên một liên kết hai chiều. Nếu một nút trung gian có một entry tuyến tới đích yêu cầu, nó so sánh số thứ tự đích trong entry tuyến của chính nó với số thứ tự đích trong bản tin RREQ để xác định xem tuyến đó có dùng được hay không. Nếu số thứ tự đích trong bản tin RREQ lớn hơn, nút trung gian sẽ không sử dụng tuyến trong bảng entry tuyến của nó để đáp ứng RREQ. Khi đó, nút trung gian sẽ tiếp tục quảng bá RREQ. Các nút trung gian chỉ trả lời khi số thứ tự đích trong bảng entry của nó lớn hơn so với trong bản tin RREQ. Nếu nút trung gian có một tuyến hiện hành tới nút đích và nếu bản tin RREQ này chưa được nhận trước đó, nút sẽ gửi unicast một bản tin RREP tới hàng xóm mà từ đó nó nhận được RREQ. Một bản tin RREP chứa các thông tin sau: Trong khi một gói tin quảng bá tới một nút có tuyến tới đích, một tuyến đường ngược được thiết lập tới nút nguồn của gói tin RREQ. Khi RREP trở lại nút nguồn, mỗi nút dọc theo tuyến đường thiết lập một con trỏ thuận tới nút mà từ đó RREP đến, cập nhật thông tin timeout cho các entry tới nút nguồn và nút đích, ghi lại số thứ tự đích mới nhất cho tuyến được yêu cầu. Thiết lập tuyến đường thuận khi RREP từ nút đích D tới nút nguồn S. Nút không nằm trên tuyến được xác định bởi RREP sẽ hết hạn sau ACTIVE_ROUTE_TIMEOUT (3000ms) và sẽ xóa con trỏ ngược. Một nút nhận RREP sẽ truyền RREP đầu tiên về nút nguồn. Nếu một nút nhận nhiều hơn một RREP, nó sẽ cập nhật thông tin định tuyến của nó và truyền RREP chỉ khi RREP có số thứ tự đích lớn hơn hoặc bằng RREP trước đó với một số chặng nhỏ hơn. Nó sẽ loại bỏ hết các RREP khác mà nó nhận được. Điều này giảm số lượng bản tin RREP truyền tới nút nguồn đồng thời đảm bảo rằng thông tin định tuyến là nhanh và mới nhất. Nút nguồn có thể truyền dữ liệu ngay sau khi nhận được RREP đầu tiên và sau đó có thể cập nhật thông tin định tuyến nếu nó học được một tuyến mới tốt hơn. Hình 2. 8 Thiết lập tuyến đường thuận Quản lý bảng định tuyến Gắn liền với các entry tuyến đường ngược là một bộ đếm thời gian, được gọi là “bộ đếm thời gian hết hạn RREQ”. Mục đích của bộ đếm thời gian này là để thanh lọc những entry tuyến đường ngược từ những nút không nằm trên tuyến đường từ nguồn tới đích. Thời gian hết hạn phụ thuộc vào kích thước của mạng Ad hoc. Một thông số quan trọng khác gắn với entry định tuyến là thời gian timeout của các tuyến đang được lưu giữ, hay thời gian mà sau đó tuyến đường này coi như hết hiệu lực. Trong mỗi entry Bảng định tuyến, địa chỉ của nút hàng xóm mà gói tin đi qua để đến đích cũng được duy trì. Một nút được coi là hoạt động đối với đích đó khi nó tạo ra hay chuyển tiếp ít nhất một gói tin tới đích đó trong khoảng thời gian timeout . Thông tin này được duy trì để tất cả các nút nguồn có thể được thông báo khi có một liên kết bị đứt. Mỗi nút duy trì một entry cho mỗi đích cần đến. Mỗi entry chứa các thông tin sau: Đích Next hop Số chặng Số thứ tự đích Các hàng xóm còn hoạt động cho đích đó Thời gian hết hạn cho entry bảng định tuyến Mỗi khi một entry tuyến được dùng để truyền gói tin dữ liệu từ nguồn tới đích, timeout cho entry đó sẽ được reset tới thời gian hiện tại cộng thêm timeout. Nếu một tuyến mới được yêu cầu cho một nút di động, các nút di động so sánh số thứ tự đích của tuyến mới với tuyến hiện tại. Nếu số thứ tự tuyến mới cao hơn, nó sẽ được chọn, nếu bằng nhau thì tuyến mới sẽ được chọn khi có metric nhỏ hơn (số chặng ít hơn) tới đích. Cập nhật đường định tuyến Khi một nút mạng phát hiện đường định tuyến đến nút bên cạnh không hoạt động, nó sẽ xóa trong bảng định tuyến và gửi một bản tin Liên kết hỏng RERR. AODV sử dụng danh sách nút mạng bên cạnh còn hoạt động để ghi nhớ nút mạng đang sử dụng đường định tuyến trong bảng định tuyến. Nút mạng nhận được bản tin này cũng sẽ lặp lại quá trình gửi bản tin. Cuối cùng bản tin cũng đến được gửi đến tất cả nút mạng có liên quan, từ đó chúng có thể dừng việc gửi thông tin hoặc yêu cầu đường định tuyến mới thông qua bản tin RREQ. DYNAMIC MANET ON- DEMAND (DYMO) DYMO là giao thức định tuyến theo bảng mới nhất, hiện vẫn đang được phát triển bới MANET trong IETF. DYMO có thể coi là sự kết hợp của AODV và DSR. Mục tiêu của nó là thiết kế đơn giản, giảm thiểu yêu cầu hệ thống , đơn giản hóa việc thực thi giao thức. Một mặt, DYMO cũng sử dụng số thứ tự để đàm bảo tránh lặp tuyến, mặt khác, DYMO đưa ra các đặc tính mới như là thực hiện tính toán tuyến đường. Bên cạnh thông tin tuyến đường về một mục tiêu được yêu cầu, một nút cũng nhận được thông tin về tất cả các nút trung gian nằm trên một tuyến đường mới khám phá được. Đây là một khác biệt cơ bản giữa DYMO và AODV, trong đó thì AODV chỉ tạo ra entry bảng định tuyến cho nút đích và nút next-hop, còn DYMO thì lưu trữ tuyến đường cho mỗi nút trung gian. Điều này được thể hiên qua hình 2.9. Hình 2.9: Sự khác nhau giữa AODV và DYMO Khi sử dụng AODV, một nút A chỉ biết đường tới B và D sau khi Yêu cầu tuyến được đáp ứng. Trong DYMO, nút A cũng biết cả đường tới C. DYMO có thể thiết lập và duy trì các tuyến đường unicast trong các kịch bản mạng IPv4 và IPv6 bằng cách sử dụng cơ chế sau: Nhằm phát hiện một tuyến mới đến một nút đích, một nút gửi một bản tin Yêu cầu tuyến RREQ tới tất cả hàng xóm trong phạm vị truyền sóng của nó. Điều này cũng nhận được bằng cách gửi bản tin tới 1 địa chỉ multicast cục bộ riêng. Khi một nút trung gian nhận được một RREQ nó thiết lập tuyến đường tới tất cả các nút mà gói tin đã đi qua. Sau đó nút sẽ gắn địa chỉ của chính nó vào bản tin và truyền bản tin tới tất cả các nút lân cận. Bằng cách này thì RREQ được quảng bả một cách hiệu quả trên mạng và cuối cùng là đến đích của nó. Đich đáp ứng RREQ bằng cách gửi unicast một bản tin Trả lời RREP trở về nút mà nó mà từ đó nó nhận được RREQ. Cũng như trong quá trình quảng bá RREQ, nút này lại gắn địa chỉ của nó và ghi chú tất cả các thông tin định tuyến có trong RREP. Cùng với thông tin định tuyến đã có được trước đó khi chuyển tiếp RREQ tương ứng, nút trung gian có khả năng gửi RREP trở về nút nguồn của RREQ. Nút này cũng sẽ biết được tuyến đường tới nút đích được yêu cầu, cũng như là đường tới mọi nút trung gian, và ngược lại. Một nút trung gian cũng có thể tạo ra RREP nếu như nó biết tuyến đường tới đích. Để phản ứng tốt với mạng có mức độ di chuyển cao, các liên kết trên tuyến đường đã biết được có thể được theo dõi, bằng cách sử dụng giao thức nhận biết hàng xóm (Neighboehood Discovery Protocol) hoặc kiểm tra phản hồi nhận được ở tầng data link. Một hệ thống cũng có thể lựa chọn không bật tính năng theo dõi, đơn giản chỉ xóa các tuyến không còn hoạt động. Khi một nút phát hiện liên kết lỗi, nó sẽ gửi một bản tin RERR để thông báo có tất cả các nút lân cận, thông báo cho chúng biết về tất cả các tuyến đị đứt. TỔNG KẾT Qua việc nghiên cứu một số giao thức trong mạng Ad hoc ta có thể thấy rằng chưa có giao thức nào có đầy đủ các tính năng và không thể khẳng định giao thức nào là tối ưu cho mạng Ad hoc. Tuy nhiên, chức năng chính của các giao thức là tìm được đường đi tới đích, không phải đường ngắn nhất hay đường tối ưu nhất được đáp ứng. CHƯƠNG 3 THÔNG SỐ ĐÁNH GIÁ VÀ MÔ HÌNH CHUYỂN ĐỘNG TRONG MÔ PHỎNG MẠNG AD HOC Như đã trình bày ở chương 2, giao thức định tuyến trong mạng Ad hoc đều tập trung giải quyết vấn đề và khái niệm đặc trưng của môi trường vô tuyến. Nhưng giao thức nào là tốt nhất, phù hợp nhất? Nó phụ thuộc vào cấu trúc và thuộc tính của mạng, mật độ nút mạng, mức độ di chuyển của nút mạng, kích cỡ môi trường, kiểu di chuyển của các nút mạng... THÔNG SỐ ĐÁNH GIÁ GIAO THỨC MẠNG AD HOC Có hai thông số để đánh giá: thông số đánh giá chất lượng và thông số kịch bản. Thông số đánh giá chất lượng Các thông số này được sử dụng để đưa ra chính xác những gì xảy ra trong quá trình mô phỏng và cung cấp các thông tin có giá trị về các giao thức định tuyến. Do đó, nó dành được nhiều sự quan tâm khi nghiên cứu giao thức định tuyến mô phỏng. Tỷ lệ gói nhận được Định nghĩa: Tỷ lệ gói nhận được RD là tỷ lệ giữa số gói nhận được bởi nút đích (PR) và số gói được gửi đi từ lớp ứng dụng của nút nguồn (PS). RD = PR / PS (CT 3.1) Ý nghĩa: giao thức định tuyến hoạt động tốt phải có giá trị RD cao do khả năng tận dụng băng thông vô tuyến là rất quan trọng. Thông số này phản ánh tỷ lệ gói tin bị mất, mức độ hoàn chỉnh và đúng đắn của giao thức định tuyến. Trễ từ đầu cuối đến đầu cuối Định nghĩa: Trễ từ đầu cuối đến đầu cuối là thời gian mà gói tin truyền trên mạng từ nút nguồn đến nút đích. Nó bao gồm nhiều giá trị nhỏ trên mạng: trễ bộ đệm, trễ chuyển tiếp gói tin ở nút trung gian, trễ truyền dẫn và thời gian để truyền lại gói tin (trong trường hợp gói tin bị mất). Có thể tính thời gian trễ theo hai cách: Tdelay = Trev – T send (CT 3.2) Hoặc: Tdelay = T buffer + Trelay + Tprop + Tresend (CT 3.3) Ý nghĩa: Trong mạng gói vô tuyến không có QoS thì giá trị trễ phụ thuộc vào giao thức định tuyến. Một thông số quan trọng là thời gian trễ trong bộ đệm, tức là gói tin được lưu giữ trong bộ đệm khi chưa có đường định tuyến đến đích trước khi bị hủy. Nếu như nút mạng đặt thời gian lớn thì ít gói tin trên mạng bị hủy, nhưng cũng có nghĩa trễ trung bình trong mạng cũng tăng lên. Và người thiết kế hệ thống sẽ quyết định: tỷ lệ gói hủy bỏ thấp hay thời gian trễ, điều này liên quan đến giá trị trễ đầu cuối đến đầu cuối. Thông lượng từ đầu cuối đến đầu cuối Định nghĩa: thông lượng là tỉ lệ giữa số gói tin dữ liệu được truyền trên một đơn vị thời gian. Ý nghĩa: Khi băng thông sẵn có trên mạng đã biết, thì trong mô phỏng băng thông thực sự có được là bao nhiêu? Thông số thông lượng T sẽ cho biết băng thông thực sự khi mô phỏng và có thể cho tháy sự hiệu quả của giao thức định tuyến ở mức độ nào. Khi thông lượng trung bình cao nghĩa là băng thông dành cho định tuyến là ít, khi đó giao thức định tuyến hoạt động tốt. Phần tải thông tin định tuyến Định nghĩa: là tỉ lệ giữa gói tin định tuyến được gửi đi với số gói dữ liệu được gửi tới đích. Ý nghĩa: Tải thông tin định tuyến là một thông số quan trọng với mạng Ad hoc, nó cũng cho biết hiệu năng sử dụng băng thông của giao thức định tuyến: bao nhiêu băng thông được sử dụng cho bản tin định tuyến, bao nhiêu băng thông được sử dụng cho các gói tin dữ liệu. Phần tải định tuyến trong giao thức định tuyến theo yêu cầu thông thường là lớn do nó phải gửi bản tin cập nhật định kỳ trên toàn mạng. Trường hợp lý tưởng là không có bản tin định tuyến, chỉ có gói tin dữ liệu được truyền trên mạng; tuy nhiên, nếu không có giao thức định tuyến thì không thể triển khai thực tế. Thông số kịch bản Các thông số kịch bản được tính toán từ dữ liệu đầu vào của mô phỏng, hoặc có thể là biến đầu vào (ví dụ như thời gian tạm dừng). Nó không phụ thuộc vào giao thức định tuyến hoặc quá trình mô phỏng cũng như các thông số đánh giá chất lượng mà ta nghiên cứu ở trên. Nó cung cấp sự so sánh thật nhất giữa các giao thức. Thông số di chuyển Nó đánh giá sự chuyển động trong mạng bằng cách tính toán di chuyển của nút mạng liên quan giữa các cặp nút trên mạng. Thông số này tương ứng với số thay đổi liên kết trong mô hình khi mà nút mạng di chuyển theo mô hình định trước. Bảng 3.1 Bảng các biến trong thông số di chuyển Tên biến Mô tả Dist(nx, ny)t Khoảng cách giữa nút X và nút Y ở thời điểm t n Số nút mạng i Chỉ số Ax(t) Khoảng cách trung bình giữa các nút x với các nút khác ở thời điểm t Mx Di chuyển trung bình của nút x với các nút trong thời gian mô phỏng T Thời gian mô phỏng Δt Bước thời gian mô phỏng Mod Di chuyển trong toàn bộ kịch bản [m/s] Bước 1: tính khoảng cách trung bình của các nút x với các nút khác trong mạng được thực hiện ở các thời điểm t=0, t= 0 + X, t=0 + 2X, ... t = T, theo công thức: (CT 3.4) Bước 2: Tính di chuyển của nút x theo công thức: (CT 3.5) Bước 3: Tính thông số di chuyển cho cả kịch bản: (CT 3.6) Thời gian tạm dừng Thời gian tạm dừng là một biến đầu vào của mô phỏng. Khi sử dụng như một thông số đánh giá, thời gian tạm dừng của tất cả các nút trong mô phỏng được sử dụng để đo kiểm thông số chuyển động. Khi giá trị trung bình càng lớn thì nút mạng càng ít di chuyển trong mạng. MÔ HÌNH DI CHUYỂN MÔ PHỎNG MẠNG AD HOC Trong mạng Ad hoc, nút mạng di chuyển từ vị trí này đến vị trí khác, nên khó khăn khi tìm ra mô hình di chuyển có thể cho mô phỏng. Để có thể mô phỏng giao thức định tuyến thì cần phải có sự phát triển và sử dụng “mô hình di chuyển” cho nút mạng, do đó việc xác định mô hình di chuyển là rất quan trọng. Mô hình di chuyển yêu cầu phải mô tả di chuyển của nút mạng giống như trong thực tế, cần có sự thay đổi về hướng và tốc độ di chuyển trong những khoảng thời gian hợp lý. Chắc chắn nút mạng thực không thể di chuyển theo đường thẳng với tốc độ không đổi trong suốt quá trình mô phỏng. Vận tốc có thể thay đổi và giảm đến 0, tương tự hướng di chuyển cũng sẽ thay đổi. Có rất nhiều mô hình áp dụng cho mạng Ad hoc, có thể tương ứng với từng ngữ cảnh kịch bản mô phỏng, trong giới hạn đồ án đề cập một số mô hình tiêu biểu. Mô hình di chuyển ngẫu nhiên Mô hình di chuyển ngẫu nhiên là mô hình di chuyển đơn giản dựa trên hướng và vận tốc ngẫu nhiên, trong đó vận tốc và hướng hiện tại của hai hay nhiều nút mạng hoàn toàn độc lập với giá trị cũ của chúng. Do đó, mô hình sẽ phải đối mặt với hiện tượng không giống thực tế: dừng đột ngột, có vòng quay nhọn, đường di chuyển quanh co hoàn toàn ngẫu nhiên. Để khắc phục vấn đề này, người ta có thể thay đổi mô hình bằng cách tính toán vận tốc hay hướng di chuyển hoặc cả hai. Mô hình di chuyển hướng ngẫu nhiên với vận tốc không đổi Đây là mô hình sửa đổi của mô hình di chuyễn ngẫu nhiên nhưng đảm bảo tất cả nút mạng được gán cho một vận tốc như nhau trong suốt quá trình mô phỏng. Sau khi hướng chọn một cách ngẫu nhiên trong khoảng (0, 2π), các nút bắt đầu di chuyển. Khi gặp biên của khu vực mô phỏng, nó nảy khỏi biên với một góc xác định bởi hướng đến, các nút di chuyển thao đường mới. Mô hình di chuyển Random Waypoint Mô hình này có sử dụng thời gian tạm dừng khi thay đổi hướng và vận tốc. Hai hay nhiều nút mạng ở một vị trí trong một khoảng thời gian (thời gian tạm dừng). Khi hết thời gian tạm dừng, nút mạng chọn ngẫu nhiên vận tốc trong khoảng (0, maxspeed) Hình 3.1 Mô hình di chuyển Random Waypoint Mô hình di chuyển hướng ngẫu nhiên Mô hình này khắc phục nhược điểm của mô hình Random Waypoint, do các nút trong mô hình Random Waypoint thường chọn các đích mới và xác suất chọn thường là trung tâm khu vực mô phỏng hoặc đường đi qua trung tâm khu vực mô phỏng. Khi các nút mạng có xu hướng hội tụ, phân tán... trong mô hình di chuyển hướng ngẫu nhiên, các nút chọn hướng thay vì chọn đích, sau đó nó di chuyển theo hướng đó đến biên của khu vực mô phỏng, ngay khi đến biên nó dừng lại trong một khoảng thời gian và chọn hướng khác (0, 180o) và tiếp tục quá trình . Hình 3.2 Mô hình di chuyển hướng ngẫu nhiên TỔNG KẾT Việc lựa chọn các thông số đánh giá giao thức và mô hình di chuyển là rất quan trọng. Thông qua các thông số đó, ta có thể đánh giá được điểm mạnh cũng như điểm yếu của một giao thức mạng. Qua đó, ta có thể lựa chọn được giao thức phù hợp cho những giả thiết và yêu cầu đặt ra. CHƯƠNG 4. MÔ PHỎNG VÀ ĐÁNH GIÁ THÔNG LƯỢNG CỦA AODV, OLSR, DSR VÀ DYMO BẰNG OMNET++ Chương này sẽ giới thiệu về công cụ để mô phỏng giao thức định tuyến mang Ad học, mô phỏng các giao thức định tuyến, giả thiết đầu vào cho quá trình mô phỏng. Kết quả mô phỏng và đánh giá, kết luận. GIỚI THIỆU CHUNG VỀ OMNET++ Tổng quan về Omnet++ Omnet ++ là gì ? OMNeT++ là viết tắt của cụm từ Objective Modular Network Testbed in C++. OMNeT++ là một ứng dụng cung cấp cho người sử dụng môi trường để tiến hành mô phỏng hoạt động của mạng. Mục đích chính của ứng dụng là mô phỏng hoạt động của mạng thông tin, tuy nhiên do tính phổ cập và linh hoạt của nó, OMNeT++ còn được sử dụng trong nhiều lĩnh vực khác như mô phỏng các hệ thống thông tin phức tạp, các mạng kiểu hàng đợi (queing networks) hay các kiến trúc phần cứng… OMNeT++ cung cấp sẵn các thành phần tương ứng với các mô hình thực tế. Các thành phần này (còn được gọi là các module) được lập trình theo ngôn ngữ C++, sau đó được tập hợp lại thành những thành phần hay những mô hình lớn hơn bằng một ngôn ngữ bậc cao (NED). OMNeT++ hỗ trợ giao diện đồ họa, tương ứng với các mô hình cấu trúc của nó đồng thời phần nhân mô phỏng (simulation kernel) và các module của OMNeT++ cũng rất dễ dàng nhúng vào trong các ứng dụng khác. Các thành phần chính của OMNeT++ Trong OMNeT++ có các thành phần chính sau: Thư viện phần nhân mô phỏng (simulation kernel) Trình biên dịch cho ngôn ngữ mô tả tình trạng (topology description language) – NED (nedc) Trình biên tập đồ họa (graphical network editor) cho các file NED (GNED) Giao diện đồ họa thực hiện mô phỏng, các liên kết bên trong các file thực hiện mô phỏng (Tkenv) Giao diện dòng thực hiện mô phỏng (Cmdenv) Công cụ (giao diện đồ họa) vẽ đồ thị kết quả vector ở đầu ra (Plove) Công cụ (giao diện đồ họa) mô tả kết quả vô hướng ở đầu ra (Scalars)Công cụ tài liệu hóa các mô hình Các tiện ích khác Các tài liệu hướng dẫn, các ví dụ mô phỏng… Ứng dụng OMNeT++ là một công cụ mô phỏng các hoạt động mạng bằng các module được thiết kế hướng đối tượng. OMNeT++ thường được sử dụng trong các ứng dụng chủ yếu như: Mô hình hoạt động của các mạng thông tin Mô hình giao thức Mô hình hóa các mạng kiểu hàng đợi Mô hình hóa các hệ thống đa bộ vi xử lý (multiprocessor) hoặc các hệ thống phần cứng theo các mô hình phân tán khác (distributed hardware systems) Đánh giá kiến trúc phần cứng Đánh giá hiệu quả hoạt động của các hệ thống phức tạp… Mô hình trong OMNeT++ Một mô hình trong OMNeT++ bao gồm các module lồng nhau có cấu trúc phân cấp. Độ sâu của các module lồng nhau là không giới hạn, điều này cho phép người sử dụng có thể biểu diễn các cấu trúc logic của các hệ thống trong thực tế bằng các cấu trúc mô hình. Các module trao đổi thông tin với nhau thông qua việc gửi các message. Các message này có thể có cấu trúc phức tạp tùy ý. Các module có thể gửi các message này theo hai cách, một là gửi trực tiếp tới địa chỉ nhận, hai là gửi đi theo một đường dẫn được định sẵn, thông qua các cổng và các kết nối. Các module có thể có các tham số của riêng nó. Các tham số này có thể được sử dụng để chỉnh sửa các thuộc tính của module và để biểu diễn cho topology của mô hình. Các module ở mức thấp nhất trong cấu trúc phân cấp đóng gói các thuộc tính. Các module này được coi là các module đơn giản, và chúng được lập trình trong ngôn ngữ C++ bằng cách sử dụng các thư viện mô phỏng. Một mô hình trong OMNeT++ chứa các module lồng nhau có cấu trúc phân cấp, trao đổi thông tin với nhau bằng cách gửi các message. Mỗi mô hình này thường biểu diễn cho một hệ thống mạng. Module mức cao nhất trong cấu trúc phân cấp được gọi là module hệ thống. Module này có thể chứa các module con, các module con cũng có thể chứa các module con của riêng nó. Độ sâu phân cấp đối với các module là không giới hạn, điều này cho phép người sử dụng có thể dễ dàng biểu diễn một cấu trúc logic của một hệ thống trong thực tế bằng cấu trúc phân cấp của OMNeT++. Cấu trúc của mô hình có thể được mô tả bằng ngôn ngữ NED của OMNeT++ Hình 4.1 Các module đơn giản và kết hợp Các module có thể chứa nhiều module con và được gọi là module kết hợp. Các module đơn giản là các module có cấp thấp nhất trong cấu trúc phân cấp. Các module đơn giản chứa các thuật toán của mô hình. Người sử dụng triển khai các module đơn giản bằng ngôn ngữ C++, sử dụng các thư viện mô phỏng của OMNeT++. Các module trao đổi thông tin bằng việc gửi các message. Trong thực tế, message có dạng khung (frame) hoặc là các gói tin (packet) được truyền đi trong mạng. Các message có thể có cấu trúc phức tạp tùy ý. Các module đơn giản có thể gửi các message đi một cách trực tiếp đến vị trí nhận hoặc gửi đi theo một đường dẫn định sẵn thông qua các cổng (gates) và các liên kết (links). Các cổng (gates) là các cổng vào, ra của các module. Message được gửi đi qua các cổng ra và được nhận vào thông qua các cổng vào. Mỗi kết nối (connection) hay còn gọi là liên kết (link) được tạo bên trong một mức đơn trong cấu trúc phân cấp của các module: bên trong một module kết hợp, một kết nối có thể được tạo ra giữa các cổng tương ứng của hai module con, hoặc giữa cổng của module con với cổng của module kết hợp. Hình 4.2 Các kết nối Tương ứng với cấu trúc phân cấp của một mô hình, các message thường di chuyển qua một loạt các kết nối với điểm bắt đầu và kết thúc là các module đơn giản. Tập các kết nối đi từ một module đơn giản và đến một module đơn giản được gọi là route. Sử dụng OMNeT++ Xây dựng và chạy thử các mô hình mô phỏng a. Một mô hình OMNeT++ bao gồm những phần sau Ngôn ngữ mô tả topology – NED (file có phần mở rộng .ned): mô tả cấu trúc của module với các tham số, các cổng… Các file.ned có thể được viết bằng bất kỳ bộ soạn thảo hoặc bất kỳ bộ soạn thảo hoặc sử dụng chương trình GNED có trong OMNeT++ Định nghĩa cấu trúc của các message (các file có phần mở rộng .msg): Người sử dụng có thể định nghĩa rất nhiều kiểu message và thêm các trường dữ liệu cho chúng. OMNeT++ sẽ dịch những định nghĩa này sang các lớp C++ đầy đủ. Mã nguồn của các module đơn giản. Đây là các file C++ với phần mở rộng là .h hoặc .cc. b. Hệ thống mô phỏng cung cấp cho ta các thành phần sau Phần nhân mô phỏng. Phần này chứa code để quản lý quá trình mô phỏng và các thư viện lớp mô phỏng. Nó được viết bằng C++, được biên dịch và được đặt cùng dạng với các file thư viện (các file có phần mở rộng là .a hoặc .lib). Giao diện người sử dụng. Giao diện này được sử dụng khi thực hiện quá trình mô phỏng, tạo sự dễ dàng cho quá trình sửa lỗi, biểu diễn (demonstration) hoặc khi thực hiện mô phỏng theo từng khối (batch execution of simulations). Có một vài kiểu giao diện trong OMNeT++, tất cả đều được viết bằng C++, được biên dịch và đặt cùng nhau trong các thư viện (các file có phần mở rộng là .a hoặc .lib) c. Thực hiện mô phỏng và phân tích kết quả Các chương trình thực hiện mô phỏng (the simulation executable) là các chương trình độc lập, tức là nó có thể chạy trên các máy khác không cài đặt OMNeT++ hay các file mô hình tương ứng. Khi chương trình khởi động, nó bắt đầu đọc file cấu hình (thông thường là file omnetpp.ini). File này chứa các thiết lập để điều khiển nhiều quá trình mô phỏng, trong trường hợp đơn giản nhất là các quá trình mô phỏng này sẽ được thực hiện lần lượt bởi một chương trình mô phỏng (simulation program). Đầu ra của quá trình mô phỏng là các file dữ liệu. Các file này có thể là các file vector, các file vô hướng hoặc các file của người sử dụng. OMNeT++ cung cấp một công cụ đồ họa Plove để xem và vẽ ra nội dung của các file vector. Tuy nhiên chúng ta cũng nên hiểu rằng khó mà có thể xử lý đầy đủ các file kết quả mà chỉ dùng riêng OMNeT++; các file này đều là các file có định dạng để có thể đọc được bởi các gói xử lý toán học của các chương trình như Matlab hay Octave, hoặc có thể được đưa vào tính của các chương trình như OpenOffice Calc, Gnumeric hay Microsoft Excel. Tất cả các chương trình này đều có chức năng chuyên dụng trong việc phân tích số hóa, vẽ biểu diễn (visualization) vượt qua khả năng của OMNeT++. Các file vô hướng cũng có thể được biểu diễn bằng các công cụ Scalar. Nó có thể vẽ được các biểu đồ, các đồ thị dựa vào tập hợp các tọa độ (x,y) và có thể xuất dữ liệu vào clipboard để có thể sử dụng trong các chương trình khác nhằm đưa những phân tích chi tiết hơn. d. Giao diện người sử dụng Mục đích chính của giao diện người sử dụng là che những phần phức tạp bên trong cấu trúc của các mô hình đối với người sử dụng, dễ dàng điều khiển quá trình mô phỏng, và cho phép người sử dụng có khả năng thay đổi các biến hay các đối tượng bên trong của mô hình. Điều này là rất quan trọng đối với pha phát triển và sửa lỗi trong dự án. Giao diện đồ họa cũng có thể được sử dụng để trình diễn hoạt động của mô hình. Cùng một mô hình người sử dụng có thể trên nhiều giao diện khác nhau mà không cần phải thay đổi gì trong các file mô hình. Người sử dụng có thể kiểm thử và sửa lỗi rất dễ dàng qua giao diện đồ họa, cuối cùng có thể chạy nó dựa trên một giao diện đơn giản và nhanh chóng có hỗ trợ thực hiện theo khối (batch execution) e. Các thư viện thành phần Các kiểu module có thể được lưu tại những vị trí độc lập với chỗ mà chúng thực sự được sử dụng. Đặc điểm này cung cấp cho người sử dụng khả nhóm các kiểu module lại với nhau và tạo ta các thư viện thành phần. f. Các chương trình mô phỏng độc lập Các chương trình thực hiện quá trình mô phỏng có thể được lưu lại nhiều lần, không phụ thuộc vào các mô hình, sử dụng cùng một thiết lập cho các module đơn giản. Người sử dụng có thể chỉ ra trong file cấu hình mô hình nào sẽ được chạy. Điều này tạo khả năng cho người sử dụng có thể xây dựng những chương trình thực hiện lớn bao gồm nhiều quá trình mô phỏng, và phân phối nó như một công cụ mô phỏng độc lập. Khả năng linh hoạt của ngôn ngữ mô tả topology cũng hỗ trợ cho hướng tiếp cận này. Chạy các ứng dụng trong OMNeT++ Như đã trình bày ở phần mở đầu, một hệ thống mạng mô phỏng trong OMNeT++ gồm các thành phần sau: Các file.ned mô tả topo mạng. Các file có phần mở rộng .msg chứa khai báo các message. Các file C++ (có phần mở rộng là .cc trong UNIX hoặc .cpp trong Windows) Quá trình xây dựng một chương trình mô phỏng Đầu tiên, dịch các file NED và các file message thành C++, sử dụng NED compiler (nedc) và message compiler (opp_msgc). Quá trình tiếp theo giống như biên dịch mã nguồn C/C++ Trong Linux: các file .cc → file.o. Trong Windows: các file .cpp → file .obj. Sau đó tất cả các file trên sẽ được liên kết (link) với các thư viện cần thiết để tạo thành file .exe. Cụ thể ta cần phải liên kết với các thư viện sau: Phần nhân mô phỏng được gọi là sim_std (như các file libsim_std.a, sim_std.lib, etc) Giao diện người dùng: cung cấp thư viện môi trường (file libenvir.a, etc) và các tiện ích tkenv và cmdenv (libtkenv.a, libcmdenv.a, etc). Các file .o (hoặc .obj) phải được liên kết tới thư viện môi trường cùng với hoặc tkenv hoặc cmdenv. Hình dưới đây cho chúng ta hình ảnh quá trình xử lý khi mô hình được xây dựng và hoạt động File mô tả cấu trúc mạng *.ned File xử lý của simple modules *.cc Thư viện lõi của chương trình mô phỏng *.lib / *.a Thư viện giao diện người dùng *.lib / *.a File mô tả cấu trúc mạng sau khi dịch *_n.cc C++ compiling Linking Chương trình mô phỏng Chạy chương trình File cấu hình Omnetpp.ini File kết quả *.vec, *.sna, *.sca NEDC compling Hình 4.3 Lược đồ xây dựng và chạy một chương trình mô phỏng OMNeT++ *.ned là các file mô tả topo mạng cũng như cấu trúc của các modul, nó sự dụng ngôn ngữ NED (Nework Description ), là ngôn ngữ chuyên biệt dùng riêng cho OmNet++. Sự phát triển tiếp theo của NED là GNED (Graphic NED) làm cho việc mô tả topo mạng được trực quan hơn bằng cách dùng các công cụ đồ hoạ để mô tả. Các file ned sau đó được NEDC (NED compiler) dich sang code C++ để mô tả cấu trúc mạng sang ngôn ngữ C++ dưới dạng file *_.cc. Các file xử lý của các simple moduls là phần cốt lõi khi viết chương trình mô phỏng và được viết bằng ngôn ngữ C++ bằng cách kế thừa các lớp có sẵn của OmNet++, người viết triển khai các hoạt động của mạng như định tuyến, xử lí gói tin đến và đi, xác định hành vi của các simple modul được mô tả trong *.ned khi có sự kiện xảy ra với nó…. Thư viện lõi của chương trình mô phỏng được cung cấp bởi OmNet++, nó bao gồm rất nhiều các lớp và các hàm có sẵn phục vụ cho chương trình mô phỏng như các lớp cSimplemodul, cMessage..., các hàm ngẫu nhiên… Thư viện giao diện người dùng cung cấp giao diện cho chương trình mô phỏng. OmNet++ với các phiên bản gần đây sử dụng hai kiểu giao diện là giao diện dòng lệnh cmd (command) và giao diện đồ hoạ dựa trên tcl/tk. Giao diện đồ hoạ rất trực quan nên được ưa dùng hơn. Sau khi dịch và liên kết ta được một chương trình mô phỏng dựa trên nền OmNet++. File omnetpp.ini để khởi động các giá trị cần thiết. omnetpp.ini do người lập trình viết, nó rất quan trọng để chạy một chương trình mô phỏng với các tham số được thay đổi để có được kết quả thống kê mong muốn. Cuối cùng là các file kết quả bao gồm file *.vec là các file vector, nó là các biến thay đổi theo thời gian trong quá trình mô phỏng, giá trị của biến và thời gian tương ứng được lưu vào file này. Trong quá trình viết code sẽ xác định biến nào được lưu. File *.sna phục vụ cho quá trình sửa lỗi. File *.sca (scalar file) lưu các giá trị thống kê có được sau khi kết thúc mô phỏng, ví dụ như số cuộc gọi đã thực hiện số cuộc gọi bị từ chối… Để xử lí kết quả thống kê đạt được, ta có thể viết một chương trình nhỏ hoặc sử dụng các công cụ có sẵn. OmNet++ cung cấp chương trình Plove để vẽ các file *.vec, còn đối với các file *.sca ta có thể dùng một chương trình tính toán bất kì. MÔ PHỎNG Khởi tạo mô phỏng Trong tất cả các kịch bản mô phỏng, đồ án sử dụng mô hình di chuyển Random Waypoint với các thông số sau: Vận tốc tối đa speedmax: ở bất kỳ thời điểm nào vận tốc có giá trị ngẫu nhiên trong khoảng [0, speedmax]. Số nút mạng: giá trị này không thay đổi trong toàn bộ quá trình mô phỏng, đồ án sử dụng 25 nút mạng trong kịch bản mô phỏng. Kích cỡ môi trường mô phỏng: đồ án sử dung khu vực mô phỏng 500x500m cho toàn bộ kịch bản mô phỏng. Thời gian mô phỏng : 300s cho tất cả kịch bản mô phỏng. Thời gian tạm dừng: thay đổi với các giá trị 0, 100, 200, 300. Một số hình ảnh mô phỏng Sau đây là tuần tự các quá trình của DYMO: Khám phá tuyến bằng cách gửi RREQ, gửi bản tin RREP, gửi gói tin dữ liệu, và gửi ACK báo nhận. Trước khi gửi gói tin tới một đích, môt nút sẽ kiểm tra trong Bộ nhớ tuyến của nó có tuyến tới đích đó hay không. Nếu không có, nó sẽ gửi bản tin RREQ để Khám phá tuyến (hình 4.4). Hình 4.4 Quá trình gửi bản tin RREQ của DYMO Các nút nhận được bản tin RREQ, nếu nút đó là đích hoặc biết môt tuyến đường tới đích, nó sẽ gửi lại bản tin RREP về nguồn (hình 4.5) Hình 4.5 Quá trình gửi bản tin RREP của DYMO Như vậy, nút nguồn đã có một tuyến tới đích và nó thực hiện quá trình gửi gói tin dữ liệu hình (hình 4.6). Hình 4.6 Quá trình gửi gói tin dữ liệu của DYMO Nút đích nhận được gói tin dữ liệu, nó sẽ gửi ACK tới nút nguồn để xác nhận nó đã nhận được gói từ nút nguồn (hình 4.7). Hình 4.7 Quá trình gửi ACK báo nhận của DYMO Kết quả mô phỏng các giao thức định tuyến mạng Ad hoc Bảng 4.1 Bảng thông số đánh giá dùng trong mô phỏng Thông số Giá trị Phạm vi truyền dẫn 250m Băng thông 54Mbps (802.11g) Thời gian mô phỏng 300s Kích thước môi trường mô phỏng 500m x 500m Loại lưu lượng CBR Tốc độ gửi gói tin 4 packet/s Kích thước gói tin 512 bytes Số nút 25 Số nguồn gửi gói tin 5 Tốc độ tối đa 20m/s Kịch bản là một phần rất quan trọng trong mô phỏng, ở đây đồ án đưa ra 4 giá trị cần đo cho thời gian tạm dừng của nút mạng: 0, 100, 200, 300. Thời gian tạm dừng bằng 0, nút mạng chuyển động liên tục; thời gian tạm dừng bằng 300, nút mạng coi như đứng yên (không chuyển động). Các nút bắt đầu gửi gói tin dữ liệu sau 60s (mạng hội tụ). Thông lượng đầu cuối - đầu cuối Hình 4.9 Thông lượng đầu cuối - đầu cuối Qua biểu đồ thông lượng ta nhận thấy thông lượng tỷ lệ thuận với gói nhận. Thông lượng của DYMO là cao nhất do DYMO là giao thức định tuyến hoạt động theo yêu cầu hoặc theo bảng điều khiển,là sự tối ưu của DSR và AODV.Khi các nút mạng chuyển động liên tục,thông lượng của DYMO vẫn rất cao Thông lượng của OLSR cao hơn AODV và DSR vì OLSR có thể đáp ứng khi topo mạng thay đổi, nó cho phép khám phá tuyến nhanh chóng tới các hàng xóm và các MPR của chúng để thiết lập kết nối với các nút khác Khi mức độ di chuyển tăng (giảm pausetime) thì thông lượng của 3 giao thức DSR, AODV, OLSR giảm rõ rệt với mức giảm tương đương nhau.Trong khi đó thì DYMO thể hiện được sự ổn định của mình khi có thông lượng khá cao.OLSR có thông lượng cao hơn AODV và DSR Đánh giá và kết luận Trong môi trường kích cỡ trung bình và số lượng nút nhỏ, khi mật độ di chuyển, hay tốc độ phát gói tăng dần thì DYMO là giao thức hoạt động khá ổn định khi có tỉ lệ gói nhận cao hơn so với các giao thức khác. Tuy nhiên, theo một số kết quả nghiên cứu cho thấy DYMO lại tạo ra khá nhiều bản tin định tuyến so với AODV và DSR. Do vậy, không thể khẳng định DYMO là một giao thức tối ưu. Hiện nay chưa có một giao thức nào có thể đáp ứng đầy đủ yêu cầu với một giao thức định tuyến trong mạng Ad hoc. Các giao thức cần được cải tiến hơn nữa để có thể đáp ứng được cho mạng Ad hoc đồng thời hỗ trợ multicast, QoS, bảo mật… CHƯƠNG 5. KẾT LUẬN Mạng Ad hoc hiện đang tham gia vào mọi mặt của cuộc sống và hứa hẹn sẽ phát triển mạnh mẽ trong tương lai. Do là một phần công nghệ của mạng không dây nên mạng Ad hoc được thừa hưởng nhiều ưu điểm của mạng không dây hiện nay và đồng thời cũng có những ưu thế đặc biệt mà các mạng khác không có. Đồ án là sự nhìn nhận tổng quan về mạng Ad hoc. Ngoài ra, đồ án cũng tập trung vào nghiên cứu các giao thức định tuyến mạng Ad hoc hiện nay, cụ thể là bốn giao thức DYMO, DSR, AODV, OLSR. Đồng thời sử dụng công cụ mô phỏng OMNET++ để phân tích đánh giá chất lượng giao thức định tuyến mạng Ad hoc (DYMO, DSR, AODV, OLSR). Qua đó, chúng ta thấy được thế mạnh và hạn chế của từng loại giao thức; không có giao thức nào đáp ứng đủ tiêu chuẩn mạng Ad hoc về mặt QoS, bảo mật. Mạng Ad hoc vẫn còn là một công nghệ mới trong vài năm gần đây ở Việt Nam và chưa có nhiều kết quả thử nghiệm, đánh giá về nó. Do đó, việc tham gia rất hạn chế, với người nghiên cứu chỉ có cách dùng mô phỏng. Chính vì vậy, định hướng phát triển của em là ngoài việc nghiên cứu lí thuyết, sẽ tìm hiểu sâu hơn về công cụ mô phỏng OMNET++ để có kết quả mô phỏng chính xác và đầy đủ. Đồng thời em sẽ đi sâu tìm hiểu về khả năng triển khai mạng Ad hoc vào thực tiễn tại Việt Nam. Trong tương lai, em mong muốn sẽ tiếp tục nghiên cứu về vấn đề này cũng như phát triển mở rộng nó. Cũng do thời gian nghiên cứu nên không tránh khỏi thiếu sót, em rất mong nhận được sự nhận xét, đóng góp ý kiến của các thầy cô trong bộ môn cũng như trong khoa để đồ án của em và những nghiên cứu sau này sẽ còn thành công hơn nữa. Một lần nữa em xin chân thành cảm ơn thầy Nguyễn Trung Dũng – Bộ môn Hệ thống viễn thông – Khoa Điện tử viễn thông – Trường Đại học Bách Khoa Hà Nội đã nhiệt tình hướng dẫn, chỉ bảo và định hướng cho chúng em thực hiện thành công đồ án. Hà Nội, tháng 5 năm 2009. Sinh viên Vũ Huy Cường TÀI LIỆU THAM KHẢO [1] Subir Kumar Sarkar, T G Basavaraju, C Puttamadappa, “Ad hoc Mobile Wireless Network Principles, protocols, and Applications”, Auerbach Publications, 2007. [2] Amitabh Mishra, “Security and quality of service in Ad hoc wireless networks”, Cambridge University Press, 2008. [3] Prasant Mohapatra and Srikanth Krishnamurthy, “Ad hoc network Technologies and Protocols”, Spinger Science and Business Media, 2005. [4] Michel Barbeau and Evangelos Kranakis, “Principles of Ad hoc networking”, Wiley, 2007. [5] Krishna Gorantala, “Routing Protocols in Mobile Ad hoc network”, June 15, 2006. [6] Jabson Andres, “ Metric in Ad hoc networks”, Master thesis, 2000. [7] Narendra Singh Yadav and R.P.Yadav, “The Effects of Speed on the Performance of Routing Protocols in Mobile Ad-hoc Network”. [8] Azzedine Boukerche, “Algorithms and protocols for wireless and mobile Ad hoc network”, Wiley, 2009. [9] A. Boukerche, “Performance Evaluation of Routing Protocols for Ad Hoc Wireless Networks”, Mobile Networks and Applications, 9, pp. 333-342, 2004. [10] Samir R. Das, “Performance Comparison of Two On-demand Routing Protocols for Ad Hoc Networks”, Division of Computer Science The University of Texas at San Antonio San Antonio, TX 78249-066 U.S.A. [11] Sehrish Abrejo, Asadullah Shah, Kamran Khowaja, Asma Ansari Pakistan “Analysis of MANET Routing Protocols using Scenario Based Mobility Models”, Department of Computer Science Isra University, Hyderabad. [12] Ashwini Kumar Pandey,“Study of MANET Routing Protocols by Simulation Experiments”,Department of Computer Science Southern Illinois University Edwardsville MAY 2004 [13] Farooq Anjum and Petros Mouchtaris, “Security for wireless Ad hoc networks” , Wiley, 2007 [14] Georgios Koltsidas and Fotini-Niovi Pavlidou, “Single-path and Multipath Routing Algorithms for Mobile Ad Hoc Networks”, Dept. of Electrical and Computer Engineering, Aristotle University of Thessaloniki, Thessaloniki, Greece [15] S. Gowrishankar, T.G. Basavaraju, M. Singh, Subir Kumar Sarkar , “Scenario based Performance Analysis of AODV and OLSR in Mobile Ad hoc Networks”, Jadavpur University, Acharya Institute of Technology India [16] [17] [18] [19] BẢNG THUẬT NGỮ VIẾT TẮT Chữ viết tắt Chữ đầy đủ Chữ tiếng Việt ABR Associativity-Based Routing Định tuyến theo liên kết ACK Acknowledgement Báo nhận AODV Ad Hoc On-Demand Distance Vector giao thức định tuyến vector khoảng cách theo yêu cầu Ad hoc AP Access point Điểm truy cập BS Base station Trạm gốc CBR Constant Bit Rate Tốc độ bit cố định DEST Destination Đích DHCP Dynamic host configuration protocol Giao thức cấu hình host động DSDV Destination sequenced distance vector Định tuyến vector khoảng cách tuần tự đến đich DSR Dynamic source routing Định tuyến nguồn động DYMO Dynamic MANET On-demand FDMA Frequency division multiple access Đa truy cập phân chia theo sóng Id Identifcation Nhận dạng IEEE Institute of electrical and electronics engineers Học viện kĩ sư điện và điện tử IN Intermediate Trung gian IP Internet protocol LAN Local area network Mạng cục bộ MAC Media access control Điều khiển truy cập đường truyền MANET Mobile ad hoc network Mạng di động không dây tùy biến MIP Mobile IP OLSR Optimized Link State Routing Định tuyến trạng thái liên kết tối ưu PDA Personal digital assistant Máy trợ lý cá nhân dùng kĩ thuật số QoS Quality of service Chất lượng dịch vụ RPC Remote Procedure Call SRC Source Nguồn TCP Transmission power control Điều khiển công suất truyền TTL Time to Live Thời gian sống VANET Vehicular Ad Hoc Network Mạng xe cộ ad hoc WLAN Wireless local area network Mạng không dây cục bộ PHỤ LỤC Mã nguồn chương trình File omnetpp.ini [General] #debug-on-errors = true sim-time-limit = 300s seed-0-mt = 5 num-rngs = 2 network = inet.examples.adhoc.grid_aodv.Grid_movilidad cmdenv-express-mode = true tkenv-plugin-path = ../../../Etc/plugins #tkenv-default-run=1 description = "Aodv Simple test" **.vector-recording = false cmdenv-express-mode = true *.numHosts =25 *.nodeSeparation = 150 *.playgroundSizeX = 500 *.playgroundSizeY = 500 **.channelNumber = 0 **.numberOfChannels = 1 **.debug = true **.coreDebug = false **.channelNumber = 0 **.wlan.mgmt.frameCapacity = 10 # channel physical parameters *.channelcontrol.carrierFrequency = 2.4GHz *.channelcontrol.pMax = 2.0mW *.channelcontrol.sat = -110dBm *.channelcontrol.alpha = 2 *.channelcontrol.numChannels = 1 # udp apps (on) **.host[*].udpAppType="UDPBasicBurst" **.host[*].numUdpApps=1 **.host[0].udpApp[0].destAddresses ="random_name(host)" **.host[1].udpApp[0].destAddresses="random_name(host)" **.host[2].udpApp[0].destAddresses="random_name(host)" **.host[3].udpApp[0].destAddresses="random_name(host)" **.host[4].udpApp[0].destAddresses="random_name(host)" **.host[*].udpApp[0].destAddresses="" **.udpApp[0].localPort=1234 **.udpApp[0].destPort=1234 **.udpApp[0].messageLength=512B # Bytes **.udpApp[0].messageFreq = 0.25s **.udpApp[0].message_freq_jitter=uniform(-0.001s,0.001s,1) **.udpApp[0].burstDuration = 0s #uniform(1,4,1) **.udpApp[0].activeBurst=true # if false all packet to the same address, if true select new destination per burts **.udpApp[0].time_off = 0s # uniform(10,20,1)) **. udpApp[0].time_begin = 60s **.udpApp[0].limitDelay =20s **.udpApp[0].rand_generator=1 **.udpApp[0].time_end=0s **.host*.mobilityType = "inet.mobility.NullMobility" **.host*.mobility.speed = 20mps #uniform(0mps,20mps) **.host*.mobility.updateInterval = 0.1s **.host*.mobility.scrollX = 50 **.host*.mobility.scrollY = 50 **.host*.mobility.nodeId = -1 # tcp apps (off) **.numTcpApps=0 **.tcpAppType="TelnetApp" # ip settings **.routingFile="" **.ip.procDelay=10us # **.IPForward=false # ARP configuration **.networkLayer.proxyARP = true # Host's is hardwired "false" **.arp.retryTimeout = 1s **.arp.retryCount = 3 **.arp.cacheTimeout = 100s # manet routing **.manetrouting.manetmanager.routingProtocol = "DYMO"# DSR/AODV/OLSR # nic settings **.wlan.mgmt.frameCapacity = 10 **.wlan.mac.address = "auto" **.wlan.mac.maxQueueSize = 14 **.wlan.mac.rtsThresholdBytes = 3000B **.wlan.mac.bitrate = 54Mbps **.wlan.mac.basicBitrate = 24Mbps # 24Mbps **.wlan.mac.retryLimit = 7 **.wlan.mac.cwMinData = 31 **.wlan.mac.cwMinBroadcast = 31 **.wlan.mac.opMode = 2 # 802.11g **.wlan.mac.slotTime = 9us # **.wlan.mac.AIFSN = 2 #DIFS # channel physical parameters *.channelcontrol.carrierFrequency = 2.4GHz *.channelcontrol.pMax = 2.0mW *.channelcontrol.sat = -110dBm *.channelcontrol.alpha = 2 *.channelcontrol.numChannels = 1 **.wlan.radio.transmitterPower = 2.0mW **.wlan.radio.pathLossAlpha = 2 **.wlan.radio.snirThreshold = 4dB # in dB **.wlan.radio.bitrate = 54Mbps **.wlan.radio.thermalNoise = -110dBm **.wlan.radio.sensitivity = -85dBm **.wlan.radio.phyOpMode = 2 #1/2 802.11b/802.11g-only **.wlan.radio.channelModel = 1 #1/2 rayleigh/awgn **.wlan.radio.berTableFile = "per_table_80211g_Trivellato.dat" **.broadCastDelay=uniform(0s,0.005s) #/ parameters : DYMOUM **.no_path_acc_ = false **.reissue_rreq_ = false **.s_bit_ = false **.hello_ival_ = 0 **.MaxPktSec = 20 #// 10 **.promiscuous = false **.NetDiameter = 10 **.RouteTimeOut = 3000 **.RouteDeleteTimeOut = 3000*5 #//5*RouteTimeOut **.RREQWaitTime = 1000 **.RREQTries = 3 **.noRouteBehaviour = 1 # // parameters: AODVUU; **.log_to_file = false **.hello_jittering = true **.optimized_hellos = true **.expanding_ring_search = true **.local_repair = true **.rreq_gratuitous = true #**.debug = false **.rt_log_interval = 0 **.unidir_hack = 0 **.internet_gw_mode = 0 **.receive_n_hellos = 1 **.ratelimit = 1000 **.llfeedback = false# //1000 **.wait_on_reboot = 0 **.active_timeout = 6000 # // time in ms **.internet_gw_address = "0.0.0.0" # // parameters: DSRUU; **.PrintDebug = true **.FlushLinkCache = true **.PromiscOperation = false **.UseNetworkLayerAck = false **.BroadCastJitter = 20 # 20 ms **.RouteCacheTimeout = 300 #300 seconds **.SendBufferTimeout = 300# //30 s **.SendBufferSize = -1 **.RequestTableSize = -1 **.RequestTableIds = -1 **.MaxRequestRexmt = -1 #// 16, **.MaxRequestPeriod = 10 #//10 SECONDS **.RequestPeriod = 500 #//500 MILLISECONDS **.NonpropRequestTimeout = 30# //30 MILLISECONDS **.RexmtBufferSize = -1 #//MAINT_BUF_MAX_LEN **.MaintHoldoffTime = 250# //250 MILLISECONDS **.MaxMaintRexmt = 2 # //2 **.TryPassiveAcks = true #//1 **.PassiveAckTimeout = 100# //100 MILLISECONDS **.GratReplyHoldOff = 1 #, //1 SECONDS **.MAX_SALVAGE_COUNT = 15 # //15 **.LifoSize = 20 **.PathCache = true **.ETX_Active = false **.ETXHelloInterval = 1 #, // Second **.ETXWindowNumHello = 10 **.ETXRetryBeforeFail = -1 **.RREPDestinationOnly = false **.RREQMaxVisit = 5 # // Max Number that a RREQ can be processes by a node #// Olsr **.Willingness = 3 **.Hello_ival = 2 **.Tc_ival = 5 **.Mid_ival = 5 **.use_mac = 0 #1 **.Mpr_algorithm = 1 **.routing_algorithm = 1 **.Link_quality = 2 **.Fish_eye = false **.Tc_redundancy = 3 **.Link_delay = true #//default false **.C_alpha = 0.2 #// DSDV **.manetroutingprotocol.hellomsgperiod_DSDV = 1 # //Period of DSDV hello message generation [seconds] **.manetroutingprotocol.manetroutingprotocol.timetolive_routing_entry = 5 # // ;[seconds] **.netmask = "255.255.0.0" # // **.MaxVariance_DSDV = 1 **.RNGseed_DSDV = 0 seed-0-mt = 1209575029 seed-1-mt = 449294716 **.host*.mobility.traceFile = "esce_10_no_pausa.1" File .awk BEGIN { sends = 0; receives = 0; sum_delay = 0; simulation = 0; numSent = 0; numReceived = 0; numReceivedOther = 0; routing =0; t = 0; } { # CALCULATE PACKET DELIVERY FRACTION if ($3 == "Total_send") { sends += $4; t++;} if ($3 == "Total_received") { receives += $4; } if ($3 == "sum_delay") { sum_delay += $4; } if ($3 == "simtime") { simulation += $4; } if ($3 == "numSent") { numSent += $4; } if ($3 == "numReceived") { numReceived += $4; } if ($3 == "Routing-overhead") { routing += $4; } if ($3 == "numReceivedOther") { numReceivedOther += $4; } } END { printf("Totalsends(pkts) = %.8f\n",sends); printf("Totalreceives(pkts) = %.8f\n",receives); printf("mean_delay = %.8f\n",sum_delay/receives); printf("packet delivery ratio = %.8f\n",(receives)/(sends)); printf("simulation_time(s) = %.8f\n",simulation/t); printf("throughput(pkts/s) = %.8f\n",(receives/simulation)); printf("numSent= %.8f\n", numSent); printf("numReceived= %.8f\n", numReceived); printf("numReceivedOther=%.8f\n", numReceivedOther); printf("normalized-routing-overhead=%.8f\n", routing/sends); }