Here is the overall architecture of the framework:
As can be seen, it consists of two big parts: a static part, which shouldn't be changed and a virtual part, which is to be reimplemented.
Two different messages are supported: the DATA_REQ and the DATA message. The DATA_REQ message is issued by interested parties (sinks) and flooded through the network (automatically). Every connected node receives the DATA_REQ message and registers it in its DataGather module (virtual) and in its RouteStrategy. The DataGather module is from now on responsible for gathering the information, requested by the sink and sending it to the Application Layer. It includes a RoutingInfo, which tells the Routing Layer to which sinks to send the data.
The Application Layer sends it down to the Routing Layer, which consults its RouteStrategy through calling getRoute(sinks). The RouteStrategy has to answer with some route - that is, a combination of neighbors (next hops) for all required sinks. After writing the royte into the packet, it sends the packet to the MAC Layer.
When a packet is received from the Routing Layer from below (from the MAC Layer), it consults first its parameter sendUp whether to route the packet directly or to send the data higher. This parameter enables the framework to process DATA packets in the Application Layer, implementing some kind of overlay networks, e.g. data aggregation. If the packet is to directly routed, the Routing Layer consults again the RouteStrategy and reroutes the packet further.
DATA messages are sent from a single node to all of its neighbors. It contains information about the packet (source, last hop, clusterID of the last hop, battery status of the last hop) and a Routing section, describing which neighbors should do what.
There are also two Statistics modules - ApplStats and RoutingStats. You can also reimplement them, if you wish some other statistics to be gathered.
The BatteryModule simulates a simple linear battery with MICA-2 energy expenditures. The current status of the battery can be read via the BlackBoard. There are only two energy spending modes: active listening and sending (limited by the MobilityFramework only, which supports only these two modes.)
If you wish to implement modules on your own, you have the choice between reimplementing the RouteStrategy, the RoutingTree, the DataGather module and the Stats modules. For more information, see the documentation of these modules.
1.4.5