Hi 802.15.4-ers!
I am working on the wpan module from ns-2.29, and I don't have the CSH
timer line. I think it was introduced in 2.30 rather than 2.28. So, I
am not seeing such strange problems. I am not sure about which is more
accurate though. Does the standard imply that any activity during the
whole 8-symbol CCA period is supposed to fail the CCA? If so, then
maybe a callback mechanism should be used on receiving while CCA is
active, to invalidate CCA. However, if I am to choose whether to
perform the CCA measurement in the middle of the CCA period or at the
end, at the end looks more consistent to me, as Daniele's found out.
I am not very familiar with the PHY part as most of my work is in MAC,
but it doesn't look to me like packets are discarded if received during
CCA, am I right?
I am working on peer-to-peer MAC too, with emphasis on contention-free
access (GTS). I have developed an extension to the protocol allowing
distributed GTS management in peer-to-peer mode. My next step is
multi-path routing, e.g. AOMDV. Unfortunately it doesn't seem to be
ported to ns-2.29.
Regards,
Ahmad
On Tue, 6 Mar 2007 21:28:13 +0100
Daniele Messina <[EMAIL PROTECTED]> 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.
>
>
>
