Introduction - mszczodrak/swift-fox GitHub Wiki

Swift Fox is a programming language for runtime dynamic network reconfiguration of low-power wireless network running on Fennec Fox platform. Swift Fox compiler is written in C using Flex and Bison libraries. Flex is a tool for generating lexical analyzers and it is an open version of lex. Bison is a parser generator and it is a GNU version of yacc. The generated output of the Swift Fox program is nesC code.

Modeling Reconfigurations with FSMs

The evolution of the behavior of a WSN that can dynamically reconfigure itself through the Fennec Fox framework can be captured in a simple way by using the Finite State Machine (FSM) model of computation. In particular, each protocol stack configuration can be modeled with a distinct state of the FSM and the process of reconfiguring the WSN between two particular configurations can be modeled with a transition between the corresponding states.

Consider the following examples of two heterogeneous applications that we deploy in a large, multi-floor building. First, Collection is an application that every few minutes reliably collects building’s climate data to the HVAC system. The sensor data is routed to a gateway by Collection Tree Protocol, known as CTP. To ensure long network lifetime, the network is duty-cycled by LPL - low power listening MAC protocol that aims to keep radio turned-off for as long as possible. The second application is called Firecam. When a fire is detected this application streams as fast as possible a series of pictures across a building. To support data streaming, we use Parasite Network Protocol, PNP, which quickly sends data on a point-to-point link. Like in other streaming protocols, PNP assumes that during picture transmissions there is no other ongoing network traffic at the same time. To further improve data streaming, we run PNP on top of a simplified CSMA MAC protocol, without clear-channel assessment, cyclic redundancy check or acknowledgements. These two applications are scheduled to run in the following way. During normal operation the network supports the HVAC system, which is done by monitoring the environment with the Collection application. But, when an emergency event occurs, such as a fire is detected by a smoke sensor, the network should switch to run the Firecam. The figure below summarized the applications' description.

This WSN network behavior, context switching between two applications is shown as a Finite State machine model in the figure below.

Here, the FSM has two states. The Monitoring state, which is also the initialization state, models the execution of the Collection application on top of the CTP stack, with the MAC and radio configured to minimize power dissipation and to avoid packet collisions. The Emergency state models the execution of the Firecam application on top of the PNP stack, with the MAC and radio configuration aimed at minimizing transmission delay and maximizing throughput. Further, the state transitions model the conditions that govern the reconfiguration of the WSN. The transition from Monitoring to Emergency specifies that this reconfiguration must occur when the smoke detector of a WSN node goes off so that the Firecam can start streaming a picture from the corresponding zone in the building. The transition from Emergency to Monitoring specifies that the opposite reconfiguration must occur when a certain time period has passed since the network has switched to the Emergency state: in this example, after a period of 30 seconds the network is brought back to execute the Collection application.

High-Level Programming of WSN Reconfigurations

To simplify the deployment of reconfigurable WSNs, we developed Swift Fox, a new domain-specific high-level programming language that has its formal foundation on the simple FSM model described above. Using Swift Fox, it is possible to specify at design time the behavior of a self reconfiguring WSN, by scheduling the execution of each application and indicating the corresponding supporting stack configurations. A Swift Fox program allows us to control the four stack layers for each configuration by instantiating modules, initializing module parameters, and assigning unique ids to each configuration. Further, for each configuration we declare a configuration priority level, which plays an important role when multiple distinct reconfigurations occur at the same time in the network, as discussed below.

The semantics of the Swift Fox language supports the declaration of the sources of reconfiguration events and the threshold values that must be matched for an event to fire. The source of an event may come from a timer or a sensor. Boolean predicates can be specified using the basic relational operators (e.g. ==, <, >) to compare sensor measurements and timer values with particular threshold values. The event-condition predicates are compiled into code that at runtime periodically evaluates the expression value. When the value is true, the occurrence of the event is signaled. The network FSM model is programmed by combining network state declarations with the event-conditions to form policy statements. Each policy statement specifies two network configurations and an event triggering network reconfiguration from one configuration to another. A Swift Fox program is concluded with a statement that specifies the initial configuration of the WSN.

The Fennec Fox software infrastructure relies on the definitions of the network configurations written in the Swift Fox program. This includes not only the logic to capture possible reconfigurations but also the list of modules that are executed across the layers of the stack for each particular configuration, i.e. which application and which network, MAC, and radio modules together with the values of their parameters. The Swift Fox programs are compiled into nesC code that links together all the modules that are specified for a given configuration and generates switch statements that direct function calls and signals among the modules.

The source code example above shows a Swift Fox program for a WSN that reconfigures between the Monitoring and Emergency states according to the state transition diagram of the FSM of Fig. 6 in order to support the execution of the Collection and Firecam applications, respectively. Lines 3-6 declare the two network configurations with ids Monitoring and Emergency. The Monitoring configuration consists of the Collection application module that starts sensing after 2000ms since the moment it receives the start command on the management interface. From every NODE, the module sends messages with the sensors’ measurements at the rate of 300 seconds (1024ms). The messages are sent to a sink node whose address is 107. Indeed, the configuration uses the ctp module, which runs the CTP network protocol with a root node at the address 107. The Collection configuration runs also a MAC protocol with Low- Power Listening (lpl), a 100ms wakeup period and stay-awake interval, together with 10jiffies random backoff, and 10jiffies minimum backoff CSMA’s parameters. The configuration is supported by a radio driver enabling all three services: autoacknowledgements, CCA and CRC. The specification of the Emergency configuration is similar but it is characterized by a higher priority level (set to 3 while the default is 1) and by the use of PNP with all MAC and radio services disabled. Lines 8-9 declare two reconfiguration events. The first event, fire, occurs when a sensor detects the presence of smoke. The second event, check if safe takes place 30 seconds after it is initiated. Lines 12-13 declare the network state reconfiguration policies: the network reconfigures from Monitoring to Emergency when fire occurs; similarly, it reconfigures from Emergency back to Monitoring when the check if safe occurs. Line 16 sets Monitoring to be the initial state. The same Swift Fox program is deployed on every node of the given WSN. While Swift Fox allows us to program a reconfigurable WSN, the language does not allow programmers to specify how a particular node detects an event, how it reconfigures itself, and how it can trigger the reconfiguration of all the other nodes in the network. Indeed, Swift Fox is meant to provide a high-level abstraction that intentionally hides the underlying mechanisms governing the WSN reconfiguration.