КИТАЙ Shenzhen Olax Technology CO.,Ltd Новости компании

1. Структура протокола Как показано на рисунке (1), NETCONF использует многослойную структуру, где каждый слой инкапсулирует определенные функции и предоставляет сервисы верхнему слою. Эта структура позволяет каждому слою сосредоточиться на одном аспекте NETCONF и уменьшает зависимости между слоями. Изменения внутри слоя оказывают минимальное влияние на другие слои.       NETCONF можно разделить на четыре слоя: слой транспортной безопасности, слой сообщений, слой операций, и слой контента. Эти слои:   Слой транспортной безопасности: Этот слой отвечает за связь между клиентом и сервером. NETCONF может быть наложен поверх любого транспортного протокола, который соответствует основным требованиям, таким как SSH, TLS и HTTPS. SSH является предпочтительным транспортным протоколом для передачи XML-сообщений в NETCONF. Слой сообщений: Этот слой предоставляет независимые от транспорта механизмы кодирования RPC и уведомлений. Клиент инкапсулирует RPC-запрос в элемент и отправляет его на сервер. Сервер инкапсулирует результат обработки этого запроса в элемент и отправляет его клиенту. Слой операций: Этот слой определяет набор базовых операций протокола, которые вызываются как методы RPC с параметрами, закодированными в XML. Слой контента: Этот слой определяется моделью данных для данных управления. В настоящее время основными моделями данных являются Schema и YANG.         Schema - это набор правил для описания XML-файлов. Устройства используют файлы схемы (аналогичные файлам MIB в SNMP) для предоставления конфигурации устройства и интерфейсов управления системам управления сетью (NMS). YANG - это язык моделирования данных, разработанный для NETCONF. Клиент может компилировать операции RPC в XML-сообщения для достижения взаимодействия клиент-сервер, которое соответствует ограничениям модели YANG.   2. Формат сообщения На рисунке (2) представлена полная структура сообщения запроса NETCONF YANG;       3. Структура взаимодействия В NETCONF RPC-запрос, инициированный клиентом, и ответ от сервера кодируются в XML и содержатся соответственно в элементах и . Эта структура запрос-ответ не зависит от протокола транспортного уровня; некоторые основные элементы RPC перечислены ниже: Элемент используется для инкапсуляции запроса, отправленного клиентом NETCONF серверу NETCONF. Сервер NETCONF отправляет элемент в ответ на каждый запрос . Если во время обработки запроса возникает какая-либо ошибка или тревога, сервер NETCONF вернет сообщение , содержащее только элемент клиенту NETCONF. Если во время обработки запроса не возникает ошибок или тревог, сервер NETCONF возвращает сообщение , содержащее только элемент клиенту NETCONF.   IV. Конфигурация базы данныхNETCONF определяет полный набор параметров конфигурации устройства. NETCONF определяет существование одной или нескольких баз данных конфигурации и позволяет выполнять операции конфигурации над ними. В базовой модели NETCONF доступна только база данных конфигурации . Другие базы данных конфигурации могут быть определены на основе возможностей и доступны только на устройствах, которые поддерживают эти возможности. К ним относятся:   : База данных текущей конфигурации. Эта база данных хранит все текущие активные конфигурации на сетевом устройстве. На устройстве существует только одна база данных конфигурации , и она всегда существует.   : База данных кандидата на конфигурацию. Эта база данных хранит данные конфигурации, которые должны быть зафиксированы в базе данных конфигурации на устройстве. Операции над базой данных конфигурации могут выполняться без влияния на текущую конфигурацию устройства. Операция используется для фиксации конфигурации кандидата. Чтобы поддерживать базу данных конфигурации , устройство должно поддерживать возможность конфигурации кандидата, стандартную возможность NETCONF.   : База данных стартовой конфигурации (аналогично сохраненному файлу конфигурации). Она хранит данные конфигурации, которые необходимо загрузить при запуске устройства. Чтобы поддерживать базу данных конфигурации , устройство должно поддерживать независимую возможность запуска, которая является стандартной возможностью NETCONF.

Из-за сложной конфигурации традиционного CLI и SNM и отсутствия поддержки механизма транзакций, в системе 5G включен протокол управления сетью NETCONF, позволяющий NMS (системе управления сетью) выдавать, изменять и удалять конфигурацию сетевых устройств, подключенных к маршрутизаторам, eNodeB, gNodeB, DU, CU или RU. Принцип работы, структура и сеанс обслуживания следующие:   I. Принцип работы Система NETCONF содержит как минимум одну NMS, которая управляет всеми сетевыми устройствами, как показано на рисунке ниже. Архитектура NETCONF содержит две роли: клиент и сервер     II. Характеристики структуры системы NETCONF содержит как минимум одну NMS, которая управляет всеми сетевыми устройствами, включая:   2.1 Клиент предоставляет следующие функции   Использовать NETCONF для управления сетевыми устройствами. Отправлять RPC-запросы на сервер NETCONF для запроса или изменения одного или нескольких значений параметров. В соответствии с сигналами тревоги и событиями, отправленными сервером NETCONF управляемого устройства, понимать состояние управляемого устройства. 2.2 Когда сервер получает запрос от клиента, он анализирует запрос и отправляет ответ клиенту. Когда управляемое устройство испытывает сбой или другой тип события, сервер NETCONF сообщает о тревоге или событии клиенту через механизм уведомлений, позволяя клиенту понимать состояние управляемого устройства.   III. Сеанс NETCONF: Как показано на рисунке ниже, клиент и сервер обмениваются данными, используя механизм RPC. Обмен данными разрешен только после установления безопасного сеанса с ориентацией на соединение между ними. Клиент отправляет RPC-запрос на сервер, который обрабатывает запрос и возвращает ответ клиенту. Клиент и сервер NETCONF обмениваются данными, используя механизм RPC. Обмен данными разрешен только после установления безопасного сеанса с ориентацией на соединение. Процесс установления и завершения сеанса выглядит следующим образом:       Клиент устанавливает SSH-соединение с сервером и, после завершения аутентификации и авторизации, устанавливает сеанс NETCONF с сервером. Клиент и сервер обмениваются сообщениями Hello для согласования возможностей. Клиент отправляет один или несколько RPC-запросов на сервер. Ниже перечислены некоторые примеры запросов:  Изменить и зафиксировать конфигурацию;  Запросить данные конфигурации или статус;  Выполнить операции обслуживания на устройстве;  Клиент завершает сеанс NETCONF;  SSH-соединение завершается.

  NETCONF - это полное название протокола Network Configuration Protocol, представляющего собой протокол управления сетью, который позволяет NMS (Network Management System) выдавать, изменять и удалять конфигурацию подключенных сетевых устройств (маршрутизаторов, eNodeB, gNodeB, DU, CU или RU). NETCONF разработан и стандартизирован IETF; в то время как для O-RAN он находится в ведении WG (Рабочей группы 4).     I. Протокол NETCONF использует кодирование данных XML (Extensible Markup Language) для обработки данных конфигурации и сообщений протокола; он основан на концепции сервера и клиента и использует механизм RPC (Remote Procedure Call) для достижения связи между сервером и клиентом. Клиентский процесс выполняется на NMS, который может быть скриптом или приложением, а сервером является типичное сетевое устройство.   II. Характеристики NETCONF следующие: Он использует многоуровневую структуру протокола, что делает его более подходящим для сетей по требованию, автоматизированных и облачных. Он используется для выдачи, изменения и удаления конфигураций сетевых устройств. XML (Extensible Markup Language) используется для кодирования данных конфигурации и сообщений протокола. Основываясь на концепции сервер-клиент, NMS выступает в роли клиента, а сетевое устройство - в роли сервера. Связь между серверами и клиентами осуществляется с использованием механизма RPC (Remote Procedure Call). Операции выполняются на основе модели YANG, что снижает сетевые сбои, вызванные ошибками ручной настройки. NETCONF отвечает потребностям сетевой автоматизации. Он предоставляет механизмы безопасности, такие как аутентификация и авторизация, для обеспечения безопасной передачи сообщений. Он также предоставляет механизмы транзакций, поддерживающие классификацию данных, хранение и миграцию, поэтапную фиксацию и изоляцию конфигурации. Он поддерживает комплексную доставку, проверку и откат конфигурации, сводя к минимуму влияние на сетевые службы. Он позволяет поставщикам определять свои собственные протокольные операции для реализации уникальных возможностей управления. 3. Зачем нужен NETCONF? Ключевым требованием облачных сетей является автоматизация сети для быстрого, по требованию предоставления услуг и автоматизированного управления операциями. Традиционные методы, такие как CLI и SNM, не могут удовлетворить это требование. Они имеют следующие ограничения, которые устраняет NETCONF.   31. Недостатки CLI: Во-первых, конфигурация сложна. Во-вторых, следующее: CLI различаются в зависимости от поставщика, требуя от пользователей изучения и адаптации скриптов CLI для каждого поставщика. Частые изменения структуры и синтаксиса CLI затрудняют обслуживание скриптов CLI. Вывод команд неструктурирован, непредсказуем и легко изменяется, что затрудняет автоматический разбор скриптов CLI. 3.2 Недостатки SNMP: SNMP не поддерживает транзакции, что приводит к неэффективной конфигурации. SNMP использует протокол User Datagram Protocol (UDP), который не обеспечивает надежную, последовательную передачу данных и не имеет эффективных механизмов безопасности. SNMP не имеет механизма для отправки транзакций конфигурации. SNMP управляет конфигурацией устройства на основе каждого устройства и не поддерживает конфигурацию на уровне сети или совместную работу нескольких устройств.

NETCONFполное название протокола конфигурации сети, который является протоколом управления сетью, который позволяет выдавать NMS (система управления сетью),Изменить и удалить конфигурацию подключенных сетевых устройств (маршрутизаторов), eNodeB, gNodeB, DU, CU или RU). NETCONF разрабатывается и стандартизируется IETF; в то время как для O-RAN он находится под ответственностью WG (Рабочая группа 4).   1.Протокол NETCONFиспользует XML (Extensible Markup Language) для кодирования данных для обработки конфигурационных данных и протокольных сообщений;Он основан на концепции сервера и клиента и использует механизм RPC (Remote Procedure Call) для достижения связи между сервером и клиентом.Клиентский процесс работает на NMS, который может быть сценарием или приложением, а сервер - типичным сетевым устройством.   2.Характеристики NETCONFследующие: Он использует многоуровневую протокольную структуру, что делает его более подходящим для сетей по требованию, автоматизированных и облачных сетей. Он используется для выпуска, изменения и удаления конфигураций сетевых устройств. XML (Extensible Markup Language) используется для кодирования данных конфигурационных данных и протокольных сообщений. Основываясь на концепции сервера и клиента, NMS действует как клиент, а сетевое устройство действует как сервер. Связь между серверами и клиентами осуществляется с использованием механизма RPC (Remote Procedure Call). Операции выполняются на основе модели YANG, уменьшая сбои сети, вызванные ошибками в ручной конфигурации. NETCONF отвечает потребностям сетевой автоматизации. Он обеспечивает механизмы безопасности, такие как аутентификация и авторизация для обеспечения безопасной передачи сообщений.хранение и миграция, поэтапное обязательство и изоляция конфигурации. Он поддерживает всеобъемлющую доставку конфигурации, проверку и отказ, минимизируя воздействие на сетевые услуги. Он позволяет поставщикам определять свои собственные операции протокола для реализации уникальных возможностей управления.     3Зачем нужен NETCONF?Ключевым требованием облачных сетей является автоматизация сети для быстрого предоставления услуг по требованию и автоматизированного управления операциями.Традиционные подходы, такие как CLI и SNM, не могут соответствовать этому требованию.У них есть следующие ограничения, которые решает NETCONF.   31Недостатки CLI: во-первых, конфигурация сложная. во-вторых, следующее: CLI варьируются в зависимости от поставщика, что требует от пользователей изучения и адаптации скриптов CLI для каждого поставщика. Структура и синтаксис CLI часто меняются, что затрудняет обслуживание скриптов CLI. Выход команды неструктурирован, непредсказуем и легко изменяется, что затрудняет автоматический анализ скриптов CLI.   3.2 Недостатки SNMP: SNMP не поддерживает транзакции, что приводит к неэффективной конфигурации. SNMP использует протокол пользовательской датаграммы (UDP), который не обеспечивает надежную передачу данных в последовательности и не имеет эффективных механизмов безопасности. SNMP не имеет механизма подачи конфигурационных транзакций. SNMP управляет конфигурацией устройств устройство за устройством и не поддерживает конфигурацию на сетевом уровне или совместную конфигурацию нескольких устройств.

  В системе 5G запрос переключения пути (PATH SWITCH REQUEST) представляет собой запрос терминала (UE) на установление сигнального соединения с 5GC и, при необходимости, запрос переключения нисходящего транспортного канала NG-U на новый сервисный узел. Этот запрос может завершиться неудачей по разным причинам; 3GPP определяет его в TS 38.413 следующим образом.   I. Сбой операции запроса пути   Как показано на рисунке 8.4.4.3-1 ниже, на сбой запроса обычно отвечает AMF после того, как узел NG-RAN выдает «PATH SWITCH REQUEST».       II. Сценарии сбоя операции запроса обычно следующие:   Если 5GC не удается переключить точку завершения нисходящего канала NG-U на новую (сервисную) точку завершения для всех ресурсов сессии PDU, AMF должен отправить сообщение PATH SWITCH REQUEST FAILURE узлу NG-RAN.   Узел NG-RAN должен освободить соответствующие потоки QoS и считать сессии PDU, указанные в IE «Список освобождения ресурсов сессии PDU», содержащемся в сообщении PATH SWITCH REQUEST FAILURE, освобожденными.   Соответствующее значение причины для каждой освобожденной сессии PDU содержится в IE «Неудачная передача запроса переключения пути» в сообщении PATH SWITCH REQUEST FAILURE.   III. Запрос нештатных операций   Если AMF получает сообщение, содержащее несколько IE идентификаторов сессии PDU, установленных в одно и то же значение (в IE «Ресурс сессии PDU для переключения» в нисходящем списке), AMF должен отправить сообщение PATH SWITCH REQUEST FAILURE узлу NG-RAN. Кроме того,   В качестве исключения, AMF может сгенерировать IE «Неудачная передача запроса переключения пути».   Если IE «Частично разрешенный NSSAI» получено в сообщении PATH SWITCH REQUEST ACKNOWLEDGE, и общее количество S-NSSAI, содержащихся в «Разрешенном NSSAI» и «Частично разрешенном NSSAI», превышает 8, узел NG-RAN должен считать процедуру завершившейся неудачей.   Если какой-либо S-NSSAI, присутствующий в IE «Частично разрешенный NSSAI», также присутствует в IE «Разрешенный NSSAI», узел NG-RAN должен считать процедуру завершившейся неудачей.

Передача статуса RAN - это процесс передачи информации о статусе восходящей и нисходящей связи терминала (UE) из узла исходной радиосети доступа (RAN) в целевой узел RAN в сети 5G.Это обычно происходит во время передачи или сценариев двойного подключенияВ ходе этого процесса AMF передает информацию о данных нисходящей связи (например, количество перенаправленных пакетов),вместе со статусом SN и порядковым номером PDCP (Packet Data Convergence Protocol) и номером гиперкадра (HFN) как для данных восходящей связи, так и для данных нисходящей связи, на цель RAN.   Я.Передача статуса RAN с подключенной ссылкойrПроцесс передачи использует сигнализацию, связанную с UE. Конкретный процесс показан на рисунке 8.4.6.2-1 ниже, где:   The source NG-RAN node initiates this process by stopping allocating PDCP SNs for downlink SDUs and sending an UPLINK RAN STATUS TRANSFER message to the AMF when it deems the transmitter/receiver status frozen. Для каждой DRB, для которой применяется сохранение состояния PDCP-SN и HFN, исходный узел NG-RAN должен включать ID DRB IE, UL COUNT IE,и DL COUNT IE в списке передачи статуса субъекта DRB IE в прозрачном контейнере передачи статуса RAN IE сообщения UPLINK RAN STATUS TRANSFER. Для каждой DRB, для которой исходный узел NG-RAN принял запрос на переадресацию восходящей связи от целевого узла NG-RAN,источник NG-RAN может также включать отсутствующие и полученные SDU восходящей связи в SDU UL PDCP IE сообщения UPLINK RAN STATUS TRANSFER.   II. Второй этапПередача статуса RAN по нижней линии связи Целью является реализация процедур передачи без потерь на основе NG-RAN с использованием сигнализации, связанной с UE. Конкретный процесс показан на рисунке 8.4.7.2-1 ниже, где:     AMF инициирует эту процедуру, отправляя сообщение DOWNLINK RAN STATUS TRANSFER к целевому узлу NG-RAN. Целевой узел NG-RAN выполняет эту передачу в соответствии с TS 38.300 и с использованием полной конфигурации игнорируют информацию, полученную в этом сообщении. Для каждого DRB в прозрачном контейнере IE для передачи статуса РАН, который подлежит государственному перечню IE для передачи статуса,Целевой узел NG-RAN не должен передавать пакеты данных восходящей связи с PDCP-SN ниже значения UL Count Value IE.. Для каждого DRB в прозрачном контейнере IE для передачи статуса РАН, который подлежит государственному перечню IE для передачи статуса,Целевой узел NG-RAN использует значение DL COUNT Value IE первого пакета данных нисходящей линии связи, которому еще не присвоен PDCP-SN.. Если по крайней мере одна DRB в прозрачном контейнере IE передачи статуса RAN сообщения DOWNLINK RAN STATUS TRANSFER содержит статус приема SDU IE UL PDCP,Целевой узел NG-RAN может использовать его в сообщениях о состоянии, отправляемых в ЕС по радиоинтерфейсу..

  Цель процесса PATH SWITCH REQUEST заключается в установлении связи сигнализации, связанной с UE, с 5GC и, если применимо,запросить, чтобы конечная точка нисходящей связи транспортного носителя NG-U была переведена на новую конечную точку. 3GPP определяет соответствующие процессы 5G в TS38.413 после включения технологий IAB, slicing, positioning и ranging следующим образом;   I. Обработка разрешений МБ   Если сообщение PATH SWITCH REQUEST ACKNOWLEDGE содержит IAB Authorization IE,узел NG-RAN (если он поддерживается) хранит полученную информацию об авторизации IAB в контексте UE и использует ее в соответствии с требованиями TS 38.401.   Если сообщение PATH SWITCH REQUEST ACKNOWLEDGE содержит Mobile IAB Authorization IE,узел NG-RAN (если он поддерживается) хранит полученный статус авторизации Mobile IAB в контексте UE Mobile IAB-MT.. Если разрешение IAB на мобильный IAB-MT установлено на "Неавторизованный", то узел NG-RAN (если он поддерживается) должен гарантировать, что узел Mobile IAB не обслуживает никакого UE.   II. NSSAI и диапазон и позиционирование   Если IE "Частично разрешенный NSSAI" включен в сообщение подтверждения запроса переключения пути (PATH SWITCH REQUEST ACKNOWLEDGE),узел NG-RAN (если он поддерживается) выводит из него частично разрешенный сетевой участок для UE;, хранить и заменять любой полученный ранее "частично разрешенный NSSAI" и использовать его в соответствии с требованиями TS 23.501.   Если в сообщении "Подтверждение запроса на переключение маршрута" (PATH SWITCH REQUEST ACKNOWLEDGE) указана информация "Информация о службе расположения маршрута и боковой трассы", тоузел NG-RAN (если он поддерживается) соответствующим образом обновляет информацию службы расстояния и местоположения боковой трассы ЕС.Если IE "Разрешение на позиционирование в диапазоне и боковом направлении" в Информационной службе по позиционированию в диапазоне и боковом направлении IE установлено на "Неразрешенное," узел NG-RAN (если он поддерживается) должен принять меры для обеспечения того, чтобы UE больше не имел доступа к услугам определения дальности и позиционирования.   III. Процедура представления отчетов о переходе на РРК неактивный   Если запрос RRC на сообщение о неактивном переходе IE включен в сообщение подтверждения запроса на переключение маршрута и установлен на "Однократный отчет о состоянии соединения RRC"," и UE в состоянии RRC_CONNECTED, узел NG-RAN (если он поддерживается) должен отправить сообщение RRC Inactive Transition Report в AMF для сообщения о статусе RRC UE.   Если RRC Inactive Transition Report Request IE включена в сообщение PATH SWITCH REQUEST ACKNOWLEDGE и установлена на "Single RRC Connection Status Report", а UE находится в состоянии RRC_INACTIVE,узел NG-RAN (если он поддерживается) отправляет сообщение RRC Inactive Transition Report в AMF., и последующее сообщение RRC Inactive Transition Report при переходе состояния RRC на RRC_CONNECTED.   Если RRC неактивный запрос на отчет о переходе IE включен в сообщение PATH SWITCH REQUEST ACKNOWLEDGE и установлен на "Последующий отчет о переходе состояния",узл NG-RAN (если он поддерживается) отправляет сообщение RRC INACTIVE TRANSION REPORT в AMF для сообщения о статусе RRC UE., и последующее сообщение RRC INACTIVE TRANSITION REPORT для сообщения о статусе RRC UE при входе или выходе UE из состояния RRC_INACTIVE.   IV. Процедура уведомления о ресурсах сессии PDU   Если сообщение PATH SWITCH REQUEST ACKNOWLEDGE содержит параметры, связанные с QoS (например,Снижение ссылки на бюджет с отсрочкой по пакетам CN IE или увеличение ссылки на бюджет с отсрочкой по пакетам CN IE), но узел NG-RAN не может успешно принять параметры, то узел NG-RAN должен продолжать использовать старые значения (если таковые имеются), полученные от источника NG-RAN.узел NG-RAN уведомляет AMF посредством отправки сообщения PDU SESSION RESOURCE NOTIFY.    

  Цель процесса запроса пути передачи заключается в установлении соответствующего сигнального соединения между терминалом (UE) и 5GC и, если применимо, запросе точки завершения нисходящего канала транспортного канала NG-U для переключения на новую точку завершения. Для передачи услуг, связанных с UE, в интерфейсе PC5 в Sildlink, 3GPP определяет это в TS38.413 следующим образом:   I. Обработка QoS PC5 Запрос пути при передаче интерфейса PC5 в Sildlink определяется следующим образом:   Если сообщение Path Switch Request Acknowledge (PATH SWITCH REQUEST ACKNOWLEDGE) содержит IE параметра PC5 QoS, узел NG-RAN должен (если поддерживается) использовать его, как определено в TS 23.287. Если сообщение Path Switch Request Acknowledge (PATH SWITCH REQUEST ACKNOWLEDGE) содержит IE параметра A2X PC5 QoS, узел NG-RAN должен (если поддерживается) использовать его, как определено в TS 23.256. Если сообщение Path Switch Request Acknowledge включает IE списка альтернативных наборов параметров QoS, узел NG-RAN должен (если поддерживается) использовать его, как указано в TS 23.502. II. Запрос пути в CE-mode-B и User Plane CIoT Передача определяется следующим образом:   Если сообщение Path Switch Request Acknowledge включает IE ограничения CE-mode-B, IE расширенного ограничения покрытия не установлено в значение «ограничено», и информация расширенного ограничения покрытия, хранящаяся в контексте UE, не установлена в значение «ограничено», узел NG-RAN должен (если поддерживается) сохранить эту информацию в контексте UE и использовать ее, как определено в TS 23.501. Если сообщение Path Switch Request Acknowledge включает IE индикатора поддержки User Plane CIoT UE, узел NG-RAN должен (если поддерживается) сохранить эту информацию в контексте UE и предположить, что UE поддерживает оптимизацию User Plane CIoT 5GS, как указано в TS 23.501. Если сообщение Path Switch Request Acknowledge включает IE идентификатора радиовозможностей UE, узел NG-RAN должен (если поддерживается) использовать его, как указано в TS 23.501 и TS 23.502. III. Ожидаемая активность UE сессии PDU и запрос пути в MDT Передача определяется следующим образом: Для каждой сессии PDU, если сообщение PATH SWITCH REQUEST ACKNOWLEDGE включает IE «Поведение ожидаемой активности UE сессии PDU», узел NG-RAN должен (если поддерживается) обработать эту информацию, как указано в TS 23.501. Если сообщение PATH SWITCH REQUEST ACKNOWLEDGE включает IE «Список PLMN MDT на основе управления», узел NG-RAN должен сохранить его в контексте UE и, если поддерживается, использовать этот список для последующего выбора UE для MDT на основе управления, как определено в TS 32.422. Если сообщение PATH SWITCH REQUEST ACKNOWLEDGE включает IE «Список модификации PLMN MDT на основе управления», узел NG-RAN (если поддерживается) должен использовать этот список для перезаписи любой ранее сохраненной информации списка PLMN MDT на основе управления в контексте UE и использовать полученную информацию для последующего выбора UE для MDT на основе управления, как определено в TS 32.422. Если сообщение PATH SWITCH REQUEST ACKNOWLEDGE включает IE информации о помощи синхронизации времени, узел NG-RAN (если поддерживается) должен сохранить эту информацию в контексте UE и использовать ее, как определено в TS 23.501. IV. Запрос пути в 5G ProSe Передача определяется следующим образом: Если сообщение PATH SWITCH REQUEST ACKNOWLEDGE включает IE авторизации 5G ProSe, узел NG-RAN (если поддерживается) должен соответствующим образом обновить информацию о авторизации ProSe для UE. Если информация авторизации 5G ProSe (IE авторизации 5G ProSe) содержит один или несколько IE, установленных в значение «Не авторизовано», узел NG-RAN (если поддерживается) должен предпринять шаги для обеспечения того, чтобы UE больше не имел доступа к связанным услугам 5G ProSe. Если IE параметров QoS PC5 5G ProSe включен в сообщение PATH SWITCH REQUEST ACKNOWLEDGE, узел NG-RAN (если поддерживается) должен использовать его, как определено в TS 23.304. Если IE информации о подписке Aerial UE включен в сообщение PATH SWITCH REQUEST ACKNOWLEDGE, узел NG-RAN (если поддерживается) должен сохранить эту информацию или перезаписать любую ранее сохраненную информацию в контексте UE и использовать ее, как определено в TS 38.300. Если IE агрегатной максимальной скорости передачи данных PC5 UE 5G ProSe включен в сообщение PATH SWITCH REQUEST ACKNOWLEDGE, узел NG-RAN должен (если поддерживается) выполнить следующие действия: Заменить ранее предоставленную агрегатную максимальную скорость передачи данных PC5 UE 5G ProSe (если доступна в контексте UE) полученным значением; Использовать полученное значение для связи по боковой линии для связанного UE в режиме сетевого планирования для службы 5G ProSe.

  1.Сетевые разделительные разделысеть на независимые варианты использования, каждый из которых предназначен для предоставления специализированных услуг.APN(Названия точек доступа) были первой формой разделения сетей в мобильных сетях, позволяющей операторам разделять свои сети на основе требований к услугам.   2.Сетевые участки 5G, определенных 3GPP, имеют независимые сетевые инстанции с независимым управлением и обработкой уровня пользователя.который используется только в 5G с автономной архитектурой (SA).   3.Сетевые элементы и идентификаторы: развертывание в 5G включает в себя сетевые функции, такие как пользовательское оборудование (UE), сеть радиодоступа следующего поколения (NG-RAN), функции самолета управления (например, AMF, PCF, SMF),и функций уровня пользователя (eКаждый сетевой участок идентифицируетсяS-NSSAI(Slice Service Type), который включаетТип обслуживания на участках (SST)для обозначения службы, к которой относится сетевой участок.SSTтакие значения, как: 1 для расширенной мобильной широкополосной связи, 2 для сверхнадежной связи с низкой задержкой; 3 для массового Интернета вещей, 4 для системы "от транспортного средства к всему" (V2X), 5 для высокопроизводительных машинных коммуникаций. Они также могут использовать локально определенные нестандартные значения SST.   4.Поддержка разрезания сети терминалов: для SA (самостоятельных) терминалов 5G (UE), сконфигурированных с USRP (UE Routing Policy),они могут выбрать S-NSSAI для сетевого разделения (услуг) на основе желаемого приложения (в зависимости от требований качества услуг приложения)Например, первый Galaxy S24 Ultra от Samsung, оснащенный URSP, позволяет выбирать фрагменты и выполнять услуги в рамках системы 5G.   5.Поддержка резки системной сети:ADC(Detection and Control) включена (функция в рамках элементов базовой сети 5G PCF (Policy Control Function) и SMF (Session Management Function)).ADCиспользуется для идентификации приложений или трафика на сетевой стороне, применения таких политик, как качество обслуживания, выставление счетов или перенаправление, а также реализации классификации и приоритетизации трафика в режиме реального времени.   6.Примеры коммерческого развертывания сетевого разреза: Сингапурские телекоммуникации (Singtel) запустилиSingtel 5G+, продвинутая инновация "сетевого нарезания", которая обеспечивает новый стандарт подключения и приоритетный опыт через три ключевых функции: Singtel 5G+: единственная сеть, использующая полосу 700 МГц, обеспечивающую оптимальное покрытие по всей стране, даже в помещениях. Singtel 5G+ Улучшенный: Более широкий охват и более высокие скорости, с постоянной скоростью до 2x. Приоритет Singtel 5G+: приоритетные сетевые каналы с 4x более высокой скоростью, всегда отдавая приоритет услугам и обнаруживая новые

3GPP определяет следующее в TS 38.413 в отношении повышенного ограничения покрытия, увеличения времени подключения, авторизации V2X-сервиса,обработки запросов и передачи маршрута для терминалов агрегации боковой связи в системе 5G:   I. Усиление ограничения охвата и увеличение времени подключения   Если сообщение подтверждения запроса переключения пути (PATH SWITCH REQUEST ACKNOWLEDGE) включаетУсиленное ограничение охвата IE, узел NG-RAN ДОЛЖЕН (если он поддерживается) хранить эту информацию в контексте UE и использовать ее в соответствии с определением в TS 23.501.   Если сообщение подтверждения запроса переключения пути (PATH SWITCH REQUEST ACKNOWLEDGE) включаетПродленное время подключения IE, узлы NG-RAN ДОЛЖНЫ (если они поддерживаются) использовать его в соответствии с определением в TS 23.501.   Если сообщение PATH SWITCH REQUEST ACKNOWLEDGE содержит информацию о дифференциации UE IE, то узел NG-RAN (если он поддерживается) должен хранить эту информацию вЕСконтекст для дальнейшего использования в соответствии с ТС 23.501.   II. Разрешение на предоставление услуг NR V2X   Если сообщение PATH SWITCH REQUEST ACKNOWLEDGE включает в себя IE авторизации службы NR V2X,узел NG-RAN (если он поддерживается) должен соответственно обновлять информацию об авторизации службы NR V2X для UE;.   Если разрешение на обслуживание NR V2X IE включает в себя одно или несколько IEs, установленных на "Неавторизованное"," узел NG-RAN (если он поддерживается) должен принять меры для обеспечения того, чтобы UE больше не имел доступа к связанным услугам.   Если сообщение PATH SWITCH REQUEST ACKNOWLEDGE включает в себя IE авторизации службы LTE V2X,узел NG-RAN (если он поддерживается) должен соответственно обновлять информацию об авторизации службы LTE V2X для UE;.Если разрешение на обслуживание LTE V2X IE содержит одно или несколько IEs, установленных на "Неавторизованное"," узел NG-RAN (если он поддерживается) должен принять меры для обеспечения того, чтобы UE больше не имел доступа к связанным услугам.   Если разрешение на обслуживание NR A2X IE содержит одно или несколько IEs, установленных на "Неавторизованное"," узел NG-RAN (если он поддерживается) должен принять меры для обеспечения того, чтобы UE больше не имел доступа к связанным услугам.   Если сообщение "Подтверждение запроса переключателя пути" (PATH SWITCH REQUEST ACKNOWLEDGE) содержит IE авторизации службы LTE A2X,узел NG-RAN (если он поддерживается) должен соответственно обновлять информацию об авторизации службы LTE A2X для UE..   Если IE авторизации службы LTE A2X содержит одну или несколько IE, установленных на "Неавторизованный"," узел NG-RAN (если он поддерживается) должен принять меры для обеспечения того, чтобы UE больше не имел доступа к связанным услугам.   III. Пристрастие и агрегирование   Если сообщение PATH SWITCH REQUEST ACKNOWLEDGE содержит NR UE Sidelink Aggregate Maximum Bit Rate IE, то узел NG-RAN (если он поддерживается) должен выполнять следующие операции: Заменить ранее предоставленную максимальную скорость передачи битов совокупной ссылки UE Sidelink (если она доступна в контексте UE) полученным значением; Использовать полученное значение для сопутствующей связи с соответствующим UE в NR V2X, обслуживающем режим планирования сети.   Если сообщение PATH SWITCH REQUEST ACKNOWLEDGE содержит LTE UE Sidelink Aggregate Maximum Bit Rate IE, то узел NG-RAN (если он поддерживается) должен выполнять следующие операции: Заменить ранее предоставленную максимальную скорость передачи битов совокупной ссылки UE Sidelink (если она доступна в контексте UE) полученным значением; Использовать полученное значение для коммуникаций с присоединенным UE в режиме планирования сети LTE V2X. Если сообщение PATH SWITCH REQUEST ACKNOWLEDGE содержит совокупную максимальную скорость передачи битов NR A2X UE PC5 IE, то узел NG-RAN (если он поддерживается) должен выполнять следующие операции: Заменить ранее предоставленную NR A2X UE PC5 совокупную максимальную скорость передачи битов (если она доступна в контексте UE) полученным значением; В режиме сетевого планирования использовать полученное значение для сетевой связи NR A2X для соответствующего UE. Если сообщение PATH SWITCH REQUEST ACKNOWLEDGE включает в себя совокупную максимальную скорость передачи битов LTE A2X UE PC5 IE, то узел NG-RAN (если он поддерживается) должен выполнять следующие операции: Заменить ранее предоставленную совокупную максимальную скорость передачи данных LTE A2X UE PC5 (если она доступна в контексте UE) полученным значением; В режиме сетевого планирования использовать полученное значение для связи со службой LTE A2X для соответствующего UE.