Malisa Vucinic writes: > 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;
I have assumed that during the joining they will be using the minimal and they do get the schedule in the EBs and will be sleeping most of the schedule. Why do you think they cannot do that? > 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. It will have minimal schedule immediately after it has seen one EB and parsed the TSCH Slotframe and Link IE. Before they see the EB they might need to do active scanning for minutes to find the correct channels and EBs. I.e. if you are using 10 ms timeslot length, with slotframe size of 100, that will mean that slotframe repeats every second. If send beacon in every 10th slotfrmae, that means you send beacon for every 10 seconds on some channel. As the joining device does not know your timing, and he might actally miss few beacons because of random noise, he might need to listen each channel for example 3 beacon intervals, i.e. 30 seconds. 30 seconds * 16 channels = 8 minutes... I.e. after 8 minutes it knows which networks there are, and can pick one. After that the actual listening time for 10 ms every second is quite a lot less than what was used for passive scanning, even if the joining process takes few minutes more. > 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. But I do not think that really changes after you get schedule, as you still listen the same slots, as they are broadcast slots which might contain information for you too. Also depending on your keepalive period you need to send packet every now and then, and that consumes much more power. > 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. I am not suggesting that we do not care it, I am saying that as joining process is done only once, it is so small amount of actual network lifetime, that it does not matter. I mean if joining process takes for example an hour for the 100 node network, and the network is then up and running for a year, before next maintenance cycle, that is 0.01% of the lifetime of the network. > 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. It depends what your keepalive period is. If you use maximum amout possible, you need to send frame every 655.35 seconds (assume 10 ms timeslot length). I have understood that cheap devices do not have that good clocks, thus they want to do keepalives more often. I have no idea how much more often. -- [email protected] _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
