Class B and Class C Functionalites

#1

Hi Everyone,

Has anyone achieved Class B and C Functionality of LoRaWAN Uptill now ??
Which available gateway supports all LoRaWAN device classes ??

#2

I haven’t seen any device yet that supports B or C. Also, the current TTN testbed does not yet support this.

1 Like
#3

TTN doesn’t even fully support class-A yet

as far as I know the following is still missing:

  • no confirmed sending (yet) meaning that the node gets an acknowledgement from the gateway the packet successfully arrived.
  • no dynamic over the air pairing of nodes (yet), only static (activation by personalization)
  • no sending back data to the node, in class-A each end-device’s uplink transmission is followed by two short downlink receive windows, in which the “network” can send back data to the node, this is not supported yet.

anyway… you can buy any gateway you like, even the D.I.Y. ones, because they all use semtech SX1301 boards … it’s just a matter of updating firmware to get new functionality, so all g/w hardware is OK

2 Likes
#4

Well, Semtech’s reference implementation supports class C devices, and IBM’s LoRaWAN in C partially supports class B devices.

While Microchip’s RN2483 only supports class A devices, there are plenty of modules available that give direct SPI access to the SX1272/SX1276 chip allowing you to run these stacks (or you can just build your own hardware).

As for the server; the loriot.io network server seems to support class C devices, however I have only tested class A devices on that platform.

1 Like
#5

Hello,

It’s been one year already and I was wondering if there has been some progress on the implementation of Class B and C devices. I am particularly interested in implementing a Class B end-device. I don’t know if my inAir9B supports Class B directly or needs a firmware update. Also, where can I find the code for the node (arduino) that implements Class B?

Thanks,

Asier

1 Like
LoraWan Pager project
#6

I don’t think class B and C will be implemented.

See:

#7

We are definitely going to implement Class B and C in our backend, but it’s not sure if we’ll be able to fully support this in the public community network.

#8

Do you consider them as a pair or will class C be implemented separated from (before?) class B?

#9

We intend to implement Class C first.

#10

Why not class C? Because of the risk of air time violations?

#11

Class B require a precise synchronisation across the gateways. As the TTN network is made of various type of GW and not all of them will have access to a reliable time source (GPS receiver), the proper time synchronisation required by Class B will probably not being available.

#12

All gateways with basic packet forwarding abilities should support class C, if the network server enables it (no need for special sync). Class B is something else entirely.

The Multitech gateways with build-in network server support class C.

#13

Does TTN network server supports Class C now?

#14

No. It is still in development.

#15

Does Network Time Protocol could be used to synchronised gateways?

NTP can usually maintain time to within tens of milliseconds over the public Internet,

#16

How many networks could I receive?
How to know if some gateways are in range?
Where are they?

The simple way seem to receive class B beacons.
Does some TTN gateways support class B beaconing?
Does other networks send beacons?

In France, Objenious will support class B in 2018 (Source)
Is there an (official) list of networks providing class B?

If there is no class B gateways, how to detect networks and gateways?

Thanks!

#17

A post was merged into an existing topic: Class C Status

#18