Skip to main content

Время устройства

Устройство LoRaWAN узнаёт у сети текущее время MAC-командой DeviceTimeReq (CID 0x0D), чтобы выставить свои часы. ONS отвечает на каждый такой запрос командой DeviceTimeAns. Настройки, которая включает или выключает ответ, нет: сервер не проверяет ни настройки устройства, ни версию LoRaWAN.

Как ONS отвечает​

  1. Через 0,3–0,6 секунды после получения uplink сервер разбирает его MAC-команды и находит в них 0x0D. Команды он ищет в поле FOpts, если FPort больше 0 или его нет вовсе (кадр только с MAC-командами), и в FRMPayload, если FPort = 0. Полезной нагрузки у запроса нет: это один байт CID.
  2. Сервер берёт текущее время UTC по своим часам и считает секунды от начала эпохи GPS — 6 января 1980 года, 00:00:00 UTC.
  3. Сервер ставит DeviceTimeAns в очередь MAC-команд устройства. Если там ещё ждёт неотправленный DeviceTimeAns, сервер его удаляет и ставит новый.
  4. Сразу после разбора MAC-команд сервер собирает кадр downlink: непустой очереди MAC-команд для этого достаточно, даже если данных приложения для устройства нет. Кадр уходит в окно приёма RX1 или RX2 этого же uplink, момент передачи отсчитывается по счётчику шлюза, который принял uplink:
    • данных приложения нет — кадр с FPort 0, MAC-команды в FRMPayload, зашифрованные ключом NwkSKey;
    • данные приложения есть — MAC-команды в поле FOpts этого кадра.

Если RX1 уже не успеть, сервер отправляет кадр в RX2. Устройству класса C ответ на uplink, в том числе DeviceTimeAns, сервер по умолчанию тоже планирует в RX1 или RX2. Сразу, без привязки к окну, кадр уходит, только если окно уже не успеть, если для кадра указан другой шлюз, чем тот, что принял uplink, или если сервер запущен с параметром --classc_uplink_imme 1.

Формат DeviceTimeAns​

Ответ занимает 6 байт:

БайтПолеЗначение
0CID0x0D
1–4СекундыЦелое число секунд от начала эпохи GPS, uint32, little-endian (младший байт первым)
5Доля секундыuint8, в единицах 1/256 секунды

Пример. Сервер снял время 9 октября 2026 года, 12:00:00,25 UTC:

  • секунды от начала эпохи GPS — 1 475 582 400, в hex 0x57F399C0, в little-endian — C0 99 F3 57;
  • доля секунды — 0,25 × 256 = 64, в hex 0x40;
  • DeviceTimeAns — 0DC099F35740.

Чтобы перевести значение ONS в Unix-время, прибавьте 315 964 800 — столько секунд между 1 января 1970 года и 6 января 1980 года. В примере 1 475 582 400 + 315 964 800 = 1 791 547 200, то есть 2026-10-09 12:00:00 UTC.

Эпоха GPS и високосные секунды​

ONS считает секунды как календарную разницу между текущим временем UTC и 6 января 1980 года, 00:00:00 UTC. Високосные секунды сервер не добавляет. Настоящее время GPS опережает UTC на 18 високосных секунд, поэтому значение ONS на 18 секунд меньше настоящего числа секунд GPS.

Внимание

Устройство, прошивка которого получает UTC из ответа вычитанием високосных секунд, с ONS будет отставать от UTC на 18 секунд. Устройства OrionM2M високосные секунды не вычитают, поэтому с ONS их часы идут по UTC.

Точность​

  • Шаг доли секунды — 1/256 секунды, около 3,9 мс. Доля отбрасывается, а не округляется.
  • Время берётся по часам сервера ONS. Метки времени шлюза (tmst и time из пакета шлюза) для ответа не используются.
  • Время снимается при разборе MAC-команд, а не на момент окончания передачи uplink в эфире: через 0,6 секунды минус половина RTT шлюза после того, как сервер получил uplink, плюс время обработки. Вычитается не больше 0,3 секунды, так что метка приходится на 0,3–0,6 секунды после получения uplink. RTT шлюза — время от отправки кадра downlink на шлюз до подтверждения TX_ACK от него, сглаженное экспоненциальным средним с коэффициентом 0,3. Если задержка в обе стороны одинакова и половина RTT не больше 0,3 секунды, метка соответствует моменту примерно через 0,6 секунды после того, как шлюз переслал uplink серверу.
  • Значение вычисляется один раз и дальше не меняется. Время ожидания до окна RX1 или RX2 к нему не прибавляется. Если шлюз отказался передать кадр в RX1 с ошибкой TOO_EARLY, TOO_LATE, COLLISION_PACKET или COLLISION_BEACON, сервер по умолчанию (параметр --rx2_retry) повторяет кадр в RX2 — если окно RX2 ещё успевает и кадр в него помещается. Повтор несёт те же байты и то же время. В остальных случаях кадр не уходит, а ответ из очереди уже снят.
  • Ответ, который не поместился в кадр, остаётся в очереди и уходит со следующим downlink — со временем, снятым при постановке в очередь. MAC-команды в FOpts занимают меньше 30 hex-символов (не больше 14 байт), в FRMPayload при FPort 0 — меньше 51 (не больше 25 байт). Очередь берётся с начала до первой команды, которая не помещается.

Когда ответа не будет​

СитуацияЧто происходит
В настройках устройства указан класс BСервер забирает ответ из очереди в кадр, но кадр не отправляет: ONS класс B не поддерживает
DeviceTimeReq пришёл в повторе кадра с тем же FCnt меньше чем через 30 секунд после предыдущего приёма — та же передача через другой шлюз или повторная передача устройстваMAC-команды повтора сервер не разбирает, новый ответ не формирует. Кадр с тем же FCnt, пришедший через 30 секунд и позже, сервер обрабатывает как новый и на запрос отвечает
Перед 0x0D в том же кадре стоит MAC-команда, которой ONS не знаетНа неизвестном CID сервер прекращает разбор кадра, и DeviceTimeReq до обработки не доходит. В uplink сервер разбирает CID 0x02–0x0A и 0x0D
Кадр с ответом не дошёл до устройстваИз очереди ответ уходит в кадр один раз. Устройство должно запросить время снова

Как проверить​

  • Запрос в данных uplink. Поле fopts в сообщении realtime_data (consume_req) и в пакетах get_data_req содержит MAC-команды из FOpts в hex. DeviceTimeReq, переданный в FOpts, виден в нём как байт 0D.
  • Запрос в веб-интерфейсе. Раздел «Узлы», карточка узла, вкладка «Мониторинг», таблица «Данные», колонка «MAC». В колонке — содержимое FOpts, а у кадров с FPort 0 — данные кадра. См. описание вкладки.
  • Ответ. В той же таблице «Данные» ответ виден в строке Downlink кадра, ушедшего после uplink с запросом: в колонке «MAC» — байт 0D и 5 байт ответа после него, например 0DC099F35740. У кадра без данных приложения (FPort 0) это данные кадра, у кадра с данными приложения — FOpts. В «Журнале MAC-команд» обмен DeviceTimeReq и DeviceTimeAns не отображается: сервер его туда не записывает, хотя тип DeviceTime (CID 13) в фильтре журнала есть. Время ответа сервер пишет и в свой журнал работы строкой «Device time request for …».

Устройства OrionM2M​

Прошивка устройств OrionM2M запрашивает время, когда часы требуют обновления:

  • часы ещё ни разу не корректировались по сети;
  • с последней корректировки прошло 7 дней;
  • после холодного старта, при котором устройство восстановило последнее сохранённое время: прошивка помечает время как неверное и запрашивает его при первой возможности.

DeviceTimeReq прошивка добавляет только к uplink с данными приложения на FPort 2. Пока часы требуют обновления, в заголовке Protocol 78 uplink выставлен бит 5 поля FLAGS — «Требуется обновление времени».

Как прошивка применяет ответ:

  • берёт 4 байта секунд, байт доли секунды пропускает;
  • вычитает 630 720 000 — число секунд от 6 января 1980 года до 1 января 2000 года без високосных секунд — и задаёт по результату поправку часов. Значение меньше 630 720 000 прошивка не применяет;
  • задержку между моментом, когда сервер снял время, и приёмом ответа не учитывает.

См. также​