RU2643451C2 - Система и способ виртуализации функции мобильной сети - Google Patents

Abstract

Изобретение относится к беспроводной передаче данных. Технический результат - возможность каталогизации, установки и объединения сетевых функций с услугами сетевого уровня (связывание услуги) для предоставляемых услуг, чтобы способствовать гранулярным и стандартным механизмам мобильных сетей, уровнем услуг и приложений, для динамического обмена состояниями, договоренностями на уровне услуги (SLA), ресурсами и другой информацией. Для этого способ виртуализации функции мобильной сети (MNFV) включает в себя этапы, на которых: формируют кластер ядра развернутого пакета (EPC), ассоциируют подсеть с кластером EPC и загружают виртуальную машину (VM) и прикрепляют VM к EPC. 2 н. и 15 з.п. ф-лы, 20 ил., 7 табл.

Description

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

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

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

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

Объем данных в операторах мобильной сети (MNO) увеличивается. Виртуализация функции мобильной сети (MNFV) устанавливает связи между областями формирования сетей, их взаимодействия и приложениями в мобильных сетях. MNFV поддерживает различные типы инфраструктуры, включая в себя традиционные мобильные инфраструктуры, виртуализированные функции сети (CloudEPC) и мобильные платформы, как услугу (MPaaS). MNFV может работать при установке децентрализованной функции, при установке централизованной функции и интеллектуально распределенных функциях мобильных сетей. Кроме того, MNFV можно использовать для отсоединения аппаратных средств и физических ресурсов, таких как компоновки, включающие в себя лицензированный и нелицензированный спектр, операторы мобильной виртуальной сети (MVNO) и предоставление других мобильных услуг и моделей реализации возможностей. Кроме того, MNFV может обеспечивать возможность каталогизации, установки и объединения сетевых функций с услугами сетевого уровня (связывание услуги) для предоставляемых богатых услуг, и чтобы способствовать гранулярным и стандартным механизмам мобильных сетей, уровнем услуг и приложений, для динамического обмена состояниями, договоренностями на уровне услуги (SLA), ресурсами и другой информацией.

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

Способ в варианте осуществления для виртуализации функции мобильной сети (MNFV) включает в себя формирование кластера ядра развернутого пакета (EPC) и ассоциирования подсети с кластером EPC. Способ также включает в себя загрузку виртуальной машины (VM) и прикрепление VM к EPC.

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

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

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

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

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

на фиг. 1 показана схема беспроводной сети для передачи данных;

на фиг. 2 показана система виртуализации функции мобильной сети (MNFV) по варианту осуществления;

на фиг. 3 показан другой вариант осуществления системы MNFV;

на фиг. 4 показана дополнительная система MNFV;

на фиг. 5 показана система варианта осуществления для администрирования приложений;

на фиг. 6 показана система варианта осуществления для программного интерфейса приложения (API);

на фиг. 7 показан оператор мобильной сети (MNO) по варианту осуществления;

на фиг. 8 показан функциональный вид улучшенного ядра пакетной передачи (EPC) по варианту осуществления;

на фиг. 9 показана архитектура варианта осуществления открытого мобильного контроллера (ОМС);

на фиг. 10 показана схема объекта ОМС по варианту осуществления;

на фиг. 11 показана схема потока сообщений для способа программного интерфейса приложения (API);

на фиг. 12 показан другой вариант осуществления системы MNFV;

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

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

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

на фиг. 16 показана топология варианта осуществления узла;

на фиг. 17 показан вариант осуществления конечного автомата для формирования EPC;

на фиг. 18 показана другая система для MNFV;

на фиг. 19 показана дополнительная система для MNFV; и

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

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

Подробное описание вариантов осуществления

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

Вариант осуществления модуля QuantumLeap (QL) используется при виртуализации функции мобильной сети (MNFV). В одном варианте осуществления модуль QL установлен, как часть контроллера. Контроллер может работать совместно с вычислительным модулем и сетевым модулем. База данных используется для интерфейса программирования приложений (API) северного интерфейса (NB), в то время как API южного интерфейса (SB) могут составлять часть открытого протокола администрирования базой данных vSwitch (OVSDB) или базой данных системы администрирования элементом (EMSDB). API северного интерфейса представляет собой API, который позволяет, в частности, для сетевого компонента, связываться с компонентами более высокого уровня. И, наоборот, южный интерфейс связывается с компонентами более низкого уровня. Южный интерфейс может представлять собой протокол OpenFlow™, который способствует передаче данных между контроллером сети с программным определением (SDN) и физическими, и виртуальными сетевыми узлами, таким образом, маршрутизатор раскрывает сетевую топологию, определяет потоки в сети и воплощает запросы, передаваемые через API северного интерфейса. Северный интерфейс может представлять собой область передачи данных с поддержкой протокола между контроллером и приложениями или программами управления более высокого уровня. QL может подавать стандартный API для инструментов взаимодействия информационной технологии (IT), для осуществления северо-западных мобильных функций. QuantumLeap может поддерживать различные режимы работы, включая в себя CloudEdge, по запросу и упругие режимы.

В варианте осуществления существуют пять функций в наборе для операций улучшенного ядра пакетной передачи (EPC). Функции включают в себя объект мобильного администрирования (MME), обслуживающий шлюз (SGW), пакетный шлюз (PGW), услугу абонента базовой сети (HSS) и функцию правил начисления счетов за пакет (PCRF).

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

OpenStack™ представляет собой бесплатную "облачную" вычислительную платформу из открытого источника. OpenStack™ может быть развернута, как инфраструктура, как решение услуги (IaaS). Технология, используемая в OpenStack™, включает в себя взаимосвязанные проекты, которые управляют наборами ресурсов обработки, сохранения и формирования сетей через центр данных для администрирования или предоставления через инструментальную панель на сетевой основе, инструменты командной строки или через API передачи состояния представления (REST)ful.

OpenStack™ имеет модульную архитектуру с кодовыми наименованиями для ее компонентов. Модуль Compute, известный как Nova, представляет собой контроллер структуры для "облачных" вычислений, разработанный для администрирования и автоматизации наборов компьютерных ресурсов. Модуль Compute может работать с различным технологиями виртуализации, с компьютерными средствами без программного обеспечения и компьютерными конфигурациями с высокими характеристиками (НРС). Гипервизор или монитор виртуальной машины (VMM) работает на виртуальных машинах. Кроме того, модуль Compute работает с внешними библиотеками, с архитектурой, которая масштабируется горизонтально.

Модуль накопителя объекта OpenStack™, известный как Swift, представляет собой масштабируемую избыточную систему накопления. Объекты и файлы записывают на множество дисковых приводов, распределенных по серверам в центре обработки данных, используя программное обеспечение OpenStack™, ответственное за репликацию и целостность данных в пределах кластера. Кластеры накопления масштабируются горизонтально путем добавления новых серверов. Когда происходит отказ сервера или привода жесткого диска, OpenStack™ формирует реплику его содержания из других активных узлов в новых местах положений в кластере.

Кроме того, модуль формирования сети OpenStack™, известный как Neutron, ранее известный как Quantum, представляет собой систему для администрирования сетями и адресами протокола Интернета (IP). Формирование сетей OpenStack™ уменьшает бутылочное горлышко сети, чтобы способствовать предоставлению собственных услуг для пользователей. Формирование сетей OpenStack™ обеспечивает модели формирования сетей для различных приложений или групп пользователей. Используемые модели включают в себя однотипные сети или виртуальные локальные вычислительные сети (VLAN) для услуг разделения и трафика. Формирование сетей OpenStack™ администрирует IP-адресами, способствует специализированным статическим IP-адресам или динамическому протоколу конфигурирования хост-устройств (DHCP). Плавающие IP-адреса способствуют динамическому перенаправлению трафика к вычислительным ресурсам, и уменьшению объема трафика во время технического обслуживания или в случае отказа. Пользователи могут формировать свои собственные сети, управлять трафиком и соединить серверы и устройства с одной или больше сетями. Администраторы могут использовать формирование сетей, определенное программным обеспечением (SDN), таким как OpenFlow, для высоких уровней с масштабе многоарендной архитектуры и в массивном масштабе. Формирование сетей OpenStack™ имеет рамки расширения для дополнительных сетевых служб, таких как системы детектирования проникновения (IDS), балансирование нагрузки, брандмауэров и виртуальных частных сетей (VPN).

Кроме того, идентичность OpenStack™, известная как Keystone, обеспечивает отображение центрального директора пользователей, на услуги OpenStack™, доступные для доступа. Идентичность действует, как общая система аутентификации, в облачной операционной системе и может быть интегрирована с другими услугами серверной директории, такими как облегченный протокол доступа к директориям (LDAP). Кроме того, Идентичность поддерживает множество форм аутентификации, включая в себя стандартное имя пользователя и удостоверение на основе пароля, системы на основе маркера и логины сетевых услуг Amazon (AWS)®. Кроме того, каталог предоставляет список с возможностью формирования очереди услуг, развернутых в облаке OpenStack™ в одном реестре.

Модуль Телеметрии, известный как Ceilometer, обеспечивает точку контакта для систем начисления счетов, предоставляя счетчики для установления счетов клиентов среди компонентов OpenStack™. Доставка счетчиков может отслеживаться и пригодна для аудита. Счетчики являются достаточно широкими и поддерживают новые проекты, и агенты, собирающие данные, независимы от всей системы.

Дополнительные модули OpenStack™ включают в себя Dashboard (Horizon), Image Service (Glance), Orchestration (Heat), Database (Trove) и Elastic Map Reduce (Sahara). OpenStack™ Dashboard предусматривает для администраторов и пользователей графический интерфейс для доступа, предоставления и автоматизации ресурсов на основе облака. Кроме того, Orchestration организует множество композитных "облачных" приложений, используя шаблоны как через собственный OpenStack™ REST API, используя API Heat Orchestration Template (HOT), так и через CloudFormation® AWS®, совместимый с Query API. База данных представляет собой базу данных, используемую как механизмы предоставления реляционной и нереляционной базы данных. Elastic Map Reduce представляет собой услугу, которая способствует обработке данных ресурсов, администрируемых OpenStack™, включая в себя обработку.

Модель варианта осуществления включает в себя определение стандартной IT или модели сетевого (NW) взаимодействия и способ для мобильных сетей. Например, определены наименование точки доступа (APN), оператор мобильной виртуальный сети (MVNO), абонент и реализация политики. Принадлежащий сети, находящийся на IT уровень используется для интеграции с платформами, такими как OpenStack™ и CloudStack™, и приложениями, и находится в пределах репозиториев API. В варианте осуществления MNFV предоставляет мобильные функции северного и южного интерфейсов, способы реализации и интерактивные способы, и ассоциированные дескрипторы, которые способствуют интеграции мобильных функций NW с гибридными веб-приложениями услуги IT, такими как OpenStack™, для формирования и координации услуги.

Агент плагин QuantumLeap на OS или гипервизоре может воплощать основные классы, для поддержки функции виртуальной сети (VNF) для кластеров ЕРС, таких как ММЕ, SGW и PGW, для южного интерфейса, через Neutron. Доступ к некоторым функциям северного интерфейса и южного интерфейса осуществляется через epc.xml или pgw.xml, или соответствующие файлы формата обозначения объекта JavaScript (JSON). Ассоциированная OVSDB может использоваться для воплощения О VS. Кроме того, также может использоваться плагин ML2.

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

На фиг. 1 иллюстрируется сеть 100, для передачи данных. Сеть 100 включает в себя контроллер 102 передачи данных, имеющий область 106 охвата, множество оборудования пользователя (UE), включающее в себя UE 104 и UE 105, и сеть 108 обратной передачи. Представлены два UE, но может присутствовать гораздо большее их количество. Контроллер 102 передачи данных может представлять собой любой компонент, выполненный с возможностью предоставления беспроводного доступа, помимо прочего, установление восходящего канала передачи (штриховая линия) и/или нисходящего канала передачи (пунктирная линия) соединений с UE 104 и UE 105, такими как базовая станция, расширенная базовая станция (eNB), точка доступа, пикосота, фемтосота и другие устройства беспроводного доступа. UE 104 и UE 105 могут представлять собой любой компонент, выполненный с возможностью установления беспроводного соединения с контроллером 102 передачи данных, таким как сотовые телефоны, смартфоны, планшетные компьютеры, датчики и т.д. Сеть 108 обратной передачи может представлять

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

Представление улучшенной системной архитектуры (SAE) представляет собой архитектуру базовой сети для беспроводной передачи данных Системы долгосрочного развития (LTE) Проекта партнерства 3-го поколения (3GPP). SAE представляет собой развитие базовой сети общей услуги пакетной радиопередачи данных (GPRS) с упрощенной архитектурой, сеть, полностью построенную на IP (AIPN), сети радиодоступа с поддержкой для более высокой пропускной способности и более низкой задержкой (RAN), и поддержкой мобильности между множеством гетерогенных сетей доступа, включая в себя не-3GPP системы. SAE включает в себя ММЕ, SGW, PGW, HSS, раскрытие сети доступа и функцию выбора (ANDSF), и развернутый шлюз пакетных данных (ePDG).

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

SGW направляет и перенаправляет пакеты данных пользователя, и действует, как якорь мобильности, для уровня пользователя во время передачи мобильного терминала между eNB. Кроме того, SGW действует, как якорь, для обеспечения мобильности между LTE и другими технологиями 3GPP. Для UE в состоянии ожидания SGW прекращает работу нисходящего канала передачи данных и инициирует пейджинговую передачу, когда данные нисходящего канала передачи поступают для UE. Кроме того, SGW администрирует записями использования ресурсов для принудительного выполнения политики и начисления счетов.

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

счетов, перехват и отсеивание пакетов.

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

ANDSF предоставляет информацию в UE о возможности подключения к сетям доступа 3GPP и He-3GPP, таким как Wi-Fi. ANDSF помогает UE при обнаружении сетей доступа в непосредственной близости и обеспечивает политики для приоритезации и администрирования соединениями с этими сетями.

ePDG обеспечивает передачу данных с UE, подключенному к EPC через не защищенный He-3GPP доступ.

На фиг. 2 иллюстрируется MNFV 190, который может использоваться в мобильной системе. MNFV 190 содержит уровень прокладки, установку мобильной функции и соединитель IT/NW. Уровень 194 приложения может использовать OpenStack™ и/или язык разметки гипертекста (HTML). Уровень 194 приложений выбирает функции 196, такие как AWS®, облачные службы Joyent®, VMware® и Eucalyptus®. Функции 196 выполняют раскрытие значения сети, конструкцию воплощения, публикацию и инкубацию API.

Комплект 204 раскрытия SAE и приложения 208 используются механизмами электронной оплаты, механизмами вставки рекламы, механизмами аналитики в режиме реального времени и распределением и кэшированием содержания.

Набор 212 SAE включает в себя PCRF 214, ММЕ 216, HSS 218, PGW 220 и SGW 222. Виртуальные машины (VM) 226 соединяют эти модули с доступными ресурсами.

Блок 228 администрирования ресурсами беспроводной передачи данных и механизм 230 дохода используются в структуре 192 EPC, объединенной структуре EPC, которая используется для оценки технологии, получения сравнительных характеристик и формирования прототипов.

Вычислительные ресурсы включают в себя кластер с балансированием нагрузки, ускорителями, виртуализированными узлами или кластерами, которые являются автоматизированными или управляемыми. Сетевые ресурсы могут представлять собой скорости 24-100 Тбс, отсутствие блокирования при соединении любого-с-любым и механизм перенаправления оптимизированного пакета (PFE) Ethernet 100 Гигабит (GE). Также присутствуют модули 232 и 234 безопасности и уровень 236 носителя. Уровень носителя 236 содержит модуль 238 администрирования виртуальным узлом, модуль 240 иерархического качества услуги (H-QoS), модуль 242 переключения метки множества протоколов (MPLS), функцию 244 принудительного выполнения политики и начисления счетов (PCEF), S1-U 246, PFE/базу информации перенаправления (FIB)/протокол туннелирования GPRS (GTPyeGTP/протокол безопасности 248 Internet (Ipsec) и принудительное выполнение 250 политики, которые могут быть распределены.

Мобильные функции могут быть виртуализированы и реализованы, используя API. Функции предоставления включают в себя, формирование, конфигурирование и тестирование виртуальной сети EPC, формирование, конфигурирование и тестирование MVNO и формирование, конфигурирование и тестирование сети из машины в машину (М2М). Функции оптимизации и технического обслуживания включают в себя конфигурирование параметров масштабирования EPC, масштабирование сети, настройку рабочих характеристику, оптимизацию топологии, выполнение динамического предоставления, выполнение повторного предоставления, администрирование отказами и администрирование программным обеспечением. Операционные функции включают в себя APN, абонента, политику, безопасность, планирование отчетов, соглашения на уровне технического обслуживания (SLA) и М2М. Функции синтеза и анализа, и интеллектуальные функции включают в себя интеллектуальное средство сети (N1), интеллектуальное средство абонента (SI), интеллектуальное средство приложения (AI), интеллектуальное средство устройства (DI), отчетность, предупреждения по сети, и предупреждения услуги. Кроме того, функции услуги включают в себя соединения услуги, голосовые функции, систему администрирования абонентом (SMS), систему администрирования модулем (MMS), организацию видеоконференций, определение местоположения, способности устройства, профиль абонента для оплаты, профиль качества услуги (QoS), М2М и интеллектуальные функции.

Вариант осуществления включает в себя интегрированную платформу с OpenStack™ для взаимодействия услуг для MVNO и облака несущих. Существует разделение уровней услуги и администрирования. Вариант осуществления включает в себя новые способы для MVNO, управления политикой и CloudEPC в отношении шаблонов и атрибутов в соответствии с физическими и виртуальными сетями носителями. Динамическое определение размеров на основе структур времени и трафика поддерживается, включая в себя случай использования для M2M/IOT.

В таблице 1 иллюстрируются примеры конфигурации и потока. GTP-v1U использует протокол датаграмм пользователя (UDP), как протокол и порт 2152, для GPR, систему универсальной мобильной передачи данных (UMTS) и LTE. GTP-v1C использует UDP и порт 2123 для GPRS и UMTS. Кроме того, GTP-v2C использует UDP и порт 2123 для LTE. Кроме того, GTP' использует UDP для CDR с неизвестным портом. GTP-v2Cx использует UDP и порт 2123 для VxLAN через интерфейс SxV.

Различные шаблоны могут использоваться для функций виртуальной сети. Политики принудительно выполняются владельцем и являются специфичными для группы пользователей. Некоторые примеры шаблонов включают в себя Template_MVNO(Tenant, SP), Template_EPC(Tenanat, ITDelegate, Capacity, Delay, ММЕ, PGW, SGW), Template_Service(ServiceName, Tenanat, SP, ServiceID, EpcID, PolicylD, ApnID), Template_APN(ApnName, ApnID, Tenanat, SP), Template_Policy(PolicyNarne, PolicylD, Tenant, SP), Template_Subscriber(SubscriberProfHeID, Tenant, SP), Template_Tunnel(Type, Endpoints(n), Capacity, TEID), and Template_DNS(ReolverID, PrivateFlag, IP адрес, порт, протокол, ForwardingID).

В случае использования RESTful API (формирование, считывание, обновление и удаление (CRUD)) используется для формирования видеочата. Видеочат представляет собой композит из двух функций, видеоуслуги и услуги чата. CRUD применим для передачи данных из "точки-в-точку" или из точки-в-множество точек. Для передачи данных из "точки-в-точку" существуют два формирования услуги, с поддержкой таких услуг через взаимодействие услуг. API QL поддерживает взаимодействие услуги через шаблоны. Конечный автомат открытого мобильного контроллера поддерживает взаимодействие, уникальное для QL, для интегрирования с OpenStack™. Таким образом, OpenStack™ IaaS разрешено для взаимодействия шаблона, для поддержки уникально разработанных шаблонов.

Операторы мобильной сети (MNO) представляют собой обобщенные термины для операторов, которые оперируют мобильными сетями. MVNO предоставляет услуги, передаваемые из конца в конец (E2E), без необходимости владения всеми ресурсами, но могут распределять или оперировать поднаборами RAN или функциями EPC, в то время как ресурс принадлежит владельцу физического ресурса (PAO). Примеры ресурсов включают в себя серверы, накопитель, физические ресурсы сети (NW), спектр и ресурсы программного обеспечения (SW) или код. Например, Spectrum, Compute, Storage, Network Cluster, IP Address и адрес виртуальной локальной сети (vLAN) представляют собой ресурсы. Оператор мобильного ресурса (MAO) оперирует физическими узлами или виртуальными мобильными функциями в пределах определенных административных доменов. Владелец физического мобильного ресурса (Р-МАО) представляет собой оператора физического мобильного ресурса. Владелец виртуального мобильного ресурса (V-MAO) работает и выделяет виртуальный контекст MVNO. Мобильная платформа, как услуга (MpaaS) или оператор виртуальной мобильной сети (VMNO), аналогична локальному доступу, как услуга (laaS) для оперируемых облаком и предоставляемых облаком сетевых функций мобильной сети.

На фиг. 3 иллюстрируется система 130, для работы с физическими и виртуальными мобильными сетями. Система поддержки операции (OSS)/блок 132 услуг поддержки бизнеса (BSS) содержит агент 134. API северного интерфейса проходит через блок OSS/BSS 132 в MNFV 136, оркестратор.

MNFV 136 содержит плагин 138, который может представлять собой плагин QuantumLeap. API южного интерфейса проходит в систему 140 администрирования облаком (CMS), которая имеет агент 142. Примеры CMS включают в себя OpenStack™, CloudStack®, Eucalyptus®, CloudFoundry® и частные облака, такие как Vcloud Director® и AWS®.

Кроме того, из MNFV 136 проходит соединение до агента 148 в системе 144 администрирования элементом (EMS). EMS 144 связывается с сетью 152, традиционными узлами EPC и сетью. Сеть 152 представляет собой традиционный физический кластер EPC или сеть. Драйвер 146 в EM 144 связывается с сетью 150, географически распределенными кластерами CloudEPC. Администрирование сетью 150 может выполняться CMS 140 и/или EMS 144. Сеть 150 представляет собой виртуальную облачную EPC с маршрутизатором между взаимным соединением между уровнями L2/L3 в стеках сети. Здесь могут присутствовать мостовые соединения, такие как vLAN, или виртуальные расширенные локальные вычислительные сети (VxLAN) через Ethernet, протокол Интернета версии 4 (IPv4), протокол Интернета версии 6 (IPv6), или IP или MPLS на уровне 2.5.

Адаптер обходного пути выполняет обход CMS 140 и выбирает ЕМ 144 из MNFV 136 для ЕМ 144 либо для сети 152, или для сети 150.

Запрос плагина высокого уровня из MNFV 136 может быть пропущен через ЕМ 144 в сеть 150 или сеть 152. В качестве альтернативы, запрос плагина непосредственно передают в сеть 150 или сеть 152. Время работы агента может быть воплощено через марионеточное ведущее устройство MNFV 136 для удаленного исполнения. Удаленный исполнитель взаимодействия может быть выполнен агентом или драйвером, в зависимости от того, является ли он OS, гипервизором или OVS, представляет собой переключатель L2, переключатель L3 или маршрутизатор для адаптера. Адаптер представляет собой плагин, не являющийся OpenStack™, такой как EMS или модуль Puppet. Воплощение адаптера QuantumLeap может регулироваться для услуг MNFV для согласования атрибутов с расширением API для Neutron. Другие несогласующиеся атрибуты, такие как задержка сети EPC и бюджеты задержки, могут иметь другие пределы для мобильных сетей.

Объекты северного и южного интерфейсов формируют через вызовы REST, такие как post, get, put и delete, соответствующие create (С), return (R), update (U) и delete (D) вызова структурированного языка запрос (SQL). C используется при операциях формирования, R используется для возврата атрибута в ответ на представление или список операций, U обновляет значение атрибута, и D удаляет значение атрибута.

Поток задачи высокого уровня вовлекает формирование кластера EPC.Затем подсети ассоциируют с кластером EPC и выполняют загрузку VM или VNF, прикрепленных к кластеру EPC. Clean-up включает в себя удаление VM или VNF, удаление портов, ассоциированных с кластером EPC, и удаление кластера EPC. Подсети, ассоциированные с кластером EPC, удаляют.

На фиг. 4 иллюстрируется операция MNFV в контексте OpenStack, используя QuantumLeap. Модуль 358 QuantumLeap представляет собой механизм QuantumLeap с QuantumLeap API. QuantumLeap API имеет различные функции, такие, как формирование EPC, формирование APN и политику формирования. Модуль 358 QuantumLeap связывается с OSS/BSS/системой администрирования сетью (NMS) 352 идущей через северный интерфейс, взаимодействуя с приложениями 354 3^-ей стороны и интерфейсом 356 графического пользователя (GUI) OpenStack™. Уровень адаптации CMS работает с множеством систем администрирования облаком, для связи с виртуальным EPC-Ds 372.

Кроме того, QuantumLeap взаимодействует с различными модулями OpenStack™. Некоторые примеры модулей OpenStack™, которые могут использоваться, включают в себя NOVA API 360 (вычисления), Glance API 362 (изображение), Cinder API 364 (сохранение), Quantum API 366 с Create-net и Create-port, расширения 368 API и Quantum плагин 370. Quantum плагин 370 содержит операции Create-net и Create-port.

Плагин QuantumLeap работает в инфраструктуре мобильной сети, содержащей мобильный контроллер 370, который работает с продуктами уровня данных от множества поставщиков. Мобильный контроллер 370 связывается с виртуальным EPC-Ds 372.

На фиг. 5 иллюстрируется система 620 для администрирования приложениями с VM агентом, используя QuantumLeap. Система 620 включает в себя узел 621 контроллера, который предоставляет услугу MNFV, и вычислительный узел 623. Узел 621 контроллера содержит сервер 622 QL, который представляет собой прокси-сервер через северный интерфейс. Соединение EPC ассоциирует узлы виртуального EPC (vEPC), для формирования кластера vEPC. Сети администрирования и управления OS проходят через сервер 622 QL, и агент 628 QL в вычислительном узле 623. Сообщения в узле контроллера включают в себя протокол вызова удаленной процедуры (RPC), QuantumLeap API, Hello Messages, восходящее и нисходящее соединение, ширину полосы пропускания и задержку для удовлетворения SLA для MNO.

Вычислительный узел 623 содержит агент 628 QL, узел 634 и узел 642. Узел 634 содержит виртуальный ММЕ (vMME) 636, блок 640 виртуального администрирования QL и плагин 642 приложения, в то время как узел 642 содержит виртуальный SGW (vSGW) 644, виртуальный менеджмент 646 QuantumLeap и плагин 648 приложения. Существуют команды, специфичные для приложения в вычислительных узлах. Вычислительные узлы имеют агенты. Агент 648 QL преобразует связи, которые должны быть сконфигурированы. Другие команды между узлами и агентом QL включают в себя порт эмулятора очереди (QEMU), перенаправление, запуск, остановки, конфигурирование и контрольный сигнал. Выполняется уведомление о состоянии vEPC. NOVA обрабатывает виртуальный интерфейс (VIF) для перенаправления порта. Перенаправление порта QEMU выполняется путем отображения порта. VM или хост-устройство выполняет доступ, используя политику группы конечной точки (EGP).

Некоторый пример выборок взаимодействия командной строки QuantumLeap для EPC включает в себя:

qleap <commands> [options][arguments] Commands: List Template

V-MME v-SGW v-PGW v-PCRF v-HSS v-eNB

Stack(Begin)

getTemplate(v-MME)

get Interface(CIO_S 1 -MME, CIO_S6a, CIO_S11)

getTemplate(v-SGW)

get Interface(DIO_S 1 -U, DIO_S5, DIO_S8)

getTemplate(v-PGW) getlnterface(DIO_S5, DIO_S8, DIO-SGi)

config Switch Huawei 9811 Port 1-6

link v- S GW.PI OS 5 v-PGW.DIO_S5 BW=10Gb P1-P2

link UE-eNB-to-E-LA v-MME CIO S1-MME=1Gb P3-P4

link UE-eNB-to-ELAN v-SGW.DIO_S1_U=10Gb P5-P6

connect QLeap mySQL Openstakc.DB.ODBC

Group (v-MME, v-SGW, v-PGW) name CloudEPC

Stack(Commit), Build stack, Instantiate stack, Monitor stack

На фиг. 6 иллюстрируется система 440 для REST API, который конфигурирует и администрирует сетями и SLA. Контроллер 442 содержит модуль 480 OpenStack™, который выполняет различные функции OpenStack™, включая в себя базу данных 482 NOVA, которая соединена с планировщиком 484 NOVA, проводником 486 NOVA и API 488 NOVA. Планировщик 484 NOVA и проводник 486 соединены с модулем 502 NOVA Compute, в вычислительных узлах 500. Проводник 486 NOVA обеспечивает поддержку для вычислительных узлов 500, которые не обращаются к базе данных 482 NOVA. Планировщик 484 NOVA определяет, как отправлять запросы на вычисления и на объем.

NOVA API 488 взаимодействует с модулем 474 QuantumLeap, который обеспечивает услугу 476 API и содержит модуль 478 OpenStack™. Взаимодействие и управление предусматриваются модулем QuantumLeap, который связывается с NOVA API 488 и neutron 496, который содержит услугу 494 API и плагин 498. Neutron 496 связывается с агентом 504, Neutron и/или хост-агентом QuantumLeap в вычислительных узлах 500. Также модуль 498 neutron обращается к базе данных 490, Neutron и/или базе данных QuantumLeap.

Модуль 462 LMOD, который взаимодействует с модулем 474 QuantumLeap, представляет собой "облачный" провайдер вычислений на основе сети. Модуль 462 IMOD содержит услугу 468 API, мобильную сеть 472 и модули 470 конференций сетевого I/F. В одном примере модуль 462IMOD и модуль 474 QuantumLeap размещены в одном месте. В качестве альтернативы, модуль 462 IMOD и модуль 474 QuantumLeap распределены. I/F 472 мобильной сети обращается к виртуальным и физическим сетям, таким как портфолио 506, CloudEdge администрирование и взаимодействие (MANO) 508 и MPaaS 509.

Менеджер 450 мобильной сети связывается с модулем 462 IMOD и модулем 474 QuantumLeap. Менеджер 450 мобильной сети содержит услугу 452 API открытой мобильной сети, MNFV 458, менеджер 454 высокой доступности (HA), менеджер 456 содержания (CM) и механизм 460 политики.

Доступ к базе данных 444 осуществляет менеджер 450 мобильной сети, модуль 474 QuantumLeap, модуль 462 IMOD и оборудование 446 виртуального мобильного абонента (vMSE). vMSE 446 обращается к имитатору 448 виртуализации сетевой функции (NFV), который используется для имитации сети.

На фиг. 7 иллюстрируется использование MNO с MNFV и QuantumLeap с IT вводом в трубопровод в мобильную область. Владельцы объектов оператора, такие как MNO и MVNO, используют программные интерфейсы 512 для взаимодействия с модулем 514 QuantumLeap и модулями OpenStack™. MVNO 516 обращается к модулю 514 QuantumLeap, который выполняет реализацию 518 vEPC, например, области, зоны и центра обработки данных. В этом примере существуют три области, область Европы, Ближнего Востока и Африки (ЕМЕА) 524, область Азиатско-Тихоокеанского региона (АРАС) 536, и область Западных США 546. Роли оператора определены в блоке 520. Определены владельцы ресурсов и операторы. Кроме того, режимы операций MNO и MVNO определены в блоке 522. Его передают в PGW 560 в MPaaS 558.

Область EMEA 524, в Лондоне, содержит серверы 528, PGW 530 и DC 534. Кроме того, область АР АС 536, расположенная в Шанхае, содержит серверы 538, ММЕ 540 и DC 544. Кроме того, западные области 546 США, расположенные в Сан-Хосе, содержат сервер 548 в DC 552. Область содержит контроллер 562 передачи данных и брандмауэры 564 и 566. Упругая емкость по требованию и реализация функции выполняются в блоке 556.

На фиг. 8 иллюстрируется функциональный вид объектов EPC, которые должны быть реализованы через вызов функции MNFV. В открытом мобильном контроллере 308 (ОМС) работает OpenStack™ 310 CMS и ОМС API 300. ОМС API 300 связывается от виртуальной сохраненной базой данных 296 процедуры (vSPDB) до виртуальной HSS (vHSS) 292 и от виртуальной OSS 298 (ВОСС) в виртуальный BSS (vBSS) 294. ОМС 308 также использует MQ-Sch 306, виртуальный PCRF (vPCRF) 304, Q-Mgr 302, соты 312 и 314, и vMME 316. На фазе 1 используются vEPC 318, vSGW 320, виртуальный PGW (vPGW) 322, vMME 324, vEPC 326, vSGW 328 и vPGW 330. Кроме того, на фазе 2 используются виртуальный MNVF (vMNVF) 332, виртуальный DHCP (vDHCP) 334, виртуальный APN (vAPN) 336, виртуальный PCEF (vPCEF) 338, виртуальный туннель (vTunnel) 340 и виртуальный GTP (vGTP) 342. Функции списка, представления, формирования, обновления и удаления доступны для функции NW, MVNO, точки доступа (AP_Subscriber, Tunnel, Session, Policy и коммутируемые виртуальные каналы (SVCs). MNFV может использовать контроллер OpenFile, который формирует провайдер, и которые распространяется географически.

На фиг. 9 иллюстрируется архитектура 380 для ОМС.ОМС 382 соединен с облачным управлением EPC и уровнем 384 данных. Архитектура 380 представляет собой протокол туннелирования в области несущей из конца в конец GTP.

База данных 398 QuantumLeap представляет собой базу данных, аналогичную другим модулям OpenStack™ на основе одной базы данных на модуль. На фиг. 10 иллюстрируется схема 410 объекта для воплощения. Схема объекта может быть перенесена в базу данных SQL или NoSQL, на основе требований масштабируемости и отклика.

В варианте осуществления MNFV охватывает сети, в которых используются выпуски 3GPP LTE, в качестве их макросот.

Кроме того, API формирует, считывает, обновляет и удаляет наименование точки доступа (APN) и назначает ее для группы виртуального облака (VCG). VCG может быть представлена группой дескрипторов EPC виртуального облака "VC_EPC_D" или группой радиосот, назначенных для одного или больше мобильных объектов администрирования (MME), называемых дескриптором виртуальной соты "VC_RAN_D".

На фиг. 11 иллюстрируется схема 420 сообщения, представляющая поток запроса и ответа из "конца-в-конец" для примера вызова API из уровня приложения в уровень инфраструктуры. Существует передача данных между модулем 394 помощника, инструментальной панелью 393, модулем 392 QuantumLeap, кластером 402 EMS, кластером 404 EPC и CMS 400. Запрос из модуля HReq() помощника передают в инструментальную панель. Помощник перенаправляет запрос GUECLI(Req) в инструментальную панель, которая представляет собой командную строку, или инструментальную панель GUI. Инструментальная панель затем передает запрос QL_Req() в механизм QuantumLeap, и механизм QuantumLeap передает EMS_Call(), который основан на QL_Req(), в EMS. Кроме того, механизм QuantumLeap передает CMS_Call() в CMS, который основан на QL_Req().

Затем CMS передает VCMS_Call() в кластер EPC. Кластер EPC отвечает VCMS_Resp(). EMS передает EMS_Resp(), ответ из EMS в механизм QL для запрашиваемой работы, в механизм QuantumLeap.

Кроме того, EMS передает PEMS_Call(), физический вызов EMS, в кластер EPC.EPC отвечает PEMS_Resp(), откликом на физический вызов EMS. CMS передает CMS_Resp(), ответ из CMS в механизм QL для запрашиваемой работы, в механизм QuantumLeap.

Механизм QuantumLeap передает ответ AL_Resp(), в инструментальную панель. Затем инструментальная панель передает в GUECLI_Resp() в помощник. Помощник затем перенаправляет HResp().

На фиг. 12 иллюстрируется система 390 для QuantumLeap. Модуль 396 QuantumLeap представляет собой механизм QuantumLeap, который обрабатывает QuantumLeap API для выполнения команд формирования, считывания, обновления и удаления (предоставления), в кластер 404 EPC. Механизм QuantumLeap обнаруживает через базу данных QuantumLeap 398 инвентаризационную базу данных QuantumLeap и ассоциированные метаданные для существующих или новых кластеров CloudEPC, для идентификации, какой интерфейс следует использовать для взаимодействия инфраструктуры и ее атрибутов. Метаданные, известные, как дескриптор кластера виртуального облака EPC или vC_EPC_D, описывают один кластер CloudEPC. CloudEPC включает в себя функции элементов узла развернутого улучшенного ядра пакетной передачи (EPC) для MME/vMME, SGW/vSGW и PGW/vPGW. CloudEPC может также включать в себя PCRPVvPCRF, HSS/vHSS и другие элементы, такие как система наименования домена (DNS), DHCP, брандмауэр и балансиры нагрузки.

Основной модуль MNFV включает в себя механизм API и модуль взаимодействия, с поддержкой виртуализации глобальных и абстрактных функций северного интерфейса для сетей мобильной несущей или MNO. Мобильные сети представлены кластерами 404 EPC.

Кластеры 402 EMS могут представлять собой физическую несущую EMS Brownfield или виртуальные кластеры облака EMS, которые определяют, строят, реализуют и администрируют кластером CloudEPC через его взаимодействия с модулем 396 QuantumLeap. Запрос из модуля 396 QuantumLeap может привести к выполнению API южного интерфейса. Кластер 402 EMS администрирует функциями CloudEPC, такими как ММЕ, SGW, PGW, PCRF, HSS и различными мобильными операциями, запрашиваемыми MNFV, которые могут быть традиционными или виртуальными.

Кластеры 404 EPC имеют каналы обратной передачи по радиосети Ethernet/IP для управления и уровней данных. Кроме того, кластер 404 EPC поддерживает приложения и/или услуги в интерфейсе Интернета. MNFV управляет CloudEPC через кластер 402 EMS или CMS 400. При этом управляют различными типами узлов, Compute (вычисления), Storage (сохранения), фиксированными/мобильными срезами и облачными виртуальными группами. Тестирование выполняется из модуля 396 QuantumLeap. Кластер 404EPC представляет собой модуль ядра, который помогает мобильным сетевым операторам предлагать услуги в облаке.

CMS 400, который может представлять собой контроллер OpenStack™ или другой контроллер CMS, может быть независимым или интегрированным с модулем 396 QuantumLeap. Мобильные функции разрабатываются в EPC Cloud, или CloudEPC выполняют через протокол передачи гипертекста (HTTP) в модуль 396 QuantumLeap, или через уровни L3/L2-IP/vLAN в кластере 404EPC.Кроме того, CMS 400 поддерживает посторонние облака с трансляцией из входов PI QuantumLeap в соответствующие облака в сети 408 CMS. Сеть 406 также используется для связи с внешними интерфейсами для Интернета.

Глобальный модуль 392 формирует интерфейс с модулем 396 QuantumLeap для поддержки услуг поддержки операций сети (OSS), услуг поддержки бизнеса (BSS), систем сетевого администрирования, таких как виртуальные EMS (vEMS) и другой виртуальной сетевой файловой системы (vNFS) для построения и поддержания CloudEPC.

Модуль 394 помощника взаимодействует с глобальным модулем 392 через интерфейс помощника. Модуль 394 помощника помогает третьей стороне vOSS/vBSS/vEMS/vNFS поддерживать ее, для того чтобы сделать MNFV универсальным. Модуль 394 помощника для NMS представляет логический программный пакет, который может обращаться к API для северного интерфейса в инструментальной панели 393 и может программным путем управлять API QuantumLeap, для управления кластером 402 EMS, логическим или физическим кластером EMS.

На фиг. 13 иллюстрируется блок-схема последовательности операций 690 для способа формирования кластера EPC. Первоначально, на этапе 692, владелец формирует кластер EPC. Например, владелец формирует кластер epc1 EPC с ID для epc1_id.

Затем, на этапе 694, подсеть ассоциируют с кластером EPC, сформированным на этапе 692. Например, владелец ассоциирует подсеть 10.0.0.0/24 с кластером epc1 EPC.

Затем, на этапе 696, VM загружают и прикрепляют к кластеру EPC. Владелец загружает VM и устанавливает один контроллер сетевого интерфейса (NIC), который соединяется с EPC. В одном варианте осуществления QuantumLeap входит в контакт с OpenStack™ Networking, для формирования NIC и прикрепления его к сети epc1 с ID net1_id:

$ QuantumLeap boot <server_name> - image <image> - flavor <flavor> - nic net-id=<epc1_id>.

В другом примере формируют порт port1. Затем VM загружают с указанным портом. OpenStack™ Networking формирует NIC и прикрепляет его к порту port1 с ID port1_id:

$ QuantumLeap boot <server_name> - image <image> - flavor <flavor> - nic port1-id=<port1_id>.

OpenStack™ Networking выбирает и назначает IP-адрес для порта port1.

На этапе 698, владелец удаляет VM. QuantumLeap входит в контакт с OpenStack™ Networking и удаляет порт port1. Выделенный IP-адрес возвращают в общий набор доступных IP-адресов.

Затем, на этапе 700, порты удаляют. Когда владелец сформировал порты и ассоциировал их с кластером EPC, владелец удаляет эти порты.

В конечном итоге, на этапе 702, удаляют сеть. Владелец удаляет кластер EPC. Кластер OpenStackQuantumLeap и его ассоциированное переданные модули EPC удаляют, когда порт не сконфигурирован в данное время по сети.

На фиг. 14 иллюстрируется блок-схема последовательности операций 710 для способа использования мобильной несущей, такой как MNO или MVNO. Первоначально, на этапе 712, владелец, MNO или MVNO, формирует глобальную зону, например, пустую глобальную зону провайдера. Например, владелец создает Северо-Американскую зону с ID GZone_id.

Затем, на этапе 714, сайт ассоциируют с глобальной зоной, сформированной на этапе 712. Владелец ассоциирует сайт с глобальной зоной. Например, владелец ассоциирует кластер EPC и epc1 с Северо-Американским GZone_id.

Затем, на этапе 716, формируют локальную зону и прикрепляют к глобальной зоне. Владелец формирует локальную зону, например пустую локальную зону провайдера. Например, владелец формирует зону Санта-Клара с ID зоны для LZone_id.

На этапе 718, сайт ассоциируют с локальной зоной, сформированной на этапе 716. Владелец ассоциирует сайте с этой локальной зоной. Например, владелец ассоциирует кластеры EPC и epc2 с Санта-Клара LZone_id.

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

На изображении представлена операционная система и/или связки загружаемых пакетов, в качестве изображения стандартного программного оборудования, для формирования виртуальных машин в стандартном формате. Imagelink представляет собой адрес унифицированного сетевого указателя ресурса (URL), например, для местоположения изображения http://w.x.y.z/bin/Images/. Дескриптор представляет собой форматированный объект XML или JSON в иерархии или во взаимоотношениях, описывающих узлы и их интерфейсы, для формирования кластеров узлов, работающих вместе. Место назначения в сетевом URL или на пути для получения дескриптора условно или по конфигурации. GroupType описывает тесно привязанные EPC или RAN для использования разными объектами. Группа виртуального облака (VCG) представляет собой группировку либо из EPC, или RAN в кластере, или облако, которое может быть описано, как модуль. APN представляет собой объект, в котором используется VCG с мобильным происхождением (MO), мобильным завершением (МТ) или срезом сетевых кластеров EPC или RAN. Абоненту (SUB) назначают мобильный номер, например, модуль идентичности абонента (SIM) или универсальный модуль идентичности абонента (USIM). Объект представляет собой любую часть аппаратных средств или программных средств, которые могут быть соединены с сетевыми услугами. Атрибуты абонента включают в себя ID международного мобильного оборудования (IMEI) и ID международного мобильного абонента (IMSI). Типы профиля включают в себя независимый счет потребителя (INDI) или счет фонда или корпорации (FAN). Групповой массив представляет собой массив с одним или больше APN или группами на основе предоставления в мобильное устройство несущей или MNO.

Владельцам физического объекта могут принадлежать объекты, или они могут получать объекты в лизинг разных типов, такие как Spectrum, Compute, Storage и Network. Network (сеть) может представлять собой сеть Ethernet или изолированную область широковещательной передачи уровня 2, например, зарезервированную для владельца, который сформировал ее, или сконфигурированную с возможностью совместного использования. Владельцы могут формировать множество сетей, пока не будут достигнуты определенные пороговые значения. Ресурсами можно администрировать, как набором, и их можно выделять или не выделять на основе доступности и политики, назначенных управлением доступом. Для MNO назначают ID, как в 3GPP, используя идентификацию открытой наземной мобильной сети (PLMNID). ID могут назначаться различным способом для частных или нелицензированных спектров. После установления MNO, в качестве проекта/владельца, например, в соответствии с OpenStack™ или другой облачной системой администрирования, совместно используемые ресурсы в узле радиодоступа или в базовой сети выделяют для операторов мобильной виртуальной сети (MVNO). MVNO устанавливается MNO или провайдером услуги из их сети. Таким образом, провайдер сети может быть эквивалентен ресурсам MNO, которые включают в себя кластер EPC с CMS/ЕМ, для элементов администрирования в пределах базовой сети. Начисление счетов и другие функции помощника северного интерфейса находятся на глобальном уровне для администрирования операциями.

Владельцам физических объектов принадлежат, и они передают в лизинг различные типы объектов, такие как Spectrum, Compute, Storage и Network. Ресурсами можно администрировать, как наборами и они могут быть выделены, или могут быть освобождены на основе доступности и политики, назначенной для управления доступом. MNO назначают ID, как в 3GPP, например, используя PLMNID, для поддержания соответствия стандартам телекоммуникаций. ID может использоваться по-разному для частного или нелицензированного спектра. Когда MNO устанавливают, как проект/владелец, в соответствии с CMS, совместно используемые ресурсы в сети радиодоступа или в базовой сети могут быть выделены для MVNO. MVNO представляет собой термин, установленный MNO или провайдером услуги, из их сетей. Таким образом, провайдер сети представляет собой термин для ресурсов MNO, которые включают в себя кластер EPC и кластер EMS для администрирования элементами в пределах базовой сети. Поскольку он администрирует операциями, начисление счетов и другие функции помощника северного интерфейса находятся на глобальном уровне.

Таким образом, помимо наборов ресурсов, перед установлением MNO/MVNO, определяют географию через дескрипторы в иерархии XML или дескрипторы JSON. Выполняется отображение для минимизации конфигураций в объекте геолокации. Это выполняется гибким образом для размещения отображения в центре обработки данных (DC) и узле несущей, идентифицированном на пути виртуальной цепи от ядра в направлении ребер.

География определена через дескрипторы в XML или JSON перед установлением MNO/MVNO. Это может быть выполнено при открытом программировании с открытым источником или OpenStack™. Существует гибкость для размещения отображения в центрах обработки данных и идентификации узла несущей в конструкции виртуального пути из ядра в направлении ребер для удовлетворения требований размеров для администрирования каналом трафика.

Когда устанавливают геолокацию в дескрипторе, узел реализуют, используя элементы узла функции виртуальной сети (VNF), такие как CloudEPC в виртуальных областях, или дополнительные программы, или пакеты. Объекты имеют менеджер. Традиционными EPC управляют, используя традиционные EMS, и более новым CloudEPC администрируют с помощью традиционных EMS или нового облака, сформированного в vEMS. Множеством объектов можно администрировать через QuantumLeap, который может обеспечивать взаимодействие программ и функций через систему администрирования облаком и традиционными EMS.

Как только сетевые кластеры готовы для управления, пользователь может подключать и использовать сеансы путем абонирования и использования сетей на основе LTE. В качестве альтернативы, сетевыми кластерами можно администрировать через Интернет, как MNO, или MVNO устанавливает их сеть по согласованию и конфигурацию через список управления доступом (ACL), политику для использования сетевого ресурса через VCG или правила, которые позволяют или ограничивают использование определенных ресурсов и групп через комбинацию ACL и политики.

Когда сетевые кластеры готовы к управлению, пользователь может соединиться и использовать сеансы путем подписки, и используя сеть на основе LTE. В качестве альтернативы, пользователь соединяется через Интернет, как MNO или MVNO, для установления сетей путем соединения и конфигурирования.

В примере владелец формирует кластер EPC, например, epc1. Затем, владелец ассоциирует подсеть с этим кластером EPC, например, "10.0.0.0/24". Владелец затем загружает VNF, используя от трех до пяти узлов EPC, и устанавливает подсети, соединенные с epc-net1. VM представляет собой полностью изолированную установку гостевой операционной системы в пределах нормальной хост-операционной системы. Модуль, например, QuantumLeap, вызывает NOVA и/или Neutron, и формирует топологию на основе дескрипторов epc.xml или vnf.xml, epc.json или vnf.json. Neutron назначает подсети и протоколы Интернета (IP), в соответствии с запросом, или определенные в дескрипторах XML/JSON для VNF. Функция виртуального приложения (vApp) представляет собой приложение на стороне сервера, или услуга обрабатывает опосредованно функции приложения (AF) мультимедийной подсистемы IP (IMS) или непосредственно через 3GPP, G-интерфейс/защищенный - (Gi/SGi) или интерфейс Интернет. IP предоставляется QuantumLeap. Владелец затем удаляет VM. NOVA связывается с QuantumLeap - Neutron и удаляет epc-netl. Выделенный IP-адрес возвращают в набор доступных IP-адресов.

Выделяют IP-адреса. Сети EPC могут использовать блоки адресов IP версии 4 (IPv4) или IP версии 6 (IPv6). Вариант осуществления сети QuantumLeam может иметь минимум три узла, включая в себя ММЕ, SGW и PGW, и дополнительные узлы, такие как PCRF, HSS, другие vNF и т.д. Когда порт формируют по сети, по умолчанию ему выделяют доступный фиксированный IP-адрес обозначенных подсетей для IP версии. Когда порт больше не используется, выделенные адреса возвращаются в набор доступных IP-адресов по подсетям. Пользователи QuantumFeap API могут выбрать определенный адрес IP из блока. В качестве альтернативы, файлы конфигурации QuantumFeap xml/json узлов, называемые дескрипторами узла, выбирают первый доступный IP-адрес.

На фиг. 15 иллюстрируется блок-схема 570 последовательности операций для способа моделирования мобильной сети и взаимодействия. Обработка начинается на этапе 572, система начинает формирование MNO.

На этапе 574 выполняют MNO CRUD.

Затем, на этапе 576, определяют рынок, или выполняют геолокацию. На этапе 578, определяют область. Кроме того, на этапе 580 определяют зону и местонахождение. Кроме того, DC, кластер и узел выполняют работу для определения геолокации.

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

Набор 590 с Vodafone™ United Kingdom (VDF- UK) DC 592 обращается к CloudEPC 594. Кроме того, набор 598 с Vodafone™ VDF-NDF DC 596 обращается к CloudEPC 600 и CloudEPC 602. Кроме того, набор 606 с VDF-DTF DC 604 обращается к CloudEPC 608 и CloudEPC 610. Модули каталога планирования виртуальной емкости (vCPCU) 584 содержат шаблоны 588 и сети 586.

На фиг. 16 иллюстрируется топология 110 с пятью узлами. eNB соединен с ММЕ 116 и SGW 118. ММЕ соединен с HSS 112. SGW 118 соединен с PGW 120 и PCRF 114, в то время, как PGW 120 соединен с PCRF 114. PGW 120 соединен с Интернетом. Взаимодействие между ММЕ 116 и SGW 118 выполняют, используя QuantumLeap API. Взаимодействие включает в себя внутреннее и внешнее взаимодействие.

Другой вариант осуществления представляет собой топологию из трех узлов, содержащую ММЕ 116, SGW 118 и PGW 120.

На фиг. 17 иллюстрируется конечный автомат 650 для EPC, сформированный с запросами и ответами JSON. Конечный автомат проходит от начального запроса до отклика для кластера EPC. Первоначально, после загрузки, конечный автомат находится в состоянии 652 инициирования (init). Конечный автомат остается в состоянии 652 инициирования, до тех пор, пока не будет закончено инициирование. Когда инициирование заканчивается, конечный автомат переходит в состояние 654 ожидания.

В состоянии 654 ожидания, конечный автомат ожидает отклика запуска. Конечный автомат затем отвечает в состоянии 656 отклика. Кроме того, конечный автомат переходит в состояние 658 для начала удостоверения.

Затем конечный автомат переходит в состояние 660, для начала транзакции Tin+.

Затем, конечный автомат переходит в состояние 662, для I-Req In - Fmt.

Конечный автомат переходит в состояние 672 при ошибке формата или в закрытое состояние 670. Из состояния 672, конечный автомат может перейти в состояние 668, состояние 674 или состояние 676.

В состоянии 668 выполняется сброс ошибки. Конечный автомат переходит в состояние 670, состояние 666 для аварийного прекращения работы, или состояние 664, для возобновления следующей операции.

В состоянии 674, конечный автомат переходит к следующей операции и переходит в состояние 654 ожидания.

В состоянии 676 передают пакет.

Затем, в состоянии 678, выполняют завершение Cmt-T. Передают XML, и в состоянии 680, обрабатывается команда.

В состоянии 684, выполняется тестовый отклик.

Затем, в состоянии 682, выполняется отклик I-Res. Конечный автомат переходит в состояние 672.

На фиг. 18 иллюстрируется система 711 для интеллектуальной виртуализации сетевой функции с известным местоположением. NFV выполняет каталогизацию функции NW, автоматическое раскрытие сетевого объекта, реализацию распределенного NFV, и режим гибких операций. Может быть выполнено определение портфеля. NFV 713, NFV с известным местоположением iMOD, выполняет интеллектуальную и динамическую реализацию рабочей нагрузки мобильной функции. Используются SGW, PGW и ММЕ.

UE 724 соединено с eNB 728 через радионоситель 730. Кроме того, eNB 728 управляется ММЕ 734. Беспроводные сигналы распространяются между UE 724 и eNB 728. eNB соединен с RAN 732. RAN 732 соединен с МВН 738 в PGW 736, SGW 740 и PGW, которыми управляет ММЕ 746.

RAN 732 соединен с МВН 738, которым управляет PGW 736.

PGW 748 соединен с Gi-LAN 750, которая соединена с Интернетом 752.

На фиг. 19 иллюстрируется система 760 для виртуализации функции мобильной сети. В системе 760 может использоваться OpenStack™. Контроллер 762, открытый мобильный контроллер, управляет переключателем 774. Переключатель 774 соединен с сервером 770, сервером 772, Ixia™ 764 и сервером 766. В сервере 766 работает OpenStack™, в то время как в сервере 772 работает PGW.

NFV 761 представляет собой iMOD с известным местоположением NFV. Соединение услуги или vMSE обеспечивается SVC 776, SVC 778, SVC 780 и SVC 782. SVC транспортирует данные, таким образом, что это выглядит, как если бы существовало соединение в виде специализированного физического уровня между оконечными системами источника и назначения.

SVC 776 соединен с трансляцией 784 сетевого адреса (NAT). SVC 778 соединен с модулем 786 глубокой инспекции пакетов (DPI). SVC 780 соединен с устройством 788 кэширования. Кроме того, SVC 782 соединен с NAT 790. Модуль 786 DPI анализирует часть данных пакета, выполняет поиск несоответствия протоколу, вирусов, спама, инструкций и т.д., для определения, можно ли пропустить пакет в его место назначения. В NAT сетевые адреса модифицируют для повторного отображения пространства одного адреса IP на другой.

Маршрутизатор 792 используется для формирования трафика.

Трафик пропускают через туннели 794 VPN в MPaaS 796 и MPaaS 800, используя сервер 768. MPaaS 796, который содержит PWG-AW 798, пропускает трафик в eNB 804, в то время как MPaaS 800, который содержит PGW-RACK 802, пропускает трафик в eNB 812.

Трафик затем может быть направлен в направлении eNB 808, UE 810 и PGW 806.

В одном примере используется несущая уровня 1. Несущая владеет тремя центрами данных (DCO, DC1 и DC2). Несущая разветвляется, Branchl и Branch2 работают в своих собственных ядрах пакета, используя локальные центры данных, работая со штаб-квартирами. Таким образом, существуют вложенные MNO на основе геолокации (GeoLoc). MY-MNO является глобальным с CMS OpenStack™, и MY-MNO1 локальная Французская и MY-MNO2 локальный Скотт. MY-MNO принадлежит, и она оперирует кластером сети EPC (EPC-NET) с APN-Великобритании и назначает APN-Франции (APN-ФРАНК) и APN Санта-Клара (APN-SC) для использования MY-MNO 1 и MY-MNO2, как назначено владельцем-администратором (Великобритания) или MY-MNO для OpenStack™, используя инструментальную панель горизонта QuantumLeap. Может существовать только один контроллер OpenStack™ на сайте Великобритании. В качестве альтернативы, существует отдельный контроллер OpenStack™ в других местах.

Первоначально, РАО, например, MY-MNO организует свои ресурсы центра данных (серверы, накопители и переключатели) в иерархию зоны/сайта/ОС/портативных модулей по запросу (РОБ)/кластеры/стойки/узлы.

В РАО работает CMS, OpenStack™ в невиртуализированных серверах. В других вычислительных ресурсах работают гипервизоры, например, виртуальная машина на основе ядра (KVM). РАО использует CMS для получения набора или выделения ресурсов. CMS и узлы могут использовать специализированную сеть администрирования для обмена данными. В РАО работает QuantumLeap (QM). OpenStack™ используется, как CMS. QL, вместе с другими модулями, обеспечивает услуги MNFV.

Выполняют отображение геолокации. РАО запрашивает набор доступных ресурсов, используя QL и разделяет на категории эти ресурсы по иерархии зоны/сайта/ОС/РОО/кластера/стойки/узла. QL использует OpenStack™, для запроса ресурсов. QL внутри себя содержит узел - отображение геолокации. В одном примере используются три DC. Эти три DC представляют собой Великобританию, Францию и Санта-Клара. DC Великобритании является глобальным, в то время как другие два являются локальными. В таблице 2, представленной ниже, иллюстрируется классификаций для 3 DC.

Формируют MNO. Поскольку каждому MNO принадлежит пакетная базовая сеть, они основываются на глобальном ядре для глобальных шаблонов. Глобальные шаблоны модифицируют для локального использования. Например, фунт изменяют на франк, часовые пояса делают локальными, и QuantumLeap реализует эти дескрипторы для локального использования, используя глобальный роуминг между центрами данных трех сетей. VLAN назначает пару нечетных/четных передающих и приемных каналов.

Абонент может быть сформирован или может быть имитирован, используя сеансы CloudEPC SGW. Сеансы абонента, исходящие из eNodeB, могут формировать сеансы по MY-MNO1, MY-MNO2, или MY-MNO, используя абонент поддержки QL (SUB) API и API сеанса.

В другом варианте осуществления, только одному из операторов MY-MNO принадлежит спектр и ресурсы ММЕ. Двум MVN, MY-MVNO1 и MY-MVNO2 принадлежат другие ресурсы. В Таблице 3, представленной ниже, иллюстрируются параметры. Операции ММЕ представляют ClearWire™, как Р-МАО в MY-MNO и виртуальный случай, назначенный для Sprint и Leap, соответственно, в MY-MVNOL и MY - MVNO2. Кроме того, APN основаны на используемом EPC, поскольку каждому объекту принадлежит, по меньшей мере, один кластер EPC в пределах их DC.

При исходной установке РАО, MY-MNO, организует свои ресурсы центра данных (серверы, накопители, переключатели) в иерархии зоны/сайта/ОС/РОО/кластера/стойки/узлы. РАО запускает CMS для невиртуализированных серверов. Другие вычислительные ресурсы работают на гипервизорах, таких как KVM. РАО использует CMS для ресурсов из набора. CMS и узлы используют специализированную сеть администрирования для обмена данными. В РАО работает QuantumLeap. CMS представляет собой OpenStack™. QL и другие модули OpenStack™ предоставляют услуги MNFV. Это повторяется для MY-MNO, MY-MVNO1 и MY-MVN2 владельцев с использованием РАО, которые передают владельцам.

Владелец MY-MNO теперь имеет радиоресурсы, распределяемые по всем трем сайтам, C1, S1, L1. MY-MNO определяет формирование APN для каждого сайта отдельно и обрабатывает APN-SP и APN-LP для MY-MVNOL и MY-MVNO2, соответственно. MY-MVNO сохраняет APN-CW для его собственного использования. MY-MNO теперь добавляет:

Затем, Clearwire назначает V-MAO Sprint и Leap для RAN, распределяющую использование MVNO. Это выполняется следующим:

В дополнительном варианте осуществления уровень 1 переносит прогоны программы, которой он управляет, по инфраструктуре провайдера услуги третьей стороны. Уровень 1 переносит владельцев аппаратных средств SGW и PGW и спектра для оперирования зоной/сайтом/БС/кластером. Однако, программное обеспечение MPaaS для CloudEPC и аппаратные средства принадлежат третьей стороне, которая представляет собой РАО. MNO формируют, и ему назначают спектр VDF через:

Владелец MY-MVNO может формировать экземпляр MPaaS, как виртуальный контекст для VDF, для использования в Шанхае, локальной области Пудун в зоне Южного Китая. Это выполняется с использованием:

Абонент может быть сформирован или может быть имитирован, используя инструмент генератора трафика или сеансы CloudEPC SGW, для демонстрации, что сеансы абонента, исходящие из eNodeB, могут формировать сеансы по MNO или MPaaS, используя QL SUB API и сеанс API.

В другом варианте осуществления весь APN принадлежит одному абоненту, который получает сетевые ресурсы из MY-MNO, в соответствии необходимостью. При исходной установке РАО, MY-MNO организует свои центральные ресурсы данных (серверы, накопители, переключатели) в иерархии зона/сайт/БС/РОО/кластер/стойка/узел. В РАО работает CMS на невиртуализированных серверах. В других вычислительных ресурсах работают гипервизоры, такие как KVM. РАО использует CMS, для формирования набора ресурсов. CMS и узлы используют специализированную сеть администрирования для обмена данными. В РАО работает QL. CMS представляет собой OpenStack™. QL, с другими модулями OpenStack™, предоставляет услугу MNFV. Когда устанавливают оба кластера ядра ЕРС и путь радиоузла с помощью MY-MNO, его абонент получает его MPaaS. MY-MNO теперь добавляет:

Абонент может быть сформирован или может быть имитирован, используя инструмент генерирования трафика или UE с сеансами VMN01 по VMNO1, VMNO2 или MY-MNO, используя QL SUB API и сеанс API.

Типы запроса и отклика могут поддерживаться в формате данных JSON. Формат для типов запроса и ответов может быть установлен, используя заголовок допуска или путем добавления расширения .son для запрашиваемого URL. Пример Запроса определяется следующим образом:

POST/vl.O/tenants/tenant/networks HTTP/1.1

Host 127.0.0.1:9696 Приложение типа содержания/json

Принять приложение/json

Длина содержания 57

Могут присутствовать синхронные и асинхронные плагины. Возможности подключения мобильной сети логической модели мобильной сети с кластерами мобильной сети, узлами, портами и подсетями представляют собой API QuantumLeap. Плагины связываются с Neutron и/или расположенной непосредственно под ним инфраструктурой, для того, чтобы способствовать перенаправлению пакета, который соответствует логической модели. Плагин может выполнять такие операции асинхронно, таким образом, что когда клиент API модифицирует логическую модель, используя HTTP POST, PUT или DELETE, вызов API может возвращаться перед модификациями при выполнении плагина для расположенных под ними виртуальных и/или физических виртуальных устройств переключения.

Последующие вызовы API соответствующим образом отражают измененную логическую модель. В одном примере клиент использует HTTP PUT, для установления прикрепления для порта. Порт представляет собой порт виртуального переключателя по переключателю логической сети. Виртуальные экземпляры прикрепляют свои интерфейсы к портам. Логический порт также определяет адрес контроллера доступа к среде (MAC) и IP-адрес, который должен быть назначен, к их подключению в интерфейсах. Когда IP-адреса ассоциированы с портом, порт ассоциирован с подсетью, поскольку адрес IP был принят из выделенного набора для определенной подсети. Подсеть представляет собой блок IP-адреса, который может использоваться для назначения IP-адресов в виртуальных экземплярах. Подсети могут иметь бесклассовые процедуры внутри домена (CIDR), которые ассоциированы с сетью. IP-адреса могут быть выбраны из всей подсети CIDR или из наборов выделения, которые могут быть установлены пользователем. При этом отсутствует гарантия того, что пакеты, переданные интерфейсом, наименованным при прикреплении, будут перенаправлены непосредственно после возврата HTTP. Однако существует гарантия того, что последующий HTTP GET, для просмотра прикрепления по порту, мог бы вернуть новое значение прикрепления. Атрибут "статус", доступный для кластера/сети EPC и ресурсов порта, можно использовать для понимания, была ли успешно закончена конфигурация плагина QuantumLeap для интересующего ресурса.

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

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

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

В представленной ниже таблице 4 показаны комбинации топологии, которые могут использоваться как дескрипторы, например, pgw.xml, комбинация pgw.xml и sgw.xml, или три минимальных из mme.xml, sgw.xml и pgw.xml. Дескрипторы представляют собой объекты форматирования XML или JSON в иерархии, описывающей узлы и их интерфейсы, для формирования кластера из узлов, работающих вместе. CRUD представляет собой базовые функции постоянного накопителя при программировании в компьютере. CRUD (L, S) X представляет собой стандарт вызова REST, как формирование вызовов типа SQL, считывания, обновления, удаления (список, представление) в API. X предназначен для выполнения или для запуска программных объектов.

Кластер EPC может использовать контексты MNO или MVNO вместе с зонами, местами и центрами данных перед их потреблении абонентами. В таблице 5 представленной ниже, показаны некоторые блоки построения QuantumLeap для иерархической реализации и потребления услуг данных абонентом, использующим доступ к мобильной сети.

В Таблице 6, представленной ниже, представлены объекты и функции API для сетевых операций мобильной несущей для автоматизации и миграции облака. <GeoLoc> представляет собой возможный рекурсивный иерархический объект, выбираемый из зоны, сайта, DC, кластера, узла и сервера. Сервер представляет собой физический уровень или уровень гипервизора, возможно VM. Наименование функции представляет собой одно из Provision, Program, Decommission, Status и Ignore. VNF представляет собой один или больше из vEMS, vMME, vSGW, vPGW, vPCRP, vHSS, виртуальный eNB (veNB), виртуальный Nano (vNano), vIMS, виртуальный Открытый компьютер и программное обеспечение (vOCS), VNF и виртуальный AF (vAF). Программа представляет собой одну или комбинацию из операционной системы (OS), пакета, компонента, соединения, интерфейса и связи. Операция представляет собой одну или комбинации Сеанса, DefBearer, GBR, QoS, DRB, SRG, Tunnel, GTP, Generic Routing Encapsulation (GRE), Alloc и Dealloc. Профиль может быть установлен для абонента INDI, FAN, для корпорации или организации с несколькими группами виртуального облака (VCG) и привязан к APN (s). VCG представляет собой группировку либо из EPC, или RAN в кластере или в облаке, которая может быть описана, как модуль. Дескрипторы могут использовать политику, профили абонента, списки управления доступом и другие доступные средства в API для определения опций для MNO/MVNO, для администрирования сетями при радиопередаче, в оболочке или их комбинации, используя правила. Аналогично, некоторые индивидуальные или группы объектов могут отслеживаться для активного или неактивного статуса и/или протокола. Объект уведомляет это в ответ на заданные значения, установленные для уведомления триггера в дескрипторах.

Архитектура варианта осуществления MNFV является модульной для поддержки гибких, адаптируемых и расширяемых API через платформы открытого источника, Linux® и OpenStack™, для виртуализации и свойств виртуализации, таких как KVM/ контейнеры Linux (LXC) и множество выполнений для MNO через OpenStack™ CMS.

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

Кроме того, интерфейсы для связи узлов инфраструктуры сети, связанные через южный интерфейс в облаках EMS и EPC, могут поддерживать поставщиков третьей стороны. Интерфейс между модулем 396 QuantumLeap и CMS 400 может использоваться, как брокер для других облаков, для администрирования инфраструктурой CloudEPC для MNO и их ассоциированных MVNO.

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

Поскольку архитектура MNFV является радионейтральной, она может применяться в разных системах радиоадминистрирования, включая в себя малую соту, UMTS, LTE, Advanced LTE, Ethernet или IP трафик, для поддержки QoS и дифференцируемых услуг.

Управление и правила политики, ассоциированные с уровнем пользователя, для использования ресурсов, уведомляют для модулей OSS/BSS через интерфейсы уведомления, используя CMS.

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

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

VCG изолирует группы радиосот и/или базовой EPC, или кластеров облака EPC. Тип группы EPC и RAN с дополнительными атрибутами APN мобильного происхождения или окончания мобильной сети или сеансы связаны, как ресурсы для использования услуги и начисления счетов.

Выполняются аутентификация и авторизация. QuantumLeap может использовать услугу идентичности Keystone OpenStack™, в качестве принятой по умолчанию услуги аутентификации. Когда разрешен Keystone, пользователи подают запросы в услугу QuantumLeap, предоставляя метку аутентификации в заголовке запроса метки X-Auth-. Метка могла быть получена в результате аутентификации с использованием Keystone.

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

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

Вариант осуществления выполняет управление GTP для VxLAN через интерфейс Sx в мобильном CloudEPC для туннелирования между конечными точками. Передачи из "точки-в-точку" (РТР) представляет собой группу протоколов обмена данными на основе IP для GPRS для сетей. В архитектуре 3GPP, интерфейсы на основе GTP и прокси мобильного IPv6, установлены в различных точках интерфейса. GTP могут быть разложены на отдельные протоколы, GTP-C, GTP-U и GTP'. GTP-C используется в пределах ядра сети GPR для передачи сигналов между узлами поддержки шлюза GPRS (GGSN), и обслуживающими узлами поддержки GPRS (SGSN). Таким образом, SGSN активирует сеанс от имени пользователя и деактивирует сеанс для регулирования качества параметров услуги (QoS) или для обновления сеанса для абонента, который только что прибыл из другой SGSN. GTP-U используется для переноса данных пользователя в пределах базовой сети GPRS и между сетью радиодоступа и базовой сетью. Транспортируемые данные пользователя могут представлять собой пакеты IPv4, IPv4 или форматов протокола из "точки-в-точку" (РРР). GTP' использует те же структуры обмена сообщениями, что и GTP-C и GTP-U, но используется для переноса данных о начислении счетов из функции данных начисления счетов (CDF) Глобальной системы мобильной передачи данных (GSM) или сети UMTS, для функции шлюза начисления счетов (CGF).

В варианте осуществления элементами мобильной сети управляют через RESTful API. Это может быть выполнено через CMS, в случае необходимости, через EMS. В качестве альтернативы, элементами мобильной сети управляют через адаптеры, где администрирование облаком не предоставляют взаимодействие для сети.

Вариант осуществления работает на основе потока, где поток сообщения протекает через модуль запроса RabbitMQ, в то время, как сохранение метаданных достигается на основе модульной базы данных в MySQL. В одном примере команда QuantumLeap вырабатывается через интерпретатор командной строки (CLI) или горизонтальный плагин, который выполняет привод потоков производителей, которые подают в топик QuantumLeap/канал/очередь через протокол организации очередей асинхронных сообщений (AMQP). Команда распространяется через планировщик NOVA или обратный вызов RPC, который возвращает механизм QuantumLeap, для получения услуги из рабочих потоков.

Рабочие потоки транслируют из планировщика для вызова запроса или ответа в CloudEPC или физические узлы, например, через OpenStack™ или EMS. CloudEPC включает в себя функции EPC, которые размещены в облаке или в кластерах. CloudEPC представляет собой виртуальное изображение с композитными или множеством изображений, изготовленными из vMME, vSGW, vPGW), vPCRF и/или vHSS.

В одном примере используется интерфейс программирования RESTful, для администрирования объектами услуги MNFV северного интерфейса и соответствующими вызовами южного интерфейса для кластера CloudEPC и/или физических узлов. Плагины SB и NB API определяют дополнения, которые используются для обработки фиксированного или кабельного участка кластера виртуальной сети, например, для установки VLAN или VxLAN.

Пример имеет архитектуру, пригодную для формирования плагина, где REST API поддерживаются различными объектами для формирования облака виртуального кластера мобильный сети. Могут быть добавлены дополнительные плагины. Кроме того, пользователи могут иметь возможность использовать разные варианты воплощения кластера EPC. Некоторые примерные плагины включают в себя РАО, MNO, MVNO, <geolocation (GeoLoc)> = (Зона, сайт, центр данных, кластер, узел, сервер), APN, VNF, Абонент и Сеанс. VNF вызывают через SB, в то время как РАО, MNO, MVNO, GeoLoc, APN, SUB и сеанс вызывают через NB. VNF может быть подклассифицирован, для поддержки кластера EPC, ММЕ, SGW и PGW для SB, для прохода через вызов.

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

В ответ может быть принят отклик формирования. Пример отклика формирования JSON представлен следующим:

Пример отклика EPC представлен следующим:

НТТР/1/1 200 Accepted Content-Type application/json

Content-Length 204

В одном примере воплощение уведомления уровня приложения воздействует на механизмы регистрации событий OpenStack™ Ceilometers. В примере QuantumLeap регистрирует интерфейс SI с ID = ''35bl7138-b364-4e6a-al31-8f3099c5be68'', и устанавливает пик SI так, чтобы он не превышал SIHighCap, например, 10 Мбит/с. Когда Si-пик > SIHighCap, приложение получает предупреждение, и определяет, следует ли добавить другой Si-Интерфейс для удвоения пропускной способности интерфейса eSl. Пример выборки измерителя JSON для уведомления уровня приложения (ALN) задан следующим:

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

Вариант осуществления QuantumLeap API является растяжимым. Растяжение способствует введению новых свойств в API без изменения версии. Кроме того, расширение способствует введению специфичной для поставщика нишевой функциональности и обеспечению испытательного полигона для экспериментальных функций. Приложения могут программным способом определять, какие расширения являются доступными, путем выполнения команды GET для vl.0/расширений URI. Расширения можно запрашивать индивидуально, используя уникальный псевдоним, путем выполнения операции GET для /vl.0/extensions/alias_name. Существующие ресурсы API ядра могут быть расширены с приданием им новых действий или дополнительных атрибутов. Кроме того, новые ресурсы могут быть добавлены, как расширения. Расширения могут иметь метки, которые предотвращают столкновения с другими расширениями, определяя атрибуты и/или ресурсы с таким же названием, что и ресурсы и атрибуты ядра. Доступность расширения может зависеть от развертывания и специфичного использования плагина.

Когда происходит отказ при обработке запроса, QuantumLeap API возвращает ответ с ошибкой. QuantumLeap использует стандартные коды ошибки HTTP. Ошибки 4хх обозначают проблемы в конкретном запросе, переданном клиентом. В Таблице 7 иллюстрируются некоторые примерные ошибки. Пользователи, подающие запрос в QuantumLeap API, также могут принимать неавторизованную 401, когда предоставляют недействительные полномочия и ошибку 403 Forbidden (запрещено), когда пользователь не может обратиться к определенному ресурсу или выполнить запрашиваемую операцию.

Пример запроса JSON для сайта Create And Assign задается следующим:

Пример отклика JSON для сайта CreateAndAssign определяется следующим:

Пример APN формирования Json определяется следующим:

Пример APN ответа JSON определяется следующим:

Пример VNF формирования Json определяется следующим:

Пример VNF ответа JSON определяется следующим:

Пример SUB запроса и аутентификации JSON определяется следующим:

Пример SUB ответа JSON определяется следующим:

Пример формирования операции или сеанса JSON определяется следующим:

Пример ответа операции или сеанса JSON определяется следующим:

API VNF используется для внутренних интерфейсов EPC и связи. API описан как место назначения соединения дескриптора для дескриптора соединения изображения для изображения с наименованием функции ID VNF.

Атрибуты API представляют собой:

VNF=MME-Instance-id, function-name=Program, Image=Script image-link=http://mysite.org/rnmel.sh Descriptor=mme.xml Descriptor - link=http://mysite.org/mmel.xml Destination=MME-Instance-IP-address

Наименование изображения "script" относится процедурам реализации перед и после установки, в зависимости от наименования функции. В этом примере наименование функции представляет собой программу, и доступен экземпляр ID или VNF. Таким образом, сценарий последующей установки работает для конфигурирования интерфейсов и связей в дескрипторе. Дескриптор mmel.xml или 5 узлов epc.xml содержат интерфейсы на уровне управления и интерфейсы на уровне данных. Интерфейсы на уровне управления или CIO ввода/вывода управления могут включать в себя от S1-MME - eNB до ММЕ, от S6a - ММЕ до HSS, от S11 - ММЕ до S-GW и от Sp - HSS до PCRF. Интерфейсы на уровне данных или DIO ввода/вывода данных включают в себя от S1-U - eNB до S-Gw, от S5 - S - GW до P-GW, от S8 - S-GW до P-GW, от SGi - доступ к Интернету, Gx - P-GW до PCRF и от Gxc - S-GW до PCRF. Атрибуты включают в себя полосу пропускания BW на расстоянии, задержку D, время RTT на отправку и возврат сигнала, дрожание J, уровень услуги QCI15, и малая/средняя/большая характерная особенность.

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

Стандартный API северного интерфейса используется для MNO/MVNO/EMS, в то время как стандартный API южного интерфейса используется для отображения, затем NB на SB 1 aaS через CMS. Здесь может использоваться интегрирование до OpenStack™.

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

На фиг. 20 иллюстрируется блок-схема системы 270 обработки, которая может использоваться для воплощения раскрытых здесь устройств и способов. Определенные устройства могут использовать все представленные компоненты или только поднабор компонентов, и уровни интеграции могут изменяться от устройства к устройству. Кроме того, устройство может содержать множество экземпляров компонента, таких как множество модулей обработки, процессоров, запоминающих устройств, передатчиков, приемников и т.д. Система обработки может содержать модуль обработки, оборудованный одним или больше устройствами ввода, такими как микрофон, "мышь", сенсорный экран, клавишная панель, клавиатура и т.п. Кроме того, система 270 обработки может быть оборудована одним или больше устройствами вывода, такими как громкоговоритель, принтер, дисплей и т.п.. Модуль обработки может включать в себя центральное процессорное устройство (CPU) 274, запоминающее устройство 276, массовое запоминающее устройство 278, видеоадаптер 280 и интерфейс 288 ПО, соединенный с шиной.

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

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

Видеоадаптер 280 и интерфейс 288 ПО обеспечивают интерфейсы для соединения внешних устройств ввода и вывода с модулем обработки. Как представлено, примеры устройств ввода и вывода включают в себя дисплей, соединенный с видеоадаптером, и "мышь"/клавиатуру/принтер, соединенные с интерфейсом ПО. Другие устройства могут быть соединены с модулем обработки, и можно использовать дополнительные или меньшее количество карт интерфейса. Например, карта последовательного интерфейса (не показана) может использоваться для предоставления последовательного интерфейса для принтера.

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

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

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

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

Claims (36)

1. Способ для виртуализации функции мобильной сети (MNFV), содержащий:

формируют кластер ядра развернутого пакета (ЕРС),

ассоциируют подсеть с кластером ЕРС

загружают виртуальную машину (VM) и

прикрепляют VM к ЕРС.

2. Способ по п. 1, дополнительно содержащий:

удаляют VM и

удаляют кластер ЕРС.

3. Способ по п. 1, в котором прикрепление VM к ЕРС содержит: контактируют с системой администрирования облаком (CMS).

4. Способ по п. 1, дополнительно содержащий: формируют порт VM.

5. Способ по п. 4, дополнительно содержащий:

формируют контроллер сетевого интерфейса (NIC) и

прикрепляют NIC к порту.

6. Способ по п. 5, дополнительно содержащий: удаляют порт.

7. Способ по п. 4, дополнительно содержащий: определяют адрес протокола Интернета (IP) порта.

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

9. Способ по п. 8, в котором выполнение географического разделения содержит:

формируют глобальную зону,

ассоциируют сайт с глобальной зоной,

формируют локальную зону,

ассоциируют локальную зону с глобальной зоной,

ассоциируют локальную зону с местом и

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

10. Способ по п. 1, в котором формирование кластера ЕРС содержит: формируют кластер ЕРС, используя программный интерфейс приложения (API).

11. Способ по п. 1, дополнительно содержащий: передают управление политикой и правилом на уровне пользователя в систему поддержки операции (OSS).

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

13. Способ по п. 1, дополнительно содержащий: тестируют кластер ЕРС.

14. Способ по п. 1, дополнительно содержащий: передают запрос плагин в систему администрирования элементом (EMS).

15. Способ по п. 1, дополнительно содержащий: формируют наименование точки доступа (APN) для сайта.

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

17. Компьютер, содержащий:

процессор и

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

ассоциирования подсети с кластером ЕРС,

исходной загрузки виртуальной машины (VM) и

прикрепления VM к ЕРС.

Images