Агрегирование информации о перегрузке

Агрегирование информации о перегрузке

Иллюстрации

Показать все

Реферат

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

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

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

Трафик пакетных данных очень быстро растет в сетях мобильной связи или сетях операторов мобильной связи; во многих случаях он растет гораздо быстрее, нежели скорость, с которой операторы могут расширять пропускную способность сети. Это приводит к более частым возникновениям перегрузки в сети радиодоступа (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, вер