Tim,
Would it be possible to post a pointer to your 802.15.4 code?
Thanks,
Scott
On 3/7/07, Tim Allemeersch <[EMAIL PROTECTED]> wrote:
>
> Hi all,
>
> This is indeed a bug in the 802.15.4 ns-2 module. I have had this
> problem too. Multiple times, a node would just stay in the 'busy
> channel' mode, and could therefore not send its data. Anyway, I solved
> it this way:
> Have a cca at the first symbol. (CSH.start(1/getRate('s'));)
> If the channel was idle, then do another carriersense at the 8th symbol.
> This can be done by calling 'CarrierSenser()' at the 8th symbol. You can
> do this by including an extra timer, or by adjusting the function
> ccahandler.
>
> Greetings,
>
> Tim Allemeersch
>
>
> Daniele Messina wrote:
> > First thank you for your feedback.
> > I've mentioned that the two timers have been introduced in order to be
> > compliant with the standard:
> >
> >>> 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:
> >>>
> > but this, as I showed, introduced an even worse problem.
> > I've adopted the quick fix of "downgrading to the previous version of CCA"
> > but
> > of course I agree this isn't the solution, and this isn't what the standard
> > says. I think you refer to this when you say "totally wrong with the timer
> > handling", but is it the same motivation for "partly right with your bug"?
> > Do
> > you refer to something else in the bug description?
> > However my priority was to put the attention of ns users on the bug (for
> > which
> > I've spent much time trying to find why my simulations aborted).
> > Note that this bug (as any respectable bug would do) may affect your
> > simulations and may not be detected.
> >
> > I'm working on a routing and mac management system for peer-to-peer
> > 802.15.4 networks.
> >
> > Bye.
> >
> >
> > On Tuesday 06 March 2007, you wrote:
> >
> >
> >> Sorry, but I think I have to disappoint you.
> >>
> >> To my knowledge, you are only partly right with your bug, but totally wrong
> >> with the timer handling :)
> >>
> >> As you said, they are set to different values for getting the whole period
> >> of 8 symbols... If you change it, your implementation might work,
> >> but unfortunately not according to the standards.
> >>
> >> In either case, if there is some noise on the channel for the first 1 - 7
> >> symbols after the cca request, you should mark the channel as busy, and not
> >> just take into account the noise at symbol 8(spoken in time *g*).
> >> Especially, as the former case is very likely to happen.
> >>
> >> The trick instead is, to ensure that all packets during the cca are
> >> discarded as "data", but regarded as noise on the channel, which is exactly
> >> what is mentioned in the standards. Another useful step would be some
> >> exeption handling within the mac->PLME_CCA_confirm...
> >>
> >> What topic are you working on?
> >> Perhaps it might be interesting to exchange some ideas...
> >>
> >> Greets,
> >> Matthias
> >>
> >>
> >>> 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'));
> >>> }
> >>> }
> >>>
> >>> Consider if the channel is idle at the end of the 1st symbol and the
> >>> reception of a packet begins just after:
> >>> when CSH expires the channel is deermined to be IDLE, even if the
> >>> response is given when CCAH expires, as the channel is BUSY!
> >>> mac->PLME_CCA_confirm is invoked with a sensed_ch_state=IDLE and after a
> >>> series of calls...
> >>>
> >>> mac->PLME_CCA_confirm(sensed_ch_state);
> >>> \__csmaca->CCA_confirm(status);
> >>> \__
> >>> mac->csmacaCallBack(p_IDLE);
> >>> *** important: csmacaCallBack set the status of the csma to 1 ***
> >>> \__
> >>> dispatch(status,__FUNCTION__);
> >>> \__
> >>>
> >>> mcps_data_request(0,0,0,0,0,0,0,0,0,taskP.mcps_data_request_TxOptions,fal
> >>> se,status); \__
> >>> plme_set_trx_state_request(p_TX_ON);
> >>>
> >>> ...Phy802_15_4::PLME_SET_TRX_STATE_request(PHYenum state) is invoked but
> >>> it cannot change the transceiver state to TX_ON, since the transceiver is
> >>> receiving a packet!!!
> >>> It will answer with a status p_BUSY_RX;
> >>>
> >>> When the reception of the packet ends the old request for changing the
> >>> transceiver status to TX_ON is overwritten by the MAC which requests that
> >>> the tranceiver passes to a RX_ON o TRX_OFF, and a PD_DATA.confirm is not
> >>> invoked for the previous PD_DATA.request.
> >>> As a result the status of the csma (which is reset by PD_DATA.confirm)
> >>> remains to the value 1.
> >>>
> >>> The csma status set to 1 prevents for example any following attempt to
> >>> start the beaconing process, with START_request getting ignored!!! (the
> >>> corresponding confirm is not invoked).
> >>> For me this triggered a sequence of events which caused a task overflow
> >>> error and the simulation to abort.
> >>> So in my simulations I turned back the CCA behaviour to the previous
> >>> version by synchronizing the moment in which the channel is tested and
> >>> that one in which the response is given.
> >>>
> >>> Bye.
> >>>
> >
> >
> >
> >
>
>
> --
> Tim Allemeersch
> Department of Information Technology (INTEC)
> Ghent University - IBBT e: [EMAIL PROTECTED]
> a: Gaston Crommenlaan 8 bus 201 - 9050 Ghent - Belgium
> t: +32 9 3314982
>
>
