And sending several 14k octet messages to register, request, get
response...and then send 10 octet message contain a status of "full" and
a time stamp?
Hm. That sensor probably has only a wireless link, with datarate in the
slow to really slow range. You need a protocol optimized for the trash
can sensor if it's really going to work.
<shameless bragging> And I know where you can find one! Take a look at
IEEE 802.15.4m. Compact over the air encoding of the essential
register/request/response messages. For an app like the trash can
sensor, you would have an edge device (mains powered) that talks to the
database (using PAWS or whatever is required), possibly keeping a local
cache of what's available for it's area.</shameless bragging>
-Ben
:-)
On 12/10/2013 7:28 AM, Rosen, Brian wrote:
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
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
