Changes between Version 6 and Version 7 of Letibee


Ignore:
Timestamp:
Nov 5, 2010, 1:03:36 AM (14 years ago)
Author:
Sensei
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • Letibee

    v6 v7  
    1414* An estimated map of the measure done at each node side.
    1515
    16 [[Image(cea_wsan.png, 40%, center)]]
     16[[Image(cea_wsan.png, 60%, center)]]
    1717
    1818Figure 1 : CEA WSAN + Gateway for Sensei
    1919
     20== Letibee WSAN ==
    2021The WSAN activities do not use standardized communication protocols. Due to this constraint the communication with a node is not direct but through a virtual connection managed by a gateway (ie : a more powerful node included in the network).
    2122
    22 
    23 
    24 [[Image(network.png, 80%, center)]]
     23[[Image(network.png, 60%, center)]]
     24
     25LETIBEE network comprises nodes spatially distributed in a 2D area, including anchors with known locations and blind nodes to be positioned. Among anchors, one node generally plays the role of network coordinator and sink, whereas the other references are fixed routers.
     26The application protocol is mainly centralised, giving the sink a central role since it has to collect all data to display them on the PC connected to it.
     27
     28A specific application protocol was developed for network:
     29Node discovery.
     30Route discovery.
     31Neighbour discovery.
     32Initial DV-Hop positioning from connectivity information.
     33Pair-wise RSSI measurements.
     34Sensors measurements.
     35
     36=== Contiki and RIME ===
     37It was decided to port the RIME stack for Contiki v2.4 from SICS onto the LETIBEE node (CEA-Leti based on the Letibee chip, both of them using a 8051 uC). The RIME stack includes the functions for mesh networking including neighbour discovery (and neighbour table construction), route discovery (and routing tables construction) and multi-hop forwarding using the discovered routes. A view of the stack is shown on Figure 2 : RIME network stack.
     38
     39[[Image(rime.png, 60%, center)]]
     40
     41Figure 2 : RIME network stack
     42
     43Modules, used in the application, are described below:
     44* chameleon: The chameleon module manages the RIME headers, that produces bit-optimized headers.
     45* abc: The abc module sends packets to all local area neighbors.
     46* broadcast: The broadcast module sends packets to all local area neighbors with an a header that identifies the sender.
     47* unicast: The unicast module sends a packet to an identified single-hop neighbor.
     48* ipolote: The ipolite module sends one local area broadcast packet within one time interval.
     49* netflood: The netflood module does best-effort flooding.
     50* multihop: The multihop module implements a multihop forwarding mechanism.
     51* neighbor: The neighbor module manages the neighbor table.
     52* neighbor discovery: The neighbor-discovery module implements a periodic neighbor discovery mechanism.
     53* route: The route module handles the route table in Rime.
     54* route discovery: The route-discovery module does route discovery for Rime.
     55* mesh: The mesh module sends packets using multi-hop routing to a specified receiver somewhere in the network.
     56
     57=== Sequences of operations and protocol aspects ===
     58
     59The mesh operation is adequately built with a “route discovery” routine since the goal is to send frame (resquest/response) to node in the network. The “route discovery” routine is used to build a route to forward the frame in the network. Once the route is build, the unicast “routing” from the originator to the addressee can be used.
     60The netflood operation is use to flood all nodes in the network.
     61
     62==== Network frame format ====
     63
     64All packets are transmitted on the radio channel according to the framing of the IEEE802.15.4 standard (Erreur : source de la référence non trouvée) where the useful packet for the MAC, the MPDU(=PSDU), length is limited to 127bytes.
     65The frame formats transmitted over the air are summarised here:
     66
     67
     68
     69[[Image(frame_format.png, 60%, center)]]
     70
     71Figure 3 : Frame format over the air on the different protocol layers
     72
     73=== Gateway frame format ===
     74
     75On the USB port, the APDU is appended with a frame delimiter 0xFF at its beginning, followed by the frame length.
     76
     77[[Image(frame_usb.png, 60%, center)]]
     78
     79Figure 4 : Frame format over the USB port.
     80
     81To sink from gateway, the source address is added at its beginning of the APDU, the rest of the frame being unchanged. To gateway from sink, ‘/0’ ascii characters is added at its ending of the APDU.
     82LOOKUP operation
     83If the sink receives a Lookup Request from the Gateway:
     84Send a Lookup Request Frame (with echoes) via netflood module.
     85Waits for a Ping Response Frame from nodes.
     86
     87HELLO/BYE operations
     88When a node join the network:
     89Send a Hello Request Frame (with echoes) via mesh module.
     90When a node leave the network:
     91Send a Bye Request Frame (with echoes) via mesh module.
     92
     93PING operations
     94If the sink receives a Ping Request from the Gateway:
     95For each node
     96Send a Ping Request Frame (with echoes if no response is received) via mesh module.
     97Waits for a Ping Response Frame from the node (other responses are ignored) or the timeout
     98Ping request
     99The Ping Request frame is initiated by a sink to ping a node so has for instance to check it is still alive. It can also be initiated by a node.
     100Ping response
     101The Ping Response frame is sent in response to a Ping request frame. It provides the number of hops to reach the node which initiated the ping request.
     102
     103DV-HOP operation
     104If the sink receives an Anchor Request from the Gateway:
     105For each node
     106Send an Anchor Request Frame (with echoes if no response is received)
     107Waits for an Anchor Response Frame from the node (other responses are ignored) or the timeout
     108The nodes, including the anchor nodes, do not embed a scheduler. However, when they receive an Anchor Request Frame, they perform the following sequence of operations:
     109If an Anchor Request Frame is received
     110For each anchor node (listed in the Anchor Request Frame)
     111Send a Ping Request Frame
     112Waits for a Ping Response Frame from the anchor node (other responses are ignored) or the timeout
     113Anchor request
     114The Anchor Request frame is initiated by a sink to request a node to issue a ping request command frame towards a list of anchor nodes. This frame aims at being used by the DV-HOP location algorithm which requires the knowledge of the number of hops between any node in the network and any anchor in the network.
     115Anchor response
     116The Anchor Response frame is initiated by a node in response to Anchor Request received from a sink. This frame aims at being used by the DV-HOP location algorithm which requires the knowledge of the number of hops between any node in the network and any anchor in the network.
     117The header contains the number of anchors seen by the node, and the payload contains for each seen anchor the (anchor address, number of hops) doublet.
     118
     119LOCALIZATION operation
     120Each node also performs neighbour discovery in a nearly periodic manner by broadcasting advertisement frames. This operation is used to collect the RSSI information from the 1-hop neighbours. Note that
     121The advertisement frames are sent after a time comprised between 1 and 2 seconds in our setup and randomly chosen for each frame.
     122The RSSI information corresponds to the RSSI measured during reception of advertisement frames from other nodes in the network.
     123The advertisement frames sent by the nodes do not trigger any response from the nodes which receives it.
     124The Gateway performs the start (or stop) operation. The sink will therefore poll each node in the network in a round robin manner to collect neighbours RSSI information from all the nodes.
     125While stop request is not received:
     126Every second
     127For each node
     128Send a Neighbour Request Frame
     129Waits for a Neighbour Response Frame from the node (other responses are ignored) or the timeout
     130Neighbor request
     131The 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.
     132Neighbor response
     133The Neighbor response frame is initiated by a node in response to a Neighbor request command frame received form a sink. It 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. The RSSI time field indicates in seconds the age of the RSSI and LQI entries.
     134Moreover 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.
     135The header of the frame indicates whether the frame was fragmented1, in case the original APDU size would have exceeded the maximal size supported by the PHY layer. The total number of fragments is given by the field “nb_fragments” and the current fragment number by the field “fragment_num”.
     136The header also gives the number of hops from the node to the sink which sent the neighbour request command frame.
     137
     138ROUTE operation
     139If the sink receives a Route Request from the Gateway:
     140For each node
     141Send a Route Request Frame (with echoes if no response is received) via mesh module.
     142Waits for a Route Response Frame from the node (other responses are ignored) or the timeout
     143Route request
     144The Route Request frame is initiated by a sink to request a node to send its routing table made of the entries (destination address, next hop adress, route cost, route time). This frame shall not be confounded with the RREQ frames that are classically used in the networking layer of the protocol.
     145Route response
     146The Route Request frame is initiated by a node in response to a Route request command frame received from a sink. It contains the entries of the routing table (destination address, next hop adress, route cost, route time). This frame shall not be confounded with the RREP frames that are classically used in the networking layer of the protocol.
     147The 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.
     148
    25149
    26150
    … …  
    28152
    29153
    30 [[Image(datamanager.png, 40%, center)]]
     154[[Image(datamanager.png, 60%, center)]]
    31155
    32156
    … …  
    91215The 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.
    92216
    93 [[Image(gateway.png, 40%, center)]]
     217[[Image(gateway.png, 60%, center)]]
    94218
    95219The LetiBee plugin is based on a skeleton plugin and its HandleRequest method. Most of datas are reachable using GET methods, each making a request to the database to get the up-to-date datas. Published datas are listed below.