Генерирование статистики сети на основе контроллера политик

Изобретение относится к области связи. Технический результат состоит в эффективном генерировании статистики сети. Для этого, чтобы поддерживать генерирование статистики сети, контроллер (30) политик мобильной сети может быть обеспечен генератором (32) статистики сети и интерфейсом (Ni) к функции (60) сетевого интеллекта. Генератор (32) статистики сети может использовать эти интерфейсы контроллера (30) политик для получения информации, необходимой для генерирования статистики сети. В дополнение, генератор (32) статистики сети может также использовать информацию, которая локально доступна в контроллере (30) политик. Другими словами, контроллер (30) политик или один или более других узлов могут действовать как источники информации для генерирования статистики сети. Генератор (32) статистики сети может выбирать типы информации, которая должна быть использована для компилирования определенной статистики сети, и также соответственно выбирать узлы, которые должны быть использованы в качестве источников информации для получения этих типов информации. Это может, например, быть совершено на основании запроса, принятого от функции (60) сетевого интеллекта. 4 н. и 10 з.п. ф-лы, 6 ил.

 

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

Настоящее изобретение относится к способам генерирования статистики сети и к соответствующим устройствам.

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

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

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

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

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

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

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

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

- приема, через интерфейс статистики сети, запроса на генерирование статистики сети,

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

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

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

- генерирования запрашиваемой статистики сети на основании полученной информации и

- отправки отчета, содержащего сгенерированную статистику сети, через интерфейс статистики сети.

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

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

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

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

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

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

Фиг. 3 показывает схему сигнализации для иллюстрирования процесса представления отчета о статистике сети согласно варианту осуществления данного изобретения.

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

Фиг. 5 схематически иллюстрирует контроллер политик согласно варианту осуществления данного изобретения.

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

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

В дальнейшем, данное изобретение будет разъяснено более подробно посредством ссылки на примерные варианты осуществления и на прилагаемые чертежи. Проиллюстрированные варианты осуществления относятся к идеям генерирования статистики сети в мобильной сети. В частности, данные идеи могут быть использованы для предоставления функции сетевого интеллекта различных типов статистики сети. В дальнейшем, данные идеи будут разъяснены в контексте мобильной сети 3GPP (проект партнерства по системам третьего поколения). Мобильная сеть может поддерживать один или более типов технологии радиодоступа (RAT), таких как GSM (глобальная система мобильной связи), GSM EDGE (развитие стандарта GSM с увеличенной скоростью передачи данных), UMTS (универсальная мобильная телекоммуникационная система) и/или развитая UMTS, также называемая 3GPP LTE (проект долгосрочного развития). Мобильная сеть может таким образом быть оборудована одним или более соответствующими типами сети радиодоступа, такими как сеть радиодоступа GSM (GRAN), сеть радиодоступа GSM EDGE (GERAN), сеть радиодоступа UMTS (UTRAN) или развитая UTRAN. Однако, следует понимать, что проиллюстрированные идеи также могут быть применены в других типах мобильной сети, например, с использованием других типов RAT, таких как RAT на основе множественного доступа с кодовым разделением (CDMA), и что конкретные типы узлов, описанные в дальнейшем, могут варьироваться в соответствии с типом реализованных RAT. Кроме того, данные идеи могут также применяться в сценарии конвергенции фиксированной и мобильной связи (FMC), т.е. в мобильной сети, которая также поддерживает фиксированный доступ, например, с использованием технологий цифровой абонентской линии (DSL) или доступа по коаксиальному кабелю.

Фиг. 1 иллюстрирует реализацию идей согласно варианту осуществления данного изобретения в архитектуре управления политиками и тарификацией (PCC) согласно техническим спецификациям (TS) 3GPP, например, 3GPP TS 23.203. Как проиллюстрировано, архитектура PCC включает в себя первый шлюз 24, например, в проиллюстрированном примере реализованный как обслуживающий шлюз (SGW), второй шлюз 26, в проиллюстрированном примере реализованный как шлюз 26 сети пакетной передачи данных (PGW), контроллер 30 политик, в проиллюстрированном примере реализованный как функция правил политик и тарификации (PCRF), и хранилище 38. Кроме того, архитектура PCC также включает в себя функцию 34 принудительного применения управления политиками, которая реализована в PGW 26. В проиллюстрированном примере, предполагается, что хранилище 38 соответствует хранилищу профилей абонентов (SPR). Однако, следует понимать, что также могли бы быть использованы другие типы хранилища, например хранилище пользовательских данных (UDR). Как проиллюстрировано, архитектура PCC может также включать в себя функцию 36 обнаружения трафика (TDF), функцию 39 привязки однонаправленных каналов и представления отчетов о событиях (BBERF), реализованную в SGW 24, систему 42 тарификации в режиме оффлайн (OFCS), систему 44 тарификации в режиме онлайн (OCS), функцию 50 приложения (AF) и/или узел 55 сети фиксированного доступа (FAN), например, сервер аутентификации, авторизации и учета (AAA) или сервер широкополосного удаленного доступа (BRAS) сети фиксированного доступа.

PCRF 30 сконфигурирована с возможностью выполнения принятия решения по управлению политиками и управления тарификацией на основе потока. PCRF 30 предоставляет сетевое управление относительно обнаружения для обнаружения потоков данных сервиса, пропускания, качества обслуживания (QoS) и тарификации на основе потока по отношению к PCEF 34. Для этой цели, PCRF 30 может сигнализировать правила PCC в PCEF 34. PCEF 34 может быть сконфигурирована с возможностью выполнения обнаружения потока данных сервиса, функциональных возможностей принудительного применения политик и тарификации на основе потока, что обычно совершается посредством применения правил PCC, которые сигнализированы посредством PCRF 30. Кроме того, PCEF 34 может также реализовать функциональные возможности проверки пакетов, такие как глубокая проверка пакетов (DPI), и классификацию сервисов. Таким образом пакеты данных могут быть классифицированы согласно правилам PCC, заданным в PCEF 34, и могут быть присвоены определенным сервисам.

PCEF 34 может быть ответственна за принудительное применение политик по отношению к аутентификации абонентов, авторизации для осуществления доступа к сервисам, и учету и мобильности. PCRF 30 может быть ответственна за управление индивидуальными политиками, задающими сеть, приложение и условия для абонента, которые должны быть соблюдены для того, чтобы успешно доставить сервис или обеспечить QoS данного сервиса. Хранилище 38, которое может быть отдельной базой данных или интегрированной в существующую абонентскую базу данных, такую как домашний абонентский сервер (HSS), может включать в себя информацию, такую как разрешения, тарифные планы и т.д. Хранилище 38 может предоставить данные подписки, такие как разрешенные для абонента сервисы, преимущественный приоритет для каждого разрешенного сервиса, информация о QoS-параметрах абонента, например подписанная гарантированная полоса пропускания QoS, информация, связанная с тарификацией абонента, например релевантная для тарификации информация о местоположении, категория абонента, например является ли абонент золотым пользователем, которому должно быть предоставлено высокое QoS, или серебряным или бронзовым пользователем, которому должно быть предоставлено низкое QoS.

AF 50 является элементом, предоставляющим одно или более приложений, в которых сервис может быть доставлен в сетевом уровне, который отличается от сетевого уровня, в котором сервис был запрошен. Например, сервис может быть запрошен в уровне сигнализации и доставлен в транспортном уровне. Примерами AF являются функции мультимедийной IP-подсистемы (IMS) мобильной сети, такие как посредническая (прокси) функция управления сеансами вызовов (P-CSCF), или серверов приложений, таких как сервер приложений протокола инициализации сеансов (SIP). AF 50 обычно осуществляет связь с PCRF 30 для пересылки информации сеанса, например описания данных, которые должны быть доставлены в транспортном уровне.

TDF 36 может поддерживать проверку пакетов и классификацию сервисов, например, посредством выполнения глубокой проверки пакетов (DPI). Для этой цели, пакеты данных протокола Интернета (IP) могут быть классифицированы согласно правилам, сконфигурированным в TDF 36, так что пакеты данных могут быть присвоены определенному типу сервисов. PCRF 30 может затем управлять обеспечением соответствующими ресурсами сети для этого сервиса, например, посредством установки или конфигурирования соответствующих правил PCC в PCEF 34. TDF 36 может быть реализована как отдельный узел или может быть интегрирована в другом сетевом узле, например в шлюзе, таком как SGW 26. В последнем примере, TDF 36 будет совмещена с PCEF 34. Согласно некоторым вариантам осуществления, TDF 36 может также действовать как зонд для сбора информации о трафике, пересылаемом через мобильную сеть, например, посредством слежения за используемыми ресурсами сети на основании унифицированных указателей ресурсов (URL) или унифицированных идентификаторов ресурсов (URI) в проверенных пакетах данных.

Как проиллюстрировано на фиг. 2, узлы архитектуры PCC соединены друг с другом посредством интерфейсов или опорных точек, именуемых как Gx, Gxx, Gy, Gz, Sd, Sp, Sy, Rx, и RADIUS. Опорная точка Gx находится между PCRF 30 и шлюзом 26, и обеспечивает возможность связи между PCRF 30 и PCEF 34. Опорная точка Gxx находится между PCRF 30 и BBERF 39. Опорная точка Gy находится между шлюзом 26 и OCS 44. Опорная точка Gz находится между PGW 26 и OFCS 42. Опорная точка Rx находится между AF 50 и PCRF 30. Опорная точка Sd находится между TDF 36 и PCRF 30. Опорная точка Sp находится между хранилищем 38 и PCRF 30. Опорная точка Sy находится между OCS 42 и PCRF 30. FAN 55 и PCRF 30 соединены друг с другом посредством интерфейса RADIUS, т.е., интерфейса на основе RADIUS (Сервиса удаленной аутентификации пользователя телефонной сети) или протокола Diameter. Подробности, имеющие отношение к реализации этих интерфейсов и протоколов, могут быть найдены в 3GPP TS, например, 3GPP TS 23.203 и 3GPP TS 29.212, и в IETF RFC 2865, 2866 и 3588. Следует понимать, что архитектура PCC по фиг. 1 предназначена для показа примерных элементов, которые могут быть предусмотрены в реализации вариантов осуществления данного изобретения, но что в реализации вариантов осуществления данного изобретения могли бы быть также предусмотрены другие элементы. Например, архитектура PCC по фиг. 1 могла бы быть модифицирована относительно узлов, взаимодействующих с PCRF 30 и соответствующими интерфейсами. Например, хранилище 38 могло бы быть реализовано как UDR, и интерфейс хранилища 38 для PCRF 30 мог бы быть реализован посредством опорной точки Ud. Также, архитектура PCC могла бы включать в себя V-PCRF (посещенную PCRF), которая должна быть использована для пользователей, которые находятся в роуминге, и PCRF 30 могла бы быть обеспечена интерфейсом к V-PCRF, например, реализованной посредством опорной точки S9. Более того, следует понимать, что могут быть предоставлены многочисленные экземпляры некоторых узлов, например многочисленные SGW и соответствующие BBERF, многочисленные PGW и соответствующие PCEF, многочисленные TDF, многочисленные AF или многочисленные FAN.

В проиллюстрированном варианте осуществления, PCRF 30 предоставлен генератор 32 статистики сети и интерфейс Ni к функции 60 сетевого интеллекта (NIF). Интерфейс Ni может, например, быть основанным на шаблоне расширенного языка разметки (XML) для сообщений, передаваемых между PCRF 30 и NIF 60. Генератор 32 статистики сети имеет целью генерирование различных типов статистики сети, которые затем могут быть представлены в отчете в NIF 60 через интерфейс Ni. Здесь следует понимать, что генератор статистики сети не должен быть реализован как выделенная физическая структура PCRF 30, но может соответствовать определенным функциональным возможностям PCRF 30, которые также могут быть реализованы посредством программного обеспечения, например программного кода, который должен быть исполнен процессором PCRF 30. Соответственно, в дальнейшем описании функциональные возможности генератора 32 статистики сети будут также описаны как функциональные возможности PCRF 30. NIF 60 в свою очередь анализирует или сохраняет статистику сети. Эта обработка может в некоторых случаях приводить к решениям для изменения одной или более из политик и профилей, сконфигурированных в PCRF 30 или хранилище 38. Например, может произойти, что оператор решает изменить уровни QoS, присвоенные определенным профилям пользователей, так как статистика сети указывает определенный шаблон использования.

Так как PCRF 30 оборудована интерфейсами для некоторого числа разных узлов, генератор 32 статистики сети PCRF 30 может использовать эти интерфейсы для получения информации, необходимой для генерирования статистики сети. В дополнение, генератор 32 статистики сети может также использовать информацию, которая локально доступна в PCRF 30. Другими словами, PCRF 30 или один или более других узлов могут действовать как источники информации для генерирования статистики сети. Генератор 32 статистики сети может выбирать типы информации, которая должна быть использована для компилирования определенной статистики сети, и также соответственно выбирать узлы, которые должны быть использованы в качестве источников информации для получения этих типов информации. Это может, например, быть совершено на основании запроса, принятого от NIF 60.

Соответственно, PCRF 30 может действовать как центральная точка принятия решения для координации и компилирования статистики сети. Это может предусматривать использование информации из транспортной плоскости, например, которая доступна из транспортных узлов, таких как SGW 24 или PGW 26, в частности из PCEF 34, TDF 36 и/или BBERF 39, информации из плоскости приложения, например, доступной из узлов AF, таких как AF 50, и/или информации из плоскости пользователя, например, которая доступна из хранилища 38 или OCS 44. Это возможно потому, что PCRF 30 является центральным сетевым узлом, где информацией сети, приложения и пользователя управляют для принятия решений по интеллектуальному доступу, QoS и тарификации. PCRF 30 расположена между плоскостью приложения и транспортной плоскостью, принимающей информацию от узлов AF и транспортных узлов. Соответственно, PCRF 30 предоставлен доступ к различным типам информации, которые полезны для генерирования статистики сети. Такая информация может быть получена из других узлов с использованием одного или более интерфейсов PCRF 30. Однако такая информация может также быть доступна в самой PCRF 30, т.е. сама PCRF 30 может быть значимым источником информации для генерирования сетевой статистики. Вследствие этого, расположение генератора 32 статистики сети в PCRF 30 обеспечивает возможность эффективного генерирования различных типов статистики сети. Например, PCRF 30 может получить информацию транспортной плоскости, которая должна быть использована для генерирования статистики сети, из PCEF 34, TDF 36 и/или BBERF 39, может получить информацию плоскости приложения, которая должна быть использована для генерирования статистики сети, из AF 50, и может получить информацию плоскости пользователя, которая должна быть использована для генерирования статистики сети, из хранилища 38. В сценарии FMC, PCRF 30 могла бы действовать как конвергированный контроллер политик, т.е. выполнять управление политиками также относительно сети фиксированного доступа, и получать информацию для генерирования статистики сети из FAN 55.

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

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

Фиг. 2 схематично проиллюстрирует процесс генерирования статистики сети в соответствии с вариантом осуществления данного изобретения. Проиллюстрированный процесс предусматривает PCRF 30, NIF 60, первый узел 21 и второй узел 22. Первый и второй узлы 21, 22 могут соответствовать любому из элементов, сопряженных с PCRF 30, которые проиллюстрированы на фиг. 1, например, SGW 24 или BBERF 39, PGW 26 или PCEF 34, TDF 36, хранилищу 38, OCS 44, AF 50 или FAN 55. Первый и второй узлы 21, 22 могут также соответствовать другим типам узлов сопряженных с PCRF 30, которые не проиллюстрированы на фиг. 1.

Как проиллюстрировано, NIF 60 может контактировать с PCRF 30 для запроса одного или более статистических показателей сети, посредством отправки сообщения 201 из нее в PCRF 30. Сообщение 201 может идентифицировать тип статистики сети, который должен быть сгенерирован, например, посредством включения в себя соответствующего идентификатора статистики. PCRF 30 может подтвердить прием сообщения 201 посредством отправки сообщения 202 в NIF 60. Сообщение 202 может например подтвердить, способна ли PCRF 30 генерировать определенную запрашиваемую статистику сети или нет. В PCRF 30, запрос, принятый с сообщением 201, может задать набор статистики сети, который необходимо сгенерировать и представить в отчете в NIF 60.

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

- число абонентов, зарегистрированных в определенном сервисе, например сервисе IMS, с использованием определенной RAT, например доступа посредством E-UTRAN;

- число попыток доступа к определенному сервису абонентами, расположенными в конкретной области;

- число абонентов, для которых трафик данных был ускорен во время роуминга;

- число попыток доступа к определенному URL;

- число попыток доступа к определенному сервису;

- число сеансов, установленных для определенного имени точки доступа (APN);

- число активных абонентов;

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

Взаимодействие между NIF 60 и PCRF 30 может быть по необходимости повторено. Например, NIF 60 могла бы в некоторый момент времени решить добавить или удалить определенный элемент статистики сети из набора статистики сети, который должен быть сгенерирован и представлен в отчете в NIF 60. Это может быть совершено посредством отправки нового запроса в PCRF 30, который идентифицирует элемент статистики сети, который должен быть добавлен или удален из набора. В качестве альтернативы, NIF 60 может также отправить запрос в PCRF 30, чтобы задать новый набор статистики сети, которые должны быть сгенерированы и представлены в отчете в NIF 60.

Как упомянуто выше, разные типы статистики сети могут быть идентифицированы при взаимодействии между NIF 60 и PCRF 30 посредством соответствующих идентификаторов. PCRF 30 может в свою очередь быть сконфигурирована с возможностью отнесения идентификаторов к информации, которая обеспечивает возможность выбора одного или более типов информации, которая должна быть получена для генерирования определенного типа статистики сети, и выбора одного или более узлов в качестве источника информации. В процессе по фиг. 2, PCRF 30 совершает выбор одного или более типов информации, которая должна быть получена, на этапе 203. Кроме того, PCRF 30 совершает выбор одного или более узлов в качестве источника информации на этапе 204. В дальнейшем будут даны некоторые примеры статистики сети и соответствующих выборов типов информации и источников информации.

- Согласно одному примеру, статистика сети может представлять собой число пользователей, принадлежащих определенному профилю пользователя, которые осуществили доступ к мобильной сети в определенной области и период времени, в то же время использующих определенный тип терминала. В этом случае, типами информации, которая должна быть получена, являются пользователи с этим типом терминала, что может быть получено из PCEF 34 при помощи международной идентификационной информации мобильного оборудования (IMEI) пользовательского терминала, и указания попыток доступа этими пользователями в представляющей интерес области, что может быть получено из PCEF 34. На основании этих указаний, PCRF 30 может увеличить счетчик для подсчета числа попыток доступа во время периода времени, представляющего интерес.

- Согласно дополнительному примеру, статистика сети может представлять собой число пользователей, одновременно зарегистрированных в IMS, в то же время использующих доступ через E-UTRAN. В этом случае, типами информации, которая должна быть получена, являются пользователи с доступом через E-UTRAN, что может быть получено из PCEF 34, и указания этих пользователей, регистрирующихся или отменяющих регистрацию в IMS, что может быть получено из AF 50. PCRF 30 может увеличивать счетчик каждый раз, когда один из пользователей регистрируется в IMS, и уменьшать этот счетчик, когда один и этих пользователей отменяет регистрацию в IMS.

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

- Согласно дополнительному примеру, статистика сети может представлять собой объем трафика, например, число пакетов данных восходящей линии связи, пересылаемых во время использования сервиса IMS для пользователей, использующих определенный тип терминала. В этом случае, типами информации, которая должна быть получена, являются пользователи с этим типом терминала, что может быть получено из PCEF 34 при помощи международной идентификационной информации мобильного оборудования (IMEI) пользовательского терминала, и использующие этот сервис IMS, что может быть получено из AF 50, и объем трафика, пересылаемый этими пользователями, что может быть получено из PCEF 34 на основе каждого пользователя. PCRF 30 может агрегировать пересылаемые объемы трафика разных пользователей.

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

- Согласно дополнительному примеру, статистика сети может представлять собой число попыток доступа к IMS во время роуминга, которые были авторизованы посредством PCRF 30, учитывая условия пользовательской подписки. В этом случае, PCRF 30 может выбрать, получить информацию приложения из IMS, например, AF 50, которая может быть частью IMS, информацию роуминга из PCEF 34 и информацию авторизации из самой PCRF 30.

- Согласно дополнительному примеру, статистика сети может представлять собой число попыток доступа к IMS во время роуминга, которые не были авторизованы посредством PCRF 30, учитывая условия пользовательской подписки. В этом случае, PCRF 30 может выбрать, получить информацию приложения из IMS, например, AF 50, которая может быть частью IMS, информацию роуминга из PCEF 34 и информацию авторизации из самой PCRF 30.

- Согласно дополнительному примеру, статистика сети может представлять собой число попыток доступа к IMS в определенной области, которые были авторизованы посредством PCRF, учитывая условия пользовательской подписки и информацию о перегрузке. В этом случае, PCRF 30 может выбрать, получить информацию приложения из IMS, например, AF 50, которая может быть частью IMS, информацию о перегрузке из PCEF 34 и информацию авторизации из самой PCRF 30.

- Согласно дополнительному примеру, статистика сети может представлять собой число попыток доступа к IMS в определенной области, которые не были авторизованы посредством PCRF, учитывая условия пользовательской подписки и информацию о перегрузке. В этом случае, PCRF 30 может выбрать, получить информацию приложения из IMS, например, AF 50, которая может быть частью IMS, информацию о расположении из PCEF 34 и информацию авторизации из самой PCRF 30.

- Согласно дополнительному примеру, статистика сети может представлять собой число попыток доступа к IMS с использованием определенного типа RAT, которые были авторизованы посредством PCRF, учитывая условия пользовательской подписки и характеристики сервиса, т.е. принимая во внимание, что в зависимости от сервиса требуется определенный тип доступа. В этом случае, PCRF 30 может выбрать, получить информацию приложения из IMS, например, AF 50, которая может быть частью IMS, информацию о типе RAT из PCEF 34 и информацию авторизации из самой PCRF 30.

- Согласно дополнительному примеру, статистика сети может представлять собой число попыток доступа к IMS с использованием определенного типа RAT, которые были авторизованы посредством PCRF, учитывая условия пользовательской подписки и характеристики сервиса, т.е. принимая во внимание, что в зависимости от сервиса требуется определенный тип доступа. В этом случае, PCRF 30 может выбрать, получить информацию приложения из IMS, например, AF 50, которая может быть частью IMS, информацию о типе RAT из PCEF 34 и информацию авторизации из самой PCRF 30.

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

В процессе по фиг. 2, предполагается, что первый узел 21 и второй узел 22 выбраны в качестве источников информации. Соответственно, PCRF 30 может запросить первый тип информации из первого узла 21 посредством отправки сообщения 205 первому узлу 21. В сообщении 205, PCRF 30 может, например, точно определить тип информации, которая должна быть представлена в отчете. Первый узел 21 может подтвердить прием сообщения 205 посредством отправки сообщения 206 в PCRF 30. Кроме того, PCRF 30 может запросить второй тип информации из второго узла 22 посредством отправки сообщения 207 второму узлу 22. В сообщении 207, PCRF 30 может, например, точно определить тип информации, которая должна быть представлена в отчете. Второй узел 22 может подтвердить прием сообщения 207 посредством отправки сообщения 208 в PCRF 30.

Первый узел 21 и второй узел 22 могут затем предпринять соответствующие действия для предоставления запрашиваемых типов информации. Например, если первый узел 21 соответствует TDF 36, он может проверить пакеты данных для предоставления информации, или если второй узел соответствует PCEF 34, он может сконфигурировать триггеры для представления в отчете определенных событий, например, как задано в разделе 6.1.4 3GPP 23.203. В процессе по фиг. 2, первый узел 21 представляет в отчете запрашиваемую информацию посредством отправки сообщения 209 в PCRF 30, и второй узел 22 представляет в отчете запрашиваемую информацию посредством отправки сообщения 210 в PCRF 30.

Как проиллюстрировано посредством этапа 211, PCRF 30 может затем сгенерировать статистику сети посредством компилирования информации, принятой от первого узла 21 и второго узла 22. PCRF 30 может затем представить отчет о сгенерированной статистики сети в NIF 60, что в процессе по фиг. 2 совершается посредством отправки сообщения 212 в NIF 60. NIF 60 может подтвердить прием сообщения 212 посредством отправки сообщения 213 в PCRF 30. Представлением отчета о статистике сети посредством PCRF 30 можно управлять различным образом, например, может быть совершено после истечения определенного интервала времени от приема сообщения 201, может совершаться часто с регулярными интервалами времени, т.е. согласно определенному интервалу сканирования, может быть совершено в ответ на сравнение отслеживаемого значения с порогом или может быть совершено в ответ на запрос от NIF 60 на принуждение незамедлительного представления отчета.

Некоторые примерные процессы представления отчета о статистике сети проиллюстрированы посредством схемы сигнализации по фиг. 3. На фиг. 3 проиллюстрированы узел 21, PCRF 30 и NIF 60. Узел 21 может соответствовать любому из элементов, сопряженному с PCRF 30, как проиллюстрировано на фиг. 1, например, SGW 24 или BBERF 39, PGW 26 или PCEF 34, TDF 36, хранилищу 38, OCS 44, AF 50 или FAN 55. Узел 21 может также соответствовать некоторому другому типу узла, сопряженному с PCRF 30, который не проиллюстрирован на фиг. 1.

Посредством сообщений 301, 302, PCRF 30 получает один или более типов информации от узла 21, которая нужна для генерирования определенного типа статистики сети, который запрошен посредством NIF 60. С помощью сообщения 303 NIF 60 запрашивает незамедлительное представление отчета о статистике сети.

В ответ на прием сообщения 303, PCRF 30 генерирует статистику сети посредством компилирования полученной информации, как проиллюстрировано на этапе 304, и представляет отчет о сгенерированной статистике сети в NIF 60 посредством отправки сообщения 305 в NIF 60. NIF 60 может подтвердить прием сообщения 305 посредством отправки сообщения 306 в PCRF 30.

Независимо от представления отчета о статистике сети в NIF 60, PCRF 30 может продолжить отслеживать операции для повторного генерирования статистики сети посредством повторного получения того же типа информации от узла 21, как проиллюстрировано сообщениями 307 и 308. Например, первоначальный запрос от NIF 60, такой как с сообщением 201 по фиг. 2, мог задать расписание представления отчета на основании одного или более запускающих событий. Одним примером такого запускающего события является истечение действия таймера. Например, первоначальный запрос от NIF 60, мог задать представление отчета после определенного интервала времени или с регулярными интервалами времени. В этом случае, представление отчета о статистике сети могло бы запускаться один раз или каждый раз, когда истекает действие таймера. Дополнительным примером запускающего события является отслеживаемое значение, достигающее порога. Например, PCRF 30 может отслеживать некоторое число пересылаемых пакетов данных, и представление отчета о статистики сети может быть запущено за счет превышения числом пересылаемых пакетов данных порогового числа пакетов данных, например, которое задано в первоначальном запросе от NIF 60. Отслеживаемое значение может быть частью представленной статистики.

В процессе по фиг. 3, запускающее событие проиллюстрировано, чтобы происходить на этапе 309, который также может включать в себя обнаружение запускающего события посредством PCRF 30. В ответ на обнаружение запускающего события, PCRF 30 генерирует статистику сети посредством компилирования полученной информации, как проиллюстрировано на этапе 310, и представляет отчет о сгенерированной статистики сети в NIF 60 посредством отправки сообщения 311 в NIF 60. NIF 60 может подтвердить прием сообщения 311 посредством отправки сообщения в PCRF 30.

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

В вышеописанных процессах, посредством PCRF 30 могут быть применены разные механизмы для получения выбранных типов информации от различных узлов. Например, могут быть использованы существующие функции представления отчетов о событиях определенных узлов. Согласно разделу 6.1.4 3GPP TS 23.203 такие функции представления отчетов о событиях могут быть расположены в PCEF 34, TDF 36 и BBERF 39. Эти функции представления отчетов работают на уровне сеансов сетей доступа с IP-связностью (IP-CAN), т.е. могут представлять отчеты о событиях, относящихся к определенному сеансу IP-CAN. PCRF 30 может затем координировать информацию, относящуюся к разным сеансам IP-CAN, для того, чтобы сгенерировать статистику сети.

Для того чтобы использовать существующие функции представления отчета о событии, PCRF 30 может подписаться на новые триггеры событий или удалить приведенные в действие триггеры событий. В зависимости от типа узла, это может быть совершено посредством использования процедуры обеспечения правилами PCC, процедуры обеспечения правилами QoS или процедуры обеспечения правилами обнаружения и управления приложениями (ADC), которые заданы в 3GPP TS 23.203. PCRF 30 может приводить в действие и приводить в дежурный режим триггеры событий учитывая информацию, которую должна получить PCRF 30 для генерирования статистики сети. В дальнейшем, некоторые примеры использования таких триггеров событий будут разъяснены посредством ссылки на триггеры событий, которые заданы в таблице 6.2 3GPP TS 23.203.

- Согласно одному примеру, PCRF 30 может требоваться подсчитать число попыток доступа к определенному сервису. В этом случае, PCRF 30 может привести в действие триггер события ″Начать обнаружение трафика приложения″ в PCEF 34 или TDF 36. Это будет предписывать представление отчета в PCRF 30, как только обнаружен определенный тип трафика приложения. Идентификатор обнаруженного приложения может быть включен в отчет для PCRF 30. Если эта информация релевантна только для пользователей, расположенных в определенной области, PCRF 30 может также привести в действие триггер события ″Изменение местоположения″ в PCEF 34 или BBERF 39. Если в последнем случае триггер события ″Начать обнаружение трафика приложения″ может быть приведен в действие только для тех пользователей, которые расположены в определенной области, согласно информации, полученной посредством PCRF 30 посредством отчетов, сгенерированных посредством триггера события ″Изменение местоположения″.

- Согласно дополнительному примеру, PCRF 30 может требоваться подсчитать объем трафика восходящей линии связи для определенной APN. В этом случае, PCRF 30 может привести в действие триггер события ″Отчет об использовании″ в PCEF 34 или TDF 36 для всех сеансов IP-CAN, соответствующих этой APN. В дополнение, PCRF 30 может предоставить соответствующие ключи отслеживания с ассоциированной квотой использования в PCEF 34 или TDF 36. Если эта информация, например, релевантна только для абонентов, которые не находятся в роуминге, PCRF 30 может также привести в действие триггер события ″Изменение PLMN″ в PCEF 34. В последнем случае, триггер события ″Отчет об использовании″ может быть приведен в действие только для пользователей, которые не находятся в роуминге согласно информации, полученной посредством PCRF 30 посредством отчетов, сгенерированных посредством триггера события ″Изменение PLMN″, т.е. был представлен отчет о неиспользовании домена другого оператора.

Для того чтобы иметь возможность приведения в действие триггеров событий, может требоваться повторная авторизация проводящихся сеансов IP-CAN. Соответственно, сигнализация между PCRF 30 и узлом, выбранным в качестве источника информации, может также включать в себя запрос повторной авторизации сеанса для проводящийся сеансов IP-CAN, например, в сообщениях 205, 207, 301, 307. Запрос повторной авторизации сеанса может указывать подписку или отмену подписки на триггеры событий и/или модификацию, установку или удаление правил PCC, правил QoS или правил ADC. В зависимости от информации, которая должна быть получена, запрос повторной авторизации сеанса может применяться к одному или более узлам, предусмотренным при обслуживании сеанса IP-CAN.

В некоторых сценариях, например, для статистики сети, относящихся к использованию группой пользователей, удовлетворяющих определенным критериям, PCRF 30 может быть сконфигурирована с возможностью предоставления соответствующих счетчиков использования. Например, PCRF 30 может предоставить счетчик использования для подсчета числа пересылаемых пакетов данных восходящей линии связи при осуществлении доступа с использованием сервиса IMS с определенным типом терминала. Такие счетчики могут накапливать отслеживаемые значения для группы пользователей. Для сеансов IP-CAN пользователей, удовлетворяющих критериям, PCRF 30 может привести в действие триггер события ″Отчет об использовании″ в PCEF 34 или TDF 36 и предоставить соответствующие ключи отслеживания и ассоциированные квоты использования. На основании отчетов, сгенерированных посредством триггера события ″Отчет об использовании″, PCRF 30 может увеличить счетчик использования.

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

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

В процессе по фиг. 4, на этапе 401 PCRF 30 выбирает профиль представления отчетов. Это может быть совершено по каждому сеансу пользователя согласно определенным критериям выбора, сконфигурированным в PCRF 30. Примеры таких критериев выбора будут разъяснены в дальнейшем.

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

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

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

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

Как проиллюстрировано этапом 403, TDF 36 генерирует отчет с информацией, запрошенной посредством PCRF 30. Это совершается на основании профиля представления отчетов, указанного в сообщении 402. Например, если указанный профиль представления отчетов задает, представить отчет с информацией по каждому URL, отчет может быть сгенерирован соответственно. TDF 36 может затем отправить сообщение 404 с отчетом в PCRF 30.

Как проиллюстрировано этапом 405, PCRF 30 может изменить выбранный профиль представления отчетов, например, в ответ на прием обновленной информацией от NIF 60. PCRF 30 может указывать изменение выбранного профиля представления отчетов посредством отправки соответствующего сообщения, например, сообщения 406 в процессе по фиг. 4.

Для того чтобы реализовать механизм представления отчетов, основанный на профиле представления отчетов, протокол интерфейса между PCRF 30 и узлом, из которого представляется отчет об информации, может быть расширен посредством возможности передавать указание выбранного профиля представления отчетов из PCRF 30 в узел. Это может быть достигнуто посредством добавления соответствующей пары атрибут-значение (AVP) к определенным сообщениям протокола, которые включают в себя идентификатор профиля представления отчетов (RP-ID). Примеры идентификаторов профилей представления отчетов и соответствующих профилей представления отчетов даны ниже:

- RP-ID=0: нет представления отчетов для сеанса пользователя

- RP-ID=1: представление отчетов по каждому обнаруженному сервису для сеанса пользователя

- RP-ID=2: представление отчетов по каждому обнаруженному сервису и по каждому обнаруженному URL для сеанса пользователя

....

- RP-ID=N: полное представление отчетов для сеанса пользователя.

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

В связи с TDF 36, использование профилей представления отчетов обеспечивает возможность для использования TDF 36 не только для обнаружения определенных типов трафика, но также в качестве IP- или DPI-зонда, предоставляющего различные типы информации, например, в том, что касается числа обращений, объема трафика, времени использования или подобного, для различных типов URL или сервисов. Это может быть достигнуто посредством конфигурирования TDF 36 для предоставления записей по каждому обнаруженному сервису или по каждому обнаруженному URL, которые могут затем быть использованы в качестве основания отчета. Представление отчета из TDF 36 может совершаться периодически или запускаться посредством одного или более сконфигурированных запускающих событий, например числа обращений или достижений порога объема. TDF 36 может также использовать конкретные методы осуществления выборки для генерирования информации, которая должна быть представлена, что может обеспечить возможность уменьшения величины трафика, который должен быть проанализирован. Например, только пакеты обработки либо с нечетными, либо с четными IP-адресами получателя могли бы быть обработаны, тем самым уменьшая нагрузку обработки, в то же время сохраняя достаточную статистическую точность в полученных результатах.

Фиг. 5 дополнительно иллюстрирует примерную реализацию контроллера 30 политик согласно варианту осуществления данного изобретения. Контроллер 30 политик может соответствовать контроллеру политик, который разъяснен в связи с фиг. 1-4, и может, в частности, быть реализован как PCRF.

В проиллюстрированном примере, контроллер 30 политик включает в себя множество интерфейсов 120, 130 узла и интерфейс 140 статистики сети. Интерфейсы 120, 130 узла могут быть использованы для связи с различными типами сетевых узлов, таких как шлюзовые узлы, например, SGW 24 или PGW 26, узлы обнаружения трафика, например, TDF 36, узлы AF, например, AF 50, узлы абонентской базы данных, например, хранилище 38, узлы системы тарификации, например, OCS 44, или узел сети фиксированного доступа, например, FAN 55. Интерфейс 140 статистики сети может быть использован для связи с функцией сетевого интеллекта, например, NIF 60. В архитектуре PCC 3GPP, которая проиллюстрирована на фиг. 1, интерфейсы 120, 130 узла могут реализовать опорные точки Gx, Gxx, Rx, Sd, Sp или Sy или интерфейс RADIUS.

Кроме того, контроллер 30 политик включает в себя процессор 150, соединенный с интерфейсами 120, 130, 140, и память 160, соединенную с процессором 150. Память 160 может включать в себя постоянную память (ROM), например постоянную флэш-память (flash ROM), оперативную память (RAM), например динамическую RAM (DRAM) или статическую RAM (SRAM), хранилище большой емкости, например жесткий диск или твердотельный диск, или подобное. Память 160 включает в себя соответственно сконфигурированный программный код, который должен быть исполнен процессором 150, с тем, чтобы реализовать вышеописанные функциональные возможности контроллера 30 политик для генерирования статистики сети. Более конкретно, память 160 может включать в себя модуль 170 выбора узла с тем, чтобы реализовать функциональные возможности осуществления выбора одного или более узлов в качестве источника информации, как описано в настоящем документе. Кроме того, память 160 может включать в себя модуль 180 выбора типа информации управления с тем, чтобы реализовать функциональные возможности осуществления выбора типа информации, которая должна быть получена для генерирования статистики сети, которые описаны в настоящем документе. Кроме того, память 160 может включать в себя модуль 190 генерирования статистики сети с тем, чтобы реализовать функциональные возможности компилирования статистики сети из полученной информации и представления отчета с сгенерированной статистике сети, как описано в настоящем документе.

Следует понимать, что структура, которая проиллюстрирована на фиг. 5, является лишь схематичной, и что контроллер 30 политик может в действительности включать в себя дополнительные компоненты, которые, для ясности, не проиллюстрированы, например дополнительные интерфейсы. Также, некоторые из проиллюстрированных структур могут быть опущены. Например, один из интерфейсов 120, 130 узла мог бы быть опущен в некоторых вариантах осуществления. Также, следует понимать, что память 160 может включать в себя дополнительные типы модулей программного кода, которые не проиллюстрированы, например модули программного кода для реализации известных функциональных возможностей контроллера политик, например генерирования фильтра или подобных. Согласно некоторым вариантам осуществления, также компьютерный программный продукт может быть предоставлен для реализации идей согласно вариантам осуществления данного изобретения, например среды, хранящей программный код, который должен храниться в памяти 160.

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

На этапе 610, контроллер политик принимает запрос на генерирование по меньшей мере одной статистики сети. Запрос может идентифицировать множество статистических показателей сети, которые должны быть сгенерированы контроллером политик. Запрос может включать в себя один или более идентификаторов статистики, чтобы идентифицировать запрашиваемые статистические показатели сети, например, в виде списка. Запрос может быть принят от функции сетевого интеллекта, например, NIF 60 по фиг. 1-3. Статистика сети может представлять собой число пользователей, зарегистрированных для определенного сервиса и использующих определенную технологию радиодоступа, число попыток доступа к определенному сервису для пользователей в определенной области, число пользователей, использующих ускорение трафика во время роуминга, число попыток доступа к определенному ресурсу сети, число попыток доступа к определенному сервису, число сеансов, установленных по отношению к определенному шлюзовому узлу, число активных пользователей, пересылаемый объем трафика и/или число пересылаемых пакетов данных. Соответственно, статистика сети может иметь отношение к множеству пользователей.

На этапе 620, контроллер политик выбирает по меньшей мере один узел из множества узлов в качестве источника информации. Примеры таких узлов включают в себя шлюзовой узел, например, SGW 24 или PGW 26 по фиг. 1, узел обнаружения трафика, например, узел, включающий в себя TDF 36 по фиг. 1 или 4, узел функции приложения, например, узел, включающий в себя AF 50 по фиг. 1, узел абонентской базы данных, например, узел, включающий в себя хранилище 38 по фиг. 1, узел системы тарификации, например, узел, включающий в себя OCS 44 по фиг. 1, и узел сети фиксированного доступа, например, FAN 55 по фиг. 1. Контроллер политик может также определять, доступна ли информация для генерирования запрашиваемой статистики сети в самом контроллере политик. В этом случае, контроллер политик может выбрать себя в качестве источника информации. Это может быть совершено на основании идентификатора статистики, включенного в запрос, и/или на основе информации, хранящейся в контроллере политик, например, в виде информации, относящей определенный идентификатор статистики к соответствующей конфигурации источников информации.

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

В некоторых вариантах осуществления, выбор узла в качестве источника информации и/или выбор типа информации может зависеть от другой информации, полученной контроллером политик. Соответственно, в некоторых вариантах осуществления контроллер политик может выбрать один или более узлов в качестве первого источника информации и получить первую информацию из этого узла или узлов, выбранных в качестве первого источника информации. Контроллер политик может затем выбрать по меньшей мере один узел и/или по меньшей мере один тип информации, которая должна быть получена для генерирования статистики сети, на основании полученной первой информации. Например, контроллер политик может сначала получить информацию из узла абонентской базы данных, например из хранилища 38, чтобы задать группу пользователей, и может затем выбрать один или более шлюзовых узлов, например шлюзовых узлов, включающих в себя PCEF, чтобы получить информацию по сеансам пользователей для этих пользователей, например указания попыток доступа, указаний использования, указаний местоположения, или подобного. Кроме того, узел обнаружения трафика, например, TDF 36, мог бы сначала обнаружить определенный тип трафика, и контроллер политик может затем выбрать принять информацию о местоположении, например из шлюзового узла, включающего PCEF, как, например, PGW 26, для того, чтобы проследить местоположения, где использован этот сервис.

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

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

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

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

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

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

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

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

1. Способ предоставления статистики сети в мобильной сети, содержащий:
контроллер (30) политик мобильной сети, принимающий запрос (201) на генерирование статистики сети, причем запрос (201) содержит идентификатор статистики;
контроллер (30) политик, выбирающий на основании идентификатора статистики из множества узлов (21, 22, 24, 26, 30, 34, 36, 38, 39, 44, 50, 55) по меньшей мере один узел (21, 22, 24, 26, 30, 34, 36, 38, 39, 44, 50, 55) в качестве источника информации;
контроллер (30) политик, выбирающий на основании идентификатора статистики по меньшей мере один тип информации, которая должна быть получена;
контроллер (30) политик, получающий выбранный тип информации из выбранного по меньшей мере одного узла (21, 22, 24, 26, 30, 34, 36, 38, 39, 44, 50, 55);
контроллер (30) политик, генерирующий запрашиваемую статистику сети на основании полученной информации; и
контроллер (30) политик, отправляющий отчет (212), содержащий сгенерированную статистику сети.

2. Способ согласно п. 1,
причем множество узлов содержат контроллер (30) политик, шлюзовой узел (24, 26), узел (36) обнаружения трафика, узел (50) функции приложения, узел (38) абонентской базы данных, узел (44) системы тарификации, или узел (55) сети фиксированного доступа.

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

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

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

6. Способ по одному из пп. 1-5,
причем контроллер (30) политик выбирает по меньшей мере один узел (21, 22, 24, 26, 30, 34, 36, 38, 39, 44, 50, 55) и/или по меньшей мере один тип информации на основании информации, хранящейся в контроллере (30) политик.

7. Способ по одному из пп. 1-5, содержащий:
контроллер (30) политик, выбирающий один из узлов (21, 22, 24, 26, 30, 34, 36, 38, 39, 44, 50, 55) в качестве первого источника информации;
контроллер (30) политик, получающий первую информацию из
узла (21, 22, 24, 26, 30, 34, 36, 38, 39, 44, 50, 55), выбранного в качестве первого источника информации;
причем контроллер (30) политик выбирает по меньшей мере один узел (21, 22, 24, 26, 30, 34, 36, 38, 39, 44, 50, 55) и/или по меньшей мере один тип информации на основании полученной первой информации.

8. Способ по одному из пп. 1-5, содержащий:
контроллер (30) политик, решающий, следует ли установить сеанс с выбранным узлом (21, 22, 24, 26, 30, 34, 36, 38, 39, 44, 50, 55).

9. Способ по одному из пп. 1-5, содержащий:
контроллер (30) политик, выбирающий, из множества профилей представления отчетов, профиль представления отчетов для получения выбранного типа информации; и
контроллер (30) политик, отправляющий запрос (402) представления отчетов, идентифицирующий профиль представления отчетов, в выбранный по меньшей мере один узел.

10. Контроллер (30) политик для мобильной сети, содержащий:
по меньшей мере один интерфейс (120, 130) для связи с узлами мобильной сети и/или другими узлами;
интерфейс (140) статистики сети; и
процессор (150),
причем процессор (150) сконфигурирован с возможностью:
- приема, через интерфейс (140) статистики сети, запроса (201) на генерирование статистики сети, причем запрос (201) содержит идентификатор статистики;
- выбора на основании идентификатора статистики и из
множества узлов (21, 22, 24, 26, 30, 34, 36, 38, 39, 44, 50, 55), по меньшей мере одного узла (21, 22, 24, 26, 30, 34, 36, 38, 39, 44, 50, 55) в качестве источника информации,
- выбора, на основании идентификатора статистики сети, по меньшей мере одного типа информации, которая должна быть получена,
- получения выбранного типа информации из выбранного по меньшей мере одного узла (21, 22, 24, 26, 30, 34, 36, 38, 39, 44, 50, 55);
- генерирования запрашиваемой статистики сети на основании полученной информации, и
- отправки отчета (212), содержащего сгенерированную статистику сети, через интерфейс (140) статистики сети.

11. Контроллер (30) политик по п. 10,
причем процессор (150) сконфигурирован с возможностью выполнения этапов способа, который задан посредством любого из пп. 1-9.

12. Система для генерирования статистики сети в мобильной сети, содержащая:
контроллер (30) политик мобильной сети; и
узел (60) сетевого интеллекта,
причем контроллер (30) политик сконфигурирован с возможностью:
- приема, из узла (60) сетевого интеллекта, запроса (201) на генерирование статистики сети, причем запрос (201) содержит идентификатор статистики,
- выбора на основании идентификатора статистики и из
множества узлов (21, 22, 24, 26, 30, 34, 36, 38, 39, 44, 50, 55), по меньшей мере одного узла (20) в качестве источника информации,
- выбора, на основании идентификатора статистики, по меньшей мере одного типа информации, которая должна быть получена,
- получения выбранного типа информации из выбранного по меньшей мере одного узла (21, 22, 24, 26, 30, 34, 36, 38, 39, 44, 50, 55);
- генерирования запрашиваемой статистики сети на основании полученной информации, и
- отправки отчета (212), содержащего сгенерированную статистику сети, на узел (60) сетевого интеллекта.

13. Система по п. 12,
причем контроллер (30) политик сконфигурирован с возможностью выполнения этапов способа, который задан посредством любого из пп. 1-9.

14. Машиночитаемый носитель, содержащий программный код, который при исполнении процессором (150) контроллера (30) политик мобильной сети конфигурирует контроллер политик для выполнения способа, который задан посредством любого пункта 1-9.