[Omnetpp-l] Re: MF2 80215.4 - snrEvalRadioAccNoise3

[peterob333 at xxx]

Hi,

thanks a lot, it was so nice description, that was hardly to find out
only from source code.

I posted question time ago, about how to make a collision (2 hosts
communicating and third just generate noise), but I cant find out how
to bypass it because after starting simulation only one host was
inicialized into Tx state. So i just faked timers in CSMA for 2 hosts.
Now its looks like it works, but simulator "display only one host
transmitting in time. Or is there any more sophisticated way how to
create collision?

Thanks

Regards,
  Peter

On May 25, 1:32 pm, Jérôme Rousselot <jerome.rousse... at xxx> wrote:
> 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
> Omnetp... at xxx://lists.omnetpp.org/mailman/listinfo/omnetpp-l
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "omnetpp" group.
To post to this group, send email to omnetpp at xxx
To unsubscribe from this group, send email to omnetpp+unsubscribe at xxx
For more options, visit this group at http://groups.google.com/group/omnetpp?hl=en
-~----------~----~----~----~------~----~------~--~---