Регистрация услуг в сети связи

Изобретение относится к средствам регистрации услуги в сети связи. Технический результат заключается в распределении нагрузки между различными версиями услуги и предоставлении услуги устройствам, для которых текущая версия услуги оказывается неработоспособной. Принимают запрос регистрации услуги, причем запрос указывает сетевую функцию для предоставления услуги, тип услуги и версию услуги. Сохраняют информацию в хранилище, причем информация указывает сетевую функцию, тип услуги и версию услуги. Принимают запрос обнаружения услуги, причем запрос обнаружения услуги указывает тип услуги. Посылают отправителю ответ на запрос обнаружения услуги, причем ответ на запрос обнаружения услуги указывает сетевую функцию и версию услуги, при этом хранилище хранит дополнительную информацию, указывающую дополнительную сетевую функцию, тип услуги и дополнительные версии услуги, содержащие предыдущую версию услуги. 8 н. и 13 з.п. ф-лы, 14 ил., 4 табл.

 

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

Введение

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

В настоящее время разрабатываемая система пятого поколения ("5G") принимает форму SBA (Service Based Architecture, архитектура, основанная на услугах), содержащую множество сетевых функций (Network Function, NF), где каждая сетевая функция предоставляет одну или множество услуг (в качестве производителя NF) одному или нескольким потребителям услуги (каждому, являющемуся потребителем NF). Например, прикладной программный интерфейс API (Application Programming Interface) HTTP/REST (Representational State Transfer using HTTP) может использоваться для взаимодействия между услугами производителя и услугами потребителя. В некоторых случаях NF может содержать одну или более услуг потребителя и одну или более услуг производителя.

На фиг. 1 показан пример роуминговой архитектуры системы 5G. В услугах, основанных на архитектуре системы 5G, предполагается, что услуга, предоставляемая производителем услуг, используется (например, потребляется) потребителем услуг. Количество услуг (или вариантов услуг), доступных в системе 5G, является динамичным (из-за, например, увеличения или уменьшения, отказов, запрограммированного обслуживания и/или других факторов). Система 5G поэтому предусматривает функцию сетевого хранилища (Network Repository Function, NRF), которая поддерживает функциональные возможности, содержащие следующее:

– регистрация услуг NF и разрегистрация в NRF;

– открытие услуг NF потребителем услуг NF; и

– авторизация производителю доступа потребителей к услугам NF .

В архитектуре 5G, такой как показано на фиг. 1, сетевая функция унифицированного управления данными (Unified Data Management, UDM) может сохранять данные абонентов в базе данных. В многоуровневой архитектуре UDM содержится в UDM Front End (UDM-FE) плюс база данных. На фиг. 2 показан пример содержания UDR и потребительских услуг (например, в одной или более сетевых функциях). Как показано на чертеже, UDR содержит данные подписки, данные политики подписки, демонстрационные данные и данные приложений, и взаимодействует через интерфейс Nudr с UDM-FE, PCF и сетевыми функциями NEF. Структура, показанная на фиг. 2, является просто примером и изображенные объекты могут быть организованы другим способом и/или использовать другой интерфейс (интерфейсы).

Интерфейс Nudr определен для сетевых функций, таких как UDM FE, PCF и NEF, чтобы получать доступ к конкретному просмотру хранящихся данных и считывать, обновлять (в том числе, добавлять, изменять) и удалять данные и подписываться на уведомление об изменениях соответствующих данных от UDR. Каждая сетевая функция, получающая доступ к UDR, может иметь возможность добавлять, изменять, обновлять или удалять только те данные, которые разрешается изменять. Эта авторизация может выполняться на основе каждого просмотра и каждого потребителя NF и потенциально на основе каждого UE, подписки и/или на основе соглашения о роуминге от UDR.

Приведенная ниже таблица 1 показывает пример услуг, определенных для UDM и сопутствующих сервисных операций.

 Таблица 1

Услуга NF	Сервисные операции	Семантика операции	Пример потребителя(-ей)
Управление абонентскими данными	Получить	Запрос/ответ	AMF, SMF, SMSF
	Запрос UpdateSubscribe	Подписать/уведомить	AMF, SMF, SMSF
	UpdateUnsubscribe	Подписать/уведомить	AMF, SMF, SMSF
UpdateNotification	Подписать/уведомить	AMF, SMF, SMSF
Управление контекстом UE	Регистрация	Запрос/ответ	AMF, SMF, SMSF
	RemoveNotification	Подписать/уведомить	AMF, SMF, SMSF
	Дерегистрация	Запрос/ответ	AMF, SMF, SMSF
	Получить	Запрос/ответ	NEF
Обновить	Запрос/ответ	AMF
Аутентификация UE	Запрос	Запрос/ответ	AUSF
EventExposure	Подписка	Подписать/уведомить	NEF
	Отменить подписку		NEF
Уведомление	NEF

Для UDR определяется только один услуга с сопутствующими сервисными операциями, как показано ниже в таблице 2.

Таблице 2

Услуга NF	Сервисные операции	Семантика операции	Пример потребителя(-ей)
Унифицированное управление данными	Запрос	Запрос/Ответ	UDM FE, PCF, Provisioning FE, NEF
	Создать	Запрос/Ответ	Provisioning FE, NEF
	Удалить	Запрос/Ответ	Provisioning FE, NEF
	Обновить	Запрос/Ответ	Provisioning FE, UDM, FE, PCF, NEF
	Подписка	Подписать/уведомить	UDM FE, PCF
Уведомление	UDM FE, PCF
Примечание 1: Вопрос о том, стандартизуется ли модель данных, используемая услугами UDR, остается для решения на этапе 3. Примечание 2: Как определено в документе TS 23.335 [11], статья 4.2.2, A Provisioning Front End (предоставляющий предпроцессор) является Application Front End (прикладным предпроцессором) для целей обеспечения UDR данными подписки и/или данными политики.

На фиг. 3 показан пример связи между NF (например, услуга NF, производитель услуги NF) и NRF для регистрации услуги (например, услуга NF или услуги NF). На этапе 1 услуга NF (производитель услуг) посылает для NRF профиль услуг (например, профиль услуг NF). На этапе 2 NRF сохраняет профиль NF. На этапе 3 NRF посылает для NF (производителя услуг) в качестве ответа подтверждение приема. Термины "услуга NF" и "профиль услуг NF" можно использоваться взаимообразно с терминами "сервис" и "сервисный профиль".

Профиль услуг NF может содержать следующую информацию:

• Идентификатор варианта NF

• Тип NF

• Идентификатор PLMN

• Участок сети, связанный с идентификатором(-ами), например, S-NSSAI, NSI ID

• FQDN или IP-адрес NF

• Информация о возможностях NF

• Информация авторизации определенной услуги NF

• Названия поддерживаемых услуг

• Окончательная информация о случае(-ях) каждой поддерживаемой услуги

• Другой сервисный параметр(-ы), например, DNN, конечная точка уведомления для каждого типа уведомления, которое услуга NF заинтересован принять

На фиг. 4 показан пример связи между услугами NF (потребитель NF) и NRF во время процесса обнаружения услуги. На этапе 1 потребитель услуг (услуга NF пытается обнаружить доступные варианты конкретной услуги в сети. Потребитель услуги посылает запрос обнаружения для NRF, указывающий:

• Название услуги NF,

• Тип NF ожидаемого варианта NF

• Тип NF для потребителя NF

• Как вариант, может указывать S-NSSAI.

На этапе 2 NRF ищет зарегистрированные услуги для тех, кто соответствует критериям в запросе обнаружения. На этапе 3 NRF отвечает NF набором обнаруженных вариантов NF или вариантов услуги NF (например, могут указываться FQDN или IP-адрес для каждой услуги в наборе), которые содержат одну, несколько или все услуги, которые соответствуют критериям.

На фиг. 5 показан пример связи между потребителем NF и производителем NF (например, поставщиком услуг). Взаимодействие между двумя сетевыми функциями (потребителя и производителя) внутри этой структуры услуг NF соответствует двум механизмам.

В первом механизме, "запрос-ответ", плоскость управления NF_B (производитель услуг NF) запрашивается другой плоскостью управления NF_A (потребитель услуг NF) для предоставления определенной услуги NF, которая либо выполняет действие, либо или предоставляет информацию, либо и то, и другое. NF_B предоставляет услугу NF, основываясь на запросе NF_A. Чтобы выполнить запрос, NF_B может, в свою очередь, использовать услуги NF от других NF. В механизме "запрос-ответ" связь является связью друг с другом двух NF (потребителя и производителя), и одноразовый ответ от производителя на запрос от потребителя ожидается в течение определенного периода времени.

Во втором механизме, "подписка-уведомление", плоскость управления NF_A (потребитель услуг NF) подписывается на услугу NF, предложенную другой плоскостью управления NF_B (производитель услуг NF). Многочисленные плоскости управления NF могут подписываться на одну и ту же услугу NF плоскости управления. NF_B сообщает о результатах этой услуги NF заинтересованному NF, который подписан на эту услугу NF. Запрос подписки должен содержать уведомление в качестве конечной точки (например, уведомление URL) потребителя услуги NF, которому должно быть послано уведомление о событии от производителя услуги NF. Кроме того, запрос подписки может содержать запрос уведомления о периодических обновлениях или уведомления, инициируемого определенными событиями (например, информация, запрошенная для получения, изменяется, достигает определенного порога и т. д.).

Плоскость управления NF_A может также подписываться на услугу NF, предлагаемую плоскостью управления NF_B от имени плоскости управления NF_C, т. е. она просит производителя услуги NF послать уведомление о событии другому потребителю(-ям). В этом случае NF_A включает в запрос подписки уведомление NF_C в качестве конечной точки.

Раскрытие сущности изобретения

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

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

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

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

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

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

Для лучшего понимания примеров, содержащихся в представленном раскрытии, и более ясного показа, как примеры могут быть реализованы на практике, будет делаться ссылка, только в качестве примера, на нижеследующие чертежи, на которых:

Фиг. 1 - пример роуминговой архитектуры системы 5G;

Фиг. 2 - пример содержания UDR и сетевых функций потребителя;

Фиг. 3 - пример связи между NF и NRF для регистрации услуги NF;

Фиг. 4 - пример связи между услугой NF и NRF во время процесса обнаружения услуги;

Фиг. 5 - пример связи между потребителем NF и производителем NF;

Фиг. 6 - блок-схема последовательности выполнения операций примера способа регистрации услуги в сети связи;

Фиг. 7 - блок-схема последовательности выполнения операций способа регистрации услуги в сети связи;

Фиг. 8 - пример устройства регистрации услуги в сети связи;

Фиг. 9 - пример устройства регистрации услуги в сети связи;

Фиг. 10 - пример устройства регистрации услуги в сети связи;

Фиг. 11 пример устройства регистрации услуги в сети связи;

Фиг. 12 - пример объектов и интерфейсов, участвующих в некоторых вариантах осуществления;

Фиг. 13 - пример связи между услугой NF и NRF во время процесса регистрации услуги; и

Фиг. 14 - пример связи между услугой NF и NRF во время процесса обнаружения услуги.

Осуществление изобретения

Изложенные ниже конкретные подробности, такие как конкретные варианты осуществления, приводятся только в целях объяснения, но не для создания ограничения. Специалисты в данной области техники должны понимать, что помимо указанных здесь конкретных подробностей, могут использоваться и другие примеры. В некоторых случаях подробные описания известных способов, узлов, интерфейсов, схем и устройств пропускаются, с тем, чтобы не перегружать описание ненужными деталями. Специалисты в данной области техники должны понимать, что описанные функции могут быть реализованы в одном или нескольких узлах, используя схемы аппаратных средств (например, аналоговые и/или дискретные логические элементы, взаимосвязанные для выполнения специализированных функций, ASIC, PLA, и т. д.) и/или используя программы и данные в сочетании с одним или более цифровыми микропроцессорами или универсальными компьютерами. Узлы, осуществляющие связь, используя радиоинтерфейс, также имеют подходящую схему беспроводной связи. Кроме того, соответствующая технология может дополнительно считаться полностью реализуемой в рамках любой формы считываемой компьютером памяти, такой как твердотельная память, магнитный диск или оптический диск, содержащие соответствующий набор компьютерных команд, которые могут заставить процессор выполнять описанные здесь способы.

Аппаратная реализация может содержать или включать в себя, без ограничения, аппаратные средства цифрового сигнального процессора (DSP), процессор с сокращенной системой команд, схемы аппаратных средств (например, цифровых или аналоговых) в том числе, но не ограничиваясь только этим, специальные прикладные интегральные схемы (ASIC) и/или программируемые логические интегральные схемы (FPGA), и (где это нужно) конечные автоматы, способные к выполнению таких функций.

Любые соответствующие этапы, способы, признаки, функции или преимущества, раскрытые здесь, могут выполняться одним или более функциональными блоками или модулями одного или более виртуальных устройств. Каждое виртуальное устройство может содержать множество этих функциональных блоков. Эти функциональные блоки могут быть реализованы процессорной схемотехникой, которая может содержать один или более микропроцессоров или микроконтроллеров, а также другие цифровые аппаратные средства, которые могут содержать цифровые сигнальные процессоры (DSP), цифровую логику специального назначения и т. п. Процессорная схемотехника может быть выполнена с возможностью исполнения управляющей программы, хранящейся в памяти, которая может содержать один или несколько типов памяти, таких как постоянная память (ROM), оперативная память (RAM), кэш-память, флэш-память, оптические запоминающие устройства и т. д. Управляющая программа, хранящаяся в памяти, содержит программные команды для осуществления одной или более связей и/или протоколов передачи данных, а также команд для выполнения одного или более описанных здесь способов. В некоторых реализациях процессорная схема может использоваться, чтобы заставить соответствующий функциональный блок выполнять соответствующие функции согласно одному или нескольким вариантов осуществления представленного раскрытия.

В соответствии с некоторыми вариантами осуществления представленного раскрытия, UDR не является уникальным объектом в сети. Например, в следующих случаях в сети могут существовать несколько UDR:

- При развертываниях клиентов может существовать множество UDR, развернутых в одной и той же сети, например, в Китае, где развертывание охватывает множество регионов.

- Многочисленные UDR для хранения различных данных, соответственно.

- Многочисленные UDR для предоставления различных услуг различным потребителям услуг (например, PCF, UDM, NEF и/или другим потребителям.

В этих случаях каждый UDR в сети может регистрировать услугу UDM в NRF, но каждый UDM обслуживает только некоторые определенные данные, например, данные подписки только для части всех подписчиков могут храниться первым UDR, тогда как второй UDR может хранить данные для остальной части подписчиков; или первый UDR может хранить данные подписки только для UDM-FE и PCF, тогда как второй UDR хранит данные приложений и даже третий UDR хранит данные для демонстрации.

Это означает, что каждый UDR может регистрировать услугу производителя под одним и тем же именем (например, "унифицированное управление данными"), но в этом случае при предоставлении услуги невозможно определить, к каким данным получают доступ/какие данные обслуживаются. В результате потребитель NF, например, UDM-FE, не может получить из обнаружения с помощью NRF информацию, чтобы иметь возможность выбрать вариант услуги UDR, которая обеспечивает доступ к данным, в которых потребитель этой услуги заинтересован.

Та же самая проблема относится к UDM, когда он хранит данные локально (т.е. UDR в качестве внешней базы данных не развертывается). Если, например, UDM хранит данные для группы или ряда подписчиков, то потребители UDM (например, AMF, SMF, SMSF) не знают, который UDM-FE хранит данные для соответствующего UE/подписчика.

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

На фиг. 6 представлена блок-схема последовательности выполнения операций примерного способа 600 регистрации услуги в сети связи. Способ 600 на этапе 602 содержит прием запроса регистрации услуги, причем запрос идентифицирует сетевую функцию для предоставления услуги, тип услуги и версию услуги, и на этапе 604 сохраняют информацию в хранилище, причем информация идентифицирует сетевую функцию, тип услуги и версию услуги. Таким образом, хранилище может хранить информацию, идентифицирующую версию услуги, которая может использоваться в различных целях. Кроме того, версия услуги может отличать услугу от предшествующих версий услуги, которые все еще могут быть зарегистрированы (например, информация, относящаяся к предшествующим версиям, может все еще храниться в хранилище).

Запрос регистрации услуги может быть получен от сетевой функции. Информация может храниться в функции сетевого хранилища (Network Repository Function, NRF) и/или способ может выполняться посредством функции сетевого хранилища (NRF).

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

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

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

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

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

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

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

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

Сетевая функция (и/или когда присутствует дополнительная сетевая функция, то дополнительная сетевая функция) может в некоторых примерах быть объединенным хранилищем данных (Unified Data Repository, UDR), объединенным управлением данными (Unified Data Management, UDM), функцией управления политикой (Policy Control Function, PCF), сетевой демонстрационной функцией (Network Exposure Function, NEF) или функцией управления доступом и мобильностью (Access and Mobility Management Function, AMF). Сеть связи в некоторых примерах быть системой 5G.

На фиг. 7 представлена блок-схема последовательности выполнения операций способа 700 для регистрации услуг в сети связи. Способ 700 содержит этап 702, на котором посылают запрос регистрации услуги сетевой функции регистрации услуги, причем запрос указывает сетевую функцию предоставления услуги для предоставления услуги, тип услуги и версию услуги. Таким образом, поставщик услуг (например, производитель услуг NF) может регистрировать услуга вместе с информацией о версии. Сетевая функция регистрации услуги может быть, например, функцией сетевого хранилища (Network Repository Function, NRF).

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

Способ 700 в некоторых примерах может выполняться производителем услуги сетевой функции. Производитель услуги сетевой функции может, например, содержать объединенное хранилище данных (Unified Data Repository, UDR), объединенное управление данными (Unified Data Management, UDM), функцию управления политикой (Policy Control Function, PCF), сетевую демонстрационную функцию (Network Exposure Function, NEF) или функцию управления доступом и мобильностью (Access and Mobility Management Function, AMF).

На фиг. 8 схематично показан пример устройства 800 для регистрации услуги в сети связи. Устройство 800 содержит процессор 802 и память 804. Память 804 содержит команды, исполняемые процессором 802 таким образом, что устройство может выполнять, например, способ 600, показанный на фиг. 6.

На фиг. 9 схематично показан пример устройства 900 регистрации услуги в сети связи. Устройство 900 содержит процессор 902 и память 904. Память 904 содержит команды, исполняемые процессором 902 таким образом, что устройство выполняет, например, способ 700, показанный на фиг. 7.

На фиг. 10 схематично показан пример устройства 1000 для регистрации услуги в сети связи. Устройство 1000 содержит приемный модуль 10020, выполненный с возможностью приема запроса регистрации услуги, причем запрос указывает сетевую функцию предоставления услуги, тип услуги и версию услуги. Устройство 1000 также содержит модуль 1004 хранения, выполненный с возможностью хранения информации в хранилище, причем информация указывает сетевую функцию, тип услуги и версию услуги.

На фиг. 11 схематично показан пример устройства 1100 регистрации услуги в сети связи. Устройство 1100 содержит передающий модуль 1102, выполненный с возможностью передачи сетевой функции регистрации услуги запроса регистрации услуги, причем запрос указывает сетевую функцию предоставления услуги для предоставления услуги, тип услуги и версию услуги.

Далее будут описаны дополнительные варианты осуществления представленного раскрытия.

Варианты осуществления представленного раскрытия обеспечивают способ управления версиями услуги, собственные функциональные возможности поставщика и/или обновления услуг в SBA, так как в примере в системе 5G. Например, предлагается любое из нижеследующего:

1. Включать в профиль NF, зарегистрированный в NRF, идентификатор поставщика и версию каждой зарегистрированной услуги NF. Поэтому эта информация также включается в запрос регистрации услуги NF, например, от производителя услуги NF;

2. NRF - указывать (например, в запросе регистрации услуги, при другой связи или каким-либо другим способом), заменяет ли новая версия услуги устаревшую предыдущую;

3. NRF - указывать (например, в запросе регистрации услуги, при другой связи или каким-либо другим способом), является ли обратно совместимой новая версия услуги с предыдущей;

4. NRF- указывать в ответе об обнаружении услуги, существуют ли доступные варианты услуги более новой версии (например, для определенного идентификатора поставщика), так чтобы отправитель соответствующего запроса обнаружения услуги (например, потребитель услуги NF) знал о новых версиях услуги и мог начать использование новой версии услуги;

5. NRF - выполнять способы/процессы (например, посылка ответов на запросы обнаружения), основанные на версии услуги, чтобы:

A. Загружать запросы обнаружения баланса загрузки среди совместимых (например, обратно совместимых) версий услуги;

B. Выполнять откаты версии услуги. NRF обнаруживает варианты новой версии услуги, следуя определенной прогрессивной модели (например, линейной, ступенчатой и т. д.), так чтобы если новая версия не работает, мог быть сделан откат к предыдущей версии, не ставя под угрозу работу всей системы; и/или

6. NRF - уведомлять (например, потребителя услуги NF или производителя услоги NF), когда определенная версия услуги является устаревшей, если никакой запрос обнаружения открытия не был получен в течение определенного периода времени или не были посланы никакие ответы об обнаружении, указывающие, что эта версия устарела, в течение определенного периода времени.

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

• Позволять управлять версиями услуги и обновлениями услуги в SBA, например, в системе 5G. Например, услуга может быть обновлена из-за исправлений ошибок или повышенной эффективности ресурса.

• Позволять поддержку и доступ к собственным функциональным возможностям поставщика. Потребители услуг могут обнаруживать услуги определенного поставщика и версии с собственными функциональными возможностями, например, с новыми параметрами ввода/вывода, отличными от присутствующих (например) в технических требованиях.

• Позволять совместное существование различных версий услуги.

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

- Позволять прогрессивные обновления. Варианты услуги новой версии прогрессивно обнаруживаются. Если новая версия не работает, может выполняться быстрый откат к старой версии, не ставя под угрозу работу всей системы.

• Автоматизированное осведомление потребителей о новых версиях. Потребителям может сообщаться о новых версиях услуги после обнаружения услуги, так чтобы они могли автоматически запрашивать более новые версии услуги.

На фиг. 12 схематично приведен пример объектов и интерфейсов, применяемых в некоторых вариантах осуществления. Объект управления услугами и координации (Service Management and Orchestration, SMO) является объектом, предложенным в раскрытых здесь вариантах осуществления, который может быть размещен на уровне управления сетью и координации. NRF и SMO могут взаимодействовать через интерфейс Noam.

На фиг. 13 показан пример связи между сервисом NF и NRF во время процесса регистрации услуги. Варианты осуществления, раскрытые здесь, такие как тот, который показан на фиг. 13, предлагают (как вариант) включать в запрос регистрации услуги одну или более из следующей информации для каждого варианта услуги:

• Идентификатор поставщика – стандартизированный идентификатор поставщика.

• Версия услуги – Это может быть стандартизированное обозначение или обозначение, определяемое продавцом, со стандартной длиной.

• Предыдущая версия – Версия, предшествующая новой версии. Она должна соответствовать тому же самому типу обозначения, что и версия услуги.

• Обратная совместимость – индикатор того, является ли новая версия обратно совместимой с предыдущей.

Из этой информации NRF может создать представление иерархии версий для различных услуг и продавцов и иметь представление о том, какие версии в ней совместимы.

На фиг. 14 показан пример связи между услугой NF и NRF во время процесса обнаружения услуги. Варианты осуществления, раскрытые здесь, предлагают (как вариант) включать в запрос обнаружения услуги (например, как показано на фиг. 14) одну или более из следующей информации:

• Идентификатор поставщика – стандартизированный идентификатор поставщика.

• Версия услуги – Это может быть стандартизированное обозначение или обозначение, определяемое продавцом, со стандартной длиной.

Это может позволить потребителю услуги NF обнаруживать варианты услуги определенного поставщика и версию.

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

• Список собственных вариантов услуги – Список вариантов услуги запрошенного поставщика и версии. Этот список отличается от обычного списка вариантов услуги тем, что в нем нет никакого зарегистрированного поставщика или версии.

Потребитель услуги может послать запрос обнаружения версии, которая не является самой последней в системе. Варианты осуществления, раскрытые здесь, предлагают (как вариант) включать в ответ об обнаружении услуги следующую информацию:

• Новая доступная версия – доступен признак, что в наличии имеется более свежая версия требуемой услуги. Признак может быть послан вместе с ответом, так чтобы потребитель услуги мог обнаружить новую версию с момента ее появления.

NRF может принять решение, когда посылать этот признак. Например, даже если доступна новая версия услуги, он может исключить это уведомление по причинам балансирования нагрузки, отсутствия обратной совместимости, политики оператора и/или по любой другой причине.

При развертывании новой версии услуги на практике может быть полезным начать позволять постепенное обнаружение новых вариантов услуги так, чтобы любой отказ в работе новой версии мог быть смягчен откатом к предыдущей версии. Другие способы обновления также могут быть применимы. В той степени, в которой здесь раскрыты варианты осуществления, предлагается новое средство (например, услуга) для NRF, чтобы конфигурировать и запускать обновление услуги и управлять откатом к предыдущей версии в случае необходимости. Представленная ниже таблица 3 показывает примерную услугу, которая позволяет достигнуть этого наряду с сервисными операциями.

Таблица 3

Название услуги	Сервисные операции	Семантики операций
Nnrf_ServiceUpgrade	Начать	Запрос/ответ
Откат	Запрос/ответ

В примере предполагается, что перед операцией начала (показанной в таблице 3) один или несколько вариантов новой версии услуги уже зарегистрированы в NRF. Сообщение запроса начала (т. е., запрос операции услуги "Начать"), может содержать одну или более следующих информации/параметров:

• Название услуги

• Идентификатор поставщика

• Версия услуги (например, новая версия)

• Тип обновления – определяет модель, посредством которой NRF обнаруживает варианты новой версии услуги.

• Параметры для каждого типа обновления – определяет параметры, связанные с типом обновления услуги. Например, наклон для линейного обновления, этапы и их продолжительность для ступенчатого обновления и т. д.

Ответом на сообщение о запуске (Start) может быть подтверждение приема сообщения запроса запуска от NRF.

При событии, когда новая услуга терпит неудачу, в NRF может быть отправлено сообщение запроса отката (Rollback) либо посредством решения NF о предоставлении услуги или системы O&M (модуль SMO). Это может содержать или более следующих параметров:

• Название услуги

• Идентификатор поставщика

• Версия услуги

• Тип отката – могут быть определены различные типы отката. Например, полный откат (с этого момента обнаруживается только старая версия), частичный откат (сохраняется поднабор новых версий, поддающихся обнаружению) и т. д.

Ответное сообщение об откате (Rollback) может быть подтверждением приема сообщения запроса об откате от NRF.

Когда новая версия услуги была развернута и обновление в некоторых вариантах осуществления было успешно завершено, потребители услуги больше не должны обнаруживать старую версию услуги. NRF может обнаруживать эту ситуацию, когда нет никаких дальнейших запросов обнаружения старой версии в течение время определенного периода времени. Это может быть полезно, например, для уровня координации при удалении вариантов услуги устаревшей версии. Варианты осуществления, раскрытые здесь, предлагают сервисную операцию в NRF по уведомлению об устаревании услуги. Эта сервисная операция может быть частью вышеупомянутой услуги “сервисного обновления” (service upgrade) (например, Nnrf_ServiceUpgrade) в NRF или частью другой услуги. В одном примере это является частью услуги "сервисного обновления", как показано ниже в таблице 4:

Таблица 4

Название услуги	Сервисные операции	Семантика операций
Nnrf_ServiceUpgrade	Obsolescence	Subscribe/Notify

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

• Название услуги

• Идентификатор поставщика

• Версия услуги – используемая версия. Версия, о которой подписывающийся объект хочет уведомляться в том случае, когда она стала устаревшей.

• Период времени – промежуток времени, в котором на указанную версию услуги не принимается запросов обнаружения и которая при этом должна считаться устаревшей.

Сообщение подписывающемуся объекту с уведомлением об устаревании (Obsolescence) может содержать признак устаревания услуги (например, конкретной версии, которая также может быть указана).

Заметим, что вышеупомянутые примеры показаны для того, чтобы ограничивать раскрытые здесь варианты осуществления и специалисты в данной области техники могут разработать много альтернативных примеров. Слово "содержащий" не исключает присутствия дополнительных элементов или этапов единственное число не исключает множественное число и единый процессор или другой блок могут выполнять функции нескольких блоков. Там, где используются термины "первый", "второй" и т. д., они должны пониматься просто как метки для удобной идентификации конкретного признака. В частности, они не должны интерпретироваться как описание первого или второго признака из множества таких признаков (т. е., первого или второго из таких признаков, которые должны произойти во времени или в пространстве), если явно не указано иное. Этапы способов, раскрытых здесь, могут выполняться в любом порядке, если явно не указано иное. Любые ссылочные позиции в заявлениях не должны истолковываться, как ограничивающие их объем.

1. Способ регистрации и обнаружения услуги в сети связи, содержащий этапы, на которых:

принимают запрос регистрации услуги, причем запрос указывает сетевую функцию для предоставления услуги, тип услуги и версию услуги;

сохраняют информацию в хранилище, причем информация указывает сетевую функцию, тип услуги и версию услуги;

принимают запрос обнаружения услуги, причем запрос обнаружения услуги указывает тип услуги; и

посылают отправителю ответ на запрос обнаружения услуги, причем ответ на запрос обнаружения услуги указывает сетевую функцию и версию услуги,

при этом хранилище хранит дополнительную информацию, указывающую дополнительную сетевую функцию, тип услуги и дополнительные версии услуги, содержащие предыдущую версию услуги.

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

3. Способ по п. 2, дополнительно содержащий этапы, на которых:

принимают множество запросов обнаружения услуги, причем запросы обнаружения услуги указывают тип услуги; и

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

4. Способ по п. 2 или 3, содержащий этапы, на которых:

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

5. Способ по любому из пп. 2-4, содержащий этап, на котором:

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

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

7. Способ по любому из пп. 2-6, в котором запрос регистрации услуги указывает, что версия услуги является обратно совместимой с дополнительной версией услуги.

8. Способ по любому из пп. 2-7, дополнительно содержащий этапы, на которых:

в ответ на определение, что в течение заданного периода времени не были сделаны никакие запросы обнаружения услуги, указывающие дополнительную версию:

информируют дополнительную сетевую функцию, что в течение заданного периода времени никакие запросы обнаружения услуги, указывающие дополнительную версию, не были сделаны; и/или

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

9. Способ по любому из пп. 1-8, дополнительно содержащий этапы, на которых:

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

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

10. Способ регистрации услуги в сети связи, содержащий этапы, на которых:

посылают запрос регистрации услуги в сетевую функцию регистрацию услуги, причем запрос указывает сетевую функцию предоставления услуги для предоставления услуги, тип услуги и версию услуги, и

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

11. Способ по п. 10, в котором дополнительный запрос регистрации услуги указывает, является ли последующая версия обратно совместимой с версией услуги.

12. Способ по п. 10 или 11, в котором дополнительный запрос регистрации услуги определяет версию услуги, которая является предыдущей версией услуги.

13. Способ по любому из пп. 10-12, в котором запрос регистрации услуги указывает идентификацию поставщика версии услуги, а дополнительный запрос регистрации услуги указывает идентификацию поставщика дополнительной версии услуги.

14. Способ по любому из пп. 10-13, содержащий этап, на котором:

принимают уведомление, что в течение заданного периода времени не были сделаны никакие запросы обнаружения услуги, указывающие версию услуги.

15. Способ по п. 14, в котором уведомление указывает, что информация, указывающая сетевую функцию, тип услуги и версию услуги, была удалена из хранилища.

16. Считываемый компьютером носитель, содержащий команды, которые при исполнении по меньшей мере одним процессором вызывают выполнение указанным по меньшей мере одним процессором способа по любому из пп. 1-9.

17. Считываемый компьютером носитель, содержащий команды, которые при исполнении по меньшей мере одним процессором вызывают выполнение указанным по меньшей мере одним процессором способа по любому из пп. 10-15.

18. Устройство регистрации услуги в сети связи, содержащее процессор и память, причем память содержит команды, исполняемые процессором, так что устройство выполнено с возможностью выполнения способа по любому из пп. 1-9.

19. Устройство регистрации услуги в сети связи, содержащее процессор и память, причем память содержит команды, исполняемые процессором, так что устройство выполнено с возможностью выполнения способа по любому из пп. 10-15.

20. Устройство регистрации услуги в сети связи, содержащее:

приемный модуль, выполненный с возможностью приема запроса регистрации услуги, причем запрос указывает сетевую функцию для предоставления услуги, тип услуги и версию услуги; и

модуль хранения, выполненный с возможностью хранения информации в хранилище, причем информация указывает сетевую функцию, тип услуги и версию услуги;

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

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

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

21. Устройство регистрации услуги в сети связи, содержащее:

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

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