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,false,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.
--
Daniele Messina
Ph.D. Student, Dept. of Informatic Engineering (DINFO), University of Palermo
Research collaborator, Dept of Electrical, Electronical and Telecommunications
Engineering (DIEET) University of Palermo
g-mail: [EMAIL PROTECTED]
e-mail: [EMAIL PROTECTED]
e-mail: [EMAIL PROTECTED]
work phone: (+39) 0916615273/269 (DIEET)
private phone: (+39) 3343879891
MSN contact: [EMAIL PROTECTED]
Visit also my home at deviantART: http://charlie-lee.deviantart.com/
