КОНТРОЛЬ ПЕРЕГРУЗОК У МОБИЛЬНЫХ ОБЪЕКТОВ

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

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

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

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

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

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

Современные системы OAM RAN работают с пространственной детализацией до соты или ниже. Это означает, что определение перегрузки могло бы выполняться на основе соты или для группы сот (например, сот, принадлежащих одному и тому же eNB (eNode B) для LTE (система долгосрочного развития), или сот, принадлежащих одной и той же зоне обслуживания для 3G). Чтобы базовая сеть предприняла подходящее действие по уменьшению, базовой сети также нужно узнать, какие UE (пользовательское оборудование/мобильные объекты) располагаются в данной соте. Поэтому список затронутых UE нужно определять для сот, которые считаются перегруженными на основе данных OAM.

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

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

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

Одной из проблем с уведомлениями о перегрузке от RCAF к PCRF является обработка мобильности UE. В сети может быть несколько узлов RCAF, соответствующих некоторой географической области. Также может быть, что данная RCAF обрабатывает только один тип RAT (технология радиодоступа), например, только LTE или только 3G, и UE может переходить между RAT. В результате мобильности UE между разными RCAF PCRF может принимать уведомления от нескольких RCAF для данного UE, и не всегда можно узнать, что является самой последней информацией.

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

Во-вторых, RCAF может знать только о данном UE, если оно испытывает перегрузку. Для UE, которое не испытывает перегрузку, RCAF не может получить информацию для того UE посредством OAM или посредством Nq. Поэтому не исключено, что UE переходит от RCAF1 к RCAF2, UE испытывает перегрузку в RCAF1, но не испытывает перегрузку в RCAF2, поэтому RCAF2 не создает никакого указания перегрузки для PCRF. Это может приводить к тому, что PCRF неверно полагает, что UE испытывает перегрузку в RCAF1.

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

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

Известный уровень техники 1. В TR 23.705 3GPP версии 0.10.0 время действия ассоциируется с информацией, отправленной от RCAF к PCRF по интерфейсу Np. Устанавливается, что "Когда это время истекло, и никакая дополнительная информация о перегрузке не принята, предполагается, что перегрузка закончилась". Такое время действия может использоваться в PCRF для предотвращения того, что PCRF постоянно предполагает, что UE испытывает перегрузку, тогда как оно перешло к другой RCAF, где оно не испытывает перегрузку.

Известный уровень техники 2. В протоколах, обрабатывающих мобильность, общепринято использовать отметки времени, чтобы сигнализировать упорядочение событий на принимающем узле. Например, отметки времени могут использоваться как один из вариантов в протоколе мобильности PMIPv6 (RFC 5213 от августа 2008 г.).

Известный уровень техники 3. В протоколах, обрабатывающих мобильность, также общепринято использовать порядковые номера, чтобы сигнализировать упорядочение событий на принимающем узле. Например, порядковые номера могут использоваться как один из вариантов в протоколе мобильности PMIPv6 (RFC 5213).

Известный уровень техники 4. Процедура TAU (обновление зоны отслеживания) внутри LTE и передачи обслуживания между eNodeB с перемещением обслуживающего GW (шлюз, SGW) с интерфейсом S5 на основе PMIP (посреднический мобильный IP) задается в TS 23.402 3GPP версии 12.4.0, раздел 5.7.1. Эта процедура включает в себя сеанс Gxc (то есть сеанс управления GW), перемещенный со старого SGW на новый SGW. Этот сеанс Gxc завершается на PCRF, таким образом, сценарий аналогичен обработке мобильности в интерфейсе Np, поскольку конечной точкой является PCRF.

Известный уровень техники 5. В процедурах сигнализации между MME и HSS (сервер домашних абонентов) для мобильности (см., например, TR 23.401 3GPP версии 12.4.0, раздел 5.3.3.1, описывающий процедуру TAU) HSS отправляет к старому MME "Cancel location", когда принимает обновление мобильности ("Update location") от нового MME. Это используется для освобождения части контекстной информации в старом MME.

С описанными выше существующими решениями наблюдаются следующие проблемы.

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

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

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

Также отметим, что использование времени действия влияет на PCRF, поскольку в противном случае узел PCRF не работает по таймеру.

Известный уровень техники 2. Использование отметок времени в нашем случае проблематично. С одной стороны, между узлами RCAF отсутствует временная синхронизация. Но даже если мы могли бы использовать достаточно точную информацию о синхронизации, этого было бы недостаточно из-за длительной и непредсказуемой задержки при передаче данных на основе OAM. Как отмечалось раньше, возможно, что UE переходит от RCAF1 к RCAF2, помимо этого, передача информации о перегрузке происходит от RCAF2 раньше, чем от RCAF1. Так как RCAF использует передачу отчетов OAM с большой временной шкалой (например, передачу отчетов с 15-минутным периодом), у RCAF нет возможности определять местонахождение UE с меньшей временной шкалой. Поэтому недостаточно упорядочения по времени сигнальных сообщений от узлов RCAF к PCRF для определения упорядочения событий мобильности UE.

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

Известный уровень техники 4. Решение для известного уровня техники 4 включает в себя явное установление нового сеанса Gxc между новым SGW и PCRF и явное освобождение старого сеанса Gxc между старым SGW и PCRF. Процедура гарантирует, что всегда происходит установление нового сеанса, а также всегда происходит освобождение старого сеанса. Это возможно, поскольку процедура включает в себя явную передачу контекста от старого MME к новому MME, который, в свою очередь, управляет установлением и освобождением сеансов между SGW и PCRF. (Если MME не меняется, то один и тот же MME может управлять установлением и освобождением сеанса между SGW и PCRF). Этот подход в нашем случае не применяется, потому что отсутствует передача контекста или единый узел, который может управлять RCAF1 и RCAF2 при мобильности. Кроме того, в нашем случае новая RCAF может не обнаруживать UE, если оно не испытывает перегрузку, поэтому не может убедиться, что всегда устанавливается новый сеанс с PCRF.

Известный уровень техники 5. В существующих процедурах мобильности между MME и HSS сервер HSS безусловно отправляет сообщение "Cancel location" старому MME. Это возможно, поскольку существует передача контекста между новым и старым MME, которая гарантирует, что всегда отправляется указание от нового MME к HSS. В нашем случае не всегда можно отправить такое сообщение для освобождения старого контекста от PCRF к старой RCAF, потому что нет гарантии, что новая RCAF будет сигнализировать к PCRF. Кроме того, невозможно отправлять такое сообщение безусловно, потому что возможно, что узел RCAF указывает PCRF о переходе в состояние без перегрузки.

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

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

Эта потребность удовлетворяется признаками из независимых пунктов формулы изобретения. Зависимые пункты формулы изобретения описывают дополнительные варианты осуществления.

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

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

Блок управления политикой может работать, как описано выше, и блок управления политикой может быть PCRF.

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

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

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

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

Фиг. 2 - блок-схема блока управления политикой, показанного на фиг. 1.

Фиг. 3 - блок-схема блока контроля перегрузок, объединяющего признаки изобретения и показанного на фиг. 1.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Нижеследующее описание сосредоточено на RCAF 200 или некотором количестве RCAF 200 и PCRF 100 и взаимодействии между этими объектами, так как основные аспекты изобретения относятся к этим функциональным объектам.

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

Нижеследующие принципы используются на RCAF 200 и PCRF 100 для непосредственного определения, испытывает ли мобильный объект состояние перегрузки.

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

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

- Когда новая или другая RCAF 200 указывает, что мобильный объект испытывает перегрузку, PCRF 100 отправляет сообщение старой RCAF для явного освобождения информации о перегрузке, относящейся к упомянутому мобильному объекту, то есть освобождения контекста на старой RCAF.

- Когда PCRF 100 принимает от новой RCAF 200, которая могла бы быть любой из RCAF, сообщение, указывающее, что мобильный объект не испытывает перегрузку, это сообщение не принимается во внимание на PCRF 100.

- Когда PCRF 100 удаляет свой контекст UE при завершении сеанса IP-CAN, например, когда UE отсоединяется, PCRF 100 явно сигнализирует текущей RCAF 200 освободить контекст UE.

- RCAF 200, когда указано с помощью сигнализация PCRF, освобождает контекст мобильного объекта.

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

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

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

Поэтому можно сделать следующие выводы для обработки мобильности.

Вывод 1: Узел 200 RCAF не может различать, перешло ли UE, которое уже не испытывает перегрузку, к другой RCAF.

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

Вывод 3: Не может быть никакой процедуры передачи обслуживания от старой RCAF к новой RCAF, включающей в себя передачу контекста.

Изобретение использует тот принцип, что RCAF 200 сообщает изменения в состоянии перегрузки, так что она может избежать передачи отчета об одном и том же состоянии снова и снова. Таким образом, нагрузку по сигнализации можно уменьшить, и можно обойтись без таймера действия в интерфейсе Np.

Более того, возможна идея политик динамической передачи отчета или, другими словами, ограничений передачи отчета. Такие ограничения передачи отчета можно задавать на основе UE, и можно управлять тем, включена ли передача отчета о перегрузке для данного UE; и какие уровни перегрузки следует сообщать, когда включена передача отчета. Возможно избежать передачи отчета о некоторых уровнях перегрузки путем задания одного или нескольких наборов уровней перегрузки, так что RCAF указывает лишь, что UE испытывает некий уровень перегрузки в данном наборе, но не указывает сам уровень перегрузки. Набор обычно может содержать диапазон уровней перегрузки. Например, набор №1={"без перегрузки", перегрузка уровня 1}, и набор №2={перегрузка уровня 2, перегрузка уровня 3}; и тогда RCAF указывает только, испытывает ли UE уровень перегрузки в наборе №1 или наборе №2. (Наборы должны быть неперекрывающимися, так что данный уровень перегрузки может принадлежать только одному набору).

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

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

Для прояснения обработки UE в RCAF 200 информация, которую нужно хранить в PCRF 100, сохраняется на основе UE.

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

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

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

Другая информация также может включаться в контекст UE в RCAF 200.

Ниже обсуждаются разные сценарии мобильности мобильных объектов, в которых вышеупомянутые основные принципы в RCAF 200 или PCRF 100 помогают определять правильную информацию о мобильности.

С учетом вышеприведенных выводов 1, 2 и 3 обработка мобильности в интерфейсе Np должна работать без какой-либо прямой сигнализации и согласования между старым и новым узлами 200 RCAF. В большинстве случаев мобильность UE от старой RCAF к новой RCAF решается автоматически: когда UE начинает испытывать перегрузку в новой RCAF, она инициирует передачу отчета о перегрузке по Np для данного UE, что автоматически ставит PCRF 100 в известность об идентификаторе новой RCAF. Однако могут быть следующие проблематичные случаи.

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

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

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

В предложенном решении PCRF 100 и RCAF 200 соблюдают следующие правила.

Правила PCRF:

- PCRF 100 хранит текущую RCAF 200, которая указала последней, что UE испытывает перегрузку.

- Когда новая RCAF указывает, что UE испытывает перегрузку, PCRF 100 отправляет сообщение старой RCAF, чтобы явно освободить контекст на старой RCAF.

- Когда PCRF 100 принимает от новой RCAF сообщение, которое не указывает, что UE испытывает перегрузку, это сообщение не принимается во внимание на PCRF 100. Такое сообщение может быть сообщением, указывающим состояние "без перегрузки" для UE, или сообщением, указывающим набор уровней перегрузки для UE, который включает в себя состояние "без перегрузки", если используются ограничения передачи отчета. При приеме такого сообщения текущая RCAF остается без изменений; никакое сообщение освобождения контекста не отправляется к старой RCAF, и PCRF 100 предполагает предыдущее состояние перегрузки без его обновления до состояния без перегрузки. Однако сообщение может быть подтверждено для RCAF.

- Когда PCRF 100 удаляет свой контекст UE при завершении сеанса IP-CAN (например, когда UE отсоединяется), PCRF явно сигнализирует текущей RCAF освободить контекст UE.

Правила RCAF:

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

Отметим, что если UE начинает испытывать перегрузку снова после того, как освобожден контекст UE, то RCAF 200, как обычно, сообщает PCRF 100 изменение в состоянии перегрузки.

Фиг. 4 показывает пример обработки мобильности от первой RCAF, в дальнейшем называемой RCAF1, ко второй RCAF, в дальнейшем называемой RCAF2. На фиг. 4 RCAF1 имеет номер 200a ссылки, а RCAF2 имеет номер 200b ссылки. На этапе S41 RCAF1 200a сообщает PCRF 100 уровень A перегрузки, при этом PCRF 100 подтверждает прием информации о перегрузке для RCAF1 200a на этапе S42. На этапе S43 PCRF 100 сохраняет текущую RCAF, здесь RCAF1 200a, в качестве блока контроля перегрузок, который контролирует состояние перегрузки у мобильного объекта, о котором идет речь. С этой целью PCRF 100 может содержать базу данных, в которой хранятся разные блоки контроля перегрузок, которые в настоящее время сообщают состояния перегрузки по каждому UE. На этапе S44 вторая RCAF 200b сообщает уровень перегрузки, на этапе S45 PCRF 100 подтверждает принятую информацию о перегрузке. Затем на этапе S46 новая RCAF 200b заменяет первую сохраненную RCAF1 200a в списке базы данных (S46). Затем PCRF 100 передает старой RCAF1 200a сообщение освобождения, которое подтверждается на этапе S48, и контекстная информация освобождается на этапе S49 в старой RCAF1 200a.

На фиг. 5 показан вариант осуществления, где PCRF 100 определяет, что закончен сеанс пакетов данных у UE. На этапе S51 PCRF 100 определяет завершение сеанса IP CAN. На этапе S52 сообщение освобождения передается к RCAF 200, при этом RCAF является RCAF, которая в настоящее время хранится в списке на PCRF 100. RCAF 200 подтверждает принятое сообщение на этапе S53, и на этапе S54 контекст освобождается.

В варианте осуществления из фиг. 4 сообщение освобождения контекста на этапе S47 обеспечивает, что RCAF1 200a не отправляет никаких последующих сообщений, указывающих неперегруженное состояние на RCAF1 200a. Не исключено, что RCAF1 200a все же отправляет сообщение, указывающее состояние без перегрузки, до того, как принимает сообщение освобождения контекста. Однако на основе вышеупомянутых правил такое указание отсутствия перегрузки от RCAF1 200a не принимается во внимание на PCRF 100.

В случае фиг. 5 сообщение освобождения контекста к RCAF 200 обеспечивает, что RCAF 200 сигнализирует PCRF 100 еще раз, если мобильный объект возвращается к RCAF 200 и испытывает перегрузку.

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

Фиг. 2 и 3 иллюстрируют примерные структуры PCRF 100 или RCAF 200. Ссылаясь главным образом на фиг. 2, PCRF 100 содержит блок 110 ввода/вывода с передатчиком 111 и приемником 112. Передатчик 111 символизирует возможность PCRF 100 передавать данные другим объектам, приемник 112 принимает данные от других объектов. Блок 110 ввода/вывода используется для связи с любыми другими объектами, например RCAF 200, шлюзом 40 PDN, TDF 50 или PDN 60. PCRF 100 содержит базу 130 данных, в которой можно хранить информацию о том, какая RCAF сообщает состояния перегрузки для какого мобильного объекта. Как обсуждалось выше, PCRF 100 хранит текущий блок контроля перегрузок или RCAF, и если перегруженное состояние принимается от другой RCAF, то сохраненная в настоящее время RCAF заменяется новой RCAF, которая сообщила перегруженное состояние. Однако, как обсуждалось выше, RCAF сохраняется только тогда, когда новая RCAF сообщает перегруженное состояние, а не неперегруженное состояние. Предоставляется блок 120 обработки, содержащий один или несколько процессоров, который отвечает за работу PCRF 100. Блок обработки может формировать команды, которые нужны для осуществления обсуждаемых выше процедур, в которых участвует PCRF 100. Предоставляется запоминающее устройство 140, которое может быть постоянным запоминающим устройством, флэш-памятью, оперативным запоминающим устройством, массовой памятью, жестким диском или т. п. Запоминающее устройство 140 включает в себя подходящие программные коды для исполнения блоком 120 обработки, чтобы реализовать вышеописанные функциональные возможности.

Точно так же показанный на фиг. 3 RCAF 200 содержит блок 210 ввода/вывода для осуществления связи с другими объектами, среди прочего - показанными на фиг. 1 объектами, причем блок ввода/вывода содержит передатчик 211 и приемник 212. Передатчик 211 используется для передачи данных другим объектам, приемник используется для приема данных от других объектов. Предоставляется блок 220 обработки, включающий в себя один или несколько процессоров, который используется для работы RCAF 200. Блок 220 обработки приспособлен для инициирования рассмотренных выше функций, в которых участвует RCAF 200. Предоставляется запоминающее устройство 230, которое может быть постоянным запоминающим устройством, флэш-памятью, оперативным запоминающим устройством, массовой памятью, жестким диском или т. п., и запоминающее устройство 230 включает в себя подходящий программный код для исполнения блоком 220 обработки, чтобы реализовать вышеописанные функциональные возможности. Кроме того, запоминающее устройство может хранить ограничения передачи отчета на основе UE, которые подробнее обсуждаются ниже.

Следует понимать, что показанные на фиг. 2 и 3 структуры являются лишь схематическими, и что PCRF 100 или RCAF 200 фактически могут включать в себя дополнительные компоненты, которые не проиллюстрированы для ясности.

Также следует понимать, что разные показанные на фиг. 2 и 3 объекты не должны состоять из нескольких объектов. Кроме того, разные показанные на фиг. 2 и 3 объекты могут состоять из аппаратных средств или программного обеспечения либо сочетания аппаратных средств и программного обеспечения.

Фиг. 6 обобщает некоторые из этапов, осуществляемых на PCRF 100. На этапе S61 информация о перегрузке принимается от одной из RCAF, и на этапе S62 RCAF, от которой принимается информация о перегрузке или указание, сохраняется в качестве текущего блока контроля перегрузок/RCAF. Если на этапе S63 информация о перегрузке принимается от другой RCAF 200, то сохраненный в настоящее время блок контроля перегрузок/RCAF информируют, чтобы освободить информацию о перегрузке, относящуюся к мобильному объекту, о котором идет речь.

На фиг. 7 показан другой вариант осуществления, где PCRF сначала принимает информацию о перегруженном состоянии, а затем принимает информацию о неперегруженном состоянии. На этапе S71 и S72 информация о перегруженном состоянии принимается от одной из RCAF 200, и RCAF, от которой принимается информация, сохраняется, как обсуждалось выше по отношению к этапам S61 и S62.

На этапе S73 PCRF теперь принимает указание о неперегруженном состоянии посредством другой RCAF. PCRF может подтвердить это сообщение для RCAF, для которой принимается информация о неперегруженном состоянии (этап S74), но PCRF игнорирует эту информацию и не изменяет сохраненный в настоящее время блок контроля перегрузок (на этапе S75).

Фиг. 8 обобщает этапы, осуществляемые на RCAF 200. Когда RCAF на этапе S81 принимает указание освободить информацию о перегрузке или контекст мобильного объекта, информация о перегрузке или контекст освобождается на этапе S82, как указано от PCRF.

Ниже подробнее описывается возможность освободить контекст.

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

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

Ниже обсуждается ситуация, где сеть содержит несколько PCRF 100.

UE может подключаться к нескольким PDN (сети с коммутацией пакетов), идентифицированным разными APN (имя точки доступа). В том случае может отличаться PCRF 100, соответствующая этим разным соединениям PDN (контекстам PDP).

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

В качестве оптимизации можно реализовать вариант осуществления с объединенной обработкой таким образом, что сообщение освобождения контекста от одной PCRF 100 также освобождает контекст, соответствующий всем другим соединениям Np с другими PCRF. Такая оптимизация могла бы ускорить освобождение полного контекста в RCAF 200.

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

В случае UE, которое располагается на границе между областью двух RCAF, не исключено, что существует частая мобильность между RCAF1 и RCAF2, когда UE переходит туда и обратно между областями. Это может происходить, например, когда RCAF1 и RCAF2 соответствуют разным RAT (одна, например, для 3G, а другая для LTE), и UE движется возле границы зоны обслуживания одной из RAT. В этом случае решение может приводить к частой сигнализации из-за частого освобождения контекста на старой RCAF.

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

Описанные выше указания или сообщения, которыми обмениваются между PCRF 100 и RCAF 200, можно объединить в одно сообщение. Однако указание также можно включить в другое сообщение.

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