АГРЕГИРОВАНИЕ ИНФОРМАЦИИ О ПЕРЕГРУЗКЕ Российский патент 2018 года по МПК H04L12/58 H04W28/02 

Область техники

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

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

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

Недавно применительно к рабочему вопросу управления перегрузками на плоскости пользователя (UPCON) в Проекте партнерства 3^го поколения (3GPP) предложено новое решение, которое использует обратную связь о перегрузке от RAN к CN (базовая сеть), см. Технический Отчет (TR) 23.705 3GPP, версия 0.10.0 от мая 2014 г., раздел 6.1. Когда RAN указывает для CN перегрузку, CN может предпринять действия для уменьшения перегрузки, например, ограничить некоторые классы трафика или запросить задержку некоторых других классов трафика.

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

Современные системы OAM RAN работают на уровне соты или даже с меньшей пространственной детализацией. То есть определение перегрузки может выполняться на основе соты либо может выполняться для группы сот, например сот, принадлежащих одному и тому же eNodeB (усовершенствованный Узел Б) для сетей мобильной связи в соответствии со стандартом системы долгосрочного развития (LTE), который задан 3GPP, или сот, принадлежащих одной и той же зоне обслуживания для сетей мобильной связи в соответствии со стандартом универсальной системы мобильных телекоммуникаций (UMTS), который задан 3GPP. Чтобы CN предприняла подходящее действие по уменьшению, CN обычно нужно определить, какие мобильные объекты (UE) располагаются в данной соте. Поэтому список затронутых UE нужно определять для сот, которые считаются перегруженными на основе данных OAM.

Одно из решений для передачи отчета о перегрузке на основе OAM документируется в решении 1.5.5 (также называемом неосновным решением) в разделе 6.1.5.5 TR 23.705 3GPP, версия 0.10.0 от мая 2014 г., которое с этой целью предлагает интерфейс Nq. Интерфейс Nq задается между сетевым объектом, обозначаемым как функция оповещения о перегрузке RAN (RCAF), и объектом управления мобильностью (MME). RCAF принимает отчет о перегрузке, включающий в себя связанные с перегрузкой RAN данные из системы OAM RAN, с пространственной детализацией до соты или с меньшей детализацией. Затем RCAF, используя интерфейс Nq, просит у MME доставить список UE на каждую соту.

Аналогичный подход предлагается для случая UMTS, использующего интерфейс Nqʹ от RCAF к обслуживающему узлу поддержки GPRS (SGSN). Однако для UMTS существует отличие, поскольку RAN может уже знать идентификаторы UE, так как контроллеру радиосети (RNC) может отправляться, например, международный идентификатор абонента мобильной связи (IMSI). OAM RAN собирает эти IMSI, а затем OAM RAN доставляет RCAF список UE, идентифицированных по IMSI, которые испытывают перегрузку. Поэтому в таком сценарии UMTS список UE, испытывающих перегрузку, известен RCAF без общения с SGSN по интерфейсу Nqʹ.

Как только узел RCAF собрал информацию о наборе UE, испытывающих перегрузку, он уведомляет функцию политики и правил тарификации (PCRF) об уровне перегрузки затронутых UE путем отправки информации о перегрузке. Здесь UE можно идентифицировать по идентификатору UE, например IMSI. С этой целью задается интерфейс Np между RCAF и PCRF. Как описано в TR 23.705 3GPP, версия 0.10.0 от мая 2014 г., раздел 6.1.6, PCRF затем может предпринять действия для уменьшения перегрузки, например, путем ограничения трафика в узле принудительного выполнения, например шлюзе сети с коммутацией пакетов (PGW) или функции обнаружения трафика (TDF), либо уведомления прикладной функции (AF) для ограничения или задержки трафика и т.п.

Современные методы, как правило, требуют отправки сравнительно большого количества сообщений, включающих в себя информацию о перегрузке, от RCAF к PCRF по интерфейсу Np. Это само может обуславливать значительный трафик по интерфейсу Np. Если данная сота становится перегруженной, то обычно большее количество UE, подключенных к этой соте, начинает испытывать перегрузку; в свою очередь, вместе с этим обычно изменяется состояние перегрузки для этого количества UE. Поэтому чрезмерный трафик сигнализации по интерфейсу Np может привести к необходимости дорогих и сложных модернизаций PCRF и/или RCAF для обработки таких ситуаций. Чрезмерная сигнализация по интерфейсу Np может сделать работу сети мобильной связи неустойчивой, особенно когда от перегрузки страдает значительная часть сети мобильной связи.

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

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

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

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

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

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

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

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

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

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

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

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

Фиг. 3 схематически иллюстрирует вариант осуществления агента маршрутизации Diameter (DRA), который может упростить взаимодействие RCAF и PCRF.

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

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

Фиг. 6 - схема сигнализации, иллюстрирующая вариант осуществления сигнализации сообщения, включающего в себя агрегированную информацию о перегрузке между RCAF и PCRF.

Фиг. 7 - схема сигнализации, иллюстрирующая вариант осуществления сигнализации сообщения, включающего в себя агрегированную информацию о перегрузке между RCAF и PCRF, при этом сигнализация упрощается с помощью DRA.

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

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

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

Подробное описание

Ниже идеи в соответствии с вариантами осуществления будут подробнее объясняться путем ссылки на прилагаемые чертежи. Проиллюстрированные решения относятся к методам отправки агрегированной информации о перегрузке. В частности, идеи относятся к отправке сообщения от блока контроля перегрузок в сети мобильной связи блоку управления политикой в сети мобильной связи, при этом сообщение включает в себя агрегированную информацию о перегрузке. Сеть мобильной связи может основываться, например, на технологии LTE, заданной 3GPP, и передаче отчета о перегрузке на основе OAM, которая описана в TR 23.705 3GPP от мая 2014 г., раздел 6.1.5.5. Однако нужно понимать, что сеть мобильной связи с тем же успехом могла бы реализовать другие технологии, например, UMTS или глобальную систему мобильной связи (GSM) в связи с общей службой пакетной радиопередачи (GPRS).

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

С помощью таких методов становится возможным уменьшить объем трафика сигнализации по соответствующему интерфейсу между блоком контроля перегрузок и блоком управления политикой, то есть в случае технологии LTE - по интерфейсу Np между RCAF и PCRF. В частности, поскольку можно включать информацию о перегрузке для множества UE в одно сообщение (агрегирование), можно уменьшить трафик сигнализации приблизительно в соотношении агрегирования, то есть количества порций информации о перегрузке на каждое сообщение. Кроме того, служебную нагрузку, необходимую для сигнализации информации о перегрузке, можно уменьшить путем повторного использования заголовка данных у сообщения для множества порций информации о перегрузке при агрегировании.

Фиг. 1 показывает архитектуру сети 1 мобильной связи в соответствии с технологией LTE, в которой блок контроля перегрузок в виде RCAF 200 определяет уровни перегрузки у UE (не показаны на фиг. 1) в RAN 10. RCAF 200 способна определять перегрузку на плоскости пользователя RAN, которая возникает, когда спрос на ресурсы RAN превышает доступную пропускную способность RAN для доставки пользовательских данных в течение некоторого периода времени. Перегрузка на плоскости пользователя RAN может приводить, среди прочего, к отбрасываниям или задержкам пакетов. RCAF 200 обычно извлекает отчет о перегрузке по действующему состоянию производительности на плоскости пользователя RAN на уровне соты от блока 11 OAM RAN; этот отчет о перегрузке обычно анализируется и оценивается перед его передачей в качестве информации о перегрузке блоку управления политикой, реализованному в виде PCRF 100 в сценарии из фиг. 1. Для связи информации о перегрузке между RCAF 200 и PCRF 100 предоставляется интерфейс Np.

Связь между RCAF 200 и PCRF 100 можно реализовать и упростить посредством объекта базы данных маршрутизации (не показан на фиг. 1), например, агента маршрутизации Diameter (DRA). Такие методы дают возможность отправлять сообщение, например, от RCAF 200 к PCRF 100 посредством DRA путем применения логического имени PCRF 100, а не адреса по Интернет-протоколу (IP) и/или имени по системе доменных имен (DNS) у PCRF 100. Однако возможно, что RCAF 200 извлекает идентификатор PCRF 100, причем идентификатор PCRF 100 является по меньшей мере одним из IP-адреса имени DNS. В качестве альтернативы или дополнительно можно отправлять сообщение, включающее в себя агрегированную информацию о перегрузке, от RCAF 200 к PCRF 100 путем непосредственной маршрутизации сообщения к PCRF 100, то есть исключая необходимость применения DRA.

RCAF 200, кроме того, подключена к MME по интерфейсу Nq. В случае технологии UMTS (не показано на фиг. 1) RCAF 200 подключается к SGSN 20 по интерфейсу Nqʹ. Данные плоскости пользователя, для которых контролируется перегрузка, передаются от RAN 10 через обслуживающий шлюз 30 (SGW), который маршрутизирует и перенаправляет пользовательские пакеты данных в шлюз 40 сети с коммутацией пакетов (GW PDN или PGW). Из GW 40 PDN пользовательские данные передаются посредством TDF 50 в сеть 60 с коммутацией пакетов (PDN). Это соответствует направлению восходящей линии связи. Также возможно, что пользовательские данные передаются в направлении нисходящей линии связи, то есть к RAN 10.

Нижеследующее описание сосредоточено на RCAF 200 и PCRF 100 и взаимодействии между RCAF 200 и PCRF 100. RCAF 200 использует отчет о перегрузке, предоставленный OAM 11 RAN, включающий в себя такую информацию, как величина потери пакетов данных, задержка при передаче пакета, пропускная способность по трафику, использование радиоинтерфейса или количество подключенных пользователей, для определения состояния перегрузки у некоторой области, например, на основе конфигурируемых пороговых величин. RCAF 200 определяет, какие UE испытывают состояние перегрузки в некоторой области, используя предоставленную MME 20 информацию.

На фиг. 1 показана одна PCRF 100. Однако в сети 1 мобильной связи может быть множество PCRF 100. Данная RCAF 200 может быть способна выборочно осуществлять связь с одной из множества PCRF 100. Как правило, данное UE статически ассоциируется/назначается конкретной PCRF 100, действующей в качестве привязки мобильности для данного UE. PCRF 100 обрабатывает сеанс сети доступа с IP-соединениями (IP CAN) у данного UE. PCRF 100 реализует политику обработки трафика данных для ассоциированных UE путем управления TDF 50 и/или GW 40 PDN, реализующих функцию применения управления политикой (PCEF) по интерфейсам Sd и Gx соответственно.

Вообще возможно, что данное UE ассоциируется с одной PCRF. Также возможно, что данное UE ассоциируется с множеством PCRF 100. Например, данное UE может иметь несколько соединений PDN с разными PDN 60 (не показано на фиг. 1). PDN можно идентифицировать по их именам точек доступа (APN). Обычно для каждого APN возможно наличие разной PCRF 100. Например, UE может одновременно подключаться к первой PDN и ко второй PDN, где первая PDN 60 идентифицируется по первому APN, и где вторая PDN 60 идентифицируется по второму APN. Для трафика данных между UE и первой PDN 60 UE может ассоциироваться с первой PCRF 100. Для трафика данных между UE и второй PDN 60 UE может ассоциироваться со второй PCRF 100.

RCAF 200 конфигурируется для агрегирования информации о перегрузке по меньшей мере для некоторых из множества UE на основе соответствующих UE, ассоциируемых с PCRF 100. То есть информация о перегрузке, относящаяся к уровню перегрузки данного UE, ассоциированного с данной PCRF 100 (с иной PCRF, нежели данная PCRF 100), включается в агрегирование (исключается из агрегирования) в данное сообщение. Затем RCAF 200 отправляет PCRF 100 сообщение, включающее в себя агрегированную информацию о перегрузке. PCRF 100 конфигурируется для приема сообщения от RCAF 200, при этом сообщение включает в себя агрегированную информацию о перегрузке для множества UE, ассоциированных с PCRF 100. PCRF 100 может ответить сообщением о результате. В сообщении о результате можно привести один код успеха или ошибки для всего сообщения, включающего в себя агрегированную информацию о перегрузке. В качестве альтернативы или дополнительно коды успеха или ошибки могли бы приводиться отдельно для каждой информации о перегрузке, включенной в сообщение.

Возможно, что сообщение и/или сообщение о результате кодируются в соответствии с протоколом Diameter, см. Запрос на изменения (RFC) 6733 от Инженерного совета Интернета (IETF).

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

Чтобы эффективно реализовать агрегирование информации о перегрузке, обычно и RCAF 200, и PCRF 100 должны поддерживать соответствующие схемы агрегирования. Существует возможность, что архитектура сети 1 мобильной связи включает в себя агрегирование информации о перегрузке в качестве необязательной функции. В простом сценарии PCRF 100 и/или RCAF 200 может опираться на предопределенную локальную конфигурацию возможностей у соответствующего другого блока для определения, поддерживается ли агрегирование информации о перегрузке; тогда отправка сообщения, включающего в себя агрегированную информацию о перегрузке, может выборочно исполняться в зависимости от этой локальной конфигурации. Однако может быть желательно реализовать методики согласования между RCAF 200 и PCRF 100, чтобы динамически устанавливать квитирование связи между ними, указывающее возможности агрегирования сообщений. Чтобы упростить согласование возможности, RCAF 200 может указывать, что поддерживается агрегирование информации о перегрузке, например, с помощью флага или иным образом в управляющем сообщении от RCAF 200 к PCRF 100. В качестве альтернативы или дополнительно PCRF 100 может указывать, поддерживается ли агрегирование информации о перегрузке, например, с помощью флага или иным образом в управляющем сообщении от PCRF 100 к RCAF 200; в такое управляющее сообщение можно включать идентификатор PCRF 100, упрощающий прямую маршрутизацию дополнительных сообщений от RCAF 200 к PCRF 100. Как правило, согласование агрегирования информации о перегрузке может инициироваться PCRF 100 и/или RCAF 200. Таким образом, PCRF 100 и RCAF 200 можно уведомлять о том, поддерживает ли соответствующий другой узел 100, 200 агрегирование информации о перегрузке, и можно, например, выборочно применять агрегирование информации о перегрузке, только когда оба узла сигнализируют поддержку.

Между PCRF 100 и RCAF 200 можно согласовать дополнительные параметры агрегирования - помимо просто возможности поддерживать агрегирование информации о перегрузке. Например, возможно, что RCAF 200 и PCRAF 100 согласуют по меньшей мере одно из задержки или максимального размера сообщения, включающего в себя агрегированную информацию о перегрузке. Например, возможно, что в RCAF 200 и/или PCRF 100 ограничивается максимальный размер сообщения, включающего в себя агрегированную информацию о перегрузке - соответственно, и максимальное количество информации о перегрузке на каждое сообщение, например, вследствие технических ограничений или соображений трафика. Это может накладывать ограничение, когда RCAF 200 агрегирует информацию о перегрузке; агрегирование следует прекратить, как только достигнут максимальный размер. В простом сценарии возможно, что максимальный размер сообщения предварительно конфигурируется статически в RCAF 200. Однако также возможно, что PCRF 100 явно или неявно указывает RCAF 200 максимальный размер сообщения. Это указание может выполняться как часть согласования, соответственно, квитирования связи между RCAF 200 и PCRF 100. Если, например, поддерживаемые максимальные размеры сообщений отличаются между PCRF 100 и RCAF 200, то RCAF 200 следует применять самое строгое ограничение.

Чтобы дополнительно уменьшить трафик сигнализации, предписанный в интерфейсе Np, возможно, чтобы RCAF 200 применяла схемы сжатия до отправки агрегированной информации о перегрузке к PCRF 100. Это может уменьшить размер сообщения, включающего в себя агрегированную информацию о перегрузке; в силу этого доставка сообщения может выполняться быстрее и, возможно, надежнее. Конкретный тип применяемого метода сжатия сообщения не ограничивается. Например, методы сжатия сообщений могут варьироваться от группирования информации о перегрузке UE в зависимости от уровня перегрузки, указанного соответствующей информацией о перегрузке; замены конкретного общепринятого APN более коротким маркером; до более сложных схем сжатия, например, кодирования длины серии или энтропийного кодирования.

Может быть желательно реализовать надежную доставку сообщений, включающих в себя агрегированную информацию о перегрузке. Это может достигаться путем применения надежного или полунадежного транспортного протокола для доставки сообщений, например, протокола управления передачей (TCP) либо протокола передачи и управления потоком (SCTP). В качестве альтернативы или дополнительно могут применяться схемы подтверждения приема. Существует возможность реализовать подтверждение приема от PCRF 100 к RCAF 200, чтобы уменьшить вероятность сбоев передач. Подтверждения приема от PCRF 100 к RCAF 200 также могут использоваться для передачи результата обработки сообщения и указания кода успеха или ошибки, то есть включающего в себя сообщение о результате.

Фиг. 2A - схематическая иллюстрация PCRF 100. PCRF 100 включает в себя интерфейс 110, базу 130 данных и процессор 120. Интерфейс 110 может конфигурироваться для осуществления связи с различными объектами сети 1 мобильной связи путем отправки и/или приема данных. Например, интерфейс 110 может конфигурироваться для осуществления связи с RCAF 200 по интерфейсу Np (см. фиг. 1). Процессор 120 в PCRF 100 может конфигурироваться для исполнения различных задач применительно к дезагрегированию принятого сообщения, включающего в себя агрегированную информацию о перегрузке для множества UE, ассоциированных с PCRF 100; и определению политик для конкретных UE, ассоциированных с PCRF 100, например, в зависимости от соответствующей информации о перегрузке. База 130 данных может хранить различную информацию, связанную с UE, ассоциированными с PCRF 100. Например, база 130 данных может хранить информацию о перегрузке, ранее принятую по интерфейсу 110 для данного UE. В базе 130 данных также может предоставляться отображение между различными RCAF 200, развернутыми по всей сети 1 мобильной связи, и ассоциированными UE. В базе 130 данных могут предоставляться различные политики для данного UE. Дополнительно предоставляется запоминающее устройство 140, которое может быть постоянным запоминающим устройством, флэш-памятью, оперативным запоминающим устройством, массовой памятью, жестким диском или т. п. Запоминающее устройство 140 включает в себя подходящие программные коды для исполнения процессором 120, чтобы реализовать вышеописанные функциональные возможности. Процессор 120 может формировать команды, которые нужны для осуществления обсуждаемых выше процедур, в которых участвует PCRF 100, в частности, дезагрегирование сообщений и/или управление реализацией политик трафика данных к данному UE и от него, ассоциированному с PCRF, и/или согласование возможностей агрегирования и параметров агрегирования для агрегирования информации о перегрузке.

На фиг. 2B показан DRA 600, содержащий интерфейс 610, процессор 620, базу 630 данных и запоминающее устройство 640. Интерфейс 610 может конфигурироваться для приема данных и/или передачи данных к дополнительным объектам сети 1 мобильной связи и от них. База 630 данных может хранить записи, например, связывающие идентификатор UE с идентификатором PCRF 100. Посредством них, когда по интерфейсу 610 принимается сообщение, которое включает в себя идентификатор UE, процессор 620 может конфигурироваться для определения, опираясь на соответствующую запись в базе 630 данных, идентификатора соответствующей PCRF 100, с которой ассоциируется UE, и, например, сигнализации этого идентификатора дополнительному объекту и/или перенаправления принятого сообщения соответствующей PCRF 100. Кроме того, база 630 данных может содержать записи, связывающие логическое имя данной PCRF 100 с IP-адресом данной PCRF 100 и/или с именем DNS данной PCRF 100. Запоминающее устройство 640 может быть постоянным запоминающим устройством, флэш-памятью, оперативным запоминающим устройством, массовой памятью, жестким диском или т. п. Запоминающее устройство 640 включает в себя подходящие программные коды для исполнения процессором 620, чтобы реализовать вышеописанные функциональные возможности. Процессор 620 может формировать команды, которые нужны для осуществления обсуждаемых выше процедур, в которых участвует DRA 600. Такие процедуры включают в себя, в частности: извлечение из базы 630 данных идентификатора данной PCRF 100, ассоциированной с конкретным UE, на основе идентификатора UE.

Обычно DRA 600 является узлом, который может гибко маршрутизировать отдельные Diameter-сообщения правильному адресату. DRA 600 задаются в базовом протоколе Diameter в RFC 3588 и 6733 IETF, раздел 2.8 IETF. DRA 600 полезен для маршрутизации отдельных Diameter-сообщений на основе некоторого количества критериев. DRA 600 может скрывать топологию Diameter-маршрутизацию от конечных точек, здесь - RCAF 200 и PCRF 100. Таким образом, DRA 600 позволяет осуществлять управление сетью 1 мобильной связи проще для оператора. DRA 600 также может поддерживать продвинутые функции, например балансирование нагрузки между узлами. Маршрутизация Np-сообщений посредством DRA 600 описывается, например, в TS 23.705 3GPP, версия 0.11.0 от мая 2014 г., раздел 6.1.5.5.2.4.

На фиг. 3 показана подробнее RCAF 200. RCAF 200 содержит интерфейс 210, процессор 220, базу 230 данных и запоминающее устройство 240. Интерфейс 210 конфигурируется для передачи данных различным объектам сети 1 мобильной связи и для приема данных от различных объектов сети мобильной связи. В частности, сообщение, агрегирующее информацию о перегрузке, может отправляться от RCAF 200, применяющей интерфейс 210, к PCRF 100 по интерфейсу Np. Кроме того, база 230 данных может конфигурироваться для включения в себя различных записей, связывающих идентификатор данного UE с идентификатором PCRF 100, с которой ассоциируется UE; такая запись может быть частью так называемого контекста UE, который может относиться к данным, хранимым в расчете на UE. Контекст UE может включать в себя дополнительную информацию. Тогда перед отправкой сообщения, включающего в себя агрегированную информацию о перегрузке, к PCRF 100 по интерфейсу 210 можно выборочно добавлять в сообщение информацию о перегрузке для данного UE в зависимости от соответствующей записи в базе 230 данных.

Запоминающее устройство 240 может быть постоянным запоминающим устройством, флэш-памятью, оперативным запоминающим устройством, массовой памятью, жестким диском или т. п. Запоминающее устройство 240 включает в себя подходящие программные коды для исполнения процессором 220, чтобы реализовать вышеописанные функциональные возможности. Процессор 220 может формировать команды, которые нужны для осуществления обсуждаемых выше процедур, в которых участвует RCAF 200. Такие процедуры включают в себя, в частности: агрегирование информации о перегрузке по меньшей мере для некоторых из множества UE на основе соответствующих UE, ассоциируемых с PCRF 100; согласование с PCRF 100 возможности PCRF 100 поддерживать агрегировании информации о перегрузке; агрегирование информации о перегрузке для сообщения.

Хотя на фиг. 2A, 2B, 3 показан один процессор 120, 220, 620, также можно применять многоядерный процессор и/или несколько процессоров, взаимодействующих друг с другом соответствующим образом; возможна распределенная обработка. Например, существует возможность включать идентификатор сеанса для любой связи, адресованной PCRF 100, при этом идентификатор сеанса или идентификатор балансирования нагрузки адресует конкретный процессор из нескольких процессоров 120 в PCRF 100. Посредством этого можно реализовать методы балансирования нагрузки. PCRF 100 может предварительно согласовывать доступные идентификаторы сеансов с RCAF 200 и/или DRA 600. В частности, PCRF 100 может уведомлять RCAF 200 о конкретном идентификаторе сеанса, используемом для отправки агрегированной информации о перегрузке для одного или нескольких UE. То есть вообще возможно, чтобы RCAF 200 конфигурировалась для агрегирования информации о перегрузке на основе идентификатора сеанса, принятого от PCRF 100. Кроме того, хотя на фиг. 2A, 2B, 3 показана локальная база 130, 230, 630 данных, можно реализовать базу данных в виде функциональной сущности, логически находящейся, например, на сервере данных или т. п.

На фиг. 4 схематически показано агрегирование информации 415 о перегрузке. На фиг. 4 всего три PCRF 100-1, 100-2, 100-3 разворачиваются по всей сети 1 мобильной связи. UE 400-1, 400-2, 400-3 ассоциируются с первой PCRF 100-1. UE 400-4 ассоциируется со второй PCRF 100-2. UE 400-5, 400-6, 400-7, 400-8 ассоциируются с третьей PCRF 100-3. Агрегирование информации о перегрузке для различных UE 400-1-400-8 иллюстрируется на фиг. 4 вертикальными стрелками. Для PCRF 100-1 формируется первое сообщение 411-1, которое включает в себя агрегированную информацию 414 о перегрузке для UE 400-1, 400-2, 400-3. Для PCRF 100-2 формируется второе сообщение 411-2, которое включает в себя информацию 450 о перегрузке для UE 400-4; так как второе сообщение 411-2 включает в себя только информацию 450 о перегрузке для одного UE 400-4, оно является неагрегированным сообщением. Для третьей PCRF 400-3 формируется первое сообщение 411-3, которое включает в себя агрегированную информацию 415 о перегрузке для UE 400-5, 400-6, 400-7, 400-8. В сценарии из фиг. 4 информация 415 о перегрузке включается в сообщения 411-11-411-13 отдельно для каждого UE 400-1-400-8, то есть в расчете на каждое UE. Информация 415 о перегрузке задает уровень перегрузки для каждого UE 400-1-400-8. Например, уровень перегрузки может относиться к численному значению, указывающему серьезность перегрузки на предопределенной шкале. Однако вообще возможно, что информация 415 о перегрузке относится к двоичному флагу, указывающему перегрузку или отсутствие перегрузки. Чтобы предоставить информацию 415 о перегрузке отдельно для каждого UE 400-1-400-8, сообщения 411-1-411-3 дополнительно включают в себя идентификаторы 440 у UE 400-1-400-8 для каждой информации 415 о перегрузке. Кроме того, сообщения 411-1-411-3 включают в себя идентификатор 413 соответствующей PCRF 100-1-100-3, которой адресовано сообщение 411-1-411-3.

Хотя на фиг. 4 иллюстрируется сценарий, где каждое сообщение 411-1-411-3 включает в себя информацию 415 о перегрузке для каждого из UE 400-1-400-8, ассоциированных с соответствующей PCRF 100-1-100-3, также возможно, что сообщения 411-1-411-3 включают в себя информацию 415 о перегрузке только для некоторых из UE 400-1-400-8, ассоциированных с соответствующей PCRF 100-1-100-3. Другими словами, можно разово включить информацию 415 о перегрузке для всех UE 400-1-400-8, ассоциируемых с данной PCRF 100-1-100-3. Например, агрегирование информации 415 о перегрузке может - в дополнение к идентификатору 413 PCRF 100-1-100-3 - основываться дополнительно на задержке между приемом соответствующего отчета о перегрузке и/или максимальном размере сообщения у сообщений 411-1-411-3.

Обращаясь к фиг. 5, сценарий иллюстрируется посредством схемы сигнализации, где RCAF 200 сигнализирует PCRF 100 информацию 415 о перегрузке. На этапе S501 RCAF 200 принимает отчет 510 о перегрузке, например, от OAM 11 RAN (см. фиг. 1). Отчет 510 о перегрузке может относиться к информации о перегрузке на плоскости пользователя RAN (RUCI), см. TS 23.705 3GPP, версия 0.10.0 от мая 2014 г. Например, отчет 510 о перегрузке может позволять определять, испытывает ли данное UE 400-1-400-8 перегрузку в соответствующей RAN 10. Точнее, отчет 510 о перегрузке может указывать, испытывает ли перегрузку eNB в RAN 10. На основе списка UE 400-1-400-8, ассоциированных с eNB, RCAF 200 может определить, что данное UE 400-1-400-8 испытывает перегрузку в RAN 10. Например, список UE 400-1-400-8, ассоциированных с eNB, можно принять по интерфейсу Nq от MME 20 - для технологии UMTS, соответственно, по интерфейсу Nqʹ от SGSN.

Другими словами, RCAF 200 определяет, испытывает ли перегрузку данное UE 400-1-400-8 в соответствующей RAN 10. Извлечение идентификатора PCRF 100 происходит в ответ на прием отчета 510 о перегрузке.

В простом сценарии RCAF 200 уже знает об идентификаторе 413 PCRF 100, с которой ассоциируется данное UE 400-1-400-8. Например, такая информация может предоставляться в базе 230 данных. Тогда идентификатор 413 PCRF 100 можно легко извлечь из базы 230 данных. В таком сценарии возможно, что RCAF 200 агрегирует информацию о перегрузке данного UE 400-1-400-8 на основе идентификатора 413 PCRF 100 в соответствующем сообщении 411-1-411-3, адресованном PCRF 100.

Вообще возможно, что отправка сообщения 411-1-411-3 применяет извлеченный идентификатор 413 PCRF 100 для маршрутизации сообщения 411-1-411-3 к PCRF 100. Маршрутизация может происходить напрямую, например, применяя в качестве идентификатора 413 имя DNS и/или IP-адрес у PCRF 100. При применении имени DNS у PCRF 100 можно выполнить DNS-поиск, чтобы отобразить имя DNS у PCRF 100 в соответствующий IP-адрес у PCRF 100. Маршрутизация также может происходить косвенно через DRA 600, например, путем применения в качестве идентификатора 413 логического имени PCRF 100. Также можно применять логическое имя PCRF 100 для маршрутизации сообщения 411-1-411-3 напрямую к PCRF 100. В таком сценарии можно локально хранить, например, в базе 230 данных таблицу отображения, которая может использоваться RCAF 200 для отображения логического имени в адрес маршрутизации PCRF 100, например, в имя DNS и/или IP-адрес. В качестве альтернативы в таком сценарии также можно применять DRA 600 для маршрутизации сообщения к PCRF 100.

Во всех таких сценариях можно добавить идентификатор сеанса к идентификатору 413 PCRF 100, используемому для сообщений 411-1-411-3. Другими словами, возможно, что PCRF 100 создает несколько сеансов для отправки сообщений 411-1-411-3 от RCAF 200 к PCRF 100. Причиной этого могло бы быть использование методик балансирования нагрузки в PCRF 100. Возможно, что данная PCRF 100 организована из нескольких блоков обработки, и для PCRF 100 эффективнее использовать разные идентификаторы сеансов для разных блоков обработки. На основе идентификатора сеанса у входящего сообщения 411-1-411-3, включающего в себя агрегированную информацию 415 о перегрузке, PCRF 100 может направлять сообщение 411-1-411-3 подходящему блоку обработки. Также несколько идентификаторов сеансов могут помочь реализовать параллельную обработку сообщения 411-1-411-3 в PCRF 100.

В сценарии из фиг. 5 предполагается, что RCAF 200 заранее знает идентификатор 413 у PCRF 100, с которой ассоциируется данное UE 400-1-400-8. Даже в таком случае может требоваться согласование возможности агрегирования и/или параметров агрегирования с PCRF 100. В этой связи, как проиллюстрировано на фиг. 5, RCAF 200 может конфигурироваться для отправки сообщения-запроса 501 (этап S502), включающего в себя соответствующий флаг, указывающий возможность агрегировать информацию 415 о перегрузке у RCAF 200. Сообщение-запрос 501 может включать в себя идентификатор 414 данного UE 400-1-400-8. Далее на этапе S503 RCAF 200 может конфигурироваться для приема сообщения-ответа 502, который включает в себя идентификатор 413 PCRF 100, которая ассоциируется с данным UE 400-1-400-8. Кроме того, может включаться указание, что PCRF 100 также поддерживает агрегирование информации 415 о перегрузке. В сценарии из фиг. 5 RCAF 200 конфигурируется для отправки сообщения-запроса 501 на этапе S502 непосредственно к PCRF 100 и дополнительно конфигурируется для приема сообщения-ответа 502 на этапе S503 непосредственно от PCRF 100. Это можно осуществить, потому что RCAF 200 заранее знает идентификатор 413 у PCRF 100. Не нужно применять DRA 600 в качестве агента маршрутизации.

В сценарии, где RCAF 200 не знает заранее идентификатор 413 у PCRF 100, может потребоваться извлечение идентификатора 413 у PCRF 100 перед отправкой сообщения 411-1-411-3 из дополнительного объекта сети 1 мобильной связи. В принципе, существуют различные возможные сценарии для реализации извлечения идентификатора 413 у PCRF 100 из дополнительного объекта сети мобильной связи. В частности, ссылаясь на сценарий из фиг. 6, возможно, что RCAF 200 конфигурируется для отправки к DRA 600 сообщения-запроса 501 (этап 602) и приема от DRA 600 сообщения-ответа 502, включающего в себя идентификатор 413 у PCRF 100 (этап S603). В таком сценарии не требуется вовлекать PCRF 100 в извлечение идентификатора 413 PCRF 100. Здесь DRA 600 работает в так называемом режиме переадресации. Также возможно, что DRA 600 работает в так называемом режиме посредника. Здесь DRA 600 перенаправил бы к PCRF 100 сообщение-запрос 501 или сообщение на основе сообщения-запроса 501. Тогда PCRF 100 могла бы отправить сообщение-ответ 502, включающий в себя идентификатор 413 PCRF 100, через DRA 600 к RCAF 200. Хотя в таком сценарии одной целью сообщения-запроса 501 является прием сообщения-ответа 502, включающего в себя идентификатор 413 PCRF 100, можно, кроме того, согласовывать возможности агрегирования и/или параметры агрегирования, применяя сообщение-запрос 501 и/или сообщение-ответ 502. На этапе S604 извлеченный идентификатор 413 PCRF 100 сохраняется в базе 230 данных в RCAF 200. Как только RCAF 200 принимает дополнительный отчет 510 о перегрузке для данного UE 400-1-400-8 (не показано на фиг. 6), можно извлечь идентификатор 413 PCRF 100 из базы 230 данных способом, который объяснялся выше в связи с фиг. 5; в частности, в таком случае может быть не нужно отправлять сообщение-запрос 501 и/или принимать сообщение-ответ 502, посредством этого повышая эффективность отправки сообщения 411-1-411-3, включающего в себя информацию о перегрузке для данного UE 400-1-400-8.

В сценариях фиг. 5 и 6 на этапах S504, S604 агрегируется управляющая информация 415. На этапах S505, S605 сообщение 411-1-411-3 отправляется к PCRF 100. Это сообщение включает в себя информацию 415 о перегрузке для данного UE 400-1-400-8, полученную из отчета 510 о перегрузке на этапах S501, S601. Оно агрегирует дополнительную информацию 415 о перегрузке. Как видно из сравнения фиг. 5 и 6, хотя на этапе S505 из фиг. 5 сообщение 411-1-411-3 отправляется непосредственно к PCRF 100, то есть без применения DRA 600, также можно применять DRA 600 при отправке сообщения 411-1-411-3 (этап S605, фиг. 6). Например, если в качестве идентификатора 413 извлекается логическое имя PCRF 100, то RCAF 200 может использовать локально сконфигурированную таблицу отображения, предусмотренную в базе 230 данных, для отображения логического имени в IP-адрес и/или имя DNS у PCRF 100. В таком случае может применяться прямая маршрутизация сообщения 411-1-411-3 к PCRF 100 (см. фиг. 5). В качестве альтернативы или дополнительно DRA 600 может применяться для маршрутизации сообщения 411-1-411-3 к PCRF 100 на основе логического имени.

На фиг. 6 дополнительно проиллюстрирован необязательный этап S606. На этапе S606 PCRF 100 отправляет к RCAF 200 сообщение 620 о результате. Сообщение 620 о результате может использоваться для подтверждения успешного приема сообщений 411-1-411-3 посредством PCRF 100. Сообщение 620 о результате в качестве альтернативы или дополнительно может применяться для передачи результата обработки сообщения 411-1-411-3 процессором 120 из PCRF 100; например, может включаться код успеха дезагрегирования и/или ошибки. Коды успеха и/или ошибки могут быть адресованы всему сообщению 411-1-411-3, то есть всей информации 415 о перегрузке, включенной в сообщение 411-1-411-3; также возможно, что коды успеха или ошибки адресованы индивидуальной информации 415 о перегрузке данного UE 400-1-400-8.

Кроме того, со ссылкой на фиг. 6 показан сценарий DRA 600, предоставляющего RCAF 200 идентификатор 413 у PCRF 100. Такой сценарий описывается в Технических спецификациях (TS) 29.213 3GPP, выпуск 12, версия 12.4.0, раздел 7.3.4.1. Клиент, здесь RCAF 200, принимает идентификатор 413 PCRF 100 в паре атрибут-значение (AVP) хоста переадресации в ответе переадресации, как задано в TS 29.213 3GPP, раздел 7.3.4.1, когда DRA 600 работает в режиме переадресации. RCAF 200 принимает идентификатор 413 PCRF 100 в AVP хоста источника в ответе Diameter, как задано в TS 29.213 3GPP, раздел 7.4.1.1, когда DRA 600 работает в режиме посредника. RCAF 200 сохраняет идентификатор 413 PCRF 100 в базе 230 данных. Тогда возможно позднее извлечь идентификатор 413 из базы 230 данных и применить идентификатор 413 в качестве AVP хоста адресата в последующих сообщениях 411-1-411-3. Существует возможность, что последующие сообщения 411-1-411-3 включают в себя агрегированную информацию о перегрузке для PCRF 100, посредством этого обходя DRA 600, как задано в базовом протоколе Diameter RFC 6733 IETF и TS 29.213 3GPP, фиг. 7.4.1.1.1.1. Как правило, AVP хоста адресата включает в себя сущность Diameter, которая идентифицирует хост в виде полного доменного имени (FQDN). Если узел Diameter имеет несколько FQDN, то выбирается одна из них.

Как показано выше, вообще возможно, что отправленный RCAF 200 сообщение-запрос 501 включает в себя идентификатор 414 данного UE 400-1-400-8; также возможно, что принятое RCAF 200 сообщение-ответ 502 включает в себя идентификатор 413 PCRF 100, ассоциированной с данным UE 400-1-400-8. При необходимости также можно, чтобы сообщение-запрос 501 включало в себя индикатор, указывающий возможность RCAF 200 отправлять сообщение 411-1-411-3, включающее в себя агрегированную информацию 415 о перегрузке, для множества UE 400-1-400-8. Также возможно, что сообщение-ответ 502 включает в себя индикатор, указывающий возможность PCRF 100 принимать сообщение 411-1-411-3, включающее в себя агрегированную информацию 415 о перегрузке. С помощью такого средства можно предварительно согласовывать возможность RCAF 200 и PCRF 100 поддерживать агрегированную информацию 415 о перегрузке.

Хотя на фиг. 5 и 6, которые показаны выше, сообщение-запрос 501 и сообщение-ответ 502 в основном применяются, во-первых, для извлечения идентификатора 413, а во-вторых, для согласования возможностей и/или параметров агрегирования, ниже объясняется дополнительный вариант осуществления, относящийся к сообщению-запросу 501 и сообщению-ответу 502. Рассматривается случай, где RCAF 200 заранее не знает об идентификаторе 413 PCRF 100, с которой ассоциируется данное UE 400-1-400-8. Тогда в ответ на прием отчета 510 о перегрузке для данного UE 400-1-400-8 возможно, что RCAF 200 включает информацию 415 о перегрузке в сообщение-запрос 502. То есть сообщение-запрос 501 применяется, в-третьих, для передачи информации 415 о перегрузке для UE 400-1-400-8, для которого не доступны сведения о соответствующем идентификаторе 413 ассоциированной PCRF 100. Например, DRA 600 может маршрутизировать сообщение-запрос 501 к подходящей PCRF 100 на основе идентификатора 414 данного UE 400-1-400-8, например IMSI и/или APN. Вообще, если имеется несколько PCRF 100, ассоциированных с данным UE 400-1-400-8, то можно маршрутизировать сообщение-запрос 501 к подходящей PCRF 100 в зависимости от APN.

Тогда возможно, как объяснялось выше, что PCRF 100 отвечает путем отправки сообщения-ответа 502, включающего в себя идентификатор 413 PCRF 100. Этот идентификатор 413 PCRF 100 может позднее применяться RCAF 200, во-первых, для управления агрегированием информации 415 о перегрузке для данного UE 400-1-400-8, а во-вторых, для маршрутизации сообщения 411-1-411-3, включающего в себя агрегированную информацию 415 о перегрузке, к PCRF 100. Тогда последующая информация 415 о перегрузке для данного UE 400-1-400-8 агрегируется в сообщение 411-1-411-3. С этой целью RCAF 200 конфигурируется для хранения идентификатора 413 PCRF 100 в базе 230 данных. Как видно, в предложенном сценарии начальное сообщение, то есть сообщение-запрос 501, включающий в себя информацию 415 о перегрузке для данного UE 400-1-400-8, отправляется без агрегирования. То есть начальное сообщение, здесь сообщение-запрос 501, не включает в себя никакую информацию 415 о перегрузке для UE 400-1-400-8, кроме данного UE 400-1-400-8. Сообщение-запрос 501 маршрутизируется посредством DRA 600 к подходящей PCRF 100, идентификатор 413 которой заранее неизвестен RCAF 200. Как только обнаруживается PCRF 100, RCAF 200 уведомляют об используемом идентификаторе 413 у PCRF 100, и RCAF 200 сохраняет идентификатор 413 в соответствующем контексте данного UE 400-1-400-8. Последующие сообщения от RCAF 200 к PCRF 100, включающие в себя информацию 415 о перегрузке для данного UE 400-1-400-8, агрегируются и предпочтительно маршрутизируются напрямую к PCRF 100, используя идентификатор 413, сохраненный в контексте данного UE 400-1-400-8.

На фиг. 7 иллюстрируется блок-схема алгоритма способа отправки информации 415 о перегрузке множеству UE 400-1-400-8, ассоциированных с конкретной PCRF 100. На этапе S701 информация 415 о перегрузке агрегируется по меньшей мере для некоторых из множества UE 400-1-400-8. Это происходит в зависимости от UE 400-1-400-8, ассоциируемых с данной PCRF 100. То есть, если определяется, что данное UE ассоциируется (не ассоциируется) с данной PCRF 100, то соответствующая информация 415 о перегрузке для данного UE 400-1-400-8 может включаться (не включаться) в сообщение 411-1-411-3.

Далее на этапе S702 к PCRF 100 отправляется сообщение 411-1-411-3, включающее в себя агрегированную информацию 415 о перегрузке по меньшей мере для некоторых из множества UE 400-1-400-8.

На фиг. 8 блок-схема последовательности операций иллюстрирует способ приема сообщения 411-1-411-3, включающего в себя агрегированную информацию 415 о перегрузке. На этапе S801 PCRF 100 конфигурируется для приема сообщения 411-1-411-3. Затем PCRF 100 может дезагрегировать сообщение 411-1-411-3, посредством этого получая доступ к индивидуальной информации 415 о перегрузке для различных UE 400-1-400-8. При необходимости PCRF 100 может отправить RCAF 200 сообщение 620 о результате.

На фиг. 9 показана блок-схема последовательности операций способа отправки информации 415 о перегрузке для множества UE 400-1-400-8 в соответствии с различными вариантами осуществления. Способ начинается с этапа S901. Сначала на этапе S901 принимается отчет 510 о перегрузке для данного UE 400-1-400-8. Далее на этапе S902 извлекается идентификатор 413 соответствующей PCRF 100, ассоциированной с данным UE 400-1-400-8. Возможно включить информацию 415 о перегрузке, относящуюся к отчету 510 о перегрузке, который принят на этапе S901, как часть сообщения-запроса 501, отправленного в течение этапа S902 от RCAF 200 к PCRF 100.

Далее на этапе S903 агрегируется информация 515 о перегрузке для UE 400-1-400-8, ассоциированных с PCRF 100. Это включает в себя агрегирование информации 415 о перегрузке для данного UE 400-1-400-8. Далее на этапе S904 сообщение 411-1-411-3, включающее в себя агрегированную информацию 415 о перегрузке с этапа S903, отправляется от RCAF 200 к PCRF 100.

На фиг. 10 подробнее показан этап S903, то есть этап агрегирования информации 415 о перегрузке для конкретной данной PCRF 100. В частности, как упоминалось выше, возможно, что агрегирование информации 415 о перегрузке дополнительно основывается по меньшей мере на одном из следующего: задержка между приемом отчета 510 о перегрузке и отправкой сообщения 411-1-411-3; и максимальный размер сообщения 411-1-411-3. Способ начинается на этапе S1001. Далее на этапе S1002 проверяется, принимается ли новый отчет 510 о перегрузке для данного UE 400-1-400-8. Отчет 510 о перегрузке позволяет RCAF 200 подготовить соответствующую информацию 415 о перегрузке для данного UE 400-1-400-8. Если на этапе S1002 принимается соответствующий отчет 510 о перегрузке, то способ начинается с этапа S1004. На этапе S1004 проверяется, ассоциируется ли данное UE 400-1-400-8, для которого принимается отчет 510 о перегрузке, с данной PCRF 100. Для этого процессор 220 в RCAF 200 может конфигурироваться для обращения к базе 230 данных, чтобы проверить, предоставляется ли идентификатор 413 PCRF 100, ассоциированной с UE 400-1-400-8, в контексте данного UE 400-1-400-8. Затем проверяется, совпадает ли этот идентификатор 413 с идентификатором 413 данной PCRF 100. Если это так, то на этапе S1005 информация 415 о перегрузке добавляется в очередь агрегирования буферизованной информации о перегрузке. В противном случае способ заканчивается на этапе S1008; в таком случае для дополнительных PCRF 100, отличных от данной PCRF 100, соответствующий способ можно исполнить повторно.

На этапе S1006 проверяется, превышает ли агрегированная информация о перегрузке предопределенную пороговую величину. Другими словами, на этапе S1006 проверяется, достигнут ли максимальный размер сообщения 411-1-411-3, для которого предоставляется буферизованная информация 415 о перегрузке. Если это так, то на этапе S1007 сообщение 411-1-411-3 отправляется к PCRF 100. Однако если на этапе S1006 не достигнут максимальный размер сообщения 411-1-411-3, то способ начинается с этапа S1002.

На этапе S1003 проверяется, превышает ли задержка буферизованной информации 415 о перегрузке (см. этап S1005) предопределенное пороговое время. Если это так, то на этапе S1007 отправляется сообщение 411-1-411-3. Как правило, самая давняя буферизованная информация 415 о перегрузке будет инициировать отправку сообщения посредством этапов S1003, S1007. Однако в принципе возможно, что разные UE 400-1-400-8 ассоциируются с разными задержками. В противном случае способ начинается с этапа S1002.

Путем реализации методов в соответствии с фиг. 10 можно реализовать компромисс между увеличенным размером сообщения и увеличенной задержкой при отправке информации 415 о перегрузке, с одной стороны; и уменьшенным количеством сообщений, отправленных по интерфейсу Np между RCAF 200 и PCRF 100, с другой стороны. Как видно из вышеизложенного, RCAF 200 может использовать сведения об идентификаторе 413 PCRF 100, ассоциированной с данным UE 400-1-400-8, чтобы агрегировать соответствующую информацию 415 о перегрузке в одно сообщение 411-1-411-3 (см. этап S1004 и этап S1005 из фиг. 10). RCAF 200 выбирает информацию 415 о перегрузке, которая предназначена данной PCRF 100, на основе идентификатора 413 соответствующей PCRF 100. Однако обычно не нужно, чтобы вся информация 415 о перегрузке, ассоциированная с одним и тем же идентификатором 413 данной PCRF 100, агрегировалась в одно сообщение 411-1-411-3. Одной из причин могли бы быть ограничения размера сообщения (см. этап S1006 из фиг. 10), которые описаны выше, что может привести к нескольким сообщениям.

Дополнительной причиной для отправки нескольких сообщений посредством RCAF 200 могло бы быть ограничение задержки. Данные OAM, то есть отчет 510 о перегрузке, могут поступать в RCAF 200 периодически, и данные для некоторых сот или eNB могут поступать раньше, чем для других eNB. Аналогичным образом информация о наборе UE 400-1-400-8 в расчете на соту или eNB также может поступать в RCAF 200 периодически и с разными фазами. RCAF 200 может конфигурироваться с максимальным периодом времени, в течение которого исполняется агрегирование информации 415 о перегрузке в одно сообщение 411-1-411-3 (см. этап S1003 на фиг. 10). Это препятствует тому, что RCAF 200 вызывает слишком большую дополнительную задержку и отправляет информацию 415 о перегрузке для агрегирования. Частным случаем является то, что RCAF 200 агрегирует информацию 415 о перегрузке только для одной соты или eNB. Как только информация для одной соты или eNB собрана в сообщение 411-1-411-3, это сообщение 411-1-411-3 отправляется, предотвращая любую дополнительную задержку из-за агрегирования сообщений. Как правило, возможно, что агрегирование информации 415 о перегрузке дополнительно основывается на ассоциации между UE 400-1-400-8 и сотой в RAN.

Как станет понятно, выше показаны методы, которые позволяют агрегировать информацию 415 о перегрузке для различных UE 400-1-400-8, ассоциированных с данной PCRF 100. Поскольку UE 400-1-400-8 обычно остаются присоединенными к сети 1 мобильной связи длительные периоды времени, и во многих случаях RCAF 200 обычно также не меняется длительные периоды времени, может быть много изменений уровня перегрузки, если UE 400- - 400-8 остается присоединенным к данной RCAF 200. Поскольку этот подход в соответствии с методами, которые объяснялись выше, может привнести оптимизацию сигнала при первом или втором изменении уровня перегрузки у данного UE 400-1-400-8, то есть, как только RCAF 200 известен идентификатор 413 ассоциированной PCRF 100, методики позволяют значительно уменьшить нагрузку по сигнализации на интерфейс Np. Вместе с тем можно повторно использовать функциональные возможности DRA 600 для нахождения PCRF 100, ассоциированной с данным UE 400-1-400-8. Последнее упрощает работу сети 1 мобильной связи и улучшает гибкость развертывания.

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

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

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

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

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

1. Способ отправки информации о перегрузке (415) для множества мобильных объектов (400-1-400-8) блоку управления политикой (100, 100-1-100-3) в сети мобильной связи (1), причем каждый из множества мобильных объектов (400-1-400-8) подключается к соответствующей сети радиодоступа (10) в сети мобильной связи (1) и ассоциируется с блоком управления политикой (100, 100-1-100-3), информация о перегрузке (415) указывает перегрузку соответствующей сети радиодоступа (10),

способ содержит этапы в блоке контроля перегрузок (200), на которых:

- извлекают идентификатор (413) блока управления политикой (100, 100-1-100-3), причем упомянутое извлечение идентификатора (413) блока управления политикой (100, 100-1-100-3) содержит этапы, на которых:

- отправляют блоком контроля перегрузок (200) сообщение-запрос (501), включающее в себя идентификатор (414) данного мобильного объекта (400-1-400-8) в множестве мобильных объектов (400-1-400-8), и

- принимают блоком контроля перегрузок (200) сообщение-ответ (502), включающее в себя идентификатор (413) блока управления политикой (100, 100-1-100-3), ассоциированного с данным мобильным объектом (400-1-400-8),

- агрегируют информацию о перегрузке (415) по меньшей мере для некоторых из множества мобильных объектов (400-1-400-8) на основе соответствующих мобильных объектов (400-1-400-8), ассоциируемых с блоком управления политикой (100, 100-1-100-3), и

- отправляют сообщение (411-1, 411-3), включающее в себя агрегированную информацию о перегрузке (415), блоку управления политикой (100, 100-1-100-3), причем упомянутая отправка сообщения (411-1, 411-3) применяет извлеченный идентификатор (413) блока управления политикой (100, 100-1-100-3) для маршрутизации сообщения (411-1, 411-3) блоку управления политикой (100, 100-1-100-3).

2. Способ по п. 1,

причем способ дополнительно содержит этап, на котором:

принимают блоком контроля перегрузок (200) отчет о перегрузке (510), который позволяет определять, испытывает ли данный мобильный объект (400-1-400-8) в множестве мобильных объектов (400-1-400-8) перегрузку в соответствующей сети радиодоступа (10),

причем упомянутый этап, на котором извлекают идентификатор (413) блока управления политикой (100, 100-1-100-3), является ответом на упомянутый этап, на котором принимают отчет о перегрузке (510).

3. Способ по п. 1 или 2,

причем сообщение-запрос (501) не агрегируется и включает в себя информацию о перегрузке (415) только для данного мобильного объекта (400-1-400-8), а не для каких-либо дополнительных мобильных объектов (400-1-400-8).

4. Способ по п. 1,

причем сообщение-запрос (501) включает в себя индикатор, указывающий возможность блока контроля перегрузок (200) отправлять сообщение (411-1, 411-3), включающее в себя агрегированную информацию о перегрузке (415) по меньшей мере для некоторых из множества мобильных объектов (400-1-400-8),

причем сообщение-ответ (502) включает в себя индикатор, указывающий возможность блока управления политикой (100, 100-1-100-3) принимать сообщение (411-1, 411-3), включающее в себя агрегированную информацию о перегрузке (415), по меньшей мере, для некоторых из множества мобильных объектов (400-1-400-8).

5. Способ по п. 1,

причем идентификатор (413) блока управления политикой (100, 100-1-100-3) является по меньшей мере одним из адреса по Интернет-протоколу IP или имени по системе доменных имен, DNS,

причем упомянутый этап, на котором отправляют сообщение (411-1, 411-3), включает в себя этап, на котором маршрутизируют сообщение (411-1, 411-3) напрямую к блоку управления политикой (100, 100-1-100-3) на основе по меньшей мере одного из IP-адреса или имени DNS у блока управления политикой (100, 100-1-100-3).

6. Способ по п. 1,

причем способ дополнительно содержит этапы, на которых:

- в ответ на упомянутый этап, на котором извлекают идентификатор (413) блока управления политикой (100, 100-1-100-3), добавляют запись в базу данных (230), причем запись связывает идентификатор (414) данного мобильного объекта (400-1-400-8) с идентификатором (413) блока управления политикой (100, 100-1-100-3),

- перед упомянутым этапом, на котором отправляют сообщение (411-1, 411-3) блоку управления политикой (100, 100-1-100-3), выборочно добавляют информацию о перегрузке (415) для данного мобильного объекта (400-1-400-8) из множества мобильных объектов (400-1-400-8) в сообщение (411-1, 411-3) в зависимости от соответствующей записи в базе данных (230).

7. Способ по п. 1,

в котором упомянутый этап, на котором агрегируют информацию о перегрузке (415), дополнительно основывается по меньшей мере на одном из следующего: задержки между приемом отчета о перегрузке (510) и отправкой сообщения (411-1, 411-3); максимального размера сообщения (411-1, 411-3); и идентификатора сеанса, ассоциированного с данным мобильным объектом (400-1-400-8) и принятого ранее от блока управления политикой (100, 100-1-100-3), при этом идентификатор сеанса идентифицирует ресурсы обработки у соответствующего объекта управления политикой (100, 100-1-100-3).

8. Способ по п. 7,

причем способ дополнительно содержит этап, на котором:

- перед упомянутым этапом, на котором агрегируют, согласуют посредством блока контроля перегрузок (200) максимальный размер с блоком управления политикой (100, 100-1-100-3).

9. Блок (200) контроля перегрузок, сконфигурированный для отправки информации (415) о перегрузке для множества мобильных объектов (400-1-400-8) блоку (100, 100-1-100-3) управления политикой в сети мобильной связи (1), причем каждый из множества мобильных объектов (400-1-400-8) подключается к соответствующей сети радиодоступа (10) в сети мобильной связи (1) и ассоциируется с блоком (100, 100-1-100-3) управления политикой, информация (415) о перегрузке указывает перегрузку соответствующей сети радиодоступа (10),

причем блок (200) контроля перегрузок содержит:

- процессор (220), сконфигурированный для агрегирования информации (415) о перегрузке по меньшей мере для некоторых из множества мобильных объектов (400-1-400-8) на основе соответствующих мобильных объектов (400-1-400-8), ассоциируемых с блоком управления политикой (100, 100-1-100-3),

- процессор (220), сконфигурированный для извлечения идентификатора (413) блока (100, 100-1-100-3) управления политикой, причем процессор (220) конфигурируется, как часть извлечения идентификатора (413) блока управления (100, 100-1-100-3) политикой, для управления интерфейсом (210), чтобы отправить сообщение-запрос (501), включающее в себя идентификатор (414) данного мобильного объекта (400-1-400-8) в множестве мобильных объектов (400-1-400-8), объекту (600) базы данных маршрутизации, и для приема от объекта (600) базы данных маршрутизации сообщения-ответа (502), включающего в себя идентификатор (413) блока (100, 100-1-100-3) управления политикой, ассоциированного с данным мобильным объектом (400-1-400-8),

- интерфейс (210), сконфигурированный для отправки сообщения (411-1, 411-3), включающего в себя агрегированную информацию (415) о перегрузке, блоку (100, 100-1-100-3-) управления политикой, где интерфейс (210) дополнительно конфигурируется для отправки сообщения (411-1, 411-3) путем применения извлеченного идентификатора (413) блока (100, 100-1-100-3) управления политикой для маршрутизации сообщения (411-1, 411-3) к блоку (100, 100-1-100-3) управления политикой.

10. Блок (200) контроля перегрузок по п. 9,

причем интерфейс (210) дополнительно конфигурируется для приема отчета (510) о перегрузке, который позволяет определять, испытывает ли данный мобильный объект (400-1-400-8) в множестве мобильных объектов (400-1-400-8) перегрузку в соответствующей сети радиодоступа (10),

причем процессор (220) конфигурируется для извлечения идентификатора (413) блока 100, 100-1-100-3) управления политикой в ответ на упомянутый прием отчета (510) о перегрузке.

11. Блок (200) контроля перегрузок по п. 9 или 10,

в котором сообщение-запрос (501) не агрегируется и включает в себя информацию (415) о перегрузке только для данного мобильного объекта (400-1-400-8), а не для каких-либо дополнительных мобильных объектов (400-1-400-8).

12. Блок (200) контроля перегрузок по п. 9,

причем сообщение-запрос (501) включает в себя индикатор, указывающий возможность блока (200) контроля перегрузок отправлять сообщение (411-1, 411-3), включающее в себя агрегированную информацию (415) о перегрузке по меньшей мере для некоторых из множества мобильных объектов (400-1-400-8),

причем сообщение-ответ (502) включает в себя индикатор, указывающий возможность блока (100, 100-1-100-3) управления политикой принимать сообщение (411-1, 411-3), включающее в себя агрегированную информацию (415) о перегрузке по меньшей мере для некоторых из множества мобильных объектов (400-1-400-8).

13. Блок (200) контроля перегрузок по п. 9,

причем идентификатор (413) блока (100, 100-1-100-3) управления политикой является по меньшей мере одним из адреса по Интернет-протоколу IP или имени по системе доменных имен, DNS,

причем интерфейс (210) конфигурируется, как часть упомянутой отправки сообщения (411-1, 411-3), для маршрутизации сообщения (411-1, 411-3) напрямую к блоку (100, 100-1-100-3) управления политикой на основе по меньшей мере одного из IP-адреса или имени DNS у блока (100, 100-1-100-3) управления политикой.

14. Блок (200) контроля перегрузок по п. 9,

причем в ответ на упомянутое извлечение идентификатора (413) блока (100, 100-1-100-3) управления политикой процессор (220) дополнительно конфигурируется для добавления записи в базу данных (230), причем запись связывает идентификатор (414) данного мобильного объекта (400-1-400-8) с идентификатором (413) блока (100, 100-1-100-3) управления политикой,

причем перед упомянутой отправкой сообщения (411-1, 411-3) блоку (100, 100-1-100-3) управления политикой процессор (220) дополнительно конфигурируется для выборочного добавления информации (415) о перегрузке для данного мобильного объекта (400-1-400-8) в сообщение (411-1, 411-3) в зависимости от соответствующей записи в базе данных (230).

15. Блок (200) контроля перегрузок по п. 9,

причем процессор (220) дополнительно конфигурируется для агрегирования информации о перегрузке (415) для сообщения (411-1, 411-3) в зависимости по меньшей мере от одного из следующего: задержки между приемом отчета о перегрузке (510) и отправкой сообщения (411-1, 411-3); максимального размера сообщения (411-1, 411-3); и идентификатора сеанса, ассоциированного с данным мобильным объектом (400-1-400-8) и принятого ранее от блока (100, 100-1-100-3) управления политикой, при этом идентификатор сеанса идентифицирует ресурсы обработки у соответствующего объекта (100, 100-1-100-3) управления политикой.

16. Блок (200) контроля перегрузок по п. 9,

причем перед упомянутым агрегированием процессор (220) конфигурируется для управления интерфейсом (210), чтобы согласовать максимальный размер с блоком (100, 100-1-100-3) управления политикой.

17. Способ приема информации (415) о перегрузке для множества мобильных объектов (400-1-400-8) от блока (200) контроля перегрузок в сети мобильной связи (1), причем каждый из множества мобильных объектов (400-1-400-8) подключается к соответствующей сети радиодоступа (10) в сети мобильной связи (1) и ассоциируется с блоком (100, 100-1-100-3) управления политикой, информация (415) о перегрузке указывает перегрузку соответствующей сети радиодоступа (10),

способ содержит этапы, на которых:

- принимают блоком (100, 100-1-100-3) управления политикой сообщение-запрос (501) от блока (200) контроля перегрузок, причем сообщение-запрос (501) включает в себя информацию (415) о перегрузке для данного мобильного объекта (400-1-400-8),

- в ответ на упомянутый прием сообщения-запроса (501) отправляют блоком (100, 100-1-100-3) управления политикой сообщение-ответ (502), включающее в себя идентификатор (413) блока (100, 100-1-100-3) управления политикой,

- принимают блоком (100, 100-1-100-3) управления политикой сообщение (411-1, 411-3) от блока (200) контроля перегрузок, причем сообщение (411-1, 411-3) включает в себя агрегированную информацию (415) о перегрузке для множества мобильных объектов (400-1-400-8), ассоциированных с блоком (100, 100-1-100-3) управления политикой.

18. Способ по п. 17,

причем сообщение-запрос (501) включает в себя индикатор, указывающий возможность блока (200) контроля перегрузок отправлять сообщение (411-1, 411-3), включающее в себя агрегированную информацию (415) о перегрузке для множества мобильных объектов (400-1-400-8),

причем сообщение-ответ (502) включает в себя индикатор, указывающий возможность блока (100, 100-1-100-3) управления политикой принимать сообщение (411-1, 411-3), включающее в себя агрегированную информацию (415) о перегрузке.

19. Блок (100, 100-1-100-3) управления политикой, сконфигурированный для приема информации (415) о перегрузке для множества мобильных объектов (400-1-400-8) от блока (200) контроля перегрузок, причем каждый из множества мобильных объектов (400-1-400-8) подключается к соответствующей сети радиодоступа (10) в сети мобильной связи (1), информация (415) о перегрузке указывает перегрузку соответствующей сети радиодоступа (10),

при этом блок управления политикой (100, 100-1-100-3) содержит:

- интерфейс (110), сконфигурированный для приема сообщения-запроса (501) от блока (200) контроля перегрузок, причем сообщение-запрос (501) включает в себя информацию (415) о перегрузке для данного мобильного объекта (400-1-400-8), где в ответ на упомянутый прием сообщения-запроса (501) интерфейс (110) дополнительно конфигурируется для отправки сообщения-ответа (502), включающего в себя идентификатор (413) блока (100, 100-1-100-3) управления политикой, интерфейс (110) дополнительно конфигурируется для приема сообщения (411-1, 411-3) от блока (200) контроля перегрузок, причем сообщение (411-1, 411-3) включает в себя агрегированную информацию (415) о перегрузке для множества мобильных объектов (400-1-400-8), ассоциированных с блоком (100, 100-1-100-3) управления политикой.

20. Блок управления политикой (100, 100-1-100-3) по п. 19,

причем сообщение-запрос (501) включает в себя индикатор, указывающий возможность блока (200) контроля перегрузок отправлять сообщение (411-1, 411-3), включающее в себя агрегированную информацию (415) о перегрузке для множества мобильных объектов (400-1-400-8),

причем сообщение-ответ (502) включает в себя индикатор, указывающий возможность блока (100, 100-1-100-3) управления политикой принимать сообщение (411-1, 411-3), включающее в себя агрегированную информацию (415) о перегрузке.

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