Subject: [Fwd: [manet] About IEEE802.11 model in OPNET]

From: John Stine <[email-masked]>
Date: Fri, 29 Mar 2002 11:48:21 -0500

Aaron,

I am sorry, not getting this message returned to me indicated I did not
send it to the manet list.  There is more information on the
deficiencies of the current OPNET wlan_mac model for ad hoc network
modeling.  The specific problem you are having is alluded to in the
text.  OPNET uses the receiver busy stat to indicate the channel busy
condition.  It is set early in the pipeline stages based solely on
whether the sender and the destination channels match.  The result is
when one node transmits, all other nodes sense the channel busy
regardless of separation distance.  This prevents spatial reuse and also
eliminates the problems encountered in ad hoc networking, i.e. hidden
node effects, exposed nodes, and the near far problem.  Please note,
however, that a subsequent pipeline stage makes certain that you can
only communicate to a node up to the distance specified in the range
parameter that is set in the simulation attributes.  You will see
packets fail based on separation distance.

John

Subject: Re: [manet] About IEEE802.11 model in OPNET
From: John Stine <[email-masked]>
To: Vikram Dham <[email-masked]>
Date: Thu, 28 Mar 2002 15:01:22 -0500

Dear Vikram,

	I agree that this additional TDA can allow one to distinguish a valid
packet from a noise packet in the latter pipeline stages and that this
would be a more accurate model.  However, the fidelity of this model
only affects a small number of packet receptions and introduces another
problem, assessing the channel as busy. 

	I can think of only one situation that this model resolves that ours
does not.  It occurs as follows.  A node receives a signal that exceeds
the threshold power level but other transmissions keep the SIR too low
for it to capture the signal. Then, during this same transmission,
another node transmits and it is received at a much higher power,
sufficient to exceed the SIR threshold even with the first signal
present. In this case, the second packet could be received and would not
have been if the receiver was locked onto the first packet.  The
question is, how frequently will this sequence of events occur.  The
802.11 MAC tries to prevent it from occurring.

 	Here is the second issue.  How do you insure the clear channel
assessment mechanism works correctly?  The OPNET wlan_mac process uses
the receiver busy stat.  This is triggered in the propdel stage so it is
not useful unless we mark the packet as invalid before this stage. (This
is not an issue in the OPNET model and is what makes it a bad solution
for modeling ad hoc networks.  Nodes consider the channel busy although
in reality they could exchange packets)  A second option is to use the
received power.  The received power stat wire interrupt is triggered
everytime a power that meets the trigger criteria is written to a
packets power TDA in the power stage.  Note, it is associated with the
packet rather than the receiver.  As a result, it is not possible to
distinguish a power level going from high to low for a transmission that
is currently causing the channel to be considered busy and a distant
transmission that meets the same power level criteria.  The SNR
statistic would also be problematic since it could be triggered several
times per packet and is not triggered at the end of a packet.  So I
model the channel busy condition through the reception of a packet. 
Passing the power threshold makes the channel busy and then receiving
the packet ends the busy condition.  IF the packet is received without
errors then the node processes it, otherwise it was just a busy
condition.  I would be interested in knowing your solution to this
problem and if you implemented it with the OPNET wlan_mac process.

	It is this second issue that caused me to commit to the model I
created.

John

Vikram Dham wrote:
> 
> Dear John,
> 
>          If you manipulate  OPC_TDA_STATUS beyond dra_power stage, then you
> could be attempting to access destroyed packets (NOISE PACKETS) in later
> stages and that is why you got the error. As mentioned in OPNET's email you
> need to use another TDA to maintain packet status and set OPC_TDA_STATUS equal
> to valid for all packets so all packets are forced through all stages. I have
> just completed running a simulations scenario which takes care of interference
> from other transmissions going around. During debugging I have observed that
> interference from other transmissions is accounted for.
> 
> With Best Regards
> 
> Vikram Dham
> 
> >===== Original Message From John Stine <[email-masked]> =====
> >Dear Vikram,
> >
> >       This was our first instinct but the OPNET kernel does not allow it.
> >The issue is, when is the latest you can set a packet's status to
> >noise.  The answer is the power stage.  Below is the text of a message I
> >got from OPNET technical support when I asked this question.  I called
> >after I noticed my simulation didn't work when I waited until the SNR
> >stage to set the sig_lock attribute and the match status.
> >
> >*** TEXT OF MESSAGE FROM OPNET
> >SUPPORT************************************
> >
> >It sounds like you are setting OPC_TDA_RA_MATCH_STATUS to .._NOISE in
> >the
> >SNR stage. The kernel expects the MATCH_STATUS TDA to be set at the
> >latest
> >by the power stage, and therefore, modifying it in the SNR stage may
> >result
> >in unexplained behaviour, including possibly the abort that you observe.
> >At
> >any rate, changing the TDA in the SNR stage will not prevent the kernel
> >from invoking the following stages (ber, etc.) because the kernel will
> >still treat it as a valid packet.
> >
> >Therefore, we suggest that you try another approach to achieve the same
> >goal. For example, you could mark all potential packets as VALID in the
> >power stage and define your own TDA called "MY_MATCH_STATUS" and set
> >this
> >to noise in the SNR stage if the conditions so dictate. However, since
> >the
> >kernel does not know about this TDA, all the stages following the SNR
> >stage, i.e., ber, error, ecc will still be invoked by the kernel for
> >this
> >packet that has its MY_MATCH_STATUS TDA set to NOISE. Therefore, you
> >will
> >have to access this TDA in the last few stages and immediately exit
> >using a
> >FOUT if the MY_MATCH_STATUS is set to NOISE.
> >
> >*****************************************************************************
> **
> >
> >So it may be possible to use the SNR but not without an additional data
> >structure to keep track of which packets are valid.  Since I cannot see
> >what happens inside the kernel I decided not to circumvent OPNET's
> >plan.  Not modeling signal lock based on SNR has little effect in the
> >performance of the model.  If SNR is a factor, the newly arriving packet
> >that we lock onto is likely to have errors and not be accepted. If we
> >successfully account for SNR, the duration of this packet would be
> >sensed as a busy channel.   So, in both cases, the effect on the
> >receiving node is the same.
> >
> >
> >John
> >
> >Vikram Dham wrote:
> >>
> >> Dear John & Kevin:
> >>
> >>    I agree with your pointers regarding pipeline stage.I would like to add
> >> that instead of setting value of signal lock  & packet status at
> >> manta_power.ps.c, you can move it to manta_snr.ps.c stage to determine
> >> whether signal lock should be set or not and whether the packet is to be
> >> stamped as *noise* or *valid* packet. This would take into account
> >> interference due to other nodes without need for maintaining any additional
> >> data structure.  For doing this you will have to maintain an additional TDA
> >> RCV_FLAG  which should be set during the first pass of the packet through
> >> the manta_snr.ps.c stage.
> >>
> >> I hope the above helps.
> >>
> >> With Best Regards
> >>
> >> Vikram Dham
> >> Graduate Research Assistant
> >> Alexandria Research Institute
> >> Virginia Tech,USA
> >>
> >> ----- Original Message -----
> >> From: "John Stine" <[email-masked]>
> >> To: "danaus" <[email-masked]>
> >> Cc: <[email-masked]>
> >> Sent: Wednesday, March 27, 2002 9:12 AM
> >> Subject: Re: [manet] About IEEE802.11 model in OPNET
> >>
> >> > Opnet's wlan_mac and the support pipeline stages take some liberty in
> >> > modeling the physical layer based on the assumption that in the intended
> >> > network all nodes should be within range of each other.  As a result,
> >> > the model does not model interference correctly, but uses collisions
> >> > only as the cause of failure.  This is a severe problem when one is
> >> > studying ad hoc networking and wants to evaluate spatial reuse of the
> >> > channel.  Two nodes in a network cannot successfully transmit
> >> > simultaneously, despite separation distance.  We addressed this problem
> >> > in our modifications to OPNET's models for Kevin Grace's MobileMesh
> >> > protocols.  You should have received a message from Kevin about the
> >> > release of these models.  If you did not receive it, the text of Kevin's
> >> > message follows.
> >> >
> >> > The OPNET models are for version 7.0.B but they are well documented so
> >> > with a little effort one can apply the changes to the 8.0.C version.  We
> >> > provided these models to OPNET and they have given us the indication
> >> > that they will incorporate our recommendations into a future release of
> >> > their product.
> >> >
> >> > In the mean time, I would recommend anyone using the OPNET wlan_mac
> >> > model to study ad hoc networks to look at our observations and
> >> > recommendations. (See Readme-MobileMeshOpnet.pdf.)  Many conclusions
> >> > based on modeling in OPNET may need to be re-evaluated.
> >> >
> >> > John
> >> >
> >> > Kevin's message follows:
> >> >
> >> > Opnet simulation models of the MobileMesh Routing Protocol and
> >> > MobileMesh Link Discovery Protocol are now available from Opnet's
> >> > website:
> >> >
> >> >  ftp://opguest:[email-masked]/433/
> >> >
> >> > Included in this distribution are numerous modifications and bug fixes
> >> > to the 802.11 wireless LAN process model and related pipeline
> >> > stages.
> >> >
> >> > Please refer to the file "Readme-MobileMeshOpnet.pdf" in the
> >> > distribution for more details.
> >> >
> >> > Information about the MobileMesh protocols and Open Source Linux
> >> > distribution
> >> > is available at:
> >> >
> >> >  http://www.mitre.org/tech_transfer/mobilemesh/
> >> >
> >> > -Kevin
> >> >
> >> > danaus wrote:
> >> > >
> >> > > Hi,
> >> > >
> >> > > Is there anyone here familiar with the IEEE 802.11 model in OPNET 8.0.C
> >> ?
> >> > > I encounter a strange problem when I make the following simulation
> using
> >> OPNET:
> >> > > --------------
> >> > > WLAN Scenarios 1:
> >> > > Two wlan_station_adv(fix) nodes in a 500m X 500m rectangle area,
> >> > > each node random selects a destination and transmits some packets.
> >> > >
> >> > > WLAN Scenarios 2:
> >> > > Same configured as the above Scenarios 1 except that the number of
> >> > > nodes is twenty.
> >> > > --------------
> >> > > I have expected that one node's throughput in Scenarios 2 should
> >> > > much lower than that in Scenarios 1. But the simulation results
> >> > > show that the throughput of each node is as same as that in
> >> > > Scenarios 1. The more eighteen nodes in Scenarios 2 seem do nothing.
> >> > >
> >> > > Could any one tell me why the nodes in Scenarios 2 don't make
> >> > > interference to each other.
> >> > >
> >> > > Thanks a lot.
> >> > >
> >> > > Sincerely,
> >> > > aaron
> >> > >
> >> > > _______________________________________________
> >> > > manet mailing list
> >> > > [email-masked]
> >> > > https://www1.ietf.org/mailman/listinfo/manet
> >> >
> >> >
> >> > _______________________________________________
> >> > manet mailing list
> >> > [email-masked]
> >> > https://www1.ietf.org/mailman/listinfo/manet
> >>
> >> _______________________________________________
> >> manet mailing list
> >> [email-masked]
> >> https://www1.ietf.org/mailman/listinfo/manet
> >
> >
> >_______________________________________________
> >manet mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/manet