Замена кодека на а-интерфейсе, основанном на интернет-протоколе
Изобретение относится к средствам замены кодека для текущих соединений на А-интерфейсе, основанном на Интернет-протоколе (IP), между подсистемой базовой станции и центром коммутации подвижной связи. Технический результат - увеличение скорости передачи. Передают команды о хэндовере от центра коммутации подвижной связи в подсистему базовой станции, причем сообщения сигнализации передают между подсистемой базовой станции и центом коммутации подвижной связи. Передают во время этапа подготовки от упомянутого центра коммутации подвижной связи в упомянутую подсистему базовой станции сообщения запроса внутреннего хэндовера, при этом упомянутое сообщение включает список предпочитаемых центром MSC кодеков. Передают во время этапа подготовки, в ответ на упомянутое сообщение запроса внутреннего хэндовера, от подсистемы базовой станции в центр коммутации подвижной связи сообщения требуемого внутреннего хэндовера, при этом упомянутое сообщение требуемого внутреннего хэндовера содержит целевую соту, список, содержащий текущие возможности в отношении кодеков в упомянутой целевой соте, и окончание IP/UDP в подсистеме базовой станции. 3 н. и 2 з.п. ф-лы, 2 ил.
Одной из основных целей определения А-интерфейса, основанного на протоколе 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).
Сокращения
| BSS | Base Station Subsystem - Подсистема базовой станции |
| BSC | Base Station Controller - Контроллер базовой станции |
| BTS | Base Transceiver Station - Базовая приемопередающая станция |
| GERAN | GSM/EDGE Radio Access Network - Сеть радиодоступа GSM/EDGE |
| IP | Internet Protocol - Интернет-протокол |
| MS | Mobile Station - Подвижная станция |
| MSC | Mobile Switching Centre - Центр коммутации подвижной связи |
| MGW | Media Gateway - Мультимедийный шлюз |
| PCL | Preferred Codec List - Список предпочтительных кодеков |
| SC | Selected Codec - Выбранный кодек |
| TrFO | Transcoder Free Operation - Работа без транскодера |
| UDP | User Datagram Protocol - Протокол пользовательских дейтаграмм |
Список ссылок
[1] 3 GPPTR 43.903 v 0.0.4.
1. Способ замены кодека для текущих соединений на А-интерфейсе, основанном на Интернет-протоколе (IP), между подсистемой базовой станции и центром коммутации подвижной связи, где функциональные возможности транскодирования расположены в медиашлюзе, при этом способ основан на процедуре хэндовера и содержит этапы подготовки и выполнения, этап выполнения включает передачу команды о хэндовере от центра коммутации подвижной связи в подсистему базовой станции, а сообщения сигнализации передают между подсистемой базовой станции и центром коммутации подвижной связи, отличающийся тем, что способ включает следующие шаги:
передачу, во время этапа подготовки, от упомянутого центра коммутации подвижной связи в упомянутую подсистему базовой станции сообщения запроса внутреннего хэндовера, при этом упомянутое сообщение включает список предпочитаемых центром MSC кодеков; и
передачу, во время этапа подготовки, в ответ на упомянутое сообщение запроса внутреннего хэндовера, от подсистемы базовой станции в центр коммутации подвижной связи сообщения требуемого внутреннего хэндовера, при этом упомянутое сообщение требуемого внутреннего хэндовера содержит целевую соту, список, содержащий текущие возможности в отношении кодеков в упомянутой целевой соте, и окончание IP/UDP в подсистеме базовой станции.
2. Способ по п.1, отличающийся тем, что упомянутое сообщение запроса внутреннего хэндовера передается центром коммутации подвижной связи в упомянутую подсистему базовой станции для инициирования отклика от упомянутой подсистемы базовой станции о текущих возможностях в отношении кодеков для конкретного текущего соединения.
3. Способ по п.1, отличающийся тем, что этап выполнения повторно использует на упомянутом А-интерфейсе, основанном на Интернет-протоколе, упомянутую команду о хэндовере от центра коммутации подвижной связи к подсистеме базовой станции и упомянутое сообщение о завершении хэндовера от подсистемы базовой станции к центру коммутации подвижной связи.
4. Подсистема базовой станции (BSS), содержащая средства, сконфигурированные для выполнения замены кодека для текущих соединений на А-интерфейсе, основанном на Интернет-протоколе, с этапом подготовки и этапом выполнения, при этом этап выполнения включает передачу сообщения о завершении хэндовера от подсистемы базовой станции к центру коммутации подвижной связи, отличающаяся тем, что упомянутые средства дополнительно сконфигурированы для приема, во время упомянутого этапа подготовки, сообщения запроса внутреннего хэндовера, при этом упомянутое сообщение запроса внутреннего хэндовера включает список предпочитаемых центром MSC кодеков; и
передачи, во время упомянутого этапа подготовки, сообщения требуемого внутреннего хэндовера в центр коммутации подвижной связи, при этом упомянутое сообщение требуемого внутреннего хэндовера содержит целевую соту, список, содержащий текущие возможности в отношении кодеков в упомянутой целевой соте, и окончание IP/UDP в подсистеме базовой станции.
5. Центр коммутации подвижной связи (MSC), содержащий средства, сконфигурированные для выполнения замены кодека для текущих соединений на А-интерфейсе, основанном на Интернет-протоколе, с этапом подготовки и этапом выполнения, при этом этап выполнения включает передачу команды о хэндовере от центра коммутации подвижной связи в подсистему базовой станции, отличающийся тем, что упомянутые средства дополнительно сконфигурированы для передачи во время этапа подготовки сообщения запроса внутреннего хэндовера в упомянутую подсистему базовой станции, и упомянутое сообщение запроса внутреннего хэндовера включает список предпочитаемых центром MSC кодеков, при этом упомянутые средства дополнительно сконфигурированы для приема, во время этапа подготовки, сообщения требуемого внутреннего хэндовера от подсистемы базовой станции, содержащего целевую соту, список, содержащий текущие возможности в отношении кодеков в целевой соте, и окончание IP/UDP в подсистеме базовой станции.
