Адаптивная скорость передачи (ADR)
ADR (Adaptive Data Rate) — механизм LoRaWAN, в котором сервер сам подбирает устройству скорость передачи (DR), мощность передачи и число передач каждого кадра (NbTrans). ONS следит, с каким запасом по сигналу шлюз принимает кадры устройства и сколько кадров теряется, и отправляет устройству новые параметры MAC-командой LinkADRReq. При хорошем приёме сервер повышает скорость, а затем снижает мощность; при плохом — поднимает мощность, а затем понижает скорость.
Когда ADR работает
ADR работает, только если выполнены оба условия:
- в настройках устройства включён ADR — поле
adr, в интерфейсе флажок «ADR»; по умолчанию включён; - устройство ставит в своих uplink бит ADR (FCtrl.ADR).
Если не выполнено хотя бы одно, сервер не копит статистику ADR и не отправляет команды. Прошивка OrionM2M включает ADR при запуске LoRaWAN, отдельной настройки для этого в приборе нет.
После каждой активации OTAA (join) сервер собирает настройки устройства заново без поля adr и считает ADR разрешённым. Выключенный флажок «ADR» снова действует только после сохранения устройства в интерфейсе ONS и лишь до следующего join.
Подсказка под флажком «ADR» в интерфейсе — «Только конечный узел может включить / отключить ADR». Режим ADR включает само устройство битом ADR, а флажок в настройках решает, будет ли сервер этим режимом пользоваться.
Решение сервер принимает не на каждом кадре, а примерно раз в adr_interval кадров uplink (по умолчанию 20), см. Как сервер принимает решение. При adr_interval = 0 сервер решений не принимает и LinkADRReq не отправляет. После каждой активации OTAA (join) статистика ADR начинается заново.
Что измеряет сервер
- Один приём кадра. Кадр устройства могут принять несколько шлюзов. Для ADR сервер берёт копию с наибольшим RSSI из тех, что пришли до начала обработки кадра — примерно через 0,6 секунды после первой копии. Из неё берутся SNR и DR кадра, а шлюз, который её принял, считается лучшим.
- SNR. Для лучшего шлюза сервер хранит окно из последних 20 значений SNR и оценивает приём по максимуму в окне (SNRmax).
- Потери. В том же окне хранятся FCnt последних 20 кадров. Потери — доля пропусков FCnt: число пропущенных кадров / (последний FCnt − первый FCnt) × 100 %.
- Окна по шлюзам. Окно ведётся отдельно для каждого шлюза, который был лучшим, но не больше чем для трёх шлюзов: при появлении четвёртого удаляется окно шлюза, который дольше всех не был лучшим. Решение принимается по окну текущего лучшего шлюза.
- Повторы не учитываются. Повтор кадра с тем же FCnt (NbTrans) в статистику ADR не попадает.
Как сервер принимает решение
Когда принимается решение
Сервер проверяет ADR в начале подготовки каждого downlink:
- после каждого нового uplink, даже если отправлять нечего. Повтор неподтверждаемого кадра (NbTrans) проверку не запускает, повтор подтверждаемого — запускает;
- когда лучший шлюз устройства снова выходит на связь, а у устройства есть данные downlink в очереди, — для устройства любого класса;
- у класса C есть и другие поводы, см. Классы устройств.
У окна лучшего шлюза есть счётчик. Пока в начале проверки счётчик меньше adr_interval, проверка только прибавляет к нему разницу FCnt двух последних кадров в окне, поэтому потерянные кадры тоже засчитываются. Пока в окне не больше двух кадров, прибавляется 1. Прибавка идёт на каждой такой проверке, даже если окно не изменилось, например на повторе подтверждаемого кадра. Когда при очередной проверке счётчик уже не меньше adr_interval, он обнуляется, и сервер принимает решение: при кадрах подряд и adr_interval = 20 — на каждой 21-й проверке.
Запас по сигналу
Сначала сервер считает запас по сигналу и число шагов:
- запас = SNRmax − требуемый SNR текущего DR − 10 дБ;
- NStep = запас / 3, дробная часть отбрасывается: 9,5 / 3 → 3, −7,5 / 3 → −2.
10 дБ — запас на условия установки, 3 — сколько децибел запаса приходится на один шаг. Оба значения — параметры сервера, см. Параметры сервера.
Требуемый SNR одинаков во всех частотных планах сервера:
| DR | Требуемый SNR, дБ |
|---|---|
| DR0 (SF12) | −20 |
| DR1 (SF11) | −17,5 |
| DR2 (SF10) | −15 |
| DR3 (SF9) | −12,5 |
| DR4 (SF8) | −10 |
| DR5 (SF7) | −7,5 |
Соответствие DR и SF (полоса 125 кГц) в таблице — для всех планов, кроме US915.
Скорость и мощность
- NStep > 0. На каждый шаг сервер повышает DR на одну ступень, пока не дойдёт до наибольшего DR для ADR (см. Частотный план). Оставшиеся шаги снижают мощность: индекс мощности растёт на 1 (−2 дБ) до наибольшего индекса плана.
- NStep < 0. На каждый шаг сервер сначала повышает мощность — индекс уменьшается на 1 до 0, максимальной мощности, — а затем понижает DR, вплоть до DR0.
- NStep = 0. DR и мощность не меняются.
Затем сервер применяет границы из настроек устройства — adr_min и adr_fix, см. Настройки устройства.
Примеры для плана с наибольшим DR для ADR — DR5 и индексами мощности 0–7, например KZ865-868:
| Было: DR, индекс мощности | SNRmax, дБ | Запас, дБ | NStep | Стало: DR, индекс мощности |
|---|---|---|---|---|
| DR0, 0 | +3 | 3 − (−20) − 10 = 13 | 4 | DR4, 0 |
| DR5, 0 | +12 | 12 − (−7,5) − 10 = 9,5 | 3 | DR5, 3 (−6 дБ) |
| DR5, 0 | −5 | −5 − (−7,5) − 10 = −7,5 | −2 | DR3, 0 |
Число повторов NbTrans
NbTrans — сколько раз устройство передаёт каждый кадр. Начальное значение — 1. Новое значение зависит от потерь в окне и от текущего NbTrans:
| Потери в окне | Текущее NbTrans 1 | Текущее NbTrans 2 | Текущее NbTrans 3 |
|---|---|---|---|
| Меньше 5 % | 1 | 1 | 2 |
| 5–10 % | 1 | 2 | 3 |
| 10–30 % | 2 | 3 | 3 |
| 30 % и больше | 3 | 3 | 3 |
Потолок задаёт новый DR: на DR0–DR2 NbTrans всегда 1, на DR3 и выше — не больше 3.
Когда команда не отправляется
- DR, индекс мощности и NbTrans совпадают с теми, что записаны у сервера.
- В очереди MAC-команд устройства уже лежит LinkADRReq.
- Устройство передаёт на DR выше наибольшего DR для ADR, см. Частотный план.
- У устройства план RU или UA: в текущей версии сервер не отправляет LinkADRReq для этих планов, см. Частотный план.
Иначе сервер ставит LinkADRReq в очередь MAC-команд, и команда уходит с ближайшим кадром downlink.
Настройки устройства
| Поле | В интерфейсе | По умолчанию | Что делает |
|---|---|---|---|
adr | «ADR» | true | Разрешает серверу ADR. При false сервер не копит статистику ADR и не отправляет LinkADRReq. После каждой активации OTAA сервер считает ADR разрешённым, пока устройство снова не сохранят в интерфейсе ONS, см. Когда ADR работает |
adr_interval | «ADR интервал» | 20 | Через сколько кадров uplink, по приросту FCnt, сервер принимает решение. 0 — решений нет |
adr_min | «Adr min» | DR0 | Нижняя граница: в момент решения сервер поднимает DR до adr_min, даже если запаса по сигналу не хватает |
adr_max | «Adr max» | DR5 | Сейчас не ограничивает ADR, см. ниже |
adr_fix | «Adr fix» | Не задан | Фиксированный DR: решение всегда равно adr_fix, мощность сервер не снижает. Действует, только если ADR включён и в настройках, и в устройстве |
adr_max сейчас ADR не ограничивает ни при каком значении: значение не больше наибольшего DR плана сервер пропускает, а большее ни на что не влияет. Чтобы ограничить скорость, задайте adr_fix.
Сохранение устройства в интерфейсе ONS сразу передаёт новые настройки сетевому серверу, активация (join) заново не нужна. Новый adr_interval действует со следующей проверки ADR.
Через WebSocket API поля ADR задаются в create_device_req и update_device_req и читаются командой get_devices_req. Командой update_device_req нельзя ни выключить ADR, ни задать DR0, ни сбросить adr_fix, а когда сетевой сервер узнает об изменении, написано на странице команды.
Частотный план
- Наибольший DR для ADR — наибольший DR с модуляцией LoRa и полосой 125 кГц среди uplink-каналов плана. Во всех планах, кроме US915-1…9 и AU915-9, это DR5 (SF7, 125 кГц); в US915-1…9 — DR3 (SF7, 125 кГц), в AU915-9 — DR3 (SF9, 125 кГц). Если устройство передаёт на DR выше — например DR6 (SF7, 250 кГц), — сервер ADR для него не применяет.
- Мощность задаётся индексом: 0 — максимальная мощность, каждый следующий индекс снижает её на 2 дБ. Наибольший индекс — 7 (−14 дБ) в планах EU, KZ_OLD, RU, BY, UA, KG863-865, KZ865-868, EU863-870, KZ864-868, EU433, AS923-1…4, KR920, UZ926, UZ927 и KZ865-only; 10 (−20 дБ) — в IN865-867, IN865+KZ865, US915 и AU915.
- Планы RU и UA. В текущей версии сервера ADR для устройств с планами RU (код 2) и UA (код 4) не работает: команду LinkADRReq сервер не отправляет, а на uplink, после которого он решил изменить параметры устройства, не отвечает — данные из очереди уйдут после следующего uplink. Чтобы сервер не пропускал ответ, задайте таким устройствам «ADR интервал» 0. Устройству с каналами плана UA выбирайте план EU или BY.
- Мощность устройства в uplink не передаётся. Поэтому, если DR очередного кадра отличается от записанного у сервера, сервер считает, что устройство снова передаёт на максимальной мощности (индекс 0).
- Маска каналов. ChMask и ChMaskCntl в LinkADRReq сервер берёт из плана: в маске — включённые каналы плана. Дополнительные каналы с панели «Радиопараметры» в маску не попадают. Примеры ChMask, номера каналов — по порядку в плане ONS: EU863-870 —
FF00(каналы 0–7), KZ865-868 —1F00(каналы 0–4, 865,1–865,9 МГц), KG863-865 —1F00(каналы 0–4, 863,7–864,5 МГц), EU, BY и KZ865-only —0700(каналы 0–2); ChMaskCntl — 0. В текущей версии сервера в планах с девятью включёнными каналами — EU433, US915-1…7 и AU915-1…8 — маска не совпадает с каналами плана: сервер передаёт ChMask01FF, то есть первый канал и восемь последних каналов блока из 16. В EU433 устройство, которое следует спецификации LoRaWAN, такую команду может отклонить, и ADR не сработает. В US915 и AU915 устройство может команду принять и перейти на каналы вне подполосы плана — тогда шлюз, настроенный на подполосу плана, перестанет слышать часть его uplink. Для US915-8, US915-9 и AU915-9 правильную команду LinkADRReq сервер не формирует: ADR не работает, а ответ, с которым должна уйти команда, может не уйти. Устройствам с планами US915 и AU915 задавайте «ADR интервал» 0: тогда сервер LinkADRReq не отправляет. - Дополнительные каналы вне маски выключаются. Каналы с панели «Радиопараметры» сервер передаёт устройству под номерами начиная с первого опционального канала плана, а если в плане опциональных каналов нет — с номера 3. Прошивка OrionM2M, приняв LinkADRReq, заменяет маску каналов целиком. Поэтому после каждого LinkADRReq устройство выключает дополнительные каналы с номерами вне маски: в EU, BY и KZ865-only — все дополнительные каналы, в KZ865-868 и KG863-865 — каналы 5–7.
Команда LinkADRReq в кадре:
| Байт | Содержимое |
|---|---|
| 1 | CID 03 |
| 2 | DR в старших 4 битах, индекс мощности в младших 4 битах |
| 3–4 | ChMask |
| 5 | ChMaskCntl в битах 4–6, NbTrans в младших 4 битах |
Например, DR5, индекс мощности 2 и NbTrans 1 в плане KZ865-868 — 03521f0001.
Коды регионов и каналы планов — на странице create_device_req и в разделе Частотные планы.
Классы устройств
- Класс A. LinkADRReq уходит в окне приёма после того uplink, на котором сервер принял решение.
- Класс C. Сервер проверяет ADR не только после uplink, но и когда ставит downlink в очередь, когда шлюз освобождается после передачи и когда немедленно отправляет MAC-команды сверки радиопараметров. Каждая такая проверка тоже увеличивает счётчик, поэтому решение может наступить раньше, чем через
adr_intervaluplink, и LinkADRReq уйдёт сразу, немедленным кадром.
ADRACKReq. Если устройство долго не получает downlink, оно ставит в uplink бит ADRACKReq — просит сервер ответить. Сервер отвечает на такой uplink кадром downlink, даже если отправлять нечего, и ставит в нём бит ACK. Это не зависит от настройки adr. В прошивке OrionM2M ADR_ACK_LIMIT = 64 и ADR_ACK_DELAY = 32: если устройство передаёт не на наименьшем DR, то после 64 uplink без downlink оно ставит ADRACKReq и переходит на максимальную мощность, а если ответа нет ещё 32 кадра, понижает DR на ступень каждые 32 кадра, до наименьшего.
Подробнее о классах — на странице Классы устройств.
Как проверить работу ADR
Каждая команда LinkADRReq, поставленная в очередь, записывается в журнал ADR — панель «Лог adr» на вкладке «Мониторинг» в карточке узла, см. Узлы. Свежие строки — сверху. Если менять нечего, строка не пишется.
| Колонка | Что значит |
|---|---|
| «Время» | Время записи |
| «Шлюз» | Лучший шлюз, по окну которого принято решение |
| «Current dr», «Ideal dr» | DR, записанный у сервера, и новый DR из команды |
| «Current tx power», «Ideal tx power» | Индекс мощности, записанный у сервера, и новый: PWR0 — максимальная мощность, PWR1 — на 2 дБ ниже и так далее до PWR10 |
| «Current nbtrans», «Ideal nbtrans» | NbTrans, записанный у сервера, и новый |
| «Snr margin» | Запас по сигналу, дБ |
| «Max snr», «Avg snr» | Максимум и среднее SNR в окне, дБ |
Применило ли устройство новый DR, видно по следующим uplink: колонка SF в таблице «Данные» на той же вкладке.
LinkADRReq и ответ устройства LinkADRAns в «Журнал MAC-команд» не попадают. Ответ LinkADRAns сервер разбирает так:
- все три подтверждения — маски каналов, DR и мощности — получены: сервер ничего не меняет;
- устройство отклонило мощность, а записанный у сервера индекс — 0: сервер ставит индекс 1 и больше не назначает индекс 0 этому устройству по окну этого шлюза;
- другие отказы сервер не откатывает: фактический DR он снова прочитает из следующего uplink.
Что важно знать
- Параметры записываются при отправке, а не по подтверждению. Новые DR, мощность и NbTrans сервер считает действующими, как только ставит LinkADRReq в очередь. Если команда не дошла или отклонена, а DR в ней менялся, сервер увидит прежний DR в следующем uplink и будет считать от него, а мощность примет за максимальную (индекс 0). Мощность и NbTrans в uplink не видны: если менялись только они, сервер об отказе не узнает — он считает новые значения действующими и повторно команду не шлёт, пока решение не изменится.
- Один LinkADRReq в очереди. Пока в очереди MAC-команд лежит LinkADRReq, новый сервер не ставит.
- Статистика ведётся по шлюзу. Если лучшим стал другой шлюз, сервер решает по его окну и его счётчику; у шлюза, который раньше не был лучшим, окно и счётчик начинаются с нуля. Кадры, которые лучше принял другой шлюз, в окне текущего выглядят пропусками, поэтому при частой смене лучшего шлюза сервер видит потери выше фактических и может поднять NbTrans.
- После join — заново. При каждой активации OTAA окна SNR и FCnt, счётчики и очередь MAC-команд обнуляются. Настройки устройства сервер собирает заново без поля
adrи считает ADR разрешённым; выключенный флажок «ADR» снова начинает действовать только после сохранения устройства в интерфейсе ONS. - Перезапуск. При перезапуске сетевого сервера (процесса LWServer) состояние ADR сохраняется: оно лежит в Redis 30 дней с последней записи. Перезапуск самого Redis эта копия переживает, только если Redis сохраняет данные на диск.
adr_minподнимает DR без учёта сигнала. Сервер назначит DR не нижеadr_min, даже если запаса по сигналу для этой скорости нет.
Параметры сервера
Эти параметры действуют на все устройства и задаются аргументами запуска LWServer — процесса сетевого сервера ONS. Они нужны тем, кто сам разворачивает ONS.
| Аргумент | По умолчанию | Что задаёт |
|---|---|---|
--adr_margin | 10 | Запас на условия установки в формуле запаса, дБ |
--adr_nstep_div | 3 | Сколько децибел запаса приходится на один шаг NStep |
--adr_snr_stat | max | Оценка SNR по окну: max — максимум, avg — среднее |
--adr_window | 20 | Размер окна SNR и FCnt, кадров |
--adr_max_gateways | 3 | Для скольких шлюзов хранить окна одного устройства |
--adr_snr_mode | window | window — окно последних значений SNR; decaying — затухающий максимум без окна: оценка = max(SNR кадра, β × прежняя оценка). В режиме decaying среднее не считается, и --adr_snr_stat принудительно max |
--adr_decay | 0,9 | Коэффициент β для режима decaying |
См. также
- Узлы — поля ADR в карточке узла и панель «Лог adr».
- Классы устройств — когда устройство получает downlink.
- Частотные планы — каналы и скорости планов.
create_device_req— поля ADR при регистрации устройства.update_device_req— изменение настроек ADR через WebSocket API.