next up previous contents index
Next: 6 Using the Blackboard Up: A Mobility Framework for Previous: 4 Building Own Simulations   Contents   Index

Subsections


5 Physical Layer Modules

The base class for all PhyLayer modules is ChannelAccess which in turn is derived from BasicModule. The only functionality ChannelAccess provides is the connectivity to the channel (i.e. to other nodes). The function sendToChannel() should be used to pass messages to the channel. It will send the message to every connected gate of the Host module.

We provide two versions of a PhyLayer. The first version called P2PPhyLayer assumes point to point connections between Hosts and is described in Section 5.3. It is the simplest PhyLayer you can think of and especially useful if detailed propagation and interference models are not needed.

For the second version we decided to divide the physical layer functionality into two submodules. The PhyLayer is divided into an SnrEval and a Decider submodule (see Fig. 4). We wanted to keep the SNR calculation and evaluation separate from the decision about bit errors. This concept makes it very easy to create different Decider modules that use the same SnrEval module and vice versa. We can define for example a Decider module that just compares the calculated SNR with a certain threshold and one that uses forward error correction and both modules can use the same SnrEval module.

Typical parameters of an snrEval module are transmitterPower, carrierFrequency and pathLossAlpha. They can be used to compute the attenuation of a signal as well as snir values. The ChannelControl module also has versions of these parameters (pMax, carrierFrequency, alpha) but they are used independently from the snrEval parameters. The ChannelControl module only computes the distance in which nodes might potentially interfere with each other, i.e. in which Omnet connections are set up. The user can define up to what signal strength received power levels should be neglected via the signal attenuation threshold (sat), i.e. every signal that is weaker than sat is neglected. As a conclusion the same power- and frequency-values should be used for snrEval- and ChannelControl-parameters. If different transmitter power levels are used, the maximum power level has to be used for pMax. For more information on the ChannelControl module and connections in the MF see Section 7.2.


5.1 SnrEval

The SnrEval module simulates a transmission delay for all received messages and also calculates SNR information. The BasicSnrEval does not account for propagation delay. The SNR information is stored in a SnrList. Each SnrList entry contains a timestamp and a SNR value for this timestamp. The basic functions for SnrEval modules differ slightly from the ones defined in Section 4.1. handleLowerMsg() is subdivided into handleLowerMsgStart() and handleLowerMsgEnd(). Additionally we defined a bufferMsg() and an unbufferMsg() function.

Right after a message is received handleLowerMsgStart() is called. In this function a SnrList should be created to hold the SNR information for this frame and an initial entry should be added. Additionally the SNR information of all other messages in the receive buffer should be updated if desired. Afterwards the message is buffered (function bufferMsg()) to simulate a transmission delay. During this time other messages may arrive which would interfere with the buffered message and thus may result in additional SnrList entries to indicate a change in SNR for this message. After the transmission is complete (i.e. the message is completely received) unbufferMsg() un-buffers the message. handleLowerMsgEnd() is called right before the message is passed up to the Decider module. Here the message should be deleted from the receive buffer and the SnrList containing the calculated SNR values should be passed as an argument to the sendUp() function. The sendUp() function

There are several ways to implement SnrEval modules from only calculating one (average) SNR per message at the beginning of the reception to recalculating the SNR every time an additional message arrives resulting in a whole list of SNR values. We believe that our concept enables all these different models without being too complex but at the same time being sophisticated enough to also support complex models.


5.2 Decider

The Decider module only processes messages coming from the channel (i.e. from lower layers). Messages coming from upper layers bypass the Decider module and are directly handed to the SnrEval module. Decisions about bit error or lost messages only have to be made about messages coming from the channel. Consequently there is no need to process messages coming from upper layers in the Decider module.

The Decider module takes the SnrList created by the SnrEval module and translates the SNR values to bit errors. The simplest possible implementation would be to compare the SNR values against a SNR threshold. If at least one of the SNR values contained in the SnrList exceeds the SNR threshold the message is dropped due to bit errors. There are of course much more complex implementations possible as well.

As mentioned already earlier the Decider would also be the place to implement error detection and / or correction codes.


5.3 P2PPhyLayer

The big advantage of the P2PPhyLayer is that it is a lot faster than the subdivision into SnrEval and Decider modules. The price for the speed is that one cannot simulate sophisticated interference models and medium access techniques anymore.

P2PPhyLayer only takes a simple bit error probability pBit (usually from omnetpp.ini). This bit error probability covers all kinds of possible bit errors and messages losses. It thus also accounts for message losses due to collisions.

Consequently complex medium access techniques and interference models are not needed anymore. The advantage is that messages can be sent directly to the desired next hop and do not need to be broadcasted to all connected neighbors. This saves a lot of message duplication, sending and processing.


next up previous contents index
Next: 6 Using the Blackboard Up: A Mobility Framework for Previous: 4 Building Own Simulations   Contents   Index
Daniel Willkomm 2007-01-12