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

  1Перегрузка системы:В сетях 5G,"перегрузка"Относится к чрезмерному трафику или слишком большому количеству устройств, пытающихся подключиться одновременно, перегружающих ресурсы сети и приводящих к перегрузке, медленной скорости или сбоям подключения.Стратегии по борьбе с этой перегрузкой включают освобождение большего количества лицензированного спектра., распределение ресурсов посредством разделения сети и основных функций сети и внедрение механизмов, таких как ограничение, таймеры выхода и сообщения о перегрузке, для эффективного контроля и управления трафиком.   2. Процесс запуска перегрузкиуведомляет узел NG-RAN об уменьшении сигнальной нагрузки, направляемой на соответствующую AMF. Этот процесс инициирования использует сигнализацию, не связанную с UE. Как показано на рисунке 8.7.7.2-1 ниже, процесс инициирования включает:     Узлу NG-RAN, получающему сообщение об инициировании перегрузки, следует предполагать, что принимающая AMF находится в перегруженном состоянии. Если сообщение о начале перегрузки содержит действие IE перегрузки и действие IE ответа AMF на перегрузку, то узел NG-RAN использует его для идентификации соответствующего сигнального трафика.Эта информация используется, когда действие перегрузки IE настроено на: ¢Отказать установлению соединения RRC для передачи данных, не связанных с экстренными мобильными устройствами ¢ (т.е. отклонить трафик, соответствующий RRC, вызывает ¢mo-data ¢, ¢mo-SMS ¢, ¢mo-VideoCall ¢,и "mo-VoiceCall" в TS 38.331 или "мо-данные" и "мо-голосовые звонки" в TS 36.331), или Отказаться от установления соединения RRC для сигнализации (т.е. отклонить трафик, соответствующий RRC, вызывает “mo-data”, “mo-SMS”, “mo-signalling”, “mo-VideoCall” и “mo-VoiceCall” в TS 38.331 или "мо-данные", "мо-сигнализация" и "мо-голосовой звонок" в TS 36.331), или ¢ Разрешить установление соединения RRC только для аварийных сеансов и мобильных оконченных служб ¢ (т.е. разрешить только трафик, соответствующий TS 38.331 или RRC вызывает "чрезвычайные ситуации" и "mt-Access" в TS 36.331), или "Установление соединения RRC разрешено только для сеансов с высоким приоритетом и мобильных оконченных служб" (т.е. только трафик, соответствующий RRC, вызывает "highPriorityAccess", "mps-Priority Access"," "mcs-PriorityAccess" и "mt-Access" в TS 38.331 или "highPriorityAccess", "mo-ExceptionData" и "mt-Access" в TS 36.331 разрешены). 3Перегрузка:NG-RAN обрабатывает ситуацию следующим образом: Если сообщение OVERLOAD START содержит указание на снижение нагрузки на движение AMF IE, сигнальное движение уменьшается на указанный процент; в противном случае,только сигнальное движение, не обозначенное как отклоненное, направляется в АМФ. Если в сообщении OVERLOAD START включен список NSSAI IE для запуска перегрузки, то узел NG-RAN должен: Если указание на снижение нагрузки на дорожное движение на участке IE присутствует, сократите сигнальный трафик UE на указанный процент, provided that the IE is present and the requested NSSAI contains only the S-NSSAI contained in the Overload Start NSSAI List IE and the signaling traffic reduction indicated by the Overload Action IE in the Slice Overload Response IEВ противном случае, убедитесь, что только сигнальный трафик из UE (если запрошенный NSSAI совпадает, only signaling traffic from the UE's requested NSSAI containing S-NSSAIs other than the S-NSSAI contained in the Overload Start NSSAI List IE) or signaling traffic not reduced as indicated by the Overload Action IE in the Slice Overload Response IE) is sent to the AMF. В случае, если происходит контроль перегрузки и узел NG-RAN получает новое сообщение OVERLOAD START, то узел NG-RAN должен заменить ранее полученное содержание сообщения новым содержанием.

  1. AMF (Функция управления доступом и мобильностью) является критически важным элементом плоскости управления в 5G, отвечающим за управление доступом пользовательского оборудования (UE), мобильностью и безопасностью в системе 5G. Она обрабатывает первоначальную регистрацию и аутентификацию UE, а также управляет хэндоверами между сотовыми ячейками сети и сетями доступа. AMF взаимодействует с другими сетевыми функциями (например, SMF) для установления и поддержания сессий передачи данных для пользователей.   2. Обязанности AMF разделены на следующие области: Регистрация и аутентификация UE: AMF аутентифицирует UE, проверяет его идентификационные данные и учетные данные подписки, а также предоставляет ему доступ к услугам 5G. Управление мобильностью: Отвечает за обработку сложного процесса перемещения UE из одной ячейки в другую или между различными сетями радиодоступа (NG-RAN). Управление контекстом: Поддерживает контекст UE, который включает информацию о текущем местоположении UE, состоянии сессии и безопасности. Взаимодействие с другими сетевыми элементами SMF (Функция управления сессиями): AMF взаимодействует с SMF для установления, изменения и управления сессиями передачи данных пользователей. UDM (Унифицированное управление данными): Она взаимодействует с UDM для получения и управления информацией о подписке пользователя.      AUSF (Функция сервера аутентификации): AMF выбирает соответствующую AUSF для аутентификации идентификатора UE во время регистрации. NSSF (Функция выбора сетевого среза): AMF использует NSSF для обнаружения и выбора соответствующего сетевого среза и функций на основе местоположения и требований UE. Управление сетевыми функциями: AMF использует интерфейс на основе сервисов и функцию репозитория сети (NRF) для обнаружения и выбора других сетевых функций. 3. Индикация статуса AMF процедура предназначена для поддержки функций управления AMF. Эта процедура использует сигнализацию, не связанную с UE, и успешная работа показана на рисунке 8.7.6.2-1 ниже, где:   AMF инициирует эту процедуру, отправляя сообщение «Индикация статуса AMF» узлу NG-RAN. После получения сообщения «Индикация статуса AMF» узел NG-RAN должен предположить, что указанный GUAMI недоступен, и выполнить повторный выбор AMF, как определено в TS 23.501. Если поддерживается, узел NG-RAN должен предпринять соответствующие действия, как указано в TS 23.501, на основе наличия метода таймера для IE удаления GUAMI. Если IE имени резервного AMF включен в сообщение «Индикация статуса AMF», узел NG-RAN должен (если поддерживается) выполнить повторный выбор AMF в соответствии с AMF, указанным в IE имени резервного AMF, как указано в TS 23.501. Если IE расширенного имени резервного AMF включен в сообщение «Индикация статуса AMF», узел NG-RAN должен (если поддерживается) выполнить повторный выбор AMF в соответствии с AMF, указанным в IE расширенного имени резервного AMF, как указано в TS 23.501.

  1. Системные аномалии:Отклонения от проекта могут возникать во время нормальной работы сети 5G. К ним относятся проблемы с производительностью, такие как угрозы сетевой безопасности, помехи сигнала, недостаточное покрытие и потенциальные сбои в программном и аппаратном обеспечении сети. Эти аномалии могут проявляться в виде перебоев в обслуживании, сбоев системы, низкой скорости сети или пропущенных вызовов. Обычно они выявляются путем анализа систем обнаружения аномалий сетевых данных и могут быть разделены на основную сеть и радиосеть.     2. Аномалии 5GC: Если сообщение NG RESET включает IE списка логических NG-соединений, связанных с UE, но ни IE AMF UE NGAP ID, ни IE RAN UE NGAP ID не присутствуют в IE элемента логического NG-соединения, связанного с UE, AMF должен игнорировать IE элемента логического NG-соединения, связанного с UE. AMF может вернуть пустой IE элемента логического NG-соединения, связанного с UE, в IE списка логических NG-соединений, связанных с UE, в сообщении NG RESET ACKNOWLEDGE.     3. Аномалии NG-RAN:Если сообщение NG RESET содержит IE списка логических NG-соединений, связанных с UE, но ни IE AMF UE NGAP ID, ни IE RAN UE NGAP ID не присутствуют в IE элемента логического NG-соединения, связанного с UE, узел NG-RAN должен игнорировать IE элемента логического NG-соединения, связанного с UE. Узел NG-RAN может вернуть пустой IE элемента логического NG-соединения, связанного с UE, в IE списка логических NG-соединений, связанных с UE, в сообщении NG RESET ACKNOWLEDGE.     4. Перекрестное сообщение NG RESETобычно возникает в следующих двух сценариях:   Если процедура сброса NG выполняется в узле NG-RAN, и узел NG-RAN получает сообщение NG RESET от однорангового объекта на том же интерфейсе NG, который связан с одним или несколькими ассоциациями UE, которые ранее было запрошено сбросить (явно или неявно указано в полученном сообщении NG RESET), узел NG-RAN должен ответить сообщением NG RESET ACKNOWLEDGE, как указано в пункте 8.7.4.2.1.   Если процедура сброса NG выполняется в AMF, и AMF получает сообщение NG RESET от однорангового объекта на том же интерфейсе NG, который связан с одним или несколькими ассоциациями UE, которые ранее было запрошено сбросить (явно или неявно указано в полученном сообщении NG RESET), AMF должен ответить сообщением NG RESET ACKNOWLEDGE, как указано в пункте 8.7.4.2.

I.Агрегация несущих: Подобно LTE, агрегация несущих 5G (NR) также увеличивает полосу частот беспроводного спектра, используемую UE, путем объединения нескольких несущих. Каждая агрегированная несущая называется компонентой несущей (CC). В 5G (NR) UE могут поддерживать до 16 смежных и несмежных компонентных несущих (CC) с различными нумерологиями как в диапазонах FR1, так и в FR2. Конфигурации агрегации несущих включают: тип агрегации несущих (внутриполосный, смежный/несмежный или межполосный), количество частотных диапазонов и класс полосы пропускания.   II. Класс полосы пропускания: Класс полосы пропускания агрегации несущих терминала (UE) определяется с использованием алфавитного списка минимальных и максимальных полос пропускания и количества компонентных несущих, которые он может использовать. Ключевые параметры включают: Терминалы 5G ​​(NR) поддерживают до 16 смежных и несмежных компонентных несущих (CC) с различными наборами параметров, когда включена CA. Класс полосы пропускания терминала (UE) представляет собой алфавитный список минимальных и максимальных полос пропускания и количества компонентных несущих (CC). Согласно Release 17, классы агрегации несущих в FR1 варьируются от A до O, что позволяет получить максимальную агрегированную полосу пропускания в 400 МГц. Согласно Release 17, классы агрегации несущих в FR2 варьируются от A до Q, что позволяет получить максимальную агрегированную полосу пропускания в 800 МГц.   III. Класс полосы пропускания агрегации несущих FR1 Категория A: 5G UE настраиваются без агрегации несущих. Максимальный частотный диапазон несущей (BWChannel, max) определяется номером частотного диапазона и набором параметров, который определяет интервал между поднесущими (SCS). Класс A относится ко всем группам отката и позволяет UE вернуться к этой конфигурации, даже когда агрегация несущих не используется. Категория B: Агрегирование двух радиоканалов, общая доступная полоса пропускания для UE составляет от 20 до 100 МГц. Категория C: Агрегирование двух радиоканалов, общая доступная полоса пропускания для UE составляет от 100 до 200 МГц. Категория D: Агрегирование трех радиоканалов, общая доступная полоса пропускания для UE составляет от 200 до 300 МГц. Категория E: Агрегирование четырех радиоканалов, общая доступная полоса пропускания для UE составляет от 300 до 400 МГц. Классы C, D и E относятся к одной и той же группе отката (Fallback Group 1). Категория G: Агрегирование трех радиоканалов, общая доступная полоса пропускания для UE составляет от 100 до 150 МГц. Категория H: агрегирует четыре радиоканала, обеспечивая общую полосу пропускания 150-200 МГц, доступную для пользовательского оборудования (UE). Категория I: агрегирует пять радиоканалов, обеспечивая общую полосу пропускания 200-250 МГц, доступную для пользовательского оборудования (UE). Класс J агрегирует шесть радиоканалов, обеспечивая общую полосу пропускания 250-300 МГц, доступную для пользовательского оборудования (UE). Класс K: агрегирует семь радиоканалов, обеспечивая общую полосу пропускания 300-350 МГц, доступную для пользовательского оборудования (UE). Класс L: агрегирует восемь радиоканалов, обеспечивая общую полосу пропускания 350-400 МГц, доступную для пользовательского оборудования (UE).  Классы G-L относятся к одной и той же группе отката (Fallback Group 2).   IV. Класс полосы пропускания агрегации несущих FR2 Категория A представляет собой конфигурацию 5G для UE без агрегации несущих. Максимальный частотный диапазон несущей (BWChannel, max) зависит от номера диапазона и нумерологии. Класс A относится ко всем группам отката и позволяет UE вернуться к этой конфигурации даже без агрегации несущих. Категория B соответствует общей полосе пропускания после агрегации двух радиоканалов, в диапазоне от 400 МГц до 800 МГц. Категория C соответствует общей полосе пропускания после агрегации двух радиоканалов, в диапазоне от 800 МГц до 1200 МГц. Класс B является конфигурацией отката для класса C; оба относятся к одному и тому же Fallback Group 1 списку отката. Категория D соответствует общей полосе пропускания после агрегации двух радиоканалов, в диапазоне от 200 МГц до 400 МГц. Категория E соответствует общей полосе пропускания после агрегации трех радиоканалов, в диапазоне от 400 МГц до 600 МГц. Категория F соответствует общей полосе пропускания после агрегации четырех радиоканалов, в диапазоне от 600 МГц до 800 МГц. Классы D, E и F относятся к одному и тому же Fallback Group 2 списку отката. Класс G соответствует агрегации двух радиоканалов с общей полосой пропускания от 100 МГц до 200 МГц. Класс H соответствует агрегации трех радиоканалов с общей полосой пропускания от 200 МГц до 300 МГц. Класс I соответствует агрегации четырех радиоканалов с общей полосой пропускания от 300 МГц до 400 МГц. Класс J соответствует агрегации пяти радиоканалов с общей полосой пропускания от 400 МГц до 500 МГц. Класс K соответствует агрегации шести радиоканалов с общей полосой пропускания от 500 МГц до 600 МГц. Класс L соответствует агрегации семи радиоканалов с общей полосой пропускания от 600 МГц до 700 МГц. Класс M соответствует агрегации восьми радиоканалов с общей полосой пропускания от 700 МГц до 800 МГц. Классы G, H, I, J, K, L и M относятся к одному и тому же Fallback Group 3 списку отката.

    I. Сценарий транспорта NAS в нисходящем направленииВ системе 5G процесс транспорта NAS в нисходящем направлении используется, когда AMF необходимо прозрачно отправить сообщения NAS в UE через узел NG-RAN, и существует логическое NG-соединение, связанное с UE, или AMF получил IE RAN UE NGAP ID в сообщении INITIAL UE MESSAGE, или узел NG-RAN отправил сообщение INITIAL UE MESSAGE через другой экземпляр интерфейса NG для запуска логического NG-соединения, связанного с UE.   II. Обработка содержимого транспорта NASВ дополнение к содержимому в 5G System Learning - Downlink NAS Transport, другое содержимое NAS в нисходящем направлении обрабатывается следующим образом:   Если сообщение DOWNLINK NAS TRANSPORT содержит IE UE Radio Capability ID, узел NG-RAN должен (если поддерживается) использовать его, как указано в TS 23.501 и TS 23.502. Если сообщение DOWNLINK NAS TRANSPORT содержит IE Target NSSAI Information, узел NG-RAN может использовать эту информацию, как указано в TS 23.501. Если сообщение DOWNLINK NAS TRANSPORT содержит IE Partially Allowed NSSAI, узел NG-RAN (если поддерживается) должен вывести из него частично разрешенный сетевой сегмент UE, сохранить и заменить любой ранее полученный Partially Allowed NSSAI и использовать его, как указано в TS 23.50. Если сообщение DOWNLINK NAS TRANSPORT содержит IE Masked IMEISV, узел NG-RAN (если поддерживается) должен использовать его для определения характеристик UE для последующей обработки. Если сообщение Downlink NAS Transport содержит IE Mobile IAB Authorization, узел NG-RAN (если поддерживается) должен сохранить полученный статус Mobile IAB Authorization в контексте UE. Если IE Mobile IAB Authorization установлено в значение "Unauthorized" для Mobile IAB-MT, узел NG-RAN (если поддерживается) должен убедиться, что UE не обслуживается этим узлом Mobile IAB. 3. Во время взаимодействия Initial UE MessageПроцедура, даже если IE RAN UE NGAP ID был присвоен в сообщении "Initial UE Message", отправленном через другой экземпляр интерфейса NG, узел NG-RAN ДОЛЖЕН использовать "AMF UE NGAP ID IE" и "RAN UE NGAP ID IE", полученные в сообщении "Downlink NAS Transport", в качестве идентификатора логического соединения.   4. Во время процедуры UE Radio Capability Information IndicationПроцедура, если сообщение Downlink NAS Transport содержит IE UE Capability Information Request, установленное в значение "requested", и информация, связанная с возможностями UE, была успешно получена от UE, узел NG-RAN ДОЛЖЕН запустить процедуру UE Radio Capability Information Indication.   5. Нештатные сценарии транспорта NAS в нисходящем направлении: Если IE Partially Allowed NSSAI получен в сообщении DOWNLINK NAS TRANSPORT, и общее количество S-NSSAI, содержащихся в Allowed NSSAI и Partially Allowed NSSAI, превышает 8, узел NG-RAN ДОЛЖЕН считать процедуру неудачной. Если какой-либо S-NSSAI, присутствующий в IE Partially Allowed NSSAI, также присутствует в IE Allowed NSSAI, узел NG-RAN должен считать процедуру неудачной.

  1.Нижняя линия NAS:Процедура Downlink NAS Transfer используется, когда AMF необходимо только транспарентно отправлять сообщения NAS в UE через узел NG-RAN и существует логическое NG-соединение, связанное с UE,или AMF получила RAN UE NGAP ID IE в сообщении INITIAL UE MESSAGE, или узел NG-RAN инициировал логическое NG-соединение, связанное с UE, путем отправки сообщения INITIAL UE MESSAGE через другой NG-интерфейс.   2.Передача NAS с нижней линиипоказан на рисунке 8.6.2.2-1 ниже, где:   AMF инициирует эту процедуру, отправляя сообщение DOWNLINK NAS TRANSPORT к узлу NG-RAN. Если логическое соединение NG, связанное с UE, не установлено,AMF присваивает UE уникальный идентификатор AMF UE NGAP и включает его в сообщение DOWNLINK NAS TRANSPORT.При полученииAMF-UENGAP ID IE в сообщении DOWNLINK NAS TRANSPORT узел NG-RAN устанавливает логическое NG-соединение, связанное с UE.   Если сообщение DOWNLINK NAS TRANSPORT содержит приоритетное значение RAN Paging IE, то узел NG-RAN может использовать его для определения приоритета UE в состоянии RRC_INACTIVE.NAS-PDU IE содержит сообщение AMF-UE, который передается неинтерпретированным внутри узла NG-RAN. - Что? Если в сообщение Downlink NAS Transport включен перечень ограничений мобильности IE, то узел NG-RAN должен перезаписать любую ранее сохраненную информацию об ограничениях мобильности в контексте UE.Если сообщение о транспортировке NAS на нисходящей линии содержит информацию из списка ограничений на передвижение IE, узел NG-RAN использует эту информацию для: определения цели последующих операций мобильности,и узел NG-RAN предоставляет ЕС информацию о цели операции мобильности; 3. Выберите соответствующий SCG во времяоперация с двойной связью; присваивать соответствующую РНК UE при перемещении ее в состояние RRC_INACTIVE; и, кроме того:   Если в сообщении о транспортировке NAS по нисходящей линии связи не содержится Список ограничений на передвижение IE и ранее не хранилась информация об ограничениях на передвижение,узел NG-RAN предполагает, что ЕС не подлежит ограничениям роуминга и доступа, за исключением мобильности PNI-NPN, описанной в TS 23.501. - Что? Узл NG-RAN должен предполагать, что роуминг или доступ к ячейке CAG разрешен только в том случае, если сообщение о транспортировке NAS с нисходящей связью содержит Список разрешенных PNI-NPN IE, как описано в TS 23.501. - Что? Если сообщение о транспортировке NAS на нисходящей линии связи содержит индекс приоритета RAT/Frequency Selection Priority Index IE, то узел NG-RAN должен (если он поддерживается) использовать его в соответствии с определением в TS 23.501. - Что? Если AMF ранее не отправлял UE Aggregate Maximum Bit Rate IE, он должен быть отправлен в узел NG-RAN.узел NG-RAN должен хранить максимальную совокупную скорость передачи данных UE в контексте UE и использовать полученную максимальную скорость передачи данных UE для всех потоков QoS, не относящихся к GBR, связанных с UE, как определено в TS 23..501. - Что? Если Legacy AMF IE включена в сообщение о транспортировке NAS на нисходящей линии связи,узел NG-RAN считает, что логическая NG-соединение, связанное с этим UE, было перенаправлено из другой AMF, определенной Legacy AMF IE, на эту AMF.. Если Extended Legacy AMF IE включена в сообщение транспорта NAS с нисходящей связью,узл NG-RAN (если он поддерживается) считает, что логическое NG-соединение, связанное с этим UE, было перенаправлено из другой AMF, определенной AMF IE Extended Legacy, на эту AMF.. - Что? Если в сообщении DOWNLINK NAS TRANSPORT включена операция SRVCC Possible IE,узел NG-RAN должен (если он поддерживается) хранить содержание полученной SRVCC Operation Possible IE в контексте UE и использовать его в соответствии с определением в TS 23.216Если в сообщении DOWNLINK NAS TRANSPORT включено расширенное время подключения IE, узел NG-RAN должен (если он поддерживается) использовать его в соответствии с определением в TS 23.501. - Что? Если в сообщении DOWNLINK NAS TRANSPORT включено ограничение расширенного охвата IE, узел NG-RAN должен (если он поддерживается) хранить эту информацию в контексте UE и использовать ее в соответствии с определением в TS 23..501. - Что? Если информация о дифференциации UE IE включена в сообщение DOWNLINK NAS TRANSPORT,узел NG-RAN (если он поддерживается) хранит эту информацию в контексте UE для дальнейшего использования в соответствии с TS 23.50. - Что? Если ограничение IE CE-mode-B включено в сообщение о транспортировке NAS на нисходящей линии связи, а ограничение IE расширенного охвата не установлено на "Ограничено",и информация об Улучшенном ограничении охвата, хранящаяся в контексте UE, не установлена на "Ограничено", узел NG-RAN должен (если он поддерживается) хранить эту информацию в контексте UE и использовать ее в соответствии с определением в TS 23.501. - Что? Если в сообщение о транспортировке NAS с нисходящей связью включена информация о радиоспособностях UE IE, узел NG-RAN должен хранить эту информацию в контексте UE и использовать ее в соответствии с определением в TS 38.300. - Что? Если конечная индикация IE включена в сообщение о транспортировке NAS на нисходящей линии связи и установлена на "Нет дополнительных данных",узл NG-RAN считает, что радиоспособности UE IE являются дополнением к включенному NAS PDU..  

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 управляет конфигурацией устройств устройство за устройством и не поддерживает конфигурацию на сетевом уровне или совместную конфигурацию нескольких устройств.