hii,
     when i run "make" command in ns directory then i
get following errors, so please kindly give me
solution to remove following errors:

for i in indep-utils/cmu-scen-gen/setdest
indep-utils/webtrace-conv/dec
indep-utils/webtrace-conv/epa
indep-utils/webtrace-conv/nlanr
indep-utils/webtrace-conv/ucb; do ( cd $i; make all; )
done
make[1]: Entering directory
`/usr/local/ns-allinone-2.29/ns-2.29/indep-utils/cmu-scen-gen/setdest'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory
`/usr/local/ns-allinone-2.29/ns-2.29/indep-utils/cmu-scen-gen/setdest'
make[1]: Entering directory
`/usr/local/ns-allinone-2.29/ns-2.29/indep-utils/webtrace-conv/dec'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory
`/usr/local/ns-allinone-2.29/ns-2.29/indep-utils/webtrace-conv/dec'
make[1]: Entering directory
`/usr/local/ns-allinone-2.29/ns-2.29/indep-utils/webtrace-conv/epa'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory
`/usr/local/ns-allinone-2.29/ns-2.29/indep-utils/webtrace-conv/epa'
make[1]: Entering directory
`/usr/local/ns-allinone-2.29/ns-2.29/indep-utils/webtrace-conv/nlanr'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory
`/usr/local/ns-allinone-2.29/ns-2.29/indep-utils/webtrace-conv/nlanr'
make[1]: Entering directory
`/usr/local/ns-allinone-2.29/ns-2.29/indep-utils/webtrace-conv/ucb'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory
`/usr/local/ns-allinone-2.29/ns-2.29/indep-utils/webtrace-conv/ucb'


--- [EMAIL PROTECTED] wrote:

> Send Ns-users mailing list submissions to
>       ns-users@isi.edu
> 
> To subscribe or unsubscribe via the World Wide Web,
> visit
>       http://mailman.isi.edu/mailman/listinfo/ns-users
> or, via email, send a message with subject or body
> 'help' to
>       [EMAIL PROTECTED]
> 
> You can reach the person managing the list at
>       [EMAIL PROTECTED]
> 
> When replying, please edit your Subject line so it
> is more specific
> than "Re: Contents of Ns-users digest..."
> 
> 
> Today's Topics:
> 
>    1. link bandwidth and delay link in ad hoc
> networks (leticia bela)
>    2. Bug in 802.15.4 implementation (Daniele
> Messina)
>    3. including scenario and traffic generator files
>       (shalini c. thilakan)
>    4. wired - wireless scenarios (Ira Vollenberg)
>    5. Re: Rate of CBR Traffic ? (Farrag, Osama)
>    6. NAT implementation in NS2 (Amol Dawalbhakta)
>    7. IFQ USE IS CORRECT? (antonis antoniou)
>    8. DSR FRAGMENTATION ERROR (antonis antoniou)
>    9. Re: Bug in 802.15.4 implementation (Daniele
> Messina)
>   10. Set contention window 802.11 from tcl (antonis
> antoniou)
>   11. Re: Bug in 802.15.4 implementation (Ahmad
> Khayyat)
>   12. Re: Problem NOAH with wired cum wireless
> scenario (Naxo)
>   13. urgent : help in getting xgraph (harpreet)
> 
> 
>
----------------------------------------------------------------------
> 
> Message: 1
> Date: Tue, 6 Mar 2007 17:04:58 +0100 (CET)
> From: leticia bela <[EMAIL PROTECTED]>
> Subject: [ns] link bandwidth and delay link in ad
> hoc networks
> To: ns-users@ISI.EDU
> Message-ID:
> <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset=iso-8859-1
> 
> Hi all, 
>    
>   I have read articles speaking about the band-width
> of a wireless link and delay of this link in the ad
> hoc networks. but I have not find any explanation on
> the way of calculating them under NS. 
>   Please If anyone  has an idea of this topic to
> help me . It is very important 
>   I am very grateful for you.
>   Thanks in advance
> 
>               
> ---------------------------------
>  D?couvrez une nouvelle fa?on d'obtenir des r?ponses
> ? toutes vos questions ! Profitez des connaissances,
> des opinions et des exp?riences des internautes sur
> Yahoo! Questions/R?ponses.
> 
> ------------------------------
> 
> Message: 2
> Date: Tue, 6 Mar 2007 18:27:06 +0100
> From: Daniele Messina <[EMAIL PROTECTED]>
> Subject: [ns] Bug in 802.15.4 implementation
> To: ns-users@ISI.EDU
> Message-ID:
> <[EMAIL PROTECTED]>
> Content-Type: text/plain;  charset="us-ascii"
> 
> Hi all,
> I've found a possible bug / unhandled scenario in
> the 802.15.4 code included 
> in version 2.28 and subsequent.
> It is due to a change introduced in the CCA and may
> cause the csma status to 
> get locked to "1", with various disastrous
> consequences.
> I think that this may help someone who is working
> with 802.15.4.
> Understanding what follows requires the reader to be
> very familiar with the 
> 802.15.4 implementation on ns, both for my english
> ;) and for the  
> complicated subject.
> You can skip my explanation and just consider the
> following fix:
> locate this method
> 
> void Phy802_15_4::PLME_CCA_request()
> {
>     if (trx_state == p_RX_ON)
>     {
>         //perform CCA
>         //refer to sec 6.7.9 for CCA details
>         //we need to delay 8 symbols
>         CSH.start(1/getRate('s'));
>         CCAH.start(8/getRate('s'));
>     }
> }
> 
> and change this line:
>         CSH.start(1/getRate('s'));
> to
>         CSH.start(8/getRate('s'));
> Stop.
> 
> For those who are interested here is all: consider a
> network entity willing to 
> send a data packet. It will issue a
> Mac802_15_4::mcps_data_request, which 
> through a series of calls makes the backoff timer
> start with a random time as 
> in the following scheme:
> 
> Mac802_15_4::mcps_data_request
> [...]
>    printf("node %d: CSMA requested by MAC at %f
> \n",index_,NOW);
>    csmacaBegin('d');
>       \__
>          [...]
>          csmacaResume();
> *** important: csmacaResume set the status of the
> csma to 99 ***
>             \__
>                [...]
>                csmaca->start
>                   \__
>                      [...]
>                      backoffT->start(wtime);
> 
> When the backoff timer expires
> CsmaCA802_15_4::backoffHandler is invoked:
> 
> CsmaCA802_15_4::backoffHandler
> [...]
>       mac->plme_set_trx_state_request(p_RX_ON); 
> [...]
> 
> The transceiver is requested to change its state to
> RX_ON
> If the state is successfully changed to RX_ON
> 
>    void
> Mac802_15_4::PLME_SET_TRX_STATE_confirm(PHYenum
> status)
> 
> invokes
> 
>    csmaca->RX_ON_confirm(status);
> 
> which in turn launches the Clear Channel Assessment:
> 
>    phy->PLME_CCA_request();
> 
> 
> Now, with version 2.28 a variation in the Clear
> Channel Assessment mechanism 
> has been introduced:
> the standard mandates that the channel has to be
> sensed for 8 symbols before 
> its status can be determined and in version 2.27 (or
> earlier) the status of 
> the channel was tested at the end of the 8th symbol.
> This way it could happen 
> that a busy channel in the first symbols but idle at
> the time of the test was 
> detected as IDLE instead of BUSY, as it should be in
> this situation. 
> Therefore two timers are used now: the first for
> testing the channel status 
> at the end of the first symbol and the second for
> giving the CCA response at 
> the end of the 8th symbol. A sample of the
> corrisponding code is reported 
> here:
> 
> void Phy802_15_4::PLME_CCA_request()
> {
>     if (trx_state == p_RX_ON)
>     {
>         //perform CCA
>         //refer to sec 6.7.9 for CCA details
>         //we need to delay 8 symbols
>         CSH.start(1/getRate('s'));
>         CCAH.start(8/getRate('s'));
>     }
> 
=== message truncated ===



                
__________________________________________________________
Yahoo! India Answers: Share what you know. Learn something new
http://in.answers.yahoo.com/

Reply via email to