способ, устройство и система хэндровера и обработки вызовов

Формула изобретения

1. Способ хэндовера, содержащий следующие этапы:

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

получают отправленное медиашлюзом МШ ответное сообщение о добавлении конечной точки;

отправляют целевому Контроллеру Базовой Станции (КБС) сообщение Запрос Хэндовера, содержащее Код Идентификации Канала (КИК) и информацию конечной точки о типе IP, если в ответном сообщении о добавлении конечной точки указано, что медиашлюз МШ успешно установил конечную точку Временного Разделения Каналов (ВРК) и конечную точку протокола IP; и

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

2. Способ по п.1, дополнительно содержащий следующие этапы:

если в ответном сообщении о добавлении конечной точки указано, что медиашлюз МШ успешно установил конечную точку IP, отправляют целевому контроллеру КБС сообщение Запрос Хэндовера, содержащее информацию конечной точки о типе IP;

получают возвращаемое целевым контроллером КБС Подтверждение Запроса Хэндовера, указывающее, что целевой контроллер КБС выбрал использование порта ВРК, если сообщение Подтверждение Запроса Хэндовера содержит код КИК, и извещают медиашлюз МШ о повторном установлении конечной точки ВРК, соответствующей коду КИК.

3. Способ по п.1, дополнительно содержащий следующие этапы:

если ответное сообщение о добавлении конечной точки указывает, что медиашлюз МШ успешно установил конечную точку IP, отправляют целевому контроллеру КБС сообщение Запрос Хэндовера, содержащее информацию конечной точки о типе IP;

получают возвращаемое целевым контроллером КБС сообщение Подтверждение Запроса Хэндовера; причем если сообщение Подтверждение Запроса Хэндовера содержит информацию конечной точки о типе IP, сообщение Подтверждение Запроса Хэндовера указывает, что целевой контроллер КБС выбрал использование порта IP.

4. Способ по п.1, дополнительно содержащий следующий этап:

отправляют медиашлюзу МШ сообщение с запросом на добавление конечной точки, содержащее информацию конечной точки о типе ВРК и информацию о кодеках, соответствующую указанному типу ВРК, а также информацию конечной точки о типе IP и информацию о кодеках, соответствующую указанному IP.

5. Способ по любому из пп.1-4, дополнительно содержащий следующий этап:

по возвращенному целевым контроллером КБС сообщению Подтверждение Запроса Хэндовера извещают медиашлюз МШ об удалении успешно установленной конечной точки, не соответствующей типу конечной точки, выбранному целевым контроллером КБС.

6. Устройство хэндовера, сконфигурированное для взаимодействия с медиашлюзом МШ и целевым контроллером КБС и содержащее:

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

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

модуль Запроса Хэндовера, сконфигурированный для отправки целевому контроллеру КБС сообщения Запрос Хэндовера, содержащего код КИК и информацию конечной точки о типе протокола IP, если в ответном сообщение о добавлении конечной точки указано, что медиашлюз МШ успешно установил конечную точку ВРК и конечную точку IP;

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

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

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

9. Система хэндовера, содержащая устройство хэндовера по любому из пп.6-8.

10. Система по п.9, дополнительно содержащая медиашлюз МШ, сконфигурированный для взаимодействия с центром ЦМК и содержащий модуль установки конечных точек, сконфигурированный для установки конечной точки ВРК и конечной точки IP по полученному сообщению с запросом на добавление конечных точек, и для возврата ответного сообщения о добавлении конечных точек, указывающего, что конечная точка ВРК и конечная точка IP установлены.

11. Система по любому из пп.9-10, дополнительно содержащая контроллер КБС, сконфигурированный для взаимодействия с центром ЦМК и содержащий модуль выбора типа конечной точки, сконфигурированный для получения сообщения Запрос Хэндовера и отправки сообщения Подтверждение Запроса Хэндовера, содержащего информацию выбранной конечной точки.

Описание изобретения к патенту

ОБЛАСТЬ ТЕХНИКИ

[0001] Настоящее изобретение относится к мобильной связи, в частности к способу, устройству и системе хэндовера и обработки вызовов.

ПРЕДПОСЫЛКИ К СОЗДАНИЮ ИЗОБРЕТЕНИЯ

[0002] Для отправки сигналов в глобальной системе мобильной связи (GSM) сначала использовали передачу на основе Временного Разделения Каналов (ВРК, TDM). Впоследствии, по мере развития и распространения технологий с использованием интернет-протоколов (IP), протоколы IP нашли повсеместное применение в Базовой Сети (БС, CN), при этом между сетью БС (CN) и сетью доступа стали применять протоколы SIGTRAN с использованием протоколов IP для отправки информации по плоскости сигнализации А-интерфейса. Фиг.1 представляет собой схематическое изображение системы GSM, на котором пунктирными линиями обозначена плоскость сигнализации, и сплошными линиями обозначена пользовательская плоскость. В данной архитектуре способ ВРК (TDM) по-прежнему применяют только в пользовательской плоскости А-интерфейса, что является последним препятствием для внедрения глобальной сети на основе протокола IP. Кроме того, консорциум 3GPP, разрабатывающий спецификации для мобильной телефонии третьего поколения предложил использовать передачу А-интерфейса по сети, построенной по протоколу IP (технология AolP) для решения задачи по внедрению протокола IP в пользовательской плоскости А-интерфейса.

[0003] При использовании для А-интерфейса передачи на основе ВРК (TDM), для соединения сети БС (CN) и Контроллера Базовой Станции (КБС, BSC) применяют фиксированную линию из коаксиального кабеля, при этом под каждый вызов по коаксиальному кабелю отводится один таймслот 64 кбит/с, то есть для передачи одного вызова в пользовательской плоскости необходимо отвести один таймслот, занимающий фиксированную часть общего ресурса, причем для однозначной идентификации одного вызова в исходном протоколе используют Код Идентификации Вызова или Код Идентификации Канала (КИК, CIC). Длина информационного элемента КИК (CIC) составляет 2 байта. Применительно к коаксиальному кабелю с пропускной способностью 2 М (то есть одного ретранслятора с возможностью мультиплексирования на тридцать два таймслота по 64 кбит/с), для идентификации конкретного номера задействованного таймслота могут быть использованы пять двоичных разрядов ХХХХХ, при этом для идентификации номера задействованного ретранслятора используют в общей сложности одиннадцать двоичных разрядов от a до k. Вариант представления кода КИК (CIC) показан в Таблице 1.

Таблица 1
8	7	6	5	4	3	2	1
Идентификатор информационного элемента								Байт 1
а	b	с	d	e	f	g	h	Байт 2
i	J	k	X	X	X	X	X	Байт 3

[0004] После внедрения технологии AolP соединение между сетью БС (CN) и контроллером КБС (BSC) уже не осуществляют посредством фиксированной линии. Поскольку больше не существует однозначного соответствия между кодом КИК (CIC) и номером таймслота фиксированной линии, код КИК (CIC) уже нельзя использовать для идентификации отдельного вызова, поэтому для идентификации вызова стали применять Идентификатор Вызова (ИВ, Call-ID). При потере связи Центра Мобильной Коммутации (центр ЦМК, MSC) или контроллера КБС (BSC) с Подсистемой Управления Соединением Сигнализации (ПУСС, SCCP) встречной станции, идентификатор ИВ (Call-ID) может использоваться в качестве объекта, запрашивающего у встречной станции синхронное освобождение соответствующих ресурсов вызова. При использовании сетевой конфигурации A-Flex с созданием пула центров ЦМК (MSC) (технология MSC In Pool) вызов генерирует ошибки, обусловленные некорректным адресом. Таким образом, при необходимости освобождения пакетов вызовов особенно эффективным является использование списка идентификаторов ИВ (Call-ID).

[0005] Если сеть поддерживает технологию AolP, идентификатор ИВ (Call-ID) можно использовать для однозначной идентификации отдельного вызова на соответствующем контроллере КБС (BSC) и соответствующем центре ЦМК (MSC); при этом контроллер КБС (BSC) должен возвращать назначенное центром ЦМК (MSC) значение идентификатора ИВ (Call-ID) в сообщении Назначение Выполнено (Assignment Complete) и в сообщении Подтверждение Запроса Хэндовера (Handover Request Acknowledge). Предусмотрены два варианта представления идентификатора ИВ (Call-ID).

[0006] 1. В виде пары (IP-адрес+номер порта UDP):

[0007] применительно к идентификатору, представленному в виде пары (IP-адрес+номер порта UDP), при использовании версии IPv4 длина заголовка одного IP-адреса составляет 4 байта, и в случае добавления 2 байтов идентификатора порта для указанной адресной пары требуется по меньшей мере 12 байтов; при использовании версии IPv6 длина заголовка одного IP-адреса составляет 16 байтов и в случае добавления 2 байтов идентификатора порта для адресной пары требуется по меньшей мере 36 байтов.

[0008] 2. В виде независимого от среды переноса номера:

[0009] применительно к данному варианту представления, для того чтобы обеспечить одномоментную уникальность значения идентификатора, в настоящее время применяют решение, заключающееся в использовании 32-разрядного значения, как показано в следующей Таблице.

Таблица 2
8	7	6	5	4	3	2
ИВ (Call-ID (самый младший бит)								Байт 1
ИВ (Call-ID)								Байт 2
ИВ (Call-ID)								Байт 3
ИВ (Call-ID) (самый старший бит)								Байт 4

[0010] Идентификатор независимого от среды переноса номера равен 1 байт (8 бит); независимый от среды переноса номер равен 4 байтам (32 бита).

[0011] Если контроллер КБС (BSC) отправляет Список Кодеков, поддерживаемых контроллером КБС (BSC) ((СКП-КБС (BSC-SCL), указывающий на поддержку контроллером КБС (BSC) технологии AolP) в сообщении с полной информацией третьего уровня (Complete Layer3)), центр ЦМК (MSC) может идентифицировать вызов, используя значение идентификатора ИВ (Call-ID), и передать информационный элемент ИВ (Call-ID) в сообщении Запрос Назначения (Assignment Request), причем контроллер КБС (BSC) использует то же самое значение идентификатора ИВ (Call-ID). При этом контроллер КБС (BSC) может в результате выбрать использование ВРК (TDM), для чего контроллер КБС (BSC) должен предоставить центру ЦМК (MSC) один информационный элемент КИК (CIC) и использовать одно конкретное значение кода КИК (CIC) для идентификации назначенной конечной точки ВРК (TDM) таким образом, чтобы в этот момент обеспечить возможность использования центром ЦМК (MSC) и контроллером КБС (BSC) идентификатора ИВ (Call-ID) для идентификации вызова.

[0012] В ходе осуществления вызова, если пользовательский терминал выполняет хэндовер между двумя контроллерами КБС (BSC) одного центра ЦМК (MSC), поскольку целевой контроллер КБС (BSC) не сообщает центру ЦМК (MSC) о текущей возможности поддержки А-интерфейса, сервер ЦМК (MSC) (С-ЦМК, MSC-S) может обратиться с начальным запросом на одновременное предоставление конечных точек по типу ВРК (TDM) и типу IP для целевого контроллера КБС (BSC) только к медиашлюзу (МШ, MGW); соответствующий процесс хэндовера показан на фиг.2. Согласно данному техническому решению сообщение Запрос Хэндовера (Handover Request) не может содержать информационный элемент Тип Канала (Channel Туре) одновременно со Списком Предпочтительных Кодеков центра ЦМК (MSC) (СПК-ЦМК, MSC-PCL), то есть сообщение Запрос Хэндовера (Handover Request) не может содержать информационный элемент КИК (CIC) (даже если объективно длина сообщения Запрос Хэндовера (Handover Request) достаточна для отправки в нем кода КИК (CIC)). Если целевой контроллер КБС (BSC) после получения сообщения Запрос Хэндовера (Handover Request) выбирает конечную точку ВРК (TDM), вполне вероятно, что целевой контроллер КБС (BSC) назначит и возвратит серверу С-ЦМК (MSC-S) одно значение кода КИК (CIC), не согласующееся с созданной на медиашлюзе МШ (MGW) конечной точкой ВРК (TDM). При этом сервер С-ЦМК (MSC-S) перейдет к процедуре обработки некорректного события и освободит вызов из-за несогласованности кода КИК (CIC) со стороны медиашлюза МШ (MGW) и со стороны целевого контроллера КБС (BSC).

[0013] В ходе разработки настоящего изобретения авторы изобретения обнаружили, что известному техническому решению присущи по меньшей мере следующие недостатки. У идентификатора, представленного в виде пары (IP-адрес+номер порта UDP), слишком большой байтовый заголовок, поэтому в информационном элементе Контейнер AolP имеется избыточность между байтовым заголовком и информацией IP и UDP, и при выполнении хэндовера может возникнуть несоответствие между имеющимися параметрами (IP и порта) и указательным значением. Кроме того, поскольку имеется ограничение, что в сообщении Запрос Хэндовера (Handover Request) нельзя одновременно передавать список СПК-ЦМК (MSC-PCL) и информационный элемент КИК (CIC), возможно возникновение приводящего к сбою вызова рассогласования между значением кода КИК (CIC), назначенного целевым контроллером КБС (BSC) и значением кода КИК (CIC), соответствующего созданной медиашлюзом МШ (MGW) конечной точке ВРК (TDM).

[0014] Кроме того, при представлении идентификатора в виде независимого от среды переноса номера, например, если один контроллер КБС (BSC) подключен к нескольким центрам ЦМК (MSC) (то есть к пулу центров ЦМК (технология MSC In Pool)), в случае нескоординированной работы нескольких центров ЦМК (MSC) в пуле, приводящей к невозможности корректного и своевременного назначения значения идентификатора ИВ (Call-ID), весьма вероятно, что в некоторый момент времени произойдет назначение идентификатора ИВ (Call-ID) с тем же значением тому же контроллеру КБС (BSC); при этом известное техническое решение не предусматривает процесса обработки на случай получения контроллером КБС (BSC) повторяющегося значения идентификатора ИВ (Call-ID).

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

[0015] Соответственно, задачей настоящего изобретения является создание способа, устройства и системы хэндовера и обработки вызовов, позволяющих устранить приводящий к сбою вызова недостаток известного технического решения, состоящий в том, что в процессе выполнения хэндовера конечная точка ВРК (TDM) целевого контроллера КБС (BSC) может отличаться от конечной точки ВРК (TDM), назначенной медиашлюзом МШ (MGW).

[0016] Одним из вариантов осуществления настоящего изобретения предусмотрен способ хэндовера, содержащий следующие этапы: получают отправленное медиашлюзом МШ (MGW) ответное сообщение о добавлении конечной точки;

отправляют целевому контроллеру КБС (BSC) сообщение Запрос Хэндовера (Handover Request), содержащее код КИК (CIC) и информацию конечной точки о типе IP, если в ответном сообщении о добавлении конечной точки указано, что медиашлюз МШ (MGW) успешно установил конечную точку ВРК (TDM) и конечную точку IP;

получают возвращаемое целевым контроллером КБС (BSC) сообщение Подтверждение Запроса Хэндовера (Handover Request Acknowledge), причем если сообщение Подтверждение Запроса Хэндовера (Handover Request Acknowledge) содержит информацию конечной точки о типе IP, сообщение Подтверждение Запроса Хэндовера (Handover Request Acknowledge) указывает, что целевой контроллер КБС (BSC) выбрал использование IP порта.

[0017] Дополнительно одним из вариантов осуществления настоящего изобретения предусмотрено устройство хэндовера, сконфигурированное для взаимодействия с медиашлюзом МШ (MGW) и контроллером КБС (BSC) и содержащее:

модуль приема ответного сообщения о добавлении конечной точки, сконфигурированный для получения ответного сообщения о добавлении конечной точки, отправленного медиашлюзом МШ (MGW);

модуль Запроса Хэндовера, сконфигурированный для отправки целевому контроллеру КБС (BSC) сообщения Запрос Хэндовера (Handover Request), содержащего код КИК (CIC) и информацию конечной точки о типе IP, если в ответном сообщении о добавлении конечной точки указано, что медиашлюз МШ (MGW) успешно установил конечную точку ВРК (TDM) и конечную точку IP; модуль Подтверждения Хэндовера, сконфигурированный для получения возвращаемого целевым контроллером КБС (BSC) сообщения Подтверждение Запроса Хэндовера (Handover Request Acknowledge); причем если сообщение Подтверждение Запроса Хэндовера (Handover Request Acknowledge) содержит информацию конечной точки о типе IP, это указывает, что целевой контроллер КБС (BSC) выбрал использование IP порта.

[0018] Дополнительно одним из вариантов осуществления настоящего изобретения предусмотрена система хэндовера, содержащая центр ЦКМС (MSC) согласно приведенному выше описанию устройства хэндовера.

[0019] Дополнительно одним из вариантов осуществления настоящего изобретения предусмотрен способ хэндовера, содержащий следующие этапы: устанавливают конечную точку ВРК (TDM) и конечную точку IP по полученному сообщению с запросом на добавление конечной точки;

возвращают ответное сообщение о добавлении конечной точки, указывающее, что конечная точка ВРК (TDM) и конечная точка IP успешно установлены.

[0020] Дополнительно одним из вариантов осуществления настоящего изобретения предусмотрено устройство хэндовера, содержащее:

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

[0021] Дополнительно одним из вариантов осуществления настоящего изобретения предусмотрен способ хэндовера, содержащий следующие этапы: получают сообщение Запрос Хэндовера (Handover Request), содержащее код ИКК (CIC) и информацию конечной точки о типе протокола IP, выбирают тип конечной точки;

отправляют сообщение Подтверждение Запроса Хэндовера (Handover Request Acknowledge), содержащее информацию о выбранном типе конечной точки.

[0022] Дополнительно одним из вариантов осуществления настоящего изобретения предусмотрено устройство хэндовера, содержащее модуль выбора типа конечной точки, сконфигурированный для получения сообщения Запрос Хэндовера (Handover Request) и отправки сообщения Подтверждение Запроса Хэндовера (Handover Request Acknowledge), содержащего информацию о выбранном типе конечной точки.

[0023] Дополнительно одним из вариантов осуществления настоящего изобретения предусмотрен способ хэндовера, содержащий следующие этапы: получают отправленное медиашлюзом МШ (MGW) ответное сообщение о добавлении конечной точки, указывающее, что конечная точка IP уже установлена;

отправляют целевому контроллеру КБС (BSC) сообщение Запрос Хэндовера (Handover Request), содержащее идентификатор ИВ (Call-ID), сформированный из идентификатора сетевого элемента (СЭ, NE) и идентификатора вызова сетевого элемента (ИВСЭ, NE Call-ID); или выбирают из назначенного центру ЦМК (MSC) диапазона значений одно свободное значение идентификатора ИВ (Call-ID) и отправляют целевому контроллеру КБС (BSC) сообщение Запрос Хэндовера (Handover Request), содержащее выбранное значение идентификатора ИВ (Call-ID), причем назначенные центрам ЦМК (MSC) диапазоны значений идентификатора ИВ (Call-ID) не пересекаются друг с другом;

получают сообщение Подтверждение Запроса Хэндовера (Handover Request Acknowledge), возвращаемое целевым контроллером КБС (BSC) после установления вызова, идентифицированного значением идентификатора ИВ (Call-ID).

[0024] Дополнительно одним из вариантов осуществления настоящего изобретения предусмотрен способ обработки вызовов, содержащий следующие этапы:

получают сообщение Запрос Назначения (Assignment Request) или сообщение Запрос Хэндовера (Handover Request), причем сообщение Запрос Назначения (Assignment Request) или сообщение Запрос Хэндовера (Handover Request) содержит идентификатор ИВ (Call-ID); при этом в случае отказа в назначении вызова по содержащему идентификатор ИВ (Call-ID) сообщению Запрос Назначения (Assignment Request) или по содержащему идентификатор ИВ (Call-ID) сообщению Запрос Хэндовера (Handover Request) возвращают центру ЦМК (MSC) сообщение Отказ Назначения (Assignment Failure), содержащее указательное значение причины отказа, или сообщение Отказ Хэндовера (Handover Failure), содержащее указательное значение причины отказа; при этом в указательном значении причины отказа либо указывают, что данный идентификатор ИВ (Call-ID) уже существует, либо указывают, что формат идентификатора ИВ (Call-ID) неверен.

[0025] Дополнительно одним из вариантов осуществления настоящего изобретения предусмотрено устройство хэндовера, содержащее: второй модуль Запроса Хэндовера, сконфигурированный для получения отправленного медиашлюзом МШ (MGW) ответного сообщения о добавлении конечной точки, указывающего, что конечная точка IP уже установлена; отправки целевому контроллеру КБС (BSC) сообщения Запрос Хэндовера (Handover Request), содержащего идентификатор ИВ (Call-ID), сформированный из идентификатора элемента СЭ (NE) и идентификатора ИВСЭ (NE Call-ID); или для выбора одного свободного значения идентификатора ИВ (Call-ID) из диапазона значений идентификатора ИВ (Call-ID), назначенного центру ЦМК (MSC), и отправки целевому контроллеру КБС (BSC) сообщения Запрос Хэндовера (Handover Request), содержащего выбранное значение идентификатора ИВ (Call-ID), причем назначенные центрам ЦМК (MSC) диапазоны значений идентификатора ИВ (Call-ID) не пересекаются друг с другом;

модуль приема Подтверждения, сконфигурированный для получения сообщения Подтверждение Запроса Хэндовера (Handover Request Acknowledge), возвращаемого целевым контроллером КБС (BSC) после установления вызова, идентифицированного значением идентификатора ИВ (Call-ID).

[0026] Дополнительно одним из вариантов осуществления настоящего изобретения предусмотрено устройство обработки вызовов, содержащее: модуль приема сообщений, сконфигурированный для получения сообщения Запрос Назначения (Assignment Request), содержащего идентификатор ИВ (Call-ID), или получения сообщения Запрос Хэндовера (Handover Request), содержащего идентификатор ИВ (Call-ID);

модуль отправки сообщения об отказе, сконфигурированный для возврата центру ЦМК (MSC) сообщения Отказ Назначения (Assignment Failure), содержащего указательное значение причины отказа, в случае отказа назначения вызова по содержащему идентификатор ИВ (Call-ID) сообщению Запрос Назначения (Assignment Request), полученному модулем приема сообщений, причем в указательном значении причины отказа либо указано, что данный идентификатор ИВ (Call-ID) уже существует, либо указано, что формат идентификатора ИВ (Call-ID) некорректен; или сконфигурированный для возврата центру ЦМК (MSC) сообщения Отказ Хэндовера (Handover Failure), содержащего указательное значение причины отказа, в случае отказа назначения вызова по содержащему идентификатор ИВ (Call-ID) сообщению Отказ Хэндовера (Handover Request), полученному модулем приема сообщений, причем в указательном значении причины отказа либо указано, что данный идентификатор ИВ (Call-ID) уже существует, либо указано, что формат идентификатора ИВ (Call-ID) некорректен.

[0027] Согласно вариантам осуществления настоящего изобретения, отправленное целевому контроллеру КБС (BSC) сообщение Запрос Хэндовера (Handover Request) содержит значение кода КИК (CIC) и информацию конечной точки IP, что обеспечивает возможность непосредственного использования назначенного центру ЦМК (MSC) значения кода КИК (CIC) при выборе целевым контроллером КБС (BSC) конечной точки типа ВРК (TDM). Таким образом предотвращен сбой вызовов по причине несогласованности конечных точек ВРК (TDM), назначаемых отдельно целевым контроллером КБС (BSC) и стороной медиашлюза МШ (MGW). В результате повышается коэффициент успешных вызовов.

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

[0028] На фиг.1 показана известная схема сети GSM;

[0029] на фиг.2 показана известная блок-схема хэндовера;

[0030] на фиг.3 показана блок-схема первого варианта осуществления заявляемого способа хэндовера;

[0031] на фиг.4 показана блок-схема второго варианта осуществления заявляемого способа хэндовера;

[0032] на фиг.5 показана блок-схема третьего варианта осуществления заявляемого способа хэндовера;

[0033] на фиг.6 показана блок-схема четвертого варианта осуществления заявляемого способа хэндовера;

[0034] на фиг.7 показана блок-схема пятого варианта осуществления заявляемого способа хэндовера;

[0035] на фиг.8 показана структурная схема системы хэндовера согласно одному из вариантов осуществления;

[0036] на фиг.9 показана структурная схема устройства хэндовера согласно одному из вариантов осуществления;

[0037] на фиг.10 показана блок-схема способа установления вызова согласно одному из вариантов осуществления;

[0038] На фиг.11 показана структурная схема устройства установления вызова согласно одному из вариантов осуществления;

[0039] На фиг.12 показана блок-схема первого варианта осуществления заявляемого способа обработки вызовов;

[0040] На фиг.13 показана блок-схема второго варианта осуществления заявляемого способа обработки вызовов;

[0041] На фиг.14 показана структурная схема устройства обработки вызовов согласно одному из вариантов осуществления.

[0042] Одним из вариантов осуществления настоящего изобретения предусмотрен способ хэндовера, содержащий указанные ниже этапы. Получают отправленное медиашлюзом МШ (MGW) ответное сообщение о добавлении конечной точки (на чертежах обозначено "Ответ о Доб."). Если в ответном сообщении о добавлении конечной точки указано, что медиашлюз МШ (MGW) успешно установил конечную точку ВРК (TDM) и конечную точку IP, то целевому контроллеру КБС (BSC) отправляют сообщение Запрос Хэндовера (Handover Request), содержащий код КИК (CIC) и информацию конечной точки о типе IP. Если полученное сообщение Подтверждение Запроса Хэндовера (Handover Request Acknowledge), возвращенное целевым контроллером КБС (BSC), содержит информацию конечной точки о типе IP, это указывает, что целевой контроллер КБС (BSC) выбрал использование IP порта. Если полученное Подтверждение Запроса Хэндовера (Handover Request Acknowledge), возвращенное целевым контроллером КБС (BSC), содержит код КИК (CIC), это указывает, что целевой контроллер КБС (BSC) выбрал использование порта ВРК (TDM).

[0043] Данным вариантом осуществления предусмотрено, что для получения ответного сообщения о добавлении конечной точки сервер С-ЦМК (MSC-S) может дополнительно сначала отправить медиашлюзу МШ (MGW) сообщение с запросом на добавление конечной точки (на чертежах обозначено "Запрос Доб.".

[0044] На фиг.3 схематически изображен первый вариант осуществления заявляемого способа хэндовера. В данном варианте осуществления исходным контроллером КБС (BSC) является контроллер КБС1 (BSC1), целевым контроллером КБС (BSC) является контроллер КБС2 (BSC2), при этом контроллеры КБС1 (BSC1) и КБС2 (BSC2) принадлежат одному центру ЦМК (MSC). В частности, указанный способ состоит из следующих этапов.

[0045] На этапе 111 медиашлюзу МШ (MGW) отправляют сообщение с запросом на добавление конечной точки, содержащее информацию конечной точки о типе ВРК (TDM) и информацию о кодеках, соответствующую указанному типу ВРК (TDM), а также информацию конечной точки о типе IP и информацию о кодеках, соответствующую указанному типу IP. Дополнительно информация о кодеках может содержать информацию о кодеке, предложенном вызовом.

[0046] На этапе 113, по получении ответного сообщения о добавлении конечной точки, указывающего, что медиашлюз МШ (MGW) успешно установил конечную точку ВРК (TDM) и конечную точку IP, целевому контроллеру КБС (BSC) отправляют сообщение Запрос Хэндовера (Handover Request), содержащее код КИК (CIC) и информацию конечной точки IP.

[0047] На этапе 115 получают возвращаемое целевым контроллером КБС (BSC) сообщение Подтверждение Запроса Хэндовера (Handover Request Acknowledge), содержащее информацию конечной точки о типе ВРК (TDM) или информацию конечной точки о типе IP. При использовании заявляемых способа и устройства хэндовера, отправленное целевому контроллеру КБС (BSC) сообщение Запрос Хэндовера (Handover Request) содержит значение кода КИК (CIC) и информацию конечной точки IP, что обеспечивает возможность непосредственного использования назначенного центру ЦМК (MSC) значения кода КИК (CIC) при выборе целевым контроллером КБС (BSC) конечной точки типа ВРК (TDM). Таким образом предотвращен сбой вызовов по причине несогласованности конечных точек ВРК (TDM), назначаемых отдельно целевым контроллером КБС (BSC) и стороной медиашлюза МШ (MGW). В результате повышается коэффициент успешных вызовов. При этом за счет соответствующего создания конечной точки ВРК (TDM) и конечной точки IP, уменьшается заголовок параметров и увеличивается скорость хэндовера.

[0048] На фиг.4 схематически изображен второй вариант осуществления заявляемого способа хэндовера. В одном из примеров данного варианта осуществления целевой контроллер КБС (BSC) выбирает использование порта ВРК (TDM). В данном варианте осуществления исходным контроллером КБС (BSC) является контроллер КБС1 (BSC1), целевым контроллером КБС (BSC) является контроллер КБС2 (BSC2), при этом контроллер КБС1 (BSC1) и контроллер КБС2 (BSC2) принадлежат одному центру ЦМК (MSC). В частности, указанный способ состоит из следующих этапов.

[0049] На этапе 211 контроллер КБС1 (BSC1) отправляет серверу С-ЦМК (MSC-S) сообщение Требование Хэндовера (Handover Required).

[0050] Сообщение Требование Хэндовера (Handover Required) содержит речевой кодек сети доступа (RANC1), используемый в данный момент пользовательской МС (MS) и контроллером КБС1 (BSC1).

[0051] На этапе 213 после получения сообщения Требование Хэндовера (Handover Required) сервер С-ЦМК (MSC-S) отправляет медиашлюзу МШ (MGW) сообщение с запросом на добавление конечной точки, содержащее одновременно информацию о предпочтительном речевом кодеке pRANC и информацию конечной точки. Например, информация конечной точки может содержать типы конечных точек для создания медиашлюзом МШ (MGW), то есть конечной точки ВРК (TDM) и конечной точки IP.

[0052] Пользовательская МС (MS) использует интерфейс AolP для реализации обычной речевой услуги в контроллере КБС1 (BSC1), при этом и контроллер КБС1 (BSC1) и контроллер КБС2 (BSC2) принадлежат одному центру ЦМК (MSC). В момент выполнения хэндовера МС (MS) с контроллера КБС1 (BSC1) на контроллер КБС2 (BSC2) сервер С-ЦМК (MSC-S) не располагает информацией о возможности поддержки текущего (динамического) речевого кодека контроллером КБС2 (BSC2) и соответствующем типе А-интерфейса, поэтому для обеспечения быстрого и успешного хэндовера, перед выполнением хэндовера МС (MS) на контроллер КБС2 (BSC2), для контроллера КБС2 (BSC2) на медиашлюзе МШ (MGW) требуется создать спаренные с контроллером КБС2 (BSC2) конечную точку IP и конечную точку ВРК (TDM).

[0053] На этапе 215 медиашлюз МШ (MGW) по принятому запросу на добавление конечной точки создает спаренные с контроллером КБС2 (BSC2) конечную точку ВРК (TDM) и конечную точку IP и возвращает ответное сообщение о добавлении конечной точки, содержащее информацию о типах созданных конечных точек, в данном варианте осуществления представляющих собой конечную точку ВРК (TDM) и конечную точку IP.

[0054] На этапе 217 сервер С-ЦМК (MSC-S) получает ответное сообщение о добавлении конечной точки и отправляет контроллеру КБС2 (BSC2) сообщение Запрос Хэндовера (Handover Request).

[0055] Сообщение Запрос Хэндовера (Handover Request) содержит список СПК-ЦМК1 (MSC-PCL1) (в котором установлен рекомендуемый порядок речевых кодеков, при этом обновленный предпочтительный кодек pRANC является оптимальным предпочтительным кодеком pRANC), информацию конечной точки ВРК (TDM) и информацию конечной точки IP. Информация конечной точки ВРК (TDM) может содержать информационный элемент КИК (CIC), значение которого может представлять собой значение кода КИК1 (CIC1), соответствующее созданной медиашлюзом МШ (MGW) конечной точке ВРК (TDM).

[0056] На этапе 219 контроллер КБС2 (BSC2) получает сообщение Запрос Хэндовера (Handover Request), принимает значение кода КИК1 (CIC1), выбирает из списка СПК-ЦМК1 (MSC-PCL1) речевой кодек RANC2 и возвращает серверу С-ЦМК (MSC-S) сообщение Подтверждение Запроса Хэндовера (Handover Request Acknowledge), содержащее кодек RANC2, значение кода КИК1 (CIC1) и список речевых кодеков, поддерживаемых в данный момент контроллером КБС2 (BSC2).

[0057] По содержащемуся в сообщении информационному элементу КИК (CIC) сервер С-ЦМК (MSC-S) может установить, что для А-интерфейса контроллер КБС2 (BSC2) выбрал передачу на основе ВРК (TDM), при этом поскольку конечная точка ВРК (TDM) создана на медиашлюзе МШ (MGW), тип выбранной контроллером КБС2 (BSC2) конечной точки согласуется с типом созданной на медиашлюзе МШ (MGW) конечной точки ВРК (TDM). Если необходимо, чтобы сообщение содержало информационный элемент КИК (CIC), значение передаваемого кода КИК (CIC) равно КИК1 (CIC1), то есть значение информационного элемента КИК (CIC) равно значению информационного элемента КИК (CIC) в сообщении Запрос Хэндовера (Handover Request). Если сеть БС (CN) назначает спаренное с контроллером КБС2 (BSC2) конечное устройство ВРК (TDM), в данном варианте осуществления сервер С-ЦМК (MSC-S) должен передавать информационный элемент КИК (CIC) в отправленном контроллером КБС2 (BSC2) сообщении Запрос Хэндовера (Handover Request) с явным указанием значения кода КИК (CIC).

[0058] На этапе 221 сервер С-ЦМК (MSC-S) получает сообщение Подтверждение Запроса Хэндовера (Handover Request Acknowledge), определяет, что контроллер КБС2 (BSC2) выбрал передачу на основе ВРК (TDM), и отправляет медиашлюзу МШ (MGW) сообщение с запросом на модификацию конечной точки (на чертежах обозначено "Запрос Мод."), содержащее тип кодека RANC2, выбранный контроллером КБС2 (BSC2) и относящийся к конечной точке ВРК (TDM).

[0059] На этапе 223 медиашлюз МШ (MGW) модифицирует созданную конечную точку ВРК (TDM), обеспечивая возможность использования конечной точкой ВРК (TDM) типа кодека RANC2. При этом активируется конечная точка ВРК (TDM) с обеспечением тем самым соединения ВРК (TDM) между медиашлюзом МШ (MGW) и контроллером КБС2 (BSC2) и возможности предоставления услуги вызова, затем медиашлюз МШ (MGW) возвращает серверу С-ЦМК (MSC-S) ответное сообщение о модификации конечной точки (на чертежах обозначено "Ответ о Мод.").

[0060] На этапе 225 сервер С-ЦМК (MSC-S) отправляет медиашлюзу МШ (MGW) сообщение с запросом на удаление конечной точки (на чертежах обозначено "Запрос Уд."), содержащий информацию о созданной медиашлюзом МШ (MGW) конечной точке IP.

[0061] Поскольку контроллер КБС2 (BSC2) выбрал в итоге передачу на основе ВРК (TDM), не требуется резервировать конечную точку IP, ранее созданную медиашлюзом МШ (MGW), что позволяет освободить указанную конечную точку.

[0062] На этапе 227 медиашлюз МШ (MGW) удаляет ранее созданный порт IP и возвращает серверу С-ЦМК (MSC-S) ответное сообщение об удалении конечной точки.

[0063] На этапе 229 сервер С-ЦМК (MSC-S) отправляет контроллеру КБС1 (BSC1) сообщение Команда Хэндовера (Handover Command), содержащее тип кодека RANC2, выбранного и используемого контроллером КБС2 (BSC2).

[0064] На этапе 231 контроллер КБС1 (BSC1) отправляет на МС (MS) сообщение Команда Хэндовера (Handover Command).

[0065] Посредством сообщения Команда Хэндовера (Handover Command) извещают МС (MS) о кодеке RANC2 и запускают хэндовер МС (MS). МС (MS) настраивают и выполняют хэндовер МС (MS) на канал, назначенный контроллером КБС2 (BSC2) по сообщению Команда Хэндовера (Handover Command), одновременно меняя тип собственного речевого кодека МС (MS) на RANC2 и используя затем кодек RANC2. Если кодек RANC2 совпадает с кодеком RANC1, МС (MS) продолжает использовать кодек RANC1.

[0066] В данном варианте осуществления отсутствуют ограничения на последовательность выполнения этапов 225-227 и 229-231, при этом этапы 225-227 можно выполнять как до выполнения этапов 229-231, так и после выполнения этапов 229-231.

[0067] Данный вариант осуществления предусматривает следующее: при выборе целевым контроллером КБС (BSC) для А-интерфейса передачи на основе ВРК (TDM) обеспечена возможность выбора и использования целевым контроллером КБС (BSC) того же значения кода КИК (CIC), что было заранее назначено сетью БС (CN), то есть обеспечена нормальная обработка вызова после хэндовера и оптимизация процесса хэндовера.

[0068] На фиг.5 показана блок-схема третьего варианта осуществления заявляемого способа хэндовера. В одном из примеров данного варианта осуществления целевой контроллер КБС (BSC) выбирает использование порта ВРК (TDM). Способ содержит следующие этапы.

[0069] На этапе 311 контроллер КБС1 (BSC1) отправляет серверу С-ЦМК (MSC-S) сообщение Требование Хэндовера (Handover Required), содержащее кодек RANC1, используемый в данный момент пользовательской МС (MS) и контроллером КБС1 (BSC1).

[0070] На этапе 313, после получения сообщения Требование Хэндовера (Handover Required) сервер С-ЦМК (MSC-S) отправляет медиашлюзу МШ (MGW) сообщение с запросом на добавление конечной точки, содержащее одновременно предпочтительный речевой кодек pRANC и информацию конечной точки. Например, информация конечной точки может содержать тип конечной точки для создания медиашлюзом МШ (MGW), то есть, в данном варианте осуществления, конечной точки IP.

[0071] На этапе 315 медиашлюз МШ (MGW) по принятому запросу на добавление конечной точки создает спаренную с контроллером КБС2 (BSC2) конечную точку IP и возвращает ответное сообщение о добавлении конечной точки, содержащее информацию о созданной конечной точке IP.

[0072] На этапе 317 сервер С-ЦМК (MSC-S) получает ответное сообщение о добавлении конечной точки и отправляет контроллеру КБС2 (BSC2) сообщение Запрос Хэндовера (Handover Request).

[0073] Сообщение Запрос Хэндовера (Handover Request) содержит список СПК-ЦМК1 (MSC-PCL1) (в котором установлен рекомендуемый порядок речевых кодеков, при этом обновленный предпочтительный кодек pRANC является оптимальным предпочтительным кодеком pRANC) и информацию конечной точки IP.

[0074] На этапе 319 контроллер КБС2 (BSC2) получает сообщение Запрос Хэндовера (Handover Request), выбирает конечную точку типа ВРК (TDM), выдает значение кода КИК1 (CIC1), выбирает соответствующий тип речевого кодека RANC2 из списка СПК-ЦМК1 (MSC-PCL1) и возвращает серверу С-ЦМК (MSC-S) сообщение Подтверждение Запроса Хэндовера (Handover Request Acknowledge), содержащее кодек RANC2, значение кода КИК1 (CIC1) и список речевых кодеков, поддерживаемых в данный момент контроллером КБС2 (BSC2).

[0075] Содержащееся в сообщении значение кода КИК1 (CIC1) указывает, что контроллер КБС2 (BSC2) выбрал передачу на основе ВРК (TDM); следовательно, на медиашлюзе МШ (MGW) необходимо создать соответствующую конечную точку ВРК (TDM).

[0076] На этапе 321, если сервер С-ЦМК (MSC-S) определяет, что выбранный контроллером КБС2 (BSC2) тип конечной точки ВРК (TDM) не согласуется с типом конечной точки IP, созданной медиашлюзом МШ (MGW), сервер С-ЦМК (MSC-S) отправляет медиашлюзу МШ (MGW) сообщение с запросом на добавление конечной точки, содержащее информацию конечной точки ВРК (TDM), созданной на контроллере КБС2 (BSC2), а также кодек RANC2.

[0077] Хотя медиашлюз МШ (MGW) ранее создал для контроллера КБС2 (BSC2) соответствующую конечную точку IP, в итоге контроллер КБС2 (BSC2) выбирает передачу на основе ВРК (TDM), таким образом сервер С-ЦМК (MSC-S) должен дополнительно известить медиашлюз МШ (MGW) об установлении одной соответствующей конечной точки ВРК (TDM) для контроллера КБС2 (BSC2).

[0078] На этапе 323 медиашлюз МШ (MGW) по речевому кодеку RANC2 и информации конечной точки ВРК (TDM) в сообщении о запросе на добавление конечной точки создает спаренную с контроллером КБС2 (BSC2) конечную точку ВРК (TDM); затем после успешного создания конечной точки ВРК (TDM) возвращает серверу С-ЦМК (MSC-S) ответное сообщение о добавлении конечной точки.

[0079] На этапе 325 сервер С-ЦМК (MSC-S) отправляет контроллеру КБС1 (BSC1) сообщение Команда Хэндовера (Handover Command), содержащее тип речевого кодека RANC2.

[0080] На этапе 327 контроллер КБС1 (BSC1) отправляет на МС (MS) сообщение Команда Хэндовера (Handover Command).

[0081] На этапе 329 сервер С-ЦМК (MSC-S) отправляет медиашлюзу МШ (MGW) сообщение с запросом на удаление конечной точки, содержащее информацию о заранее созданной конечной точке IP.

[0082] На этапе 331 медиашлюз МШ (MGW) удаляет соответствующую конечную точку IP и возвращает серверу С-ЦМК (MSC-S) ответное сообщение об удалении конечной точки.

[0083] В данном варианте осуществления отсутствуют ограничения на последовательность выполнения этапов 325-327 и 329-331, при этом этапы 325-327 можно выполнять как до выполнения этапов 329-331, так и после выполнения этапов 329-331.

[0084] Из описания первого и третьего варианта осуществления видно, что в случае принятия контроллером КБС2 (BSC2) решения об использовании А-интерфейса с передачей на основе BPK(TDM), предусмотрено два варианта назначения кода КИК (CIC).

[0085] (1) Аналогично способу по третьему варианту осуществления, сообщение Запрос Хэндовера (Handover Request), отправленное контроллеру КБС2 (BSC2) сервером С-ЦМК (MSC-S), не содержит информационный элемент Тип Канала и информационный элемент КИК (CIC), то есть сеть БС (CN) не назначает заранее конечную точку ВРК (TDM). После получения сообщения Запрос Хэндовера (Handover Request) и принятия решения об использовании канала А-интерфейса с передачей на основе ВРК (TDM), контроллер КБС2 (BSC2) отправляет назначенное контроллером КБС2 (BSC2) значение кода КИК (CIC) в возвращаемом сообщении Подтверждение Запроса Хэндовера (Handover Request Acknowledge); затем, после получения сообщения Подтверждение Запроса Хэндовера (Handover Request Acknowledge), сервер С-ЦМК (MSC-S) извещает медиашлюз МШ (MGW) о назначении спаренной с контроллером КБС2 (BSC2) конечной точки ВРК (TDM) по значению кода КИК (CIC) и освобождает ранее созданную конечную точку IP.

[0086] (2) Аналогично способу по второму варианту осуществления, сообщение Запрос Хэндовера (Handover Request), отправленное контроллеру КБС2 (BSC2) сервером С-ЦМК (MSC-S), не содержит информационный элемент Тип Канала, однако содержит информационный элемент КИК (CIC), то есть сеть БС (CN) заранее назначает конечную точку ВРК (TDM) при назначении конечной точки IP. После получения сообщения Запрос Хэндовера (Handover Request) контроллер КБС2 (BSC2) принимает назначенное сетью БС (CN) значение кода КИК (CIC) и явно использует значение кода КИК (CIC) в информационном элементе КИК (CIC), содержащемся в возвращаемом сообщении Подтверждение Запроса Хэндовера (Handover Request Acknowledge), то есть значение кода КИК (CIC) должно согласовываться со значением кода КИК (CIC), содержащемся в сообщении Запрос Хэндовера (Handover Request). Затем сервер С-ЦМК (MSC-S) извещает медиашлюз МШ (MGW) о модификации и активизации конечной точки ВРК (TDM) на медиашлюзе МШ (MGW) и одновременно освобождает ранее созданную конечную точку IP.

[0087] Данный вариант осуществления предусматривает следующее: при выборе целевым контроллером КБС (BSC) для А-интерфейса передачи на основе ВРК (TDM) обеспечена возможность выбора и использования целевым контроллером КБС (BSC) того же значения кода КИК (CIC), что было заранее назначено сетью БС (CN), то есть обеспечена нормальная обработка вызова после хэндовера и оптимизация процесса хэндовера. Кроме того, согласно данному варианту осуществления сначала создают одну конечную точку. При наличии рассогласования созданной конечной точки с типом конечной точки, выбранным целевым контроллером КБС (BSC), заново создают конечную точку по типу, выбранному целевым контроллером КБС (BSC), и согласовывают ее с выбранной контроллером КБС (BSC) конечной точкой, избавляясь тем самым от таких недостатков известного уровня техники как низкая скорость хэндовера и непроизводительное расходование ресурсов, обусловленных тем, что в известных технических решениях сначала создают все типы конечных точек.

[0088] На фиг.6 показана блок-схема четвертого варианта осуществления заявляемого способа хэндовера. В одном из примеров данного варианта осуществления целевой контроллер КБС (BSC) выбирает передачу на основе IP; при этом этапы 411-415 в данном варианте осуществления аналогичны этапам 211-215 второго варианта осуществления, за исключением того, что контроллер КБС2 (BSC2) выбирает передачу на основе IP следующим образом.

[0089] На этапе 417 сервер С-ЦМК (MSC-S) получает ответное сообщение о добавлении конечной точки и отправляет контроллеру КБС2 (BSC2) сообщение Запрос Хэндовера (Handover Request).

[0090] Сообщение Запрос Хэндовера (Handover Request) содержит список СПК-ЦМК1 (MSC-PCL1) (в котором установлен рекомендуемый порядок речевых кодеков, при этом обновленный предпочтительный кодек pRANC является оптимальным предпочтительным кодеком pRANC), информацию конечной точки ВРК (TDM) и информацию конечной точки IP. Информация конечной точки ВРК (TDM) может содержать информационный элемент КИК (CIC), значение которого может представлять собой значение кода КИК1 (CIC1), соответствующее конечной точке ВРК (TDM), созданной медиашлюзом МШ (MGW).

[0091] Если медиашлюз МШ (MGW) создает только конечную точку IP, сообщение Запрос Хэндовера (Handover Request) на этом этапе не содержит информационный элемент КИК (CIC).

[0092] На этапе 419 контроллер КБС2 (BSC2) получает сообщение Запрос Хэндовера (Handover Request), выбирает из списка СПК-ЦМК (MSC-PCL) речевой кодек RANC2 и возвращает серверу С-ЦМК (MSC-S) сообщение Подтверждение Запроса Хэндовера (Handover Request Acknowledge), содержащее кодек RANC2, а также такую информацию, как информация созданной контроллером КБС2 (BSC2) конечной точки IP.

[0093] Содержащаяся в указанном сообщении информация конечной точки IP указывает, что контроллер КБС2 (BSC2) выбрал для А-интерфейса передачу на основе IP; то есть ранее созданную на медиашлюзе МШ (MGW) конечную точку IP модифицируют и активируют, при этом сообразно кодеку RANC2, выбранному контроллером КБС2 (BSC2), активируют маршрут IP.

[0094] На этапе 421 сервер С-ЦМК (MSC-S) получает сообщение Подтверждение Запроса Хэндовера (Handover Request Acknowledge) и определяет, что выбранная контроллером КБС2 (BSC2) передача на основе IP согласуется с типом созданной конечной точки IP; соответственно сервер С-ЦМК (MSC-S) отправляет медиашлюзу МШ (MGW) сообщение с запросом на модификацию конечной точки, содержащее информацию конечной точки IP контроллера КБС2 (BSC2) и кодек RANC2.

[0095] На этапе 423 медиашлюз МШ (MGW) модифицирует созданную конечную точку МП (IP) таким образом, чтобы обеспечить возможность использования конечной точкой IP типа кодека RANC2. При этом конечную точку IP активируют таким образом, чтобы установить маршрут IP между медиашлюзом МШ (MGW) и контроллером КБС2 (BSC2) и обеспечить возможность предоставления услуги вызова; после чего медиашлюз МШ (MGW) возвращает серверу С-ЦМК (MSC-S) ответное сообщение о модификации конечной точки.

[0096] На этапе 425, если медиашлюз МШ (MGW) ранее создал конечную точку типа ВРК (TDM), сервер С-ЦМК (MSC-S) отправляет медиашлюзу МШ (MGW) сообщение с запросом на удаление конечной точки, содержащее информацию о конечной точке ВРК (TDM), созданной медиашлюзом МШ (MGW).

[0097] Поскольку контроллер КБС2 (BSC2) выбрал передачу на основе IP, не требуется резервировать конечную точку ВРК (TDM), ранее созданную медиашлюзом МШ (MGW), что позволяет освободить указанную конечную точку.

[0098] На этапе 427 медиашлюз МШ (MGW) удаляет ранее созданную конечную точку ВРК (TDM) и возвращает серверу С-ЦМК (MSC-S) ответное сообщение об удалении конечной точки.

[0099] На этапе 429 сервер С-ЦМК (MSC-S) отправляет контроллеру КБС1 (BSC1) сообщение Команда Хэндовера (Handover Command), содержащее тип кодека RANC2, выбранного и используемого контроллером КБС2 (BSC2).

[00100] На этапе 431 контроллер КБС1 (BSC1) отправляет на МС (MS) сообщение Команда Хэндовера (Handover Command).

[00101] Посредством сообщения Команда Хэндовера (Handover Command) извещают МС (MS) о кодеке RANC2 и запускают хэндовер МС (MS). МС (MS) настраивают и выполняют хэндовер МС (MS) на канал, назначенный контроллером КБС2 (BSC2) по сообщению Команда Хэндовера (Handover Command), одновременно меняя тип собственного речевого кодека МС (MS) на RANC2 и используя затем кодек RANC2. Если кодек RANC2 совпадает с кодеком RANC1, МС (MS) продолжает использовать кодек RANC1.

[00102] Если перед выполнением этапа 417 данного варианта осуществления медиашлюз МШ (MGW) создает конечную точку типа ВРК (TDM), то на этапе 417 отправленное контроллеру КБС2 (BSC2) сообщение Запрос Хэндовера (Handover Request) по-прежнему должно содержать значение кода КИК (CIC), назначенное созданной медиашлюзом МШ (MGW) конечной точке ВРК (TDM), поскольку в этот момент времени сервер С-ЦМК (MSC-S) не располагает информацией о типе конечной точки, выбранной контроллером КБС2 (BSC2).

[00103] В данном варианте осуществления отсутствуют ограничения на последовательность выполнения этапов 425-427 и 429-431, при этом этапы 425-427 можно выполнять как до выполнения этапов 429-431, так и после выполнения этапов 429- 431.

[00104] Согласно данному варианту осуществления, отправленное целевому контроллеру КБС (BSC) сообщение содержит значение кода КИК (CIC) для конечной точки ВРК (TDM), созданной медиашлюзом МШ (MGW), благодаря чему обеспечено следующее: при выборе целевым контроллером КБС (BSC) передачи на основе ВРК (TDM) целевой контроллер КБС (BSC) и сеть БС (CN) выбирают и используют один и тот же код КИК (CIC), что позволяет оптимизировать процесс хэндовера.

[00105] На фиг.7 показана блок-схема четвертого варианта осуществления заявляемого способа хэндовера, содержащего следующие этапы.

[00106] На этапе 711 контроллер КБС1 (BSC1) отправляет серверу С-ЦМК (MSC-S) сообщение Требование Хэндовера (Handover Required), содержащее речевой кодек RANC1, используемый в данный момент контроллером КБС1 (BSC1).

[00107] На этапе 713, после получения сообщения Требование Хэндовера (Handover Required), сервер С-ЦМК (MSC-S) отправляет медиашлюзу МШ (MGW) сообщение с запросом на добавление конечной точки, содержащее одновременно предпочтительный кодек pRANC и информацию конечной точки. Информация конечной точки может содержать, например, тип конечной точки для создания медиашлюзом МШ (MGW), то есть конечной точки IP.

[00108] На этапе 715 медиашлюз МШ (MGW) по принятому запросу на добавление конечной точки создает спаренную с контроллером КБС2 (BSC2) конечную точку IP и возвращает ответное сообщение о добавлении конечной точки, содержащее информацию о созданной конечной точке, то есть информацию конечной точки IP.

[00109] На этапе 717 сервер С-ЦМК (MSC-S) получает ответное сообщение о добавлении конечной точки и отправляет контроллеру КБС2 (BSC2) сообщение Запрос Хэндовера (Handover Request), содержащее назначенный сервером С-ЦМК (MSC-S) идентификатор ИВ2 (Call-ID2).

[00110] Для того чтобы предотвратить получение контроллером КБС1 (BSC1) запроса соединения для идентификаторов ИВ (Call-ID) с одинаковым значением, одновременно назначенных разными серверами, необходимо обеспечить различение идентификаторов ИВ (Call-ID) от разных серверов С-ЦМК (MSC-S). Поскольку в одной Наземной Сети Мобильной Связи Общего Пользования НСМСОП (PLMN) количество серверов С-ЦМК (MSC-S) намного меньше количества контроллеров КБС (BSC), и сервер С-ЦМК (MSC-S) отвечает за управление определенной услугой вызова, в данном варианте осуществления только сервер С-ЦМК (MSC-S) может назначать идентификатор ИВ (Call-ID), при этом контроллер КБС (BSC) не имеет прав назначения идентификатора ИВ (Call-ID). Если некий сервер С-ЦМК (MSC-S) назначает идентификатор ИВ (Call-ID) и устанавливает соответствующий вызов, в отношении которого не выполняют хэндовер на другой сервер С-ЦМК (MSC-S) или удаление, то идентификатор ИВ (Call-ID) вызова является постоянно действующим и значение идентификатора ИВ (Call-ID) невозможно модифицировать.

[00111] На этапе 719 контроллер КБС2 (BSC2) получает сообщение Запрос Хэндовера (Handover Request), принимает идентификатор ИВ2 (Call-ID2), выбирает речевой кодек RANC2 из списка СПК-ЦМК (MSC-PCL) и возвращает серверу С-ЦМК (MSC-S) сообщение Подтверждение Запроса Хэндовера (Handover Request Acknowledge), содержащее информацию созданной конечной точки IP, кодек RANC2 и идентификатор ИВ2 (Call-ID2). На этапе 721 сервер С-ЦМК (MSC-S) получает сообщение Подтверждение Запроса Хэндовера (Handover Request Acknowledge), определяет, что контроллер КБС2 (BSC2) выбрал передачу на основе IP, и отправляет медиашлюзу МШ (MGW) сообщение с запросом на модификацию конечной точки, содержащее информацию конечной точки IP контроллера КБС2 (BSC2) и кодек RANC2. На этапе 723 медиашлюз МШ (MGW) модифицирует созданную конечную точку IP таким образом, чтобы обеспечить возможность использования конечной точкой IP типа кодека RANC2. При этом конечная точка IP активирована и обеспечена возможность предоставления услуги вызова между медиашлюзом МШ (MGW) и контроллером КБС2 (BSC2), после чего медиашлюз МШ (MGW) возвращает серверу С-ЦМК (MSC-S) ответное сообщение о модификации конечной точки. Этапы 725-727 аналогичны соответствующим этапам 429-431.

[00112] Данный вариант осуществления предусматривает два варианта представления идентификатора ИВ (Call-ID).

[00113] (1) Каждому серверу С-ЦМК (MSC-S) в глобальной сети назначают соответствующий поддиапазон значений идентификатора ИВ (Call-ID).

[00114] При использовании в сети конфигурации пула центров ЦМК (технология MSC In Pool), то есть при соединении контроллера КБС (BSC) с несколькими серверами С-ЦМК (MSC-S), невозможно полностью обеспечить назначение разными серверами С-ЦМК (MSC-S) идентификаторов ИВ (Call-ID) с разными значениями; при этом согласно данному варианту осуществления возможно использование способа назначения каждому серверу С-ЦМК (MSC-S) в глобальной сети соответствующего поддиапазона значений идентификатора ИВ (Call-ID). Диапазон значений идентификатора ИВ (Call-ID) длиной 32 бита можно разбить на поддиапазоны по количеству элементов элементе СЭ (NE) в сети, например по количеству серверов С-ЦМК (MSC-S), при этом каждый сервер С-ЦМК (MSC-S) будет использовать определенный поддиапазон идентификаторов ИВ (Call-ID). В каждом пуле серверы С-ЦМК (MSC-S) также могут совместно использовать один из поддиапазонов значений идентификатора ИВ (Call-ID). Допустим, например, что сервер С-ЦМК1 (MSC-S1), сервер С-ЦМК2 (MSC-S2) и сервер С-ЦМКЗ (MSC-S3) образуют один совместный пул. Если сервер С-ЦМК2 (MSC-S2) назначает идентификатору ИВ (Call-ID) значение 3 для одного вызова, сервер С-ЦМК2 (MSC-S2) извещает об этом сервер С-ЦМК1 (MSC-S1) и сервер С-ЦМКЗ (MSC-S3), так что сервер С-ЦМК1 (MSC-S1) и сервер С-ЦМКЗ (MSC-S3) не назначают вызову идентификатор ИВ (Call-ID) со значением 3. Подобным же образом, если сервер С-ЦМК2 (MSC-S2) освобождает вызов с идентификатором ИВ (Call-ID), имеющим значение 3, сервер С-ЦМК2 (MSC-S2) также извещает об этом сервер С-ЦМК1 (MSC-S1) и сервер С-ЦМКЗ (MSC-S3), так что сервер С-ЦМК1 (MSC-S1) и сервер С-ЦМКЗ (MSC-S3) могут назначить идентификатор ИВ (Call-ID) со значением 3.

[00115] (2) Для задания идентификатора ИВ (Call-ID) используют сочетание идентификатора элемента СЭ (NE) и идентификатора ИВСЭ (NE Call-ID).

[00116] В качестве идентификатора элемента СЭ (NE) возможно использование кодека пункта сигнализации, IP-адреса, уникально определяющего элемент СЭ (NE), и назначенного в глобальной сети номера элемента СЭ (NE); при этом идентификатор элемента СЭ (NE), такой как идентификатор сервера С-ЦМК (MSC-S), может уникально идентифицировать элемент СЭ (NE) в глобальной сети.

[00117] Идентификатор ИВСЭ (NE Call-ID) задает номер, назначаемый вызову элементом СЭ (NE), и может представлять собой значение идентификатора ИВ (Call-ID), единообразно назначаемое в элементе СЭ (NE), и использовать значения определенного диапазона для задания определенного значения идентификатору ИВ (Call-ID), при этом элемент СЭ (NE) может управлять конкретным назначением номера. Помимо единообразного назначения значения идентификатора ИВ (Call-ID), в элементе СЭ (NE) также возможно управление назначенными значениями идентификатора ИВ (Call-ID) и удаление указанных значений.

[00118] Для получения сведений о конкретном варианте осуществления, необходимо обратиться к описанию варианта осуществления в части способа установления вызова.

[00119] В способе хэндовера согласно данному варианту осуществления настоящего изобретения для задания идентификатора ИВ (Call-ID) либо используют сочетание идентификатора элемента СЭ (NE) и идентификатора ИВСЭ (NE Call-ID), либо заранее назначают элементу СЭ (NE) различные диапазоны значений идентификатора ИВ (Call-ID), при этом идентификатор ИВ (Call-ID) выбирают из отдельного диапазона значений идентификатора ИВ (Call-ID) и назначают вызову таким образом, чтобы обеспечить уникальность идентификатора ИВ (Call-ID) и тем самым предотвратить получение контроллером КБС (BSC) идентификаторов ИВ (Call-ID) с одинаковым значением; что позволяет повысить коэффициент успешно выполненных хэндоверов вызова.

[00120] Один из вариантов осуществления настоящего изобретения предусматривает систему хэндовера, содержащую модуль приема ответного сообщения о добавлении конечной точки, модуль Запроса Хэндовера и модуль Подтверждения Хэндовера. Модуль приема ответного сообщения о добавлении конечной точки сконфигурирован для получения передаваемого медиашлюзом МШ (MGW) ответного сообщения о добавлении конечной точки. Модуль Запроса Хэндовера сконфигурирован для отправки целевому контроллеру КБС (BSC) сообщения Запрос Хэндовера (Handover Request), содержащего код КИК (CIC) и информацию конечной точки о типе IP, если в ответном сообщении о добавлении конечной точки указано, что медиашлюз МШ (MGW) успешно установил конечную точку ВРК (TDM) и конечную точку IP. Модуль Подтверждения Хэндовера сконфигурирован для получения сообщения Подтверждение Запроса Хэндовера (Handover Request Acknowledge), возвращаемого целевым контроллером КБС (BSC). Если сообщение Подтверждение Запроса Хэндовера (Handover Request Acknowledge) содержит информацию конечной точки о типе IP, это указывает на то, что целевой контроллер КБС (BSC) выбрал использование IP порта.

[00121] На фиг.8 показана структурная схема системы хэндовера согласно одному из вариантов осуществления настоящего изобретения, содержащая модуль 1 запроса на добавление конечной точки, первый модуль 2 Запроса Хэндовера и модуль 3 Подтверждения Хэндовера. Модуль 1 запроса на добавление конечной точки сконфигурирован для отправки медиашлюзу МШ (MGW) сообщения с запросом на добавление конечной точки, содержащего информацию конечной точки о типе ВРК (TDM) и информацию о кодеке, предложенном вызовом в соответствии с типом ВРК (TDM), а также информацию конечной точки о типе IP и информацию о кодеке, предложенном вызовом в соответствии с типом IP. Первый модуль 2 Запроса Хэндовера сконфигурирован для отправки целевому контроллеру КБС (BSC) сообщения Запрос Хэндовера (Handover Request), содержащего информационный элемент КИК (CIC) и информацию конечной точки IP, при получении ответного сообщения о добавлении конечной точки, извещающего об успешной установке медиашлюзом МШ (MGW) конечной точки ВРК (TDM) и конечной точки IP. Модуль 3 Подтверждения Хэндовера сконфигурирован для получения возвращаемого целевым контроллером КБС (BSC) сообщения Подтверждение Запроса Хэндовера (Handover Request Acknowledge), содержащего информацию конечной точки о типе ВРК (TDM) или информацию конечной точки о типе IP.

[00122] Дополнительно система хэндовера согласно данному варианту осуществления содержит модуль 4 удаления, сконфигурированный для извещения об необходимости удаления установленной конечной точки, не соответствующей типу конечной точки, указанному в информации конечной точки, содержащейся в сообщении Подтверждение Запроса Хэндовера (Handover Request Acknowledge), согласно информации конечной точки о типе ВРК (TDM) или информации конечной точки о типе IP, содержащейся в возвращенном целевым контроллером КБС (BSC) сообщении Подтверждение Запроса Хэндовера (Handover Request Acknowledge), при успешной установке конечной точки ВРК (TDM) и конечной точки IP. Кроме того, система хэндовера согласно данному варианту осуществления содержит модуль 5 определения, сконфигурированный для определения того, совпадает ли тип конечной точки, указанный в информации конечной точки, содержащейся в сообщении Подтверждение Запроса Хэндовера (Handover Request Acknowledge), с типом конечной точки, указанным в информации установленной конечной точки, содержащейся в ответном сообщении о добавлении конечной точки.

[00123] Система хэндовера согласно данному варианту осуществления также содержит модуль 6 установки конечных точек; сконфигурированный для установки конечной точки ВРК (TDM) и конечной точки IP по принятому запросу на добавление конечной точки и для возврата ответного сообщения о добавлении конечной точки, указывающего, что конечная точка ВРК (TDM) и конечная точка IP успешно установлены. Кроме того, система хэндовера согласно данному варианту осуществления содержит модуль 7 выбора типа конечной точки, сконфигурированный для получения сообщения Запрос Хэндовера (Handover Request) и для отправки сообщения Подтверждение Запроса Хэндовера (Handover Request Acknowledge), содержащего информацию выбранной конечной точки.

[00124] На фиг.9 показана структурная схема устройства хэндовера согласно одному из вариантов осуществления, содержащего второй модуль 8 Запроса Хэндовера, сконфигурированный для получения отправленного медиашлюзом МШ (MGW) ответного сообщения о добавлении конечной точки, указывающего, что конечная точка IP уже установлена, и последующей отправки целевому контроллеру КБС (BSC) сообщения Запрос Хэндовера (Handover Request), содержащего идентификатор ИВ (Call-ID), сформированный из идентификатора элемента СЭ (NE) и идентификатора ИВСЭ (NE Call-ID); или для выбора одного свободного значения идентификатора ИВ (Call-ID) из диапазона значений идентификатора ИВ (Call-ID), назначенного центру ЦМК (MSC), и отправки целевому контроллеру КБС (BSC) сообщения Запрос Хэндовера (Handover Request), содержащего выбранное значение идентификатора ИВ (Call-ID); при этом назначенные центрам ЦМК (MSC) диапазоны значений идентификатора ИВ (Call-ID) не пересекаются друг с другом. Дополнительно устройство хэндовера согласно данному варианту осуществления содержит модуль 9 приема Подтверждения, сконфигурированный для получения сообщения Подтверждение Запроса Хэндовера (Handover Request Acknowledge), содержащего значение идентификатора ИВ (Call-ID), возвращенное целевым контроллером КБС (BSC) после установления вызова, идентифицированного значением идентификатора ИВ (Call-ID).

[00125] На фиг.10 показана блок-схема, иллюстрирующая способ установления вызова согласно одному из вариантов осуществления настоящего изобретения, содержащая следующие этапы.

[00126] На этапе 611 контроллер КБС1 (BSC1) отправляет серверу С-ЦМК (MSC-S) сообщение с полной информацией третьего уровня (Complete Layer3), содержащее список СКП-КБС1 (BSC-SCL1) с информацией о речевых кодеках, поддерживаемых в данный момент контроллером КБС1 (BSC1), и указывающее, что контроллер КБС1 (BSC1) поддерживает на А-интерфейсе тип IP.

[00127] На этапе 613 МС (MS) отправляет серверу С-ЦМК (MSC-S) сообщение Прикладной Части Прямой Передачи ПЧПП (DTAP), содержащее список СКП-МС1 (MS-SCL1) с информацией о речевых кодеках, поддерживаемых МС (MS).

[00128] На этапе 615 сервер С-ЦМК (MSC-S) получает сообщение с полной информацией третьего уровня (Complete Layer3) и сообщение ПЧПП (DTAP), на основе информации о кодеках, поддерживаемых и контроллером КБС1 (BSC1) и МС (MS), выбирает оптимальный предложенный кодек, затем отправляет медиашлюзу МШ (MGW) сообщение с запросом на добавление конечной точки, содержащее оптимальный предложенный кодек и указывающее, что медиашлюз МШ (MGW) устанавливает конечную точку IP согласно оптимальному предложенному кодеку.

[00129] На этапе 617 медиашлюз МШ (MGW) получает запрос на добавление конечной точки, устанавливает конечную точку IP согласно оптимальному предложенному кодеку из сообщения, затем возвращает серверу С-ЦМК (MSC-S) ответное сообщение о добавлении конечной точки.

[00130] На этапе 619 сервер С-ЦМК (MSC-S) отправляет контроллеру КБС1 (BSC1) сообщение Запрос Назначения (Assignment Request), содержащее идентификатор ИВ1 (Call-ID1), назначенный контроллеру КБС1 (BSC1) сервером С-ЦМК (MSC-S), а также информацию конечной точки IP, установленной на медиашлюзе МШ (MGW).

[00131] Для того чтобы предотвратить получение контроллером КБС1 (BSC1) запроса соединения для идентификаторов ИВ (Call-ID) с одинаковым значением, одновременно назначенных разными серверами, необходимо обеспечить различение идентификаторов ИВ (Call-ID) от разных серверов С-ЦМК (MSC-S). Поскольку в одной Наземной Сети Мобильной Связи Общего Пользования НСМСОП (PLMN) количество серверов С-ЦМК (MSC-S) намного меньше количества контроллеров КБС (BSC), и сервер С-ЦМК (MSC-S) отвечает за управление определенной услугой вызова, в данном варианте осуществления только сервер С-ЦМК (MSC-S) может назначать идентификатор ИВ (Call-ID), при этом контроллер КБС (BSC) не имеет прав назначения идентификатора ИВ (Call-ID). Если некий сервер С-ЦМК (MSC-S) назначает идентификатор ИВ (Call-ID) и устанавливает соответствующий вызов, в отношении которого не выполняют хэндовер на другой сервер С-ЦМК (MSC-S) или удаление, то идентификатор ИВ (Call-ID) вызова является постоянно действующим и значение идентификатора ИВ (Call-ID) невозможно модифицировать.

[00132] На этапе 621 контроллер КБС1 (BSC1) устанавливает соединение между МС (MS) и контроллером КБС1 (BSC1) и отправляет серверу С-ЦМК (MSC-S) сообщение Назначение Выполнено (Assignment Complete), содержащее такую информацию, как созданная конечная точка IP, тип кодека, выбранный для конечной точки IP, и идентификатор ИВ1 (Call-ID1).

[00133] На этапе 623 сервер С-ЦМК (MSC-S) отправляет медиашлюзу МШ (MGW) сообщение с запросом на модификацию конечной точки, содержащее информацию конечной точки IP, назначенной контроллером КБС1 (BSC1), а также информацию о выбранном и используемом кодеке.

[00134] На этапе 625 медиашлюз МШ (MGW) получает сообщение с запросом на модификацию конечной точки, модифицирует созданную конечную точку IP таким образом, чтобы обеспечить возможность использования конечной точкой IP типа кодека, содержащегося в сообщении с запросом на модификацию конечной точки, активирует конечную точку IP для установления IP соединения между медиашлюзом МШ (MGW) и контроллером КБС1 (BSC1), затем возвращает ответное сообщение о модификации конечной точки.

[00135] Данный вариант осуществления предусматривает два варианта представления идентификатора ИВ (Call-ID).

[00136] (1) Каждому серверу С-ЦМК (MSC-S) в глобальной сети назначают соответствующий поддиапазон значений идентификатора ИВ (Call-ID).

[00137] При использовании в сети конфигурации пула центров ЦМК (технология MSC In Pool), то есть при соединении контроллера КБС (BSC) с несколькими серверами С-ЦМК (MSC-S), невозможно полностью обеспечить назначение разными серверами С-ЦМК (MSC-S) идентификаторов ИВ (Call-ID) с разными значениями; при этом согласно данному варианту осуществления возможно использование способа назначения каждому серверу С-ЦМК (MSC-S) в глобальной сети соответствующего поддиапазона значений идентификатора ИВ (Call-ID). Диапазон значений идентификатора ИВ (Call-ID) длиной 32 бита можно разбить на поддиапазоны по количеству элементов элементе СЭ (NE) в сети, например по количеству серверов С-ЦМК (MSC-S), при этом каждый сервер С-ЦМК (MSC-S) будет использовать определенный поддиапазон идентификаторов ИВ (Call-ID). В каждом пуле серверы С-ЦМК (MSC-S) также могут совместно использовать один из поддиапазонов значений идентификатора ИВ (Call-ID). Допустим, например, что сервер С-ЦМК1 (MSC-S1), сервер С-ЦМК2 (MSC-S2) и сервер С-ЦМКЗ (MSC-S3) образуют один совместный пул. Если сервер С-ЦМК2 (MSC-S2) назначает идентификатору ИВ (Call-ID) значение 3 для одного вызова, сервер С-ЦМК2 (MSC-S2) извещает об этом сервер С-ЦМК1 (MSC-S1) и сервер С-ЦМКЗ (MSC-S3), так что сервер С-ЦМК1 (MSC-S1) и сервер С-ЦМКЗ (MSC-S3) не назначают вызову идентификатор ИВ (Call-ID) со значением 3. Подобным же образом, если сервер С-ЦМК2 (MSC-S2) освобождает вызов с идентификатором ИВ (Call-ID), имеющим значение 3, сервер С-ЦМК2 (MSC-S2) также извещает об этом сервер С-ЦМК1 (MSC-S1) и сервер С-ЦМКЗ (MSC-S3), так что сервер С-ЦМК1 (MSC-S1) и сервер С-ЦМКЗ (MSC-S3) могут назначить идентификатор ИВ (Call-ID) со значением 3.

[00138] (2) Для задания идентификатора ИВ (Call-ID) используют сочетание СЭ (NE) и идентификатора ИВСЭ (NE Call-ID).

[00139] В качестве идентификатора элемента СЭ (NE) возможно использование кодека пункта сигнализации, IP-адреса, уникально определяющего элемент СЭ (NE), и назначенного в глобальной сети номера элемента СЭ (NE); при этом идентификатор элемента СЭ (NE), такой как идентификатор сервера С-ЦМК (MSC-S), может уникально идентифицировать элемент СЭ (NE) в глобальной сети.

[00140] Идентификатор ИВСЭ (NE Call-ID) задает номер, назначаемый вызову элементом СЭ (NE), и может представлять собой значение идентификатора ИВ (Call-ID), единообразно назначаемое в элементе СЭ (NE), и использовать значения определенного диапазона для задания определенного значения идентификатору ИВ (Call-ID), при этом элемент СЭ (NE) может управлять конкретным назначением номера.

[00141] Например, если в качестве идентификатора элемента СЭ (NE) используют кодек пункта сигнализации, вариант представления идентификатора ИВ (Call-ID) соответствует показанному в Таблице 3.

Таблица 3
8	7	6	5	4	3	2	1
Идентификатор информационного элемента								Байты 1
Длина информационного элемента								Байт 2
Кодек пункта сигнализации								Байт 3 - (n+5)
Номер вызова в элементе СЭ (NE)								Байт (n+6) - (n+9)

[00142] Идентификатор ИВСЭ (NE Call-ID) представляет собой значение идентификатора ИВ (Call-ID), единообразно назначаемое в элементе СЭ (NE), при этом, как показано в Таблице 2, использована длина 4 байта, что достаточно для назначения вызова отдельным элементом СЭ (NE). Вариант представления идентификатора ИВСЭ (NE Call-ID) соответствует показанному в Таблице 4.

Таблица 4
8	7		6	5	4	3	2	1
Идентификатор поля элемента									Байт 1
Длина=(n+1)									Байт 2
Н/Ч		Свойства адресного индикатора							Байт 3
Адресная информация кодека пункта сигнализации									Байт 4 - (n+3)

[00143] В Таблице 4 значение n представляет собой байтовую длину компонента "адресная информация кодека пункта сигнализации".

[00144] Н/Ч представляет собой указатель нечетности/четности: бит 8 в октете 3 обозначает нечетность/четность количества адресных сигналов, содержащихся в адресной информации, а именно:

[00145] 0: четность адресных сигналов,

[00146] 1: нечетность адресных сигналов.

[00147] Свойства адресного индикатора: биты 1-7 октета 3 обозначают атрибуты адресной информации, а именно:

[00148] бит 7654321

[00149] 0000000 (0) свободный

[00150] 0000001 (1) пользовательский номер

[00151] 0000010 (2) резервный национальный

[00152] 0000011 (3) национальный значимый номер

[00153] 0000100 (4) международный номер

[00154] 0000101 (5)-1111111 (127) свободный

[00155] Адресная информация: октет 4 и соответствующая последующая информация представляют собой адресные сигналы следующего формата.

[00156] Если Н/Ч=1, то К является нечетным числом и К=n/2-1. Каждый адресный сигнал занимает 4 бита; соответствующий вариант представления показан в Таблице 5.

Таблица 5
8	7	6	5	4	3	2	1
2-й адресный сигнал				1-й адресный сигнал				Байт 4
4-й адресный сигнал				3-й адресный сигнал				Байт 5
Заполнение 0				К-й адресный сигнал				Байт (n+3)

[00157] Если Н/Ч=0, то К является четным числом и К=n/2. Каждый адресный сигнал занимает 4 бита; соответствующий вариант представления показан в Таблице 6.

Таблица 6
8	7	6	5	4	3	2	1
2-й адресный сигнал				1-й адресный сигнал				Байт 4
4-й адресный сигнал				3-й адресный сигнал				Байт 5
К-й сигнал адреса				(К-1)-й адресный сигнал				Байт (n+3)

[00158] В способе установления вызова согласно данному варианту осуществления настоящего изобретения для задания идентификатора ИВ (Call-ID) либо используют сочетание идентификатора элемента СЭ (NE) и идентификатора ИВСЭ (NE Call-ID), либо заранее назначают элементу СЭ (NE) различные диапазоны значений идентификатора ИВ (Call-ID), при этом идентификатор ИВ (Call-ID) выбирают из отдельного диапазона значений идентификатора ИВ (Call-ID) и назначают вызову таким образом, чтобы обеспечить уникальность идентификатора ИВ (Call-ID) и тем самым предотвратить получение контроллером КБС (BSC) идентификаторов ИВ (Call-ID) с одинаковым значением; что позволяет повысить коэффициент успешно выполненных хэндоверов вызова.

[00159] На фиг.11 показана структурная схема устройства установления вызова согласно одному из вариантов осуществления, содержащего модуль 10 Запроса Назначения, сконфигурированный либо для получения отправленного медиашлюзом МШ (MGW) ответного сообщения о добавлении конечной точки, указывающего, что конечная точка IP уже установлена, и последующей передачи контроллеру КБС (BSC) сообщения Запрос Назначения (Assignment Request), содержащего идентификатор ИВ (Call-ID), сформированный из идентификатора элемента СЭ (NE) и идентификатора ИВСЭ (NE Call-ID); либо для выбора одного свободного значения идентификатора ИВ (Call-ID) из диапазона значений идентификатора ИВ (Call-ID), назначенного центром ЦМК (MSC), и отправки контроллеру КБС (BSC) сообщения Запрос Назначения (Assignment Request), содержащего выбранное значение идентификатора ИВ (Call-ID). Дополнительно устройство установления вызова согласно данному варианту осуществления может содержать модуль 11 приема сообщения о Выполнении, сконфигурированный для получения сообщения Назначение Выполнено (Assignment Complete), содержащего значение идентификатора ИВ (Call-ID), возвращаемое контроллером КБС (BSC) после установления вызова, идентифицированного значением идентификатора ИВ (Call-ID).

[00160] На фиг.12 показана блок-схема четвертого варианта осуществления заявляемого способа обработки вызовов. Этапы 811-819 данного варианта осуществления аналогичны этапам 611-619 варианта осуществления с фиг.8, при этом отличия между вариантами имеются на следующих этапах.

[00161] На этапе 821 контроллер КБС1 (BSC1) получает отправленное сервером С-ЦМК (MSC-S) сообщение Запрос Назначения (Assignment Request) и присваивает содержащееся в сообщении значение идентификатора ИВ (Call-ID); при этом контроллер КБС1 (BSC1) определяет, существует ли в контроллере КБС1 (BSC1) значение идентификатора ИВ (Call-ID), а также является ли верным представление идентификатора ИВ (Call-ID). В случае существования указанного значения и/или неверного представления идентификатора на сервер С-ЦМК (MSC-S) отправляют сообщение Отказ Назначения (Assignment Failure), содержащий идентификатор ИВ (Call-ID) и/или соответствующее указательное значение причины отказа.

[00162] Согласно данному варианту осуществления к возможным причинам отказа в установлении вызова относятся, в том числе, следующие причины: контроллер КБС (BSC) получил повторяющиеся значения идентификатора ИВ (Call-ID); не поддерживается тип речевого кодека; недоступны ресурсы; неверно представлен идентификатор ИВ (Call-ID). По этим причинам также происходит сбой вызова. Если неверно представлен идентификатор ИВ (Call-ID), например в идентификаторе ИВ (Call-ID) не хватает одного байта, в указательном значении причины отказа указана некорректность формата идентификатора ИВ (Call-ID), что означает неверность представления идентификатора ИВ (Call-ID). Если контроллер КБС (BSC) получил повторяющееся значение идентификатора ИВ (Call-ID), в указательном значении причины отказа указано, что данный идентификатор ИВ (Call-ID) уже существует.

[00163] На этапе 823 сервер С-ЦМК (MSC-S) прерывает вызов по значению идентификатора ИВ (Call-ID).

[00164] На фиг.13 показана блок-схема четвертого варианта осуществления заявляемого способа обработки вызовов. Этапы 911-917 данного варианта осуществления аналогичны этапам 711-717 варианта осуществления с фиг.9, при этом отличия между вариантами имеются на следующих этапах.

[00165] На этапе 919 контроллер КБС2 (BSC2) получает сообщение Запрос Хэндовера (Handover Request) и присваивает содержащееся в сообщении Запрос Хэндовера (Handover Request) значение идентификатора ИВ (Call-ID); затем контроллер КБС2 (BSC2) проверяет определяет, существует ли в контроллере КБС2 (BSC2) значение идентификатора ИВ (Call-ID), а также является ли верным представление идентификатора ИВ (Call-ID). В случае существования указанного значения или и/или неверного представления идентификатора серверу С-ЦМК (MSC-S) отправляют сообщение Отказ Хэндовера (Handover Failure), содержащее идентификатор ИВ (Call-ID) и/или соответствующее указательное значение причины отказа.

[00166] Согласно данному варианту осуществления к возможным причинам отказа хэндовера относятся, в том числе, следующие причины: контроллер КБС (BSC) получил повторяющиеся значения идентификатора ИВ (Call-ID); не поддерживается тип речевого кодека; недоступны ресурсы; неверно представлен идентификатор ИВ (Call-ID). Все указанные причины приводят к сбою вызова. Если неверно представлен идентификатор ИВ (Call-ID), например в идентификаторе ИВ (Call-ID) не хватает одного бита, контроллер КБС2 (BSC2) может выявить некорректность формата идентификатора ИВ (Call-ID) и сообщить серверу С-ЦМК (MSC-S) указательное значение причины отказа, содержащее информацию о некорректности формата идентификатора ИВ (Call-ID). Если контроллер КБС (BSC) получил повторяющиеся значения идентификатора ИВ (Call-ID), серверу С-ЦМК (MSC-S) сообщают указательное значение причины отказа, содержащее информацию о существовании данного идентификатора ИВ (Call-ID).

[00167] На этапе 921 сервер С-ЦМК (MSC-S) прерывает процесс хэндовера по значению идентификатора ИВ (Call-ID).

[00168] Согласно данному варианту осуществления способ обработки вызовов обеспечивает эффективную обработку вызова при получении контроллером КБС (BSC) идентификатора ИВ (Call-ID) с повторяющимся значением. В частности, серверу С-ЦМК (MSC-S) направляют сообщение Отказ Назначения (Assignment Failure) или Отказ Хэндовера (Handover Failure), содержащее идентификатор ИВ (Call-ID) с указанным существующим значением, что обеспечивает возможность прерывания сервером С-ЦМК (MSC-S) некорректного вызова, полученного в результате повторения идентификатора ИВ (Call-ID), по значению идентификатора ИВ (Call-ID).

[00169] На фиг.14 показана структурная схема устройства обработки вызовов согласно одному из вариантов осуществления, содержащее модуль 12 приема сообщений и модуль 13 передачи сообщения об отказе. Модуль 12 приема сообщений сконфигурирован для получения сообщения Запрос Назначения (Assignment Request), содержащего идентификатор ИВ (Call-ID), или приема сообщения Запрос Хэндовера (Handover Request), содержащего идентификатор ИВ (Call-ID). Модуль 13 передачи сообщений об отказе либо сконфигурирован для получения сообщения Запрос Назначения (Assignment Request), содержащего идентификатор ИВ (Call-ID), и возврата центру ЦМК (MSC) сообщения Отказ Назначения (Assignment Failure), содержащего значение идентификатора ИВ (Call-ID) и/или соответствующее указательное значение причины отказа, в случае отказа назначения вызова по принятому сообщению Запрос Назначения (Assignment Request), содержащему идентификатор ИВ (Call-ID), причем в указательном значении причины отказа либо указано, что идентификатор ИВ (Call-ID) уже существует либо указано, что формат идентификатора ИВ (Call-ID) некорректен; либо сконфигурирован для получения сообщения Запрос Хэндовера (Handover Request), содержащего идентификатор ИВ (Call-ID), и для возврата центру ЦМК (MSC) сообщения Отказ Хэндовера (Handover Failure), содержащего значение идентификатора ИВ (Call-ID) и/или соответствующее указательное значение причины отказа, в случае отказа назначения вызова по принятому сообщению Отказ Хэндовера (Handover Request), содержащему идентификатор ИВ (Call-ID). Дополнительно модуль 13 передачи сообщения об отказе может отправлять центру ЦМК (MSC) сообщение Отказ Назначения (Assignment Failure) или сообщение Отказ Хэндовера (Handover Failure), содержащее указательное значение причины отказа с указанием на то, что формат идентификатора ИВ (Call-ID) некорректен или что идентификатор ИВ (Call-ID) уже существует. Дополнительно устройство обработки вызовов согласно данному варианту осуществления может содержать модуль 14 ответа о хэндовере и/или модуль 15 ответа о назначении. Модуль 14 ответа о хэндовере сконфигурирован для возврата сообщения Подтверждение Запроса Хэндовера (Handover Request Acknowledge) после выполнения назначения вызова при условии отсутствия значения идентификатора ИВ (Call-ID) в целевом контроллере КБС (BSC) и верности представления идентификатора. Модуль 15 ответа о назначении сконфигурирован для возврата сообщения Назначение Выполнено (Assignment Complete) после выполнения назначения вызова при условии отсутствия значения идентификатора ИВ (Call-ID) в целевом контроллере КБС (BSC) и верности представления идентификатора.

[00170] Специалистам в данной области техники будет очевидно, что все или некоторые этапы способа согласно вариантам осуществления настоящего изобретения могут быть осуществлены посредством программы, управляющей соответствующими аппаратными средствами. Программу можно хранить на считываемом компьютерном носителе данных. После запуска программа исполняет этапы, приведенные в описании вариантов осуществления. В качестве носителя данных можно использовать постоянное запоминающее устройство ПЗУ (ROM), магнитный или оптический диск.

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