The heaven attained Oneness and became clear. The earth attained Oneness and became settled. The spirit attained Oneness and became numinous. Valleys attained Oneness and became reproductive. All things attained Oneness and became alive. --- Tao Teh Ching, Lao Tzu
| Models | Home | Utilities | Applications | Download |
Introduction:
Prowler
is an event-based simulator, a framework similar to
TinyOS/NesC. In the simulator, the following events can be caught:
Init_Application, Packet_Sent,
Packet_Received, Collided_Packet_Received, and
Clock_Tick.
Rmase supports a layered architecture, composed of one component at each
layer. A set of basic routing components has been developed for component
sharing and reuse among routing algorithms.
Layered Routing Architecture:
A component handles events (e.g., Packet_Received, Packet_Sent, Clock_Tick) and executes commands (e.g., Send_Packet). By default events are passed up and commands are passed down the layers. However, one can stop the flow by setting variable pass to 0 (false) for a command or event.
The minimum configuration of layers for Rmase includes the MAC layer, a routing layer, and the application layer, with the MAC layer at the bottom and the application layer at the top. The application layer is for generating the application scenarios and commands Send_Packet, the routing layer will forward packets received for other nodes or passes the received packet up if it is the destination of that packet, and the MAC layer will actually send the packet out. A packet shall arrive at the application layer if and only if the node is a destination. The MAC layer simulates the TinyOS MAC layer functionality (i.e., GenericComm). A packet can be sent to the next hop address (data.address = nodeID) or broadcast (data.address = 0). One can also set the communication mode to promiscuous, so that all neighbors can hear a packet, even if the packet is sent to the next hop node. The MAC layer also simulates energy consumption with a parameterized energy consumption model for transmitting, receiving, and idling states. A node can also switch between sleep and idle states and no energy is consumed in sleep state.
The statistics layer is added on top of the application layer for collecting routing statistics (e.g., the total number of sent packets, the total number of received packets, the time delays of received packets, etc.), for calculating the performance metrics described in the Rmase models.
Furthermore, one can have a set of control layers between the routing layer and the application layer, and a set of support layers between the MAC layer and the routing layer. The control layers are for network initialization or maintenance, e.g., building and maintaining a routing table or a spanning tree. The support layers are for adding features such as transmitting and receiving queues, data aggregation/fragmentation, neighborhood management, confirming/delaying transmissions, and checking duplications, etc. It is the algorithm designer's choice to put individual functions at different layers so that common functions can be shared by different algorithms.
Routing Data Structure:
Rmase defines a set of data fields for packets, however, not all the fields need to be presented for all packets.
Name
Definition
Examples
source
source ID where the data is generated; it is used for reply, or to distinguish different messages when multiple sources exist
data.source = 10
address
address of next hop; if address is 0 it means broadcast, i.e., everyone in the neighborhood receives, otherwise only the neighbor with the address receives the message; it is used at MAC layer to decide it is passing the packet up or not
data.address = 8
maxhops
the maximum hops left to travel, set by the source initially and decreased at each hop; it is used for bounded broadcast
data.maxhops = 5
from
ID of previous hop, attached at the neighborhood layer before transmit, used for neighbor management
data.from=7
msgID
msgID is given by application at the source node; typically different msgIDs are for different destinations or different types of data
data.msgID = 0
seqID
seqID is given at the application layer or generated at the support layers, to distinguish different packets of the same destination; for a given source and msgID, seqID is continuous. This is also used for detecting lost packets and duplicates
data.seqID = 2
forward
indicating if the data is received from other nodes or generated at this node; routing may have different policies for forwarding and for sending
data.forward=1
It is received from other nodes
duplicated
indicating if the packet was received more than once
data.duplicated = 1
It has been received before
delayTime specifying the time of transmission delay, normally set at the routing layer and used at the delay of transmission layer data.delayTime = 10 startTime
the time that the packet is sent from the source node; it is used for obtaining time delay
data.startTime=10
Some of the fields, e.g., forward or duplicated, are not sent out with the packets; they are flags to mark the type of packets, which can be used by upper layers. For example, at the routing layer, duplicated packets may not be forwarded again or forwarded with lower priority. For another example, transmission delay may be added to forwarding packets but not to original packets.
Common Routing Components:
This layered architecture allows for the sharing of common components for different algorithms. For example, many algorithms need neighborhood management and transmission queues, single path routing may need confirmation for reliable transmission, and flooding-based routing may add transmission delays to reduce collision. For real-time applications, one may bound the maximum number of hops given the time bound. Thus, for a given application scenario, one shall select not only the routing algorithm, but also the support and control components from the component repository. Here is a list of support and control components implemented in Rmase:
|
Name |
Type |
Definition |
Parameters |
Affected data fields |
| Probabilistic Faulty Model | support | model the probabilities from alive to dead and from dead to alive |
FailProb WakeupProb |
|
| Transmission Queue | support | maintain a transmission queue | ||
| Aggregation Queue | support | pack a maximum of M packets from the queue into one packet to transmit. On the receiving side, a packed packet will be unpacked into the original packets |
AggregatePackets AggregateTimeout |
|
| Maximum Hops | support | bound the maximum number of hops in transmission | maxhops | |
|
Neighborhood Management |
support |
maintain a neighbor list |
from |
|
|
Transmission Confirmation |
support |
trigger a timeout event when no confirmation is heard within a certain time |
TransTimeout | |
|
Duplication Check |
support |
mark duplicated packets |
seqID source duplicated |
|
|
Transmission Delay |
support |
delay a packet transmission according to the timeDelay field of data, set by upper layers, and transmit a forwarding packet probabilistically according to the number of times the packet has been heard |
randOff minDelay |
seqID source duplicated |
|
Hello Initialization |
control |
broadcast a couple
of ``hello'' packets |
msgID<0 |
|
|
Backward Initialization |
control |
flood from the
destination to set up hop counts or to build an |
msgID<0 |
More components can be added to this list, such as priority queues, duplicated transmission for extra robustness, and security encoding and decoding.