Результат интеллектуальной деятельности: ТРИГГЕР СОБЫТИЯ УСЛУГИ

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

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

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

В базовой сети мобильной сети связи должны быть предоставлены ресурсы для передачи данных между двумя пользователями и ресурсы, которые предоставляют, чтобы определять качество обслуживания, испытываемое пользователями. В сети, как определено с помощью Проекта партнерства 3-го поколения (3GPPP) ETSI, определены функция правил стратегии и оплаты (PCRF), функция осуществления стратегии и оплаты (PCEF) и опорная точка Gx, расположенная между PCRF и PCEF. Как определено в TS 29.212 3GPP, опорную точку Gx используют для предоставления и удаления правил управления стратегией и оплатой (PCC) из PCRF в PCEF и передачи событий плоскости трафика из PCEF в PCRF. Следовательно, опорная точка Gx может быть использована для управления оплатой, управления стратегии или для того и другого.

В случае сети, как определено в 3GPP, PCEF может быть осуществлена в шлюзовом узле поддержки GPRS (GGSN), и известно, что GGSN может поддерживать технологию глубокого инспектирования пакетов (DPI), которая позволяет узлу выполнять инспектирование пакетов и классификацию услуг в данных, проходящих через него. Более конкретно, IP-пакеты классифицируют, в соответствии со сконфигурированным деревом правил, таким образом, что их назначают в конкретный сеанс услуг.

Однако известное использование технологии DPI в GGSN не позволяет никакой дифференциации услуг на основании классификации услуг.

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

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

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

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

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

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

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

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

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

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

Фиг.3 изображает поток сообщений во время первой части способа фиг.2.

Фиг.4 изображает поток сообщений во время второй части способа фиг.2.

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

Фиг.1 изображает часть телекоммуникационной сети, в частности часть базовой сети 10 мобильной сети связи, как определенной в спецификациях 3GPP.

Одним элементом базовой сети 10 является шлюзовой узел поддержки GPRS (GGSN) 12. Как общепринято, сеть радиодоступа (RAN) 14 мобильной сети связи соединена с GGSN 12, что дает возможность пользовательскому оборудованию (UE) 16 создавать вызов через подходящий беспроводный интерфейс. Вызов может быть маршрутизирован обратно через RAN 14 в другое UE в сети или он может быть соединен через сеть пакетных данных 18, такую как Internet, с фиксированной линией связи или мобильным устройством связи, или в случае сеанса данных с дистанционным сервером. Этот аспект сети является общепринятым и не будет дополнительно описан в настоящей заявке.

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

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

Несмотря на то что фиг.1 изображает блок 22 обнаружения трафика услуг, процессор 24 и блок 26 интерфейса как отдельные блоки для простоты понимания, следует понимать, что соответственные функции могут быть выполнены с помощью любого общеизвестного средства и что на практике эти блоки не обязательно должны быть узнаваемыми как отдельные.

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

Как общепринято, базовая сеть 10 также включает в себя функцию правил стратегии и оплаты (PCRF) 28, структура которой опять является общепринятой, включая процессор 30, который выполняет часть процесса, описанного более подробно ниже, и блок 32 интерфейса, предназначенный для соединения с другими блоками в базовой сети 10. Например, PCRF 28 может быть осуществлена в контроллере стратегии учета услуг Ericsson.

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

PCEF 20 также соединена с автономной системой оплаты (OFCS) 34 и оперативной системой 36 оплаты, которая включает в себя пункт 38 управления обслуживанием специализированных приложений для расширенной логики мобильной сети (CAMEL) и блок 40 управления разрешением на основании потока данных услуг.

PCRF 28 соединена с банком профилей подписки (SPR) 42 и с функцией приложения (AF) 44. Например, AF 44 может быть уполномоченной функцией управления сеансом вызова (P-CSCF) подсистемы IP-мультимедиа (IMS).

PCEF 20 и PCRF 28 связываются через опорную точку Gx, как определено в TS 29.212 3GPP. Опорную точку Gx используют для предоставления и удаления правил PCC из PCRF в PCEF и передачи событий плоскости трафика из PCEF в PCRF. Опорная точка Gx может быть использована для управления оплатой, управления стратегии или для того и другого.

PCRF 28 и AF 44 связываются через опорную точку Rx, как определено в TS 29.214 3GPP, которую используют для того, чтобы обмениваться информацией сеанса прикладного уровня между PCRF и AF.

PCEF 20 и OFCS 34 связываются через опорную точку Gz, в то время как PCEF 20 и OCS 36 связываются через опорную точку Gy, а PCRF 28 и SPR 42 связываются через опорную точку Sp.

Общая структура, описанная выше, изображена в TS 29.214 3GPP и, таким образом, не будет дополнительно описана в настоящей заявке.

Способ, в соответствии с настоящим изобретением, теперь будет описан более подробно со ссылкой на фиг.2 в виде блок-схемы последовательности этапов, и фиг.3 и фиг.4, изображающие поток сообщений между различными узлами. А именно, фиг.2 изображает этапы, выполняемые в PCEF 20 и PCRF 28, в то время как фиг.3 и фиг.4 изображают сообщения, передаваемые между UE 16, PCEF 20 и PCRF 28 и другим UE или сервером, с которым соединено UE 16.

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

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

Таким образом, на этапе 62 PCEF выполняет мониторинг трафика до тех пор, пока она не обнаружит начало одной из предоставленных услуг, также указанного как точка 64 на фиг.3. PCEF может обнаруживать начало услуги с помощью любого подходящего метода, например с использованием эвристических методов, разрешенных с помощью использования DPI.

Когда PCEF обнаруживает состояние начала услуги, на этапе 66 она запускает таймер бездеятельности. Затем, на этапе 68, PCEF 20 уведомляет PCRF 28 о состоянии начала услуги посредством команды запроса управления разрешением (CCR) через интерфейс Gx с использованием установки AVP триггера события в значение, указывающее вновь определенное событие услуги.

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

AVP начала-окончания услуг указывает, соответствует ли событие либо началу, либо окончанию услуги (следовательно, в этом случае, он установлен, чтобы указывать событие начала услуги).

AVP кадрированного IP-адреса содержит IP-адрес, связанный с сеансом IP-CAN, закодированный, как специфицировано в RFC 4005. Другой AVP, такой как AVP описания содержания среды, содержит соответственную информацию о потоке. Например, сигнализация RTSP передает информацию об IP-адресах и портах, соответствующих потокам аудио- или видеоданных транспортного протокола реального времени (RTP), согласованным во время сигнализации, таким образом, что PCRF может создавать вторичные контексты PDP согласно этим согласованным IP-адресам и портам.

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

На этапе 70 PCRF принимает уведомление из PCEF и сигнализирует это с помощью посылки сообщения ответа управления разрешением (CCA) с кодом результата, указывающим, что уведомление было успехом.

На этапе 72 PCRF устанавливает соответствующие правила РСС с помощью передачи в PCEF сообщения запроса повторного санкционирования (RAR) Gx. Это позволяет модификацию существующего канала-носителя (или создание специализированного канала-носителя) с установками либо более высокого, либо более низкого QoS, в зависимости от услуг, которое начинают. На этапе 74, PCEF подтверждает прием этой команды с помощью посылки в PCRF ответа повторного санкционирования с кодом результата, указывающим, что уведомление было успехом.

В ответ на уведомление PCRF может требовать любых подходящих этапов для управления предоставлением услуг в ответ на обнаруженное состояние услуг. Это может включать в себя модификацию установок QoS для сеанса услуг, а это, в свою очередь, может состоять из любых из следующих действий из неполного списка, содержащего модификацию установленного контекста PDP Gx (т.е. когда GGSN действует как PCEF), изменение приоритета обработки трафика (ТНР) для существующего канала-носителя, изменение максимальной скорости передачи в битах (MBR) для существующего канала-носителя, управление шириной полосы частот IP-потока или инициирование сети специализированного канала-носителя IP-CAN с динамическими правилами РСС (т.е. когда GGSN действует как PCEF).

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

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

После этого поток услуг может происходить, как изображено в 76 на фиг.3, и, как упомянуто выше, это может требовать соответственной сигнализации контекста PDP для того, чтобы создать вторичный контекст 80 PDP между UE 16 и PCEF 20. В других случаях услуга может быть выполнена через существующий контекст PDP, и нет необходимости создавать вторичный контекст PDP.

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

Если определено на этапе 82, что таймер бездеятельности истек, или определено на этапе 84, что обнаружено состояние окончания услуги, процесс проходит на этап 86, на котором PCEF 20 уведомляет PCRF 28 посредством команды запроса управления разрешением (CCR) через интерфейс Gx с помощью использования установки AVP триггера события в значение, указывающее вновь определенное событие услуги.

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

AVP начала-окончания услуг в этом случае установлен таким образом, чтобы указывать событие окончания услуги. AVP кадрированного IP-адреса содержит IP-адрес, связанный с сеансом IP-CAN, закодированный, как специфицировано в RFC 4005. Другой AVP, такой как AVP идентификатора приложения, содержит информацию, которая идентифицирует конкретную обнаруженную услугу (например, потоковый протокол реального времени (RTSP)).

На этапе 88 PCRF принимает уведомление из PCEF и сигнализирует это с помощью посылки сообщения ответа управления разрешением (CCA) с кодом результата, указывающим, что уведомление было успехом.

На этапе 90 PCRF удаляет ранее установленные правила РСС с помощью передачи в PCEF сообщения запроса повторного санкционирования (RAR) Gx. Это позволяет восстановление первоначальных установок QoS с помощью модификации существующего канала-носителя (или удаления специализированного канала-носителя, созданного для этой услуги). На этапе 92 PCEF подтверждает прием этой команды с помощью посылки в PCRF ответа повторного санкционирования с кодом результата, указывающим, что уведомление было успехом.

Как изображено на фиг.4, когда вторичный контекст PDP был создан между UE 16 и PCEF 20, соответственная сигнализация 94 контекста PDP может быть использована для того, чтобы разрушить вторичный контекст PDP на этапе 96.

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

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

AVP начала-окончания услуг в этом случае устанавливают таким образом, чтобы указывать событие обновления услуги, а уведомление в PCRF могло бы инициировать модификацию параметров QoS для сеанса услуг.

Как описано до сих пор, способ включает в себя передачу через интерфейс Gx. Однако локальное решение без участия Gx также является возможным. В этом случае PCEF должна быть предоставлена множеством услуг (например, таких как RTSP, как описано ранее), для которых эта функциональная возможность должна быть инициирована, а также должна быть предоставлена локальной стратегией, которая будет применяться для каждой из этих услуг. PCEF может быть сконфигурирована для обнаружения состояния начала услуг, как описано выше, и после такого обнаружения PCEF запускает таймер бездеятельности. На основании локальных стратегий, предоставленных для этой услуги, PCEF затем может инициировать модификацию существующего канала-носителя или создание специализированного канала-носителя с установками более высокого или более низкого QoS, в зависимости от услуги, которую начинают. Когда PCEF обнаруживает состояние окончания услуги, или истекает таймер бездеятельности, PCEF (на основании локальных стратегий, предоставленных для этой услуги) должна восстановить предыдущие установки QoS с помощью модификации существующего канала-носителя или с помощью удаления специализированного канала-носителя, ранее созданного для услуги.

Таким образом, предоставлено усовершенствование в интерфейс Gx, позволяющее PCEF, которая может выполнять обнаружение трафика услуг, уведомлять PCRF о состоянии услуги посредством специфического события в AVP триггера события. Это позволяет PCRF устанавливать соответствующие правила РСС, для того чтобы модифицировать параметры QoS для этого конкретного сеанса пользователя.