СИСТЕМЫ И СПОСОБЫ ДЛЯ УПРАВЛЕНИЯ СЕАНСОМ БЛОКА ДАННЫХ ПРОТОКОЛА (PDU), АДАПТИРОВАННОГО К ПРИЛОЖЕНИЮ Российский патент 2021 года по МПК H04W28/02 

Перекрёстная ссылка на родственные заявки

Настоящая заявка испрашивает приоритет: предварительной заявки на патент США, серийный номер 62/442,857 «СИСТЕМЫ И СПОСОБЫ УПРАВЛЕНИЯ СЕАНСАМИ БЛОКА ДАННЫХ ПРОТОКОЛА (PDU)», поданной 5 января 2017 г.; предварительной заявки на патент США, серийный номер 62/455,368 «СИСТЕМЫ И СПОСОБЫ УПРАВЛЕНИЯ СЕАНСОМ БЛОКА ДАННЫХ ПРОТОКОЛА (PDU)», поданной 6 февраля 2017 г.; предварительной заявки на патент США № 62/459,985 «СИСТЕМЫ И СПОСОБЫ УПРАВЛЕНИЯ СЕАНСОМ БЛОКА ДАННЫХ ПРОТОКОЛА (PDU)», поданной 16 февраля 2017 г.; предварительной заявки на патент США № 62/473,274 «СИСТЕМЫ И СПОСОБЫ УПРАВЛЕНИЯ СЕАНСОМ БЛОКА ДАННЫХ ПРОТОКОЛА (PDU)», поданной 17 марта 2017 г.; предварительной заявки на патент США № 62/477,384, поданной 27 марта 2017 г.; предварительной заявки на патент США 62/487, 960, поданная 20 апреля 2017 г.; предварительной заявки на патент США 62/491,529, поданной 28 апреля 2017 г. «СИСТЕМЫ И СПОСОБЫ УПРАВЛЕНИЯ СЕАНСОМ БЛОКА ДАННЫХ ПРОТОКОЛА (PDU), АДАПТИРОВАННОГО К ПРИЛОЖЕНИЮ»; предварительной заявки на патент США 62/522,040 «СИСТЕМЫ И СПОСОБЫ УПРАВЛЕНИЯ СЕАНСОМ БЛОКА ДАННЫХ ПРОТОКОЛА (PDU), АДАПТИРОВАННОГО К ПРИЛОЖЕНИЮ», поданной 19 июня 2017 года, и заявки на патент США № 15/832,103, поданной 5 декабря 2017 года, содержание каждой из которых включены в настоящий документ посредством ссылки.

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

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

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

Технический отчет проекта партнерства третьего поколения (3GPP) под номером TR 23.799 и озаглавленный «Исследование архитектуры для системы следующего поколения», версия 0.8.0, сентябрь 2016 года (далее именуемый TR 23.799), представляет собой один из подходов к проектированию системной архитектуры для мобильных сетей следующего поколения, также называемых сетями 5-го поколения (5G). Как предложено в вышеупомянутых ссылочных документах, сеть может быть логически разделена на плоскость управления (CP), которая поддерживает функциональные возможности управления сетью, и плоскость пользователя (UP), которая поддерживает передачу данных между устройством пользователя (UE), серверами и сетевыми функции, доступные в сети. В некоторых вариантах осуществления также может быть определена плоскость управления. Следует понимать, что разные плоскости являются логическими структурами. Во многих случаях узлы и функции в сети могут использовать одно и то же физическое оборудование и соединения, хотя они считаются логически различными.

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

Следовательно, необходимо разработать способ и устройство, обслуживающее мобильные устройства беспроводной связи в сетях беспроводной связи, таких как предложенные 5G сети, в которых PDU сеансы могут быть, по меньшей мере, сконфигурированы и обновлены для соответствия текущим параметрам PDU сеанса, таким как расположение прикладной системы или UP выбор.

Виртуализация сетевых функций (NFV) представляет собой концепцию сетевой архитектуры, которая использует технологии IT виртуализации для формирования целых классов виртуализированных сетевых функций в компоновочные блоки, которые могут быть соединены друг с другом или с другими объектами, или могут быть объединены в цепочку, предоставляя услуги связи. NFV основана, но отличается, на традиционных способах виртуализации серверов, таких как используемые в корпоративных IT. Виртуальная сетевая функция (VNF) может состоять из одной или нескольких виртуальных машин (ВМs), на которых выполняют различное программное обеспечение и процессы, поверх стандартных серверов большого объема, коммутаторов и устройств хранения или даже инфраструктуры облачных вычислений, вместо использования пользовательских аппаратных устройств для каждой сетевой функции. В других вариантах осуществления VNF может быть предоставлена без использования виртуальной машины посредством использования других технологий виртуализации, включающие в себя использование контейнеров. В дополнительных вариантах осуществления пользовательское аппаратное устройство может находиться в физической инфраструктуре, используемой для разных виртуальных сетей, и может быть представлено каждой виртуальной сети в качестве виртуальной собственной версии на основании разделения ресурсов устройства между сетями. Например, виртуальный контроллер границы сеанса может быть использован на основании существующих ресурсов для защиты сетевого домена без типичных затрат и сложности получения и установки физических защитных сетевых блоков. Другие примеры VNFs включают ы себя виртуализированные выравниватели нагрузки, брандмауэры, устройства для обнаружения вторжений и WAN акселератор.

NFV структура состоит из трех основных компонентов:

Виртуальные сетевые функции (VNFs) являются программными реализациями сетевых

функций, которые могут быть развернуты в инфраструктуре виртуализации сетевых функций (NFVI).

Инфраструктура виртуализации сетевых функций (NFVI) представляет собой

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

Архитектурный шаблон управления и оркестровки виртуализацией сетевых функций

(MANO) (NFV-MANO архитектурный шаблон, например NFV-MANO, определенный Европейским институтом телекоммуникационных стандартов (ETSI), именуемый ETSI_MANO или ETSI NFV-MANO), представляет собой совокупность всех функциональные блоки, репозитории данных, используемые этими блоками, а также опорные точки и интерфейсы, через которые эти функциональные блоки обмениваются информацией с целью управления и оркестровки NFVI и VNFs.

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

Программно-определяемая топология (SDT) является сетевым технологией, которая определяет логическую сетевую топологию в виртуальной сети. На основе требований к услуге, предоставляемой в виртуальной сети, и доступных базовых ресурсов, виртуальные функции и логические связи, соединяющие функции, могут быть определены SDT контроллером, и эта топология может затем быть реализована для данного экземпляра сетевой услуги. Например, для облачной услуги баз данных SDT может содержать логические связи между клиентом и одним или несколькими экземплярами услуги базы данных. Как следует из названия, SDT обычно генерируют SDT контроллером, который сам может быть виртуализированным объектом в другой сети или сетевом сегменте. Определение логической топологии выполняется SDT контроллером, который генерирует дескриптор (NSLD) инфраструктуры сетевых служб (NSI) в качестве выходных данных. Он может использовать существующий шаблон NSI и добавлять значения параметров к нему для формирования NSLD, или он может генерировать новый шаблон и определять состав NSI.

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

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

Сервисно-ориентированное автоматическое формирование сети (SONAC) представляет собой технологию, в которой используют программно-определяемую топологию (SDT), программно-определяемый протокол (SDP) и программно-определяемое выделение ресурсов (SDRA) для формирования сети или виртуальной сети для данного экземпляра сетевой услуги. Координируя управление SDT, SDP, SDRA и в некоторых вариантах осуществления программно-определяемой сети (SDN), можно добиться оптимизации и повышения эффективности. В некоторых случаях SONAC контроллер может быть использован для формирования сетевого сегмента, в пределах которого может быть сформирована сеть, совместимая с проектом партнерства 3-го поколения (3GPP), с использованием виртуализированной инфраструктуры (например, VNF и логических каналов) для предоставления услуги виртуальной сети (VN). Специалистам в данной области техники должно быть понятно, что ресурсами, выделенными различным VNFs и логическим каналам, можно управлять с помощью функциональных возможностей SDRA-типа SONAC контроллера, в то время как способ, которым соединены VNFs, может быть определен функциональными возможностями SDT-типа SONAC контроллера. Способ, которым VNFs обрабатывают пакеты данных, может быть определен функциональностью SDP- типа SONAC контроллера. SONAC контроллер может быть использован для оптимизации управления сетью, и поэтому также может рассматриваться как оптимизатор управления сетью (NM).

По мере реализации и стандартов реализации NFV, необходимо разработать системы и способы для обеспечения выполнения соглашений об уровне предоставления услуги (SLAs) согласованным и надежным способом.

Использованные в настоящем описании сокращения, которые конкретно не определены в данном документе, должны интерпретироваться в соответствии с техническими стандартами проекта партнерства 3-го поколения (3GPP), такими как, например, технический стандарт TS 23.501 V0.3.1 (март 2017 года).

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

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

Задача вариантов осуществления настоящего изобретения состоит в предоставлении систем и способов обеспечения того, что соглашения об уровне предоставления услуги (SLAs) могут быть удовлетворены.

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

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

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

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

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

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

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

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

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

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

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

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

В реализации AS уведомление о местоположении содержит AS уведомление о перемещении, которое изменяет существующее местоположение PDU сеанса.

В реализации, в котором AS уведомление о местоположении содержит AS уведомление о местоположении, которое устанавливает местоположение будущего PDU сеанса. Уведомление о перемещении AS может быть передано в функцию управления сеансом (SMF) для конфигурирования управления трафиком для трафика данных в перемещенную AS.

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

В реализации предусмотрен способ управления трафиком данных сеанса блока данных протокола (PDU), которым обменивается устройство пользователя (UE), подключенное к сети, причем способ содержит объект плоскости управления, доступный в сети: прием PDU запроса сеанса от UE; верификация UE контекста и авторизация запроса сеанса на основе данных подписки пользователя и, если авторизован, способ дополнительно содержит: выбор и установку тракта плоскости пользователя (UP) для запрошенного PDU сеанса; передачу ответа на запрос PDU сеанса в UE.

В реализации запрос PDU сеанса включает в себя идентификатор сеанса.

В реализации запрос PDU сеанса включает в себя предпочтительный SSC режим для запрошенного PDU сеанса.

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

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

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

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

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

фиг. 3А является блок-схемой, иллюстрирующей основанное на обслуживании представление архитектуры системы 5G базовой сети;

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

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

фиг. 5 представляет собой схему сигнализации, иллюстрирующую вариант осуществления уведомления о AS местоположении или перемещении;

фиг. 6 представляет собой схему сигнализации, иллюстрирующую вариант осуществления процедуры запроса уведомления о выборе (повторном выборе) UP;

фиг. 7 представляет собой схему сигнализации, иллюстрирующую вариант осуществления процедуры уведомления о выборе (повторном выборе) UP;

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

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

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

фиг. 11A и фиг. 11B являются схемами сигнализации, иллюстрирующие вариант осуществления выбора UP под влиянием приложения, выполняемого SMF, как часть установления сеанса;

фиг. 12A и фиг. 12B являются схемами сигнализации, иллюстрирующие варианты осуществления процедуры UP повторного выбора под влиянием приложения;

фиг. 13 является схемой сигнализации, иллюстрирующей вариант осуществления процедуры услуги уведомления о местоположении (повторном) приложения;

фиг. 14 является схемой сигнализации, иллюстрирующей вариант осуществления услуги уведомления о выборе (повторного выбора) UP;

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

фиг. 16 является схемой сигнализации, иллюстрирующей вариант осуществления процедуры уведомления о выборе (повторном выборе) UP;

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

фиг. 18А и фиг. 18В показывают схемы сигнализации, иллюстрирующие вариант осуществления реконфигурации привязки PDU сеанса из-за перемещения приложения;

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

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

фиг. 21 представляет собой упрощенную схему сети, иллюстрирующую вариант осуществления сегментированного управления;

фиг. 22 представляет собой упрощенную схему сети, иллюстрирующую сегментированное управление в соответствии с вариантами осуществления настоящего изобретения;

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

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

фиг. 25A-25C является схемой алгоритма операций по обработке вызова, иллюстрирующей соответствующие примерные процессы в соответствии с вариантами осуществления настоящего изобретения;

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

фиг. 27A и фиг. 27B показывают схемы алгоритма операций по обработке вызова, иллюстрирующие соответствующие примерные процессы для уведомления об управлении UP трактом в AF в соответствии с примерными вариантами осуществления настоящего изобретения; и

фиг. 28A и фиг. 28B показывают схемы алгоритма операций по обработке вызова, иллюстрирующие альтернативный процесс для уведомления об управлении UP трактом в AF в соответствии с примерным вариантом осуществления настоящего изобретения;

фиг. 29A и фиг. 29B показывают схемы алгоритма операций по обработке вызова, иллюстрирующие дополнительный альтернативный процесс для уведомления об управлении UP трактом в AF в соответствии с примерным вариантом осуществления настоящего изобретения;

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

фиг. 31 является логической блок-схемой, иллюстрирующей примерную взаимосвязь между местоположением приложения, DNAI и UPF, в соответствии с вариантами осуществления настоящего изобретения.

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

Описание вариантов осуществления

В данной заявке в примерных вариантах осуществления был использован термин IP-адрес. Следует понимать, что в разных вариантах осуществления вместо IP-адреса, где это применимо, могут быть использованы разные идентификаторы и адреса, такие как аппаратный адрес, IP-адрес, MAC-адрес или другой адрес.

На фиг. 1 показана блок-схема вычислительной системы 100, которая может быть использована для реализации устройств и способов, раскрытых в данном документе. Конкретные устройства могут использовать все показанные компоненты или только подмножество компонентов, и уровни интеграции могут варьироваться от устройства к устройству. Кроме того, устройство может содержать несколько экземпляров компонента, таких как множество блоков обработки, процессоров, запоминающих устройств, передатчиков, приемников и т.д. Вычислительная система 100 включает в себя блок 102 обработки. Блок 102 обработки также может называться электронным устройством (ED). В некоторых вариантах осуществления блок 102 обработки может быть устройством пользователя (UE), тогда как в других вариантах осуществления это может быть вычислительная платформа, такая как вычислительный сервер в среде центра обработки данных. Блок 102 обработки обычно включает в себя центральный процессор 114 (CPU), шину 120 и память 108 и может дополнительно включать в себя запоминающее устройство 104 большой емкости, видеоадаптер 110 и интерфейс 112 ввода/вывода (показаны пунктирной линией). Специалистам в данной области техники должно быть понятно, что CPU 114 представляет возможности обработки. В некоторых вариантах осуществления вместо обычного CPU может быть предусмотрено специализированное ядро обработки. Например, графический процессор (GPU) или другие так называемые ускоренные процессоры (или ускорители обработки) могут быть предусмотрены в дополнение к центральному процессору или вместо него.

CPU 114 может содержать электронный процессор данных любого типа. Память 108 может содержать любой тип постоянной памяти системы, такой как статическая память с произвольным доступом (SRAM), динамическая память с произвольным доступом (DRAM), синхронная DRAM (SDRAM), постоянная память (ROM) или их комбинация. В варианте осуществления память 108 может включать в себя ROM для использования при загрузке и DRAM для хранения программ и данных для использования во время выполнения программ. Шина 120 может быть одной или более из любого типа нескольких архитектур шины, включающая в себя шину памяти или контроллер памяти, периферийную шину или видео шину.

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

Видеоадаптер 110 и интерфейс 112 ввода/вывода предоставляют дополнительные интерфейсы для подключения внешних устройств ввода и вывода к блоку 102 обработки. Примеры устройств ввода и вывода включают в себя дисплей 118, соединенный с видеоадаптером 110, и I/О устройство 116, такое как сенсорный экран, подключенный к интерфейсу 112 ввода/вывода. Другие устройства могут быть подключены к процессору 102, и могут использоваться дополнительные или меньше интерфейсов. Например, последовательный интерфейс, такой как универсальная последовательная шина (USB) (не показана), может использоваться для обеспечения интерфейса для внешнего устройства.

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

На фиг. 2 показана блок-схема, схематично иллюстрирующая архитектуру типичного сервера 200, используемого в вариантах осуществления настоящего изобретения. Предполагают, что сервер 200 может быть физически реализован как один или несколько компьютеров, запоминающих устройств и маршрутизаторов (любой или все из которых могут быть сконструированы в соответствии с системой 100, описанной выше со ссылкой на фиг. 1), соединенных вместе для формирования локальной сети или кластера, и для выполнения подходящего программного обеспечения для реализации их функций. Специалистам в данной области техники понятно, что возможно множество подходящих комбинаций аппаратного и программного обеспечения, которые могут быть использованы для целей настоящего изобретения, которые либо известны в данной области техники, либо могут быть разработаны в будущем. По этой причине, чертеж, показывающий физическое оборудование сервера, не описан в данной спецификации. Скорее, блок-схема фиг. 2А показывает типичную функциональную архитектуру сервера 200, при этом следует понимать, что эта функциональная архитектура может быть реализована с использованием любой подходящей комбинации аппаратного и программного обеспечения.

Как можно видеть на фиг. 2, иллюстрированный сервер 200 обычно содержит инфраструктуру 202 хостинга и прикладную платформу 204. Инфраструктура 202 хостинга содержит физические аппаратные ресурсы 206 (такие как, например, ресурсы обработки информации, пересылки трафика и хранения данных) сервера 200, и уровень 208 виртуализации, который представляет абстракцию аппаратных ресурсов 206 для прикладной платформы 204. Конкретные подробности этой абстракции будут зависеть от требований приложений, размещаемых на прикладном уровне (описано ниже). Таким образом, например, приложение, которое обеспечивает функции пересылки трафика, может быть представлено с абстракцией аппаратных ресурсов 206, которая упрощает реализацию политик пересылки трафика в одном или нескольких маршрутизаторах. Аналогично, приложение, которое обеспечивает функции хранения данных, может быть представлено с абстракцией аппаратных ресурсов 206, которая облегчает хранение и поиск данных (например, с использованием облегченного протокола доступа к каталогам - LDAP).

Прикладная платформа 204 предоставляет возможности для размещения приложений и включает в себя менеджер 210 виртуализации и услуги 212 прикладной платформы. Менеджер 210 виртуализации поддерживает гибкую и эффективную многопользовательскую среду выполнения и хостинга для приложений 214, предоставляя инфраструктуру как объекты услуг (IaaS). При работе менеджер 210 виртуализации может предоставлять «песочницу» безопасности и ресурсов для каждого приложения, размещаемого платформой 204. Каждая «песочница» может быть реализована как виртуальная машина (ВМ) 216 или как виртуализированный контейнер, который может включает в себя соответствующую операционную систему и контролируемый доступ к (виртуализированным) аппаратным ресурсам 206 сервера 200. Услуги 212 прикладной платформы предоставляют набор услуг приложений межплатформного программного обеспечения и услуг инфраструктуры для приложений 214, размещенных на прикладной платформе 204, как это будет более подробно описано ниже.

Приложения 214 от поставщиков, поставщиков услуг и третьих сторон могут быть развернуты и выполнены в соответствующей виртуальной машине 216. Например, могут быть реализованы MANO и SONAC (и их различные функции, такие как SDT, SDP и SDRA) посредством одного или нескольких приложений 214, размещенных на прикладной платформе 204, как описано выше. Может быть удобно предоставлена коммуникация между приложениями 214 и услугами на сервере 200 в соответствии с принципами сервис-ориентированной архитектуры (SOA), известными в данной области техники.

Услуги 218 связи позволяют приложениям 214, размещенным на одном сервере 200, обмениваться данными с услугами 212 прикладной платформы (например, через заданные интерфейсы прикладного программирования (APIs)) и друг с другом (например, посредством API конкретной услуги).

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

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

Услуга 224 функции разгрузки трафика (TOF) может расставлять приоритеты трафика и маршрутизировать выбранные потоки пользовательских данных на основе политики в приложения 214 и из них. Услуга 224 TOF может предоставляться приложениям 224 различными способами, включающие в себя: сквозной режим, в котором (по меньшей мере, один из восходящего и нисходящего каналов) трафик передают приложению 214, которое может отслеживать, изменять или формировать его, а затем отправлять обратно в исходное соединение сети пакетной передачи данных (PDN) (например, 3GPP канал); и режим конечной точки, где трафик прекращается приложением 214, которое действует как сервер.

На фиг. 3А иллюстрируют основанную на услуге архитектуру 300 для базовой сети 5G или следующего поколения (5GCN/NGCN/NCN). Эта иллюстрация изображает логические связи между узлами и функциями, и показанные на ней соединения не должны интерпретироваться как прямые физические соединения. ED 102 формирует соединение сети радиодоступа с узлом 302 сети радиодоступа (RAN) (который может быть, например, gNodeB (gNB)), который подключен к функции плоскости пользователя (UP) (UPF) 304, такой как шлюз UP через сетевой интерфейс, обеспечивающий заданный интерфейс, такой как интерфейс N3. UPF 304 обеспечивает логическое соединение с сетью данных (DN) 306 через сетевой интерфейс, такой как интерфейс N6. Соединение сети радиодоступа между ED 102 и RAN узлом 302 может называться радиоканалом передачи данных (DRB).

DN 306 может быть сетью передачи данных, используемой для предоставления услуги оператора, или она может выходить за рамки стандартизации проекта партнерства третьего поколения (3GPP), такого как интернет, сеть, используемая для предоставления услуги третьей стороны. и в некоторых вариантах осуществления DN 306 может представлять сеть или ресурс граничных вычислений, такую как сеть мобильных граничных вычислений (MEC).

ED 102 также подключают к функции 308 управления доступом и мобильности (AMF) через логическое соединение N1 (хотя физический путь соединения не является прямым). AMF 308 отвечает за аутентификацию и авторизацию запросов доступа, а также за функции управления мобильностью. AMF 308 может выполнять другие роли и функции, как определено в технической спецификации 3GPP (TS) 23.501. В представлении на основе услуг AMF 308 может связываться с другими функциями плоскости управления базовой сети через интерфейс на основе услуг, обозначенный как Namf.

Функция 310 управления сеансом (SMF) является сетевой функцией, которая отвечает за распределение и управление IP-адресами, которые назначены для ED, а также за выбор UPF 304 (или конкретного экземпляра UPF 304) для трафика, ассоциированного с конкретным сеансом ED 102. Понятно, что в сети 300 обычно имеют несколько SMFs 310, каждая из которых может быть ассоциирована с соответствующей группой EDs 102, узлами 302 RAN или UPFs 304. SMF 310 может устанавливать связь с другими функциями базовой сети в представлении, на основе услуг, через интерфейс на основе услуг, обозначенный как Nsmf. SMF 310 также может подключаться к UPF 304 через логический интерфейс, такой как сетевой интерфейс N4.

Функция 312 сервера аутентификации (AUSF) предоставляет услуги аутентификации другим сетевым функциям через интерфейс Nausf на основе услуг.

Функция 314 сетевого воздействия (NEF) может быть развернута в сети, чтобы позволить серверам, функциям и другим объектам, таким как те, которые находятся вне доверенного домена, иметь доступ к услугам и возможностям в сети. В одном таком примере NEF 314 может действовать подобно прокси-серверу между сервером приложений вне показанной сети и сетевыми функциями, такими как функция 314 управления политикой (PCF), SMF 310, UDM 320 и AMF 308, поэтому что внешний сервер приложений может предоставлять информацию, которая может быть полезна при установке параметров, ассоциированных с сеансом данных. NEF 314 может устанавливать связь с другими сетевыми функциями через сетевой интерфейс Nnef на основе услуг. NEF 314 также может иметь интерфейс для функций не-3GPP.

Функция 318 сетевого хранилища (NRF) предоставляет функциональные возможности обнаружения сетевых услуг. NRF 318 может быть специфическим для наземной сети подвижной связи общего пользования (PLMN) или оператора сети, с которым ассоциирована. Функциональность обнаружения услуг может позволить сетевым функциям и EDs, подключенным к сети, определять, где и как получить доступ к существующим сетевым функциям, и может представлять основанный на услуге интерфейс Nnrf.

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

Унифицированная функция 320 управления данными (UDM) может представлять собой основанный на услуге интерфейс Nudm для связи с другими сетевыми функциями и может предоставить средство хранения данных для других сетевых функций. Унифицированное хранилище данных может обеспечить консолидированное представление сетевой информации, которая может быть использована для обеспечения доступности наиболее релевантной информации для различных сетевых функций из одного ресурса. Это может упростить реализацию других сетевых функций, поскольку им не нужно определять, где в сети хранится определенный тип данных. UDM 320 может использовать интерфейс, такой как Nudr, для соединения с хранилищем пользовательских данных (UDR) 322. PCF 314 может быть ассоциирован с UDM 320, потому что он может быть связан с запросом и предоставлением информации политики подписки в UDR, но следует понимать, что обычно PCF 314 и UDM 320 являются независимыми функциями.

PCF 314 может иметь прямой интерфейс к UDR 322 или может использовать интерфейс Nudr для соединения с UDR 322. UDM 320 может принимать запросы на извлечение контента, хранящегося в UDR 322, или запросы на сохранение контента в UDR 322. UDM 320 обычно отвечает за функциональность, такую как обработка учетных данных, управление местоположением и управление подпиской. UDR 322 также может поддерживать любую или всю обработку аутентифицированных учетных данных, обработку идентификационных данных пользователя, авторизацию доступа, управление регистрацией/мобильностью, управление подпиской и управление службой коротких сообщений (SMS). UDR 322 обычно отвечает за хранение данных, предоставленных UDM 320. Сохраненные данные обычно ассоциированы с информацией профиля политики (которая может быть предоставлена PCF 314), которая управляет правами доступа к хранимым данным. В некоторых вариантах осуществления UDR 322 может хранить данные политики, а также данные подписки пользователя, которые могут включать в себя любой или все идентификаторы подписки, учетные данные безопасности, данные подписки, связанные с доступом и мобильностью, и данные, относящиеся к сеансу.

Функция приложения (AF) 324 представляет функциональность не плоскости данных (также называемой плоскостью не пользователя) приложения, развернутого в домене оператора сети и в сети, совместимой с 3GPP. AF 324 взаимодействует с другими функциями базовой сети через интерфейс Naf на основе услуг и может получать доступ к информации о возможностях сети, а также предоставлять информацию о приложении для использования при принятии решений, таких как маршрутизация трафика. AF 324 также может взаимодействовать с такими функциями, как PCF 314, чтобы предоставлять конкретный ввод приложения для принятия решений в отношении политики и политики. Следует понимать, что во многих ситуациях AF 324 не предоставляет сетевых услуг другим NFs и вместо этого часто рассматривается как потребитель или пользователь услуг, предоставляемых другими NFs. Приложение вне сети 3GPP может выполнять многие из тех же функций, что и AF 324, посредством использования NEF 314.

ED 102 устанавливает связь с сетевыми функциями, которые находятся в плоскости пользователя (UP) 326 и плоскости управления (CP) 328. UPF 304 является частью CN UP 326 (DN 306 находится вне 5GCN). RAN узел 302 может рассматриваться как часть плоскости пользователя, но поскольку он не является строго частью CN, то не считается частью CN UP 326. AMF 308, SMF 310, AUSF 312, NEF 314, NRF 318, PCF 314 и UDM 320 являются функциями, которые находятся в CN CP 328, и часто называются функциями плоскости управления. AF 324 может устанавливать связь с другими функциями в CN CP 328 (прямо или косвенно через NEF 314), но обычно не считается частью CN CP 328.

Специалистам в данной области техники должно быть понятно, что может быть множество UPFs, последовательно соединенных между узлом RAN 302 и DN 306, и могут быть использованы множество сеансов передачи данных для разных DNs посредством параллельного использования нескольких UPFs.

На фиг. 3B иллюстрирует часть сети 300 беспроводной связи, в которой UE 102 подключено к плоскости управления (CP) 328 базовой сети (CN) и к плоскости 326 пользователя UP (UP) через узел доступа (AN) 302. CN CP 328 включает в себя функцию 320 унифицированного управления данными (UDM), которая обменивается данными с плоскостью 330 управления.

Контроллер 332 прикладной системы (AS) отвечает за определение местоположения, перемещение, выбор или повторный выбор AS в AS сети 334. AS контроллер 332 подключен к CN CP 328 через функцию 314 воздействия на сеть (NEF) 314.

CN CP 328 выполнена с возможностью управлять логическим расположением ресурсов в 3GPP домене. Прикладной сервер или прикладная система AS сети 334 управляется AS контроллером 332. Возможность управления трафиком или качество межсетевого взаимодействия (например, измеряется пропускной способностью, задержкой, загрузкой, такой как PDU сеансы), между CN UP 326 и AS предоставляется CN CP 328 сетевыми функциями в плоскости 330 управления, и информация, связанная с этими возможностями и параметрами качества соединения, может храниться в UDM 320. Информация о возможностях управления трафиком может использоваться CP 328 для установления эффективного сквозного тракта между связывающимися сторонами.

CN CP 328 устанавливает связь с подключенным UE 102 через интерфейс NG1 и с AN 302, которая обеспечивает связь через интерфейс NG2. AN 302 связывается с CN UP 326 через интерфейс NG3. CN UP 326 управляется CN CP 328 через интерфейс NG4. Интерфейсы NG1, NG2, NG3 и NG4 описаны более подробно и определены 3GPP стандартами мобильной широкополосной связи. Специалистам в данной области техники будет понятно, что могут быть сделаны изменения в конкретном определении этих интерфейсов без отступления от раскрытого здесь изобретения. Конкретные термины определения этих интерфейсов можно найти в общедоступных документах (см., например, www.3gpp.org для ранее изданных и текущих стандартных документов).

CN CP 328 выполнена с возможностью управлять трафиком на шлюзе (GW) 336 плоскости пользователя для маршрутизации трафика приложения восходящей линии связи (UL) в надлежащее AS местоположение, возможно, с учетом возможного внутрисеансного AS расположения (повторного).

AS сеть 334 выполнена с возможностью управлять трафиком приложения нисходящей линии связи (DL) к надлежащему UP GW 336, возможно, с учетом возможного внутрисеансного выбора (повторного) UP.

Управление трафиком, осуществляемое AS сетью 334, может быть сконфигурировано AS контроллером 332. В некоторых вариантах осуществления управление трафиком, осуществляемое AS сетью 334, может быть сконфигурировано или реализовано посредством механизмов управления мобильностью верхнего уровня внутри самой AS сети 334. В примере по фиг. 3B линия, соединяющая UP GW 336 с AS сетью 334, указывает на соединение, соединяющее CN UP 326 с AS сетью 334, которое реализуется посредством управления трафиком. Следующие схемы сигнализации в настоящем документе описывают реализации, которые сфокусированы на взаимодействии между CN UP 326 и AS сетью 334 для предоставления возможности управлять сеансом PDU осведомленного о приложении для трафика приложения, используя эффективный сквозной тракт.

Сетевая архитектура, показанная на фиг. 3B, предоставляет интерфейс, который может быть необходим для обеспечения взаимодействия между CP 328 (или узлами и функциями в CP) и AS контроллером 332. Этот интерфейс может использоваться для обеспечения управления PDU сеансами осведомленного о приложении для трафика приложений, который требует эффективного сквозного тракта.

В общих чертах, варианты осуществления настоящего изобретения предоставляют способы, посредством которых информация управления плоскостью пользователя (UP) может обмениваться между функцией приложения (AF), поддерживающей одно или несколько приложений, и функцией управления сеансом (SMF). AF обычно является внесетевой функцией, совместимой с 3GPP (в некоторых примерах это может быть сервер или набор серверов, предоставляющих услугу для UEs, подключенных к сети, совместимой с 3GPP, в то время как в других примерах AF может представлять собой функцию, реализованную в среде мобильных граничных вычислений за пределами базовой сети, совместимой с 3GPP, или за пределами RAN, совместимой с 3GPP). В некоторых вариантах осуществления AF упоминается как AS контроллер. AF может быть функцией, выходящей за рамки 3GPP стандарта. AF может быть установлена на прикладном сервере вне 3GPP базовой сети и может работать в качестве контроллера, отвечающего за такие функции, как AS определение местоположения (перемещения) (или AS выбор (повторный выбор)) в пределах локальной DN.

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

Функция приложения может отправлять запросы, чтобы влиять на решения по маршрутизации SMF для трафика PDU сеансов. AF запросы могут влиять на выбор (повторный выбор) UPF и позволять маршрутизировать пользовательский трафик в локальный доступ к сети данных (идентифицируемой идентификатором доступа к сети данных (DNAI)).

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

Если оператор не разрешает функции приложения осуществлять прямой доступ к сети, функция приложения должна использовать NEF для взаимодействия с 5GC. Эта операция может руководствоваться положениями соответствующих технических стандартов, таких как, например, пункт 6.2.10 технического стандарта 3GPP TS 23.501 V0.3.1 (март 2017 года). В вариантах осуществления, где AF не осуществляет доступ к сети напрямую, NEF может быть предоставлена, чтобы предоставить интерфейс, позволяя AF осуществлять доступ к функциям CP сети. Хотя доверенной AF может быть предоставлена возможность взаимодействовать с функциями CN CP, вполне вероятно, что в некоторых сетях будет слишком много функций, чтобы обеспечить доступ к функциям CP для каждой из них. Вместо этого NEF может служить прокси для AF за пределами CN для обмена информацией с CP функциями. Посредством использования NEF AF может быть обеспечен тракт для связи с CP функцией, но он может не знать непосредственно адрес или сетевое имя функции, с которой устанавливают связь.

Функция приложения может быть выполнена с возможностью выбирать (повторно выбирать) или перемещать приложения в пределах локальной DN. Для этого AF может запросить прием уведомлений о событиях, относящиеся к PDU сеансам.

В некоторых вариантах осуществления для AF, которому разрешено напрямую взаимодействовать с NF 5GC, AF запросы относительно текущих PDU сеансов отдельных UE могут отправляться в PCF через N5. В некоторых вариантах осуществления AF запросы могут отправляться через NEF. Запросы, которые предназначены для нескольких UEs, могут отправляться через NEF и могут предназначаться для нескольких PCFs. Затем PCF может преобразовывать AF запросы в политики, которые применяются к PDU сеансам. Специалистам в данной области техники должно быть понятно, что преобразование AF запроса в политику может быть достигнуто несколькими различными способами, включающие в себя генерирование политики, которая может быть передана PCF в UPF, или набор UPFs, который управляет обработкой трафика, ассоциированного с идентифицированными потоками в течение сеанса, генерирование политики выполняют в соответствии с принятым AF запросом. Когда AF подписан на SMF уведомления, такие уведомления могут быть отправлены AF непосредственно или через NEF.

PCF также может подписываться на такие уведомления.

Такие AF запросы могут содержать, по меньшей мере:

Информацию для идентификации трафика, подлежащего маршрутизации. Трафик может быть идентифицирован в AF запроса следующим образом:

Либо номер сети передачи данных (DNN), либо другой вид DN идентификатора и,

возможно, информации сегмента (например, информация содействия выбора сегмента единой сети (S-NSSAI) или AF идентификатор услуги.

Когда AF предоставляет AF идентификатор услуги, то есть, идентификатор услуги, от имени которой AF отправляет запрос, функция базовой сети 5G (например, NEF или PCF) может отобразить этот идентификатор на целевой DNN и информацию сегмента (S-NSSAI).

Когда NEF обрабатывает AF запрос, AF идентификатор услуги может использоваться для авторизации AF запроса идентификатора приложения или информации фильтрации трафика (например, 5-ти компонентный кортеж IP-адреса). Идентификатор приложения относится к приложению, обрабатывающему UP трафик, и может использоваться UPF для обнаружения трафика приложения. AF также может ассоциировать описания фильтров пакетов (PFDs) с идентификатором приложения, но данная ассоциация может быть выполнена с помощью отдельного запроса.

Информации о N6 требованиях к маршрутизации трафика для трафика, указанных в приведенной выше информации. Следует понимать, что N6 относится к интерфейсу между UPF и DN, внешним по отношению к CN. Эта информация о требованиях к маршрутизации трафика может быть предоставлена в форме списка идентификаторов профиля маршрутизации, каждый из которых соответствует одному местоположению хоста приложения в локальной DN, когда приложения формируют статически (то есть, идентификаторы профиля маршрутизации, каждый соответствует DNAI). Когда DNAI (s), в которых формируют приложения, могут динамически изменяться, что может быть представлено в форме DNAI списка и ассоциированной N6 информации маршрутизации. На основании информации N6 требованиях к маршрутизации трафика, которые в некоторых вариантах осуществления могут содержать идентификаторы профилей маршрутизации, PCF определяет список идентификаторов профилей управления трафиком, каждый из которых соответствует поведению управления, которое предварительно сконфигурировано в SMF или UPF. PCF передает идентификатор (идентификаторы) политики управления трафиком в SMF. Идентификаторы политики управления трафиком относятся к механизму, обеспечивающему управление трафиком DN. Если AF взаимодействует с PCF через NEF, он может указывать, по меньшей мере, одно из DNN и местоположение (местоположения) хоста в форме адреса (адресов) или имени (имен) приложения, и NEF может сопоставить информацию с идентификаторами профиля маршрутизации. В варианте осуществления SMF выполнена с возможностью принимать идентификатор (идентификаторы) политики управления трафиком и определять, какой из идентификаторов политики управления трафиком и соответствующие поведения управления должны применяться. SMF передает выбранные идентификаторы политики управления трафиком в UPF. В варианте осуществления UPF выполнена с возможностью идентифицировать соответствующие параметры управления трафиком, которые предварительно сконфигурированы и ассоциированы с выбранным идентификатором (идентификаторами) политики управления трафиком. UPF дополнительно выполнена с возможностью применять соответствующие параметры управления трафиком при обработке трафика данных.

N6 требования к маршрутизации трафика относятся к механизмам, обеспечивающим управление трафиком при локальном доступе к DN. Предполагают, что они соответствуют локальным правилам, сконфигурированными в UPFs для поддержки управления трафиком. Идентификаторы профиля маршрутизации могут относиться к предварительно согласованной политики между AF и 5GC или в альтернативном варианте осуществления они могут просто ссылаться на предварительно определенное требование маршрутизации. Эта политика может ссылаться на разные идентификаторы политики управления, отправленные SMF. В некоторых реализациях политики могут основываться на других условиях, таких как временные условия (например, в зависимости от времени суток и т.д.)

Потенциальные местоположения приложений, к которым должна применяться маршрутизация трафика. Потенциальное местоположение приложения выражается или может быть выражено в виде DNAI списка. В некоторых вариантах осуществления, когда AF взаимодействует с PCF через NEF, AF может предоставлять PCF или NEF список адресов хоста или имен приложений, который транслируется в DNAI(s) список посредством NEF. В некоторых вариантах осуществления, когда AF взаимодействует с PCF через NEF, NEF может отображать информацию AF идентификатора услуги, предоставленную AF, в список DNAI(s). В любом случае, DNAIs могут, например, быть использованы для UPF выбора (повторного выбора).

AF запросы также могут содержать:

информацию о UE(s), для которых должен маршрутизироваться трафик. Это может соответствовать отдельным UEs, идентифицированным с использованием либо внешнего идентификатора, такого как идентифицированные в TS23.682, либо MSISDN, как описано в TS23.003, либо IP-адреса/префикса, либо может соответствовать группе UEs, идентифицированной идентификатором группы, например, идентификатор внешней группы, такой как те, которые определены в TS 23.682, или любое UE, к которому применяют запрос, которое осуществляет доступ к комбинации DNN, S-NSSAI и DNAI, которые могут быть идентифицированы индикатором. В случае или варианте осуществления, в котором тип PDU является IP, когда AF предоставляет IP-адрес/префикс UE, это позволяет PCF идентифицировать PDU-CAN сеанс, для которого применяют данный запрос, и AF запрос применяют только к текущему PDU-CAN сеансу этого UE. В этом случае, также может быть предоставлена дополнительная информация, такая как идентификатор UE, чтобы помочь PCF идентифицировать правильный PDU-CAN сеанс.

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

Когда AF запрос направлен на какое-либо UE или группу UEs, AF запрос, вероятно, повлияет на несколько PDU сеансов, возможно обслуживаемых множеством SMFs и PCFs.

Когда AF запрос направлен группе UEs, он предоставляет один или несколько идентификаторов группы в своем запросе. В некоторых вариантах осуществления члены группы имеют информацию о группе в своей подписке (то есть, идентификатор группы), хранящуюся в UDM. В реализации информация о группе может быть извлечена посредством SMF, например, через интерфейс N10, и передана в PCF, например, через интерфейс N7, при установке PDU-CAN сеанса. Эта реализация позволяет также предоставлять идентификатор группы в AMF, например, через интерфейс N8. В некоторых вариантах осуществления идентификатор группы могут хранить в UDR (действующем в качестве депозитария профиля подписки «SPR») как PCF нестандартные данные. В некоторых вариантах осуществления UE может принадлежать нескольким группам.

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

Информация о том, где (условие пространственной достоверности) должны быть UEs, при применении маршрутизации трафика. В варианте осуществления это обеспечивается в форме географических или топологических идентификаторов, таких как идентификаторы узлов RAN, указывающих возможные обслуживающие узлы RAN UE, когда применяется маршрутизация трафика. Если AF взаимодействует с PCF через NEF, то предоставляют или, в некоторых вариантах осуществления, может предоставлять список идентификатора (идентификаторов) географической области, и NEF отображает информацию на идентификаторы RAN узла. В варианте осуществления условия пространственной достоверности могут быть предоставлены в форме интересующей области (областей). Область, представляющая интерес, может включать в себя, например, географическую область или топологическую область, определяющую область интереса в отношении топологии сети. Интересующая область может быть указана с использованием пространственного идентификатора, такого как идентификатор области отслеживания, идентификатор RAN узла, идентификатора соты и т.д. Если AF взаимодействует с PCF через NEF, он может предоставить список идентификатора географической области (областей) и NEF может отображать информацию на интересующую область на основании предварительно сконфигурированной информации. Предварительная конфигурация может быть выполнена с помощью функции плоскости управления. Предварительная конфигурация может включать в себя отображение идентификатора зоны → информация/конфигурация зоны → интересующая область (или идентификатор (идентификаторы) RAN узла или идентификаторы (идентификаторы) соты).

Альтернативно, в отдельной процедуре, которая выполнена ранее, AF может предоставлять информацию отображения идентификатора зоны → информация/конфигурация зоны в NEF, и функция плоскости управления конфигурирует NEF информацией об RAN узле или информацией о местоположении соты или предварительно определенные области информации, представляющей интерес. Для выполнения отображения NEF может использовать информацию, предоставленную AF, и информацию, предоставленную плоскостью управления (обе являются предварительно сконфигурированной информацией).

AF подписка на следующие события.

Уведомления о событиях управления трактом UP: изменение DNAI для UPF, обслуживающего UE, во время изменения UPF. Соответствующее уведомление об изменении от исходного DNAI к целевому DNAI, отправленное SMF в AF, включает в себя идентификатор целевого DNAI и адрес привязки UPF. В некоторых вариантах осуществления уведомление также может включать в себя IP-адрес/префикс UE, информацию идентификации UE (например, либо внешний идентификатор, либо MSISDN) и N6 информацию маршрутизации, относящуюся к базовой сети.

В некоторых вариантах осуществления, по меньшей мере, одна из информации идентификации UE и N6 информации маршрутизации, относящейся к базовой сети, может не потребоваться, если тип PDU сеанса является IP.

Подписка может быть, по меньшей мере, на одно из раннее уведомление и позднее уведомление. В случае подписки на раннее уведомление, SMF отправляет уведомление перед выполнением выбора (повторного) UPF. В случае подписки на позднее уведомление SMF отправляет уведомление, когда выбор UPF (повторный) завершен.

Функция приложения может отправлять запросы для влияния на решения о маршрутизации SMF для подписки на событие или для обоих.

PCF, основываясь на информации, принятой от AF, политики оператора и т.д., авторизует запрос, принятый от функции приложения, и определяет политику управления трафиком. Политика управления трафиком может указывать список подходящих профилей управления трафиком, сконфигурированных в SMF, и в некоторых вариантах осуществления, политика управления трафиком может включать в себя N6 информацию маршрутизации, например, в случаях, когда N6 информация маршрутизации, ассоциированная с приложением, явно предоставляется AF. Профиль управления трафиком может включать в себя, по меньшей мере, один из идентификаторов профиля маршрутизации, который он поддерживает, и соответствующий идентификатор доступа к сети передачи данных (DNAI). DNAIs относятся к информации, рассматриваемой SMF для выбора UPF, например, для переадресации (локально) некоторых фильтров трафика, соответствующих трафику, предоставляемых PCF.

PCF подтверждает запрос в AF или в NEF.

В процедуре установления сеанса UE может предоставлять идентификаторы приложения в запросе сеанса, указывая, что PDU сеанс предназначен или выделен для приложения, идентифицированного идентификатором (идентификаторами) приложения. Когда DNN в запросе сеанса указывает на локальную DN и когда идентификатор приложения содержится в запросе сеанса, SMF может инициировать аутентификацию/авторизацию третьей стороны, как описано в п. 5.6.6, TS23.501, для проверки доступа приложения.

Во время процедуры установления PDU сеанса (вариант осуществления которого показан на фиг. 28A) SMF может получать информацию групповой подписки (например, идентификатор группы IMSI) из UDR через UDM (например, этапы 2806 и 2808). SMF предоставляет идентификатор приложения (если имеется) и информацию групповой подписки в PCF (например, этап 2814 или 2818) для применения политики оператора.

Для PDU-CAN сеансов, которые соответствуют AF запросу, PCF предоставляет SMF правила PCC, которые могут содержать, по меньшей мере, одно из: по меньшей мере, одну из информации о приложении (то есть, идентификатор приложения) и информации о DNAI(s) к которому должна применяться маршрутизация трафика; и, по меньшей мере, один из список идентификаторов профиля управления трафиком, условий пространственной достоверности и информации о подписке AF в SMF события. В вариантах осуществления, где N6 информация маршрутизации, ассоциированная с приложением, явно предоставляется в AF запросе, PCF также может предоставлять N6 информацию маршрутизации в SMF как часть правил PCC. Это делается путем предоставления политик при установке PDU-CAN сеанса или путем инициирования процедуры модификации PDU-CAN сеанса. В некоторых вариантах осуществления PCF периодически оценивает условие временной действительности AF запроса и информирует SMF, чтобы активировать или деактивировать соответствующие правила PCC в соответствии с результатом оценки.

Если активированные правила PCC содержат условия пространственной достоверности, SMF подписывается на прием информации мобильности UE из AMF, ассоциированной с UE, входящим или выходящим из заинтересованных областей, указанных в условиях пространственной достоверности. SMF использует информацию мобильности UE и условия пространственной достоверности для определения, действительны ли правила PCC для приложения.

Когда правила PCC действительны, SMF может, основываясь на локальных политиках, принимать информацию в правилах PCC для:

выбора (повторного выбора) UPF для PDU сеансов. SMF выполнена с возможностью управлять сопоставлением местоположения UE (TAI/Id соты) и DNAI, ассоциированных с UPF и приложениями. SMF выполнена с возможностью выбирать UPFs, которые обслуживают PDU сеанс. Данную операцию выполняют согласно положениям соответствующих технических стандартов, таких как, например, пункт 6.3.3 технического стандарта 3GPP TS 23.501 V0.3.1 (март 2017 года),

активирования механизмов многоадресности трафика или применения классификатора UL (UL CL). Такие механизмы могут соответствовать положениям соответствующих технических стандартов, таких как, например, пункт 5.3.5 технического стандарта 3GPP TS 23.501 V0.3.1 (март 2017 года). Это может включать в себя предоставление UPF правил пересылки трафика (например, прекращения) и ассоциированной N6 информации о маршрутизации, если N6 информация о маршрутизации является частью правил PCC. Правило пересылки трафика может включать в себя идентификатор приложения и идентификатор политики управления трафиком. Идентификатор приложения относится к правилам обнаружения трафика приложения, сконфигурированным в UPF. В варианте осуществления может быть использован заголовок приложения для ассоциации идентификатора приложения с правилами обнаружения трафика приложения.

Информирования функции приложения о (повторном) выборе UP тракта (например, об изменении местоположения DNAI и PDU сеанса).

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

В некоторых вариантах осуществления, когда UE предоставляет идентификатор приложения во время установления PDU сеанса, SMF может быть выполнена с возможностью передавать идентификатор приложения в DN. В некоторых реализациях SMF может действовать для передачи идентификатора приложения в объект аутентификации/авторизации для DN. Сетевой узел, объект или функция в пределах DN может действовать для выполнения аутентификации/авторизации для конкретного приложения на основании принятого идентификатора приложения. В альтернативных вариантах осуществления идентификатор приложения не предоставляют SMF сетевому узлу, объекту или функции в DN в качестве входной информации. Вместо этого, сетевой узел, объект или функция в DN возвращает список идентификаторов приложения в SMF. В этом случае, SMF должна проверить идентификатор приложения, предоставленный UE, на соответствие приложению. Эти варианты осуществления отличаются тем, что идентификатор приложения предоставляют DN в качестве входной информации в процессе аутентификации/авторизации. В результате, аутентификация/авторизация может быть списком идентификаторов конкретного приложения, возвращаемым DN для обеспечения авторизации конкретного приложения.

На фиг. 4 иллюстрируют сценарий перемещения приложения в виртуализированной среде, где приложение App-1 (например, приложение потокового видео) перемещают в три этапа, например, из-за высокой загрузки. Первый этап выполняют в DNAI-1 и невидим для 5GC. 5GC повторно выбирает DNAI-2 (изменяется от первоначального DNAI-1) в ответ на этап 2 перемещения, а затем 5GC повторно выбирает UPF-2 (меняется с UPF-1) и DNAI-2 (меняется с DNAI-2) относительно этапа 3 перемещения приложения. Третий этап выполняют через центр-А обработки данных и центр-В обработки данных. Перемещение функции приложения во второй центр обработки данных является событием, которое может инициировать повторный выбор UPF.

Далее приведено описание двух вариантов осуществления для инициирования повторного выбора UPF/DNAI.

В первом варианте осуществления DNAI используют без влияния AF на маршрутизацию трафика. В этом случае, влияние AF на маршрутизацию трафика (то есть, повторный выбор UPF/реконфигурация управления трафиком) может быть реализовано после обнаружения трафика приложения в UPF или в DN. То есть, UPF или AF могут передавать уведомление в направлении функции плоскости управления, указывающей, что сеанс содержит трафик данных, ассоциированный с приложением («обнаружение трафика приложения»), путем передачи, например, запроса повторного выбора управления трафиком. В некоторых вариантах осуществления это может быть выполнено посредством AF, передающей запрос или уведомление в SMF, возможно, посредством взаимодействия с NEF. В других примерах, UPF может передавать запрос или уведомление в ответ на обнаружение трафика в сеансе с функцией приложения в DN, доступ к которому осуществляется через UPF. В ответ на прием запроса повторного выбора управления трафика объект плоскости управления может либо запросить, либо вызвать процесс повторного выбора управления трафиком (иногда упоминаемый как «инициирование» повторного выбора управления трафиком). В некоторых вариантах осуществления AF может дополнительно передавать запрос повторного выбора UPF в объект плоскости управления плоскости управления для повторного выбора UPF (иногда упоминаемого как «инициирование» повторного выбора UPF). Таким образом, применяют эффективность сквозного тракта только к части трафика, ассоциированного с PDU сеансом.

Во втором варианте осуществления используют DNAI с влиянием AF на маршрутизацию трафика. В этом варианте осуществления UE предоставляет идентификатор приложения для SMF как часть запроса сеанса. Этот идентификатор приложения может быть ассоциирован с идентификатором PDU сеанса, указывающим, что PDU сеанс предназначен или для трафика, ассоциированного с приложением. Этот идентификатор может быть использован для указания функциям на UP тракте, что должны применяться конкретные политики или правила обработки трафика или конкретная политика маршрутизации трафика. Это позволяет конфигурировать функцию UPF с помощью функции плоскости управления путем отправки политики обработки трафика, указывающей, как должен обрабатываться любой или все потоки трафика с конкретным идентификатором. Например, может быть определена политика маршрутизации трафика, которая гарантирует, что трафик данных, ассоциированный с PDU сеансом, направляют по заданному тракту через CN в или из DN, ассоциированной с приложением.

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

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

Когда UE предоставляет идентификатор приложения, SMF может инициировать аутентификацию/авторизацию третьей стороны для использования PDU сеанса для приложения. Аутентификация/авторизация третьей стороны может быть полезна, так как управление UP для конкретного приложения может применяться к PDU сеансу в соответствии с идентификатором приложения. Сторонняя аутентификация/авторизация может предотвратить ситуации, в которых нельзя полагаться на информацию, принятую от UE (например, идентификатор приложения). Например, механизм аутентификации/авторизации третьей стороны, описанный в 5.6.6, TS23.501, использует плоскость пользователя для обмена информацией или связи между SMF и функцией аутентификации/авторизации третьей стороны. В варианте осуществления в настоящей заявке предлагают расширить механизм, чтобы позволить сторонней аутентификации/авторизации быть выполненной через NEF (который может позволить сторонней аутентификации/авторизации быть выполненной в расширенной плоскости управления). Предоставляя доступ через NEF, в зависимости от предоставленного уровня доступа, функция аутентификации/авторизации третьей стороны может выполнять функции, эквивалентные AF. Этот вариант осуществления предоставляет дополнительные функциональные возможности для поддержки случаев, когда сторонняя функция аутентификации/авторизации не находится в DN. В реализации NEF предоставляет интерфейс и функциональные возможности для обеспечения функции аутентификации/авторизации третьей стороны с возможностью действовать в качестве AF.

При установлении PDU сеанса для DN:

- в некоторых вариантах осуществления UE может быть аутентифицировано/авторизовано третьей стороной, которая может быть расположена в DN, например, DN-AAA сервер.

Если UE предоставляет информацию аутентификации/авторизации во время установления PDU сеанса, и SMF определяет, что требуется сторонняя аутентификация/авторизация установления PDU сеанса на основании политики DN или локальной конфигурации, SMF передает информацию аутентификацию/авторизацию UE третьей стороне. В варианте осуществления, если третья сторона находится в DN, информация может быть передана третьей стороне в DN через UPF. В варианте осуществления, если третья сторона не находится в DN, информация может быть передана третьей стороне через NEF. При использовании NEF, третья сторона может действовать как AF. Если SMF определяет, что требуется аутентификация/авторизация третьей стороны для установления PDU сеанса, но UE не предоставило информацию аутентификации/авторизации, тогда SMF может отклонить установление PDU сеанса.

В реализации третья сторона может аутентифицировать/авторизовать установление PDU сеанса и возвращать результат аутентификации/авторизации в SMF через UPF. В реализации третья сторона может аутентифицировать/авторизовать установление PDU сеанса и возвращать результат аутентификации/авторизации в SMF через NEF.

Если UE предоставляет SMF идентификатор приложения во время установления PDU сеанса, SMF может передать идентификатор приложения третьей стороне. Третья сторона может выполнять аутентификацию/авторизацию для конкретного приложения в соответствии с идентификатором приложения.

SMF может определить, использовать ли UPF или NEF, по меньшей мере, для одной из сторонней аутентификации согласно политике DN, авторизации согласно политики DN, локальной конфигурации и идентификатора приложения, предоставленного UE.

По меньшей мере, выполняют одну из аутентификации и авторизации DN с целью авторизации PDU сеанса в дополнение к:

Аутентификация доступа 5GC, обработанная AMF (в варианте осуществления аутентификация может быть выполнена в соответствии со способом, описанным в пункте 5.2 TS 23.501).

Авторизация PDU сеанса в отношении данных подписки, извлеченных из UDM, обеспечивается SMF.

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

Если UE предоставляет идентификатор приложения во время установления PDU сеанса и, если UPF используют для сторонней аутентификации/авторизации, управление трафиком в UPF может быть сконфигурировано в соответствии с идентификатором приложения. Если UE предоставляет идентификатор приложения во время установления PDU сеанса и, если NEF используют для сторонней аутентификации/авторизации, SMF передает DNN, S-NSSAI и идентификатор приложения в NEF, после чего NEF может выбирать AF (например, функцию аутентификации/авторизации третьей стороны) в соответствии с информацией, передаваемой SMF (например, принятым DNN, S-NSSAI и идентификатором приложения).

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

В некоторых вариантах осуществления, когда SMF добавляет привязку PDU сеанса (такую как привязку PDU сеанса, определенную в пункте 5.6.4 TS 23.501) к PDU сеанса аутентификация и/или авторизация третьей стороны может не выполняться. В некоторых вариантах осуществления политики SMF могут требовать от SMF уведомления третьей стороны, когда новый IP-адрес был добавлен или удален из PDU сеанса, или, когда существующий IP-адрес, ассоциированный с сеансом, был изменен посредством модификации или замены префикса.

Указание отклонения установления PDU сеанса может быть передано посредством SMF в UE через NAS SM.

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

На фиг. 5 представлена схема сигнализации, иллюстрирующая вариант осуществления уведомления о местоположении или перемещении AS.

На этапе 500 NEF 314 принимает уведомление о AS местоположении или перемещении на основе интерфейса прикладной программы (API) из AS контроллера 332. На чертежах термин местоположение (перемещение) относится либо к уведомлению о местоположении, либо к уведомлению о перемещении. Термин выбор (повторный выбор) аналогично относится к выбору или повторному выбору, в зависимости от обстоятельств.

Уведомление может включать в себя AS местоположение (местоположения), подходящее для использования в нем, и это может приниматься во внимание во время выбора UP или повторного выбора, в зависимости от обстоятельств. В случае AS перемещения для существующего сеанса, в уведомлении могут указывать новое AS местоположение (местоположения), которое будет использоваться с этого момента. Уведомление может включать в себя некоторые или все из следующих признаков:

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

Индикатор управления трафиком, который указывает, должно ли управление трафиком от UP 326 к AS быть сконфигурировано посредством CP или обработано AS сетью 334.

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

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

Фильтр трафика, который указывает трафик, к которому может применяться AS местоположение (перемещение). Трафик может принадлежать текущим PDU сеансам (текущий трафик) или будущим PDU сеансам (будущий трафик). Фильтр трафика включает в себя индикатор приложения, который указывает приложение, с которым ассоциирован трафик, и индикатор UE, который идентифицирует UE 5, с которым ассоциирован трафик.

Индикатор UE может быть IP-адресом, ассоциированным с трафиком. В этом случае, трафик является текущим трафиком, и AS контроллер 332 получает IP-адрес из AS. Индикатор UE также может быть идентификатором UE, который выделяется CP 328 и предоставляется AS контроллеру 332 через NEF 314. В этом случае, трафик может включать в себя как текущий трафик, так и будущий трафик.

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

В реализации принятая информация о местоположении может содержать географическое местоположение. NEF 314 может использоваться для преобразования принятого географического местоположения в местоположение, ассоциированное с сетевой топологией, такого как соответствующий идентификатор соты, и для пересылки в SMF 310 или PCF 314 идентификатор соты в качестве местоположения UE через уведомление о AS местонахождении (перемещении). В реализации NEF 314 может действовать для передачи географического местоположения в SMF 310 или PCF 314 в качестве местоположения UE.

Затем на этапе 502 NEF 314 отправляет запрос аутентификации в функцию 312 службы аутентификации (AUSF), если AS контроллер 332 не находится в доверенном домене. Запрос аутентификации может включать в себя информацию идентификации AS контроллера 332, если информация идентификации AS контроллера предоставлена AS контроллером 332 на этапе 500 уведомления определения AS местоположения (перемещения), основанное на API.

На возможном этапе 504 (показан пунктирной линией) AUSF 312 получает идентификацию AS контроллера 332. Этап 504 выполняют, если запрос аутентификации на этапе 502 не включает в себя идентификацию AS контроллера.

На этапе 506 AUSF 314 аутентифицирует AS контроллер 332 и отправляет ответ аутентификации в NEF 314. Ответ аутентификации указывает результат аутентификации.

Если аутентификация успешна, NEF 314 проверяет уведомление и выполняет следующие этапы, которые определяются на основании, применяют ли AS перемещение к текущему трафику или к будущим PDU сеансам.

В реализации, процедура включает в себя только одну из процедуру 508 (AS перемещение для текущих PDU сеансов) и процедуру 510 (определение AS местоположения для будущих PDU сеансов). В одной реализации процедура 508 не используется, и процедура 510 реализована для AS перемещения, выполненного для текущих PDU сеансов, будущего PDU сеанса или комбинации как текущих, так и будущих PDU сеансов. В случае, когда процедура 510 реализована для текущих PDU сеансов, PCF 314 инициирует SMF 310 для повторного выбора UP, передавая триггер повторного выбора UP в SMF 310, чтобы повторно выбрать соответствующую UP для текущих PDU сеансов. В альтернативной реализации процедура 510 не используется, и используется только процедура 508. В альтернативной реализации SMF 310 действует для выполнения AS перемещения для будущих PDU сеансов на основе приема уведомления о AS перемещении, отправленного, например, NEF 314.

В общем, процедура 508 может выполняться в случае AS перемещения для текущих PDU сеансов (то есть, продолжающегося трафика данных). Сначала NEF 314 идентифицирует PDU сеансы, ассоциированные с трафиком, и SMF 310, управляющая идентифицированными PDU сеансами, генерирует уведомление о AS перемещении на основании уведомления о AS перемещении на основании API, и на этапе 512 отправляет уведомление о AS перемещении в идентифицированную SMF 310. В реализации NEF 314 может идентифицировать SMF 310, взаимодействуя с функцией 318хранилища сетевых функций (NRF).

После приема уведомления о AS перемещении SMF 310 может определить, выполнять ли повторный выбор UP для трафика, на который влияют, в соответствии с новым AS местоположением (местоположениями), политикой оператора и режимом непрерывности сеанса и обслуживания (SSC) PDU сеансов.

На этапе 514A, если SMF 10 определяет, что повторный выбор UP не требуется, и, если уведомление о AS перемещении указывает на необходимость конфигурации управления трафиком, SMF 310 конфигурирует управление трафиком путем обновления управления трафиком в UP GW 336. В качестве альтернативы, на этапе 514B, если SMF 310 определяет, что требуется повторный выбор UP, SMF 310 инициирует процедуру повторного выбора UP. При необходимости, SMF 310 может дополнительно конфигурировать управление трафиком в повторно выбранном UP GW 336.

В общем, процедуру 510 выполняют в случае определения AS местоположения (перемещения), применяемого к будущему трафику. На этапе 516, NEF 314 идентифицирует функцию 314 управления политикой (PCF), которая отвечает за политику оператора для будущего трафика, генерирует уведомление о AS местоположении (перемещении) на основании запроса AS местоположения (перемещения) на основе API, и отправляет уведомление о AS местоположении (перемещении) в PCF 314. NEF 314 может идентифицировать PCF 314 путем взаимодействия с NRF 318. На возможном этапе 518 PCF 314 конфигурирует управление трафиком UP GW 336. В реализации конфигурация может быть применяется ко всем UP GWs 336, которые потенциально могут быть использованы для поддержки запрошенного PDU сеанса (в настоящее время или в будущем). В частности, на основании уведомления о AS местонахождении (перемещении), данных подписки и текущих политик оператора PCF 314 может генерировать политику выбора UP и политику управления трафиком для трафика. В реализации возможный этап 518 не выполняют, так как управление трафиком может быть отдельно сконфигурировано во время выбора (повторного выбора) UP (то есть, на этапах 514 или 516).

В одном варианте осуществления, в котором уведомление о AS местоположении (перемещении) указывает на возможность AS перемещения в будущем, PCF 314 может генерировать политику выбора режима сеанса и непрерывности обслуживания (SSC), такую как, например, любой PDU сеанс, ассоциированный с приложением, должен иметь режим SSC, не равный 1.

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

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

На фиг. 6 показана процедура запроса уведомления о выборе (повторного выбора) UP. На этапе 600 NEF 314 принимает запрос уведомления о выборе (повторном выборе) UP на основе API от контроллера 332. Запрос уведомления о выборе (повторном выборе) UP на основе API может включать в себя токен транзакции из предшествующей процедуры уведомления AS местоположения (перемещения). Токен может указывать, что текущий запрос соответствует любой процедуре выбора (повторного выбора) UP, на которую влияет уведомление AS местоположения (перемещения). В качестве альтернативы, запрос может включать в себя некоторую или всю следующую информацию:

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

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

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

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

Фильтр трафика возможно включает в себя индикатор UE, который указывает UE 102, ассоциированное с трафиком данных. Индикатор UE может быть IP-адресом, ассоциированным с трафиком данных. В этом случае, трафик данных является текущим трафиком, и AS контроллер 332 получает IP-адрес из AS. Индикатор UE также может быть идентификатором UE, который выделяется CN CP 328 и предоставляется AS контроллеру 332. В этом случае, трафик данных может включать в себя как текущий трафик, так и будущий трафик. Индикатор UE может указывать более чем одно UE 102. Когда фильтр трафика не включает в себя индикатор UE, он указывает, что запрос уведомления применяют к трафику данных любого UE 102, который соответствует критериям, определенным фильтром трафика.

После приема запроса уведомления выбора (повторного выбора) UP на основе API, на этапе 602, NEF 314 отправляет запрос аутентификации в AUSF 312, если AS контроллер 332 не находится в доверенном домене. Запрос аутентификации может включать в себя идентификационную информацию AS контроллера 332, если информация предоставляется AS контроллером в запросе уведомления о выборе (повторном выборе) UP на основе API.

На возможном этапе 604 AUSF 312 получает идентификацию AS контроллера 332. Этот этап выполняют, если запрос 602 аутентификации не включает в себя идентификационную информацию AS контроллера 332.

На этапе 30406 AUSF 312 аутентифицирует AS контроллер 332 и отправляет ответ аутентификации в NEF 314, указывающий результат аутентификации.

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

На этапе 608 NEF 314 генерирует запрос уведомления о выборе (повторном выборе) UP на основе запроса уведомления о выборе (повторном выборе) UP на основе API и отправляет его в PCF 314. PCF 314 может подтвердить запрос и, если запрос является действительным, PCF 314 может генерировать политику уведомления о выборе (повторного) UP на основе принятого запроса уведомления о выборе (повторного выбора) UP. На возможном этапе 610 PCF 314 может передавать ответ аутентификации выбора (повторного выбора) в NEF 314, указывающий результат проверки.

На этапе 612, NEF 314 отправляет ответ на уведомление о UP местоположении (перемещении) на основе API обратно в AS контроллер 332, либо подтверждая принятие уведомления AS местоположения (перемещения), либо отклоняя уведомление AS местоположения (перемещения). В случае отказа, сообщение содержит код ошибки, указывающий причину отказа. В реализации ответ включает в себя токен транзакции, идентифицирующий уведомление AS местоположения (перемещения). Маркер транзакции может использоваться AS контроллером 332 для последующего обновления уведомления AS местоположения (перемещения), по меньшей мере, одного из предоставления полной информации и запроса уведомления о выборе (повторном выборе) UP, на который влияет уведомление AS местоположения (перемещения).

Фиг. 7 иллюстрирует процедуру уведомления UP выбора (повторного выбора). SMF 310 инициирует процедуру уведомления UP выбора (повторного выбора), если требуется уведомление UP выбора (повторного выбора) в результате процедуры запроса уведомления UP выбора (повторного выбора) (например, как описано выше), после выполнения UP выбора (повторного выбора).

На этапе 700 SMF 310 отправляет уведомление UP выбора (повторного выбора) в NEF 314. Уведомление UP выбора (повторного выбора) может включать в себя, по меньшей мере, один из токен транзакции соответствующего запроса уведомления UP выбора (повторного выбора), указание AS местоположения и указание местоположения UP GW 336. Информация о местоположении может, например, иметь вид сетевого адреса.

На этапе 702 NEF 314 генерирует уведомление UP выбора (повторного выбора) на основе API на основании уведомления UP выбора (повторного выбора) и передает его AS контроллеру 332. AS контроллер 332 сообщает NEF 314 подтверждение приема уведомления UP выбора (повторного выбора) на основе API. Перед отправкой подтверждения AS контроллер 332 может выполнить необходимые этапы для процедуры AS местоположения (перемещения) или AS состояния местоположения (перемещения), которая может включать в себя высвобождение ресурсов и структур данных, конфигурирование управления трафиком и т.д.

На этапе 704 NEF 314 передает подтверждение уведомления UP выбора (повторного выбора) в SMF 310, подтверждающее прием подтверждения уведомления UP выбора (повторного выбора) на основе API, принятого от AS контроллера 332.

Фиг. 8 иллюстрирует процедуру установления PDU сеанса, адаптированного к приложению. На этапе 800 AS контроллер 332 инициирует процедуру уведомления AS местоположения (перемещения) с помощью CP 328 для будущего трафика, ассоциированного с UE 102, и для указанного приложения, которое генерирует политику выбора UP с учетом осведомленности о приложении и политику управления трафиком.

На этапе 802 AS контроллер 332 также инициирует процедуру запроса уведомления о UP местоположении (перемещении) с CP 328 для будущего трафика, ассоциированного с UE 102, и к указанному приложению, которое генерирует политику выбора UP с учетом осведомленности о приложении и политику управления трафиком.

В процедуре 804, UE 102 может инициировать процедуру установления сеанса, при наличии трафика приложения для передачи или приема из приложения. На этапе 806 UE 102 отправляет запрос сеанса в SMF 310 через функцию 308 управления доступом и мобильностью ядра (AMF). Запрос сеанса может включать в себя идентификатор сеанса и предпочтительный режим SSC (возможно). Запрос сеанса также может включать в себя идентификатор приложения, указывающий, что это выделенный запрос сеанса для приложения. На этапе 808 SMF 310 проверяет контекст UE с помощью UDM 320 и авторизует запрос сеанса в соответствии с данными подписки пользователя.

Если запрос сеанса авторизован, SMF 310 инициирует процедуру 810 выбора UP. На первом этапе 812 SMF 310 получает политики оператора от PCF 314, включающие в себя результирующие политики, адаптированные к приложению, из процедуры 800 уведомления AS местоположения (перемещения). На возможном этапе 814, SMF 310 выбирает режим SSC для PDU сеанса в соответствии с запросом сеанса, политиками оператора, типом UE и другой необходимой информацией. Например, если запрос включает в себя идентификатор приложения, но нет предпочтительного режима SSC и, если правила оператора указывают на потенциальное будущее перемещение AS, SMF 310 может установить режим SSC PDU сеанса на 2 или 3 для предоставления повторного выбора UP для эффективного сквозного тракта.

На этапе 816 SMF 310 взаимодействует с UDM 320, чтобы получить возможность управления трафиком между кандидатами UP GWs 336 и AS местоположениями, и выбирает UP тракт для PDU сеанса относительно политик оператора на основании информации, предоставленной посредством UDM 320. На этапе 818 SMF 310 инициирует установку UP и, если политики оператора указывают на необходимость конфигурации управления трафиком, конфигурирует управление трафиком в UP GW 336.

На этапе 820 SMF 310 передает запрос на установление соединения в AN 302 для соединения с UP 326. На этом этапе AN 302 может выделять RAN ресурсы для PDU сеанса.

Если операторские политики указывают на необходимость уведомления о UP выборе (повторном выборе), на этапе 822 SMF 310 уведомляет AS контроллер 332 о выборе UP посредством процедуры уведомления о выборе UP.

На этапе 824 SMF 310 передает ответ на запрос PDU сеанса в UE 102 через AMF 308. Ответ включает в себя режим SSC, выбранный для PDU сеанса, если UE 102 не предоставил предпочтительный режим SSC в запросе сеанса. На этапе 826 выполняют передачу трафика из UE 102 через UP GW 336.

На фиг. 9 иллюстрирует процедуру повторного выбора UP с учетом применения для модификации PDU сеанса. В этой процедуре на этапе 900 UE 102 имеет установленный PDU сеанс, который переносит трафик приложения через UP-A 326A. Как показано на фиг. 9, передача трафика приложений 902 осуществляется через UP-A 326A.

SMF 310 принимает триггер для повторного выбора UP для трафика приложения, переносимого PDU сеансом. Триггер может быть из: процедуры 904 уведомления о AS перемещении, указывающей новое AS местоположение; процедуры 906 хендовера, указывающей новую обслуживающую AN; или триггер 908 политики из PCF 314, указывающий изменение политики, которое влияет на выбор UP PDU сеанса.

В ответ на прием триггера на этапе 910 SMF 310 отправляет сообщение перенаправления сеанса в UE 102 через AMF 308. Этот этап является возможным, если установленный PDU сеанс должен быть предварительно обслужен или использован повторно в соответствии с к конфигурации режима SSC.

На этапе 912 UE 102 передает запрос сеанса для установки нового сеанса в ответ на прием перенаправления сеанса. Обратите внимание, что этот этап также является возможным, поскольку выполняют только в том случае, если от SMF 310 принято сообщение о перенаправлении сеанса.

На этапе 914 SMF 310 устанавливает UP-B 326B для трафика приложения, используя процедуру UP выбора (повторного выбора). Этап 914 аналогичен процедуре выбора UP, показанной на фиг. 7 и описан выше.

В случае, если этап 912 является возможным, если PDU сеанс не является выделенным PDU сеансом для приложения и имеет режим SSC 3, SMF 310 может вставить точку ответвления в UP тракт, так что UP-A 326A и UP-B 326B являются двумя ветвями UP тракта. SMF 310 инструктирует точку ответвления направлять трафик, ассоциированный с приложением, на UP-B 326B, например, согласно адресу назначения или комбинации адреса назначения и номера порта.

На этапе 916 SMF 310 отправляет ответ сеанса в UE 102 через AMF 308, чтобы закрыть запрос сеанса, отправленный на этапе 912. Если текущий PDU сеанс не является выделенным PDU сеансом для приложения и имеет SSC режим 3, ответ должен указывать трафик приложения, который должен быть перенаправлен на новый PDU сеанс, например, через адрес назначения или комбинацию адреса назначения и номера порта. UE 102 будет выполнять перенаправление трафика в соответствии с указанием перенаправления в ответе сеанса.

На этапе 918 SMF 310 устанавливает перенаправление трафика от UP-A 326A к UP-B 326B для оставшегося трафика. На этапе 920 трафик будущих приложений продолжается теперь через UP-B 326B.

В варианте осуществления предоставлены система и способ для управления SSC и UP под влиянием приложения для граничных вычислений. В варианте осуществления предполагают, что приложения (то есть AS) развернуты в локальной сети оператора, то есть, в локальной DN.

Ссылаясь на фиг. 10, функция приложения (AF) 324 (не-3GPP-функция) отвечает за AS местоположение (перемещение) (или AS выбор (повторный выбор)) в пределах локальной DN. Функция 324 приложения взаимодействует с CP 328 через NEF 314. Поведение функции 324 приложения и фактическое перемещение приложения или контекста приложения еще не определены в соответствии с текущим стандартом и не относятся к настоящему изобретению.

CN CP 328 имеет информацию о возможности управления трафиком между UPF 304 и AS местоположениями. Информацию предоставляют компонентом управления сетью, таким как сетевой менеджер в плоскости 330 управления, и используется NEF 314 для определения пригодности или предпочтения UPF 304 для приложения.

SMF 310 выполнена с возможностью конфигурировать управление трафиком в UPF 304 для маршрутизации трафика UL в надлежащее AS местоположение с учетом AS местоположения (перемещения).

Локальная DN выполнена с возможностью управлять трафиком DL на надлежащий UPF 304 с учетом UP выбора (повторного выбора). UPF 304 распознает IP-адрес UE, ассоциированный с трафиком DL, как действительный IP-адрес. Чтобы гарантировать, что UPF 304 распознает IP-адрес UE, в некоторых вариантах осуществления каждый из UPF 304 может использовать одно и то же пространство частных IP-адресов.

Управление трафиком DL может быть сконфигурировано функцией 324 приложения или реализовано с помощью механизмов управления мобильностью верхнего уровня в пределах локальной DN. UPF 304 может распознавать IP-адрес UE в трафике DL как действительный идентификатор. Это может быть достигнуто, например, путем применения того же пространства частных IP-адресов в UPF 304. Как отмечено выше, в вариантах осуществления, где IP-адресация не используется, могут использовать другие типы адресов или идентификаторы. Описание функционирования локальной DN для управления DL трафиком не имеет непосредственного отношения к следующему обсуждению.

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

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

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

На фиг. 11А представлена схема сигнализации, иллюстрирующая вариант осуществления выбора UP под влиянием приложения, выполняемого SMF 310 как часть установления сеанса. На этапе 1100 функция приложения уведомляет сеть о местоположении (местоположениях) приложения для будущего трафика приложения, ассоциированного с UE 102, посредством процедуры «уведомление о местоположении приложения (перемещении)» услуги NEF 314, где политика выбора UP и правило управления трафиком генерируется PCF 314. В одной реализации процедура уведомление о местоположении приложения (перемещении) услуги NEF 314 может быть реализована с использованием любого количества различных способов, включающие в себя некоторые из описанных в другом месте в настоящем документе.

На этапе 1102 функция 324 приложения может подписаться на уведомление выбора (повторного выбора) UP 326 для будущего трафика приложения, ассоциированного с UE 102, посредством процедуры (часть 1) «уведомление выбора (повторного выбора) UP» услуги NEF 314, где политика уведомления о выборе UP (повторного выбора) генерируется PCF 314. В реализации может быть реализована процедура «уведомления выбора (повторного выбора) UP» NEF 314. Этап 1102 является возможным этапом, который может быть определен функцией 324 приложения. В некоторых реализациях этапы 1100 и 1102 могут работать независимо друг от друга.

На этапе 1104 UE 102 отправляет запрос сеанса в SMF 310, который включает в себя локальный идентификатор DN. Запрос может включать в себя идентификатор приложения, указывающий, что это выделенный PDU сеанс для приложения. Локальный идентификатор DN и идентификатор приложения могут быть двумя частями интегрированного идентификатора (в качестве локального идентификатора DN или идентификатора приложения) или могут быть двумя отдельными идентификаторами.

На этапе 1106 SMF 310 проверяет контекст UE и авторизует запрос сеанса в соответствии с данными подписки пользователя. На этапе 1108 SMF 310 получает операторские политики от PCF 314, включающие в себя политику управления UP под влиянием приложения, полученную на этапах 1100 и 1102. На этапе 1110 SMF 310 выбирает режим SSC для PDU сеанса в соответствии с запросом сеанса, операторские политики, тип UE и другую необходимую информацию. Если запрос сеанса включает в себя идентификатор приложения и, если операторские политики указывают мобильность приложения (то есть, потенциальное перемещение приложения), то SMF 310 может выбрать SSC режим 2 для PDU сеанса. Если запрос сеанса не включает в себя идентификатор приложения и, если операторские политики указывают, что приложения, к которым UE может осуществлять доступ, имеют мобильность, SMF 310 может выбрать SSC режим 3 для PDU сеанса.

На этапе 1112 SMF 310 может выбрать сквозной UP тракт для PDU сеанса относительно операторских политик. Данный сквозной тракт в UP 326 может включать в себя местоположение приложения, выбранное для PDU сеанса.

На этапе 1114 SMF 310 запрашивает, чтобы AN 302 установил соединение N3. На возможном этапе 1116 AN 302 может выделять RAN ресурс для PDU сеанса.

На этапе 1118 AN 302 отвечает на SMF 310, указывая на завершение установки соединения N3.

На этапе 1120 SMF 310 устанавливает UP тракт. На этапе 1122 SMF 310 может сконфигурировать управление трафиком через интерфейс N6 на UPF 304 привязки UP 326. В некоторых вариантах осуществления этапы 1120 и 1122 могут быть объединены в один интегрированный этап конфигурации, на котором UP установку и конфигурацию управления трафиком выполняют вместе.

На этапе 1124 SMF 310 может уведомить функцию 324 приложения о выборе сквозного UP тракта посредством процедуры (часть 2) «уведомления о выборе (повторном выборе) UE» услуги NEF 314. Уведомление указывает местоположение PDU сеанса и местоположение приложения. В некоторых вариантах осуществления местоположение PDU сеанса может использоваться в качестве привязки IP-адреса UPF. В других вариантах осуществления IP-адрес UE может использоваться для определения местоположения PDU сеанса. Этап 1124 является возможным, если этап 1102 не выполняют или, если этап 1102 не указывает на необходимость UP (повторного) выбора после уведомления.

На этапе 1126 SMF 310 отправляет ответ сеанса в UE 102 через AMF 308. Способ, которым выполняется установление PDU сеанса, может варьироваться в разных реализациях. Специалистам в данной области будет понятно, что эта процедура может быть предметом стандартизации, и детали такой процедуры не обязательно относятся к настоящему изобретению.

На фиг. 11B иллюстрирует альтернативный вариант осуществления, включающий в себя дополнительный возможный этап 1128. На этапе 1128 SMF 310 уведомляет функцию 324 приложения о выборе сквозного UP тракта посредством процедуры (часть 2) «уведомление о выборе (повторном выборе) UP» услуги NEF 314. В уведомлении указывается местоположение PDU сеанса и местоположение приложения. В некоторых вариантах осуществления местоположение PDU сеанса является IP-адресом UPF привязки. В других вариантах осуществления IP-адрес UE может использоваться в качестве местоположения PDU сеанса. Этап 1128 является этапом предварительного уведомления, который является возможным, например, если этап 1102 отсутствует или, если этап 1102 не указывает на необходимость предварительного уведомления о выборе (повторном выборе) UP.

На фиг. 12A и 12B показаны схемы сигнализации, иллюстрирующие варианты осуществления процедуры повторного выбора UP под влиянием приложения. Эта процедура не изменяет IP-адрес UE и поэтому прозрачна для UE 102. Вариант осуществления по фиг. 12A и 12B предполагают, что UE 102 уже имеет установленный PDU сеанс через UP-A 326A.

Ссылаясь на фиг. 12A, на этапе 1200 функция 324 приложения подписывается на уведомление о выборе (повторном выборе) UP от сети для трафика приложения, ассоциированного с PDU сеансом, посредством процедуры (часть 1) «уведомление о выборе (повторном выборе) UP» услуги NEF. Этап 1200 является возможным, в зависимости от требований функции 324 приложения.

На этапе 1202 может продолжаться передача трафика между UE 102 и UP-A 326A.

На этапе 1204 функция 324 приложения может уведомить сеть о перемещении приложения с помощью процедуры «уведомление о местоположении (перемещении) приложения» услуги NEF 314. Этапы 1200 и 1204 могут быть независимыми друг от друга. Сетевое уведомление может включать в себя функцию 324 приложения, передающую сообщение уведомления одному или нескольким сетевым узлам, которые, в свою очередь, могут предоставлять уведомление функциям базовой сети, которые иначе не доступны для функции 324 приложения.

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

В процедуре 1206 SMF 310 модифицирует сквозной UP тракт, где требуется повторный выбор UP. На этапе 128 SMF 310 повторно выбирают UP-B 326B и управление трафиком (по интерфейсу N6) для PDU сеанса. Если SSC режим PDU сеанса равен 2, UP-B 326B выбирают для замены UP-A 326A. Если SSC режим PDU сеанса равен 3, SMF 310 вставляет UPF ответвления или UPF CL UL в UP тракт таким образом, что UP-A 326A и UP-B 326B являются двумя ветвями UP тракта.

На этапе 1210 SMF 310 уведомляет функцию 324 приложения о повторном выборе UP с помощью процедуры (часть 2) «уведомление о выборе (повторном выборе) UP» услуги NEF. Этап 1210 является возможным, если этап 1200 отсутствует или, если функция 324 приложения была уведомлена о выборе UP (повторном выборе) с тем же контентом.

На этапе 1212 SMF 310 модифицирует сквозной UP тракт согласно решению о повторном выборе UP. Это может быть выполнено с использованием любого из ряда различных способов. Особенности такого способа могут быть предметом стандартизации, например, как описано для этапов 8-11 в пункте 4.3.5.X.2 текущего стандарта. На этапе 1212 соединение N3 может быть модифицировано, разветвляющийся UPF или UL CL UPF (если таковая имеется) может быть сконфигурирован для направления трафика приложения к UP-B 326B и сконфигурирован интерфейс N6 (т.е. управления трафиком) на UPF привязки UP-B. Управление трафиком в UPF разветвления или UPF CL UL может основываться на IP-адресе назначения, номере порта назначения, IP-адресе источника или комбинации любого из них.

На этапе 1214 SMF 310 реконфигурирует управление трафиком в случаях, когда повторный выбор UP не требуется. SMF 310 реконфигурирует интерфейс N6 в UPF привязки UP-A 326A, чтобы направлять трафик приложения в новое местоположение приложения.

На этапе 1216 передача трафика между UE 102 и UP-B 326B может продолжаться.

На этапе 1218 SMF 310 высвобождает ресурсы PDU сеанса, относящиеся к UP-A 326A, если выполняется этап 1206 и SSC режим PDU сеанса равен 2.

Ссылаясь на фиг. 12B, этап 1200 альтернативного варианта осуществления по фиг. 12A, может выполняться после 1204. На этапе 1220 передача трафика между UE 102 и UP-A 326A может продолжаться.

На этапе 1222 функция 324 приложения уведомляет сеть о перемещении приложения с помощью процедуры «уведомление о местонахождении (перемещении) приложения» услуги NEF 314. Этапы 1200 и 1222 могут быть независимыми друг от друга.

На этапе 1224 функция 324 приложения подписывается на уведомление о выборе (повторном выборе) UP из сети для трафика приложения, ассоциированного с PDU сеансом, посредством процедуры (часть 1) «уведомление о выборе (повторном выборе) UP» услуги NEF 314. Этап 1224 является возможным, в зависимости от требований функции 324 приложения.

На этапе 1226 SMF 310 выполняет повторный выбор сквозного UP такта, включающий в себя, по меньшей мере, один из повторный выбор UP и повторный выбор местоположения приложения, в соответствии с перемещением приложения и локальной политикой.

На этапе 1228 SMF 310 повторно выбирает сквозной UP тракт для PDU сеанса. Если требуется повторный выбор UP, SMF 310 повторно выбирает UP-B 326B для PDU сеанса. Если SSC режим PDU сеанса равен 2, UP-B 326B выбирается для замены UP-A 326A. Если SSC режим PDU сеанса равен 3, SMF 310 вставляет UPF ответвления или UPF CL UL в UP тракт таким образом, что UP-A 326A и UP-B 326B являются двумя ветвями UP тракта.

На этапе 1230 SMF 310 уведомляет функцию 324 приложения о повторном выборе сквозного UP тракта посредством процедуры (часть 2) «уведомление о выборе (повторном выборе) UP» услуги NEF 314. В уведомлении указывают привязку местоположения UPF и нового местоположения приложения. Этот этап является предварительным уведомлением. Возможно, если этап 1224 отсутствует или, если этап 1224 не указывает на необходимость предварительного (повторного) выбора предварительного уведомления.

На этапе 1232 SMF 310 изменяет сквозной UP тракт согласно решению этапа 1228. В случае, когда UP-B 326B выбран для PDU сеанса, SMF 310 модифицирует сквозной UP тракт, как описано на этапах 8 - 11 в пункте 4.3.5.X.2 текущего стандарта. На этапе 1232 соединение N3 модифицируют, ответвление UPF или UL CL UPF (если таковая имеется) выполнено с возможностью управлять трафиком приложения в интерфейс UP-B, 326B и сконфигурирован интерфейс N6 (т.е. управление трафиком) на UPF привязки UP-B 326B. Управление трафиком в UPF ответвлении или UPF CL UL может основываться на IP-адресе назначения, номере порта назначения, IP-адресе источника или комбинации любого из них.

В случае, когда повторный выбор UP не требуется, на этапе 1234 SMF 310 реконфигурирует интерфейс N6 в UPF привязки UP-A 326A, чтобы направлять трафик приложения в новое местоположение приложения.

На этапе 1236 SMF 310 уведомляет функцию 324 приложения о повторном выборе сквозного UP тракта посредством процедуры (часть 2) «уведомление о выборе (повторном выборе) UP» услуги NEF 314. Этап 1236 является этапом после уведомления. Это необязательно, если этап 1224 отсутствует или, если этап 1224 не указывает на необходимость UP (повторного) выбора после уведомления.

На этапе 1216 передача трафика между UE 102 и UP-B 326B может продолжаться.

На этапе 1240 SMF 310 высвобождает ресурсы PDU сеанса, ассоциированные с UP-A 326A, если SSC режим PDU сеанса равен 2 и UP-B выбран для PDU сеанса на этапе 1228.

Фиг. 13 является схемой сигнализации, иллюстрирующей вариант осуществления процедуры услуги уведомления о местоположении (перемещении) приложения.

На этапе 1300 NEF 310 принимает запрос уведомления о местоположении (перемещении) приложения (идентификатор приложения, информация о местоположении приложения, условие временной достоверности, условие пространственной достоверности, фильтр трафика, информация о запрашивающем) из функции 324 приложения. Информация местоположения приложения указывает (новое) местоположение (местоположения) приложения и статус (нового) местоположения (местоположений) приложения. Местоположение (местоположения) приложения указывают с использованием IP-адреса. Условие временной действительности указывает, когда будет предоставлено указанное уведомление о местоположении (перемещении) приложения. Отсутствие условия временной действительности подразумевает, что местоположение (перемещение) приложение предоставлено немедленно. Условие пространственной достоверности указывает, что местоположение (перемещение) приложения применяется только к трафику, ассоциированному с UE, расположенными в указанных местоположениях. Отсутствие условия пространственной достоверности подразумевает, что заявленное местоположение (перемещение) приложения применяется без учета местоположения UE.

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

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

NEF 314 уведомляет о местоположении (перемещении) приложения для выбранной функции CP, то есть, SMF 310 или PCF 314. Уведомление включает в себя идентификатор транзакции услуги уведомления о местонахождении (перемещении) приложения, идентификатор приложения, (новое) местоположение (местоположения) приложения, идентификаторы привязки UPFs, подходящих для выбора для каждого (нового) местоположения (местоположений) приложения, и условия временной и пространственной достоверности, фильтр трафика. В зависимости от характера информации о местоположении в условии пространственной достоверности, NEF 314 может потребоваться преобразовать информацию о местоположении в информацию, понятную для функций CP. Фильтр трафика может быть преобразованным фильтром трафика, описанным с использованием идентификаторов PDU сеансов. NEF 314 определяет привязки UPFs, подходящие для выбора, в соответствии с возможностями управления трафиком между UPF и заявленными местоположениями приложений, которые предоставляют плоскостью управления.

В процедуре 1302 уведомление относится к случаю, когда соответствующий трафик относится только к текущим PDU сеансам. На этапе 1304, NEF 314 идентифицирует PDU сеансы, ассоциированные с соответствующим трафиком, и SMF 310 управляет PDU сеансами и отправляет уведомление в SMF 310. NEF 314 идентифицирует SMF 310, взаимодействуя с UDM 320. На этапе 1306 SMF подтверждает прием уведомления в NEF.

В процедуре 1308 уведомление может указывать, что соответствующий трафик принадлежит будущим PDU сеансам (а также, возможно, текущим PDU сеансам). На этапе 1310 NEF 314 идентифицирует PCF 314, который отвечает за политику оператора для PDU сеансов, и отправляет уведомление в PCF 314. NEF 314 идентифицирует PCF 314 путем взаимодействия, по меньшей мере, с одним из NRF 318 и UDM. 320. На этапе 1312 PCF 314 подтверждает прием уведомления в NEF 314. На этапе 1314 PCF 314 генерирует или обновляет политики управления UP в соответствии с уведомлением. Если соответствующий трафик принадлежит текущим PDU сеансам, то на этапе 1314 PCF 314 идентифицирует обслуживающую SMF 310 трафика и уведомляет SMF 310 об изменении политики. На этапе 1318 SMF 310 получает обновление политики от PCF 314.

На этапе 1320 NEF 314 отправляет сообщение ответа на запрос (код результата) уведомления о местоположении (перемещении) приложения в функцию 324 приложения. Код результата указывает подтверждение запроса или его отклонение.

Фиг. 14 является схемой сигнализации, иллюстрирующей вариант осуществления услуги подписки на уведомления о выборе (повторном выборе) UP.

На этапе 1402 NEF 314 принимает сообщение подписки уведомления о выборе (повторном выборе) UP ([идентификатор транзакции] или [идентификатор приложения, условие временной достоверности, условие пространственной достоверности, фильтр трафика], тип уведомления, информация запрашивающей стороны)) из функции 324 приложения.

Альтернатива A [Идентификатор транзакции]: запрос на подписку соответствует существующей транзакции услуги уведомления о местоположении (перемещении) приложения. Идентификатор транзакции существующей транзакции услуги уведомлений о местоположении (перемещении) приложения подразумевает, что запрос подписки применяют к любому выбору (повторному выбору) UP, на который влияет существующая транзакция услуги уведомления о местоположении (перемещении) приложения. NEF 314 может выполнять упрощенную аутентификацию и проверку достоверности путем проверки идентификатора транзакции.

Альтернатива B [идентификатор приложения, условие временной достоверности, условие пространственной достоверности, фильтр трафика, информация запрашивающей стороны]: запрос подписки не зависит от существующих транзакций услуги уведомления о местоположении (перемещении) приложения. Условие временной действительности указывает, когда подписка может вступить в силу. Отсутствие условия временной действительности подразумевает, что подписка вступает в силу немедленно. Условие пространственной достоверности указывает, что подписка действительна только для трафика UEs, расположенных в указанных местоположениях. Отсутствие условия пространственной достоверности подразумевает, что подписки вступают в силу без учета местоположения UE. Фильтр трафика указывает трафик, к которому может применяться подписка, который может принадлежать текущим PDU сеансам или будущим PDU сеансам. Отсутствие фильтра трафика означает, что подписка распространяется на весь трафик, ассоциированный с приложением. Фильтр трафика может явно указывать, включает ли в себя трафик, по меньшей мере, один из текущий трафик и будущий трафик. Фильтр трафика может быть описан с использованием IP-адреса, ассоциированного с трафиком. Это также может быть описано с использованием идентификатора UE, который распознается как функцией приложения, так и сетью. Тип уведомления указывает либо предварительное уведомление, либо пост-уведомление, либо запрашиваются как предварительное уведомление, так и пост-уведомление. Предварительное уведомление подразумевает, что уведомление должно быть отправлено до того, как будет сконфигурирован сквозной UP тракт; пост-уведомление подразумевает, что уведомление должно быть отправлено после конфигурации сквозного тракта. Информация запрашивающей стороны может включать в себя: идентификатор запрашивающей стороны, IP-адрес запрашивающей стороны и номер порта запрашивающей стороны.

NEF 314 запрашивает выбранную функцию CP, то есть, SMF 310 или PCF 314, установить уведомление о выборе (повторном выборе) UP. Запрос может включать в себя идентификатор транзакции услуги подписки уведомления о выборе (повторном выборе) UP, идентификатор NEF и информацию о подписке в сообщении запроса, за исключением информации запрашивающей стороны. В зависимости от характера информации о местоположении в условии пространственной достоверности, NEF 314 может потребоваться преобразовать информацию о местоположении в информацию, понятную для функций CP. Фильтр трафика может быть преобразованным фильтром трафика, описанным с использованием идентификаторов PDU сеансов.

В процедуре 1404 обрабатываемый трафик принадлежит только текущим PDU сеансам. На этапе 1406 NEF 314 идентифицирует PDU сеансы, с которыми ассоциирован обрабатываемый трафик, и SMF 310 управляет PDU сеансами и отправляет запрос на идентифицированную SMF 310. На этапе 1408 SMF 310 направляет сообщение ответа в NEF 314, указывая принятие запроса. NEF 314 идентифицирует SMF 310 путем взаимодействия с UDM 320.

В процедуре 1410 обрабатываемый трафик принадлежит будущим PDU сеансам (а также текущим PDU сеансам). На этапе 1412 NEF 314 идентифицирует PCF 314, которая отвечает за политику оператора для PDU сеансов, с которой ассоциирован обрабатываемый трафик, и отправляет запрос на идентифицированную PCF 314. На этапе 1414 PCF 314 направляет сообщение ответа в NEF 314, что свидетельствует о принятии запроса. NEF 314 идентифицирует PCF 314 путем взаимодействия, по меньшей мере, с одним из NRF 318 и UDM 320. На этапе 1416 PCF 314 генерирует или обновляет политики управления UP в соответствии с запросом. Если обрабатываемый трафик принадлежит текущим PDU сеансам, на этапе 1418 PCF 314 идентифицирует обслуживающую SMF 310 трафика и уведомляет SMF 310 об изменении политики. На этапе 1420 SMF 310 получает обновление политики от PCF 314.

На этапе 1422 NEF 314 отправляет сообщение ответа подписки (код результата) выбора (повторного выбора) UP в функцию 324 приложения. Код результата указывает принятие запроса или его отклонение.

После выполнения сквозного выбора (повторного выбора) UP) для обрабатываемого трафика на этапе 1424 SMF 310 уведомляет NEF 314 о выборе (повторном выборе) UP. Уведомление может включать в себя такую информацию, как идентификатор транзакции услуги подписки на уведомления о выборе (повторном выборе) UP, тип уведомления, местоположение PDU сеанса, местоположение UPF привязки и местоположение приложения. Местоположение PDU сеанса в некоторых вариантах осуществления может быть одним из адресом UPF привязки или адресом UE для PDU сеанса. В некоторых вариантах осуществления эти адреса являются IP-адресами. Информация о приложении может иметь вид IP-адреса или другого такого идентификатора.

На этапе 1426 NEF 314 отправляет информацию выбора (повторного выбора) UP в функцию 324 приложения, используя IP-адрес запрашивающей стороны и номер порта запрашивающей стороны.

На этапе 1428 функция 324 приложения отвечает в NEF 314, чтобы подтвердить доставку уведомления. Ответ указывает, должна ли сеть продолжать конфигурацию сквозного тракта, если типом уведомления является предварительное уведомление.

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

На этапе 1430 NEF 314 отвечает SMF 310, чтобы подтвердить доставку уведомления. Ответ включает в себя информацию, принятую от функции 324 приложения на этапе 1428.

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

Информация для идентификации UE 102 может быть либо фиксированными идентификаторами, либо динамическими идентификаторами.

Фиксированные идентификаторы SUPI, PEI, описаны в п. 5.9 TS 23.501: поскольку граничные вычислительные приложения могут находиться в недостоверных доменах, эти идентификаторы не должны раскрываться сторонним граничным вычислительным приложениям.

MSISDN: Может использоваться для сторонних граничных вычислений.

Внешний идентификатор: может быть назначен либо операторами, либо граничным вычислительным приложением.

Динамические идентификаторы.

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

IP-адрес: назначается во время процедуры установления сеанса.

Вышеприведенные два идентификатора могут использоваться для идентификации UE 102, имеющего активные PDU сеансы. Однако эти идентификаторы могут быть изменены из-за мобильности UE или повторного выбора UPF. Кроме того, если PDU сеанс не относится к типу IP, то IP-адрес неприменим. Таким образом, эти динамические идентификаторы могут не подходить для приложений граничных вычислений.

Предложение 1: для идентификации UE, трафик которого должен маршрутизироваться, используют либо внешний идентификатор, либо MSISDN.

2 идентификатора для группы UEs.

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

Географические области: покрытие PLMN может быть разделено на зоны, каждая зона имеет идентификатор зоны (ZID). Оператор может информировать граничное вычислительное приложение о отображении между географическим местоположением и ZID. Нет необходимости стандартизировать ZID.

Префикс IP: возможно, что группе UEs для данного приложения может быть назначен диапазон IP-адресов. Диапазон IP-адресов может быть зарезервирован для указания группы UEs. Однако это решение неприменимо к типу трафика не-IP.

Доменное сетевое имя (DNN): Каждое граничное вычислительное приложение может иметь уникальное имя, распознаваемое CN. DNN может указывать UE, кто может получить доступ к DNN.

Идентификатор приложения (AID): если DN предоставляет несколько приложений, каждое приложение может иметь идентификатор приложения. Идентификатор приложения может быть представлен портом сервера приложений для IP-трафика.

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

Предложение 2: Для идентификации группы UEs могут использовать комбинацию DNN, AID и ZID.

3. Информация о том, куда направлять трафик: может быть (или оба) из DNN локальной сети передачи данных и IP-адреса сервера приложений.

Предложение 3: Для указания пункта назначения маршрутизации могут использовать либо DNN локальной сети передачи данных, либо IP-адрес сервера приложений.

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

В качестве альтернативы, могут использоваться IP-адреса сервера приложений. Объекты управления сетью могут конфигурировать CP о возможностях транспортного канала связи между UPF и серверами приложений. Необходимо дополнительное пояснение этого вопроса.

Предложение 4: Для указания потенциальных местоположений приложения для маршрутизации трафика могут использовать либо DNN локальных сетей передачи данных, либо IP-адреса серверов приложений.

5. Информация для идентификации трафика, подлежащего маршрутизации

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

DN предоставляет 1 приложение: для идентификации PDU сеанса, если DN предоставляет только одно приложение, DNN может использоваться.

DN предоставляет несколько приложений: каждое приложение должно иметь идентификатор приложения (AID). Для IP-трафика AID может быть номером порта сервера приложений.

Предложение 5: DNN может использоваться для идентификации PDU сеансов, если DN предоставляет одно граничное вычислительное приложение. Если DN предоставляет несколько приложений, для идентификации PDU сеансов используют каждый DNN и AID.

Запрос функции приложения может быть направлен в SMF другой функцией управления, такой как NEF или PCF.

а. В EPC интерфейс Rx между PCRF и функцией приложения для поддержки сторонних приложений используют:

Примеры: IMS и функцию приложения общественной безопасности, SCEF

Безопасность: эти приложения считаются расположенными в доверенном домене 3GPP. В данном аспекте безопасность обеспечена.

Информация, полученная через интерфейс Rx, предназначена для PCRF. Это означает, что PCRF обрабатывает принятую информацию для принятия решения относительно политики.

b. Граничные вычислительные приложения в 5G CN

Безопасность: функция управления приложением граничных вычислений может находиться в не доверенных доменах. Таким образом, запрос от функции управления приложением должен быть аутентифицирован и авторизован. Текущие согласованные функции NEF включают в себя функции аутентификации/авторизации, но не PCF.

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

Предложение 6: NEF используется в качестве интерфейса между функцией управления приложением и функциями CN CP.

Функция приложения может отправлять запросы через NEF, чтобы влиять на решения по маршрутизации SMF для трафика PDU сеанса. Это может повлиять на выбор UPF и разрешить маршрутизацию пользовательского трафика на локальный доступ к сети передачи данных.

Такие запросы могут содержать по меньшей мере:

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

В некоторых реализациях номер порта сервера приложений может использоваться в качестве AID. Информация о том, куда направить трафик. Для указания места назначения маршрутизации можно использовать либо DNN локальной сети передачи данных, либо IP-адрес сервера приложений. Потенциальные местоположения приложения, к которым должна применяться маршрутизация трафика. Либо DNN локальных сетей передачи данных, либо IP-адреса серверов приложений могут использоваться для указания потенциальных местоположений приложения для маршрутизации трафика. Трафик может быть идентифицирован DNN, когда функция приложения является единственной функцией приложения, размещенной в локальной DN, или, если нет никакой возможности для путаницы; в противном случае, для идентификации трафика приложения может использоваться комбинация DNN и идентификатора приложения или информации о фильтрации трафика.

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

- в некоторых реализациях запросы могут включать в себя информацию о том, куда направлять трафик, такой как DNN (например, если весь трафик PDU сеанса направляют в функцию приложения) или IP-адрес функции приложения.

- в некоторых реализациях запросы могут включать в себя потенциальные местоположения приложения, к которым должна применяться маршрутизация трафика. Потенциальные местоположения AF могут указываться с использованием IP-адреса AF обработки трафика, который NEF (или AF, если ему доверяет оператор, как описано в пункте 6.2.X), сопоставляется с конкретными привязками PDU сеанса к локальной DN.

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

В некоторых реализациях запросы могут включать в себя информацию об UE, трафик которых должен маршрутизироваться. Отдельные UEs могут быть идентифицированы с использованием внешнего идентификатора или MSISDN. Группы UEs могут быть идентифицированы посредством DNN, с которым они имеют активный PDU сеанс, возможно, вместе с идентификатором приложения или информацией о фильтрации трафика. Кроме того, чтобы ограничить группу UEs в определенной географической области, могут быть использованы идентификаторы зоны.

Примечание 3. Идентификатор зоны может быть сопоставлен с географической областью. Отображение сконфигурировано как в NEF, так и в AF. Для идентификации отдельных UEs применяют внешний идентификатор или MSISDN. DNN, AID (идентификатор приложения) и ZID (идентификатор зоны) или их комбинация могут использоваться для идентификации группы UEs.

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

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

SMF 310 может, основываясь на локальных политиках, принимать во внимание следующую информацию:

Выбор (повторный выбор) UPF для PDU сеансов.

Активировать механизмы многоадресности трафика или применения классификатора UL (UL CL). Такие механизмы определены в подпункте 5.3.5. Это может включать в себя предоставление UPF правил пересылки трафика (например, вывод).

Информировать функцию приложения о (повторном) выборе UP тракта.

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

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

За Против Требуется сопоставление Влияние среды приложения на архитектурное проектирование минимизировано.
Базовая сеть является независимым приложением. Любое изменение в среде приложения маскируют обработкой NF, которая выполняет обработку/сопоставление.
Обработка NF может быть выполнена с возможностью поддерживать неограниченное число типов сред приложения, не оказывая влияния на системную архитектуру. Таким образом, архитектура имеет возможность расширения. Требуется обработка информации NF между AF и функциями базовой сети.
Увеличивает сложность. Сопоставление не требуется AF генерирует информацию, доступную для функций базовой сети
Упрощенная архитектура. Среда приложения оказывает существенное влияние на архитектурное проектирование
Базовая сеть расширена до домена приложения. Необходима дополнительная работа по стандартизации расширения, например, признака местоположения приложения, взаимосвязи между UPF и местоположением приложения.
При изменении среды приложения, необходимо обновить 3GPP стандарты. Или стандарты должны охватывать все возможные среды приложения.

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

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

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

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

Соответственно, в соответствии с некоторыми вариантами осуществления, условие пространственной достоверности содержится в информации, предоставляемой AF для CN, которая не зависит от условий, влияющих на выбор (повторный) UP.

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

AF может отправлять запросы для влияния на решения SMF маршрутизации для трафика одного или более PDU сеансов. В некоторых реализациях AF отправляет запросы в PCF, чтобы повлиять на эти решения о маршрутизации SMF. Это может повлиять на процесс выбора UPF и позволить маршрутизацию пользовательского трафика в локальный доступ к сети передачи данных (DN). Специалистам в данной области техники будет понятно, что ссылка в этом документе на маршрутизацию трафика при локальном доступе к DN может быть понята, как включающая в себя передачу трафика на локальную точку доступа, которая может предоставить доступ к рассматриваемому DN. Эта локальная точка доступа может быть локальной для CN (или сегмента CN) или локальной для DN. Топологически локальный доступ служит связью с DN.

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

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

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

В сценариях, в которых AF взаимодействует с PCF через NEF, информация, предоставляемая AF, и информация, используемая в базовой сети 5G (5GC), может иметь другой формат или различаться по сути (например, содержать различные элементы информации). В некоторых реализациях NEF может быть выполнена с возможностью выполнять преобразования/сопоставления информации. В случае, когда AF взаимодействует напрямую с PCF, AF может предоставлять информацию, используемую 5GC, без необходимости преобразования информации.

Запросы на влияние принятия решения по маршрутизации SMF для трафика PDU сеанса могут отправлены посредством AF. Функция приложения может отправлять сообщение уведомления о местоположении приложения в PCF. Сообщение может содержать как минимум:

информацию для определения трафика для маршрутизации. Трафик может быть

идентифицирован, например, посредством DNN и идентификатора приложения или информации о фильтрации трафика. В некоторых реализациях трафик может быть идентифицирован в запросе AN посредством DNN. DNN может использоваться для идентификации трафика PDU сеанса и идентификатора приложения, чтобы указывать конкретную услугу PDU сеанса. В случае IP трафика, в некоторых вариантах осуществления может содержаться информация фильтрации трафика (например, IP 5- кортеж, который может содержать адреса источника и назначения, а также номера портов в каждом из источника и назначения, а также используемый протокол), В некоторых реализациях информация разделения (например, S-NSSAI) может быть частью информации фильтрации трафика или отдельным элементом в запросе AN.

Информацию о направлении маршрутизации трафика. Если AF взаимодействует напрямую с PCF, могут указывать профиль маршрутизации, включающий в себя список динамических идентификаторов доступа к сети (DNAI), каждый из которых может содержать локальный доступ к DN, и N6 параметры маршрутизации трафика, ассоциированные с каждым DNAI. Если AF взаимодействует с PCF через NEF, могут указывать, по меньшей мере, один из DNN и адрес приложения в своих сообщениях. В варианте осуществления N6 параметры маршрутизации трафика могут быть сконфигурированы в UPF для поддержки механизма управления трафиком или реализации в локальной DN.

Потенциальные местоположения AF, которые могут использоваться для определения, где должна применяться маршрутизация трафика. Потенциальные местоположения AF могут, например, использоваться для выбора UPF. Если AF взаимодействует напрямую с PCF, информация, ассоциированная с потенциальными местоположениями AF (в абсолютном или топологическом выражении), может быть предоставлена посредством DNAI в профиле маршрутизации, описанном выше. Если AF взаимодействует с PCF через NEF, информация о потенциальных местоположениях AF может предоставляться адресом (адресами) хоста приложения.

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

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

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

В некоторых реализациях AF может взаимодействовать с PCF через NEF. В этом случае, NEF может быть выполнена с возможностью преобразовывать «информацию о потенциальных местоположениях приложений, куда должна применяться маршрутизация трафика» и «информацию направления маршрутизации трафика» в сообщении, в профиль маршрутизации и предоставляет этот профиль маршрутизации, или в указании профиля маршрутизации в PCF. Если профили маршрутизации можно упорядочить и поместить в индексированный список, необходимо указать только индекс.

В некоторых реализациях PCF на основании, по меньшей мере, одной из принятой информации (например, принятой от AF или NEF) и, возможно, предварительно определенной политики оператора и входных данных от других объектов (например, пользовательской подписки), квоты пользователя, текущей RAT пользователя, состояния загрузки сети, времени суток, местоположения UE, APN…, которые могут быть приняты от других сетевых объектов, таких как CSM объект, HSS, функции организации трафика или любого количества средств контроля и управления плоскости объекта) могут авторизовать запрос, принятый от AF, и, в соответствии с запросом, определить политику управления трафиком. Политика управления трафиком может указывать подходящие профили управления трафиком из набора профилей. Каждый из профилей может указывать UPF, обеспечивающий управление трафиком и N6 параметры маршрутизации трафика. Это может неявно указывать уникальный DNAI, который будет сконфигурирован в UPF.

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

выбора (повторного выбора) UPF для PDU сеансов. SMF может выполнять выбор профиля управления трафиком при (повторного) выборе UP тракта. Поскольку профиль управления трафиком может неявно отображаться на уникальный DNAI (через N6 параметры маршрутизации трафика в профиле), выбор профиля управления трафиком может подразумевать отображение местоположения UE (TAI/ID соты) на DNAI в дополнение к выбору UPF;

активировать механизмы многоадресности трафика или применения классификатора UL (UL CL). Это может включать в себя предоставление UPF правил пересылки трафика (например, вывода); и

конфигурировать N6 маршрутизацию трафика в UPF привязки в соответствии с выбранным профилем управления трафиком.

Со ссылкой на фиг. 15, в варианте осуществления процедуры уведомления о местоположении (перемещении) приложения, информация о соединении (включавшая в себя качество соединений, например, количество переходов, производительность, например, задержка, дрожание задержки, пропускная способность или атрибуты, например поддерживаемые протоколы и параметры протокола, включающие в себя заголовки протокола) между DNAI (например, DNAI-1 или DNAI-2) и отдельными хостами приложений могут быть сконфигурированы в NEF 314 посредством объекта управления плоскостью, такой как сетевой менеджер, менеджер сегмента или менеджер услуг. Альтернативно, информация о соединении может предоставляться посредством AF 324 в NEF 314. Информация о соединении для DNAI с хостом приложения в некоторых вариантах осуществления также может упоминаться как требования к маршрутизации или профиль маршрутизации. В других вариантах осуществления эта информация о соединении может быть частью профиля маршрутизации.

Если AF 324 не находится в доверенном домене (например, не в CN или в сети, которой доверяет CN), AF 324 может взаимодействовать с PCF 316 через NEF 314. В этом случае, AF 324 может предоставить потенциальное местоположение хоста приложения (или набор местоположений, ассоциированных с приложением) для NEF 314 в сообщении, таком как сообщение уведомления местоположения приложения. NEF 314 может выбирать подходящие DNAIs, которые будут ассоциированы с приложением, в соответствии с информацией и информацией о соединении, описанными выше. В некоторых реализациях NEF 314 также может выполнять выбор в соответствии с требованиями QoS, ассоциированными с приложением, к сквозному соединению (либо на постоянной основе, либо на основе конкретного сеанса). Требования QoS могут быть предоставлены AF 324 одновременно с другими данными, такими как сообщение уведомления о местоположении приложения, или они могут переданы отдельно. NEF 314 может указывать выбранные DNAI (s) и соответствующую информацию о соединении (выбранные части или полностью) для PCF 316. В некоторых реализациях информация о соединении (или профиль маршрутизации, или требование маршрутизации), указанная с помощью NEF 314, может быть сконфигурирована в PCF 316 с помощью функции плоскости управления, такой как сетевой менеджер, менеджер сегмента или менеджер услуги. В таком случае, NEF может потребоваться только для указания идентификатора соединения (или идентификатора требования маршрутизации, или идентификатора профиля маршрутизации) для PCF. В соответствии с предоставленным идентификатором соединения PCF 316 может идентифицировать детали из своей локальной конфигурации. В некоторых реализациях PCF 316 может получать информацию о соединении (или профиль маршрутизации, или профиль требования маршрутизации) заранее из NEF. В некоторых реализациях NEF 314 получает информацию о соединении (или профиль маршрутизации, или профиль требования маршрутизации) от AF 324.

Когда функция плоскости управления действует для конфигурирования функции CP, например, изменение конфигурации, которое должно применяться к NEF 314, конфигурация может быть изменена после приема запроса, переданного посредством AF 324. В некоторых реализациях функция управления плоскостью может использовать альтернативный тракт для конфигурации CP функции. В тех случаях, когда условно функция плоскости управления конфигурирует CP функцию через систему «управление элементами» в плоскости управления, в вариантах осуществления настоящего изобретения информация о конфигурации может быть отправлена в CP функцию через NEF 314. В таком сценарии функция управления плоскостью может рассматриваться как действующая как AF, которая отправляет сообщения в NEF. Это позволяет NEF 314 пересылать информацию о конфигурации или инструкции без использования интерфейса системы управления элементами.

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

Поскольку ассоциация между UPFs 304 и DNAIs может быть предварительно определена, когда NEF 314 передает указание подходящих DNAIs в PCF 316, это неявно указывает подходящие UPFs 304. В некоторых сценариях выбор DNAI может привести к неявному выбору поднабора доступных UPFs 304.

Профиль управления трафиком может быть определен между DNAI и каждой из UPFs 304, ассоциированной с ним. Этот профиль управления трафиком может использоваться для описания поведения управления трафиком (включающий в себя, по меньшей мере, одну из характеристик управления трафиком, таких как задержка, пропускная способность, максимально разрешенные PDU сеансы и т.д., и

параметры маршрутизации, включающие в себя заголовки протокола) трафика UPF в направлении DNAI. Профиль может быть сконфигурирован в PCF 306 объектом плоскости управления, таким как менеджер сети, менеджер сегмента или менеджер услуг. В некоторых вариантах осуществления профиль управления трафиком может быть сконфигурирован в UDM 320 (унифицированное управление данными) или DSF (функция хранения данных, например, UDR 322), и PCF 316 должна получить, указав DNAI и UPF 304 для UDM 320 или DSF (например, UDR 322).

В соответствии с профилями маршрутизации PCF 316 может выбирать профили управления трафиком (например, те, которые обеспечивают соответствие производительности QoS или требуемую поддержку протокола). Выбранные профили (иногда упоминаемые как подходящие профили управления трафиком или выбранные подходящие профили управления трафиком) или указание выбранных профилей могут передаваться PCF в SMF. SMF может применять или начинать применять принятую политику управления трафиком во время установления сеанса или модификации сеанса (или в ответ на установление сеанса или изменение сеанса). Если профили управления трафиком также сконфигурированы в SMF, PCF в некоторых вариантах осуществления должен будет только указывать идентификаторы профиля управления трафиком. Если профили управления трафиком не сконфигурированы в SMF, то PCF 316 может потребоваться предоставить содержимое профилей управления трафиком в SMF. В некоторых вариантах осуществления SMF 310 указывается идентификаторами профиля управления трафиком, передаваемыми PCF 316, и указанная SMF 310 может получать контент профиля управления трафиком из сторонней CP функции, такой как UDM 320 или DSF (например, UDR 322).

AF 324 может отправлять запросы на подписку на уведомление о выборе (повторном) UP тракта из SMF. Подписка может быть, по меньшей мере, одним из ранних уведомлений и поздних уведомлений. В случае подписки на раннее уведомление SMF 310 отправляет уведомление перед выполнением выбора (повторного) UP тракта. В случае подписки на позднее уведомление SMF 310 отправляет уведомление после завершения (повторного) выбора UP тракта.

AF 324 запрашивает подписку на уведомление о выборе (повторном) UP тракта из SMF, что может содержать, по меньшей мере:

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

относящаяся к подписке. В реализации трафик может быть идентифицирован DNN, если AF является единственным AF, размещенной в локальной DN; в противном случае, комбинация DNN и информации о фильтрации трафика может использоваться для идентификации трафика приложения. В реализации DNN может идентифицировать трафик на основании, по меньшей мере, одного из: запроса AF, идентификатора приложения и информации о фильтрации трафика. В одном примере DNN может использоваться для идентификации трафика PDU сеанса, и идентификатор приложения может использоваться для указания конкретной услуги PDU сеанса. В случае IP-трафика в некоторых вариантах осуществления информация о фильтрации трафика может быть вставлена (например, IP 5- кортеж, как описано выше).

информация о UE, трафик которых связан с подпиской. Это может соответствовать

отдельным UEs, всем UEs, группам UEs, идентифицированным с использованием внешнего идентификатора, идентификатора внешней группы, MSISDN, IP-адреса или префикса IP-адреса.

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

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

В некоторых вариантах осуществления PCF 316 на основании информации, принятой от AF (или NEF), политики оператора и входных данных от других объектов (например, подписки пользователя, квоты пользователя, текущей RAT пользователя, состояния загрузки сети, времени суток, местоположение UE, APN…), может авторизовать запрос, принятый от AF, и либо предоставить, либо выбрать политику уведомления о событии выбора (повторного) UP тракта.

В некоторых вариантах осуществления PCF 316 может предоставлять SMF 310 политику уведомления о событии выбора (повторного) UP тракта. SMF 310 может, основываясь на локальной политике, принимать эту информацию во внимание, чтобы информировать AF 324 о (повторном) выборе UP тракта (изменение управления трафиком).

Подписка на уведомления о выборе (повторном выборе) UP может происходить в цепочке, например, когда AF подписывается на NEF, который, в свою очередь, подписывается, по меньшей мере, на одну из SMF и PCF. CP функция в середине такой цепочки подписки (например, в вышеприведенном примере, NEF) будет передавать уведомление (в некоторых примерах это может быть ретрансляция принятого уведомления) по цепочке. CP функция может поддерживать свою роль в цепочке подписки, чтобы поддерживать соответствие между контекстом подписки с предшествующей CP функцией и следующей CP функции в цепочке. Перед передачей уведомления CP функция может обработать уведомление и может улучшить или обогатить информацию в уведомлении, уменьшить или упростить информацию в уведомлении или преобразовать информацию в уведомлении.

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

В некоторых реализациях идентификатор функции абонентской сети может указывать сетевой адрес, связанный с функцией абонентской сети. В некоторых реализациях SMF взаимодействует с функцией абонентской сети, используя идентификатор функции абонентской сети напрямую (например, посредством IP-маршрутизации в случае, если идентификатор является IP-адресом). В некоторых реализациях SMF отображает идентификатор функции абонентской сети на некоторую информацию о маршрутизации (например, информацию о туннелировании) и использует эту информацию для взаимодействия с AF. В некоторых реализациях SMF поддерживает такое отображение, например, посредством конфигурации из функций плоскости управления; в некоторых вариантах осуществления SMF получает отображение путем взаимодействия с третьей СР функцией, например, NRF или UDM, посредством предоставления идентификатора функции абонентской сети третьей CP функции и получения отображения в ответ.

В случае, когда AF 324 находится в доверительном домене (то есть, когда AF взаимодействует непосредственно с PCF):

в некоторых вариантах осуществления функция абонентской сети, в которую SMF 310 отправляет уведомление, является AF 324, и уведомление содержит идентификатор выбранной UPF привязки PDU сеанса. В некоторых вариантах осуществления идентификатор UPF указывает адрес UPF 304.

В некоторых вариантах осуществления функция абонентской сети, на которую SMF 310 отправляет уведомление, является PCF 316, и уведомление указывает выбранный профиль управления трафиком (например, идентификатором профиля управления трафиком). PCF 316 затем идентифицирует соответствующий DNAI и указывает DNAI (вместе с идентификатором подписки в сообщении запроса уведомления о выборе (повторном выборе) UP, PCF 316 выполняет преобразование информации, подписчику AF 324. В некоторых вариантах осуществления DNAI указывают в формате сетевого адреса.

В случае, когда AF 324 не находится в доверительном домене (то есть, когда AF взаимодействует с PCF через NEF):

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

В некоторых вариантах осуществления функция абонентской сети, на которую SMF отправляет уведомление, является PCF, и уведомление указывает выбранный профиль управления трафиком (например, идентификатором профиля управления трафиком). Затем PCF может идентифицировать соответствующий DNAI и предоставить указание DNAI (вместе с идентификатором подписки) подписчику NEF, который затем может определить адрес подлежащего DNAI и хоста соответствующего приложения и уведомить подписчика AF об информации (вместе с идентификатором подписки в сообщении запроса уведомления о выборе (повторном) UP, принятом от AF), PCF и в некоторых вариантах осуществления NEF, может рассматриваться как выполняющая, по меньшей мере, одно из преобразование информации и обогащение информации.

AF может отправлять вышеупомянутые два типа запросов независимо. В некоторых реализациях предполагают, что AF, направляющая такие запросы, принадлежит PLMN, обслуживающей UE. AF может направлять запросы от имени других AF, не принадлежащих PLMN, обслуживающей UE. Базовая сеть 5G сети может использовать функцию доступа к сети для раскрытия сетевой информации и возможностей, позволяющих AF взаимодействовать с CNFs с целью влияния на управление UP трактом и маршрутизацию трафика, либо напрямую, либо через NEF.

В случае, когда AF взаимодействует с CNFs через NEF, информация, предоставляемая AF, и информация, используемая в CN, могут быть по-разному отформатированы или организованы. В таком случае, NEF может быть выполнена с возможностью выполнять обработку/отображение информации.

В случае AF, взаимодействующей с CNF напрямую, AF может предоставлять информацию, используемую CNF, без обработки/отображения.

Информация, предоставляемая AF, преобразуется в политики управления UP под влиянием приложения, включающая в себя правила маршрутизации трафика, относящиеся к N6, с помощью PCF, а затем направляется в SMF. SMF может, основываясь на локальных политиках, учитывать эту информацию для:

выбора (повторного выбора) UPFs для PDU сеансовактивирования механизмов многоадресности трафика или применения классификатора UL (UL CL). Это может включать в себя, например, предоставление UPF правил пересылки трафика (например, вывод).

информирования функции приложения выбора (повторном выборе) UP тракта.

AF может запросить уведомление об информации местоположения UE.

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

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

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

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

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

5G CN функция может выбирать UPF рядом с UE и выполняет управление трафиком от UPF к локальной сети передачи данных через интерфейс N6. Выбор может быть основан на данных подписки UE, местоположении, политики или других относящихся правилах трафика.

Из-за мобильности пользователя или AF может потребоваться непрерывность обслуживания или сеанса на основании требований услуги или 5G сети.

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

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

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

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

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

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

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

информирование о сетевых возможностях: многие функции базовой сети могут обмениваться информацией с и AF (например, информацией о возможностях функций) через NEF.

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

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

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

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

информацию о направлении маршрутизации трафика, такую как, по меньшей мере, один из DNN (например, если весь трафик PDU сеанса направлен в приложение) и адрес приложения

потенциальные местоположения приложения, к которым должна применяться маршрутизация трафика. Потенциальные местоположения AF обработки трафика используют для выбора (повторного) UPF

информацию о маршрутизации трафика, относящуюся к N6, сконфигурированную в UPF.

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

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

информацию о том, когда (указание времени) должна применяться маршрутизация трафика.

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

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

выбирать (повторно) UPFs для PDU сеансов

активировать механизмы многоадресности трафика или применения классификатора UL (UL CL). Это может включать в себя, например, предоставление UPF правил пересылки трафика (например, вывод).

информировать AF о (повторном) выборе UP тракта.

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

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

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

В варианте (3) осуществления NEF преобразует информацию о местоположении UE (например, идентификатор зоны или некодированную информацию о зоне), принятую из приложения, в информацию (например, идентификаторы), идентифицирующую AN, которые обслуживают географическую зону.

В варианте (4) осуществления NEF предоставляет переведенную информацию для выбранной CPF, такой как SMF или PCF.

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

В реализации предоставлен способ для подключения UE к сети. Способ включает в себя UE, предоставляющее DNN и идентификатор приложения в запросе сеанса; SMF получает из политики оператора под управлением приложения PCF, используя UE, местоположение DNN и идентификатор приложения. Политика оператора может быть проиндексирована в PCF с использованием одного из DNN, идентификатора приложения, идентификатора UE, местоположения или комбинации любого, или всех вариантов выбора. В некоторых реализациях политика может быть ассоциирована с условием пространственной достоверности. В реализации, в соответствии с политикой, SMF имеет достаточную информацию для обеспечения возможности выбора UP тракта (например, привязки UPFs). SMF может установить UP тракт и сконфигурировать управление трафиком на UPF привязки (например, трафик, предназначенный для IP-адреса приложения, направляют в конкретное местоположение в локальной DN). SMF может сконфигурировать управление трафиком, поскольку сконфигурировано с помощью отображения между идентификатором приложения и IP-адресом приложения.

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

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

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

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

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

AFs, обрабатывающие трафик от/к UE, развертывают в локальной DN оператора.

AF выполнена с возможностью выбирать (повторно выбирать) или перемещать AFs в пределах локальной DN. AF взаимодействует с сетевыми функциями плоскости управления либо напрямую, либо через NEF.

NEF (или сама AF, когда AF взаимодействует непосредственно с CN CP) определяет список подходящих UPFs, обеспечивающих эффективный UP тракт к идентифицированным потенциальным местоположениям AF, и предоставляет эту информацию в SMF.

Также можно предположить, что NEF может аутентифицировать и проверять достоверность информации, принятую от функции приложения.

Фиг. 16 является схемой сигнализации, иллюстрирующей вариант осуществления процедуры уведомления AF местоположения (перемещения). Однако следует отметить, что в определенных вариантах осуществления, в которых оператор AF 324 доверяет, AF 324 может напрямую взаимодействовать с CN функциями, так что AF 324 также выполняет роль NEF 314 в этом способе. Это отмечается на этапах 1600-1608, где AF 324 может участвовать непосредственно, а не через NEF 314, в тех случаях, когда оператор доверяет AF 324.

На этапе 1600 AF 324 отправляет уведомление о AF местоположении (перемещении) (которое включает в себя идентификатор приложения, информацию о местоположении AF, условие временной достоверности, условие пространственной достоверности, фильтр трафика) в NEF 314.

На этапе 1602 NEF 314 (или AF 324) выбирает обслуживающую PCF 314 с использованием NRF 318. В варианте осуществления, показанном на фиг. 15, выбранная обслуживающая PCF является PCF 318. В некоторых вариантах осуществления (не показаны) NEF 314 предоставляет NRF 318 локальное имя DN, идентификатор приложения граничного вычисления, условие пространственной достоверности (такое как идентификаторы обслуживающих узлов доступа, географическое местоположение или область), и NRF 318 отвечает на NEF 314 с обслуживающей PCF согласно всей или любой комбинации этих фрагментов информации. Информация может предоставляться посредством AF 324, или NEF 314 может извлекать информацию на основании ввода, предоставленного AF 324. Следует понимать, что информация, предоставленная посредством NEF 314 в NRF 318, может предоставляться посредством AF 324. информация может быть предоставлена в сообщении, таком как уведомление переопределения местоположения AF, или она может быть определена или принята посредством NEF 314 через информацию, предоставленную посредством AF 324.

Затем на этапе 1604 NEF 314 (или AF 324) обрабатывает уведомление и отправляет запрос обновления политики управления UP в PCF 314. На этапе 1606 PCF 314 затем генерирует или обновляет политики управления UP в соответствии с запросом. Если установление/обновление политики влияет на текущий PDU сеанс, и обслуживающая SMF 310 PDU сеанса подписалась на уведомление об обновлении политики, PCF 314 уведомит SMF 310 об обновлении политики.

На этапе 1608 PCF 314 отвечает на NEF 314 (или AF 314), чтобы подтвердить прием запроса. В случае, когда PCF 314 отвечает на NEF 314, а не в AF 324, NEF 314 подтверждает, на этапе 1610, уведомление AF местоположении (перемещении) в AF 324.

Фиг. 17 является схемой сигнализации, иллюстрирующей вариант осуществления процедуры уведомления UP (повторного) выбора. В некоторых вариантах осуществления AF 324 является доверенным оператором, так что он может напрямую взаимодействовать с CN. В этом случае, AF 324 берет на себя роль NEF 314 в этой процедуре, и этапы 1702 и 1712 пропускают и этапы 1704, 1706 и 1708 включают в себя AF 324, а не NEF 314.

Способ начинают с процедуры 1700 уведомления о выборе (повторном выборе) UP. На этапе 1702 этой процедуры AF 324 отправляет запрос подписки уведомления о выборе (повторном выборе) UP (который включает в себя идентификатор PDU сеанса или приложения, условие временной достоверности, условие пространственной достоверности, фильтр трафика) в NEF 314, указывающий, запрашивают ли, по меньшей мере, одно из уведомлений до и уведомлений после выбора (повторного выбора) UP. Как отмечено выше, этот этап является возможным и может не требоваться в вариантах осуществления, в которых AF 324 является доверенной для оператора.

На этапе 1704 NEF 314 (или AF 324, если ей доверяет оператор) взаимодействует с NRF 318, чтобы выбрать PCF. В варианте, показанном на фиг. 16, выбранная PCF является PCF 314. В некоторых вариантах осуществления NEF 314 предоставляет NRF 318 имя локального DN, идентификатор приложения граничного вычисления, условие пространственной достоверности (такое как идентификаторы обслуживающего узла доступа, географическое местоположение или область), и NRF 318 отвечает на NEF 314 обслуживающим PCF согласно всей или любой комбинации этих фрагментов информации. Информация может предоставляться посредством AF 324, или NEF 314 может извлекать информацию на основании ввода, предоставленного AF 324. Аналогично ситуации, описанной выше, информация, предоставленная в NRF 318 посредством NEF 314, может быть принята из 324 в запросе подписки на уведомления о выборе (повторном выборе). В других вариантах осуществления NRF 318 может определять или извлекать эту информацию на основании информации, принятой из NEF 314. На этапе 1706 NEF 314 (или AF 324) обрабатывает запрос и отправляет запрос обновления политики уведомления о выборе (повторном выборе) UP в PCF 314.

На этапе 1708 PCF 314 генерирует или обновляет политики уведомлений о выборе (повторном выборе) UP в соответствии с принятым запросом. Если установление/обновление политики влияет на текущий PDU сеанс, и обслуживающая SMF 310 PDU сеанса подписалась на уведомление об обновлении политики, PCF 314 может отправить SMF 310 сообщение с уведомлением об обновлении политики.

На этапе 1710 PCF 314 отвечает на NEF 314 (или AF 324), чтобы подтвердить прием запроса. В варианте осуществления, в котором AF 324 не взаимодействует напрямую с CN, NEF 314 может отправлять подтверждение, на этапе 1712, подписки на уведомление о выборе (повторном выборе) UP в AF 324.

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

На этапе 1716 SMF 310 передает уведомление о выборе (повторном выборе) UP в NEF 314, которое служит в качестве уведомления для подписчиков о выборе (повторном выборе) UP, что имел место выбор (повторный выбор) UP. Это уведомление представляют, по меньшей мере, до и после выбора (повторного выбора) UP, основанного на типе запрошенного уведомления. Он указывает местоположение PDU сеанса, которое может включать в себя, по меньшей мере, одно из местоположения привязки PDU сеанса и IP-адрес UE 102.

Ранние уведомления позволяют AF 324 подготовить необходимые этапы (например, мобильность AF 324), ассоциированные с выбором (повторным выбором) UP. Поздние уведомления позволяют AF 324 конфигурировать локальную DN для маршрутизации трафика от AF 324.

На этапе 1718, в ответ на прием уведомления о выборе (повторном выборе) UP, NEF 314 обрабатывает уведомление и отправляет уведомление о выборе (повторном выборе) UP в AF 324. AF 324 может затем указать местоположение PDU сеанса и соответствующее местоположение приложения. Этот этап 1718 является возможными в некоторых вариантах осуществления выполняется только тогда, когда NEF 314 используется AF 324. В случае, когда NEF 314 не используется, AF 324 и PCF 316 могут взаимодействовать непосредственно друг с другом и AF 324 может реализовывать функции иным образом выполняемые посредством NEF 314 (например, функциональные возможности, относящиеся к настоящей процедуре). Если этап 1718 выполняется, на этапе 1720 AF 324 подтверждает доставку уведомления в NEF 314.

На этапе 1722 NEF 314 (или AF 324) подтверждает доставку уведомления SMF 310.

В реализации услуга «обновление политики управления UP» является услугой, в которой PCF 316 принимает запрос обновления политики управления UP. Запрос может включать в себя идентификатор (идентификаторы) приложения, идентификаторы привязки UPFs, подходящих для выбора каждого из местоположений приложения, условия временной достоверности, условия пространственной достоверности, фильтра трафика и N6 информации о маршрутизации трафика. Результатом доставки запроса является предоставление услуги.

Во время предоставления данной услуги, когда PCF 316 принимает запрос на обновление политики управления UP, PCF 316 соответственно генерирует или обновляет политики управления UP и подтверждает прием запроса запрашивающей стороне. Если генерация/обновление политики влияет на текущий PDU сеанс и обслуживающая SMF 310 PDU сеанса подписалась на уведомление об обновлении политики, PCF 316 уведомит SMF 310 об обновлении политики.

В другой реализации услуга «обновление политики уведомления о выборе (повторном выборе) UP» является услугой, в которой PCF принимает запрос обновления политики уведомления о выборе (повторном выборе) UP. Запрос может включать в себя идентификатор приложения, условие временной достоверности, условие пространственной достоверности, фильтр трафика, тип уведомления. Результатом работы услуги является результат доставки запроса.

Во время предоставления данной услуги, когда PCF 316 принимает запрос обновления политики уведомления о выборе (повторном выборе) UP, он может соответственно сгенерировать или обновить политики уведомления о выборе (повторном выборе) UP и подтверждает прием запроса запрашивающей стороны. Если генерирование/обновление политики влияет на текущий PDU сеанс, и обслуживающая SMF 310 PDU сеанса подписалась на уведомление об обновлении политики, PCF 316 может уведомить SMF 310 об обновлении политики.

В одной реализации услуга «уведомление о местонахождении (перемещении) AF» является услугой, в которой NEF 314 принимает уведомление о местонахождении (перемещении) AF 324. Входное уведомление может включать в себя идентификатор приложения, информацию о местонахождении AF, условие временной достоверности, условие пространственной достоверности, фильтр трафика, N6 информацию о маршрутизации трафика. Выходные данные службы являются результатом доставки уведомления о AF местонахождении.

Во время предоставления данной услуги, когда NEF 314 принимает уведомление о AF местоположении (перемещении), обрабатывают уведомление и запрашивают PCF 316 обновить политики управления UP и подтверждают уведомление AF местоположения (перемещения) запрашивающей стороне.

В одной реализации услуга «подписка на уведомления о выборе (повторном выборе) UP» является услугой, в которой NEF 314 принимает подписку на уведомление о выборе (повторном выборе) UP для уведомлений о событиях выбора (повторном выборе) UP для указанного трафика. Входная подписка может включать в себя идентификатор приложения, условие временной достоверности, условие пространственной достоверности, фильтр трафика и тип уведомления. Выходные данные услуги являются результатом подписки на уведомления о выборе (повторном выборе) UP.

Во время предоставления услуги, когда NEF 314 принимает подписку на уведомление о выборе (повторном выборе) UP, могут запросить PCF 316 обновить политики уведомления о выборе (повторном выборе) UP и подтвердить подписку для запрашивающей стороны. Когда NEF 314 принимает уведомление о выборе (повторном выборе) UP, идентифицируют местоположение соответствующей AF 324 для обработки трафика и уведомляет подписчиков об уведомлении о выборе (повторном выборе) UP и местоположении AF обработки трафика.

В реализации услуга «уведомления о выборе (повторном выборе) UP» является услугой, в которой SMF 310 имеет локальную политику, указывающую подписку на уведомление о выборе (повторном выборе) UP для уведомлений о событиях выбора (повторного выбора) UP для продолжающейся PDU сессии. Входными данными для этой услуги является политика уведомления о выборе (повторном выборе) UP, которая может включать в себя идентификатор PDU сеанса, условие временной достоверности, условие пространственной достоверности, тип уведомления и информацию о подписке. Информация о подписке указывает на подписчика NF. Результатом этой услуги является уведомление о выборе (повторном выборе) UP (которое может включать в себя информацию о подписке и информацию о местоположении PDU сеанса). Информация о подписке используется для идентификации записи контекста подписки в NF подписчика.

Во время выполнения данной процедуры, когда SMF 310 обнаруживает локальную политику, указывающую подписку для уведомления о выборе (повторном выборе) UP для уведомлений о событиях выбора (повторном выборе) UP для текущего PDU сеанса, регистрируют подписку, указанную политикой. Когда SMF 310 выбирает (повторно выбирает) UPF для PDU сеанса, уведомляют подписчиков об уведомлении о выборе (повторном выборе) UP. В случае подписки на раннее уведомление SMF 310 отправляет уведомление перед выполнением выбора (повторном выборе) UPF. В этом случае, ответ на это уведомление может включать в себя информацию о маршрутизации трафика, относящуюся к N6. SMF 310 уведомляет NEF 314, который уведомляет AF 324; AF 324 направляет ответ в NEF 314, который затем направляет ответ в SMF 310. Информация о маршрутизации трафика, относящаяся к N6, может содержаться в ответе, передаваемый AF 324 в NEF 314. NEF 314 может обрабатывать его перед отправкой в SMF 310. Обработка может включать в себя дополнение его недостающими информационными частями, что является специфическим для протокола N6, и компиляцию заголовка протокола. SMF 310 затем конфигурирует UPF привязки для поддержки или использования интерфейса N6 с AF обработки трафика, который может быть AF 324 или другой AF, в соответствии с принятой информацией маршрутизации трафика, относящейся к N6, при выполнении выбора (повторного выбора) UPF.

В случае подписки на позднее уведомление SMF 310 отправляет уведомление, когда выбор (повторный выбор) UPF завершен. В реализации предоставляют способ для установления PDU сеанса, запрошенного UE 102. В случае роуминга AMF 308 может определить, должен ли PDU сеанс быть установлен в локальном выводе (LBO) или домашней маршрутизации. В случае LBO процедура такая же, как и в случае отсутствия роуминга, с той разницей, что любая или все SMF 310, UPF 304 и PCF 316 могут быть расположены в посещаемой сети.

На фиг. 18А и 18В представлена схема сигнализации, иллюстрирующая вариант осуществления процедуры для запрашиваемого UE установления PDU сеанса при отсутствии роуминга и роуминга с локальным выводом. Процедура предполагает, что UE 102 уже зарегистрировано в AMF 308, таким образом, AMF 308 уже извлекла данные подписки пользователя из UDM 320.

Чтобы установить новый PDU сеанс, UE 102 генерирует новый ID PDU сеанса. UE 102 инициирует процедуру установления запрашиваемого PDU сеанса UE путем передачи на этапе 1800 сообщения NAS (S-NSSAI, DNN, идентификатор приложения, идентификатор PDU сеанса, информация N1 SM) (обратите внимание, что в некоторых вариантах осуществления идентификатор приложения может быть встроен в информацию SM), содержащее запрос установления PDU сеанса в информации SM N1 для AMF 308. Запрос установления PDU сеанса может включать в себя тип PDU, режим SSC, параметры конфигурации протокола.

Когда DNN указывает на локальную DN, NAS сообщение может включать в себя идентификатор приложения, соответствующий приложению граничных вычислений, размещенному в локальной DN. Наличие идентификатора приложения указывает на то, что это запрос на PDU сеанс, выделенный для приложения граничных вычислений.

NAS сообщение, отправленное UE 102, инкапсулируется AN 308 в сообщение N2, которое должно включать в себя информацию о местоположении пользователя и информацию о типе технологии доступа.

Информация SM может содержать контейнер запроса DN PDU SM, содержащий информацию для авторизации PDU сеанса внешней DN.

На этапе 1802 AMF 308 определяет, что сообщение соответствует запросу на новый PDU сеанс на основании идентификатора PDU сеанса, который не используется для какого-либо существующего PDU сеанса UE. AMF 308 выбирает SMF 310.

На этапе 1804 AMF 308 передает SM-запрос SMF 310. SM-запрос содержит постоянный идентификатор абонента, DNN, S-NSSAI, идентификатор PDU сеанса, AMF ID, информацию N1 SM, информацию о местоположении пользователя и тип технологии доступа. Идентификатор AMF однозначно идентифицирует AMF 308, обслуживающую UE 102. Информация N1 SM содержит запрос установления PDU сеанса, принятый от UE 102.

На этапе 1806 SMF 310 передает запрос данных подписки (постоянный идентификатор подписчика, DNN) в UDM 320. Этот этап является возможным и может выполняться, если SMF 310 еще не извлекла ассоциированные с SM данные подписки для UE, ассоциированного с DNN, SMF 310 запрашивает эти данные подписки.

Если этап 1806 выполняется, то на этапе 1808 UDM 320 передает ответные данные подписки на SMF 310. Данные подписки включают в себя авторизованный тип (типы) PDU, авторизованный режим (режимы) SSC, профиль QoS по умолчанию.

SMF 310 проверяет, соответствует ли запрос UE пользовательской подписке и локальным политикам. Если не соответствует, то SMF 310 отклоняет запрос UE через NAS сигнализацию SM (включающую в себя соответствующую причину отклонения SM), ретранслированную посредством AMF 308, SMF 310 указывает AMF 308, что идентификатор PDU сеанса должен рассматриваться как освобожденный и остальную часть процедуры не выполняют.

Этап 1810 является этапом аутентификации/авторизация PDU сеанса из SMF 310 в DN 306 через UPF 304. Если SMF 310 необходимо авторизовать/аутентифицировать установление PDU сеанса, SMF 310 выбирает UPF 304 и инициирует аутентификацию/авторизацию установления PDU сеанса. Если аутентификация/авторизация установления PDU сеанса выполнена неудачно, то SMF 310 завершает процедуру установления PDU сеанса и указывает отклонение в UE 102.

При использовании динамического управления политикой и тарификацией (PCC), то на этапе 1812 SMF 310 выполняет выбор PCF. На этапе 1814 SMF 310 может инициировать установление PDU-CAN сеанса в PCF 316, чтобы получить правила PCC по умолчанию для PDU сеанса. Следует отметить, что в этом конкретном варианте осуществления целью этапа 1810 является получение правил PCC перед выбором UPF 304. Если правила PCC не нужны в качестве входных данных для выбора UPF, то этап 1810 может быть пропущен.

На этапе 1816 SMF 310 выбирает режим SSC для PDU сеанса. Если этап 1710 не выполняется, SMF 310 также может выбрать UPF 304 во время этого этапа. В случае PDU типа IPv4 или IPv6 SMF 310 может выделить IP-адрес/префикс для PDU сеанса.

Если развернут динамический PCC и установление PDU-CAN сеанса не было выполнено на этапе 1814, то на этапе 1818 SMF 310 может инициировать установление PDU-CAN сеанса в направлении PCF 316, чтобы получить правила PCC по умолчанию для PDU сеанса. В противном случае, если развернут динамический PCC, и тип PDU является IPv4 или IPv6, SMF инициирует модификацию PDU-CAN сеанса и предоставляет выделенный IP-адрес/префикс UE для PCF 316.

На этапе 1820 SMF 310 уведомляет AF 324 о выборе UP тракта, если запрос PDU сеанса предназначен для приложения граничных вычислений и, если AF 324 подписана на такое раннее уведомление, относящееся к PDU сеансу. Уведомление указывает привязку PDU сеанса.

Если этап 1810 не был выполнен, то SMF инициирует процедуру установления сеанса N4 с выбранной UPF 304, в противном случае, инициируют процедуру модификации сеанса N4 с выбранной UPF 304, как проиллюстрировано на фиг. 17. В частности, на этапе 1822 SMF отправляет запрос на установление/модификацию сеанса N4 в UPF 304 и предоставляет правила обнаружения пакетов, применения и отчетности для установки в UPF 304 для этого PDU сеанса. Если информация о туннеле CN выделена SMF 310, на этом этапе информация о туннеле CN предоставляется UPF 304. Затем, на этапе 1824, UPF 304 подтверждает отправкой ответа на установление/изменение сеанса N4. Если информация о туннеле CN выделена UPF 304, информация о туннеле CN предоставляется SMF 310 на этом этапе 1824.

На этапе 1826 SMF 310 отправляет подтверждение запроса SM (информация N2 SM (идентификатор PDU сеанса, профиль QoS, информация о туннеле CN), информация SM N1 (принятие установления PDU сеанса (правило авторизованного QoS, режим SSC))) в AMF 308.

Информация SM N2 несет информацию, которую AMF 308 может предоставить в (R) AN 302. Информация туннеля CN может соответствовать адресу базовой сети туннеля N3, соответствующему PDU сеансу. Профиль QoS может предоставлять (R) AN 302 отображение между параметрами QoS и QoS идентификаторами потока. ID PDU сеанса может использоваться (R) сигнализацией AN с UE 102, чтобы указывать UE 102 связь между (R) ресурсами AN и PDU сеансом для UE 102. Информация SM N1 может содержать подтверждение установления PDU сеанса, что AMF предоставляет в UE 102. В подтверждении установления PDU сеанса может содержаться множество авторизованных правил QoS в информации N1 SM и в информации N2 SM. Подтверждение запроса SM может дополнительно содержать информацию, позволяющую AMF 308 знать или определять, какое UE 102 является целью запроса SMF 310, а также определять, какой доступ к UE 102 использовать.

Следует отметить, что информация о доступе может предоставляться/использоваться для разрешения случая, когда UE одновременно подключено через 3GPP и не-3GPP доступ.

На этапе 1828 AMF 308 отправляет запрос N2 PDU сеанса (информация N2 SM, принятие установления PDU сеанса) в (R) AN 302. AMF 308 отправляет подтверждение установления PDU сеанса и информацию SM N2, принятую от SMF 310 в пределах запроса N2 PDU сеанса в (R) AN 302.

На этапе 1830 (R) AN 302 может начать специфический для AN обмен сигнализацией с UE 102, который ассоциирован с информацией, принятой из SMF 310. Например, в случае 3GPP RAN, может потребоваться реконфигурация RRC соединения с UE 102 установлением необходимых ресурсов RAN, относящихся к авторизованным правилами QoS, для запроса PDU сеанса, принятого на этапе 1822.

(R) AN 302 также может выделять (R) AN информацию туннеля для PDU сеанса. (R) AN 302 может пересылать NAS сообщение (подтверждение установления PDU сеанса), предоставленное на этапе 1824, в UE 102. (R) AN 302 может предоставлять NAS сообщение в UE 102, когда необходимые (R) AN ресурсы установлены и выделение (R) AN туннельной информации прошло успешно.

На этапе 1832 (R) AN 302 отправляет подтверждение запроса N2 PDU сеанса ((R) AN туннельная информация) в AMF 308. ((R) AN туннельная информация может соответствовать адресу сети доступа туннеля N3, соответствующему PDU сеансу.

На этапе 1834 AMF 308 может отправлять запрос SM (информация N2 SM) в SMF 310. Более конкретно, AMF 308 пересылает информацию SM N2, принятую из (R) AN 302, в SMF 310.

В некоторых реализациях UE 102 может уведомить CN функцию, что она успешно установила PDU сеанс. В некоторых реализациях UE 102 передает NAS сообщение о завершении установления PDU сеанса, чтобы указать, что UE 102 успешно установило PDU сеанс. В некоторых реализациях успешное установление сеанса в (R) AN 302, указанном на этапе 1828, служит уведомлением.

Если сеанс N4 для этого PDU сеанса еще не был установлен, SMF 310 на этапе 1836 инициирует процедуру установления сеанса N4 с помощью UPF 304. В противном случае, SMF 310 инициирует процедуру модификации сеанса N4 с помощью UPF 304. SMF 310 предоставляет туннельную информацию AN и туннельную информацию CN. Туннельная информация CN требуется только в том случае, если на этапе 1718 SMF 310 выбрала туннельную информацию CN.

На этапе 1838 UPF 304 передает SMF 310 ответ установления/модификации сеанса N4. После этого этапа AMF 308 может пересылать уведомление о соответствующих событиях в SMF 310, например, при хендовере, когда изменяют (R) AN туннельную информацию или AMF 308 перемещается. В некоторых вариантах осуществления SMF 310 явно подписывается на эти события. В других вариантах подписка является неявной. На возможном этапе 1842 SMF 310 пересылает конфигурацию адреса IPv6 в UE 102 через UPF 304. В частности, в случае PDU типа IPv6 SMF 310 генерирует объявление маршрутизатора IPv6 и отправляет его в UE 102 через N4 и UPF. 304. Следует понимать, что в некоторых вариантах осуществления после этапа 1838 SMF может отправлять подтверждение запроса SM (показано как 1840) в AMF 308. Это может быть ответом на сообщение 1724 запроса SM.

На этапе 1844 SMF 310 передает в AF 324 сообщение уведомления о выборе UPF (позднее уведомление), которое информирует AF 324 о выборе UP тракта, если запрос PDU сеанса предназначен для приложения граничных вычислений и, если AF 324 подписана на такое позднее уведомление, ассоциированное с PDU сеансом. Уведомление указывает привязку PDU сеанса. AMF 308 может хранить в течение времени действия PDU сеанса ассоциацию идентификатора PDU сеанса и идентификатора SMF.

В варианте осуществления предоставлена процедура для управления SSC и UP трактом под влиянием AF в сценариях граничных вычислений. Процедуру выполняют между AF и CN CP для поддержки эффективного UP тракта для AF, которые в этом нуждаются. Для этой процедуры предполагают, что локальные сети передачи данных, в которых размещают приложения граничных вычислений, отвечают за надлежащую реализацию интерфейса N6 для обеспечения непрерывности обслуживания или сеанса при наличии, по меньшей мере, одного из мобильности UE и мобильности AF. В этом случае повторный выбор UP тракта может быть прозрачным для UE 5.

В одной реализации из-за перемещения приложения выполняют реконфигурацию привязки PDU сеанса. В этом случае, перемещение приложения не влияет на решение о выборе UPF SMF, и SMF 10 нужно только переконфигурировать маршрутизацию трафика N6 на привязку PDU сеанса, чтобы гарантировать доставку трафика UL в новое местоположение AF обработки трафика и распознавание трафика DL из нового местоположения AF для обработки трафика.

На фиг. 19 показана схема сигнализации, иллюстрирующая вариант реконфигурации привязки PDU сеанса из-за перемещения приложения. Как показано на фиг. 19, на этапе 1900 UE 102 имеет установленный PDU сеанс с UPF1 304A в качестве привязки PDU сеанса. На этапе 1902 SMF 310 принимает триггер для обновления конфигурации маршрутизации трафика N6 в UPF1 304A. Это может быть инициировано, например, перемещением приложения, изменением политики и т.д. На этапе 1904 SMF 310 уведомляет AF 324 о повторном выборе UP тракта, если AF 324 подписана на такое раннее уведомление. Уведомление указывает UPF1 304A в качестве привязки PDU сеанса. Затем на этапе 1906 SMF 310 реконфигурирует маршрутизацию трафика N6 на UPF1 304A. На этапе 1908 SMF 310 уведомляет AF 324 о повторном выборе UP тракта, если AF 324 подписана на такое позднее уведомление. Уведомление указывает UPF1 304A в качестве новой привязки PDU сеанса. В некоторых вариантах осуществления AF 324 подписана только на раннее уведомление, так что этап 1908 не выполняется. В некоторых вариантах осуществления AF 324 подписана только на позднее уведомление, так что этап 1904 не выполняется. В других вариантах осуществления AF 324 подписана как на раннее, так и на позднее уведомление, так что выполняют этапы 1904 и 1908.

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

Фиг. 20 является схемой сигнализации, иллюстрирующей вариант осуществления способа для перемещения привязки PDU сеанса для PDU сеанса, выделенного для приложения граничных вычислений. Как показано на фиг. 20, на этапе 2000 UE 102 имеет установленный PDU сеанс с UPF1 304A в качестве привязки PDU сеанса. PDU сеанс предназначен для трафика, ассоциированного с приложением граничных вычислений. На этапе 2002 SMF 310 принимает триггер для повторного выбора UPF2 304B в качестве привязки PDU сеанса. Это может быть инициировано, например, перемещением приложения, мобильностью UE, изменением политики и т.д. На этапе 2004 SMF 310 уведомляет AF 324 о повторном выборе UP тракта, если AF 324 подписана на такое раннее уведомление. Уведомление указывает UPF2 304B в качестве новой привязки PDU сеанса. На этапе 2006 SMF 310 реконфигурирует UP тракт с UPF2 304B в качестве привязки PDU сеанса, включающую в себя конфигурацию маршрутизации трафика N6 в UPF2 304B. На этапе 2008 SMF 310 уведомляет AF 324 о повторном выборе UP тракта, если AF 324 подписана на такое позднее уведомление. Уведомление указывает, что новой привязкой PDU сеанса является UPF2 304B. В некоторых вариантах осуществления AF 324 подписана только на раннее уведомление, так что этап 2008 не выполняют. В некоторых вариантах осуществления AF 324 подписана только на позднее уведомление, так что этап 2004 не выполняют. В других вариантах осуществления AF 324 подписана как на раннее, так и на позднее уведомление, так что выполняют этапы 2004 и 2008. На этапе 2010 SMF 310 высвобождает ресурс PDU сеанса с UPF1 304A.

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

Фиг. 21 является схемой сигнализации, иллюстрирующей вариант осуществления способа для перемещения привязки PDU сеанса для PDU сеанса, совместно используемого несколькими приложениями граничных вычислений. Как показано на фиг. 21, на этапе 2100 UE 102 имеет установленный PDU сеанс с UPF1 304A в качестве привязки PDU сеанса для трафика, ассоциированного с приложением граничных вычислений. На этапе 2102 SMF 310 решает повторно выбрать UPF2 304B в качестве привязки PDU сеанса для трафика, ассоциированного с приложением граничных вычислений. Это может быть инициировано, например, перемещением приложения, мобильностью UE, изменением политики и т.д. На этапе 2104 SMF 310 уведомляет AF 324 о повторном выборе UP тракта, если AF 324 подписана на такое раннее уведомление. Уведомление указывает UPF2 304B в качестве новой привязки PDU сеанса для трафика, ассоциированного с приложением граничных вычислений. На этапе 2106 SMF 310 конфигурирует UPF2 304B через N4, чтобы быть новой привязкой PDU сеанса для трафика, ассоциированного с приложением граничных вычислений. На этапе 2108 SMF 310 конфигурирует через N4 UPF как UL CL 304C для PDU сеанса и устанавливает две ветви от UL CL 304C до UPF1 304A и UPF2 304B. SMF 310 предоставляет UL CL 304C необходимые правила пересылки трафика UL. SMF 310 затем инструктирует, на этапе 2110, (R) AN 302 обновить N3. На этапе 2112 SMF 310 уведомляет AF 324 о повторном выборе UP тракта, если AF 324 подписана на такое позднее уведомление. Уведомление указывает UPF2 302B в качестве новой привязки PDU сеанса для трафика, ассоциированного с приложением граничных вычислений. В некоторых вариантах осуществления AF 324 подписана только на раннее уведомление, так что этап 2112 не выполняют. В некоторых вариантах осуществления AF 324 подписана только на позднее уведомление, так что этап 2104 не выполняют. В других вариантах осуществления AF 324 подписана как на раннее, так и на позднее уведомление, так что выполняют этапы 2104 и 2112.

В некоторых обстоятельствах сетевой адрес (например, IP-адрес) AF 324 (приложение граничных вычислений), известный UE 102, не указывает фактическое местоположение, где размещается AF 324 (например, IP-адрес может не указывать на сервер, на котором формируют экземпляр AF). Это может возникнуть, например, из-за мобильности AF, и может быть более распространенным в виртуализированной среде. В результате, IP-адрес AF 324 может не работать во всех передачах по восходящей линии связи (UL) от UE 102.

В некоторых вариантах осуществления могут использовать совместное управление CN-UP и локальную DN. NEF (функция CP в CN) определяет взаимосвязь между UPF и физическими хостами AF (то есть, приложениями граничных вычислений). NEF может определять межсоединение на основании информации AF, предоставленной MEC контроллером, и предварительно сконфигурированной информации топологии между хостами UPF и AF. NEF компилирует параметры протокола для соединения между UPF и хостами AF. Компиляция может быть основана на, по меньшей мере, одной из информации протокола, предоставленной MEC контроллером и UE, и информации сеанса, предоставленной другими CPFs. NEF инструктирует PCF генерировать политики в соответствии с решением объекта управления. Решение об управлении принимают для каждого сеанса/группы сеансов, для каждой группы UE/UE или для каждого приложения/услуги.

MEC контроллер управляет объединением обслуживающих функций в пределах локальной DN и управляет/конфигурирует хосты AF для интерфейса с UPF на основании, по меньшей мере, одной из информации UPF и UE, предоставленной CN-CP. Управление осуществляется для каждого сеанса/группы сеансов, для каждой группы UE/UE или для каждого приложения/услуги.

SMF (CP функция в CN) управляет и конфигурирует тракт и протоколы между RAN и привязки UPF, а также конфигурируют и UPF привязку для интерфейса с хостами AF в соответствии с политиками, предоставляемыми PCF, включающие в себя параметры протокола и пункт назначения маршрутизации. SMF может дополнительно предоставлять MEC контроллеру (напрямую или через NEF) информацию, относящуюся, по меньшей мере, к одному из UPF-привязки и UE. Управление осуществляют на основе сеансов.

Ссылаясь на фиг. 22 представлена упрощенная схема сети, иллюстрирующая сегментированное управление. CN-CP 328 управляет CN-UP 326 и MEC контроллер 324 управляет MEC в локальной DN 306. NEF 314 управляет связями между CN-UP 326 и локальной DN 306. Специалистам в данной области техники должно быть понятно, что связи, управляемые NEF 314, можно понимать, как логические связи между сетевыми функциями в CN-UP 326 и локальной DN 306.

UE 102 может обнаруживать MEC приложения, отправляя запрос на обнаружение в CP функцию. Запрос может включать в себя локальное имя DN, запрашивающее обнаружение MEC приложений, размещенных внутри указанной локальной DN. В некоторых реализациях отсутствие локального имени DN указывает, что запрашивается обнаружение всех MEC приложений. CP функция направляет ответ в UE согласно результату обнаружения. Результат обнаружения включает в себя список <идентификатор приложения, [адрес приложения]>, где [] указывает, что информация является возможной. В некоторых вариантах осуществления результаты обнаружения ограничиваются теми MEC приложениями, которые доступны для UE 102, или теми MEC приложениями, которые UE 102 имеет право использовать. Адрес приложения используется UE 102 для связи верхнего уровня (такого как TCP уровень) с MEC приложением. Информация MEC приложения может поддерживаться NRF 318 или храниться в UDM 320 или SMF 310. СР функция может быть любой соответствующей СР функцией, включающая в себя, например, AMF 308, NEF 314, SMF 310, NRF 318. СР функция должна взаимодействовать с NRF 318 или UDM 320 или SMF 310 для получения запрошенной информации MEC приложения перед ответом в UE 102. СР функцией также может быть NRF 318 или UDM 320 или SMF 310. В вариантах осуществления, где СР функцией является AMF 308, процедура обнаружения может быть интегрирована с процедурой регистрации, то есть, в сообщении о завершении регистрации (для UE 102) AMF 308 может включать в себя результат обнаружения.

СР функция может уведомлять UE 102 об изменениях в результате обнаружения, таких как изменение адреса приложения, через NAS сообщение. UE 102 может отправлять запрос на выделенные PDU сеансы для обработки трафика, ассоциированного с приложениями граничных вычислений. Такой выделенный PDU сеанс может использоваться для одного приложения граничных вычислений или совместно использоваться несколькими приложениями граничных вычислений.

В некоторых реализациях запрос UE может указывать, предназначен ли выделенный PDU сеанс для использования с одним приложением граничных вычислений или совместно используется несколькими приложениями граничных вычислений. В некоторых реализациях, если UE 102 запрашивает использование с одним приложением граничных вычислений, UE 102 может указывать приложение для SMF 310 во время процедуры установления PDU сеанса. SMF 310 может указывать UE 102 адрес приложения во время этапа подтверждения установления сеанса.

Совместное управление решает техническую задачу адресации в UL коммуникации. Хотя это и не требуется, использование совместного управления для совместного управления DL коммуникации позволяет отделить IP-адрес UE от привязки UPFs, т.е. прозрачный повторный выбор UPF. Повторный выбор UPF привязки может происходить из-за мобильности UE, мобильности AF, загрузки и т.д. IP-адрес UE не должен изменяться при изменении UPF привязки.

Фиг. 23 является схемой последовательности передачи сообщений, иллюстрирующей репрезентативные процедуры для аутентификации/авторизации третьей стороны через NEF 314. Аутентификация/авторизация третьей стороны для установления PDU сеанса возможно инициирована посредством SMF 310 во время процедуры установления PDU сеанса и выполняется через NEF 314.

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

На этапе 2302 SMF отправляет запрос на аутентификацию/авторизацию третьей стороны в NEF 314. Как часть этого запроса, SMF 310 может предоставить NEF 314 SM AF PDU контейнер запроса в сообщение запроса аутентификации/авторизации третьей стороны. Сообщение запроса может включать в себя, по меньшей мере, одно из DNN, S-NSSAI и идентификатор приложения. Идентификатор приложения, как описано ранее, может быть предоставлен UE 102 как часть запроса установления PDU сеанса.

На этапе 2304 NEF 314 выбирает AF 324, используя информацию, принятую на этапе 2302. На этапе 2306 NEF 314 ретранслирует в выбранную AF 324 SM AF PDU контейнер запроса, принятый из SMF 310, с использованием сообщения запроса аутентификации/авторизации. Сообщение запроса может дополнительно включать в себя идентификатор приложения.

Процедуру 2308 аутентификации/авторизации выполняют между UE 102 и AF 324 посредством сообщений, транспортируемых через NEF 314, SMF 310 и NAS. На этапе 2308a AF передает запрос аутентификации/авторизации в NEF 314. В ответ на запрос аутентификации/авторизации, на этапе 2308b NEF 314 передает транспортное сообщение NEF (сообщение аутентификации) в SMF 310, где сообщение аутентификации включает в себя информацию запроса аутентификации/авторизации, принятую от AF 324 для UE 102 на этапе 2308a. В ответ на прием транспортного сообщения NEF (сообщение аутентификации) на этапе 2308c SMF 310 передает NAS SM транспортное сообщение (сообщение аутентификации) в AMF 314. На этапе 2308d AMF 324 затем пересылает NAS SM транспортное сообщение (сообщение аутентификации) в UE 102 через (R) AN 302. На этапе 2308e UE 102 отвечает, передавая NAS SM транспортное сообщение (сообщение аутентификации) в AMF 308 через (R) AN 302, где сообщение аутентификации предназначено для AF 324. На этапе 2308f, AMF 308 передает NAS SM транспортное сообщение (сообщение аутентификации) в SMF 310. В ответ на прием NAS SM транспортного сообщения (сообщение аутентификации) на этапе 2308g SMF 310 передает SMF транспортное сообщение (сообщение аутентификации) в NEF 314. В ответ на прием SMF транспортного сообщения (сообщение аутентификации) на этапе 2308h NEF 314 передает ответное сообщение аутентификации/авторизации в AF 324. Следует понимать, что могут быть применимы подходящие альтернативные процедуры, состоящие из разных этапов.

На этапе 2310 AF 324 на основании сообщения аутентификации UE 102 завершает аутентификацию/авторизацию и отправляет ответное сообщение аутентификации/авторизации в NEF 314, чтобы подтвердить успешную аутентификацию/авторизацию PDU сеанса или о сбое. AF 324 может предоставлять AF PDU SM контейнер ответа в NEF 314, чтобы указывать успешную аутентификацию/авторизацию или сбой. AF PDU SM контейнер ответа может включать в себя идентификатор (идентификаторы) приложения (приложений), с которым UE 102 уполномочено использовать PDU сеанс.

На этапе 2312 NEF 314 отправляет сообщение ответа аутентификации/авторизации третьей стороны в SMF 310, содержащее AF PDU SM контейнер ответа.

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

На этапе 2402 SMF 310 выбирает UPF 304. На этапе 2404 SMF 310 передает DN PDU SM контейнер запроса в сообщении пересылки данных N4 на выбранную UPF 304. В некоторых случаях обозначают как SMF 310 «инициирование» процедуры установления PDU сеанса. В варианте осуществления SMF 310 предоставляет выбранной UPF 304 информацию о конфигурации управления трафиком (которая может, например, представлять собой подробное сообщение о конфигурации или идентификатор, указывающий на предварительно сохраненную информацию о конфигурации, доступную для UPF). Информация о конфигурации управления трафиком может быть частью сообщения пересылки данных N4 или может передаваться как отдельное сообщение в UPF 304. На этапе 2406 UPF 304 ретранслирует в DN 306 DN PDU SM контейнер запроса, принятый от SMF 310.

Процедуру 2408 аутентификации/авторизации выполняют, и показано, что включает в себя этапы с 2408a по 2408h между UE 102 и DN 306, с сообщениями, транспортируемыми через N4 и NAS. Следует понимать, что альтернативные процедуры, состоящие из разных этапов, также могут быть пригодны для использования.

На этапе 2410 DN подтверждает успешную аутентификацию/авторизацию PDU сеанса. DN может предоставить DN PDU SM контейнер ответа в UPF, чтобы указать успешную аутентификацию/авторизацию.

На этапе 2412 UPF 304 возвращает сообщение пересылки данных N4 в SMF 310, содержащую DN PDU SM контейнер ответа.

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

На первом этапе 2500 AF 324 может отправлять сообщение запроса AF в NEF 314. Предполагают, что сообщение запроса может содержать множество полей, таких как, например: идентификатор запроса; идентификатор сети приложения; внешний идентификатор приложения; фильтр трафика; условие временной действительности; условие пространственной достоверности; тип запроса; и контент запроса. Сообщение запроса AF также может включать в себя информацию для указания текущих или будущих сеансов, к которым может применяться запрос. В некоторых таких вариантах осуществления идентификатор UE, идентификаторы групп UEs, идентификатор группы UE или другая такая информация может содержаться в запросе AF.

Идентификатор запроса может быть использован для уникальной идентификации сообщения запроса AF и, таким образом, может позволить AF 324 изменять или удалять сообщение запроса AF или коррелировать сообщение запроса AF с будущими сообщениями запроса AF. Идентификатор запроса может быть сгенерирован либо самой AF 324, либо NEF 314. В вариантах осуществления, в которых AF 324 генерирует идентификатор запроса, он может содержаться в сообщение запроса AF, отправленное в NEF 314, которая может записать запрос идентификатор для будущего использования. В вариантах осуществления, в которых NEF 314 генерирует идентификатор запроса, он может быть передан в AF 324 в ответном сообщении запроса AF, что будет описано более подробно ниже.

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

Внешний идентификатор приложения может использоваться для идентификации приложения, к которому относится запрос AF.

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

идентификаторы UE, такие как внешний идентификатор UE или ISDN мобильной станции (MSISDN), например, для ссылки на будущий трафик конкретных UEs или трафик не-IP конкретных UEs;

IP-адреса/префиксы, например, для ссылки на IP-трафик, ассоциированный с текущими PDU сеансами;

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

индикатор ANY_UE, например, для ссылки на трафик любого UE.

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

Условие пространственной достоверности является возможным параметром, который может использоваться для указания области, в которой сообщение запроса AF является действительным. Например, условие пространственной достоверности может использоваться для ограничения действительности сообщения запроса AF текущим местоположением UE. Условие пространственной достоверности может иметь форму одного или нескольких идентификаторов зоны или домена. Зона или домен могут относиться к географическому региону или сетевой зоне, или домену. Географическая область может быть определена в терминах географической границы (и может быть объединена с условием временной достоверности) для применения к любому электронному устройству (например, UE) в пределах определенной границы (или к указанному набору устройств в пределах границы) или оно может быть определено в терминах топологии сети (например, путем указания того, что сообщение запроса применяется к любому соединению через набор узлов доступа или других таких сетевых узлов или функций) вместо границы на основании географических координат. Как отмечено выше, условие пространственной достоверности может быть объединено с другими условиями достоверности (например, временной достоверностью или спецификацией UE или UEs, к которым применяется запрос), так что запрос может быть применен к любому сеансу во временном окне, где UE в указанном наборе UE подключается, находясь в пространственной области, определяемой либо географической границей, либо определяемой топологическим ограничением сети (например, всеми сеансами, когда UE подключено, по меньшей мере, к одному из набора узлов доступа в сети радиодоступа). В вариантах осуществления, где AF обеспечивает условие пространственной достоверности на основании географических местоположений, сетевая функция в сети, совместимой с 3GPP, может использоваться для сопоставления определения географической границы с набором узлов доступа к сети или другими сетевыми функциями, которые соответствуют географической границе.

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

Контент запроса может использоваться для предоставления дополнительной информации, связанной с запросом AF. При желании контент запроса также может использоваться для предоставления информации, требуемой, по меньшей мере, для одного из указателей и поддержки двух или более типов запросов, либо отдельно, либо в сочетании с параметром типа запроса. В конкретных вариантах осуществления эта дополнительная информация может зависеть от типа запроса. Например, в сценарии, в котором параметр типа запроса указывает, что запрос AF является уведомлением о местоположении приложения, контент запроса может включать в себя любое одно или несколько из: потенциальных местоположений приложения; и соответствующие N6 требованию туннелирования «точка-точка» для UP тракта. Потенциальные местоположения приложения могут быть в форме транспортных адресов (например, имя сервера, IP-адрес и т.д.) в сети приложения. N6 требования туннелирования «точка-точка» могут указывать тип туннеля (например, отсутствие туннеля, IP-туннеля, IP/UDP-туннель, Ethernet-туннель и т.д.) и соответствующие параметры протокола туннелирования (такие как, по меньшей мере, один из адресов конечной точки туннеля)/идентификатор и номер порта в местоположении приложения, например). Отсутствие конкретных N6 требований к туннелированию «точка-точка» может использоваться для предположения, что может использоваться набор требований по туннелированию по умолчанию.

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

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

В ответ на сообщение запроса AF NEF 314 может выполнить (на 2502) процесс аутентификации/авторизации между AF 324, функцией 312 сервера аутентификации (AUSF) и хранилищем пользовательских данных (UDR) 322 или функцией 320 унифицированного управления данными (UDM). В некоторых вариантах осуществления термин UDR 322 также можно понимать как относящийся к унифицированному депозитарию данных, который обеспечивает хранение унифицированных данных для пользовательских данных и данных, ассоциированных с приложением, таких как требования политики, предоставленные AF (например, в форме запроса AF).

В некоторых вариантах осуществления AF 324 может регистрировать себя (используя свою собственную идентификацию) и приложения (например, идентификаторы приложений или внешние идентификаторы приложений), которыми управляет в сети. Эта регистрация может также указывать идентификатор сети приложения (или DNN). Регистрация может быть выполнена с помощью функции плоскости управления, такой как менеджер услуг, сетевой менеджер, менеджер домена и т.д. Функция управления может распределять учетные данные безопасности для AF и может сохранять регистрационные данные и учетные данные безопасности в функции 320 унифицированного управления данными (UDM) или UDR 322.

В процессе аутентификации/авторизации на этапе 2503 NEF 314 может отправлять, по меньшей мере, одну из идентификационную информацию AF, внешний идентификатор приложения (или идентификатора приложения) и идентификатор сети приложения (или DNN) в AUSF 312, который затем может взаимодействовать с UDM 320 (или UDR 322) для аутентификации и авторизации. NEF 314 также может взаимодействовать с AF для получения идентификационной информации AF, если эта информация, например, еще не была предоставлена в сообщении запроса AF. В качестве альтернативы, NEF 314 может предоставлять идентификатор AF в AUSF, которая затем может получать информацию идентификации AF от AF.

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

После завершения процесса аутентификации/авторизации NEF может возвратить (на 2504) ответное сообщение запроса AF, включающее в себя код результата, в AF. Код результата может указывать результат процесса аутентификации/авторизации. Если результатом является сбой, NEF 314 может завершить процедуру запроса AF после этапа 2504. В противном случае, NEF 314 может перейти к этапу 2506 и выбрать функцию 316 управления политикой (PCF), используя NRF 318. В некоторых вариантах осуществления PCF 316 может быть выбрана на основании зоны обслуживания PCF. Например, на этом этапе может быть выбрана PCF, имеющая зону обслуживания, которая, по меньшей мере, одна из них покрывает локальную DN и перекрывает условие пространственной достоверности в запросе AF. В некоторых вариантах осуществления PCF 316 может быть выбрана на основании зоны обслуживания локальной DN. Например, могут быть выбраны все PCFs в зоне обслуживания локальной DN. В другом примере, PCF 316 может быть выбрана на основании пересечения зоны обслуживания PCF и зоны локальной DN. В некоторых вариантах осуществления внешний идентификатор приложения (или идентификатор приложения) может использоваться для выбора PCF. В некоторых вариантах осуществления PCF 316 может быть предварительно сконфигурирована в NEF 314 и, в этом случае, этап 2506 выбора PCF может быть пропущен.

На этапе 2508 NEF 314 может обрабатывать сообщение запроса AF и отправлять сообщение запроса обновления политики в PCF 316. Сообщение запроса обновления политики может включать в себя любой один или несколько из следующих параметров: идентификатор запроса; DNN; идентификатор приложения; фильтр трафика; условие временной действительности; условие пространственной достоверности; тип запроса; и контент запроса.

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

DNN может быть отображен из идентификатора сети приложения, принятого NEF на этапе 2500. Это отображение может быть предварительно сконфигурировано в NEF 314. Идентификатор сети приложения также может использоваться для идентификации соответствующей управляющей информации, такой как S-NSSAI, с которым ассоциировано приложение.

Идентификатор приложения может отображаться из внешнего идентификатора приложения, принятого NEF на этапе 2500 и используемого в 5GC и UE 102 для идентификации управляющей информации (например, информации о помощи выбора сегмента одной сети (S-NSSAI) политики), к которым относится приложение. Отображение между внешним идентификатором приложения и идентификатор приложения может быть предварительно сконфигурирован в NEF 314.

Поле «фильтр трафика» в сообщении запроса обновления политики может содержать идентификаторы запроса обновления политики, которые могут быть сгенерированы на основании или преобразованы из идентификаторов запроса AF (если таковые имеются) в поле «фильтр трафика» сообщения запроса AF, принятого посредством NEF. Поле фильтра трафика также может содержать идентификаторы группы UEs. Группы UEs, на которые ссылаются идентификаторы, могут быть сформированы или определены в соответствии с предшествующим запросом группирования UEs из AF, и членство в группе поддерживают в UDM 320 (например, UDR 322). Группа UEs может быть конкретной для приложения.

Условие пространственной достоверности может принимать форму идентификаторов RAN узлов или идентификаторов сот, и любой из них может отображаться из условия пространственной достоверности сообщения запроса AF, принятого NEF на этапе 2500. Отображение между условием пространственной достоверности сообщение запроса AF и сообщением запроса обновления политики могут быть предварительно сконфигурировано в NEF.

В случае, когда запрос AF является уведомлением о местоположении приложения, контейнер контента запроса может включать в себя идентификаторы профиля маршрутизации и соответствующие N6 требованию туннелирования «точка-точка». Идентификаторы профиля маршрутизации могут отображаться из информации (такой как идентификатор сети приложения, внешний идентификатор приложения и потенциальные местоположения приложения), содержащейся в сообщении запроса AF, принятом NEF на этапе 2500. Это отображение может быть предварительно сконфигурировано в NEF непосредственно плоскостью управления (MP) или через сетевую функцию (NF), такую как PCF 316, UDM 320 или DSF (например, UDR 322).

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

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

В некоторых вариантах осуществления предварительную конфигурацию не выполняют непосредственно для целевой NF, а для третьей NF, такой как UDM 320 или DSF. Целевая NF может получать информацию о предварительной конфигурации из третьей NF заблаговременно (например, периодически или при необходимости) или реактивно (например, после получения уведомления от третьей NF). Специалистам в данной области техники должно быть понятно, что DSF может, в некоторых вариантах осуществления, быть получена посредством UDR 322.

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

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

Если поле фильтра трафика принятого сообщения запроса обновления политики содержит идентификаторы запроса обновления политики, эти идентификаторы запроса обновления политики могут быть преобразованы в соответствующие фильтры трафика. Сообщение запроса также может содержать идентификаторы группы UEs, которые могут быть преобразованы в фильтры трафика (или могут использоваться в сочетании с другими данными для построения фильтров трафика). Для преобразования PCF может взаимодействовать с UDR для получения соответствующих данных политики. Это преобразование может быть выполнено до того, как PCF предоставит данные политики в UDR. Альтернативно, преобразование может быть выполнено позже, когда политика отправлена SMF. Выполнение преобразования позднее позволяет выполнить любое обновление/изменение фильтров трафика в этих запросах на обновление политик (например, указанным идентификаторами запроса обновления политики) или членство в группе UE, когда SMF получает политику.

Политика управления трафиком может включать в себя любое одно или несколько из: DNN, идентификатор приложения, фильтр трафика, идентификаторы профиля управления трафиком, идентификатор профиля маршрутизации, условия временной достоверности, условия пространственной достоверности, N6 требования туннелирования «точка-точка» и идентификатор запроса на обновление политики. Идентификаторы профиля управления трафиком могут быть отображены из идентификаторов профиля маршрутизации в запросе обновления политики (на этапе 2508).

Политика уведомления о событии управления UP может включать в себя любое одно или более из: DNN, идентификатор приложения, фильтр трафика, условия временной достоверности, условие пространственной достоверности, тип события, тип уведомления, идентификатор получателя уведомления о событии (например, NEF или AF или PCF) и идентификатор запроса на обновление политики.

Политика группирования UE может включать в себя любое одно или более из: DNN, идентификатор приложения, фильтр UE и идентификатор запроса на обновление политики. В этом случае фильтр трафика в запросе обновления политики (и запросе AF) может служить в качестве фильтра UE, и сопоставление/преобразование может выполняться для фильтра UE, по меньшей мере, одной из в NEF и PCF, как описано выше.

Как только были сгенерированы политики управления UP (или, что эквивалентно, данные политики управления UP), PCF может выбрать UDR и предоставить (на 2512) соответствующие данные политики управления UP для выбранного UDR. UDR может быть выбран с использованием DNN и идентификатора приложения. Информация UE в фильтре трафика также может быть использована для выбора UDR, если это необходимо. UDR может уведомить любые другие PCFs, которые подписались на событие изменения данных политики. Альтернативно, это может быть основано на перекрытии любого одного или нескольких из DNNs, идентификатора приложения и условия пространственной достоверности (по желанию) и зоны обслуживания PCF.

Как только данные политики были предоставлены в UDR, PCF возвращает (на 2514) сообщение ответа обновления политики в NEF (или AF), чтобы подтвердить получение запроса обновления политики.

PCF 316 также может уведомлять (на 2516) любые SMF 310, которые подписались на уведомление о событии обновления политики. В качестве альтернативы, PCF 316 может идентифицировать целевые SMFs на основании перекрытия условия пространственной достоверности (если есть) и зоны обслуживания SMF и уведомлять идентифицированные SMFs. После получения уведомления от PCF 316 подписывающая SMF 310 может получить политики управления UP, идентифицировать PDU сеансы, к которым применяют политики, и применить политики к этим PDU сеансам.

Чтобы определить, подписана ли SMF 310 на уведомление о событии обновления политики, SMF 310 может отправлять свойства PDU сеанса (такие как, по меньшей мере, одно из: приложение, DNN, IP-адрес UE, идентификатор UE и информацию о местоположении UE) в PCF 316, и PCF 316 может сверять свойства PDU сеанса с обновленными политиками. PCF 316 может предоставлять обновленные политики, на которые имеет право PDU сеанс, для SMF 310 в соответствии с доступной ему информацией. SMF 310 может дополнительно проверять PDU сеанс на соответствие обновленным политикам, используя свойства PDU сеанса, которых нет у PCF 310. Таким образом, информация, которая использовалась для проверки PDU сеанса посредством PCF 316, не должна предоставляться SMF 310. Например, если условие временной достоверности проверяется посредством PCF 316, тогда SMF310 не нужно проверьте его, и, следовательно, политика, предоставленная SMF, не будет его иметь. В варианте осуществления, в котором PCF не проверяет свойства PDU сеанса, вся информация может быть предоставлена SMF.

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

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

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

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

В некоторых вариантах осуществления на основании N6 требований к туннелированию «точка-точка» в политике управления трафиком SMF вычисляет информацию N6 требований к туннелированию «точка-точка» и конфигурирует ее в привязке PDU сеанса. Информация N6 требований к туннелированию «точка-точка» может включать в себя шаблон потока трафика (TFT) для отображения туннеля N6 на UP тракт для пакетов DL и инструкции по обработке пакетов (например, должен применяться заголовок протокола туннелирования) для пакетов UL.

В примере на фиг. 25A, PCF может быть выбрана (на этапе 2506) на основании области обслуживания PCF, перекрывающей условие пространственной достоверности в запросе AF. Фиг. 25B иллюстрирует альтернативный вариант осуществления, в котором PCF выбирают на основании DNN и идентификатора приложения. Фиг. 25C иллюстрирует другой альтернативный вариант осуществления, в котором PCF выбирают посредством UDM (или UDR), а не NEF.

Как можно видеть на фиг. 25B, процесс обработки вызова (также называемый процессом обработки сообщений) в целом аналогичен процессу по фиг. 25A, за исключением того, что в этом случае этап 2512 опускается, и этап 2506 (выбор PCF) заменяют альтернативным этапом (2518), на котором NEF 314 (или AF 324) может отображать идентификатор сети приложения на DNN и внешний идентификатор приложения на идентификатор приложения и предоставляют результирующую информацию DNN и идентификатора приложения в NRF 318 для выбора PCF 316. Информация UE в фильтре трафика также может быть использована для выбора PCF. Идентификатор приложения может использоваться в 5GC и UE для идентификации управляющей информации (например, S-NSSAI, политики), к которой относится приложение. В некоторых вариантах осуществления выбирают несколько PCFs, и NEF (или AF) отправляет запрос на обновление политики всем выбранным PCFs. В некоторых вариантах осуществления NEF 314 (или AF 324) выполняет выбор PCF путем выбора агентства PCF (которое является сетевой функцией) и отправляет запрос на обновление политики в агентство PCF, которое затем отправляет его всем PCFs, которые обслуживает или делегирует. В некоторых вариантах осуществления отображения могут быть предварительно сконфигурированы в NEF (или AF). В некоторых вариантах осуществления выбор PCF может быть предварительно сконфигурирован в NEF (или AF), и в этом случае, этап выбора PCF может быть опущен.

Ссылаясь на фиг. 25C, в проиллюстрированном альтернативном варианте осуществления AF 324 и NEF 314 взаимодействуют для выполнения этапов 2500, 2502 и 2504, как описано выше со ссылкой на фиг. 3A. Затем (на 2520) NEF 314 (или AF 324) может сопоставить сетевой идентификатор приложения с DNN, и внешний идентификатор приложения на идентификатор приложения и использовать результирующую информацию DNN и идентификатора приложения для выбора UDM 320. Информация UE в фильтре трафика также может использоваться для выбора UDM. Идентификатор приложения может использоваться в 5GC и UE 102 для идентификации управляющей информации (например, S-NSSAI, политики), к которой относится приложение. В некоторых вариантах осуществления отображения могут быть предварительно сконфигурированы в NEF (или AF). В некоторых вариантах осуществления выбор UDM может быть предварительно сконфигурирован в NEF, и в этом случае, этап 2520 выбора UDM может быть опущен.

На этапе 2522 NEF 314 может обрабатывать сообщение запроса AF и отправлять сообщение запроса обновления данных приложения в UDM 320. Сообщение запроса обновления данных приложения может включать в себя любой один или несколько из следующих параметров: идентификатор запроса; DNN; идентификатор приложения; фильтр трафика; условие временной действительности; условие пространственной достоверности; тип запроса; и контент запроса.

Идентификатор запроса может использоваться для уникальной идентификации запроса на обновление данных приложения и, следовательно, может позволить NEF изменять или удалять запрос на обновление данных приложения или коррелировать запрос на обновление данных приложения с будущими запросами на обновление политики. Идентификатор запроса может быть сгенерирован либо самим NEF 314, либо UDM 320 (или UDR 322). В вариантах осуществления, в которых NEF 314 генерирует идентификатор запроса, он может содержаться в сообщении запроса обновления данных приложения, отправленное в UDM 320 (или UDR 322), которое может записать идентификатор запроса для будущего использования. В вариантах осуществления, в которых UDM (или UDR) генерирует идентификатор запроса, он может быть передан в NEF 314 в ответном сообщении обновления данных приложения, которое будет описано более подробно ниже. Предпочтительно, NEF 314 поддерживает отображение между идентификатором запроса обновления данных приложения и идентификатором запроса AF, принятым NEF 314 на этапе 2500.

DNN может отображаться из идентификатора сети приложения, принятого NEF на этапе 2500. Это отображение может быть предварительно сконфигурировано в NEF.

Идентификатор приложения может отображаться из внешнего идентификатора приложения, принятого NEF на этапе 2500 и используемого в 5GC и UE для идентификации управляющей информации (например, информации о помощи выбора сегмента одной сети (S-NSSAI), политики), к которой относится приложение. Отображение между внешним идентификатором приложения и идентификатором приложения может быть предварительно сконфигурировано в NEF.

Поле «фильтр трафика» в сообщении запроса на обновление политики может содержать идентификаторы запроса на обновление политики, которые могут быть сгенерированы на основании идентификаторов запроса AF (если таковые имеются) в поле «фильтр трафика» сообщения запроса AF, принятого NEF.

Условие пространственной достоверности может принимать форму идентификаторов RAN узлов или идентификаторов сот, и любой может быть отображен из условия пространственной достоверности сообщения запроса AF, принятого NEF на этапе 2500. Отображение между условием пространственной достоверности сообщение запроса AF и сообщением запроса обновления политики может быть предварительно сконфигурировано в NEF.

На этапе 2524 UDM 320 (или UDR) может возвращать ответное сообщение обновления данных приложения в NEF 314.

Затем UDM 320 (или UDR) может идентифицировать любые PCFs, которые подписались на уведомление об обновлениях данных приложения. Альтернативно, UDM 320 (или UDR) может идентифицировать любые PCFs, имеющие область обслуживания, которая включает в себя локальную DN или пересекает область обслуживания локальной DN. UDM 320 (или UDR) может затем отправлять (на 2526) соответствующие сообщения уведомления об изменении данных приложения каждой идентифицированной PCF 316. На основании информации, содержащейся в принятых сообщениях уведомления об изменении данных приложения, PCF 314 может генерировать политики и пересылать соответствующие обновления политики для подписки SMF 310, как описано выше на этапах 2510 и 2516. В некоторых вариантах осуществления уведомление об изменении данных приложения является простым сигналом и не включает в себя детали изменения, и PCF необходимо взаимодействовать с UDM (или UDR) для получения подробной информации об изменениях и соответственно сгенерировать политики.

Следует отметить, что в примере по фиг. 25C, поскольку UDM 320 используют для выбора PCF 314, этапы выбора и уведомления UDM 320 (или UDR), описанные выше на 2512 и 2514, могут быть опущены.

Как можно понять, функция 324 приложения, которой доверяет оператор, может напрямую взаимодействовать с PCF 316. В таком случае, AF 324 также может выполнять роль NEF в процедуре. Фиг. 26 иллюстрирует примерную схему операций обработки вызовов, соответствующую примеру по фиг. 25А, на которых этапы 2500, 2502 и 2504 по фиг. 25A, либо не выполняются, либо выполняются AF 324, и этапы 2506, 2508 и 2514 заменяют этапами 2600, 2602 и 2604, которые выполняют AF 324, но в остальном идентичны этапам 2506, 2508 и 2514. Понятно, что для вариантов осуществления по фиг. 25B, 25C и 27A-27B могут использовать аналогичные варианты, которые ради краткости изложения, не описаны подробно в данном описании.

На фиг. 27A показана схема операций обработки вызовов (также называемая схемой операций обработки сообщений), иллюстрирующая процесс уведомления управления UP трактом к AF 324. Очевидно, что функция приложения, которой доверяет оператор, может напрямую взаимодействовать с PCF 316. В таком случае, AF 324 может взять на себя роль NEF 314 в этой процедуре. Процедура уведомления о событии управления UP может быть выполнена, по меньшей мере, за одно до того, как инициируют событие управления UP в плоскости пользователя, и после того, как оно завершено, в зависимости от типа уведомления.

Для целей этой процедуры AF может подписаться (на 2700) на уведомления о событиях управления UP из SMF 314 с использованием любого подходящего процесса, такого как, например, как описано выше, или как изложено в применимом техническом 3GPP стандарте.

На первом этапе (на 2702) SMF 310 может применять политику оператора и идентифицировать (на 2704) каждую NEF (или AF), которая запросила соответствующее уведомление об обновлении политики.

Затем, SMF 310 может отправлять (на этапе 2706) сообщение с уведомлением о событии управления UP на (или каждую) идентифицированную NEF (или AF). Сообщение уведомления о событии управления UP может включать в себя один или несколько из следующих параметров: идентификатор запроса на обновление политики (или идентификатор запроса на обновление данных приложения); фильтр трафика; тип события; тип уведомления; и контент уведомления о событии.

Идентификатор запроса обновления политики (или идентификатор запроса обновления данных приложения) может быть получен SMF из политики оператора.

Фильтр трафика может указывать трафик, с которым связано событие управления UP, который является частью трафика, указанного в поле «фильтр трафика» в запросе обновления политики. Отсутствие фильтра трафика в сообщении уведомления о событии управления UP может использоваться для указания, что событие управления UP связано со всем трафиком, указанным фильтром трафика в запросе обновления политики. Фильтр трафика может включать в себя любую подходящую комбинацию: идентификаторов UE, таких как внешний идентификатор UE или MSISSDN; и IP-адреса/префиксы.

Тип уведомления может использоваться для указания, является ли уведомление о событии управления UP либо ранним уведомлением, либо поздним уведомлением.

Контент уведомления о событии может быть использован для предоставления дополнительной информации, связанной с событием управления UP. Контент уведомления о событии может включать в себя одно или несколько из: фильтр трафика; местоположение приложения; местоположение UPF привязки; и N6 информацию туннелирования «точка-точка». Местоположение приложения может принимать форму идентификатора профиля маршрутизации или DNAI, или идентификатора профиля управления трафиком. Местоположение UPF привязки может принимать форму сетевого адреса, который может зависеть от типа туннеля. Например, для IP-туннеля он имеет форму IP-адреса; для туннеля Ethernet имеет вид адреса Ethernet. В некоторых вариантах осуществления информация местоположения UPF привязки может использоваться для поддержки N6 туннелирования «точка-точка» в локальной DN. Информация N6 туннелирования «точка-точка» может быть предоставлена для конфигурирования в местоположении приложения для ассоциации трафика DL с соединением N6 туннелирования «точка-точка» для обеспечения надлежащей доставки пакетов DL. Информация N6 туннелирования «точка-точка» может включать в себя, по меньшей мере, один из адрес/идентификатор конечной точки туннеля и номера порта на стороне UPF привязки. Форма адреса/идентификатора конечной точки туннеля может зависеть от типа туннеля. Например, для IP-туннеля адрес/идентификатор конечной точки туннеля предпочтительно будет иметь вид IP-адреса; для туннеля Ethernet он предпочтительно будет иметь вид адреса Ethernet. В конкретных вариантах осуществления конкретная информация, предоставляемая в контенте уведомления о событии, может зависеть от типа события, на которое ссылается уведомление о событии управления UP. Например, в случае события изменения QoS контент уведомления о событии может включать новые «правила QoS». В дополнительном примере, если типом события является изменение управления трафиком, тогда контент уведомления о событии может включать в себя местоположение приложения, местоположение UPF привязки и информацию N6 туннелирования «точка-точка».

На основании принятого сообщения уведомления о событии управления UP, NEF 314 может отправлять (на 2708) соответствующее сообщение уведомления о событии управления UP в AF 324. Сообщение уведомления о событии управления UP, отправленное в AF 324, может включать в себя любое одно или более: идентификатор запроса AF; тип события; тип уведомления; и контент уведомления о событии. Идентификатор запроса AF может отображаться из идентификатора запроса обновления политики, содержащегося в сообщении запроса обновления политики, описанном выше со ссылкой на фиг. 25 и 26. Контент уведомления о событии может отображаться из контента уведомления о событии из сообщения уведомления о событии управления UP, полученного NEF от SMF (на этапе 2706). Например, местоположение приложения может быть преобразовано из формы идентификатора профиля маршрутизации или DNAI, или идентификатора профиля управления трафиком в вид сетевого адреса, который относится к местоположению, в котором развернуто приложение.

После приема сообщения уведомления о событии управления UP от NEF 310, AF 324 может отправлять (на 2710) сообщение подтверждения в NEF 314. Подтверждение может включать в себя N6 информацию туннелирования «точка-точка», которая должна быть сконфигурирована в UPF 304 привязке.

NEF 314 может затем отправлять (на 2712) подтверждение исходного сообщения уведомления о событии управления UP в SMF 310. В вариантах осуществления, в которых AF предоставляет N6 информацию туннелирования «точка-точка» в NEF 314, эта информация может содержаться в сообщение подтверждения, отправленного SMF 310.

После приема сообщения подтверждения от NEF 314 SMF 310 может конфигурировать (на 2714) N6 информацию туннелирования «точка-точка» в UPF привязки.

Как отмечено выше, функция приложения, которой доверяет оператор, может напрямую взаимодействовать с SMF 310. В таком случае, AF 324 также может выполнять роль NEF 314 в процедуре по фиг. 27А. Соответственно, этапы 2708 и 2710 не будут выполняться и этапы 2706 и 2712 выполняются посредством AF 324.

На фиг. 27B показана схема операций обработки вызовов (также называемой схемой операций обработки сообщений), иллюстрирующей альтернативный процесс уведомления управления UP трактом к AF 324. Как и в варианте осуществления по фиг. 27А, процедура уведомления о событии управления UP может быть выполнена, по меньшей мере, за одно до того, как событие управления UP инициируется в плоскости пользователя и после его завершения, в зависимости от типа уведомления.

Для целей этой процедуры PCF 316 может подписаться (на 2716) на уведомления о событиях управления UP от SMF 310, используя любой подходящий процесс, такой как, например, как описано выше, или как изложено в применимом 3GPP техническом стандарте. Аналогично, AF может подписаться (на 2718) на уведомления о событиях управления UP от PCF 316.

На первом этапе (на этапе 2702) SMF 310 может применять политику оператора и идентифицировать (на этапе 2720) каждую PCF 316, которая запросила соответствующее уведомление об обновлении политики.

SMF 310 может отправлять (на 2722) сообщение уведомления о событии управления UP на (или каждой) идентифицированной PCF 316. Сообщение уведомления о событии управления UP может быть отформатировано, как описано выше со ссылкой на фиг. 27А.

На основании принятого сообщения уведомления о событии управления UP, PCF 316 может отправлять (на 2724) соответствующее сообщение уведомления о событии управления UP в NEF 314. Перед отправкой сообщения может преобразовать ID профиля управления трафиком или DNAI в сообщение с идентификатором профиля маршрутизации. Сообщение уведомления о событии управления UP, отправленное в NEF 314, может включать в себя любой один или несколько из: идентификатор запроса AF; тип события; тип уведомления; и контент уведомления о событии. Идентификатор запроса AF может отображаться из идентификатора запроса обновления политики, содержащегося в сообщении запроса обновления политики, описанном выше со ссылкой на фиг. 25 и 26. Контент уведомления о событии может отображаться из контента уведомления о событии из сообщения уведомления о событии управления UP, полученного NEF от SMF (на этапе 2706). Например, местоположение приложения может быть преобразовано из формы идентификатора профиля маршрутизации в вид сетевого адреса, который ссылается на местоположение, в котором развернуто приложение. NEF 314 может пересылать (на 2726) принятое сообщение уведомления о событии управления UP в AF 324.

В некоторых вариантах осуществления сообщение уведомления о событии управления UP, отправленное в NEF 314 или PCF 316, также может включать в себя поле формата контента, которое предоставляет информацию о том, как структурированы данные, чтобы позволить сетевой функции правильно интерпретировать информацию в контенте уведомления о событии. Например, контент уведомления о событии может использоваться для хранения различных типов информации (таких как идентификатор профиля маршрутизации, идентификатор профиля управления трафиком или DNAI события) в зависимости от функции приемника. В таком случае, поле формата контента может использоваться для указания соответствующего формата, который должен использоваться для считывания информации в поле контента уведомления о событии. Поле формата контента может быть установлено PCF при генерировании политики или на основании контента управления UP даже уведомлением из SMF (на этапе 2722).

После приема сообщения уведомления о событии управления UP из NEF 314, AF 324 может отправлять (на 2728) сообщение подтверждения в NEF 314. Подтверждение может включать в себя N6 информацию туннелирования «точка-точка», которая должна быть сконфигурирована в UPF 304 привязки.

NEF 314 может отправлять (на 2730) подтверждение исходного сообщения уведомления о событии управления UP в PCF 316. В вариантах осуществления, в которых AF 324 предоставляет N6 информацию туннелирования «точка-точка» в NEF 314, эта информация может содержаться в сообщение подтверждения, отправленного в PCF 316.

После приема сообщения подтверждения из NEF 314, PCF 316 может пересылать (на 2732) сообщение подтверждения в SMF 310.

После приема сообщения подтверждения от PCF 316 SMF 310 может конфигурировать (на 2714) N6 информацию туннелирования «точка-точка» в UPF 304 привязки.

Как отмечено выше, функция приложения, которой доверяет оператор, может напрямую взаимодействовать с PCF 316. В таком случае, AF 324 также может выполнять роль NEF 314 в процедуре по фиг. 2. Соответственно, этапы 2726 и 2728 не будут выполняться и этапы 2725 и 2730 будут выполняться AF 324.

На фиг. 28A и 28B показывают схему операций обработки вызовов (также называемую схемой операций обработки сообщений), иллюстрирующую процесс запрашиваемого UE установления PDU сеанса для сценариев без роуминга. Процедура по фиг. 28A и 28B предполагает, что UE 102 уже зарегистрировано в AMF 308, таким образом, AMF 308 уже извлекла данные подписки пользователя из UDM 320.

На первом этапе (на этапе 2800) UE 102 инициирует процедуру установления запрашиваемого PDU сеанса UE, генерируя и отправляя NAS сообщение в AMF 308. NAS сообщение может содержать S-NSSAI, DNN, идентификатор приложения, ID PDU сеанса и информацию SM N1, и может содержать запрос установления PDU сеанса в информации SM N1. Запрос установления PDU сеанса может включать в себя тип PDU, режим SSC и параметры конфигурации протокола. Идентификатор приложения может быть использован для описания URSP, как описано в пункте A.3.1.3.3 TS 23.501.

NAS сообщение может включать в себя идентификатор приложения, соответствующий приложению граничных вычислений. Это может произойти, когда DNN указывает на локальную DN. Наличие идентификатора приложения указывает на то, что это запрос на PDU сеанс, использование которого предназначено или выделено для приложения граничных вычислений.

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

Информация SM может содержать DN PDU SM контейнер запроса, содержащий информацию для авторизации PDU сеанса внешней DN.

На основании информации, предоставленной в NAS сообщении, AMF 308 может определить, что сообщение соответствует запросу на новый PDU сеанс, на основании идентификатора PDU сеанса, который не используется для какого-либо существующего PDU сеанса (сеансов) UE. AMF может затем выбрать (на 2802) SMF для PDU сеанса.

На следующем этапе (на этапе 2804) AMF 308 может отправлять сообщение запроса SM на выбранную SMF 310. Сообщение запроса может включать в себя параметры, такие как: постоянный идентификатор абонента, DNN, идентификатор приложения, S-NSSAI, идентификатор PDU сеанса, идентификатор AMF, информацию N1 SM, информацию о местоположении пользователя и тип технологии доступа). Идентификатор AMF однозначно идентифицирует AMF 308, обслуживающую UE. Информация SM N1 содержит запрос установления PDU сеанса, принятый от UE 102.

На основании информации, предоставленной в сообщении запроса SM, SMF 310 может выполнить одну или несколько проверок, чтобы определить, соответствует ли запрос UE пользовательской подписке и локальным политикам. Это может включать в себя отправку (на 2806) запроса данных подписки в UDM 320 и прием (на 2808) ответа данных подписки, предоставляющего информацию о подписке пользователя. Данные подписки могут включать в себя авторизованный тип (типы) PDU, авторизованный режим (режимы) SSC, профиль QoS по умолчанию и определенную подпиской информацию о группе (например, идентификаторы группы). Если SMF 310 еще не извлекла относящиеся к SM данные подписки для UE 102, ассоциированного с DNN, SMF 310 также может запросить эти данные подписки из UDM 320.

Если запрос UE не соответствует подписке пользователя и локальным политикам, то SMF 310 может отклонить запрос UE через сигнализацию NAS SM, чтобы указать AMF 308, что идентификатор PDU сеанса должен рассматриваться как освобожденный, и процедура заканчивается.

В вариантах осуществления, в которых SMF 310 необходимо авторизовать/аутентифицировать установление PDU сеанса через третью сторону, SMF может инициировать применимый процесс 2810 аутентификации/авторизации установления PDU сеанса третьей стороны. Инициирование процесса 2810 установления PDU сеанса третьей стороны может включать в себя SMF 310, передающий запрос в службу аутентификации третьей стороны, которая может находиться в пределах DN. Этот процесс 2810 может быть выполнен через UPF или NEF, как описано в другом месте в настоящем документе. Если аутентификация/авторизация установления PDU сеанса выполнена неудачно, то SMF 310 может завершить процедуру установления PDU сеанса и указывает на отклонение в UE 102.

В вариантах осуществления, в которых развернут динамический PCC, SMF 310 может выполнять выбор PCF (на этапе 2812). SMF 310 также может инициировать установление PDU-CAN сеанса (2814) с PCF 316, чтобы получить правила PCC по умолчанию для PDU сеанса. В вариантах осуществления, в которых развернут динамический PCC, и DNN указывает на локальную DN, SMF 310 может предоставить DNN и идентификатор приложения для PCF 316. Дополнительная информация может быть предоставлена для PCF 316, чтобы дать возможность принять более подробные решения относительно политик. Например, информация UE (такая как информация о местоположении, идентификатор UE, информация о группе, определенной по подписке и т.д.) или информация о трафике (например, IP-адрес UE) могут быть предоставлены так, чтобы PCF могла реагировать только с помощью политики, которая приспособлена к требованиям конкретного UE или трафика. При желании может быть предоставлена другая информация, относящаяся к PDU сеансу. PCF может использовать эту информацию для получения соответствующих данных политики из UDR для принятия решений относительно политики. Это может привести к тому, что PCF подпишется на уведомления как минимум об одном изменении данных политики, относящейся к DN и приложению из UDR. Правила PCC могут включать в себя политики уведомлений о событиях управления UP трактом. Правила PCC могут включать в себя информацию о N6 туннеле, относящуюся к DN (такую как, по меньшей мере, один из адрес и номер порта конца туннеля в DN). Понятно, что задачей данного этапа является получение правил PCC перед выбором UPF. Если правила PCC не нужны в качестве входных данных для выбора UPF, то данный этап можно пропустить.

SMF 310 может выбирать (на этапе 2816) UPF 304 и режим SSC для PDU сеанса. В вариантах осуществления, в которых типом PDU является либо IPv4, либо IPv6, SMF 310 может выделять IP-адрес/префикс для PDU сеанса. Для неструктурированного типа PDU SMF 310 может выделять префикс IPv6 для PDU сеанса и N6 туннелирования «точка-точка» (на основании UDP/IPv6). Если предоставляют политики управления трафиком, то на данном этапе SMF 310 также может выбрать профиль или политику управления трафиком.

В вариантах осуществления, в которых развернут динамический PCC, и установление сеанса PDU-CAN не было выполнено на этапе 2514, SMF 310 может инициировать (на 2818) установление PDU-CAN сеанса к PCF 316, чтобы получить правила PCC по умолчанию для PDU сеанса. Если DNN указывает на локальную DN, в дополнение к информации UE (например, идентификатору UE, информации о группе, определенной по подписке) SMF 310 может также предоставить DNN и идентификатор приложения (если доступно) для PCF 316. В противном случае, если развернут динамический PCC и тип PDU является либо IPv4, либо IPv6, SMF 310 может инициировать модификацию PDU-CAN сеанса и предоставить выделенный IP-адрес/префикс UE для PCF 316. Если развернут динамический PCC для неструктурированного типа PDU, SMF 310 может предоставлять префикс IPv6, выделенный для PDU сеанса, в PCF 316.

На следующем этапе (2820) SMF 310 может выбрать профиль или политику управления трафиком.

В вариантах осуществления, в которых предоставляют политики уведомления о событии управления UP трактом, SMF может уведомлять (на 622) AF (или NEF) о выборе UP тракта. Если политики управления трафиком указывают на необходимость динамической конфигурации информации N6 туннеля между SMF 310 и AF 324, согласование также может выполняться вместе с уведомлением о выборе UP тракта. Уведомление может включать в себя информацию N6 туннеля, ассоциированную с UPF (например, по меньшей мере, один из адрес и номер порта UPF), и указание на раннее уведомление.

На этапе 2824 SMF 310 может отправлять запрос установления/ изменение сеанса N4 в UPF 304 и предоставлять правила обнаружения пакетов, принудительного применения и сообщения, которые должны быть установлены в UPF 304 для этого PDU сеанса. В вариантах осуществления, в которых процесс аутентификации PDU сеанса не выполняют (на этапе 2810), сообщение запроса на установление/изменение сеанса N4 может использоваться для инициирования процедуры установления сеанса N4 с выбранной UPF 308, в противном случае, могут использовать для инициирования N4 процедуры изменения сеанса с выбранной UPF 308: если информация о туннеле CN выделена посредством SMF, на этом этапе предоставляют соответствующую информацию о туннеле CN в UPF 308. Если должен поддерживаться N6 туннель, то на этом этапе предоставляют соответствующую информацию о N6 туннеле в UPF 304. Следует понимать, что на этом этапе информация N6 туннеля не обязательно должна предоставляться в UPF 304.

UPF может подтвердить сообщение запроса на установление/изменение сеанса N4, отправив (на 2826) сообщение ответа на установление/изменение сеанса N4 в SMF. Если информация о туннеле CN выделена UPF 308, то на этом этапе соответствующая информация о туннеле CN также может быть предоставлена SMF 310.

На этапе 2828 SMF 310 может вернуть сообщение подтверждения запроса SM в AMF 308. Сообщение подтверждения запроса SM может содержать параметры, такие как: SM N2 информация (например, идентификатор PDU сеанса, профиль QoS и информация туннеля CN); SM N1 информация (например, принятие установления PDU сеанса (включающая в себя авторизованное правило QoS и режим SSC)). N2 SM информация может содержать информацию, которую AMF должна предоставить в (R)AN. Информация о туннеле CN может соответствовать адресу базовой сети туннеля N3, соответствующему PDU сеансу. Профиль QoS может предоставлять AN узлу отображение между параметрами QoS и идентификаторами потока QoS. Идентификатор PDU сеанса может использоваться сигнализацией AN с UE, чтобы указывать UE ассоциацию между ресурсами AN и PDU сеансом для UE. SM N1 информация может содержать сообщение принятия установления PDU сеанса, которое AMF должна предоставить в UE. Множество авторизованных правил QoS могут содержаться в сообщение принятия установления PDU сеанса в N1 SM информации и в N2 SM информации.

Сообщение подтверждения запроса SM может дополнительно содержать информацию, позволяющую AMF идентифицировать, какое UE является целью запроса SMF, а также определять, какой доступ к UE использовать. Информация о доступе может использоваться, чтобы иметь дело со случаем, когда UE одновременно соединено через 3GPP и не 3GPP доступ.

Обращаясь теперь к фиг. 28B, на этапе 2830 AMF может отправлять сообщение запроса N2 PDU сеанса в R (AN) 302. Сообщение запроса N2 PDU сеанса может содержать параметры, такие как: SM N2 информация; и подтверждение установления PDU сеанса.

В ответ на сообщение запроса N2 PDU сеанса R (AN) 302 может инициировать (на 2832) специальный обмен сигналами AN с UE 102, чтобы установить ресурсы для PDU сеанса. Например, в случае 3GPP RAN может быть выполнена реконфигурация RRC соединения с UE 102, устанавливающим необходимые RAN ресурсы, ассоциированные с авторизованными правилами QoS для PDU сеанса. (R)AN узлы также могут выделять (R) информацию туннеля AN для PDU сеанса. (R)AN узлы могут пересылать NAS сообщение (включающее в себя подтверждение установления PDU сеанса) в UE, если необходимые RAN ресурсы установлены и выделение информации туннеля RAN выполнено успешно.

После установки ресурсов для PDU сеанса RAN узел 302 может отправлять (на 2834) сообщение подтверждения запроса N2 PDU сеанса в AMF 308. Сообщение подтверждения запроса N2 PDU сеанса также может включать в себя информацию о RAN туннеле, соответствующую адресу сети доступа туннеля N3 для PDU сеанса. После приема сообщения подтверждения приема запроса N2 PDU сеанса AMF 304, UE 102 может начать передачу (на 2836) данных восходящей линии связи PDU сеанса в UPF 304.

На следующем этапе (2838) AMF 308 может переслать SM N2 информацию, принятую от (R)AN, в SMF 310, используя сообщение запроса SM, которое включает в себя N2 SM информацию.

Затем SMF 310 может отправлять (на 2840) запрос изменения сеанса N4 в UPF 304 для предоставления информации туннеля AN и (возможно) информации туннеля CN для сеанса N4, ассоциированного с новым PDU сеансом. В случае, когда сеанс N4 для нового PDU сеанса еще не был установлен, SMF 310 может инициировать процедуру установления сеанса N4 с UPF 304, чтобы установить сеанс N4 с информацией туннеля AN и (возможно) информацией туннеля CN. В противном случае, SMF 310 может инициировать процедуру изменения сеанса N4 с UPF 304, чтобы добавить информацию о туннеле AN и (возможно) информацию о туннеле CN к существующему сеансу N4. Обратите внимание, что информация о туннеле CN требуется только в том случае, если SMF 310 выбрала информацию о туннеле CN на этапе 2816.

После приема ответа на установление/изменение сеанса N4 от UPF (на 2842) SMF 310 может уведомить (на 2844) AF 324 (или NEF 314) о выборе UP тракта, если политики уведомления о событии управления UP трактом предоставляют и указывают на необходимость позднего уведомления. Уведомление может включать в себя информацию туннеля N6, ассоциированную с UPF (например, по меньшей мере, один из адрес и номер порта UPF), и указание, что уведомление является поздним уведомлением. Если используется туннель N6, этот этап может указывать AF, что туннель N6 готов к использованию. Впоследствии AMF может пересылать соответствующие события в SMF, например, при передаче обслуживания, когда RAN информацию о туннеле изменяют или AMF перемещают.

SMF 310 затем возвращает (на 2846) подтверждение запроса SM в AMF 308 перед генерированием и отправкой (на 2848) объявления маршрутизатора IP в UE 102 через сеанс N4 и UPF 304. Данный этап предоставляет IP информацию конфигурации, так что данные нисходящей линии связи могут быть переданы в UE (на этапе 2850).

В течение времени PDU сеанса AMF 308 сохраняет ассоциацию идентификатора PDU сеанса и идентификатора SMF.

На фиг. 29A и 29B показывают схему операций обработки вызовов, иллюстрирующую процесс для запрашиваемого UE установления PDU сеанса для роуминга с локальным выводом. Процедура по фиг. 29А и 29В аналогична показанной на фиг. 28A и 28B, за исключением того, что в случае роуминга с локальным выводом SMF 310, UPF 304 и PCF 316 все расположены в посещаемой сети. Это подразумевает, что этапы 2820, 2822 и 2844, описанные выше, не выполняются.

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

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

Впоследствии, AMF может обнаруживать событие мобильности UE (на этапе 3002) и отправляет соответствующее уведомление в AF (на этапе 3004). В качестве альтернативы, AMF может уведомлять SMF, и SMF, в свою очередь, уведомляет AF. Уведомление может быть отправлено через NEF (например, когда AF не является доверенным) или напрямую в AF (например, когда AF находится в доверительной области). Уведомление может включать в себя целевые локальные DNs (где также развернуто приложение), в которое перемещают UE.

После приеме уведомления AF может идентифицировать (на этапе 3006) вторую AF, которая ассоциирована с приложением в целевой DN, и уведомляет вторую AF о идентификаторе приложения, фильтре трафика (указывающем обрабатываемый трафик приложения) и контекстную информацию приложения. AF может дополнительно уведомлять вторую AF об идентификаторе уведомления AMF (передают в уведомлении AMF).

Затем вторая AF может отправлять запрос (на 3012) в 5GC (например, SMF), чтобы инициировать установление или возобновление PDU сеанса после того, как UE входит в целевую локальную DN. Запрос, отправленный в 5GC (например, SMF) для установления или возобновления PDU сеанса, может включать в себя, по меньшей мере, один из идентификатор уведомления AMF и фильтр трафика, так что 5GC может возобновить правильный PDU сеанс или информировать UE для установления PDU сеансов для надлежащего трафика.

Как только событие мобильности UE произошло, AMF может отправить соответствующее уведомление в SMF (на этапе 3008), и SMF может ответить путем деактивации или освобождения (на 3010) PDU сеанса, связанного с приложением.

В некоторых случаях одна и та же AF может быть ассоциирована с приложением как в текущей, так и в целевой DNs. В этом случае, «AF» и «вторая AF», упомянутые выше, фактически являются одним и тем же объектом. Следовательно, взаимодействие между двумя AFs на этапе 3006 становится внутренней процедурой, и этап 3012 может выполняться посредством ответного сообщения от первой AF к AMF или к SMF.

Как можно понять, процесс по фиг. 30 позволяет сохранять сеанс приложения UE, поскольку контекст приложения передают второй AF, которая управляет приложением в целевой DN.

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

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

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

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

Следует понимать, что, когда приложение связывается с UE через 3GPP-совместимую сеть, местоположение приложения может быть отображено или ассоциировано с DNAI. В некоторых вариантах осуществления эта ассоциация может быть частью профиля маршрутизации (например, сохранена или иным образом указана в профиле маршрутизации). В других вариантах осуществления ассоциация является внешней по отношению к профилю маршрутизации и может храниться в локально доступной таблице или в общей контрольной точке в сети. В некоторых вариантах осуществления профиль маршрутизации описывает параметры маршрутизации, ассоциированные с маршрутизацией трафика в местоположение приложения. Это может принимать форму комбинации одного или обоих адресов назначения и номера порта назначения в местоположении приложения. Такие варианты осуществления являются примерами ситуаций, в которых ассоциация может быть внешней по отношению к профилю маршрутизации. Специалистам в данной области техники будет понятно, что профили маршрутизации в некоторых вариантах осуществления могут зависеть от местоположения приложения. Это позволяет направлять трафик в DNAI и оттуда перенаправлять в приложение. Приложение может быть сгенерировано в разных DNs. В одной и той же DN приложение может быть сгенерировано в нескольких местоположениях, и каждое местоположение приложения может быть ассоциировано с множеством DNAIs. В реализациях, где профиль маршрутизации зависит от местоположения приложения, профиль маршрутизации может указывать транспортный адрес, такой как IP-адрес и номер порта, или сетевой адрес, такой как адрес Ethernet, ассоциированный с местоположением приложения и другими параметрами маршрутизации трафика, которые будут использоваться DNAI, ассоциированные с местоположением приложения, для маршрутизации трафика в местоположение приложения.

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

Поскольку DNAI идентифицирует точку доступа сети передачи данных, и каждая DN может поддерживать множество различных приложений и UPFs, DNAI может быть ассоциирован с множеством различных UPFs. Профиль управления трафиком обычно ассоциирован с DNAI и затем применяется к каждой UPF, ассоциированной с DNAI. В некоторых вариантах осуществления PCF может быть сконфигурирована с информацией о DNAI и профилях управления трафиком. В некоторых вариантах осуществления ассоциация между профилем управления трафиком и UPFs может быть сконфигурирована в SMF. В другом варианте осуществления профиль управления трафиком может быть сконфигурирован в UPF и SMF. Описанная выше конфигурация может выполняться функцией плоскости управления, такой как менеджер сети, менеджер сегментов, менеджер услуг и т.д. Другие сетевые функции, включающие в себя SMF, NEF или PCF, также могут иметь роли в конфигурации UPF и профиль управления трафиком. В реализациях, где профиль управления трафиком соответствует специфическому DNAI, профиль управления трафиком может указывать транспортный адрес, такой как IP-адрес и номер порта, или сетевой адрес, такой как адрес Ethernet, ассоциированный с DNAI и другими параметрами маршрутизации трафика, которые будут использоваться UPFs, ассоциированные с DNAI, для маршрутизации трафика в DNAI. Профиль управления трафиком может также указывать сам DNAI с помощью идентификатора.

На фиг. 31 показана логическая блок-схема 3100, иллюстрирующая пример взаимосвязи между местоположением приложения, DNAI и UPF. Проиллюстрирован набор из четырех UPFs, UPF1 3102, UPF2 3104, UPF3 3106 и UPF4 3108. Проиллюстрирован набор из двух местоположений AS1 3120 и AS2 3126 приложения. Доступ к AS1 3120 может осуществляться через DNAI 1 3110 или DNAI 2 3114. Доступ к AS2 3126 осуществляется через DNAI 2 3114. Трафик с UPF1 3120 и UPF2 3104 на AS1 3120 зависит от профиля 1 3112 управления трафиком и профиля 1 3122 маршрутизации. Трафик от UPF2 3104, UPF3 3106 и UPF4 3108 к AS2 3126 является объектом профиля 2 3116 управления трафиком и профиля 2 3124 маршрутизации. Таким образом, трафик от UPF2 3104 может зависеть от различных профилей управления трафиком на основании целевого местоположения приложения.

Профиль 1 3122 маршрутизации соответствует местоположению AS1 3120 приложения, которое ассоциировано как с DNAI1 3110, так и с DNAI2 3114. Профиль 2 3124 маршрутизации соответствует местоположению AS2 1326 приложения, которое ассоциировано с DNAI2 3114.

Ассоциация между UPF и DNAI может подразумевать, что UPF может поддерживать управление трафиком в направлении DNAI, используя информацию, указанную в профиле управления трафиком, ассоциированным с DNAI. Например, UPF2 3104 ассоциирована как с DNAI1 3110, так и с DNAI2 3112. Таким образом, UPF2 3104 выполнена с возможностью направлять трафик в направлении обоих DNAIs.

Информация отображения, сконфигурированное в NEF, PCF и SMF, иллюстрируется ниже:

@ NEF: расположение приложения ←→ ID профилирования маршрутизации

@ PCF: ID профиля маршрутизации → DNAIs;

DNAI ←→ ID профиля управления трафиком

@ SMF: идентификатор профиля управления трафиком →UPFs

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

В проиллюстрированных вариантах осуществления по фиг. 31, применяют минимальный набор информации, доступной для каждого из различных типов сетевых функций. AF должна иметь доступ к местоположению приложения (например, с точки зрения транспортного адреса или сетевого адреса местоположения приложения). DNAI должен иметь доступ к профилям маршрутизации, ассоциированным с местоположением приложения, с которым ассоциирован. UPF должна иметь доступ к профилям управления трафиком DNAIs, с которыми ассоциирована. Конфигурирование этих узлов и функций выполняют таким образом, чтобы они обеспечивались этой информацией, или обеспечивался доступ к этой информации, что может быть выполнено с помощью любой из множества различных функций плоскости управления, таких как, по меньшей мере, одной из следующих функций: сетевой менеджер, менеджер сегмента, менеджер услуги и AF. Например, AF может предоставлять необходимую информацию для DNAI, в то время как функция плоскости управления предоставляет необходимую информацию для NEF, PCF, SMF и UPF.

N6 информация туннеля, которая могла быть предоставлена SMF, используется UPF для установления N6 туннеля и для определения обработки, применяемой к пакетам UL, отправленным через N6 туннель. N6 информация туннеля может включать в себя тип туннеля, такой как IP- туннель, Ethernet туннель, IPv6/UDP туннель и т.д. Может включать в себя информацию об идентификаторе или адресе конечной точки туннеля, номер порта и другие параметры протокола туннеля. Параметры управления трафиком могут быть получены с использованием идентификатора профиля управления трафиком (который сам может быть получен из функции, такой как SMF). Параметры управления трафиком могут быть получены из локальной конфигурации. Если параметры управления трафиком предварительно не сконфигурированы локально в UPF, UPF может получить их из функции, такой как SMF. Если параметры управления трафиком предоставлены SMF для UPF, идентификатор профиля управления трафиком может не предоставляться для UPF SMF. Пакеты, отправленные через N6 туннель, могут быть инкапсулированы, и информация управления трафиком может быть встроена во внешний заголовок. Внешний заголовок также может включать в себя идентификатор обработки, которая должна применяться для пакетов UL.

Как будет понятно, способ, которым трафик в UP маршрутизируется и обрабатывается, может быть сконфигурирован CP функциями. Для маршрутизации трафика под влиянием приложения процесс конфигурации может начинаться с того, что AF выполняет процедуру запроса отправки уведомления о местоположении приложения в сеть. AF может предоставлять местоположение приложения (например, в транспортном адресе) и информацию о N6 туннеле (если есть) в NEF. NEF может сопоставить местоположение приложения, полученное от AF, с профилем маршрутизации. Затем NEF может отправлять идентификатор профиля маршрутизации и информацию о N6 туннеле в PCF. PCF может сопоставить идентификатор профиля маршрутизации хотя бы с одним DNAI. Идентификатор профиля маршрутизации также может быть сопоставлен с профилями управления трафиком, например, посредством сопоставленного, по меньшей мере, одного DNAI. На основе этих отображений может быть сформирована политика управления трафиком. Политика управления трафиком обычно указывает один или несколько идентификаторов профиля управления трафиком, идентификатор профиля маршрутизации и информацию о N6 туннеле. Политика управления трафиком может также содержать другую информацию, такую как условия действительности.

Для трафика, не относящегося к IP, обычно требуется информация о N6 туннеле. Для IP-трафика это может быть необязательным. Если N6 туннель не используют при обработке IP-трафика, параметры маршрутизации трафика в профиле управления трафиком и в профиле маршрутизации вместе могут описывать, как маршрутизировать трафик от конца к концу по N6.

Далее приведено описание примера влияния приложения на маршрутизацию трафика во время процедуры установления сеанса (или процедуры изменения сеанса). Процесс может начаться с отправки PCF политики управления трафиком в SMF. SMP может затем сопоставить идентификаторы профиля управления трафиком (обычно содержащиеся в политике управления трафиком, но при необходимости предоставляемые вместе с политикой) в UPF. Затем PCF может выполнить процесс выбора UPF/управления трафиком и предоставить выбранный идентификатор профиля управления трафиком и информацию о N6 туннеле (переносимую политикой) в UPF, выбранный для PDU сеанса. SMF может компилировать/обрабатывать информацию о N6 туннеле перед отправкой ее в UPF, например, генерируя заголовок туннеля для UPF, чтобы применять к пакетам UL. SMF также может генерировать шаблон пересылки трафика. TFT может использоваться UPF для сопоставления N6 туннеля с трактом в UP для трафика DL.

SMF может отправлять уведомление в NEF о любом изменении N6 туннеля (например, изменении конечной точки N6 туннеля из-за повторного выбора UPF). SMF также может отправлять уведомление в NEF, чтобы информировать NEF об изменении управления трафиком, которое может включать в себя изменения, по меньшей мере, одного из отображений DNAI и идентификатора профиля маршрутизации. NEF может сопоставить DNAI с транспортным адресом и идентификатором профиля маршрутизации с адресом трафика соответствующего местоположения приложения. NEF может затем предоставить информацию, ассоциированную с изменением N6 туннеля и изменением управления трафиком (после отображения информации), в AF.

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

Способ управления трафиком данных сеансов блока протокольных данных в сети, причем способ содержит объект плоскости управления, доступный в сети:

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

передачу уведомления о местоположении AS для определения местоположения AS.

В некоторых вариантах осуществления перед тем, как объект плоскости управления передает уведомление о местоположении AS, способ дополнительно содержит аутентификацию объекта плоскости управления AS контроллера.

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

В некоторых вариантах осуществления уведомление о местоположении AS содержит уведомление о перемещении AS, которое изменяет существующее местоположение PDU сеанса.

В некоторых вариантах осуществления уведомление о местоположении AS содержит уведомление о местоположении AS, которое устанавливает местоположение будущего PDU сеанса.

В некоторых вариантах осуществления уведомление о перемещении AS передают в функцию управления сеансом (SMF), чтобы сконфигурировать управление трафиком для трафика данных в перемещенную AS.

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

Способ управления трафиком данных сеанса блока протокольных данных (PDU), которым обмениваются с устройством пользователя (UE), подключенным к сети, причем способ содержит объект плоскости управления, доступный в сети:

принимают запрос PDU сеанса от UE;

проверяют контекст UE и авторизуют запрос сеанса на основании данных подписки пользователя и, если авторизован, способ дополнительно содержит:

выбор и установку тракта пользовательской плоскости (UP) для запрошенного PDU сеанса;

передачу ответа на запрос PDU сеанса в UE.

В некоторых вариантах осуществления запрос PDU сеанса включает в себя идентификатор сеанса.

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

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

Способ для подключения UE к сети, причем способ содержит функцию управления сеансом, доступную в сети:

принимать запрос PDU сеанса из UE;

выбирать сквозной тракт плоскости пользователя (UP) для PDU сеанса;

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

отправлять узлу доступа (AN) запрос на установку соединения PDU сеанса для UE, соответствующего выбранному сквозному UP тракту.

В некоторых вариантах осуществления AN содержит обслуживающую AN, которая приняла запрос PDU сеанса от UE и перенаправила запрос PDU сеанса в SMF.

В некоторых вариантах осуществления запрос PDU сеанса указывает местоположение функции плоскости пользователя (UPF) привязки и местоположение функции приложения.

Электронное устройство содержит:

сетевой интерфейс;

процессор;

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

Способ управления трафиком данных сеанса блока протокольных данных в сети, причем способ содержит функцию воздействия на сеть (NEF), доступную в сети:

выбор функции управления политикой (PCF), доступной в сети;

передачу в PCF запроса обновления политики уведомления о выборе пользовательской плоскости (UP); и

прием ответа обновления политики уведомления о выборе UP.

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

передачу ответа о подписке на уведомления о выборе UP.

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

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

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

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

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

информацию о политике оператора или события; и

требования к трафику приложений, поддерживаемых объектом функции приложения.

Способ установления PDU сеансом, выполняемого сетевым объектом, выполняющимся в блоке обработки сетевого узла сети связи, содержит сетевой объект, выполняющий этапы:

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

передачу в функцию воздействия на сеть (NEF) запроса аутентификации/авторизации от имени UE;

прием из NEF ответа аутентификации/авторизации; и

авторизацию PDU сеанса на основании ответа аутентификации/авторизации.

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

В некоторых вариантах осуществления сетевой объект передает запрос аутентификации/авторизации стороннему объекту через NEF.

В некоторых вариантах осуществления сетевой объект принимает ответ аутентификации/авторизации от стороннего объекта через NEF.

Сетевой узел выполнен с возможностью устанавливать PDU сеанс в сети связи, причем сетевой узел содержит:

процессор, выполненный с возможностью обеспечить сетевому узлу:

принимать из UE запрос сеанса, включающий в себя идентификатор приложения;

передавать в функцию воздействия на сеть (NEF) запрос аутентификации/авторизации от имени UE;

принимать от NEF ответ аутентификации/авторизации; и

авторизовать PDU сеанс на основании ответа аутентификации/авторизации.

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

В некоторых вариантах осуществления сетевой узел передает запрос аутентификации/авторизации стороннему объекту через NEF.

В некоторых вариантах осуществления сетевой узел принимает ответ аутентификации/авторизации от стороннего объекта через NEF.

Способ для установления PDU сеанса, выполняемого сетевым объектом, выполняющимся в блоке обработки сетевого узла сети связи, содержащий сетевой объект, выполняющий этапы:

прием от UE запроса сеанса;

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

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

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

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

передачу запроса аутентификации/авторизации стороннему объекту через NEF.

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

Сетевой узел выполнен с возможностью устанавливать PDU сеанс в сети связи, причем сетевой узел содержит:

процессор, выполненный с возможностью обеспечивать возможность сетевому узлу:

принимать от UE запрос сеанса;

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

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

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

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

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

Способ установления PDU сеанса, выполняемого сетевым объектом, выполняющимся в блоке обработки сетевого узла сети связи, содержащий сетевой объект, выполняющий этапы:

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

получение правил PCC, ассоциированных с идентификатором приложения; и

конфигурирование политик обработки трафика приложений для PDU сеанса на основании полученных правил PCC.

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

Сетевой узел выполнен с возможностью устанавливать PDU сеанс в сети связи, причем сетевой узел содержит:

процессор, позволяющий сетевому узлу:

принимать от UE запрос сеанса, включающий в себя идентификатор приложения;

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

конфигурировать политики обработки трафика приложения для PDU сеанса на основании полученных правил PCC.

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

Способ установления PDU сеанса, выполняемого сетевым объектом, выполняющимся в блоке обработки сетевого узла сети связи, содержащий сетевой объект, выполняющий этапы:

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

выбор функции приложения (AF) на основании запроса аутентификации/авторизации третьей стороны; и

передачу на выбранную AF стороннего запроса аутентификации/авторизации.

В некоторых вариантах осуществления сетевой объект содержит функцию воздействия на сеть (NEF).

В некоторых вариантах осуществления объект управления сеансом содержит функцию управления сеансом (SMF).

В некоторых вариантах осуществления способ дополнительно содержит:

прием ответа аутентификации/авторизации из выбранной AF.

В некоторых вариантах осуществления способ дополнительно содержит:

передачу ответа аутентификации/авторизации объекту управления сеансом.

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

В некоторых вариантах осуществления сетевой объект и объект управления сеансом являются функциями базовой сети, и в котором выбранная AF является внешней по отношению к базовой сети.

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

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

Изобретение относится к области обмена информацией управления плоскости пользователя (UP) между функцией приложения (AF), поддерживающей одно или несколько приложений, и функцией управления сегментом (SMF), выполненной с возможностью управлять потоками трафика в данном сегменте сети. Техническим результатом является обеспечение того, что соглашения об уровне предоставления услуги (SLAs) могут быть удовлетворены. Для этого обмен информацией управления UP может быть инициирован либо от AF, либо от SMF. В случае инициированного AF обмена информацией, информация управления UP, предоставляемая AF, может содержать требования к трафику приложений, поддерживаемых AF. В случае инициированного SMF обмена информацией, информация управления UP, предоставляемая SM, может содержать информацию или события политики оператора, и AF может направлять ответ с информацией о требованиях к трафику приложений, поддерживаемых AF. 14 н. и 36 з.п. ф-лы, 40 ил.

1. Способ управления уведомлением по подписке, причем способ содержит:

получение с помощью функции управления сеансом (SMF) информации из функции управления политикой (PCF), при этом информация представляет собой политику, ассоциированную с подпиской на уведомление о выборе или повторном выборе плоскости пользователя (UP), из функции приложения (AF); и,

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

2. Способ по п. 1, в котором информация указывает тип уведомления.

3. Способ по любому из пп. 1 и 2, в котором уведомление содержит местоположение приложения.

4. Способ по любому из пп.1-3, в котором уведомление отправляют без участия PCF.

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

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

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

6. Функциональный блок по п. 5, в котором информация, полученная из AF, указывает тип уведомления.

7. Функциональный блок по любому из пп. 5 и 6, в котором уведомление содержит местоположение приложения.

8. Функциональный блок по любому из пп.5-7, в котором уведомление отправляют без участия PCF.

9. Способ управления уведомлением по подписке, причем способ содержит:

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

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

10. Способ по п. 9, в котором запрос содержит тип уведомления.

11. Способ по любому из пп. 9 и 10, в котором сообщение включает в себя местоположение приложения.

12. Способ по любому из пп.9-11, в котором передача сообщения не включает PCF.

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

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

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

14. Функциональный блок по п. 13, в котором запрос содержит тип уведомления.

15. Функциональный блок по любому из пп. 13 и 14, в котором принятое сообщение содержит местоположение приложения.

16. Функциональный блок по любому из пп.13-15, в котором передача сообщения не включает PCF.

17. Способ уведомления, выполняемого функцией хранилища данных, содержащий:

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

хранение информации, ассоциированной с запросом AF, данными пользователя и данными политики; и

уведомление функции управления политикой (PCF) об обновлении информации, ассоциированной с запросом AF, в соответствии с подпиской от PCF.

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

19. Способ по п. 17 или 18, в котором информация, ассоциированная с запросом AF, содержит информацию, передаваемую в запросе AF, или информацию, ассоциированную с запросом AF, отображают на информацию, передаваемую в запросе AF.

20. Способ по любому из пп. 17-19, дополнительно содержащий

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

в котором этап уведомления включает уведомление каждой из PCF об обновлении информации, ассоциированной с запросом AF.

21. Способ по любому из пп. 17-20, в котором информация, ассоциированная с запросом AF, должна влиять на решения о маршрутизации функции управления сеансом (SMF) для трафика PDU сеансов.

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

прием от функции сетевого воздействия (NEF) информации, ассоциированной с запросом AF;

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

уведомление функции управления политикой (PCF) об обновлении информации, ассоциированной с запросом AF, в соответствии с подпиской от PCF.

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

24. Функциональный блок хранилища данных по п. 22 или 23, в котором информация, ассоциированная с запросом AF, содержит информацию, передаваемую в запросе AF, или информацию, ассоциированную с запросом AF, отображают на информацию, передаваемую в запросе AF.

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

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

в котором этап уведомления включает уведомление каждой из PCF об обновлении информации, ассоциированной с запросом AF.

26. Функциональный блок хранилища данных по любому из пп. 22-25, в котором информация, ассоциированная с запросом AF, должна влиять на решения функции управления сеансом (SMF) маршрутизации для трафика PDU сеансов.

27. Способ управления уведомлением по подписке, содержащий:

прием посредством функции управления сеансом (SMF) запроса на подписку уведомления о событии управления плоскостью пользователя (UP) от функции приложения (AF); и

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

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

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

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

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

30. Функциональный блок по п. 29, в котором сообщение уведомления о событии управления UP дополнительно включает в себя тип уведомления, указывающий, является ли уведомление о событии управления UP либо ранним уведомлением, либо поздним уведомлением.

31. Способ управления уведомлением, содержащий:

прием (308) с помощью функции управления политикой (PCF) сообщения запроса, включающего в себя контент запроса, включающего в себя потенциальные местоположения приложения и соответствующие N6 требования туннелирования точка-точка; и

уведомление (316) посредством PCF функции управления сеансом (SMF) обновленной политики управления трафиком для конфигурирования блока данных протокола (PDU) сеанса привязки, причем обновленная политика управления трафиком включает в себя N6 требования туннелирования точка-точка и указание потенциальных местоположений приложения, ассоциированных с N6 требованиями к туннелированию точка-точка.

32. Способ по п. 31, в котором N6 требования к туннелированию точка-точка указывают тип туннеля и соответствующие параметры протокола туннелирования.

33. Способ по п. 32, в котором параметры протокола туннелирования включают в себя один или несколько из: адрес конечной точки туннеля, идентификатор конечной точки туннеля и номер порта в местоположении приложения.

34. Способ по любому из пп. 31-33, в котором контент запроса принимают посредством PCF из функции приложения (AF).

35. Способ по любому из пп. 31-34, в котором SMF заключается в подписке на уведомление события обновления политики.

36. Способ по любому из пп. 31-35, дополнительно содержащий:

верификацию посредством PCF условия пространственной достоверности, содержащегося в сообщении запроса на основании информации местоположения UE; и

обновление посредством PCF политики управления трафиком на основании результата верификации.

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

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

уведомление функции управления сеансом (SMF) обновленной политики управления трафиком для конфигурирования блока данных протокола (PDU) сеанса привязки, причем обновленная политика управления трафиком включает в себя N6 требования туннелирования точка-точка и указание потенциальных местоположений приложения, ассоциированного с N6 требованиями туннелирования точка-точка.

38. Функциональный блок по п. 37, в котором N6 требования туннелирования точка-точка указывают тип туннеля и соответствующие параметры протокола туннелирования.

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

40. Функциональный блок по любому из пп. 37-39, в котором контент запроса принимают из функции приложения (AF).

41. Функциональный блок по любому из пп. 37-40, в котором SMF заключается в подписке на уведомление события обновления политики.

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

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

обновление политики управления трафиком на основании результата верификации.

43. Способ управления уведомлением, содержащий:

прием посредством функции управления сеансом (SMF) из функции управления политикой (PCF) политики управления трафиком, включающей в себя N6 требования туннелирования точка-точка;

вычисление посредством SMF информации N6 туннеля точка-точка на основании N6 требований туннелирования точка-точка; и

конфигурирование посредством SMF информации N6 туннеля точка-точка в блок данных протокола (PDU) сеанса привязки.

44. Способ по п. 43, в котором N6 требования туннелирования точка-точка указывают одно или более из: тип туннеля и относящиеся параметры протокола туннелирования.

45. Способ по п. 44, причем информация N6 туннеля точка-точка включает в себя одно или более из:

шаблон переадресации трафика (TFT) для отображения N6 туннеля на плоскости пользователя (UP) тракт для пакетов нисходящей линии связи (DL), и

инструкции обработки пакета для UL пакетов.

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

прием из PCF политики управления трафиком, включающей в себя N6 требования туннелирования точка-точка;

вычисление информации N6 туннеля точка-точка на основании N6 требований туннелирования точка-точка; и

конфигурирование информации N6 туннеля точка-точка в PDU сеанс привязки.

47. Функциональный блок по п. 46, в котором N6 требования туннелирования точка-точка указывают одно или более из: тип туннеля и соответствующие параметры протокола туннелирования.

48. Функциональный блок по п. 46, в котором информация N6 туннеля точка-точка включает в себя одно или более из:

шаблон переадресации трафика (TFT) для отображения N6 туннеля на UP тракт для DL пакетов, и

инструкции обработки пакета для UL пакетов.

49. Система управления уведомлением, содержащая по меньшей мере одно из:

функция для управления уведомлением по подписке по одному из пп. 5-8;

функция для управления уведомлением по подписке по одному из пп. 13-16;

функция хранилища данных по одному из пп. 22-26;

функция по одному из пп. 29-30;

функция по одному из пп. 37-42; и

функция по одному из пп. 46-48.

50. Постоянный машиночитаемый носитель, хранящий инструкции, которые при выполнении одним или более процессорами побуждают один или более процессоров выполнять способ по меньшей мере по одному из пп. 1-4, 9-12, 17-21, 27-28, 31-36 и 43-45.