Поддомен: Cloud/DevOps и телеком-инфраструктура. Роль: DevOps/SRE-инженер с опытом сетевых функций.
МТС сообщила: 38% смартфонов в России поддерживают 5G, а в Калининградской области — каждый третий. На первый взгляд это новость для отдела маркетинга. Но для выпускника ИТ-направления здесь спрятан готовый каркас ВКР: рост парка 5G-устройств упирается не в абонентов, а в инфраструктуру — в ядро сети, edge-площадки и автоматизацию развёртывания сетевых функций. Пока устройств мало, оператору хватает классического ядра. Когда их становится треть, без network slicing, MEC и Kubernetes-оркестрации уже не масштабироваться. Именно на этом стыке делаются защищаемые работы: измеримые метрики, живая архитектура, понятная экономика.
Три легальных пути. Первый — открытые отчёты аналитиков и релизы операторов вроде того, что мы разбираем: они дают проценты по парку устройств и динамику по регионам. Второй — публичные датасеты по трафику и mobility (например, измерения скорости от независимых сервисов). Третий — собственный стенд: free5GC или Open5GS в кластере плюс эмулятор UERANSIM вместо реальных базовых станций. Для ВКР этого достаточно, если вы честно описываете ограничения модели.
Да. Вариант SA (Standalone) с открытым ядром спокойно живёт в трёх-четырёх узлах Kubernetes на ноутбуке с 16 ГБ памяти. Управляющие функции (NRF, AMF, SMF) не требовательны к ресурсам, а UPF вы ограничиваете пропускной способностью. Главное — не пытаться эмулировать радиополосу и честно писать в главе 1, что лабораторный стенд заменяет gNodeB эмулятором.
Через относительные метрики и сценарии нагрузки. Сравнивайте две конфигурации: монолитный UPF против slice-aware разнесения по edge-узлам. Считайте p95 задержки, джиттер, потребление CPU на сессию и стоимость часа работы кластера. Абсолютные числа не нужны — нужен доказанный прирост на вашей модели.
ГОСТ 34.601 отлично сочетается с C4 и UML: стадии и этапы берёте из стандарта, а диаграммы контекста, контейнеров и развёртывания рисуете по нотации C4. Никакого конфликта нет — нормоконтроль смотрит на состав и оформление, а не на модность нотации. Если сомневаетесь в трактовке требований, разумно уточнить её с научным руководителем до, а не после вёрстки главы.
Актуальность: рост парка 5G-устройств до 38% означает, что операторы начинают сегментировать сеть под разные классы сервисов — от eMBB до URLLC. Один физический кластер должен обслуживать изолированные срезы.
Цель: спроектировать и реализовать стенд, где сетевые функции ядра разворачиваются декларативно и изолируются по срезам.
Задачи: анализ архитектуры 5GC и SBA; выбор open-source реализации; проектирование Helm-чартов и сетевых политик; измерение задержки и изоляции между срезами.
Структура: Глава 1 — архитектура 5G Core, SBA, slicing, NFV. Глава 2 — проектирование кластера, манифесты, чарты, CNI. Глава 3 — нагрузочное тестирование, метрики, выводы.
Актуальность: если треть смартфонов готова к 5G, то latency-чувствительные сервисы логично выносить на периферию. Возникает задача экономического обоснования edge-площадок.
Цель: оценить, при каком профиле нагрузки edge-развёртывание выгоднее централизованного.
Задачи: моделирование задержек с учётом размещения UPF; расчёт стоимости владения; сравнение сценариев; выработка критериев размещения.
Структура: Глава 1 — теория MEC и сценарии. Глава 2 — модель TCO и архитектура. Глава 3 — расчёты, чувствительность модели, рекомендации.
Актуальность: распределённое ядро невозможно эксплуатировать «на глаз». Нужны SLO на задержку регистрации абонента, доступность NRF, стабильность сессий.
Цель: построить систему сбора метрик, трассировки и оповещений для стенда 5GC.
Задачи: инструментировать функции; настроить сбор и хранение; формализовать SLI/SLO; проверить алерты на инъекции отказов.
Структура: Глава 1 — обзор практик наблюдаемости. Глава 2 — реализация конвейера метрик и трасс. Глава 3 — эксперименты с отказами и оценка полноты алертов.
Актуальность: статистика по 5G-смартфонам — сырьё для планирования ёмкости. Из неё выводят, где раньше включать новые несущие.
Цель: построить модель прогноза проникновения устройств по регионам и связать её с планом модернизации.
Задачи: сбор и нормализация данных; выбор модели прогноза; оценка качества; интерпретация для инфраструктурных решений.
Структура: Глава 1 — источники и метрики парка устройств. Глава 2 — конвейер обработки и модель. Глава 3 — валидация и прикладные рекомендации.
Не начинайте с фразы «сейчас идёт цифровизация». Начните с числа: 38% устройств и треть в отдельном регионе. Дальше разложите показатель по смыслу — сколько это абонентов, какой прирост трафика даёт, что означает для ёмкости. Постройте диаграмму контекста по C4: система «5G-ядро», внешние акторы — абонентские устройства, OSS/BSS, внешние сети данных. Укажите, что метрики качества вы будете проверять по ISO/IEC 25010 — производительность, надёжность, масштабируемость. Это снимет вопрос «а почему именно эти характеристики вы измеряете».
Здесь основная инженерная работа. Функции ядра в SBA — это набор сервисов, которые логично упаковать в чарты. Опишите, как вы разносите плоскости: управляющие (NRF, AMF, SMF, AUSF, UDM) и пользовательскую (UPF). Разделяйте их по namespace и задавайте ресурсные квоты. Ниже — фрагмент values.yaml, который уместно вынести в приложение и сослаться в тексте главы.
# values.yaml — параметры развёртывания функций ядра
amf:
replicas: 2
resources:
requests: { cpu: "300m", memory: "256Mi" }
limits: { cpu: "1", memory: "1Gi" }
smf:
replicas: 2
slices: [embb, urllc]
upf:
replicas: 3
nodeSelector:
node-role.kubernetes.io/edge: "true"
n4:
peer: smf.nf.svc.cluster.local
mtu: 1500
hpa:
minReplicas: 2
maxReplicas: 8
targetCPUUtilizationPercentage: 65
К этому месту просится диаграмма развёртывания: узлы периферии и центра, какие поды где живут, как проходит трасса N4. Не поленитесь показать, что UPF на edge, а SMF в центре — это не произвол, а следствие требований к задержке.
Собирайте телеметрию через OpenTelemetry, храните в Prometheus, визуализируйте в Grafana. Ключевое — заранее зафиксировать, что считаете. Ниже пример запроса для контроля задержки установления сессии по срезам.
histogram_quantile(
0.95,
sum by (le, slice_id) (
rate(pfcp_session_setup_duration_seconds_bucket[5m])
)
)
| Метрика | Что показывает | Целевой ориентир в стенде | Где фиксируется |
|---|---|---|---|
| p95 задержки установления PDU-сессии | Отзывчивость ядра под нагрузкой | < 150 мс при 500 сессиях/с | Глава 3, таблица экспериментов |
| Джиттер на UPF | Пригодность для URLLC-среза | < 5 мс | Глава 2, раздел верификации |
| Потребление CPU на 1000 сессий | Плотность упаковки в кластер | Снижение на 20% против монолита | Глава 3, сравнительный график |
| Доступность NRF | Устойчивость реестра функций | 99,9% на окне теста | Глава 3, SLI/SLO |
| TCO стенда за месяц | Экономика решения | Расчёт на 3 сценария | Глава 3, экономический раздел |
Стадии и этапы разработки оформляйте по ГОСТ 34.601, программную документацию — по ГОСТ 19. Отчёты по тестам выносите в приложения, а в тексте оставляйте выводы. Схемы — единым стилем, с рамкой и штампом, если требует кафедра. Проверьте, чтобы каждая задача из введения имела отражение в выводах по главам: это первое, что смотрят на защите. Если тема сетевая, отдельно опишите план адресации и легенду обозначений — на них чаще всего спотыкаются при вопросах.
1. Пересказ новости вместо технической постановки. Полстраницы про то, что у МТС выросли показатели, и ни слова о том, какие требования это накладывает на сеть. Исправляется просто: каждое число превращайте в требование — при росте парка на N% планируйте запас ёмкости на M.
2. Стек ради стека. Kubernetes в работе есть, а зачем он там — не объяснено. Если обошлись бы systemd-юнитами, честно скажите, что выбрали оркестратор ради тиражируемости и самовосстановления, и докажите это экспериментом с отказом узла.
3. Метрики без методики. «Задержка снизилась» без указания профиля нагрузки, размера выборки и погрешности. Заведите шаблон протокола испытаний и заполняйте его на каждом прогоне — тогда цифры на защите не развалятся от одного вопроса.
Если времени на разбор стека и вычитку глав не хватает, у вас есть вариант обратиться за помощью с дипломом к профильным специалистам. Мы разбираем около 120 часов работы над темой, даём бесплатную консультацию по постановке задач и подсказываем, какую часть исследования можно сузить без потери качества. Работа остаётся вашей — мы лишь ускоряем движение по ней.
Источник: МТС: каждый третий смартфон в Калининградской области поддерживает 5G (опубликовано 2026-03-26)