Skip to content
By using AWS re:Post, you agree to the AWS re:Post Terms of Use
AWS re:Postre:Post
About re:Post

Class C Join Accept Message Behavior

0

I have a device running LoRa Basics Modem and a gateway running LoRa Basics station. I am classifying the device as Class C in my device profile, as I set it to class C upon a successful join in my firmware. However, as of this week, my device was unable to join. I saw the join accept messages come down, but they were sent too soon for the RX1 window (5 seconds after TX) to get them. My gateway does not seem to be delaying them by the specified 5 seconds and instead sends them immediately, seemingly due to these join accept messages being labelled as dC 2 (class C). When I change the device profile to class A, it works correctly and the gateway delays it by the appropriate 5 seconds.

My question is should join accept messages be marked as Class C? It seems to be making my gateway ignore the RxDelay number and send them immediately. Or is this a gateway firmware issue? This just started for me this week, as I had no issue with joining when my device was set to Class C before.

Thanks!

Topics
Internet of Things (IoT)
Tags
AWS IoT Core
Language
English

asked 2 years ago335 views

2 Answers
1

I can confirm I am seeing the same issue. The issue seems to only be occoring when using Gateways from Tekelic. I have also raised a support case with AWS - 174142772300264

When using Gateways from RAK Wireless or Microtik I can confirm that Class C devices join as expected. However the logs show that for the Tekelic devices AWS is mishandling the joins.

answered 2 years ago

  • wick
    2 years ago

    @fabltd Glad someone else was able to reproduce! Can I ask if you've received a response from AWS acknowledging the issue/planning to resolve it?

-1

The behavior you're experiencing with Class C Join Accept messages is not typical and may indicate an issue with either your gateway configuration or a recent change in firmware.

Join Accept messages should generally follow the same timing rules regardless of the device class. For Class A devices (which all devices effectively are during the join procedure), there should be a delay before sending the Join Accept message to ensure it falls within the RX1 or RX2 receive windows of the device.

The fact that setting the device profile to Class A resolves the issue suggests that there might be a misinterpretation of the device class during the join procedure. Normally, a device starts in Class A mode and only switches to Class C after a successful join and explicit configuration change.

It's unusual for Join Accept messages to be marked as Class C (dC 2) during the joining process. This labeling might be causing your gateway to treat these messages differently, ignoring the RxDelay and sending them immediately.

This behavior could be due to:

  1. A recent firmware update on your gateway that has changed how it handles Join Accept messages for devices profiled as Class C.
  2. A configuration issue in your device profile or gateway settings that is causing premature classification of join messages as Class C.
  3. A potential bug in the LoRa Basics station software running on your gateway.

To troubleshoot this issue:

  1. Check if there have been any recent updates to your gateway firmware or LoRa Basics station software.
  2. Review your device profile settings to ensure they are correct and not causing any unexpected behavior during the join process.
  3. Verify that your gateway is correctly configured to respect the RxDelay for join procedures, regardless of the ultimate device class.
  4. Consider temporarily setting your device to start in Class A mode, perform the join, and then switch to Class C after a successful join.

If the problem persists, you may need to contact the support team for your gateway or LoRa Basics station software to report this as a potential bug or to get more specific guidance on your configuration.

Remember, the join procedure should typically follow Class A timing regardless of the final intended device class, so the behavior you're seeing is not standard and warrants further investigation.
Sources
AWS LoRaWan Class C Downlink Delay | AWS re:Post
Managing devices with AWS IoT Core for LoRaWAN - AWS IoT Wireless
ERROR when sending downlink to class A devices | AWS re:Post

answered 2 years ago

AWS
EXPERT

reviewed 2 years ago

  • wick
    2 years ago

    There have been no recent updates to my gateway, as it is my gateway for internal use. Everything was working late last week with no changes to device firmware or gateway firmware. I didn't look at the device classification indicator when things were working, so I cannot confirm that join accept packets were being labelled as Class A, but it seems that the AWS IoT LNS is the only thing I can't confirm stayed the same. Is it possible that a recent change resulted in AWS labeling join-accept messages as Class C?

    The gateway has no visibility into what classification the device is, so something in the downlink from AWS is resulting in it interpreting the join-accept message as Class C (when the device's profile is set to Class C). A change of the device's profile to Class A results in a class A join-accept message.

  • wick
    2 years ago

    Tektelic support has confirmed they see the same thing that I do, that when a device profile is set to Class C, join-accept messages from AWS IoT are marked as class C messages and are sent immediately by the gateway, missing the RX window. The same does not occur with TTN.

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Relevant content