**9.2. Routing decision updates**

Upon determining the optimized resource allocation for a request from a source sensor *vi*, a cluster-head *vm* will propagate a routing decision update (RDU) to each node *vx* ∈ *pathvi*,*vj* . The RDU is sent backwards along the path in the sensor network to the source *vi*, and forwards along the path in the mesh network to the central controlling station *vj* as shown in Figure 8. This ensures that all nodes along the path are aware of their necessary resource allocations.

**Figure 8.** Propagation of RDU through Sensor and Mesh Networks

The cluster-head will include the following parameters such that all nodes can update their forwarding tables with up-to-date information:



**Figure 9.** RDU Packet Format

16 Wireless Sensor Networks / Book 1

8

9

7

or three bits for the NID field, and padding of six or thirteen bits, depending on if the source

We design one hello packet format for both the sensor and mesh network to simplify the system design process and to reduce decoding complexity. A packet length of 15 bytes could have been used in the mesh network, but we choose to have a common packet format at the expense of a transmitting an extra byte of padding. With that said, separate packet formats may need to be considered depending on the number of sensor and mesh nodes in the network

Upon determining the optimized resource allocation for a request from a source sensor *vi*, a cluster-head *vm* will propagate a routing decision update (RDU) to each node *vx* ∈ *pathvi*,*vj*

The RDU is sent backwards along the path in the sensor network to the source *vi*, and forwards along the path in the mesh network to the central controlling station *vj* as shown in Figure 8. This ensures that all nodes along the path are aware of their necessary resource allocations.

RDU

The cluster-head will include the following parameters such that all nodes can update their

• **Sending sensor identifier (SSID)**: the ID of source sensor *vi* that is the origin of the request; • **Request identifier (RID)**: the ID of the request being serviced at source sensor *vi* given

8

9

7

6

RDU

6

5

**Figure 7.** The Exchange of Presence Information in Distributed WSNs

and the overhead associated with using a single format.

5

**Figure 8.** Propagation of RDU through Sensor and Mesh Networks

presence message

NIDs: [1 2 3 4 5]

3

2

1

4

is a sensor or mesh node, respectively.

**9.2. Routing decision updates**

3

RDU

2

1

4

RDU

forwarding tables with up-to-date information:

that sensors may support multiple requests;

Legend centralized controlling station mesh node

204 Wireless Sensor Networks – Technology and Protocols Cross-Layer Design for Smart Routing in

sensor node

point of data aggregation

Legend centralized controlling station mesh node

sensor node

.

where the resulting format of the RDU is presented in Figure 9. Additionally, the cluster-head will include the node identifier (NID) of each node along the determined path such that they can retrieve their necessary operating parameters when they receive the routing decision. The message will also include the transmit power POW (each hop in 32-bit single precision floating point format), and operating channel FRQ (four bits to represent the channel number to be used per hop) determined during the optimization process, and the sub-network identifier (SNID) of the sub-network in which the node resides. *PD* bits of padding may also be used.

The RDU packet is designed such that each RDU contains information for at most (*K*� − 1) hops, with separate RDUs being sent backwards through the sensor network to the source and forwards through the mesh network to the central controlling station. Recall that, since the cluster-head acts as a bridge between the sensor cluster and the mesh network, at least one hop must reside in each sub-network. Hence, information for only (*K*� − 1) hops is required.

For the RDU, we design our network with separate packet formats for the sensor and mesh networks, as the overhead associated with a single format is significant. In our case, the mesh network would need to transmit over eight bytes of overhead per RDU packet if we were to use a single format. As a result, given the same network conditions as for the hello packet, the RDU has a length of 27 bytes and 19 bytes for the sensor and mesh networks, respectively.
