It doesn’t need a channel assignment until it needs to send a message. When it wants to send a message, it goes online, registers, requests and sends. Then it goes off line.
Brian From: Peter Stanforth <[email protected]<mailto:[email protected]>> Date: Tuesday, December 10, 2013 at 10:14 AM To: Brian Rosen <[email protected]<mailto:[email protected]>>, Ray Bellis <[email protected]<mailto:[email protected]>>, Don Joslyn <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [paws] Proposal to optionally support shortened message format UK example. Sensor on a trash can. Wants to talk (real data) only when the can is full (once a week?) battery goal is 5 years. Ofcom requires channel validation every 15 minutes. So it is sending 672 overhead messages for every useful one. The validation times are not going to get longer, only shorter, when we move into other bands. Not everything wireless is a smart phone. There may be 6B of those eventually but the projections for M2M are nearly 10 times that. From: <Rosen>, Brian <[email protected]<mailto:[email protected]>> Date: Tuesday, December 10, 2013 10:00 AM To: Peter Stanforth <[email protected]<mailto:[email protected]>>, Ray Bellis <[email protected]<mailto:[email protected]>>, Don Joslyn <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [paws] Proposal to optionally support shortened message format We’ve looked at these kinds of claims. If it meant 10% of battery, it would be significant, but it almost never does. In one example we looked at, 30% change of message size changed battery by less than 1%. Yes, the radio is a significant drain on the battery, but so is CPU and other interfaces. You have to look at the entire message set transmission over the typical charge/discharge cycle. How often is this message sent, and what other radio traffic is there when battery charge is stressed? So, how often is it sent? In the US, it’s once every 24 hours unless there are schedule changes. The UK wants more. What is their number? Once an hour? Once every 15 minutes? A master has to send an equivalent message to every slave, but if I halve the size of a message sent every 15 minutes while the device is servicing those clients, what is the percentage of radio traffic due to the protocol? Could it even approximate 1%? More likely .01%. Then halve it size, just to be aggressive. What happens to battery? Brian From: Peter Stanforth <[email protected]<mailto:[email protected]>> Date: Tuesday, December 10, 2013 at 9:44 AM To: Brian Rosen <[email protected]<mailto:[email protected]>>, Ray Bellis <[email protected]<mailto:[email protected]>>, Don Joslyn <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [paws] Proposal to optionally support shortened message format Energy per transmitted bit, the challenge for many battery powered transceivers. So yes 10% is meaningful From: <Rosen>, Brian <[email protected]<mailto:[email protected]>> Date: Tuesday, December 10, 2013 8:53 AM To: Ray Bellis <[email protected]<mailto:[email protected]>>, Don Joslyn <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [paws] Proposal to optionally support shortened message format <personal opinion> I don’t have an objection to doing that, but it won’t do anything substantial to the problem. We have had discussions like this on many protocols over the years. Our experience is this kind of thing has little effect on implementations other than complicating debugging. Using a formal compression scheme on the entire message often helps substantially reduce message size, also substantially complicates debugging, and, in general, we don’t think it actually helps implementations. You really think that reducing message sizes from, say 14KB to, say 10KB, which any decent compression system should be able to do, would actually make any difference to a device implemented this year? If those Ks were Ms, it might be worth thinking about, but Ks? Please. Shorter names probably only changes messages sizes by 10% or so, clearly insufficient to do anything other than confuse humans. Brian From: Ray Bellis <[email protected]<mailto:[email protected]>> Date: Tuesday, December 10, 2013 at 8:34 AM To: Don Joslyn <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [paws] Proposal to optionally support shortened message format On 10 Dec 2013, at 13:03, Don Joslyn <[email protected]<mailto:[email protected]>> wrote: Dan, Vince, When you say that you don’t want to have aliases and just want to decide on short names, does that mean that the current long names would be changed to short names and the long names would not be supported? That's my understanding of what has been proposed, and I think it's a good idea. Ray
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
