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 <jstine@mitre.org> =====
>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" <jstine@mitre.org>
>> To: "danaus" <licheng@sjtu.edu.cn>
>> Cc: <manet@ietf.org>
>> 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:opguest@corporate7.opnet.com/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
>> > > manet@ietf.org
>> > > https://www1.ietf.org/mailman/listinfo/manet
>> >
>> >
>> > _______________________________________________
>> > manet mailing list
>> > manet@ietf.org
>> > https://www1.ietf.org/mailman/listinfo/manet
>>
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org
>> https://www1.ietf.org/mailman/listinfo/manet
>
>
>_______________________________________________
>manet mailing list
>manet@ietf.org
>https://www1.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet