[Ns-developers] Questions regarding ns-3 Wifi

[Jens Mittag]

Hi together!

Together with the Chalmers University, we (University of Karlsruhe) are 
currently working on a detailed physical layer implementation for the 
ns-3 wifi, which goes from the data bits of a packet down to the 
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

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.

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).

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.

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 
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).

-- 
Dipl.-Inform. Jens Mittag
University of Karlsruhe
Institute of Telematics
Decentralized Systems and Network Services Research Group

Engesserstr. 2, 76131 Karlsruhe, Germany
Building 20.50, Room 112

Phone: +49 (721) 608 5768
Fax:   +49 (721) 608 6789

http://dsn.tm.uni-karlsruhe.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5833 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090519/f495db4c/smime-0001.bin