RECOWER Distributed Architecture

As stated in the scenario section, RECOWER mainly adopts a mobile infrastructure based on ad-hoc communications between mobile nodes. From a distributed architecture point-of-view, the mobile nodes carried by rescue team members are grouped in a peer-to-peer heterogeneous MANET that integrates both WiFi and BT technologies for local ad-hoc communications. To impose locality principle and to reduce management overhead, RECOWER does not assume any MANET multi-hop routing protocol, and manages data routing on a hop-by-hop basis between neighbors.

RECOWER Software Architecture

RECOWER software architecture is divided in two principal layers:

  • Context Data Management Layer - This layer realizes all the high-level functionalities required for context production and retrieval. Every context aspect is mapped to a particular context type that describes the layout of associated data. All current types are available by means of a local Context Data Type Storage. In addition, each context type is associated with a proper Context Data Module that contains i) a Source to inject context data; ii) a Sink to retrieve context data; iii) a local Data Repository to store associated data; and iv) a Neighbours Data Repositories Status data structure used to retrieve the state of data repositories deployed on near nodes.
  • Context Data Spreading Layer - This layer implements all the low-level functionalities related to data routing and wireless communications. The Communications Module implements technology-independent communication operations while proper adapters, i.e., the WiFi and the BT Adapter, map them to the low-level technology-dependent ones. Each adapter has a Neighborhood sampling facility used to retrieve the current available neighbours (one-hop physical neighbours). Finally, the Adaptive Routing Manager realizes the effective context data routing by receiving context data requests and by handling the matching phase with locally stored data.

RECOWER General Data Distribution

In RECOWER, each context type is associated with a definition that contains both the structure of associated data and memorization policy. Once defined a particular data type, each mobile node can create and inject new data instances, while routing is addressed as explained in the following.

RECOWER data routing is based on two principal entities, i.e., context data instances and queries. While context data represents the real context aspect, context queries are used to build lightweight dissemination paths into RECOWER MANET that trigger data distribution from remote repositories towards query creator node. In other words, context queries represent the basic routing information used to address context data routing. The sink associated with each context data module is in charge of translating application requests to proper context queries.

At default, a context query is distributed to all the current one-hop neighbors by using a broadcast-based approach. When a query is received for the first time, the receiving node tries to match it with locally memorized data and, if possible, forwards matching data towards the creator node. Context data distribution is always performed on hop-by-bop basis in which each node sends matching data to the node that had relayed the query. If a query is not satisfied by locally memorized data, it is stored into the local routing manager to enable future context data routing, and further query distributions can be scheduled depending on query parameters.

Both context data instances and queries have management information useful to control their associated distributions. In particular, each data instance has:

  • Sequence number: Positive increasing number attached by the source and used to differentiate older data from newer ones.
  • Remaining lifetime: Positive number dynamically decreased and used to understand if a data instance is still valid or not.
  • Foreseen lifetime: Initial data instance lifetime attached by the source.
  • Data: The real context data represented according to system directives.

while each context query comes with:

  • Query Lifetime: The maximum total lifetime of the query.
  • Query Routing Delay: Delay applied by each node during query distributions.
  • Data Routing Delay: Delay applied by each node during data distribution.
  • Query Priority: Query priority used to enable traffic differentiation.
  • Time to live: The maximum number of hops a query can traverse.
  • Maximum query responses: Maximum number of relayed data.
  • Data Filters: Filters used by receiving nodes to select matching data.

Considering above parameters, each mobile node memorizes received queries according to the QLT and to MQR: when one of them is zero, the query is expired and removed. In addititon, the TTL limits the propagation of the query: each node decreases this parameter before distributing a query, and further distributions cannot be performed when TTL is zero. While all these parameters define the lifetime and the distribution scope of the query, the QRD and the DRD avoid context query/data immediate flooding, so to reduce wireless network congestion and to perform resource management.

To adapt query/data distribution depending on current network load, RECOWER monitors wireless channel status and imposes limitations on sending operations. By monitoring both pending messages and bandwidth, RECOWER adapts QRD and DRD to increase both data distribution efficiency and reliability.