Đồ án Nghiên cứu kiến trúc cluster của mạng cảm nhận không dây

 

MỤC LỤC 1

LỜI CẢM ƠN 3

NỘI DUNG CỦA ĐỀ TÀI 4

MỞ ĐẦU 5

CHƯƠNG I: GIỚI THIỆU VỀ MẠNG CẢM NHẬN KHÔNG DÂY 6

I.1Định nghĩa mạng cảm nhận không dây 6

I.2. Yêu cầu của mạng cảm nhận không dây 6

I.3.Ưu nhược điểm của WSN 6

I.3.1 Ưu điểm của WSN 6

I.3.2 Nhược điểm của WSN 6

I.4. CácKiến trúc của mạng cảm nhận không dây 7

I.4.1 Mạng đơn 7

I.4.2 Mạng liên kết bước 7

I.5 Tình hình nghiên cứu và ứng dụng WSN ở Trên thế giới và Việt Nam hiện nay 8

I.5.1 Ứng dụng WSN ở Trên thế giới 8

I.5.2 Ứng dụng WSN ở Việt Nam 9

CHƯƠNG II : KIẾN TRÚC NÚT MẠNG CẢM NHẬN KHÔNG DÂY 10

II.1 Bộ vi xử lý (xử lý dữ liệu: Nhiều loại) 10

II.2 Bo mạnh 10

II.3 Bộ lưu trữ 10

II.4 Bộ truyền thông 10

II.5 Bộ cảm biến, bộ khởi động 10

II.6 Giới thiệu về vi điều khiển CC1010 11

CHƯƠNG III : MẠNG CẢM NHẬN KHÔNG DÂY - KIẾN TRÚC CLUSTER 12

III.1 Giới thiệu chung về kiến trúc CLUSTER 12

III.2 Cấu trúc bó (địa chỉ các nút trong bó) 13

III.3.1Chu kỳ thiết lập bó 14

III.3.2 Giải thuật chọn nút đầu bó 15

III.3.3 Thiết lập bó 17

III.3.4 Giao thức phân cấp năng lượng thấp LEACH 20

III.4 Truyền thông trong WSN kiến trúc bó 23

III.4.1Truyền nhận dữ liệu 23

III.4.2 Giao thức truyền thông tránh xung đột 27

III.4.2.1 Giao thức lộ trình phản ứng DSR (Dynamic Source Routing) 28

III.4.2.2 Giao thức điều khiển truy cập môi trường trong mạng (MAC) 31

III.5 Các tình huống đặt ra đối với WSN kiến trúc bó 38

III.5.1 Giới hạn nút trong bó(quản lý kích thước bó) 38

III.5.2 khả năng tự cấu hình 38

 

III.5.3 khả năng cấu hình lại khi thêm nút hoặc có nút bị hỏng 39

CHƯƠNG IV: XÂY DỰNG THỬ NGHIỆM MẠNG CẢM NHẬN KHÔNG DÂY KIẾN TRÚC CLUSTER (Kiến trúc Bó) 43

IV.1. Yêu cầu 43

IV.2 Lập trình thử nghiệm 44

IV.2.1 Khái quát về chương trình 44

IV.2.2 Sơ đồ khối và giải thuật 46

IV.2.4 Thư viện HAL của CC1010 47

IV.2.5 Chương trình chính 59

IV.3 Các bước thực hiện chương trình 67

IV.3.1 Dịch chương trình 67

IV.3.2 Nạp chương trình 67

IV.3.3 Thực hiện truyền nhận dữ liệu 68

 

 

doc59 trang | Chia sẻ: lynhelie | Lượt xem: 1406 | Lượt tải: 0download
Bạn đang xem trước 20 trang tài liệu Đồ án Nghiên cứu kiến trúc cluster của mạng cảm nhận không dây, để xem tài liệu hoàn chỉnh bạn click vào nút DOWNLOAD ở trên
i đoạn thiết lập để nghe các thông báo của tất cả các nút đầu bó. Sau khi giai đoạn này hoàn thành, mỗi nút thành viên quyết định chọn bó mà nó thuộc về trong vòng tới. Việc lựa chọn này dựa trên chiều dài tín hiệu thông báo nhận được. Giai đoạn 2: thiết lập bó: Sau khi mỗi nút đã quyết định thuộc về bó nào, nó phải khai báo với nút đầu bó rằng nó sẽ là một thành viên của bó. Mỗi nút truyền lại thông tin này tới nút đầu bó sử dụng một giao thức CSMA MAC. Trong giai đoạn này, tất cả các nút đầu bó phải luôn giữ trạng thái lắng nghe Giai đoạn 3: Khởi tạo lịch trình Nút đầu bó nhận tất cả các thông báo từ các nút trong bó. Dựa vào số lượng các nút trong bó, nút đầu bó tạo ra một lịch trình TDMA để thông báo cho mỗi nút thành viên biết khi nào nó có thể truyền thông. Lịch trình này sẽ được quảng bá lại cho các nút trong bó. Giai đoạn 4: Truyền thông dữ liệu Một khi các bó được tạo, lịch trình TDMA được cố định, quá trình truyền dữ liệu được bắt đầu. Nút đầu bó nhận tất cả dữ liệu từ các nút trong bó, khi tất cả dữ liệu được thu thập, nút đầu bó thực hiện các chức năng xử lí tín hiệu để nén dữ liệu vào trong một tín hiệu đơn. Tín hiệu tổng hợp này sẽ được gửi tới trạm cuối III.4 Truyền thông trong WSN kiến trúc bó III.4.1Truyền nhận dữ liệu Trong chế độ Transparent và UART dữ liệu đến và đi được đưa trực tiếp đến bộ điều chế và giải điều chế. Tuy nhiên trong chế độ Manchester và NRZ dữ liệu được đưa tới thanh ghi RFBUF Để xác định tốc độ truyền dữ liệu qua RF, lựa chọn tần số dao động thạch anh và các chế độ dữ liệu ta có thể thiết lập ở thanh ghi MODEM0(Thanh ghi điều khiển Modem). - MODEM0.BAUDRATE(2:0): Xác định tốc độ. - MODEM.DATAFORMAT(1:0): Xác định các chế độ dữ liệu. - MODEM.XOSC_FREG(2:0): Lựa chọn tần số dao động thạch anh. Có 4 chế độ dữ liệu khác nhau được định sẵn cho việc truyền và nhận. Chúng có thể lập trình được thông qua MODEM0.DATA_FORMAT. Các chế độ này khác nhau trong cách mã hóa dữ liệu, cách gửi và nhận dữ liệu cho dù việc tái đồng bộ các bit có được thực hiện hay không. Định dạng dữ liệu phải được lựa chọn trước khi truyền nhận. Hai trong các chế độ hoạt động, đó là NZR và Manchester. Tốc độ truyền dữ liệu được xác định trong MODEM0.BAUDRATE. MODEM thực hiện việc tái đồng bộ các bit trong suốt quá trình nhận. Trong chế độ hoạt động mã Manchester, Modem luôn thực hiện việc mã hóa và giải mã theo mã Manchester. Chế độ hoạt động Manchester và NZR nhận và gửi dữ liệu theo từng bit hoặc từng byte, có thể lập trình thông qua RFCON.BYTEMODE. Hai chế độ hoạt động này được sử dụng trong phần lớn các ứng dụng. Hai chế độ hoạt động khác đó là: Transparent mode UART mode. Trong 2 chế độ này chỉ đơn giản là việc truyền dữ liệu giữa FSK modem, thanh ghi RFBUF và UART0. Tốc độ truyền từ 0.6kBaud đến 76.8kBaud có thể được lập trình thông qua bit điều khiển MODEM0.BAUDRATE. Bit điều khiển MODEM0.XOSC_FREQ cũng phải được thiết lập theo đồng hồ dao động đang sử dụng: Tốc độ truyền dữ liệu: Truyền dữ liệu Khi truyền dữ liệu trong chế độ bytemode(RFCON.BYTEMODE=1) thì các bit trong thanh ghi dịch 8 bit được chuyển tới bộ điều chế. Khi thanh ghi dịch này trống thì nó sẽ nạp dữ liệu mới từ thanh ghi RFBUF. Nội dung còn lại của thanh ghi RFBUF sẽ không bị ảnh hưởng gì, tuy nhiên sẽ có 1 yêu cầu ngắt được sinh ra để RFBUF có thể nạp dữ liệu mới. Nếu 1 byte dữ liệu mới không được ghi thì thanh ghi dịch sẽ trống và nó sẽ nạp lại byte dữ liệu từ RFBUF. Trong chế độ bitmode (RFCON.BYTEMODE=0) thì tại mỗi thời điểm chỉ có 1 bit được đưa vào bộ đệm. Vì vậy thanh ghi dịch sẽ nạp 1 bit mới từ RFBUF.0 sau mỗi bit được truyền đi. Để có thể ghi 1 bit mới vào RFBUF.0 trong chu kỳ 1 bit thì nên dùng chế độ hỏi vòng khép kín thay vì 1 thủ tục ngắt. Để có thể bắt đầu truyền dữ liệu 1 cách nhanh chóng thì byte hoặc bit đầu tiên phải được nạp vào thanh ghi RFBUF. Sau đó nó sẽ được nạp vào thanh ghi dịch và 1 yêu cầu ngắt sẽ được sinh ra cho byte/bit thứ 2. Nhận dữ liệu Khi nhận dữ liệu bộ đệm sẽ làm các công việc ngược lại so với quá trình truyền dữ liệu. Từng bit 1 trong bộ giải mã được chuyển vào thanh ghi dịch đầu tiên là bit MSB: Khi thanh ghi dịch đầy dữ liệu được đưa sang RFBUF và yêu cầu ngắt được sinh ra. Các byte phải được đọc trong 1 chu kỳ byte (chu kỳ 8 Baud đối với mã NRZ và chu kì 16 Baud đối với mã Manchester). Nếu không thì dữ liệu cũ sẽ bị ghi đè. Trong chế độ bitmode việc nạp đệm dữ liệu diễn ra tương tự nhưng tại một thời điểm chỉ có một bit được nạp vào. Vì vậy khi bit dữ liệu mới đến từ bộ giải mã thì thanh ghi dịch sẽ lưu trữ nó và lưu bit cuối cùng vào RFBUF.0. Nó sẽ sinh ra một yêu cầu ngắt để có thể nhận được bit dữ liệu. RFBUF (0xC9) – RF Data Buffer Bit Name R/W Reset value Description 7:0 RFBUF R/W 0x00 RF Data Buffer, 8 bits, RFBUF is used as described below. RFCON (0xC2) – RF Control Register: III.4.2 Giao thức truyền thông tránh xung đột Trong WSN các gói tin có thể được định tuyến thông qua nhiều chặng, đó cũng chính là điều cần giải quyết cho vấn đề lộ trình trong mạng cảm nhận không dây. Mỗi nút tại các thời điểm luôn lưu giữ thông tin về đường đi tới tất cả các nút còn lại, kể cả các nút không giao tiếp tới. Bên cạnh đó là một tiếp cận cải tiến theo hướng phản ứng (reactive), việc thiết lập đường được thực hiện chỉ khi có yêu cầu. Các giao thức trong phạm trù này bao gồm giao thức thứ tự vectơ khoảng cách đến (Destination sequenced distance vector DSDV), giải thuật lộ trình có trật tự thời gian (TORA), sơ đồ lộ trình toàn cầu (GSR), và giao thức vectơ khoảng cách theo yêu cầu (The ad hoc ondemand distance vector protocol - AODV). Trong phạm vi của đề tài, chúng ta đi sâu nghiên cứu về giao thức DSR (Dynamic Source Routing), DSR là giao thức định tuyến phản ứng sử dụng định tuyến nguồn (source routing) đặc trưng cho giao thức theo yêu cầu (on-demand protocol). Tiêu đề của các gói tin dữ liệu chứa thứ tự các nút mà gói tin cần phải đi qua để tới đích. Do vậy, các nút trung gian chỉ cần giữ liên lạc với các nút hàng xóm ngay sát cạnh mình để chuyển tiếp các gói tin. Ngược lại, nút nguồn cần phải biết thứ tự của toàn bộ các chặng để đạt tới đích. III.4.2.1 Giao thức lộ trình phản ứng DSR (Dynamic Source Routing) Khi một nút mạng được thêm hoặc giảm bớt khỏi mạng, quá trình tìm đường sẽ được tự động xác định và duy trì bởi giao thức DSR. Mỗi nút mạng có một Route Cache để lưu trữ mọi source route mà nó đã học. Khi một nút mạng cần gửi một gói dữ liệu, đầu tiên nó kiểm tra trong route cache của nó một source route tới nút đích. Nếu không có một source route tới nút đích thì nút gốc bắt đầu thực hiện quá trình phát hiện đường. Để hạn chế băng thông mạng, quá trình thiết lập đường chỉ được thực hiện khi một nút yêu cầu thiết lập đường đi (Lộ trình theo yêu cầu – On Demand Routing). Trong DSR, nút yêu cầu (source, initiator) xác định toàn bộ lộ trình từ nguồn tới nút đích.(Source-Routing) và đặt địa chỉ của các nút trung gian của lộ trình trong các packets. DSR được phát triển dành cho MANET với một đường kính nhỏ giữa 5 đến 10 bước nhảy và các nút chỉ nên di chuyển với tốc độ vừa phải. DSR dựa trên giải thuật link-state, trong đó mỗi nút có khả năng ghi nhớ cách tốt nhất để tới được đích. Và khi cấu trúc mạng có thay đổi, thì toàn bộ mạng sẽ có thông tin về sự thay đổi này. DSR bao gồm 2 giai đoạn: Route Discovery (Phát hiện đường) Route Maintenance (Duy trì đường) Bước 1:Phát hiện đường Hình 3.8: Cơ chế phát hiện đường Nếu trong nút A có một lộ trình tới nút đích E trong Route Cache, thì tuyến đường đó được sử dụng ngay lập tức. Nếu không có thì cơ chế phát hiện đường (Route discovery) sẽ được khởi động: • Nút A (nút nguồn) gửi một Route Resquest qua toàn bộ mạng. Route Resquest này bao gồm địa chỉ nút nguồn, địa chỉ nút đích, một danh sách lộ trình (route record) • Nếu gần đây nút B đã từng nhận Route Resquest có cùng một đích hoặc địa chỉ của nút B đã được liệt kê trong Route Record, thì nút B sẽ loại yêu cầu đó. • Nếu nút B là đích của cơ chế phát hiện đường, nó sẽ gửi gói Route Reply tới nút nguồn. Gói Route Reply chứa danh sách đường đi tốt nhất từ nút nguồn tới nút đích. Khi nút nguồn nhận được gói Route Reply này, nó lưu quẵng đường này vào trong Route Cache của nó để chuyển tiếp các gói tin sau tới nút đích. • Còn nếu nút B không phải là nút gốc thì nó chuyển tiếp Route Request tới các nút lân cận nó (ngoại trừ nút nguồn) Hình 3.9: Quá trình tìm đường: ROUTE REQUEST & ROUTE REPLY Bước 2:Duy trì đường Trong DSR mọi nút đều chịu trách nhiệm để xác nhận rằng nút tiếp theo trong Source Route nhận được gói tin, mỗi gói tin chỉ được chuyển tiếp duy nhất một lần bởi một nút (hop-by-hop routing). Nếu một gói không không được nhận bởi một nút, nó sẽ được phát lại với một số lần lớn nhất cho đến khi nút kế tiếp nhận được. Nếu kết quả quá trình phát lại thất bại, một thông báo Route Error được gửi tới nút nguồn,để loại bỏ Source Route trong Route Cache của nó. Như vậy nút nguồn có thể kiểm tra Route Cache cho tuyến đường khác tới đích. Nếu không có tuyến đường nào trong Cache, thì một gói Route Request phát quảng bá lại. Hình 3.10: Cơ chế duy trì đường Nếu nút C không nhận được một sự ghi nhận của nút D sau một số Request, nó sẽ gửi một Route Error tới nút nguồn A Ngay khi nhận được thông báo Route Error, nút nguồn sẽ xóa bỏ tuyến liên kết hỏng (broken-link-route) trong cache của nó. Nếu A có một tuyến đường khác tới E, nó sẽ gửi ngay các gói tin theo tuyến đường này. Nếu không nút nguồn A phi bắt đầu lại quá trình Route Discovery. III.4.2.2 Giao thức điều khiển truy cập môi trường trong mạng (MAC) A: Giao thức MAC Một nhiệm vụ cơ bản của giao thức MAC là tránh xung đột để hai nút bất kì không truyền thông tại cùng 1 thời điểm. Có rất nhiều giao thức MAC được phát triển cho các mạng truyền thông không dây và dữ liệu không dây. Các ví dụ tiêu biểu bao gồm: TDMA (Time division multiple access). CDMA (Code division multiple access). Các giao thức dựa trên sự tranh chấp như IEEE 802.11. Để thiết kế tốt một giao thức MAC dành cho mạng cảm nhận không dây, chúng ta dựa trên các đặc tính sau: Trước hết là hiệu quả năng lượng, như đã nêu trên, các nút cảm nhận thường sử dụng năng lượng nguồn pin, và thường rất khó để thay đổi hoặc nạp lại nguồn pin cho những nút này. Và thực tế, chúng ta mong đợi các nút đủ rẻ để vứt bỏ hơn là được nạp lại. Đặc tính quan trọng khác là tính biến đổi được để thay đổi kích thước mạng, mật độ các nút và kiến trúc mạng. Một vài nút có thể chết, một vài nút mới được thêm vào về sau, một vài nút có thể di chuyển tới các vị trí khác. Kiến trúc của mạng có thể thay đổi bởi rất nhiều lí do. Các đặc tính quan trọng khác bao gồm sự rõ ràng, sự tiềm ẩn, thông lượng và việc sử dụng băng thông. Các thuộc tính này nói chung được quan tâm chính trong các mạng dữ liệu và truyền thông không dây truyền thống, nhưng trong mạng cảm nhận không dây thì chúng chỉ là vấn đề phụ. S-MAC (Sensor MAC), một giao thức MAC mới được thiết kế dành cho mạng cảm nhận không dây. Trong đó việc giảm bớt tiêu thụ năng lượng là mục đích chính trong thiết kế của chúng ta, giao thức này cũng có khả năng biến đổi được và tránh né xung đột tốt. Nó đạt được khả năng biến đổi được và tránh né xung đột tốt bằng việc sử dụng một kết hợp giữa lịch trình và lược đồ tranh chấp. Để đạt được mục đích chính là hiệu quả năng lượng, chúng ta cần xác định đâu là nguồn gốc làm giảm hiệu quả năng lượng cũng như những sự cân bằng nào chúng ta có thể làm để giảm bớt tiêu thụ năng lượng. Chúng ta đã xác định 3 vấn đề chính gây ra lãng phí năng lượng: Sự xung đột. Nghe lỏm Việc điều khiển gói dữ liệu B: Giao thức S-MAC (Sensor MAC): Mục đích chính trong thiết kế giao thức S-MAC của chúng ta là giảm bớt tiêu thụ năng lượng, trong đó hỗ trợ tốt khả năng biến đổi được và tránh né xung đột. Giao thức của chúng ta cố gắng giảm bớt tiêu thụ năng lượng từ tất cả các vấn đề mà chúng ta đã xác định gây tiêu tốn năng lượng như: Idle listening, collision, overhearing, và control overhead. Để đạt được mục đích thiết kế, chúng ta sẽ phát triển giao thức S-MAC bao gồm 3 thành phần chính: chu kỳ Listen và SLEEP, tránh né xung tđột và nghe lỏm, truyền thông điệp. Phần 1: Chu kỳ tuần hoàn Listen và Sleep Trong nhiều ứng dụng của mạng cảm nhận, các nút nhàn rỗi trong trong một thời gian dài nếu không có sự việc nào xảy ra. Điều thật sự là nhịp độ dữ liệu trong trong thời gian này là rất thấp, và không cần thiết phải giữ các nút lắng nghe trong tất cả thời gian. Giao thức của chúng ta giảm bớt thời gian lắng nghe (listen) bằng việc để cho các nút vào trạng thái ngủ (sleep). Ví dụ, nếu trong mỗi giây một nút ngủ trong nửa giây và lắng nghe trong nửa giây còn lại, thì chu trình nhiệm vụ của nó giảm bớt tới 50%. Như vậy chúng ta có thể tiết kiệm tới 50% năng lượng. A – Lược đồ cơ bản Lược đồ cơ bản được trình bày trong hình 2.8: Hình3.11 : Chu kỳ listen và sleep Mỗi nút chuyển về trạng thái ngủ vài lần, và sau đó tỉnh dậy để lắng nghe nếu các nút khác muốn truyền thông với nó. Trong trạng thái ngủ, nút đó ngắt radio của nó, và đặt một khoảng thời gian để tự đánh thức. Khoảng thời gian để lắng nghe và ngủ có thể được lựa chọn theo những kịch bản ứng dụng khác nhau. Để đơn giản các giá trị này là tương đương cho tất cả các nút. Lược đồ của chúng ta yêu cầu sự đồng bộ hóa tuần hoàn giữa các nút lân cận để cứu chữa sự sai lệch chu kỳ của chúng.Tất cả các nút đều tự do để chọn lịch trình listen/sleep của chúng. Tuy nhiên để giảm bớt việc điều khiển vượt quá, chúng nên để các nút lân cận đồng bộ hóa cùng nhau.Nó cần phải được chú ý rằng không phải tất cả các nút lân cận có thể cùng đồng bộ hóa với nhau trong một mạng đa điểm. Hai nút lân cận A và B có thể có lịch trình khác nhau nếu chúng phải đồng bộ hóa với nút khác, C và D, tương ứng, như trong hình 2.9: Hình 3.12: Các nút lân cận A và B có lịch trình khác nhau B – Lựa chọn và duy trì lịch trình Trước khi mỗi nút bắt đầu chu kỳ listen và sleep, nó cần phải chọn một lịch trình và trao đổi với các nút lân cận của nó. Mỗi nút duy trì một bảng lịch trình cái dùng để lưu trữ các lịch trình của tất cả các nút lân cận mà nó biết. Nó sẽ theo các bước sau để chọn lịch trình của nó và thiết lập bảng lịch trình của nó: 1- Đầu tiên nút lắng nghe trong một lượng thời gian nhất định, nếu nó không nghe thấy một lịch trình nào từ các nút khác, nó sẽ ngẫu nhiên chọn một thời gian để chuyển về ngủ và ngay lập tức quảng bá lịch trình của nó trong một thông báo SYNC, thông báo rằng nó sẽ chuyển về trạng thái ngủ sau khoảng t giây. Chúng ta gọi một nút như vậy là một nút đồng bộ hóa, khi nó tự chọn lịch trình của nó và các nút khác sẽ đồng bộ hóa với nó. 2- Nếu nút nhận được một lịch trình từ một nút lân cận trước khi tự chọn lịch trình cho mình, nó đặt lịch trình của nó tương tự lịch trình nhận được. Chúng ta gọi một nút như vậy là một nút bộ phận. Sau đó nó sẽ đợi một khoảng td ngẫu nhiên và quảng bá lại lịch trình này, thông báo rằng nó sẽ chuyển về trạng thái ngủ trong t-td giây. Sự trì hoãn ngẫu nhiên này để tránh xung đột, để nhiều nút bộ phận từ cùng nút đồng bộ hóa không có xung đột hệ thống khi quảng bá lịch trình. 3- Nếu một nút nhận được một lịch trình khác khi nó đã tự chọn và quảng bá lịch trình của mình, nó chấp nhận cả 2 lịch trình (lịch trình của nó được đánh thức vào thời điểm của cả 2 lịch trình trên). Nó quảng bá lịch trình của mình trước khi ngủ. Chúng ta mong rằng các nút chỉ hiếm khi chấp nhận nhiều lịch trình, khi mỗi nút cố gắng theo lịch trình có sẵn trước khi chọn một lịch trình độc lập.Mặt khác, có thể là một vài nút lân cận không phát hiện được lẫn nhau khi bắt đầu bởi các sự xung đột khi quảng bá các lịch trình. Chúng vẫn có thể tìm thấy lẫn nhau về sau trong chu kỳ lắng nghe kế tiếp của chúng. C – Duy trì sự đồng bộ hóa: Lược đồ listen/sleep yêu cầu sự đồng bộ hóa giữa các nút lân cận. Mặc dù thời gian lắng nghe kéo dài có thể làm sai lệch thời gian khá lớn, các nút lân cận cần cập nhật định kỳ lịch trình của lẫn nhau để tránh việc sai lệch thời gian. Quá trình cập nhật có thể khá dài, các kết quả đo trên các nút thử nghiệm của chúng ta cho thấy rằng quá trình đó mất hàng chục giây. Việc cập nhật các lịch trình được hoàn thành bằng việc gửi một gói SYNC. Gói SYNC là rất nhỏ, nó bao gồm địa chỉ nút gửi và thời gian ngủ tiếp theo của nó. Thời gian ngủ tiếp theo là tương đối trong chốc lát mà nút gửi kết thúc quá trình truyền gói SYNC, xấp sỉ thời điểm bên nhận lấy được gói dữ liệu. Bên nhận sẽ điều chỉnh thời gian của nó ngay lập tức sau khi nó nhận gói SYNC. Một nút sẽ chuyển sang trạng thái ngủ khi thời gian kết thúc. Trong trường hợp một nút nhận được cả gói SYNC và gói dữ liệu, nó chia khoảng thời gian lắng nghe của nó thành 2 phần. Phần đầu dành cho việc nhận các gói SYNC, và phần 2 dành cho việc nhận các gói RTS, như trong hình 2.10. Hình 3.13 : Mối quan hệ thời gian giưa 1 bên nhận và nhiều bên gửi khác nhau Mỗi phần lại được chia thành rất nhiều khe thời gian để bên gửi thực hiện việc “cảm nhận sóng mang”(carrier sense). Ví dụ, nếu bên gửi muốn gửi một gói SYNC, nó bắt đầu cảm nhận sóng mang khi bên nhận bắt đầu lắng nghe. Nó ngẫu nhiên lựa chọn một khe thời gian để kết thúc việc cảm nhận sóng mang của nó. Nếu nó không phát hiện ra bất kỳ sự truyền thông nào trong khe thời gian, nó chiếm đường truyền và bắt đầu gửi gói SYNC của nó. Quy trình như vậy cũng được làm khi nút cần gửi gói dữ liệu. Hình 2.10 trình bày mối quan hệ thời gian của ba trạng thái có thể xảy ra khi một nút muốn truyền thông tới nút khác. CS tượng trưng cho cảm nhận sóng mang (carrier sense). Như trong hình, nút thứ nhất chỉ gửi một gói SYNC, nút thứ 2 chỉ muốn gửi dữ liệu, và nút thứ 3 gửi một gới SYNC và một gói RTS. Mỗi gói định kỳ quảng bá các gói SYNC tới các nút lân cận thậm chí các nút đó không thực hiện theo lịch trình đó. Điều này cho phép một nút mới gia nhập vào mạng hiện thời. Nút mới sẽ theo cùng quy trình trong tiểu khu để chọn lịch trình của nó. Thời kỳ lắng nghe ban đầu cần phải đủ dài để có thể học và theo một lịch trình có sẵn trước khi chọn một lịch trình mới. Phần 2: Cơ chế tránh né xung đột và nghe lỏm. Việc tránh né xung đột là một nhiệm vụ cơ bản của các giao thức MAC.S-MAC thông qua một lược đồ dựa trên sự tranh chấp. Đó là điều phổ biến rằng bất kỳ gói nào được truyền bởi một nút thì được nhận bởi tất cả các nút lân cận của nó mặc dù chỉ một trong số chúng là nút nhận. Sự nghe lỏm làm cho các giao thức dựa trên sự tranh chấp kém hiệu quả về năng lượng hơn các giao thức TDMA. Do đó cần giải quyết vấn đề này. A – Cơ chế tránh né xung đột. Khi có nhiều nút cần gửi tới một nút tại cùng một thời điểm, chúng cần phải tranh dành môi trường truyền để tránh xung đột xảy ra. Trong các giao thức dựa trên sự tranh chấp, 802.11 thực hiện rất tốt việc tránh né xung đột. Giao thức của chúng ta làm theo tương tự với các thủ tục, bao gồm cả cảm nhận sóng mang thực và ảo, và cả trao đổi RTS/CTS. Chúng ta chấp nhận cơ chế RTS/CTS để nhằm ẩn các vấn đề. Có một trường thời gian trong mỗi gói được truyền mà cái đó khai báo thời gian truyền thông còn lại là bao nhiêu. Như vậy nếu một nút nhận được một gói dành cho nút khác, nó biết rằng nó phải tạm ngưng trong khoảng bao lâu. Nút sẽ ghi giá trị này trong một biến được gọi là vector định vị mạng (NAV) và đặt một khoảng thời gian cho nó. Mỗi khi thời gian NAV chạy, nút sẽ giảm giá trị NAV cho tới khi nó bằng 0. Khi một nút muốn gửi dữ liệu, đầu tiên nó kiểm tra NAV, nếu giá trị NAV không bằng 0, nó xác định rằng môi trường đang bận. Điều này được gọi là cảm nhận sóng mang ảo. Tất cả các nút cần gửi thực hiện quá trình cảm nhận sóng mang trước khi bắt đầu một sự truyền thông. Nếu một nút thất bại trong việc chiếm môi trường, nó chuyển sang trạng thái ngủ và thức dậy khi bên nhận rỗi và lắng nghe lần nữa. Các gói quảng bá được gửi mà không sử dụng RTS/CTS. Các gói được truyền lần lượt RTS/CTS/DATA/ACK giữa bên nhận và bên gửi B- Cơ chế tránh nghe lỏm Trong 802.11 mỗi nút lắng nghe tất cả sự truyền thông của các nút lân cận nó để thực hiện hiệu quả việc cảm nhận sóng mang ảo. Như vậy, mỗi nút nghe lỏm rất nhiều các gói mà không gửi tới nó. Điều này gây lẵng phí năng lượng, đặc biệt khi mật độ các nút cao và việc tải trọng lớn. Giao thức của chúng ta cố gắng tránh né việc nghe lỏm bằng việc chuyển các nút về trạng thái ngủ khi nhận một gói RTS hoặc CTS. Một vấn đề cần quan tâm là các nút nào sẽ ngủ khi một sự truyền thông được bắt đầu. Hình 3.14 : Nút nào lên ngủ khi A truyền thông với B? Như trong hình 2.11, nút A,B,C,D,E và F hình thành một mạng đa bước, trong đó mỗi nút chỉ có thể nghe sự truyền thông từ các nút lân cận hiện thời của nó. Giả thiết nút A hiện thời truyền một gói dữ liệu sang B, tất cả các nút lân cận hiện thời của nút A và nút B nên chuyển về trạng thái ngủ khi nhận được gói RTS hoặc CTS cho đến khi sự truyền thông kết thúc. Mỗi nút duy trì NAV để chỉ báo hoạt động trong khu vục lân cận của nó. Khi một nút nhận một gói dành cho các nút khác, nó cập nhật NAV của nó bởi trường thời gian trong gói. Một giá trị NAV khác 0 chỉ ra rằng có một sự truyền thông đang hoạt động trong khu vực lân cận của nó. Giá trị NAV giảm bớt mỗi khi thời gian NAV chạy. Như vậy một nút cần ngủ để tránh nghe lỏm nếu giá trị NAV của nó khác 0. Nó thức dậy khi giá trị NAV bằng 0. III.5 Các tình huống đặt ra đối với WSN kiến trúc bó III.5.1 Giới hạn nút trong bó(quản lý kích thước bó) Để tránh việc có quá nhiều hay quá ít các nút trong một bó. Nhằm mục đích đảm bảo kết nối tốt và tránh xung đột. Nếu ta gọi A là nút đầu bó ,n(A) là số các nút nhỏ nhất và N(A) là số các nút lớn nhất trong một bó , khi đó số khả thi được đưa ra là N(A) = 8 với 3bit địa chỉ được gán cho một bó. Trường hợp nếu không đủ số nút cho một bó thì nút đầu bó giữ tín hiệu join và tăng bán kính(r) truyên lên : r = k.r (là giới hạn số lượng các nút mới) với k>1. Do đó xuất hiện giá trị Rmax , Nếu r>Rmax thì thuật toán sẽ kết thúc. Và mỗi nút sẽ cố gắng kết nối với bó hiện tại trước. Trong lúc nhận tín hiệu join_request, nút đầu bó kiểm tra xem bó có còn khả năng tiếp nhận cho một nút mới không. Nếu còn thì nút đầu bó sẽ trả lời lại một tín hiệu là join_confirm và gán cho nút đích một địa chỉ tạm. Nút đích sẽ gửi lại tín hiệu chấp nhận ACK. Nếu bó đã đầy thì nút đầu bó sẽ dừng lại việc liên lạc và nút cần kết nối sẽ khởi động lại chế độ trước và tiếp tục lắng nghe các nút đầu bó khác quảng bá. III.5.2 khả năng tự cấu hình Tính chất của mạng WSN là sử dụng rất nhiều nút mạng, với nhiều bước truyền trong mạng. Nên khả năng tự động tổ chức và duy trì mạng mà không cần sự can thiệp của người quản trị mạng là một yêu cầu đối với mạng cảm nhận không dây kiến trúc bó. Khả năng tự cấu hình được đề xuất bởi Subramanian và Kats lần đầu tiên cho một tầng mạng được tự động cấu hình địa chỉ và một số lượng các thuộc tính hữu ích khác. Thuật toán. Cấp cho mỗi nút mạng một địa chỉ duy nhất, cho phép các gói dữ liệu định tuyến giữa mỗi hai cặp nút mạng ,và thiết lập lại mạng trong trường hợp đường liên kết hoặc nút mạng bị lỗi. Gồm 4 giai đoạn : Giai đoạn tìm kiếm : Các nút mạng tìm hiểu các nút lân cận nó và thiết lập bán kính truyền dữ liệu . Giai đoạn cấu hình : các nút mạng bắt đầu tập hợp lại thành bó, các bó hợp lại thành bó lớn hơn , các bó này là lớn ngang nhau trong một vài vị trí các bó có thể không cùng kích thước kết hợp nhau nhằm để cho hai bó xấp sỉ bằng nhau. Nhằm mục đích duy trỳ bảng định tuyến. Giai đoạn duy trì :Mỗi nút mạng phát ra đều đặn một tín hiệu “ I`m alive”, nó thông báo cho các nút lân cận của nó bảng định tuyến và nó vẫn còn trong mức độ năng lượng hoạt động. Tiến trình này được gọi là sự kiểm tra hoạt động, một nút mạng sẽ hỏi các nút khác để biết nếu nó còn đang hoạt động. Giai đoạn cấu hình lại : Một nút khi phát hiện ra nút lân cận bị lỗi hoặc một bó bị phân chia, và nó cập nhật bảng định tuyến của nó. Nếu một bó bị chia cắt, bó đó sẽ cố gắng kết nối vào một bó hiện tại khác trong khi vẫn giữ nguyên sự cân bằng của về cấp độ trong mạng. III.5.3 khả năng cấu hình lại khi thêm nút hoặc có nút bị hỏng Khi một nút nào đó bị lỗi hoặc có thêm nút mới trong mạng thì mạng sẽ tiến hành cấu hình lại Các lỗi được xác địng như sau : Nút mạng bị lỗi : Mỗi nút liên tục gửi thông báo ” I am alive” tới các nút lân cận của nó. Nếu một nút không nhận một sự đáp lại từ các nút lân cận của nó trong sáu khoảng thời gian liên tiếp, thì nút đó giả thiết rằng nút lân cận đó đã chết. Nó sẽ cập nhật tất cả các đường đến trong bảng định tuyến của chúng, nhữnh chặng có chứa nút bị lỗi đó. Đường liên kết bị lỗi: Một lỗi liên kết xuất hiện khi một nút trở lên không thể với tới nút khác. Trong trường hợp này, bảng lộ trình được thay đổi tương ứng tại cả hai nút. Nhóm (bó ) bị phân chia: : Nếu tất cả các mối liên kết nối giữa hai phần của một nhóm bị lỗi hoặc nếu vài nút quan trọng bị lỗi thì nhóm bị phân chia thành hai mảnh hoặc nhiều hơn rời ra. Những mảnh rời ra này tự tổ chức lại vào trong những nhóm mới và sự kết hợp với những nhóm xung quanh khác. Trong trường hợp đó, địa ch

Các file đính kèm theo tài liệu này:

  • docbaocaotom tat.doc
  • pptbao cao.ppt