Smart-MVNO в дипломе: интеграция банковских сервисов и сети оператора
25 марта 2026 года АО КБ «Солидарность» и «Билайн» объявили о запуске Smart-MVNO: банк получает виртуального мобильного оператора поверх инфраструктуры сотовой сети, а абонент — единый счёт, брендированное приложение и связку тарифа с банковскими продуктами. Для выпускника ИТ это не «новость про маркетинг», а учебный полигон по интеграции разнородных систем: BSS/OSS оператора, CRM банка, биллинг, eSIM-профили, единая идентификация. Именно такие кейсы дают живые данные для глав 2 и 3 ВКР — от проектирования API-шлюза до расчёта SLA и стоимости владения. Ниже — как превратить эту новость в защищаемую работу, а не в пересказ пресс-релиза.
FAQ: что чаще всего спрашивают студенты по этой теме
«Smart-MVNO — это вообще про ИТ или про телеком? Мне разрешат взять такую тему?»
Про ИТ, причём в чистом виде. Ключевые артефакты проекта — интеграционная шина, API между ядром оператора и биллингом банка, потоковые события тарификации, единый личный кабинет. Кафедры принимают такие темы охотно: они попадают в паспорт специальности по проектированию информационных систем.
«Где брать реальные данные и метрики, если я не работаю в банке?»
Реального контура не нужно. Открытые источники: документация 3GPP по архитектуре MVNO, спецификации TM Forum (Open API, ODA), публичные SLA операторов. Метрики — синтетика на нагрузочном стенде: RPS, p95 задержки, доля успешных CDR-сессий.
«Нужно ли поднимать Kubernetes для ВКР?»
Не обязательно, но если интеграционный слой описан как набор микросервисов, K8s-манифест в приложении усилит работу. Достаточно одного манифеста Deployment + Service + ConfigMap.
«Как не получить замечание нормоконтроля по схемам?»
Оформляйте диаграммы по ГОСТ 34.601/34.602 (стадии и этапы, ТЗ) и UML/C4 — по нотации. Не смешивайте нотации в одной схеме, у каждой диаграммы должен быть номер, наименование и ссылка в тексте.
Темы ВКР, которые «вырастают» из кейса
-
1. Проектирование интеграционного шлюза между биллингом MVNO и CRM банка.
Актуальность: кейс «Солидарности» показывает, что MVNO-модель живёт именно за счёт интеграции, а не за счёт радиоинтерфейса.
Цель: разработать сервис-посредник, синхронизирующий тарификацию и клиентские профили.
Задачи: анализ протоколов и API; выбор паттерна (API Gateway + Saga); реализация прототипа; нагрузочное тестирование.
Структура: Гл.1 — обзор MVNO-архитектур, Гл.2 — проектирование и код, Гл.3 — тесты, метрики, экономика. -
2. Оценка качества интеграционного решения по ISO/IEC 25010.
Актуальность: банковский канал связи критичен к доступности и защищённости, нужна формальная модель качества.
Цель: построить метрическую модель качества интеграции MVNO.
Задачи: выбрать характеристики (reliability, security, performance); определить метрики; собрать данные стенда; сравнить с целевыми.
Структура: Гл.1 — теория качества, Гл.2 — методика и стенд, Гл.3 — результаты и рекомендации. -
3. Модель угроз и защита канала «банк ↔ оператор» по OWASP API Security Top 10.
Актуальность: MVNO-канал соединяет два регулятора и два класса ПДн.
Цель: выявить и снизить риски API-обмена.
Задачи: инвентаризация эндпоинтов; STRIDE-модель; тесты авторизации; меры mitigations.
Структура: Гл.1 — ИБ интеграций, Гл.2 — модель угроз, Гл.3 — верификация.
Основная часть: как разложить кейс по главам
Глава 1. Что именно вы анализируете
Не пересказывайте новость. Разложите Smart-MVNO на слои: радиодоступ и ядро (зона ответственности Билайна), BSS/OSS (биллинг, тарификация, CDR), клиентский слой банка (приложение, ЛК, CRM), интеграционный слой (API Gateway, брокер сообщений). Именно последний — предмет вашей работы. В главе 1 уместны C4-диаграмма уровня Context и Container: она наглядно показывает 4 системы и потоки данных между ними. Ссылайтесь на статью как на подтверждение отраслевой практики, а не как на источник технических деталей.
Глава 2. Проектирование и реализация
Здесь пригодятся три артефакта. Во-первых, спецификация API в формате OpenAPI 3.1: минимум 4 эндпоинта — активация SIM/eSIM, получение баланса, отправка CDR, обновление профиля. Во-вторых, sequence-диаграмма (UML) на сценарий подключения абонента. В-третьих, конкретный код — не абстрактный, а воспроизводимый. Ниже пример Kubernetes-манифеста для сервиса-посредника и фрагмент обработчика вебхука тарификации:
apiVersion: apps/v1
kind: Deployment
metadata:
name: mvno-bridge
spec:
replicas: 3
selector:
matchLabels: { app: mvno-bridge }
template:
metadata: { labels: { app: mvno-bridge } }
spec:
containers:
- name: bridge
image: registry.local/mvno-bridge:1.4.0
ports: [ { containerPort: 8080 } ]
envFrom:
- configMapRef: { name: mvno-bridge-cfg }
readinessProbe:
httpGet: { path: /healthz, port: 8080 }
// обработка события тарификации от оператора
async function onCdrBatch(batch) {
for (const cdr of batch) {
const client = await crm.findByMsisdn(cdr.msisdn);
if (!client) { metrics.inc("cdr_orphan"); continue; }
await billing.applyCharge(client.id, cdr.volumeMb, cdr.cost);
await audit.log({ clientId: client.id, cdrId: cdr.id, ts: cdr.ts });
}
metrics.observe("cdr_batch_size", batch.length);
}
Глава 3. Тестирование и метрики
Минимальный набор измерений: пропускная способность (RPS на /activate), p95 задержки, доля потерянных CDR, MTTR при падении одного pod, стоимость обработки 1 ГБ трафика. Если добавите OpenTelemetry-трассировку — получите красивый трейс «банковское приложение → шлюз → биллинг» и картинку для приложения. Экономику считайте через TCO: CAPEX стенда + OPEX облака за 12 месяцев, сравнение с полностью самостоятельным MVNO-контуром.
Чему вы научитесь на такой ВКР
- Проектировать интеграцию двух доменов (telco + fintech) через API Gateway и брокер событий.
- Описывать архитектуру в C4/UML и оформлять её по ГОСТ 34.
- Строить метрическую модель качества по ISO/IEC 25010 и защищать цифры.
- Разворачивать прототип в Kubernetes и валидировать под нагрузкой.
- Считать TCO и SLA-показатели, а не только «работает / не работает».
1. Пересказ пресс-релиза вместо анализа. Половина работы не должна быть о «банк запустил связь». Из статьи берите факт коллаборации и переходите к интеграционной архитектуре.
2. Отсутствие воспроизводимости. Схема без кода и без логов нагрузочного теста защищается слабо. Приложите docker-compose или манифест — комиссия любит воспроизводимые стенды.
3. Игнорирование ИБ. Канал «банк ↔ оператор» — это PII и платежные данные. Без модели угроз и ссылок на OWASP API Security работа выглядит наивно.
- Задачи в ведении совпадают с выводами в заключении — построчно.
- Каждая диаграмма пронумерована, названа и упомянута в тексте.
- Метрики из главы 3 (RPS, p95, TCO) обоснованы методикой расчёта.
- Оформление по ГОСТ 34.602 (ТЗ) и ГОСТ 7.32 (отчёт о НИР) — проверьте поля.
- Ссылки на источники старше 5 лет — не более 20% от списка.
- Приложение содержит код, конфиги и логи тестов.
- Уникальность текста подтверждена отчётом системы антиплагиата.
Практический вывод
Кейс Солидарность × Билайн ценен не как новость, а как типовой сценарий Smart-MVNO. Возьмите из него архитектурный скелет, достройте интеграционный слой, измерьте качество и защитите цифрами. Такую работу сложно «завалить» вопросами — вы говорите про API, метрики и стандарты, а не про тарифы. А если захочется собрать всё «под ключ» — это тот случай, когда профессиональная помощь с дипломом экономит месяцы, но не отменяет вашу защиту.
Источник: Банк «Солидарность» запускает брендированную мобильную связь на базе сети Билайна (опубликовано 2026-03-26)