Hi! On Tue, 10 Nov 2009, Paul Johnson wrote:
> I think "beacons whenever a node wakes up from sleep" covers that :-) Right. I was thinking to the LPL stream when I read that. :P > But regardless, either you are sending additional messages to keep tight time > synchronization (even if you have no need to send packets in the near > future), each node is wasting energy every time it wakes up by sending a > beacon(even if no node has anything to send to it), or the sender wastes > energy sending superfluous packets. > It all depends on how common transmissions are in your network. If they are > very rare, then on the event that a sender needs to spend a little extra > energy might not be that bad compared to the constant overhead of > synchronization or beacons. On the other hand if transmissions are common, > then you will probably be better off with beacons or time synchronization. > True again. Note: the setRxSleepInterval was renamed to setRemoteWakeupInterval in the CVS. -- Razvan ME > Razvan Musaloiu-E. wrote: >> Hi! >> >> On Tue, 10 Nov 2009, Paul Johnson wrote: >> >>> Yes, that pretty much sums it up. There are better ways of doing it, but >>> those usually require either very strict time synchronization or beacons >>> whenever a node wakes up from sleep. Each has its disadvantages, it just >>> depends on what is more important to the application. >> >> Actually, there is one more way which doesn't involve synchronization or >> sending so many packets: a node could signal that he is awake by sending a >> packet and the sender waits for this signal. :-) >> >> A MAC protocol based on this is RI-MAC: >> http://www.cs.rice.edu/~yanjun/research/sensys08.pdf >> >> The same idea is also used in Low Power Probing in Koala: >> http://cs.jhu.edu/~razvanm/ipsn2008koala.pdf >> >> The master+lpp head from here [1] is implementing LPP as an alternative to >> LPL. LPP is also implemented in Contiki along XMAC (which is similar with >> the LPL). :-) >> >> [1] http://hinrg.cs.jhu.edu/git/?p=razvanm/tinyos-2.x.git >> >> All the best! >> Razvan ME >> >>> Of course, if you come up with a better way of doing it w/out time >>> synchronization or beacons, then i'm sure you could get a research paper >>> out of it at the least. >>> >>> :-) >>> >>> -Paul >>> >>> Xiaodong Wang wrote: >>>> 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> 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 Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
