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

Из-за сложной конфигурации традиционного 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.

  В системе 5G передачаЗапрос на путьявляется просьбой терминала (UE) установить с 5GC связь сигнализации, связанную с UE, и, если применимо,запросить, чтобы конечная точка спусковой связи на носителе NG-U была переведена на новую конечную точку;Поскольку 5G поддерживает все большее количество типов услуг, содержание запросов на пути во время передачи станет все более сложным.   I. Бюджет по задержке пакетов   ЕслиСнижение расходов на пакеты CNIE включается в сообщение "Подтверждение запроса переключения маршрута" (PATH SWITCH REQUEST ACKNOWLEDGE)узл NG-RAN ДОЛЖНО (если он поддерживается) заменить ранее предоставленную CN Packet Delay Budget Downlink (если таковая имеется) и использовать ее в соответствии с требованиями TS 23.502.   ЕслиСсылка на расширенную сетьIE включается в сообщение Ack Transport IE просьбы Ack No WLEDGE,узел NG-RAN должен (если он поддерживается) заменить ранее предоставленную расширенную систему поддержки (если таковая имеется) и использовать ее в соответствии с требованиями TS 23.502.   II. Обработка взрывных данных   Если в сообщении "Путь переключения запроса Ack Transport IE" сообщения "Путь переключения запроса Ack" включено "Время прибытия взрыва" (Burst Arrival Time Downlink IE),узел NG-RAN (если он поддерживается) заменяет ранее предоставленное значение (если таковое имеется) и использует его в соответствии с требованиями TS 23.502.   III. Неактивные РРК и обработка информации об оказании содействия основной сети   Если в сообщении подтверждения запроса на переключение маршрута включена основная информация об оказании помощи сети RRC INACTIVE IE,узел NG-RAN (если он поддерживается) должен хранить эту информацию в контексте UE и использовать ее для решений состояния RRC_INACTIVE и конфигурации РНК UE и поиска RAN (если таковые имеются)., как описано в ТС 38.300.   Если основная информация об оказании помощи сети RRC INACTIVE IE включает в себя MICO All PLMN IE,узел NG-RAN (если он поддерживается) рассматривает область регистрации ЕС как полный PLMN и игнорирует список TAI RRC Inactive IE..   Если основная информация об оказании помощи в сети RRC INACTIVE IE включает в себя указание причины вызова голосовой службы IE,узел NG-RAN (если он поддерживается) хранит и использует его в соответствии с требованиями TS 38.300.   Если основная информация об оказании помощи в сети RRC INACTIVE IE включает информацию об оказании помощи PEIPS IE,узел NG-RAN (если он поддерживается) должен хранить его и использовать для обмена сообщениями с подгруппами ЕС в состоянии RRC_INACTIVE, как описано в ТС 38.300.   Если СН МТ СМИ обработки сообщений включена в основную информацию об оказании помощи сети (RRC INACTIVE СМИ),узел NG-RAN должен (если он поддерживается) хранить данный IE и может впоследствии запросить CN выполнить обработку связи MT., как описано в ТС 23.502, в зависимости от реализации.   Если в сообщении "Подтверждение запроса переключения пути" (PATH SWITCH REQUEST ACKNOWLEDGE) включено IE "Поддерживаемая корректировка параметров RAN CN", то узел NG-RAN может использовать этот IE, как описано в TS 23.501.   Если RRC INACTIVE Transition Report Request IE включена в сообщение подтверждения запроса на переключение пути (PATH SWITCH REQUEST ACKNOWLEDGE),узел NG-RAN должен (если он поддерживается) хранить эту информацию в контексте UE.   V. Обработка EPS и SRVCC   Если сообщение PATH SWITCH REQUEST ACKNOWLEDGE включает перенаправление для голосаОтступление EPSIE, узел NG-RAN должен (если он поддерживается) хранить этот IE и использовать его в последующих резервных решениях голосовой EPS, как указано в TS 23.502.   Если сообщение PATH SWITCH REQUEST ACKNOWLEDGE содержит информацию SRVCC Operation Possible IE,узел NG-RAN должен (если он поддерживается) хранить полученное содержание SRVCC Operation Possible IE в контексте UE и использовать его в соответствии с определением в TS 23.216.