Все, что вы хотели знать про телеком: как устроена опорная сеть 5G простыми словами

Опорная сеть (Core Network) — это «мозг» мобильной связи, именно она делает возможными звонки, выход с мобильного устройства в интернет и все, что связано с мобильной связью. Она вступает в игру сразу после базовой станции, которая оцифровывает и передает сигналы в опорную сеть. Базовая станция (БС) устанавливает связь, переводит радиосигнал в данные и отсылает дальше. Но именно опорная сеть решает, что это за данные, кому они адресованы, имеет ли абонент на это право и куда все это отправить.

Опорная сеть отвечает за самое важное:

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

Физически между базовой станцией и опорной сетью проходят два потока:

• Control Plane — управляющий трафик. Отвечает за процедуры подключения к сети, аутентификации, переключения между станциями, сессий и т. д.
• User Plane — пользовательский трафик. Это все, что идет от приложений пользователя: стриминговые сервисы, мессенджеры, браузер и так далее.

Они разделены как логически, так и физически. Такой подход нужен, чтобы обеспечивать надежность, безопасность и гибкость.

Есть заблуждение, что опорная сеть — это просто набор мощных маршрутизаторов, которые пересылают трафик между базовыми станциями и интернетом. Сигнал от телефона приняли, пакет пошел, дальше все передается по правилам обычной IP-сети. Звонок пришел — отправили. Интернет запросили — передали.

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

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

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

Вся эта логика реализуется не на каком-то специализированном железе, а на обычных серверах общего назначения. Вся магия происходит на уровне софта, работающего в контейнерах, — микросервисах. Этим и занимается наша команда: мы проектируем и пишем компоненты этой умной сетевой «начинки» для 5G.

В предыдущих поколениях мобильных сетей (2G, 3G, LTE) масштабирование сервисов не предусматривали и настраивали компоненты вручную. 5G пошел другим путем — в архитектуру опорной сети пришли микросервисы. Теперь каждый функциональный блок, будь то авторизация, управление сессиями или работа с базой данных абонентов, — это отдельный сервис, со своими API, логикой, масштабируемостью и жизненным циклом.

Эти микросервисы общаются между собой через специальный механизм под названием шина SBI (Service-Based Interface, или «интерфейс на основе сервисов»). Это способ, по которому все внутренние части опорной сети «разговаривают» друг с другом.

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

• REST — способ построения API, то есть набора правил, по которым программы могут обмениваться данными.
  
• HTTP/2 — обновленная версия протокола, на котором работает весь интернет. Она быстрее и эффективнее обычного HTTP.
  
• OpenAPI — специальный формат для описания API, который читается как инструкция: кто с кем общается и какие данные передаются.
  
• YAML — удобный читаемый текстовый формат.
  
• JSON — это способ упаковки данных в виде текста, который легко читается как людьми, так и программами.

Сегодня внутренняя часть мобильной сети — опорная сеть — все чаще строится как набор отдельных сервисов, которые работают по стандартным правилам обмена данными. Эти правила похожи на те, что используются в современных интернет-приложениях: данные передаются в текстовом формате (например, JSON), а сервисы обмениваются запросами и ответами, как при работе обычного сайта.

Из-за этого может сложиться впечатление, что опорная сеть устроена так же, как и веб-приложение. То есть как система, где каждая операция независима от предыдущей: пользователь нажал кнопку — сервер отреагировал и тут же «забыл», что происходило. Такой подход называют stateless — «без сохранения состояния».

Но в мобильной связи все работает иначе. Здесь каждое действие пользователя — это продолжение цепочки предыдущих шагов. Сеть не может «забыть», что происходило ранее:

• При включении телефона сеть должна вас узнать и авторизовать.
• Если вы переехали в другую зону, телефон нужно переключить на новую базовую станцию.
• Если вы начали смотреть видео, нужно установить специальную сессию передачи данных.
• Если вы на время отложили телефон, соединение может перейти в спящий режим (idle mode).
• Если вы вернулись, все должно быстро восстановиться.

Однако у REST есть важная особенность: он предполагает, что каждый запрос самодостаточен и не зависит от других — stateless. В мобильной сети такой подход не работает. Как мы уже знаем, все действия пользователя — от подключения к сети до переключения между базовыми станциями — тесно связаны друг с другом.

Поэтому, несмотря на внешнее сходство с веб-разработкой, архитектура опорной сети 5G устроена намного сложнее. Под капотом — сотни состояний, процедур и зависимостей, которые постоянно в движении.

Под привычными веб-протоколами скрывается сложная система бизнес-логики, состояний, таймеров и технических зависимостей. Это делает опорную сеть 5G не просто современной, а структурно и концептуально сложной.

Даже международные стандарты связи, например 3GPP (организация, которая описывает, как должны работать сети вроде LTE и 5G), признают это ограничение. REST используется потому, что он понятен и его легко описывать и документировать.

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

Переход на микросервисную архитектуру — важный шаг вперед. Он делает опорную сеть более гибкой: можно масштабировать нагрузку, развивать отдельные компоненты независимо друг от друга и проще интегрироваться с другими системами. Главное — помнить, что под внешне простыми форматами вроде JSON по-прежнему работает сложная, живая система, где все зависит от контекста и последовательности действий.

Если вы думаете, что главная нагрузка в мобильной сети — это гигабайты трафика от социальных сетей, то вы ошибаетесь. Это только часть картины. Настоящий вызов для разработчиков опорной сети — это контрольные процедуры: подключения, смены состояний, переключения между базовыми станциями и запуск новых сессий. И таких запросов в крупной сети — сотни тысяч в секунду. Подробнее про то, какая функциональность переключает телефон с одной БС на другую без перерыва в обслуживании.

Эти действия не требуют большого объема данных — зачастую это просто небольшие управляющие пакеты. Но их много, и они требуют ответа в очень жесткие сроки. Если пользователь спустился в метро, он должен получить мобильный интернет уже через секунду. Если какая-то базовая станция «упала», подключенные к ней устройства должны переподключиться — быстро и бесшовно для пользователя. Опорная сеть должна все обработать без задержек и с сохранением контекста.

Нагрузка измеряется не в мегабитах, а в процедурах в секунду. Это важное отличие от классического интернета. Одна «процедура» — это цепочка сообщений, состояний и ответов, часто растянутых во времени и идущих параллельно. Процедура может инициироваться от базовой станции, от пользователя, от внешнего сервиса или по таймеру внутри самой сети. И таких процедур одновременно может быть миллион.

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

Особая сложность — в синхронной работе десятков микросервисов. Каждая операция — это пересылка сообщений между ними. Каждая задержка — это потенциальная потеря контекста. Поэтому разработчики часто вынуждены писать свои сетевые стеки, использовать минималистичные фреймворки, избегать лишних абстракций и оптимизировать код до байта и микросекунды. В высоконагруженной опорной сети даже такая «мелочь», как аллокация памяти, может много значить.

А еще есть IoT — устройства интернета вещей. Они не гонят трафик, но могут десятками тысяч одновременно «просыпаться» и требовать соединения. Контрольный трафик от них ничуть не легче, чем от человека с телефоном.

5G сеть — это не просто быстрый интернет. Это инфраструктура, которая должна выдерживать хаотичную, постоянно изменяющуюся, сложную и предельно чувствительную к задержкам нагрузку. И именно это делает разработку в этой области настоящей инженерной задачей — на грани IT, телекоммуникаций и системного программирования.

Разработка в телекоме звучит как что-то очень сложное, с миллионами абонентов, сигналами, ассемблером и графиками трафика. Но правда в том, что здесь есть место и для тех, кто только начинает свой путь в программной инженерии. Главное — не бояться учиться.

Начнем с того, что большинство систем — это программный код на C++ (иногда с вкраплениями других языков), который пишется, читается и отлаживается так же, как в любой другой области. В основе — знакомые концепции: сетевое и сервисное взаимодействие, работа с API, логика обработки запросов. Просто все это накладывается на специфику мобильной сети.

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

Здесь также важно представлять, как работает сетевой стек (пусть даже на уровне «знаю, что есть TCP и UDP»), уметь запустить что-то в контейнере, разобраться, почему сообщение не дошло и как с этим быть. Не обязательно уметь все это с первого дня, главное — хотеть разобраться.

Полезно знать, что в телекоме многое работает по состояниям — так называемым конечным автоматам. Каждая сессия, каждый абонент проходит через последовательность шагов, и логика в коде часто построена вокруг переходов между ними. Это может показаться странным, если до этого вы писали просто API, но на самом деле очень помогает «держать в голове» происходящее.

А еще — нужно быть спокойным к легаси. Здесь встречаются и древние протоколы, и та самая ASN.1-нотация из 80-х. В телекоме важно, чтобы все было предсказуемо, совместимо и работало у всех устройств — от новейшего смартфона до сенсорного датчика в порту.

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