## 1 Introduction  
Wireless Sensor Networks (WSNs) have been considered as a key technology for a wide range of application domains that cannot be resolved with traditional wireless _ad hoc_ networks [1; 2; 3]. WSNs are expected to be versatile in many situations [4], but no standards and design rules have been followed in designing sensor network architectures because every sensor application has its own unique purpose and requires various sensor hardware and network capability. For this reason, traditional WSN research projects tend to design their sensor applications depending on specific sensor hardware, network routing schemes, and operating systems. However, this monolithic and all-in-one approach forces a sensor application to be tightly coupled to a proprietary sensor network architecture and it results in several technical weaknesses; interoperability, extensibility, difficulty of development, and reusability of sensing data [5]. As an alternative method to resolve the issue, the protocol bridge research seamlessly integrating WSNs with the TCP/IP network has attracted researchers' attention [6; 7] including the IETF [8]. The main purpose of this research is to provide Internet users with a unified interface to transparently access sensor networks using the TCP/IP protocol. It is often argued whether the TCP/IP protocol stack and the node-centric communication are suitable for WSNs or not. However, if WSNs support the TCP/IP protocol, existing TCP/IP network applications can use heterogeneous WSNs as ordinary network participants and this seamless integration can be used on diverse applications such as a smart space or Next Generation Network (NGN). In spite of promising advantages of the protocol bridge research, existing studies still have several issues that should be deeply discussed. Most of all, those studies give no consideration to the reusability of sensing data. Their main purpose is to ensure the end-to-end communication between sensors and external sensor applications. It means every session through a bridge is independent, regardless of the similarity of sensing data. Usually, in WSNs, a data reporting model can be categorized into four models: periodical, event-driven, query-driven, and hybrid [9]. If a single external sensor application uses a WSN, each model may show its own pros and cons. However, when multiple sensor applications share a WSN simultaneously, things begin to take on a new aspect. In this circumstance, a WSN using a periodical or an event-driven model has to repeatedly report the same data to multiple external applications. Even with a query-driven model, the same sensing data may be requested by multiple sensor applications and the data will be repeatedly transmitted as well. In WSNs, the transmission energy is much larger than the computational energy, so reducing the number of transmissions on WSNs is always an important design factor [3; 5], but the protocol bridge research has not seriously discussed the reusability of sensing data yet. Another consideration is that the current studies do not provide the data-centric communication method. As indicated in [10], the data-centric method is very suitable for the characteristics of sensor networks. The data-centric method does not collect sensing data directly from each sensor's raw data but allocates abstract sensing tasks to the whole sensor network. This kind of communication method enables sensor applications to consider the entire sensor network as an abstract data infrastructure. Although the node-centric method is undoubtedly a basic method for WSNs, some sensor applications may need to access sensing data via the data-centric method. To overcome the shortcomings of existing research, we proposed a new bridge system, TinyONet, in which virtual sensors cache sensing data and gather into functional entities that provide multiple sensor applications with both the data-centric and the node-centric communications. Most WSNs use a sink node as a portal to communicate with physical sensors on a sensing field.