Семён сохраняет полезное_)

Как из неуправляемого коммутатора сделали управляемый или как я купил очередную хрень и сделал из неё другую

2026-09-20T17:55:01.202Z

Однажды мне попался на озоне медиаконвертер с 4 портами RJ-45(8P8C) и одним портом для оптики. Стоил он недорого(их и сейчас можно найти за 2 тысячи) и мне было интересно на чем он устроен и что можно из него сделать(а ещё если он будет вовсе глупый то использовать по прямому назначению). Так прошел год после покупки и у меня недоходили руки до него. Недавно время всё таки нашлось. Итак я сделал из медиаконвертера управляемый свитч.

Начнем с того что обнаружилось на плате медиаконвертера.

RTL8367S-CG — управляемый коммутатор второго уровня, пять встроенных
приёмопередатчиков на гигабит плюс два расширенных порта. На нашей плате
наружу выведены четыре разъёма и один под оптику.

Рядом с ним на плате стоит FT24C32A — микросхема памяти на 32 килобита
(4 КБ) с двухбайтовой адресацией, откликается на адрес 0x50.

В качестве управляющей платы я взял WeAct STM32G431 Core Board. На плате стоит STM32G431CB, а в нем: Cortex-M4F на 170 МГц, 128 КБ флеш-памяти,
32 КБ оперативной. Определение платы уже есть в дереве Zephyr под именем
weact_stm32g431_core, и в нём всё, что нужно. Ровно 48 МГц для USB — обязательное требование, и делитель Q подобран
именно под него. Взят он потому-что был просто под рукой. И да для данной задачи это over.

Выводы коммутатора и выбор режима

Самая ценная выкладка из документации на RTL8367S-CG была в том:

Отдельных выводов MDC/MDIO у микросхемы нет. Это те же две линии что и I2C. Какую из двух ролей они играют, задаёт состояние вывода SMI_SEL
(совмещён с GPIO52, LAN0LED0/LED_CK) в момент сброса.

Второй страппинг: EEPROM_MOD/LAN4LED0 задаёт размер памяти —
низкий уровень означает до 16 кбит (24C02…24C16), высокий — больше
(24C32…24C256). У нас стоит 24C32, значит вывод должен быть в высоком
состоянии.

Служебный протокол Realtek SMI

Протокол внешне напоминает I²C, но им не является: у него свои условия
начала и конца посылки. Поэтому аппаратный контроллер I²C использовать
нельзя — обмен формируется программно.

Код команды

Первый байт собирается из трёх частей:

  1011    +    100    +    К       =  1011 100К
  4 бита       3 бита      1 бит

где К — направление: 1 означает чтение, 0 — запись.

Последовательность чтения регистра

START
0xB9                → подтверждение
младший байт адреса → подтверждение
старший байт адреса → подтверждение
младший байт данных ← выдаём подтверждение (0)
старший байт данных ← выдаём отказ (1)
STOP

Запись отличается тем, что после старшего байта адреса передаются младший
и старший байты данных, каждый с подтверждением.

Порядок байт: младший вперёд и для адреса, и для данных.

Условия начала и конца

Начало посылки отличается от I²C тем, что спад линии данных приходится
на второй такт, а не на первый:

SCK: __/‾‾\__/‾‾‾‾‾‾\__
SDA: ‾‾‾‾‾‾‾‾‾‾‾‾\_____/‾‾
         такт 1    такт 2

Конец посылки содержит несколько добавочных тактов - коммутатору нужно
время завершить внутреннюю операцию.

Самое важное: способ управления линиями

Линии необходимо вести активно в оба уровня. На открытом стоке, когда
единицу отдаёт подтягивающий резистор, коммутатор не отвечает вовсе -
ни на одной скорости, ни при каком назначении выводов.

Тайминги

Задержка между сменами уровней у Realtek - 1 микросекунда. У нас по
умолчанию 2 мкс, и обмен устойчиво работает в диапазоне 1…10 мкс. Скорость
на работоспособность не влияла: перебор от нулевой задержки до 100 мкс при
открытом стоке не дал ни одного ответа.

5. Открытие доступа к регистрам

Регистр номера чипа 0x1300 упорно читался нулями, хотя соседние регистры
отдавали осмысленные значения. Разгадка нашлась в исходниках изготовителя:
при запуске он записывает особое значение в отдельный регистр.

записать 0x0249 в регистр 0x13C2

Проверка на железе и тут!

0x6367 - это и есть опознавательный номер RTL8367. Заодно опыт доказал,
что запись в регистры работает: записанное значение изменило поведение
микросхемы.

Прошивка делает это сама при запуске, выждав перед этим три секунды —
столько коммутатору нужно на собственную инициализацию после включения. Поймал при ребуте коммутатора по питанию.

6. Карта регистров

Официальный заголовок Realtek rtl8367c_reg.h содержит около двадцати трёх
тысяч строк определений. Переписывать это руками бессмысленно, поэтому
карта построил разбором заголовка.

Привязка полей к регистрам делается по самому длинному совпадающему
префиксу имени — иначе поля похоже названных регистров достаются не тем
владельцам.

7. Состояние портов

Один регистр на порт, начиная с 0x1352:

адрес = 0x1352 + номер порта

Расшифровка проверена вживую. При подключении кабеля регистр изменился
так:

было  0x00e0 = 0000 0000 1110 0000
стало 0x00f5 = 0000 0000 1111 0101
                          ↑  ↑ ↑ ↑
                          │  │ │ └─ бит 0: скорость 100 Мбит/с
                          │  │ └─── бит 2: полный дуплекс
                          │  └───── бит 4: появилась связь
                          └──────── биты 5-7 не изменились

Поднялись ровно три ожидаемых разряда, остальное осталось на месте.

Соответствие разъёмов портам: физический разъём 1 — это порт 0
внутри микросхемы.

8. Счётчики

Коммутатор ведёт 59 счётчиков на каждый порт. Они лежат не в обычных
регистрах: нужно задать номер счётчика и забрать значение из окна.

0x1004 -номер нужного счётчика

0x1005 -состояние, разряд 0 - занятость, разряд 1 - идёт сброс

0x1000…0x1003 -окно из четырёх регистров со значением

Вычисление номера

смещение = 0x7C × номер_порта
если номер_порта > 7: смещение += 68
для каждого предыдущего счётчика: смещение += его_длина

Длина счётчика — 4 регистра (64 разряда) для объёмов в байтах и
2 регистра (32 разряда) для остальных. Шаг между наборами разных портов —
0x7C, то есть 124 регистра.

Порядок обращения

Прочитать 0x1004. Если там уже лежит нужный номер, записать другой —
иначе коммутатор не станет обновлять окно.
Записать смещение >> 2 в 0x1004.
Дождаться сброса разряда занятости в 0x1005.
Прочитать окно. Для счётчика длиной 4 регистра чтение начинается
с 0x1003, для длиной 2 — с 0x1000 + ((смещение + 1) mod 4).
Дальше адрес убывает, а значение собирается сдвигом влево на 16.

Отдельно стоит счётчик отброшенных изученных записей: он не привязан
к порту и лежит по фиксированному смещению 0x420.

9. Виртуальные сети

Два уровня описания.

Записи членства: 32 штуки по 4 регистра

адрес = 0x0728 + номер_записи × 4

Раскладка по словам:

0 - маска портов-членов, 11 разрядов

1 - группа фильтрации, 4 разряда

2 - разряд 0 - приоритет включён, 1–3 - приоритет, 4 - учёт включён, 5–10 - номер счётчика

3 - номер сети, 13 разрядов

Привязка порта к записи

адрес = 0x0700 + номер_порта / 2

По два порта на регистр: порт с чётным номером в младшей половине, со
следующим - в старшей. В каждой половине разряды 0–4 содержат номер
записи членства, разряды 5–7 - приоритет.

Обратите внимание: порт ссылается не на номер сети напрямую, а на
номер записи членства.

Таблица на 4096 сетей: 3 слова на запись

0 - разряды 0–7 - маска членов, 8–15 - маска портов без метки

1 - 0-3 группа фильтрации, 4 приоритет включён, 5–7 приоритет, 8 учёт включён, 9–13 номер счётчика, 14 раздельное изучение адресов

2 - 0-2 старшие разряды маски членов, 3–5 старшие разряды маски без метки, 6 старший разряд номера счётчика

Маски портов разрезаны между словами 0 и 2, потому что портов
одиннадцать, а в байт помещается восемь.

10. Доступ к внутренним таблицам

Таблицы сетей, изученных адресов и правил разбора доступны через общее
окно:

0x0500 - вид таблицы и направление обращения

0x0501 - номер записи

0x0510…0x0519 - окно записи

0x0520…0x0529 - окно чтения

Слово управления собирается так:

команда = (направление << 3) | вид_таблицы

Правила разбора - 1

Действия разбора - 2

Сети - 3

Изученные адреса - 4

Группы рассылки - 5

Направление: 0 — чтение, 1 — запись.

11. Прочие подсистемы

Зеркалирование трафика

Регистр 0x121C:

0–3 - порт-источник

4–7 - порт-приёмник копии

9 - копировать принятое

10 - копировать переданное

Дополнительно 0x12FB содержит маску портов-источников (11 разрядов).

Изоляция портов

адрес = 0x08A2 + номер_порта

Одиннадцатиразрядная маска: каким портам этот порт вправе пересылать
кадры. Позволяет развести абонентов, не прибегая к виртуальным сетям.

Ограничение скорости

Приём -0x000F + номер_порта × 2, два регистра

Передача -PORT<n>_EGRESSBW_CTRL0/1

Первый регистр хранит младшие 16 разрядов, второй — разряды 16–18. Счёт
идёт в единицах по 8 килобит в секунду, поэтому заданное значение
округляется вниз до кратного.

12. Что лежало в памяти на плате

Содержимое микросхемы вычитано целиком — 4096 байт. Ожидалась таблица
вида «адрес регистра — значение», которую коммутатор загружает при
включении. Оказалось иное.

Начало образа:

0000: b7 0d 02 0a 71 e4 f5 a8 d2 af 22 00 00 02 0c d3

0x00 - b7 0d - заголовок: 0x0DB7 = 3511, длина

0x02 -02 0a 71 - LJMP 0x0A71 — вектор сброса

0x05 - e4 f5 a8 d2 af 22 - CLR A / MOV IE,A / SETB EA / RET

0x0D - 02 0c d3 - LJMP 0x0CD3 - вектор прерывания таймера

Это исполняемый код архитектуры 8051. Если считать, что адресу
0x0000 соответствует смещение 2, таблица векторов прерываний сходится
идеально.

Характерные команды по всему объёму: e4 (CLR A), 90 xx xx
(MOV DPTR), 12 xx xx (LCALL), 02 (LJMP), 22 (RET),
7f/7e/7d (загрузка регистров).

В конце образа: по смещению 0x0FE0 — байты d1 a1 cd a4 ca a1, которые
в кодировке GB2312 складываются в иероглифы; по смещению 0x0FF6 —
20 16 10 25, очень похоже на дату 25 октября 2016 года.

Проверка догадки

В открытой библиотеке для этого семейства нашёлся готовый образ памяти,
причём именно для FT24C32A в корпусе SOIC8 — той же микросхемы:

наш образ:  b7 0d 02 0a 71 e4 f5 a8 d2 af 22 00 00 02 0c d3
эталонный:  fc 09 02 07 37 e4 f5 a8 d2 af 22 00 00 02 09 44
            └──┬──┘ └───┬──┘ └────────┬───────┘ └─┬─┘ └──┬──┘
            заголовок  LJMP      одинаковый код  нули  LJMP

Совпадает структура: заголовок с длиной, переход на начало программы,
побайтово одинаковый стартовый код, нули, вектор прерывания.
Содержимое разное (другая версия прошивки, у эталона длина 0x09FC =
2556), но формат тот же.

ядро 8051 встроено в сам RTL8367S, и в памяти лежит его
прошивка. Коммутатор при включении сам вычитывает её по тем же линиям,
выступая на шине ведущим.

13. Архитектура решения

Почему логика на компьютере

Карта регистров содержит 4079 позиций. Реализовывать их обслуживание в
прошивке значило бы перепрошивать плату ради каждой новой возможности.
Поэтому разделение такое:

Прошивка на Zephyr v4.4.2 на STM32 - прозрачный мост к регистрам

Программа на Python - карта регистров, подсистемы, веб-интерфейс

Машинный протокол

У оболочки на плате два набора команд. Один для кожаных - с подписями и
пояснениями. Второй для программы - со строгим ответом:

m r <адрес> [кол-во] - прочитать подряд идущие регистры

m w <адрес> <знач>… - записать подряд идущие регистры

m m <адрес> <маска> <знач> - изменить только отмеченные разряды

m i - номер чипа, версия, режим

m u - открыть доступ к регистрам

m s [мкс] - показать или задать полутакт шины

Ответ всегда одной строкой: + <значения> при успехе, - <код> при
отказе, все числа шестнадцатеричные. Пример:

m r 1352 8
+ 00e0 00e0 00e0 00f5 0086 0000 0000 0000

Команда изменения разрядов существует отдельно неспроста: читать и писать
по очереди небезопасно, потому что между двумя обращениями регистр может
изменить сам коммутатор. Прошивка делает это неделимо.

Связь с платой

Плата отдаётся системе как виртуальный последовательный порт с
опознавательными признаками 2FE3:0001 и названием RTL8367S Manager.
Программа ищет её по этим признакам, поэтому смена имени устройства
(/dev/ttyACM0 против /dev/ttyACM1) ни на что не влияет — а меняется
оно охотно, поскольку рядом подключён отладчик.

Источники

RTL8367S-CG, техническое описание
Realtek Unmanaged Switch Arduino Library — эталонная реализация обмена, карта регистров, образ памяти
Realtek_switch_hacking — первоисточник файлов изготовителя
Драйверы realtek в ядре Linux — два независимых интерфейса управления
Описание привязки realtek-smi в Linux

Трафик без data bearer: как передавать данные, если есть только служебный канал

2026-09-12T20:08:24.207Z

Иногда бывает так: модем подключён, сеть есть, но привычного IP-интерфейса (ppp0, wwan0) — нет. Либо оператор заблокировал data bearer, либо устройство работает в режиме «только сигнализация». При этом диагностический порт (Qualcomm DIAG, Gobinet, QXDM) доступен, и через него идёт служебный трафик: NAS, RRC, SIB, paging.

В таких условиях можно организовать передачу пользовательских данных, используя служебный канал как транспорт. Ниже — рабочий подход, проверенный на Qualcomm MSM8916, USB-модемах и Android-устройствах с root.

Что доступно, если нет data bearer

Обычный сценарий работы модема:

UE <--RRC/NAS--> eNB <--S1-AP--> MME
 |                              |
 +------IP (PPP/NCM/MBIM)------+

При отсутствии data bearer IP-канал не поднимается. Но диагностический порт остаётся активным:

UE <--DIAG (USB/ADB)--> Host (Linux/Android)
       ^
       | сырые L2/L3 фреймы: BCCH, CCCH, DCCH, DTCH

Через DIAG можно:

принимать и декодировать служебные сообщения (NAS, RRC, SIB);
в некоторых случаях — инкапсулировать пользовательские данные в DTCH-подобные фреймы;
использовать туннелирование поверх существующих сигнальных процедур.

Инструментарий

Для работы понадобятся:

QCSuper — утилита для захвата и декодирования радиофреймов с Qualcomm-модемов.github+1
Wireshark — для анализа pcap-файлов.
ADB (если модем встроен в Android) или USB-модем с DIAG-портом (например, разлоченный Quectel).
socat / netcat — для организации туннелей.
AT-команды для включения диагностического режима.

Включение диагностического порта

Для USB-модема (Quectel, Thales и др.)

# Найти порт модема
mmcli -L

# Включить DIAG (Qualcomm)
mmcli -m <modem-index> --command="AT$QCDMG"

После этого появится устройство /dev/ttyUSBx (обычно ttyUSB0 или ttyUSB2) — это и есть DIAG-порт.

Для Android-устройства

# Включить отладку по USB
adb devices

# Проверить доступ
adb shell

# Включить DIAG (требует root)
adb shell "su -c 'setprop sys.usb.config diag,adb'"

На некоторых устройствах требуется прописать правило udev:

# Узнать VID:PID
lsusb

# Создать правило
sudo nano /etc/udev/rules.d/51-android.rules
# Добавить строку:
SUBSYSTEM=="usb", ATTR{idVendor}=="<VID>", ATTR{idProduct}=="<PID>", MODE="0666", GROUP="plugdev"

# Перезагрузить правила
sudo udevadm control --reload-rules

Захват трафика через QCSuper

Базовый запуск

# Для USB-модема
qcsuper --usb-modem /dev/ttyUSB0 --wireshark-live --decrypt-nas --reassemble-sibs --include-ip-traffic

# Для Android через ADB
qcsuper --adb --wireshark-live --decrypt-nas --reassemble-sibs

По умолчанию QCSuper показывает только сигнальные фреймы. Опция --include-ip-traffic добавляет пользовательский IP-трафик, если он есть.

Что видно в Wireshark

BCCH — широковещательные SIB (информация о соте);
PCCH — paging;
CCCH/DCCH — сигнальные сообщения (attach, authentication, bearer setup);
DTCH — зашифрованный пользовательский трафик (если data bearer активен).

Если data bearer отсутствует, DTCH будет пустым или отсутствовать. Но это не значит, что передача данных невозможна.

Организация туннеля поверх служебного трафика

Идея

Поскольку прямой IP-канал недоступен, можно:

Инкапсулировать пользовательские данные в сигнальные сообщения (например, в NAS или RRC);
Использовать существующий DTCH как транспорт, даже если он не поднимает PPP;
Организовать туннель между двумя устройствами, где одно выступает как «модем», а другое — как шлюз.

Пример: туннель через socat

Предположим, у вас есть:

Устройство A — модем с DIAG-портом (например, Raspberry Pi с USB-модемом);
Устройство B — шлюз с доступом в интернет.

На устройстве A:

# Открыть порт для ретрансляции DIAG-трафика
socat TCP-LISTEN:12345,reuseaddr,fork /dev/ttyUSB0,raw,echo=0

На устройстве B:

# Создать виртуальный COM-порт, подключённый к устройству A
socat PTY,link=/dev/virtualTTY0,raw,echo=0 TCP:<IP-устройства-A>:12345

# Запустить QCSuper с туннелированием
qcsuper --usb-modem /dev/virtualTTY0 --wireshark-live --include-ip-traffic

Теперь можно захватывать трафик удалённо, а при необходимости — модифицировать его на лету (например, внедрять пользовательские данные в DTCH).

Обход блокировок: ICMP, DNS, HTTP-туннели

Если оператор блокирует обычный data bearer, но пропускает ICMP или DNS, можно использовать их как транспорт:

ICMP-туннель (ping)

import socket, struct

def create_packet(id, data):
    ICMP_ECHO_REQUEST = 8
    header = struct.pack('bbHHh', ICMP_ECHO_REQUEST, 0, 0, id, 1)
    data = data + b"\x00" * ((len(data) % 2))
    # checksum calculation omitted for brevity
    return header + data

sock = socket.socket(socket.AF_INET, socket.SOCK_RAW, socket.IPPROTO_ICMP)
packet = create_packet(1, b"Hello, world!")
sock.sendto(packet, ("8.8.8.8", 0))

Такой подход позволяет передавать данные внутри ICMP Echo Request, обходя блокировки на уровне L3.

DNS-туннель

DNS-запросы обычно не блокируются. Можно кодировать данные в поддоменах:

# Пример отправки данных через DNS
dig data12345.tunnel.example.com

На стороне сервера — парсить запросы и извлекать данные.

HTTP/HTTPS-туннель

Если доступен HTTP/HTTPS (даже без полноценного data bearer), можно использовать:

# Через curl
curl -X POST -d @data.bin https://tunnel.example.com/upload

# Через socat
socat TCP-LISTEN:8080,reuseaddr,fork EXEC:'curl -X POST -d @- https://tunnel.example.com'

Практический пример: передача данных через DIAG

Допустим, нужно передать файл с устройства на сервер, но PPP не поднимается.

Шаг 1: Подготовка

Включить DIAG на модеме (AT$QCDMG);
Убедиться, что QCSuper видит фреймы;
На сервере — запустить socat для приёма данных.

Шаг 2: Кодирование данных

Пользовательские данные можно внедрять в:

NAS-сообщения (например, в поля, которые не проверяются сетью);
RRC-сообщения (если есть возможность модифицировать их на уровне модема);
DTCH (если он активен, но не поднимает PPP).

Ссылки:

QCSuper: https://github.com/P1sec/QCSuper
Включение DIAG на модемах: https://forum.digikey.com/t/cellular-layer3-tracing-possibility-for-qualcomm-based-modules-2g-3g-4g-lte-m-nb-iot/27228
ICMP-туннели: https://habr.com/ru/companies/ruvds/articles/763600/
Приём служебного GSM-трафика: https://habr.com/ru/companies/timeweb/articles/947684/

Малоизвестные разработчики чипсетов LTE и GSM

2026-09-06T21:09:59.326Z

Когда речь заходит о модемах LTE и GSM, на ум сразу приходят Qualcomm, MediaTek, Huawei и Samsung. Но за пределами этого «большого клуба» существовал и продолжает существовать целый пласт компаний, чьи чипы работали в миллионах устройств, но остались в тени. Многие из них были поглощены, закрыты или перепрофилированы, оставив после себя лишь упоминания в спецификациях и старых пресс-релизах.

Пионеры single-mode LTE: Altair и Sequans

Altair Semiconductor (Израиль) — одна из первых компаний, выпустивших коммерческий LTE-чипсет. Их FourGee-3100 (Cat. 3, 100 Мбит/с) появился на рынке ещё в 2009 году и стал первым сертифицированным Verizon решением для LTE-сетей. Позже вышли FourGee-3800 (Cat. 4, 150 Мбит/с) и FourGee-3802 (Cat. 6, 300 Мбит/с) с поддержкой LTE-Advanced. В 2014 году Altair была приобретена Sony и переименована в Sony Semiconductor Israel, но бренд Altair сохранился для IoT-линейки (ALT1160, ALT1250 — Cat-M1/NB-IoT).

Sequans Communications (Франция) — начинала с WiMAX, но к 2011 году полностью переключилась на LTE. Их первый LTE-чип Colibri вышел в 2010 году, а позже компания стала известна благодаря Calliope (Cat. 1 для IoT) и Monarch (первый в мире single-chip Cat-M1/NB-IoT). Sequans поставляла чипы для China Mobile, SK Telecom, Verizon и других операторов, но осталась в нише IoT-модулей, не попав в массовый смартфонный рынок.

«Второй эшелон» 2010-х: GCT, Leadcore, Innofidei

GCT Semiconductor (США/Корея) — разработчик single-mode LTE-чипов серии GDM724x, которые использовались в USB-донглах, CPE, M2M-устройствах и даже некоторых смартфонах. Их решения коммерчески доступны с 2010 года и до сих пор встречаются в IoT-модулях.

Leadcore Technology (Китай) — дочерняя компания Datang Telecom, известная чипами LC1761, LC1860 и другими LTE-решениями для китайского рынка. Поддерживали TD-LTE и FDD, но остались в основном внутри экосистемы китайских OEM.

Innofidei (Япония) — ещё один игрок, предлагавший single-mode LTE-чипсеты в начале 2010-х, но так и не вышедший на массовый рынок. Компания упоминается в отчётах ABI Research как один из пяти вендоров single-mode LTE, но широкой известности не получила.

Поглощённые и исчезнувшие: Icera, ST-Ericsson, Renesas Mobile

Icera (Великобритания) — основана в 2002 году, специализировалась на software-defined модемах с архитектурой на базе custom DSP. Их чипы ICE8040/ICE8060 поддерживали 2G/3G/4G и использовались в смартфонах и планшетах. В 2011 году NVIDIA приобрела Icera за $367 млн, но к 2015 году свернула baseband-бизнес, так и не сумев конкурировать с Qualcomm.

ST-Ericsson (совместное предприятие STMicroelectronics и Ericsson) — выпускала multimode-модемы Thor M7400/M7450 и платформы NovaThor (L8540, L8580) с интеграцией LTE Cat. 4, HSPA+, GSM, TD-SCDMA. Несмотря на технологическую продвинутость (28 нм, FDSOI, carrier aggregation), компания не выдержала конкуренции и была ликвидирована в 2013 году.

Renesas Mobile (Япония) — наследник wireless-бизнеса Nokia, приобретённого Renesas в 2010 году. Разрабатывала multimode LTE-чипы, но в 2013 году продала LTE-активы Broadcom за $164 млн, фактически выйдя из рынка.

Забытые имена: Beceem, Wavesat, Comsys

Beceem Communications (Израиль) — лидер рынка WiMAX-чипов, который к 2010 году выпустил первый multimode-чип BCS500 с поддержкой LTE и WiMAX. В том же году была приобретена Broadcom за $316 млн, но после сворачивания WiMAX-направления технологии Beceem так и не стали массовыми в LTE-сегменте.

Wavesat (Израиль) — разработчик WiMAX-чипов Odyssey 9000, позднее поглощённый Cavium Networks в 2011 году.

Comsys (Израиль) — поставляла baseband-решения CM1125 для GSM/EDGE/WiMAX/LTE, но осталась в нише IP-лицензирования и не вышла на массовый рынок чипов.

Китайские игроки: Spreadtrum/UNISOC, HiSilicon, Sanechips

Spreadtrum (позже UNISOC) — начинала с GSM/GPRS-чипов для ультрабюджетных телефонов, позже добавила LTE. Сегодня UNISOC — один из крупнейших вендоров LTE-платформ для IoT и бюджетных смартфонов.

HiSilicon (дочерняя Huawei) — разрабатывала LTE-чипы Balong для устройств Huawei и Honor, а также для внешних OEM.

Sanechips (бывшая ZTE Microelectronics) — поставляла LTE-решения для оборудования ZTE и партнёров.

Почему они исчезли?

Рынок baseband-модемов — один из самых безжалостных в полупроводниковой индустрии. За период с 2010 по 2015 год из него ушли десятки компаний: Texas Instruments, Freescale, NXP, Infineon, Renesas Mobile, ST-Ericsson, Broadcom, NVIDIA/Icera, и это только верхушка айсберга. Причины их ухода не случайны — они системны и повторяются из кейса в кейс. Разберем их:

1. Экстремальные затраты на R&D при низкой маржинальности

Разработка multimode LTE-модема (GSM/UMTS/LTE, все мировые диапазоны, carrier aggregation, VoLTE) требует команды в 2000–3000 инженеров и ежегодных инвестиций в сотни миллионов долларов. При этом рынок быстро консолидировался: к 2014 году(время внедрения LTE) Qualcomm контролировала более 50% выручки, MediaTek и Intel делили ещё 30%, а всем остальным оставались крохи.

Broadcom — хрестоматийный пример. Компания инвестировала около $3 млрд в baseband-бизнес (включая покупку Beceem за $316 млн и активов Renesas Mobile за $164 млн), но так и не смогла выйти на долю рынка выше 5%. В 2014 году Broadcom закрыла подразделение, уволив 2500 сотрудников.

«Мы увидели ухудшающуюся экономику этого бизнеса: цены и маржи падали, а ряд игроков не заботились о прибыли и были готовы работать в убыток ради присутствия на рынке. Чтобы выжить, нужна была доля рынка в топ-2 или топ-3. Мы были номер четыре или пять — это нежизнеспособно».
— Скотт Макгрегор, CEO Broadcom (2015)

NVIDIA/Icera — похожая история. После покупки Icera за $367 млн в 2011 году NVIDIA выпустила Tegra 4i с интегрированным модемом i500, но не смогла привлечь ни одного крупного OEM. К 2015 году компания свернула baseband-разработку, сославшись на доминирование Qualcomm и агрессивное ценообразование MediaTek.

«Я пытался найти способы продолжить разработку модемов. После тщательного анализа стало ясно: это просто неосуществимо. Другие компании сталкиваются с теми же ограничениями».
— Дженсен Хуанг, CEO NVIDIA (2015)

2. Зависимость от 1–2 крупных клиентов

ST-Ericsson — классический кейс «смерти от зависимости». Совместное предприятие STMicroelectronics и Ericsson, созданное в 2009 году, к 2012 году потеряло двух ключевых клиентов: Nokia и Sony Ericsson. Nokia, переходя на Windows Phone и затем на Android, сократила заказы, а Sony Ericsson и вовсе исчезла как бренд.

В 2012 году ST-Ericsson потеряла почти $1 млрд, а в 2013 году совместное предприятие было ликвидировано. Общие убытки с 2009 по 2013 год составили $2,7 млрд при выручке $7,82 млрд.

«Главная причина провала — чрезмерная зависимость от Nokia и Sony Ericsson. Оба производителя пострадали от перехода рынка на Apple и Samsung, и это ударило по ST-Ericsson».
— аналитик Carnegie Bank (2013)

Ericsson попыталась продолжить бизнес самостоятельно, но к 2014 году закрыла и это направление, сославшись на «снижение цен, рост затрат на R&D и сужение рынка».

3. Патентная монополия Qualcomm

Qualcomm владела (и владеет) ключевыми патентами на CDMA, UMTS и LTE, что давало ей двойное преимущество:

Лицензионные отчисления с каждого проданного устройства (3–5% от цены смартфона).
Перекрёстное лицензирование: конкуренты вынуждены были покупать патенты у Qualcomm, чтобы легально выпускать свои чипы.

Это создавало «налоговый барьер»: даже если конкурент делал технически сопоставимый модем, его себестоимость оказывалась выше из-за патентных выплат.

NVIDIA в 2016 году даже подала иск против Qualcomm, утверждая, что та «незаконно раздавила» её baseband-бизнес (включая Icera) через злоупотребление доминирующим положением. Иск так и не привёл к восстановлению бизнеса, но показал, насколько патентная сила Qualcomm влияла на рынок.

4. Вертикальная интеграция OEM-производителей

К 2013–2015 годам крупнейшие OEM-производители начали разрабатывать собственные модемы:

Samsung — Exynos с интегрированными LTE-модемами.
Apple — переход на Qualcomm, а затем на собственные модемы (с 2023 года).
Huawei — HiSilicon Balong.
Xiaomi, OPPO, vivo — инвестиции в UNISOC и собственные R&D-центры.

Это сократило «открытый» рынок для независимых вендоров modem-чипов. Оставшиеся игроки (Qualcomm, MediaTek, UNISOC) боролись за оставшихся OEM, а мелкие компании просто не находили покупателей.

5. Ценовая война и «игроки, которым не важна прибыль»

Рынок LTE-модемов превратился в «красный океан» с агрессивным демпингом. MediaTek, Spreadtrum (UNISOC) и китайские вендоры готовы были работать с минимальной маржой ради доли рынка.

Broadcom прямо указывала на это в 2014 году:

«На рынке было несколько игроков, которым было всё равно, зарабатывают они или нет. У них были стратегические императивы присутствовать в этом бизнесе любой ценой. Broadcom — коммерческая компания, мы так не работаем».

Это создавало ситуацию, когда даже технологически продвинутые решения (например, NovaThor L8580 от ST-Ericsson с 28 нм FDSOI и LTE Cat. 4) не могли конкурировать по цене с более простыми чипами MediaTek и Qualcomm.

6. Неспособность выйти на «критическую массу»

Аналитики сходились во мнении: чтобы выжить на рынке baseband-модемов, нужна доля рынка не менее 10–15%, а лучше - 20%. Ниже этого порога R&D-затраты на новую генерацию (LTE-Advanced, Cat. 6/9/12, 5G) становились неподъёмными.GCT, Sequans, Altair выжили именно потому, что ушли в ниши (IoT, M2M, CPE), где требования ниже, а конкуренция слабее. Но в массовом сегменте смартфонов они не смогли набрать критическую массу и остались «вторым эшелоном».

7. Технологическая гонка: отставание на поколение = смерть

Рынок модемов развивался быстрее, чем рынок connectivity-чипов (Wi-Fi, Bluetooth). Если за одно поколение baseband (2–3 года) проходило два поколения connectivity, то интеграция их в один чип становилась проблемой: baseband отставал, а connectivity — нет.

Broadcom пыталась решить это через покупку Beceem и Renesas Mobile, но так и не смогла синхронизировать циклы разработки. В итоге компания продала/закрыла baseband-бизнес, сосредоточившись на Wi-Fi, Ethernet и других направлениях.

8. «Эффект домино»: закрытия порождали новые закрытия

Когда одна крупная компания уходила с рынка, это создавало цепную реакцию:

Поставщики IP и инструментов теряли клиентов.
Инженеры увольнялись и уходили в Qualcomm/MediaTek.
OEM-производители переставали сертифицировать «рискованные» чипы.

ST-Ericsson после закрытия в 2013 году оставила после себя «пустоту»: Ericsson попыталась продолжить, но к 2014 году закрыла и этот бизнес. Аналогично, после ухода Broadcom в 2014 году на рынке остались только Qualcomm, Intel, MediaTek и горстка нишевых игроков.

Intel: самый дорогой провал на рынке модемов

Intel — отдельная и, пожалуй, самая болезненная глава в истории baseband-рынка. Компания потратила на развитие модемного бизнеса более $10 млрд (включая покупку Infineon Wireless за $1,4 млрд в 2011 году), но в апреле 2019 года полностью вышла из сегмента смартфонных модемов, продав остатки Apple за $1 млрд — то есть с мульти-миллиардным убытком.

Почему Intel проиграл

1. Зависимость от одного клиента. К 2018 году Apple была фактически единственным крупным заказчиком смартфонных модемов Intel. Когда Apple заключила сделку с Qualcomm, Intel потеряла последний якорь.macrumors

«После объявления Apple и Qualcomm мы оценили перспективы заработка на поставках этой технологии для смартфонов и пришли к выводу, что просто не видим пути к прибыли».
— Боб Свон, CEO Intel (апрель 2019)

2. Технологическое отставание. По данным инсайдеров, Intel столкнулась с серьёзными проблемами при разработке 5G-модемов:

Тепловыделение: XMM 8160 перегревался и требовал сложной системы охлаждения.
Энергопотребление: 5G-модем Intel потреблял значительно больше, чем решения Qualcomm, что критично для смартфонов.
Сроки: Intel не успевала к релизу iPhone 2020 с готовым 5G-чипом.

3. Патентная война Qualcomm. Intel поддерживала Apple в судебном процессе против Qualcomm, надеясь, что победа Apple откроет рынок. Но когда Apple сдалась и подписала 6-летний договор с Qualcomm, Intel оказалась в изоляции.

«Intel не смогла преодолеть искусственные и непреодолимые барьеры для честной конкуренции, созданные схемой Qualcomm, и была вынуждена выйти с рынка в этом году».
— Роджерс, юрист Intel (декабрь 2019)

4. Экономика не складывалась. Даже с Apple в качестве единственного крупного клиента бизнес не был прибыльным. Intel оценивала общие затраты на разработку и acquisitions (Infineon, Beceem-конкуренты и т.д.) в $10+ млрд, а выручка так и не покрыла эти инвестиции.

Что осталось после Intel

Apple получила ~2200 инженеров, IP и оборудование для разработки собственных 5G-модемов (которые, появились в iPhone).
Intel сохранила R&D по 5G для PC, IoT, автомобилей и сетевой инфраструктуры, но полностью вышла из смартфонного сегмента.
Qualcomm укрепила монополию: после ухода Intel и Apple–Qualcomm settlement на рынке смартфонных модемов остались Qualcomm, MediaTek, Samsung и UNISOC.

Итог

Intel стала последним крупным игроком, который попытался бросить вызов Qualcomm на рынке smartphone modems — и проиграл. История Intel подтверждает общее правило: без доли рынка ≥15–20%, без 3–5 крупных OEM-клиентов и без способности выдерживать патентное давление Qualcomm baseband-бизнес обречён на убытки.

«В бизнесе смартфонных модемов стало очевидно: нет ясного пути к прибыльности и положительной отдаче».
— Боб Свон, CEO

Как превратить бинарный CP-лог модема SIMCom A7665E в читаемый

2026-08-29T19:53:33.456Z

Введение

Отладочные логи мобильных модемов часто выглядят как поток непонятных бинарных данных. Внутри могут находиться сообщения о регистрации в сети, выборе PLMN, параметрах serving cell, APN, IP-адресах и состоянии протоколов LTE. Однако без знания транспортного формата и таблицы сообщений прошивки этот поток практически бесполезен.

В этой статье разберём, как устроено распознавание debug-лога модема SIMCom A7665E на базе ASR «Crane» ASR1603. Цель — пройти весь путь от байтов, поступающих через USB, до человекочитаемой строки:

байтовый поток → бинарная запись → форматное сообщение → декодированные аргументы

Практически задача состоит из двух независимых частей:

определить границы бинарных записей;
понять смысл каждой записи по её идентификаторам и payload.

Первую проблему можно решить детерминированно. Вторая требует базы форматных строк, соответствующей конкретной сборке прошивки.

1. Исходные условия

В качестве устройства используется модем SIMCom A7665E

Важно не перепутать этот поток с Qualcomm DIAG. CP-log ASR имеет другой бинарный формат, поэтому инструменты, рассчитанные на Qualcomm DIAG, например qc_debug_monitor, его не распознают.

Итоговая архитектура декодера выглядит так:

/dev/ttyUSBx
     │
     │ AT+ECPLOG=1
     ▼
поток бинарных данных
     │
     ▼
asr_proto.py
байты → Record
     │
     ▼
asr_mdb.py
(msg_type, fmt_id) + payload → строка
     │
     ▼
asr_debug_monitor.py
захват, фильтрация, цветной вывод, replay

Такое разделение ответственности удобно по нескольким причинам:

транспортный парсер не зависит от базы форматов;
декодер семантики не зависит от последовательного порта;
один и тот же протокол можно использовать в CLI, web-мониторе или тестовой системе;
каждый слой можно тестировать отдельно.

2. Поиск CP-log-порта

Почему нельзя полагаться на `ttyUSB0`

После перезагрузки модема Linux может назначить интерфейсам другие имена:

до перезагрузки:     ttyUSB0, ttyUSB1, ttyUSB2
после перезагрузки:  ttyUSB3, ttyUSB4, ttyUSB5

Поэтому поиск порта по имени ненадёжен. Лучше использовать USB VID и номер интерфейса в USB-топологии.

В рассматриваемом устройстве CP-log находится на интерфейсе #2. В pyserial его можно найти по полю location:

from serial.tools import list_ports

MODEM_VID = 0x1e0e
DEBUG_IFACE = 2

def find_debug_port(iface=DEBUG_IFACE, vid=MODEM_VID):
    fallback = None

    for port in list_ports.comports():
        if port.vid != vid:
            continue

        location = port.location or ""

        if location.endswith(f":1.{iface}"):
            return port.device

        fallback = fallback or port.device

    return fallback

Ключевая проверка:

location.endswith(":1.2")

Номер ttyUSBx может измениться, а номер USB-интерфейса в конкретной композиции обычно остаётся постоянным.

Включение потока

CP-log не начинает передаваться автоматически. Сначала на тот же порт необходимо отправить AT-команду:

ENABLE_CMD = b"AT+ECPLOG=1\r\n"
DISABLE_CMD = b"AT+ECPLOG=0\r\n"

Пример открытия устройства:

import serial
import time

def open_device(device, baudrate=115200):
    ser = serial.Serial(device, baudrate, timeout=0.2)

    ser.reset_input_buffer()
    ser.write(ENABLE_CMD)
    ser.flush()

    time.sleep(0.4)

    # Удаляем эхо команды и текстовый ответ OK
    ser.reset_input_buffer()

    return ser

Здесь есть важная особенность: после AT+ECPLOG=1 модем сначала может вернуть обычный текстовый ответ:

AT+ECPLOG=1
OK

Затем начинается бинарный поток. Если не очистить входной буфер, парсер может попытаться интерпретировать ASCII-ответ как начало бинарной записи.

При завершении работы полезно отключить лог:

ser.write(DISABLE_CMD)
ser.flush()
time.sleep(0.1)
ser.reset_input_buffer()
ser.close()

3. Формат бинарной записи

Как была найдена граница сообщений

В дампе регулярно повторяется последовательность:

маленькое число → несколько нулей → полезная нагрузка

Это позволяет предположить, что первые два байта являются длиной записи в формате little-endian.

Алгоритм проверки простой:

прочитать первые два байта;
интерпретировать их как u16;
перейти вперёд на указанное количество байт;
проверить, похожи ли следующие два байта на очередную длину;
повторить процедуру до конца буфера.

Если цепочка проходит через весь дамп без рассинхронизации, гипотеза подтверждается.

Такой формат обладает свойством самосинхронизации: если в поток попал мусор, длина обычно выходит за разумные пределы, и парсер может начать поиск следующей потенциальной записи.

Заголовок

Аргументы сообщения

В Python структура описывается так:

import struct

HDR = struct.Struct("<HHHHHHI")
HDR_LEN = HDR.size  # 16 байт

Порядок полей:

length, flags, channel, seq, msg_type, fmt_id, timestamp

Таймстамп

Поле timestamp не является временем в микросекундах или миллисекундах. Экспериментальное сопоставление с известными интервалами показало, что устройство использует частоту 32768 Гц:

TS_HZ = 32768

def timestamp_seconds(timestamp):
    return timestamp / TS_HZ

Например:

timestamp = 2 572 383
time      = 2 572 383 / 32 768 ≈ 78.503 с

Это абсолютное время работы устройства до момента включения ECPLOG. В пользовательском интерфейсе удобнее вычесть timestamp первой записи и показывать относительное время:

[+0.000000] ...
[+0.003174] ...
[+0.006287] ...

4. Потоковый парсер

Парсер должен корректно работать в двух режимах:

с готовым бинарным файлом;
с живым потоком, где одна запись может прийти несколькими частями.

Разбор одной записи

MIN_REC = 16
MAX_REC = 16384

def take_record(buf, offset, flush=False):
    end = len(buf)

    if offset + 2 > end:
        return None, offset, True

    length = buf[offset] | (buf[offset + 1] << 8)

    if length < MIN_REC or length > MAX_REC:
        # Некорректная длина: пробуем синхронизацию со следующего байта
        return None, offset + 1, False

    if offset + length > end:
        if flush:
            # Финальный обрезанный хвост
            return None, offset + 1, False

        # Для живого потока ждём следующую порцию данных
        return None, offset, True

    fields = HDR.unpack_from(buf, offset)

    record = {
        "length": fields[0],
        "flags": fields[1],
        "channel": fields[2],
        "seq": fields[3],
        "msg_type": fields[4],
        "fmt_id": fields[5],
        "timestamp": fields[6],
        "payload": bytes(
            buf[offset + HDR_LEN:offset + length]
        ),
        "offset": offset,
    }

    return record, offset + length, False

Инкрементальный режим

class StreamParser:
    def __init__(self):
        self.buffer = bytearray()

    def feed(self, chunk):
        self.buffer.extend(chunk)

        offset = 0
        end = len(self.buffer)

        while offset < end:
            record, next_offset, need_more = take_record(
                self.buffer,
                offset,
                flush=False
            )

            if need_more:
                break

            offset = next_offset

            if record is not None:
                yield record

        if offset:
            del self.buffer[:offset]

        # Защита от бесконечного роста при потере синхронизации
        if len(self.buffer) > 1 << 20:
            del self.buffer[:len(self.buffer) - (1 << 16)]

Если в середине записи пришёл только заголовок и часть payload, она остаётся во внутреннем буфере. Следующий вызов feed() продолжает разбор.

5. Разбор первой записи

Рассмотрим пример записи размером 34 байта:

22 00 | 00 00 | 00 00 | 01 00 | 2b 00 | 96 14 |
5f 40 27 00 |
02 00 63 00 78 08 12 00 01 00 00 00 02 00 00 00 00 00

Разметка:

length     flags      channel    seq
22 00      00 00      00 00      01 00

msg_type   fmt_id     timestamp
2b 00      96 14      5f 40 27 00

payload
02 00 63 00 78 08 12 00 01 00 00 00 02 00 00 00 00 00

В данном случае msg_type = 0x2b соответствует текстовой записи. Однако payload содержит бинарный префикс, поэтому его нельзя безусловно интерпретировать как обычную C-строку.

6. Типы сообщений

Поле msg_type определяет, как нужно обрабатывать запись:

TYPE_TEXT = 0x2B

TYPE_NAMES = {
    0x2B: "TEXT",
    0x1D: "TRACE",
    0x17: "SIGNAL",
    0x1A: "T1A",
    0x16: "T16",
    0x0E: "T0E",
    0x03: "T03",
}

TEXT-записи

TEXT-записи уже содержат готовые фрагменты текста. Их можно декодировать без базы форматных строк, извлекая печатные ASCII-последовательности.

def printable_runs(data, min_run=3):
    runs = []
    current = bytearray()

    for byte in data:
        if 32 <= byte < 127:
            current.append(byte)
        else:
            if len(current) >= min_run:
                runs.append(current.decode("latin-1"))
            current.clear()

    if len(current) >= min_run:
        runs.append(current.decode("latin-1"))

    return runs

Для текстовых записей достаточно использовать короткий порог:

runs = printable_runs(payload, min_run=3)
text = " ".join(runs)

Terse-записи

Terse-записи содержат не сам текст, а:

идентификатор форматной строки;
бинарные аргументы.

Их можно представить как удалённый вызов:

diagPrintf("Serving Cell: rsrp = %d", rsrp);

На провод передаются только:

fmt_id + бинарное значение rsrp

Сама строка формата находится в базе данных прошивки.

7. Записи `file:line` без базы

Часть assert-сообщений содержит имя исходного файла и номер строки:

rrcdsutils.c\0\xa2\x0a\x00\x00

То есть payload имеет вид:

имя файла + NUL + номер строки u32

Такой формат можно распознать независимо от версии базы:

import re

SOURCE_RE = re.compile(
    r"\.(c|h|cpp|cc|cxx)$",
    re.IGNORECASE
)

def decode_file_line(payload):
    nul = payload.find(b"\x00")

    if nul < 4:
        return None

    raw_name = payload[:nul]

    if not all(32 <= byte < 127 for byte in raw_name):
        return None

    name = raw_name.decode("latin-1")

    if not SOURCE_RE.search(name):
        return None

    name = name.replace("\\", "/").rsplit("/", 1)[-1]

    if len(payload) < nul + 5:
        return None

    line = int.from_bytes(
        payload[nul + 1:nul + 5],
        "little"
    )

    return name, line

Пример результата:

rrcdsutils.c:2722

Строгая проверка необходима: случайный бинарный payload тоже может содержать печатные байты. Условие с расширением исходного файла снижает вероятность ложного распознавания.

8. База форматных строк

Зачем нужна база

Terse-сообщение само по себе неполно. Например, запись может содержать:

msg_type = 0x1d
fmt_id   = 0x0b3d
payload  = бинарные аргументы

Чтобы понять, что означают эти байты, нужна запись из базы:

"updates ( %ld , %d ) measUpdateTime: ( 0x%lx ) , ( rsrp = %d )"

В случае ASR используется база cp_MDB.txt формата CATStudio TxtDbHeader.

Секции базы

Наиболее важны три секции:

EnumValsRes — таблица форматных строк;
Enums — преобразование числовых значений в имена;
Signals — описания структур для %S{...}.

Извлечение секций

В начале файла находится индекс с байтовыми смещениями:

EnumValsRes,1234,987654
Enums,987654,1048576
Signals,1048576,4567890

Пример загрузки:

def parse_sections(raw):
    marker = raw.find(b"<end>")

    if marker < 0:
        return {}

    header = raw[:marker].decode(
        "latin-1",
        "replace"
    )

    sections = {}

    for line in header.splitlines():
        parts = line.split(",")

        if len(parts) != 3:
            continue

        name, start, end = parts

        if start.isdigit() and end.isdigit():
            sections[name] = (
                int(start),
                int(end)
            )

    return sections

Таблица форматных строк

Строка в EnumValsRes выглядит примерно так:

table,id,flag,flag,GROUP,MODULE,NAME,diagPrintf("формат", args);

Запятые могут встречаться внутри самой форматной строки, поэтому разделять строку нужно только по первым семи запятым:

parts = line.split(",", 7)

Для поддержки всех вариантов вызова используется регулярное выражение:

import re

FORMAT_RE = re.compile(
    r'diag(?:Text|Struct)?Printf\s*\('
    r'\s*"((?:[^"\\]|\\.)*)"'
)

Оно распознаёт:

diagPrintf(...)
TextPrintf(...)
StructPrintf(...)

Это исправляет важную ошибку: если искать только diagPrintf, записи diagTextPrintf и diagStructPrintf останутся без форматной строки и будут ошибочно показаны как hex.

9. Подбор подходящей базы

База форматных строк должна соответствовать сборке прошивки. Даже если две версии используют один и тот же чипсет, идентификаторы сообщений могут отличаться.

Для выбора наиболее подходящей базы удобно использовать измеримые метрики.

Key-match

Первая метрика — доля пар (msg_type, fmt_id), найденных в базе:

distinct_keys = {
    (record["msg_type"], record["fmt_id"])
    for record in terse_records
}

matched = {
    key for key in distinct_keys
    if key in mdb_entries
}

key_match = len(matched) / len(distinct_keys)

Эта метрика показывает, совпадает ли схема идентификаторов.

Scalar-clean

Вторая метрика проверяет, удалось ли полностью разобрать аргументы скалярных сообщений без маркера <?>.

scalar-clean =
число сообщений без underflow /
общее число проверяемых сообщений

Она проверяет уже не только идентификаторы, но и ширины аргументов.

10. Главная особенность: `int` занимает 16 бит

Это наиболее нетривиальная часть реверса.

Симптом

При стандартной интерпретации printf-аргументов каждый %d ожидает 4 байта. Но результаты выглядели неправильно:

rsrp = 104922215

или:

rsrp = <?>

Причина — payload заканчивался раньше, чем ожидал декодер.

Проверка гипотезы

Для каждого сообщения можно вычислить ожидаемый размер аргументов и сравнить его с фактической длиной payload:

def fit_score(records, short_width):
    exact = 0
    underflow = 0
    leftover = 0

    for record in records:
        fmt = get_format(record)

        if not fmt:
            continue

        required = calculate_argument_size(
            fmt,
            short_width=short_width,
            long_width=4
        )

        actual = len(record["payload"])

        if required == actual:
            exact += 1
        elif required > actual:
            underflow += 1
        else:
            leftover += 1

    return exact, underflow, leftover

При ширине 2 байта количество underflow уменьшается примерно в пять раз.

Практическое правило

Для ASR-терс-сообщений используется следующее соответствие:

if conversion in "eEfFgG":
    width = 8 if length in ("l", "ll", "L") else 4
elif conversion == "p":
    width = 4
elif length == "ll":
    width = 8
elif length == "hh":
    width = 1
elif length == "l":
    width = 4
elif length in ("L", "z", "j", "t"):
    width = 4
elif length == "h":
    width = 2
else:
    width = 2

Значения %d и %i необходимо интерпретировать как знаковые:

value = int.from_bytes(
    payload[pos:pos + width],
    "little",
    signed=conversion in "di"
)

11. Сквозной пример декодирования

Рассмотрим запись:

msg_type = 0x1d
fmt_id   = 0x0b3d
payload  = e40c0000 d100 021c0f00 61e4

Форматная строка:

"updates ( %ld , %d ) 's measUpdateTime: "
"( 0x%lx ) , ( rsrp = %d ) "

Результат:

updates ( 3300, 209 ) measUpdateTime:
( 0xf1c02 ), ( rsrp = -7071 )

При ошибочной ширине %d = 4 байта декодер начал бы читать следующие аргументы с неправильных смещений и в итоге получил бы <?>.

12. Поддержка `%S{...}` и структур

Некоторые диагностические сообщения передают не скаляры, а структуры:

%S{EmmPrintDebugInfoInd_MobileId}

Описание полей находится в секции Signals.

Минимальная модель структуры:

structs = {
    "Example": [
        ("field_a", "int", 1, ""),
        ("field_b", "enum", 1, "StateType"),
        ("field_c", "pointer", 1, ""),
    ]
}

Декодер обрабатывает:

скалярные поля;
enum;
указатели;
вложенные структуры;
массивы;
рекурсию.

Упрощённая схема:

def decode_struct(name, payload, pos=0, depth=0):
    if depth > 6:
        return f"{{{name}?}}", pos

    fields = structs.get(name)

    if fields is None:
        return f"{{{name}?}}", pos

    result = []

    for field_name, field_type, count, detail in fields:
        values = []

        for _ in range(count):
            if field_type == "enum":
                value = read_u32(payload, pos)
                pos += 4
                value = enums.get(detail, {}).get(
                    value,
                    str(value)
                )

            elif field_type == "pointer":
                value = read_u32(payload, pos)
                pos += 4
                value = hex(value)

            elif field_type == "int":
                value = read_u32(payload, pos, signed=True)
                pos += 4

            elif detail in structs:
                value, pos = decode_struct(
                    detail,
                    payload,
                    pos,
                    depth + 1
                )

            else:
                value = "<?>"

            values.append(value)

        rendered = (
            values[0]
            if count == 1
            else "[" + ",".join(map(str, values)) + "]"
        )

        result.append(f"{field_name}={rendered}")

    return "{" + ", ".join(result) + "}", pos

Почему структуры могут декодироваться неверно

Секция Signals из близкой базы может не полностью соответствовать конкретной сборке модема. Например, поля большой EMM-структуры могут иметь другую раскладку или тип.

В результате появляются значения вроде:

mcc = -1727901696

В таких случаях проблема находится не в транспортном парсере, а в несовпадении описания структуры. Исправить её можно только точной базой cp_MDB.txt для конкретной версии прошивки.

13. Приоритет способов декодирования

Одна запись может быть распознана несколькими способами. Поэтому форматтеру нужен строгий порядок выбора:

1. TEXT-запись
   └─ готовая строка, база не нужна

2. file:line
   └─ имя исходного файла и номер строки

3. terse-декодирование через MDB
   └─ форматная строка + бинарные аргументы

4. встроенная ASCII-строка
   └─ длинный печатный фрагмент внутри payload

5. raw hex
   └─ неизвестный или неподдерживаемый payload

Формат вывода может выглядеть так:

[+0.000000] [TEXT] +ZDON
[+0.003174] [NAS] New Selected PLMN (250,1)
[+0.006287] [RRC] Serving Cell rsrp=-110.5 dBm
[+0.009460] [ASSERT] rrcdsutils.c:2722

Большие необработанные записи лучше скрывать по умолчанию и включать отдельным флагом:

./asr_debug_monitor.py --replay capture.bin -t

где -t показывает terse-записи, а:

./asr_debug_monitor.py --replay capture.bin -a

показывает все записи, включая объёмные signal-сообщения.

14. Контроль потерь по `seq`

Поле seq — 16-битный счётчик записей. Оно позволяет заметить потерю данных на USB или переполнение буфера.

Поскольку счётчик циклический, сравнение выполняется по модулю 2162^{16}216:

def sequence_gap(previous, current):
    return (current - previous - 1) & 0xFFFF

Практическая проверка:

gap = (record.seq - last_seq - 1) & 0xFFFF

if 0 < gap < 0x8000:
    dropped += gap

Ограничение gap < 0x8000 нужно, чтобы отличать нормальное переполнение счётчика от большого обратного скачка.

В интерфейсе можно показывать:

[warning] потеряно записей: 12

Это особенно полезно при высокоскоростном логе, когда USB-порт, пользовательский процесс или внутренний буфер не успевают обработать весь поток.

15. Верификация

Декодер необходимо проверять на двух уровнях.

Автономные тесты

Полезно протестировать отдельно:

разбор заголовка;
length-framing;
повторную синхронизацию после мусора;
инкрементальный StreamParser;
TEXT-записи;
file:line;
разбор MDB;
%S{...};
%e{...};
16-битные аргументы.

В исходном проекте такой набор из девяти тестов проходит на синтетической базе и искусственно сформированных записях.

Сквозная проверка

Затем необходимо проверить полный путь:

A7665E
  → USB CP-log
  → StreamParser
  → MDB decoder
  → человекочитаемый вывод

В корректно декодированных сообщениях должны распознаваться, например:

+ZDON;
выбранная PLMN;
serving cell;
RSRP и RSRQ;
APN;
IP-адрес;
события NAS и RRC;
сообщения IPC между L1 и protocol stack.

16. Ограничения метода

Даже при правильно найденном транспортном формате часть сообщений может оставаться неполностью декодированной.

Особенно важно различать ошибки разных уровней:

неправильная длина записи
    → проблема транспортного парсера

правильная запись, но <?>
    → проблема формата или ширины аргумента

правильный текст, но неверные поля структуры
    → несовпадение Signals с конкретной прошивкой

Транспортный формат при этом может быть полностью понятен, даже если семантическая расшифровка остаётся неполной.

17. Запуск декодера

Примерный набор команд:

cd /home/sam/work/modems_debug/asr_debug

Живой захват с автоматическим поиском порта:

./asr_debug_monitor.py

Разбор сохранённого файла:

./asr_debug_monitor.py \
    --replay boot_registration.bin

Разбор terse-записей:

./asr_debug_monitor.py \
    --replay boot_registration.bin \
    -t

Вывод всех записей:

./asr_debug_monitor.py \
    --replay boot_registration.bin \
    -a

Использование точной базы:

./asr_debug_monitor.py \
    -m /path/to/exact/cp_MDB.txt

Для захвата, переживающего ребут модема, нужен внешний wrapper:

дождаться появления нужного USB-интерфейса;
открыть порт;
отправить AT+ECPLOG=1;
записывать необработанный поток;
обнаружить исчезновение порта;
дождаться повторной USB-энумерации;
открыть новую сессию в отдельном файле.

Так можно захватывать загрузку модема с самого начала, даже если во время ребута меняются имена ttyUSBx.

Заключение

Распознавание бинарного CP-лога ASR состоит из нескольких независимых уровней:

USB-порт
  → AT+ECPLOG=1
  → length-framing
  → 16-байтный заголовок
  → msg_type + fmt_id
  → база форматных строк
  → декодирование printf-аргументов
  → структуры, enum и timestamp
  → читаемый трейс

Самая важная практическая находка — нестандартная упаковка аргументов: обычные %d, %u и %x в terse-сообщениях ASR занимают 2 байта, а %l... — 4 байта. Без этого правила идентификаторы сообщений могут находиться правильно, но значения будут «плыть», а декодер будет регулярно выдавать <?>.

Второй важный вывод — транспорт и семантику нужно разрабатывать отдельно. Формат записи можно восстановить и протестировать независимо от базы. А база, в свою очередь, может заменяться без изменений в протоколе и потоковом парсере.

Для полного покрытия остаётся получить точную cp_MDB.txt под прошивку A7665M5_B01V01. После этого должны исчезнуть ошибки в больших структурах, неизвестные enum и большая часть необработанных бинарных хвостов.

Как используются данные SIM‑карты в GSM (2G): аутентификация, ключи, IMSI, A3/A8

2026-08-15T18:36:57.708Z

Всем привет! В GSM (2G) SIM‑карта хранит постоянный секретный ключ абонента Ki и идентификатор IMSI; при регистрации в сети используется механизм «вызов‑ответ»: сеть посылает случайное число RAND, SIM вычисляет подписанный ответ SRES = A3(Ki, RAND) и сеансовый ключ шифрования Kc = A8(Ki, RAND), после чего сеть проверяет SRES и при успехе включает шифрование A5.

Важно: Ki никогда не передаётся по радиоинтерфейсу и не выводится из SIM; вся криптография «вызов‑ответ» выполняется внутри SIM.jucs+2

2. Роли сетевых элементов (кратко)

MS (Mobile Station) = ME (телефон) + SIM.
BTS/BSC — радиодоступ.
MSC/VLR — коммутация и локальное управление сессиями; VLR хранит «триплеты» аутентификации для абонента.
HLR — домашний реестр абонентов.
AuC (Authentication Center) — генерирует RAND, SRES, Kc (триплеты) на основе IMSI и Ki.

3. Протокол аутентификации GSM (2G): пошагово

Ниже — упрощённая последовательность при регистрации/доступе к услугам.

text[MS/SIM]                         [MSC/VLR]                         [HLR/AuC]
    |                                |                                |
    | 1. Location Update / CM Service Request (IMSI или TMSI)         |
    |--------------------------------------------------------------->|
    |                                | 2. Запрос триплетов для IMSI   |
    |                                |------------------------------>|
    |                                | 3. Возврат N триплетов         |
    |                                | (RAND_i, SRES_i, Kc_i)         |
    |                                |<------------------------------|
    |                                |                                |
    | 4. AUTHENTICATION REQUEST      |                                |
    |    (RAND)                      |                                |
    |<-------------------------------|                                |
    | 5. SIM: SRES' = A3(Ki, RAND)   |                                |
    |     Kc'   = A8(Ki, RAND)       |                                |
    | 6. AUTHENTICATION RESPONSE     |                                |
    |    (SRES')                     |                                |
    |------------------------------>|                                |
    |                                | 7. Проверка: SRES' == SRES?    |
    |                                |    Если да → аутентификация OK |
    | 8. Cipher Mode Command (A5/x)  |                                |
    |<-------------------------------|                                |
    | 9. Включение шифрования A5/x с Kc'                               |
    |<================================================================>|

Ключевые моменты:

Сеть заранее получает от AuC «триплеты» (RAND, SRES, Kc) для данного IMSI; при аутентификации она посылает только RAND.
SIM вычисляет SRES' и Kc' по тем же формулам; VLR сравнивает SRES' с ожидаемым SRES.
После успеха сеть инициирует Cipher Mode Command и далее трафик шифруется A5/x с ключом Kc.

4. Алгоритмы A3 и A8: что именно считается

Формально стандарт GSM не фиксирует одну конкретную реализацию A3/A8; операторы выбирают алгоритм (часто COMP128‑1/2/3, milenage‑подобные варианты в 2G‑совместимых реализациях и др.).

A3: SRES = A3(Ki, RAND) → 32‑битный ответ.
A8: Kc = A8(Ki, RAND) → 64‑битный сеансовый ключ для A5/x.

На практике A3 и A8 часто реализованы как единая функция, выдающая (SRES, Kc) из (Ki, RAND).

5. Роль IMSI и почему он важен

IMSI используется для идентификации абонента в HLR/AuC и получения правильного Ki (и триплетов).
При первой регистрации в новой зоне MS обычно передаёт IMSI (если нет валидного TMSI), что делает IMSI видимым для любой базовой станции в радиусе.

В дальнейшем сеть старается использовать TMSI вместо IMSI для конфиденциальности, но IMSI всё равно может быть запрошен (например, при сбоях или специальных процедурах).
TMSI (Temporary Mobile Subscriber Identity) — это временный идентификатор абонента, который сеть выдаёт мобильному устройству после успешной регистрации, чтобы вместо постоянного IMSI использовать его в радиоканале для повышения конфиденциальности.

6. Риски безопасности GSM (2G), связанные с SIM и аутентификацией

GSM (2G) имеет ряд фундаментальных ограничений, которые напрямую касаются использования данных SIM:

Односторонняя аутентификация

Сеть аутентифицирует телефон (MS), но телефон не аутентифицирует сеть.
Это позволяет IMSI‑catcher'у (фейковой базовой станции) притворяться «легальной» сетью: телефон отправляет IMSI/TMSI, проходит «аутентификацию» у злоумышленника, а трафик может не шифроваться или шифроваться слабым алгоритмом.

Слабость шифрования A5/1 (и A5/2)

A5/1 (64‑битный ключ Kc) уязвим к атакам по заранее вычисленным таблицам (rainbow tables); практическая расшифровка возможна за секунды–минуты на обычном железе.
A5/2 ещё слабее и практически не защищает.
Злоумышленник может принудительно переключить сессию на A5/0 (без шифрования) или слабый A5/x.

Зависимость от реализации A3/A8

Ранние популярные реализации (например, COMP128‑1) имели криптографические слабости, позволяющие при достаточном числе запросов извлекать Ki.
Даже при более стойких A3/A8, 32‑битный SRES и 64‑битный Kc ограничивают криптостойкость по современным меркам.

Перехват IMSI

Поскольку IMSI передаётся в открытом виде при первой регистрации, IMSI‑catcher может собирать IMSI всех устройств в зоне покрытия.

Эти ограничения — причина, по которой в 3G/4G/5G введена взаимная аутентификация (сеть тоже доказывается абоненту), более длинные ответы (RES вместо SRES), ключи CK/IK и более стойкие алгоритмы (Milenage, AES‑based и др.).

7. Сводная схема «данные SIM → параметры сессии»

textSIM (Ki, IMSI, A3/A8)
       │
       │ IMSI → HLR/AuC → выбор Ki
       │
       └─► AuC: для каждого RAND_i
               SRES_i = A3(Ki, RAND_i)
               Kc_i   = A8(Ki, RAND_i)
               триплет (RAND_i, SRES_i, Kc_i) → VLR

При аутентификации:
  VLR → MS: RAND
  SIM: SRES' = A3(Ki, RAND)
       Kc'   = A8(Ki, RAND)
  MS → VLR: SRES'
  VLR: если SRES' == SRES → OK, шифрование A5/x с Kc'

Данные вещательных каналов сотовой вышки (2G/GSM и LTE): что можно получить и как декодировать

2026-08-03T07:11:42.451Z

Сотовая вышка (BTS в 2G, eNodeB в LTE) непрерывно передаёт в эфир «системную информацию» — набор параметров, которые нужны телефону (UE), чтобы обнаружить сеть, синхронизироваться и подготовиться к подключению. Это не «перехват трафика» — это открытые широковещательные (broadcast) данные, которые предназначены для приёма всеми устройствами в зоне покрытия. Их декодирование полностью пассивно, законно в большинстве юрисдикций и не затрагивает трафик абонентов.

Ниже — какие каналы есть, что они несут и что из этого можно понять о вышке и сети.

1. Что вообще вещает вышка

Любая вышка передаёт на нисходящей частоте (downlink) набор логических каналов. Для пассивного наблюдателя важны два класса:

Каналы синхронизации — позволяют обнаружить сигнал, получить тайминг и идентификатор соты.
Вещательные каналы (BCCH в 2G, BCH/DL-SCH в LTE) — несут системную информацию (System Information) с параметрами сети.

Телефон при включении делает ровно то же самое: ищет сигнал синхронизации, читает системную информацию и решает, можно ли подключиться. С помощью SDR (Software Defined Radio) и открытых инструментов этот процесс можно повторить без телефона.

2. GSM (2G)

Каналы и сообщения

Вещательные данные GSM передаются на BCCH (Broadcast Control Channel), который передаётся непрерывно и служит стабильным опорным «маяком» соты. Основное содержимое BCCH — это сообщения System Information (SI), описанные в ETSI TS 144 018 (3GPP TS 44.018).

Что можно извлечь из BCCH

MCC (Mobile Country Code) — страна оператора
MNC (Mobile Network Code) — сам оператор
LAC (Location Area Code) — код зоны местоположения
Cell ID (CI) — идентификатор соты → вместе с MCC+MNC+LAC+CI образует CGI (Cell Global Identity)
ARFCN — номер радиоканала → пересчитывается в частоту
BSIC (Base Station Identity Code) — цветовой код вышки
CCCH конфигурация — сколько каналов paging, AGCH и т.д.
Параметры RACH — как телефону запрашивать доступ
Параметры выбора соты — минимальный уровень приёма (C1/C2), приоритеты
Список соседей — частоты соседних сот (для handover/reselection)
Признак GPRS/EDGE — поддерживает ли сота пакетную передачу
Cell Barring — заблокирована ли сота для доступа
Информация о 3G-соседях — частоты UMTS

Синхронизация

До чтения BCCH нужно сначала найти сигнал. В GSM для этого служат:

FCCH (Frequency Correction Channel) — чистый синус на фиксированном смещении, позволяет подстроить частоту приёмника.
SCH (Synchronisation Channel) — несёт BSIC и номер кадра, позволяет выровнять тайминг.

3. LTE (4G)

Каналы и сообщения

В LTE системная информация разделена на MIB (Master Information Block) и набор SIB (System Information Blocks), описанные в 3GPP TS 36.331.

MIB

Передаётся на PBCH (Physical Broadcast Channel) с периодичностью 40 мс (с повторениями каждые 10 мс). Содержит самый минимум:

DL Bandwidth соты (в числе Resource Blocks: 1.4 / 3 / 5 / 10 / 15 / 20 МГц)
PHICH конфигурация
SFN (System Frame Number)

SIB1

Передаётся на DL-SCH с периодичностью 80 мс (с повторениями). Несёт:

PLMN identity list (MCC+MNC, может быть несколько)
Tracking Area Code (TAC)
Cell Identity — 28-битный E-UTRAN Cell Identifier (ECI). В макросетях часто раскладывается на eNodeB ID (старшие 20 бит) и локальный/секторный Cell ID (младшие 8 бит), но это не универсальное правило
Cell bar status (доступна ли сота)
Cell selection info (минимальный требуемый уровень приёма, Q-RxLevMin)
p-Max — максимальная разрешённая мощность UE
Frequency band indicator
TDD конфигурация (если TDD)
SI-window length и schedulingInfoList — расписание остальных SIB
System info value tag — версия информации

Остальные SIB

Передаются в сообщениях SystemInformation (SI) по расписанию из SIB1:

SIB2

Общая конфигурация радио: параметры RACH, PRACH, UL-частота, ширина UL-канала

SIB3

Параметры reselection внутри той же частоты

SIB4

Информация о соседях intra-frequency

SIB5

Информация о соседях inter-frequency (другие частоты LTE)

SIB6

Информация о соседях 3G (UTRA)

SIB7

Информация о соседях 2G (GERAN)

SIB8

Информация о соседях CDMA2000

SIB9

Home eNodeB identifier (femtocell)

SIB10

ETWS — первичное уведомление (Earthquake & Tsunami Warning)

SIB11

ETWS — вторичное уведомление

SIB12

CMAS — коммерческие предупреждения (Cell Broadcast)

SIB13

MBMS/MBSFN-конфигурация

SIB14

Extended Access Barring (EAB)

SIB15

MBMS Service Area Info

SIB16

Информация о времени (GPS/UTC)

4. Как это декодируется на практике (концептуальный пайплайн)

textSDR-приёмник (I/Q) → настройка на частоту → синхронизация → демодуляция → L2/L3 декодирование → Wireshark / ASN.1

Инструменты для GSM (2G)

gr-gsm (GNU Radio GSM decoder) — основной инструмент. Компоненты:

grgsm_scanner — сканирование эфира, поиск вышек, вывод ARFCN, BSIC, Cell ID
grgsm_capture — запись сигнала в .cfile
grgsm_decode — декодирование BCCH, SDCCH и др. → GSMTAP в Wireshark
grgsm_livemon — интерактивный мониторинг одного канала в реальном времени

Wireshark — анализ декодированных пакетов с фильтром gsmtap
DragonOS — готовый Linux-дистрибутив со всем предустановленным

(gr-gsm Wiki: Usage, RTL-SDR Tutorial)

Инструменты для LTE (4G)

srsRAN (бывший srsLTE) — открытый стек 4G/5G. Утилита cell_search находит соты и получает параметры из MIB; для декодирования SIB нужны специальные receive-only конфигурации/примеры srsRAN, LTE-Cell-Scanner или обёртки вроде lte-sib-parser. srsue в режиме только приёма может парсить SIB2–SIB6.
LTE-Cell-Scanner — OpenCL-ускоренный сканер от JiaoXianjun: от I/Q-сэмплов до SIB-сообщений в ASN.1. Поддерживает FDD и TDD, RTL-SDR/HackRF/BladeRF.
lte-sib-parser — обёртка над cell_search и srsue для рекурсивного сканирования по SIB5.
free5GRAN — для 5G NR (MIB + SIB1).

(LTE-Cell-Scanner на GitHub, srsRAN docs, lte-sib-parser)

Что это даёт на практике

Идентификация оператора и страны по MCC+MNC.
Картирование покрытия — зная Cell ID + частоту + уровень сигнала, можно составить карту расположения и охвата базовых станций (без доступа к базам операторов). Сторонние проекты вроде OpenCelliD и CellMapper агрегируют именно такие данные.
Понимание топологии сети — какие соты являются соседями, какие частоты используются в зоне, какие поколения (2G/3G/LTE) присутствуют.
Оценка нагрузки — косвенно, по количеству paging-сообщений (но это уже не чисто broadcast, аpaging-канал, требующий чуть более активного прослушивания CCCH).
Проверка конфигурации — для исследовательских и образовательных целей: какая ширина канала, какие параметры RACH, закрыта ли сота и т.д.
Косвенная оценка активности — по объёму paging-трафика можно грубо судить о нагрузке, но это не системная информация и не позволяет отслеживать конкретных абонентов.

6. Чего из broadcast-данных получить нельзя

Важно зафиксировать границы:

GPS-координаты вышки не передаются в эфир. Координаты можно определить только косвенно — по триангуляции сигнала или по внешним базам данных (OpenCelliD).
Содержимое звонков, SMS и интернет-трафика — не относится к broadcast и может быть зашифровано. В GSM может использоваться A5/0 (без шифрования), A5/1 или A5/3; в LTE — SNOW 3G или AES. Перехват и расшифровка трафика выходят за рамки данной заметки.
IMSI абонентов не передаётся в broadcast/System Information. В 2G/3G/LTE постоянный идентификатор может появляться в отдельных процедурах идентификации до установления защиты, но это не вещательные данные. В 5G для этого используется SUCI.
Точная нагрузка/количество абонентов — broadcast не несёт такой информации. Paging-канал может дать лишь грубую оценку совокупной активности сети и не является средством отслеживания конкретных абонентов.
Точное местоположение абонента — требует данных из ядра сети (core network) или активного слежения за конкретным устройством, что выходит далеко за рамки пассивного декодирования вещательных каналов.

POLQA и с чем его едят

2026-07-18T18:53:47.479Z

Привет всем! Сегодня постараюсь рассказать о POLQA.
POLQA расшифровывается как Perceptual Objective Listening Quality Analysis. Это full-reference метод: он сравнивает эталонный речевой сигнал с ухудшенной версией после прохождения через сеть, кодек или устройство, а затем вычисляет оценку, близкую к MOS — Mean Opinion Score. Проще говоря, POLQA пытается математически смоделировать то, как человеческое ухо и восприятие оценивают качество речи.

Зачем он нужен

Главная ценность POLQA в том, что он помогает измерять качество голоса воспроизводимо и сравнимо между лабораториями, устройствами и сценариями тестирования. Его используют для бенчмаркинга сетей, проверки кодеков, оптимизации VoIP/VoLTE и диагностики проблем с голосом в канале связи. Это особенно важно, когда качество портят не только потери пакетов, но и джиттер, компенсация задержек, time-scaling, шумоподавление и другие современные механизмы обработки.

Что было раньше

До POLQA в инженерной практике использовали разные методы объективной оценки качества речи, включая простые энергетические и шумовые метрики, а также более продвинутые психоакустические модели; однако они либо слабо коррелировали с субъективным восприятием, либо были ограничены узким классом искажений. Затем появился PESQ, который стал важным шагом вперед благодаря моделированию слухового восприятия.

Как возник POLQA

POLQA создавался как ответ на эти ограничения, то есть преемник PESQ, с акцентом на более точное моделирование восприятия речи в условиях современных телекоммуникаций. PESQ был спроектирован в первую очередь для узкополосной телефонной речи и сравнительно стабильных соединений, а не для современных сетей с переменной задержкой, джиттером и более широким частотным диапазоном. PESQ хорошо решал задачу оценки качества для классических телефонных и кодековых сценариев, но в VoIP и IP-сетях сигнал часто сталкивается с непостоянной задержкой и адаптацией jitter buffer, из-за чего точное выравнивание эталонного и тестового сигнала становится сложнее. Кроме того, в новых сетях ухудшения связаны не только с кодированием, но и с пакетными потерями, перепаковкой, временными сдвигами и другими эффектами передачи по IP, которые выходят за рамки более ранней модели применения PESQ

История создания

Работы над POLQA начались в ITU-T Study Group 12 в 2006 году под рабочим названием P.OLQA. В 2009–2010 годах прошёл конкурс кандидатов. Лучшие модели от трёх компаний — OPTICOM (Германия), SwissQual (Rohde & Schwarz, Швейцария) и TNO (Нидерланды) — были объединены в единый алгоритм.

Первая редакция — 2011 год.
Вторая (исправления и улучшения) — 2014 год.
Третья (POLQA v3 / Edition 3) — 2018 год (актуальная), с поддержкой Full Band и оптимизацией под современные сети.

POLQA разработан специально для новых реалий: VoIP, HD Voice, 3G/4G/VoLTE, 5G, современных кодеков (EVS, Opus и др.).

Основные характеристики

Тип алгоритма: Full Reference (FR) — требует и reference-сигнал (чистый), и degraded-сигнал (после прохождения через систему).
Диапазоны:

Narrowband (NB): 300–3400 Гц (классическая телефония).
Super-Wideband (SWB): до 14 кГц (HD Voice).
Full Band (FB, с v3): до 20–24 кГц (48 кГц сэмплирование).

Выход: MOS-LQO (Listening Quality Objective) от 1 (плохо) до 5 (отлично). Также дополнительные индикаторы.

Как работает POLQA (высокоуровнево)

Алгоритм состоит из двух основных частей:

Temporal Alignment (временное выравнивание):

Решает сложные проблемы VoIP: внезапные скачки задержки (shift-jitter), постепенное time-scaling (растяжение/сжатие речи), packet loss и т.д.
Использует macro frame, корреляцию, backtracking (аналог Viterbi алгоритма), обработку pitch-preserving техник (типа PSOLA).
Оценивает sample rate differences и компенсирует их.

Perceptual Model (психоакустическая модель):

Моделирует человеческое слуховое восприятие: преобразование в Bark-scale (критические полосы), loudness (Sone), masking effects (частотное и временное).
Idealization: "идеализирует" reference-сигнал (убирает мелкие шумы, корректирует timbre/level), чтобы имитировать Absolute Category Rating (ACR) тесты, где слушатели оценивают без прямого сравнения.
Вычисляет disturbance density (плотность искажений) отдельно для additive и subtractive distortion, с учётом сильных и слабых эффектов.
Cognitive model преобразует perceptibility в annoyance (раздражаемость), учитывая level variations, reverberation, noise и т.д.
Финальный mapping в MOS-LQO с полиномиальной коррекцией.