СПОСОБ И ОБОРУДОВАНИЕ ДЛЯ ОБНОВЛЕНИЯ СЕТИ ПРОИЗВОЛЬНОГО ДОСТУПА В СИСТЕМЕ СВЯЗИ Российский патент 2024 года по МПК H04W28/02 H04W24/10 H04L41/08 

Область техники, к которой относится изобретение

[1] Варианты осуществления в данном документе относятся к обновлению сети радиодоступа (RAN), а более конкретно, к способам и оборудованию для обновления программного обеспечения виртуального RAN-узла сети связи пятого поколения (5G) с использованием сервиса аналитики управляющих данных (MDAS).

Уровень техники

[2] Чтобы удовлетворять спрос на растущий трафик беспроводных данных с момента развертывания систем связи четвертого поколения (4G), прикладываются усилия для разработки улучшенной 5G- или пред-5G-системы связи. Следовательно, 5G- или пред-5G-система связи также называется "выходящей за рамки 4G-сетиʺ или ʺсистемой после LTEʺ.

[3] Считается, что 5G-система связи реализуется в верхних полосах частот (mmWave), к примеру, в полосах частот на 60 ГГц, с тем чтобы добиваться более высоких скоростей передачи данных. Чтобы снижать потери при распространении радиоволн и увеличивать расстояние передачи, в 5G-системах связи обсуждаются формирование диаграммы направленности, массовая технология с многими входами и многими выходами (MIMO), полноразмерная технология MIMO (FD-MIMO), решетчатая антенна, формирование аналоговой диаграммы направленности, крупномасштабные антенные технологии.

[4] Помимо этого, в 5G-системах связи проводятся разработки для улучшения системной сети на основе усовершенствованных небольших сот, облачных сетей радиодоступа (RAN), сверхплотных сетей, связи между устройствами (D2D), беспроводного транзитного соединения, перемещаемой сети, совместной связи, координированной многоточечной передачи (СоМР), подавления помех на приемном конце и т.п.

[5] В 5G-системе разработаны гибридная FSK- и QAM-модуляция (FQAM) и кодирование с наложением окон переменной длительности (SWSC) в качестве усовершенствованной модуляции с кодированием (АСМ), а также интерфейс беспроводного доступа на нескольких несущих с гребенками фильтров (FBMC), неортогональный множественный доступ (NOMA) и множественный доступ на основе разреженных кодов (SCMA) в качестве усовершенствованной технологии доступа.

[6] Элемент сети связи может включать в себя множество программных блоков. Программные блоки должны периодически обновляться для исправления связанных с ошибками проблем и введения новых функций и свойств в элементе сети связи. Оператор сети связи с большой вероятностью должен запускать обновление программного обеспечения конкретного программного блока или конкретного элемента сети связи ночью, что требует вмешательства вручную. Требование вмешательства вручную может напрягать оператора сети связи, поскольку вмешательство вручную требует наличия специализированного персонала наготове для проверки того, являются или нет текущие условия трафика подходящими для запуска обновления программного обеспечения. Поскольку обновление программного обеспечения с большой вероятностью должно прерывать доступность услуг, необходимо обеспечивать то, что трафик является минимальным во время обновления программного обеспечения.

[7] Обновления программного обеспечения в процессе обслуживания обеспечивают возможность сетевому оператору исправлять программные ошибки и добавлять новые функции и свойства в элемент сети связи без прерывания доступности сети. Хотя обновления программного обеспечения в процессе обслуживания являются предпочтительными, применение обновлений программного обеспечения в процессе обслуживания для элементов сети связи требует введения изменений в элементы сети связи.

Сущность изобретения

Техническая задача

[8] Различными иллюстративными вариантами осуществления раскрываются способы и/или оборудование для предоставления модели машинного обучения (ML) для прогнозирования оптимальной временной метки для обновления программного обеспечения виртуальных сетевых элементов 5G-сети на основе анализа параметров, связанных с условиями трафика виртуальных сетевых элементов 5G-сети.

[9] Различными иллюстративными вариантами осуществления обеспечивается возможность автоматического обновления

программного обеспечения виртуальных сетевых элементов посредством интегрирования ML-модели с системой управления облаком (CMS), такой как функция управления и оркестровки сети на основе виртуализации сетевых функций (NFV MANO).

[10] Различными иллюстративными вариантами осуществления формируется аналитическое сообщение с информацией каналов (BIAR), посредством ML-модели, при приеме запроса из NFV MANO предоставить оптимальную временную метку для обновления программного обеспечения виртуальных сетевых элементов, при этом запрос указывает по меньшей мере один целевой виртуальный сетевой элемент и интервал формирования сообщений, при этом NFV MANO инициирует обновление программного обеспечения по меньшей мере одного целевого виртуального сетевого элемента на основе BIAR.

[11] Различными иллюстративными вариантами осуществления формируется Сообщение BIAR на основе данных трафика, связанных с различными типами каналов, при этом данные трафика собираются из по меньшей мере одного целевого виртуального сетевого элемента в 5G-сети.

[12] Различными иллюстративными вариантами осуществления предоставляется Сообщение BIAR в NFV MANO для обеспечения NFV MANO возможности запускать обновление программного обеспечения по меньшей мере одного целевого виртуального сетевого элемента в прогнозированный оптимальный момент времени.

[13] Различными иллюстративными вариантами осуществления сохраняется контекстная информация, связанная с каналами, соединяющими по меньшей мере одно абонентское устройство (UE) с по меньшей мере одним целевым виртуальным сетевым элементом, при этом контекстная информация сохраняется в течение предварительно заданного периода времени и верифицируется после того, как обновление завершается.

Решение задачи

[14] Согласно варианту осуществления настоящего раскрытия предоставляется способ управления обновлением программного обеспечения сетевого элемента сети радиодоступа (RAN) посредством производителя сервиса аналитики управляющих данных (MDAS). Способ может содержать этап, на котором принимают от потребителя MDAS запрос, относящийся к оптимальному времени для обновления программного обеспечения сетевого элемента в RAN. Способ может содержать этап, на котором идентифицируют информацию, относящуюся к выделенному радиоканалу (DRB). Способ может содержать этап, на котором идентифицируют информацию, относящуюся к оптимальному времени для обновления программного обеспечения сетевого элемента, на основе информации, относящейся к DRB. Способ может содержать этап, на котором передают отчет, включающий в себя информацию, относящуюся к оптимальному времени для обновления программного обеспечения сетевого элемента.

[15] Согласно варианту осуществления настоящего раскрытия предоставляется электронное устройство производителя сервиса аналитики управляющих данных (MDAS) для управления обновлением программного обеспечения сетевого элемента сети радиодоступа (RAN). Электронное устройство может содержать память и по меньшей мере один процессор, подключенный к памяти. По меньшей мере один процессор может быть выполнен с возможностью принимать запрос, относящийся к оптимальному времени для обновления программного обеспечения сетевого элемента в RAN. По меньшей мере один процессор может быть выполнен с возможностью идентифицировать информацию, относящуюся к выделенному радиоканалу (DRB). По меньшей мере один процессор может быть выполнен с возможностью идентифицировать информацию, относящуюся к оптимальному времени для обновления программного обеспечения сетевого элемента, на основе информации, относящейся к DRB. По меньшей мере один процессор может быть выполнен с возможностью передавать отчет, включающий в себя информацию, относящуюся к оптимальному времени для обновления программного обеспечения сетевого элемента.

[16] Согласно варианту осуществления настоящего раскрытия предоставляется долговременный машиночитаемый носитель, хранящий программный код, который при его исполнении по меньшей мере одним процессором электронного устройства производителя сервиса аналитики управляющих данных (MDAS) для управления обновлением программного обеспечения сетевого элемента сети радиодоступа (RAN) предписывает электронному устройству выполнять операции. Операции могут содержать прием от потребителя MDAS запроса, относящегося к оптимальному времени для обновления программного обеспечения сетевого элемента в RAN. Операции могут содержать идентификацию информации, относящейся к выделенному радиоканалу (DRB). Операции могут содержать идентификацию информации, относящейся к оптимальному времени для обновления программного обеспечения сетевого элемента, на основе информации, относящейся к DRB. Операции могут содержать передачу отчета, включающего в себя информацию, относящуюся к оптимальному времени для обновления программного обеспечения сетевого элемента.

[17] Эти и другие аспекты вариантов осуществления в данном документе должны лучше приниматься во внимание и пониматься при рассмотрении в сочетании с нижеприведенным описанием и прилагаемыми чертежами. Тем не менее, следует понимать, что нижеприведенное описание, при указании вариантов осуществления и множества их конкретных подробностей, приводится в качестве способа иллюстрации, а не ограничения. Множество изменений и модификаций могут вноситься в пределах объема вариантов осуществления в данном документе без отступления от их сущности, и варианты осуществления в данном документе включают в себя все такие модификации.

Краткое описание чертежей

[18] Вышеуказанные и прочие аспекты, признаки и преимущества определенных иллюстративных вариантов осуществления станут более понятными из нижеследующего подробного описания в сочетании с сопровождающими фигурами чертежей, на которых:

[19] Фиг. 1 иллюстрирует взаимодействие через интерфейс центрального блока в плоскости управления (CU-CP) и центрального блока в пользовательской плоскости (CU-UP) для иллюстративного варианта осуществления;

[20] Фиг. 2 иллюстрирует различные компоненты CU-CP для иллюстративного варианта осуществления;

[21] Фиг. 3 иллюстрирует различные компоненты CU-UP для иллюстративного варианта осуществления;

[22] Фиг. 4 иллюстрирует компоненты каркаса виртуализации сетевых функций (NFV), который виртуализирует сетевые функции узла 5G-сети радиодоступа (RAN) для иллюстративного варианта осуществления;

[23] Фиг. 5 является схемой последовательности операций, иллюстрирующей существующий механизм CU-CP-обновления для иллюстративного варианта осуществления;

[24] Фиг. 6 является блок-схемой, иллюстрирующей процесс, предусмотренный при обновлении программного обеспечения сетевой функциональности виртуальной RAN 5G-сети, согласно различным иллюстративным вариантам осуществления;

[25] Фиг. 7 является схемой последовательности операций, иллюстрирующей поток информации, предусмотренный при автоматическом обновлении программного обеспечения сетевой функциональности сетевого элемента виртуальной 5G RAN, согласно различным иллюстративным вариантам осуществления;

[26] Фиг. 8 иллюстрирует компоненты примерной модели машинного обучения (ML), используемой для прогнозирования временной метки, которая является оптимальной для обновления виртуальных сетевых элементов виртуальной 5G RAN, согласно различным иллюстративным вариантам осуществления;

[27] Фиг. 9 является схемой последовательности операций, иллюстрирующей обновление программного обеспечения CU-CP в прогнозированной оптимальной временной метке, согласно различным иллюстративным вариантам осуществления; и

[28] Фиг. 10 является блок-схемой последовательности операций, иллюстрирующей способ для обновления программного обеспечения виртуального сетевого элемента виртуальной RAN 5G-сети с использованием услуги аналитики управляющих данных (MDAS), согласно различным иллюстративным вариантам осуществления.

Оптимальный режим осуществления изобретения

[29] Иллюстративные варианты осуществления в данном документе, а также их различные признаки и преимущественные подробности поясняются более полно в отношении неограничивающих вариантов осуществления, которые проиллюстрированы на прилагаемых чертежах и подробно описаны в нижеприведенном описании. Описание известных компонентов и технологий обработки опускается с тем, чтобы не затруднять понимание вариантов осуществления в данном документе лишними подробностями. Примеры, используемые в данном документе, имеют намерение просто упрощать понимание способов, которыми могут осуществляться на практике варианты осуществления в данном документе, и дополнительно предоставлять возможность специалистам в данной области техники осуществлять на практике варианты осуществления в данном документе. Соответственно, примеры не должны истолковываться в качестве ограничения объема вариантов осуществления в данном документе.

[30] Архитектура 5G RAN разбивается на два функциональных блока, т.е. на распределенный блок (DU) и центральный блок (CU). Также предусмотрено разделение плоскости управления (CP) и пользовательской плоскости (UP) CU. Следовательно, CU содержит CU-CP и CU-UP.

[31] Фиг. 1 иллюстрирует взаимодействие через интерфейс CU-CP и CU-UP для иллюстративного варианта осуществления.

[32] Как проиллюстрировано на фиг. 1, CU-CP (110) и CU-UP (130) могут непосредственно или опосредованно соединяться между собой с использованием линии связи "точка-точка" с использованием E-1-интерфейса. Е-1-интерфейс отделяет сетевой уровень радиосвязи от транспортного сетевого уровня. Е-1-интерфейс поддерживает обмен информацией между CU-CP (110) и CU-UP (130). Информация может представлять собой связанную с абонентским устройством (UE) или не связанную с UE информацию.

[33] Фиг. 2 иллюстрирует различные компоненты CU-CP для иллюстративного варианта осуществления.

[34] Как проиллюстрировано на фиг. 2, CU-CP (110) содержит три компонента, т.е. компонент (210) управления CU-CP (CU-CP-МС), компонент (230) интерфейса CU-CP (CU-CP-IC) и компонент (250) обработки CU-CP (CU-CP-PC). CU-CP-MC (210) содержит все конфигурируемые базы данных и рабочие базы данных. CU-CP-MC (210) дополнительно может включать в себя данные по производительности и связанные с отказами данные. CU-CP-IC (230) может быть выполнен с возможностью управлять интерфейсами, соединенными с внешними компонентами и CU-CP-PC (250). CU-CP-PC (250) может быть выполнен с возможностью обрабатывать и выполнять все связанные с плоскостью управления запросы, т.е. обрабатывать все связанные с RRC запросы.

[35] Фиг. 3 иллюстрирует различные компоненты CU-UP для иллюстративного варианта осуществления.

[36] Как показано на фиг. 3, CU-UP (130) содержит по меньшей мере три компонента, т.е. компонент (310) управления CU-UP (CU-UP-MC), компонент (330) интерфейса CU-UP (CU-UP-IC) и компонент (350) обработки CU-UP (CU-CP-PC). CU-UP-MC (310) содержит все конфигурируемые базы данных и рабочие базы данных. CU-UP-MC (310) дополнительно может включать в себя данные по производительности и связанные с отказами данные для конкретного CU-UP. CU-UP-IC (330) может быть выполнен с возможностью управлять интерфейсами, соединенными с внешними компонентами и одним или более CU-UP-PC. CU-UP-PC (350) может быть выполнен с возможностью обрабатывать и выполнять все связанные с пользовательской плоскостью запросы, к примеру, связанную с UE и DRB обработку.

[37] Работа CU-CP (110) завершается вручную для проведения критического техобслуживания в течение очень небольшой продолжительности. Обновление программного обеспечения CU-CP может представлять собой критический сценарий техобслуживания. В настоящее время, во время процедуры обновления программного обеспечения, CU-CP (110) инструктирует высвобождение всех каналов, ассоциированных с UE. Ресурсы, которые управляются посредством CU-CP (110) (который завершает работу) для функций каналов, функций обеспечения безопасности, функций управления мобильностью и т.д., должны очищаться во время процедуры обновления программного обеспечения. CU-CP (110) отправляет Е-1-сообщение сброса в CU-UP (130). При приеме E-1-сообщения сброса, CU-UP (130) высвобождает все UE и ассоциированные выделенные радиоканалы (DRB). DRB переконфигурируются в другом CU-CP (CU-CP в состоянии ожидания). CU-CP (110) присоединяет абонентские устройства (UE) к CU-CP в состоянии ожидания (считающемуся активным во время процедуры обновления программного обеспечения).

[38] DRB переконфигурируются снова, когда встает в строй предыдущий CU-CP (теперь обновленный). Обновленный CU-UP может повторно присоединять DRB-каналы к абонентским устройствам (UE) во время процедуры повторного присоединения в CU-CP (110). Это приводит к повторному установлению всех DRB. Высвобождение и (повторное) присоединение DRB-каналов приводят к значительному влиянию на предоставление услуг (с точки зрения прерывания предоставления услуг) и воздействию на функционирование (с точки зрения эксплуатационных затрат).

[39] CU в системе узлов 5G RAN может представлять собой виртуализированный узел-CU RAN, который устанавливается в рыночном центре обработки и хранения данных (MDC) или в краевом центре обработки и хранения данных (EDC). Узел-CU RAN может обрабатывать функциональные возможности уровней управления радиоресурсами (RRC) и протокола конвергенции пакетных данных (PDCP). Виртуализация CU повышает масштабируемость 5G-системы и упрощает работу CU. Виртуализация может представлять собой реализованную технологию виртуализации на платформе виртуализации сетевых функций (NFV).

[40] Фиг. 4 иллюстрирует компоненты каркаса NFV, который виртуализирует сетевые функции узла 5G RAN для иллюстративного варианта осуществления.

[41] Как проиллюстрировано на фиг. 4, каркас NFV содержит функцию (450) управления и оркестровки сети (MANO), виртуализированные сетевые функции (410) (VNF) и -инфраструктуру (430) NFV (NFVI). CU-CP (401) и CU-UP (403, 405) могут реализовываться как VNF (410), которые могут масштабироваться независимо на основе объема трафика. CU-CP (401) может обрабатывать служебные сообщения RRC и PDCP-C (PDCP-управления). CU-UP (403, 405) может обрабатывать пакетные данные, связанные с протоколом туннелирования на основе стандарта GPRS (общей службы пакетной радиопередачи) (GTP), и пакетные данные, связанные с PDCP.

[42] VNF (410) могут исполняться на виртуальных машинах (VM) и выполнять конкретные сетевые функции узлов CU 5G RAN и узлов DU 5G RAN. Следовательно, VNF (410) могут считаться виртуальным узлом CU RAN. В примере, считается, что VNF (410), выполняющие сетевые функции CU-CP (401), исполняются на VM-1, VM-2, VM-3 и VM-4. Считается, что CU-UP разбивается на CU-UP1 (403) и CU-UP2 (405). VNF (410), выполняющие сетевые функции CU-UP1 (403), исполняются на VM-5, VM-6 и VM-8. VNF (410), выполняющие сетевые функции CU-UP2 (405), исполняются на VM-8, VM-9 и VM-10. Сетевые функции CU-CP (401) и CU-UP (403, 405) устанавливаются посредством загрузки VNF (410), выполняющих конкретные сетевые функции на виртуальных машинах (VM). Следовательно, VNF (410), соответствующие сетевым функциям CU-CP (401), обновляются во время обновления программного обеспечения CU-CP.

[43] MANO (450) может включает в себя функцию (451) аналитики управляющих данных (MDAF), окрестратор (453) NFV (NFVO), диспетчер (455) виртуализированных сетевых функций (VNFM), диспетчер (457) виртуализированной инфраструктуры (VIM) и диспетчер (459) физической инфраструктуры (PIM). Диспетчер виртуализированной системы (VSM) предоставляет функции управления для работы и техобслуживания Узла-CU RAN и узла-DU RAN. Помимо этого, VSM предоставляет северный интерфейс для взаимодействия систем функциональной поддержки (OSS). VSM взаимодействует с VNFM (455), который отвечает за управление функциями управления программным обеспечением VNF, такими как загрузка VNF и обновление VNF. VIM (457) может управлять виртуальными ресурсами NFVI (430), т.е. виртуальными вычислениями, виртуальным устройством хранения данных и виртуальной сетью. PIM (459) может управлять аппаратными ресурсами NFVI (430), например, вычислительными аппаратными средствами, аппаратными средствами хранения данных и сетевыми аппаратными средствами.

[44] Фиг. 5 является схемой последовательности операций, иллюстрирующей существующий механизм обновления CU-CP для иллюстративного варианта осуществления. Как проиллюстрировано на фиг. 5, активный CU-CP (510) представляет собой CU-CP, который должен обновляться. UE соединяются с активным CU-CP (510) через DRB. Поскольку CU-CP представляет собой виртуализированный узел CU RAN, VIM (590) предусматривается при обновлении программного обеспечения CU-CP. Когда активный CU-CP (510) обновляется, UE могут соединяться с CU-CP (530), находящимся в состоянии ожидания. После того как UE соединяются с CU-CP (530) в состоянии ожидания, CU-CP (530) в состоянии ожидания становится активным CU-CP (510). Процедура обновления программного обеспечения может запускаться посредством NFVO (570). Графический пользовательский интерфейс NFVO (GUI NFVO) может проверять подробности программных пакетов VNF, функционирующих в качестве CU-CP (выполняющих сетевые функции CU-CP). VNF, которые функционируют в качестве CU-CP, могут считаться активным CU-CP (510).

[45] Если NFVO (570) определяет, что CU-CP должен обновляться, на этапе 501, NFVO (570) может отправлять запрос на обновление VNF в VNFM (550) на этапе 503. Поскольку VNFM (550) управляет функциями управления программным обеспечением VNF, VNFM (550) может перенаправлять запрос на обновление VNF в активный CU-CP (510) на этапе 505. Активный CU-CP (510) может формировать порядок обновления и отслеживать порядок обновления. Порядок обновления представляет собой последовательность, в которой должны обновляться различные компоненты CU-CP. В примере, последовательность обновления может представлять собой CU-CP-MC, далее CU-CP-IC, и далее CU-CP-PC.

[46] Активный CU-CP (510) может отправлять порядок обновления в VNFM (550) на этапе 507. VNFM (550) может ретранслировать порядок обновления активного CU-CP в NFVO (570) на этапе 509. Обновление активного CU-CP инициируется после того, как активный CU-CP (510) отправляет порядок обновления в VNFM (550). UE, присоединенные к активному CU-CP (510), высвобождаются, и DRB, соединяющие UE с активными CU-CP (510), очищаются на этапе 511. По мере того, как DRB очищаются, происходит возникновение события переключения на этапе 513, при этом UE соединяются с CU-CP (530) в состоянии ожидания на этапе 515. VIM (590) может отправлять новые пакеты VNF, для обновления CU-CP-MC, CU-CP-IC и CU-CP-PC, в активный CU-CP (510) через протокол передачи файлов (FTP) на этапе 517.

[47] DRB переконфигурируются в CU-CP (530) в состоянии ожидания, который становится активным CU-CP (510) в ходе всей процедуры обновления программного обеспечения на этапе 519. DRB могут переконфигурироваться снова с предыдущим (ранее активным) CU-CP, когда предыдущий (ранее активный) CU-CP обновляется с новыми пакетами VNF. Обновленный (ранее активный) CU-UP может повторно присоединять DRB-каналы к абонентским устройствам (UE) во время процедуры повторного присоединения в обновленном CU-CP. Обновление CU-CP приводит к потерям данных и операционным потерям, поскольку DRB должны переконфигурироваться в CU-CP (530), находящемся в состоянии ожидания, и повторно присоединяться к активному CU-CP (510) (после обновления). Кроме того, СР-СР (530) в режиме ожидания может создавать SRB на этапе 521. Варианты осуществления в данном документе раскрывают способы и оборудование для обновления программного обеспечения виртуальных сетевых элементов виртуальной SG-сети радиодоступа (RAN) с использованием сервиса аналитики управляющих данных (MDAS). Обновление программного обеспечения выполняется в оптимальной временной метке в пределах оптимального временного окна, при этом оптимальная временная метка прогнозируется на основе анализа параметров, связанных с условиями трафика виртуальных сетевых элементов. Иллюстративные варианты осуществления могут включать в себя формирование, с использованием модели машинного обучения (ML), аналитического сообщения с информацией каналов (BIAR), при приеме, из функции управления и оркестровки сети на основе виртуализации сетевых функций (NFV MANO), запроса предоставить оптимальную временную метку для обновления программного обеспечения виртуальных сетевых элементов. Прогнозированная оптимальная временная метка включается в BIAR и предоставляется в NFV MANO.

[48] NFV MANO может определять, является или нет оптимальная временная метка, которая прогнозируется на основе параметров, связанных с условиями трафика виртуальных сетевых элементов, подходящей для запуска обновления программного обеспечения виртуальных сетевых элементов. Указание основывается на условиях, которые могут определяться на основе BIAR. NFV MANO инициирует обновление программного обеспечения виртуальных сетевых элементов в оптимальной временной метке, включенной в BIAR, которая определяется как подходящая на основе упомянутых условий.

[49] Виртуальные сетевые элементы могут сохранять контекстную информацию, связанную с каналами, которые соединяют по меньшей мере одно абонентское устройство (UE) с виртуальными сетевыми элементами, до инициирования обновления программного обеспечения. Виртуальные сетевые элементы могут сохранять контекстную информацию в течение предварительно заданного периода времени. Виртуальные сетевые элементы верифицируют каналы после того, как обновление программного обеспечения успешно завершено.

[50] Ссылаясь теперь на чертежи, а более конкретно, на фиг. 6-10, на которых аналогичные ссылочные номера обозначают соответствующие признаки согласованно на всех чертежах, показаны различные иллюстративные варианты осуществления. Каждый вариант осуществления здесь может использоваться в сочетании с любым другим описанным здесь вариантом осуществления.

[51] Фиг. 6 является блок-схемой, иллюстрирующей процесс, предусмотренный при обновлении программного обеспечения сетевой функциональности виртуальной сети RAN 5G, согласно вариантам осуществления, раскрытым в данном документе. Варианты осуществления могут обновлять программное обеспечение сетевой функциональности конкретного виртуального сетевого элемента виртуальной 5G RAN. В варианте осуществления, программное обеспечение сетевой функциональности виртуальных сетевых элементов сети четвертого поколения (4G) или сети шестого поколения (6G) может обновляться с использованием упомянутого процесса.

[52] Например, если виртуальный сетевой элемент, который должен обновляться, представляет собой CU-CP, то программное обеспечение для реализации функциональности CU-CP может обновляться. В варианте осуществления, обновление программного обеспечения может выполняться на основе параметров, связанных с трафиком данных в 56-сети. Процедура обновления программного обеспечения может обеспечиваться за счет MDAS (603), который представляет собой компонент NFV MANO. MDAS (603) может запрашиваться на предмет того, чтобы выполнять обновление программного обеспечения посредством NFVO (605), который также представляет собой компонент NFV MANO. MDAS (603) может предоставлять прогнозированное расписание в NFVO (605) для инициирования обновления программного обеспечения виртуального сетевого элемента в виртуальной 5G RAN (611).

[53] В варианте осуществления, процедура обновления программного обеспечения обеспечивается за счет классификатора (601) трафика и MDAS (603). В варианте осуществления, классификатор (601) трафика и MDAS (603) могут составлять часть системы (609) управления элементами (EMS). Классификатор (601) трафика собирает данные, связанные с условиями трафика в виртуальной 5G RAN (611). Данные могут представлять собой параметры, связанные с передачей обслуживания, состояния каналов, типы каналов, восстановление после ошибок и т.д. На основе данных, собранных посредством классификатора (601) трафика, MDAS (603) может определять, является или нет текущий момент времени подходящим для выполнения обновления программного обеспечения. MDAS (603) также может прогнозировать подходящий будущий момент времени для выполнения обновления программного обеспечения сетевого элемента виртуальной 5G RAN (611).

[54] MDAS (603) может отправлять подходящий будущий момент времени для выполнения обновления программного обеспечения сетевого элемента виртуальной 5G RAN (611) в NFVO (605). MDAS (603) может совместно работать с NFVO (605) для проверки достоверности того, должно или нет обновление программного обеспечения выполняться в подходящий будущий момент времени. Точность прогнозирования подходящего будущего момента времени для выполнения обновления программного обеспечения может повышаться через совместную работу. Если NFVO (605) намеревается инициировать процедуру обновления программного обеспечения, NFVO (605) может отправлять запрос на обновление VNF в VNFM (607). VNFM (607) может перенаправлять в запрос на обновление в виртуальную 5G RAN (611) или в сетевой элемент виртуальной 5G RAN (611), который должен обновляться.

[55] Сетевой элемент виртуальной 5G RAN (611) может инициировать обновление программного обеспечения. Иллюстративные варианты осуществления могут включать в себя сохранение состояния или контекста каналов, соединяющих абонентские устройства (UE) с сетевым элементом виртуальной 5G RAN (611). Сетевой элемент виртуальной 5G RAN (611) может загружаться с помощью нового пакета VNF. Действительность каналов может проверяться сетевым элементом виртуальной 5G RAN (611), чтобы гарантировать, что обновление программного обеспечения является успешным.

[56] Фиг. 7 является схемой последовательности операций, иллюстрирующей поток информации, предусмотренный при автоматическом обновлении программного обеспечения сетевой функциональности сетевого элемента виртуальной 5G RAN, согласно вариантам осуществления, раскрытым в данном документе.

[57] В примере, сетевой элемент 703 виртуальной 5G RAN, который должен обновляться, представляет собой CU-CP. Часть сетевого элемента 703, в которой расположен сетевой элемент 703, может представлять собой узел В следующего поколения (gNB). Обновление программного обеспечения сетевой функциональности CU-CP может запускаться автоматически. В варианте осуществления, потребитель 702 MDAS может подписываться на аналитическое сообщение с информацией каналов (BIAR) из производителя 701 MDAS, который может содержать микросхемы, на этапе 711. Потребитель 702 MDAS может представлять собой NFV MANO (NFVO NFV MANO) и может содержать микросхемы. Производитель 701 MDAS представляет собой MDAS (см. фиг. 6), который предоставляется посредством функции аналитики управляющих данных (MDAF), расположенной в EMS.

[58] BIAR может включать в себя параметры, которые обеспечивают возможность потребителю 702 MDAS определять, должно или нет обновление программного обеспечения инициироваться в будущей временной метке. Будущий момент времени прогнозируется производителем 701 MDAS и включается в BIAR. BIAR может формироваться производителем 701 MDAS на основе данных, собранных из целевых gNB. В варианте осуществления, данные могут включать в себя параметры трафика, связанные с условиями трафика целевых gNB.

[59] В варианте осуществления, потребитель 702 MDAS может запрашивать производителя 701 MDAS на предмет того, чтобы предоставлять оптимальную временную метку, в которой процедура обновления программного обеспечения должна запускаться таким образом, что влияние процедуры обновления программного обеспечения на возможности работы операторов и пользователей является низким. Запрос может включать в себя оптимальное временное окно и по меньшей мере один целевой gNB. Интервал формирования сообщений может указывать для производителя 701 MDAS то, что потребитель 702 MDAS предполагает, что производитель 701 MDAS должен указывать оптимальную временную метку для запуска обновления программного обеспечения по меньшей мере одного виртуального сетевого элемента 703 в пределах оптимального временного окна. По меньшей мере один целевой gNB может указывать для производителя 701 MDAS то, что потребитель MDAS предполагает, что производитель 701 MDAS должен анализировать условия трафика конкретного по меньшей мере одного gNB и указывать оптимальную временную метку для запуска обновления программного обеспечения по меньшей мере одного виртуального сетевого элемента 703 по меньшей мере одного целевого gNB.

[60] Производитель 701 MDAS, который может содержать микросхемы, может собирать данные, связанные с условиями трафика по меньшей мере одного целевого gNB, на этапе 713 и 715. Данные могут включать в себя параметры, связанные с качеством обслуживания (QoS), каналами, мобильностью, восстановлением после ошибок и т.д. Производитель 701 MDAS может формировать BIAR на основе собранных данных, связанных с условиями трафика по меньшей мере одного целевого gNB, на этапе 717. BIAR может включать в себя множество параметров, включающих в себя момент прогнозированной будущей временной метки, который является оптимальным для выполнения обновления программного обеспечения по меньшей мере одного виртуального сетевого элемента 703.

[61] После того как BIAR формируется производителем 7 01 MDAS-, BIAR доставляется в потребитель 702 MDAS на этапе 719. Потребитель 702 MDAS решает, следует или нет запускать обновление программного обеспечения по меньшей мере одного виртуального сетевого элемента 703 по меньшей мере одного целевого gNB на основе BIAR на этапе 721. Потребитель 702 MDAS может наблюдать множество параметров, включенных в BIAR, и решать, следует или нет инициировать процедуру обновления программного обеспечения. Потребитель 702 MDAS также может совместно работать с производителем 701 MDAS для того, чтобы повышать точность прогнозирования будущего момента времени, который является подходящим для выполнения обновления программного обеспечения по меньшей мере одного виртуального сетевого элемента 7 03 по меньшей мере одного целевого gNB.

[62] Фиг. 8 иллюстрирует компоненты примерной модели 800 ML, используемой для прогнозирования временной метки, которая является оптимальной для обновления виртуальных сетевых элементов виртуальной 5G RAN, согласно вариантам осуществления, раскрытым в данном документе, модель 800 ML представляет собой компонент в производителе 701 MDAS и выполнена с возможностью формировать Сообщение BIAR. Модель 800 ML обеспечивает возможность интегрирования сформированного сообщения BIAR с потребителем 702 MDAS, т.е. NFV MANO. Модель 800 ML может обеспечивать обновление программного обеспечения в процессе обслуживания виртуальных сетевых элементов 703 в виртуальной 5G RAN. Модель 800 ML обеспечивает возможность автоматического обновления программного обеспечения виртуальных сетевых элементов 703 в виртуальной 5G RAN в оптимальной временной метке. Оптимальная временная метка прогнозируется посредством модели 800 ML и включается в BIAR.

[63] Модель 800 ML уменьшает потенциальные трудности, которые может испытывать оператор сети связи во время обновления программного обеспечения виртуальных сетевых элементов 703. Точное прогнозирование оптимальной временной метки для обновления виртуальных сетевых элементов 703 в виртуальной 5G RAN и обновление программного обеспечения виртуальных сетевых элементов 703 в прогнозированной временной метке приводит к минимальному или малому влиянию обновления программного обеспечения на возможности работы пользователей.

[64] Модель 800 ML содержит механизм 801 предсказания унивариативных временных рядов и механизм 802 оптимизации. Механизм 801 предсказания унивариативных временных рядов и механизм 802 оптимизации представляют собой часть механизма предсказания запуска. Модель 800 ML выполняет предварительную обработку данных и обнаружение оптимальных временных окон. В варианте осуществления, данные содержат информацию, связанную с условиями трафика в виртуальных сетевых элементах 703. Модель 800 ML может собирать информацию, связанную с условиями трафика в виртуальных сетевых элементах 703, на основе множества входных параметров (параметров трафика). Модель 800 ML может формировать BIAR (которое может включать в себя оптимальную временную метку) на основе параметров трафика. Обнаруженное оптимальное временное окно представляет собой временной интервал, в пределах которого находится оптимальная временная метка, для запуска обновления программного обеспечения сетевых элементов 703.

[65] В варианте осуществления, параметры трафика содержат, но не в ограничительном смысле, идентификатор класса 5G QoS (5G QCI), QCI по стандарту долгосрочного развития (LTE), состояние радиоканалов, число модификаций каналов, выполнение передачи обслуживания, индикатор ошибки в протоколе туннелирования по стандарту общей службы пакетной радиопередачи (GPRS) (GTP) и т.д. Механизм 801 предсказания унивариативных временных рядов может включать в себя множество моделей временных рядов. Параметры трафика предоставляются в механизм 801 предсказания унивариативных временных рядов. Число моделей временных рядов, включенных в механизм 801 предсказания унивариативных временных рядов, основано на числе (входных) параметров трафика, подаваемых в механизм 801 предсказания унивариативных временных рядов. В примере, если шесть параметров трафика подаются в механизм 801 предсказания унивариативных временных рядов, механизм 801 предсказания унивариативных временных рядов может включать в себя шесть моделей временных рядов.

[66] Механизм 801 предсказания унивариативных временных рядов может назначать весовые коэффициенты параметрам трафика в различных временных метках. Значение весовых коэффициентов и входных параметров может оказывать влияние на запуск обновления программного обеспечения сетевых элементов 703 в различных временных метках. В варианте осуществления, если значение весового коэффициента в конкретной (текущей или будущей) временной метке является высоким, то параметр трафика, с которым ассоциирован весовой коэффициент, может затруднять запуск обновления программного обеспечения. С другой стороны, если значение весового коэффициента в конкретной временной метке является низким, то параметр трафика может упрощать запуск обновления программного обеспечения.

[67] 5G QCI указывает тип каналов выделения ресурсов. Тип каналов может представлять собой каналы с гарантированной скоростью передачи битов (GBR), критические к задержке каналы и He-GBR-каналы. Механизм 801 предсказания унивариативных временных рядов (модель 1 временных рядов) может использовать тип, чтобы выводить общее число активных сеансов в различных временных метках в пределах оптимального временного окна. На основе числа активных сеансов, модель 1 временных рядов может определять весовой коэффициент, который должен назначаться 5G QCT в различных временных метках. Значение весового коэффициента в конкретной временной метке является прямо пропорциональным числу активных сеансов. Следовательно, когда число активных сеансов является низким, 5G QCI может упрощать запуск обновления программного обеспечения. Аналогично, когда число активных сеансов является высоким, 5G QCI может сокращать или предотвращать запуск обновления программного обеспечения.

[68] LTE QCI указывает GBR- и не-GBR-типы каналов выделения ресурсов. Модель 2 временных рядов механизма 801 предсказания унивариативных временных рядов может использовать тип, чтобы выводить общее число активных GBR-сеансов LTE и активных не-GBR-сеансов LTE в различных временных метках в пределах оптимального временного окна. На основе числа активных сеансов, LTE модель 2 временных рядов может определять весовой коэффициент, который должен назначаться LTE QCI в различных временных метках. Значение весового коэффициента, ассоциированного с LTE QCT в конкретной временной метке, является прямо пропорциональным числу активных GBR-сеансов LTE и активных не-GBR-сеансов LTE. Тем не менее, доля активных GBR-сеансов LTE в весовом коэффициенте больше доли активных не-GBR-сеансов LTE. Следовательно, когда число активных GBR-сеансов LTE и активных не-GBR-сеансов LTE является низким, LTE QCI может упрощать запуск обновления программного обеспечения. Аналогично, когда числа активных GBR-сеансов LTE и активных не-GBR-сеансов LTE являются высокими, LTE QCI может сокращать или предотвращать запуск обновления программного обеспечения.

[69] Состояние радиоканалов указывает то, находится ли радиоканал в активном состоянии или в бездействующем состоянии. Состояние радиоканалов используется для определения состояния соединения по каналу. Модель 3 временных рядов механизма 8 01 предсказания унивариативных временных рядов может использовать состояние радиоканалов, чтобы выводить общее число бездействующих/активных соединений в различных временных метках в пределах оптимального временного окна. Модель 3 временных рядов может определять весовой коэффициент, который должен назначаться состоянию радиоканалов, на основе числа бездействующих/активных соединений в различных временных метках. Значение весового коэффициента, ассоциированного с состоянием радиоканалов в конкретной временной метке, является прямо пропорциональным числу активных соединений. Следовательно, когда число бездействующих соединений является высоким, и число активных соединений является низким, состояние радиоканалов может упрощать запуск обновления программного обеспечения. Аналогично, когда число бездействующих соединений является низким и число активных соединений является высоким, состояние радиоканалов может сокращать или предотвращать запуск обновления программного обеспечения.

[70] Число модификаций каналов может указывать, для конкретного сеанса работы каналов, число раз, когда канал подвергается модификациям с момента создания. Модель 4 временных рядов механизма 801 предсказания унивариативных временных рядов может использовать число модификаций каналов, чтобы определять частоту модификации, которой подвергается каждый из каналов в различных временных метках в пределах оптимального временного окна. Модель 4 временных рядов может определять число сеансов работы каналов, уязвимых для дополнительных модификаций каналов в различных временных метках. Весовой коэффициент, который должен назначаться числу модификаций каналов в конкретной временной метке, основан на числе сеансов, уязвимых для дополнительных модификаций каналов в конкретной временной метке. Значение весового коэффициента, ассоциированного с числом модификаций каналов, является прямо пропорциональным числу сеансов, которые являются уязвимыми для модификаций каналов. Следовательно, когда число сеансов, уязвимых для модификаций каналов, является низким, число модификаций каналов упрощает запуск обновления программного обеспечения. Аналогично, когда число сеансов, уязвимых для модификаций каналов, является высоким, число модификаций каналов сокращает или предотвращает запуск обновления программного обеспечения.

[71] Параметр трафика ʺвыполнение передачи обслуживанияʺ может указывать, подвергается или нет конкретный канал передаче обслуживания. Модель 5 временных рядов механизма 801 предсказания унивариативных временных рядов может использовать ʺвыполнение передачи обслуживанияʺ, чтобы выводить число сеансов работы каналов, которые подвергаются передаче обслуживания в различных временных метках в пределах оптимального временного окна. Весовой коэффициент, который должен назначаться параметру трафика ʺвыполнение передачи обслуживанияʺ, основан на числе сеансов, которые подвергаются передаче обслуживания в различных временных метках. Значение весового коэффициента в конкретной временной метке является прямо пропорциональным числу сеансов, которые подвергаются передаче обслуживания в конкретной временной метке. Следовательно, когда число сеансов, подвергающихся передаче обслуживания, является низким, запуск обновления программного обеспечения упрощается. Аналогично, когда число сеансов, подвергающихся передаче обслуживания, является высоким, запуск обновления программного обеспечения предотвращается или сокращается.

[72] Индикатор ошибки GTP обеспечивает возможность определения того, находится ли тракт GTP в состоянии ошибки и ожидает восстановления либо нет. Модель 6 временных рядов механизма 801 предсказания унивариативных временных рядов может использовать индикатор ошибки GTP для того, чтобы выводить число сеансов работы каналов, которые восстанавливаются вследствие ошибки в своих соответствующих трактах GTP в различных временных метках в пределах оптимального временного окна. Весовой коэффициент, который должен назначаться индикатору ошибки GTP, основан на числе сеансов, которые находятся в состоянии ошибки в различных временных метках. Значение весового коэффициента, ассоциированного с индикатором ошибки GTP в конкретной временной метке, является прямо пропорциональным числу сеансов в состоянии ошибки в конкретной временной метке. Следовательно, когда число сеансов в состоянии ошибки является низким, индикатор ошибки GTP обеспечивает запуск обновления программного обеспечения. Аналогично, когда число сеансов в состоянии ошибки является высоким, индикатор ошибки GTP сокращается или предотвращает запуск обновления программного обеспечения.

[73] Механизм 801 предсказания унивариативных временных рядов может вычислять значение следующей суммы произведений в каждой временной метке в пределах оптимального временного окна:

[74] (весовой коэффициент 5G QCI) * (5G QCI)+(весовой коэффициент LTE QCI) * (LTE QCI)+(весовой коэффициент состояния радиоканалов) * (состояние радиоканалов)+(весовой коэффициент числа модификаций каналов) * (число модификаций каналов)+(весовой коэффициент выполнения передачи обслуживания) * (выполнение передачи обслуживания)+(весовой коэффициент индикатора ошибки GTP) * (индикатор ошибки GTP).

[75] Механизм 801 предсказания унивариативных временных рядов, например, может определять минимальное значение суммы произведений и временную метку, соответствующую минимальному значению суммы произведений, из всех сумм произведений, соответствующих различным временным меткам в пределах оптимального временного окна. Когда оптимальное временное окно содержит будущие временные метки, то минимальное значение суммы произведений может представлять собой прогнозированное значение, которое соответствует будущей временной метке. Механизм 801 предсказания унивариативных временных рядов может считать временную метку с минимальным значением суммы произведений или малым значением суммы произведений, например, выходной ʺбудущей временной меткойʺ. Будущая временная метка может представлять собой оптимальную временную метку, в которой обновление программного обеспечения сетевых элементов 703 должно запускаться, чтобы обеспечивать то, что влияние обновления программного обеспечения на возможности работы пользователей и прерывание предоставления услуг минимизируется или сокращается.

[76] Механизм 801 предсказания унивариативных временных рядов может формировать BIAR, содержащее будущую временную метку, временную метку, в которой формируется BIAR (временную метку формирования сообщений), индикатор того, является или нет временная метка формирования сообщений оптимальной для запуска обновления программного обеспечения виртуальных сетевых элементов 703, прогнозированное число активных GBR DRB в будущей временной метке, прогнозированное число активных не-GBR DRB в будущей временной метке, число активных GBR DRB во временной метке формирования сообщений и прогнозированное число активных не-GBR DRB во временной метке формирования сообщений. Механизм 801 предсказания унивариативных временных рядов может доставлять BIAR в потребитель 702 MDAS (NFV MANO или NFVO).

[77] После того как оптимальная временная метка для запуска обновления программного обеспечения сетевых элементов прогнозируется и предоставляется в ʺMDAS->NFVO 702ʺ, NFVO 702 может предоставлять обратную связь в механизм 802 оптимизации относительно оптимальности прогнозированной будущей временной метки. Механизм 802 оптимизации может проверять достоверность того, является или нет прогнозированная будущая временная метка оптимальной для запуска обновления программного обеспечения, на основе обратной связи, принимаемой из NFVO 702. Если прогнозированная будущая временная метка признается недостоверной, механизм 801 предсказания унивариативных временных рядов может прогнозировать другую оптимальную временную метку. С другой стороны, если достоверность прогнозированной будущей временной метки удостоверена, NFVO 702 может запускать обновление программного обеспечения.

[78] Если число не-GBR DRB больше числа GBR DRB (как указано в BIAR), в конкретной временной метке, на коэффициент или весовой показатель, могут ожидаться потери пакетов. Это условие является оптимальным для того, чтобы предполагать допуск по задержке, что также представляет собой оптимальное условие для обновления. Следовательно, обновление программного обеспечения может запускаться в конкретной временной метке.

[79] Фиг. 8 показывает примерные блоки модели 800 ML, но следует понимать, что другие варианты осуществления не ограничены этим. В других вариантах осуществления, модель 800 ML может включать в себя меньшее или большее число блоков. Дополнительно, метки или названия блоков модели 800 ML используются только в качестве иллюстрации и не ограничивают объем. Один или более блоков могут комбинироваться между собой, чтобы выполнять идентичную или практически аналогичную функцию в модели 800 ML.

[80] Фиг. 9 является схемой последовательности операций, иллюстрирующей обновление программного обеспечения CU-CP в прогнозированной оптимальной временной метке, согласно вариантам осуществления, раскрытым в данном документе. CU-CP представляет собой виртуальный сетевой элемент 703, который составляет часть gNB. GNB составляет часть виртуальной 5G RAN. NFVO (потребитель 702 MDAS) может запрашивать анализатор трафика (производитель 701 MDAS) предоставить временную метку, которая является оптимальной для запуска обновления программного обеспечения CU-CP в пределах временного окна. Запуск обновления программного обеспечения CU-CP в оптимальной временной метке требует, предусматривает минимальные эксплуатационные затраты при выполнении обновления программного обеспечения, сокращает или предотвращает потери данных вследствие обновления программного обеспечения и оказывает уменьшенное или минимальное влияние обновления программного обеспечения на возможности работы пользователей. Анализатор трафика может прогнозировать оптимальную временную метку для запуска обновления программного обеспечения CU-CP на основе анализа условий трафика в CU-CP. Анализатор трафика может анализировать множество параметров трафика, связанных с условиями трафика в CU-CP, чтобы прогнозировать оптимальную временную метку.

[81] Как проиллюстрировано на фиг. 9, активный CU-CP (901) и CU-CP (903) в состоянии ожидания должны обновляться. Активный CU-CP (901) может соединяться с абонентскими устройствами (UE) через DRB-каналы. Анализатор трафика может формировать сообщение, релевантное для состояний каналов, которое может включать в себя прогнозированную оптимальную временную метку. Анализатор трафика может доставлять сообщение в NFVO (909) на этапе 920. NFVO (909) может решать, следует или нет запускать обновление программного обеспечения, на основе сообщения на этапе 921.

[82] В варианте осуществления, если NFVO (909) решает запускать обновление программного обеспечения, CU-CP (903) в состоянии ожидания обновляется сначала. Если программное обеспечение сетевой функциональности CU-CP для CU-CP (903) в состоянии ожидания обновляется успешно, NFVO (909) запускает обновление программного обеспечения сетевой функциональности CU-CP для активного CU-CP. Графический пользовательский интерфейс NFVO (GUI NFVO) может проверять подробности пакетов VNF, функционирующих в качестве CU-CP, до инициирования обновления программного обеспечения сетевой функциональности CU-CP.

[83] Когда NFVO (909) запускает обновление программного обеспечения CU-CP в состоянии ожидания, NFVO (909) может отправлять запрос на обновление VNF в VNFM (907) на этапе 923. VNFM (907) может перенаправлять в запрос на обновление VNF в CU-CP (903) в состоянии ожидания на этапе 925. CU-CP (903) в состоянии ожидания может формировать порядок обновления и отслеживать порядок обновления. Кроме того, CU-CP (903) в состоянии ожидания может отправлять успешность обновления VNF в NFVO (909) на этапе 926. VIM (911) может отправлять обновленные пакеты VNF, соответствующие различным компонентам CU-CP (903) в состоянии ожидания, в CU-CP (903) в состоянии ожидания через протокол передачи файлов (FTP). Это обеспечивает возможность обновления CU-CP (903) в состоянии ожидания. После того как NFVO (909) верифицирует то, что обновление программного обеспечения CU-CP (903) в состоянии ожидания успешно завершается, обновление программного обеспечения активного CU-CP (901) может инициироваться.

[84] Когда NFVO (909) запускает обновление программного обеспечения активного CU-CP (901), NFVO (909) может отправлять запрос на обновление VNF в VNFM (907) на этапе 927. VNFM (907) может перенаправлять в запрос на обновление VNF в активный CU-CP (901) на этапе 929. Активный CU-CP (901) может информировать NFVO (909) и VNFM (907) в отношении того, что VNF, исполняющиеся на VM активного CU-CP (901), должны обновляться, на этапе 931 и 933. Активный CU-CP (901) может запрашивать CU-UP (905) на предмет того, чтобы постоянно сохранять (хранить) состояние каналов, которые соединяют UE (устройства на конце пользователя) с CU-CP, на этапе 935. Каналы сохраняются в течение предварительно заданного временного интервала восстановления. В варианте осуществления, временной интервал восстановления задается на основе согласований между активным CU-CP (901) и CU-UP (905) через сообщения уровня конфигурирования радиоресурсов (RRC). Сохранение состояния канала может значительно уменьшать объем передаваемой служебной информации, предусмотренной при установлении радиоканалов, что требуется в том случае, если UE соединяются с другим CU-CP. Следовательно, сохранение состояния канала уменьшает объем операционной служебной информации, предусмотренной при установлении избыточных узлов CU-CP, в то время как активный CU-CP (901) подвергается обновлению программного обеспечения.

[85] После этого, активный CU-CP (901) переходит в режим обновления программного обеспечения в прогнозированный оптимальный момент времени на этапе 937. Можно отметить, что временной интервал восстановления начинается, когда активный CU-CP (901) переходит к обновлению программного обеспечения. VIM (911) может отправлять новые пакеты VNF в активный CU-CP через FTP на этапе 939 для обновления различных компонентов активного CU-CP.

[86] Когда активный CU-CP (901) выходит из режима обновления программного обеспечения с обновленным пакетом VNF, активный CU-CP отправляет RRC-сообщение в CU-UP (905) на этапе 941. RRC-сообщение указывает то, что обновление программного обеспечения активного CU-CP (901) является успешным. Сохраненные записи по каналам проходят проверку достоверности в CU-CP с помощью UE. С другой стороны, если активный CU-CP не становится функциональным, например, если CU-CP остается в режиме обновления программного обеспечения после предварительно заданного временного интервала восстановления, сохраненные записи по каналам помечаются как недостоверные на этапе 943. В этом случае, обновление программного обеспечения не считается успешным.

[87] Фиг. 10 является блок-схемой 1000 последовательности операций, иллюстрирующей способ для обновления программного обеспечения виртуального сетевого элемента виртуальной сети RAN 5G с использованием MDAS, согласно вариантам осуществления, раскрытым в данном документе. На этапе 1001 способ может включать в себя анализ, посредством производителя 701 MDAS, данных, связанных с условиями трафика по меньшей мере одного виртуального сетевого элемента 703 виртуальной RAN. В варианте осуществления, данные могут включать в себя параметры трафика, такие как, но не только, 5G QCT, LTE QCT, состояние радиоканалов, число модификаций каналов, выполнение передачи обслуживания, индикатор ошибки GTP и т.д. производитель 701 MDAS получает параметры трафика при приеме от потребителя 702 MDAS запроса предоставить BIAR, которое может включать в себя оптимальную временную метку для запуска обновления программного обеспечения по меньшей мере одного виртуального сетевого элемента 703.

[88] В варианте осуществления, запрос может включать в себя по меньшей мере один виртуальный сетевой элемент 703 (который должен обновляться) и оптимальное временное окно. В варианте осуществления, оптимальная временная метка для запуска обновления программного обеспечения по меньшей мере одного виртуального сетевого элемента 703 находится в пределах оптимального временного окна.

[89] На этапе 1002 способ может включать в себя прогнозирование оптимальной временной метки для запуска обновления программного обеспечения по меньшей мере одного виртуального сетевого элемента 703 на основе проанализированных данных. В варианте осуществления, оптимальная временная метка прогнозируется, на основе параметров трафика, с использованием предсказания временных рядов с использованием моделей временных рядов. Каждый из параметров трафика указывает состояние трафика и ассоциирован с весовыми коэффициентами, которые могут оказывать влияние на прогнозирование оптимальной временной метки для запуска обновления программного обеспечения. Весовые коэффициенты могут варьироваться на основе параметров трафика. Например, 5G QCI указывает число активных сеансов в различных временных метках в пределах оптимального временного окна. Весовой коэффициент, ассоциированный с 5G QCI, является прямо пропорциональным числу активных сеансов. Когда число активных сеансов является низким, запуск обновления программного обеспечения упрощается. Когда число активных сеансов является высоким, запуск обновления программного обеспечения предотвращается или сокращается.

[90] Поскольку параметры трафика с большой вероятностью должны варьироваться в различных временных метках в течение всего оптимального временного окна, весовые коэффициенты, ассоциированные с параметрами трафика, отличаются в различных временных метках в течение всего оптимального временного окна. Иллюстративные варианты осуществления могут включать в себя вычисление суммы произведений параметров трафика и ассоциированных весовых коэффициентов в каждой из различных временных меток в течение всего оптимального временного окна. Временная метка, в которой сумма произведений является минимальной, представляет собой иллюстративную оптимальную временную метку для запуска обновления программного обеспечения по меньшей мере одного виртуального сетевого элемента 703 в пределах оптимального временного окна.

[91] Иллюстративные варианты осуществления могут включать в себя формирование BIAR, которое может включать в себя оптимальную временную метку, временную метку, в которой формируется BIAR (временную метку формирования сообщений), указание того, является или нет временная метка формирования сообщений оптимальной для запуска обновления программного обеспечения по меньшей мере одного виртуального сетевого элемента 703, число активных GBR DRB в оптимальной временной метке и число активных не-GBR DRB в оптимальной временной метке. Иллюстративные варианты осуществления могут включать в себя доставку BIAR в потребитель 702 MDAS.

[92] На этапе 1003 способ может включать в себя прием обратной связи из потребителя 702 MDAS относительно уместности запуска обновления программного обеспечения по меньшей мере одного виртуального сетевого элемента 703 в прогнозированной оптимальной временной метке. В варианте осуществления, потребитель 702 MDAS может отправлять обратную связь производителю 701 MDAS. Производитель 701 MDAS может проверять достоверность того, является или нет прогнозированная оптимальная временная метка подходящей для запуска обновления программного обеспечения, на основе обратной связи. Если прогнозированная будущая временная метка признается недостоверной, иллюстративные варианты осуществления могут включать в себя прогнозирование другой оптимальной временной метки для запуска обновления программного обеспечения. Это может повышать точность прогнозирования оптимальной временной метки.

[93] В варианте осуществления, условия, которые являются подходящими для запуска обновления программного обеспечения, представляют собой, но не в ограничительном смысле, то, когда число активных сеансов работы каналов является низким, то, когда только сеансы работы каналов по умолчанию являются активными, то, когда число модификаций каналов, которым подвергаются активные GBR-/критические GBR-сеансы, меньше, то, когда большинство сеансов работы каналов не находятся в активном состоянии, то, когда передача обслуживания не выполняется для большинства активных сеансов каналов, то, когда большинство активных сеансов каналов не находятся в состоянии указания ошибки GTP и т.д.

[94] На этапе 1004 способ может включать в себя инициирование обновления программного обеспечения в прогнозированной оптимальной временной метке, которая определяется как подходящая на основе обратной связи. Потребитель 702 MDAS может отправлять запрос на обновление VNF в VNFM, который отвечает за управление сетевыми функциями, например VNF, исполняющимися на VM, представляющих по меньшей мере один виртуальный сетевой элемент 703. VNFM может перенаправлять запрос на обновление VNF в по меньшей мере один виртуальный сетевой элемент 703. ʺНа основеʺ, в том смысле как используется здесь, охватывает ʺна основе, по меньшей мереʺ.

[95] По меньшей мере один виртуальный сетевой элемент 703 может сохранять состояние каналов, которые соединяют по меньшей мере одно UE с по меньшей мере одним виртуальным сетевым элементом 703. Иллюстративные варианты осуществления могут включать в себя сохранение каналов в течение предварительно заданного временного интервала восстановления. По меньшей мере один виртуальный сетевой элемент 703 переходит в режим обновления программного обеспечения в прогнозированный оптимальный момент времени. В по меньшей мере один виртуальный сетевой элемент 703 загружаются новые пакеты VNF во время обновления программного обеспечения. Иллюстративные варианты осуществления могут включать в себя проверку достоверности сохраненных записей по каналам после успешного обновления программного обеспечения. Если обновление программного обеспечения не завершается в пределах предварительно заданного временного интервала восстановления, сохраненные записи по каналам высвобождаются.

[96] Различные действия на блок-схеме 1000

последовательности операций способа могут выполняться в представленном порядке, в другом порядке или одновременно. Дополнительно, в некоторых вариантах осуществления, некоторые действия, перечисленные на фиг. 10, могут опускаться.

[97] Варианты осуществления, раскрытые в данном документе, могут реализовываться через по меньшей мере одну программу, работающую на по меньшей мере одном аппаратном устройстве и выполняющую функции управления сетью с тем, чтобы управлять сетевыми элементами. Сетевые элементы, показанные на фиг. 7, включают в себя блоки, которые могут представлять собой по меньшей мере одно из аппаратного устройства или комбинации аппаратного устройства и программного модуля. Каждый ʺмодульʺ здесь может содержать микросхему.

[98] Варианты осуществления, раскрытые в данном документе, описывают способы и оборудование для предоставления модели ML для прогнозирования оптимальной временной метки для обновления программного обеспечения виртуальных сетевых элементов 5G-сети на основе анализа параметров, связанных с условиями трафика виртуальных сетевых элементов 5G-сети. Следовательно, следует понимать, что объем охраны распространяется на такую программу, и в дополнение к машиночитаемому средству, имеющему сообщение, такое машиночитаемое средство хранения данных содержит программное кодовое средство для реализации одного или более этапов способа, когда программа исполняется на сервере или на мобильном устройстве, либо на любом подходящем программируемом устройстве. Способ реализуется в предпочтительном варианте осуществления через или вместе с программно-реализованной программой, написанной на примерном языке описания аппаратных средств на сверхбыстродействующих интегральных схемах (VHDL) или на любом другом языке программирования либо реализованной посредством одного или более VHDL или несколько программных модулей, выполняемых, по меньшей мере, на одном аппаратном устройстве. Аппаратное устройство может представлять собой любой вид портативного устройства, которое может программироваться. Устройство также может включать в себя средство, которое, например, может представлять собой аппаратное средство, например, специализированную интегральную схему (ASIC) либо комбинацию аппаратного и программного средства, например, ASIC и программируемой пользователем вентильной матрицы (FPGA), либо по меньшей мере один микропроцессор и по меньшей мере одно запоминающее устройство с программными модулями, расположенными в нем. Варианты осуществления способа, описанные в данном документе, могут реализовываться частично в аппаратных средствах и частично в программном обеспечении. Альтернативно, различные иллюстративные варианты осуществления могут реализовываться на различных аппаратных устройствах, например, с использованием множества центральных процессоров (CPU). Каждый CPU и каждый ʺпроцессорʺ здесь содержит микросхему.

[99] Вышеприведенное описание конкретных вариантов осуществления должно полностью раскрывать общий характер вариантов осуществления в данном документе таким образом, что другие могут, посредством применения современных знаний, легко модифицировать и/или адаптировать для различных вариантов применения такие конкретные варианты осуществления без отступления от общего принципа, и в силу этого такие адаптации и модификации должны и имеют намерение пониматься в пределах смысла и диапазона эквивалентов раскрытых вариантов осуществления. Следует понимать, что фразеология или терминология, используемая в данном документе, служит для описания, а не для ограничения. Следовательно, хотя варианты осуществления в данном документе описаны с точки зрения предпочтительных вариантов осуществления, специалисты в данной области техники должны признавать, что варианты осуществления в данном документе могут осуществляться на практике с модификацией в пределах объема вариантов осуществления, как описано в данном документе. Хотя раскрытие проиллюстрировано и изложено со ссылкой на различные варианты осуществления, следует понимать, что эти различные варианты осуществления подразумеваются иллюстративными, неограничивающими. Специалистам также следует понимать, что различные изменения в форме и деталях могут быть выполнены не отклоняясь от истинного существа и полного объема раскрытия, включая прилагаемую формулу изобретения и ее эквиваленты. Следует также понимать, что любой(ые) из описанных здесь вариантов осуществления может использоваться в сочетании любым другим описанным здесь вариантом(ами) осуществления.

Изобретение относятся к обновлению сети радиодоступа (RAN), а более конкретно к способам и оборудованию для обновления программного обеспечения виртуального RAN-узла сети связи пятого поколения (5G) с использованием сервиса аналитики управляющих данных (MDAS). Технический результат заключается в обеспечении возможности обновления программного обеспечения виртуального RAN-узла сети связи в оптимальное время. Предложенный способ для управления обновлением программного обеспечения сетевого элемента сети произвольного доступа (RAN) посредством производителя сервиса аналитики управляющих данных (MDAS) содержит этапы, на которых: принимают от потребителя MDAS запрос, относящийся к оптимальному времени для обновления программного обеспечения сетевого элемента в RAN; идентифицируют информацию, относящуюся к выделенному радиоканалу (DRB); идентифицируют информацию, относящуюся к оптимальному времени для обновления программного обеспечения сетевого элемента, на основе информации, относящейся к DRB; и передают отчет, включающий в себя информацию, относящуюся к оптимальному времени для обновления программного обеспечения сетевого элемента. 3 н. и 15 з.п. ф-лы, 10 ил.

1. Способ управления обновлением программного обеспечения сетевого элемента сети радиодоступа (RAN) посредством производителя сервиса аналитики управляющих данных (MDAS), причем сетевой элемент соединен с абонентским устройством (UE) через выделенный радиоканал (DRB), при этом способ содержит этапы, на которых:

принимают от потребителя MDAS запрос, относящийся к оптимальному времени для обновления программного обеспечения сетевого элемента в RAN;

идентифицируют информацию, относящуюся к DRB;

идентифицируют информацию, относящуюся к оптимальному времени для обновления программного обеспечения сетевого элемента, на основе информации, относящейся к DRB; и

передают отчет, включающий в себя информацию, относящуюся к оптимальному времени для обновления программного обеспечения сетевого элемента.

2. Способ по п.1, в котором запрос, принимаемый от потребителя MDAS, включает в себя информацию, указывающую сетевой элемент и предварительно определенное временное окно, в которое включено оптимальное время.

3. Способ по п.1, в котором информация, относящаяся к DRB, содержит по меньшей мере одно из состояния радиоканалов, числа модификаций каналов и состояния передачи обслуживания, относящихся к DRB.

4. Способ по п.1, в котором информация, относящаяся к оптимальному времени для обновления программного обеспечения сетевого элемента, включает в себя по меньшей мере одно из оптимального времени для обновления программного обеспечения сетевого элемента, числа DRB с гарантированной скоростью передачи битов (GBR) в оптимальное время и числа не-GBR DRB в оптимальное время.

5. Способ по п.1, дополнительно содержащий этап, на котором оптимизируют оптимальные времена, по меньшей мере, посредством совместной работы с потребителем MDAS, при этом совместная работа предусматривает предоставление, посредством потребителя MDAS в производитель MDAS, обратной связи касаемо оптимальности оптимального времени для обновления программного обеспечения сетевого элемента в оптимальное время.

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

7. Электронное устройство производителя сервиса аналитики управляющих данных (MDAS) для управления обновлением программного обеспечения сетевого элемента сети радиодоступа (RAN), причем сетевой элемент соединен с абонентским устройством (UE) через выделенный радиоканал (DRB), при этом электронное устройство содержит:

память; и

по меньшей мере один процессор, подключенный к памяти, при этом по меньшей мере один процессор выполнен с возможностью:

принимать запрос, относящийся к оптимальному времени для обновления программного обеспечения сетевого элемента в RAN,

идентифицировать информацию, относящуюся к DRB,

идентифицировать информацию, относящуюся к оптимальному времени для обновления программного обеспечения сетевого элемента, на основе информации, относящейся к DRB, и

передавать отчет, включающий в себя информацию, относящуюся к оптимальному времени для обновления программного обеспечения сетевого элемента.

8. Электронное устройство по п.7, при этом упомянутый запрос, принимаемый от потребителя MDAS, включает в себя информацию, указывающую сетевой элемент и предварительно определенное временное окно, в которое включено оптимальное время.

9. Электронное устройство по п.7, при этом информация, относящаяся к DRB, содержит по меньшей мере одно из состояния радиоканалов, числа модификаций каналов и состояния передачи обслуживания, относящихся к DRB.

10. Электронное устройство по п.7, при этом информация, относящаяся к оптимальному времени для обновления программного обеспечения сетевого элемента, включает в себя по меньшей мере одно из оптимального времени для обновления программного обеспечения сетевого элемента, числа DRB с гарантированной скоростью передачи битов (GBR) в оптимальное время и числа не-GBR DRB в оптимальное время.

11. Электронное устройство по п.7, в котором по меньшей мере один процессор дополнительно выполнен с возможностью оптимизировать оптимальные времена, по меньшей мере, посредством совместной работы с потребителем MDAS, при этом совместная работа предусматривает предоставление, посредством потребителя MDAS в производитель MDAS, обратной связи касаемо оптимальности оптимального времени для обновления программного обеспечения сетевого элемента в оптимальное время.

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

13. Долговременный машиночитаемый носитель, хранящий программный код, который при его исполнении по меньшей мере одним процессором электронного устройства производителя сервиса аналитики управляющих данных (MDAS) для управления обновлением программного обеспечения сетевого элемента сети радиодоступа (RAN) предписывает электронному устройству выполнять операции, причем сетевой элемент соединен с абонентским устройством (UE) через выделенный радиоканал (DRB), при этом операции содержат:

прием запроса, относящегося к оптимальному времени для обновления программного обеспечения сетевого элемента в RAN;

идентификацию информации, относящейся к DRB;

идентификацию информации, относящейся к оптимальному времени для обновления программного обеспечения сетевого элемента, на основе информации, относящейся к DRB; и

передачу отчета, включающего в себя информацию, относящуюся к оптимальному времени для обновления программного обеспечения сетевого элемента.

14. Долговременный машиночитаемый носитель по п.13, при этом упомянутый запрос, принимаемый от потребителя MDAS, включает в себя информацию, указывающую сетевой элемент и предварительно определенное временное окно, в которое включено оптимальное время.

15. Долговременный машиночитаемый носитель по п.13, при этом информация, относящаяся к DRB, содержит по меньшей мере одно из состояния радиоканалов, числа модификаций каналов и состояния передачи обслуживания, относящихся к DRB.

16. Долговременный машиночитаемый носитель по п.13, при этом информация, относящаяся к оптимальному времени для обновления программного обеспечения сетевого элемента, включает в себя по меньшей мере одно из оптимального времени для обновления программного обеспечения сетевого элемента, числа DRB с гарантированной скоростью передачи битов (GBR) в оптимальное время и числа не-GBR DRB в оптимальное время.

17. Долговременный машиночитаемый носитель по п.13, при этом операции дополнительно содержат оптимизацию оптимальных времен, по меньшей мере, посредством совместной работы с потребителем MDAS, при этом совместная работа предусматривает предоставление, посредством потребителя MDAS в производитель MDAS, обратной связи касаемо оптимальности оптимального времени для обновления программного обеспечения сетевого элемента в оптимальное время.

18. Долговременный машиночитаемый носитель по п.17, при этом операции дополнительно содержат повторную идентификацию информации, относящейся к оптимальному времени, на основе обратной связи, указывающей, что оптимальное время не является оптимальным для обновления программного обеспечения сетевого элемента.