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

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

5GC снижает этот риск за счет более широкого применения сетевых функций без состояния. Это не означает, что сетевая функция вообще не использует состояние во время работы. Смысл состоит в том, что долгоживущее или восстанавливаемое состояние не должно оставаться запертым внутри одного локального вычислительного экземпляра. Возможность хранить и получать через UDSF неструктурированные данные, такие как контекст UE, дает AMF и другим сетевым функциям более гибкую модель восстановления.

Почему локальное состояние создает риск

Пример MME в 4G наглядно показывает проблему. В сети LTE/EPC после завершения подключения UE через MME1 этот MME создает и локально сохраняет контекст UE. Контекст может включать сведения управления мобильностью и сеансами, например местоположение UE, GUTI и параметры, связанные с IP-адресом UE.

Если MME1 неожиданно выходит из строя, MME2 может по-прежнему физически присутствовать в пуле MME. Однако наличие другого MME не означает автоматической непрерывности обслуживания. Если контекст UE хранится только на MME1, у MME2 недостаточно информации для продолжения прозрачного обслуживания UE. Пользователю может потребоваться перезапустить устройство или снова выполнить подключение, прежде чем сервис восстановится. С точки зрения пользовательского опыта это слабая модель восстановления.

Традиционным обходным решением является кластер MME с синхронизацией активного и резервного узлов. В такой схеме контекст UE синхронизируется в реальном времени между активным MME и MME в режиме ожидания. При отказе активного MME резервный узел может продолжить работу с синхронизированным контекстом. Такой подход уменьшает перерывы, но имеет ограничения. Он может зависеть от реализации конкретного поставщика, не иметь широкой стандартизованной поддержки, увеличивать стоимость и снижать переносимость между различными системными средами.

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

Что меняет UDSF

UDSF означает функцию хранения неструктурированных данных. Она позволяет любой сетевой функции 5GC сохранять и получать собственные неструктурированные данные, включая контекст UE. В этой модели AMF или другая NF обрабатывает сигнализацию как вычислительная функция, а UDSF предоставляет независимое место для хранения выбранной информации о состоянии.

По смыслу это похоже на бездисковую рабочую станцию. Такая станция имеет CPU, память, сетевой интерфейс и другое оборудование для выполнения задач, но не хранит рабочие данные на локальном жестком диске. Она загружается и получает данные с сетевого сервера. Рабочая станция выполняет вычисления, а хранение отделено. В 5GC сетевые функции можно проектировать аналогично: NF выполняет сигнализацию и логику обслуживания, а данные контекста хранятся вне локального экземпляра.

Ценность UDSF не сводится к роли базы данных. Ее архитектурное значение состоит в поддержке NF без состояния, восстановления AMF и более гибких облачно-нативных развертываний. Когда состояние доступно через UDSF, отказ экземпляра AMF не обязательно приводит к безвозвратной потере контекста UE. Новый выбранный AMF может получить необходимый контекст и продолжить обработку при следующей транзакции.

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

Чем отличаются типы данных

Для правильного понимания UDSF важно различать структурированные и неструктурированные данные. В терминологии 5GC структурированными считаются данные, структура которых определена спецификациями 3GPP. Типичный пример — данные подписки, поскольку их ресурсная структура и модель доступа четко описаны.

Неструктурированными являются данные, внутренняя структура которых не определена спецификациями 3GPP. Типичный пример — контекст UE. Он критически важен для непрерывности обслуживания, но его точная внутренняя организация не стандартизована так же, как данные подписки. Поэтому он подходит для хранения через UDSF.

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

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

Как работает восстановление AMF

Типичный процесс восстановления AMF с UDSF выполняется в понятной последовательности. Сначала UE 5G регистрируется через AMF1. AMF1 создает контекст UE, необходимый для управления доступом и мобильностью. Затем AMF1 сохраняет этот контекст в UDSF. После этого пользовательское состояние больше не находится только внутри локального экземпляра AMF.

Если AMF1 выходит из строя, сеть доступа 5G или соседние функции плоскости управления обнаруживают отказ. Неисправный AMF больше не рассматривается при выборе. Когда сети требуется другой AMF из того же набора AMF, она может выбрать AMF2. Именно здесь UDSF меняет механизм восстановления.

AMF2 не обязан рассматривать UE как полностью неизвестное устройство. При транзакции с UE AMF2 может получить контекст UE из UDSF. Для получения могут использоваться идентификаторы SUPI, 5G-GUTI или AMF UE NGAP ID. После получения контекста AMF2 способен обработать сообщение UE и при необходимости обновить 5G-GUTI для UE.

Практический результат — более высокая непрерывность обслуживания. Сети по-прежнему нужны корректное обнаружение отказа, повторный выбор AMF и логика получения контекста, однако основа восстановления надежнее модели, в которой весь пользовательский контекст хранится только в отказавшем узле. Для пользователя идеальный результат — восстановление без перезапуска устройства, ручного повторного подключения и заметного перерыва в обслуживании.

Инженерная ценность и ограничения

Главная инженерная ценность разделения вычислений и хранения — отказоустойчивость. При отказе экземпляра AMF состояние услуги может оставаться доступным через UDSF. Это снижает зависимость от локального состояния узла и помогает сети восстановиться с меньшими последствиями. Поддерживается и эластичное масштабирование, поскольку новые экземпляры сетевых функций можно вводить без предварительной локальной синхронизации всего исторического состояния.

Вторая ценность — архитектурная переносимость. В отличие от специфической для поставщика синхронизации активного и резервного узлов, UDSF входит в архитектуру 5GC и лучше соответствует стандартизованному облачно-нативному дизайну ядра. Она позволяет более открыто организовать хранение и восстановление состояния, не привязывая высокую доступность к закрытому кластерному механизму.

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

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

Для инженеров важнее всего проверить, записывается ли контекст UE в UDSF в нужный момент, может ли новый выбранный AMF корректно его получить, работает ли выбор набора AMF как ожидается, последовательно ли обрабатываются идентификаторы и действительно ли переключение остается незаметным или почти незаметным для пользователя. Разделение имеет ценность только тогда, когда весь путь восстановления протестирован от начала до конца.

Часто задаваемые вопросы

UDSF используется только функцией AMF?

Нет. UDSF предназначена для любой сетевой функции, которой требуется хранить и получать неструктурированные данные. Восстановление AMF с использованием контекста UE — лишь один из наиболее понятных примеров.

Почему контекст UE считается неструктурированными данными?

Контекст UE важен, но его внутренняя структура не полностью определена как стандартизованная структура данных 3GPP. Поэтому его удобно хранить как неструктурированные данные.

Заменяет ли UDSF все локальное состояние сетевых функций?

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

Может ли UDSF гарантировать полное отсутствие перерыва в обслуживании?

Сама по себе — нет. Она улучшает основу восстановления, но фактическая непрерывность также зависит от обнаружения отказов, повторного выбора AMF, актуальности данных, поведения сигнализации и доступности UDSF.

Что следует проверить перед производственным развертыванием UDSF?

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

Разделение вычислений и хранения в 5GC — это больше, чем изменение базы данных. Оно меняет подход ядра сети к состоянию, отказам и восстановлению. Благодаря хранению в UDSF неструктурированных данных, таких как контекст UE, сетевые функции меньше зависят от локального хранилища и лучше подходят для отказоустойчивых облачно-нативных развертываний. Основная идея проста: вычислительные экземпляры могут отказать или измениться, но пользовательское состояние должно оставаться восстанавливаемым.