RU2695507C2 - Допуск сеанса к услуге виртуальной сети - Google Patents

Abstract

Изобретение относится к способу, устройству и системе допуска пользовательского сеанса к виртуальной сети. Технический результат заключается в обеспечении допуска пользовательского оборудования к виртуальной сети. В способе выполняют прием, в функции управления мобильностью в домене базовой сети, запроса присоединения от пользовательского оборудования, ассоциированного с виртуальной сетью; выполнение запроса аутентификации с пользовательским оборудованием и функцией аутентификации, ассоциированной с и находящейся в виртуальной сети и вне домена базовой сети; и допуск пользовательского оборудования к пользовательскому сеансу в виртуальной сети в ответ на успешное завершение запроса аутентификации. 3 н. и 22 з.п. ф-лы, 11 ил.

Description

РОДСТВЕННЫЕ ЗАЯВКИ

[0001] Настоящая заявка испрашивает приоритет предварительной патентной заявки США № 62/169,425, поданной 1 июня 2015, озаглавленной ʺAdmission of an Individual Session/User Who Has Already Subscribed to a Virtual Network Serviceʺ, все содержание которой включено в настоящий документ посредством ссылки, и непредварительной патентной заявки США № 15/169,469, поданной 31 мая 2016, содержание которой также включено в настоящий документ посредством ссылки.

ОБЛАСТЬ ТЕХНИКИ

[0002] Настоящее раскрытие относится к виртуальным сетям (VN) и, более конкретно, к процессу допуска пользовательского сеанса к VN.

ПРЕДШЕСТВУЮЩИЙ УРОВЕНЬ ТЕХНИКИ

[0003] В обычных мобильных сетях, сеть радиодоступа (RAN) образует пару с основанной, как правило, на проводной линии базовой сетью. RAN обеспечивает соединения с мобильными устройствами, такими как пользовательское оборудование (UE), через использование сетевых точек доступа (AP), соединенных с базовой сетью через транзитное соединение. В существующих мобильных сетях третьего/четвертого поколения (3G/4G), RAN и базовая сеть тесно взаимосвязаны. Обычно, базовой сетью и RAN владеет один объект, который предоставляет услугу конечным пользователям, и может предлагать платформу, через которую оператор мобильной виртуальной сети (MVNO) может предоставлять услуги своим собственным конечным пользователям.

[0004]

[0005] В мобильных сетях, 4G сетях, таких как совместимые со стандартами Долгосрочного развития (LTE), установленными Проектом партнерства 3-го поколения (3GPP), UE начинает процесс присоединения к сети путем передачи запроса присоединения (Attach Request). Этот запрос принимается посредством eNodeB, который затем отправляет запрос к объекту управления мобильностью, который находится в базовой сети. Выполняются аутентификация UE, установка безопасности уровня, не относящегося к доступу (NAS), и установка безопасности AS. Установка безопасности AS является единственным процессом, который выполняется между UE и объектами, основанными на RAN (в данном случае eNodeB). Поскольку сетевые операторы, как правило, владеют инфраструктурой в RAN, а также базовой сети и используют эти ресурсы для предоставления услуги конечным пользователям, процедуры управления аутентификацией и доступом выполняются исключительно в базовой сети.

[0006] Больше не является обязательным, чтобы один объект владел и осуществлял администрирование всеми ресурсами и инфраструктурой для обеспечения услуг связности и сетевого взаимодействия. Оператор мобильной виртуальной сети (MVNO) предоставляет услуги своим абонентам с использованием предоставляемых услуг и ресурсов сетевого оператора (также упоминаемого как провайдер услуг). Обычно, MVNO предоставляет информацию аутентификации и авторизации сетевому оператору, так что эта информация может использоваться в базовой сети сетевого оператора, когда клиент MVNO соединяется с сетевой точкой доступа. Некоторые MVNO имеют отношения с более чем одним провайдером услуг. Это позволяет MVNO с выгодой для себя использовать карты охвата (покрытия) множества провайдеров. MVNO может иметь возможность создавать более широкие зоны покрытия, где карты охвата провайдеров услуг не перекрываются, и обеспечивать возможность более глубокого или с большей избыточностью покрытия, где области обслуживания перекрываются. Использование сети провайдера услуг для потоков трафика, ассоциированных с MVNO, обычно регулируется соглашениями уровней обслуживания (SLA).

[0007] Так как сетевые архитектуры развиваются, RAN может быть ассоциирована не с единственной базовой сетью. RAN, которая используется для доступа к ряду сегментов базовой сети (или одной базовой сети, которая использует сетевое сегментирование), будет эффективно ассоциирована с рядом различных базовых сетей. Когда UE присоединяется, процедура присоединения, которая в сильной степени основывается на доступе к ресурсу в базовой сети, может оказаться невыполнимой. Имеются предложения и подготовки стандартов (такие как управление и координация (MANO) виртуализацией сетевых функций (NFV), совместно NFV-MANO, как описано, например, Европейским Институтом по стандартизации в области телекоммуникаций (ETSI), чтобы облегчить сетевую архитектуру, когда провайдер услуг (SP) может предоставлять виртуальную сеть (VN) в качестве услуги своим клиентам с использованием ресурсов виртуализированной инфраструктуры. В таком сценарии, даже SP, обеспечивающий информацию аутентификации и авторизации, может находиться в VN, а не в базовой сети, которая непосредственно доступна для RAN.

[0008] Существует потребность в способах для допуска индивидуальных сеансов, которые принадлежат к VN или к конкретной базовой сети (или сегменту базовой сети, как это может иметь место). Имеется потребность в инфраструктуре и способе для допуска индивидуальных сеансов в соответствии с требованиями либо релевантной базовой сети, либо релевантной VN, SLA и требованиями индивидуального сеанса.

КРАТКОЕ ОПИСАНИЕ СУЩНОСТИ ИЗОБРЕТЕНИЯ

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

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

[0011] Аспект раскрытия обеспечивает способ допуска сеанса от пользовательского устройства, подписанного на услугу оператора виртуальной сети. Способ включает в себя прием запроса услуги от упомянутого пользовательского устройства в точке доступа и выбор сетевой функции аутентификации и авторизации AAF для подтверждения, что пользовательское устройство авторизовано для запрошенной услуги, и передачу ответа к выбранной AAF. AAF, которая обрабатывает запрос, может находиться у оператора виртуальной сети (VNO). Однако VNO может совместно использовать свою базу данных аутентификации и авторизации (AA) с другими сетевыми объектами (например, провайдерами телекоммуникационных услуг связности (TCSP) или InP) и разрешать этим объектам выполнять функции AA.

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

[0013] Аспект раскрытия обеспечивает способ допуска сеанса в виртуальной сети (VN), установленной в многоуровневой сети. Способ включает в себя выполнение проверки допуска для запроса, принятого точкой доступа (AP), находящейся во владении первого объекта многоуровневой сети, проверку допуска с использованием AAF хоста, причем хост имеет принятую информацию AA относительно установленной VN оператором виртуальной сети (VNO). Такой способ применяется, когда прямая ассоциация между VNO и первым объектом не установлена. В некоторых вариантах осуществления, хост находится у VNO. В некоторых вариантах осуществления, информация AA относительно установленной VN находится у VNO. В некоторых вариантах осуществления, хост находится в сети второго объекта многоуровневой сети, причем второй объект имеет ассоциацию как с VNO, так и с первым объектом. В некоторых вариантах осуществления, хост получает информацию АА относительно установленной VN от VNO. В некоторых вариантах осуществления, хост находится в сети первого объекта и сконфигурирован для получения информации АА относительно установленной VN от второго объекта многоуровневой сети, второй объект имеет ассоциацию как с VNO, так и с первым объектом. В некоторых вариантах осуществления, этап выполнения проверки допуска включает в себя пересылку запроса от AP в первом объекте к хосту в сети второго объекта многоуровневой сети, причем второй объект имеет ассоциацию как с VNO, так и с первым объектом. В некоторых вариантах осуществления, проверка допуска включает в себя аутентификацию и авторизацию. В некоторых вариантах осуществления, проверка допуска дополнительно включает в себя проверку управления допуском, чтобы гарантировать, что доступны достаточные сетевые ресурсы. В некоторых вариантах осуществления, проверка допуска дополнительно включает в себя проверку ведения учета.

[0014] Другой аспект раскрытия обеспечивает способ допуска сеанса в виртуальной сети (VN), установленной в пределах многоуровневой сети. Такой способ включает в себя прием запроса соединения в точке доступа (AP), находящейся во владении провайдера инфраструктуры (InP) многоуровневой сети. Способ дополнительно включает в себя запрашивание посредством AP проверки допуска, причем проверка допуска использует AAF хоста, причем хост принимает информацию АА относительно VN от оператора виртуальной сети (VNO). В таком способе, запрашивание посредством AP проверки допуска включает в себя запрашивание посредством AP проверки управления допуском от провайдера телекоммуникационных услуг связности (TCSP) многоуровневой сети, причем TCSP имеет ассоциацию как с VNO, так и с InP. В некоторых вариантах осуществления, способ дополнительно включает в себя прием ответа управления допуском от TCSP, относительно того, доступны ли достаточные ресурсы для запроса соединения в сети TCSP. В некоторых вариантах осуществления, хост находится в InP, AAF предоставила информацию АА относительно VN от TCSP, который, в свою очередь, принял информацию АА относительно установленной VN от VNO. В некоторых вариантах осуществления, хост находится в TCSP, и запрашивание посредством AP проверки допуска содержит передачу запроса на хост, находящийся в TCSP, чтобы выполнять аутентификацию и авторизацию для сеанса.

[0015] Другой аспект раскрытия обеспечивает способ допуска сеанса в виртуальной сети (VN) обеспечиваемой провайдером телекоммуникационных услуг связности (TCSP) для оператора виртуальной сети (VNO). Такой способ включает в себя прием запроса допуска для сеанса в TCSP от провайдера инфраструктуры (InP), который владеет точкой доступа, которая приняла запрос соединения от пользовательского оборудования (UE), причем InP не ассоциирован с VNO. Такой способ дополнительно включает в себя обеспечение ответа к InP. В таком способе, запрос допуска запрашивает проверку допуска, включающую в себя проверку управления допуском. Такая проверка допуска использует AAF хоста, причем хост принял информацию АА относительно установленной VN от оператора виртуальной сети (VNO). В некоторых вариантах осуществления, способ также включает в себя выполнение посредством TCSP проверки управления допуском, чтобы определить, доступны ли достаточные ресурсы для запрашиваемого сеанса в сети TCSP. В некоторых вариантах осуществления, хост находится в TCSP, AAF приняла информацию АА относительно установленной VN от VNO. В некоторых вариантах осуществления, хост находится в VNO, и дополнительно предусматривается запрашивание посредством TCSP аутентификации и авторизации от VNO. В некоторых вариантах осуществления, TCSP не ассоциирован с InP, и принятый запрос допуска от InP был перенаправлен к TCSP от второго TCSP, и второй TCSP имеет ассоциацию с InP. В некоторых вариантах осуществления, TCSP выполняет согласование с вторым TCSP, чтобы установить сквозной канал для допуска сеанса.

[0016] Другой аспект раскрытия обеспечивает хост, который включает в себя процессор и машиночитаемую память, хранящую машинно-исполняемые инструкции, которые, при исполнении процессором, реализуют AAF для выполнения проверки допуска для запроса соединения, принятого точкой доступа (AP), находящейся во владении провайдера инфраструктуры (InP), AAF использует информацию АА относительно виртуальной сети (VN), установленной провайдером телекоммуникационных услуг связности (TCSP) для оператора виртуальной сети (VNO). Такой хост используется, когда InP и VNO являются неассоциированными. В некоторых вариантах осуществления, хост находится в VNO, и машинно-исполняемые инструкции конфигурируют хост, чтобы принимать запрос соединения от TCSP, авторизовать и аутентифицировать запрос и предоставлять ответ к TCSP. В некоторых вариантах осуществления, хост находится в TCSP, и машинно-исполняемые инструкции конфигурируют хост, чтобы принимать запрос соединения от AP, авторизовать и аутентифицировать запрос с использованием информации, принятой от VNO, и предоставлять ответ к AP. В некоторых вариантах осуществления, хост находится в TCSP, и машинно-исполняемые инструкции конфигурируют хост, чтобы принимать запрос от AP и пересылать запрос к VNO, чтобы авторизовать и аутентифицировать запрос. В некоторых вариантах осуществления, хост находится в InP, и машинно-исполняемые инструкции конфигурируют хост, чтобы принимать запрос от AP и авторизовать и аутентифицировать запрос с использованием информации АА, принятой от TCSP. В некоторых вариантах осуществления, хост находится в InP, и машинно-исполняемые инструкции конфигурируют хост, чтобы принимать запрос от AP и пересылать запрос к TCSP, чтобы авторизовать и аутентифицировать запрос.

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

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

Фиг. 1 - блок-схема, иллюстрирующая сетевую архитектуру.

Фиг. 2 - блок-схема, иллюстрирующая отношения в сетевой архитектуре.

Фиг. 3 - блок-схема, иллюстрирующая отношения в сетевой архитектуре.

Фиг. 4 - блок-схема, иллюстрирующая второй набор коммуникаций в отношениях сетевой архитектуры (упоминается как опция В).

Фиг. 5 - блок-схема, иллюстрирующая отношения в сетевой архитектуре (упоминается ниже как опция С).

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

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

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

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

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

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

ОПИСАНИЕ ВАРИАНТОВ ОСУЩЕСТВЛЕНИЯ

[0019] Фиг. 1 является диаграммой, иллюстрирующей разделение ролей (функций), которые могут возникнуть в будущих сетевых архитектурах. Такая несвязанная сетевая архитектура может быть применима к беспроводным сетям следующего поколения, включая так называемые сети связи пятого поколения (5G). В такой несвязанной сети, инфраструктура сетевого доступа может быть изолирована как отдельный объект, указанный здесь как провайдер инфраструктуры (InP). Функциональность RAN, предоставляемая посредством InP, может быть отделена от базовой сети в другой сетевой домен, так что ею можно администрировать и управлять отдельно от базовой сети. Функции базовой сети (CN) могут быть предоставлены провайдером услуг, упоминаемым также как провайдер телекоммуникационных услуг связности (TCSP). В некоторых областях, InP может служить в качестве сети доступа (или части сети доступа) множества различных TCSP. Услуги, встречающиеся клиентам, показаны в следующих примерах как предоставляемые оператором виртуальной сети (VNO). Понятно, что эти подразделения сети могут осуществляться чисто по причинам администрирования, или они могут быть полностью различными объектами. InP может иметь очень малую сеть доступа, такую как набор малых точек доступа в здании. InP может предоставлять доступ своим ресурсам ряду различных TCSP. Это имеет эффект одной RAN, обслуживающей множество CN. В другом примере, один InP может обслуживать множество CN, которые реально являются, каждая, сегментами одной CN. Это может произойти, когда тот же самый объект владеет как CN, так и RAN (например, TCSP и InP являются одним и тем же), но когда RAN является отдельным доменом, так что она может обслуживать множество различных сегментов CN.

[0020] На фиг. 1, сетевая архитектура, в соответствии с вариантом осуществления, включает в себя первого InP₁ 130, имеющего зону покрытия 140, и второго InP₂ 135, имеющего зону покрытия 145. Каждый InP владеет ресурсами связности, такими как AP, причем AP, обозначенные черным, ассоциированы с InP₂ 135, а AP, обозначенные белым, ассоциированы с InP₁ 130. TCSP A 150 использует часть ресурсов InP₁ 130 и InP₂ 135, чтобы предоставлять доступ RAN к функциям базовой сети, которые он предоставляет. Условия, на которых InP предоставляет услуги доступа для TCSP, могут регулироваться соглашением об уровне обслуживания (SLA). TCSP A 150 использует ресурсы InP вместе с другими сетевыми ресурсами (включая ресурсы, которыми он владеет), чтобы предоставлять функциональность базовой сети и радиодоступа различным VNO. Первый и второй VNO (VNO 1 110 и VNO 2 115) приобретают услуги связности от TCSP A 150, чтобы предоставлять услуги своим соответствующим совокупностям конечных пользователей. Каждый VNO 110, 115 имеет свою собственную совокупность конечных пользователей, каждая из которых совместно обозначена как клиент 1 120 и клиент 2 125, соответственно. Другие варианты осуществления могут содержать дополнительных TCSP, таких как TCSP B 160. Кроме того, специалистам в данной области техники должно быть понятно, что не имеется взаимно однозначного соответствия между InP 130, 135 и VNO 110, 115, несмотря на то, что диаграмма иллюстрирует два для каждого. Любое количество InP, TCSP и VNO может поддерживаться.

[0021] Совокупности конечных пользователей могут содержать, в качестве неограничительного примера, устройства, ассоциированные с одним или более из компании оповещения о тревоге, компании сенсорных устройств, отдела полиции, пожарной службы, службы электронного мониторинга здоровья и их комбинации. Каждая из этих клиентских групп может заключать договоры с конкретными VNO на услуги виртуальной сети (VN) для своих пользователей/устройств. Альтернативно, VNO 110, 115 могут просто предоставлять услуги отдельным клиентам, которые подписываются на их услуги.

[0022] Каждый VNO может рассматриваться как клиент ресурсов и услуг одного или нескольких TCSP. Ресурсы, требуемые виртуальной сетью, могут в некоторых примерных вариантах осуществления зависеть от типа и функции виртуальной сети.

[0023] При обеспечении услуги клиенту VN, провайдер услуг (например, TCSP) может получить ресурсы инфраструктуры, которые могут не находиться в собственности или не быть всегда доступными для TCSP. Например, TCSP может получать ресурсы от InP, так что клиенту VN могут быть представлены услуги в областях, в которых TCSP не имеет собственных ресурсов RAN. TCSP может агрегировать ресурсы от различных InP, чтобы создавать сетевую топологию, которая включает в себя ресурсы как узла, так и канала связи. Это обеспечивает сквозную услугу для VN, позволяя клиентам VN соединяться с сетью и получать доступ к услугам.

[0024] VNO обычно предоставляют услуги, которые используются конечными пользователями. В некоторых примерах, это включает в себя такие услуги, как поддержка голосовых каналов, мобильных широкополосных (MBB) каналов и других каналов данных. Некоторые VNO обеспечивают поддержку в соответствии с конкретными потребностями, такими как трафик связи машинного типа (MTC), или определенными клиентскими группами, такими как службы чрезвычайного назначения (например, правоохранительных органов, неотложные медицинские службы, пожарные части). TCSP предоставляют услуги связности, используемые посредством VNO. В некоторых случаях, TCSP может предоставлять функции связности и сетевые функции, которые эквиваленты (или по существу эквивалентны) Evolved Packet Core (развитому пакетному ядру, EPC) как определено посредством 3GPP. В некоторых вариантах осуществления, TCSP распределяет услуги таким образом, чтобы они проявлялись, как если бы VNO имел свою собственную виртуальную сеть. Это может быть осуществлено посредством использования таких методов, как сетевое сегментирование и виртуализация сетевых функций. Одиночная сеть радиодоступа может быть создана посредством использования ряда различных InP. TCSP может создавать карту покрытия путем получения ресурсов RAN от множества различных InP и может, не обязательно, иметь некоторые из своих собственных ресурсов RAN. В некоторых вариантах осуществления, TCSP распределяет по меньшей мере один сетевой сегмент для каждого VNO, чтобы предоставлять VN своим клиентам с сетевым доступом через ресурсы RAN InP.

[0025] Чтобы обеспечить изоляцию трафика и некоторую степень управления, InP может предоставлять ресурсы для TCSP как сетевой сегмент. Сегмент может быть жестким сегментом (фиксированное распределение определенных ресурсов), мягким сегментом (распределение ресурсов может изменяться во времени, либо по количеству ресурсов, либо путем изменения в конкретных ресурсах, которые распределены) или гибридом обоих типов (например, жесткого сегмента, предоставляющего гарантированный уровень услуги, с гибким компонентом поверх него, который может быть обеспечен мягким сегментом). TCSP может компоновать пул ресурсов на основе сегментов, полученных от различных InP. На основе скомпонованного пула ресурсов, TCSP может затем предлагать сетевые услуги для VNO, включая сетевой сегмент, в котором могут быть предоставлены функции базовой сети. Должно быть понятно, что в обычных базовых сетях, функции, такие как домашний абонентский сервер (HSS), являются частью CN, но в несвязанной архитектуре, проиллюстрированной на фиг. 1, база данных, содержащая абонентскую информацию, может находиться в сети VNO. Абонентская база данных может быть реализована на ресурсах, которые получены от TCSP, но она также может находиться в подсети, которая может быть доступной через сегмент, предоставленный посредством TCSP, но не строго внутри него.

[0026] Ресурсы, распределенные для конкретной VN, могут быть статически распределенными, они могут варьироваться вместе с потребностью динамическим способом или гибридным способом, как описано выше. Базовые физические ресурсы могут быть распределены с использованием либо жестких, либо мягких сегментов, так что базовые физические ресурсы могут быть статически выделенными или динамическим выделенными, соответственно.

[0027] Фиг. 2 дополнительно иллюстрирует разделение ролей, которые могут быть присущи будущим сетевым архитектурам. Пул мобильных устройств 270 обслуживается посредством VNO1 210 и VNO2 220. Мобильные устройства, обслуживаемые посредством VNO1 210, указаны элементами 272 белого цвета, а мобильные устройства, обслуживаемые посредством VNO2 220, указаны элементами 271 черного цвета. Термин ʺмобильное устройствоʺ должен пониматься как относящийся к устройствам, которые могут соединяться с мобильной сетью для обслуживания. Устройство использует мобильное соединение, независимо от того, является ли само устройство мобильным. Известным примером мобильного устройства является пользовательское оборудование (UE), такое как телефонный аппарат мобильной сети (например, мобильный телефон). Другие устройства, такие как устройства связи машинного типа (MTC), также упоминаемые как устройства связи ʺот машины к машинеʺ (m2m), также являются примерами мобильных устройств. Понятно, что термины ʺмобильное устройствоʺ and ʺUEʺ используются взаимозаменяемым образом, и использование одного из терминов не должно пониматься в качестве ограничения.

[0028] Как показано на фиг. 2, провайдер инфраструктуры (InP), такой как InP1 260 или InP2 250, предоставляет ресурсы радиодоступа. InP может не иметь в собственности спектр, через который обеспечивается связность, а вместо этого может получать права на использование спектра от владельца 240 спектра. Альтернативно, для InP могут быть предоставлены инструкции от TCSP, чтобы обеспечивать TCSP услугами в определенном спектральном диапазоне. TCSP может получать права на использование спектра от правительства либо посредством соглашения с владельцем 240 спектра. Провайдер телекоммуникационных услуг связности (TCSP) 230 использует ресурсы, полученные от InP, чтобы предоставлять радиодоступ к функциям CN, которые он может предоставлять. В некоторых вариантах осуществления, InP обеспечивает сеть радиодоступа, через которую пользователи могут получать доступ к сетевым функциям, предоставляемым посредством TCSP для VNO. В других вариантах осуществления, InP также могут предоставлять некоторые ресурсы базовой сети.

[0029] VNO будет обычным образом включать в себя AAF, показанные как VN-AA 211 и VN-AA 221, сконфигурированные, чтобы предоставлять услуги AA. VN-AAA может включать в себя или иметь доступ к абонентской базе данных. Специалистам в данной области техники должно быть понятно, что AAF предоставляет услуги авторизации и аутентификации, как те, которые были бы предоставлены функцией аутентификации, авторизации и учета (ААА), совместимой с 3GPP. Опущение функции учета из AAF не должно интерпретироваться как требование того, что это не должно присутствовать, а вместо этого должно быть понятно, что функция учета может предоставляться еще где-либо, хотя она могла бы быть предоставлена в AAF. Если в 3GPP функция AAA усматривает аутентификацию как определение, что устройство, предоставляющее идентификатор, является устройством, ассоциированным с этим идентификатором (устройство есть то, что заявлено таковым), следует иметь в виду, что в некоторых вариантах осуществления функции AA, аутентификация может предусматривать аутентификацию пользователя вместо аутентификации UE. Авторизация относится к определению, следует ли объекту предоставить доступ к запрашиваемой услуге или ресурсу. Аутентификация может также предусматривать определение того, запрещен ли доступ к ресурсу аутентифицированной идентичности (идентификатору) или аутентифицированным учетным данным (мандату) (например, посредством использования черного списка).

[0030] Специалистам в данной области техники должно быть понятно, что TCSP 230 может также включать в себя AAF TCSP-AA 231, сконфигурированную, чтобы предоставлять услуги AA в сети TCSP. TCSP AA может включать в себя данные AA, ассоциированные с абонентами, для поддерживаемых VNO. Это позволяет TCSP предоставлять услуги AA, не требуя прохождения трафика в домен VNO, что может обеспечить возможность более быстрой обработки AA. Кроме того, каждый InP может включать свою собственную локальную AAF 251, 261 для обеспечения услуг AA в RAN. Поскольку мобильное устройство соединяется с RAN, которая может поддерживать множество базовых сетей, может быть выгодным предоставлять услуги AA в RAN вместо исключительного предоставления в CN. Локальная AA, реализованная в InP, может быть поднабором данных AA TCSP. Данные АА TCSP могут быть комбинацией частей данных AA каждого VNO. Если InP предоставляет услугу множеству TCSP, его локальная AAF может хранить данные AA, которые являются комбинацией частей ААF соответствующих TCSP.

[0031] Конфигурирование и допуск VN к TCSP могут быть выполнены любым из ряда различных путей, и конкретный способ, которым VN допускается к TCSP, не является релевантным для последующего обсуждения. Варианты осуществления будут обсуждены в предположении, что VN уже была сконфигурирована и допущена. Если TCSP не предоставляет услугу для VNO, а вместо этого предоставляет услугу непосредственно конечным пользователям или клиентским группам, AAF TCSP будет хранить эквивалент полной базы данных VN AAF.

[0032] Для пояснения, отмечается, что UE может быть допущено, или индивидуальные сеансы для UE могут, каждый, быть допущены отдельно. Следует отметить, что имеются ситуации, в которых UE может быть допущено к сети для одного типа сеанса, но не для другого. Например, UE может быть допущено к конкретному VNO, чтобы получить некоторый тип услуги (например, услуги MBB или расширенного MBB (eMBB)). Тому же самому UE может быть отказано, той же самой сетью, если оно пытается зарегистрироваться на другую услугу, такую как v2x (транспортную услугу), для которой UE не имеет подписки. В этом сценарии, следует отметить, что VNO может предлагать v2x услуги, но не иметь регистрации для данного UE. В других вариантах осуществления, UE может выполнить согласование, чтобы зарегистрироваться для v2x услуги. Или UE может соединиться с другим VNO, чтобы получить v2x услуги.

[0033] Процесс допуска индивидуального сеанса, в соответствии с вариантом осуществления, будет описан ниже. UE соединяется с RAN, обеспечиваемой посредством InP. InP обеспечивает ресурсы для TCSP, на котором хостируется VN, ассоциированная с UE. В этом сценарии, VNO (например, VNO1 210) ассоциирован с TCSP 230. TCSP 230 использует ресурсы RAN, предоставленные посредством InP (например, InP 260). Однако InP1 260 не ассоциирован (т.е., не имеет договорных отношений) с VNO1 201. Иными словами, непосредственная ассоциация между VNO и InP не установлена. TCSP 230 ассоциирован как с InP1 260, так и с VN01 310.

[0034] Как часть передачи запроса соединения, UE представляет учетные данные, которые используются для процесса AA. В некоторых вариантах осуществления, также возникает процесс управления допуском (AC). Три опции, которые будут упоминаться как опция A, опция B и опция C, описаны ниже. Специалистам в данной области техники должно быть понятно, что эти примеры не подразумеваются в качестве исчерпывающих. Кратко, процесс AA может быть выполнен распределенным образом различными объектами в сети и даже объектами в различных доменах сети. Процесс AA включает в себя проверку допуска, которая может включать в себя аутентификацию и авторизацию, как поясняется выше.

[0035] В одном варианте осуществления опции A, процесс AA должен выполняться исключительно посредством VN AAF 211. Опция A обеспечивает VNO полным управлением процессом, так как опция A не связана ни с каким делегированием каких-либо прав или передачей каких-либо данных. Компенсирующей стоимостью для этого управления является то, что процесс AA обычно будет иметь большую латентность (запаздывание) ввиду того, что сообщения для процесса AA проходят через множество сетевых доменов.

[0036] В варианте осуществления опции B, VNO1 210 может делегировать функции AA к TCSP 230. Это может быть сделано, чтобы уменьшить непроизводительные издержки, требуемые VNO1 210, и будет использовать TCSP AAF 231. Однако все еще имеется уровень латентности, создаваемой в такой компоновке, так как InP1 260 должен передавать данные для аутентификации и авторизации к TCSP 230. Дополнительно, это требует, чтобы VNO1 210 предоставлял TCSP 230 достаточно информации, чтобы обрабатывать по меньшей мере одну функцию AA. Это требует доверительного отношения, которое не всегда возможно. Там, где VNO использует множество TCSP (не показано), эта опция может привести к тому, что информация АА совместно используется множеством TCSP. Является вероятным, что TCSP уже выполняет AAF. Данные AA могут быть либо предварительно загружены в TCSP AAF, либо TCSP AAF может заполняться данными AA каждый раз, когда отдельный пользователь или UE аутентифицируется и/или авторизуется. Это постепенное создание данных AAF позволяет VNO передавать данные только по мере необходимости. Данные, сохраненные в TCSP AAF, могут терять силу по истечении срока и будут удалены после приемлемого истечения срока действия, чтобы уменьшить проблемы с обеспечением защиты данных.

[0037] В варианте осуществления опции C, AAF (или ее часть) может располагаться в InP1 260. Наличие локальной AAF 261 будет, как правило, обеспечивать самую низкую латентность (с прямым воздействием на времена допуска), но потребует наибольшего количества делегирований AA посредством VNO 1 210. Также должно быть понятно, что различные части процесса AA должны выполняться на различных объектах.

[0038] VNO может выбрать использование создание экземпляра (реализацию) AAF посредством TCSP или InP (например, с использованием виртуальной машины AA (AA VM)). Это позволяет AAF находиться в TCSP, но AAF управляется посредством VNO. VNO может использовать создание экземпляра AA посредством TCSP для своих нужд, или он может иметь свое собственное. Соглашение VNO-TCSP может позволить TCSP иметь AAF, реализованную в TCSP, чтобы выполнять функции AA от имени VNO. Альтернативно, TCSP может рассылать данные аутентификации VNO в AAF, управляемую посредством TCSP, чтобы обеспечить возможность более быстрой обработки AA. TCSP AAF может поддерживать всех VNO, поддерживаемых посредством TCSP.

[0039] AAF могла бы также перемещаться в InP (необязательно с ограниченными пользовательскими данными), чтобы обеспечить возможность более быстрых откликов AA. Это могло бы позволить создавать экземпляр AAF на краю сети с ограниченными наборами пользовательских данных. Когда UE соединяется с краевым узлом в первый раз, данные, релевантные для его аутентификации, могут быть перемещены в AAF, реализованную в InP, который является владельцем оборудования, к которому присоединяется UE. Вместо большого количества сетевых операторов и провайдеров услуг, предварительно загружающих AAF, основанную на InP, пользовательскими данными, которые могут никогда не быть использованы, данные AA, ассоциированные с UE, которое присоединилось к InP AP, могут быть кэшированы посредством InP AAF (или просто отправлены к ней). Это снизит латентность будущих процессов AA. В любой ситуации, в которой AAF находится вне домена VNO, ограниченные данные AA могут быть предоставлены в AAF. Подписка и другие данные, относящиеся к VN, могут исключительно сохраняться посредством VNO, если это желательно.

[0040] Если UE не проходит процесс AA, запрос присоединения может быть отклонен, или может быть отказано в доступе. Имеются другие обстоятельства, в которых UE будет блокирован, которые обычно относятся к распределению ресурсов. Например, если InP испытывает перегрузку, он может отклонить запрос присоединения UE. Аналогично, если распределение ресурсов VNO превышено, TCSP может отклонить сеанс. Вообще говоря, когда новый пользователь/сеанс успешно проходит процесс AA, он получит допуск, если только это не будет разрешено из-за пропускной способности сети.

[0041] В дополнение к AA, функции мониторинга и управления политикой (M&PC), такие как мониторинг трафика (M) и управление политикой (PC), могут также перемещаться к InP. Для простоты иллюстрации, M&PC будет использоваться, чтобы в общем случае включать в себя управление допуском (AC) и управление трафиком (TC), но должно быть понятно, что эти функции могут быть разделены, и их администрирование может осуществляться различными сетевыми элементами. В самом деле, в некоторых опциях, AAF может быть разделена, причем авторизация, аутентификация и учет выполняются различными сетевыми элементами. В некоторых вариантах осуществления, одна или несколько из этих функций могут динамически управляться и перемещаться между сетевыми элементами и/или различными уровнями сети. В некоторых вариантах осуществления, проверка допуска может включать в себя аутентификацию, авторизацию и управление допуском, что не обязательно должно выполняться посредством тех же самых функций. В этом контексте, управление допуском относится к проверке доступности достаточного количества сетевых ресурсов, чтобы удовлетворить запрос. В некоторых ситуациях, запрос соединения может быть аутентифицирован и авторизован, но не может быть допущен ввиду нехватки ресурсов для доставки запрошенной услуги.

[0042] Фиг. 3-5 являются блок-схемами, иллюстрирующими возможную топологию сети, полезную для иллюстрации различных опций допуска для одиночного сеанса для пользователя, который уже является абонентом VNO. Как описано выше, варианты осуществления будут описаны по отношению к трем опциям:

Опция A: VNO поддерживает данные AA и функциональность в функции VNO, обозначается как V-AA и описывается в основном со ссылкой на фиг. 3 и фиг. 8;

Опция B: VNO может распределять данные AA и функциональность к функции TCSP, обозначается как V-T-AA и описывается в основном со ссылкой на фиг. 4 и фиг. 9; или

Опция C: VNO может запрашивать TCSP распределять данные AA и функциональность InP, обозначается как L-V-AA и описывается в основном со ссылкой на фиг. 5 и фиг. 10.

[0043] Фиг. 3 иллюстрирует архитектуру, в которой VNO1 310 ассоциирован с TCSP1 330. Ассоциация между VNO1 310 и TCSP1 330 схематично иллюстрируется посредством линии 315. TCSP 1 330, в свою очередь, имеет ассоциации 334, 337 с InP1 360 и InP2 350, соответственно. InP2 350 также имеет ассоциацию 385 с TCSP2 380. TCSP2 380 не ассоциирован с VNO1, но имеет ассоциацию 311 с InP3. TCSP 1 330 имеет свою собственную AAF, T_AA 331 и функцию M&PC 332, которые выполняют эти функции для TCSP 1 330. Аналогично, TCSP2 380 имеет свою собственную AAF (T_AA 381) и функцию M&PC 382. InP 1 360 имеет свою собственную AAF, локальную AA 361 и функцию M&PC 362, а также физическую инфраструктуру, такую как точки доступа (AP) 363, 364 и 365. InP 2 350 имеет свою собственную AAF, локальную AA 351, функцию M&PC 352 и AP 353, 354 и 355. InP 3 340 имеет свою собственную AAF, локальную AA 341, функцию M&PC 342 и AP 343, 344 и 345. Хотя и необязательно, но предполагается, что каждый InP обеспечивает услуги доступа более чем для одного TCSP, тем самым обосновывая действие своих собственных AA и функций M&PC. Однако если InP находится в собственности или только выделен для TCSP, он может отказываться от задействования своих собственных AA и функций M&PC, и использовать имеющиеся у TCSP. Не каждый InP будет поддерживать функции AA (например, пико-сотовая сеть, эксплуатируемая системой управления зданием в офисном здании, может не поддерживать локальную функцию AA). В некоторых реализациях, локальные функции AA могут быть очень простыми, и после приема запроса AA, они могут пересылать запрос к другому объекту AA. TCSP будет также включать в себя другие функции, такие как функции шлюза и функции управления мобильностью, вместе с другими функциями, которые будут очевидны для специалистов в данной области техники. В контексте сети LTE, функция шлюза может представлять собой одну из обслуживающего шлюза (S-GW) или пакетного шлюза (PGW), а функция управления мобильностью (MMF) может быть эквивалента объекту управления мобильностью (MME). TCSP1 330 также включает в себя MMF 336. Если NFV используется, то TCSP1 330 может также включать в себя MANO 333 для создания экземпляра VF. В качестве другого примера, если используется NFV, то могут использоваться v-u-GW (не показаны).

[0044] Для каждой из фиг. 3-5, используются следующие условные обозначения. Круги представляют VNO, также управляемые посредством VNO или локализуемые функции. Овалы представляют TCSP или функции TCSP. Прямоугольники представляют InP и локализуемые InP функции. Эти условные обозначения иллюстрируют, что VNO могут делегировать функциональность (посредством обеспечения или управления функциями или данными, которые они используют) различным уровням многоуровневой сети. Должно быть понятно, что каждая из функций может исполняться одним или несколькими хостами. Хост может представлять собой компьютер или сетевой элемент, который включает в себя процессор и машиночитаемые инструкции, которые, при исполнении процессором, реализуют функцию. Фиг. 6 является примерной блок-схемой системы 601 обработки хоста, которая может быть использована для реализации различных сетевых функций, которые будут дополнительно описаны ниже.

[0045] Для каждой из трех опций (т.е., опции A, опции B и опции C), варианты осуществления описаны для двух сценариев для ситуаций, где как UE1 370, так и UE2 372 являются абонентами VNO1:

Сценарий 1: Допуск сеанса, когда UE1 370 соединяется с InP1 360; и

Сценарий 2: Допуск сеанса, когда UE2 372 соединяется с InP3 340 (который не ассоциирован с TCSP, ассоциированным с VNO1 310).

[0046] Вариант осуществления, реализующий опцию A, в которой VNO 1 310 поддерживает управление данными и функциональностью AA, будет описан ниже со ссылкой на фиг. 3. В опции A, процессы AA не делегируются к TCSP или InP. Вместо этого, VNO 1 310 поддерживает функции AA в V-AA 311. В качестве альтернативы, для вариантов осуществления, в которых TCSP реализует сетевое сегментирование, функции AA могут быть реализованы в сегменте (обработки) ресурсов TCSP для этой VN. В одном варианте осуществления, управление допуском (AC) выполняется посредством VNO на основе состояния сетевого сегмента, например, на основе остающейся емкости (пропускной способности) или другой абстрагированной обратной связи от TCSP. В другом варианте осуществления, после того как аутентификация и авторизация выполняется посредством AA VNO, решение AC выполняется посредством функции M&PC 332 TCSP1 330 на его усмотрение на основе текущей загрузки сети и политики. В этом случае, функция M&PC 332 принимает руководящие указания политики и мониторинга от VNO и устанавливает свои собственные политики на основе своей выгоды (стоимость/состояние сети, требования QOE и требования, заданные посредством VNO, и т.д.).

[0047] Ниже описан сценарий 1 для опции A. В соответствии с вариантом осуществления, UE1 370 соединяется с AP 363, которая приводится в действие посредством InP1 360. UE1 370 передает запрос присоединения, который включает в себя свой ID и свой ID подписки VNO1, чтобы инициировать запрос о возможности соединения. Запрос присоединения может пересылаться посредством AP 363 к локальной AAF 361, если ее экземпляр был создан. Локальная AA 361 пытается аутентифицировать UE. Имеется три возможных результата: успешно, отклонение и невозможность аутентификации. Успешный результат имеет место тогда, когда локальная AA имеет информацию, требуемую для аутентификации UE, и UE имеет учетные данные для аутентификации (в этом случае процесс аутентификации завершается). Отклонение имеет место, когда локальная AA имеет информацию, требуемую для аутентификации UE, но UE не имеет учетных данных, и, таким образом, этот процесс заканчивается. Невозможность аутентификации возникает в том случае, когда локальная AA 361 не имеет информации, требуемой для аутентификации, чтобы принять решение. В некоторых сценариях, AP 363 может определить из ID подписки VNO, предоставленного в запросе присоединения, что процесс аутентификации не может быть выполнен локальным образом. В таком сценарии, можно просто переместить процесс AA к TCSP.

[0048] Поскольку локальная AA 361 не может аутентифицировать UE, запрос присоединения перемещается либо к TCSP, либо к VNO. Соответственно, InP1 360 пересылает запрос к V-AA 311, обычно путем отправки запроса к T-AA 331. T-AA 331 будет неспособна завершить аутентификацию и затем перешлет запрос к V-AAF 311. V-AAF 311 аутентифицирует пользователя и отправляет ключи защиты и детали категории авторизованного пользователя к TCSP1 330 в соответствии с соглашением об услуге, устанавливающим VN. TCSP1 330 отправляет информацию и политику AA и требования мониторинга к InP1 360. InP, которые предоставляют услугу, могут выбираться или изменяться на основе местоположения и любого последующего перемещения UE. Например, услуга может быть распределена для AP 353 InP 2 350. В некоторых вариантах осуществления, которые используют виртуализацию сетевой функции (NFV), такая установка может включать в себя создание экземпляра виртуальных объектов, таких как виртуальный специфический для пользователя обслуживающий шлюз (v-u-SGW), и может включать в себя создание экземпляра других виртуализированных функций, например в TCSP1. После завершения сеанса, информация о завершении отправляется к VNO1 310.

[0049] Фиг. 8 представляет диаграмму потоков сообщений, иллюстрирующую потоки сообщений в соответствии с вариантом осуществления для этого сценария. В показанном сценарии, VNO 310 имеет соглашение об услуге с TCSP 330. После приема запроса от UE 370, AP 363 проверяет VN ID, определяет 810 корректную функцию (например, MMF), отвечающую за управление связностью для UE 370, и отправляет запрос присоединения к этой функции (например, MMF в TCSP 330). AP 363 может переслать запрос присоединения к своей локальной AA 361. Локальная AA 361 не может аутентифицировать UE, поэтому она отправляет запрос к TCSP. Запрос может быть отправлен либо прямо к MMF 336, либо к MMF 336 через T-AA 331. В вариантах осуществления, которые используют сетевую сегментацию, это может быть MMF, ассоциированная с сегментом услуги VNO, установленным в TCSP 330. Когда UE соединяется с AP, которая совместно используется множеством TCSP, AP может выбрать TCSP, ассоциированный с VNO, предоставляющим услугу UE. Может иметься иерархический список TCSP, ассоциированных с каждым VNO, чтобы позволить AP выбрать одного TCSP, когда как VNO, так и InP совместно используют множество общих TCSP. Также должно быть понятно, что могут использоваться различные способы выбора TCSP из набора TCSP, ассоциированных с VNO. В одном варианте осуществления, MMF выполняет проверку с объектом управления доступом TCSP (T-AC) и/или объектом политики и выставления счетов TCSP (T-PC), оба из которых могут быть частью функции M&PC 332 или отдельными функциями, чтобы оценить доступность сетевых ресурсов. В вариантах осуществления, которые используют сетевую сегментацию, будет оцениваться доступность ресурсов сегмента сети. Соответственно, в некоторых вариантах осуществления, M&PC 332 определяет 820, должен ли запрос быть отклонен, на основе политики, перед аутентификацией UE 310. После подтверждения, что имеется достаточно ресурсов и отсутствует основанная на политике причина отклонения соединения, MMF запускает процесс 822 запроса аутентификации. Специалистам в данной области техники должно быть понятно, что запрос 822 аутентификации подобен тому, который выполняется в сетях LTE. Запрос данных аутентификации передается к V-AA 311, но может отправляться к любому узлу с деталями аутентификации UE, такому как HSS, или в случаях, когда другие AAF действуют от имени V-AA 311, к другим AAF. После завершения запроса 822 аутентификации, MMF 336 может быть уверена, что UE аутентифицировано до уровня, требуемого посредством VNO. Следует отметить, что показанный поток вызова подобен процессу, используемому в существующих сетях 3GPP, чтобы аутентифицировать UE. В некоторых вариантах осуществления, аутентификация может выполняться относительно пользователя, а не UE. В таких вариантах осуществления, запрос данных аутентификации может пересылаться от AAF к объекту аутентификации третьей стороны, так что может быть получен запрос аутентификации. В других вариантах осуществления, аутентификация пользователя разрешается путем создания сеанса между функцией аутентификации третьей стороны и UE, позволяя пользователю предоставлять учетные данные аутентификации. Результат аутентификации пользователя может быть предоставлен к MMF либо от UE, либо от функции аутентификации третьей стороны. Как показано на фиг. 8, после запроса 822 аутентификации, может выполняться процесс 824 установки безопасности NAS. Этот процесс должен быть понятен для специалистов в данной области техники и обеспечивает создание безопасного соединения между MMF 336 и UE 370. Запрос присоединения (для аутентифицированного UE) затем пересылается MMF 336 к V-AA 331. V-AA 311 выполняет авторизацию и управление допуском 830. AC может выполняться объектом управления доступом VNO (V-AC) (который может быть частью V-AA 311 или отдельной функцией VNO). В качестве альтернативы, VNO 310 может выполнять авторизацию отдельно. Это, в частности, подходит, если VNO 310 только использует ресурсы одного TCSP. В таком случае, T-AC (которое может быть функцией в MME или в T-AA 331) может выполнять процесс AC 840 на основе доступных ресурсов для VNO и политики управления допуском VNO. Должно быть понятно, что, в некоторых вариантах осуществления, AC проверяется только однократно (например, на этапе 820 или 840). В других вариантах осуществления, этап 820 обеспечивает проверку AC на основе первого порога, основанного на доступности сегмента/сети. Если сеть или сегмент имеет недостаточную пропускную способность, допуск может быть отклонен. Если сеть или сегмент имеет ограниченную пропускную способность то решение о допуске сеанса может зависеть от политики, например, основанной на приоритете UE и/или VN и т.д.). В этом случае, вторая проверка AC выполняется после проверки 830 аутентификации и авторизации. Принятие присоединения отправляется назад в UE 370. AP 363, после приема указания о допуске UE, может выполнить установку безопасности AS и переслать принятие присоединения в процессе 850. Установка безопасности AS обеспечивает возможность безопасного соединения между допущенным UE 370 и AP 363.

[0050] Для вариантов осуществления, в которых TCSP обеспечивает ресурсы, на которых VNO работает в форме сегмента, запрос присоединения может включать в себя ID сегмента. Если UE 370 не предоставляет ID сегмента, но идентифицирует VN, AP 363 может выявить TCSP и ID сегмента, например, через таблицу поиска или т.п. В некоторых вариантах осуществления, TCSP может распределять сегмент более чем одной VN (т.е. ресурсы сегмента совместно используются множеством VN), и в этом случае запрос может включать в себя как ID сегмента, так и VN ID. Если TCSP не реализует сетевую сегментацию, AC будет обычно зависеть от доступности ресурсов в общем, в противоположность доступности ресурсов, распределенных сегменту VN.

[0051] Сценарий 2, в котором UE2 372 соединяется с InP3 340 (который не ассоциирован с TCSP, ассоциированным с VNO1 310) будет описан ниже со ссылкой на фиг. 3. UE2 372 соединяется с AP 344, приводимой в действие посредством InP3 340, запрашивающим сетевое соединение. UE2 373 является абонентом VNO1 310. AP 344 передает запрос соединения к локальной AA 341 в InP3 340. Запрос аутентификации может включать в себя UE ID и ID подписки, который идентифицирует по меньшей мере один из VNO1 310 и TCSP1 330. Локальная AA 341 не может аутентифицировать UE2 372. Локальная AA 341 не может переслать запрос к AAF, которая может обработать его. InP3 340 и созданные им экземпляры функций не могут аутентифицировать UE2 372 или соединить его с VNO 310. Соответственно, InP 3 340 пересылает запрос к T_AA 381, которая представляет собой AAF в TCSP2 380. T_AA 381 пересылает запрос к T_AA 331 в TCSP1 330, который, в свою очередь, пересылает запрос к V-AA 311 в VNO1 310. Пересылка сообщения может использовать базовую услугу (в юрисдикции, которая имеет полномочия свободной базовой услуги), или затраты могут быть оплачены посредством VNO1, UE2 некоторого другого объекта. В случае предоставления как базовой услуги, UE2 может быть аутентифицировано централизованным сервером аутентификации, чтобы избежать потенциально неправомочного поведения, и, как правило, предотвращает перегрузку или участие в DDoS. После допуска посредством VNO1, VNO1/TCSP1 может запросить TCSP2 предоставить услугу на основе ʺпо требованиюʺ и выставить счет за услугу на этой основе. Альтернативно, VNO1 может установить новый договор с TCSP2, ожидая, что многие из его пользователей запросят услугу от TCSP2.

[0052] V-AAF 311 в VNO1 310 аутентифицирует пользователя и отправляет ключи защиты и детали категории авторизованного пользователя к TCSP2. TCSP2 380 предоставляет допуск и отправляет информацию AA и требования M&PC к своим InP. Дополнительно, шлюз, MMF и другие функции (не показаны), включая другие виртуализированные функции, могут быть использованы по мере необходимости. После завершения, информация о завершении отправляется к VNO1/TCSP1.

[0053] Когда соединение UE через InP3 принято, телекоммуникационные услуги связности, предоставляемые посредством TCSP, все еще должны обеспечиваться. TCSP1 и TCSP2 могут координировать установку и выбор каналов, по которым данные могут передаваться от InP3 к TCSP2, к TCSP1 и затем к VNO1. Это могут быть каналы от InP3 непосредственно к TCSP1 или каналы, установленные как туннели (или иные такие структуры) в пределах TCSP2, которые допускают маршрутизацию трафика от InP3 к TCSP1, возможно, через функции, которые предоставляются посредством TCSP2.

[0054] Множество других механизмов может быть использовано, когда UE соединяется с сетью радиодоступа (такой как InP3) и не имеет подписки, которая позволила бы выполнить аутентификацию UE. Эти механизмы не релевантны для аутентификации UE или пользователя и последующего допуска сеанса UE на основе подписки.

[0055] Вариант осуществления, реализующий опцию B, в которой VNO делегирует содержимое базы данных AA и функциональность AA к TCSP V_T_AA 335, будет описан в основном со ссылкой на фиг. 4. Вновь будут описаны сценарий 1 и сценарий 2. Фиг. 3 отличается от фиг. 4 добавлением функции V_T_AA 335 в TCSP. Следует отметить, что V-T-AA 335 иллюстрируется кружком для представления того, что она является функцией, обеспечиваемой VNO в пределах овала TCSP1 330. Создание экземпляра V-T-AA 335 в TCSP1 330 может быть осуществлено различными путями. Экземпляр V-T-AA 335 может быть создан как автономная функция, достижимая посредством T_AA 331. Это обеспечивает возможность того, что большая часть сигнализации, показанной на фиг. 8, остается действующей. Любой обмен данными между T_AA 331 и V-AA 311 должен производиться через V-T-AA 335. Этот автономно созданный экземпляр может создавать свою собственную базу данных AA, когда UE соединяются, или он может копировать часть или всю базу данных AA, доступную посредством V-AA 311. Альтернативно, экземпляр V-T-AA 335 может быть создан в T_AA 331. Это обеспечило бы T_AA 331 доступом по меньшей мере к поднабору данных AA, доступных для V-AA 311. В некоторых вариантах осуществления, VNO1 310 делегирует полномочия к TCSP1 330, чтобы принимать решения о допуске, и V_T_AA 335 представляет данные VN AA, загруженные или иным образом предоставленные посредством VNO1 310, к T_AAF 331. В других вариантах осуществления, V_T_AA 335 представляет виртуальную AAF, экземпляр которой создан посредством VNO1 310 в TCSP1 330. Использование такой виртуальной AAF позволяет VNO1 310 поддерживать в большей степени управление, чем делегирование полномочия принятия решения к TCSP1 330, по-прежнему при сокращении латентности по сравнению с опцией A. В некоторых вариантах осуществления, V_T_AA 335 будет устанавливаться во время установки VN и может обновляться с интервалами, определенными посредством VNO1 310. Следует отметить, что для простоты иллюстрации, MMF 336 не показана на фиг. 4, но должно быть понятно, что такая функция может по-прежнему использоваться.

[0056] Процесс присоединения UE1 370 к сети (сценарий 1) будет описан ниже. UE1 370 соединяется с AP 363 в RAN, предоставленной посредством InP1 360, который пересылает принятый запрос присоединения в локальную AA 361. Запрос присоединения может включать в себя UEID и идентификацию VNO1 в качестве VNO, для которого UE имеет подписку. В некоторых вариантах осуществления, InP1 будет направлять все запросы аутентификации в локальную AA 361. Если локальная AA 361 не может принять решение об аутентификации (либо аутентифицировать UE, либо определить, что UE не является объектом, в качестве которого он себя заявляет) UE 370, она пересылает запрос к T_AA 331. Если T_AA 331 может принять решение об аутентификации UE, она будет выполнять это. В противном случае, в вариантах осуществления, в которых V-T-AA 335 была реализована, чтобы учитывать автономность данных аутентификации VNO, T_AA 331 пересылает запрос к V-T-AA 335.

[0057] В некоторых вариантах осуществления, для InP может быть предписано, что вся аутентификация должна осуществляться либо в TCSP1, либо в VNO1. В этом случае для AP может быть предписано пересылать запрос к T_AA 331. Альтернативно, InP1 может реализовать это требование путем предоставления инструкции в локальную AA 361. Когда запрос на аутентификацию принят, AP будет отправлять запрос к локальной AA 361, которая будет отправлять запрос аутентификации к T_AA 331 без попытки аутентифицировать UE.

[0058] В некоторых вариантах осуществления, AP 363 или локальная AA 361 будет передавать запрос присоединения к T-AA1 331, которая обрабатывает запрос с использованием V-T-AA 335. В других вариантах осуществления, T-AA1 331 пересылает запрос к V-T-AA 335 для обработки. V-T-AA 335 предоставляет допуск и информирует InP1 путем представления информации AA и требований M&PC к InP1. Другие варианты осуществления могут предоставлять авторизацию другим InP по мере необходимости, например, на основе мобильности UE. Вновь, фактические AP, которые предоставляют услугу, могут выбираться и изменяться на основе местоположения и любого последующего перемещения UE. Дополнительно, функции S-GW и MMF, которые весте с другими функциями могут быть предоставлены посредством виртуализации, могут быть установлены в желательных местоположениях. Информация мониторинга может отправляться в течение сеанса к VNO в соответствии с SLA. После завершения, информация завершения отправляется к VNO1.

[0059] Фиг. 9 представляет диаграмму потоков сообщений для обеспечения возможности реализации вышеописанного варианта осуществления. Фиг. 9 также иллюстрирует потоки сообщений для варианта осуществления, предусматривающего создание экземпляра виртуализированной AAF в хосте TCSP, что будет описано ниже со ссылкой на фиг. 8. Процесс начинается с создания экземпляра в VNO1 310, который создает 910 экземпляр V-T-AA 335 в TCSP 310. Создание экземпляра функции в сети TCSP может быть выполнено объектом управления и координации (MANO), таким как TCSP MANO 333. In ответ на инструкцию создать экземпляр виртуальной AAF в домене базовой сети, обеспеченном посредством TCSP, MANO 333 создает экземпляр новой AAF (V-T-AA 335). MANO 333 передает подтверждение создания экземпляра V-T-AAA 335 к запрашивающему объекту (показанному как VNO 310). Объект в VNO 310 может затем переслать данные AA из V-AA 311 к V-T-AA 335 в потоке 905. Этот процесс может выполняться на основе по каждому сегменту VN, если реализована сетевая сегментация. V-T-AA может принимать дальнейшие обновления данных AA в ходе функционирования.

[0060] UE 370 передает запрос присоединения к AP 363. Запрос присоединения, не обязательно, включает в себя VN ID. AP 363 выбирает MMF для запроса 920. Выбор MMF может быть сделан с использованием VNO ID, если он включен. InP не пытается выполнять аутентификацию UE 370 и пересылает запрос к выбранной MMF 336. MMF 336 может быть специфической для сегмента VN, если VNO 310 создан посредством сетевой сегментации. MMF 336 выбирает полномочную AAF, в данном случае V-T-AA 335, и запрашивает аутентификацию и авторизацию. Затем выполняется процесс AA 930. Хотя процесс AA показан как выполняемый посредством V-T-AA 335, MMF 336 может отправить запрос аутентификации к T-AA, которая может либо переслать его к V-T-AA 335, либо T-AA может выполнить процесс аутентификации сама с использованием данных, доступных для V-T-AA 335. Как отмечено в отношении фиг. 8, процесс AA 930 может содержать запрос аутентификации, подобный 822, и установку 824 безопасности NAS. После аутентификации UE 370, V-T-AA 335 предоставляет результат аутентификации к MMF 336, которая может выполнить проверку управления допуском 930. AC 930 может быть выполнено компонентом T-AC функции M&PC 332 или специализированной функцией T-AC. Ответ на запрос присоединения затем отправляется к UE 370 через AP 363. Специалистам в данной области техники должно быть понятно, что передача ответа присоединения может быть включена в установку безопасности AS подобно тому, как в 850.

[0061] Фиг. 5 иллюстрирует опцию C. В опции C, данные VNO AA могут рассылаться к любому или обоим из TCSP и InP. Распределение данных AA может быть реализовано либо через обеспечение доступности поднабора данных AA, либо путем создания экземпляра AAF в RAN, обеспеченной посредством InP 1 360. Экземпляр AAF, созданный в InP1 360, иллюстрируется как V-L-AA 367. Следует отметить, что V-L-AA 367 показана как круг, чтобы проиллюстрировать, что она является функцией VNO (хотя и той, которая может быть реализована посредством MANO 333 в TCSP 330 либо посредством MANO InP в ответ на запрос из MANO 333). V-L-AA 367 может быть локализована совместно с AP. Альтернативно, V-L-AA 367 может находиться в сети InP и соединяться с одной или несколькими AP, без создания ее экземпляра в данной AP. Следует отметить, что для простоты иллюстрации, MMF 336 не показана на фиг. 5, но следует иметь в виду, что такая функция по-прежнему может использоваться.

[0062] Процесс присоединения для UE с данными AA в функции V-L-AA будет описан ниже. UE1 370 отправляет запрос присоединения к AP 363, ассоциированной с InP1 360. Запрос включает в себя UE ID и идентификатор VNO. Идентификатор VNO указывает AP 363, что аутентификация UE может выполняться в RAN, обеспеченной посредством InP. AP 363 пересылает запрос присоединения либо к локальной AA 361, либо к V-L-AA 367, в зависимости от того, как был создан экземпляр V-L-AA 367. Аутентификация и авторизация для доступа к VNO обеспечивается в RAN. InP1 360 информирует TCSP1 330 о запросе допуска и обеспечивает информацию о пропускной способности относительно доступности ресурсов. TCSP1 330 подтверждает, что сеанс может быть разрешен. Остальные этапы такие же, как описано выше. Должно быть понятно, что InP может либо принимать данные для включения в его услугу AA, либо он может, после приема запроса присоединения, создавать экземпляр AAF от имени VNO. Это привело бы к созданию экземпляра V-AA в узле InP, таком как точка доступа (например, eNodeB), или в том же самом узле или наборе узлов, используемых, чтобы создать экземпляр локальной AA 361. Это может обеспечивать управление AAF для VN (в зависимости от характера создания экземпляра), при обеспечении AAF в ближайшем возможном местоположении по отношению к UE.

[0063] Фиг. 10 является диаграммой потока сообщений, иллюстрирующей потоки сообщений в соответствии с вышеописанным процессом. Фиг. 10 также иллюстрирует потоки сообщений для варианта осуществления, предусматривающего виртуализированную AAF, экземпляр которой создан в AP. VNO 310 передает запрос на создание экземпляра V-L-AA в RAN, обеспеченной посредством InP. Это может предусматривать передачу запроса к TCSP MANO 333. Если MANO 333 может создавать экземпляры функций в InP, он передает инструкцию для реализации. На фиг. 10, это сообщение передается к AP, так что V-L-AA может быть реализована на краю радио покрытия. В других вариантах осуществления, TCSP MANO 333 может инструктировать выполнение реализации V-L-AAA в других местоположениях. В вариантах осуществления, где TCSP MANO 333 не может непосредственно управлять созданием экземпляров функций в домене InP, запрос может пересылаться к InP MANO, который, в свою очередь, будет управлять созданием экземпляра V-L-AA. Если NFV не используется, этот этап может быть опущен. На этапе 1015 VNO 310 предоставляет релевантные данные AA к основанной на InP AAF (например, V-L-AA). Этот обмен данными может быть выполнен через TCSP1 330, который является обычным посредником между InP и VNO, или в ответ на создание экземпляра V-L-AA в 1010, MANO может предоставлять информацию адресации для реализуемой функции к VNO, чтобы обеспечить возможность прямого соединения. UE 370 передает запрос присоединения к AP. Запрос присоединения, не обязательно, включает в себя идентификатор VNO. AP может определить, что AAF, которая может аутентифицировать UE, находится в RAN данного InP. Это определение может выполняться в то же самое время, что и идентификация MMF в релевантном TCSP, на этапе 1020. Запрос присоединения пересылается к выбранной MMF, и MMF и V-L-AA затем выполняют процесс 1030 аутентификации и авторизации. После успешной аутентификации и авторизации, может выполняться управление допуском 1040. Ответ успешного присоединения затем отправляется назад к UE. Специалистам в данной области техники должно быть понятно, что процессы 822 и 824 могут выполняться, когда MMF 336 контактирует с V-L-AA для запроса данных аутентификации, как часть процесса 1030.

[0064] Как отмечено, в некоторых вариантах осуществления, VNO может сохранять управление своей функциональностью AA и информацией путем создания экземпляра настроенной виртуальной функции в TCSP 330. Соответственно, VNO1 310 обеспечивает настроенную AAF (виртуализированную функцию: V_T_AA 335) для TCSP, подлежащую реализации в его сети или в облаке. V_T_AA 335 может использоваться, когда пользователю необходим допуск сеанса. Как отмечено выше, V-L-AA 367 могла быть также реализована в InP1 360. Фиг. 7 представляет собой последовательность операций, которая иллюстрирует использование такой виртуализированной функции в соответствии с вариантом осуществления. Здесь V-AA 311 устанавливает виртуализированную AAF V-T-AA 335. Виртуализированная AAF V-T-AA 335 может быть доступной (но не может быть модифицирована) посредством T-AA 331. VNO сохраняет возможность модификации как данных AA, так и виртуализированной функции AA. Это является полезным, чтобы предоставлять доступ через недоверительные AP.

[0065] Фиг. 11 является диаграммой потоков сообщений, которая иллюстрирует примерный поток сообщений для вариантов осуществления, относящихся к сценарию 2 для опции A или опции B, описанных выше. Здесь предполагается, что VNO имеет соглашение об услуге с TCSP1, и эта информация доступна для других TCSP, так что VNO может получать услугу от других TCSP. Информация об ассоциации между TCSP и VNO также может быть включена в запрос присоединения UE. Кроме того, в этом примере, TSP2 выделил ресурсы для роуминга или сегмента 'базовой услуги', чтобы обслуживать клиентов, не имеющих подписки. В этом случае UE2 372 соединяется с AP 344, которая проверяет VN ID и отправляет запрос к MMF TCSP2 380, ассоциированного с сегментом 'базовой услуги' TCSP. TCSP2 380 будет идентифицировать запрос как направленный к VNO, для которого TCSP2 380 не имеет соглашения об услуге. MMF будет проверять ограничения роуминга и проверять базу данных TCSP и VNO. В качестве примера, для UE, которое было бы в противном случае аутентифицировано, может быть отклонен доступ в некоторых географических местоположениях или для конкретных InP. VNO может иметь список InP, через которые VNO не будет разрешать прохождение трафика, даже если они соединены с TCSP, с которым VNO имеет отношение. Кроме того, TCSP может иметь InP, с которыми он не будет иметь соглашений, независимо от того, кто является VNO или другим TCSP. Например, VNO для группы национальной безопасности может позволять TCSP заключать ʺна летуʺ соглашения с InP или TCSP, за исключением любого InP, который использует оборудование от поставщика, которое считается небезопасным. Это означает, что запросы присоединения будут отклоняться на основе InP, через которого UE осуществляет соединение (даже если InP имеет соглашение с основным TCSP). MMF затем пересылает запрос прямо либо к TCSP1 330, либо к VNO 1 310. VNO 310 может отклонить или согласовать с TCSP2 предоставление требуемой услуги, и если согласовано, TCSP2 обеспечивает услугу способом, подобным тем, которые были описаны в приведенных выше сценариях. VNO может разрешать TCSP (например, TCSP1) выполнять доступ через другого TCSP и InP. VNO должен устанавливать условия, которые ему желательно принимать (например, затраты не могут быть больше, чем X), если TCSP может заключать соглашения в соответствии с этими условиями, чтобы управлять соединением UE.

[0066] В соответствии с вариантом осуществления, если ожидаются будущие пользователи, VNO 310 может выполнять согласование, чтобы иметь функции VNO_AA, частично реализованные в TCSP2 380 или AP в InP3 340, чтобы предоставлять более быстрый ответ на последующие запросы. В этом случае, MANO в TCSP (или InP) может использоваться для создания экземпляров виртуальных функций AA в TCSP2 380 или AP в InP3 340.

[0067] На фиг. 6 показана примерная блок-схема системы 601 обработки хоста, которая может использоваться для реализации различных сетевых функций. Как показано на фиг. 6, хост 601 включает в себя процессор 610, рабочую память 620, не-временное хранилище 630, сетевой интерфейс, интерфейс I/O 1240 и, в зависимости от типа узла, приемопередатчик 660, все из которых коммуникативно связаны через двунаправленную шину 670.

[0068] В соответствии с некоторыми вариантами осуществления, могут быть использованы все из изображенных элементов или только поднабор элементов. Кроме того, система 601 обработки может содержать множество экземпляров некоторых элементов, таких как несколько процессоров, блоков памяти или приемопередатчиков. Также, элементы хоста 601 могут быть непосредственно связаны с другими компонентами без двунаправленной шины. Хост 601 может формировать часть сетевого элемента, такого как AP или маршрутизатор, он может формировать специализированную систему обработки для реализации сетевых функций. Соответственно, хост 601 может исполнять машинно-исполняемые инструкции для реализации различных сетевых функций, включая функции AA и M&PC, описанные в настоящем документе.

[0069] Память может включать в себя любой тип не-временной памяти, такой как статическая память с произвольным доступом (SRAM), динамическая память с произвольным доступом (DRAM), синхронная DRAM (SDRAM), постоянная память (ROM), любая их комбинация и т.п. Элемент массовой памяти может включать в себя любой тип не-временного устройства хранения данных, такого как твердотельный накопитель, накопитель на жестких дисках, накопитель на магнитных дисках, накопитель на оптических дисках, USB-накопитель или любой программный продукт, сконфигурированный, чтобы хранить данные и машинно-исполняемый программный код. В соответствии с некоторыми вариантами осуществления, память или хранилище данных большой емкости имеют записанные на них операторы и инструкции, исполняемые процессором для создания экземпляров вышеуказанных функций и для выполнения вышеуказанных этапов.

[0070] По всем описаниям предшествующих вариантов осуществления, настоящее раскрытие может быть реализовано с использованием только аппаратных средств или с использованием программного обеспечения и необходимой универсальной платформы аппаратных средств. На основе такого понимания, техническое решение настоящего раскрытия может быть воплощено в форме программного продукта. Программный продукт может быть сохранен на энергонезависимом или не-временном запоминающем носителе данных, который может включать в себя устройства памяти, как описано выше, или сохранен на съемной памяти, такой как постоянная память на компакт-дисках (CD-ROM), флэш-память или съемный жесткий диск. Программный продукт включает в себя ряд инструкций, которые позволяют компьютерному устройству (компьютеру, серверу или сетевому устройству) выполнять способы, представленные в вариантах осуществления настоящего раскрытия. Например, такое выполнение может соответствовать имитации логических операций, как описано в настоящем документе. Программный продукт может дополнительно или альтернативно включать в себя ряд инструкций, которые позволяют компьютерному устройству выполнять операции для конфигурирования или программирования цифрового логического устройства в соответствии с вариантами осуществления настоящего раскрытия.

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

Claims (34)

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

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

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

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

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

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

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

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

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

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

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

9. Способ по п. 1, в котором функция аутентификации находится в сети радиодоступа, ассоциированной с точкой доступа, от которой принят запрос присоединения.

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

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

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

13. Способ по п. 1, в котором этап допуска пользовательского оборудования включает в себя передачу ответа принятия присоединения к точке доступа в сети радиодоступа.

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

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

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

17. Способ по п. 16, в котором сетевой сегмент включает в себя ресурсы сети радиодоступа (RAN).

18. Способ по п. 17, в котором ресурсы RAN предоставляются посредством домена отдельно от домена базовой сети.

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

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

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

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

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

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

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

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

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

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

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

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

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

Images