search

helium / router

router combines a LoRaWAN Network Server with an API for console, and provides a proxy to the Helium blockchain
Apache License 2.0
69 stars 32 forks source link

LoRaWAN Class-C device support on Helium #642

Closed pdvaneijk closed 2 years ago

pdvaneijk commented 2 years ago

Class-C LoRaWAN devices are an important devices class in addition to the currently supported Class-A devices that are battery powered devices. Class-C devices are typically characterized as "main powered", ie always on devices. These can be devices in street lights, electric meters, HVAC monitoring devices or even 24V powered thermostats. While Class-A devices only have 2 defined receive windows (RX1 and RX2) during which the end device will listen for an downlink from a nearby gateway, Class-C devices have a third type of parameter called RXC, which is in essence a window that is always open except during transmit of an uplink or during RX1 and RX2. RXC has typically a different DL channel and DR setting that RX1 and RX2. There is another important use case for Class-C and that is FUOTA (Firmware Over the Air Update). The idea is that Class-A device can, for a predefined time, be configured as Class-C devices to receive a bunch of downlinks that can be reassembled into a new FW image. While FUOTA needs to be implemented on the application layer, Multicast FUOTA is the most effective but needs to be supported by the LNS. The first step to make this happen is to be able to support Class-C devices. So not only do the RXC DR/channel parameters have to be defined, but if a DL is queued up, the Router needs to be smart enough to realize that the connected device is a Class-C device and transmit a DL asap after a device uplink, or in between RX1 or RX2, or if RX2 has already passed, but definitely NOT wait for the next RX1/RX2 window after the next Uplink. Since there is not a 400ms dwell time limitation on 500Khz channels, the idea behind MC FUOTA is that you put your in Class-C mode for a short period of time and send a whole bunch of consecutive DLs, which of course is not possible with Class-A devices. The packets have built in parity so that you only need to receive say 60% of all the packets in order to re-assemble the new FW image.

pvolodin commented 2 years ago

@pdvaneijk

It would be great to have class C support, BUT...

Class-C devices have a third type of parameter called RXC, which is in essence a window that is always open except during transmit of an uplink or during RX1 and RX2.

RXC was introduced in LoRaWAN 1.0.4, right? Do you think there's a lot of 1.0.4 devices on the market?

RXC has typically a different DL channel and DR setting that RX1 and RX2.

From the spec:

The RXC window parameters differ, depending on whether the Class C functionality is used to receive unicast or multicast downlinks:  Unicast: The RXC parameters are identical to the RX2 parameters, and they use the same channel and data rate. Modifying the RX2 parameters using the appropriate MAC commands also modifies the RXC parameters.  Multicast: The RXC parameters are provided by the application layer. All end-devices in the multicast group SHALL share the same RXC parameters. If the multicast RXC parameters are different from the end-device’s RX2 parameters, then the end-device is not able to listen simultaneously to multicast and unicast downlink. In that case, the decision whether the end-device should use unicast or multicast RXC parameters is application-specific. If the multicast RXC parameters provided by the application layer match the current RX2 parameters of the end-device, then the end-device receives both unicast and multicast traffic during the RXC windows

So, in unicast mode RXC parameters are same as RX2 parameters (to not break compatibility with older versions of the spec), and I don't think we can say the devices typically shall be in multicast mode.

Regarding FUOTA - you hardly can implement FUOTA Process Summary Technical Recommendation TR002 v1.0.0 or something similar using the Helium network where most of the hotspots don't seem to be equipped with GPS which is required for Application Layer Clock Synchronization or DeviceTimeReq MAC command support.

Oliv4945 commented 2 years ago

Hi @pvolodin,

RXC was introduced in LoRaWAN 1.0.4, right?

Yes but class C was already existing in 1.0.2. The application knows the devices it will use for the multicast session, so it can set RXC=RX2 if devices with a 1.0.2 or 1.0.3 are involved

where most of the hotspots don't seem to be equipped with GPS which is required for Application Layer Clock Synchronization or DeviceTimeReq MAC command support.

That is not true, while having a GPS chip in the gateway will improve accuracy, those commands can work with gateway using an NTP based clock source or a gateways based on Basic Station (which is not used in Helium network)

pvolodin commented 2 years ago

@Oliv4945

Yes but class C was already existing in 1.0.2.

It was existing even in LoRaMAC (i.e. pre-LoRaWAN 1.0.0) spec, that's why I mentioned compatibility with older version and so on.

so it can set RXC=RX2 if devices with a 1.0.2 or 1.0.3 are involved

Surely, that's my point, actually there's more than one task: first, support the "classic" class C. and then support 1.0.4 extensions to class C. Sorry for not being clear enough.

those commands can work with gateway using an NTP based clock source

They can try to do that. In non-ideal conditions, it can be hard to impossible to reach the accuracy needed when we're talking about LoRaWAN 1.0.3 devices/DeviceTimeReq command.

jdgemm commented 2 years ago

Class-C LoRaWAN devices are an important devices class in addition to the currently supported Class-A devices that are battery powered devices. Class-C devices are typically characterized as "main powered", ie always on devices. These can be devices in street lights, electric meters, HVAC monitoring devices or even 24V powered thermostats. While Class-A devices only have 2 defined receive windows (RX1 and RX2) during which the end device will listen for an downlink from a nearby gateway, Class-C devices have a third type of parameter called RXC, which is in essence a window that is always open except during transmit of an uplink or during RX1 and RX2. RXC has typically a different DL channel and DR setting that RX1 and RX2. There is another important use case for Class-C and that is FUOTA (Firmware Over the Air Update). The idea is that Class-A device can, for a predefined time, be configured as Class-C devices to receive a bunch of downlinks that can be reassembled into a new FW image. While FUOTA needs to be implemented on the application layer, Multicast FUOTA is the most effective but needs to be supported by the LNS. The first step to make this happen is to be able to support Class-C devices. So not only do the RXC DR/channel parameters have to be defined, but if a DL is queued up, the Router needs to be smart enough to realize that the connected device is a Class-C device and transmit a DL asap after a device uplink, or in between RX1 or RX2, or if RX2 has already passed, but definitely NOT wait for the next RX1/RX2 window after the next Uplink. Since there is not a 400ms dwell time limitation on 500Khz channels, the idea behind MC FUOTA is that you put your in Class-C mode for a short period of time and send a whole bunch of consecutive DLs, which of course is not possible with Class-A devices. The packets have built in parity so that you only need to receive say 60% of all the packets in order to re-assemble the new FW image.

Thanks for taking the time to write this issue and provide additional context behind the description for class c devices.

We are focused on ensuring class a devices are operating well/rock solid before moving on to add support for class c. What type of class devices do you specifically plan on deploying?

pdvaneijk commented 2 years ago

Hi Dal,

I fully understand and agree that Class-A needs to be Rock solid first. But Class-C is an important device class. This includes street light controllers, connected outlets and switches, electric meters. For example I am working with one particular company that has a 24V connected device that monitors AC unit performance and sits in between an AC unit and a Thermostat; these folks are talking about 100,000s of devices. I am sure there are many other applications. The below write-up comes from one of our customers asking for Class C support on Helium (just as an example):

The essential use cases for class C is for timely control (e.g. to turn things on and off without delay). We have LoRaWAN switched outlets and switches, which wait for a command from the network to turn on/off. Typically in a Class C configuration, this will happen in less than 3 seconds. There is no practical way for class A device to do this as it would require the device to uplink once a second to query for a downlink. It just won’t scale, overwhelming the network.

I believe Class C support requires the network to forward messages for downlink to the last reported gateway(s). Right now we can tell in the Helium Console that the network is waiting for an uplink from the device before sending the downlink message onto the gateway. That is not our experience with other Lora WAN networks supporting class C devices.

So this goes back to the mission statement for Helium, is it a sensor telemetry network only (Class A) or is it for systems control (Class C)? Seems to me that it will cut off a huge portion of the market not to support control use cases. It is important for our future business plans with Helium; otherwise we will have to focus on other networks. The ability to control things at a long distance in a responsive manner is an important capability.

Best Regards,

Patrick

From: Dal @.> Sent: Monday, March 7, 2022 4:49 PM To: helium/router @.> Cc: Patrick van Eijk @.>; Mention @.> Subject: [SPAM:] Re: [helium/router] LoRaWAN Class-C device support on Helium (Issue #642)

Warning - External Email

Class-C LoRaWAN devices are an important devices class in addition to the currently supported Class-A devices that are battery powered devices. Class-C devices are typically characterized as "main powered", ie always on devices. These can be devices in street lights, electric meters, HVAC monitoring devices or even 24V powered thermostats. While Class-A devices only have 2 defined receive windows (RX1 and RX2) during which the end device will listen for an downlink from a nearby gateway, Class-C devices have a third type of parameter called RXC, which is in essence a window that is always open except during transmit of an uplink or during RX1 and RX2. RXC has typically a different DL channel and DR setting that RX1 and RX2. There is another important use case for Class-C and that is FUOTA (Firmware Over the Air Update). The idea is that Class-A device can, for a predefined time, be configured as Class-C devices to receive a bunch of downlinks that can be reassembled into a new FW image. While FUOTA needs to be implemented on the application layer, Multicast FUOTA is the most effective but needs to be supported by the LNS. The first step to make this happen is to be able to support Class-C devices. So not only do the RXC DR/channel parameters have to be defined, but if a DL is queued up, the Router needs to be smart enough to realize that the connected device is a Class-C device and transmit a DL asap after a device uplink, or in between RX1 or RX2, or if RX2 has already passed, but definitely NOT wait for the next RX1/RX2 window after the next Uplink. Since there is not a 400ms dwell time limitation on 500Khz channels, the idea behind MC FUOTA is that you put your in Class-C mode for a short period of time and send a whole bunch of consecutive DLs, which of course is not possible with Class-A devices. The packets have built in parity so that you only need to receive say 60% of all the packets in order to re-assemble the new FW image.

Thanks for taking the time to write this issue and provide additional context behind the description for class c devices.

We are focused on ensuring class a devices are operating well/rock solid before moving on to add support for class c. What type of class devices do you specifically plan on deploying?

— Reply to this email directly, view it on GitHubhttps://github.com/helium/router/issues/642#issuecomment-1061292952, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AUHSXOAICKEUQTTU2ZMWX4DU62PZBANCNFSM5P67KVKA. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you were mentioned.Message ID: @.**@.>>

To view our privacy policy, including the types of personal information we collect, process and share, and the rights and options you have in this respect, see www.semtech.com/legal.

jdgemm commented 2 years ago

hi Patrick,

Thanks for the additional context. Definitely agree there's use cases that only class c support it's, like many things in life, a question of priority. As you can imagine we often hear prospects mention they will deploy "100,000's" of devices if only (insert magical blank).

That's why I'd like to set up a call to discuss the urgency you're seeing around class c devices and would appreciate any help quantifying the "huge portion of the market" that requires class c devices (email sent). Because quite frankly we're not seeing it which is the reason it hasn't been a priority.

pdvaneijk commented 2 years ago

Hello – Almost any control related command within a smart home would benefit greatly from Class C. When you think about turning on a light or activating a smart plug or controlling a garage door you are a) dealing with a powered device and b) dealing with something where users expect “immediate” feedback. That sort of latency, or predictability, is not achievable with Class A. Since a lot of Helium hotspots are inside of homes, these types of applications are natural uses for the network.

From: Patrick van Eijk @.> Sent: Monday, March 7, 2022 7:57 PM To: helium/router @.> Cc: Mention @.>; Olivier Gimenez @.>; Byron BeMiller @.>; Richard Lansdowne @.>; helium/router @.***> Subject: RE: [SPAM:] Re: [helium/router] LoRaWAN Class-C device support on Helium (Issue #642)

Hi Dal,

I fully understand and agree that Class-A needs to be Rock solid first. But Class-C is an important device class. This includes street light controllers, connected outlets and switches, electric meters. For example I am working with one particular company that has a 24V connected device that monitors AC unit performance and sits in between an AC unit and a Thermostat; these folks are talking about 100,000s of devices. I am sure there are many other applications. The below write-up comes from one of our customers asking for Class C support on Helium (just as an example):

The essential use cases for class C is for timely control (e.g. to turn things on and off without delay). We have LoRaWAN switched outlets and switches, which wait for a command from the network to turn on/off. Typically in a Class C configuration, this will happen in less than 3 seconds. There is no practical way for class A device to do this as it would require the device to uplink once a second to query for a downlink. It just won’t scale, overwhelming the network.

I believe Class C support requires the network to forward messages for downlink to the last reported gateway(s). Right now we can tell in the Helium Console that the network is waiting for an uplink from the device before sending the downlink message onto the gateway. That is not our experience with other Lora WAN networks supporting class C devices.

So this goes back to the mission statement for Helium, is it a sensor telemetry network only (Class A) or is it for systems control (Class C)? Seems to me that it will cut off a huge portion of the market not to support control use cases. It is important for our future business plans with Helium; otherwise we will have to focus on other networks. The ability to control things at a long distance in a responsive manner is an important capability.

Best Regards,

Patrick

From: Dal @.**@.>> Sent: Monday, March 7, 2022 4:49 PM To: helium/router @.**@.>> Cc: Patrick van Eijk @.**@.>>; Mention @.**@.>> Subject: [SPAM:] Re: [helium/router] LoRaWAN Class-C device support on Helium (Issue #642)

Warning - External Email

Class-C LoRaWAN devices are an important devices class in addition to the currently supported Class-A devices that are battery powered devices. Class-C devices are typically characterized as "main powered", ie always on devices. These can be devices in street lights, electric meters, HVAC monitoring devices or even 24V powered thermostats. While Class-A devices only have 2 defined receive windows (RX1 and RX2) during which the end device will listen for an downlink from a nearby gateway, Class-C devices have a third type of parameter called RXC, which is in essence a window that is always open except during transmit of an uplink or during RX1 and RX2. RXC has typically a different DL channel and DR setting that RX1 and RX2. There is another important use case for Class-C and that is FUOTA (Firmware Over the Air Update). The idea is that Class-A device can, for a predefined time, be configured as Class-C devices to receive a bunch of downlinks that can be reassembled into a new FW image. While FUOTA needs to be implemented on the application layer, Multicast FUOTA is the most effective but needs to be supported by the LNS. The first step to make this happen is to be able to support Class-C devices. So not only do the RXC DR/channel parameters have to be defined, but if a DL is queued up, the Router needs to be smart enough to realize that the connected device is a Class-C device and transmit a DL asap after a device uplink, or in between RX1 or RX2, or if RX2 has already passed, but definitely NOT wait for the next RX1/RX2 window after the next Uplink. Since there is not a 400ms dwell time limitation on 500Khz channels, the idea behind MC FUOTA is that you put your in Class-C mode for a short period of time and send a whole bunch of consecutive DLs, which of course is not possible with Class-A devices. The packets have built in parity so that you only need to receive say 60% of all the packets in order to re-assemble the new FW image.

Thanks for taking the time to write this issue and provide additional context behind the description for class c devices.

We are focused on ensuring class a devices are operating well/rock solid before moving on to add support for class c. What type of class devices do you specifically plan on deploying?

— Reply to this email directly, view it on GitHubhttps://github.com/helium/router/issues/642#issuecomment-1061292952, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AUHSXOAICKEUQTTU2ZMWX4DU62PZBANCNFSM5P67KVKA. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you were mentioned.Message ID: @.**@.>>

To view our privacy policy, including the types of personal information we collect, process and share, and the rights and options you have in this respect, see www.semtech.com/legal.

jdgemm commented 2 years ago

Definitely seems like a big opportunity for a manufacturer to come up with a killer app for Hotspot owners. Up until now seems that smart home devices are primarily using wi-fi. Can you share any data on the number or the type smart home device manufacturers using or planning to use lora vs. wi-fi?

pdvaneijk commented 2 years ago

Dal,

Do you have time this Thursday for a zoom call with the CEO and VP of BD from a company called www.codepoint.xyzhttp://www.codepoint.xyz ? They want to give you some more insight into Class C and the market for these devices. They work closely with this company called www.yosmart.comhttp://www.yosmart.com who has a large catalog of LoRa devices that they initially connected with their own protocol on top of LoRa, often because of a lack of Class-C support.

Best Regards,

Patrick

From: Dal @.> Sent: Tuesday, March 8, 2022 9:52 AM To: helium/router @.> Cc: Patrick van Eijk @.>; Mention @.> Subject: [SPAM:] Re: [helium/router] LoRaWAN Class-C device support on Helium (Issue #642)

Warning - External Email

Definitely seems like a big opportunity for a manufacturer to come up with a killer app for Hotspot owners. Up until now seems that smart home devices are primarily using wi-fi. Can you share any data on the number or the type smart home device manufacturers using or planning to use lora vs. wi-fi?

— Reply to this email directly, view it on GitHubhttps://github.com/helium/router/issues/642#issuecomment-1062045027, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AUHSXOHZ6XMSKTBRTHG7LALU66HS5ANCNFSM5P67KVKA. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you were mentioned.Message ID: @.**@.>>

To view our privacy policy, including the types of personal information we collect, process and share, and the rights and options you have in this respect, see www.semtech.com/legal.

jdgemm commented 2 years ago

Yes please, probably makes sense to continue the discussion over email, and pls cc Mark P. Thanks!

pvolodin commented 2 years ago

@pdvaneijk

We have LoRaWAN switched outlets and switches, which wait for a command from the network to turn on/off. Typically in a Class C configuration, this will happen in less than 3 seconds.

With Helium it can be 4+ seconds. Please see, for instance, #617 and #531. RECEIVE_DELAY1 was increased not without a reason.

@jdgemm

We are focused on ensuring class a devices are operating well/rock solid before moving on to add support for class c.

BTW, does the Helium's imlementation of roaming functionality currently support the class C devices belonging to other (Senet etc.) networks? In other words, assuming we use the method described in https://docs.helium.com/lorawan-on-helium/lorawan-roaming-on-helium/ , will a Semtech GWMP PULL_RESP packet with "imme" fiels inside JSON set to "true" be properly processed?

Oliv4945 commented 2 years ago

We have LoRaWAN switched outlets and switches, which wait for a command from the network to turn on/off. Typically in a Class C configuration, this will happen in less than 3 seconds.

With Helium it can be 4+ seconds. Please see, for instance, #617 and #531. RECEIVE_DELAY1 was increased not without a reason.

In class C a device is in RX2/RXC state when it is not doing class A tasks (TX,RX1,RX2) so RxDelay does not have any influence on class c latency.

pvolodin commented 2 years ago

@Oliv4945

In class C a device is in RX2/RXC state when it is not doing class A tasks (TX,RX1,RX2) so RxDelay does not have any influence on class c latency.

Thanks, but this doesn't mean there's no latency (which any blockchain carries with it) in hotspot<->router channel, which was the reason to increase RECEIVE_DELAY1.

leogaggl commented 2 years ago

Is there any roadmap on the Class-C support with the Helium router?

There are a number of Class-C devices we are currently not able to use. Some kind of feedback if this is working it's way through the engineering pipeline or will never happen with the current focus moving to 5G?

Some feedback to manage expectations would be very helpful for us out there that are trying to deploy devices. Keep up the great work!