Mailing list archive (omnetpp-l at omnetpp.org)


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Omnetpp-l] MF2 80215.4 - snrEvalRadioAccNoise3



Hello Peter,


Le lundi 18 mai 2009 à 23:57 +0200, Peter O a écrit :
> Hi,
> 
> I read the snrEvalRadioAccNoise3.cc code but I'm kind of confused.
> First thing, isn't there any better description of the FSM in
> execute() method? Do you guys take the FSM behave from ieee80215.4 
> spec?

yes there is: have a look at snrEvalFSM.odg (with openoffice draw)
for the big picture.


> 
> What I'm looking for in this code is SNR calculation, i cant figure
> out "how" or "if you count" the noise if receiver is interfere with
> packet that is not for him. Example I want to have two hosts
> communicating with each other and another 2 hosts that will generate
> packets that will interfering communication. Is it possible? 
> 

Yes, that's why we developed RadioAccNoise3.
snrEval receives frame start events through its handleLowerMessage()
method.
If we are trying to synchronize on a frame (SYNC state), the module will
schedule a self message (or timer, if you prefer) at the end of the
Start Frame Delimiter. At this point in (simulation) time, the BER is
estimated from the SNR, and a random value is generated. If this random
value is lower than the BER estimate, we consider that the
synchronization failed. If it succeeds, we attempt to receive the frame
and forward it, together with the SNR history, to the decider module, at
the end of the reception.
If the radio is not in sync state, e.g. already receiving a frame, or
transmitting a frame, sleeping, or switching between two modes, a frame
start event will simply be used to increase the noise level estimate.
A timer will be scheduled at the end of the interfering frame, to update
the noise level accordingly.

the received signal divided by the noise level gives a SNR estimate. The
noise level is updated at each frame start and at each frame end. So we
have a "noise level history" composed of segments. 

The decider considers each of these segments, divides their duration
with the symbol duration, and compute for each segment, the probability
of having at least one error during that segment.

If no errors are "found" for all SNR segments in the decider, the frame
is considered valid and forwarded to the MAC by the decider.



> Another question is why do you count BER in snrEval and then in
> decider?
> 
> Last question is about network and application layer. Your network
> (wise net) layer act like flood packet generator - starting generate
> packets right after simulation is lunched.

the wiseroute layer is a simple routing layer that builds a convergecast
routing tree by initially flooding the network. When a node first
receives this route building message, it selects the source node as its
parent in the tree.

This tree building procedure takes some time to complete. This is why
the SensorApplLayer provides an initializationTimer to delay its first
packet generation.

After the tree building procedure, wiseroute does not generate any
signaling traffic. It is however possible to configure it to
periodically rebuild the tree. If this is not desired, set this
parameter to a large value (e.g. 1 month).

>  Kind of same thing is doing SensorApplLayer - which generate random
> packets too - but starting to generate with some delay. So isn't that
> unnecessary? Or why do we generating packets from both network and
> appl layer?
> 

The network layer generates packets to build the routing tree.

The sensor application layer generates packets to simulate the activity
of a sensor network. 
You can configure it as you like: the inter-arrival times of the packets
can be distributed according to a uniform distribution, or
exponentially. Some of the nodes can be switched off (nbPackets = 0) as
it is commonly the case for the sink node (the tree root node). The
rates can be specified individually if you want it so.



> I will appreciate any of more detailed description of
> snrEvalRadioAccNoise3.
> 
> Thanks.
> 
> Best regard,
> Peter

_______________________________________________
Omnetpp-l mailing list
Omnetpp-l at xxx
http://lists.omnetpp.org/mailman/listinfo/omnetpp-l

Home | Main Index | Thread Index