= LETIBEE Island = [[Image(Letibee-Board-Compresse.JPG, 30%, right)]][[Image(letibee_node1_compresse.jpg, 30%, right)]] [[PageOutline(2-4,Table of Contents,inline)]] [[Image(sensinode_N711_16antenna_side_small_compresse.jpg,30%, right)]] == Introduction == This document describes the LETIBEE-based Wireless Network in a SENSEI island and in particular how to set it up. The LETIBEE network is composed of RF nodes based on the LETIBEE RF SoC, on top of which have been put an application program running over Contiki/RIME stack. == Objectives == The network at CEA-Leti provides information to an end-user located at a gateway or through the SENSEI platform as shown in the figure below. These information are: * Nodes positions * Average value of a measurement carried out at each node side (i.e. luminance or temperature) * An estimated map with the measurements obtained from each node side. [[Image(cea_wsan.png, 30%,center)]] == LETIBEE WSAN == The WSAN uses a dedicated communication protocol. Each node communicates with the network not directly but through a virtual connection managed by a gateway ( a sink node and the application platform). [[Image(network.png, 50%, center)]] The LETIBEE 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. The application protocol is mainly centralised, giving the sink a central role since it has to collect all data from the different nodes and to deliver them on the PC connected to it. A specific application protocol has been developed for network : * Node discovery. * Route discovery. * Neighbour discovery. * Initial DV-Hop positioning from connectivity information. * Pair-wise RSSI measurements. * Sensors measurements. === Contiki and RIME === The RIME stack for Contiki v2.4 from SICS has been ported onto the LETIBEE node. The LETIBEE SoC, developped at CEA-Leti, includes a 8051 µC). 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 in the figure below. [[Image(rime.png, 70%, center)]] Modules, used in the application, are described below: * chameleon : The chameleon module manages the RIME headers, which produce bit-optimized headers. * abc : The abc module sends packets to all local area neighbors. * broadcast : The broadcast module sends packets to all local area neighbors with a header which identifies the sender. * unicast : The unicast module sends a packet to an identified single-hop neighbor. * ipolite : The ipolite module sends one local area broadcast packet within one time interval. * netflood : The netflood module does best-effort flooding. * multihop : The multihop module implements a multihop forwarding mechanism. * neighbor : The neighbour module manages the neighbor table. * neighbor discovery: The neighbour-discovery module implements a periodic neighbor discovery mechanism. * route : The route module handles the route table in RIME. * route discovery : The route-discovery module does route discovery for RIME. * mesh : The mesh module sends packets using multi-hop routing to a specified receiver somewhere in the network. === Sequences of operations and protocol aspects === The mesh operation is built in an ad hoc manner 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 the route used to deliver the frames through the network. Once the route has been built, the unicast “routing” from the originator to the addressee can be used. The netflood operation can be used to flood all nodes in the network. ==== Network frame format ==== All 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. The frame formats transmitted over the air are summarised here after. [[Image(frame_format.png, 50%, center)]] ==== Gateway frame format ==== On the USB port, the APDU is appended with a frame delimiter 0xFF at its beginning, followed by the frame length. [[Image(frame_usb.png, 40%, center)]] * To 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. ==== LOOKUP operation ==== If the sink receives a Lookup Request from the Gateway: * Sends a Lookup Request Frame (with echoes) via netflood module. * Waits for a Ping Response Frame from nodes. ==== HELLO/BYE operations ==== When a node joins the network: * Sends a Hello Request Frame (with echoes) via mesh module. When a node leaves the network: * Sends a Bye Request Frame (with echoes) via mesh module. ==== PING operations ==== If the sink receives a Ping Request from the Gateway: * For each node * Sends a Ping Request Frame (with echoes if no response is received) via mesh module. * Waits for a Ping Response Frame from the node (other responses are ignored) or the timeout ===== Ping request ===== The 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. ===== Ping response ===== The Ping Response frame is sent in response to a Ping request frame. It provides the number of hops to reach the node which had initiated the ping request. ==== DV-HOP operation ==== If the sink receives an Anchor Request from the Gateway: * For each node * Sends an Anchor Request Frame (with echoes if no response is received) * Waits for an Anchor Response Frame from the node (other responses are ignored) or the timeout The 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: * If an Anchor Request Frame is received * For each anchor node (listed in the Anchor Request Frame) * Sends a Ping Request Frame * Waits for a Ping Response Frame from the anchor node (other responses are ignored) or for the timeout ===== Anchor request ===== The 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. ===== Anchor response ===== The 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. The 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. ==== LOCALIZATION operation ==== Each 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: * The advertisement frames are sent after a time comprised between 1 and 2 seconds in our setup and randomly chosen for each frame. * The RSSI information corresponds to the RSSI measured during reception of advertisement frames from other nodes in the network. * The advertisement frames sent by the nodes do not trigger any response from the nodes which receives it. The 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. * While stop request is not received: * Every second * For each node * Sends a Neighbour Request Frame * Waits for a Neighbour Response Frame from the node (other responses are ignored) or the timeout ===== Neighbour request ===== The 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. ===== Neighbour response ===== The Neighbour response frame is initiated by a node in response to a Neighbour 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. Moreover 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. 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. The total number of fragments is given by the field “nb_fragments” and the current fragment number by the field “fragment_num”. The header also gives the number of hops from the node to the sink which sent the neighbour request command frame. ==== ROUTE operation ==== If the sink receives a Route Request from the Gateway: * For each node * Sends a Route Request Frame (with echoes if no response is received) via mesh module. * Waits for a Route Response Frame from the node (other responses are ignored) or the timeout ===== Route request ===== The 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. ===== Route response ===== The 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 confused with the RREP frames which are classically used in the networking layer of the protocol. The 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. == Datamanager == The datamanager is a standalone server which have the following roles: * Gather frames received on the usb port from the Letibee WSN * Put data into database tables (rssi and position - see below) * Remove older data if a time limit is specified [[Image(datamanager.png, 40%, center)]] This approach allows to decouple the data acquisition from the data treatment and in addition provides a tunable persistent storage of the sensed data. It is then easy to simulate sensor networks by populating the database with an external script. === Database === The database is a MySQL database. The script below creates the tables and the rows useful for the datamanager and the gateway. {{{ CREATE DATABASE sensei; USE sensei; CREATE TABLE rssi (TxNodeId double); ALTER TABLE rssi ADD (RxNodeId double); ALTER TABLE rssi ADD (Rssi double); ALTER TABLE rssi ADD (RelativeTime double); ALTER TABLE rssi ADD (Time time); ALTER TABLE rssi ADD (Date date); CREATE TABLE position (NodeId double); ALTER TABLE position ADD (PositionX double); ALTER TABLE position ADD (PositionY double); ALTER TABLE position ADD (Time time); ALTER TABLE position ADD (Date date); CREATE TABLE measTemperature (NodeId double); ALTER TABLE measTemperature ADD (Temperature double); ALTER TABLE measTemperature ADD (RelativeTime double); ALTER TABLE measTemperature ADD (Time time); ALTER TABLE measTemperature ADD (Date date); CREATE TABLE measLuminance (NodeId double); ALTER TABLE measLuminance ADD (Luminance double); ALTER TABLE measLuminance ADD (RelativeTime double); ALTER TABLE measLuminance ADD (Time time); ALTER TABLE measLuminance ADD (Date date); CREATE TABLE regmapOut (Type text); ALTER TABLE regmapOut ADD (RefPositionX double); ALTER TABLE regmapOut ADD (RefPositionY double); ALTER TABLE regmapOut ADD (Value double); ALTER TABLE regmapOut ADD (PositionX double); ALTER TABLE regmapOut ADD (PositionY double); ALTER TABLE regmapOut ADD (Time time); ALTER TABLE regmapOut ADD (Date date) }}} === Octave algorithms === Octave algorithms are used to compute RSSI and position data in order to generate more accurate positions data and a regularized map. These algorithms may be seen as plugins, thereby allowing different types of algorithms to be available. == Gateway == 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. [[Image(gateway.png, 40%, center)]] The LETIBEE plugin is based on a skeleton plugin and its HandleRequest method. Most of data are reachable using GET methods, each making a request to the database to get the up-to-date data. Published data are listed below. === Published data === The communication from the gateway to the end-user is encapsulated in an xml file. The LETIBEE network is viewed as a geographic information database. This database contains nodes identities, positions, measurements and their history, estimates of others positions values computed via algorithms written in Octave. All these information will be sent through the SENSEI framework using the common protocol and xml format. === WSAN description === Resource description '''Sensors''' '''/letibee/nodes''' This resource returns the number of nodes in the LETIBEE network and their identities. === Nodes position === Resource description '''Sensors''' '''/letibee/[nodeid]/[position]''' Where position = positionX, positionY This resource returns the position of the identified node === Nodes measurements === Resource description '''Sensors''' '''/letibee/[nodeid]/[scalar_sensor_type]''' With scalar_sensor_type= luminance, temperature This resource returns the measured value of the sensor and time reference for the considered node. === Regularized map === Resources description '''Sensors''' '''/letibee/regmap''' This resource allows the user to choose between different algorithms to compute the regmap, and the consensusStrength ; returns a VRML file (.wrl) (you may find a plugin for the web browser here : http://cic.nist.gov/vrml/vbdetect.html) '''Parameters''' '''/letibee/mapdescription''' This resource returns the name of the algorithm used to compute the last regmap.