## 4 Implementation and Operations
### Communication between External Sensor Applications and Physical Sensors  
Up to now, most WSNs adopted their own proprietary network routing protocols instead of using IP and TCP/IP protocol stack because an authorized standard for WSN address scheme has not been established yet. In TinyONet, each sensor node is allocated a 16 bit address spanning from 0 - FFFE and FFFF is reserved for the broadcast address. A TinyOS-based note of our research, ZigbeX [22], uses TOS_Msg format [23] over ZigBee radio channel for its data communication. In order to transmit a packet, each mode composes its data packet with its ID, a command, and command dependent data as shown in Figure 6, and then it puts the data packet in the payload of TOS_Msg. Since ZigBee uses a wireless channel, a transmitted TOS_Msg packet will be arrived at every more. However, only a more having the same ID of the packet will accept the packet. Each more examines the ID of the transmitted packet and decides whether to drop or accept. If the ID of the packet is matched to its own ID, the note will accept it. Exceptionally, a more operating as a base station listens to every packet and delivers the arrived packet to its connected _SensorMapper_, which decides whether to drop or accept. Although this proposed WSN protocol provides simple functions, this protocol can be easily extended or replaced without affecting TinyONet itself.  
A packet transmission can be started from the sensing field or external applications. From the sensing field, one of the REGISTER, GET, or BYPASS packet is reported and the packet is served by corresponding _Command_ subclasses; _RegCommand_, _GetCommand_, and _ByRcvCommand_. As shown in Figure 7, if a sensor transmits a REGISTER packet containing its ID, the arrived packet on _SensorMapper_ will trigger to make a _RegCommand_ and an _Info_ class instances. Since the  
Figure 7: Processing of a REGISTER packet transmitted from a sensing field.  
_RegCommand_ class inherits the _Command_ class, the delivered _RegCommand_'s command for creating new sensor (i.e. regSensor() function) will be executed from the target class, _SensorPool_. The payload of TOS_Msg (i.e. the sensor's original packet) is stored into an _Info_ class instance and the instance is used by the concrete _Command_ class instance, _RegCommand_. This packet processing based on Command design pattern [24] can provide an advantage of extensibility. If a new kind of packet is required, TinyONet just adds the corresponding inherited _Command_ class which can handle the packet. Undoubtedly, this pattern enables smooth extensibility without ruining other parts of the system.  
When an external sensor application needs to access specific sensor nodes, it can issue a request that invokes a BYPASS or an URGENT packet. The request is served a _SyncSlice_ and then the _SyncSlice_ creates an instance of _Command_ subclasses; _BySendCommand_ for the BYPASS and _UrgentCommand_ for the URGENT respectively. As shown in Figure 8, if an URGENT packet is needed, a _SyncSlice_ prepares an _UrgentCommand_ and an _Info_ class instances. The _UrgentCommand_ contains a command that will be executed at _SensorMapper_ and the _Info_ instance contains the target sensor ID, URGENT command, and the related data. When the _UrgentCommand_ is delivered to _SensorMapper_, the _UrgentCommand_'s command for _SensorMapper_'s transferring code is executed. The code makes the URGENT packet with the contents of the _Info_ instance. Then, the URGENT packet is delivered to the target sensors on the sensing field. As described above, the only target sensor having the same sensor ID will accept the URGENT packet while other sensor nodes will drop the packet.