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 <[email protected]> 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 >
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
