3 deus leaflet wp3

558 views
516 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
558
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

3 deus leaflet wp3

  1. 1. DEUS Deployment and Ease Use of wireless Services Wireless Sensor Network Main challenges One of the major research areas in the DEUS project is the development of new solutions for wireless sensor networks. Current state of the art solutions fail to meet all the objectives as stated in the DEUS project proposal. They are mostly optimized for a specific USE-CASE or are not able to meet QoS (Quality of Service) – requirements for any given service. Another major shortcoming is the lack of support for different device capabilities. The main challenge in the DEUS project is to include all advantages of previous developed architectures without including the drawbacks. This means that our focus lies on supporting heterogeneity and flexibility at any level. We want to support all kinds of devices. Therefore our solution has to work both on always powered high capable devices as on energy harvesting low capable devices. Deus Approach The main objectives for the DEUS project are easy use and easy deployment. We have translated these requirements in sensor network objectives. The easy use requirement can be translated into robustness, QoS aware networking and flexibility. This means that any service or application can be executed in a transparent manner without having to change the network infrastructure. Easy deployment implicates a scalable solution that works well for any given number and type of devices. Deus Solutions Modular Sensor Node Architecture Traditional layered architectures are often too complex for sensor networks with limited memory and processing capacity. To be able to deploy complex applications on sensor nodes, a novel modular architecture was developed. This architecture, called IDRA (Information Driven Architecture), has the following features: • The system is responsible for packet creation and packet manipulation. As a result, the complexity and the memory footprint of the network protocols are reduced. • The protocol logic and the packet type are fully decoupled. The packet type can be changed without any changes to the used network protocols.
  2. 2. DEUS Deployment and Ease Use of wireless Services • All packets are stored in a single, shared packet queue, reducing the memory footprint. In addition, the QoS module has full control on the behavior of each packet in the system. • To reduce the number of transmissions, the system intelligently combines information exchanges from multiple network protocols in a single packet. As a result, the network lifetime increases and the harmful interference decreases. • A varying number of network modules can be added according to the node capabilities, thus promoting heterogeneous networks. Further, on more capable nodes, multiple routing and MAC protocols can be 'plugged-in' on the same node. An intelligent protocol selector chooses the most optimal network protocol for each traffic type. As a result, our architecture not only is much more scalable in terms of memory and energy requirements than tradition system architectures, but also supports next- generation applications over heterogeneous network optimally. FlexMAC Existing 802.15.4 MAC protocols for sensor networks lack support for heterogeneity. Hence, a new MAC protocol was designed and implemented, FlexMAC, which provides an energy efficient and adaptive L2 (OSI-Layer 2) protocol for all kind of devices and applications. The protocol uses a low duty cycle (max 15% for routers and 4% for host devices) in order to support energy efficiency. In a general setting, TSCH is used as operating mode, i.e. time slots are combined with synchronized channel hopping. QoS input and profile information can change the default behaviour. For instance, FlexMac supports random access for unsynchronized devices or it changes the operating mode when high throughput and low delay is required. Hybrid Routing HYDRO HYDRO (Hybrid Routing Protocol) is a routing protocol that combines several ideas. The first idea is that it is a centralized protocol where the edge router contains an overview of the entire sensor network. To be able to build this view on the edge router, every regular router or host device periodically sends a topology report (containing all its neighbors) to the edge router. Drawback of this method is that all traffic is routed through the edge router in order to reach its destination. Therefore HYDRO is able to install routes in the network. This is illustrated below.
  3. 3. DEUS Deployment and Ease Use of wireless Services Working of the HYDRO protocol The black links represent the startup phase of the network, in which a tree of the network is formed with the edge router as root. The red link represents the link to the back-end, where the central SIS is located. The blue links show the path a packet initially takes when host A sends traffic to host B. The green links visualize the optimized path between host A and B after a route install based on the central topology overview of the edge router. The HYDRO routing protocol uses IPv6 (6LoWPAN) addresses to identify the nodes in the network. 6LoWPAN is a compression mechanism that allows IPv6 packets to be sent to and received from IEEE 802.15.4 sensor networks. At the network start-up phase, every node has to register itself to a central Sensor Installation Server (SIS), to acquire a unique IPv6 address. DYMO (voice) The Dynamic MANET On-demand (DYMO) routing protocol is a reactive routing protocol based on route-request and route-reply messages. This routing protocol is very suited to set up a voice call between two nodes because it only sets up a route between nodes when needed and hence reduces the global routing protocol overhead.
  4. 4. DEUS Deployment and Ease Use of wireless Services QoS enhancements The provided QoS enhancements can be dependent or independent to a protocol. Protocol-independent QoS enhancement First, we made a protocol-independent QoS extension for IDRA. Therefore, we have implemented an intelligent priority based dropping strategy. Working of DYMO 1. The source node (A) wants to set up a voice call and broadcasts a route-request message to the destination (B). Each (intermediate) node that receives this route-request message analyses this request, updates its routing tables and possibly adds some own information. Afterwards, this node rebroadcasts this message to the destination. This process repeats itself until the destination node receives the route-request message. 2. When the destination (B) receives the route-request message, it sends a unicast route- reply message back to the source (A). Again, each intermediate node can update its routing information and can add own information if desired. 3. When A receives the route-reply message from B, it has enough information to set up the voice path from source to destination. In a more general scenario in the Zuiderpoort building, when setting up a route from node 1 to node 200, we can clearly see the broadcast route-request messages (circle), the unicast route-reply messages from destination (200) to source (1), and afterwards the unicast data traffic from source (1) to destination (200). This system allows us to give voice packets a higher priority and to drop only packets with a lower priority when the network becomes congested. Almost all packets from source 2 are received by the destination when QoS is enabled.
  5. 5. DEUS Deployment and Ease Use of wireless Services Protocol-dependent QoS enhancement However, the protocol-independent QoS extension is not enough to support voice traffic. Suppose the maximum end-to-end delay for voice is 250 ms. This strict delay can not be guaranteed with only protocol- independent QoS enhancements. Therefore, we need an extra interaction between the routing (DYMO) and the MAC (FlexMAC) protocol. A specialized QoS management module is therefore responsible for gathering routing information from the routing module (path information), interpreting and translating this information (translate end-to-end QoS information to single-hop information) and informing the MAC protocol about this information (so it can adjust the duty cycle). This way, it is possible to support voice traffic within a dedicated end-to-end delay. LSR-routing As a final routing solution, a new routing paradigm for wireless sensor networks based on label switching is devised. Instead of addresses, labels are used to define the routing path between source and destination. These labels are centrally assigned and deployed over the sensor nodes. This system allows us to enable fast and reliable routing with low processing overhead, it offers native support for QoS and multiple applications can be supported at the same time. WSN Gateway The WSN Gateway (see figure) has several tasks. Its first task is to ensure routing between two separate sensor networks that are not able to communicate directly with each other. When a 6LoWPAN sensor packet with a destination sensor node in a different sensor cloud arrives at the WSN gateway, it is converted to an IPv6 packet and forwarded to a Click module (WSNTP – Wireless sensor network tunneling protocol) on the gateway. WSNTP encapsulates IPv6 packets into standard IPv4 packets and ensures the routing over the mesh network between two WSN gateways, thus connecting two separated sensor clouds. The second task of the WSN Gateway is to forward traffic from sensor nodes to IPv6 servers (e.g. the Sensor Installation Server). It also ensures that messages from an IPv6 server can reach the correct sensor node. The last task of the gateway consists of routing traffic between sensor nodes and standard IPv4 servers (e.g. monitoring server). Since the monitoring server does not have any IPv6 functionality, the NAT-PT box is used to translate IPv6 to IPv4 addresses.
  6. 6. DEUS Deployment and Ease Use of wireless Services The three different traffic flows are illustrated in the figure below. The traffic flow coloured in red shows the traffic between two separate sensor clouds. The yellow traffic flow shows traffic between a sensor node and an IPv6 server. The blue link illustrates the connectivity between sensor nodes and IPv4 servers. Energy Harvesting A wireless sensor network can only be truly wireless if one can also eliminate the power cable running to the sensor. Therefore, we have developed a software/hardware platform that enables energy harvesting. Two types of energy harvesters were considered: solar and pressure energy are converted to electricity. This example platform demonstrates a display. The information displayed on the display can be updated over the air. The protocol used to do so is IEEE802.15.4. The solar cells provide sufficient energy to update the display once every 5 minutes. The software to update the display remotely is developed by GreenPeak as well. DEUS Proof of Concept implementation
  7. 7. DEUS Deployment and Ease Use of wireless Services As this a technical work package most Proof of Concept solutions are described in other work packages. For instance positioning uses the DEUS sensor network to collect positioning information to the positioning server. The collected data used for the reasoning is gathered by the DEUS sensor network. Another Proof of Concept implementation is Voice Routing. Voice Routing will be demonstrated in the elderly care home De Vijvers. The main goal is to provide easy to use communication in case of emergency. Due to hardware limitations we had to implement the speech codex on a different hardware platform. This makes this solution not useable in real life. It demonstrates however that it is possible with suitable hardware. With our solution we can guarantee the following properties: • The setup of the voice call takes at most 5 seconds, • The maximum end-to-end delay is 250 milliseconds, • We only use power during a voice call. Project partners In cooperation with IBBT research groups UGent - IBCN http://www.ibcn.intec.ugent.be UGent - WiCa http://www.wica.intec.ugent.be UA - PATS http.www.pats.ua.ac.be KU Leuven – DistriNet http.www.distrinet.cs.kuleuven.be KU Leuven – CUO http://ww.soc.kuleuven.be/com/mediac/cuo UHasselt - EDM http://www.edm.uhasselt.be/

×