[Smac-users] regarding border nodes behavior

Wei Ye weiye at ISI.EDU
Thu Jul 29 10:02:23 PDT 2004


Esteban,

Please look below for the answers.

On Thu, 2004-07-29 at 05:43, Esteban Egea López wrote:
> Hi,
> I have some questions about border nodes, namely, nodes which adopt more than 
> one schedule. As can be read in  Wei Ye's SMAC paper (Trans on Networking, 
> June 2004), there are two options regarding adoption of several schedules: 
> (1) to wake up at the listen time of both schedules or (2) to wake up just at 
> the listen time of the first schedule receive. Since the node knows that some  
> other neighbors follow another schedule, it can still talk to them.
> 
> According to SMAC source code, the second option has been chosen and the nodes 
> just wake up at listen time if schedule id=0  or if there is a message to be 
> transmitted to a neighbor in that schedule. Otherwise, it won't wake up.
> 
> The question is: How can this node receive messages from neighbors in 
> schedules other than the main one (first received, sched id=0)? 
> It can send messages to those neighbors but it won't be able to receive 
> because the node will be sleeping unless has someting to send.

It can receive from a node on another schedule, because the sender will
wake up at the receiver's schedule (receiver's listen time) and send the
packet.

> Related to this, if a node wakes up to send a message in a sched id > 0, it 
> won't go to sleep again until sleep time of sched id =0. If listen time of 
> both schedules are close and duty cycle is high, energy will be wasted 
> listening during sleep time.

After a node sent out a packet and performed adaptive listen, it should
go to sleep if it was sleep time at that moment according to its
schedule (id = 0).

-Wei

> Is that the correct protocol behavior?
> 
> Thanks a lot in advance,
> Esteban
> _______________________________________________
> Smac-users mailing list
> Smac-users at mailman.isi.edu
> http://mailman.isi.edu/mailman/listinfo/smac-users



More information about the Smac-users mailing list