Subject: [paws] Proposal to optionally support shortened message format

From: Don Joslyn <[email-masked]>
Date: Fri, 6 Dec 2013 14:14:54 -0500

All,

While working closely with a number of white space radio vendors that wish to support the PAWS protocol, some have expressed concerns with the size of paws messages, especially the size of an AVAIL_SPECTRUM_RESP message that supports Ofcom requirements and includes every channel. One issue raised is that when these messages are very large (in this case >14k bytes), requiring several MTU's of packet data, their radio device does not have enough available RAM (or resources) to support the required packet buffering, especially when their device is being used as a master with several attached slaves. A second issue raised is the amount of traffic generated by these control messages, reducing the bandwidth available for user data traffic. The worst case is a master device supporting several slave devices where every device is required to periodically request a new channel list (and the periodic interval requirement seems to be getting smaller). Both issues are serious concerns for these radio vendors, and unless we do something to resolve it, they may not be able to support the paws protocol. A further concern for radio developers is energy expended per transmitted bit.  This is a major issue for battery powered devices.

I would like to propose that we support an optional shortened message format, by creating a two-character alias for each defined parameter's text name, without making any changes to message structure. We would be shortening the parameter text names, not the parameter data values. When a device sends a message to the database with shortened parameter names, the presence of shortened parameter names could serve as a trigger for the database to reply to the device using shortened parameter names in the reply message.

This would be fairly easy to express in the current document by adding a paragraph to explain the support for shortened messages and adding a two-character alias in parenthesis next to each defined parameter name. I have attached an example to this email as a markup to page 40 of the version 7 draft.
In the example, I have defined two-character aliases for several parameter names, and included a sample "spectrum" section that uses shortened parameter names.

The sample uses the following aliases:

"spectrum" = "sp"
"resolutionBwHz" = "bw"
"profiles" = "pf"
"freqHz" = "hz"
"powerDbmPerBw" = "pw"

We could define the shortened parameter names and make support of shortened messages optional to allow database owners to decide if they want to support shortened messages or not.

If there is support for this proposal, I would volunteer to update the version 7 draft to help move it forward.

Thank you,
Don

---

From: <[email-masked]>
Date: Fri, 6 Dec 2013 22:26:02 +0000

You are asking for a json compression mechanism, for understandable reasons. I was actually surprised this issue did not come up earlier.
We first need to have a discussion to see if there's consensus for the need of a compression mechanism, and if yes, then see how do we get one in place.
I did not find any json compression related work in ietf, but a quick search found few available algorithms. Do we have on this list JSON experts who could give some advice?
Gabor

From: paws [mailto:[email-masked]] On Behalf Of ext Don Joslyn
Sent: Friday, December 06, 2013 11:15 AM
To: [email-masked]
Subject: [paws] Proposal to optionally support shortened message format

All,

"spectrum" = "sp"
"resolutionBwHz" = "bw"
"profiles" = "pf"
"freqHz" = "hz"
"powerDbmPerBw" = "pw"

Thank you,
Don

---

From: "Harasty, Daniel J" <[email-masked]>
Date: Mon, 9 Dec 2013 16:02:12 +0000

All,

While I don't necessarily agree with all of Don's reasons, I'm not opposed to us adopting some means to shorten the messages.

Here's my proposal:

*         If we want to consider "more concise" / "less wordy" tag names, fine by me.  We can shorten things like "powerDbmPerBw" to "power" or simply "db".

o   Sure, that makes the protocol a wee-bit less "human readable".  However, if it makes it more "machine friendly" ala Don's view, that is probably acceptable.  After all: the human should be reading the spec...

o   Note that shortening the longer tags that appear repeatedly (such as in the "spectra" list) will give us the most "bang for the buck" in this effort.

*         Let's not mess around with *optional* "short form" tags.

o   Either a tag is short or long; let's not add complexity by creating something like aliases.

*         If we want to consider some actual compression, let's not invent something new here.  I haven't heard of any standardize way to compress JSON... but since HTTP is the presumptive transport, why not just rely on "standard" HTTP compression?

o   See: http://en.wikipedia.org/wiki/HTTP_compression

o   I would make support the spec stating this is "recommended" for WS Databases, and optional for WS Clients.

Will actual compression help?  Turns out we've experimented a bit with this even before Don's email, so here's one data point: we found many of the AVAIL_SPECTRUM_RESP messages to be in the range of 17k characters.  A simple call to a zlib compression algorithm on that string typically shortened it to about 1k characters.  (This was specifically using the HTTP compression techniques, but I expect the compression rate to be similar.)

Here's my concern:

*         If memory management is an issue in the radios, then don't we actually make things WORSE by compression?  After all, if a 17k message is compressed down to 1k... then the TRANSPORT of the message is sped up... but the message now has to exist in the client's memory - at least briefly - in BOTH the compressed and decompressed form.

Just a quick viewpoint to consider:  In my opinion, at the heart of the matter, the desire of some participants is to make a VERY GENERAL message structure to AVAIL_SPECTRUM_RESP that will suit multiple use cases in multiple countries.  This is at odds with brevity, and therefore may be at odds with certain radio-implementation constraints.

*         For example, a given device which is only going to operate in the US gains nothing from this verbosity of our current generic structure.  To wit, for US purposes, the whole SpectrumSchedule could be condensed to something a lot like this:
avail_chans: {5: 4000, 12: 4000, 16: 100, 17: 100, 18: 100, 31: 40, 41: 40}
representing that channels 5 and 12 are available at 4000mW, channels 16, 17, and 18 are available at 100mW, and channels 31 and 41 are available at 40mW.  This alone represents a savings of the majority of the 17k characters.  (Admittedly, the "time" aspect of the schedule would still need to be addressed.)

Dan Harasty

From: paws [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, December 06, 2013 5:26 PM
To: [email-masked]; [email-masked]
Subject: Re: [paws] Proposal to optionally support shortened message format

From: paws [mailto:[email-masked]] On Behalf Of ext Don Joslyn
Sent: Friday, December 06, 2013 11:15 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [paws] Proposal to optionally support shortened message format

All,

"spectrum" = "sp"
"resolutionBwHz" = "bw"
"profiles" = "pf"
"freqHz" = "hz"
"powerDbmPerBw" = "pw"

Thank you,
Don

---

From: Vincent Chen <[email-masked]>
Date: Mon, 9 Dec 2013 22:56:51 -0800

All,

Shortened Names:
- I agree with Dan that we should not have aliases for parameter names. We
should just decide on the short names
- I would only shorten the names that are highly repeated, such as those in
the Spectrum message, as Don suggested.

Compression:
- I agree we should just rely on standard HTTP compression and, as Dan
suggests:
   - “Recommended” for WS Databases, and optional for WS Clients.

On a separate note, HTTPS is required. Are the radio vendors concerned
about supporting that?

-vince

On Mon, Dec 9, 2013 at 8:02 AM, Harasty, Daniel J <[email-masked]>wrote:

> All,
>
>
>
> While I don’t necessarily agree with all of Don’s reasons, I’m not opposed
> to us adopting some means to shorten the messages.
>
>
>
> Here’s my proposal:
>
> ·         If we want to consider “more concise” / “less wordy” tag names,
> fine by me.  We can shorten things like “powerDbmPerBw” to “power” or
> simply “db”.
>
> o   Sure, that makes the protocol a wee-bit less “human readable”.
> However, if it makes it more “machine friendly” ala Don’s view, that is
> probably acceptable.  After all: the human should be reading the spec…
>
> o   Note that shortening the longer tags that appear repeatedly (such as
> in the “spectra” list) will give us the most “bang for the buck” in this
> effort.
>
> ·         Let’s not mess around with **optional** “short form” tags.
>
> o   Either a tag is short or long; let’s not add complexity by creating
> something like aliases.
>
> ·         If we want to consider some actual compression, let’s not
> invent something new here.  I haven’t heard of any standardize way to
> compress JSON… but since HTTP is the presumptive transport, why not just
> rely on “standard” HTTP compression?
>
> o   I would make support the spec stating this is “recommended” for WS
> Databases, and optional for WS Clients.
>
>
>
> Will actual compression help?  Turns out we’ve experimented a bit with
> this even before Don’s email, so here’s one data point: we found many of
> the AVAIL_SPECTRUM_RESP messages to be in the range of 17k characters.  A
> simple call to a zlib compression algorithm on that string typically
> shortened it to about 1k characters.  (This was specifically using the HTTP
> compression techniques, but I expect the compression rate to be similar.)
>
>
>
> Here’s my concern:
>
> ·         If memory management is an issue in the radios, then don’t we
> actually make things WORSE by compression?  After all, if a 17k message is
> compressed down to 1k… then the TRANSPORT of the message is sped up… but
> the message now has to exist in the client’s memory – at least briefly – in
> BOTH the compressed and decompressed form.
>
>
>
> Just a quick viewpoint to consider:  In my opinion, at the heart of the
> matter, the desire of some participants is to make a VERY GENERAL message
> structure to AVAIL_SPECTRUM_RESP that will suit multiple use cases in
> multiple countries.  This is at odds with brevity, and therefore may be at
> odds with certain radio-implementation constraints.
>
> ·         For example, a given device which is only going to operate in
> the US gains nothing from this verbosity of our current generic structure.
> To wit, for US purposes, the whole SpectrumSchedule could be condensed to
> something a lot like this:
>
> representing that channels 5 and 12 are available at 4000mW, channels 16,
> 17, and 18 are available at 100mW, and channels 31 and 41 are available at
> 40mW.  This alone represents a savings of the majority of the 17k
> characters.  (Admittedly, the “time” aspect of the schedule would still
> need to be addressed.)
>
>
>
> Dan Harasty
>
>
>
>
>
> *From:* paws [mailto:[email-masked]] *On Behalf Of *
> [email-masked]
> *Sent:* Friday, December 06, 2013 5:26 PM
> *To:* [email-masked]; [email-masked]
> *Subject:* Re: [paws] Proposal to optionally support shortened message
> format
>
>
>
> You are asking for a json compression mechanism, for understandable
> reasons. I was actually surprised this issue did not come up earlier.
>
> We first need to have a discussion to see if there’s consensus for the
> need of a compression mechanism, and if yes, then see how do we get one in
> place.
>
> I did not find any json compression related work in ietf, but a quick
> search found few available algorithms. Do we have on this list JSON experts
> who could give some advice?
>
> Gabor
>
>
>
>
>
> *From:* paws [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *ext Don Joslyn
> *Sent:* Friday, December 06, 2013 11:15 AM
> *To:* [email-masked]
> *Subject:* [paws] Proposal to optionally support shortened message format
>
>
>
> All,
>
>
>
> While working closely with a number of white space radio vendors that wish
> to support the PAWS protocol, some have expressed concerns with the size of
> paws messages, especially the size of an AVAIL_SPECTRUM_RESP message that
> supports Ofcom requirements and includes every channel. One issue raised is
> that when these messages are very large (in this case >14k bytes),
> requiring several MTU’s of packet data, their radio device does not have
> enough available RAM (or resources) to support the required packet
> buffering, especially when their device is being used as a master with
> several attached slaves. A second issue raised is the amount of traffic
> generated by these control messages, reducing the bandwidth available for
> user data traffic. The worst case is a master device supporting several
> slave devices where every device is required to periodically request a new
> channel list (and the periodic interval requirement seems to be getting
> smaller). Both issues are serious concerns for these radio vendors, and
> unless we do something to resolve it, they may not be able to support the
> paws protocol. A further concern for radio developers is energy expended
> per transmitted bit.  This is a major issue for battery powered devices.
>
>
>
> I would like to propose that we support an optional shortened message
> format, by creating a two-character alias for each defined parameter’s text
> name, without making any changes to message structure. We would be
> shortening the parameter text names, not the parameter data values. When a
> device sends a message to the database with shortened parameter names, the
> presence of shortened parameter names could serve as a trigger for the
> database to reply to the device using shortened parameter names in the
> reply message.
>
>
>
> This would be fairly easy to express in the current document by adding a
> paragraph to explain the support for shortened messages and adding a
> two-character alias in parenthesis next to each defined parameter name. I
> have attached an example to this email as a markup to page 40 of the
> version 7 draft.
>
> In the example, I have defined two-character aliases for several parameter
> names, and included a sample “spectrum” section that uses shortened
> parameter names.
>
>
>
> “spectrum” = “sp”
> “resolutionBwHz” = “bw”
> “profiles” = “pf”
> “freqHz” = “hz”
> “powerDbmPerBw” = “pw”
> We could define the shortened parameter names and make support of
> shortened messages optional to allow database owners to decide if they want
> to support shortened messages or not.
>
>
>
> _______________________________________________
> paws mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/paws
>
>

-- 
-vince

---

From: Don Joslyn <[email-masked]>
Date: Tue, 10 Dec 2013 08:03:25 -0500

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?

Don

From: Vincent Chen [mailto:[email-masked]]
Sent: Tuesday, December 10, 2013 1:57 AM
To: Harasty, Daniel J
Cc: [email-masked]; Don Joslyn; [email-masked]
Subject: Re: [paws] Proposal to optionally support shortened message format

All,

Shortened Names:
- I agree with Dan that we should not have aliases for parameter names. We should just decide on the short names
- I would only shorten the names that are highly repeated, such as those in the Spectrum message, as Don suggested.

Compression:
- I agree we should just rely on standard HTTP compression and, as Dan suggests:
   - "Recommended" for WS Databases, and optional for WS Clients.

On a separate note, HTTPS is required. Are the radio vendors concerned about supporting that?

-vince

On Mon, Dec 9, 2013 at 8:02 AM, Harasty, Daniel J <[email-masked]<mailto:[email-masked]>> wrote:
All,

Here's my proposal:

Here's my concern:

Dan Harasty

From: paws [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Friday, December 06, 2013 5:26 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [paws] Proposal to optionally support shortened message format

All,

"spectrum" = "sp"
"resolutionBwHz" = "bw"
"profiles" = "pf"
"freqHz" = "hz"
"powerDbmPerBw" = "pw"

Thank you,
Don

_______________________________________________
paws mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/paws

--
-vince

---

From: Ray Bellis <[email-masked]>
Date: Tue, 10 Dec 2013 13:34:47 +0000

On 10 Dec 2013, at 13:03, Don Joslyn <[email-masked]<mailto:[email-masked]>> 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

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 10 Dec 2013 13:53:09 +0000

<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-masked]<mailto:[email-masked]>>
Date: Tuesday, December 10, 2013 at 8:34 AM
To: Don Joslyn <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [paws] Proposal to optionally support shortened message format

Dan, Vince,

Ray

---

From: Peter Stanforth <[email-masked]>
Date: Tue, 10 Dec 2013 09:44:36 -0500

Energy per transmitted bit, the challenge for many battery powered transceivers. So yes 10% is meaningful

From: <Rosen>, Brian <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, December 10, 2013 8:53 AM
To: Ray Bellis <[email-masked]<mailto:[email-masked]>>, Don Joslyn <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [paws] Proposal to optionally support shortened message format

<personal opinion>

Brian

Dan, Vince,

Ray

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 10 Dec 2013 15:00:24 +0000

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-masked]<mailto:[email-masked]>>
Date: Tuesday, December 10, 2013 at 9:44 AM
To: Brian Rosen <[email-masked]<mailto:[email-masked]>>, Ray Bellis <[email-masked]<mailto:[email-masked]>>, Don Joslyn <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [paws] Proposal to optionally support shortened message format

<personal opinion>

Brian

Dan, Vince,

Ray

---

From: Peter Stanforth <[email-masked]>
Date: Tue, 10 Dec 2013 10:14:58 -0500

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-masked]<mailto:[email-masked]>>
Date: Tuesday, December 10, 2013 10:00 AM
To: Peter Stanforth <[email-masked]<mailto:[email-masked]>>, Ray Bellis <[email-masked]<mailto:[email-masked]>>, Don Joslyn <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [paws] Proposal to optionally support shortened message format

Brian

<personal opinion>

Brian

Dan, Vince,

Ray

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 10 Dec 2013 15:28:24 +0000

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

Date: Tuesday, December 10, 2013 at 10:14 AM

Brian

<personal opinion>

Brian

Dan, Vince,

Ray

---

From: "Benjamin A. Rolfe" <[email-masked]>
Date: Tue, 10 Dec 2013 10:28:03 -0800

I am not sure I get Brian's point, but....
The kind of TVWS devices I am dealing with fall into a couple groups.

We have mains powered, resource rich devices that have an internet 
connection, all the memory needed to implement a complete IP protocol 
stack including PAWS, and a high data rate connection to the internet.  
An 802.11 access point is an example of this sort  of device.

There are battery or mains powered, transitory devices that have the 
resource to implement a complete IP stack, assume a reasonable high data 
rate connection to the internet, have the battery capacity to operate 
for a couple days between recharging.  An 802.11 STA in a portable 
device (phone, tablet, PC) might be an example of this kind of device.  
Another example is a M2M device with moderate (1Mbps) interface through 
a gateway.

A resource constrained device may have no IP stack, or a stripped down 
IP stack (UDP, 6loWPAN, ...). Some may have to run for many years on 
battery. Likely no direct internet connection, or squeezes through a 
gateway on a very low data rate wireless link. It may have only an 
wireless interface.  Raw bit rate  is low (100kbps or less) and 
effective throughput much lower. Such devices may be "sleepy" meaning 
they turn off all but a few gates most of the time, only communicate 
when there is something to say.  A low cost remote sensor is an example 
of this sort of device.

PAWS is targeted at the first category, and IMO  will work for the 
second category.  Not ideal for the last category.    I think the 
fundamental assumptions driving protocol design are so different that it 
would be a mistake at this stage to try and make PAWS fit the really 
slim device.

Hope that helps.
Ben

On 12/10/2013 5:53 AM, Rosen, Brian wrote:
> <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
>
>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>
> On 10 Dec 2013, at 13:03, Don Joslyn <[email-masked] 
> <mailto:[email-masked]>> 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?
>

---

From: "Benjamin A. Rolfe" <[email-masked]>
Date: Tue, 10 Dec 2013 10:40:09 -0800

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
>
> To: Brian Rosen <[email-masked] 
> <mailto:[email-masked]>>, Ray Bellis 
> <[email-masked] <mailto:[email-masked]>>, Don 
> Joslyn <[email-masked] <mailto:[email-masked]>>
> 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.
>
> To: Peter Stanforth <[email-masked] 
> <mailto:[email-masked]>>, Ray Bellis 
> <[email-masked] <mailto:[email-masked]>>, Don 
> Joslyn <[email-masked] <mailto:[email-masked]>>
> 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
>
> To: Brian Rosen <[email-masked] 
> <mailto:[email-masked]>>, Ray Bellis 
> <[email-masked] <mailto:[email-masked]>>, Don 
> Joslyn <[email-masked] <mailto:[email-masked]>>
> To: Ray Bellis <[email-masked] 
> <mailto:[email-masked]>>, Don Joslyn 
> <[email-masked] <mailto:[email-masked]>>

---

From: Don Joslyn <[email-masked]>
Date: Tue, 10 Dec 2013 15:25:33 -0500

Brian, All,

My calculations for using two-character names within "spectrum" blocks shows ~37% reduction. Using two "spectrum"  blocks to define 40 channels for two bandwidths (for Ofcom) results in ~6500 characters uncompressed (not counting spaces) versus ~4050 compressed, saving ~2450 bytes for a fully loaded (40 channel) Ofcom-compliant channel list reply. This does not include compressing other names within the message, I'm only showing compression for the "spectrum" blocks.

I realize that some WG members may object to this proposal, some may accept it, and others may not care. If there is more to discuss for or against, I hope others will present their opinion and supporting data. I hope we can come to a speedy decision so that radio vendors will know exactly what they are dealing with. The message size in the current specification may be too large for some to accept/implement, but as others have suggested, they can always use a different protocol.

Thanks,
Don

From: Rosen, Brian [mailto:[email-masked]]
Sent: Tuesday, December 10, 2013 8:53 AM
To: Ray Bellis; Don Joslyn
Cc: [email-masked]
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.

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.

Brian

Dan, Vince,

Ray