I think "beacons whenever a node wakes up from sleep" covers that :-)
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. -Paul 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 <[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
