[Ns-developers] progress on wireless PHY

[Ruben Merz]

Hi Mathieu, hi all,


> 2) If you care about the MAC <-> PHY interface, please, comment on the
> attached API proposal. Also available from there:
> http://www-sop.inria.fr/dream/personnel/Mathieu.Lacage/wireless-phy.h 

Here are my (lengthy) comments and questions on wireless-phy.h. To try 
to keep it short, I have removed the parts of the codes where I have no 
comments. My comments are written in C++ comment style with an "rmz" at 
the beginning of each comments. I hope they will make sense:

class PropagationModel
{

   [snip]

   double GetRxPower (double txPower, PositionModel *source, 
PositionModel *destination) const;
};

/* rmz
  * What is a position model?
  *
  */

class WirelessChannel
{

   [snip]

   void Connect (WirelessPhy *phy, PositionModel *model);

   [snip]

   void Send (WirelessPhy *sender, Packet p,
	     uint8_t mode, double txPowerDbm);
};

/* rmz
  * I don't understand why the Connect method is necessary?
  *
  * Also, we might want to have a way to limit the number of nodes to
  * send the packet to already at this stage. We could have a function
  * in PropagationModel that returns a maximum range. But on the other
  * hand this could be counterproductive when dealing with cumulative
  * inteference.
  *
  */

   [snip]

class WirelessPhy
{
  public:
   WirelessPhy ();

   uint32_t GetNTxPowerLevels (void);
   /* rmz
    *
    * Are the power levels all the possible transmition powers
    * available to this PHY? Or is this function supposed to return the
    * current transmission power. Then according to what I can see
    * below, you have a finite amount of transmit power available
    * i.e. a table of transmit powers. How would we deal with cases
    * where the power is chosen in a continuous range of values between
    * a P_min and a P_max?
    *
    *
    */

   uint32_t GetNModes (void);
   /* rmz
    *
    * I fail to see what this function exactly returns
    */

   /**
    * \param mode the mode we want to get information upon
    * \returns the number of bits per second sent for this mode.
    *
    * The returned bit rate should be the physical-level bitrate.
    * i.e.: if the tx mode sents 6Mbs bits and has a 1/2 FEC, then
    * the value returned by this method should be 6Mbs.
    */

   /* rmz
    *
    * You probably want to have 3 instead of 6 in the above comment.
    */
   uint32_t GetModeBitRate (uint32_t mode);

   /* rmz
    *
    * I understand that a mode is a combination of a given modulation
    * and channel code that results in a given bit rate. Now, how would
    * we do to get the particular modulation used or the particular
    * mode. In other words, how to get more information from a mode?
    *
    * Right now, the modes seems to be simple index. So, can the modes
    * be extended? I would see a mode as a structure (or an
    * object). The PHY would have a table/list of modes and when
    * invoking the function GetModeBitRate with the index of the
    * particular mode in the table. Say
    *
    * uint32_t GetModeBitRate (uint8_t mode_index);
    *
    * struct mode {
    *   uint32_t modulation_index;
    *   uint32_t code_index;
    * }
    *
    * The function GetNModes would then return a pointer to the tables
    * of all modes.
    *
    * More generally, another point is the following, there exists
    * physical layers with variable phyical-level bitrate and variable
    * physical-level transmission power.
    *
    * So I would suggest the following, which is to have function that
    * returns all the possible transmission mode, a function that
    * returns all the possible transmission powers, or the range of
    * transmission power. And then to have two functions that return
    * the particular mode or transmission power that is being used
    * currently.
    *
    * uint32_t * GetNModes (void);
    * double GetNPmin (void);
    * double GetNPmax (void);
    *
    * uint32_t GetCurrentMode (void);
    * uint32_t GetCurrentTxPower (void);
    *
    */

   /**
    * predicates on the current state.
    */
   bool IsStateBusy (void);
   bool IsStateIdle (void);
   bool IsStateBusy (void);
   bool IsStateSync (void);
   bool IsStateTx (void);

   /* rmz
    *
    * I would change the name of the SYNC sate to RX. Why? beacause,
    * for me the SYNC state represents the state of the physical layer
    * when it tries to obtain the start time of the packet.
    *
    * This would add
    *
    * bool IsStateRx (void);
    *
    */

   /**
    * \param p packet to send
    * \param mode the mode to use to send this packet. This number
    *        is an index in the internal transmission mode array.
    * \param power the power level to use to send this packet.
    *        This number is an index in the internal tx power
    *        level array.
    *
    * Send the packet with specified transmission mode and
    * transmission power.
    */
   void Send (Packet p, uint8_t mode, uint8_t power);

   /* rmz
    *
    * Power could be a continuous value, no? So why not use a double
    * for power instead.
    */

   [snip]

   void Receive (Packet p, uint8_t mode, double rxPowerDbm);

   /* rmz
    *
    * Mmm, for me to have a double for the power is not consistent with
    * the Send function. I would have a double everywhere.
    *
    */

   /* rmz
    *
    * Finally, I see three things missing: 1. How to keep track of
    * interfering packets 2. the notion of packet detection stage and
    * timing synchronozation stage 3. the absence of the concept of
    * "channels" either in the transmission mode or as a separate
    * argument. 802.11 has 11 frequency channels it can transmit
    * on. CDMA has "channels" that corresponds to the different
    * spreading codes.
    *
    * (1) I would create an interference list where all packets
    * received by the PHY that are not candidate for reception would be
    * kept. The functions would be
    *
    * void insertPacket(Packet p, uint8_t mode, double rxPowerDbm)
    * void computeInterference(Time t1, Time t2)
    *
    * where computeInterference is used to compute the average level of
    * interference from time t1 to time t2, typically the beginning and
    * end of a packet.
    *
    * (2) In some other physical layers than 802.11, detecting that
    * there is a packet on the channel is a non trivial thing that can
    * fail. So I would try to keep this in mind. One of my proposal is
    * to replace the SYNC state by RX state and to use SYNC for the
    * purpose of packet detection and timing acquisition.
    *
    * (3) Regarding the "channels", it is important to understand that
    * packets send on different channels can be received by the same
    * PHY. But one packet might be considered as pure interference and
    * the other be a candidate for reception. Hence, what also must be
    * defined is on which "channel" does a PHY listens to.
    *
    * To illustrate this concept a little bit more, let's take an
    * 802.11 radio. Say that a station S1 send a packet on channel 5
    * and another station S2 sends a packet on channel 6. The
    * destination of the packet of S1 is R which is listening on
    * channel 5 too. For R, the packet sent by S2 will be interference
    * (actually, it is even worse cause depending on the transmit power
    * of this packet, it might create a collision).
    *
    * The Send function would become:
    *
    * void Send (Packet p, uint8_t mode, uint8_t power, uint8_t channel);
    *
    */

   [snip]

   void SetReceiveOkCallback (Callback<void,Packet,uint8_t,double> cb);

   [snip]

   void SetReceiveErrorCallback (Callback<void,Packet,uint8_t,double> cb);

   /* rmz
    *
    * I'm not sure I really understand how you want to use these two
    * methods, or what they are for.
    *
    */

   [snip]

   void SetTxPowerIncrememntsDbm (double txPowerBase,
				 double txPowerEnd,
				 uint32_t nTxPower);
   /*
    * rmz
    *
    * This is how you planned to fill the table of possible transmit
    * power. I'm not convinced by this idea. But then, we should have a
    * table of transmission modes too.
    */

   [snip]

   };
};