Способ и устройства для управления перегрузкой

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

 

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

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

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

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

Если маршрут BICC (управление вызовом с независимым носителем) перегружен, то возможно обрабатывать вызовы через альтернативную сеть TDM, поскольку в качестве альтернативы может быть выбран маршрут ISUP (ISDN плоскости пользователя) с TDM транспортом. Когда маршрут BICC в состоянии рабочей готовности, а проблема имеет отношение к плоскости пользователя, вызов отклоняется посредством M-MGW (сетевой шлюз мобильной связи), например, используя MBAC (основанное на измерении управление доступом) или подобный механизм, в зависимости от условий плоскости пользователя. Термин MGW (сетевой шлюз) используется по всему этому тексту в качестве неограничивающего примера узла, который обрабатывает вызов в плоскости пользователя и содержит ресурсы для обработки плоскости пользователя. Если вызов обрабатывается посредством одного сервера, например центра коммутации мобильной связи (MSC), для сервера остается возможность изменить маршрут вызова на альтернативный маршрут. В случае вызовов через два или более серверов, что очень распространено, в течение установления вызова слишком поздно изменять маршрут вызова и вызов будет неуспешным.

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

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

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

- как правило, междугородные вызовы управляются двумя серверами, то есть предпочтительно решение, которое учитывает не только сценарий, в котором вызов управляется одним MSC-S (сервер центра коммутации мобильной связи).

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

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

Раскрытие изобретения

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

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

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

- принимают индикацию перегрузки ресурсов на маршруте к адресату через сеть первого типа,

сохраняют индикацию перегрузки, ассоциированную с маршрутом,

при приеме последующего запроса инициализации установления вызова на маршруте,

- проверяют, существует ли индикация перегрузки для маршрута, и

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

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

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

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

- память для хранения индикации перегрузки, ассоциированной с маршрутом, и

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

- проверять, существует ли индикация перегрузки для маршрута, и

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

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

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

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

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

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

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

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

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

Фиг.5 - график, показывающий пример адаптации уровней перенаправления трафика (TDL) со временем.

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

Осуществление изобретения

Далее предложенный способ и устройства описываются на основе конкретных вариантов осуществления. Однако необходимо отметить, что конкретные примеры приводятся только для того, чтобы проиллюстрировать вышеупомянутые общие условия основной концепции. Например, способ и устройства также могут быть применены в случае основанной на ATM (асинхронный режим передачи) плоскости пользователя или описываемые с использованием M-MGW варианты осуществления также могут быть выполнены, используя обычный MGW или любой другой соответствующий узел обработки плоскости пользователя. В равной степени, управление вызовом может быть выполнено посредством MSC, MSC-S или любого другого соответствующего сервера управления вызовом.

Фиг.1 - блок-схема последовательности операций, иллюстрирующая способ согласно варианту осуществления настоящего изобретения. Этот способ может быть применен, например, к системе, которая показана на Фиг.4, в которой трафик плоскости пользователя (изображен сплошными линиями) может пройти от первой сети 404 связи (например, сеть мобильной телефонной связи или сеть доступа) до узла 402 обработки плоскости пользователя (UPHN), ассоциированного с сетью 404, который в свою очередь может маршрутизировать трафик через сеть T1 первого типа и сеть T2 второго типа еще одному UPHN 403, который в свою очередь ассоциирован с еще одной сетью 405 связи (например, еще одна сеть мобильной телефонной связи или еще одна сеть доступа). Управление трафиком осуществляется посредством соответствующих серверов, 400 и 401, управления вызовом (CCS), которые обмениваются управляющей сигнальной информацией (изображено пунктирными линиями) с UPHN 402 и 403 соответственно. Конечно, система на Фиг.4 - только пример, и концепция изобретения также может быть применена к другим системам, например, имеющим больше типов сетей, чем Т1 и T2, или, где обработка в плоскости пользователя и управление трафиком выполняются в одном узле или распределяются по более чем двум узлам. Кроме того, отличающиеся UPHN могут быть задействованы для обработки трафика от и к системам 402, 404 связи в зависимости от сетей Т1, T2, через которые трафик маршрутизируется, что указывается, например, посредством UPHN 403'.

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

Индикация перегрузки - это часть информации, приемлемой для того, чтобы передать, что перегрузка присутствует. В примере, иллюстрированном на Фиг.4, CCS 400 может, например, принять такую индикацию для сети Т1 первого типа при попытке выполнить установление вызова для запрашиваемого от мобильного терминала 406 вызова. Адресатом может быть, например, мобильный терминал 407. Индикация перегрузки может быть сформирована любым приемлемым или желаемым образом, например, она может исходить от UPHN 402 или от CCS 401 в ответ на запрос ресурсов от CCS 400. Она может содержаться, например, в предназначенном сообщении или быть частью основной информации, принятой во время процесса установления вызова.

На этапе S11 сохраняют ассоциированную с маршрутом индикацию перегрузки, для которого была указана перегрузка. В примере, иллюстрированном на Фиг.4, предположим, что данный маршрут (например, маршрут BICC) через сеть Т1 первого типа указан как перегруженный, CCS 400 делает запись индикации перегрузки, ассоциированной с данным маршрутом. Таким образом, сохранение индикации перегрузки может быть реализовано посредством сохранения части информации, которая принята на этапе S10, или посредством записи в любой другой приемлемой форме, которая указывает такой же информационный контент.

Процесс, иллюстрированный на Фиг.1, может быть частью более масштабного процесса управления, который указан на Фиг.1 пунктирными линиями до этапа S10 и после S11. Могут быть дополнительные этапы (не показаны на Фиг.1), которые приводят к прерыванию вызова, во время установления которого на этапе S10 была принята индикация перегрузки. С другой стороны, уведомление о перегрузке также может быть принято за пределами контекста установления вызова, например, как часть предназначенного сигнального сообщения, инициированного узлом испытывающей перегрузку сети.

В соответствии с настоящим вариантом осуществления, в любом случае существуют дополнительные этапы так, чтобы, если позже принимают (S12) запрос инициализации установления вызова, на этапе S13 проверять, существует ли индикация перегрузки для ассоциированного с вызовом первоначального маршрута. Первоначальный маршрут - это любой маршрут, изначально ассоциированный с запрашиваемым вызовом, например, на основе таблицы маршрутизации. Если упомянутая индикация перегрузки существует, то вызов устанавливают на альтернативном маршруте к адресату через сеть второго типа, например сеть T2 на Фиг.4, см. S14.

Если сохраненной индикации перегрузки нет, например, потому что этапы S10 и S11 не применялись, так как ранее не была принята индикация перегрузки, или потому что механизм очистки записей удалил сохраненную индикацию перегрузки, тогда процедуру продолжают посредством установления на первоначальном маршруте, этап S15. Упомянутый механизм очистки записей может быть основан на времени, например, сохраненные индикации перегрузки удаляются, если обновленная индикация не принимается в пределах заданного периода времени, и/или, основываясь на положительной сигнальной информации, например, основываясь на получении индикации, что перегрузки нет или больше не присутствует. В качестве основанного на времени примера, возможно, например, запускать таймер для интервала T_RC перегрузки каждый раз, когда для маршрута сохраняется индикация перегрузки. Продолжительность интервала T_RC перегрузки может быть того же порядка величины, как интервал измерения для MBAC, например, несколько секунд. Например, значение может быть равным 2с.

Например, для носителей IP, обнаружение перегрузки первоначально происходит исходя из основанного на измерении управления доступом (MBAC) в MGW при приеме сообщений "Запрос IPBCP" и "Согласие". Иногда обнаружение может произойти на более поздней стадии, например, если инициализация Nb терпит неудачу.

Когда MGW, задействованные в вызове, управляются посредством отличающихся серверов MSC, во время обнаружения перегрузки, как описано выше, два сервера уже обменялись сообщениями BICC IAM (сообщение исходного адреса) и APM (прикладной транспортный механизм). Переход на другой маршрут больше не возможен для этого вызова. Таким образом, предложенный способ заключается в том, чтобы направлять последующие вызовы на альтернативные маршруты, как только обнаружиться перегрузка, пока это считается нерешенным.

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

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

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

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

- сохраняют индикацию перегрузки, ассоциированную с маршрутом,

- при приеме запроса инициализации установления вызова на маршруте,

- проверяют, существует ли индикация перегрузки для маршрута, и

- устанавливают вызов на альтернативном маршруте к адресату через сеть с коммутацией каналов.

Способ, иллюстрированный на Фиг.1, может быть выполнен в любом приемлемом узле или множестве узлов. Например, описанные этапы могут быть выполнены в сервере управления вызовом упомянутой системы связи, например CCS 400 и/или CCS 401 на Фиг.4. Индикация перегрузки может быть принята от UPHN, например CCS 401 может принять индикацию перегрузки от UPHN 402. Помимо этого, индикация перегрузки может быть принята от другого CCS, например CCS 400 может принять индикацию перегрузки от CCS 401, который в свою очередь, возможно, принял ее от UPHN 403. Последняя ситуация одного CCS, принимающего уведомление о перегрузке от другого CCS, может произойти, если вызовом управляют посредством более чем одного сервера управления вызовом.

Процедура формирования индикации перегрузки может быть выбрана любым приемлемым или желаемым образом. Например, индикация перегрузки может быть сформирована, если состояние перегрузки обнаруживается в плоскости пользователя. Таким образом, по меньшей мере часть процедуры формирования индикации перегрузки может быть выполнена в узле обработки плоскости пользователя. Индикация перегрузки также может быть сформирована в случае потери связи между плоскостью пользователя и плоскостью управления. Таким образом, по меньшей мере часть процедуры формирования индикации перегрузки может быть выполнена в сервере управления вызовом. Например, на Фиг.4, если CCS 401 распознает потерю сигнальной связи с UPHN 403, то может отправить индикацию перегрузки CCS 400, тем самым инициируя изменение маршрута последующих вызовов. В случае, иллюстрированном на Фиг.4, индикация перегрузки должна была бы указать перегрузку для всего трафика, проходящего через UPHN 403, так что изменение маршрута должно было бы быть организовано так, чтобы обойти UPHN 403 и, соответственно, возможно использовать третью сеть (не показана на Фиг.4) или дополнительный UPHN (не показан на Фиг.4), подключенный к одной или обеим, Т1 и T2, а также к системе 405 связи. Таким образом, очевидно, что обладающий признаками изобретения механизм использования индикаций перегрузки не ограничивается применениями, в которых присутствует перегрузка в плоскости пользователя, а может быть применена в любой ситуации, в которой вследствие нарушения в работе какой-то части всей системы связи желательно изменение маршрута, по меньшей мере, последующих вызовов.

Условие, при котором узел сети посылает индикацию перегрузки, может быть выбрано любым приемлемым или желаемым образом. Например, UPHN могут регулярно контролировать ситуацию перегрузки в плоскости пользователя и отправлять CCS соответствующие сообщения, содержащие индикацию перегрузки, если перегрузка обнаружена.

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

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

занимают ресурсы для носителя вызова, и

- определяют перегрузку при занятии ресурсов. Другими словами, если во время установления вызова занятие ресурсов прерывается предопределенным методом, то это воспринимается CCS как индикация перегрузки.

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

запрос на установление соединения Интернет-протокола отклоняется посредством функции основанного на измерении управления доступом,

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

- протокол формирования кадров Nb плоскости пользователя не может быть корректно инициализирован.

На Фиг.6 показан конкретный пример установления носителя в прямом направлении. Ссылочные номера 600 и 601 относятся к MSC или MSC-S в качестве примеров CCS. Ссылочные номера 602 и 603 относятся к MGW или M-MGW в качестве примеров UPHN. Ссылочные номера 604 и 605 относятся к мобильным терминалам, 606 имеет отношение к сети IP в качестве примера сети первого типа, а 607 имеет отношение к сети TDM в качестве примера сети второго типа. Как указано посредством облаков, изображающих межсетевые соединения, другие устройства, например маршрутизаторы IP, могут переадресовывать информацию плоскости пользователя между MGW. Для простоты опущены известные сигнальные подключения и известные подключения управления между инициирующими и оконечными серверами, а также инициирующими вызовы и оконечными MGW, и инициирующим и оконечным оборудованием пользователя, представленного мобильными телефонами.

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

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

В начальной стадии MSC-S 600 принимает от мобильного терминала 604 запрос установления вызова к мобильному терминалу 605 и, основываясь на нем, выбирает маршрут BICC для маршрутизации вызова через сеть 606 IP. Затем отправляет MSC-S 601 начальное адресное сообщение M60 (IAM), который в свою очередь запускает основанное на измерении управление доступом (MBAC) в MGW 603. В качестве альтернативы, в MGW 603 может быть выполнено статическое управление доступом (SAC). В примере предполагается, что MGW 603 обнаруживает отклонение, указывающее перегрузку, например показатель потери пакетов больше, чем предопределенное пороговое значение. В результате MGW 603 посылает MSC-S 601 сообщение M61 отклонения, который в свою очередь отправляет MSC-S 600 сообщение M62, содержащее индикацию перегрузки. Как следствие, MSC-S 600 на определенное время помечает исходящий маршрут BICC как "Плоскость Пользователя перегружена". В течение этого времени, когда маршрут помечен как "Плоскость Пользователя перегружена", MSC-S должен иметь возможность использовать альтернативные исходящие маршруты, в частности маршруты ISUP/TDM через сеть 607 TDM.

Если в следующем по порядку узле обнаружена перегрузка, когда используется установленный от MSC-S 600 носитель в прямом направлении, а перегрузка обнаруживается посредством MGW 603, управляемого посредством следующего по порядку MSC-S 601, то узел 603 пошлет новое уведомление предыдущему узлу 602 плоскости пользователя для того, чтобы указать перегрузку, например, в туннеле во время BICC через серверы 601 и 600, а узел 602 отправит MSC-S 600 уведомление о перегрузке. Следовательно, MSC-S 600 может действовать в соответствии с перегрузкой, как если бы это было сообщено посредством собственного M-MGW 602. Кроме того, узел 603 может отправить уведомление о перегрузке серверу 601, который в свою очередь может отправить предыдущему серверу 600 сообщение отклонения, содержащее код причины.

Прием этого кода причины позволит MSC пометить исходящий маршрут BICC как " Плоскость Пользователя перегружена".

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

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

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

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

Аналогично описанному выше, MSC-S 600 принимает запрос установления, выбирает маршрут BICC, отправляет IAM к MSC-S 601, который в свою очередь управляет, например, M-MGW 603, чтобы выполнить MBAC. Применяя MBAC, для того, чтобы разрешить новые подключения M-MGW, 603 может отслеживать, выше ли отношение потерянных пакетов предопределенного ограничения, ниже ли пороговой величины. M-MGW 603 должен быть выполнен с возможностью информировать MSC-S 601 о новом событии, что сеть IP по направлению к конкретному получателю становится перегруженной, то есть в этом случае показанное на Фиг.6 сообщение M61 предоставляет эту информацию. Она может быть основана на: a) отслеживании, что отношение потерянных пакетов превышает предопределенное ограничение, что должно быть сделано во время применения MBAC и b) мониторинге DSCP (поле кода дифференцирования трафика) октета заголовка IP. Это уведомление может использовать новое событие, которое ниже также обозначается, как ipcong (индикация частичной перегрузки на IP).

Если перегрузка обнаруживается, одна из возможностей сообщения MGW о перегрузке заключается в том, чтобы установить биты в широко известном поле DSCP заголовка IP, например, посредством еще одного MGW.

В связи с установлением вызова MGW посылает MSC-S уведомление ipcong. В момент времени, когда применяется MBAC, MGW отслеживает уровень отношения потерянных пакетов, как это обычно делается, но теперь для того, чтобы разрешить больше вызовов, если MSC-S выполнен с возможностью обрабатывать событие ipcong, MGW не только проверит, ниже ли трафик пороговой величины (т.е. пороговой величины полной перегрузки), но также, превышен ли предопределенный предельный уровень отношения потерянных пакетов или указывает ли перезаполненный октет DSCP ситуацию перед наступлением перегрузки. Если это так, MGW посылает уведомление с событием ipcong.

MSC-S на определенное время помечает исходящий маршрут BICC как "Плоскость Пользователя частично перегружена", когда посредством функции основанного на измерении управления доступом в MGW принят запрос на соединение, но от MGW принято уведомление, указывающее что в сети с носителем IP есть признаки перегрузки определенного уровня, например, если обнаруживается заданное отношение потерянных пакетов данных.

Когда маршрут помечен, как "Плоскость пользователя частично перегружена", MSC-S должен иметь возможность использовать альтернативные исходящие маршруты для некоторого процентного отношения вызовов, которые в обычном случае адресовались бы частично перегруженному маршруту. Таким образом, перегрузка ослабляется, не полностью блокируя маршрут для новых вызовов.

Что касается уровней перегрузки и обработки вызовов во время перегрузки, уведомление о перегрузке будет обработано посредством инициирующего MSC-S до продолжения установления вызова. Если маршрут не был помечен как "Плоскость Пользователя перегружена", то теперь MSC пометит его и запустится управляемый BICC интервал T_RC перегрузки плоскости пользователя. В этом решении маршрут также будет помечаться с помощью уровня перенаправления трафика TDLi, который будет определять процентное отношение вызовов, которые будут перенаправляться на альтернативный маршрут в течение интервала T_RC. “i” указывает отличающиеся уровни перенаправления, более высокое значение i указывает более высокое процентное отношение перенаправленных вызовов. Если вместо события ipcong принимается обнаруженная посредством MBAC перегрузка, уровень перенаправления трафика должен быть установлен на максимальное значение (100%).

Продолжительность интервала T_RC перегрузки может быть того же порядка величины, как интервал измерения для MBAC, например несколько секунд. Например, значение может быть равным 2с.

TDLi может зависеть от:

- типа принятой индикации перегрузки. Если отклонение вызвано MBAC или, в более общем плане, управлением доступом для конкретного маршрута, должен быть применен максимальный уровень перенаправления трафика, так как изменение состояния перегрузки не может ожидаться в течение следующего временного интервала T_RC вследствие механизма обнаружения. Если вызвано событием ipcong или неудачной инициализацией UP (плоскость пользователя), примененный в предыдущем интервале уровень перенаправления может быть ступенчато увеличен. Существуют другие механизмы, которые используются сегодня, для того, чтобы обнаружить перегрузку на уровне плоскости пользователя. Основываясь на сущности отличающихся механизмов, может быть целесообразно применять максимальный уровень перенаправления трафика или увеличивать уровень перенаправления. Например, так называемый механизм статического управления доступом (SAC), основанный на полном объеме трафика IP в MGW, также может отклонить установление нового вызова. Для этого типа отклонения целесообразно увеличение уровня перенаправления.

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

Когда интервал T_RC(n) перегруженного маршрута истекает, может быть запущен новый интервал T_RC(n+l), в котором уровень перенаправления может быть, например:

- таким же, как в предыдущем интервале T_RC(n), если предыдущий интервал был первым интервалом перегрузки, то есть n=1.

- TDLi+1, где TDLi - уровень, который применялся в течение T_RC(n), если в течение T_RC(n) была принята индикация перегрузки и n>1.

- TDLi-1, где TDLi - уровень, который применялся в течение T_RC(n), если в течение T_RC(n) не была принята индикация перегрузки и n>1. Если TDLi-1=0, то не нужно контролировать новый интервал и n возвращается к значению 0.

Если, когда TDL меньше максимального значения, принята индикация перегрузки, вызванная отклонением посредством MBAC, всегда можно запустить или перезапустить новый интервал T_RC перегруженного маршрута. Максимальное значение TDL будет сохранено в течение двух интервалов T_RC. В третьем интервале, уровень перенаправления трафика может быть уменьшен на один уровень.

На Фиг.5 показан пример такого режима работы, в котором существуют пять уровней TDL с 20%-ными интервалами между каждым из них. Как может быть замечено, события ipcong приводят к постепенной корректировке TDL, тогда как событие отклонение MBAC (индикация перегрузки) приводит к перезапуску T_RC и корректировке TDL к 100%.

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

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

Термин “управляемый BICC интервал (T_RC) перегруженной плоскости пользователя” используется, чтобы отобразить интервал времени, в течение которого плоскость пользователя, управляемая посредством исходящего маршрута BICC, помечается как перегруженная или частично перегруженная, и все или некоторое процентное отношение вызовов перенаправляются на альтернативный маршрут.

Термин уровень перенаправления трафика (TDL) используется для того, чтобы указать процентное отношение вызовов, которые в течение интервала перегруженного маршрута направляются по другому маршруту. Предлагаемые уровни, например, 0, 20%, 40%, 60%, 80% и 100%.

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

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

Кроме того, настоящее изобретение может также быть воплощено в виде устройства, приемлемого для использования в вышеупомянутых способах. Например, настоящее изобретение при этом также может быть воплощено в сервере управления вызовом, таком как MSC или MSC-S, для системы связи, которая имеет возможность маршрутизации по сети первого типа и сети второго типа, таких как описанные выше CCS 400, 401, 600 и 601. На Фиг.2 показана схематическая блок-схема такого сервера 2 управления вызовом, содержащего приемник 20 для приема информации от других узлов и серверов через линии 23, память 21 для хранения принятой информации и содержащую программы, и процессор или устройство 22 управления для управления работой. Приемник 20 выполнен с возможностью принимать индикацию перегрузки ресурсов на маршруте к адресату через сеть первого типа. Память 21 выполнена с возможностью хранить индикацию перегрузки, ассоциированную с маршрутом. Устройство 22 управления выполнено с возможностью при приеме последующего запроса инициализации установления вызова на маршруте:

- проверять, существует ли индикация перегрузки для маршрута, и

- устанавливать вызов на альтернативном маршруте к адресату через сеть второго типа, если упомянутая индикация перегрузки существует. Кроме того, для упрощения не упомянуты известные элементы серверов управления вызовом.

Устройство 22 управления может быть реализовано любым приемлемым или желаемым образом. Например, оно может содержать одно или более

устройство 220 управления сообщениями для обработки принятых посредством приемника 20 сообщений, включающего в себя элементы для распознавания индикации перегрузки, и для управления операцией сохранения индикации перегрузки в памяти 21;

устройство 221 выделения индикации перегрузки для того, чтобы проверить, присутствует ли индикация перегрузки в памяти 21; и

- устройство 222 управления маршрутами для установления вызова на первоначальном маршруте или альтернативном маршруте, в зависимости от выходных данных от устройства 221 выделения индикации перегрузки.

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

Кроме того, настоящее изобретение может быть воплощено в узле обработки плоскости пользователя, например MGW, схематическая блок-схема которого показана на Фиг.3. Узел 3 обработки плоскости пользователя может иметь структуру, схожую с сервером 2, показанным на Фиг.2, то есть содержать приемник 30 для приема информации от других узлов и серверов через линии 33, содержащую программы память 31 для хранения принятой информации, и процессор или устройство 32 управления для управления операцией. Узел 3 обработки плоскости пользователя выполнен для системы связи, которая имеет возможность маршрутизации по сети первого типа и сети второго типа. Устройство 32 управления выполнено с возможностью выполнять процедуру распознавания состояния частичной перегрузки для маршрута через упомянутую сеть первого типа и формировать уведомление о частичной перегрузке, направляемое серверу управления вызовом упомянутой системы связи. Дополнительные известные элементы узлов обработки плоскости пользователя пропущены для простоты.

Устройство 32 управления может быть реализовано любым приемлемым или желаемым образом. Например, оно может содержать одно или более

- устройство 320 управления трафиком для обработки принятого посредством приемника 30 трафика, включающее в себя элементы для обработки и отправления упомянутого трафика и для управления операцией сохранения в памяти 31;

- устройство 321 обнаружения перегрузки для распознавания присутствия состояния перегрузки или состояния частичной перегрузки для маршрута сети, подключенной к узлу 3 обработки плоскости пользователя; и

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

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

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

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

2. Способ по п.1, в котором упомянутой сетью первого типа является сеть с пакетной коммутацией, а упомянутой сетью второго типа является сеть с коммутацией каналов.

3. Способ по п.1 или 2, в котором упомянутой сетью первого типа является либо сеть протокола Интернет, либо сеть с асинхронным режимом передачи.

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

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

6. Способ по любому из пп.1, 2, 5, в котором упомянутая индикация перегрузки формируется, если идентифицируется одно или оба из состояния перегрузки в плоскости пользователя и потери связи между плоскостью пользователя и плоскостью управления.

7. Способ по п.6, в котором упомянутая идентификация состояния перегрузки содержит формирование индикации перегрузки, если выполняется одно или более из следующего:
запрос соединения Интернет-протокола отклоняется посредством функции основанного на измерении управления доступом,
запрос соединения Интернет-протокола отклоняется посредством функции статического управления доступом, и
протокол формирования кадров Nb плоскости пользователя не может быть корректно инициализирован.

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

9. Способ по любому из пп.1, 2, 5, 7, 8, дополнительно содержащий процедуру идентификации состояния частичной перегрузки для формирования уведомления о частичной перегрузке.

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

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

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

13. Способ по п.12, в котором контролируются предопределенные интервалы (Т_RC), и по истечении каждого из упомянутых интервалов обновляется уровень перенаправления трафика.

14. Сервер (2) управления вызовом для системы связи, которая имеет возможность маршрутизации по сети первого типа и сети второго типа, содержащий
приемник (20) для приема индикации перегрузки, сформированной в медиашлюзе, для ресурсов на маршруте к адресату через сеть первого типа,
память (21) для хранения ассоциированной с маршрутом индикации перегрузки и
устройство (22) управления, выполненное так, чтобы после приема последующего запроса инициализации установления вызова на маршруте:
проверять, существует ли индикация перегрузки для маршрута, и
устанавливать вызов на альтернативном маршруте к адресату через сеть второго типа, если упомянутая индикация перегрузки существует.

15. Медиашлюз (3) для системы связи, которая имеет возможность маршрутизации по сети первого типа и сети второго типа, содержащий
устройство (32) управления для:
выполнения процедуры идентификации состояния частичной перегрузки для маршрута через упомянутую сеть первого типа, и
формирования уведомления о частичной перегрузке, направляемого серверу управления вызовом упомянутой системы связи.