Результат интеллектуальной деятельности: ЗАМЕНА КОДЕКА НА А-ИНТЕРФЕЙСЕ, ОСНОВАННОМ НА ИНТЕРНЕТ-ПРОТОКОЛЕ

Одной из основных целей определения А-интерфейса, основанного на протоколе IP, является возможность избежать использования кодека стандарта G.711 на А-интерфейсе и, более того, вообще избежать любого транскодирования в соединении от мобильного телефона к мобильному телефону. Другими словами, цель состоит в том, чтобы сделать возможной сквозную работу без транскодирования (Transcoding-Free Operation, TrFO) в сетях GERAN.

Чтобы достигнуть этого, необходимо сквозное согласование кодека, когда соединение устанавливается впервые: две подсистемы базовых станций BSS, обслуживающие двух пользователей, сообщают свои возможности в отношении кодеков (для этого соединения, в этой конкретной соте) базовой сети при установке соединения. Затем базовая сеть окончательно решает использовать для этого конкретного соединения один из кодеков, совместно поддерживаемых обеими подсистемами BSS. В целом, описание этого механизма вместе с лежащей в его основе архитектурой приводится в документе 3 GPP Tdoc G2-080090: "Draft CR to TR 43.903-003: Input to chapter 5.2.3".

Однако когда хэндовер должен быть выполнен к соте, не поддерживающей кодек, который был согласован при установке соединения (например, кодек «х»), шлюз MGW, подключаемый к целевой подсистеме BSS (подсистеме BSS, включающей ту соту, куда перемещается подвижная станция), должен вставить ресурс транскодирования, чтобы выполнить транскодирование между кодеком «х» (согласованным при установке соединения и используемым на одном участке маршрута соединения) и кодеком «у» (используемым на другом участке маршрута соединения в целевой соте после хэндовера). Когда это случается, работа без транскодирования прерывается, и качество речи может быть ухудшено. Чтобы восстановить режим работы TrFО, должно быть начато повторное согласование кодека. Например, базовая сеть может запустить замену кодека (с «x» на «y») на участке маршрута соединения, где кодек «х» продолжает использоваться, чтобы подстроиться к другому участку маршрута соединения, где используется кодек «y». Если это возможно, шлюз MGW может удалить ресурс транскодирования из тракта и восстановить работу без транскодирования.

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

Одной из связанных с этим проблем является обеспечение механизма, посредством которого подсистема BSS сообщает базовой сети о кодеках, которые она поддерживает для текущего соединения, прежде чем базовая сеть запускает замену кодека на определенный кодек (то есть кодек «y» в вышеприведенном примере). Необходимо обратить внимание, что хотя подсистема BSS сообщает свои возможности в отношении кодеков при установлении соединения, это является динамической информацией, связанной с определенным моментом времени в определенной соте, и может изменяться во времени, например, вследствие состояния перегрузки (когда могут использоваться только полускоростные кодеки). Поэтому необходим механизм, чтобы обновлять эту информацию для текущего соединения.

Предложение для решения этой проблемы заключается в следующем:

1. Определение сообщения сигнализации, передаваемого центром MSC в подсистему BSS для инициирования отклика от подсистемы BSS о ее текущих возможностях в отношении кодеков для конкретного текущего соединения.

2. Определение сообщения сигнализации, передаваемого подсистемой BSS в центр MSC и содержащего текущие возможности в отношении кодеков (то есть BSS-PCL - список предпочитаемых кодеков подсистемы BSS (Preferred Codec List) и окончание IP/UDP (протокола пользовательских дейтаграмм) в подсистеме BSS, которое используется базовой сетью (в частности, шлюзом MGW) как пункт назначения для пользовательских данных, передаваемых новым кодеком.

Далее, идея заключается в повторном использовании существующих сообщений на А-интерфейсе: "Команда о хэндовере" (Handover Command) от центра MSC к подсистеме BSS (чтобы окончательно запустить замену кодека) и "Хэндовер завершен" (Handover Complete) от подсистемы BSS к центру MSC (чтобы подтвердить хэндовер/замену кодека центру MSC).

Сообщение, выпускаемое центром MSC для приема текущих возможностей подсистемы BSS в отношении кодеков, может быть названо как "Запрос замены кодека" (Codec Change Request). Но полагая, что на радиоинтерфейсе (возможно, внутри соты) для замены кодека, в конце концов, будет использоваться"Команда о хэндовере", имеет смысл назвать зондирующее сообщение от центра MSC как "Требование внутреннего хэндовера" (Internal Handover Request) или "Запрос внутреннего хэндовера" (Internal Handover Enquiry), чтобы минимизировать необходимые изменения. Это сообщение отличается от существующего "Запроса хэндовера" (Handover Request), передаваемого в целевую подсистему BSS во время этапа подготовки хэндовера между подсистемами BSS: его цель состоит в том, чтобы получить обратно данные об обновленных возможностях подсистемы BSS в отношении кодеков для обработки конкретного соединения, и никакая конкретная целевая сота не указывается в сообщении (главной целью является замена кодека, и не обязательно замена соты, и обычно в этом случае, в конце концов, будет запущен хэндовер внутри соты). С другой стороны, список MSC-PCL (MSC-Preferred Codec List) предпочитаемых центром MSC кодеков может быть включен в сообщение "Запрос внутреннего хэндовера", чтобы сообщить подсистеме BSS о предпочтительных для центра MSC кодеках. Подсистема BSS сможет тогда использовать эту информацию, чтобы определить возможную целевую соту, которая удовлетворяет таким требованиям.

После приема сообщения "Запрос внутреннего хэндовера" от центра MSC подсистема BSS отвечает сообщением "Требуемый внутренний хэндовер" (Internal Handover Required), содержащим:

- Целевую соту. Это должна быть сота, управляемая той же самой подсистемой BSS, и может быть той же самой сотой, где в настоящее время осуществляется текущее соединение. Альтернативно, это также может быть сота, где подсистема BSS может лучше удовлетворить предпочтения центра MSC в отношении кодека, выраженные в списке MSC-PCL, входящем в состав сообщения " Запрос внутреннего хэндовера ".

- Список с текущими возможностями в отношении кодека, то есть BSS-PCL, в соте, где подсистема BSS намеревается обработать соединение после хэндовера.

- Окончание IP/UDP в подсистеме BSS (IP/UDP Tbss), используемое как пункт назначения для пользовательских данных, передаваемых шлюзом MGW с окончательно выбранным кодеком центра MSC.

Это сообщение отличается от существующего "Требуемый хэндовер", передаваемого в центр MSC во время этапа подготовки хэндовера между подсистемами BSS: посылая это сообщение, подсистема BSS уже подтверждает возможность поддерживать соединение в целевой соте (которая управляется той же самой подсистемой BSS) вместе с информацией о поддерживаемом кодеке и используемом окончании IP/UDP, так что никакой последующий обмен сообщениями “Запрос хэндовера” / “Подтверждение запроса хэндовера” (Handover Request Acknowledge) не требуется на этапе подготовки.

При приеме сообщения "Требуемый внутренний хэндовер" от подсистемы BSS центр MSC выбирает новый кодек SC (Selected Codec, выбранный кодек), принимая во внимание список BSS-PCL и необходимость восстановить работу без транскодирования (TrFO).

Выбранный кодек SC и новое окончание IP/UDP Tbss в подсистеме BSS сообщаются шлюзу MGW для того, чтобы он мог добавить другое окончание к подсистеме BSS. Шлюз MGW подтверждает этот запрос, посылая назад центру MSC новое окончание IP/UDP в шлюзе MGW (IP/UDP Tmgw).

В этой точке во времени существующие сообщения используются в А-интерфейсе для запуска этапа выполнения хэндовера. В частности, для запуска замены кодека (и возможно замены соты, если это требуется подсистемой BSS), центром MSC в подсистему BSS передается сообщение "Команда о хэндовере", включающее выбранный кодек вместе с новым окончанием IP/UDP Tmgw. Существующая процедура хэндовера выполняется по радиоинтерфейсу, и тогда BSS окончательно подтверждает хэндовер/замену кодека центру MSC сообщением "Хэндовер завершен" (Handover Complete).

Вся процедура описана на фиг.1.

Описанный подход для замены кодека, запускаемой базовой сетью, может повторно использоваться также в случае хэндовера внутри подсистемы BSS к "несовместимой соте", то есть целевой соте, где должен использоваться кодек, который является несовместимым с кодеком, используемым в исходной соте. Например, это может быть в случае соты в условиях перегрузок, где могут использоваться только кодеки с половинной скоростью (и кодек, используемый перед хэндовером, несовместим с кодеками с половинной скоростью).

В этом сценарии хэндовер не может быть обработан внутренне в подсистеме BSS при информировании центра MSC только в конце процедуры сообщением "Хэндовер выполнен" (Handover Performed). Фактически, перед выполнением хэндовера подсистема BSS должна потребовать у базовой сети выбрать кодек, который может быть поддержан в целевой соте.

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

Процедура для хэндовера внутри подсистемы BSS к несовместимой соте описана на фиг.2.

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

Сокращения

Список ссылок

[1] 3 GPPTR 43.903 v 0.0.4.