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
