Class B Ping slot frequency mac command PingSlotChannelReq

vitaly · June 1, 2023, 8:25am

Hello,
I have deployed many devices with class B functionality in CN470 band. I use fixed frequency for ping slot, which is 508300000 by setting parameter in network server config file like this

# Ping-slot frequency (Hz)
#
# Set this to 0 to use the default frequency plan for the configured region
# (which could be frequency hopping).
ping_slot_frequency=508300000

The network server sends PingSlotChannelReq to nodes after successfull join.
But if a node falls back to class A and then back to class B, it resets ping slot frequency to default. After that downlinks cannot be received.
Is it possible to make LoRa server send PingSlotChannelReq command to a node every time when it switches from class A to class B? In other words,. downlink PingSlotChannelReq when the uplink class B flag changed to 1
My network server version is chirpstack-network-server316

brocaar · June 3, 2023, 12:10pm

Are you sure this is correct behavior? As far as I know, these settings should remain active until the next activation. Therefore I would propose to fix this issue at the device-side rather than at the server-side.

vitaly · June 5, 2023, 12:45am

@brocaar It seems there is no clear description from LoRa standard. Both undestandings can be correct. It is not feasible for us to update thousands of devices in the field. Can it be implemented at server side as an option?
It would greatly help us.

vitaly · June 5, 2023, 7:46am

I tried to use default ping slot frequency for CN470 but it seems that network server is using wrong frequency.

This is my settings in chirpstack-network-server.toml

 # Class B settings
    [network_server.network_settings.class_b]
    # Ping-slot data-rate.
    ping_slot_dr=2

    # Ping-slot frequency (Hz)
    #
    # Set this to 0 to use the default frequency plan for the configured region
    # (which could be frequency hopping).
    # ping_slot_frequency=508300000
    ping_slot_frequency=0

expected frequency for CN470 is 508.3 to 509.7MHz with 200kHz steps depending on beacon time

image1425×779 76.5 KB
But the network server is sending with different frequency like this

image1044×204 21.8 KB

Am I making mistake? Can anyone help?

brocaar · June 5, 2023, 8:02am

You are looking at the beacon frequencies. Please note that a beacon is not equal to a ping-slot.

Beacons are sent by the gateways every 128 seconds to synchronize the time of the devices. Ping-slots are used by the NS for sending downlink payloads.

vitaly · June 5, 2023, 8:18am

how can i look at ping-slot frequency.?

vitaly · June 5, 2023, 8:44am

when i set ping_slot_frequency=508300000 in config file then i see same in downlink frames

but when i set it to 0, frequency not matching to expected

vitaly · June 5, 2023, 9:17am

I believe I am looking at ping-slots. they are sent when I schedule downlink.
Also, when i set ping_slot_frequency another then 0 they are matching to the ping_slot_frequency

vitaly · June 5, 2023, 9:53am

@brocaar could you tell me what pingslot frequency is used by the networkserver if it is set to 0 (default) for CN470?
thank you

brocaar · June 5, 2023, 10:18am

Please see for the implementation:

github.com

chirpstack/chirpstack/blob/master/lrwn/src/region/cn470.rs#L453


      
          ) -> Result<usize> {
              Ok(uplink_channel % 48)
          }
          
          
fn get_rx1_frequency_for_uplink_frequency(&self, uplink_freq: u32) -> Result<u32> {
              let up_chan = self.get_uplink_channel_index(uplink_freq, false)?;
              let rx1_chan = self.get_rx1_channel_index_for_uplink_channel_index(up_chan)?;
              Ok(self.base.downlink_channels[rx1_chan].frequency)
          }
          
          
fn get_ping_slot_frequency(&self, dev_addr: DevAddr, beacon_time: Duration) -> Result<u32> {
              let down_channel = (u32::from_be_bytes(dev_addr.to_be_bytes()) as usize
                  + (beacon_time.as_secs() / 128) as usize)
                  % 8;
              Ok(self.base.downlink_channels[down_channel].frequency)
          }
          
          
fn get_downlink_tx_power(&self, _freq: u32) -> isize {
              14
          }

To be honest, I’m not sure if this is the correct implementation. The current CN470 implementation is based on the “non-experimental” implementation of the CN470 region. Where for other regions the ping-slot frequencies are defined, this is not the case for the CN470 region I believe, I assumed the same implementation as US915 this this assumption might be wrong.

Later RP002 specifications contain an updated channel-plan which is currently considered experimental:

vitaly · June 5, 2023, 12:24pm

Hello Brocaar.
Thank you for your help.
As I mentioned, I am using networkserver version 3.16, not chirpstack version 4. I believe it’s implementation for CN470 ping_slot_frequency is not the actual one and it does not work with our modules.
But with fixed ping_slot_frequency it does work very well. The only problem is that the module resets ping_slot_frequency to default (hopping) when it falls back to class A and the network server does not send PingSlotChannelReq command when module switches to class B again. Is it possible to make the networkserver send PingSlotChannelReq every time class B is activated?

brocaar · June 5, 2023, 12:50pm

It seems there is no clear description from LoRa standard. Both undestandings can be correct. It is not feasible for us to update thousands of devices in the field. Can it be implemented at server side as an option? It would greatly help us.

On which LoRaWAN implementation are your devices based?

I still think the issue is at the device implementation. The behavior you describe is that once the device changes its ClassB bit in the uplink (Class-A to Class-B and / or from Class-B to Class-A), that it flushes the state of the PingSlotChannelReq parameters. This would be problematic also because the LoRaWAN specs do not state that this mac-command can only be used when the device is in Class-B mode. I believe that ChirpStack sends this mac-command to Class-B capable devices even if the device hasn’t switched to Class-B yet (e.g. it is still syncing on the beacons).

I understand that in your case this is problematic as you already have many devices deployed, but if this is an issue in your device firmware then I would like to avoid having a fix for this in the open-source code as it might negatively affect devices that do not have the same behavior. In that case please reach out to me in private so that we can discuss this further.