Passive Roaming between 2 Chirpstack NS

Hi everyone,

I am setting up a stateless passive roaming PoC. I’ve almost succeeded but something still goes wrong.

Here is my scenario:
I own 2 Chirpstack NS on 2 different servers, and I have both configured them in a peer-to-peer roaming agreement. To do so, I have read the backend interface and I have followed the Chirpstack NS configuration guidelines available here: Configuration - ChirpStack open-source LoRaWAN<sup>®</sup> Network Server
Elements of my PoC:

  • A Chirpstack NS (server1) that works as fNS. This one has a NetID. (.toml configuration at the end of the post)
  • A Chirpstack NS (server2) works as hNS and sNS. This one has a NetID. (.toml configuration at the end of the post)
  • An ABP end-device registered in the server2. It has already emitted successful uplinks into the server 2 coverage.

What I have done and what I have seen:
My end-device emits frames into the server1 coverage. I should receive the emitted frames into the “LORAWAN FRAMES” section of my server2… but nothing comes.
When my end-device emit a frame, here are the logs I meet on the server1 (I am well aware of the 3-first lines meaning. I am actually wondering about the last one):

chirpstack-network-server_1      | time="2022-06-13T12:22:09.244006575Z" level=info msg="uplink/data: devaddr does not match netid, assuming roaming device" ctx_id=bbfaeb9e-2b79-4fe0-89e7-4ba672568418 dev_addr=041a2b3c
chirpstack-network-server_1      | time="2022-06-13T12:22:09.245126677Z" level=info msg="uplink/data: starting passive-roaming sessions with matching netids" ctx_id=bbfaeb9e-2b79-4fe0-89e7-4ba672568418 dev_addr=041a2b3c
chirpstack-network-server_1      | time="2022-06-13T12:22:09.245861101Z" level=info msg="uplink/data: starting passive-roaming session" ctx_id=bbfaeb9e-2b79-4fe0-89e7-4ba672568418 dev_addr=041a2b3c net_id=000002
chirpstack-network-server_1      | time="2022-06-13T12:22:09.319217632Z" level=error msg="uplink/data: start passive-roaming error" ctx_id=bbfaeb9e-2b79-4fe0-89e7-4ba672568418 dev_addr=041a2b3c error="request error: http post error: Post \"http://ADDRESS_SEVER2:8000\": net/http: HTTP/1.x transport connection broken: malformed HTTP response \"\\x00\\x00\\x06\\x04\\x00\\x00\\x00\\x00\\x00\\x00\\x05\\x00\\x00@\\x00\"" net_id=000002

And on the server2:

chirpstack-network-server_1      | time="2022-06-13T12:22:09.319169137Z" level=warning msg="[core] grpc: Server.Serve failed to create ServerTransport:  connection error: desc = \"transport: http2Server.HandleStreams received bogus greeting from client: \\\"POST / HTTP/1.1\\\\r\\\\nHost: s\\\"\""

Has anyone ever managed to do a passive roaming scenario like the one I am trying to setup?
Is there something wrong in my configuration?

Really appreciate your attention, thank you!
Regards,
.
.
.
.
.

Here is the chirpstack-network-server.toml configuration of the server1 (fNS):

[network_server]
net_id="C00052"
...
[roaming]
  # Resolve NetID domain suffix.
  resolve_netid_domain_suffix=".netids.lora-alliance.org"
  # Per roaming-agreement server configuration.
  [[roaming.servers]]
    # NetID of the roaming server.
    net_id="000002"
    # Use the async API scheme.
    async=true
    # Async request timeout.
    async_timeout="1s" 
    # Allow passive-roaming.
    passive_roaming=true
    # Passive-roaming session lifetime.
    # When set to 0s, the passive-roaming will be stateless.
    passive_roaming_lifetime="0s"
    # Passive-roaming KEK label (optional).
    # When set, the session-keys will be encrypted using the given KEK when these
    # are exchanged.
    # passive_roaming_kek_label=""
    # Server (optional).
    # When set, this will bypass the DNS resolving of the Network Server.
    server="http://ADDRESS_SEVER2:8000"
    # CA certificate (optional).
    # When configured, this is used to validate the server certificate.
    # ca_cert=""
    # TLS client certificate (optional).
    # When configured, this will be used to authenticate the client.
    # This mist be configured together with the tls_key.
    # tls_cert=""
    # TLS key for client certificate (optional).
    # tls_key=""

.
.

Here is the chirpstack-network-server.toml configuration of the server2 (hNS, sNS):

[network_server]
net_id="000002"
….
[roaming]
  # Resolve NetID domain suffix.
  resolve_netid_domain_suffix=".netids.lora-alliance.org"
  # Per roaming-agreement server configuration.
  [[roaming.servers]]
    # NetID of the roaming server.
    net_id="C00052"
    # Use the async API scheme.
    async=true
    # Async request timeout.
    async_timeout="1s"
    # Allow passive-roaming.
    passive_roaming=true
    # Passive-roaming session lifetime.
    # When set to 0s, the passive-roaming will be stateless.
    passive_roaming_lifetime="0s"
    # Passive-roaming KEK label (optional).
    # When set, the session-keys will be encrypted using the given KEK when these
    # are exchanged.
    # passive_roaming_kek_label=""
    # Server (optional).
    # When set, this will bypass the DNS resolving of the Network Server.
    server="http://ADDRESS_SEVER1:8000"
    # CA certificate (optional).
    # When configured, this is used to validate the server certificate.
    # ca_cert=""
  
    # TLS client certificate (optional).
    # When configured, this will be used to authenticate the client.
    # This mist be configured together with the tls_key.
    # tls_cert=""
    # TLS key for client certificate (optional).
    # tls_key=""

You are using the wrong port, port 8000 is the NS gRPC API endpoint. Please see this configuration section:

  # Roaming API settings.
  [roaming.api]
  # Interface to bind the API to (ip:port).
  bind=""

  # CA certificate (optional).
  #
  # When configured, this is used for client-certificate validation.
  ca_cert=""

  # TLS certificate (optional).
  #
  # When configured, this is used to secure the API interface using TLS.
  # This must be configured together with the tls_key.
  tls_cert=""

  # TLS key (optional).
  tls_key=""

You must configure the bind option, e.g. 0.0.0.0:8090 and then use this as server endpoint in the other NS configuration (e.g. server="http://ADDRESS_SERVER1:8090").

Hi @brocaar !

Thank you for your answer.
I have successfully managed my passive roaming PoC.

My team and I work on LoRaWAN Roaming but not only!
I take the liberty to share our work. There is a e-book for beginners and another one dealing with advanced topics (roaming, fuota, etc.). By the way, this PoC of stateless passive roaming is documented in it. All of this is free. Enjoy.
Feel free to check: USMB website

Hope this will help,
Regards,

I succeeded in configuring peer-to-peer passive roaming using ABP activation. However, I’m curious whether it’s feasible to establish passive roaming with OTAA activation. If I intend to implement passive roaming with OTAA activation, do I need a CA certificate, TLS certificate, and TLS key?
@brocaar @Ogui Any help would be very appreciated.

Dear @Jaehoon_Yang ,

I am pleased to see that you have been able to configure a roaming agreement with ABP.

If your end-device is using OTAA, there are two possibilities,

1/ Let’s say your OTAA end-device started its session (Join procedure completed) in its hNS coverage. And then it moved to the fNS coverage. In this situation, the frames emitted in the fNS coverage will be transmitted to the hNS (if a peer-to-peer roaming agreement has been set up accordingly).

2/ Let’s say your OTAA end-device sends its join request in the fNS coverage. A dedicated message flow will then start to make the OTA activation work. I can’t comment on this scenario as I haven’t tested it. But everything is presented in the Backend Interfaces (section 12.2.1)

Then, regarding any TLS configuration, they do not affect the message flows between services. If the connection between your servers allows non-secure communication, it should work as it did in your test with ABP.

Of course, I will leave it to @brocaar to complete or correct any omissions or errors,

Best,

Dear @Ogui,

Thank you very much for your clear explanation. From what I understand, there are two LoRaWAN networks with non-overlapping coverage areas. I’m curious about how passive roaming occurs when the coverage areas of two networks overlap, especially when an end-device approaches a gateway controlled under fNS. In this scenario, does the hNS send the downlink packet via its own gateway or through the fNS’ gateway? Or, does this case only apply to handover roaming?

Best regards,

Hi @Jaehoon_Yang ,
Handover Roaming has never been used so far. So whenever you hear about roaming, it’s all about passive roaming. In that case, it’s called passive as the end-device doesn’t know whether its location is in the hNS or fNS area.
The gateway selected for downlink is supposed to be the one which has received with the best RSSI whatever to where it belongs. There might be some restrictions according to your roaming agreement. While the routing policies are quite clear with packet broker (TTI way of doing roaming), I don’t know if you can easily select the scope of your roaming configuration.