Población objetivo

From this point forward, when we refer to middleware, we will be addressing both the middleware on theBSand on the nodes. When the discussion specifically applies to just one of those parts we will highlight this.

The hardware abstraction layer of the middleware is responsible for:

• allowing the control of the nodes, including (for sensors) their sensing services;

• allowing the discovery of the services provided by the nodes;

• hiding the details of theOSrunning on the nodes;

• providing a communication abstraction that hides the underlying network/link protocol (Blue-tooth, 802.15.4, etc.);

2In the Natarajan et al. article [76] they used a variant of thePDRoptimized routing that was limited to two hop paths. This was so as to lower the path size, that was getting to 2.57 hops average length. The restriction led to an average of 1.67 hops.

48 3.3. Hardware abstraction layer

Network ITF implementation

Base Station Node

Network ITF implementation Dispatcher

Daemon Service

Discovery Daemon

BS

Network ITF abstraction

Network ITF implementation

NetPoints Command DB

Daemon implement.

Command Daemon

BS

Sensor Service Impl.

Sensor Service Sensor Service Sensor Service Impl.

Dispatcher Daemon Service

Discovery Daemon Node

Network ITF abstraction

Network ITF implementation Command

Daemon implement.

Command Daemon

Node

Figure 3.3– Middleware components on theBSand node

– defining the data structures and messages that permit the communication between nodes and theBS;

• receiving data from the nodes regarding the sensing data, handling the metadata received (time of collection, etc.) and deriving new metadata (delay, errors, etc.);

• allow easy deployment of new nodes (i.e. enabling a new type of node to be used within the middleware should not be a difficult job).

The components of the hardware abstraction layer are depicted in figure3.3. Note that theBS does not have sensing services. This does not mean that theBSis not allowed to provide sensing services. It only illustrates the separation of concerns. These services could be instantiated if the BShas sensing capabilities.

The blue filled components from the figure are the generic components of the framework that are independent of the applications and the node devices. The orange striped components are specific implementations for the devices that deal with the intrinsic details of that hardware.

Note that these implementations are per different hardware components and not necessarily different for every node. If, for example, a network interface implementation is developed for Bluetooth it could be re-used by every node (including the BS) that has a Bluetooth interface.

The architecture follows thebridgedesign pattern to provide a generic abstraction for the network interfaces, the sensors themselves³and for commandeering the node.

The node representation in the picture is a SunSPOT [113]. Our development was mostly done on these devices (we discuss it in chapter6).

3.3.1 Network

The network interface abstraction provides a generic way to use the network regardless of the underlying hardware instance (Bluetooth, 802.15.4, etc.). This provides anAPIthat is then implemented for the particular network interface(s) of the node. The genericAPIallows sending of messages (broadcast or unicast) and waiting for messages (listen to). Messages are seen as data blocks from thisAPI, and message classes provide easier access and message building functions to higher layers.

3Remember that a node may have more than one sensing capability. Each sensor service block controls one such instance.

An abstraction for communication with a specific node is also provided. This component uses the networkAPIand enables direct communication with a specific node; again transparently to the real network interface that the node uses. ThisNodeCommcomponent defines anAPIto send messages to the node it represents. TheNetPointsDBfrom the figure holds all theNodeComm components that theBSknows about. Note that it is not aNodeCommper sensor/actuator, but per interface in a node, which may host several sensors/actuators. This way, requesting data from a sensor involves knowing which node it belongs to and then sending the request to the node. As theNodeCommknows the specific network interface to use, this also hides the network interface used to contact the node. The sensor/actuator being addressed is identified in the message sent to the node (see §3.5.2). A node may find it useful to have such aNetPoinstDBcomponent if a multi-hop topology is used. In this case the node needs to know its neighbouring nodes.

The network interface component is also able to handle message fragments. This is needed when the message to be sent exceeds the network’s maximum packet size (Maximum Transmission Unit (MTU)). In these cases the component breaks up the message into fragments of the allowed size, i.e. theMTU, and sends each. On the receiving site it re-orders the fragments and reconstructs the datagram. Note that it only provides abest-effortstrategy in that no control on received fragments is done, meaning that lost fragments imply a lost datagram.

A reliable message interface is also defined. The contract for this interface is that its imple-mentation provides ordered, reliable delivery of messages, by setting up a connection. This could be used, for example, for instructing an actuator for medication administration where correct delivery and avoiding duplicated messages is relevant. On the other end, monitoring aHRcan misssomemeasurements.

The abstracted network interface does not provide flow control for messages sent. This is notper sean issue, as the case when this is most relevant is when receiving measurements from sensors. As we will see, the sensor services allow us to set rates for collecting and sending these measurements. This enables the information layer to have some control on the flow of data.

Although the network examples we have given so far (Bluetooth, etc.) point to the network abstraction being “situated” at level 3 of the IP stack, this is not mandatory. The network abstraction expects to have implemented: message sending (unicast and broadcast), getting addresses of endpoints, listening to messages and setting up reliable channels. This can be done using any layer of the IPstack (for example on top of the transport layer). However, in most cases what is needed is an implementation for a specific link layer interface. This also implies that in most cases theMAClayer will only be used and not changed or circumvented. But again, it is up to the developer of the network implementation to define that.

This flexibility leaves some room for using multi-hop technologies as we discussed above. If the network implementation either relies on a network layer that handles multi-hop or adds it in the implementation, the middleware transparently runs on a different topology. Note however that some of the profiles we discuss further may be affected by these intermediate nodes in the path. Optimization will also not take into account these intermediate nodes.

As expected, for communicating between the node and the BS, the same type of network interface must exist on both.

All the functionality defined is available for both nodes andBS.

50 3.3. Hardware abstraction layer 3.3.2 Daemons

Service Discovery

Daemon

Network ITF abstraction Command

Daemon …

Dispatcher Daemon

Message

Figure 3.4– Dispatching of received messages We use the termdaemonto mean a

compon-ent that is able to process input as a separated part of the main process. The usual implement-ation would be in a different thread from the main thread, which is supported in theJVMof SunSPOTs. In nodes where theirOSdoes not support this, an implementation that allows for different call back functions should be sup-ported. For example, TinyOS [121] allows for split-phase or non-blocking operations. In this OS, there is also the possibility to use “tasks”

that enable longer running code to be “posted”

to run in parallel⁴.

In an effort to modularize the treatment of

different types of messages we define different components to handle different parts of the protocol, which also allows for an easier expansion of the protocol. As such, we define daemon components as responsible for handling messages for a specific part of the protocol. There is a dispatcher daemonthat receives all the node’s messages and (as the name implies) dispatches them to the daemons responsible for the specific types. Currently there are two protocol daemons, one for the controlling nodes and the other one for service discovery.

From figure3.4we have:

Dispatcher Daemon just inspects the message type and, according to the registered daemons it knows about and the message types they handle, forwards the message to one of them.

Command Daemon is responsible for handling control messages. It handles and issues requests for data, setting rates forcollectionandinformation sendingand also for turning the node on/off. As part of handling requests it also deals with the replies by interfacing with the Sensor Service portrayed in figure 3.5. These replies carry the measurements taken by sensors. On theBS side this daemon issues commands for the nodes. On the nodes, it replies with measurements and sends acknowledgements to commands.

Service Discovery Daemon handles the service discovery part, as expected. As is easily per-ceived, this an important component in a dynamic environment such as a BAN. The SD allows for nodes to advertise their capabilities and for the BS to query nodes about capabilities needed. We discuss it in more detail in §3.6.

From figure 3.3 we can see that daemons run on both the nodes and on the BS. The DispatcherDaemon has the same functionality on nodes and the BS. We discuss the Ser-viceDiscDaemon in §3.6. The CommandDaemon on the BS issues commands and receives measurements (sent through command messages). On a node it does the reverse, receives commands from theBSand sends out measurements. Acknowledgements are sent for commands received and single measurements by the nodes and theBSrespectively.

The daemons described, as expected, handle the defined protocols. The information abstrac-tion layer uses them to query for data types (service discovery daemon), control the nodes (command daemon), etc. On receiving these calls, the daemons issue the necessary messages

4From TinyOS 2.1.0 there is a TOSThreads library to enable the use of threads in TinyOS.

for the requested action. Notifications also flow to the information layer as measurements are received, nodes are discovered, etc.

The message dispatching from the network abstraction to the specific daemons involves sending to a queue that is managed by each daemon. As in the network abstraction no flow control is provided and daemonsquicklyprocess the messages in the queue, posting the longer tasks to run either separately or later.

Note also that some daemons may need specific implementations depending on what device they are running. The command daemon is such an example, as it hosts the functionalities to turn on/off the devices (we discuss sleep patterns and power cycles in §3.9.4). These functionalities are specific to a particular node’sOS and as such need a particular implementation. TheSD, on the other hand, does not use any specificity of the hardware. It only resorts to the network interface, which is already abstracted.

3.3.3 Sensor services

A sensor service is the abstraction of the sensing capabilities of a given node. In figure3.5 its relationships are illustrated. The sensor service abstraction provides an interface to collect sensed values. It allows setting the frequency of collection (e.g. take a sample every 5s), through SensorCollect. The frequency at which collected data is sent (e.g. send every 22s bulk data collected every 5s) is controlled throughSensorSend. The collection is node specific and as such needs to be implemented for the particular sensor in the node. These sensor services are associated with a sensor profile that describes what the sensor senses, in what units, with what limits, errors, etc. These profiles are discussed in §3.5.1. The command daemon can access the sensor services to be able to control them.

Figure 3.5– Command daemon relationships

3.3.4 Active components

In figure3.6we illustrate how the componentslivein the node/BS. The diagram is a Unified Modelling Language (UML) collaboration diagram where the connections mean that information is flowing between the components. Components that are active (able to process input in parallel as discussed in the beginning) have extra vertical lines on the sides (e.g.SensorSend). The figure can represent a node or aBS(where the sensor services would not be instantiated). Every network interface is instantiated as an activeNetworkItf. Messages received in these interfaces are forwarded to theDispatcherDaemon. According to the message type, the dispatcher sends it to the appropriate active daemon. TheCommandDaemoncan set the collection and sending

52 3.4. Information abstraction layer