Đánh giá, xây dựng và tồi ưu thuật toán định tuyến trên mạng Ad-Hoc

n packet ) cho node “T” để node “T” gửi lại gói tin xác nhận tuyến cho node “O” ( route confirmation packet ). Khi nhận được gói tin xác nhận từ “T” thì node “O” tuyến đường mới sẽ được nó lưu vào bảng định tuyến và bắt đầu việc trao đổi thông tin. Nếu “A” không tìm thấy tuyến đường tới node “T” nó sẽ gửi gói tin đáp ứng tuyến ( route respone packet ) chứa danh sách các hàng xóm của mình cho node “O”. Node “O” lại tiếp tục gửi gói tin dò tìm tuyến cho các hàng xóm của node “A” ( trừ những node nó đã gửi bản tin rồi, node gửi tin rồi được lưu trong bảng dò tìm tuyến RDT – Route Discovery Table ) để tiếp tục tìm đường tới node “T”. Quá trình này lặp đi lặp lại cho đến khi tuyến đường tới node “T” được xác định. Hình 1.14 Phương thức ISM Phương thức SRM : để triển khai phương thức này mỗi node phải lưu giữ “next hop” và “next to next hop” cho mỗi đích trong bảng định tuyến của nó. Phương thức này hoạt động ở cả hai loại giao thức Proactive và Reactive. Để hiểu rõ phương thức này ta xét ví dụ trong hình 1.15 dưới đây. Mỗi node “A” khi phát hiện đường link tới node hàng xóm, node “B”, bị hỏng sẽ ngay lập tức dùng phương thức SRM cho tất cả các node trong bảng định tuyến hoạt động ( ART – Active Routing Table ) coi node B như “next hop”. Node “A” cố gắng chỉnh sửa mỗi tuyến trong bảng ART của nó sử dụng node “B” như “next hop” bằng cách tìm một tuyến luân phiên tới node “C” ( next to next hop của “A” ) hướng về node đích “T”. Trong ví dụ này tuyến “A-B-C” được thay thế bởi tuyến “A-N-C”. a) mất kết nối A- B b) thay thế tuyến mới Hình 1.15 Phương thức SRM Đặc tính của các giao thức Reactive : Ưu điểm : Với việc sử dụng phương thức ISM để dò tìm tuyến, giao thức Reactive có ưu điểm là ít chiếm dụng băng thông. Giao thức Reactive chỉ dò tìm tuyến khi có yêu cầu chứ không gửi bản tin cập nhật trên mạng một cách tuần tự nên không gây ra lãng phí tài nguyên mạng Nhược điểm : Ngoài ưu điểm kể trên, việc dò tìm tuyến khi có nhu cầu lại gây ra tình trạng trễ trên mạng do phải chờ đợi tìm tuyến. Khó có thể sử dụng trong việc truyền thời gian thực. Một số giao thức định tuyến Reactive : AODV : Ad-hoc On-demand Distance Vector Routing. DSR : Dynamic Source Routing. TORA : Temporally Orde-red Routing Algorithm. ABR : Associativity-Based Routing. BSR : Backup Source Routing. ……… Các giao thức HYBRID. Các giao thức định tuyến Hybrid là dạng giao thức thế hệ mới. Dạng giao thức này kết hợp các đặc tính của cả hai dạng giao thức Proactive và Reactive để cân bằng trễ và điều khiển overhead. Việc sử dụng đặc tính của giao thức Proactive trong những mạng nhỏ (để giảm thiểu trễ ) và giao thức Reactive trong những mạng lớn (để giảm thiểu việc điều khiển overhead) được giao thức Hybrid tận dụng để tăng tối đa tính năng của nó. Giao thức được thiết kế để tăng khả năng mở rộng mạng bằng cách cho phép các node có trạng thái tương tự nhau hoạt động cùng nhau từ một vài dạng đường trục để giảm overhead trong việc dò tìm tuyến. Việc định tuyến sẽ được khởi tạo ngay lập tức sau một vài lần thăm dò tuyến và sau đó phục vụ những yêu cầu từ những node hoạt động thông qua việc flooding yêu cầu. Tuy nhiên, giao thức Hybrid cũng có một số nhược điểm như : Làm sao để tổ chức mạng theo các thông số của nó. Node có thông tin về topo mạng ở mức cao phải duy trì nhiều thông tin định tuyến dẫn đến tiêu tốn nhiều bộ nhớ và tài nguyên mạng. Một số giao thức dạng Hybrid : ZRP : Zone Routing Protocol. HRPLS : Hybrid Routing Protocol for Large Scale Mobile Ad Hoc Networks with Mobile Backbones. HSLS : Hazy Sighted Link State routing protocol. .......... CHƯƠNG 2 PHƯƠNG THỨC MÃ HOÁ VÀ TRUYỀN DỮ LIỆU TRÊN MẠNG AD-HOC 2.1 Chuẩn nén video H.264. 2.1.1 Giới thiệu chung về bộ codec H.264. H.264 là chuẩn nén mở được công bố chính thức vào năm 2003, hiện là chuẩn hỗ trợ công nghệ nén tiên tiến và hiệu quả nhất hiện nay. Và nó đang dần được đưa vào thành chuẩn nén tiêu chuẩn của ngành công nghệ an ninh giám sát bằng hình ảnh. H.264 (còn được gọi là chuẩn MPEG-4 Part 10/AVC for Advanced Video Coding hay MPEG-4 AVC) nó kế thừa những ưu điểm nổi trội của những chuẩn nén trước đây. Đồng thời sử dụng những thuật toán nén và phương thức truyền hình ảnh mới phức tạp, phương pháp nén và truyền hình ảnh mà chuẩn H.264 sử dụng đã làm giảm đáng kể dữ liệu và băng thông truyền đi của video. Với cách nén và truyền thông tin bằng chuẩn H.264 làm giảm đến 50% băng thông và kích thước file dữ liệu lưu trữ so với cách nén thông thường hiện nay (chuẩn nén thông thường hiện nay đang được sử dụng rộng rãi là MPEG-4 Part 2) và giảm tới hơn 80% băng thông và kích thước file dữ liệu lưu trữ so với nén bằng chuẩn Motion JPEG. Điều đó cho chúng ta thấy với cùng một hệ thống nếu chúng ta sử dụng chuẩn nén mới chúng ta có thời gian lưu trữ gấp đôi và băng thông mạng giảm đi một nửa, lợi ích mà chúng ta thấy ngay đó là chi phí cho lưu trữ dữ liệu video giảm một nửa so với dùng hệ thống có chuẩn nén thông thường. Ngoài ra việc truyền hình ảnh chiếm băng thông giảm một nửa, vì vậy chi phí dành cho thuê băng thông mạng cũng giảm đáng kể. Hoặc chúng ta có thể tăng chất lượng hình ảnh giám sát lên gấp đôi nhưng vẫn đảm bảo được băng thông và thời gian lưu trữ như trước đây. Đây là một lợi thế rất lớn, bởi với một hệ thống an ninh lớn, giải quyết vấn đề băng thông mạng và thời gian lưu trữ là rất phức tạp. Với chuẩn nén H.264 nó đã giải quyết được rất nhiều những khó khăn như vậy. Với việc giảm được băng thông của chuẩn nén H.264 đã thúc đẩy cho dòng camera độ nét cao (hay còn gọi Camera Megapixel) có cơ hội phát triển mạnh mẽ. Với những hệ thống giám sát quan trọng cần hình ảnh rõ nét thì lựa chọn các camera độ nét cao và đầu ghi hỗ trợ chuẩn nén H.264 là hoàn toàn hợp lý. Chuẩn nén H.264 được kỳ vọng là cơn gió mới, tạo thêm sinh khí để thúc đẩy sự phát triển của ngành an ninh giám sát phát triển mạnh mẽ hơn. Chuẩn nén H.264 bao gồm hai thành phần chính : Bộ mã hoá Encoder. Bộ giải mã Decoder. Encoder. Hình 2.1 : Sơ đồ bộ mã hoá H.264 Bộ mã hóa bao gồm hai luồng dữ liệu, luồng thuận từ trái sang phải, và luồng tái tạo từ phải sang trái trong hình. Một khung đầu vào hay một trường Fn được xử lý theo từng khối macro. Mỗi khối được mã hóa theo mô hình mã hóa trong hay ngoài, đối với mỗi khối macro, một ảnh tham chiếu để dự đoán PRED ( điểm P trên vẽ) được tái tạo từ các mẫu của bức ảnh. Trong chế độ mã hóa trong, PRED được tạo bởi các mẫu trong slice hiện tại trước đó đã được mã hóa, giải mã và tái tạo (xem uF_n, chú ý rằng các mẫu chưa được lọc sẽ được sử dụng để tạo lên PRED). Trong chế độ mã hóa ngoài, PRED được tạo bởi dự đoán bù chuyển động từ một hoặc hai ảnh tham chiếu được lựa chọn từ tập danh sách các ảnh tham chiếu 0 hay 1. Trong hình minh họa ảnh tham chiếu là Fn-1 nhưng tham chiếu dự đoán cho một vùng của khối macro có thể chọn là ảnh tham chiếu (đã được mã hóa, tái tạo và lọc trước đó) ở tương lai hay là quá khứ ( theo thứ tự hiển thị) PRED sẽ được loại bỏ đi từ khối hiện tại để tạo ra khối dư thừa còn lại Dn (sai khác). Dn sẽ được biến đổi và lượng tử hóa để tạo ra X một tập các hệ số biến đổi lượng tử hóa . Các hệ số này sẽ được xắp xếp lại thứ tự và sau đó mã hóa entropy. Các hệ số được mã hóa entropy kết hợp với các thông tinh cần thiết để giải mã mỗi khối trong khối macro (chế độ dự đoán, tham số lượng tử hóa, thông tin vector chuyển động) tạo thành luồng bit được nén sẽ được chuyển tới Lớp mạng trừu tượng- NAL để truyền đi hay lưu trữ.Đồng thời khi mã hóa và truyền đi, mỗi khối trong khối macro sẽ được bộ mã hóa tái tạo lại để làm tham chiếu cho việc dự đoán. Các hệ số X sẽ được tái tạo qua các khối biến đổi ngược Q-1, T-1 để tạo thành Dn. Khối dự đoán PRED được cộng vào với Dn để tạo ra khối uFn ( bản giải mã của khối nguyên thủy). Tiền tố “u” để chỉ khối này chưa được lọc. Bộ lọc dùng để giảm méo và ảnh tham chiếu được tái tạo từ nhiều khối. Decoder. Hình 2.2 Sơ đồ bộ giải mã H.264 Bộ mã hóa nhận được 1 luồng dữ liệu nén từ NAL và giải mã entropy nhưng thành phần cơ bản của dữ liệu để tạo ra tập các hệ số được lượng tử hóa X. Những hệ số này được “scale” và chuyển dổi ngược thành .Dn.Sử dụng thông tin tiêu đề được giải mã từ lượng bit, bộ giải mã tạo ra khối dự đoán PRED, phân biệt với khối PRED được tạo ở bộ mã hóa. 2.1.2 Cấu trúc H.264. Hình 2.3 Mô hình cấu trúc H.264 2.1.2.1 Định dạng video. H.264 hỗ trợ mã hóa và giải mã video 4:2:0 quét liên tục hoặc xen kẽ. Khung quét xen kẽ bao gồm 2 trường (trên và dưới) tách biệt theo thời gian với định dạng mặc định. 2.1.2.2 Định dạng dữ liệu được mã hoá. H.264 phân biệt lớp mã hóa video (Video Coding layer – VCL) và lớp mạng trừu tượng (Network Abstraction Layer – NAL). Đầu ra của quá trình mã hóa là dữ liệu lớp mã hóa video VCL (chuỗi bit biểu diễn dữ liệu video đã được mã hóa) sẽ được ánh xạ và các đơn vị của lớp mạng trừu tượng- NAL trước khi truyền dẫn hay lưu trữ. Mỗi đơn vị NAL bao gồm chuỗi byte thô về thứ tự tải, và một tập các thông tin ứng với dữ liệu video hay còn gọi là thông tin header. Một chuỗi video được mã hóa được biểu diễn bởi chuỗi các đơn vị NAL mà có thể được truyền dẫn trên các mạng gói hay luồng bit trên đường truyền hay lưu ra file. Mục đích của việc phân chia các lớp VCL và NAL là để phân biệt đặc tính mã hóa tại lớp VCL và đặc tính truyền dẫn tại lớp NAL. Hình 2.4 Luồng dữ liệu cơ bản H.264 Header slice định nghĩa loại slice và ảnh mã hóa mà slice đó thuộc về và có thể kèm theo các thông tin hướng dẫn liên quan đến quản lý ảnh tham chiếu. Phần dữ liệu của slice bao gồm chuỗi các khối macro được mã hóa và chỉ thị bỏ qua ( không được mã hóa) khối macro. Mỗi khối macro bao gồm chuỗi các thành phần header và dữ liệu dư thừa được mã hóa. 2.1.2.3 Slice. Một ảnh video được mã hóa gồm một hay nhiều slide. Mỗi slice bao gồm số nguyên các khối macro. Số lượng khối macro trong một bức ảnh có thể không cố định. Có sự phụ thuộc lẫn nhau tối thiểu giữa các slide đã được mã hóa để giúp giảm sự lan truyền lỗi.Có 5 loại slide được mã hóa và một ảnh được mã hóa có thể bao gồm nhiều loại slide khác nhau ví dụ ảnh được mã hóa trong profile cơ bản có thể bao gồm các slide I và P và ảnh được mã hóa ở profile chính hay mở rộng có thể gồm I, P, B slide. Hình 2.5 Cấu trúc Slice 2.1.2.4 Macroblock. Một khối macro bao gồm các dữ liệu được mã hóa ứng với vùng 16x16 mẫu của khung video.( 16x16 mẫu độ chói, 8x8 Cb và 8x8 Cr) và bao gồm các thành phần cú pháp theo bảng ở . Khối macro được đánh số theo thứ tự quét trong khung. Mb_type Xác định liệu khối macro là loại I hay P, xác định kích cỡ một vùng trong khối macro Mb_pred Xác định chế độ mã hóa trong ( khối macro intra), danh sách tham chiếu List 0 hay List 1 và mã hóa các vector chuyển động khác nhau cho mỗi phần của khối macro Sub_mp_pred Xác định kích cỡ khối macro con. Danh sách tham chiếu List 0 hay 1 cho mỗi vùng khối macro và mã hóa các vector chuyển động khác nhau cho mỗi vùng con Coded_block_pattern Xác định khỗi 8x8 nào ( độ chói hay sắc) sẽ mang hệ số biến đổi Mb_qp_delta Thay đổi tham số lượng tử hóa Residual Hệ số biến đổi đã được mã hóa ứng với mẫu dư thừa sau khi dự đoán 2.1.2.5 Ảnh tham chiếu. Bộ mã hóa H.264 có thể sử dụng hai hoặc nhiều các ảnh được mã hóa trước đó để làm tham chiếu cho dự đoán bù chuyển động cho mã hóa ngoài các khối macro hoặc phân tách khối macro. Điều này cho phép bộ mã hóa tìm kiếm khối macro giống nhất với khối macro được tách ra từ bức ảnh vừa được mã hóa.Bộ mã hóa và giải mã luôn giữ một hoặc hai danh sách các ảnh tham chiếu, bao gồm ảnh đã vừa được mã hóa hay giải mã (xuất hiện trước hoặc sau ảnh hiện tại). Mã hóa ngoài các khối macro hay vùng của khối macro trong slice P được dự đoán từ một danh sách các ảnh –list 0. Mã hóa ngoài khối macro và vùng các khối macro trong slide B có thể được dự đoán từ hai danh sách list 0 và list 1. Loại Slice Mô tả Profile I (Intra) Chỉ bao gồm khối macro I (mỗi khối hoặc khối macro được dự đoán từ dữ liệu được mã hóa trước đó trong cùng một slide) Tất cả P (Predicted) Bao gồm khối macro P (mỗi khối macro hoặc vùng macro được dự đoán từ danh sách các ảnh trong list 0 hoặc là khối macro I Tất cả B (Dự đoán hai chiều) Bao gồm các khối macro B( mỗi khối hay một vùng khối macro được dự đoán từ danh sách ảnh list 0 hoặc list 1) hoặc là khối macro I Mở rộng hoặc chính SP (Swiching P) Tạo điều kiện thuận lợi Mở rộng Profile Hình 2.6 Profile trong H.264 H264 định nghĩa 3 profile trong đó mỗi profile hỗ trợ 1 tập cụ thể các hàm mã hóa, và chỉ ra những gì đươc yêu cầu của bộ mã hóa/giải mã phù hợp với từng profile. Base profile hỗ trợ mã hóa trong và liên khung (sử dụng slice I và slice P ),và phương pháp mã hóa entropy CAVLC. Main profile bao gồm video quét xen kẽ,mã hóa liên khung sử dụng slice B ,mã hóa liên khung dùng dự đoán có trọng sô và phương pháp mã hóa entropy CABAC. Extended profile không hỗ trợ video quét xen kẽ và phương pháp mã hóa entropy CABAC, nhưng có thêm chế dộ cho phép việc chuyển đổi  giữa các luồng bit được mã hóa. Ứng dụng tiềm năng của profile Baseline bao gồm thoại video, hội thảo truyền hình, và truyền thông không dây. Ứng dụng tiềm năng của Main profile là truyền hình quảng bá và lưu trữ dữ liệu. Profile mở rộng có thể hữu ích trong ứng dụng streaming. Tuy nhiên mỗi profile có sự mềm dẻo đủ để hỗ trợ một loại ứng dụng khác nhau. Lớp mạng trừu tượng. Hình 2.7 Lớp NAL trong H.264 Các NAL unit chứa trong nó slice đầu ra của VCL (video coding layer), thích hợp cho việc truyền đi trên mạng gói (packet-oriented network) hoặc các mạng hướng luồng byte (byte- oriented networks). Hình 2.8 Đơn vị dữ liệu ứng với các lớp trong H.264 2.1.3.1 Cấu trúc của NAL unit. 2.1.3.1.1 NAL unit header. Hình 2.9 Cấu trúc dữ liệu phân mảnh Trên hình là cấu trúc của NAL header có độ dài 1 byte,và là byte đầu tiên của 1 Nal unit. F (forbidden_zero_bit) : Giá trị 0 chỉ rằng octet NAL type và tải không chứa bit lỗi hoặc sai cú pháp.Và ngược lại.Khi bit F được đặt lên 1 thì bộ giải mã được chi rằng trong tải và octet NAL ype của NAL unit có chứa lỗi hoặc sai cú pháp,bộ giả mã có thể huỷ bỏ NAL unit và giấu đi dữ liệu của gói bị huỷ. NRI(nal_ref_idc) : giá trị 00 chỉ nội dung của NAL unit không được dùng đẻ tái xây dựng ảnh tham chiếu cho dự đoán liên ảnh,do vậy mà các Nal unit có thể bi huỷ mà không làm rủi ro toàn thể ảnh tham chiếu. Còn giá trị lớn hơn 00 chỉ rằng việc giải mã Nal unit được yêu cầu để duy trì sự toàn vẹn của ảnh tham chiếu. Mức độ ưu tiên truyền giảm dần theo trật tự:11, 10, 01, 00 ,và giá trị của Nri tuỳ thuộc giá trị của NAL type. Datatype : Hình 2.10 Loại dữ liệu chứa trong một đơn vị NAL Khi NAL=5 (ảnh IDR) thì giá trị của của NRI=11 Hình 2.11 Cấu trúc gói NAL 2.1.3.1.2 Cấu trúc gói dạng byte stream. Trật tự của NALU dạng luồng byte nên theo trật tự giải mã NALU trong luồng byte NALU. Bắt đầu mỗi NALU là chuỗi 3 byte được gọi là start_code_prefix_one_3byte =0x000001(theo hệ số đếm 16). Emulation_prevent_three_byte chứa bên trong của 1 NALU để thông báo là không có chuỗi byte liên tiếp byte-aligned bên trong NALU,hay nois cách khác là dảm bảo trong luồng dữ liệu của nal unit không chứa mã mở đầu(prefix start code :0x000001). 2.1.3.2 Tập tham số Hình 2.12 Tập tham số Khi truyền video được mã hóa theo cách truyền thống qua mạng dễ xảy ra lỗi (error prone),một trong các vấn đề lớn hơn là khả năng mất 1 tiêu đề mang thông tin có liên quan tới nhiều gói.Ví dụ như việc mất tiêu đề (header) của ảnh, dẫn đến không có khả năng của bộ giải mã sử dụng bất kì gói thông tin nào sau đó liên quan tới bức ảnh, thậm chí rất nhiều gói còn nguyên không bị thay đổi gi so với khi được đóng gói tại phía phát. Nhiều cơ chế được giới thiệu tới các chuẩn mã hóa video và sự sắp xếp đóng gói (packetization schemes) để giảm thiểu vấn đề trên như cơ chế nhân bản tiêu đề trong MPEG-4. Tuy nhiên những cơ chế này không thể giải quyết hoàn toàn vấn đề. Vấn đề cơ bản là việc đồng bộ của các thông tin cao hơn của tiêu đề với luồng bit.Ở bất kì trạng thái nào được nêu ra của bộ giải mã, có duy nhất 1 ngữ cảnh (context) của tiêu đề sẵn sàng ở bộ giải mã.Nếu ngữ cảnh bị mất vì bất kì lí do nào, bộ giải mã sẽ có vấn đề Khái niệm NAL của H26L tránh được vấn đề này bằng cách tách biệt việc truyền của thông tin slice và tiêu đề của trật tự cao hơn (higher hierarchy). Bộ mã hóa và bộ giải mã duy trì nhiều địa điermer chứa cho toàn bộ nội dung của tiêu đề của ảnh/GOB/Slice. Mỗi 1 slice chứa trong tiêu đề 1 từ mã của tập tham số (parameter set) có chức năng như 1 chỉ số tới địa chỉ của tập tham số liên quan việc giải mả của slice đó. Do vậy, bộ giải mã có thể thay đổi không đồng bộ các tập tham số trong khi vẫn cho phép giải mã đúng slice mà không gửi (address) tham số các tập tham sô đó. Hình 2.13 Sự liên kết giữa các tập tham số Việc truyền các cập nhât của tập tham số phụ thuộc vào NAL.Tập tham số nên được thiết lập và cập nhật một cách cậy và theo 1 kênh truyền khác với kênh truyền video.Trong các ứng dụng hội thoại, thiết lập của tập tham sô sẽ thường là ảnh hưởn 1 phía của trao đổi khả năng (capability exchange) và sau đó những thay đổi sẽ được thực hiện thông qua giao thức điều khiển tin cậy như H.243 trong môi trường mà không có giao thức điều khiển nào, tập tham số có thể được truyền trong cùng 1 kênh truyền. Hình 2.14 Cơ chế truyền tập tham số ảnh Thông thường các tập tham sô ảnh , tập tham số chuỗi được truyền trước các slice để bộ giải mã phía thu có thể thiết lập các giá trị phù hợp để giải mã đúng luồng dử liệu video truyền từ phía phát. Tập tham số ảnh (PPS) : Mỗi slice đều tham chiếu đến 1 tập tham số ảnh (picture parameter set) dùng cho việc giải mã dữ liệu video được mã hóa của 1 hay nhiều ảnh. Tập tham số chuỗi (SPS) : Mỗi tập tham số ảnh đều tham chiếu đến 1 tập tham số chuỗi (sequence parameter set). Mỗi tập tham số chuỗi chứa thông tin cho cả chuỗi video dùng cho quá tŕnh giải mã cho toàn chuỗi ảnh. 2.1.3.3 Trật tự của các NALU và liên kết tới các ảnh được mã hoá, đơn vị truy cập và chuỗi video. 2.1.3.3.1 Trật tự của PPS và SPS. Tập tham số ảnh và tập tham số chuỗi phân tách việc truyền những thông tin thay đổi không thường xuyên từ dữ liệu của các macroblock được mã hóa. Tập tham số ảnh và tập tham số chuỗi được truyền “out-of-band” dùng cơ chế truyền tin cậy. RBSP của tập tham số ảnh có thể được chiếu đến bởi các đơn vị NAL của slice được mã hóa hoặc phân vùng dữ liệu. RBSP của mỗi tập tham số ảnh ban đầu không hoạt động lúc bắt đầu hoạt động của quá trình giải mã. Một tập tham số ảnh được xem là hoạt động tại bất kì thời điểm nào của quá trình giải mã,và dẫn đến sự vô hiệu hóa của một tập tham số ảnh trước đấy. Và khi có một tâp tham số ảnh mới thì tập tham số ảnh hiện tại sẽ bị vô hiệu hóa. Bất kì đơn vị NAL chứa giá trị của pic_parameter_set_id cho RBSP của tập tham số ảnh hoạt động sẽ có cùng nội dung như của RBSP tập tham số ảnh hoạt động trừ phi nó theo sau đơn vị NAL VCL cuối cùng của một ảnh được mã hóa và dứng trước đơn vị NAL VCL đầu tiên của ảnh được mã hóa khác. Một tập tham số chuỗi chứa thông số có thể được chỉ đến bỏi một hay nhiều tập tham số ảnh hoặc một hay nhiều thông điệp SEI. Mỗi tập tham số chuỗi ban đầu không hoạt động lúc bắt đầu hoạt động của quá trình giải mã và hoạt động tại bất kì thời điểm nào của quá trình giải mã,và dẫn đến sựu vô hiệu hóa của một tập tham số ảnh trước đấy. Và khi có một tâp tham số chuỗi mới thì tập tham số chuỗi hiện tại sẽ bị vô hiệu hóa. Bất kì đơn vị NAL chứa cụ thể giá trị của seq_parameter_set_id cho RBSP của tập tham số chuỗi không sắn sàng hoạt động như của RBSP tập tham số chuỗi hoạt động trừ phi nó theo sau đơn vị NAL VCL cuối cùng của một ảnh được mã hóa và dứng trước đơn vị NAL, VCL đầu tiên của ảnh được mã hóa khác. Bất kì đơn vị NAL chứa cụ thể giá trị của seq_parameter_set_id cho RBSP của tập tham số chuỗi không sắn sàng hoạt động như của RBSP tập tham số chuỗi hoạt động trừ phi nó theo sau đơn vị NAL, VCL cuối cùng của một ảnh được mã hóa và dứng trước đơn vị NAL, VCL đầu tiên của ảnh được mã hóa khác. Do đơn vị truy cập IDR bắt đầu một chuỗi video được mã hóa mới và một RBSP của tập tham số chuỗi phải duy trì hoạt động cho toàn thể chuỗi video được mã hóa, RBSP của tập tham số chuỗi chỉ có thể được hoạt động bới một thông điệp SEI đang đệm theo chu kì. Bất kì đơn vị NAL chứa giá trị của seq_parameter_set_id cho RBSP của tập tham số chuỗi hoạt động sẽ có cùng nội dung .RBSP tập tham số chuỗi hoạt động trừ phi nó theo sau đơn vị NAL, VCL cuối cùng của một ảnh được mã hóa và dứng trước đơn vị NAL VCL đầu tiên của ảnh được mã hóa khác,và đơn vị SEI chứa thông điệp SEI của chuỗi video được mã hóa khác.Khi trình bày,RBSP của tập tham số chuỗi mở rộng có chức năng tượng tự các RBSP của tập tham số chuỗi. 2.1.3.3.2 Trật tự của các đơn vị truy cập và gắn với chuỗi video được mã hóa. Một chuỗi video bao gồm hay nhiều đơn vị truy cập. Đợn vị truy cập đầu tiên của mỗi chuỗi video được mã hóa là 1 đơn vị IDR và tất cả các chuỗi video là các đơn vị truy cập không phải IDR. Giá trị của só đếm trật tự của ảnh cho các ảnh được mã hóa trong các đơn vị truy cập liên tiêp nhau theo trật tự giải mã đàg chứa ảnh không được tham chiếu sẽ không tăng. Khi hiển thị, một đơn vị truy cập theo sau 1 đơn vị truy cập cuối cùng của 1 chuỗi NAL sẽ là 1 đơn vị truy cập của ảnh IDR. Khi một dơn vị NAL SEI chứa dữ liệu là thuộc tính của nhiều đơn vị truy cập, đơn vị NAL SEI sẽ được chứa trong đơn vị truy cập đầu tiên nó áp dụng Khi kết thúc của luồng NAL được trình bày ở trong 1 đơn vị truy cập,đơn vị truy cập này nên là đơn vị cuối cùng của chuỗi bit và kết thúc của chuỗi đơn vị NAL sẽ là đơn vị NAL cuối cùng trong đơn vị truy cập này. 2.1.3.3.3 Trật tự của các đơn vị NAL và ảnh được mã hóa và sự gán kết tới các đơn vị truy cập. Hình 2.15 Cấu trúc đơn vị truy nhập Một đơn vị truy cập chứa 1 ảnh được mã hóa chính,không hoặc nhiều ảnh dược mã hóa dư thừa liên quan và không hoặc nhiều đơn vị NAL không phải là của VCL. Đơn vị đầu tiên của các đơn vị NAL theo sau đơn vị NAL của lớp VCL của một ảnh được mã hóa chính : Đợn vị NAL phân chia đơn vị truy câp (access unit delimiter NAL unit). Đơn vị NAL của tập tham số chuỗi ( sequence parameter set NAL unit). Đơn vị NAL của tập tham số ảnh (picture parameter set NAL unit). SEI NAL unit (when present). Đơn vị NAL với nal_unit_type trong khoảng 14 từ 18. Đơn vị NAL VCL đầu tiên của một ảnh được mã hóa. Những hạn chế sau sẽ được điều khiển được trật tự của các ảnh được mã hóa và các đơn vị của NAL không phải của lớp VCL bên trong một đơn vị truy cập. Khi một đơn vị NAL phân chia các đơn vị truy cập được trình bày,nó sẽ là đơn vị NAL đầu tiên.Nên có ít nhât 1 đơn vị phân chia đơn vị truy cập ở bất kì đơn vik truy cập nào. Khi các đơn NAL SEI bất kì được trình bày, chúng sẽ thep trước ảnh được mã hóa. Khi một đơn vị NAL SEI chứa thông điệp SEI đang được đệm,thông điệp SEI đang được đệm sẽ là tải của thông điệp SEI đầu tiên của đơn vị NAL đầu tiên tron đơn vị truy cập. Ảnh được mã hóa chính sẽ di trước các ảnh được mã hóa dư thừa liên quan. Khi ảnh được mã hóa dư thừa được trình bày,nó sẽ là đơn vị NAL tiếp theo và theo trật tự của giá trị của redundant_pic_cnt. .Các đơn vị NAL thuộc cùng 1 chuỗi thì có cùng số seq_parameter_set_id. Khi đơn vị NAL của tập tham số chuỗi đươc trình bày,nó sẽ là đơn vị NAL tiếp theo sau đơn vị NAL của tập tham số chuỗi có cùng giá trị seq_parameter_set_id khi có 1 hay nhiều slice được mã hóa của một ảnh được mã hóa phụ không có các đơn vị NAL của các phân vùng được trình bày,chúng sẽ theo sau ảnh được mã hóa chính và tất cả các ảnh được mã hóa dư thừa. Khi đơn vị NAL kết thúc của chuỗi được trình bày, nó sẽ theo sau ảnh được mã hóa chính và tất cả các ảnh được mã hóa dư thừa. Khi đơn vị NAL của luồng kết thúc được trình bày,nó sẽ là đơn vị NAL cuối cùng. Đơn vị NAL có nal_unit_type từ 0 đến 12 hoặc trong khoảng 20 đến 31,sẽ không theo sau đơn NAL lớp VCL đầu tiên của ảnh được mã hóa chính. Đơn vị NAL của tập tham số chuỗi hoặc của tập tham số ảnh có thể được trình bày trong 1 đơn vị truy câp nhưng không đi sau đơn vị NAL VCL cuối cùng của ảnh đươc mã hóa chính bên trong 1 đơn vị truy cập, khi điều kiện này sẽ được chỉ bát đầu của một đơn vị truy cập mới. Khi một NAL có nal_unit_type là 7,8 được trình bày bên trong một đơn vị truy cập,nó có the hoăc không được tham chiêu tới bên trong ảnh được mã hóa của một đơn vị truy cập. Cấu trúc của đơn vị truy cập không chứa bất kì đơn vị NAL có nal_unit_type là 0, 7, 8 hoặc 12. 2.1.3.3.4 Dò tìm đơn vị NAL đầu tiên của 1 ảnh chính được mã hoá (primari codec picture ). Bất kì đơn vị NAL của slice được mã hóa hoặc phân vùng dữ liệu của slice được mã hóa của ảnh được mã hóa chính trong đơn vị truy cập hiện tại sẽ phân biệt với bất kì đơn vị NAL ckủa slice được mã hóa hoặc phân vùng dữ liệu của slice được mã hóa của ảnh đươc mã hóa trước đó theo những cách sau: • frame_num :khác biệt giá trị .Giá trị của frame_num được dùng đề kiểm tra điều kiện này được xuất hiện trong cú pháp của tiêu đề của slice bất kể giá trị được ngụ ý là 0 cho việc dùng các chuỗi con trong quá trình giải mã vi việc xuất hiện của hoạt động điều khiển quản lí bộ nhớ bằng 5 • pic_parameter_set_id khác giá trị • field_pic_flag khác giá trị • bottom_field_flag khác giá trị • nal_ref_idc khác giá trị với nal_ref_idc có giạ trị là 0. • pic_order_cnt_type là 0 và pic_order_cnt_lsb khác giá trị hoặc delta_pic_order_cnt_bottom khác giá trị . • pic_order_cnt_type là 1 cho cả 2 ảnh delta_pic_order_cnt[ 0 ] khác giá trị or delta_pic_order_cnt[ 1 ] .khác giá trị • nal_unit_type khác giá trị với đơn vị nal có nal_unit_type là 5. 2.2 Chương trình VLC. 2.2.1 Giới thiệu. Chương trình VLC là chương chình chính của dự án VideoLAN. VideoLAN là giải pháp phần mềm hoàn thiện cho việc truyền và xem video. Dự án VideoLAN là dự án phần mềm mã nguồn mở dành cho multimedia được phát triển bởi các sinh viên thuộc trường đại học Ecole Centrale Paris và được phát triển trên toàn thế giới dưới bản quyền của GNU Genaral Public License (GPL). Hình 2.16 VideoLAN Ban đầu, VideoLAN được thiết kế để truyền video MPEG trên mạng băng thông rộng. Sau này, bằng việc phát triển chương trình VLC người ta đã hoàn thiện hơn đặc tính của một chương trình media đa nền tảng. Do đó chương trình VLC còn được gọi là VideoLAN client. Chương trình VLC có thể hoạt động trên nhiều hệ điều hành như : Linux, Windows, Mac OS X, BeOS, BSD, Solaris, Familiar Linux, Yopy/Linupy and QNX. Nó có thể được sử dụng để chạy : MPEG-1, MPEG-2 and MPEG-4 / DivX files từ các thiết bị đĩa CD-ROM, ổ cứng… DVDs, VCDs, và audio CDs. Từ thẻ vệ tinh ( DBV-S : Digital Video Broadcasting by Satellite ). Một vài dạng truyền dữ liệu mạng : UDP/RTP Unicast, UDP/RTP Multicast, HTTP, RTSP, MMS … Từ việc dò sóng hoặc các thẻ mã hoá ( chỉ trên hệ điều hành GNU/Linux và Windowns ). Ngoài ra chương trình VLC còn được sử dụng như là streaming server ( server truyền multimedia ). 2.2.2 Cài đặt và hoạt động. Trên Windows : Download chương trình VLC từ trang web : Cài đặt chương trình vlc.exe vừa download về : Hình 2.17 Cài đặt chương trình VLC trên Windows Chạy chương trình : Hình 2.18 Chạy chương trình VLC trên Windows Truền Multimedia trên Windows : Hình 2.19 Truyền Multimedia trên Windows Trên Linux : Download chương trình VLC tại : Giải nén và cài đặt : Hình 2.20 Cài đặt VLC trên Linux Chạy chương trình : Hình 2.21 Chạy VLC trên Linux Trên Linux ta truyền và nhận video bằng dòng lệnh : Hình 2.22 Truyền video trên Linux Hình 2.23 Nhận video trên Linux CHƯƠNG 3 GIAO THỨC OLSR 3.1 Tổng quan. Optimized Link State Routing Protocol (OLSR) là giao thức định tuyến được phát triển cho mạng Mobile Adhoc Network (MANET). OLSR hoạt động như một bảng ghi, một giao thức proactive,.., chuyển đổi thông tin topo mạng với các node khác một cách đều đặn. Mỗi node lựa chọn trong số những node hàng xóm của nó một node làm “multipoint relay” (MPR). Trong OLSR, chỉ những node được lựa chọn làm MPR mới đáp ứng cho việc điều khiển forwarding lưu lượng, dành riêng cho việc truyền tin vào trong toàn bộ mạng. MPRs cung cấp cơ chế hiệu quả cho điều khiển flooding lưu lượng bằng cách giảm số lượng yêu cầu truyền. Những node được lựa chọn làm MPR cũng có đáp ứng đặc biệt khi quảng bá thông tin trạng thái link trong mạng. Thật vậy, chỉ những yêu cầu cho OLSR để cung cấp thông tin trạng thái link tuyến ngắn nhất được MPRs quảng bá cho những node lựa chọn MPR của chúng (MPR selector). OLSR phù hợp rất tốt cho những mạng lớn và mật độ dày đặc các node mạng bởi khả năng sử dụng MPR của mình. Giao thức này không yêu cầu cơ chế truyền lại tin cậy của bản tin điều khiển : mỗi node gửi bản tin điều khiển một cách tuần tự, và có thể chấp nhận lý do mất gói của một số bản tin. Sự mất gói trong mạng là do sự xung đột ( collision ) hoặc lỗi khi truyền. Nó sử dụng phương thức định tuyến hop-by-hop ( mỗi node sử dụng thông tin nội bộ của mình để định tuyến cho gói tin ). OLSR được phát triển để hoạt động độc lập từ các giao thức khác. OLSR không hề đưa ra một giả định nào về lớp dưới link-layer. Giao thức định tuyến này thừa kế sự ổn định của thuật toán link-state và có thuận lợi khi luôn có tuyến sẵn có khi cần. Ngoài ra OLSR cũng thừa kế ý tưởng của forwarding và relaying từ HIPERLAN ( giao thức lớp MAC ) , một chuẩn của ETSI. Giao thức này được phát triển trong dự án IPANEMA ( một phần của chương trình Euclid ) và trong dự án PRIMA ( một phần của RNRT ) OLSR được định nghĩa trong RFC 3626. Mã nguồn mở và các chương trình của nó có trên trang web : . Giao thức này có thể chạy trên rất nhiều hệ điều hành : Windows (XP and Visa). Linux (i386, arm, alpha, mips, xscale). OS X (powerpc, intel, xscale, iPhone). VxWorks, NetBSD, FreeBSD, OpenBSD …… 3.2 Một số thuật ngữ. Node : một MANET router triển khai OLSR OLSR interface : thiết bị tham gia vào MANET có sử dụng OLSR. Một node có thể có một vài OLSR interface, mỗi interface được phân cho một địa chỉ IP duy nhất. Non OLSR interface : thiết bị không tham gia vào một MANET đang chạy OLSR. Mỗi node có thể có một vài non OLSR interface ( không dây hoặc có dây ). Thông tin định tuyến từ các interface này có thể xen vào một miền định tuyến OLSR ( OLSR routing domain ) Single OLSR interface node : node có duy nhất một OLSR interface tham gia vào miền định tuyến OLSR. Multiple OLSR interface : node có nhiều OLSR interface tham gia vào miền định tuyến OLSR. Main address : địa chỉ chính của node được dùng trong OLSR để điều khiển lưu lượng như là địa chỉ gốc (originator address ) của tất cả các bản tin phát ra từ node đó. Một single OLSR interface phải dùng địa chỉ interface đó làm “main address”. Một multiple OLSR interface phải lựa chọn trong số những OLSR interface của nó làm “main address”. Neighbor node : node X được gọi là hàng xóm của node Y nếu node Y có thể nghe thấy node X. 2-hop neighbor : node nghe được từ hàng xóm. Strict 2-hop neighbor : node không phải là chính nó hay hàng xóm của một node với điều kiện là hàng xóm của hàng xóm. Multipoint relay (MPR) : node được lựa chọn bởi 1-hop neighbor của nó để “re-transmit” tất cả bản tin broadcast mà nó nhận được từ 1-hop neighbor, miễn là bản tin đó không bị lặp và trường TTL của bản tin lớn hơn 1. Multipoint relay selector ( MPR selector, MS ) : node lựa chọn một trong số 1-hop neighbor của nó làm MPR. Link : một link là một cặp OLSR interface ( từ hai node khác nhau ) có thể nghe thấy một trong hai ( có thể nhận được luồng traffic của nhau ). Một node được gọi là có đường link tới node khác khi một trong số các interface của nó có đường link tới một trong số các interface của node khác. Symmetric link : link thực hiện kết nối trực tiếp hai phía giữa hai OLSR interface. Asymmetric link : link thực hiện kết nối từ một phía giữa hai OLSR interface. 3.3 Cấu trúc bản tin. 3.3.1 Định dạng gói tin cơ bản. Hình 3.1 Định dạng gói tin Packet Header : Packet Length : trường mô tả chiều dài ( tính theo byte ) của gói tin. Packet Sequence Number : trường mô tả số thứ tự tuần tự của gói tin. Trường PSN phải giảm đi 1 đơn vị khi một gói tin OLSR được gửi đi. Message Header : Message Type : trường mô tả loại bản tin. Vtime : thời gian sau khi một node tiếp nhận một bản tin, nó phải xem xét thông tin chứa trong bản tin là đúng hay sai trừ khi một vài thông tin update đã được nhận trước đó. Message Size : trường mô tả kích thước của bản tin, tính theo byte và tính từ trường “Message type ” đến trường “Message type ” kế tiếp. Originator Address : trường chứa địa chỉ chính (main address) của node (nơi phát ra bản tin). Trường này không phải là địa chỉ nguồn (source address) lấy từ IP header. Time To Live : trường chứa số lượng tối đa hops mà bản tin được truyền qua. Khi qua mỗi hop, trường này giảm đi 1.Khi một node nhận được bản tin có trường TTL bằng 0 hoặc 1 thì bản tin sẽ bị huỷ. Hop Count : trường này cho biết số hop mà một bản tin đi qua khi tới đích. Khi đi qua mỗi hop trường này sẽ tăng lên 1. Message Sequence Nuber : khi phát đi một bản tin, node gốc sẽ được phân cho một số duy nhất để nhận dạng bản tin đó. 3.3.2 Định dạng bản tin Hello. Hình 3.2 Định dạng bản tin Hello Reserved : trường thiết lập bởi “0000000000000”. Htime : thời gian phát ra bản tin Hello. Khoảng thời gian phát bản tin Hello được mô tả bởi phần định trị của nó ( 4 bit đầu của trường Htime). Willingness : trường mô tả khả năng “willingness” (sự bằng lòng) của một node để mang theo và vận chuyển lưu lượng cho node khác. Một node có trường willingness là WILL_NEVER sẽ không bao giờ được chọn làm MPR. Chỉ những node có trường willingness là WILL_ALWAYS mới được lựa chọn làm MPR. Link Code : trường mô tả thông tin về link cũng như thông tin về hàng xóm. Link Message Size : trường mô tả kích thước của bản tin link, tính từ trường “Link Code” này đến trường “Link Code” kế tiếp. Neighbor Interface Address : trường chứa địa chỉ giao diện của node hàng xóm. Có 4 loại link và 3 loại hàng xóm : Link_Types : UNSPEC_LINK : cho ta biết không có thông tin đặc biệt từ đường link này. ASYM_LINK : cho ta biết đây là link bất đối xứng. SYM_LINK : cho ta biết đây là link đối xứng. LOST_LINK : cho ta biết đường link này đã bị mất. Neighbor_Type : SYM_NEIGH : cho ta biết hàng xóm có ít nhất một đường link đối xứng với node này. MPR_NEIGH : cho ta biết hàng xóm có ít nhất một đường link đối xứng và được lựa chọn làm MPR. NOT_NEIGH : cho ta biết hàng xóm không phải và chưa từng là SYM_NEIGH. 3.3.3 Định dạng bản tin TC ( Topology Control ). Hình 3.3 Định dạng bản tin TC Advertised Neighbor Sequence Number (ANSN) : số tuần tự được gắn với sự quảng bá hàng xóm. Mỗi khi một node phát hiện ra sự thay đổi về hàng xóm nó sẽ tăng số tuần tự này. Advertised Neighbor Main Address : chứa địa chỉ chính của node. Resrved : trường dự trữ, được dành riêng và thiết lập bởi “0000000000000000”. 3.3.4 Định dạng bản tin MID (Multiple Interface Declaration). Hình 3.4 Định dạng bản tin MID OLSR Interface Address : trường chứa địa chỉ một interface cuả một node (trừ địa chỉ chính) Bản tin MID chỉ được gửi bởi node có nhiều giao diện. 3.3.5 Định dạng bản tin HNA (Host and Network Associate). Hình 3.5 Định dạng bản tin HNA Network Address : địa chỉ của mạng kết hợp. Netmask : netmask phù hợp với địa chỉ mạng ở trên. 3.4 Hoạt động. Trong mạng Ad-hoc, khi các node mạng nằm trong vùng phủ sóng của nhau thì chúng có thể giao tiếp với nhau một cách đơn giản mà không cần cài đặt lên nó bất kỳ giao thức định tuyến nào. Nhưng khi các node mạng di chuyển ra khỏi vùng phủ sóng của nhau thì việc truyền tải thông tin giữa các node đó là không thể. Để giải quyết vấn đề này ta phải cài đặt lên mỗi node mạng một giao thức định tuyến. Với những những ưu điểm kể trên của mình, giao thức OLSR đã giải quyết vấn đề truyền multi-hop rất hiệu quả. Hình 3.6 Truyền multi-hop sử dụng OLSR Khi một node tham gia vào mạng nó sẽ hoạt động tuần tự theo các bước sau : Link sensing : mỗi node trong mạng sẽ gửi bản tin Hello một cách tuần tự. Dựa vào bản tin Hello mà các node thiết lập nên đường link với nhau. Để duy trì kết nối link, các node phải gửi và nhận bản tin Hello một cách định kỳ. Hình 3.7 Thiết lập đường link giữa hai node Neighbor detection : Sau khi thiết lập đường link, vẫn dựa vào bản tin Hello các node xây dựng mối quan hệ hàng xóm với nhau. Để hai node là hàng xóm của nhau thì chúng phải nhận và duy trì bản tin Hello một cách định kì theo đúng trường Htime của bản tin. Hình 3.8 Thiết lập mối quan hệ hàng xóm giữa hai node MPR selection và MPR signaling : Sau khi các node đã thiết lập mối quan hệ hàng xóm với nhau, chúng sẽ bầu chọn ra một node trong số những hàng xóm đó (1-hop neighbor) làm MPR để “retrasmit” các bản tin broadcast. Hình 3.9 Minh hoạ về MPR Node MPR Topology Control Message Diffusion : Để mạng hội tụ và các node có thể tính toán chính xác bảng định tuyến của mình, mỗi node gửi vào mạng bản tin TC quảng bá thông tin đầy đủ về các node cũng như trạng thái link mà mình có. Route Calculation : Sau khi có đầy đủ thông tin về topo mạng, mỗi node tự tìm đương đi ngắn nhất tới đích (node khác) đi qua node MPR cho riêng mình. Tuyến đường này sẽ được lưu vào bảng định tuyến của nó. Khi phát hiện có bất kì thay đổi nào về đường link, hàng xóm, topo mạng, …, các node tự động tính toán và cập nhật lại bảng định tuyến. Khi mạng ổn định ta sẽ có bảng định tuyến như sau : Hình 3.10 Bảng định tuyến 3.5 Thông số cần quan tâm. 3.5.1 Link quality. Hình 3.11 Link quality Thông số này cho ta biết chất lượng kênh truyền từ một node tới hàng xóm của nó. Có hai thông số Link quality cần quan tâm : LQ : chất lượng kênh truyền từ một node tới hàng xóm của nó. Thông số này cho ta biết tỉ lệ mất gói khi truyền một bản tin từ một node tới hàng xóm của nó. NLQ : chất lượng kênh truyền từ hàng xóm của một node tới node đó. Thông số này cho ta biết tỉ lệ mất gói khi truyền một bản tin từ hàng xóm của một node tới node đó. LQ và NLQ có giá trị giữa 0 và 1 tương ứng với 0% tới 100% . Giá trị của thông số càng cao thì chất lượng đường link càng tốt. 3.5.2 ETX-Expected Transmission Count. Khi truyền một bản tin ta cần quan tâm xem khả năng tới đích của nó là thế nào, khi nào cần phải truyền lại gói và phải truyền bao nhiêu lần gói đó thì mới thành công. Thông số ETX cho ta biết điều đó. Thông số ETX được xác định bởi : ETX = 1/(LQ*NLQ) Thông số ETX là số lớn hơn hoặc bằng một. Giá trị ETX càng nhỏ càng tốt. Chú ý : Thông số ETX trên chỉ là thông số ETX giữa hai node hàng xóm với nhau. Khi truyền một gói tin từ nguồn tới đích qua nhiều node ta phải xác định được ETX trên toàn chặng. ETX toàn chặng tính bằng tổng ETX qua mỗi hop. ETX = ETX1 + ETX2 + ………..+ ETXn 3.6 Phân tích bảng định tuyến. Hình 3.12 Phân tích bảng định tuyến Đây là bảng định tuyến của node có địa chỉ 192.168.10.113. Thông số của LINK : IP address : địa chỉ của hàng xóm kết nối với node. Từ bảng định tuyến ta thấy node này có hai hàng xóm có địa chỉ là : 192.168.10.100 và 192.168.10.111. Hyst : giá trị trễ hiện tại của đường link. Thông thường khi cài đặt cho một node ta không dùng thông số này nên giá trị “hyst” bằng 0 LQ : chất lượng của đường link Lost : số lượng gói mất trong số n gói được gửi gần đây bởi hàng xóm qua đường link này. N là link quality windown size (kích thước cửa sổ) Total : tổng số gói nhận tính cho đến thời điểm hiện tại. NLQ : chất lượng đường link nhìn từ phía hàng xóm. ETX : ETX của đường link. Thông số của Two hop neighbor : IP addr (2-hop) : địa chỉ của 2-hop neighbor. Từ bảng định tuyến ta thấy node này có hai 2-hop neighbor : 192.168.10.100 (có được từ 1-hop neighbor 192.168.10.111) và 192.168.10.111 (có được từ 1-hop neighbor 192.168.10.100) IP addr (1-hop) : địa chỉ của neighbor. Trong bảng định tuyến này ta thấy node có địa chỉ 192.168.10.100 và node có địa chỉ 192.168.10.111 vừa là 1-hop neighbor vừa là 2-hop neighbor. Điều này là do mạng ở trong thí nghiệm này là mạng hình tam giác. 1-hop neighbor 192.168.10.100 quảng bá node hàng xóm 192.168.10.111 cho node 192.168.10.113. Node 192.168.10.113 ghi node 192.168.10.111 vào bảng định tuyến của mình với vai trò là 2-hop neighbor. Tương tự như vậy, node 192.168.10.111 vừa là 1-hop vừa là 2-hop neighbor của nó. Thông số của Topology : Source IP addr : địa chỉ IP nguồn. Dest IP addr : địa chỉ IP đích. LQ : chất lượng đường link từ nguồn tới đích. ILQ : chất lượng đường link từ đích về nguồn. ETX : ETX giữa nguồn và đích. Cài đặt và sử dụng. Trên Windows : Download chương trình OLSR cho Windowns tại trang Web : Cài đặt file olsr.exe. Hình 3.13 Cài đặt OLSR trên Windows Chạy chương trình : Thiết lập các thông số như hình 3.14 rồi nhấn node start. Hình 3.14 Chạy OLSR trên Windows Trên Linux : Download chương trình OLSR cho linux tại trang Web : Giải nén và cài đặt : Hình 3.15 Cài đặt OLSR trên Linux Chỉnh sửa các thông số cho phù hợp bằng lệnh “ vi /etc/olsr.conf ” hoặc “ gedit /etc/olsrd.conf ” Hình 3.16 Chỉnh sửa cấu hình OLSR Chạy chương trình bằng cách gõ lệnh olsrd trên cửa sổ terminal : Hình 3.17 Chương trình OLSR trên Linux và Windows Quản lý và chỉnh sửa mã nguồn : Mã nguồn nằm trong thư mục src. Để tiện cho việc chỉnh sửa và quản lý mã nguồn ta dùng chương trình Kdevelop. Hình 3.18 Mã nguồn chương trình OLSR CHƯƠNG 4 KẾT QUẢ NGHIÊN CỨU , KẾT LUẬN VÀ HƯỚNG NGHIÊN CỨU TIẾP THEO Mục tiêu nghiên cứu. Mục tiêu của đề tài là xây dựng giao thức định tuyến để tối ưu hệ thống truyền Multimedia đa chặng thời gian thực. Để tối ưu được việc truyền thời gian thực ta phải xây dựng được hệ thống có sự trao đổi giữa các tầng để điều khiển tốc độ cũng như chất lượng dữ liệu. Trong hệ thống này, các tầng cần trao đổi là tầng định tuyến và tầng truyền. Hay nói cách khác là sự trao đổi giữa OLSR và VLC. Mô hình trao đổi giữa VLC và OLSR : Hình 4.1 Mô hình trao đổi giữa OLSR và VLC Giao tiếp xuyên tầng giữa OLSR và VLC dựa trên cơ chế giao tiếp giữa các tiến trình sử dụng chung vùng nhớ ngoài để chia sẻ dữ liệu. Nội dung chính của vùng nhớ ngoài là : OLSRD_pid : chỉ số tiến trình của OLSR. VLC_pid : chỉ số tiến trình của VLC. ETX_value : giá trị ETX được đưa từ tầng định tuyến lên tầng truyền. Cơ chế giao tiếp : OLSR gửi giá trị ETX lên vùng nhớ chung mỗi khi giá trị này có sự thay đổi. Sau khi gửi giá trị ETX, tầng định tuyến sẽ gửi tín hiệu thông báo lên tầng truyền thông qua tín hiệu để tầng truyền nhanh chóng cập nhật sự thay đổi. Tầng truyền ngay khi nhận được tín hiệu thông báo sẽ truy cập vùng nhớ chung để lấy giá trị ETX mới. Thiết kế hệ thống : Trong vlc xây dựng một tuyến (thread) giao tiếp với OLSR thông qua vùng nhớ chung. Tuyến này chỉ “thức dậy” khi được đánh thức bởi một tín hiệu đồng bộ tuyến từ hàm signal_catch(). Hàm signal_catch() là hàm được xây dựng để bắt tín hiệu thông báo của OLSR. Thí nghiệm. Thí nghiệm 1. Đánh giá kết nối đa chặng sử dụng giao thức OLSR Hardware : Hai Laptop chạy hệ điều hành Linux với các địa chỉ IP : 192.168.10.111 ( node A ) và 192.168.10.113 ( node B). Bo nhúng Armadillo300 có địa chỉ IP : 192.168.10.100 ( node C ). Software : Giao thức định tuyến OLSR cài đặt trên cả 3 máy. Thí nghiệm : Chạy giao thức OLSR trên cả ba máy. Ban đầu cả ba máy đều đặt trong phòng Lab411. Bảng định tuyến trên node B thể hiện ở hình 4.2. Hình 4.2 Bảng định tuyến đơn chặng Từ bảng định tuyến ta thấy : Node B có hai hàng xóm là node A và node C. Ba node này nằm trong vùng phủ sóng của nhau nên mạng ở đây là mạng hình tam giác. Do đó node A và node C vừa là 1-hop neighbor vừa là 2-hop neighbor của node B. Di chuyển hai node A và B ra khỏi phòng Lab 411 về hai phía của C cho đến khi hai node A và B không nhìn thấy nhau ở thông tin về đường LINK trong bảng định tuyến. Lúc này, bảng định tuyến nhìn thấy ở node B như hình 4.3. Hình 4.3 Bảng định tuyến đa chặng Từ bảng định tuyến ta thấy : Node C là hàng xóm 1-hop neighbor của node B. Node A là hàng xóm 2-hop neighbor của node B. Topo mạng không thay đổ do bảng định tuyến chứa thông tin về cả đường đi tới đích 1-hop và 2-hop. Để chứng minh node A là hàng xóm 2-hop neighbor của B và kiểm tra kết nối giữa A và B ta dùng lệnh tracerout để tìm đường từ B đến A. Trên của sổ terminal của node B ta gõ lệnh : tracerout 192.168.10.111. Hình 4.4 Kiểm tra kết nối đa chặng Qua lệnh tracerout ta thấy : Kết nối giữa node A và node vẫn còn dù nó không xuất hiện trong thông tin đường LINK của nhau tại bảng định tuyến. Node B sẽ đi qua node trung gian C để tới node A. Kết luận : giao thức OLSR đáp ứng tốt cho việc duy trì kết nối đa chặng. Thí nghiệm 2. Giao tiếp giữa OLSR và VLC Test 1: Hardware : Hai PC chạy Linux có địa chỉ IP : 192.168.1.33 và 192.168.1.40 Webcam Software : Chương trình VLC và OLSR được cài đặt trên cả hai máy. Chạy chương trình OLSR và VLC trên cả hai máy. Sử dụng chương trình VLC trên PC có địa chỉ 192.168.1.40 để truyền video. Khi chạy chương trình VLC để truyền video thì hai chương trình VLC và OLSR sẽ trao đổi thông tin với nhau về các thông số : địa chỉ IP nguồn, đích, giá trị ETX như hình 4.5. Hình 4.5 Tương tác giữa OLSR và VLC Kết luận : Xây dựng thành công bước đầu giao tiếp giữa tầng truyền và tầng định tuyến. Test 2 : Truyền video đơn chặng Hardware : Labtop chạy hệ điều hành Linux có địa chỉ IP là : 192.168.11.18 PC có card Wifi chạy hệ điều hành Linux với địa chỉ IP là : 192.168.11.20 Webcam. Software : Streaming server chạy trên PC được cài đặt chương trình VLC và bộ encoder H.264. Dữ liệu video truyền lấy từ Webcam gắn trên PC. Client chạy trên Laptop được cài đặt chương trình VLC và bộ decoder H.264. Chạy chương trình OLSR trên cả hai máy. Trên PC khởi động việc truyền video. Hình 4.6 Truyền Video Hình 4.7 Nhận Video Kết luận : Hệ thống truyền và nhận video tốt và có sự trao đổi giữa tầng truyền và tầng định tuyến. Thí nghiệm 3. Truyền video đa chặng thời gian thực Hardware : Ba labtop chạy hệ điều hành Linux với các địa chỉ IP là : 192.168.12.104 (node A), 192.168.12.105 (node B), 192.168.12.165 (node C). Webcam. Software : Chương trình OLSR, H.264, VLC chạy trên 3 máy. Địa điểm thí nghiệm : sân trường đại học Bách Khoa Hà Nội. Nội dung thí nghiệm : Máy A và B di chuyển về hai phía của B. Hai máy này chạy định tuyến OLSR và chương trình VLC để truyền và nhận dữ liệu thu được từ Webcam cho nhau. Máy C không chạy định tuyến và đứng nguyên tại chỗ. Hai máy A và B di chuyển đến khi dữ liệu có dấu hiệu không ổn định thì di chuyển từ từ đến lúc nào không thể truyền và nhận dữ liệu thì dừng lại không di chuyển nữa nhưng vẫn tiếp tục chạy chương trình. Lúc này, máy C mới bắt đầu chạy định tuyến. Sau khi máy C chạy định tuyến, nếu hai máy A và B lại trao đổi dữ liệu được với nhau là thành công. Kết quả thí nghiệm : Máy A di chuyển đến cổng Parabol, máy B đến thư viện điện tử thì kết nối bị mất và không thể truyền dữ liệu cho nhau được nữa. Khi máy C chạy định tuyến thì máy A và B có kết nối với nhau và tiếp tục truyền và nhận dữ liệu bình thường. Hình 4.8 Truyên video đa chặng Kết luận : Giao thức định tuyến OLSR chạy tốt trong việc truyền đa phương tiện đa chặng trong mạng Ad-hoc. Kết luận chung. Trong thời gian nghiên cứu đề tài đã xây dựng thành công việc truyền và định tuyến cho ứng dụng truyền thông đa phương tiện đa chặng trên mạng Ad-hoc. Khi các node di động thì việc truyền đa phương tiện không bị gián đoạn và chất lượng dữ liệu thu được là tạm ổn. Việc giao tiếp xuyên tầng ( tầng truyền và tầng định tuyến ) bước đầu cũng đã thu được kết quả. Ngoài ra, hệ thống còn có thể triển khai được trên các bo nhúng chứ không phải PC hay Laptop thông thường, dù bo nhúng chỉ hoạt động với vai trò là node trung gian. Tuy nhiên do trình độ có hạn và thời gian nghiên cứu không được nhiều nên kết quả thu được chưa đạt tới mong muốn đề ra như : lựa chọn đường đi từ nguồn tới đích theo ý mình, cơ chế truyền lại gói cần thiết bị mất mà vẫn đảm bảo tính “thực” của dữ liệu. Hướng nghiên cứu tiếp theo. Từ những thiếu sót kể trên, hướng nghiên cứu tiếp theo của đề tài là : Lựa chọn, định tuyến đường đi của dữ liệu từ nguồn tới đích theo ý mình. Xây dựng cơ chế truyền lại gói tin cần thiết bị mất để vừa đảm bảo tính trọn vẹn của dữ liệu vừa đảm bảo tính “thực” của nó. Phát triển để bo nhúng có thể ứng dụng tất cả các tính năng của hệ thống như PC hay Labtop thông thường. Tính toán được thông số ETX end to end ( từ nguồn tới đích ) để đưa vào bảng định tuyến và gửi cho tầng truyền. Xây dựng hệ thống đa phương tiện thời gian thực trên mạng hỗn hợp. Hình 4.9 Mô hình hệ thống đa phương tiện trên mạng hỗn hợp OLSR ABR ZRP ROUTING PROTOCOL FOR MANET FSR REACTIVE TORA DSR DSDV TÀI LIỆU THAM KHẢO [1] C. Siva Ram Murthy and B.S.Manoj, “Ad Hoc Wireless Networks: Architectures and Protocols (Prentice Hall Communications Engineering and Emerging Technologies Series)”, June 3 2004. [2] T. G. Basavaraju, C. Puttamadappa, “Ad Hoc Mobile Wireless Networks: Principles, Protocols and Applications”, 2007. [3] Arun Mukhija, “Reactive Routing Protocol For Mobile Ad-hoc Network”, December 2001. [4] J.R.R Tolkien , “Mobile Ad-hoc Network”, July 29 2004. [5] : OLSR - Optimized Link State Routing Protocol. [6] Tien Pham Van, “Proactive ad hoc devices for relaying real-time video packets”, Doctor of Philosophy Dissertation 2007. [7] Phạm Văn Tiến, “Mạng Ad-hoc và các hướng nghiên cứu”, FETNEWS, 3/3008. [8] Iain E. G. Richardson , “H.264 and MPEG-4 Video Compression Video Coding for Next-generation Multimedia “, John Willey & Son 2003. [9] David Austerberry, “The Technology of Video and Audio Streaming”, Focal press 2005. [10] Alexis de Lattre, Anil Daoud, Benjamin Pracht, Clément Stenac, and Jean-Paul Saman, “VLC Play How to”. [11] Thomas Wiegand et al, Overview of the H.264/AVC video coding standard,. IEEE Trans. on circuits and systems for video technology, Vol. 13, No. 7, pp. 560-576, July 2003. [12] [13] [14]