LoRaWan MAC version 1.0.3

Hello @brocaar in the next release of loraserver do you plan to implement the LoRaWan MAC version 1.0.3 ?

No special need in the moment it’s just to be up to date with the software release of my devices wich is covered with this lorawan MAC version.

https://www.st.com/content/st_com/en/about/media-center/press-item.html/n4075.html

Thank you.

Yes, it will be added to the next release :slight_smile:

1 Like

TiTop, super hard worker as usual thank you…

Hello Guys,

I have one additional question regarding devices based on 1.0.3 release.

Some of my devices will have to be working with a loraserver suite implementing only 1.0.2 (loraserver v0.25.1 and lora-app-server v0.19.0)… The thing is that this suite can’t be upgraded to last versions… since it does not have internet access.

Do you think that devices working with classA working on 1.0.3 might work?

Thanks a lot

This should not be an issue as Class A was not changed. I believe the changes were mostly Class-B related.

Yes, except for some additional MAC commands that have been implemented, I thought two it would work… But an expert confirmation is always welcome!
Thanks

Any plans to support the new (v1.0.3) DeviceTime commands to support time-syncing of RTCs in LoRa node devices with the server’s time?

Thanks

It is already supported since LoRa Server 0.25.0 when Class-B support was added :wink: (you do need a gateway with GPS for this!)

@brocaar GPS? Why is that needed for DeviceTime syncing?

EDIT: Reading the spec now. I guess it’s because GPS is a pretty accurate source of current time and the spec demands ±100ms accuracy? What If I’m OK with less accuracy? Any way to replace GPS as time source with some other time source?

In case you are OK with less accuracy, you would need to change the packet-forwarder so that it includes the GPS time on uplink: https://github.com/Lora-net/packet_forwarder/blob/master/PROTOCOL.TXT#L134.

1 Like

@brocaar after reading your message more carefully, I think that you may be talking about a different thing.

With DeviceTime syncing I meant the DeviceTimeReq and DeviceTimeAns MAC commands that were added in the LoRaWAN v1.0.3 spec:


(From https://lora-alliance.org/sites/default/files/2018-06/lorawan1.0.3_final_0.pdf)

Searching through the code it looks like it’s supported:

Is this also what you were talking about?

Aaaah… after reading the implementation of handleDeviceTimeReq it all makes sense.
The loraserver just echoes back the GPS time that the DeviceTimeReq (uplink) message was received by the gateway. Hence your comment about that the packet forwarder needs to include the GPS time on uplink. Thanks!

:slight_smile: Yes, that is correct. Please note that depending your setup there might quite some latency between the network-server and gateway (e.g. when it uses a cellular network). So the only accurate timestamp to use for this mac-command is the RX GPS time forwarded by the gateway (as for Class-B it is important that the timestamp is accurate, also note that the timestamp is expected to be the in GPS epoch time thus no leapseconds).

@brocaar I noticed you added a fallback (still on master) to send the NS time in case no GPS time and no “time” value is present in the frame. Thanks for that! Any ETA for the next release that will include this change? Thanks!

Not yet, but I think I will release it soon :slight_smile:

Hi
I still dont see any DeviceTimeAns from th eserver is this feature included in the new release ?

Yes, see for the source: https://github.com/brocaar/chirpstack-network-server/blob/master/internal/maccommand/device_time.go#L18.