Hi Paul,
Thank you very much for your reply. This helps a lot.
According to your reply, then I have a follow up question. Bascially,
the sender will repeatedly send a packet, which covers at least one
sleeping interval such that the receiver is likely to hear the packet.
This seems very inefficient, especially when the receiver is in
low-duty-cycle application. I think this incurs a lot of energy waste
at the sender side, as well as the unnecessary interference at other
nodes because of the continuously using of channel. Am I right?
Thanks,
Xiaodong
On Tue, Nov 10, 2009 at 6:46 PM, Paul Johnson <oewyn...@gmail.com
<mailto:oewyn...@gmail.com>> wrote:
Xiaodong,
My comments are in-line
Hi Guys,
I have a question regarding the low power listening function.
I know for the receiver, we could use setLocalSleepInterval() to
invoke the periodic sleeping. And for the sender, in order to
send the packet to this receiver, setRxSleepInterval should be
used to set the receiver's sleep interval value into the packet
meta data field.
*However, my question is what is the detail of this proceedure? I
don't quite understand the reason why this packet can be received
by the receiver with the same sleep interval value, as we set the
receiver's interval to the packet's meta data field.*
Basically the sender repeatedly sends the packet until it has a
good idea that the receiving node likely heard it. The sender
figures out how long to send the packet based upon the receiving
node's RxSleepInterval. A very abstract example:
Lets say the Receiving node with ID = 3 is awake for 1 second
every 5 seconds. If a transmitting node (ID = 2) continually
sends a packet to Node 3 for 5 seconds, then it is very likely
that the receiving node was awake sometime during which the entire
packet was transmitted.
In tinyos2.x DefaultLplP.nc, I found when to initialize the
sending, the following function will be called:
void initializeSend() {
if(call LowPowerListening.getRxSleepInterval(currentSendMsg)
> ONE_MESSAGE) {
if(call AMPacket.destination(currentSendMsg) ==
AM_BROADCAST_ADDR) {
call PacketAcknowledgements.noAck(currentSendMsg);
} else {
// Send it repetitively within our transmit window
call PacketAcknowledgements.requestAck(currentSendMsg);
}
call SendDoneTimer.startOneShot(
call
LowPowerListening.getRxSleepInterval(currentSendMsg) + 20);
}
post send();
}
*What is the use of this SendDoneTimer?* seems to me that it
schdules next fire time at the interval +20 ms. And when the
timer fires, it will do the following:
/**
* When this timer is running, that means we're sending
repeating messages
* to a node that is receive check duty cycling.
*/
event void SendDoneTimer.fired() {
if(call SendState.getState() == S_LPL_SENDING) {
// The next time SubSend.sendDone is signaled, send is
complete.
call SendState.forceState(S_LPL_CLEAN_UP);
}
}
*What does the above function mean?*
From what i can gather, there is another timer called SubSend that
is in charge of repeatedly sending the packet. This timer
determines when SubSend should stop trying to send the packet. If
SubSend succeeded, the state would not be S_LPL_SENDING, so the
SendDoneTimer doesn't need to do anything. However if it is
S_LPL_SENDING, this means that the SubSend was not able to
successfully send the packet to the node, therefore, it needs to
abandon the attempt. Think of it as a watchdog timer, if it
doesn't succeed by the allotted time, the send will be aborted.
**
**
*Another question is in the initializeSend function, when the
destination address is not broadcast, it will request ack. Does
this mean that the software ack is automatically turned on? When
a receiver receives packet, it will send out ack automatically?
Is it necessary?*
There is a field in the packet that indicates this packet should
be acked. Calling
PacketAcknowledgements.requestAck(currentSendMsg); Makes the
necessary modifications to the packet. The receiver will
automatically send an ACK if this bit is set in the packet upon
receiving it.
When an ACK is requested, the sendDone event for a particular
packet is not called until the ACK is received. In the case of a
broadcast packet, sendDone is called whenever the mac protocol
successfully transmits the packet (regardless of collisions, etc
that may have occurred)
I hope this helps you.
-Paul
