[Ns-developers] progress on wireless PHY

[Ruben Merz]

Hi again,

[snip]

> 
> Cross layer stuff is yet another problem. I am not sure I want to tackle
> it right now.

Sure

[snip]

> 
> Like this:
> void
> WirelessPhy::Send (Packet p, uint8_t mode, uint8_t channel, double
> txPowerDbm)
> {
>   if (txPowerDbm < m_minTxPowerDbm)
>     {
>       txPowerDbm = m_minTxPowerDbm;
>     }
>   else if (txPowerDbm > m_maxTxPowerDbm)
>     {
>       txPowerDbm = m_maxTxPowerDbm;
>     }
>   txPowerDbm += m_txGainDbm;
>   RealSend (p, mode, txPower);

Ok

>>>>>>     */
>>>>>>
>>>>>>    [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.
>>>>> I agree. The rationale for the current behavior is that the Receive
>>>>> method is expected to be called by the Channel object while the Send
>>>>> method is expected to be called by the MAC. So, both methods have
>>>>> different semantics. and if we did decide to use a double everywhere,
>>>>> there would still be the problem of defining exactly the semantics of
>>>>> that argument. Let me explain:
>>>>>
>>>>> Send (double txPower);
>>>>>
>>>>> Is this txPower pre or post tx gain ? i.e. to get the tx power at the
>>>>> end of the antenna, do you need to add the tx gain ? the same question
>>>>> holds for Receive. Currently, Receive is post tx gain, post propagation
>>>>> loss and pre rx gain. RealReceive is post rx gain. You think that this
>>>>> is confusing ? I agree but I do not see a simple way to solve this kind
>>>>> of problem. I welcome better suggestions :)
>>>>>
>>>> For the receiver, this is not confusing. The power you want to have when 
>>>> you compute, say, an SNR is the power "post-everything". So here it is 
>>>> simple.
>>>>
>>>> And at the send side, yes you should add the tx gain. Of course upper 
>>>> layers should now about it.
>>> I mean, who should add the tx gain ? the Caller of ::Send or the Send
>>> method itself ? I see this as a bit confusing to users. I wish I could
>>> find a way to make this super explicit in the API other than relying on
>>> documentation.
>> I believe the caller of ::Send should do it. Because if the Send method 
>> does it by itself, the user of the Send method will still have to make 
>> sure that the power value given to the send method + a gain does not 
>> exceed a maximum.
> 
> I was leaning the other way. I think both solutions are inherently
> fragile so, I will try to come up with something nicer.

I'll think about it too.

>> [snip]
>>
>>>> For (3), no I disagree. this is as important than the mode and the tx 
>>>> power. In the classical 802.11, the channel (in this case, the 
>>>> frequency) does not change. But it might very well at some point. CDMA 
>>>> physical layers can have a different spreading code for each packets. 
>>>> Same for UWB physical layers where we might use a different time-hopping 
>>>> code for each packet depending on the destination.
>>> I see. In this context, your suggestion to create a table of 'channels'
>>> similar to the table of 'txmodes' makes sense.
>> Did I suggest this? Actually it might be a good idea. Though in the case 
>> of CDMA or UWB channels, you might have a (very) large table because you 
>> can have a large number of "channels".
> 
> I am not sure I like the idea of a table of channels though (as you say,
> it could be very big). Allowing the user to specify a 'frequency' seems
> enough. Which also solves nicely the naming problem you had below.

Not sure I understand why it solves the naming problem. Yes, if the 
function is called from the MAC, you can have any name you want. But in 
the PHY, you still want to have something reasonnable.

On the other hand, maybe the naming is a non-issue.

[snip]

>> Thanks, I believe it is important that the "channel" is called in the 
>> Send method. Now, I'm not sure that "channel" is really the best name 
>> available. Neither is frequency, or code or time-hopping sequence since 
>> they are implementation specific names. What bothers me a little bit 
>> with the "channel" name is that there is already a channel in ns which 
>> is the wireless channel. So maybe we could call it
>>
>> - logical-channel
>> - phy-channel
>> - pseudo-channel
>>
>> Any idea?
> 
> I am really not convinced channel should be passed to each call
> to ::Send. I think it should be passed to each call to ::Receive to
> specifiy the channel of the sender

Ok for the ::Send. But then, how to give this information to ::Receive.

> I see no reason to make the sender
> have to specify both a 'currently-listening-on' channel and a
> 'currently-sending-on' channel on a per-packet basis. This really looks
> awkward. I think it would make much more sense to set a per-PHY current
> channel used for each packet sent and used as the 'listening-on' channel
> and then, we can pass to each call to ::StartReceive an extra channel
> arg which identifies the channel of the sender.

Oups, sorry, I'm not sure I understand. So what you suggest, is that the 
PHY as only a m_currentChannel, right? How would this work? What if the 
channels used between the source and the destination are not the same? 
This can be the case with CDMA/UWB networks. It is not awkward, you 
simply want to have a channel for listening and a channel for sending, 
that's all.


Then, regarding how to set the channel(s), I have another scenario. What 
if the sender changes it channel from packet to packets? Take the 
following use case: with UWB radios, each node can have a time-hopping 
sequence (or spreading code in the CDMA language). In my case, when a 
source talks to a destination, it uses the time-hopping sequence (ths) 
of the destination. So a packet sent to destination B will use ths_B. A 
packet sent to destination C will use ths_C. So, if my source talks to 
several nodes, it will very regularly change the channel it uses per 
packet. CDMA networks can also behave in the very same way. So, so far 
we have two solutions

1. A setChannel function that sets a m_channel
2. the channel being set explicitly in the Sent call.

right? For case 1, whenever I'm transmitting to another destination, I 
would have to call the ::setChannel function before the ::Send function. 
In case 2, I directly call ::Send channel.

I also have another scenario. Say you have a node that listens to on 
channel A. Then, say the MAC of this node has a packet to send on 
channel B. With case 1, the MAC sets the m_currentChannel to B (A->B) 
and just call the :Send function. This will schedule an event at time t2 
at the PHY for sending this packet. Then, say there is a packet 
scheduled to arrive from some source on channel A at time t1 <= t2. This 
packet won't be received because you have already changed 
m_currentChannel in the PHY (to B != A). But you have not sent anything 
yet either. And this is bad, because to lose a packet that you were 
supposed to received  is very costly. The source will have timers 
expiring, will have to resend the packet, etc.

On the other hand, If you do not set immediately the m_currentCHannel, 
then this does not happen. You will receive the packet sent on channel 
A. The packet to send on channel B will see a busy phy and simply need 
to wait. And this is really less of a problem because it is a local 
issue and the MAC can know about it. It just wait for the end of the 
packet reception and sends right after.

Another way to solve this issue is to have a m_rxCHannel and a 
m_txCHannel that are independent.

I hope it is not too confusing. And to summarize, what I don't 
understand is how to make it work with one channel parameter at the phy 
and how this would interact with  ::StartReceive?

Regards,
Ruben