СПОСОБЫ И УСТРОЙСТВА ДЛЯ ГИБКОГО УПРАВЛЕНИЯ МОБИЛЬНОЙ СВЯЗЬЮ В СОТОВЫХ СЕТЯХ
METHODS AND DEVICES FOR FLEXIBLE MOBILE STEERING IN CELLULAR NETWORKS

Область техники, к которой относится изобретение
Варианты осуществления настоящего раскрытия, в общем, относятся к области беспроводной связи и, в частности, к способам и устройствам для гибкого управления мобильной связью в сотовых сетях.
Уровень техники
Исследования гибкого управления услугами мобильной связи (FMSS) направлены на потенциальные требования для поддержания классификации трафика и возможностей выбора цепочки услуг в расчете на политику оператора для того, чтобы реализовать эффективное и гибкое управление услугами мобильной связи в сетях (S)Gi-LAN.
Краткое описание чертежей
Варианты осуществления будут полностью поняты из последующего подробного описания совместно с сопроводительными чертежами. Для облегчения этого описания одинаковые ссылочные позиции обозначают одинаковые структурные элементы. Варианты осуществления проиллюстрированы посредством примера, а не ограничения, на фигурах сопроводительных чертежей.
На фиг.1 показана среда связи в соответствии с некоторыми вариантами осуществления.
На фиг.2 показана блок-схема последовательности операций процесса управления в соответствии с некоторыми вариантами осуществления.
На фиг.3 показана блок-схема последовательности операций процесса предоставления правил в соответствии с некоторыми вариантами осуществления.
На фиг.4 показана блок-схема последовательности операций процесса создания отчетов в соответствии с некоторыми вариантами осуществления.
На фиг.5 показана среда связи в соответствии с некоторыми вариантами осуществления.
На фиг.6 показана блок-схема последовательности операций процесса обновления в соответствии с некоторыми вариантами осуществления.
На фиг.7 показаны компоненты среды связи в соответствии с некоторыми вариантами осуществления.
На фиг.8 показано вычислительное устройство в соответствии с некоторыми вариантами осуществления.
Подробное описание изобретения
Различные аспекты иллюстративных вариантов осуществления будут описаны с помощью терминов, обычно применяемых специалистами в данной области техники для передачи сущности их работы другим специалистам в данной в технике. Однако специалистам в данной области техники будет очевидно, что альтернативные варианты осуществления можно осуществить на практике только с помощью некоторых описанных аспектов. В целях объяснения конкретные числа, материалы и конфигурации изложены для того, чтобы обеспечить полное понимание иллюстративных вариантов осуществления. Однако специалистам в данной области техники будет очевидно, что альтернативные варианты осуществления можно осуществить на практике без специфических деталей. В других случаях хорошо известные признаки опущены или упрощены для того, чтобы не усложнять иллюстративные варианты осуществления.
Кроме того, различные операции будут описаны в виде многочисленных дискретных операций, в свою очередь, способом, который является наиболее полезным при понимании иллюстративных вариантов осуществления; однако очередность описания не следует истолковывать, как предполагающий то, что эти операции обязательно имеют зависимую очередность. В частности, эти операции не обязательно выполнять в порядке представления.
Фраза "в некоторых вариантах осуществления" используется повторно. Как правило, фраза не относится к одним и тем же вариантам осуществления; однако это возможно. Термины "содержащий", "имеющий" и "включающий в себя" являются синонимами, если из контекста не следует иное.
Фразы "A или B", "A/B" и "A и/или B" означают (A), (B) или (A и B).
Термин "схема", используемый в данном документе, относится к, является частью или включает в себя компоненты аппаратных средств, такие как специализированная интегральная микросхема (ASIC), электронная схема, логическая схема, процессор (совместно используемый, специализированный или групповой) и/или память (совместно используемая, специализированная или групповая), которые сконфигурированы для обеспечения описанных функциональных возможностей. В некоторых вариантах осуществления схема позволяет исполнить одну или более программ, реализованных программными или программно-аппаратными средствами для обеспечения по меньшей мере некоторых из описанных функциональных возможностей.
Иллюстративные варианты осуществления настоящего раскрытия включают в себя, но не ограничиваются ими, способы, системы, машиночитаемые носители и устройства, которые можно использовать в сфере услуг и системных аспектах для FMSS в различных случаях применения в мобильных широкополосных сетях, таких как сети стандарта долгосрочного развития (LTE) и усовершенствованного стандарта LTE-Advanced. Используемая в данном документе ссылка на LTE может включать в себя LTE, LTE-A или любые другие версии LTE, если не указано иное. Случаи использования, описанные здесь, могут включать в себя, но не ограничиваются ими: классификацию и управление трафиком на основании характеристик приложения; управление трафиком на основании подписки пользователя; и управление трафиком на основании состояния сети.
На фиг.1 схематично показана среда 100 связи в соответствии с различными вариантами осуществления. Среда 100 связи может включать в себя компоненты операторской сети 104 и компоненты сети 108 (S)Gi-локальной вычислительной сети (LAN). Операторская сеть 104 и сеть 108 (S)Gi-LAN могут поддерживать связь через интерфейс 112 (S)Gi. Интерфейс Gi может быть интерфейсом после GGSN с выходом в Интернет, и интерфейс SiGi может быть интерфейсом после PGW с выходом в Интернет. Для цели настоящего описания ссылка на интерфейс (S)Gi может в общем случае относиться к любому интерфейсу. Аналогичным образом, ссылка на (S)Gi-LAN может относиться к любой LAN.
Компоненты среды 100 связи можно реализовать в виде различных устройств, например, сервера, и они могут поддерживать связь друг с другом через внешние интерфейсы связи, как показано в общем виде. В некоторых вариантах осуществления один или более компонентов среды 100 связи можно совместно реализовать в одном устройстве. Некоторые конкретные совместные реализации раскрыты в данном документе, но можно также использовать и другие реализации.
Операторская сеть 104 может быть сетью LTE, которая включает в себя, например, сеть 116 радиодоступа (RAN), которая обеспечивает радиоинтерфейс для пользовательского оборудования (UE), коммуникативно связанного с операторской сетью 104. RAN 116 можно соединить со шлюзами сети пакетной передачи данных (PGW)/шлюзовым узлом поддержки общей службы пакетной радиопередачи (GGSN) 124 через другие шлюзы (GW) 120, которые могут включать в себя, например, обслуживающий шлюз.
PGW/GGSN 124 могут быть общими шлюзами, через которые UE может осуществлять доступ к конкретной сети пакетной передачи данных (PDN). PGW/GGSN 124 могут управлять применением политики, фильтрацией пакетов для пользователей и функциями тарификации.
PGW/GGSN 124 могут быть связаны с функцией 128 обнаружения трафика (TDF). TDF 128 может обеспечить возможность обнаружения трафика услуг на основании информации об абоненте, приложении, содержании и устройстве. TDF 128 может управлять пропусканием обнаруженного трафика услуг и блокировать, разрешать, формировать или переадресовывать трафик услуг по мере необходимости.
PGW/GGSN 124 могут быть дополнительно связаны с функцией реализации правил политики и тарификации (PCRF) 132 через интерфейс Gx. Интерфейс Gx позволяет соединить PCRF 132 с функцией реализации правил политики и тарификации (PCEF) в PGW/GGSN 124 и может использоваться PCRF 132 для предоставления правил управления политикой и тарификацией (PCC) в и удаления правил PCC из PCEF. Правила PCC позволяют выполнить идентификацию потока данных услуг (SDF) для упрощения реализации подходящих параметров тарификации и управления политикой для SDF. Интерфейс Gx можно также использовать для передачи событий в плоскости трафика из PCEF в PCRF 132. Интерфейс Gx может соответствовать определениям интерфейса Gx, приведенным в технической спецификации (TS) 3GPP 29.212 vl2.6.0 (2014-09-26).
Интерфейсы между различными элементами, как описано в данном документе, могут ассоциироваться с соответствующими протоколами связи, которые обеспечивают предполагаемые типы трафика, передаваемого через соответствующий интерфейс. Например, различные интерфейсы могут предоставлять протоколы, которые поддерживают транзакции в реальном времени, режимы без отслеживания состояния (например, тарификация на основе событий), режимы с отслеживанием состояния (например, тарификация на основе сеансов), механизмы надежности и т.д. в зависимости от конкретных потребностей трафика. В некоторых вариантах осуществления интерфейс может также упоминаться как опорная точка.
TDF 128 может быть связана с PCRF 132 через интерфейс Sd. Интерфейс Sd можно использовать для передачи запроса на обнаружение трафика услуг из PCRF 132 в TDF 128. Запрос на обнаружение трафика услуг может включать в себя, например, идентификатор приложения. Интерфейс Sd можно дополнительно использовать для создания отчета об обнаружении потоков услуг из TDF 128 в PCRF 132. Отчет об обнаружении потоков услуг может включать в себя, например, информацию о потоке услуг. Интерфейс Sd может соответствовать определениям интерфейса Sd, приведенным в 3GPP TS 29.212.
В некоторых вариантах осуществления TDF 128 может быть дополнительно связана с функцией 134 управления услугой (SSF). SSF 134 может выполнять функции контроля и управления услугами (SSC) для приема и обработки запросов с целью управления трафиком приложений в конкретных инструментах реализации услуг (SE) (S)Gi-LAN 108 и для применения предписанных действий по реализации управления услугами и тарификации по отношению к данным, которые передаются из или принимаются с помощью операторской сети 104. Функции SSC могут обеспечить то, чтобы конкретный SDF, например, был маршрутизирован последовательным образом по цепочке услуг одного или более инструментов реализации услуг (SE) (S)Gi-LAN 108, например, SE1 136, SE2 140 и SE3 144. SSF 134 может поддерживать связь с SE через интерфейс 112 (S)Gi.
SSF 134 можно соединить с PCRF 132 через интерфейс Ss. Интерфейс Ss позволяет обеспечить применение правил SSC в SSF и позволяет дополнительно обеспечить применение информации о нагрузке SE в PCRF 132, как описано в настоящем документе.
Хотя на фиг.1 показана SSF 134 в виде отдельного элемента, в некоторых вариантах осуществления SSF может быть включена в TDF 128 или, в случае исходящего трафика (например, трафика, отправляемого из операторской сети 104), в PCEF PGW/GGSN 124. В вариантах осуществления, в которых SFF 134 находится в PCEF, правило SSC может быть частью правила управления политикой и тарификацией (PCC), и в вариантах осуществления, в которых SFF 134 находится в TDF 128, правило SSC может быть частью правила обнаружения и управления приложением (ADC).
SE (S)Gi-LAN 108 позволяет выполнить специфические функции обработки, которые могут привести к повышению качества восприятия пользователя, уменьшению нагрузки на полосу пропускания или предоставлению некоторых других дополнительных видов услуг. В некоторых вариантах осуществления SE могут включать в себя фильтр URL (например, для блокирования небезопасных URL или URL с ограниченным доступом), процесс оптимизации видео (например, для адаптации разрешения видео и скорости передачи битов согласно терминалу пользователя), средство оптимизации протокола (например, для использования многокомпонентного или конвейерного механизма для оптимизации протокола HTTP), брандмауэр и т.д. SE могут располагаться в дискретных устройствах, или множество SE может совместно располагаться в одном устройстве.
На фиг.2 показана блок-схема последовательности операций процесса 200 управления SSF 134 в соответствии с некоторыми вариантами осуществления.
На этапе 204 процесс 200 управления может включать в себя прием набора правил SSC из PCRF 132. Набор правил SSC может быть принят SSF 134 через интерфейс Ss.
Правило SSC может обеспечить индикацию того, как конкретная SDF или ее части должны быть маршрутизированы посредством одного или более SE на основании характеристик приложений, политик операторской сети 104, пользовательских данных подписки, состояния сети, времени/местоположения, информации о качестве обслуживания (QoS) и т.д. Например, правила SSC могут обеспечить то, что трафик данных, выработанный из веб-браузера, должен быть маршрутизирован через инструмент реализации услуг, который обеспечивает оптимизацию протокола для улучшения восприятия пользователя в соответствии с политикой оператора; трафик данных с высоким приоритетом может быть маршрутизирован во избежание рекламных объявлений; трафик данных для пользователя, имеющего разрешенную фильтрацию вирусов, может быть маршрутизирован через инструмент реализации услуг для проверки на наличие вирусов, вредоносных программ и т.д. и при необходимости разрешение блокировки или деактивации трафика и т.д. Можно также предположить много конкретных сценариев маршрутизации и инструментов реализации услуг.
Отдельные правила SSC из набора правил SSC, принятых SSF 134, могут включать в себя идентификатор правила SSC, один или более идентификаторов приложений, один или более идентификаторов SDF и один или более идентификаторов SE.
На этапе 208 процесс 200 управления может включать в себя идентификацию SDF в пределах операторской сети. SDF можно идентифицировать путем приведения в соответствие идентификатора, принятого при установке SDF с помощью идентификатора SDF правила SSC. В некоторых вариантах осуществления идентификатор SDF может включать в себя набор из 5 элементов, которые идентифицируют пять различных значений, которые содержит подключение через протокол управления передачей данных/Интернет-протокол (TCP/IP). Набор из 5 элементов может включать в себя, например, IP-адрес источника, количество портов, IP-адрес пункта назначения и протокол.
На этапе 212 процесс 200 управления может включать в себя маршрутизацию SDF через один или более SE. Правило SSC может показывать, что пакеты конкретной SDF должны быть маршрутизированы по упорядоченной цепочке из множества SE, идентифицированных с помощью правила SSC. Например, со ссылкой на фиг.1, правило SSC может показывать, что соответствующая SDF должна маршрутизироваться первой через SE1 136, затем через SE3 144 и затем передаваться в компоненты PDN, например, маршрутизаторы, сетевые коммутаторы и т.д., по направлению к пункту их назначения. SSF 134 может применять правило SSC, путем принудительной передачи пакетов SDF по цепочке SE с очередностью, заданной правилом SSC.
В некоторых вариантах осуществления реализацию правила SSC можно достичь, используя любой тип туннеля 2-го уровня. Туннели 2-го уровня включают в себя, но не ограничиваются ими, туннели Ethernet, туннели идентификатора (ID) виртуальной локальной вычислительной сети (VLAN), многопротокольную коммутацию по меткам (MPLS) и туннели "IP в IP". SSF 134 может передать SDF в SE1 136 через туннель 2-го уровня. После того, как SE1 136 выполнит свои операции в отношении SDF, он может передать SDF обратно в SSF 134 через тот же самый туннель 2-го уровня. После приема SDF из SE1 136, SSF 134 может использовать разворот туннеля 2-го уровня для передачи SDF в следующий SE в цепочке, например, SE3 144, или разрешить трафик из операторской сети 104.
Хотя на фиг.1 показано правило, применимое к исходящим данным, в других вариантах осуществления может использоваться правило SSC для входящих данных, например, данных, входящих в операторскую сеть 104 из PDN. В некоторых вариантах осуществления исходящий и входящий трафик в пределах одной и той же SDF можно маршрутизировать через один и тот же набор SE, причем входящий трафик маршрутизируется по цепочке SE в обратном порядке относительно исходящего трафика.
В некоторых вариантах осуществления правила управления из правила SSC можно применить ко всем частям SDF. В других вариантах осуществления правила управления из правила SSC можно применить только к выбранным участкам, например, к данным или пакетам SDF. Например, набор идентификаторов приложений может быть включен в правило SSC для идентификации этих приложений или класса приложений, которые начинают или прекращают действия данных SDF, которая должна быть маршрутизирована через связанные с ней инструменты реализации услуг. Таким образом, в этих вариантах осуществления правило SSC можно применить только к выбранным частям SDF, которые соответствуют идентифицированным приложениям.
В некоторых вариантах осуществления, как только SSF 134 идентифицирует SDF на этапе 208, она может отметить трафик в кодовой точке дифференцированных услуг (DSCP) внутреннего или внешнего заголовка IP заголовка сетевой услуги (NSH). Это позволяет обеспечить SE цепочки услуг информацией QoS для обеспечения соответствующей обработки.
На фиг.3 показана блок-схема последовательности операций процесса 300 предоставления правил из PCRF 132 в соответствии с некоторыми вариантами осуществления. В некоторых вариантах осуществления процесс 300 предоставления правил можно проиллюстрировать примерами, когда абонент первоначально подключается к или регистрируется с помощью операторской сети 104.
На этапе 304 процесс 300 предоставления правил может включать в себя определение правила SSC для абонента. В некоторых вариантах осуществления настоящего изобретения правила SSC могут быть определены для конкретной классификации приложения абонента с учетом профиля абонента. PCRF 132 может принимать данные подписки пользователя или другую информацию (например, информацию о качестве восприятия (QoE)), на которой могут базироваться правила SSC из функции выбора и обнаружения сети доступа (ANDSF) или домашнего сервера абонента/репозитория абонентских профилей (HSS/SPR). В некоторых вариантах осуществления правила SSC можно предварительно сконфигурировать в PCRF 132. В других вариантах осуществления правила SSC можно предварительно сконфигурировать в ANDSF или HSS/SPR, и при необходимости PCRF 132 может извлечь правила SSC.
В вариантах осуществления, в которых правила SSC предварительно сконфигурированы в ANDSF или HSS/SPR, SSF 134 можно выполнить с возможностью получения правила SSC непосредственно из ANDSF или HSS/SPR, а не из PCRF 132. Такие варианты осуществления могут включать в себя новые интерфейсы между SSF 134 и ANDSF или HSS/SPR для обеспечения такой связи.
На этапе 308 процесс 300 предоставления правил может включать в себя предоставление правил SSC в SSF 134. Правила SSC можно предоставить в SSF 134 через интерфейс Ss, как обсуждено выше.
На этапе 312 процесс 300 предоставления правил может включать в себя динамическое обновление правил SSC. В некоторых вариантах осуществления динамическое обновление правил SSC может запускаться на основании информации, принятой с помощью PCRF 132, касающейся изменения профиля абонента, политики оператора, сетевой среды и т.д.
На этапе 316 процесс 300 предоставления правил может включать в себя предоставление обновленных правил SSC в SSF 134 через интерфейс Ss. В некоторых вариантах осуществления предоставление обновленных правил SSC может происходить каждый раз при обновлении правил SSC. В других вариантах осуществления предоставление обновленных правил SSC может происходить менее часто на основании, например, важности обновления, графика обновлений и т.д.
В некоторых вариантах осуществления правило SSC может быть предварительно сконфигурировано в SSF 134. В данных вариантах осуществления PCRF 132 может по-прежнему обеспечивать обновление предварительно сконфигурированного правила SSC через интерфейс Ss, как описано выше, на этапе 316, но может не потребоваться предоставление правил SSC в первоначальном виде на этапе 308.
На фиг.4 показана блок-схема последовательности операций процесса 400 создания отчетов о SSF 134 в соответствии с некоторыми вариантами осуществления.
На этапе 404 процесс 400 создания отчетов может включать в себя сбор информации о статусе динамической нагрузки из SE. Информацию о статусе динамической нагрузки можно передать в SSF 134 через интерфейс 112 (S)Gi. В некоторых вариантах осуществления SE могут периодически отправлять свою информацию о статусе нагрузки в SSF 134. В других вариантах осуществления SE могут отправлять свою информацию о статусе нагрузки после изменения статуса поверх порогового значения.
В некоторых вариантах осуществления информацию о статусе нагрузки можно определить с помощью SSF 134 косвенным образом. Например, SSF 134 может определить информацию о статусе нагрузки на основании количества трафика, направляемого в SE на основании времени обработки SE и т.д.
На этапе 408 процесс 400 создания отчетов может включать в себя определение того, запускается ли создание отчетов. В различных вариантах осуществления отчеты могут запускаться периодически или после возникновения события, например, после приема информации о статусе нагрузки из SE.
Если на этапе 408 запускается создание отчетов, то процесс 400 создания отчетов может перейти к передаче информации о статусе динамической нагрузки в PCRF 132. Информацию о статусе динамической нагрузки можно передать из SSF 134 в PCRF 132 через интерфейс Ss.
После передачи статуса динамической нагрузки на этапе 412 или после определения, что создание отчетов не запустилось на этапе 408, процесс 400 создания отчетов может вернуться к началу цикла для сбора информации о статусе динамической нагрузки из SE на этапе 404.
На фиг.5 показана среда 500 связи в соответствии с некоторыми вариантами осуществления. Компоненты среды 500 связи могут быть аналогичны одноименным компонентам, показанным и описанным по отношению к среде 100 связи. Однако среда 500 связи может дополнительно включать в себя оркестратор (модуль управления) в (S)Gi-LAN 508. В некоторых вариантах осуществления оркестратор 548 может быть частью сервера эксплуатации, администрировании и управления (OAM) в (S)Gi-LAN 508.
Оркестратор 548 можно соединить с PCRF 532 через интерфейс Rs. Оркестратор 548 можно дополнительно соединить с SE (S)Gi-LAN 508. В некоторых вариантах осуществления оркестратор 548 может выполнять процесс 400 создания отчетов вместо SSF 134. То есть оркестратор 548 может производить сбор информации о статусе динамической нагрузки из SE на этапе 404, определить, запущено ли создание отчетов на этапе 408, и передать информацию о статусе динамической нагрузки в PCRF 532 на этапе 412.
На фиг.6 показан блок-схема последовательности операций процесса 600 обновления PCRF в соответствии с некоторыми вариантами осуществления. Операцию 600 обновления можно выполнить с помощью PCRF 132 или PCRF 532.
На этапе 604 процесс 600 обновления может включать в себя прием информации о динамической нагрузке. Как обсуждено выше, информацию о динамической нагрузке можно принять из SSF 134 через интерфейс Ss или можно принять из оркестратора 548 через интерфейс Rs. Кроме того, информацию о динамической нагрузке можно принимать через периодические интервалы или интервалы отчетности на основе событий.
На этапе 608 процесс 600 обновления может включать в себя обновление правила SSC на основании информации о динамической нагрузке, принятой на этапе 604. PCRF может попытаться обновить правила SSC для того, чтобы уменьшают нагрузку на перегруженном SE. В некоторых вариантах осуществления это можно сделать путем повторной маршрутизации одного или более потоков данных из перегруженного SE. В некоторых вариантах осуществления PCRF может обновить правила SSC для того, чтобы более равномерно распределить нагрузку среди имеющихся SE.
На этапе 612 процесс 600 обновления может включать в себя предоставление обновленных правил SSC в SSF (например, SSF 134 или SSF 534). Обновленные правила SSC можно предоставить в SSF через интерфейс Ss.
На фиг.7 показаны более подробно компоненты среды связи 700. В частности, на фиг.7 показана PCRF 704, связанная с SSF 708 и, если требуется, с оркестратором 712.
PCRF 704 может быть аналогичной и по существу взаимозаменяемой по отношению к PCRF 132 или PCRF 532. PCRF 704 может включать в себя интерфейсную схему 716, соединенную со схемой 720 управления.
Интерфейсную схему 716 можно выполнить с возможностью поддержания связи с другими сетевыми объектами через различные интерфейсы с использованием соответствующих сетевых протоколов связи. Например, в некоторых вариантах осуществления интерфейсную схему 716 можно выполнить с возможностью поддержания связи с оркестратором 712 через интерфейс Rs с использованием протокола связи Rs. В частности, интерфейсная схема 716 может принимать информацию о статусе динамической нагрузки из оркестратора 712.
Интерфейсную схему 716 можно дополнительно выполнить с возможностью поддержания связи с SSF 708 через интерфейс Ss с использованием протокола связи Ss. В частности, интерфейсная схема 716 может передавать правила SSC или обновления в SSF 708 через интерфейс Ss и в некоторых вариантах осуществления принимать информацию о динамической нагрузке из SSF через интерфейс Ss.
Интерфейсная схема 716 может подавать информацию, принятую из оркестратора 712 или SSF 708, в схему 720 управления для дополнительной обработки более высокого уровня. Интерфейсная схема 716 может также принимать информацию из схемы 720 управления, которая должна передаваться через интерфейсы Rs или Ss.
В некоторых вариантах осуществления интерфейсная схема 716 может включать в себя первую схему, которая специально выполнена с возможностью поддержания связи через интерфейс Rs, и вторую схему, которая специально сконфигурирована для поддержания связи через интерфейс Ss. В других вариантах осуществления одну и ту же схему можно выполнить с возможностью поддержания связи одновременно через интерфейс Rs и Ss.
В некоторых вариантах осуществления интерфейсная схема 716 может включать в себя одну или более схем приема входящих сигналов и может дополнительно включать в себя одну или более схем передачи исходящих сигналов.
Хотя это не показано в явном виде, интерфейсную схему 716 можно дополнительно выполнить с возможностью поддержания связи с другими сетевыми узлами, включая, но не ограничиваясь ими, ANDSF, HSS/SPR и т.д.
Схему 720 управления можно выполнить с возможностью выполнения операций PCRF более высокого уровня, как это описывает, например, процесс 300 предоставления правил или процесс 600 обновления. Например, схема 720 управления может определить правила SSC и предоставить правила SSC в SSF 708 через интерфейсную схему 716. Схема 720 управления может в дальнейшем динамически обновлять правила SSC на основании информации о динамической нагрузке или другой информации о сети или абоненте, и предоставлять обновление в SSF 708 через интерфейсную схему 716.
SSF 708 может быть аналогичной и по существу взаимозаменяемой по отношению к SSF 134 или SSF 534. SSF 708 может включать в себя интерфейсную схему 724, соединенную со схемой 728 управления.
Аналогично интерфейсной схеме 716, интерфейсную схему 724 можно выполнить с возможностью поддержания связи с другими сетевыми объектами через различные интерфейсы. Например, в некоторых вариантах осуществления интерфейсную схему 724 можно выполнить с возможностью поддержания связи с PCRF 704 через интерфейс Ss, используя протокол связи Ss. В частности, интерфейсная схема 724 может принимать правила SSC из PCRF 704 через интерфейс Ss и в некоторых вариантах осуществления передавать информацию о динамической нагрузке в PCRF 704 через интерфейс Ss.
Интерфейсную схему 724 можно дополнительно выполнить с возможностью обмена данными SDF между компонентами операторской сети (например, TDF, PGW/GGSN и т.д.), SE в (S)Gi-LAN через интерфейс (S)Gi и компонентами сети PDN.
Оркестратор 712 может быть аналогичным и по существу взаимозаменяемым по отношению к оркестратору 548. Оркестратор 712 может включать в себя интерфейсную схему 732, соединенную со схемой 736 управления.
Аналогично интерфейсной схеме 716, интерфейсную схему 732 можно выполнить с возможностью поддержания связи с другими сетевыми объектами через различные интерфейсы. Например, в некоторых вариантах осуществления интерфейсную схему 732 можно выполнить с возможностью поддержания связи с PCRF 704 через интерфейс Rs, используя протокол связи Rs, и можно дополнительно выполнить с возможностью поддержания связи с SE. В частности, интерфейсная схема 732 может принимать информацию о динамической нагрузке из SE и передавать информацию о динамической нагрузке в PCRF 704 через интерфейс Rs.
Интерфейсные схемы 716, 724 и 732 позволяют поддерживать связь по Ethernet или с помощью других технологий построения компьютерных сетей с использованием различных физических медиа-интерфейсов, таких как, но неограниченных ими, коаксиальные, с витой парой и волоконно-оптические медиа-интерфейсы.
Варианты осуществления, описанные в данном документе, можно реализовать в виде системы, используя любые, подходящим образом сконфигурированные аппаратные средства и/или программное обеспечение. На фиг.8 показан один вариант осуществления примерных компонентов вычислительного устройства 800, которые могут содержать, или быть их частью, PCRF (например, PCRF 132, PCRF 532 или PCRF 704), SSF (например, SSF 134, SSF 534 или SSF 708) или оркестратор (например, оркестратор 548 или оркестратор 712).
Вычислительное устройство 800 может включать в себя один или более процессоров 804, связанных с одним или более носителями 808 информации. Процессоры 804 могут включать в себя один или более одноядерных или многоядерных процессоров. Процессоры могут включать в себя любое сочетание процессоров общего назначения и специализированных процессоров, в том числе, например, процессоры цифровых сигналов (DSP), центральные процессоры (CPU), микропроцессоры, контроллеры памяти (интегрированные или дискретные) и т.д.
Носители 808 информации можно использовать для загрузки и хранения данных или инструкций (которые обобщенно упоминаются как "схема 812") для операций, выполняемых процессорами 804. Носители 808 информации могут включать в себя любое сочетание из подходящей энергозависимой памяти и энергонезависимой памяти. Носители 808 информации могут включать в себя любое сочетание из памяти/запоминающего устройства различных уровней, в том числе, но не ограничиваясь ими, постоянное запоминающее устройство (ROM), имеющее встроенные инструкции программного обеспечения (например, программно-аппаратные средства), оперативное запоминающее устройство (например, динамическое оперативное запоминающее устройство (DRAM)), кэш, буферы и т.д. Носители 808 информации могут быть совместно используемыми среди различных процессоров или специализированными для конкретных процессоров.
В некоторых вариантах осуществления один или более процессоров 804 можно объединить с одним или более носителями 808 информации и, возможно, с другой схемой в одной микросхеме, одном наборе микросхем или разместить на одной и той же монтажной плате в некоторых вариантах осуществления.
Вычислительное устройство 800 может выполнить одну или более из операций, описанных выше по отношению к схеме управления (например, схеме 720 управления, схеме 728 управления или схеме 736 управления) или по отношению к интерфейсной схеме (например, интерфейсной схеме 716, интерфейсной схеме 724 или интерфейсной схеме 732).
Некоторые неограничивающие примеры представлены ниже.
Пример 1 включает в себя один или более машиночитаемых носителей, имеющих инструкции, которые при их исполнении предписывают функции контроля и управления услугами (SSF): принять правило контроля и управления услугами (SSC), причем правило SSC должно включать в себя идентификатор потока данных услуги (SDF) и один или более идентификаторов инструментов реализации услуг (SE); идентифицировать поток данных услуги (SDF) на основании идентификатора SDF в пределах операторской сети; и маршрутизировать SDF посредством одного или более инструментов реализации услуг в (S)Gi-LAN на основании одного или более идентификаторов SE.
Пример 2 включает в себя один или более машиночитаемых носителей согласно примеру 1, в которых SSF должна принимать правило SSC из функции реализации правил политики и тарификации (PCRF), функции выбора и обнаружения сети доступа (ANDSF), домашнего сервера абонента (HSS) или репозитория абонентских профилей (SPR).
Пример 3 включает в себя один или более машиночитаемых носителей согласно примеру 1, в которых инструкции, при их исполнении, дополнительно предписывают SSF: произвести сбор информации о статусе динамической нагрузки из отдельных инструментов реализации услуг из одного или более инструментов реализации услуг; и передать информацию о статусе динамической нагрузки в функцию реализации правил политики и тарификации (PCRF).
Пример 4 включает в себя один или более машиночитаемых носителей согласно примеру 1, в которых маршрутизация SDF посредством одного или более инструментов реализации услуг включает в себя: предписание передать SDF по цепочке из множества инструментов реализации услуг с очередностью, заданной правилом SSC.
Пример 5 включает в себя один или более машиночитаемых носителей согласно примеру 4, в которых предписание передавать SDF по цепочке включает в себя: передачу данных SDF в первый инструмент реализации услуг из множества инструментов реализации услуг; прием данных SDF из первого инструмента реализации услуг; передачу, после приема данных SDF из первого инструмента реализации услуг, данных во второй инструмент реализации услуг из множества инструментов реализации услуг.
Пример 6 включает в себя один или более машиночитаемых носителей согласно примеру 1, в которых SDF является входящим потоком данных.
Пример 7 включает в себя один или более машиночитаемых носителей согласно примеру 1, в которых правило SSC включает в себя информацию для ассоциирования SDF с одним или более инструментами реализации услуг и обеспечения очередности, с которой пакеты SDF должны передаваться посредством одного или более инструментов реализации услуг.
Пример 8 включает в себя один или более машиночитаемых носителей согласно любому из примеров 1-7, в которых SSF должна маршрутизировать SDF посредством одного или более инструментов реализации услуг с использованием одного или более туннелей 2-го уровня.
Пример 9 включает в себя устройство, содержащее: схему управления для определения правила контроля и управления услугами (SSC), которое будет применяться к трафику данных через операторскую сеть; и интерфейсную схему, соединенную со схемой управления, для передачи правила SSC в функцию контроля и управления услугами (SSF) с целью упрощения реализации правила SSC, причем правило SSC включает в себя информацию для ассоциирования трафика данных с одним или более инструментами реализации услуг в (S)Gi-LAN.
Пример 10 включает в себя устройство согласно примеру 9, в котором: интерфейсная схема должна принимать информацию о статусе динамической нагрузки, соответствующую по меньшей мере одному из одного или более инструментов реализации услуг; схема управления должна обновлять правило SSC на основании информации о статусе динамической нагрузки; и интерфейсная схема должна передать обновленное правило SSC в SSF.
Пример 11 включает в себя устройство согласно примеру 9, в котором интерфейсная схема должна принимать информацию о статусе динамической нагрузки из SSF или из оркестратора в (S)Gi-LAN.
Пример 12 включает в себя устройство согласно примеру 9, в котором схема управления должна определить правило SSC на основании профиля подписки пользователя, связанного с потоком данных.
Пример 13 включает в себя устройство согласно примеру 9, в котором: интерфейсная схема должна принимать информацию, соответствующую изменению профиля абонента, политики оператора или сетевой среды; схема управления должна обновлять правило SSC на основании информации; и интерфейсная схема должна передать обновленное правило SSC в SSF.
Пример 14 включает в себя устройство согласно примеру 9, в котором: интерфейсная схема должна принимать информацию из функции выбора и обнаружения сети доступа (ANDSF), домашнего сервера абонента (HSS) или репозитория абонентских профилей (SPR); и схема управления должна определить правило SSC на основании информации.
Пример 15 включает в себя устройство согласно примеру 9, в котором правило SSC дополнительно включает в себя информацию для обеспечения очередности, с которой пакеты трафика данных должны передаваться посредством одного или более инструментов реализации услуг.
Пример 16 включает в себя устройство согласно примеру 9, в котором устройство содержит функцию реализации правил политики и тарификации (PCRF).
Пример 17 включает в себя устройство согласно любому из примеров 9-16, в котором правило SSC включает в себя идентификатор правила, идентификатор потока данных услуги, идентификатор инструмента реализации услуг и идентификатор приложения.
Пример 18 включает в себя один или более машиночитаемых носителей, имеющих инструкции, которые при их исполнении предписывают устройству: принимать информацию о статусе динамической нагрузки из множества инструментов реализации услуг в (S)Gi-LAN; и передавать информацию о статусе динамической нагрузки в функцию реализации правил политики и тарификации (PCRF).
Пример 19 включает в себя один или более машиночитаемых носителей согласно примеру 18, в которых устройство представляет собой оркестратор в (S)Gi-LAN, и инструкции, при их исполнении, дополнительно предписывают оркестратору передавать информацию о статусе динамической нагрузки через интерфейс Rs.
Пример 20 включает в себя один или более машиночитаемых носителей согласно примеру 18, в которых устройство имеет функцию контроля и управления услугами (SSF), и инструкции, при их исполнении, дополнительно предписывают SSF: маршрутизировать поток данных услуги посредством одного или более инструментов реализации услуг из множества инструментов реализации услуг на основании правила контроля и управления услугами (SSC).
Пример 21 включает в себя один или более машиночитаемых носителей согласно примеру 20, в которых инструкции, при их исполнении, дополнительно предписывают SSF: принимать правило SSC из PCRF.
Пример 22 включает в себя один или более машиночитаемых носителей согласно примеру 20, в которых правило SSC включает в себя идентификатор правила, идентификатор потока данных услуги, идентификатор инструмента реализации услуг и идентификатор приложения.
Пример 23 включает в себя один или более машиночитаемых носителей, имеющих инструкции, которые при их исполнении предписывают функции реализации правил политики и тарификации (PCRF): определить правила контроля и управления услугами (SSC), которые будут применяться к трафику данных через операторскую сеть; и предоставить правило SSC в функцию контроля и управления услугами (SSF) для упрощения реализации правила SSC, причем правило SSC включает в себя информацию для ассоциирования трафика данных с одним или более инструментами реализации услуг в (S)Gi-LAN.
Пример 24 включает в себя один или более машиночитаемых носителей согласно примеру 23, в которых инструкции, при их исполнении, дополнительно предписывают PCRF: принимать информацию о статусе динамической нагрузки, соответствующую по меньшей мере одному из одного или более инструментов реализации услуг; обновить правило SSC на основании информации о статусе динамической нагрузки; и предоставить обновленное правило SSC в SSF.
Пример 25 включает в себя один или более машиночитаемых носителей согласно примеру 24, в которых PCRF должна принимать информацию о статусе динамической нагрузки из SSF или из оркестратора в (S)Gi-LAN.
Пример 26 включает в себя один или более машиночитаемых носителей согласно примеру 23, в которых инструкции, при их исполнении, дополнительно предписывают PCRF: определить правило SSC на основании профиля подписки пользователя, связанного с потоком данных.
Пример 27 включает в себя один или более машиночитаемых носителей согласно примеру 23, в которых инструкции, при их исполнении, дополнительно предписывают PCRF: принимать информацию, соответствующую изменению профиля абонента, политики оператора или сетевой среды; обновить правило SSC на основании информации; и предоставить обновленное правило SSC в SSF.
Пример 28 включает в себя один или более машиночитаемых носителей согласно примеру 23, в которых инструкции, при их исполнении, дополнительно предписывают PCRF: принять информацию из функции выбора и обнаружения сети доступа (ANDSF), домашнего сервера абонента (HSS) или репозитория абонентских профилей (SPR); и определить правило SSC на основании информации.
Пример 29 включает в себя один или более машиночитаемых носителей согласно примеру 23, в которых правило SSC дополнительно включает в себя информацию для обеспечения очередности, с которой пакеты трафика данных должны передаваться посредством одного или более инструментов реализации услуг.
Пример 30 включает в себя один или более машиночитаемых носителей согласно любому из примеров 23-29, в которых правило SSC включает в себя идентификатор правила, идентификатор потока данных услуги, идентификатор инструмента реализации услуг и идентификатор приложения.
Пример 31 включает в себя устройство, содержащее: интерфейсную схему для приема правила контроля и управления услугами (SSC), причем правило SSC должно включать в себя идентификатор потока данных услуги (SDF) и один или более идентификаторов инструментов реализации услуг (SE); и схему управления для: идентификации потока данных услуги (SDF) на основании идентификатора SDF в пределах операторской сети; и маршрутизации SDF посредством одного или более инструментов реализации услуг в (S)Gi-LAN на основании одного или более идентификаторов SE.
Пример 32 включает в себя устройство согласно примеру 31, в котором интерфейсная схема должна принимать правило SSC из функции реализации правил политики и тарификации (PCRF), функции выбора и обнаружения сети доступа (ANDSF), домашнего сервера абонента (HSS) или репозитория абонентских профилей (SPR).
Пример 33 включает в себя устройство согласно примеру 31, в котором: схема управления должна произвести сбор информации о статусе динамической нагрузки из отдельных инструментов реализации услуг из одного или более инструментов реализации услуг; и интерфейсная схема должна передать информацию о статусе динамической нагрузки в функцию реализации правил политики и тарификации (PCRF).
Пример 34 включает в себя устройство согласно примеру 31, в котором маршрутизация SDF посредством одного или более инструментов реализации услуг схемы управления должна предписывать передавать SDF по цепочке из множества инструментов реализации услуг с очередностью, заданной правилом SSC.
Пример 35 включает в себя устройство согласно примеру 34, в котором предписание схеме управления передавать SDF по цепочке должно предписывать интерфейсной схеме: передавать данные SDF в первый инструмент реализации услуг из множества инструментов реализации услуг; и передать, после приема данных SDF из первого инструмента реализации услуг, данные во второй инструмент реализации услуг из множества инструментов реализации услуг.
Пример 36 включает в себя устройство согласно примеру 31, в котором SDF является входящим потоком данных.
Пример 37 включает в себя устройство согласно примеру 31, в котором правило SSC включает в себя информацию для ассоциирования SDF с одним или более инструментами реализации услуг и обеспечения очередности, с которой пакеты SDF должны передаваться посредством одного или более инструментов реализации услуг.
Пример 38 включает в себя устройство согласно любому из примеров 31-37, в котором SSF должна маршрутизировать SDF посредством одного или более инструментов реализации услуг с использованием одного или более туннелей 2-го уровня.
Пример 39 включает в себя способ, содержащий: прием правила контроля и управления услугами (SSC), причем правило SSC должно включать в себя идентификатор потока данных услуги (SDF) и один или более идентификаторов инструментов реализации услуг (SE); идентификацию потока данных услуги (SDF) на основании идентификатора SDF в пределах операторской сети; и маршрутизацию SDF посредством одного или более инструментов реализации услуг в (S)Gi-LAN на основании одного или более идентификаторов SE.
Пример 40 включает в себя способ согласно примеру 39, в котором правило SSC принимается из функции реализации правил политики и тарификации (PCRF), функции выбора и обнаружения сети доступа (ANDSF), домашнего сервера абонента (HSS) или репозитория абонентских профилей (SPR).
Пример 41 включает в себя способ согласно примеру 39, дополнительно содержащий: сбор динамической информации о статусе нагрузки из отдельных инструментов реализации услуг из одного или более инструментов реализации услуг; и передачу динамической информации о статусе нагрузки в функцию реализации правил политики и тарификации (PCRF).
Пример 42 включает в себя способ согласно примеру 39, в котором маршрутизация SDF посредством одного или более инструментов реализации услуг включает в себя: предписание передавать SDF по цепочке из множества инструментов реализации услуг с очередностью, заданной правилом SSC.
Пример 43 включает в себя способ согласно примеру 42, в котором предписание передавать SDF по цепочке включает в себя: передачу данных SDF в первый инструмент реализации услуг из множества инструментов реализации услуг; прием данных SDF из первого инструмента реализации услуг; передачу, после приема данных SDF из первого инструмента реализации услуг, данных во второй инструмент реализации услуг из множества инструментов реализации услуг.
Пример 44 включает в себя способ согласно примеру 39, в котором SDF является входящим потоком данных.
Пример 45 включает в себя способ согласно примеру 39, в котором правило SSC включает в себя информацию для ассоциирования SDF с одним или более инструментами реализации услуг и обеспечения очередности, с которой пакеты SDF должны передаваться посредством одного или более инструментов реализации услуг.
Пример 46 включает в себя способ согласно любому из примеров 39-45, в котором маршрутизация SDF посредством одного или более инструментов реализации услуг содержит маршрутизацию SDF с использованием одного или более туннелей 2-го уровня.
Пример 47 включает в себя способ, содержащий: прием информации о статусе динамической нагрузки из множества инструментов реализации услуг в (S)Gi-LAN; и передачу динамической информации о статусе нагрузки в функцию реализации правил политики и тарификации (PCRF).
Пример 48 включает в себя способ согласно примеру 47, дополнительно содержащий передачу информации о статусе динамической нагрузки через интерфейс Rs.
Пример 49 включает в себя способ согласно примеру 47, дополнительно содержащий: маршрутизацию потока данных услуги посредством одного или более инструментов реализации услуг из множества инструментов реализации услуг на основании правила контроля и управления услугами (SSC).
Пример 50 включает в себя способ согласно примеру 49, дополнительно содержащий: прием правила SSC из PCRF.
Пример 51 включает в себя способ, содержащий: определение правила контроля и управления услугами (SSC), которое будет применяться к трафику данных через операторскую сеть; и передачу правила SSC в функцию контроля и управления услугами (SSF) для упрощения реализации правила SSC, причем правило SSC включает в себя информацию для ассоциирования трафика данных с одним или более инструментами реализации услуг в (S)Gi-LAN.
Пример 52 включает в себя способ согласно примеру 51, дополнительно содержащий: прием динамической информации о статусе нагрузки, соответствующей по меньшей мере одному из одного или более инструментов реализации услуг; обновление правила SSC на основании информации о статусе динамической нагрузки; и передачу обновленного правила SSC в SSF.
Пример 53 включает в себя способ согласно примеру 52, в котором информация о статусе динамической нагрузки принимается из SSF или из оркестратора в (S)Gi-LAN.
Пример 54 включает в себя способ согласно примеру 51, дополнительно содержащий: определение правила SSC, основанного на профиле подписки пользователя, связанном с потоком данных.
Пример 55 включает в себя способ согласно примеру 51, дополнительно содержащий: прием информации, соответствующей изменению профиля абонента, политики оператора или сетевой среды; обновление правила SSC на основании информации; и передачу обновленного правила SSC в SSF.
Пример 56 включает в себя способ согласно примеру 51, дополнительно содержащий: прием информации из функции выбора и обнаружения сети доступа (ANDSF), домашнего сервера абонента (HSS) или репозитория абонентских профилей (SPR); и определение правила SSC на основании информации.
Пример 57 включает в себя способ согласно примеру 51, в котором правило SSC дополнительно включает в себя информацию для обеспечения очередности, с которой пакеты трафика данных должны передаваться посредством одного или более инструментов реализации услуг.
Пример 58 включает в себя устройство, содержащее средство для выполнения любого способа из примеров 39-57.
Пример 59 включает в себя один или более машиночитаемых носителей согласно любому из примеров 20-22, в которых правило SSC может быть частью правила управления политикой и тарификацией (PCC) или правила обнаружения и управления приложением (ADC).
Приведенное в данном документе описание иллюстрированных реализаций, включая то, что описано в реферате, не предназначено быть исчерпывающим или ограничивающим настоящее раскрытие точными раскрытыми формами. Хотя конкретные реализации и примеры описаны в данном документе для иллюстративных целей, различные эквивалентные модификации возможны в пределах объема раскрытия, как это будет понятно специалистам в данной области техники. Эти модификации могут быть сделаны в раскрытии в свете вышеописанного подробного описания.