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
