You are ignoring the facts that 1) nodes do not efficiently duty-cycle during 
the join process as they are not yet provisioned with schedule; 2) that overall 
consumption of a node during join will depend on the time it spends at a high 
duty cycle, i.e., time it takes until it is provisioned with the schedule. So 
IMO the key metric is the duration of the overall process, network-wise. 
Percentage of battery consumed was not the best metric to consider as it 
clearly depends on the capacity of your battery. The duty cycle with minimal 
schedule during joining will probably be on the order of 10-15% (1/11, 1/7 
cells). That means that 10-15% of time you will be wasting energy listening to 
the transmissions of others, collisions, retransmissions, the duration of which 
depends on the number of nodes contending for the minimal cell and obviously 
the traffic load per node. 

The only factor that we can affect in this working group is the traffic load 
and you seem to be suggesting to just not care about it. To your point that a 
node "needs to send a frame every few seconds just to stay in the network", 
this happens at a duty cycle that can be bellow 0.1% and so doesn’t have much 
in common with the join process.


> On 03 Nov 2015, at 08:36, Tero Kivinen <kivi...@iki.fi> wrote:
> 
> If sending/receiving 10 frames deplates a quarter of the battery of
> nodes, then you do have problem. Also if your network is so that the
> node #100 needs to go through all nodes #2-#99 to get to the
> coordinator, then the node #2 needs to indeed pass huge amount of
> frames through.
> 
> It we assume that we have network where we have 100 nodes, and those
> 100 nodes are split in 2 levels of interaction, i.e. coordinator talks
> to 10 nodes, and each of those nodes have 10 "child" neighbors, then
> the traffic between those JA nodes need to pass 10*10 frames, i.e. 100
> frames. That should not be problem in TSCH network, as TSCH nodes
> cannot be silent for long time. They need to transmit frame every few
> beacon intervals, thus they are sending frame every few seconds just
> to stay in the network.

_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Reply via email to