Routing Failure Model

Figure 6.5 reports the SAN model in charge of modeling the packet generation and

delivery process of a single node. The model reported in the Figure 6.5 is related to

an exemplary node X with three neighbors (nodes 2, 9, and 10 in the example, as reported in Figure 6.6), and it is divided in 5 zones, each of them responsible for a

specific task.

Zone 1 is in charge managing packet loss ratio parameters for each link between node X and its neighbors (places sendY loss in Figure 6.5, zone 1, where Y is the ID of

the neighboring node). It also manage radio energy consumption parameters for each sent or received bit (places radioConsPerReceivedBit, radioConsPerSentBit ), and the

initial energy of batteries (place battery charge status, shared with the power supply

(a) (b)

Figure 6.5: SAN of the Routing model.

the behavioral simulation.

Zone 2 models the reception of packets from other nodes. A packet is received when a token is placed in the place Incoming. The received packet can be discarded if its TTL

is zero, by means of the action discard, otherwise the packet is made available and

processed (places packetAvaliable and processing in Zone 5). In both the cases, when a packet is received, a quantity of energy is subtracted from the battery charge status

place, depending on the adopted radio chip (in terms of energy per received bit) and

on the packet size.

Items included in Zone 3 model the packets generation process. The timed action

sendOwn, models the duty-cycle profiled during the behavioral simulation. Once that

Figure 6.6: Topology considered in Figure 6.5. Labels of edges represent the places used in the model.

functions of the Changes Manager (see Chapter 5) and stored in the place Own. At

the same time, a token flows from the place generating to the places packetAvailable

and processing.

Zone 4 is in charge of reproducing the acknowledgment mechanism, if employed in

the simulated routing algorithm. This includes the retransmission of missing packets.

The modeling is simplified by the use of the Changes Manager, which implements a linked list for each node, storing the packets waiting for an acknowledgment. Figure

6.7 shows the portion of code of the Routing output gate responsible for managing

acknowledgments, acting on the list, providing an example of interaction with the Changes Manager component.

All the items in Zone 5 of Figure 6.5 are used to model the routing of received or generated packets. The output gate routing is in charge of modeling the selection

of the destination node for the packet stored in the processing place. Figure 6.5.(b)

reports the code used for this task, providing a further example of the interaction between the SAN model and the Changes Manager. Depending on the routing al-

Figure 6.7: Output gate routing: extract of the code responsible for managing ac- knowledgements

function of the Changes Manager to select the destination node. If the algorithm

employs a routing tree (e.g., multi-hop routing), the gate will select only one parent, e.g., the node 10, from its neighbor list by means of the method getParent() of the

Changes Manager. Then, a token is inserted in the sending10 place, reproducing the

sending of the packet toward node 10. On the other hand, if a flooding (or gossip- ing) algorithm is being simulated, a broadcast is simulated and a token is inserted

in all (or a subset) of the places of the neighbor nodes. The IDs of the neighbor-

the forwarding is generated automatically by the Model Generator component of the External Engine, as highlighted in Figure 6.5.(b).

When a token reaches one of the sendingY places (where Y represents the ID of

the destination node), the packet is forwarded to the specific node by means of the corresponding sendY activity and the routeY output gate. All sendY activities are

characterized by cases, used to model packet losses. A packet is lost or forwarded,

depending on the loss rates contained in the sendY loss places (Zone 1). When a packet is sent, a specific quantity of energy is drawn from the batteries, depending

on i) the current settings of the radio hardware of the node (e.g. transmissive power, gathered from behavioral simulation ), and ii) the packet size. After updating the

remaining energy (place battery charge status) the packet is transferred to the cor-

responding place OutgoingY. A token is placed also into the shared place outgoingY to signal to the destination node that a new packet is available. Such shared places

represent the model interface towards the models of neighboring nodes. In particular,

the outgoingY place is shared with the incoming place of the Routing model of node Y.

It is worth noting that the routing model represents a good example of model tem-

plate. It is clear that the number and the names of all the items present in Zones 1 and 5 of Figure 6.5 strictly depend on the topology of the network. Hence they need

to be generated by the Model Generator (places, gates, C++ code, and activities)

consistently to the results of the behavioral simulation and to user preferences. For instance, in the case node X had another neighbor node, node 5, then the routing

model of node X would have been generated with another output branch linked to the route output gate, and ending in the places outgoing5, and Outgoing5.