Changes between Version 36 and Version 37 of Letibee


Ignore:
Timestamp:
Nov 5, 2010, 3:42:39 PM (13 years ago)
Author:
Sensei
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Letibee

    v36 v37  
    6262* netflood          : The netflood module does best-effort flooding.
    6363* multihop          : The multihop module implements a multihop forwarding mechanism.
    64 * neighbor          : The neighbor module manages the neighbor table.
    65 * neighbor discovery: The neighbor-discovery module implements a periodic neighbor discovery mechanism.
     64* neighbor          : The neighbour module manages the neighbor table.
     65* neighbor discovery: The neighbour-discovery module implements a periodic neighbor discovery mechanism.
    6666* route             : The route module handles the route table in RIME.
    6767* route discovery   : The route-discovery module does route discovery for RIME.
     
    7878==== Network frame format ====
    7979
    80 All packets are transmitted on the radio channel according to the framing of the IEEE802.15.4 standard (Figure 3) where the useful packet for the MAC, the MPDU(=PSDU), length is limited to 127bytes.
     80All packets are transmitted on the radio channel according to the framing of the IEEE802.15.4 standard where the useful packet for the MAC, the MPDU(=PSDU), length is limited to 127 bytes.
    8181The frame formats transmitted over the air are summarised here after.
    8282
     
    9797
    9898If the sink receives a Lookup Request from the Gateway:
    99 * Send a Lookup Request Frame (with echoes) via netflood module.
     99* Sends a Lookup Request Frame (with echoes) via netflood module.
    100100* Waits for a Ping Response Frame from nodes.
    101101
    102102==== HELLO/BYE operations ====
    103 When a node join the network:
    104 * Send a Hello Request Frame (with echoes) via mesh module.
    105 When a node leave the network:
    106 * Send a Bye Request Frame (with echoes) via mesh module.
     103When a node joins the network:
     104* Sends a Hello Request Frame (with echoes) via mesh module.
     105When a node leaves the network:
     106* Sends a Bye Request Frame (with echoes) via mesh module.
    107107
    108108==== PING operations ====
     
    110110
    111111* For each node
    112   * Send a Ping Request Frame (with echoes if no response is received) via mesh module.
     112  * Sends a Ping Request Frame (with echoes if no response is received) via mesh module.
    113113  * Waits for a Ping Response Frame from the node (other responses are ignored) or the timeout
    114114
     
    119119===== Ping response =====
    120120The Ping Response frame is sent in response to a Ping request frame.
    121 It provides the number of hops to reach the node which initiated the ping request.
     121It provides the number of hops to reach the node which had initiated the ping request.
    122122
    123123==== DV-HOP operation ====
    124124If the sink receives an Anchor Request from the Gateway:
    125125* For each node
    126  * Send an Anchor Request Frame (with echoes if no response is received)
     126 * Sends an Anchor Request Frame (with echoes if no response is received)
    127127 * Waits for an Anchor Response Frame from the node (other responses are ignored) or the timeout
    128128
     
    132132* If an Anchor Request Frame is received
    133133 * For each anchor node (listed in the Anchor Request Frame)
    134   * Send a Ping Request Frame
    135   * Waits for a Ping Response Frame from the anchor node (other responses are ignored) or the timeout
     134  * Sends a Ping Request Frame
     135  * Waits for a Ping Response Frame from the anchor node (other responses are ignored) or for the timeout
    136136
    137137===== Anchor request =====
     
    163163 * Every second
    164164  * For each node
    165    * Send a Neighbour Request Frame
     165   * Sends a Neighbour Request Frame
    166166   * Waits for a Neighbour Response Frame from the node (other responses are ignored) or the timeout
    167167
    168 ===== Neighbor request =====
    169 
    170 The Neighbor request frame is initiated by a sink to request a node to send its table made of the (neighbour address, RSSI time, RSSI value, LQI value) quadruplets.
    171 
    172 ===== Neighbor response =====
    173 
    174 The Neighbor response frame is initiated by a node in response to a Neighbor request command frame received form a sink.
     168===== Neighbour request =====
     169
     170The Neighbour request frame is initiated by a sink to request a node to send its table made of the (neighbour address, RSSI time, RSSI value, LQI value) quadruplets.
     171
     172===== Neighbour response =====
     173
     174The Neighbour response frame is initiated by a node in response to a Neighbour request command frame received form a sink.
    175175It contains its table of neighbours and is made of the (neighbour address, RSSI time, RSSI value, LQI value) quadruplets as requires by the RSSI based location algorithm.
    176176The RSSI time field indicates in seconds the age of the RSSI and LQI entries.
     
    178178Moreover the frame payload contains the values of the sensor readings of the node (8 bytes, fixed with 1 byte per sensor according to the bitmap field “active_sensors” of the header.
    179179
    180 The header of the frame indicates whether the frame was fragmented, in case the original APDU size would have exceeded the maximal size supported by the PHY layer. 
     180The header of the frame indicates whether the frame was fragmented, in case the original APDU size would have exceeded the maximal size supported by the PHY layer.
    181181The total number of fragments is given by the field “nb_fragments” and the current fragment number by the field “fragment_num”.
    182182
     
    188188
    189189* For each node
    190  * Send a Route Request Frame (with echoes if no response is received) via mesh module.
     190 * Sends a Route Request Frame (with echoes if no response is received) via mesh module.
    191191 * Waits for a Route Response Frame from the node (other responses are ignored) or the timeout
    192192
     
    199199The Route Request frame is initiated by a node in response to a Route request command frame received from a sink.
    200200It contains the entries of the routing table (destination address, next hop adress, route cost, route time).
    201 This frame shall not be confounded with the RREP frames that are classically used in the networking layer of the protocol.
     201This frame shall not be confused with the RREP frames which are classically used in the networking layer of the protocol.
    202202The route cost contains a cost metric for the corresponding route, whereas the route time contains a value in seconds about the age of the route.
    203203
     
    213213
    214214This approach allows to decouple the data acquisition from the data treatment and in addition provides a tunable persistent storage of the sensed data.
    215 It is too very easy to simulate sensor networks by populating the database with an external script.
     215It is then easy to simulate sensor networks by populating the database with an external script.
    216216
    217217=== Database ===
     
    261261=== Octave algorithms ===
    262262
    263 Octave algorithms are used to compute rssi and position datas in order to generate more accurate positions datas and a regularized map.
    264 These algorithms may be seen as plugins, then different types of algorithm may be available.
     263Octave algorithms are used to compute RSSI and position data in order to generate more accurate positions data and a regularized map.
     264These algorithms may be seen as plugins, thereby allowing different types of algorithms to be available.
    265265
    266266== Gateway ==
    267267
    268 The Gateway task is to read on demand the information saved in DB tables and send these results by using the appropriate format to the end-user through the Sensei framework.
     268The Gateway task is to read on demand the information saved in DB tables and send these results by using the appropriate format to the end-user through the SENSEI framework.
    269269
    270270[[Image(gateway.png, 40%, center)]]
    271271
    272 The LetiBee plugin is based on a skeleton plugin and its HandleRequest method.
    273 Most of datas are reachable using GET methods, each making a request to the database to get the up-to-date datas.
    274 Published datas are listed below.
    275 
    276 === Published datas: ===
     272The LETIBEE plugin is based on a skeleton plugin and its HandleRequest method.
     273Most of data are reachable using GET methods, each making a request to the database to get the up-to-date data.
     274Published data are listed below.
     275
     276=== Published data: ===
    277277
    278278The communication from the gateway to the end-user is encapsulated in an xml file.
    279 The Letibee WSAN is thinked like a geographic information database.
    280 This database contains nodes identities, positions, measures and their histories, estimates of others positions values computed via algorithms written in Octave.
    281 All these information will be send through the Sensei framework using the common protocol and xml format.
     279The LETIBEE network is viewed as a geographic information database.
     280This database contains nodes identities, positions, measurements and their history, estimates of others positions values computed via algorithms written in Octave.
     281All these information will be sent through the SENSEI framework using the common protocol and xml format.
    282282
    283283=== WSAN description ===
     
    287287                  '''/letibee/nodes'''
    288288
    289 This resource returns the number of nodes in the letibee network and their identities.
     289This resource returns the number of nodes in the LETIBEE network and their identities.
    290290
    291291=== Nodes position ===
     
    315315                  '''/letibee/regmap'''
    316316
    317 This resource allows the user to choose between differents algorithms for computing the regmap, and the consensusStrength ; returns a VRML file (.wrl)
     317This resource allows the user to choose between different algorithms to compute the regmap, and the consensusStrength ; returns a VRML file (.wrl)
    318318(you may find a plugin for the web browser here : http://cic.nist.gov/vrml/vbdetect.html)
    319319