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

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

Иллюстрации

Показать все

Реферат

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Фиг. 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 генерирует статистику сети посредством компилирования полученной информации, как проил