[omnetpp] Distributed beacon generation (part 2)
Francesco Sgolacchia
I've almost completed a simple implementation (hiding some details) for
distributed beacon generation in ad hoc networks. (Ieee80211MgmtAdhoc
module)
The things implemented are:
1. one host (defined by parameter) is the network initiator, i.e.
it's the only one
who can send beacons at first
2. the hosts who receive the first beacon that contains the desired
ssid will
join the network and start beaconing with the same interval
3. in sending the beacon, Ieee80211Mac module uses a separate backoff
interval, in the range [0, 2*CWmin*SlotTime] (802.11-1999, 11.1.2.2)
4. if a beacon is received while trying to send out one, the
transmission is canceled.
What I really need is some help in understanding well the Mac80211 FSM
to correctly implement that last point (and don't screw up
everything...)
In fact, what must be done there, is:
- *most important*:
if a beacon is received during beacon backoff, cancel timer and
transmission.
(MnmgtAdhoc is responsible for scheduling a beaconTimer for next TBTT)
- suspend a backoff timer, active for other non beacon transmissions
(don't know if
this is really needed) before starting beacon backoff.
Could someone help me, giving some hints, please?
Obviously, when I'll finish coding I'll public the patch, if someone
want to try out / debug it.
Thanks in advance!
Regards,
Francesco
_______________________________________________
OMNeT++ Mailing List
options: http://lists.omnetpp.org/mailman/listinfo/omnetpp-l
archive: http://www.omnetpp.org/listarchive/index.php
Andras Varga
What is the point of explicitly simulating beacons in ad-hoc networks?
Beacons are relatively rare, so they don't consume significant bandwidth.
The point of simulating beacons with infrastructure networks is that many
people are interested in studying transient behavior during handovers --
where beacons play a crucial role. Are you interested in handovers between
ad-hoc networks? Or am I missing something?
> The things implemented are:
> 1. one host (defined by parameter) is the network initiator, i.e.
> it's the only one who can send beacons at first
>
> 2. the hosts who receive the first beacon that contains the desired
> ssid will join the network and start beaconing with the same interval
>
> 3. in sending the beacon, Ieee80211Mac module uses a separate backoff
> interval, in the range [0, 2*CWmin*SlotTime] (802.11-1999, 11.1.2.2)
>
> 4. if a beacon is received while trying to send out one, the
> transmission is canceled.
Sounds good.
> What I really need is some help in understanding well the Mac80211 FSM
> to correctly implement that last point (and don't screw up
> everything...)
> In fact, what must be done there, is:
>
> - *most important*:
> if a beacon is received during beacon backoff, cancel timer and
> transmission.
> (MnmgtAdhoc is responsible for scheduling a beaconTimer for next TBTT)
One can implement a "cancel transmission" command in MAC; and Mgmt could
issue this command when it receives a beacon just after giving one to Mac
for transmission.
> - suspend a backoff timer, active for other non beacon transmissions
> (don't know if this is really needed) before starting beacon backoff.
Yes, this is to be done for non-adhoc beacons too, but implementation has
been postponed for now (other things take priority)...
> Could someone help me, giving some hints, please?
>
> Obviously, when I'll finish coding I'll public the patch, if someone
> want to try out / debug it.
You can send me (or Levente) the code in a private email, we'll see :)
Regards,
Andras
Andreas Koepke
Francesco Sgolacchia
Il giorno 17/gen/07, alle ore 17:23, Andras Varga ha scritto:
> Hi Francesco,
>
> What is the point of explicitly simulating beacons in ad-hoc networks?
> Beacons are relatively rare, so they don't consume significant
> bandwidth.
> The point of simulating beacons with infrastructure networks is
> that many
> people are interested in studying transient behavior during
> handovers --
> where beacons play a crucial role. Are you interested in handovers
> between
> ad-hoc networks? Or am I missing something?
The point is that in ad hoc networks beacons are needed to achieve
synchronization between stations, mainly for power saving.
One, for example, could evaluate the level of synchronization
achieved by STAs in multihop networks.
>> - *most important*:
>> if a beacon is received during beacon backoff, cancel timer and
>> transmission.
>> (MnmgtAdhoc is responsible for scheduling a beaconTimer for next
>> TBTT)
>
> One can implement a "cancel transmission" command in MAC; and Mgmt
> could
> issue this command when it receives a beacon just after giving one
> to Mac
> for transmission.
Ok.
>> - suspend a backoff timer, active for other non beacon transmissions
>> (don't know if this is really needed) before starting beacon backoff.
>
> Yes, this is to be done for non-adhoc beacons too, but
> implementation has
> been postponed for now (other things take priority)...
Ok
Anyway, where I can find some documentation about Mac FSM?
> You can send me (or Levente) the code in a private email, we'll see :)
Thanks.
Cheers,
Francesco
Andras Varga
> Anyway, where I can find some documentation about Mac FSM?
We begun the implementation based on the FSMs in the paper "Specification
and Analysis of the DCF and PCF Protocols in the 802.11 Standard Using
Systems of Communicating Machines" by Moustafa A. Youssef, Arunchandar
Vasan, Raymond E. Miller, but later had to deviate from them because we
found them too inaccurate.
In the Ieee80211/Mac directory there is a graphwiz dot file (and
corresponding gif) about the FSM, but it's not very up to date. The FSMA
macros used to describe the FSM are in Base/. You may have already figured
out the way it works:
Messages, timers and other events are dispatched to Ieee80211Mac::
handleWithFSM(cMessage *msg). All events (including radio state changes) are
represented with cMessages.
FSMA_Switch() contains state descriptions (FSMA_State), each of which can
have code to be executed when the state is entered (FSMA_Enter),
"event-transitions" (FSMA_Event_Transition) and "non-event transitions"
(FSMA_No_Event_Transition). Args for the latter two are: transition name,
guard condition, destination state, code to execute.
The behind event-transition and non-event transition: on one invocation of
FSMA_Switch, first an event-transition of the current state may be
performed, then potentially a sequence of non-event transitions.
The idea is similar to the OMNeT++ FSM's "transient" and "steady" states,
but here we only have steady states, and the code normally put into the
entry or exit code of a transient state is here put into the code of a
non-event transition. We simply found non-event transitions to be more
convenient to use (and the resulting code cleaner) than transient states,
but expression power of the two are the same.
Andras
Francesco Sgolacchia
> corresponding gif) about the FSM
...oh my.... I completely overlooked at it...
Anyway I figured out the mechanism, also by looking to the macros.
Your infos are useful, too, you tell me I'm not wrong...
something was a bit "obscure" to me at first...
Regarding the hint you gave me last time:
I tried with the command, sent by mgmt to the mac,
but since beacons must be cancelled during backoff,
I've found that adding a No_Transition in the receive state was
easier.
Though I'm thinking it may be necessary the command too.
Another little question:
I'd like to show the transmitter range of nodes,
but setting the "r=100,,black,1" in ned file seems doing nothing,
and a _very_ big circle (I think of radius=1000) is visualized.
Is there a way to draw it at runtime, (more or less) resembling txPower?
Many thanks for all your replies!
Regards,
Francesco
Il giorno 23/gen/07, alle ore 00:23, Andras Varga ha scritto:
> Thanks for the useful comments on ad-hoc beaconing!
>
>> Anyway, where I can find some documentation about Mac FSM?
>
> We begun the implementation based on the FSMs in the paper
> "Specification
> and Analysis of the DCF and PCF Protocols in the 802.11 Standard Using
> Systems of Communicating Machines" by Moustafa A. Youssef, Arunchandar
> Vasan, Raymond E. Miller, but later had to deviate from them
> because we
> found them too inaccurate.
>
Andras Varga
> > corresponding gif) about the FSM
>
> ...oh my.... I completely overlooked at it...
If you happen to update it, please send me a copy :)
> Anyway I figured out the mechanism, also by looking to the macros.
> Your infos are useful, too, you tell me I'm not wrong...
> something was a bit "obscure" to me at first...
>
> Regarding the hint you gave me last time:
> I tried with the command, sent by mgmt to the mac,
> but since beacons must be cancelled during backoff,
> I've found that adding a No_Transition in the receive state was
> easier.
> Though I'm thinking it may be necessary the command too.
Just go ahead as you like. I'm not prepared to propose a well though-out
solution for it right now...
> Another little question:
> I'd like to show the transmitter range of nodes,
> but setting the "r=100,,black,1" in ned file seems doing nothing,
> and a _very_ big circle (I think of radius=1000) is visualized.
> Is there a way to draw it at runtime, (more or less) resembling txPower?
Radius is set at runtime by the mobility module of the host, in the
BasicMobility::updatePosition() function -- which in turn obtains the radius
from the ChannelControl, calling cc->getCommunicationRange(myHostRef). That
in fact returns maxInterferenceDistance rather than the distance at which
transmissions are still fairly reliable (possible misnomer...?).
Cheers,
Francesco Sgolacchia
Il giorno 23/gen/07, alle ore 11:18, Andras Varga ha scritto:
>>> In the Ieee80211/Mac directory there is a graphwiz dot file (and
>>> corresponding gif) about the FSM
>>
>> ...oh my.... I completely overlooked at it...
>
> If you happen to update it, please send me a copy :)
ok. (It seems the gif image is more update than graphviz)
> Radius is set at runtime by the mobility module of the host, in the
> BasicMobility::updatePosition() function -- which in turn obtains
> the radius
> from the ChannelControl, calling cc->getCommunicationRange
> (myHostRef). That
> in fact returns maxInterferenceDistance rather than the distance at
> which
> transmissions are still fairly reliable (possible misnomer...?).
Thanks!
From ChannelControl:
//signal attenuation threshold
double sat = par("sat");
...
//minimum power level to be able to physically receive a signal
double minReceivePower = pow(10.0, sat / 10.0);
interfDistance = pow(waveLength * waveLength * pMax /
(16.0 * M_PI * M_PI * minReceivePower),
1.0 / alpha);
where "sat" is set to thermal noise level (-110) in omnetpp.ini.
Reading the 2nd comment, should "sat" be set to a higher value?
(since most devices have a minimum receive sensitivity of -96 dBm.)
Thanks Andras!
Cheers,
Francesco
chandra shekhar menaria
Could you please suggest me if you have provided this functionality as an example of any framework (eg INET or Mixim). I am working on same kind of functionality for unmanned arial vehicles distributed communication scenario.