In Sections 6.3.1 and 6.3.2, we demonstrated how WSNFS enables general in-network processing algorithm implementations with a spectrum of possible approaches. Ad- ditionally, in Section 6.3.3, we looked at how WSNFS simplifies distributed pro- gramming in WSN systems. In this section, we will take a look at how WSNFS compares with another WSN framework built with some similar goals. As indicated in Sections 1.3, 2.3, and 6.1, a wide range of existing work may be compared to different aspects of WSNFS. However, as we have seen, few examples of truly general purpose frameworks for WSN systems exist that enable WSN application access to network topology while providing a mechanism for wireless sensor nodes to both discover and share acquired sensor data for general in-network processing purposes. In their recent survey of state-of-the-art WSN collaborative processing research, Bao et al. discussed a large cross section of WSN collaborative processing systems and applications research [49]. They categorized WSN systems by a number of characteristics including collaborative processing for localization, energy manage- ment, task execution, routing/topology, and others. Among the systems discussed, only one of the frameworks presented was somewhat comparable to WSNFS, called SPINE2 [51]. SPINE2 may be considered similar to WSNFS in that it was designed to provide an API for general purpose WSN applications. SPINE2 builds on many of the concepts first implemented within an earlier framework called SPINE. SPINE was designed to be tightly integrated with TinyOS, specifically for health monitoring sensor network applications. SPINE2 improves on SPINE by decoupling its services from any particular underlying operating system or specific application. SPINE2
provides APIs for collaborative data acquisition, data aggregation, and task execu- tion. However, it achieves these goals at the cost of limiting access to the WSN facilities, centralizing control of collaborative actions. Central control is imposed by requiring a fixed coordinator node to orchestrate operations.
Aside from the problems associated with the centralized management scheme of SPINE2, it does not provide a distributed way to allow each node in the network to freely share data and thus work autonomously. Data aggregation and processing in SPINE2, again, must be explicitly orchestrated by a network coordinator. In terms of the data aggregation methods discussed in Sections 6.3.1 and 6.3.2 for WSNFS, the SPINE2 model is most closely represented by the first simple (and centralized) method discussed in Section 6.3.1. From this, we can see that WSNFS provides a far wider range of in-network processing options to WSN application developers.
Finally, SPINE2 does not provide sensor nodes with network topology informa- tion, as found in WSNFS. Instead, it implicitly hides the network information from the application (as is traditionally done), in an effort to facilitate WSN application portability. While this is a commendable goal, it prevents WSN applications from making smart decisions when sharing and collaboratively processing sensor data.
6.5
Summary
In this chapter, we discussed the benefits of the WSNFS approach to WSN ap- plications as compared to existing systems. We showed that WSNFS provides a unique combination of services that have great potential for improving in-network processing within WSNs. We also identified the practical issues associated with
implementing WSNFS on current embedded hardware. We outlined how WSNFS may be implemented on memory restrictive platforms by defining the data structures and relations needed for WSNFS to be implemented in the C programming language. In Section 6.3, we identified how WSNFS provides valuable information about the network topology that aids in developing collaborative processing algorithms. Here, we also provided examples of how the WSNFS approach can greatly simplify data aggregation as compared to traditional methods. Lastly, we provided a comparison of WSNFS with one of the more similar in-network processing frameworks currently available and showed that the WSNFS approach provides a number of characteristics that make in-network processing and data sharing more effective in WSNs.
CHAPTER 7
FUTURE WORK
While many of the details of the WSNFS concept have been investigated as part of this work, there remain a number of areas that are worthy of further study. Embedded systems implementations, routing enhancements and network mapping enhancements represent a few of these areas. In Chapter 3, we presented an im- plementation of WSNFS that operates on computer systems within a LAN, which was utilized to verify many of the WSNFS protocols and algorithms. One of the next steps is to push WSNFS onto the microcontroller-based platforms that are typically used in WSN systems. Some of the issues associated with an embedded systems implementation of WSNFS were discussed in Chapter 6, however the work of porting WSNFS to these platforms remains. As for routing enhancements, the routing mechanism employed in WSNFS, and discussed in detail within Section 2.4.1, provides only bare bones features for basic operation. A number of possible enhancements exist in this area of WSNFS. Lastly, as with the WSNFS routing framework, the network mapping framework (as described in Section 2.4.1), likewise provides only essential functionality, and as such a number of ways to enhance this area of WSNFS are available as well.