Способ разъединения вызова и устройство для его осуществления
Иллюстрации
Показать всеЗаявленное изобретение относится к способу и устройству разъединения вызова. Технический результат заключается в эффективном использовании идентификатора вызова (Call-ID) и повышении доли успешных передач обслуживания вызова и доли успешных процедур выделения ресурсов для вызова. Для этого способ включает в себя освобождение ресурсов, связанных с вызовом, если сетевой элемент (NE) обнаруживает, что идентификатор (ID) вызова неправильный и/или вызов неправильный, и/или принято сообщение с запросом на эксплуатацию и сопровождение; изменение статуса Call-ID вызова со значения «занято» на значение «свободно» и отправку на равноправный NE сообщения с запросом подсистемы управления сигнализацией соединения (SCCP); и прием от равноправного NE сообщения без установления соединения с подтверждением SCCP, при этом равноправный NE сконфигурирован для освобождения ресурсов, связанных с вызовом, на стороне равноправного NE, и изменения статуса Call-ID вызова со значения «занято» на значение «свободно». При использовании способа и устройства, обеспеченных в упомянутых вариантах осуществления изобретения, идентификатор Call-ID также освобождается при освобождении ресурсов, связанных с вызовом. 4 н. и 12 з.п. ф-лы, 16 ил., 4 табл.
Реферат
ПЕРЕКРЕСТНЫЕ ССЫЛКИ НА РОДСТВЕННЫЕ ЗАЯВКИ
Данная заявка испрашивает приоритет патентной заявки Китая № 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 со значения «свободно» на значение «занято». Сообщение с запросом передачи обслуживания также доставляет информацию, такую ка