OpenWSN's software provides several tools for 6LoWPAN networking:
- Monitoring and debugging, as required by OpenVisualizer
- Border routing messages between an IPv6 interface and the internal 6LoWPAN
- Implementation of a 6TUS scheduling mechanism for a 15.4e network
- Simulation via OpenSim, which allows coexistence of real and simulated motes
The software architecture must implement these tools and provide the flexibility to support the ongoing development of networking for low-power, lossy networks (LLNs).
To meet these requirements, the software is based on publish-subscribe messaging between components in a Python process. The diagram below provides a high-level view. The Event Bus provides the messaging framework. Specific components implement services like connection of wireless motes via serial connection, and external user applications via an IPv6 TUN interface. In addition, a Python-based application may be run as an internal component. Also, notice that several motes may be connected simultaneously – either real motes for monitoring or virtual motes for simulation.
Components, Services and Messages
Now let's explore the actual component and message implementations in the Python process. In the diagram below, the Event Bus is extended to show the full chain of event handlers between a mote and the external network or application. Conceptually we may group the components into the functional areas shown on the bus. We use these groups to structure the descriptions below.
Remember that the Event Bus provides a framework for 6LoWPAN applications, and a given component may not be required for every application. For example, an internal Application component is not required if the application is external to the Python process.
A component in the diagram is introduced below in bold text. Component names correspond to directories and files in the openVisualizer section of the openwsn-sw repository.
openTun creates and uses a local IPv6 TUN interface to communicate with an application on the same computer as the Event Bus. Presently there is not a component that reads and writes to an IPv6 socket, but such a component would implement v6ToInternet and v6ToMesh message handling.
An internal Application simulates network messages with events keyed on a tuple of IP address, protocol, and port. See the coap repository for an example.
To implement 6TUS scheduling, a connected DAG root node operates in a bridging mode, where the routing components described here consume DAO notifications from the LLN and provide DIO notifications to the LLN.
LBR provides border router translation between IPv6 packets on the external network and 6LoWPAN packets on the LLN. It generates (IP, proto, ...) events for ICMP messages from the LLN DAG root, which then may be handled by the RPL component.
RPL manages 6LoWPAN routing. It reads DAO messages from the LLN and passes updateParents messages to the path state components to build a local representation of the network topology. RPL also generates the DIO messages for the LLN.
LLN Path State
These components track the state and pathways for communication between LLN nodes. This information is particularly useful for 6TUS schedule maintenance.
Mote Communication and State
These components provide common, low level building blocks upon which most applications depend.
moteConnector is the primary bus interface for individual motes. It pushes the fromMote.* events out from the motes and onto the bus. If the mote represents a DODAG root, it forwards bytesToMesh events out to the motes. Each moteConnector communicates with its serially attached mote via a moteProbe.
moteState provides a local cache of the current state of an attached mote, via the fromMote.status events. It also provides cmdToMote to send an out of band command to the mote.
BspRadio represents a simulated mote. The two-header arrow in the diagram means that two separate instances send and receive a given event. In effect, they use the event bus as the wireless medium between them.