Device Time

A LoRaWAN device asks the network for the current time with the DeviceTimeReq MAC command (CID 0x0D) to set its clock. ONS answers every such request with the DeviceTimeAns command. There is no setting that turns the answer on or off: the server checks neither the device settings nor the LoRaWAN version.

How ONS responds

0.3–0.6 seconds after receiving an uplink, the server parses its MAC commands and finds 0x0D among them. It looks for commands in the FOpts field if FPort is greater than 0 or absent (a frame with MAC commands only), and in FRMPayload if FPort = 0. The request has no payload: it is a single CID byte.
The server takes the current UTC time from its own clock and counts the seconds since the start of the GPS epoch — January 6, 1980, 00:00:00 UTC.
The server queues DeviceTimeAns in the device's MAC command queue. If an unsent DeviceTimeAns is still waiting there, the server removes it and queues a new one.
Right after parsing the MAC commands, the server builds a downlink frame: a non-empty MAC command queue is enough for that, even if there is no application data for the device. The frame goes out in the RX1 or RX2 receive window of the same uplink, with the transmission moment counted on the counter of the gateway that received the uplink:
- no application data — a frame with FPort 0, MAC commands in FRMPayload, encrypted with the NwkSKey key;
- application data present — MAC commands in the FOpts field of that frame.

If RX1 can no longer be reached, the server sends the frame in RX2. For a class C device, the server also schedules the reply to an uplink, DeviceTimeAns included, in RX1 or RX2 by default. The frame goes out immediately, without being tied to a window, only if the window can no longer be reached, if a gateway other than the one that received the uplink is set for the frame, or if the server runs with the --classc_uplink_imme 1 parameter.

DeviceTimeAns format

The answer is 6 bytes long:

Byte	Field	Value
0	CID	`0x0D`
1–4	Seconds	Whole seconds since the start of the GPS epoch, uint32, little-endian (least significant byte first)
5	Fraction of a second	uint8, in units of 1/256 second

Example. The server took the time October 9, 2026, 12:00:00.25 UTC:

seconds since the start of the GPS epoch — 1,475,582,400, in hex 0x57F399C0, in little-endian — C0 99 F3 57;
fraction of a second — 0.25 × 256 = 64, in hex 0x40;
DeviceTimeAns — 0DC099F35740.

To convert an ONS value to Unix time, add 315,964,800 — the number of seconds between January 1, 1970 and January 6, 1980. In the example, 1,475,582,400 + 315,964,800 = 1,791,547,200, which is 2026-10-09 12:00:00 UTC.

GPS epoch and leap seconds

ONS counts the seconds as the calendar difference between the current UTC time and January 6, 1980, 00:00:00 UTC. The server adds no leap seconds. True GPS time is ahead of UTC by 18 leap seconds, so the ONS value is 18 seconds less than the true number of GPS seconds.

Warning

A device whose firmware derives UTC from the answer by subtracting leap seconds will be 18 seconds behind UTC on ONS. OrionM2M devices do not subtract leap seconds, so on ONS their clocks run on UTC.

Accuracy

The fraction step is 1/256 second, about 3.9 ms. The fraction is truncated, not rounded.
The time comes from the ONS server clock. Gateway timestamps (tmst and time from the gateway packet) are not used for the answer.
The time is taken when the MAC commands are parsed, not at the moment the uplink transmission ends on air: 0.6 seconds minus half the gateway RTT after the server received the uplink, plus processing time. At most 0.3 seconds is subtracted, so the stamp falls 0.3–0.6 seconds after the uplink was received. The gateway RTT is the time from sending a downlink frame to the gateway until the gateway's TX_ACK, smoothed with an exponential moving average with a coefficient of 0.3. If latency is the same in both directions and half the RTT is no more than 0.3 seconds, the stamp corresponds to about 0.6 seconds after the gateway forwarded the uplink to the server.
The value is computed once and does not change afterwards. The wait until the RX1 or RX2 window is not added to it. If the gateway refuses to transmit the frame in RX1 with the error TOO_EARLY, TOO_LATE, COLLISION_PACKET or COLLISION_BEACON, the server by default (the --rx2_retry parameter) resends the frame in RX2 — if the RX2 window can still be reached and the frame fits into it. The resend carries the same bytes and the same time. In all other cases the frame is not sent, and the answer has already left the queue.
An answer that does not fit into the frame stays in the queue and leaves with the next downlink — with the time taken when it was queued. MAC commands in FOpts take fewer than 30 hex characters (at most 14 bytes), in FRMPayload with FPort 0 — fewer than 51 (at most 25 bytes). The queue is taken from the head up to the first command that does not fit.

When there is no answer

Situation	What happens
The device settings specify class B	The server takes the answer from the queue into the frame but does not send the frame: ONS does not support class B
DeviceTimeReq arrived in a repeat of a frame with the same FCnt less than 30 seconds after the previous reception — the same transmission through another gateway or a retransmission by the device	The server does not parse the MAC commands of the repeat and builds no new answer. A frame with the same FCnt that arrives 30 seconds or more later is processed as a new one, and the request is answered
A MAC command unknown to ONS precedes 0x0D in the same frame	At an unknown CID the server stops parsing the frame, and DeviceTimeReq is never processed. In an uplink the server parses CIDs 0x02–0x0A and 0x0D
The frame with the answer did not reach the device	The answer leaves the queue in a frame only once. The device has to request the time again

How to check

The request in uplink data. The fopts field in the realtime_data message (consume_req) and in get_data_req packets contains the MAC commands from FOpts in hex. A DeviceTimeReq sent in FOpts shows up there as the byte 0D.
The request in the web interface. The Nodes section, the node card, the "Monitoring" tab, the "Data" table, the "MAC" column. The column shows the FOpts contents, and for frames with FPort 0 — the frame data. See the tab description.
The answer. In the same "Data" table the answer shows in the Downlink row of the frame sent after the uplink with the request: the "MAC" column holds the byte 0D followed by the 5 bytes of the answer, e.g. 0DC099F35740. For a frame without application data (FPort 0) this is the frame data, for a frame with application data it is FOpts. The DeviceTimeReq and DeviceTimeAns exchange does not appear in the "MAC command log": the server does not write it there, even though the log filter lists the DeviceTime type (CID 13). The server also writes the answer time to its own operation log as a line "Device time request for …".

OrionM2M devices

The firmware of OrionM2M devices requests the time when the clock needs updating:

the clock has never been corrected over the network;
7 days have passed since the last correction;
after a cold boot in which the device restored the last saved time: the firmware marks the time as incorrect and requests it at the first opportunity.

The firmware adds DeviceTimeReq only to an uplink with application data on FPort 2. While the clock needs updating, bit 5 of the FLAGS field in the Protocol 78 uplink header is set — "Time requires update".

How the firmware applies the answer:

it takes the 4 bytes of seconds and skips the fraction byte;
it subtracts 630,720,000 — the number of seconds from January 6, 1980 to January 1, 2000 without leap seconds — and sets the clock correction from the result. The firmware does not apply a value less than 630,720,000;
it does not compensate for the delay between the moment the server took the time and the reception of the answer.

How ONS responds​

DeviceTimeAns format​

GPS epoch and leap seconds​

Accuracy​

When there is no answer​

How to check​

OrionM2M devices​

See also​