[Ns-developers] Questions regarding ns-3 Wifi

[Mathieu Lacage]

hi jens,

I am sorry it took me so long to answer your email, but, here are
hopefully some answers.

On Tue, 2009-05-19 at 16:47 +0200, Jens Mittag wrote:

> modulated complex waveform representation. Since we are emulating a real 
> hardware chipset, we had to extend the WifiPhy states to
> 
> 	SYNC: the transceiver could successfully detect the preamble
> 	RX: the transceiver was able to decode to signal header and is 
> currently decoding the data part of the frame
> 	TX: transceiver is transmitting
> 	IDLE: transceiver is idle
> 	CCA_BUSY: transceiver is busy due to CCA indication

sounds good.

> 
> As a consequence, we have to divide the reception process into several 
> parts, with independent decisions:
> 
>      1. After the preamble, we decide whether we could synchronize to it.
>       - If yes -> continue with the decoding of the signal header (=SYNC)
>       - If no  -> go back to IDLE or CCA_BUSY
> 
>      2. If we could synchronize, we decide at the end of the signal 
> header, whether we could decode it successfully or not
>       - If yes -> continue with decoding of data payload (=RX)
>       - If no  -> go back to IDLE or CCA_BUSY
> 
>      3. At the end of the frame, decide whether we could also decode the 
> payload successfully.

ok.

> 
> So it is (theoretically) possible that a transceiver is BUSY after 
> having synchronized to the preamble, but IDLE again after the signal 
> header (that is before the end of the whole frame).

ok.

> 
> The question I have now is related to the DcfManager: Up to now the 
> WifiPhyListener used only the following methods to report the start/end 
> of a frame reception to the DcfManager:
> 
>    void NotifySyncStart (Time duration);
>    void NotifySyncEndOk (void);
>    void NotifySyncEndError (void);
> 
> which is not sufficient in our case, since we cannot say from the 
> beginning how long the transceiver will be busy (see above). From the 
> perspective of comprehensibility, it would be good to extend this 
> interface by
> 
>    void NotifyRxStart (Time duration);
>    void NotifyRxEndOk (void);
>    void NotifyRxEndError (void);
> 
> such that Sync(Start|EndOk|EndError) refer to the signal header duration 
> and Rx(Start|EndOk|EndError) correspond to the payload duration. 
> However, if we do this, the compatibility to the existing YansWifiPhy 
> and Ns2ExtWifiPhy is broken. To solve this issue, we plan to use the 
> NotifySync(Start|EndOk|EndError) methods for both parts, the signal 
> header and the payload.

ok.

> Since I am not too familiar with the DCF implementation, I prefer to get 
> your opinion as well: do you think that this approach will be compatible 
> with the existing DcfManager? I can not state this by myself for sure 

It sounds about right, some comments below.


> yet, since I haven't understood where the resume of a running Backoff in 
> DcfManager is handled...
> 
> Thanks for your input
>   Jens
> 
> PS: I would be happy about any hint which tells me where a running 
> backoff is resmued in the DcfManager, once it got stopped by a 
> DcfManager::NotifyRxStartNow (Time duration).

There is no real concept of backoff resume in this codebase. What
NotifyRxStartNow does is, rather than stop the timer of a running
backoff and schedule a resume for later, it records information about
the reception to be able to check in AccessTimeout if the backoff has
really expired. If it has not expired because an RxStart arrived since
the last time we scheduled the AccessTimeout method, we recalculate the
expected time at which the backoff should expire and reschedule
AccessTimeout for that time. Basically, AccessTimeout is invoked
whenever a backoff might expire but we don't know for sure if that
backoff really has expired because things might have happened since we
scheduled AccessTimeout so, when AccessTimeout is called, we
double-check with DcfManager::UpdateBackoff to see if a backoff really
expired.

Do this explanation make sense to you ?


Mathieu