ОБЛАСТЬ ТЕХНИКИ
Настоящая заявка в целом относится к кодированию речи/аудио, и в частности к способу и устройству для форматирования полезной нагрузки для передачи данных многорежимного кодека речи/аудио.
УРОВЕНЬ ТЕХНИКИ
Проект партнерства третьего поколения 3GPP задает адаптивный многоскоростной (AMR) и адаптивный многоскоростной широкополосный (AMR-WB) в качестве обязательных речевых кодеков для голосовых услуг в сетях 3G. Эти кодеки также обязательны для услуги передачи голоса по IP-протоколу (VoIP) 3GPP, которая задается в мультимедийной телефонии 3GPP посредством мультимедийной подсистемы на базе IP (IMS). Руководящей спецификацией для обработки и взаимодействия со средой является TS 26.114 3GPP. Несмотря на обязательный статус этих кодеков в настоящее время в 3GPP проводятся действия для задания нового голосового кодека, который сделает возможным еще более высокое качество услуги, чем возможно при AMR-WB, кодека улучшенной голосовой услуги (EVS).
Однако внедрение нового кодека речи в систему речевой связи в некоторых отношениях может быть проблематичным. Одна проблема состоит в том, что всегда имеется парк унаследованного оборудования (терминалы и сетевая инфраструктура), который поддерживает только существующие кодеки 3GPP или только один из них, например AMR-WB, но не новый кодек. Это может приводить к проблемам совместимости, при которых связь между новым и унаследованным оборудованием невозможна, пока в системе не реализованы надлежащие механизмы. Традиционным способом решения этой проблемы является предоставление транскодеров, например, в шлюзах среды, которые преобразуют между новыми и старыми форматами кодирования, или предоставление унаследованных кодеков помимо нового кодека в новых терминалах, что позволяет выбирать унаследованный формат кодирования, когда устанавливается соединение с унаследованным терминалом. Этот последний способ требует, чтобы имелся обмен возможностями между терминалами перед фактическим речевым соединением, который идентифицирует общий кодек, который поддерживают оба терминала. В рамках IMS протокол описания сеанса (SDP) RFC 4566 IETF используется для осуществления этого обмена возможностями.
Тем не менее вышеописанные способы для обеспечения совместимости при внедрении нового кодека в систему связи являются не только возможностями, но и обладают различными недостатками. Предоставление транскодеров означает дополнительное оборудование, что повышает капиталовложение в сеть и эксплуатационные расходы. Транскодирование также ассоциируется с нежелательными ухудшениями качества речи. Использование обмена возможностями между терминалами перед вызовом является изящным способом, который, однако, не всегда возможен. Примерами того, где это не всегда возможно, являются конференц-связь нескольких участников, сценарии передачи обслуживания с мобильными пользователями, перемещающимися в соты без поддержки услуги мультимедийной телефонии для IMS (MTSI), передача голосовых сообщений. Также с точки зрения реализации терминала может быть нежелательно обеспечивать поддержку полного набора новых и унаследованных кодеков, так как это может увеличить расходы на реализацию и лицензирование технологии.
Следовательно, существует потребность в обеспечении внедрения новых речевых кодеков в телекоммуникационные системы, чтобы предоставлять повышенное качество обслуживания, в частности в системах 3GPP, поддерживая при этом обратную совместимость со старыми или унаследованными кодеками.
Поэтому третьей возможностью, выбранной 3GPP для взаимодействия кодека EVS с унаследованным оборудованием AMR-WB, является включение совместимых с AMR-WB режимов кодирования в качестве одной части кодека EVS, помимо полностью новых режимов работы. Этот подход уменьшает все обсуждаемые выше проблемы. Однако 3GPP не задает решения касательно того, как сигнализировать от UE отправляющей стороны к UE приемной стороны, какой из доступных режимов EVS, совместимый с AMR-WB или несовместимый, использован для кодирования и с какой скоростью передачи битов.
Одно возможное решение этой проблемы сигнализации раскрывается в документе US20120035918: "Method and arrangement for providing a backwards compatible payload format". Это решение относится к способам внедрения новых речевых кодеков в унаследованные системы. В частности, это решение раскрывает обратно совместимый формат полезной нагрузки, который допускает включение нового кодека речи. В конкретном применении этого решения совместимые с AMR-WB режимы кодека EVS пакетируются по транспортному протоколу реального времени (RTP) как пакеты AMR-WB в соответствии с RFC 4867 IETF. Тем не менее сигнальный бит включается в ранее неиспользуемые биты формата полезной нагрузки AMR-WB, чтобы предоставить возможность сигнализировать возможное использование новых, несовместимых режимов кодека EVS. Если устанавливается соответствующий бит в заголовке полезной нагрузки RTP, то это расценивается как сигнал того, что последующие информационные биты полезной нагрузки речи/аудио представляют поток двоичных сигналов, ассоциированный с новыми, несовместимыми режимами кодека EVS, а не с совместимыми с AMR-WB режимами.
Однако проблема с вышеописанным подходом из документа US20120035918 состоит в том, что соответствующий формат полезной нагрузки RTP для кодека EVS неминуемо использует заголовок полезной нагрузки RTP включенного унаследованного кодека (AMR-WB). В применениях, где ресурсы передачи сильно ограничены, такая служебная нагрузка нежелательна.
Чтобы решить эту проблему служебной нагрузки, существуют другие решения, которые вообще не используют заголовок полезной нагрузки RTP (примерный EVRC (усовершенствованный кодек с переменной скоростью) или кодек G.729 ITU-T). В таких случаях необходимая сигнальная информация, связанная с полезной нагрузкой, получается из других информационных элементов пакетов RTP, например, как информация, предоставленная в полях заголовка IP/UDP/RTP, которые отличаются от заголовка полезной нагрузки RTP. Одним важным информационным элементом, который может использоваться, является размер полезной нагрузки RTP или размер пакета. Если понятно, что каждый пакет RTP всегда содержит только один кадр кодированной речи/аудио (соответствующий, например, 20-миллисекундной речи/аудио), то скорость передачи битов, используемую для кодирования речевого/аудиосигнала, легко получить из размера полезной нагрузки RTP. Это практичное решение, если кодек использует только ограниченный и дискретный набор скоростей, и если режимы работы кодека непосредственно связаны с соответствующими скоростями передачи битов. Однако, если используется агрегирование кадров, означающее, что в пакете передается множество кодированных кадров речи/аудио, это решение работает не всегда. Это будет проиллюстрировано следующим образом: Предположим, что в каждом пакете RTP можно передавать вплоть до 2 кодированных кадров, и кодек имеет два режима кодека со скоростями 8 Кбит/с и 16 Кбит/с. Каждый кадр соответствует 20 мс. Теперь дополнительно предположим, что отправитель работает с агрегированием кадров и помещает два кадра в каждый пакет. В примере дополнительно предположим, что первый кадр пакета кодируется при 8 Кбит/с, означая, что он содержит 20 байт данных. Второй кадр кодируется при 16 Кбит/с, означая, что кодированный кадр речи содержит 40 байт данных. Поэтому размер полезной нагрузки пакета, содержащего оба агрегированных кадра, равен 60 байтам. Приемник принимает этот пакет RTP с 60 байтами полезной нагрузки, и задача состоит в том, чтобы понять, каким образом кодируются включенные в него данные. Приемник из приема этого пакета и его размера полезной нагрузки может теперь сделать вывод, что тот либо содержит 3 кадра данных, кодированные при 8 Кбит/с, либо один кадр, кодированный при 16 Кбит/с, и один кадр, кодированный при 8 Кбит/с. В последнем случае еще не ясно, идет ли кодированный с 8 Кбит/с кадр первым или вторым. Как становится ясно из примера, эта неопределенность не позволяет декодеру в приемнике декодировать принятые кадры надлежащим образом. Поэтому разрешение агрегирования кадров (или не исключение вероятности агрегирования кадров) может вносить неоднозначности, которые делают невозможными форматы полезной нагрузки RTP без заголовка. Тем не менее агрегирование кадров является очень желательным свойством для VoIP для некоторых IP-сетей, например доступа WLAN.
Другая проблема имеет отношение к возможному взаимодействию совместимых с AMR-WB режимов кодека EVS с унаследованным оборудованием, поддерживающим только кодек AMR-WB. С целью адаптации режима формат полезной нагрузки RTP AMR-WB предоставляет в своем заголовке 4-битное поле для переноса так называемых CMR (запросы режима кодека). Целью CMR является сигнализировать UE отправляющей стороны предпочтительный режим кодека, который ему следует использовать в операции кодирования. Это допускает адаптацию используемой скорости передачи битов в ответ, например, на изменения канала передачи или ограничения пропускной способности системы, так называемую адаптацию AMR с использованием внутриполосной сигнализации. Формат полезной нагрузки без заголовка у кодека EVS для совместимых с AMR-WB режимов не смог бы транспортировать эти CMR, и поэтому в сценариях взаимодействия с унаследованным оборудованием AMR-WB была бы невозможна адаптация режима кодека на основе идеи внутриполосной сигнализации AMR с использованием CMR.
СУЩНОСТЬ ИЗОБРЕТЕНИЯ
Задача настоящих вариантов осуществления – решить или по меньшей мере уменьшить по меньшей мере одну из вышеупомянутых проблем.
Задачей является предоставление эффективного формата полезной нагрузки RTP для многорежимного кодека речи/аудио, содержащего по меньшей мере два режима работы, один из которых может взаимодействовать с кодеком, который уже введен в действие существующим унаследованным оборудованием. С одной стороны, проблема состоит в том, чтобы сделать формат полезной нагрузки как можно эффективнее в том смысле, что он содержит как можно меньше служебной нагрузки. Одновременно не должно быть ограничений в отношении возможностей агрегировать множество кодированных кадров в пакет RTP. Кроме того, в случаях, когда унаследованный режим кодирования используется в контексте взаимодействия с унаследованным оборудованием, формат полезной нагрузки RTP должен допускать передачу дополнительной сигнальной информации, необходимой для взаимодействия с унаследованным оборудованием.
Точнее говоря, кодек, который уже введен в действие существующим унаследованным оборудованием, может быть AMR-WB, и сигнальной информацией, связанной с взаимодействием с унаследованным оборудованием, использующим AMR-WB, могут быть данные адаптации режима AMR-WB, а еще точнее – информация CMR.
В соответствии с первым аспектом изобретения предоставляется способ задания формата полезной нагрузки для поддержки совместимости кодеков речи/аудио, выбора формата полезной нагрузки и форматирования полезной нагрузки для передачи данных многорежимного кодека речи/аудио. Способ содержит задание набора режимов кодека и скоростей передачи битов, используемого для кодирования полезной нагрузки речи/аудио. На основе используемого режима кодека и скорости передачи битов принимается решение, используется ли заголовок полезной нагрузки, и в зависимости от этого решения данные полезной нагрузки пакетируются с заголовком полезной нагрузки или без него.
В соответствии со вторым аспектом изобретения предоставляется способ депакетирования кадров речевых/аудиоданных в принятом пакете. Сначала можно определить, соответствует ли размер полезной нагрузки какому-нибудь из набора защищенных или уникальных размеров полезной нагрузки. В том случае определяется, что использовалось пакетирование без заголовка, а размер полезной нагрузки однозначно идентифицирует используемый режим кодека и скорость передачи битов. В противном случае определяется, что использовалось пакетирование с заголовком. В том случае считывается заголовок полезной нагрузки для определения информации о скорости и режиме кодека, используемых для кодирования полезной нагрузки речи/аудио.
В соответствии с третьим аспектом изобретения предоставляется устройство для пакетирования речевых/аудиоданных. Устройство содержит блок принятия решения для принятия решения, используется ли заголовок полезной нагрузки, причем решение принимается на основе используемого режима кодека и скорости передачи битов. Устройство дополнительно содержит формирователь пакетов для пакетирования полезной нагрузки речи/аудио с заголовком полезной нагрузки или без него в зависимости от решения блока принятия решения.
В соответствии с четвертым аспектом изобретения предоставляется устройство для депакетирования кадров речевых/аудиоданных в принятом пакете. Разборщик пакетов сначала может определить, соответствует ли размер полезной нагрузки какому-нибудь из элементов набора защищенных или уникальных размеров полезной нагрузки. В том случае определяется, что использовалось пакетирование без заголовка, а размер полезной нагрузки однозначно идентифицирует используемый режим кодека и скорость передачи битов. В противном случае определяется, что использовалось пакетирование с заголовком. В том случае разборщик пакетов считывает заголовок полезной нагрузки, который содержит всю необходимую сигнальную информацию о скорости и режиме кодека, используемых для кодирования полезной нагрузки речи/аудио.
В соответствии с пятым аспектом изобретения предоставляется компьютерная программа, содержащая компьютерно-читаемые элементы кода, которые при выполнении на устройстве побуждают устройство принять решение, используется ли заголовок полезной нагрузки, причем решение принимается на основе используемого режима кодека и скорости передачи битов, и пакетировать полезную нагрузку речи/аудио с заголовком полезной нагрузки или без него в зависимости от решения блока принятия решения.
В соответствии с шестым аспектом изобретения предоставляется компьютерная программа, содержащая компьютерно-читаемые элементы кода, которые при выполнении на устройстве побуждают устройство определить, соответствует ли размер полезной нагрузки какому-нибудь из элементов набора защищенных или уникальных размеров полезной нагрузки, и когда определяется, что размер полезной нагрузки не соответствует никакому из элементов набора защищенных или уникальных размеров полезной нагрузки, устройство дополнительно побуждают считать заголовок полезной нагрузки для определения информации о скорости и режиме кодека, используемых для кодирования полезной нагрузки речи/аудио.
В соответствии с седьмым аспектом компьютерный программный продукт содержит компьютерно-читаемый носитель, хранящий компьютерную программу в соответствии с вышеописанным пятым или шестым аспектом.
ЧЕРТЕЖИ
Для более полного понимания примерных вариантов осуществления настоящего изобретения сделана ссылка на нижеследующее описание применительно к прилагаемым чертежам, на которых:
Фиг. 1 иллюстрирует пример способа, выполняемого кодером.
Фиг. 2 – блок-схема алгоритма принятия решения для принятия решения, используется ли пакетирование без заголовка либо с заголовком.
Фиг. 3 иллюстрирует пример способа депакетирования, выполняемого декодером.
Фиг. 4 иллюстрирует примерную схему полезной нагрузки RTP без заголовка для режима 12,65 AMR-WB.
Фиг. 5 иллюстрирует альтернативную примерную схему полезной нагрузки RTP без заголовка для режима 12,65 AMR-WB со смещением.
Фиг. 6 показывает первый пример устройства в соответствии с вариантом осуществления изобретения.
Фиг. 7 показывает второй пример устройства в соответствии с вариантом осуществления изобретения.
Фиг. 8 показывает третий пример устройства в соответствии с вариантом осуществления изобретения.
ПОДРОБНОЕ ОПИСАНИЕ
Варианты осуществления изобретения используют сочетание формата полезной нагрузки RTP без заголовка и с заголовком. Чтобы гарантировать, что использование эффективного формата без заголовка не приводит к неоднозначностям размера полезной нагрузки RTP, которые делают невозможным надлежащее декодирование с помощью приемника, формат без заголовка используется только условно в некоторых случаях. В противном случае используется формат полезной нагрузки RTP с заголовком полезной нагрузки, где заголовок полезной нагрузки включает в себя всю релевантную сигнальную информацию, необходимую для идентификации режима кодека и скорости передачи битов, используемых для кодирования данных, включенных в полезную нагрузку RTP. Часть идеи состоит в задании набора уникальных размеров пакетов RTP, которые непосредственно и уникально связаны со скоростью передачи битов и режимом кодирования, используемыми для кодирования полезной нагрузки речи/аудио. Если используется формат полезной нагрузки с заголовком, то при создании пакета RTP его размером управляют так, что он не совпадает ни с каким из набора уникальных размеров пакетов RTP, зарезервированных для формата полезной нагрузки без заголовка. Если это так, то размер пакета RTP регулируется путем добавления заполняющих байтов до тех пор, пока не устранится конфликт с зарезервированными размерами пакетов RTP. Кроме того, данные, ассоциированные с режимом кодека для использования при взаимодействии с унаследованным оборудованием, передаются с использованием эффективного формата полезной нагрузки без заголовка. Дополнительная сигнальная информация, необходимая для взаимодействия с унаследованным оборудованием, передается с использованием запасных битов в полезной нагрузке либо посредством разброса этой информации по времени, либо посредством ее повторного отображения в доступные запасные биты.
Один вариант осуществления описывается в виде следующего способа 100, проиллюстрированного на фиг. 1. На первом этапе 101 задается набор режимов кодека и/или скоростей передачи битов, для которого полезная нагрузка RTP должна позволять эффективную передачу без заголовка полезной нагрузки RTP. Этот набор соответствует набору защищенных или уникальных размеров полезной нагрузки, называемому "prot_set".
В качестве примера теперь предположим, что формат полезной нагрузки RTP должен допускать передачу унаследованной полезной нагрузки AMR-WB и полезной нагрузки, не совместимой с AMR-WB. Набор скоростей AMR-WB, являющихся частью набора, показан в следующей таблице 1 и содержит все 9 режимов AMR-WB и режим SID (дескриптор вставки молчания), используемый для операции прерывистой передачи (DTX)/комфортного шума:
Набор несовместимых (то есть не совместимых с унаследованным кодеком AMR-WB) скоростей передачи битов/режимов, который должен быть частью набора скоростей/режимов, который может передаваться в примере без заголовка полезной нагрузки RTP, показан в следующей таблице 2:
Поэтому в примере набором защищенных (уникальных) размеров полезной нагрузки является следующий:
Prot_set={7, 10, 14, 17, 18, 20, 23, 24, 32, 33, 36, 40, 41, 46, 50, 58, 60, 61}.
Следующий дополнительный набор скоростей передачи битов, являющийся частью несовместимого режима, в примере не должен передаваться без заголовка полезной нагрузки RTP, а с заголовком полезной нагрузки, см. следующую таблицу 3:
На следующем этапе 103 способ принимает решение, используется ли пакетирование RTP с заголовком полезной нагрузки RTP или без него. В качестве примера, если агрегирование кадров используется больше чем с одним кодированным кадром на пакет, то будет использоваться пакетирование RTP с заголовком. Поэтому отсутствует опасность того, что агрегирование нескольких кадров в пакете RTP может привести к неоднозначности, которая делает сложным или невозможным правильное декодирование полезной нагрузки для приемника. Кроме того, может быть больше условий, для которых выбирается пакетирование с заголовком, а не пакетирование без заголовка. Например, это может зависеть от скорости передачи битов в переданном режиме кодека. В частности, если скорость передачи битов большая, то ассоциированная с пакетированием с заголовком служебная нагрузка может быть относительно небольшой и поэтому приемлемой. Другой причиной для выбора пакетирования с заголовком может быть, например, потребность передать дополнительную информацию в пакете RTP, которую следует поместить в заголовок полезной нагрузки. В качестве примера это могут быть информационные биты, связанные с адаптацией режима (типа CMR), или другие характерные для кодека сигнальные данные (типа информации о полосе пропускания аудио или информации о внутреннем режиме кодека), которые нужно передать приемнику, чтобы декодер работал должным образом.
В качестве примера этого этапа блок-схема алгоритма из фиг. 2 иллюстрирует алгоритм 200 принятия решения для принятия решения, используется ли пакетирование без заголовка либо пакетирование с заголовком. В этом примере пакетирование с заголовком всегда выбирается, если используется агрегирование кадров с несколькими кадрами на пакеты, выбор на этапе 201, скорость передачи битов превышает 24,4 Кбит/с, выбор на этапе 203, или в случае специального признака, требующего это, выбор на этапе 205. Таким специальным признаком может быть, как объяснялось выше, доступность данных адаптации режима или других характерных для кодека сигнальных данных. Поэтому в этом примере параметрами решения, использовать ли (207) пакетирование без заголовка или нет (209), являются:
- агрегирование кадров (num_agg);
- скорость передачи битов, или число байт (октетов) на кадр;
- специальный признак, требующий формата полезной нагрузки с заголовком.
На следующем этапе 105 определяется размер полезной нагрузки RTP (или, соответственно, пакета RTP), как часть пакетирования. Это можно выполнить с помощью следующего алгоритма в псевдокоде в силе программирования на C на основе вышеупомянутого определения, должно ли использоваться пакетирование без заголовка или пакетирование с заголовком:
В вышеприведенном псевдокоде "octets" соответствует размеру в байтах кодированных речевых/аудиоданных заданного кадра i (подсчет начинается с 0). "num_agg" является количеством агрегированных кадров на пакет, то есть 1, если агрегирование не используется, в противном случае num_agg больше 1.
На приемной стороне депакетирование должно выполнять обратный алгоритм 300 к вышеупомянутому, чтобы определить кодированные кадры речевых/аудиоданных в принятом пакете и ассоциированную сигнальную информацию, как проиллюстрировано на фиг. 3. Например, разборщик пакетов сначала может определить, соответствует ли размер полезной нагрузки какому-нибудь из элементов набора защищенных или уникальных размеров полезной нагрузки, "prot_set", как показано на этапе 301. В том случае использовалось пакетирование без заголовка, и размер полезной нагрузки однозначно идентифицирует используемый режим кодека и скорость передачи битов, как показано на этапе 303. В противном случае использовалось пакетирование с заголовком. В том случае разборщик пакетов сначала считывает заголовок полезной нагрузки RTP (или по меньшей мере первый заголовок полезной нагрузки RTP), как показано на этапе 305. Заголовок полезной нагрузки содержит всю необходимую сигнальную информацию о скорости и режиме кодека, используемых для кодирования полезной нагрузки речи/аудио, и использовалось ли, например, агрегирование кадров, которое может подразумевать, что может существовать дополнительная информация заголовка, ассоциированная с дополнительными кодированными кадрами речи/аудио. Следует отметить, что может быть один заголовок RTP для каждого кадра речи/аудио, или может быть всего лишь один заголовок RTP, даже если используется агрегирование кадров. Возможную дополнительную сигнальную информацию, которая также может быть частью заголовка RTP, также можно извлечь с помощью способа депакетирования в приемнике.
На дополнительном этапе способа данные, ассоциированные с режимом кодека для использования при взаимодействии с унаследованным оборудованием, обрабатываются так, что их можно передать вместе с полезной нагрузкой, ассоциированной с тем режимом кодека, и с использованием эффективного пакетирования без заголовка. Следует отметить, что эта сигнальная информация может быть необходима для взаимодействия с унаследованным оборудованием. Хотя передача такой дополнительной информации в случае пакетирования без заголовка может показаться в принципе невозможной, все же такая возможность существует, если имеются неиспользуемые биты в полезной нагрузке речи/аудио. Это будет подробно описываться в следующих вариантах осуществления.
Один из таких вариантов осуществления объясняется на конкретном примере совместимого с AMR-WB режима для использования при взаимодействии с унаследованным оборудованием. Как видно из таблицы 4 ниже, в зависимости от используемого режима биты для передачи на каждый кадр не являются, как правило, целыми кратными 8, что соответствует пакетированию RTP. Поэтому при упаковке этих битов полезной нагрузки в октеты (или байты) из 8 битов остаются неиспользуемыми некоторые биты в упакованной в байты полезной нагрузке. В таблице ниже эти неиспользуемые биты обозначаются как "запасные биты". Как видно, всегда доступно минимум 3 запасных бита.
Первым случаем для рассмотрения является тот, когда объем дополнительной сигнальной информации не превышает доступных запасных битов. Тогда способ может непосредственно использовать запасные биты для передачи дополнительной информации. В качестве примера предположим случай, где полезная нагрузка речи/аудио соответствует режиму #2 AMR-WB (то есть 12.65) в вышеупомянутой таблице. И дополнительно предположим, что дополнительная информация для передачи содержит 3 бита. Тогда информационными битами того режима являются биты с d(0) по d(252). Как показано на фиг. 4, их можно поместить в пакет RTP без заголовка, начиная с бита 0 в октете 0. Тогда 3 дополнительных сигнальных бита S помещаются после последнего информационного бита d(252).
Здесь следует отметить, что вышеприведенная схема является лишь одним конкретным примером. В частности, может быть полезно поместить информационные биты AMR-WB в пакет RTP со смещением, например, если пакеты будут переформированы в шлюзе среды с использованием другого формата полезной нагрузки RTP, например RFC 4867 с упаковкой с эффективным использованием полосы пропускания. Такой пример показан в альтернативной схеме на фиг. 5. Из-за смещения первым информационным битом полезной нагрузки AMR-WB является не d(0), а, например, d(2). Биты d(0) и d(1) затем вставляются в конец битов полезной нагрузки AMR-WB.
Однако более широким случаем является тот, когда имеется больше сигнальных битов, чем можно перенести с помощью запасного бита. В том случае первым предпочтительным вариантом осуществления является разброс передачи сигнальной информации по времени. С этой целью дополнительная сигнальная информация сначала прореживается во времени. Предположим, что эта дополнительная сигнальная информация поступает с такой же частотой, как кодированные кадры речи/аудио, сначала нужно убедиться, что эти данные достаточно прорежены (или субдискретизированы), чтобы скорость, необходимая для их передачи, не превышала доступной скорости передачи, которую можно достичь с использованием запасных битов. Нужно отметить, что во многих случаях такую сигнальную информацию можно прореживать без значительного влияния на услугу. В более конкретном варианте осуществления можно предположить, что эти данные являются CMR для использования при адаптации режима кодека. Этот тип данных можно прореживать без серьезного влияния.
В еще более конкретном примере этого варианта осуществления предположим, что имеется 4 бита CMR, которые нужно сигнализировать каждые 20 мс. Сначала эти данные прореживаются так, что существует только 4 бита CMR в каждые 40 мс, то есть в каждом втором кадре. Затем эти 4 прореженных бита CMR разделяются на 2 двухбитные части и передаются в соседних кадрах: первая двухбитная часть передается с первым кадром, оставшаяся двухбитная часть идет со вторым кадром. С помощью бита LSB указывается, передается ли два самых младших бита, или две самых старших двухбитных части.
Это еще подробнее иллюстрируется следующим образом: 4 бита CMR называются (c3, c2, c1, c0), тогда кортежем (c3, c2) являются два самых старших бита, кортежем (c1, c0) являются два самых младших бита. В первом кадре три бита S из фиг. 5 или 6 могут переносить биты (c1, c0, L), где L=1 указывает, что c1 и c0 являются LSB. В соответствующем втором кадре три бита S переносят биты (c3, c2, L), где L=0 указывает, что c3 и c2 являются LSB.
В другом варианте осуществления сигнальная информация уменьшается до объема, который можно транспортировать с использованием доступных запасных битов посредством повторного отображения в доступные запасные биты. Снова рассмотрим пример, когда 4 бита CMR нужно уменьшить до 3 доступных запасных битов. Поскольку биты CMR кодируют запросы для одного из показанных выше режимов AMR-WB, одной возможностью является то, что CMR для 8 из 9 режимов AMR-WB (все режимы за исключением 23,05) сигнализируются с помощью трех запасных битов. CMR для режима 23,05 повторно отображаются в соседний режим (19,85). Другим примером является то, когда разрешены только CMR, соответствующие режимам 6,6, 8,85, 12,65, 15,85 и 23,85, и любой CMR для другого режима AMR-WB повторно отображается в ближайший разрешенный режим AMR-WB. В том контексте отметим, что эти 5 режимов AMR-WB являются релевантными режимами AMR-WB для использования в голосовых услугах 3GPP с коммутацией каналов (CS). В этих двух примерах теперь можно использовать три доступных бита S непосредственно для передачи повторно отображенной сигнальной информации.
Дополнительный вариант осуществления может работать аналогично варианту осуществления выше с повторным отображением, но только для CMR для подмножества режимов, которые разрешено сигнализировать непосредственно с использованием битов S. В случае CMR для другого режима можно выбрать пакетирование с заголовком вместо пакетирования без заголовка. В заголовке полезной нагрузки RTP, используемом в том случае, может быть достаточно пространства сигнализации, чтобы передать CMR для этого другого режима.
Следующий вариант осуществления в соответствии с Таблицей 5 показывает пример заголовка полезной нагрузки RTP, который может использоваться для пакетирования с заголовком. В соответствии с этим вариантом осуществления задается 8-битный заголовок со следующими сигнальными элементами:
- FT (5 битов): тип кадра
используется для сигнализации несовместимых и совместимых с AMR-WB режимов
- F (1 бит): продолжение
Если установлен в 1, то указывает, что за этим кадром идет другой кадр речи в этой полезной нагрузке; если установлен в 0, то указывает, что этот кадр является последним кадром в этой полезной нагрузке.
- CMR_ext/Spare (1 бит): дополнительный бит CMR
Может использоваться как часть вариантов осуществления, где CMR для совместимых с AMR-WB режимов, которые не разрешено сигнализировать с помощью запасных битов. Этот дополнительный бит CMR_ext позволяет увеличить пространство сигнализации CMR до 4 битов, которых тогда достаточно для сигнализации CMR для всех режимов AMR-WB. В противном случае может быть запасным/неиспользуемым. Этот бит может использоваться, например, для расширения пространства сигнализации дальше для несовместимых режимов.
- Spare (1 бит)
В настоящее время не используется. Может использоваться для расширения пространства сигнализации для разрешения дополнительных режимов/скоростей, например, стерео.
Варианты осуществления применяются к кодеку для речевого/аудиосигнала. Фиг. 6 – блок-схема устройства в соответствии с вариантами осуществления. Этот чертеж иллюстрирует часть кодирующей стороны в кодеке. Устройство 600 содержит входной блок 601 (приемный блок), сконфигурированный для приема данных полезной нагрузки речи/аудио, и блок 605 для пакетирования полезной нагрузки речи/аудио для передачи в виде потока двоичных сигналов. Устройство дополнительно содержит блок 603 для принятия решения, используется ли заголовок полезной нагрузки. Фиг. 6 иллюстрирует только блоки, которые необходимы для понимания вариантов осуществления изобретения. Поскольку устройство 600 можно реализовать как часть кодера, может присутствовать несколько других блоков, выполняющих кодирование речевого/аудиосигнала, которые не показаны на чертеже. Кроме того, приемный блок 601 можно рассматривать как блок для приема кодированного речевого/аудиосигнала для пакетирования или можно рассматривать как блок для приема речевого/аудиосигнала, и в этом случае между приемным блоком 601 и блоком 603 принятия решения может присутствовать один или несколько блоков.
Фиг. 7 – блок-схема другого примерного устройства в соответствии с вариантами осуществления. Этот чертеж иллюстрирует часть декодирующей стороны в кодеке. Устройство 700 содержит входной блок 701 (приемный блок), сконфигурированный для приема пакетов 707 данных, содержащих кодированный речевой/аудиосигнал, и блок 703 для депакетирования принятых пакетов 707 данных для декодирования кодированного речевого/аудиосигнала. Фиг. 7 иллюстрирует только блоки, которые необходимы для понимания вариантов осуществления изобретения. Поскольку устройство 700 можно реализовать как часть декодера, может присутствовать несколько других блоков, выполняющих декодирование кодированного речевого/аудиосигнала, которые не показаны на фиг. 7.
Кодек с включенными в него блоками можно реализовать в аппаратных средствах. Существуют многочисленные варианты элементов схем, которые можно использовать и объединять для выполнения функций блоков в кодеке. Такие варианты охвачены вариантами осуществления. Конкретными примерами аппаратной реализации кодека является реализация в аппаратных средствах цифрового процессора сигналов (DSP) и технологии интегральных схем, включающей в себя как универсальные электронные схемы, так и специализированные схемы.
Фиг. 8 показывает другой пример устройства в соответствии с вариантами осуществления. Устройство 800 содержит входной узел 801 для приема речевого/аудиосигнала (когда устройство является кодером) или потока двоичных сигналов, соответствующего кодированному речевому/аудиосигналу (когда устройство является декодером), и выходной узел 803 для предоставления потока двоичных сигналов для передачи (кодер) или для предоставления декодированного речевого/аудиосигнала (декодер). Устройство 800 дополнительно содержит процессор 805, например центральный процессор (CPU), и компьютерный программный продукт в виде запоминающего устройства 807 для хранения команд, например компьютерной программы 809, которая при извлечении из запоминающего устройства 807 и исполнении процессором 805 побуждает устройство 800 выполнить процессы, связанные с вариантами осуществления настоящего изобретения, например, по меньшей мере один из способов, проиллюстрированных на фиг. 1, 2 и 3. Процессор 805 коммуникационно соединен с входным узлом 801, с выходным узлом 803 и с запоминающим устройством 807.
Описанная выше технология может использоваться, например, в кодеке речи/аудио, который может использоваться в мобильном устройстве (например, мобильном телефоне, переносном компьютере) или стационарном устройстве, например персональном компьютере.
Нужно понимать, что выбор взаимодействующих блоков или модулей, а также именование блоков служат только для примера, и они могут конфигурироваться множеством альтернативных способов, чтобы иметь возможность исполнять раскрытые действия процесса.
Также следует отметить, что блоки или модули, описанные в этом раскрытии изобретения, нужно рассматривать как логические сущности, а не обязательно как отдельные физические сущности. Нужно будет принять во внимание, что объем раскрытой в этом документе технологии полностью включает в себя другие варианты осуществления, которые могут стать очевидными специалистам в данной области техники, и что объем этого раскрытия изобретения, соответственно, не ограничивается.
Ссылка на элемент в единственном числе не имеет целью означать "один и только один", пока не указано явно, а скорее "один или несколько". Все структурные и функциональные эквиваленты элементов из вышеописанных вариантов осуществления, которые известны средним специалистам в данной области техники, в прямой форме включаются в этот документ путем отсылки и предназначены для охвата им. Кроме того, устройству или способу не нужно решать все без исключения проблемы, которые пытаются решить с помощью раскрытой в этом документе технологии, чтобы устройство или способ были ей охвачены.
В предшествующем описании с целью объяснения, а не ограничения, излагаются характерные подробности, например конкретные архитектуры, интерфейсы, методики и т. д., чтобы обеспечить всестороннее понимание раскрытой технологии. Однако специалистам в данной области техники будет очевидно, что раскрытая технология может применяться на практике в других вариантах осуществления и/или в сочетаниях вариантов осуществления, которые отступают от этих характерных подробностей. То есть специалисты в данной области техники смогут разработать различные конфигурации, которые, хотя явно не описаны или показаны в этом документе, воплощают принципы раскрытой технологии. В некоторых случаях подробные описания известных устройств, схем и способов пропускаются с тем, чтобы не затруднять описание раскрытой технологии ненужными подробностями. Все утверждения, излагающие в этом документе принципы, аспекты и варианты осуществления раскрытой технологии, а также их конкретные примеры предназначены для охвата как структурных, так и их функциональных эквивалентов. Дополнительно подразумевается, что такие эквиваленты включают в себя как известные в настоящее время эквиваленты, так и эквиваленты, разработанные в будущем, например, любые разработанные элементы, которые выполняют ту же функцию, независимо от структуры.
Таким образом, например, специалистам в данной области техники будет понятно, что чертежи в этом документе могут давать концептуальные представления пояснительных схем или иных функциональных блоков, воплощающих принципы технологии, и/или различных процессов, которые в основном можно представить на компьютерно-читаемом носителе и исполнить компьютером или процессором, даже если такой компьютер или процессор может быть не показан явно на чертежах.
Функции различных элементов, включающих в себя функциональные блоки, могут обеспечиваться посредством использования аппаратных средств, например аппаратных схем и/или аппаратных средств, допускающих исполнение программного обеспечения в виде кодированных команд, сохраненных на компьютерно-читаемом носителе. Таким образом, такие функции и проиллюстрированные функциональные блоки нужно понимать как реализуемые либо аппаратными средствами, и/либо реализуемые компьютером, и соответственно реализуемые машиной.
Описанные выше варианты осуществления нужно понимать как несколько пояснительных примеров настоящего изобретения. Специалистам в данной области техники будет понятно, что можно создать различные модификации, сочетания и изменения к вариантам осуществления без отклонения от объема настоящего изобретения. В частности, разные частичные решения в разных вариантах осуществления можно объединить в другие конфигурации, где это технически возможно.
Изобретение относится к кодированию аудио/речи. Технический результат - обеспечение эффективного формата полезной нагрузки RTR для многорежимного кодека речи/аудио. Способ содержит принятие решения, используется ли формат полезной нагрузки без заголовка или с заголовком для передачи кодированного кадра. Решение основывается на режиме кодека и необходимых функциональных возможностях. Данные полезной нагрузки пакетируются с заголовком полезной нагрузки или без него в зависимости от решения. 6 н. и 17 з.п. ф-лы, 8 ил., 5 табл.
1. Способ форматирования полезной нагрузки для передачи данных многорежимного кодека речи или данных многорежимного кодека аудио, содержащий этапы, на которых:
принимают решение (103) на основе по меньшей мере одного из режима кодека и необходимых функциональных возможностей, используется ли формат полезной нагрузки без заголовка или с заголовком, причем, если используется формат полезной нагрузки с заголовком с некоторым заголовком полезной нагрузки, то заголовок полезной нагрузки содержит сигнальную информацию; и
пакетируют (105) данные полезной нагрузки RTP с заголовком полезной нагрузки или без него в зависимости от решения.
2. Способ по п. 1, в котором сигнальная информация ассоциирована по меньшей мере с одним из: идентификационных данных режима кодека, скорости передачи битов, адаптации режима, запроса режима кодека, полосы пропускания аудио, внутреннего режима кодека и агрегирования кадров.
3. Способ по п. 1 или 2, в котором формат полезной нагрузки без заголовка ассоциирован с защищенными размерами полезной нагрузки, которые однозначно идентифицируют режимы кодека и скорости передачи битов.
4. Способ по п. 1 или 2, в котором данные полезной нагрузки RTP переносят один кодированный кадр, когда используется формат полезной нагрузки без заголовка.
5. Способ по п. 1, в котором решение использовать формат с заголовком принимается, когда используется агрегирование кадров с несколькими кодированными кадрами на пакеты.
6. Способ по п. 1, в котором необходимые функциональные возможности содержат по меньшей мере одно из:
агрегирования кадров, где данные полезной нагрузки пакета ассоциируются с несколькими кадрами;
включения заголовка полезной нагрузки RTP;
включения данных адаптации режима; и
включения характерных для кодека сигнальных данных.
7. Способ по п. 6, в котором решение использовать формат с заголовком принимается, когда включаются характерные для кодека сигнальные данные.
8. Способ по п. 7, в котором характерные для кодека сигнальные данные содержат информацию о полосе пропускания аудио или информацию о внутреннем режиме кодека.
9. Способ по п. 6, в котором решение использовать формат с заголовком принимается, когда включаются информационные биты, связанные с адаптацией режима кодека.
10. Способ по п. 1, в котором необходимые функциональные возможности содержат передачу дополнительной сигнальной информации, ассоциированной с режимом кодека, для использования при взаимодействии с унаследованным оборудованием.
11. Способ по п. 10, в котором упомянутая дополнительная сигнальная информация связана с адаптацией режима кодека и содержит биты CMR (запрос режима кодека), причем подмножество режимов разрешено запрашивать при использовании формата полезной нагрузки без заголовка, а CMR для режимов, не принадлежащих упомянутому подмножеству режимов, передаются с использованием формата полезной нагрузки с заголовком.
12. Способ по п. 3, в котором размер пакета регулируется путем добавления заполняющих байтов, так что размер не совпадает ни с каким из защищенных размеров полезной нагрузки, когда принимается решение использовать формат полезной нагрузки с заголовком.
13. Способ депакетирования принятого пакета кодированных кадров речевых данных или кодированных кадров аудиоданных, содержащий этапы, на которых:
определяют (301), соответствует ли размер полезной нагрузки принятого пакета какому-нибудь из элементов набора защищенных размеров полезной нагрузки, который уникально идентифицирует режимы кодека и скорости передачи битов, и
считывают заголовок полезной нагрузки (305), если определяется, что размер полезной нагрузки принятого пакета не соответствует никакому из элементов набора защищенных размеров полезной нагрузки.
14. Способ по п. 13, дополнительно содержащий этап, на котором извлекают информацию из заголовка полезной нагрузки для определения режима кодека и скорости передачи битов, когда определяется, что размер полезной нагрузки принятого пакета не соответствует никакому из элементов набора защищенных размеров полезной нагрузки.
15. Способ по п. 13, дополнительно содержащий этап, на котором определяют режим кодека и скорость передачи битов на основе размера полезной нагрузки (303), когда определяется, что размер полезной нагрузки принятого пакета соответствует одному из элементов набора защищенных размеров полезной нагрузки.
16. Устройство для форматирования полезной нагрузки для передачи данных многорежимного кодека, содержащее:
процессор (805) и
запоминающее устройство (807), хранящее команды (809), которые при исполнении процессором предписывают устройству:
принять решение на основе по меньшей мере одного из режима кодека и необходимых функциональных возможностей, используется ли формат полезной нагрузки без заголовка или с заголовком, причем, если используется формат полезной нагрузки с заголовком с некоторым заголовком полезной нагрузки, то заголовок полезной нагрузки содержит сигнальную информацию; и
пакетировать данные полезной нагрузки RTP с заголовком полезной нагрузки или без него в зависимости от решения.
17. Устройство по п. 16, дополнительно содержащее запоминающее устройство, хранящее инструкции, которые при исполнении процессором предписывают устройству выполнять способ по любому одному из пп. 2-15.
18. Устройство для депакетирования принятого пакета кодированных кадров речевых данных или кодированных кадров аудиоданных, содержащее:
процессор (805) и
запоминающее устройство (807), хранящее команды (809), которые при исполнении процессором предписывают устройству:
принять пакет данных, содержащий кодированный речевой сигнал или кодированный аудиосигнал;
определить, соответствует ли размер полезной нагрузки принятого пакета какому-нибудь из элементов набора защищенных размеров полезной нагрузки, который уникально идентифицирует режимы кодека и скорости передачи битов, и
считывать заголовок полезной нагрузки, если определяется, что размер полезной нагрузки принятого пакета не соответствует никакому из элементов набора защищенных размеров полезной нагрузки.
19. Устройство по п. 18, дополнительно содержащее
извлечение информации из заголовка полезной нагрузки для определения режима кодека и скорости передачи битов, если определяется, что размер полезной нагрузки принятого пакета не соответствует никакому из элементов набора защищенных размеров полезной нагрузки, и
определение режима кодека и скорости передачи битов на основе размера полезной нагрузки, если определяется, что размер полезной нагрузки принятого пакета соответствует одному из элементов набора защищенных размеров полезной нагрузки.
20. Устройство по любому из пп. 16-19, причем устройство содержится в или соединено с возможностью осуществления связи с речевым или аудиокодеком, имеющим по меньшей мере два рабочих режима, по меньшей мере один из которых является режимом, совместимым с унаследованным кодеком.
21. Устройство по любому из пп. 16-20, причем устройство содержится в мобильном устройстве.
22. Компьютерно-читаемый носитель, содержащий компьютерно-читаемые элементы кода, которые при выполнении на устройстве предписывают устройству:
принять решение на основе по меньшей мере одного из режима кодека и необходимых функциональных возможностей, используется ли формат полезной нагрузки без заголовка или с заголовком, причем, если используется формат полезной нагрузки с заголовком с некоторым заголовком полезной нагрузки, то заголовок полезной нагрузки содержит сигнальную информацию; и
пакетировать данные полезной нагрузки RTP с заголовком полезной нагрузки или без него в зависимости от решения.
23. Компьютерно-читаемый носитель, содержащий компьютерно-читаемые элементы кода, которые при выполнении на устройстве предписывают устройству:
принять пакет данных, содержащий кодированный речевой сигнал или кодированный аудиосигнал;
определить, соответствует ли размер полезной нагрузки принятого пакета какому-нибудь из элементов набора защищенных размеров полезной нагрузки, который уникально идентифицирует режимы кодека и скорости передачи битов, и
считывать заголовок полезной нагрузки, если определяется, что размер полезной нагрузки принятого пакета не соответствует никакому из элементов набора защищенных размеров полезной нагрузки.
