## 1 Introduction  
Recent advances in MEMS (Micro-Electro-Mechanical Systems) technology and wireless communications have led to small and low-cost sensors with increasingly powerful processing and networking capabilities. Sensor networks may comprise many sensor types, capable of monitoring a diversity of surrounding conditions, including temperature, humidity, lightning condition, pressure, noise levels, the presence or absence of particular objects and the object properties such as speed, direction and size. Additionally, many various domain applications, such as factory automation, chemical pollution monitoring, healthcare, and security adopt sensor computing [1; 2; 3]. Figure 1 illustrates the communication architecture of wireless sensor computing. Up to thousands of sensor nodes are spread across a geographical area to monitor ambient conditions as mentioned. They cooperate with each other to form a sensing network, providing access to surrounding information anytime, anywhere. A sink may function as a powerful stationary sensor node, or a mobile hardware device carried by users to gather all sensing messages sent from multiple sensor nodes. While gathering messages successfully, sinks process and forward essential data to administrators _via_ communication channels. Sensor computing is limited by extremely constrained resources, such as storage, computation capability, radio model and energy. These limitations affect the types of routing mechanisms that can be efficiently deployed. Sensor nodes are generally powered by batteries, and these are often very difficult to change or recharge in inaccessible terrains. The power consumption in wireless sensor computing can be categorized into two parts, _i.e._, communication and computation. Among these, communication consumes the most power. Hence, reducing the number of unnecessary transmissions is the best way to save energy consumption and prolong the lifetime of the sensor service network. Many various routing protocols, such as _ad hoc_ On-demand Distance Vector (AODV), Dynamic Source Routing (DSR), have been proposed for _ad hoc_ networks [4; 5]. The performance of these approaches has been analyzed and compared with each other. Routing protocols for _ad hoc_ networks are generally classified into three parts, namely on-demand, table-driven and hybrid. The route in the on-demand routing protocol is identified only when the source node is needed to send packets, and no  
Figure 1: Communication architecture of sensor computing. destination address is given. Although utilizing less bandwidth to discover the routing path and minimize the overhead of the network, on-demand mechanisms have a higher end-to-end average delay. Oppositely, table-driven routing protocols discover routing paths and maintain routing tables occasionally even if the network is not in use. Although the latency of discovering the routing path is low in table-driven routing protocols, the amount of control packets along with new or broken nodes generates a high network overhead. Additionally, table-driven routing protocols expend more bandwidth usage for maintaining routing tables. The hybrid mechanism is a cluster-based routing protocol that exploits both the other two protocols. Figure 2 illustrates cluster-based routing protocols dividing all nodes into many clusters, applying a proactive protocol within clusters and a reactive protocol between clusters. A cluster-based structure not only restricts the message flooding scope, but also elects a cluster header in every cluster to exchange routing information. The structure reduces the overhead of the network and bandwidth usage, thus saving energy, and is appropriate for a wireless sensor computing. Current research on routing in sensor computing focuses on maximizing the service lifetime, enabling scalability for large number of sensors and supporting fault tolerance for battery exhaustion and broken nodes [6]. A wireless network of sensor nodes is inherently exposed to various sources of unreliable communication channels and node failures.