LoRaWan MAC version 1.0.3

julien · August 6, 2018, 5:08pm

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.

brocaar · August 6, 2018, 8:32pm

Yes, it will be added to the next release

julien · August 6, 2018, 8:41pm

TiTop, super hard worker as usual thank you…

Nicolasr · September 30, 2018, 11:56am

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

brocaar · October 1, 2018, 7:52am

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

Nicolasr · October 1, 2018, 8:54am

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

Martijn_The · October 4, 2018, 2:32pm

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

brocaar · October 5, 2018, 9:03am

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

Martijn_The · October 16, 2018, 7:31am

@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?

brocaar · October 16, 2018, 1:59pm

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.

Martijn_The · October 19, 2018, 7:40pm

@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:

github.com

brocaar/chirpstack-network-server/blob/8329230e2116e1d661651bec2241ac40c3f3d8cb/internal/maccommand/maccommand.go#L25


	case lorawan.LinkADRAns:
		return handleLinkADRAns(ds, block, pending)
	case lorawan.LinkCheckReq:
		return handleLinkCheckReq(ds, rxPacket)
	case lorawan.DevStatusAns:
		return handleDevStatusAns(ds, sp, asClient, block)
	case lorawan.PingSlotInfoReq:
		return handlePingSlotInfoReq(ds, block)
	case lorawan.PingSlotChannelAns:
		return handlePingSlotChannelAns(ds, block, pending)
	case lorawan.DeviceTimeReq:
		return handleDeviceTimeReq(ds, rxPacket)
	case lorawan.NewChannelAns:
		return handleNewChannelAns(ds, block, pending)
	case lorawan.RXParamSetupAns:
		return handleRXParamSetupAns(ds, block, pending)
	case lorawan.RXTimingSetupAns:
		return handleRXTimingSetupAns(ds, block, pending)
	case lorawan.RekeyInd:
		return handleRekeyInd(ds, block)
	case lorawan.ResetInd:

Is this also what you were talking about?

Martijn_The · October 19, 2018, 7:54pm

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!

brocaar · October 21, 2018, 12:55pm

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).

Martijn_The · January 30, 2019, 3:35pm

@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!

brocaar · February 3, 2019, 4:53pm

Not yet, but I think I will release it soon

Achuthan_Param · January 7, 2020, 10:15am

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

brocaar · January 7, 2020, 3:18pm

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