LORA api changes for transmit data rate

[will sanfilippo <wi...@runtime.io>]

Hello:

I would like to propose some changes to the lora api and I want to see if folks had any comments or issues with the following proposal.

The basic issue is the ability to set the transmission data rate on a per port basis. This presents some complications in the code which seem to be unncessary. 

Consider the following API: lora_app_port_cfg(uint8_t port, uint8_t datarate, uint8_t retries).

The main reason for having this API was to allow the developer to set the data rate and retries for the message being sent. This came from the reference code and the ability to set the retries and data rate in the McpsRequest API.

Looking at the code in more detail, I have come to the conclusion that the McpsRequest should not contain the data rate. Not quite sure about the retries but certainly not the data rate. Here are my reasons:

1) If ADR is turned on (Data Rate Adaptation) setting the data rate in the port has no effect. The code must then handle this properly. Not tricky and adds very little extra code but is something that has to be dealt with nonetheless.

2) The data rate set in the original McpsRequest is not necessarily the data rate at which the frame will be sent if there are retries and the frame is confirmed. The lorawan stack will automatically lower the data rate when confirmed frames are sent and not acknowledged. While this is not mandatory in the specification, they strongly urge implementations to lower the data rate after 2 failed confirmed attempts. While I do think the lorawan spec approach leaves something to be desired and is an area where improvements can be made, the main point here is the behavior of the lora stack. The developer sends a confirmed frame on a port and that port uses data rate X. There are failures and the data rate gets lowered to Y. The specification says that future transmissions should start at Y but the current code will set all new McpsRequests to the data rate specified in the port.

3) Generally, I do not think the application developer is going to want to mess with the data rate at all. If they do, there is a way to do this that makes more sense with the current implementation and that is to simply set the MIB element MIB_CHANNELS_DATARATE. While this will still change if confirmed frames fail, the application developer can change the data rate used whenever they want and the code becomes less complicated.

4) Setting the data rate on a per-port basis is just overkill. I cannot imagine the application wanting to change the data rate on a per port basis.

Specific code changes based on this proposal:
1) Remove the data rate from the Mcps Request structure
2) Remove the data rate from the port structure.

As always, comments/suggestions/thoughts always welcome.

Thanks!

PS I think a similar case can be made for specifying retries. I am going to investigate that a bit more and if folks are fine with the current proposal, retries will probably go away as well.

Re: LORA api changes for transmit data rate

[will sanfilippo <wi...@runtime.io>]

That is how it would end up if we removed setting the data rate from the port: the MAC/MLME will determine the data rate by using ADR. If ADR is not enabled, the data rate will be set via a default configuration and can also be modified by setting the MIB.

> On Oct 24, 2017, at 7:01 PM, marko kiiskila <ma...@runtime.io> wrote:
> 
> My preference would be for this to be a system specific API, and not
> tied to application port.
> I feel this is a setting which should be owned by the entity who is
> doing other lora network management (joins/rejoins/link monitoring).
> 
>> On Oct 24, 2017, at 5:08 PM, will sanfilippo <wi...@runtime.io> wrote:
>> 
>> I understand your point and it is a valid concern meaning that I can see why it might be nice to be able to configure different ports as you suggest. However, given the current underlying lora stack, the data rate would not remain constant and the application developer would still have to handle a message being sent back if it was too big once the data rate was lowered out from under them.
>> 
>> Note that adding setting the data rate on a port basis is really an implementation detail of our lora stack. The reference design allows the application developer to set the port and data rate in the McpsRequest, meaning on a per message basis. This got morphed into doing this on a per port basis as access to the reference design's McpsRequest is “hidden” by the current lora api. However, even in the reference design case, the data rate used for that McpsRequest could change.
>> 
>> I was considering modifying the api such that the data rate was specified in lora_app_port_send() when the application wants to send a frame. However, the data rate could still get changed and to me this makes it not as useful. Furthermore, I still think it will be rare for the application developer to dictate the data rate (but I could be wrong here). Honestly, in most cases I think this adds some extra burden on the app developer to specify a data rate.
>> 
>> A possible consideration would be to modify the code so that the application developer can specify the data rate on either a per port or per message basis if they desire, and that the message would always be sent at that data rate.
>> 
>>> On Oct 24, 2017, at 3:56 PM, Christopher Collins <ch...@runtime.io> wrote:
>>> 
>>> On Tue, Oct 24, 2017 at 01:56:22PM -0700, will sanfilippo wrote:
>>>> Hello:
>>>> 
>>>> I would like to propose some changes to the lora api and I want to see if folks had any comments or issues with the following proposal.
>>> 
>>> [...]
>>> 
>>> It sounds reasonable to me.  There is just one thing that stuck out for
>>> me:
>>> 
>>>> 4) Setting the data rate on a per-port basis is just overkill. I cannot imagine the application wanting to change the data rate on a per port basis.
>>> 
>>> The application likely contains several packages not written by the
>>> application developer.  If any of those packages use LoRa, and they have
>>> specific data rate requirements, per-port configuration might actually
>>> make sense.  If a package needs to send packets of a particular size,
>>> for example, then it might have minimum data rate restrictions.  I'm not
>>> very familiar with LoRa, so I don't know if this is a valid concern or
>>> not.  
>>> 
>>> Chris
>> 
> 

Re: LORA api changes for transmit data rate

[marko kiiskila <ma...@runtime.io>]

My preference would be for this to be a system specific API, and not
tied to application port.
I feel this is a setting which should be owned by the entity who is
doing other lora network management (joins/rejoins/link monitoring).

> On Oct 24, 2017, at 5:08 PM, will sanfilippo <wi...@runtime.io> wrote:
> 
> I understand your point and it is a valid concern meaning that I can see why it might be nice to be able to configure different ports as you suggest. However, given the current underlying lora stack, the data rate would not remain constant and the application developer would still have to handle a message being sent back if it was too big once the data rate was lowered out from under them.
> 
> Note that adding setting the data rate on a port basis is really an implementation detail of our lora stack. The reference design allows the application developer to set the port and data rate in the McpsRequest, meaning on a per message basis. This got morphed into doing this on a per port basis as access to the reference design's McpsRequest is “hidden” by the current lora api. However, even in the reference design case, the data rate used for that McpsRequest could change.
> 
> I was considering modifying the api such that the data rate was specified in lora_app_port_send() when the application wants to send a frame. However, the data rate could still get changed and to me this makes it not as useful. Furthermore, I still think it will be rare for the application developer to dictate the data rate (but I could be wrong here). Honestly, in most cases I think this adds some extra burden on the app developer to specify a data rate.
> 
> A possible consideration would be to modify the code so that the application developer can specify the data rate on either a per port or per message basis if they desire, and that the message would always be sent at that data rate.
> 
>> On Oct 24, 2017, at 3:56 PM, Christopher Collins <ch...@runtime.io> wrote:
>> 
>> On Tue, Oct 24, 2017 at 01:56:22PM -0700, will sanfilippo wrote:
>>> Hello:
>>> 
>>> I would like to propose some changes to the lora api and I want to see if folks had any comments or issues with the following proposal.
>> 
>> [...]
>> 
>> It sounds reasonable to me.  There is just one thing that stuck out for
>> me:
>> 
>>> 4) Setting the data rate on a per-port basis is just overkill. I cannot imagine the application wanting to change the data rate on a per port basis.
>> 
>> The application likely contains several packages not written by the
>> application developer.  If any of those packages use LoRa, and they have
>> specific data rate requirements, per-port configuration might actually
>> make sense.  If a package needs to send packets of a particular size,
>> for example, then it might have minimum data rate restrictions.  I'm not
>> very familiar with LoRa, so I don't know if this is a valid concern or
>> not.  
>> 
>> Chris
> 

Re: LORA api changes for transmit data rate

[will sanfilippo <wi...@runtime.io>]

I understand your point and it is a valid concern meaning that I can see why it might be nice to be able to configure different ports as you suggest. However, given the current underlying lora stack, the data rate would not remain constant and the application developer would still have to handle a message being sent back if it was too big once the data rate was lowered out from under them.

Note that adding setting the data rate on a port basis is really an implementation detail of our lora stack. The reference design allows the application developer to set the port and data rate in the McpsRequest, meaning on a per message basis. This got morphed into doing this on a per port basis as access to the reference design's McpsRequest is “hidden” by the current lora api. However, even in the reference design case, the data rate used for that McpsRequest could change.

I was considering modifying the api such that the data rate was specified in lora_app_port_send() when the application wants to send a frame. However, the data rate could still get changed and to me this makes it not as useful. Furthermore, I still think it will be rare for the application developer to dictate the data rate (but I could be wrong here). Honestly, in most cases I think this adds some extra burden on the app developer to specify a data rate.

A possible consideration would be to modify the code so that the application developer can specify the data rate on either a per port or per message basis if they desire, and that the message would always be sent at that data rate.

> On Oct 24, 2017, at 3:56 PM, Christopher Collins <ch...@runtime.io> wrote:
> 
> On Tue, Oct 24, 2017 at 01:56:22PM -0700, will sanfilippo wrote:
>> Hello:
>> 
>> I would like to propose some changes to the lora api and I want to see if folks had any comments or issues with the following proposal.
> 
> [...]
> 
> It sounds reasonable to me.  There is just one thing that stuck out for
> me:
> 
>> 4) Setting the data rate on a per-port basis is just overkill. I cannot imagine the application wanting to change the data rate on a per port basis.
> 
> The application likely contains several packages not written by the
> application developer.  If any of those packages use LoRa, and they have
> specific data rate requirements, per-port configuration might actually
> make sense.  If a package needs to send packets of a particular size,
> for example, then it might have minimum data rate restrictions.  I'm not
> very familiar with LoRa, so I don't know if this is a valid concern or
> not.  
> 
> Chris

Re: LORA api changes for transmit data rate

[Christopher Collins <ch...@runtime.io>]

On Tue, Oct 24, 2017 at 01:56:22PM -0700, will sanfilippo wrote:
> Hello:
> 
> I would like to propose some changes to the lora api and I want to see if folks had any comments or issues with the following proposal.

[...]

It sounds reasonable to me.  There is just one thing that stuck out for
me:

> 4) Setting the data rate on a per-port basis is just overkill. I cannot imagine the application wanting to change the data rate on a per port basis.

The application likely contains several packages not written by the
application developer.  If any of those packages use LoRa, and they have
specific data rate requirements, per-port configuration might actually
make sense.  If a package needs to send packets of a particular size,
for example, then it might have minimum data rate restrictions.  I'm not
very familiar with LoRa, so I don't know if this is a valid concern or
not.  

Chris