## 3 Network Model and Assumptions  
Network ModelWe assume that several biomedical sensors (BMSs) are attached to a human body, and that they acquire sensor data and transmit to a central node, namely body sensor more (BSM), which is responsible for collecting raw data, processing (coding, aggregation, _etc._) and forwarding them toward the sink node in multihop fashion, as shown in Figure 1. They might have one or more sensing devices as well. Note here that these central nodes, which are also considered in [16], are different from personal servers (e.g., PDA) as used in other works [17] and references therein. These sensor modes have relatively high energy and computing capability compared to tiny BMSs. We also assume that there may be several sink nodes \(\mathcal{S}\) in the network and any sink node \(s\in\mathcal{S}\) is primarily responsible for collecting and recording the patient's data and then uploading this data to the medical care server via the Internet. In this architecture, the master BSM node and the slave BMSs together form a cluster of a body sensor network. As in Figure 1(b), a set of such cluster heads \(\mathcal{N}\) form the backbone of the network. The key idea used in this network architecture is to move much of the network and protocol complexity away from the power-constrained BMSs and into the much more capable cluster head node. Note that the above network architecture is not only suitable for medical healthcare applications as in [18] but also for sports, battlefield, rescue operations, _etc._, those require large number of sensor nodes to be deployed. We also assume that each cluster head node has equal initial energy \(e_{init}\), and the residual energy of any node \(i\in\mathcal{N}\) is denoted by \(e_{res}(i)\). Geographic Information ConsiderationIn many applications of BSNs, the knowledge of the location of an event is also desired. Hence, it is important that the location of the network cluster nodes be known. If the nodes know their global or relative coordinates, distributed or stateless routing schemes can be employed, mitigating the need for propagation and updating of routing tables across the network. Distributed routing schemes based on the geographic locations of the nodes have been proposed and widely examined in [12, 15] and references therein. Like them, we also assume that the coordinates of the nodes are known locally, _i.e._, each node knows its own coordinates as well as those of its routing neighbors through execution of a HELLO protocol. All nodes would also know the coordinates of the sink(s). ConstraintsWe assume that every delay-sensitive packet has a lifetime \(t_{life}\), specified by the application layer, which indicates the time limit within what the packet should be delivered to the final recipient; otherwise, the information in the packet is useless. For the reliability-sensitive packets, the application layer also tags the required reliability level \(R\) with a packet. Moreover, routing of all data packets should be energy-aware in order to extend the network lifetime. HELLO ProtocolEach cluster head node broadcasts a HELLO packet, periodically or upon observing significant changes in some parameter values, including its _current position, residual energy_ and _average queuing delays_ of different packet types in the node. This HELLO protocol works in similar way as in [15, 19]. Upon reception of a HELLO packet, the neighbor cluster head nodes update their neighbor table entries. A new entry is added into the neighbor table when a new node moves into vicinity, and an existing entry is deleted when a neighboring node moves away or breaks down, which can be determined when a HELLO packet is not received during a predefined period of time (timeout). Thus, HELLO packets make the neighborhood information available to each cluster head node at a cost of additional energy and bandwidth. Time between broadcasts represents a trade-off between overhead communications and outdated cost function parameters.