Retraso de la PCI primaria y Riesgo de Mortalidad a 30 días

This component is in charge of handling changes that occur during the simulation of

the SAN model. Changes management is needed due to the occurrence of node fail-

ures or reconfiguration actions which may cause topology changes (e.g. the network is partitioned due to the failure of a node). Once a topology change has occurred,

it is important to update all parameters coherently, so that the SAN model simu- lation can compute updated figures, such as power consumption (and hence nodes

lifetime) due to the different traffic they have to forward toward the sink. Hence,

after each change in the network topology, the routing three must be re-computed for each node. This is accomplished by running on the updated topology the routing

aim, the Changes Manager holds an abstract model of the network layer of the WSN: a weighted connectivity graph representing the topology of the considered WSN is

built starting from the packet loss matrix (see Chapter 5) stored in the behavioral

simulation logs (step 2 approach in Figure 4.1). A weight on an edge (i,j) in the graph represents the packet loss probability of the wireless link between nodes i and

j. Then, the change manager build the routing three on the updated topology.

Once the routing three is updated, the Changes Manager allows the SAN model to update the energy consumption of the running nodes. This is accomplished by

using parameters values about energy consumption, estimated from the behavioral simulation. For instance, a leaf node X (e.g. a node that is not forwarding packets

to other nodes) after a node failure, may be selected by other nodes as a forwarder

to the sink, due to the updated routing tree. Consequently, node X may experience a higher energy consumption rate that is dependent to all the packets that now it

forwards to the sink.

The Changes Manager component is implemented as an external library linked to the SAN model. In particular, the Model Generator instruments the SAN model with

explicit calls to the methods of the Changes Manager. For instance, methods are

invoked during the simulation of the SAN model upon topology changes (e.g. failure of a node) with the objective of propagating network changes to the graph managed

by the Changes Manager. Using an external library to handle such changes in the

network preserves the generality of the failure model making it possible, for instance, to simulate different routing algorithms, without the need of different SAN models.

A subset of the methods provided by the Changes Manager is shown in Table 4.2. For instance, upon each failure event, the function Failing (Table 4.2) is invoked

by the SAN model, in order to update the graph of the available nodes held by

the Changes Manager component. Consequently, a running node may be notified of the change in the topology after the manifested failure. If the failed node was the

only parent (i.e. the gateway currently used to reach the sink node) of a running

node, then that node is temporary isolated from the sink. To signal this event, the function propagate_isolation,is invoked by the isolated node with the objective

of propagating this information to all its children nodes (e.g. all the nodes sending packets through the isolated node). The involved nodes will then select alternative

paths to the sink. Once the new routing tree is computed, and if alternative paths

to the sink are found, the function propagate_reconnect (Table 4.2) is invoked by the SAN model in order to update the list of online nodes.

Accounting for Routing Behavior

The computeRoutingTable(nodeID) method is invoked to request an update of the routing table of a node. This is accomplished by implementing this method con-

sistently with the selected routing algorithm. Different sub-functions are included

in computeRoutingTable,making it possible to reproduce the behavior of different routing algorithms without changing the SAN model.

More specifically, the Changes Manager component takes into account only the char-

acteristics of routing algorithms that have a direct impact on the resiliency of the considered WSN. The first characteristic we consider is the selection function of for-

warding nodes. This is a basic function of each routing algorithm: each sensor node

has to select one (or more) nodes, among its neighboring nodes, to be used as a forwarder to the sink node. According to this characteristic, routing algorithms can

be classified as random or based on a selection function. The former simply for-

wards they packets to all their neighbors (flooding), to a random subset of them (gossiping), or to a random neighbor (random path routing) with the assump-

tion that data will eventually reach the sink. The latter selects the neighbor on the

path that minimizes/maximize a cost function (e.g. quality of traversed links, overall energy to reach the sink, QoS-based routing ). For instance, concerning a multi-hop

routing algorithm, a function is computed maximizing the quality of the overall path to be traversed to reach the sink from each node.

The last characteristic we consider is the use of acknowledgments and data aggre-

node received the packet, hence providing a feed-back for reliable transmissions. The latter consists in waiting a specific interval of time before forwarding a packet, so to

combine different packets coming from different sources en route, hence reducing the

number of transmissions and increasing network lifetime. As will be later described in Chapter 6, we take into account data aggregation and acknowledgments in the

routing SAN model.

It is worth noting that the approach pursued in the design of the change manager component enables the simulation of a large number of routing algorithms by re-

placing graph weights, node selection function or both, without any change to the structure of the SAN model. For instance, it is possible to simulate energy aware

routing algorithms by replacing multi-hop graph weights with figures related to the

remaining energy available on nodes, and by implementing a routing function finding paths from all nodes to the sink maximizing WSN lifetime.