способ разъединения вызова и устройство для его осуществления

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

1. Способ разъединения вызова, содержащий:

освобождение ресурсов, связанных с вызовом, если сетевой элемент (NE) обнаруживает неправильное событие и/или обнаруживает, что принято сообщение с запросом на эксплуатацию и сопровождение;

изменение статуса идентификатора вызова со значения «занято» на значение «свободно»;

отправку на равноправный NE сообщения без установления соединения с запросом подсистемы управления сигнализацией соединения (SCCP), так что равноправный NE освобождает ресурсы, связанные с вызовом, на стороне равноправного NE и изменяет статус идентификатора вызова со значения «занято» на значение «свободно» на равноправном NE; и

прием от равноправного NE сообщения без установления соединения с подтверждением SCCP.

2. Способ по п.1, в котором сообщение без установления соединения с запросом SCCP представляет собой сообщение о сбросе ресурсов, доставляющее идентификатор вызова, и сообщение без установления соединения с подтверждением SCCP представляет собой сообщение с подтверждением сброса ресурсов, доставляющее идентификатор вызова.

3. Способ по п.2, в котором обнаружение того, что вызов неправильный, содержит:

обнаружение того, что вызов неправильный на стороне сетевого элемента, и/или прием от равноправного NE сообщения с уведомлением о неправильном вызове.

4. Способ по п.3, в котором прием от равноправного NE сообщения с уведомлением о неправильном вызове содержит:

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

5. Способ по п.1, в котором, если поддерживается функция интерфейса А по протоколу IP (AoIP), то отправка сообщения без установления соединения с запросом SCCP содержит:

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

6. Способ по любому из пп.1-5, в котором освобождение ресурсов, связанных с вызовом, содержит:

освобождение ресурсов, связанных со всеми вызовами;

изменение статуса идентификатора вызова со значения «занято» на значение «свободно» содержит:

изменение статусов идентификаторов всех вызовов со значения «занято» на значение «свободно»; или

освобождение ресурсов, связанных с упомянутым вызовом, содержит:

освобождение ресурсов, связанных со всеми вызовами одинакового типа; и

изменение статуса идентификатора вызова со значения «занято» на значение «свободно» содержит:

изменение статусов идентификаторов всех вызовов одинакового типа со значения «занято» на значение «свободно», при этом все вызовы одинакового типа содержат все вызовы, переданные на основе интерфейса А посредством TDM (AoTDM), и/или все вызовы, переданные на основе интерфейса А по протоколу IP (AoIP).

7. Способ по п.6, в котором

равноправный NE освобождает ресурсы, связанные со всеми вызовами, на стороне равноправного NE, что соответствует освобождению ресурсов, связанных со всеми вызовами; или

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

8. Способ по п.1, в котором NE представляет собой центр коммутации мобильной связи (MSC), равноправный NE представляет собой контроллер базовой станции (BSC), управляемый центром MSC; или NE представляет собой BSC, а равноправный NE представляет собой MSC, управляющий контроллером BSC.

9. Способ по п.1, в котором неправильное событие содержит то, что идентификатор вызова неправильный и/или вызов неправильный.

10. Сетевой элемент для разъединения вызова, содержащий:

модуль отправки сообщения о сбросе, сконфигурированный для освобождения ресурсов, связанных с вызовом, изменения статуса идентификатора вызова со значения «занято» на значение «свободно» и отправки на равноправный сетевой элемент (NE) сообщения о сбросе ресурсов, если обнаружено неправильное событие и/или принято сообщение с запросом на эксплуатацию и сопровождение, так что равноправный NE освобождает ресурсы, связанные с вызовом, на стороне равноправного NE и изменяет статус идентификатора вызова со значения «занято» на значение «свободно» на равноправном NE; и

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

11. Сетевой элемент по п.10, в котором модуль отправки сообщения о сбросе содержит:

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

блок освобождения, сконфигурированный для освобождения ресурсов, связанных с упомянутым вызовом, и изменения статуса Call-ID вызова со значения «занято» на значение «свободно»; и

блок отправки, сконфигурированный для отправки на равноправный NE сообщения о сбросе ресурсов.

12. Сетевой элемент по п.10 или 11, в котором

модуль отправки сообщения о сбросе сконфигурирован для освобождения ресурсов, связанных с вызовом, путем освобождения ресурсов, связанных со всеми вызовами, и сконфигурирован для изменения статуса идентификатора вызова со значения «занято» на значение «свободно» путем изменения статусов идентификаторов всех вызовов со значения «занято» на значение «свободно»; или

модуль отправки сообщения о сбросе сконфигурирован для освобождения ресурсов, связанных с вызовом, путем освобождения ресурсов, связанных со всеми вызовами одинакового типа, и сконфигурирован для изменения статуса идентификатора вызова со значения «занято» на значение «свободно» путем изменения статусов идентификаторов всех вызовов одинакового типа со значения «занято» на значение «свободно», при этом все вызовы одинакового типа содержат все вызовы, пересылаемые на основе интерфейса А посредством TDM (AoTDM), и/или все вызовы, пересылаемые на основе интерфейса А по протоколу IP (AoIP).

13. Сетевой элемент по п.10, в котором неправильное событие содержит то, что идентификатор вызова неправильный и/или вызов неправильный.

14. Сетевой элемент по п.10, в котором

сетевой элемент представляет собой центр коммутации мобильной связи (MSC), равноправный NE представляет собой контроллер базовой станции (BSC), управляемый центром MSC; или сетевой элемент представляет собой BSC, а равноправный NE представляет собой MSC, управляющий контроллером BSC.

15. Способ разъединения вызова, содержащий:

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

освобождение ресурсов, выделенных вызову контроллера BSC, и изменение статуса идентификатора, соответствующего данному вызову, со значения «занято» на значение «свободно».

16. Способ разъединения вызова, содержащий:

при приеме от целевого контроллера базовой станции (BSC) сообщения об отказе передачи обслуживания после отказа передачи обслуживания вызова, освобождение ресурсов, выделенных данному вызову, для терминала на целевом BSC и изменение статуса идентификатора вызова, соответствующего данному вызову, со значения «занято» на значение «свободно»; при этом сообщение об отказе передачи обслуживания доставляет значение причины отказа.

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

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

Данная заявка испрашивает приоритет патентной заявки Китая № 200810118365.9 «METHOD AND APPARATUS FOR CALL RELEASE», поданной в Патентное ведомство Китая 14 августа 2008 года, содержание которой целиком включено в материалы настоящего документа посредством ссылки.

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

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

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

Глобальная система мобильной связи (GSM) изначально основана на мультиплексировании с временным разделением (TDM) для передачи сигналов. С постоянным развитием и ростом популярности протокола Интернета (IP) базовая сеть (CN) базируется только на протоколе IP и протоколе транспорта сигнализации (SIGTRAN) IP интерфейса А между сетью CN и сетью доступа (AN). Архитектура системы GSM, согласно известному уровню техники, показана на Фиг. 1. Пунктирные линии представляют сигнализацию, а сплошные линии указывают плоскость пользователя. В этой архитектуре только плоскость пользователя интерфейса А использует режим TDM, который остается последним препятствием для внедрения разработки, где используется только протокол IP. Таким образом, Проект партнерства 3-го поколения (3GPP) обеспечивает интерфейс А по протоколу IP (AoIP) для обсуждения решений на пути использования только протокола IP для плоскости пользователя интерфейса А.

При использовании в интерфейсе А режима передачи с TDM сеть CN и контроллер базовой станции (BSC) соединены друг с другом посредством коаксиальной кабельной фиксированной линии связи. Каждый вызов занимает один временной интервал со скоростью 64 кбит/с по коаксиальному кабелю. То есть каждая передача вызова в плоскости пользователя гарантированно занимает фиксированный временной интервал. Таким образом, исходный протокол использует идентификационный код вызова/идентификационный код канала (CIC) для уникальной идентификации вызова. Длина ячейки CIC составляет 2 байта. Для коаксиального кабеля с полосой пропускания 2 Мбит/с (то есть, одна магистраль, которая может быть мультиплексирована на 32 временных интервала со скоростью 64 кбит/с), номер используемого временного интервала может быть идентифицирован пятью битами «ХХХХХ», а номер используемой магистрали может быть идентифицирован 11 битами (биты от a до k). Представление CIC показано в Таблице 1.

Таблица 1
8	7	6	5	4	3	2	1
ID ячейки	Байт1
a	b	C	d	e	f	g	h	Байт2
i	j	K	X	X	X	X	X	Байт3

После введения AoIP маршрут между сетью CN и контроллером BSC больше не является фиксированной линией связи. Идентификационный код вызова (CIC) и номер временного интервала фиксированной линии связи больше не связаны взаимно однозначным соотношением. Следовательно, вызов не может быть идентифицирован идентификационным кодом канала (CIC), и для идентификации вызова вводится идентификатор вызова (Call-ID). Когда центр коммутации мобильной связи (MSC) или контроллер BSC теряет соединение подсистемы управления сигнализаций (SCCP) на равноправной стороне, может быть выполнен запрос равноправной стороны на основе Call-ID для освобождения ресурсов, связанных с данным вызовом. Если сеть сконфигурирована применительно к технологии A-flex (MSC в пуле), то появляются ошибки вызова, поскольку некоторые адреса оказываются неправильными. Следовательно, когда требуется обеспечить пакет разъединений вызовов, список идентификаторов Call-ID будет иметь решающее значение для повышения эффективности. Существующий идентификатор Call-ID имеет 32-разрядное значение, не относящееся к пеленгации. Его вид представлен в Таблице 2.

Таблица 2
8	7	6	5	4	3	2	1
идентификатор информационного элемента	Байт1
идентификатор вызова (младший значащий бит)	Байт2
идентификатор вызова	Байт3
идентификатор вызова	Байт4
идентификатор вызова (старший значащий бит)	Байт5

Вдобавок, несколько Call-ID можно объединить в список Call-ID и представить так, как показано в Таблице 3.

Идентификатор Call-ID уникально идентифицирует вызов, обслуживаемый центром MSC и контроллером BSC. Когда центр MSC поддерживает и использует интерфейс А на основе IP в операциях выделения и передачи обслуживания вызова, центр MSC выделяет вызову конкретное значение Call-ID, доставляет Call-ID в информационном элементе идентификатора вызова и уведомляет об этом соответствующий контроллер BSC посредством сообщения с запросом выделения или сообщения с запросом передачи обслуживания вызова. После этого MSC или BSC использует этот Call-ID для идентификации вызова перед его разъединением.

После прерывания соединения SCCP между центром MSC и контроллером BSC, которые связаны с конкретным вызовом, обнаруживается, что прерываемая сторона отправляет сообщение о сбросе ресурсов, доставляющее противоположной стороне значение Call-ID, идентифицирующее конкретный вызов, и дает команду противоположной стороне на освобождение соответствующих ресурсов и ссылок. Если эта операция оказывается успешной, то обратно отправляется сообщение с подтверждением сброса ресурсов, где указанное сообщение доставляет список идентификаторов Call-ID вызовов, чьи ресурсы успешно освобождены.

В ходе реализации настоящего изобретения автор обнаружил, что в известном уровне техники имеет место, по меньшей мере, следующая проблема. В известном уровне техники принято, что идентификатор Call-ID может выделяться только сервером центра MSC, причем этот Call-ID сообщается центру BSC посредством сообщения с запросом выделения или сообщения с запросом на передачу обслуживания вызова, которое содержит указанный Call-ID. Предположим, что сервер MSC периодически выделяет Call-ID в соответствии со значением Call-ID в порядке его возрастания. После нормального разъединения вызова, если сервер MSC и контроллер BSC вовремя не освободили соответствующее занятое значение Call-ID, то этот Call-ID может быть определенно использован вновь, будучи еще раз занятым, когда i-й вызов (i 232) осуществляется после выделения Call-ID этого вызова, хотя статус этого Call-ID будет иметь значение «занято», что приведет к ошибке выделения Call-ID. В этом случае, идентификаторы Call-ID в контроллере BSC и сервере MSC оказываются несовместимыми, что вызывает не только бесполезное расходование ресурсов Call-ID, но также уменьшает долю успешных попыток и эффективность выделения и передачи обслуживания вызовов.

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

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

Способ разъединения вызова, обеспеченный в вариантах осуществления настоящего изобретения, включает в себя:

освобождение ресурсов, связанных с вызовом, если сетевой элемент (NE) обнаруживает, что идентификатор вызова неправильный и/или вызов неправильный, и/или принято сообщение с запросом на эксплуатацию и сопровождение;

изменение статуса идентификатора вызова со значения «занято» на значение «свободно»;

отправку на равноправный элемент NE сообщения без установления соединения с запросом подсистемы управления сигнализацией соединения (SCCP) так, что равноправный NE освобождает ресурсы, связанные с вызовом, на стороне равноправного NE и изменяет статус идентификатора вызова со значения «занято» на значение «свободно» на равноправном NE; и

прием от равноправного NE сообщения без установления соединения с подтверждением SCCP.

Другой способ разъединения вызова, обеспеченный в вариантах осуществления настоящего изобретения, включает в себя:

отправку сообщения с запросом на выделение, доставляющего идентификатор вызова, выделенный контроллеру базовой станции (BSC), и прием от BSC сообщения об отказе выделения, если BSC отказывает в выделении, при этом сообщение об отказе выделения доставляет значение причины отказа; и

освобождение ресурсов, выделенных вызову контроллера BSC, и изменение статуса идентификатора вызова, соответствующего данному вызову, со значения «занято» на значение «свободно».

Еще один способ разъединения вызова, обеспеченный в вариантах осуществления настоящего изобретения, включает в себя:

при приеме от целевого контроллера базовой станции (BSC) сообщения об отказе передачи обслуживания после отказа в передаче обслуживания вызовов, освобождение ресурсов, выделенных вызову, для терминала на целевом контроллере BSC и изменение статуса идентификатора вызова, соответствующего данному вызову, со значения «занято» на значение «свободно»; при этом сообщение об отказе в передаче обслуживания доставляет значение причины отказа.

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

если NE, связанный с вызовом, поддерживает интерфейс А по протоколу IP (AoIP), и вызов поддерживается в элементах NE независимо от того, использует ли текущая линия связи плоскости пользователя интерфейса А в данном вызове мультиплексирование с временным разделением (TDM) или протокол Интернет (IP), - идентификацию вызова только с помощью значения Call-ID.

Устройство разъединения вызова, обеспеченное в вариантах осуществления настоящего изобретения, включает в себя:

модуль отправки сообщения о сбросе, сконфигурированный для освобождения ресурсов, связанных с вызовом, изменения статуса идентификатора вызова со значения «занято» на значение «свободно», и отправки на равноправный сетевой элемент (NE) сообщения о сбросе ресурсов, если элемент NE обнаруживает, что идентификатор вызова неправильный и/или вызов неправильный, и/или принято сообщение с запросом на эксплуатацию и сопровождение, так что равноправный NE освобождает ресурсы, связанные с вызовом, на стороне равноправного NE и изменяет статус идентификатора вызова со значения «занято» на значение «свободно» на равноправном NE; и

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

При использовании способа и устройства для разъединения вызова, обеспеченных в вариантах осуществления настоящего изобретения, изменяют статус Call-ID вызова со значения «занято» на значение «свободно» во время освобождения ресурсов, связанных с вызовом, так что статус Call-ID вызова, обслуживаемого центром MSC и контроллером BSC, оказывается одинаковым. Call-ID разъединенного вызова можно освободить и использовать для идентификации другого вызова. Таким образом, решается проблема бесполезного расходования идентификаторов Call-ID, и повышается доля успешных попыток установления вызова и доля успешных попыток передачи обслуживания вызова.

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

Фиг.1 - архитектура системы GSM согласно известному уровню техники;

Фиг.2 - архитектура системы GSM согласно настоящему изобретению;

Фиг.3 - блок-схема способа разъединения вызова согласно одному варианту осуществления изобретения;

Фиг.4 - блок-схема способа разъединения вызова согласно другому варианту осуществления изобретения;

Фиг.5 - блок-схема способа разъединения вызова согласно другому варианту осуществления изобретения;

Фиг.6 - блок-схема способа разъединения вызова согласно другому варианту осуществления изобретения;

Фиг.7 - блок-схема способа разъединения вызова согласно другому варианту осуществления изобретения;

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

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

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

Фиг. 11 - блок-схема способа разъединения вызова согласно другому варианту осуществления изобретения;

Фиг. 12 - блок-схема способа разъединения вызова согласно другому варианту осуществления изобретения;

Фиг. 13 - блок-схема способа разъединения вызова согласно другому варианту осуществления изобретения;

Фиг. 14 - схема устройства разъединения вызова согласно одному варианту осуществления изобретения;

Фиг. 15 - схема устройства разъединения вызова согласно другому варианту осуществления изобретения;

Фиг. 16 - схема устройства разъединения вызова согласно другому варианту осуществления изобретения.

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

Идентификатор Call-ID, раскрытый в вариантах осуществления настоящего изобретения, относится к Call-ID конкретного вызова в соединении интерфейса А между MSC и BSC. Управление и выделение Call-ID выполняется центром MSC одинаковым образом. На Фиг. 2 показана архитектура системы GSM согласно настоящему изобретению. Все последующие варианты осуществления основаны на системе GSM с передачей только по протоколу IP.

На Фиг. 3 представлена блок-схема способа разъединения вызова согласно одному варианту осуществления настоящего изобретения. Этот способ включает в себя следующие этапы.

Этап 101. Если сетевой элемент (NE) обнаруживает, что Call-ID вызова неправильный и/или вызов неправильный, и/или принято сообщение с запросом эксплуатации и сопровождения, то освобождают ресурсы, связанные с этим вызовом, изменяют статус Call-ID данного вызова со значения «занято» на значение «свободно» и отправляют на равноправный элемент NE сообщение без установления соединения с запросом SCCP.

Этап 102. Принимают от равноправного элемента NE сообщение без установления соединения с подтверждением SCCP, при этом равноправный NE сконфигурирован для освобождения ресурсов вызова на стороне равноправного NE и для изменения статуса Call-ID вызова со значения «занято» на значение «свободно».

При использовании этого способа разъединения вызова, обеспеченного в данном варианте осуществления настоящего изобретения, статус Call-ID вызова изменяют со значения «занято» на значение «свободно» во время освобождения ресурсов, связанных с данным вызовом, так что статус Call-ID вызова, обслуживаемого центром MSC и контроллером BSC, поддерживается согласованно. Call-ID разъединенного вызова может стать свободным и быть использованным для идентификации следующего вызова. Таким образом, решается проблема бесполезного расходования идентификаторов Call-ID и увеличивается доля успешных попыток установления вызова и доля успешных передач обслуживания вызова.

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

Этап 201. Сервер MSC отправляет на BSC сообщение с запросом на передачу обслуживания, при этом это сообщение доставляет значение Call-ID 1, выделенное вызову, принадлежащему контроллеру BSC.

Этап 202. После приема сообщения с запросом на передачу обслуживания контроллер BSC получает значение Call-ID 1 и определяет, был ли выделен Call-ID 1 другому вызову, посредством, например, определения, имеет ли статус Call-ID 1 значение «занято», и определяет, является ли действительным режим идентификации Call-ID 1. Если Call-ID 1 уже был выделен другому вызову до того, как контроллер BSC принял сообщение с запросом на передачу обслуживания (например, в случае, когда статус Call-ID вызова 1 имел значение «занято» перед тем, как контроллер BSC принял сообщение с запросом на передачу обслуживания), и/или режим идентификации Call-ID 1 не действителен, то происходит отказ в передаче обслуживания, и контроллер BSC резервирует вызов, идентифицированный идентификатором Call-ID 1, и связанные с ним ресурсы, и отправляет сообщение об отказе в передаче обслуживания, доставляющее значение причины отказа и/или значение Call-ID 1 на сервер MSC.

Если Call-ID 1 в контроллере BSC уже выделен другому вызову, то BSC отправляет сообщение с отказом на передачу обслуживания, указывающее, что причина отказа состоит в том, что «Call-ID уже был выделен другому вызову».

Этап 203. Если сервер MSC получает, в соответствии со значением причины отказа, доставленной в сообщении от отказе передачи обслуживания, информацию о том, что имеет место отказ в передаче обслуживания и Call-ID 1 выделен неправильно, статус Call-ID 1 изменяют на значение «свободно», освобождают ресурсы, связанные с этим вызовом, и отправляют на BSC сообщение о сбросе ресурсов, в котором содержится значение Call-ID 1.

Этап 204. После приема командного сообщения контроллер BSC изменяет статус Call-ID 1 на значение «свободно», освобождает ресурсы, связанные с вызовом, идентифицированным идентификатором Call-ID 1, и отправляет сообщение с подтверждением сброса ресурсов, доставляющее на сервер MSC значение Call-ID 1.

Сообщение о сбросе ресурсов в этом варианте осуществления изобретения может представлять собой сообщение без установления соединения с запросом SCCP, а сообщением с подтверждением сброса ресурсов может быть сообщение без установления соединения с подтверждением SCCP.

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

На Фиг. 5 представлена блок-схема другого способа разъединения вызова согласно одному варианту осуществления настоящего изобретения. В качестве примера здесь рассматривается случай отказа выделения из-за того, что Call-ID выделен другому вызову. Подробная процедура состоит в следующем.

Этап 301. Сервер MSC отправляет на BSC сообщение с запросом выделения, причем это сообщение доставляет такую информацию, как Call-ID 1, выделенный сервером MSC, на BSC и конечную точку IP, установленную на сетевом шлюзе (MGW), и/или конечную точку с мультиплексированием с временным разделением (TDM).

Этап 302. После приема сообщения с запросом выделения и получения Call-ID 1 контроллер BSC определяет, выделен ли Call-ID 1 другому вызову (то есть, имеет ли статус Call-ID 1 значение «занято»), и определяет, действителен ли режим идентификации Call-ID 1. Если BSC выделил Call-ID 1 другому вызову (то есть, значение статуса Call-ID 1 изменилось на «занято», прежде чем BSC принял сообщение с запросом выделения) и/или режим идентификации не действителен, то на сервер MSC отправляют сообщение об отказе выделения, содержащее значение причины отказа и/или Call-ID 1.

Если Call-ID 1, обслуживаемый контроллером BSC, уже выделен другому вызову, то BSC отправляет сообщение об отказе выделения, устанавливающее, что причина отказа состоит в том, что «Call-ID уже был выделен другому вызову».

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

Этап 303. Если сервер MSC узнает, в соответствии со значением причины, доставленном в сообщении от отказе выделения, что в установке вызова отказано и Call-ID 1 выделен неправильно, то сервер MSC изменяет статус Call-ID 1 на значение «свободно», освобождает ресурсы, связанные с этим вызовом, и отправляет на BSC сообщение о сбросе ресурсов, которое доставляет значение идентификатора Call-ID 1.

Этап 304. После приема сообщения о сбросе ресурсов контроллер BSC изменяет статус Call-ID 1 на значение «свободно», освобождает ресурсы, связанные с вызовом, идентифицированным как Call-ID 1, и отправляет сообщение с подтверждением сброса ресурсов, доставляющее на сервер MSC значение Call-ID 1.

В этом варианте осуществления нет никаких ограничений на последовательность выполнения сервером MSC этапов изменения статуса Call-ID 1, освобождения его ресурсов и отправки сообщения о сбросе ресурсов.

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

Этап 401. Когда сервер MSC принимает команду на эксплуатацию и сопровождение или обнаруживает серьезный сбой, вследствие чего все вызовы, обслуживаемые элементом NE, или все вызовы одинакового типа, обслуживаемые элементом NE, должны быть разъединены, сервер MSC отправляет каждому контроллеру BSC, находящемуся под управлением центра MSC, сообщение без установления соединения с запросом SCCP, с тем, чтобы освободить ресурсы, связанные со всеми вызовами, обслуживаемыми контроллером BSC, и изменить статус Call-ID этих вызовов на значение «свободно».

Этап 402. При приеме сообщения без установления соединения с запросом SCCP каждый контроллер BSC освобождает ресурсы, связанные с каждым вызовом, изменяет статус Call-ID, соответствующего данному вызову, со значения «занято» на значение «свободно» и отправляет сообщение без установления соединения с подтверждением SCCP на сервер MSC, уведомляя о том, что ресурсы всех вызовов, связанных с сервером MSC, обслуживаемым контроллером BSC, или ресурсы, связанные со всеми вызовами одинакового типа, обслуживаемыми контроллером BSC, а также идентификаторы Call-ID этих вызовов успешно освобождены.

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

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

Форма А. Сообщением без установления соединения с запросом SCCP может быть сообщение о сбросе ресурсов, а сообщением без установления соединения с подтверждением SCCP может быть сообщение с подтверждением сброса ресурсов. Ячейка в списке идентификаторов вызовов в этих двух сообщениях указывает идентификаторы Call-ID всех вызовов в элементе NE, инициирующем эти вызовы, или все вызовы одинакового типа в элементе NE. Эти идентификаторы Call-ID не должны перечисляться в списке по отдельности.

В Таблице 4 показана форма идентификации ячейки списка идентификаторов. Значения старшего значащего бита длины Call-ID (длина MSB) и младшего значащего бита (длина LSB) установлены в «0», и конкретное значение «Идентификатора вызова» не приводится. То есть в этот момент длина ячейки списка идентификаторов вызовов составляет 3 октета (байта). Либо, для указания того, что количество идентификаторов вызовов равно 0, используют другие информационные элементы, и значение «Идентификатора вызова» не приводится. То есть, длина информационного элемента списка идентификаторов вызовов составляет в этот момент 2 октета (байта), указывая на то, что все идентификаторы Call-ID заняты вызовами, обслуживаемыми элементом NE, который инициировал запрос. Для элемента NE, поддерживающего функцию AoIP, этот способ можно использовать для разъединения всех вызовов данного NE и подачи команды на равноправный NE для разъединения всех вызовов, связанных с данным NE. Для элемента NE, который не поддерживает функцию AoIP (то есть, имеется просто интерфейс А на основе AoTDM), сообщение о сбросе можно использовать для подачи команды на равноправный элемент NE на разъединение всех вызовов (то есть, всех вызовов на основе AoTDM), связанных с элементом NE, инициировавшим запрос, поскольку сообщение о сбросе ресурсов и сообщение с подтверждением сброса ресурсов не могут быть идентифицированы.

Таблица 4
8	7	6	5	4	3	2	1
Call-ID	Октет 1
Длина Call-ID (старший значащий бит)	Октет 2
Длина Call-ID (младший значащий бит)	Октет 3
Call-ID 1	Октет 4-7
Call-ID n	n*4-n*4+3

Кроме того, для повышения эффективности разъединения вызова эту форму можно использовать для разъединения всех вызовов на основе AoIP, обслуживаемых контроллером BSC и центром MSC. Для варианта AoTDM при разъединении всех вызовов используют существующее сообщение о сбросе и подтверждении сброса.

Форма В. В вариантах осуществления настоящего изобретения сообщение без установления соединения с запросом SCCP и сообщение без установления соединения с подтверждением SCCP могут составлять пару вновь созданных сообщений без установления соединения SCCP (то есть, существующее сообщение о сбросе/сообщение с подтверждением сброса или существующее сообщение о сбросе ресурсов/сообщение с подтверждением сброса ресурсов). Эти сообщения используют для подачи на равноправный NE команды на сброс ресурсов и инициирование всех вызовов на основе AoIP, связанных с данным элементом NE. Для разъединения всех вызовов на основе AoTDM используют существующее сообщение о сбросе и сообщение с подтверждением сброса.

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

Новое представление сообщения о сбросе может выглядеть следующим образом:

ИНФОРМАЦИОННЫЙ ЭЛЕМЕНТ	Направление	Длина
Тип сообщения	В обе стороны	1 байт
Причина	В обе стороны	3-4 байта
Тип вызова	В обе стороны	2 байта

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

8	7	6	5	4	3	2	1
Идентификатор элемента	октет 1
Пауза (не используется)	Указатель типа	октет 2

00: все вызовы независимо от типа

01: все вызовы на основе AoTDM

10: все вызовы на основе AoIP

11: зарезервировано (не определено)

Если в сообщении о сбросе содержится информационный элемент «тип вызова», то он указывает, что отправляющий NE поддерживает функцию интерфейса AoIP; в противном случае отправляющий NE не доставляет информационный элемент «тип вызова» в сообщении о сбросе. В частности, если отправляющий NE отправляет сообщение о сбросе без информационного элемента «тип вызова», и принимающий NE не поддерживает сообщение о сбросе, доставляющее информационный элемент «тип вызова», то принимающий NE разъединяет все вызовы (в действительности, только вызовы на основе AoTDM), связанные с отправляющим NE, что аналогично процедуре разъединения вызова в известном уровне техники. Если принимающий NE поддерживает сообщение о сбросе, доставляющее информационный элемент «тип вызова», то, когда определяют, что отправляющий NE имеет только вызовы на основе AoTDM, разъединяют все вызовы (в действительности вызовами на основе AoTDM являются вызовы, связанные как с отправляющим NE, так и с принимающим NE), связанные с отправляющим NE.

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

Информационный элемент «тип вызова» используется в качестве примера в случае, когда для дифференциации вызовов используют только тип интерфейса на плоскости пользователя интерфейса А. В действительности, для дифференциации вызовов можно также использовать и другие формы дифференциации. Вдобавок, при увеличении или уменьшении количества типов вызовов также необходимо увеличить количество битов, необходимых для информационного элемента «тип вызова». В этом случае только требуется, чтобы сетевые элементы (NE) на обеих сторонах трактовали тип вызова одинаковым образом.

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

Этап 501. Станция MS отправляет сообщение о разъединении на сервер MSC через контроллер BSC, запрашивая разъединение линии связи вызова. BSC направляет сообщение о разъединении на сервер MSC.

Этап 502. Приняв сообщение о разъединении, сервер MSC отправляет сообщение с запросом разъединения на контроллер BSC. BSC перенаправляет сообщение с запросом разъединения на станцию MS.

Этап 503. Приняв сообщение с запросом разъединения, станция MS останавливает все таймеры управления вызовами, разъединяет линию управления мобильностью (MM) и отправляет на сервер MSC через контроллер BSC сообщение о завершении разъединения.

Этап 504. Приняв сообщение о завершении разъединения, сервер MSC также останавливает все таймеры управления вызовом, разъединяет линию MM, освобождает ресурсы, связанные с вызовом станции MS, например ресурсы конечной точки с мультиплексированием с временным разделением (TDM) и конечной точки IP, выделенные вызову на шлюзе MGW, изменяет статус Call-ID, соответствующий данному вызову, со значения «занято» на значение «свободно» и отправляет на контроллер BSC сообщение с командой отбоя для прикладной части подсистемы управления базовых станций (BSSMAP).

Этап 505. Приняв от сервера MSC сообщение с командой отбоя протокола BSSMAP, контроллер BSC разъединяет все соединения с MS и освобождает ресурсы радиоинтерфейса и наземной связи данного вызова, изменяет статус Call-ID, соответствующий данному вызову, со значения «занято» на значение «свободно» и отправляет на сервер MSC сообщение о завершении отбоя по протоколу BSSMAP.

Этап 506. Сервер MSC отправляет на шлюз MGW сообщение с запросом на удаление конечной точки.

Этап 507. Шлюз MGW освобождает ресурсы, такие как конечная точка TDM или конечная точка IP, выделенные вызову, и отправляет на сервер MSC ответное сообщение об удалении конечной точки.

В этом варианте осуществления нет никаких ограничений на последовательность выполнения сервером MSC этапов отправки сообщения с командой отбоя и изменения статуса Call-ID вызова. Вдобавок, нет никаких ограничений на последовательность выполнения сервером MSC этапов отправки сообщения с командой отбоя и освобождения установленных ресурсов, связанных с данным вызовом, например, путем удаления на шлюзе MGW конечной точки TDM и конечной точки IP, созданных для данного вызова.

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

Этап 511. Сервер MSC отправляет на станцию MS через контроллер BSC сообщение о разъединении, запрашивая разъединение линии связи для данного вызова. Контроллер BSC перенаправляет сообщение о разъединении на станцию MS.

Этап 512. Приняв сообщение о разъединении, станция MS отправляет на контроллер BSC сообщение с запросом разъединения. Контроллер BSC перенаправляет сообщение с запросом разъединения на сервер MSC.

Этап 513. Приняв сообщение с запросом разъединения, сервер MSC останавливает все таймеры управления вызовом, разъединяет линию MM и отправляет на станцию MS сообщение о завершении разъединения через контроллер BSC.

Этап 514. Приняв сообщение о завершении разъединения, станция MS также останавливает все таймеры управления вызовом, разъединяет линию MM, освобождает ресурсы, связанные с вызовом, например, освобождает ресурсы конечной точки TDM и конечной точки IP, выделенные данному вызову на шлюзе MGW, и изменяет статус Call-ID, соответствующий вызову, со значения «занято» на значение «свободно».

Этап 515. Сервер MSC отправляет на контроллер BSC сообщение с командой отбоя по протоколу BSSMAP. Далее процедура повторяет шаги 505-507.

На Фиг. 8 представлена блок-схема еще одного способа разъединения вызова согласно одному варианту осуществления настоящего изобретения. В качестве примера здесь рассматривается случай, когда BSC-источник разъединяет вызов после передачи обслуживания вызова между контроллерами BSC, обслуживаемыми одним и тем же центром MSC. Например, станция MS осуществляет голосовую связь под управлением контроллера BSC 1 и использует Call-ID 1 для идентификации вызова, после чего происходит передача обслуживания станции MS на целевой контроллер BSC 2. Подробности этой процедуры состоят в следующем.

Этап 601. Контроллер BSC 1 отправляет на сервер MSC сообщение о необходимости передачи обслуживания, содержащее запрос на передачу обслуживания вызова станции MS на подходящую соту.

Сообщение о необходимости передачи обслуживания доставляет кодек RanC1 (Ran Codec), используемый в настоящий момент станцией MS и контроллером BSC 1.

Этап 602. Приняв сообщение о необходимости передачи обслуживания, сервер MSC выбирает соту из числа рекомендованных сот, обслуживаемых контроллером BSC 2, в качестве целевой соты станции MS, отправляет сообщение ADD.Req для добавления конечной точки на шлюз MGW, причем указанное сообщение содержит информацию о рекомендованном предпочтительном кодеке Ranc (pRanc) и информацию о конечных точках, соответствующую контроллеру BSC 2. Например, информация о конечных точках может включать в себя тип конечной точки, создаваемой шлюзом MGW, то есть, конечную точку TDM и/или конечную точку IP.

Станция MS обычно использует услуги передачи речи, обеспечиваемые контроллером BSC 1. Контроллеры BSC 1 и BSC 2 принадлежат одному и тому же центру MSC. Когда для станции MS необходима передача обслуживания с BSC 1 на BSC 2, то, поскольку в этом случае сервер MSC не имеет информации о возможностях поддержки Ranc текущего BSC 2 (в динамике) и типе интерфейса А, необходимо создать для BSC 2 на шлюзе MGW конечную точку IP и/или конечную точку TDM перед передачей обслуживания на BSC 2, с тем, чтобы обеспечить быструю и успешную передачу обслуживания вызова.

Этап 603. Шлюз MGW создает конечную точку TDM и/или конечную точку IP для BSC 2 в соответствии с принятым сообщением ADD.Req для добавления конечных точек и отправляет обратно сообщение ADD.Reply для добавления конечных точек. Сообщение ADD.Reply доставляет информацию о созданной конечной точке.

Этап 604. Сервер MSC принимает сообщение ADD.Reply и отправляет на BSC 2 сообщение с запросом передачи обслуживания.

Сообщение с запросом передачи обслуживания содержит идентификатор Call-ID 2, выделенный центром MSC для станции MS, обслуживаемой BSC 2. Сервер MSC изменяет статус Call-ID 2 со значения «свободно» на значение «занято». Сообщение с запросом передачи обслуживания также доставляет информацию, такую как MSC-PCL (речевой код составлен в рекомендованном порядке, при этом обновленный pRanC представляет собой рекомендованный предпочтительный речевой код) и выделенную конечную точку TDM и/или конечную точку IP на шлюзе MGW. Информация о конечной точке TDM может включать в себя ячейку CIC. Значение ячейки CIC может быть равно значению CIC конечной точки TDM, созданной шлюзом MGW.

Этап 605. Если приняв сообщение с запросом передачи обслуживания, контроллер BSC 2 может идентифицировать ячейку Call-ID, содержащуюся в этом сообщении, то используемый вызов идентифицируется идентификатором Call-ID 2, содержащимся в этом сообщении, а статус Call-ID 2 изменяется со значения «свободно» на значение «занято». Данному вызову выделяют ресурсы, и одновременно отправляют обратно сообщение с подтверждением запроса передачи обслуживания. Как возможный вариант, если контроллер BSC 2 может идентифицировать ячейку Call-ID, доставляемую в сообщении с запросом передачи обслуживания, и данный вызов поддерживается контроллером BSC 2, то независимо от того, какой режим (TDM или IP) используется в линии связи интерфейса А плоскости пользователя, данный вызов идентифицируется только идентификатором Call-ID в указанном сообщении, а CIC линии связи интерфейса А плоскости пользователя или пара конечных точек IP указывает только физическую линию связи для данного вызова.

Этап 606. Сервер MSC отправляет сообщение с командой на передачу обслуживания контроллеру BSC 1, причем сообщение доставляет тип кодирования (RanC2), выбранный контроллером BSC 2.

Этап 607. Контроллер BSC 1 перенаправляет на станцию MS сообщение с командой на передачу обслуживания.

Этап 608. Успешно осуществляется передача обслуживания станции MS на заданную соту, обслуживаемую целевым контроллером BSC 2. Контроллер BSC 2 отправляет на сервер MSC сообщение о завершении передачи обслуживания, подтверждающее успешность передачи обслуживания.

Этап 609. Сервер MSC освобождает ресурсы, изначально выделенные станции MS, обслуживаемой BSC 1, например, отсоединяя конечную точку TDM или конечную точку IP, выделенную для BSC 1 на шлюзе MGW, изменяет статус Call-ID 1, соответствующий данному вызову, со значения «занято» на значение «свободно» и отправляет на контроллер BSC 1 сообщение с командой отбоя по протоколу BSSMAP.

Этап 610. Контроллер BSC 1 принимает сообщение с командой отбоя по протоколу BSSMAP, разъединяет все соединения со станцией MS и освобождает соответствующие ресурсы радиоинтерфейса и наземной связи, изменяет статус Call-ID 1, соответствующий данному вызову, со значения «занято» на значение «свободно» и отправляет на контроллер BSC 1 сообщение о завершении отбоя по протоколу BSSMAP, подтверждающее завершение разъединения.

Этап 611. В соответствии с типом конечной точки, указанным в сообщении с подтверждением передачи обслуживания, сервер MSC дает команду шлюзу MGW на удаление созданных конечных точек, типы которых отличаются от типов, выбранных станцией MS в контроллере BSC 2.

В этом варианте осуществления нет никаких ограничений на последовательность выполнения сервером MSC этапов отправки на BSC 1 сообщения с командой отбоя и изменения статуса Call-ID 1. Вдобавок, нет никаких ограничений на порядок выполнения сервером MSC этапов отправки сообщения с командой отбоя и освобождения установленных ресурсов, связанных с BSC 1, например, путем подачи команды на шлюз MGW на удаление конечной точки TDM и/или конечной точки IP, созданной для данного вызова.

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

Этап 701. Контроллер BSC отправляет на сервер MSC сообщение полного уровня 3. Это сообщение доставляет BSC-SCL1, предоставляющее информацию о речевом кодировании, поддерживаемом контроллером BSC 1, и типе IP, поддерживаемом контроллером BSC 1 на плоскости пользователя интерфейса А.

Этап 702. Станция MS отправляет на сервер MSC сообщение об установке прикладной части для прямой передачи (DTAP). Это сообщение доставляет MS-SCL, предоставляющее информацию о речевом кодировании, поддерживаемом станцией MS.

Этап 703. Сервер MSC принимает сообщение полного уровня 3 и сообщение об установке, отправленное станцией MS, и выделяет ресурсы для данного вызова, например, выделяет данному вызову ресурсы конечной точки TDM и/или ресурсы конечной точки IP, изменяет статус Call-ID данного вызова со значения «свободно» на значение «занято» и отправляет на BSC сообщение с запросом выделения. Это сообщение доставляет Call-ID, выделенный сервером MSC данному вызову, список рекомендованных кодов и информацию о конечной точке TDM и/или конечной точке IP, созданную шлюзом MGW.

Этап 704. Контроллер BSC принимает сообщение с запросом выделения. Как возможный вариант, если BSC может идентифицировать ячейку Call-ID, содержащуюся в сообщении с запросом выделения, и данный вызов поддерживается контроллером BSC, то независимо от того, какой режим (TDM или IP) используется линией связи интерфейса А плоскости пользователя, данный вызов идентифицируется только идентификатором Call-ID, содержащимся в указанном сообщении, а CIC линии связи интерфейса А плоскости пользователя или пара конечных точек IP указывает только физическую линию связи для данного вызова. Но, если произошел отказ выполнения процедуры выделения контроллером BSC, то контроллер BSC поддерживает состояние выделенного идентификатора Call-ID со значением «свободно» и отправляет на сервер MSC сообщение об отказе выделения.

Этап 705. Сервер MSC принимает сообщение об отказе выделения и освобождает ресурсы вызова, выделенные станции MS, обслуживаемой контроллером BSC, например, освобождает ресурсы конечной точки TDM и/или ресурсы конечной точки IP, выделенные данному вызову на шлюзе MGW, и изменяет статус Call-ID данного вызова со значения «занято» на значение «свободно».

В этом варианте осуществления нет никаких ограничений на последовательность выполнения сервером MSC этапов отправки на BSC сообщения с командой отбоя и изменения состояния Call-ID данного вызова. Вдобавок, нет никаких ограничений на порядок выполнения сервером MSC этапов отправки сообщения с командой отбоя и освобождения ресурсов, связанных с данным вызовом, например, путем подачи на шлюз MGW команды на удаление конечной точки TDM и/или конечной точки IP, созданной для данного вызова.

На Фиг. 10 представлена блок-схема другого способа разъединения вызова согласно одному варианту осуществления настоящего изобретения. В качестве примера здесь рассматривается случай, когда происходит отказ в передаче обслуживания вызова между контроллерами BSC, находящимися под управлением одного и того же центра MSC, поскольку целевой контроллер BSC не получает вызов. Предположим, что BSC-источник обозначен как BSC 1, а целевой BSC - как BSC 2, и предположим, что терминал MS выполняет вызов обычным образом под управлением BSC 1, а Call-ID 1 идентифицирует вызов, обслуживаемый BSC 1, и тогда подробная процедура будет выглядеть следующим образом.

Этап 801. Контроллер BSC 1 отправляет на сервер MSC сообщение о необходимости передачи обслуживания, запрашивая передачу обслуживания вызова станции MS на подходящую соту. Сообщение о необходимости передачи обслуживания доставляет кодек RanC1 (Ran Codec), используемый в данный момент станцией MS и контроллером BSC 1.

Этап 802. Сервер MSC выбирает соту из числа сот, обслуживаемых контроллером BSC 2, в качестве целевой соты для данной MS, отправляет на BSC 2 сообщение с запросом передачи обслуживания после успешного выделения соответствующих ресурсов для BSC 2, например, путем создания спаренной конечной точки TDM и конечной точки IP для BSC 2 на шлюзе MGW. Это сообщение доставляет идентификатор Call-ID 2, выделенный вызову, под управлением BSC 2, и изменяет статус Call-ID 2 со значения «свободно» на значение «занято». Данное сообщение, кроме того, доставляет список рекомендованных кодов и информацию о созданной конечной точке TDM и конечной точке IP.

Этап 803. Контроллер BSC 2 использует Call-ID 2 для идентификации используемого вызова. Если произошел отказ в выделении ресурсов, или Call-ID 2 уже выделен другому вызову под управлением BSC 2 (то есть, статус Call-ID 2 имеет значение «занято»), контроллер BSC 2 поддерживает неизменным статус Call-ID 2 и отправляет на сервер MSC сообщение об отказе в передаче обслуживания, содержащее значение причины отказа.

Этап 804. Сервер MSC принимает сообщение об отказе в передаче обслуживания, освобождает ресурсы, такие как конечная точка, выделенная контроллеру BSC 2, и изменяет статус Call-ID 2, выделенный BSC 2, со значения «занято» на значение «свободно». Как возможный вариант, сервер MSC может отправлять на BSC 2 сообщение об отклонении затребованной передачи обслуживания, указывающее, что передача обслуживания потерпела неудачу.

Затем контроллер BSC 1 поддерживает вызов станции MS, идентифицированный идентификатором Call-ID 1.

В этом варианте осуществления нет никаких ограничений на последовательность выполнения сервером MSC этапов отправки на BSC 2 сообщения с командой отбоя и изменения состояния Call-ID данного вызова. Вдобавок, нет никаких ограничений на порядок выполнения сервером MSC этапов отправки сообщения с командой отбоя и освобождения установленных ресурсов, связанных с вызовом, обращающимся к BSC 2, например, путем подачи на шлюз MGW команды на удаление конечной точки TDM и/или конечной точки IP, созданной для данного вызова.

На Фиг. 11 представлена блок-схема другого способа разъединения вызова согласно одному варианту осуществления настоящего изобретения. В качестве примера в этом варианте осуществления рассматривается случай отказа в передаче обслуживания между контроллерами BSC, обслуживаемыми одним и тем же центром MSC, из-за того, что MSC-источник получил запрос на разъединение вызова при передаче обслуживания. Предположим, что BSC-источник обозначен как BSC 1, целевой BSC обозначен как BSC 2, терминал MS осуществляет вызов обычным образом под управлением BSC 1, и Call-ID 1 идентифицирует вызов, обслуживаемый контроллером BSC 1; тогда подробная процедура состоит в следующем.

Этап 901. Контроллер BSC 1 отправляет на сервер MSC сообщение о необходимости передачи обслуживания, содержащее запрос на передачу обслуживания вызова станции MS на подходящую соту. Сообщение о необходимости передачи обслуживания содержит кодек RanC1 (Ran Codec), используемый в данный момент станцией MS и контроллером BSC 1.

Этап 902. Сервер MSC выбирает соту из числа рекомендованных сот, обслуживаемых контроллером BSC 2, в качестве целевой соты для данной MS и отправляет на BSC 2 информацию с запросом передачи обслуживания после успешного выделения соответствующих ресурсов для BSC 2, например, путем создания спаренной конечной точки TDM и конечной точки IP для BSC 2 на шлюзе MGW. Это сообщение доставляет идентификатор Call-ID 2, выделенный вызову под управлением BSC 2, и изменяет статус Call-ID 2 со значения «свободно» на значение «занято». Данное сообщение, кроме того, доставляет список рекомендованных кодов и информацию о созданной конечной точке TDM и конечной точке IP.

Этап 903. Контроллер BSC 2 использует Call-ID 2 для идентификации данного вызова, то есть, изменяет статус Call-ID 2 вызова со значения «свободно» на значение «занято», выделяет ресурсы и отправляет обратно сообщение с подтверждением запроса передачи обслуживания.

Этап 904. Сервер MSC отправляет на станцию MS через контроллер BSC 1 сообщение с командой передачи обслуживания, давая команду станции MS передать обслуживание на определенную соту под управлением целевого контроллера BSC 2.

Этап 905. Станция MS принимает сообщение с командой передачи обслуживания и выполняет передачу обслуживания, но передача обслуживания не происходит. Тогда станция MS отправляет на BSC 1 информацию об отказе передачи обслуживания.

Этап 906. Контроллер BSC 1 поддерживает вызов, идентифицированный идентификатором Call-ID 1, и в то же время отправляет на сервер MSC сообщение об отказе передачи обслуживания.

Этап 907. Сервер MSC принимает сообщение об отказе в передаче обслуживания, дает команду шлюзу MGW освободить ресурсы, выделенные BSC 2, такие как созданные конечная точка TDM и конечная точка IP, изменяет статус Call-ID 2 со значения «занято» на значение «свободно» и отправляет на BSC 2 сообщение с командой отбоя.

Этап 908. Контроллер BSC 2 принимает сообщение с командой отбоя, освобождает все ресурсы радиоинтерфейсов и наземной связи, подготовленные для станции MS, изменяет статус Call-ID 2 со значения «занято» на значение «свободно» и отправляет на сервер MSC сообщение о завершении отбоя.

В этом варианте осуществления нет никаких ограничений на последовательность выполнения сервером MSC этапов отправки на BSC 2 сообщения с командой отбоя и изменения статуса Call-ID 2 вызова. Вдобавок, нет никаких ограничений на порядок выполнения сервером MSC этапов отправки сообщения с командой отбоя и освобождения установленных ресурсов, связанных с вызовом, обращающимся к BSC 2, например, путем подачи команды шлюзу MGW на удаление конечной точки TDM и/или конечной точки IP, созданных для данного вызова.

На Фиг. 12 представлена блок-схема другого способа разъединения вызова согласно одному варианту осуществления настоящего изобретения. В качестве примера в этом варианте осуществления рассматривается случай отказа в передаче обслуживания между контроллерами BSC, обслуживаемыми одним и тем же центром MSC, из-за того, что MSC-источник получил запрос на разъединение вызова при передаче обслуживания. BSC-источник обозначен как BSC 1, целевой BSC обозначен как BSC 2, терминал MS осуществляет вызов обычным образом под управлением BSC 1, и Call-ID 1 идентифицирует вызов, обслуживаемый контроллером BSC 1; тогда подробная процедура состоит в следующем.

Этап 1001. BSC 1 отправляет на сервер MSC сообщение о необходимости передачи обслуживания, содержащее запрос на передачу обслуживания вызова станции MS на подходящую соту.

Этап 1002. Сервер MSC выбирает соту из числа рекомендованных сот, обслуживаемых контроллером BSC 2, в качестве целевой соты для данной MS и отправляет на BSC 2 информацию с запросом передачи обслуживания после успешного выделения соответствующих ресурсов для BSC 2. Это сообщение доставляет идентификатор Call-ID 2, выделенный вызову под управлением BSC 2, и изменяет статус Call-ID 2 со значения «свободно» на значение «занято». Данное сообщение, кроме того, доставляет список рекомендованных кодов и информацию о созданной конечной точке TDM и конечной точке IP.

Этап 1003. Контроллер BSC 2 принимает сообщение с запросом передачи обслуживания и использует Call-ID 2 для идентификации данного вызова, то есть изменяет статус Call-ID 2 вызова со значения «свободно» на значение «занято», выделяет ресурсы и отправляет обратно сообщение с подтверждением запроса передачи обслуживания.

Этап 1004. Сервер MSC отправляет на станцию MS через контроллер BSC 1 сообщение с командой передачи обслуживания, давая команду станции MS передать обслуживание на определенную соту под управлением целевого контроллера BSC 2.

Этап 1005. Станция MS принимает команду на передачу обслуживания и выполняет передачу обслуживания, но во время этой операции контроллер BSC 1 отправляет на сервер MSC сообщение с запросом отбоя по каким-либо причинам (например, BSC 1 не принял сообщение об отказе передачи обслуживания, отправленное станцией MS, после того как истекло время таймера T8). Таким образом, BSC 1 отправляет на сервер MSC сообщение с запросом отбоя, и в то же время контроллеру BSC 1 необходимо зарезервировать Call-ID 1 и соответствующие ресурсы, выделенные данному вызову.

Этап 1006. Сервер MSC принимает сообщение с запросом отбоя и определяет, что вызов не может продолжаться. Тогда сервер MSC освобождает все ресурсы, выделенные станции MS, и изменяет статус Call-ID 1 и Call-ID 2 со значения «занято» на значение «свободно». Затем сервер MSC отправляет каждому контроллеру BSC 1 и BSC 2 сообщение с командой отбоя.

Этап 1007. Контроллеры BSC 1 и BSC 2 принимают сообщение с командой отбоя, освобождают все ресурсы, подготовленные для станции MS, и каждый контроллер (BSC 1 и BSC 2) изменяет статус Call-ID 1 и Call-ID 2 со значения «занято» на значение «свободно». Контроллеры BSC 1 и BSC 2 соответствующим образом отправляют обратно на сервер MSC сообщение о завершении отбоя.

В этом варианте осуществления нет никаких ограничений на последовательность выполнения сервером MSC этапов отправки на BSC 1 и BSC 2 сообщений с командой отбоя и изменения статуса Call-ID 1 и Call-ID 2. Вдобавок, нет никаких ограничений на порядок выполнения сервером MSC этапов отправки сообщения с командой отбоя и освобождения установленных ресурсов, связанных с вызовом, обращающимся к BSC 2, например, путем подачи команды шлюзу MGW на удаление конечной точки TDM и/или конечной точки IP, созданных для данного вызова.

На Фиг. 13 представлена блок-схема другого способа разъединения вызова согласно одному варианту осуществления настоящего изобретения. В качестве примера в этом варианте рассматривается случай отказа в передаче обслуживания между контроллерами BSC, обслуживаемыми одним и тем же центром MSC, из-за того, что в сервере MSC произошел сбой при передаче обслуживания. Предположим, что BSC-источник обозначен как BSC 1, целевой BSC обозначен как BSC 2, терминальная MS осуществляет вызов обычным образом под управлением BSC 1, и Call-ID 1 идентифицирует вызов, обслуживаемый контроллером BSC 1. Подробная процедура состоит в следующем.

Этап 1101. BSC 1 отправляет на сервер MSC сообщение о необходимости передачи обслуживания, содержащее запрос на передачу обслуживания вызова станции MS на подходящую соту.

Этап 1102. Сервер MSC выбирает соту из числа рекомендованных сот, обслуживаемых контроллером BSC 2, в качестве целевой соты для данной MS и отправляет на BSC 2 сообщение с запросом передачи обслуживания после успешного выделения соответствующих ресурсов для BSC 2. Это сообщение доставляет идентификатор Call-ID 2, выделенный вызову под управлением BSC 2, и изменяет статус Call-ID 2 со значения «свободно» на значение «занято». Данное сообщение, кроме того, доставляет список рекомендованных кодов и информацию о созданной конечной точке TDM и конечной точке IP.

Этап 1103. Контроллер BSC 2 принимает сообщение с запросом передачи обслуживания и использует Call-ID 2 для идентификации вызова, то есть изменяет статус Call-ID 2 со значения «свободно» на значение «занято», выделяет ресурсы и отправляет обратно сообщение с подтверждением запроса передачи обслуживания.

Этап 1104. Сервер MSC отправляет на станцию MS через контроллер BSC 1 сообщение с командой передачи обслуживания, давая команду станции MS передать обслуживание на определенную соту под управлением целевого контроллера BSC 2.

В противном случае, перед отправкой сообщения с командой передачи обслуживания сервер MSC обнаруживает появление отказа. Тогда сервер MSC освобождает все ресурсы, выделенные станции MS, и изменяет статус Call-ID 1 и Call-ID 2 со значения «занято» на значение «свободно». Сервер MSC отправляет сообщение с командой отбоя на контроллеры BSC 1 и BSC 2 соответственно.

Этап 1105. Контроллеры BSC 1 и BSC 2 освобождают все ресурсы, подготовленные для станции MS, и каждый из них изменяет статусы Call-ID 1 и Call-ID 2 со значения «занято» на значение «свободно». BSC 1 и BSC 2 отправляют обратно на сервер MSC сообщение о завершении отбоя.

В этом варианте осуществления нет никаких ограничений на последовательность выполнения сервером MSC этапов отправки на BSC 1 и BSC 2 сообщения с командой отбоя и изменения статусов Call-ID 1 и Call-ID 2. Вдобавок, нет никаких ограничений на порядок выполнения сервером MSC этапов отправки сообщения с командой отбоя и освобождения установленных ресурсов для данного вызова, например, путем подачи команды шлюзу MGW на удаление конечной точки TDM и/или конечной точки IP, созданных для данного вызова.

На Фиг. 14 представлена схема устройства для разъединения вызова согласно одному варианту осуществления изобретения. Устройство включает в себя модуль 1 освобождения ресурсов и модуль 2 изменения статуса.

Модуль 1 освобождения ресурсов сконфигурирован для освобождения ресурсов, связанных с завершенным вызовом.

Модуль 2 изменения статуса сконфигурирован для изменения статуса Call-ID завершенного вызова со значения «занято» на значение «свободно».

Согласно данному варианту осуществления, устройство дополнительно включает в себя первый приемный модуль 3. Первый приемный модуль 3 сконфигурирован для приема от контроллера базовой станции (BSC) сообщения от отказе выделения в ходе процедуры выделения вызова; или приема от целевого BSC сообщения об отказе передачи обслуживания после отказа передачи обслуживания вызова в ходе процедуры передачи обслуживания вызова, причем сообщение об отказе в передаче обслуживания доставляет значение причины отказа; или приема от BSC-источника сообщения об отказе передачи обслуживания после отказа передачи обслуживания вызова под управлением BSC-источника в ходе процедуры передачи обслуживания вызова, причем сообщение об отказе передачи обслуживания доставляет значение причины отказа; или приема сообщения с запросом отбоя от BSC-источника в ходе процедуры передачи обслуживания вызова. Устройство дополнительно включает в себя модуль 4 отправки команды отбоя, сконфигурированный для изменения состояния Call-ID вызова и отправки на BSC сообщения с командой отбоя.

Согласно этому варианту осуществления, устройство дополнительно включает в себя второй приемный модуль 5. Второй приемный модуль 5 сконфигурирован для приема ресурсов вызова, разъединенного контроллером BSC, и изменения статуса Call-ID данного вызова со значения «занято» на значение «свободно».

На Фиг. 15 представлена схема устройства для разъединения вызова согласно другому варианту осуществления изобретения. Устройство включает в себя модуль 6 отправки сообщения о сбросе и модуль 7 приема ответа. Модуль 6 отправки сообщения о сбросе сконфигурирован для освобождения ресурсов, связанных с данным вызовом, изменения статуса Call-ID вызова со значения «занято» на значение «свободно» и отправки на равноправный сетевой элемент NE сообщения о сбросе ресурсов, если NE обнаруживает, что Call-ID вызова неправильный и/или вызов неправильный, и/или принято сообщение с запросом эксплуатации и сопровождения. Модуль 7 приема ответа сконфигурирован для приема ресурсов вызова, освобожденных равноправным элементом NE, изменения статуса Call-ID данного вызова со значения «занято» на значение «свободно» и отправки обратно (сразу или позднее) сообщения с подтверждением сброса ресурсов.

В данном варианте осуществления модуль 6 отправки сообщения о сбросе, в частности, включает в себя блок обнаружения, блок освобождения и блок отправки. Блок обнаружения сконфигурирован для обнаружения того, является ли Call-ID неправильным и/или является вызов на стороне элемента NE неправильным, и/или является ли вызов на стороне равноправного NE неправильным, и обнаружения того, принято ли сообщение с запросом на эксплуатацию и сопровождение. Блок освобождения сконфигурирован для освобождения ресурсов, связанных с вызовом, и изменения статуса Call-ID вызова со значения «занято» на значение «свободно». Блок отправки сконфигурирован для отправки на равноправный элемент NE сообщения о сбросе ресурсов. Таким образом, блок освобождения сконфигурирован, в частности, для освобождения ресурсов, связанных с данным вызовом, когда обнаружено, что Call-ID неправильный и/или вызов на стороне NE или на стороне равноправного NE неправильный, и/или принят запрос на эксплуатацию и сопровождение.

На Фиг. 16 представлена структура устройства для разъединения вызова согласно другому варианту осуществления настоящего изобретения. Устройство включает в себя модуль 8 отправки сообщения SCCP и модуль 9 приема сообщения с подтверждением.

Модуль 8 отправки сообщения SCCP сконфигурирован для освобождения ресурсов, связанных со всеми вызовами, изменения статуса идентификаторов Call-ID всех вызовов со значения «занято» на значение «свободно» и отправки на равноправный NE сообщения без установления соединения с запросом SCCP, когда необходимо обеспечить отбой для всех вызовов.

Модуль 9 приема сообщения с подтверждением сконфигурирован для приема сообщения без установления соединения с подтверждением SCCP после того, как принимающий элемент NE успешно освободил ресурсы, связанные со всеми вызовами.

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

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