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

Изобретение относится к области беспроводной связи. Техническим результатом является разделение существующих сетевых функций (NF) в сети связи на основе архитектуры на основе услуг (SBA) на конкретную и независимую функциональность, независимое управление жизненным циклом (LCM) в расчете на услугу. Упомянутый технический результат достигается тем, что обеспечен способ обнаружения услуг, предоставляемых посредством NF в сети связи SBA, при этом упомянутая сетевая функция регистрируется в функции сетевого репозитория (NRF), содержащейся в упомянутой сети связи, с использованием названия услуги, адреса услуги и правила выбора, при этом упомянутое правило выбора задает дополнительный адрес услуги и предварительное условие для применения упомянутого правила выбора, при этом упомянутый способ содержит этапы приема, посредством упомянутой NRF, запроса на обнаружение, от потребителя NF, при этом упомянутый запрос на обнаружение содержит упомянутое название услуги, определения, посредством упомянутой NRF, того, что упомянутое правило выбора применяется, посредством определения того, что упомянутое предварительное условие удовлетворяется на основе упомянутого принимаемого запроса на обнаружение, и передачи, посредством упомянутой NRF, упомянутому NF-потребителю ответа по обнаружению, при этом упомянутый ответ по обнаружению содержит упомянутый дополнительный адрес услуги. 5 н. и 10 з.п. ф-лы, 7 ил.

 

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

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

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

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

Для каждой NF, заданы услуги. Например, для NF управления пользовательскими данными (UDM) задаются следующие услуги:

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

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

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

Один из определяющих факторов SBA заключается в том, чтобы достигать независимого управления жизненным циклом (LCM) в расчете на услугу. Другими словами, каждая SBA-услуга должна иметь возможность, по меньшей мере, разрабатываться/обновляться, модернизироваться, масштабироваться, развертываться независимо от других заданных SBA-услуг.

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

Тем не менее, некоторые SBA-услуги, заданные в пятом поколении (5G) Партнерского проекта третьего поколения (3GPP), не следуют этим принципам. Пример такого узла представляет собой UDM NF, функциональности которой описаны выше. При рассмотрении примера UDM-узла, дополнительно показывается то, как все NF не оптимизированы для SBA-окружения.

Услуга "управления данными абонентов", предлагаемая посредством UDM, главным образом представляет собой услугу для того, чтобы осуществлять доступ к базе данных (DB), которая включает в себя операции DB-доступа, такие как запрос, обновление, удаление, создание, подписка, уведомление.

Услуга "управления контекстом UE" представляет собой услугу, которая должна включать в себя большую часть логики сервера собственных абонентов (HSS) четвертого поколения (4G), например при регистрации, потребитель должен принимать некоторые данные подписок; релевантные данные, которые должны предоставляться, внутренняя авторизация и проверки на непротиворечивость зависят от того, представляет потребитель собой функцию доступа и мобильности (AMF), функцию управления сеансами (SMF) или SMS-функцию (SMSF).

По этой причине, услуга "управления контекстом UE" не является четко определенной, чтобы достигать независимого LCM, например:

Масштабирование: для AMF, количество запросов на предоставление услуг может составлять в два раза больше, чем для SMF. В таком случае, чтобы иметь возможность применять различные шаблоны масштабирования с тем, чтобы оптимизировать внутренние ресурсы, каждая различная логика должна задаваться как различная услуга, а не все как идентичные.

Разработка/обновление: если некоторые изменения могут требоваться для SMSF-бизнес-логики, то вся услуга "управления контекстом UE" должна обновляться. Даже если требуемые изменения могут быть ограничены одной/несколькими микроуслугами, это подразумевает, что SW-фрагменту требуется обновление, повторная компиляция, базовое тестирование. Все SW-задачи разработки требуются для всей услуги. Следовательно, желательно смешивать различные функциональности в идентичной услуге, чтобы обеспечивать возможность независимой разработки/обновления каждой функциональности.

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

Развертывание: может требоваться просто развертывать, например, "SMS-управление", но если эта функциональность не задается в независимой услуге, независимая разработка невозможна. Следовательно, UDM-услуги и другие заданные услуги в 3GPP не обеспечивают оптимизированное независимое LCM. Тем не менее, определение услуги уже зафиксировано в 3GPP, и реализации нормально должны быть совместимыми с ним таким способом, чтобы обеспечивать решения с оборудованием от различных производителей. Следовательно, существует потребность дорабатывать 3GPP SBA таким способом, чтобы обеспечивать улучшенное независимое LCM. Следует обратиться к документу "3^rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Procedures for the 5G System; Stage 2 (Release 15)", датированному 2 июня 2017 года, XP051298344. Также следует обратиться к документу US 2012/203864, который раскрывает способ и компоновку в сети связи для выбора сетевых элементов.

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

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

- приема, посредством упомянутой NRF, запроса на обнаружение, от потребителя сетевой функции (NF), при этом упомянутый запрос на обнаружение содержит упомянутое название услуги;

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

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

Авторы изобретения нашли решение, которое является совместимым с уже согласованным определением услуги в 3GPP-сетях связи пятого поколения. В дальнейшем подробнее описывается вышеуказанное относительно унифицированного управления данными (UDM), но следует отметить, что оно представляет собой просто иллюстративный пример. Дополнительно, способ, как описано выше, обеспечивает улучшенное независимое управление жизненным циклом в расчете на услугу или подуслугу.

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

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

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

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

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

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

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

- конкретный тип NF-потребителей, такой как функция управления доступом и мобильностью (AMF) или функция управления сеансами (SMF);

- конкретные идентификационные данные потребителя.

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

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

Дополнительный различный адрес услуги может представлять собой адрес Интернет-протокола (IP) или любой другой адрес, например, полностью определенное доменное имя (FQDN), с помощью которого упомянутая услуга может быть найдена в сети связи. Дополнительно следует отметить, что идентичный IP-адрес со "стандартным" IP-адресом может использоваться для дополнительного адреса услуги, но в таком случае с другим портом и т.п.

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

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

В дополнительном примере, способ содержит этапы:

- приема, посредством упомянутой NRF, из упомянутой NF, запроса на регистрацию услуг для регистрации упомянутой NF в упомянутой NRF, при этом упомянутый запрос на регистрацию содержит упомянутое название услуги, упомянутый адрес услуги и упомянутое правило выбора;

- сохранения, посредством упомянутой NRF, упомянутого названия услуги, упомянутого адреса услуги и упомянутого правила выбора;

- передачи, посредством упомянутой NRF, в упомянутую NF ответа по регистрации услуг для подтверждения приема упомянутого принимаемого запроса на регистрацию.

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

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

- адрес интернет-протокола (IP);

- полностью определенное доменное имя (FQDN).

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

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

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

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

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

- приемное оборудование, выполненное с возможностью принимать запрос на обнаружение от потребителя сетевой функции (NF), при этом упомянутый запрос на обнаружение содержит упомянутое название услуги;

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

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

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

Дополнительно, следует отметить, что оборудование также может упоминаться как модуль, блок, устройство и т.п.

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

- конкретный тип NF-потребителей, такой как функция управления доступом и мобильностью (AMF) или функция управления сеансами (SMF);

- конкретные идентификационные данные потребителя.

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

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

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

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

- и при этом упомянутое передающее оборудование выполнено с возможностью передачи в упомянутую NF ответа по регистрации услуг для подтверждения приема упомянутого принимаемого запроса на регистрацию.

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

- адрес интернет-протокола (IP);

- полностью определенное доменное имя (FQDN).

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

- передающее оборудование, выполненное с возможностью передавать запрос на регистрацию услуг в упомянутую NRF, при этом упомянутый запрос на регистрацию услуг содержит название услуги, адрес услуги и правило выбора, при этом правило выбора задает дополнительный адрес услуги и предварительное условие для применения упомянутого правила выбора;

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

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

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

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

Фиг. 1 схематично иллюстрирует часть архитектуры сети связи пятого поколения (5G).

Фиг. 2 схематично иллюстрирует примерную сетевую функцию (NF) 5G-сети связи.

Фиг. 3 схематично иллюстрирует примерную оптимизацию NF 5G-сети связи.

Фиг. 4 схематично иллюстрирует примерную оптимизацию NF 5G-сети связи.

Фиг. 5 схематично иллюстрирует способ согласно настоящему раскрытию.

Фиг. 6 схематично иллюстрирует способ согласно настоящему раскрытию.

Фиг. 7 схематично иллюстрирует NF согласно настоящему раскрытию.

Подробное описание изобретения

Фиг. 1 схематично иллюстрирует часть архитектуры сети связи пятого поколения (5G), 1. На фиг. 1, ссылка с номером 1 указывает опорную архитектуру для 5G-системы. Архитектура 5G-системы содержит следующие сетевые функции (NF):

- функцию сервера аутентификации (AUSF), 6

- функцию управления доступом и мобильностью (AMF), 7

- сеть передачи данных (DN), например, услуги оператора, доступ в Интернет или сторонние услуги, 5

- функцию сетевой экспозиции (NEF), 12

- функцию NF-репозитория (NRF), 11

- функцию управления политиками (PCF), 10

- функцию управления сеансами (SMF), 8

- унифицированное управление данными (UDM), 13

- функцию пользовательской плоскости (UPF), 4

- прикладную функцию (AF), 9

- абонентское устройство (UE), 2

- сеть (радио)доступа ((R)AN), 3.

Функциональное описание этих сетевых функций указывается в части 6 формулы изобретения 3GPP-стандарта 23.501 "System Architecture for the 5G system". В частности, на фиг. 1, ссылка с номером 1 указывает архитектуру системы для 5G-сети связи в роуминговом случае. Таким образом, UE 2 не находится в сети связи, которой оно первоначально принадлежит, т.е. регистрируется. UE 2 первоначально регистрируется в собственной сети 16, но в данный момент находится в гостевой сети 15. Такое представление показывается просто в качестве иллюстрации и не является ограничением идей согласно настоящему раскрытию.

Фиг. 2 схематично иллюстрирует примерную сетевую функцию (NF) 5G-сети связи. Ссылка с номером 20 связана с ситуацией, в которой услуга 21 потребителя запрашивает конкретную услугу из услуги 30 производителя. В качестве примера, услуга 30 производителя может представлять собой услугу управления контекстом UE, предлагаемую посредством UDM. К примеру, услуга реализуется в облачном окружении посредством нескольких микроуслуг 41-48. Число микроуслуг и функция, выполняемая посредством каждой микроуслуги, зависят от NF, а также зависят от внутренней программной архитектуры.

Микроуслуги содержатся в соответствующих контейнерах 31-38 виртуальных сетевых функций (VNFC). Снова рассмотрим пример, в котором услуга 30 означает услугу управления контекстом UE, предлагаемую посредством UDM, и AMF-логика требует других микроуслуг относительно SMF-логики. Такой пример представляется посредством ссылок с номерами 50 и 55 на фиг. 3.

Ссылка с номером 51 означает группу микроуслуг 41, 42, 44, 45, 46 и 48, которые требуются посредством AMF-логики, и другая - группу 52, сформированную посредством микроуслуг 41, 43, 47 и 48, которые требуются посредством SMF-логики. В идеале, чтобы достигать наилучшего независимого управления жизненным циклом (LCM) в расчете на услугу, лучше задавать AMF-управление и управление сеансами в качестве двух независимых услуг, а не в качестве части услуги управления контекстом UE.

Согласно настоящему раскрытию, предлагается, после того как стандарт задается, оптимизировать LCM на основе критериев оптимизации для регистрации и обнаружения услуг. Например, в вышеуказанном сценарии, критерии оптимизации могут представлять собой тип потребительских NF таким образом, что AMF-логика 51 выполняется, когда потребительская NF представляет собой AMF, и логика 52 управления сеансами выполняется, когда потребительская NF представляет собой SMF.

Фиг. 4 схематично иллюстрирует примерную оптимизацию NF 5G-сети связи. Ссылка с номером 60 указывает вариант осуществления оптимизированной UDM-функции, в котором заданы две оптимизированных подуслуги 51, 52. Одна из двух подуслуг 51 служит для управления доступом и мобильностью, когда потребитель представляет собой AMF 7, а другая 52 служит для управления сеансами, когда потребитель представляет собой SMF 8. В этом примере, услуга управления контекстом UE, предлагаемая посредством UDM, оптимизирована с помощью критериев оптимизации типа потребительских NF. Специалисты в данной области техники понимают, что другие сетевые функции также могут аналогично оптимизироваться на основе различных критериев оптимизации. Альтернативно, идентичная сетевая функция может оптимизироваться несколькими способами с использованием нескольких критериев оптимизации.

Также возможно то, что когда независимые микроуслуги задаются, некоторые микроуслуги содержатся в нескольких подуслугах. В примерном варианте осуществления, показанном на фиг. 4, микроуслуги 41 и 48 содержатся в обоих подуслугах 51 и 52. Микроуслуга 41, например, может требоваться для реализации интерфейсов с оборудованием от различных производителей, таких как передача репрезентативного состояния (REST). В качестве примера, микроуслуга 38 может требоваться в обеих подуслугах 51, 52, чтобы реализовывать доступ к UDR. Но помимо этих двух микроуслуг 41, 48, остальные микроуслуги могут быть полностью конкретными для каждой подуслуги.

Фиг. 5 схематично иллюстрирует способ 70 согласно настоящему раскрытию. Более конкретно, способ 70 показывает модифицированный процесс регистрации после рассмотрения процесса оптимизации согласно настоящему раскрытию. Как задано в технических требованиях (TS) 3GPP 5G, каждый NF-производитель 71 регистрирует 72 услуги, которые он предлагает в NRF 11. По меньшей мере, следующие параметры включаются:

- Название услуги, идентифицирующее регистрируемую услугу.

- Адрес услуги. Адрес услуги, например, может представлять собой адрес Интернет-протокола (IP) или полностью определенное доменное имя (FQDN). Он может использоваться посредством услуги потребителя для того, чтобы контактировать с услугой производителя.

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

В примере, NFtype=AMF используется в качестве критериев, чтобы идентифицировать услугу 51 управления контекстом UE, оптимизированную для управления доступом и мобильностью. Несколько значений для идентичных критериев могут предоставляться, как, например, NFtype=SMF. Альтернативно, даже несколько критериев оптимизации, причем в этом случае может требоваться задавать порядок приоритезации, в случае если несколько критериев могут не быть достоверными для идентичной подуслуги.

Определение критериев оптимизации и улучшение регистрации услуг могут подчиняться потенциальной стандартизации в 3GPP 5G для решений с оборудованием от различных производителей. Стандартизация может исключаться посредством некоторой конфигурации в NRF 11, к примеру, посредством предоставления конкретных адресов услуг в расчете на NFtype.

На дополнительном этапе 63, NRF 11 сохраняет предоставленные один или более адресов услуг. Один адрес для SBA-услуги всегда предоставляется, и, в необязательном порядке, дополнительные адреса могут предоставляться, чтобы идентифицировать различные подуслуги, полностью с критериями оптимизации, с тем чтобы обеспечивать возможность NRF идентифицировать то, когда должен предоставляться каждый адрес услуги. В завершение, NRF 11 отправляет ответ 74 по регистрации услуг в NF-производителя 71.

Фиг. 6 схематично иллюстрирует способ 80 согласно настоящему раскрытию. В частности, способ 80 иллюстрирует способ для обнаружения услуг согласно настоящему раскрытию. Обнаружение услуг может не требовать улучшения при условии, что критерии оптимизации представляют собой значение, которое уже предоставляется при регулярном обнаружении услуг. Это имеет место для NF-типа. Услуга сохраняется 81 в NRF 11 согласно способу 70.

NF-потребитель 81 отправляет запрос 83 на обнаружение услуг в NRF 11. Любые другие критерии оптимизации, не включенные уже для регулярного обнаружения услуг, должны задаваться как необязательные параметры согласно стандартизации, как упомянуто для регистрации услуг 70. В примере, NF-тип должен служить в качестве критериев оптимизации, поскольку этот параметр может нормально использоваться для обнаружения услуг в любом случае. Другие критерии оптимизации в необязательном порядке могут добавляться в запрос. Если да, услуга для обнаружения услуг должна улучшаться и затем подлежать стандартизации для решений с оборудованием от различных производителей или собственного решения для E-решений.

Если критерии оптимизации согласуются 84, то соответствующий адрес подуслуги предоставляется 85 вместо адреса SBA-услуги. Согласно примеру, когда AMF представляет собой потребителя, адрес подуслуги 51 может предоставляться вместо AS-адреса. Тем не менее, если критерии оптимизации не согласуются 86, то соответствующий адрес SBA-услуги предоставляется 87. В нашем примере, AS-адрес.

Фиг. 7 схематично иллюстрирует NF согласно настоящему раскрытию.

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

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

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

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

принимают, посредством упомянутой NRF, запрос на обнаружение от потребителя сетевой функции (NF), каковой запрос на обнаружение содержит упомянутое название услуги;

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

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

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

конкретный тип потребителей NF, такой как функция управления доступом и мобильностью (AMF) или функция управления сеансами (SMF);

конкретные идентификационные данные потребителя.

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

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

5. Способ по п.1, при этом упомянутый способ содержит начальные этапы, на которых:

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

сохраняют, посредством упомянутой NRF, упомянутое название услуги, упомянутый адрес услуги и упомянутое правило выбора;

передают, посредством упомянутой NRF в упомянутую NF, ответ по регистрации услуг для подтверждения приема принимаемого запроса на регистрацию.

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

адрес Интернет-протокола (IP);

полностью определенное доменное имя (FQDN).

7. Способ регистрации услуги, предоставляемой посредством сетевой функции (NF) в сети связи на основе архитектуры, основывающейся на услугах (SBA), в функции сетевого репозитория (NRF), содержащейся в упомянутой сети связи, при этом способ содержит этапы, на которых:

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

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

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

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

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

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

9. Сетевое устройство по п.8, при этом упомянутое предварительное условие связано с любым из следующего:

конкретный тип потребителей NF, такой как функция управления доступом и мобильностью (AMF) или функция управления сеансами (SMF);

конкретные идентификационные данные потребителя.

10. Сетевое устройство по п.8 или 9, при этом упомянутая NF регистрируется в упомянутой NRF с использованием названия услуги, адреса услуги и множества правил выбора, причем каждое правило выбора задает дополнительный, отличающийся от других адрес услуги и соответствующее предварительное условие для применения соответствующего правила выбора.

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

12. Сетевое устройство по п.8, в котором приемное оборудование дополнительно выполнено с возможностью принимать от упомянутой NF запрос на регистрацию услуг для регистрации упомянутой NF в упомянутой NRF, каковой запрос на регистрацию содержит упомянутое название услуги, упомянутый адрес услуги и упомянутое правило выбора; при этом упомянутая NRF содержит оборудование хранения, приспособленное сохранять упомянутое название услуги, упомянутый адрес услуги и упомянутое правило выбора; при этом передающее оборудование выполнено с возможностью передавать в упомянутую NF ответ по регистрации услуг для подтверждения приема принимаемого запроса на регистрацию.

13. Сетевое устройство по п.8, при этом упомянутый адрес услуги и упомянутый дополнительный другой адрес услуги представляют собой любое из следующего:

адрес Интернет-протокола (IP);

полностью определенное доменное имя (FQDN).

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

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

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

15. Машиночитаемый носитель, содержащий компьютерный программный код, который при его исполнении посредством NF, инструктирует NF реализовывать способ по любому из пп.1-7.