RBS - Функциональные характеристики

1. Общие функциональные характеристики

1.1 Назначение

Программа RBS обеспечивает выполнение следующих основных функций:

Реализация функций базовой станции GSM (BTS)
Реализация функций базовой станции UMTS (NodeB)
Реализация функций базовой станции LTE (eNodeB)
Реализация функций распределенного узла базовой станции 5G NR (gNB-DU)
Обработка сигнального трафика протоколов S1AP, NBAP, GTP-C, F1AP, XnAP, NG-AP
Управление контекстами абонентов (UE-контексты)
Конфигурирование параметров работы в реальном времени через REST API
Ведение журнала событий

1.2 Архитектура программного обеспечения

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

Основные потоки:

Поток GSM — выполнение функций GSM BTS
Поток UMTS — выполнение функций UMTS NodeB
Поток LTE — выполнение функций LTE eNodeB
Поток NR — выполнение функций 5G NR gNB-DU
Поток REST-сервера — обработка команд оператора через HTTP API
Поток OMS — управление авариями и счетчиками производительности

Общие структуры данных:

Хранилище конфигурационных параметров (потокобезопасное)
Хранилище UE-контекстов (потокобезопасное)
Хранилище PDP-контекстов (потокобезопасное)
Журнал событий (потокобезопасный)

1.3 Режимы работы

Программное обеспечение функционирует в следующих режимах:

Режим ожидания:

Потоки RAT ожидают входящих сообщений
Сетевые серверы прослушивают заданные порты
REST API готов к приему команд

Режим обработки сигнального трафика:

Прием и разбор входящих сообщений протоколов
Формирование и отправка ответов
Обновление контекстов абонентов

Режим конфигурирования:

Изменение параметров работы в реальном времени через REST API
Динамическая перезагрузка конфигурации без остановки основного процесса

2. Поддерживаемые протоколы и интерфейсы

2.1 Протоколы GSM (2G)

Текущая реализация:

TDMA-структура кадров (8 временных слотов по 577 мкс). Каждый TDMA-кадр объединяет 8 слотов, 26 кадров образуют мультифрейм для TCH (трафиковых каналов), 51 кадр — мультифрейм для управляющих каналов

Формирование типов burst-пакетов: Normal Burst (148 бит: 57 бит данных + 26-битная обучающая последовательность + 57 бит данных), Synchronisation Burst (SCH) для передачи BSIC и RFN, Frequency Correction Burst (FCB) для настройки частоты UE

Системные информационные сообщения (SI Type1, SI Type3) на BCCH, содержащие MCC, MNC, LAC, BSIC, параметры выбора ячейки (Cell Selection)

Выделение логических каналов: SDCCH (Stand-alone Dedicated Control Channel) для сигнализации и TCH_F (Traffic Channel Full Rate) для голосовых вызовов

Протокол Abis (OML/RSL) поверх IPA/TCP для взаимодействия с BSC (Base Station Controller). OML (Operations and Maintenance Link) отвечает за управление конфигурацией и загрузку программного обеспечения, RSL (Radio Signalling Link) — за выделение и освобождение радиоканалов

BSSGP/NS слой для поддержки GPRS (General Packet Radio Service): NS (Network Service) управляет сетевым сервисом с процедурами NS-RESET, NS-ALIVE, NS-UNITDATA; BSSGP (Base Station System GPRS Protocol) обеспечивает передачу пользовательских данных с процедурами UL-UNITDATA, DL-UNITDATA, BVC-RESET, RADIO-STATUS, а также трассировку с BCD Cell ID

2.2 Протоколы UMTS (3G)

Текущая реализация:

WCDMA с частотой чипов 3.84 Мчипс. Один радиофрейм длительностью 10 мс состоит из 15 слотов. Расширение спектра (spreading) осуществляется с помощью ортогональных кодов OVSF (Orthogonal Variable Spreading Factor), где каждый бит данных повторяется SF раз. Меньшие значения SF (4, 8, 16) обеспечивают высокую скорость передачи данных, большие значения SF (32, 64, 128, 256) — большее радиопокрытие

Каналы физического уровня: CPICH (Common Pilot Channel) — 256 бит на фрейм, SF=256, используется UE для измерения Ec/No и RSCP; SCH (Synchronisation Channel) для первичной и вторичной синхронизации; PCCPCH (Primary Common Control Physical Channel) для передачи системной информации; DCH (Dedicated Channel) для выделенных соединений с конкретными UE

Скремблирование с использованием Gold-кода на основе Primary Scrambling Code (PSC) в диапазоне 0–511, накладываемого поверх spread-сигнала для разделения ячеек

Протокол NBAP (NodeB Application Part) поверх Iub для взаимодействия с RNC (Radio Network Controller). Реализованные процедуры: Cell Setup Request FDD (настройка ячейки), Radio Link Setup Request FDD (установка радиолинии), Radio Link Addition Request FDD (добавление радиолинии в Active Set), Radio Link Deletion Request (удаление радиолинии), Common Transport Channel Setup (настройка FACH/PCH/RACH), Radio Link Reconfigure Prepare/Commit (изменение SF), HS-DSCH Setup (настройка HSDPA), Reset Request (сброс узла), Audit Request (аудит конфигурации)

HSDPA (High Speed Downlink Packet Access): канал HS-DSCH (High Speed Downlink Shared Channel) с фиксированным SF=16, обеспечивающий скорость до 14.4 Мбит/с в соответствии с TS 25.308

E-DCH (Enhanced Dedicated Channel) для HSUPA (High Speed Uplink Packet Access) с улучшенной скоростью восходящей линии

Soft Handover (мягкий хэндовер): управление Active Set через добавление и удаление радиолиний с поддержкой макро-разнесения (macro diversity), когда UE одновременно поддерживает соединение с несколькими NodeB

2.3 Протоколы LTE (4G)

Текущая реализация:

OFDMA (DL) / SC-FDMA (UL)
Ресурсные блоки (RB) от 6 до 100 в зависимости от полосы (1.4–20 МГц)
Сигналы синхронизации PSS и SSS, канал PBCH (MIB)
Планировщик Proportional Fair (PF) на основе CQI
HARQ с 8 процессами
PDCP: заголовки, шифрование AES-128 CTR, SNOW3G, ZUC, целостность EIA2 (AES-128-CMAC)
Протокол S1AP (18 процедур, включая S1 Setup, Reset, Initial UE Message, Initial Context Setup, E-RAB Setup, Handover)
Протокол X2AP (X2 Setup, Handover)
GTP-U для туннелирования пользовательских данных (S1-U)
CSFB (Circuit-Switched Fallback) в GSM/UMTS
Carrier Aggregation (до 5 CC)

2.4 Протоколы 5G NR

Текущая реализация:

Физический уровень NR: PSS, SSS, PBCH, SSB burst
Поддерживаемые SCS: 15 кГц (FR1 FDD), 30 кГц (FR1 TDD), 60 кГц, 120 кГц
Протокол F1AP (gNB-DU ↔ gNB-CU): F1 Setup Request/Response/Failure
Протокол XnAP (inter-gNB handover): Xn Setup, Handover
Протокол NG-AP (gNB ↔ AMF): NG Setup, PDU Session Setup, UE Context Release
NR MAC: планировщик с учетом очередей, BWP, DCI 1_1
NR SDAP: отображение QFI на DRB
NR PDCP: SN 18 бит
EN-DC NSA: Option 3, 3a, 3x (X2AP SgNB Addition/Modification/Release)
RAN Slicing: PRB-квоты для eMBB, URLLC, mMTC

3. Функции управления и конфигурирования

3.1 Консоль управления (REST API)

Программное обеспечение предоставляет REST API на базе HTTP-сервера с поддержкой следующих команд:

Команды мониторинга состояния:

GET /api/v1/status — отображение версии, состояния узла, списка активных RAT, статуса EN-DC
GET /api/v1/pm — вывод всех счетчиков производительности (OMS)
GET /api/v1/alarms — отображение активных аварий с уровнем серьезности
GET /api/v1/links — список всех интерфейсов (Abis, Iub, S1, X2, Ng, Xn) с их состоянием

Команды управления:

POST /api/v1/admit — подключение UE (IMSI, RAT)
POST /api/v1/links/{name}/connect — поднятие интерфейса
POST /api/v1/links/{name}/disconnect — опускание интерфейса
POST /api/v1/links/{name}/inject — инжекция процедуры (например, S1AP:S1_SETUP)
POST /api/v1/links/{name}/block — блокировка типа сообщения
POST /api/v1/links/{name}/unblock — снятие блокировки
PATCH /api/v1/config — динамическая перезагрузка конфигурации из файла или отдельных ключей

3.2 Параметры конфигурации

Программное обеспечение поддерживает следующие параметры настройки в файле rbs.conf:

Параметры сети GSM:

cell_id — идентификатор GSM-ячейки
arfcn — абсолютный номер радиоканала
bsic — код идентификации базовой станции
lac — код зоны расположения
bsc_addr — IP-адрес BSC (для Abis)

Параметры сети UMTS:

cell_id — идентификатор UMTS-ячейки
uarfcn — абсолютный номер радиоканала UMTS
psc — первичный скремблирующий код
rnc_addr — IP-адрес RNC (для Iub)

Параметры сети LTE:

cell_id — идентификатор LTE-ячейки
earfcn — абсолютный номер радиоканала LTE
pci — физический идентификатор ячейки
mme_addr — IP-адрес MME (для S1AP)

Параметры сети 5G NR:

cell_id — идентификатор NR-ячейки
nr_arfcn — NR-ARFCN несущей DL
band — операционный диапазон NR (n1, n78 и т.д.)
scs — межносубнесущее расстояние
cu_addr — IP-адрес gNB-CU (для F1AP)

3.3 Загрузка конфигурации из файлов

При запуске программа автоматически загружает конфигурацию из файла rbs.conf в рабочей директории.

Формат файла конфигурации INI:

Строки, начинающиеся с символа ';' или '#', игнорируются
Параметры группируются в секции [секция]
Параметры задаются в формате ключ = значение
Пробельные символы в начале и конце строк игнорируются

Поддерживается динамическая перезагрузка конфигурации без остановки процесса при получении сигнала SIGHUP (Linux) или через REST API PATCH /api/v1/config.

4. Функции ведения журнала

4.1 Консольный вывод

Программное обеспечение поддерживает цветовую дифференциацию сообщений в консоли с использованием ANSI 256-цветовых escape-кодов, что обеспечивает удобство визуального анализа работы системы в терминалах Linux, macOS, Windows Terminal и WSL.

Окрашивание по компонентам (RAT и подсистемам):

GSM (2G), ABIS, OML, RSL — зеленый цвет
UMTS (3G), NBAP, IUB — голубой цвет (cyan)
LTE (4G), LTEMAC, S1AP, X2AP — ярко-синий цвет
NR (5G), F1AP, NGAP, XNAP — пурпурный цвет (magenta)
OMS (Operations and Maintenance System) — оранжевый цвет
HAL (Hardware Abstraction Layer) — темно-серый цвет
MAIN и RBS — белый цвет, жирное начертание

Окрашивание по уровню серьезности сообщения:

DEBUG — серый цвет (dim), используется для детальной отладочной информации
INFO — зеленый цвет (bright), информирует о штатных событиях работы системы
WARNING — желтый цвет (bold) на желтом фоне, предупреждает о нештатных ситуациях, не приводящих к отказу
ERROR — красный цвет (bold) на красном фоне, указывает на ошибки, влияющие на отдельные функции
CRITICAL — белый цвет (bold) на красном фоне, сигнализирует о критических отказах подсистем

Формат строки вывода:

text

YYYY-MM-DD HH:MM:SS.mmm [УРОВЕНЬ] [КОМПОНЕНТ] Сообщение

Каждая запись содержит временную метку с точностью до миллисекунды, уровень серьезности, наименование компонента-источника и текст сообщения. Такое форматирование позволяет быстро фильтровать сообщения по времени, компоненту или уровню критичности при визуальном просмотре.

Цветовая индикация особенно полезна при одновременной работе нескольких RAT (режим ALL), когда в консоль одновременно выводятся сообщения от GSM, UMTS, LTE и NR стеков. Администратор может мгновенно определить принадлежность сообщения к тому или иному стандарту по цвету тега компонента, а также оценить серьезность ситуации по цвету уровня логирования.

4.2 Файл журнала

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

text

YYYY-MM-DD HH:MM:SS.mmm [УРОВЕНЬ] [ИСТОЧНИК] Сообщение

Пример:

text

2026-04-07 16:40:05.691 [INFO] [LTE] UE admitted RNTI=1 CQI=12

2026-04-07 16:40:07.701 [INFO] [OMS] Performance Report: lte.connectedUEs = 3

Уровень логирования задается в файле конфигурации (секция [logging], ключ level).

5. Управление состоянием

5.1 Контексты UE

Хранилище UE-контекстов предназначено для отслеживания состояния абонентских устройств. В текущей реализации структура контекста включает:

IMSI — международный идентификатор абонента
RNTI — временный идентификатор радиосети
RAT — тип сети (GSM, UMTS, LTE, NR)
Время подключения

5.2 PDP-контексты (SGSN)

Хранилище PDP-контекстов предназначено для отслеживания активных сессий передачи данных в сетях 2G/3G. PDP-контекст создается при установлении сессии передачи данных между абонентским устройством и сетью пакетной передачи данных. В структуру контекста входят:

TEID (Tunnel Endpoint Identifier) — идентификатор туннеля GTP, используемый для маршрутировки пакетов между SGSN и GGSN

IMSI (International Mobile Subscriber Identity) — международный идентификатор абонента, однозначно определяющий SIM-карту

APN (Access Point Name) — имя точки доступа, определяющее внешнюю сеть (например, internet, ims)

Тип PDP — тип протокола передачи данных (IPv4, IPv6, IPv4v6, PPP)

Хранилище обеспечивает возможность поиска контекста как по TEID, так и по IMSI, что необходимо для обработки как нисходящего, так и восходящего трафика.

5.3 UE-контексты (MME)

Хранилище UE-контекстов в LTE предназначено для отслеживания состояния абонентских устройств на уровне управления мобильностью. Контекст UE создается при выполнении процедуры присоединения (Attach) к сети и сохраняется на всем протяжении присутствия устройства в зоне обслуживания MME. Структура контекста включает:

IMSI — международный идентификатор абонента, используемый для постоянной идентификации

GUTI (Globally Unique Temporary Identifier) — глобальный временный идентификатор, назначаемый MME для обеспечения конфиденциальности IMSI при передаче по радиоканалу

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

Контекст безопасности — набор криптографических параметров, включая ключи шифрования (K_eNB) и целостности, используемые для защиты NAS-сигнализации

Управление UE-контекстами включает создание при успешной аутентификации, обновление при изменении состояния мобильности (например, при хэндовере между ячейками) и удаление при отсоединении устройства или истечении таймаута неактивности.

6. Планируемые функциональные расширения

6.1 Этап 1 — Межвендорная совместимость (E2E)

E2E smoke-скрипты для Open5GS (NGAP/PDU session)
Набор эталонных трасс (pcap) для регрессионной проверки
Воспроизводимые E2E сценарии с документированными командами запуска

6.2 Этап 2 — Развитие непрерывной интеграции (CI)

Матрица сборок для Windows (MSVC) и Linux
Публикация тестовых логов и артефактов при падениях
Опционально: конвейер статического анализа (clang-tidy/format/lint)

6.3 Этап 3 — Производительность и наблюдаемость

Бенчмарки латентности планировщика и сквозного пути передачи данных
Расширенные метрики Prometheus (гистограммы латентности, счетчики ошибок на интерфейс)
Автоматическая проверка регрессий производительности

6.4 Этап 4 — Укрепление безопасности

Валидация и лимиты для REST API (размер полезной нагрузки, частота запросов)
Негативные и fuzz-тесты для путей парсеров и кодеков
Модель угроз и документация

ЭрикссонСофт