BRPI0706417A2 - método e equipamento para melhorar o desempenho de rohc ao encontrar supressão de silêncio - Google Patents
método e equipamento para melhorar o desempenho de rohc ao encontrar supressão de silêncio Download PDFInfo
- Publication number
- BRPI0706417A2 BRPI0706417A2 BRPI0706417-9A BRPI0706417A BRPI0706417A2 BR PI0706417 A2 BRPI0706417 A2 BR PI0706417A2 BR PI0706417 A BRPI0706417 A BR PI0706417A BR PI0706417 A2 BRPI0706417 A2 BR PI0706417A2
- Authority
- BR
- Brazil
- Prior art keywords
- value
- stride
- devices
- increment
- timestamp
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 41
- 230000001629 suppression Effects 0.000 title abstract description 19
- 238000007906 compression Methods 0.000 claims abstract description 31
- 230000006835 compression Effects 0.000 claims abstract description 31
- 230000005540 biological transmission Effects 0.000 claims description 10
- 238000004590 computer program Methods 0.000 claims 2
- 230000002123 temporal effect Effects 0.000 claims 1
- 230000008859 change Effects 0.000 description 16
- 230000008569 process Effects 0.000 description 16
- 238000004891 communication Methods 0.000 description 14
- 230000006837 decompression Effects 0.000 description 14
- 230000006870 function Effects 0.000 description 6
- 230000002441 reversible effect Effects 0.000 description 6
- 230000003068 static effect Effects 0.000 description 4
- 238000012217 deletion Methods 0.000 description 3
- 230000037430 deletion Effects 0.000 description 3
- 238000012545 processing Methods 0.000 description 3
- 238000005070 sampling Methods 0.000 description 3
- 238000004364 calculation method Methods 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 239000002245 particle Substances 0.000 description 2
- 230000009467 reduction Effects 0.000 description 2
- 230000008901 benefit Effects 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 125000004122 cyclic group Chemical group 0.000 description 1
- 238000013144 data compression Methods 0.000 description 1
- 230000007423 decrease Effects 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 230000005672 electromagnetic field Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 239000000835 fiber Substances 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 238000012886 linear function Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000008929 regeneration Effects 0.000 description 1
- 238000011069 regeneration method Methods 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
- 239000002699 waste material Substances 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/04—Protocols for data compression, e.g. ROHC
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/22—Parsing or analysis of headers
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Telephonic Communication Services (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Compression, Expansion, Code Conversion, And Decoders (AREA)
- Mobile Radio Communication Systems (AREA)
- Medicines Containing Antibodies Or Antigens For Use As Internal Diagnostic Agents (AREA)
Abstract
METODO E EQUIPAMENTO PARA MELHORAR O DESEMPENHO DE ROHC AO ENCONTRAR SUPRESSAO DE SILENCIO São aqui descritos exemplos relacionados a métodos e sistemas para melhorar o desempenho de um compressor de compressão de header robusta (ROHC) ao encontrar supressão de silêncio. Em um exemplo, é calculado um incremento de marca de tempo (timestamp) RTP parapacotes sucessivos, até que um número predeterminado de pacotes possua um valor de incremento de marca de tempo constante, O valor de incremento de marca de tempo RTP constante é designado na forma de um valor de passo (stride) de marca de tempo (TO_STRIDE) para compressão, sendo o valor de cada marca de tempo (TS) RTP escalonado pelo passo de marca de rempo (TS_STRIDE) e o header é comprimido usando-se o valor designado.
Description
MÉTODO E EQUIPAMENTO PARA MELHORAR O DESEMPENHO DE ROHC AOENCONTRAR SUPRESSÃO DE SILÊNCIO
Antecedentes
Reivindicação de prioridade de acordo com 35 U.S.C. § 119.
O presente pedido de patente reivindica aprioridade do Pedido Provisório de Patente U.S. N- de Série60/756.658, intitulado "METHOD AND APPARATUS FOR ENHANCINGROHC PERFORMANCE WHEN ENCOUNTERING SILENCE SUPRESSION",depositado em 6 de janeiro de 2006, em nome da Requerenteda presente invenção e aqui expressamente incorporado pelapresente referência.
Campo
A presente invenção está de um modo geralrelacionada a sistemas de comunicação. Maisespecificamente, os exemplos aqui descritos estãorelacionados a métodos e sistemas para melhorar odesempenho de um compressor de compressão de header robusta(RoHC) ao encontrar supressão de silêncio.
Antecedente
0 Protocolo Internet (IP) se tornou o protocolode transporte escolhido para redes sem fio ou por cabo, eestá levando à convergência de redes de telecomunicação edados. Esforços vêm sendo feitos para comprimir headers deprotocolo, todavia, um desafio permanece no desenvolvimentode esquemas de compressão de header eficientes e robustos.
Breve Descrição dos Desenhos
A Figura 1 ilustra quadros e pacotes em umsistema de comunicação;
A Figura 2 ilustra um exemplo de compressão de header;
A Figura 3 ilustra um exemplo de um sistema decomunicação;A Figura 4 ilustra alguns componentes de hardwaree software de um BTS-RNC-PDSN;
A Figura 5 ilustra alguns componentes de hardwaree software de um terminal de acesso;
A Figura 6 ilustra uma série de pacotes em umacorrente de pacotes;
A Figura 7a ilustra pacotes de fala consecutivos;
A Figura 7b ilustra um segmento de falarepresentado por seis pacotes consecutivos;
A Figura 8 ilustra a supressão de silêncio em umexemplo;
A Figura 9 ilustra a supressão de silêncio emoutro exemplo;
A Figura 10 ilustra mudanças em TS_STRIDE em umexemplo;
A Figura 11 ilustra um exemplo de um processoconfigurado para melhorar o desempenho de RoHC;
A Figura 12 ilustra períodos de rajadas de fala eperíodos de silêncio em AMR;
A Figura 13 ilustra um fluxograma de um exemplode um processo configurado para melhorar o desempenho deRoHC;
A Figura 14 ilustra dispositivos correspondentesao método da Figura 13;
A Figura 15 ilustra um fluxograma de outroexemplo de um processo configurado para melhorar odesempenho de RoHC; e
A Figura 16 ilustra dispositivos correspondentesao método da Figura 15.
Descrição Detalhada
Os exemplos aqui descritos estão relacionados amétodos e sistemas para melhorar o desempenho de umcompressor de compressão de header robusto (RoHC) aoencontrar supressão de silêncio. Tais exemplos podem serimplementados em qualquer sistema de comunicação sem fio oupor cabos, tal como em redes celulares, redes públicas decomutação telefônica (PSTN's), Internet sem fio, redes desatélites, redes de área ampla (WAN's), redes de área localsem fio (WLAN's), redes VoIP, sistemas multimídia baseadosem IP, etc.
Em vários serviços e aplicações, por exemplo, devoz através de IP (VoIP), vídeo telefonia, jogosinterativos, serviços de mensagens, etc., os dados sãoformados em pacotes e roteados através de uma rede. Talcomo é aqui utilizado, o termo "quadro" se refere a umaparte de um quadro de dados formatado para transmissão emum sistema de comunicação. A Figura 1 ilustra váriospacotes 102 e quadros 104. Um quadro 104 pode possuir umacerta duração de tempo, por exemplo, 20 ms, e pode ou nãocoincidir com a duração de um pacote 102. Cada pacote éenviado para um destino na rede com base em um endereçodesignado, tipicamente contido em um header ou cabeçalho. 0header marca o início do pacote; um trailer ou cauda marcao final de um pacote; o termo "payload" ou "carga útil" serefere à parte de dados de um pacote. Um pacote podeapresentar vários tipos de headers, tal como headers deprotocolo Internet (IP), protocolo de datagrama de usuário(UDP), protocolo de transporte em tempo real (RTP) eprotocolo de controle de transmissão (TCP). Em certoscasos, a carga útil de um pacote IP pode ter tamanhocomparável, ou mesmo menor do que o header.
Em sistemas de linhas terrestres ou linhas decabos, as restrições sobre a amplitude de banda são baixase os dados podem ser comunicados pelo envio contínuo depacotes na taxa cheia. No entanto, nos sistemas decomunicação sem fio existe uma amplitude de banda limitadae, portanto, uma necessidade de econpmizá-la. Uma reduçãodo overhead dos pacotes pode ser conseguida pela redução detamanho dos headers dos pacotes. A compressão de headersmelhora a qualidade, a velocidade e a eficiência detransmissão da rede. Além disso, o tempo de respostainterativa é melhorado pela compressão dos headers,tornando possível dar suporte a maior número de usuáriosdentro de uma certa amplitude de banda de canal. Isto, porsua vez, resulta em uma redução de custos de implantação. AFigura 2 ilustra um exemplo de compressão de header em umsistema de comunicação implementando voz. Neste exemplo, oheader não comprimido adiciona 4 0 bytes de overhead. Com acompressão do header, o overhead resultante apresentará, aoinvés disso, 2 a 4 bytes. A compressão de header auxilia aeconomizar a amplitude de banda necessária por toda a rede.
A Figura 3 ilustra um exemplo de um sistema decomunicação 300 no qual um ou mais métodos aqui descritospodem ser implementados. Um primeiro terminal de acesso(AT) 301a inclui um compressor de header 302 de linkreverso (ou uplink). O primeiro terminal de acesso 301a secomunica de forma sem fio através de um link reverso (RL)com uma estação base 304a e um sistema transreceptor deestação base/nodo servidor de dados em pacotes (BTS-RNC-PDSN) 306a em uma rede de acesso por rádio (RAN).
O BTS-RNC-PDSN 306a inclui um descompressor deheader de link reverso 310, que pode efetuar um ou mais dosmétodos aqui descritos. O BTS-RNC-PDSN 306a se comunica comum nodo servidor de dados em pacotes/sistema transreceptorde estação base (PDSN-BTS) 306b através de uma rede VoIP308. O PDSN-BTS 306b inclui um compressor de header de linkde emissão (ou downlink) 312.
A estação base 304b e o PDSN-BTS 306b podem secomunicar de forma sem fio através de um link de emissãocom um segundo terminal de acesso 301b. O segundo terminalde acesso 301b inclui um descompressor de header de link deemissão 314, o qual pode efetuar um ou mais dos métodosaqui descritos. Em lugar de dois terminais de acesso semfio 301a e 301b, um dos terminais de acesso pode ser umterminal por cabos. 0 compressor de header de link reverso302 e o descompressor de header de link reverso 310representam um primeiro par de compressor-descompressor. 0compressor de header de link de emissão 312 e odescompressor de header de link de emissão 314 representamum segundo par compressor-descompressor.
O link reverso e o link de emissão podem usar umou mais protocolos de comunicação, tais como o de múltiploacesso por divisão de código (CDMA) lx, CDMA Ix EV-DO(dados de evolução otimizados), CDMA de banda larga (W-CDMA), CDMA sincronizado por divisão de tempo (TD-SCDMA),Sistema Global para Telecomunicações Móveis (GSM) ,multiplexação por divisão de freqüência ortogonal (OFDM) ,sistemas que suportem normas IEEE, tais como as 802.11 (A,BeG), 802.16, etc.
0 "terminal de acesso" aqui descrito pode servários tipos de dispositivos, tais como um telefone porcabos, um telefone sem fio, um telefone celular, umcomputador laptop, uma placa de comunicação sem fio paracomputador pessoal (PC), um assistente digital pessoal(PDA), um modejn externo ou interno, etc. Um terminal deacesso pode ser qualquer dispositivo de dados que secomunica através de um canal sem fio ou através de um canalcabeado, utilizando, por exemplo, fibras ópticas ou caboscoaxiais. Um terminal de acesso pode possuir vários nomes,tais como unidade de acesso, unidade de assinante, estaçãomóvel, dispositivo móvel, unidade móvel, telefone móvel,telemóvel, estação remota, terminal remoto, unidade remota,dispositivo de usuário, equipamento de usuário, dispositivomanual, etc. Os terminais de acesso podem ser móveis ouestacionários, e podem estar dispersos por todo o sistemade comunicação 300 da Figura 3. Os terminais de acessopodem se comunicar com um ou mais sistemas transreceptoresde estação base (BTS), os quais podem ser designados como(ou incluir) estações base, redes de acesso, pontos deacesso, Nodos B ou transreceptores de grupo de modems.
A Figura 4 ilustra um exemplo de algunscomponentes de hardware e software do BTS-RNC-PDSN 306ae/ou PDSN-BTS 30 6b da Figura 3. Um exemplo inclui umprocessador 400, um circuito integrado especifico paraaplicativo (ASIC) 402, um transreceptor 404 e uma memória
406. A memória 406 armazena uma ou mais camadas superiores407, tais como uma camada de aplicativo 408, uma camada detransporte 410 e uma camada de rede 412. A camada deaplicativo 408 processa headers de protocolo de transporteem tempo real (RTP ou RTPC) . A camada de transporte 410processa headers de protocolo de controle de transmissão(TCP) e protocolo de datagrama de usuário (UDP). A camadade rede 412 processa headers IP.
A memória 406 pode também armazenar um compressorde compressão de header robusta 312 e um descompressor decompressão de header robusta 310. 0 compressor decompressão de header robusta 312 pode armazenar uma unidadede cálculo de ' marca de tempo 312a e o descompressor decompressão de header robusta 310 pode armazenar uma unidadede cálculo de marca de tempo 310a. A memória 406 podetambém armazenar uma ou mais camadas inferiores 420, taiscomo uma camada de controle de acesso a meio (MAC) decamada de link 414, a gual pode incluir uma subcamada deprotocolo de link de rádio (RLP). As camadas inferiores 420podem também incluir uma camada física 416.
A Figura 5 ilustra alguns componentes de hardwaree software dos terminais de acesso 301a, 301b, da Figura 3.Um exemplo inclui um processador 500, um ASIC 502, umtransreceptor 504 e uma memória 506. A memória 506 podearmazenar uma ou mais camadas superiores 507, tais como umacamada de aplicativo 508, uma camada de transporte 510 euma camada de rede 512. A camada de aplicativo 508 podeprocessar headers RTP. A camada de transporte 510 podeprocessar headers TCP e UDP. A camada de rede 512 podeprocessar headers IP.
A memória 506 pode também armazenar um compressorde compressão de header robusta 302 e um descompressor decompressão de header robusta 314. O compressor decompressão de header robusta 302 pode armazenar uma unidadede cálculo de marca de tempo 302a e o descompressor decompressão de header robusta 314 pode armazenar uma unidadede cálculo de marca de tempo 314a. A memória 506 podearmazenar também uma ou mais camadas inferiores 520, taiscomo uma camada MAC de camada de link 514, a qual podeincluir uma subcamada RLP. A camada inferior 520 podetambém incluir uma camada física 516.
O RoHC é um esquema de compressão de header quecomprime eficientemente headers RTP/UDP/IP. A compressão deheader robusta está descrita na RFC (requisição paracomentários) 3095, intitulada "Robust Header Compression(ROHC) : Framework and four profiles: RTP, UDP, ESP anduncompressed", que é um protocolo de seguimento de normasda Internet distribuído pelo Network Working Group da TheInternet Society, em julho de 2001.
De um modo geral, os pacotes transferidos atravésde um link não são independentes entre si, compartilhando,porém, parâmetros específicos em comum, por exemplo,endereços de origem, endereços de destino, etc. Acompressão de headers é tornada possível pela significativaredundância entre campos de header dentro do mesmo pacoteou entre pacotes consecutivos pertencentes à mesma correntede pacotes. Uma "corrente de pacotes" se refere a umaseqüência de pacotes, usualmente agrupados de forma lógica,por exemplo, em uma corrente de pacotes de áudio ou umacorrente de pacotes de vídeo. Um algoritmo de RoHC utilizaparâmetros em comum em uma corrente de pacotes paracomprimir os headers de pacotes através da manutenção decertas informações de estado. Tais informações de estadosão designadas como um "contexto".
Um par de compressor/descompressor mantém umcontexto em cada ponta para cada corrente de pacotes. 0contexto para cada corrente de pacotes é identificado pelomesmo campo identificador de contexto (CID) no compressor eno descompressor. Como exemplo, o compressor de header deRL 302 e o descompressor de header de RL 310 na Figura 3podem, cada um, manter um contexto, "CIDi", para um fluxode voz especifico, xnVFi". O contexto contém informaçõesprovenientes de headers anteriores na corrente de pacotes eoutros valores de referência possíveis para compressão edescompressão. Dados que descrevem a corrente de pacotes,tais como informações sobre como um campo identificador IPse modifica e aumentos entre pacotes no número de seqüência(SN) ou marca de tempo (TS) também estão contidos em umcontexto. Para assegurar um esquema de compressão de headerrobusta, existe uma necessidade de mecanismos para evitarinconsistências de contexto e para tornar os contextosconsistentes quando eles não o são.
Inicialmente, um compressor e um descompressorpodem não ter um acordo sobre a compressão ou descompressãode uma certa corrente de pacotes. Um compressor pode enviarpacotes RoHC possuindo informações estáticas e dinâmicassobre uma corrente de pacotes para o descompressor paraestabelecer um contexto. Uma vez estabelecidos camposestáticos e dinâmicos, um compressor necessita apenasenviar um mínimo de informações para adiantar a seqüênciaregular de campos de header comprimidos. 0 compressor e odescompressor atualizam seus contextos quando da ocorrênciade certos eventos.
Os campos de header estáticos devem sertransmitidos somente no estabelecimento de um contexto, umavez que tais campos a seguir permanecem constantes.Algoritmos mais sofisticados são necessários para comprimiros aspectos dinâmicos de um campo de header. Um campo deheader dinâmico pode ser comprimido ou descomprimidodiretamente por um algoritmo de RoHC. No entanto, pode sèrmais eficaz comprimir ou descomprimir um campo de headerpelo uso de uma função linear de outros campos, tais comoum aumento em SsN ou TS. Isto demanda menor número de bits.
Pelo envio de informações de campos estáticos apenasinicialmente, e utilização de dependências eprevisibilidade para outros campos, o tamanho de headerpode ser significativamente reduzido para a maioria dospacotes.
O SN de um pacote RTP é incrementado em um paracada pacote transmitido e pode ser usado por um receptorpara restaurar a següência de pacotes e para detectar aperda de pacotes. A TS pode refletir o instante deamostragem de um primeiro octeto no pacote de dados RTP. Oinstante de amostragem é derivado a partir de um relógioque se incremente de forma monótona e linear no tempo. Emaplicativos que processam fala, a TS pode ser incrementadapor um delta constante que corresponde ao número deamostras em cada pacote de fala, Como exemplo, umdispositivo de alimentação pode receber pacotes de falapossuindo 160 períodos de amostragem; dessa forma, a TS éincrementada em 160 para cada pacote. A Figura 6 ilustrauma série de pacotes em uma corrente com SN e TSconsecutivas em incrementos de 160. 0 incremento de TS é omesmo, isto é, 160, caso o pacote porte um segmento de falaou represente um segmento de silêncio. Isto ocorre tambémseja a supressão de silêncio implementada ou não. Asupressão de silêncio será descrita em maiores detalhesmais adiante.
Um compressor RoHC estima o incremento em RTP TSentre dois pacotes gerados sucessivamente. Quando ospacotes RTP possuem números de seqüência consecutivos, talincremento é designado como TS_STRIDE. De um modo geral, oTS STRIDE entre pacotes consecutivos do mesmo tipoconstitui uma quantidade fixa. Como exemplo, a Figura 7ailustra um aplicativo em que SN1, . . . SN6 representampacotes de fala possuindo SNs consecutivos de 1, ... 6. Talcomo ilustrado, TS_STRIDE entre cada par de pacotes é adiferença de TS entre um pacote especifico e o pacoteanterior. Tal como ilustrado, TS__STRIDE entre dois pacotesé dado por TSj - Tsi, em que i e j são SNs consecutivos. NaFigura 7a, TS_STRIDE = (TSj - Tsi) = (TSk - TSj) = (TSi -TSk)/ etc. O conhecimento de tal quantidade fixa permite aocompressor escalonar o RTP TS antes da compressão. Dessaforma, a determinação acurada de TS_STRIDE entre os pacotesé necessária para compressão eficiente do campo de marca detempo de RTP.
O uso de um RTP TS escalonado reduz o overhead deheader uma vez que o escalonamento resulta na compressão deum valor menor e, conseqüentemente, menor número de bits.Como exemplo, consideremos voz portada através deRTP/UDP/IP. Em um CODEC de voz produzindo pacotes de 20 msamostrados a 8 kHz, a RTP TS aumenta pelo número deamostras contidas em 20 ms, ou 8000 χ 0,02 = 160 amostras.Um segmento de fala representado por seis pacotesconsecutivos está ilustrado na Figura 7b. A RTP TS seincrementa em 160 entre pacotes consecutivos, portanto, aRTP TS do primeiro pacote é 160, a RTP TS do segundo pacoteé 320, a RTP TS do terceiro pacote é 480, etc. Neste caso,um compressor pode usar valores escalonados de RTP TS de 1,2, 3, etc., em lugar dos valores de RTP TS de 160, 320,480, etc. Neste último caso, um compressor necessitariacodificar uma mudança de 160, enquanto que no caso anteriornecessitaria codificar uma mudança de 1, usando, portanto,menos bits. Como exemplo, o algoritmo RoHC pode comprimir ocampo RTP SN e a seguir usar relações lineares de RTP SNpara outros campos mutáveis, tais como a RTP TS.Em outra modalidade da presente invenção, podeser usada codificação de bits menos significativos (LSB)para comprimir os campos de header. Pelo uso de codificaçãode LSB's, os k bits menos significativos de um valor decampo são transmitidos em lugar de um valor de campointeiro, em que k é um número, inteiro positivo. Umdescompressor recebe os k bits e deriva o valor originalusando um valor recebido previamente como uma referência.Este valor pode ser designado como "v_ref". Para ilustrar,usando-se codificação LSB, o binário 00001010(correspondente ao decimal 10) , compreende os bits maissignificativos (MSB's) 0000 e os LSB's 1010. Em lugar detransmitir todos os oito bits do valor original, podem sertransmitidos os quatro LSB's 1010 para um dispositivoreceptor. Caso sejam recebidos com sucesso, umdescompressor deriva o valor do pacote original usançiov_ref. O v_ref pode ser armazenado em um contexto. Comoexemplo, v_ref representa o último valor de pacotecorretamente descomprimido. Presumindo-se a descompressãobem sucedida do header recebido, o contexto dodescompressor é atualizado para 00001010 e o pacoteoriginal é regenerado. Quando da regeneração bem sucedida,v_ref pode ser atualizado para um valor correntecorretamente descomprimido e armazenado. Presumindo-se queum próximo valor, 00001111 (valor decimal 15) , deve sertransmitido, os quatro LSB's 1111 podem ser transmitidos e,caso recebidos com sucesso, o descompressor atualiza seucontexto anexando o valor recebido 1111 aos MSB's do valorde contexto corrente e confere se o valor gerado estádentro de um intervalo de interpretação. Neste exemplo, ovalor de contexto corrente é de 00001010 e os MSB's são0000. O descompressor irá atualizar seu valor de contextopara 00001111 e regenerar o valor de pacote transmitidooriginalmente.Na codificação de fala, o ruído de fundo é de ummodo geral transmitido em conjunto com a fala. Caso atransmissão de fala seja cortada, ocorre também um corte doruído de fundo. Descontinuidades na transmissão do ruído defundo podem ser desconcertantes para um ouvinte que aguardafeedback proveniente da outra ponta do link de comunicação.
De um modo geral, o ruído de fundo serve como feedback.Durante um intervalo de "silêncio" (um instante, em umaconversação duplex total, em que pelo menos uma das partesfica em silêncio) o canal pode comunicar informações deruído de fundo usando pacotes de menor tamanho. Comoexemplo, vários sistemas CDMA enviam uma seqüência contínuade pacotes em taxa de um oitavo a cada 20 ms durante umperíodo de silêncio para comunicar o ruído de fundo. Paraeconomizar amplitude de banda em um sistema comutado empacotes, a maioria dos pacotes representando silêncio podemser descartados. Isto é feito sem comprometer a qualidadedo canal de comunicação e pode ser designado como supressãode silêncio.
Em vocodificadores, tais como CODEC AMR (Multi-taxa avançado) e EVRC (CODEC de taxa variávelaperfeiçoado), um esquema de compressão de dados éincorporado para a codificação de fala. Em taisaplicativos, um ruído sintético similar a ruído de fundo naponta de transmissão é gerado no lado de recepção (RX) .
Quando a fala não está presente, o ruído sintético éestimado no lado de transmissão e transmitido para o ladode recepção em intervalos freqüentes. Isto permite ao ruídosintético no receptor se adaptar a mudanças no ruído nolado de transmissão. Na codificação AMR, por exemplo,durante os períodos de silêncio, o ruído de fundo avaliadoé codificado em um pacote designado como um pacotedescritor de silêncio (SID). Os parâmetros de ruído defundo a serem codificados em um pacote SID são calculadossobre oito pacotes consecutivos e o pacote SID étransmitido para o lado do receptor a cada oitavo pacote.Efetivamente, sete de cada oito pacotes SID gerados sãodescartados na origem. Dessa forma, durante os períodos desilêncio, um CODEC AMR gera e transmite pacotes SID a cada8 χ 20 = 160 ms. Isto contrasta com os pacotes de falaregulares em uma rajada de fala, que são gerados a cada20 ms. No lado do receptor, a geração do ruido de fundo éiniciada ou atualizada sempre que um pacote SID válido érecebido.
Em um sistema que implementa a supressão desilêncio, uma RTP TS pode "pular" em proporção à duração doperíodo de silêncio. Durante a supressão de silêncio,apesar de alguns pacotes serem descartados, a RTP TScontinua a se incrementar, mas a RTP SN não se incrementa.Isto está ilustrado na Figura 8, em que um pacote é geradoe a ele designado um SN de 1 e possuindo uma TS de 160.Este pacote pode representar um segmento de fala.Subseqüentemente, três pacotes são descartados no emissor.Os pacotes descartados podem ser pacotes de um oitavo detaxa representando ruído de fundo. Nesta ilustração, ostrês pacotes descartados recebem as TS's 320, 480 e 640, emordem. Eles não recebem SN's. Na Figura 8, um quintopacote, representando um segmento de uma rajada de fala quese segue ao período de silêncio, é gerado e recebe um SN de2.0 quinto pacote recebe uma TS de 800, uma vez que oincremento em TS é de 160. Nesta ilustração, TS_STRIDEentre o primeiro pacote recebido, SN = 1, e o último pacoterecebido, SN = 2, é calculado como 800 - 160 = 640.
De um modo geral, quando TS_STRIDE for um valorfixo entre pacotes consecutivos, o valor comprimido de umaRTP TS escalonada é comunicado pelo compressor aodescompressor onde ela é descomprimida. Com um valor deTS_STRIDE fixo, são necessários poucos bytes, tal como emum pacote UOR-O ou UOR-1, para transmitir valorescomprimidos para o descompressor. Uma descrição detalhadadestes formatos de pacotes pode ser encontrada na RFC 3095.Estes pacotes possuem de um modo geral um a três bytes decomprimento (mais dois bytes de UDP checksum, caso seaplique) e contêm informações de SN, TS e CRC, que sãousadas para atualizar o contexto de um esquema decompressão de header. Como exemplo, na Figura 9 é presumidoque a fonte implementa supressão de silêncio. Os pacotesSN1, SN2, SN3 e SN4 são transmitidos com TS = 160, 320, 480e 960, respectivamente. Vamos presumir que dois pacotes desilêncio foram suprimidos entre os pacotes SN3 e SN4. Vamosadicionalmente presumir que, no compressor, a TS de cadapacote é comprimida por TS_STRIDE = 160. Portanto, oprimeiro pacote possui uma TS escalonada de 1, o segundopacote uma TS escalonada de 2, o terceiro pacote uma TSescalonada de 3 e o quarto pacote uma TS escalonada de 6.Neste caso, usando-se codificação LSB, na recepção dosegundo pacote, SN2, o algoritmo RoHC atualiza o contextodo compressor para representar o valor escalonado de 2 como0010. Ao receber o terceiro pacote, SN3, o contexto éatualizado com informações de TS e os bits 0010 sãoatualizados para 0011. Nesta situação, somente os últimospoucos bits devem ser modificados. Dessa forma, o contextopode ser atualizado pelo uso de um pequeno pacote, tal comoum pacote UOR-O ou UOR-I. 0 pequeno porte dos pacotes UOR-Oe UOR-I torna possível manter o uso eficiente da amplitudede banda.
Em um cenário em que o valor de TS_STRIDE semodifica, é necessário um pacote maior do que um UOR-O ouUOR-I para comunicar a mudança em TS_STRIDE. Como exemplo,pode ser usado um pacote UOR-2 ext 3, IR-DYN ou IR. Estespacotes possuem comprimento de pelo menos 7 ou 8 bytes e aamplitude de banda passa a preocupar, especialmente quandofor necessário transmitir estes pacotes várias vezes (casoa mudança em TS_STRIDE deva ser comunicada de formaconfiável, estes pacotes podem ter que ser repetidosalgumas vezes). Quando a origem RTP empregando supressão desilêncio passa do silêncio para a fala (e da fala para osilêncio), o compressor RoHC pode julgar que o TS_STRIDEmudou, levando-o a enviar o TS_STRIDE atualizado. Paracomunicar tal TS_STRIDE de forma confiável, o TS_STRIDEdeve ser enviado algumas vezes. Como exemplo, na Figura 10,TS_STRIDE é um primeiro valor, TS_STRIDEi durante umprimeiro segmento de fala, um segundo valor, TS_STRIDEk,durante um período de silêncio e o primeiro valor,TS_STRIDEi no segundo período de fala. Durante cada mudançaem TS_STRIDE, por exemplo, de TSJSTRIDEi para TS_STRIDEk, ocompressor RoHC pode atualizar seu contexto e isto demandao uso de mais bits, representado o valor atualizado deTS_STRIDE. Por outro lado, maiores pacotes UOR-2 ext 3, que podem ser transmitidos várias vezes, são usados paracomunicar o TS_STRIDE modificado. Fazendo novamentereferência à Figura 9, ocorre um salto em TS_STRIDE entreos pacotes SN3 e SN4 devido à supressão de silêncio. Aoreceber o pacote SN3, o compressor pode estimar TS_STRIDEcomo 160, enquanto ao receber o pacote SN4, o compressorestima TS_STRIDE como 480. Quando a origem RTP volta àfala, o compressor pode novamente estimar TS_STRIDE como160. A cada vez que o TS_STRIDE muda, o compressor podenecessitar enviar um pacote U0R-2 ext 3 (ou IR ou IR-DYN)para comunicar ;esta mudança para o descompressor.
Como exemplo, para superar as ineficiênciascausadas por uma mudança do valor de TS_STRIDE entrepacotes, o compressor pode não modificar seu valor deTS_STRIDE até que ele perceba um novo TS_STRIDE recorrenteem "N" ocorrências consecutivas. Em outras palavras, umcompressor pode continuar a usar seu valor calculado maisantigo de TS_STRIDE até que um número N predeterminado devalores consecutivos de novos TS_STRIDE calculados produzamo mesmo valor. Este exemplo está ilustrado na Figura 11.Na Figura 11 é gerado um pacote SNi, TS = 160.Este é seguido por dois pacotes que são subseqüentementedescartados no emissor devido à supressão de silêncio,seguindo-se a geração de quatro pacotes SN2, SN3, SN4 e SN^.
Estes pacotes possuem valores de TS de 640, 800, 960 e1120, respectivamente. Conforme ilustrado, os últimos trêsvalores consecutivos de TS_STRIDE permanecem constantes,com TS_STRIDE = 160. O compressor pode, portanto, usarTS STRIDE = 160 para a compressão. No exemplo acima, foiusado N = 3, todavia, o valor de N pode ser dependente doaplicativo. Além disso, apesar de RTP TS ter "pulado" 480entre os pacotes SN3 e SN4, o compressor não atualizou suaestimativa de TS_STRIDE, dado que o incremento de 480 emRTP TS ocorreu apenas uma vez. Em outros exemplos, ocompressor pode usar outros valores para N (por exemplo, 5)para a determinação do valor correto de TS_STRIDE.
Um caso de utilização de TS_STRIDE ocorrendo Nvezes consecutivas pode não ser o ideal quando vários (maisdo que o valor de N) pacotes consecutivos de SID ou taxa de1/8 sejam enviados durante o silêncio. Tais pacotes podemestar espaçados por uma quantidade igual de tempo na origeme, portanto, apresentam a mesma mudança de RTP TS. Comoexemplo, supondo que TS_STRIDE seja selecionado como umvalor ocorrendo em N ocorrências consecutivas de TS_STRIDEem uma aplicativo AMR. Conforme ilustrado na Figura 12,oito pacotes 706 de 20 ms são transmitidos durante umsegmento de fala 702 e TSJ3TRIDE é calculado por 8000 kHz χ0,020 s = 160. Durante o silêncio, um pacote SID 708 étransmitido a cada oito pacotes gerados durante o silêncio704. TS_STRIDE durante o silêncio é de 8000 kHz χ 0,160 s =1280. Na Figura 12, o pacote SN9 possui uma TS de 160 χ 9 =1440, o pacote SN10 possui uma TS de 160 χ 10 = 1600, opacote SID SNn possui uma TS de 160 χ 18 = 2880, o pacoteSID SN12 possui uma TS de 160 χ 26 = 4160, etc. Conformeilustrado, durante o primeiro período de fala, o compressorpercebe um valor de TS_STRIDE = 160, e durante o silêncioTS STRIDE é atualizado para 160 χ 8 = 1280. Portanto, em umcaso em que N = 2 e a contagem de N é acionada no pacoteSN12, o valor de TS_STRIDE ocorrendo em N ocorrências deTS_STRIDE = 1280. Dessa forma, o compressor RoHC podeestimar um valor atualizado de TS_STRIDE durante o silêncioe, portanto, deverá enviar um pacote maior.
Na Figura 12, TS_STRIDE é estimado como sendo 160durante o primeiro segmento de fala e o header comprimidopode ser comunicado ao descompressor por meio de um pacoteUOR-O ou UOR-I. No entanto, durante o silêncio, quandoTS_STRIDE é atualizado para 1280, o "salto" aparente emTS_STRIDE demanda o uso de um pacote maior UOR-2 ext 3, IR-DYN ou IR para comunicar o valor comprimido para odescompressor. Como foi acima mencionado, estes headersrequerem pelo menos 7 ou 8 bytes e, portanto, tomamamplitude de banda extra. Uma vez que a origem RTP volte àfala, TS_STRIDE aparenta mudar novamente para 160 χ 1 =160 e o descompressor deve ser atualizado. Novamente, amudança é comunicada para o descompressor através do maiorheader UOR-2 ext 3, IR ou IR-DYN. Este pacote maior podeter que ser enviado várias vezes para comunicar a mudançade forma confiável, resultando em uma utilização abaixo daideal da amplitude de banda. Portanto, quando RoHC estiver comprimindo pacotes gerados por AMR, a utilização de umvalor de TS_STRIDE determinado durante N pacotesconsecutivos pode ainda perceber um salto de TS STRIDEentre segmentos de fala e silêncio em uma rajada de fala.Isto resulta em um potencial desperdício de amplitude debanda. O AMR é aqui utilizado apenas com o propósito deilustração. Os conceitos aqui descritos podem ser aplicadosa outros algoritmos de codificação de fala.
Em um exemplo, em lugar de atualizar TS_STRIDEcaso o mesmo incremento de RTP TS seja observado durante Nocorrências, pode ser usado um valor "MIN_TS STRIDE", emque MIN TS_STRIDE é o valor mais baixo de TS_STRIDEcalculado durante o fluxo. MIN_TS_STRIDE representaTS STRIDE calculado quando a origem não está efetuandosupressão de silêncio, isto é, durante rajadas de fala.
Como exemplo, para um fluxo VoIP empregando supressão desilêncio, MIN_TS_STRIDE corresponde à mudança em RTP TSquando a origem não está efetuando supressão de silêncio.Isto corresponde também ao TS_STRIDE real a ser usado paracompressão.
A Figura 13 ilustra um fluxograma de um exemplode um processo configurado para melhorar o desempenho deRoHC. Conforme ilustrado, na etapa 802, é determinado seRoHC está sendo implementado em um sistema. Caso negativo,o processo termina. Caso RoHC esteja sendo implementado, érecebido um pacote na etapa 804. Na etapa 806, édeterminado o incremento em RTP TS entre o pacote recebidoe um pacote recebido anteriormente. Este valor é designadocomo TS_INCREMENT. Pode ser presumido que um valor originalde TS_STRIDE tenha sido previamente usado para compressão.Na etapa 808, caso seja determinado que TS_INCREMENT paraos N pacotes consecutivos anteriores é o mesmo, e que talvalor difere do valor corrente de TS_STRIDE, o processopassa para a próxima etapa 810. Caso contrário, o processovolta à etapa 806. Na etapa 810, TS_STRIDE é atualizado ciovalor original para TS_INCREMENT.
A Figura 15' ilustra um fluxograma de outroexemplo de um processo configurado para melhorar odesempenho de RoHC. Tal como ilustrado, na etapa 902, édeterminado se RoHC está sendo implementado em um sistema.Caso negativo, o processo termina. Caso RoHC esteja sendoimplementado, na etapa 904 é recebido um pacote. Na etapa906 é determinado se o incremento em RTP TS é menor do queo TS_STRIDE mínimo observado para a corrente de pacotesatual. Caso negativo, o processo volta à etapa 904; casocontrário, o processo prossegue para a etapa 908. Na etapa908 TS STRIDE é atualizado para o incremento em RTP TS (oqual era menor do que o TS_STRIDE mínimo para o fluxo).
Os métodos das Figuras 13 e 15 acima descritospodem ser efetuados por dispositivos correspondentes, alémde blocos de função, ilustrados nas Figuras 14 e 16. Emoutras palavras, os blocos 802 a 810 ilustrados na Figura13 correspondem aos dispositivos mais blocos de função 1802a 1810 ilustrados na Figura 14. Os blocos 902 a 908ilustrados na Figura 15 correspondem aos dispositivos maisblocos de funções 1902 a 1908 ilustrados na Figura 16.
Em outra modalidade, quando ocorre uma mudança emTS_STRIDE entre segmentos de fala e silêncio, a mudançapode não ser apropriadamente comunicada ao descompressor. 0"dano de contexto" ocorre quando o contexto d/descompressor não está consistente com o contexto docompressor e a descompressão falha em reproduzir o headeroriginal. Tal situação pode ocorrer quando pacotes tenhamsido perdidos ou danificados entre o compressor e odescompressor, ou quando o valor de TS_STRIDE no compressordeixa de alcançar um descompressor. Os pacotes que nãopodem ser descomprimidos devido a contextos inconsistentessão "perdidos" devido a danos de contexto. Os pacotes quesão descomprimidos, mas contêm erros devidos a contextosinconsistentes são "danificados" devido a dano de contexto.0 RoHC pode usar uma conferência de redundância cíclica(CRC) em um header original para detectar descompressãoincorreta. Em uma situação em que o compressor observa umprimeiro valor TS_STRIDE enquanto o descompressor observaum valor diferente, pode ocorrer uma falha de tal código deCRC.
Como exemplo, na Figura 12, supondo que TS_STRIDEseja 160 durante o primeiro segmento de fala e 1280 duranteo segmento de silêncio como foi acima descrito. Presumindo-se adicionalmente que devido às condições ruins do canal,todos os headers U0R-2 ext 3 que foram enviados a partir docompressor para comunicar a mudança de TS_STRIDE foramdescartados. Como resultado, apesar de o valor de TS_STRIDEter mudado de 160 para 1280 no compressor, o descompressornão percebe esta mudança. Dessa forma, quando odescompressor regenera um próximo pacote, ele usa um valorrepresentando TS_STRIDE = 160 em lugar do valor atualizadode 1280. A CRC falha, pois o pacote regenerado é diferentedaquele pacote originalmente transmitido. Como resultado, odescompressor pode descartar o pacote regenerado.
Outra vantagem dos algoritmos aqui descritosconsiste em que, uma vez que TS_STRIDE não é estimado comomudando quando a origem RTP passa de fala a silêncio e desilêncio a fala, é eliminada qualquer vulnerabilidadepotencial introduzida devido à atualização de TS_STRIDEquando a fonte RTP passa entre silêncio e fala.
Os exemplos aqui descritos propiciam algunsexemplos de melhoria de desempenho de RoHC quando ocorre asupressão de silêncio. Vários dos exemplos descritos podemser implementados em qualquer compressor RoHC, por exemplo,associado a um AT, uma AN e outros dispositivos queempreguem compressão de header. Vários módulos/unidades eexemplos aqui descritos podem ser implementados emhardware, software, firmware ou uma combinação destes. Parauma implementação em hardware, várias unidades podem serimplementadas dentro de um ou mais circuitos integradosespecíficos para aplicativo (ASIC), processadores de sinaisdigitais (DSP) , dispositivos processadores de sinaisdigitais (DSPD), conjuntos de portas de campo programáveis(FPGA), processadores, microprocessadores, controladores,dispositivos lógicos programáveis (PLD), outras unidadeseletrônicas ou qualquer combinação destes. Para umaimplementação em software, várias unidades podem serimplementadas por meio de módulos (por exemplo,procedimentos, funções e assim por diante) que efetuam asfunções aqui descritas. Os códigos de software podem serarmazenados em uma unidade de memória e executadas por umprocessador (ou unidade de processamento). A unidade dememória pode ser implementada no interior do processador ouexternamente ao processador, caso este em que ela podeestar acoplada em comunicação com o processador através devários dispositivos, como é do conhecimento dos técnicos naárea.
Os técnicos na área notarão que as informações esinais podem ser representados usando-se quaisquer dentreuma diversidade de diferentes tecnologias e técnicas. Comoexemplo, dados, instruções, comandos, informações, sinais,bits, símbolos e chips que possam ter sido mencionados portoda a descrição acima podem ser representados porvoltagens, correntes, ondas eletromagnéticas, campos oupartículas eletromagnéticas, campos ou partículas ópticasou quaisquer combinações destes.
Os técnicos na área notarão adicionalmente que osvários exemplos de blocos lógicos, módulos, circuitos eetapas de algoritmos descritos em conexão com asmodalidades aqui descritas podem ser implementados na formade hardware eletrônico, software de computador oucombinações destes. Para ilustrar claramente talintercambialidade de hardware e software, vários exemplosde componentes, blocos, módulos, circuitos e etapas foramacima descritos de um modo geral em termos de suafuncionalidade. Se tal funcionalidade é implementada naforma de um hardware ou software depende da aplicação erestrições de projeto específicas impostas ao sistema comoum todo. Os técnicos na área podem implementar afuncionalidade descrita de diversas formas para cadaaplicação específica, porém tais decisões de implementaçãonão devem ser interpretadas como um afastamento do escopoda presente invenção.
Os vários exemplos de blocos lógicos, módulos ecircuitos aqui descritos em conexão com as modalidades aquiapresentadas podem ser implementados ou efetivados por meiode um processador de uso geral, um processador de sinaisdigitais (DSP), um circuito integrado especifico paraaplicativo (ASIC), arranjos de porta programáveis no campo(FPGA) ou outros dispositivos lógicos programáveis, portasindividuais ou lógica de transistores, componentes dehardware individuais, ou guaisquer combinações destes,projetadas para efetuar as funções aqui descritas. Umprocessador de uso geral pode ser um microprocessador,porém como alternativa o processador pode ser qualquerprocessador, controlador, microcontrolador ou máquina deestado convencionais. Um processador pode também serimplementado na forma de uma combinação de dispositivos decomputação, por exemplo, uma combinação de um DSP e ummicroprocessador, uma pluralidade de microprocessadores, umou mais microprocessadores em conjunto com um núcleo DSP ouqualquer outra configuração similar.
As etapas de um método ou algoritmo descritos emconexão com as modalidades aqui apresentadas podem serefetivadas diretamente em hardware, em um módulo desoftware executado por um processador ou em uma combinaçãode ambos. Um módulo de software pode residir em uma memóriaRAM (memória de acesso aleatório), memória flash, memóriaROM (memória de leitura somente), memória EPROM (ROMeletricamente programável), memória EEPROM (ROMeletricamente programável apagável), registradores, discorígido, um disco removível, um CD-ROM ou qualquer outraforma de meio de armazenamento conhecido pelos técnicos naárea. Um exemplo de meio de armazenamento pode ser acopladoao processador de tal forma que o processador possa lerinformações provenientes do, e gravar informações no, meiode armazenamento. Como alternativa, o meio de armazenamentopode estar integrado ao processador. 0 processador e o meiode armazenamento podem residir em um ASIC. 0 ASIC poderesidir em um terminal de acesso (AT). Como alternativa, oprocessador e o meio de armazenamento podem residir naforma de componentes individuais em um terminal de acesso.
A descrição acima das modalidades preferidas éprovida para permitir que os técnicos na área efetivem oufaçam uso da presente invenção. As diferentes modificaçõesdessas modalidades ficarão prontamente claras para óstécnicos na área e os princípios genéricos aqui definidospodem ser aplicados a outros exemplos sem se afastar doespirito e do escopo da presente invenção. Dessa forma, apresente invenção não deve ser limitada aos exemplos aquiapresentados, devendo receber o escopo mais amplo,consistente com os princípios e características novos aquidescritos.
Claims (20)
1. Um método para comprimir um headercompreendendo:determinar uma marca de tempo (TS) de protocolode transporte em tempo real (RTP) para pelo menos um dentreuma pluralidade de pacotes sucessivos;calcular um incremento de marca de tempo RTP parapacotes sucessivos até que um número predeterminado depacotes possuam um valor de incremento de marca de tempoconstante;designar o valor de incremento de marca de tempoRTP constante como um valor de passo de marca de tempo(TS_STRIDE) para compressão;reduzir o valor de cada marca de tempo (TS) RTPpelo passo de marca de tempo (TS_STRIDE); ecomprimir o header usando o valor designado.
2. Um método para comprimir um headercompreendendo:determinar uma marca de tempo (TS) de protocolode transporte em tempo real (RTP) para pelo menos um dentreuma pluralidade de pacotes sucessivos;calcular um incremento de marca de tempo RTP parapacotes sucessivos;encontrar um incremento de marca de tempo RTPmínimo (MIN_TS_STRIDE) pela duração de um fluxo;designar o valor de incremento de marca de tempoRTP mínimo (MIN_TS_STRIDE) como um valor de passo de marcade tempo (TS_STRIDE) para compressão;reduzir o valor de cada marca de tempo (TS) RTPpelo passo de marca de tempo (TS_STRIDE); ecomprimir o header usando o valor designado.
3. O método da reivindicação 2, em que acompressão compreende:determinar um valor codificado usando codificaçãode bit menos significativo baseada em intervalo; eatualizar um contexto com o valor codificado.
4. 0 método da reivindicação 3, em que acompreensão compreende adicionalmente:determinar uma diferença entre um primeiro valorno contexto correspondente a um pacote anterior e umsegundo valor correspondente a um pacote corrente;atualizar o contexto com o segundo valor; ecomprimir um header do pacote corrente com osegundo valor.
5. 0 método da reivindicação 2, em que o headercompreende informações relacionadas a pelo menos um dentreprotocolo internet (IP), protocolo de transporte em temporeal (RTP), protocolo de datagrama de usuário (UDP) eprotocolo de controle de transmissão (TCP).
6. 0 método da reivindicação 2, em que oincremento de marca de tempo (TS_STRIDE) é um número deamostras em um pacote.
7. 0 método da reivindicação 1, em que o númeropredeterminado é 5.
8. 0 método da reivindicação 1, em que o númeropredeterminado é um primeiro valor para um primeiro tipo dedados e um segundo valor para um segundo tipo de dados.
9. 0 método da reivindicação I1 em que ospacotes compreendem dados de fala.
10. Um equipamento para comprimir um headercompreendendo:dispositivos para determinar uma marca de tempo(TS) de protocolo de transporte em tempo real (RTP) parapelo menos um dentre uma pluralidade de pacotes sucessivos;dispositivos para calcular um incremento de marcade tempo RTP para pacotes sucessivos até que um númeropredeterminado de pacotes possuam um valor de incremento demarca de tempo constante;dispositivos para designar o valor de incrementode marca de tempo RTP constante como um valor de passo demarca de tempo (TS_STRIDE) para compressão;dispositivos para reduzir o valor de cada marcade tempo (TS) RTP pelo passo de marca de tempo (TS_STRIDE);edispositivos para comprimir o header usando ovalor designado.
11.Um equipamento para comprimir um headercompreendendo:dispositivos para determinar uma marca de tempo(TS) de protocolo de transporte em tempo real (RTP) parapelo menos um dentre uma pluralidade de pacotes sucessivos;dispositivos para calcular um incremento de marcade tempo RTP para pacotes sucessivos;dispositivos para encontrar um valor deincremento de marca de tempo RTP minimo (MIN_TS_STRIDE)pela duração de um fluxo;dispositivos para designar o valor de incrementode marca de tempo RTP minimo (MIN_TS_STRIDE) como um valorde passo de marca de tempo (TS_STRIDE) para compressão;dispositivos para reduzir o valor de cada marcade tempo (TS) RTP pelo passo de marca de tempo (TS_STRIDE);edispositivos para comprimir o header usando ovalor designado.
12.0 equipamento da reivindicação 11, em que osdispositivos p^ra comprimir compreendem:dispositivos para determinar um valor codificadousando codificação de bit menos significativo baseada emintervalo; edispositivos para atualizar um contexto com ovalor codificado.
13.O equipamento da reivindicação 12, em que osdispositivos para comprimir compreendem adicionalmente:dispositivos para determinar uma diferença entreum primeiro valor no contexto correspondendo a um pacoteanterior e um segundo valor correspondendo a um pacotecorrente;dispositivos para atualizar o contexto com osegundo valor; edispositivos para comprimir um header do pacotecorrente com o segundo valor.
14. 0 equipamento da reivindicação 11,compreendendo adicionalmente dispositivos para transmitir oheader comprimido.
15. Um equipamento compreendendo:dispositivos para receber pelo menos um valor depasso de marca de tempo (TS_STRIDE);dispositivos para receber pelo menos um pacotecomprimido;dispositivos para descomprimir o pacotecomprimido compreendendo:decodificar o pacote usando um intervalo debits menos significativo; edispositivos para determinar um valor de umamarca de tempo (TS) de pelo menos um pacote com base novalor de passo de marca de tempo (TS_STRIDE) recebido.
16. Um equipamento compreendendo:dispositivos para determinar um incremento demarca de tempo mínimo (MIN_ TS_STRIDE) para uma pluralidadede pacotes;dispositivos para receber um pacote corrente;dispositivos para determinar um incremento demarca de tempo para o pacote corrente;caso o incremento de marca de tempo do pacotecorrente seja menor do que o incremento de marca de tempomínimo (MIN_?S_STRIDE) da pluralidade de pacotes,dispositivos para atualizar o valor de incremento de marcade tempo mínimo (MIN_ TS_STRIDE);dispositivos para transmitir o valor atualizadopara um descompressor;dispositivos para receber um próximo pacote; edispositivos para comprimir o próximo pacote combase no incremento de marca de tempo mínimo (MIN_TSJ5TRIDE) atualizado.
17. 0 equipamento da reivindicação 16, em que osdispositivos para atualizar compreendem:dispositivos para modificar o incremento de marcade tempo mínimo (MIN_ TS_STRIDE) para o incremento de marcade tempo (TS_STRIDE) do pacote corrente.
18. Um equipamento compreendendo:dispositivos para receber uma pluralidade depacotes;dispositivos para determinar uma pluralidade devalores de incremento de marca de tempo (TS_STRIDE) para ospacotes recebidos;dispositivos para determinar se a pluralidade devalores de marca de tempo permanece constante para Npacotes recebidos;dispositivos para comparar os valoresdeterminados de. incremento de marca de tempo (TS_STRIDE)com um incremento de marca de tempo (TS_STRIDE) armazenadoem um contexto;dispositivos para atualizar o valor armazenadocaso o incremento de marca de tempo (TS_STRIDE) para os Núltimos pacotes consecutivos recebidos permaneça o mesmo eseja diferente do valor armazenado;dispositivos para receber um pacote corrente; edispositivos para comprimir o pacote correnteusando o incremento de marca de tempo (TS STRIDE)atualizado.
19. Um produto de programa de computadorcompreendendo:uma primeira pluralidade de códigos paradeterminar um incremento de marca de tempo mínimo (MIN_TS STRIDE) para uma pluralidade de pacotes;uma segunda pluralidade de códigos para recebérum pacote corrente;uma terceira pluralidade de códigos paradeterminar um incremento de marca de tempo do pacotecorrente;uma quarta pluralidade de códigos para atualizaro valor de incremento de marca de tempo mínimo (MIN_TS_STRIDE) caso o incremento de marca de tempo do pacotecorrente seja menor do que o incremento de marca de tempomínimo (MIN_ TS_STRIDE) da pluralidade de pacotes;uma quinta pluralidade de códigos para transmitiro valor atualizado para um descompressor;uma sexta pluralidade de códigos para receber umpróximo pacote; euma sétima pluralidade de códigos para comprimiro próximo pacote com base no incremento de marca de tempomínimo (MIN_ TS_STRIDE) atualizado.
20. Um produto de programa de computadorcompreendendo:uma primeira pluralidade de códigos para receberuma pluralidade de pacotes;uma segunda pluralidade de códigos paradeterminar uma pluralidade de valores de incremento demarca de tempo (TS_STRIDE) para os pacotes recebidos;uma terceira pluralidade de códigos paradeterminar se a pluralidade de valores de marca de tempopermanece constante para N pacotes recebidos;uma quarta pluralidade de códigos para compararos valores de incremento de marca de tempo (TS STRIDE)determinados com um incremento de marca de tempo(TS STRIDE) armazenado em um contexto;uma quinta pluralidade de códigos para atualizaro valor armazenado caso o incremento de marca de tempo(TS_STRIDE) para os N últimos pacotes consecutivosrecebidos permaneça o mesmo e seja diferente do valorarmazenado;uma sexta pluralidade de códigos para receber umpacote corrente; euma sétima pluralidade de códigos para comprimiro pacote corrente usando o incremento de marca de tempo(TS STRIDE) atualizado.
Applications Claiming Priority (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US75665806P | 2006-01-06 | 2006-01-06 | |
| US60/756,658 | 2006-01-06 | ||
| US11/545,956 US7907609B2 (en) | 2006-01-06 | 2006-10-10 | Method and apparatus for enhancing RoHC performance when encountering silence suppression |
| US11/545,956 | 2006-10-10 | ||
| PCT/US2007/060191 WO2007112140A2 (en) | 2006-01-06 | 2007-01-05 | Method and apparatus for enhancing rohc performance when encountering silence suppression |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| BRPI0706417A2 true BRPI0706417A2 (pt) | 2011-03-29 |
| BRPI0706417A8 BRPI0706417A8 (pt) | 2018-08-28 |
Family
ID=38541764
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| BRPI0706417A BRPI0706417A8 (pt) | 2006-01-06 | 2007-01-05 | método e equipamento para melhorar o desempenho de rohc ao encontrar supressão de silêncio |
Country Status (13)
| Country | Link |
|---|---|
| US (1) | US7907609B2 (pt) |
| EP (1) | EP1974528B1 (pt) |
| JP (3) | JP2009522954A (pt) |
| KR (1) | KR100965438B1 (pt) |
| CN (1) | CN101366261B (pt) |
| AU (1) | AU2007230862B2 (pt) |
| BR (1) | BRPI0706417A8 (pt) |
| CA (1) | CA2633896C (pt) |
| IL (1) | IL192076A0 (pt) |
| NO (1) | NO20083421L (pt) |
| RU (1) | RU2407205C2 (pt) |
| TW (1) | TWI381689B (pt) |
| WO (1) | WO2007112140A2 (pt) |
Families Citing this family (36)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8755113B2 (en) | 2006-08-31 | 2014-06-17 | Moxtek, Inc. | Durable, inorganic, absorptive, ultra-violet, grid polarizer |
| KR100745782B1 (ko) * | 2006-09-29 | 2007-08-03 | 한국전자통신연구원 | 동적 헤더 압축 장치 및 방법 |
| WO2009017340A2 (en) * | 2007-07-27 | 2009-02-05 | Lg Electronics Inc. | Method of transmitting packet for reducing header overhead |
| US8265065B2 (en) * | 2007-09-14 | 2012-09-11 | Sharp Laboratories Of America, Inc. | Method and system for voice-over-internet-protocol (VoIP) transmission in a wireless communications network |
| US8059632B2 (en) * | 2007-09-14 | 2011-11-15 | Sharp Laboratories Of America, Inc. | Method and system for transmission of channel quality indicators (CQIs) by mobile devices in a wireless communications network |
| CN102349285B (zh) * | 2009-03-19 | 2014-04-16 | 富士通株式会社 | 接收装置、发送装置、接收方法、发送方法、通信系统及通信方法 |
| JP5778672B2 (ja) | 2009-07-08 | 2015-09-16 | トムソン ライセンシングＴｈｏｍｓｏｎ Ｌｉｃｅｎｓｉｎｇ | バックワードルッキングロバストヘッダ圧縮レシーバ |
| EP2282577B1 (en) * | 2009-07-27 | 2012-05-23 | Institute for Imformation Industry | Wireless communication apparatus, header compression method thereof, and header decompression method thereof |
| EP2312804B1 (en) * | 2009-10-13 | 2015-02-25 | BlackBerry Limited | Methods and apparatus for intelligent selection of a transport protocol for content streaming |
| KR101568881B1 (ko) | 2009-10-14 | 2015-11-12 | 에릭슨 엘지 주식회사 | 헤더 압축 효율 향상 방법 및 그를 위한 패킷 송신 장치 |
| CN101674315B (zh) | 2009-10-20 | 2014-12-10 | 中兴通讯股份有限公司 | 一种时间戳压缩、解压缩的方法及装置 |
| US9769287B2 (en) * | 2010-05-10 | 2017-09-19 | Telefonaktiebolaget Lm Ericsson (Publ) | Reducing protocol overhead in single-block packet access procedures |
| US8611007B2 (en) | 2010-09-21 | 2013-12-17 | Moxtek, Inc. | Fine pitch wire grid polarizer |
| US8913321B2 (en) | 2010-09-21 | 2014-12-16 | Moxtek, Inc. | Fine pitch grid polarizer |
| US8472754B1 (en) | 2010-11-11 | 2013-06-25 | Amazon Technologies, Inc. | Image artifact prevention |
| US8688762B2 (en) | 2011-02-22 | 2014-04-01 | Lsi Corporation | Iterative-division operations such as for header compression in packet-based communications |
| US8370526B2 (en) | 2011-02-22 | 2013-02-05 | Lsi Corporation | Binary-shift operations such as for header compression in packet-based communications |
| US8873144B2 (en) | 2011-05-17 | 2014-10-28 | Moxtek, Inc. | Wire grid polarizer with multiple functionality sections |
| US8913320B2 (en) | 2011-05-17 | 2014-12-16 | Moxtek, Inc. | Wire grid polarizer with bordered sections |
| US20130155918A1 (en) * | 2011-12-20 | 2013-06-20 | Nokia Siemens Networks Oy | Techniques To Enhance Header Compression Efficiency And Enhance Mobile Node Security |
| US8922890B2 (en) | 2012-03-21 | 2014-12-30 | Moxtek, Inc. | Polarizer edge rib modification |
| CN102882879B (zh) * | 2012-10-08 | 2015-10-07 | 中国电子科技集团公司第五十四研究所 | 一种适用于卫星信道的ip数据压缩传输方法 |
| CN103812846A (zh) * | 2012-11-14 | 2014-05-21 | 重庆重邮信科通信技术有限公司 | 一种头压缩方法及系统 |
| AU2013387114B2 (en) * | 2013-04-17 | 2018-02-22 | Interdigital Vc Holdings, Inc. | Method and apparatus for packet header compression |
| US9354374B2 (en) | 2013-10-24 | 2016-05-31 | Moxtek, Inc. | Polarizer with wire pair over rib |
| US20150195326A1 (en) * | 2014-01-03 | 2015-07-09 | Qualcomm Incorporated | Detecting whether header compression is being used for a first stream based upon a delay disparity between the first stream and a second stream |
| US9923695B2 (en) | 2014-09-24 | 2018-03-20 | Samsung Electronics Co., Ltd. | Call processing method and apparatus for use in LTE system |
| CN104320810B (zh) * | 2014-11-07 | 2018-07-06 | 大唐移动通信设备有限公司 | 一种头压缩方法、装置及解压缩方法、装置 |
| US11032194B2 (en) * | 2015-01-09 | 2021-06-08 | Samsung Electronics Co., Ltd. | Transmitting apparatus and signal processing method using removal of transport steam packet header |
| US10037240B2 (en) * | 2015-09-24 | 2018-07-31 | Qualcomm Incorporated | Timestamp repair mechanism in case of decompression failure |
| CN106941697A (zh) * | 2016-01-04 | 2017-07-11 | 中兴通讯股份有限公司 | 一种发送、接收时间戳信息的方法和装置 |
| CN108737349B (zh) * | 2017-04-24 | 2020-08-28 | 大唐移动通信设备有限公司 | 一种语音数据包的处理方法及装置 |
| US11330665B2 (en) * | 2020-01-09 | 2022-05-10 | Qualcomm Incorporated | Increasing throughput efficiency in a PDCP channel with ROHC TCP profile |
| TWI739320B (zh) * | 2020-02-25 | 2021-09-11 | 瑞昱半導體股份有限公司 | 網路通訊裝置以及網路映射表的操作方法 |
| WO2024151259A1 (en) * | 2023-01-11 | 2024-07-18 | Zeku, Inc. | Protocol test framework for performance analysis |
| WO2025014476A1 (en) * | 2023-07-11 | 2025-01-16 | Greater Shine Limited | Apparatus and method for robust header compression cyclic redundancy check computation using a vector engine |
Family Cites Families (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE69927243T2 (de) * | 1999-05-25 | 2006-06-29 | Lucent Technologies Inc. | Verfahren und Vorrichtung für Telekommunikationen mit Internet-Protokoll |
| US6680921B1 (en) * | 1999-06-18 | 2004-01-20 | Telefonaktiebolaget Lm Ericsson (Publ) | Estimation of time stamps in real-time packet communications |
| US6680955B1 (en) | 1999-08-20 | 2004-01-20 | Nokia Networks Oy | Technique for compressing a header field in a data packet |
| US6535925B1 (en) * | 1999-11-09 | 2003-03-18 | Telefonaktiebolaget L M Ericsson (Publ) | Packet header compression using division remainders |
| US7061936B2 (en) * | 2000-03-03 | 2006-06-13 | Ntt Docomo, Inc. | Method and apparatus for packet transmission with header compression |
| DE60018927T2 (de) * | 2000-09-07 | 2005-07-28 | Matsushita Electric Industrial Co. Ltd., Kadoma | Verfahren und Vorrichtung zur Datenpaketenübertragung |
| ATE472897T1 (de) * | 2000-09-28 | 2010-07-15 | Nokia Corp | Verfahren und kompressor zur komprimierung von zeitstempelinformation von paketen |
| JP3556195B2 (ja) * | 2000-11-06 | 2004-08-18 | 松下電器産業株式会社 | ヘッダ圧縮方法及び装置並びにプログラム |
| JP2002290383A (ja) * | 2001-03-27 | 2002-10-04 | Ntt Docomo Inc | パケット伝送制御方法及び送信装置 |
| US7031666B2 (en) | 2001-03-28 | 2006-04-18 | Qualcomm Incorporated. | Method and apparatus for header compression in a wireless communication system |
| WO2003041424A2 (en) * | 2001-11-06 | 2003-05-15 | Koninklijke Philips Electronics N.V. | Wireless communication arrangements with encapsulation and header compression |
| EP1315356B1 (en) | 2001-11-24 | 2008-10-22 | Lg Electronics Inc. | Method for transmitting packet data in compressed form in a communication system |
| US20050190700A1 (en) * | 2002-05-07 | 2005-09-01 | Koninklijke Philips Electronics N.V. | Wireless communication arrangements with packet transmissions |
| KR100889864B1 (ko) * | 2002-08-14 | 2009-03-24 | 엘지전자 주식회사 | 멀티미디어 데이터의 압축 전송 방법 및 시스템 |
-
2006
- 2006-10-10 US US11/545,956 patent/US7907609B2/en active Active
-
2007
- 2007-01-05 JP JP2008549667A patent/JP2009522954A/ja active Pending
- 2007-01-05 TW TW096100635A patent/TWI381689B/zh active
- 2007-01-05 WO PCT/US2007/060191 patent/WO2007112140A2/en not_active Ceased
- 2007-01-05 CA CA2633896A patent/CA2633896C/en not_active Expired - Fee Related
- 2007-01-05 RU RU2008132318/09A patent/RU2407205C2/ru not_active IP Right Cessation
- 2007-01-05 KR KR1020087019329A patent/KR100965438B1/ko active Active
- 2007-01-05 CN CN2007800019260A patent/CN101366261B/zh active Active
- 2007-01-05 EP EP07756304.7A patent/EP1974528B1/en not_active Not-in-force
- 2007-01-05 AU AU2007230862A patent/AU2007230862B2/en not_active Expired - Fee Related
- 2007-01-05 BR BRPI0706417A patent/BRPI0706417A8/pt not_active Application Discontinuation
-
2008
- 2008-06-11 IL IL192076A patent/IL192076A0/en unknown
- 2008-08-05 NO NO20083421A patent/NO20083421L/no not_active Application Discontinuation
-
2011
- 2011-06-22 JP JP2011138576A patent/JP5134115B2/ja active Active
-
2013
- 2013-06-19 JP JP2013128899A patent/JP2013243690A/ja active Pending
Also Published As
| Publication number | Publication date |
|---|---|
| US7907609B2 (en) | 2011-03-15 |
| RU2008132318A (ru) | 2010-02-20 |
| WO2007112140A2 (en) | 2007-10-04 |
| EP1974528A2 (en) | 2008-10-01 |
| TW200814667A (en) | 2008-03-16 |
| JP2011239432A (ja) | 2011-11-24 |
| RU2407205C2 (ru) | 2010-12-20 |
| US20100278196A1 (en) | 2010-11-04 |
| JP2009522954A (ja) | 2009-06-11 |
| CN101366261A (zh) | 2009-02-11 |
| AU2007230862B2 (en) | 2010-12-02 |
| CA2633896A1 (en) | 2007-10-04 |
| CA2633896C (en) | 2013-04-02 |
| BRPI0706417A8 (pt) | 2018-08-28 |
| KR100965438B1 (ko) | 2010-06-24 |
| CN101366261B (zh) | 2013-03-27 |
| AU2007230862A1 (en) | 2007-10-04 |
| IL192076A0 (en) | 2009-08-03 |
| EP1974528B1 (en) | 2017-03-08 |
| KR20080083355A (ko) | 2008-09-17 |
| JP5134115B2 (ja) | 2013-01-30 |
| NO20083421L (no) | 2008-10-06 |
| JP2013243690A (ja) | 2013-12-05 |
| WO2007112140A3 (en) | 2008-01-03 |
| TWI381689B (zh) | 2013-01-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| BRPI0706417A2 (pt) | método e equipamento para melhorar o desempenho de rohc ao encontrar supressão de silêncio | |
| Bormann et al. | RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed | |
| ES2525641T3 (es) | Método y sistema para comprimir y descomprimir encabezamientos de paquetes | |
| CN1197281C (zh) | 实时业务中的标题压缩 | |
| US9125088B2 (en) | Dynamic robust header compression | |
| EP1415474B1 (en) | Method and compressor for compressing packet timestamp information | |
| JP4598082B2 (ja) | エラーに強いヘッダ圧縮においてローカル修正を強化させるための方法及びシステム | |
| JP2005509381A6 (ja) | ヘッダ圧縮を行う無線通信装置 | |
| CN1371560A (zh) | 自适应语音缓存的方法和系统 | |
| ES2958212T3 (es) | Señalización de una solicitud de adaptación de una sesión de comunicación de voz sobre IP | |
| WO2001063774A1 (en) | Partial redundancy encoding of speech | |
| CN109219078A (zh) | 语音丢包处理方法及装置 | |
| JP5307207B2 (ja) | ネットワーク内の順序のずれたデータパケットの効率的な符号化 | |
| Cellatoglu et al. | Robust header compression for real-time services in cellular networks | |
| Larzon et al. | Efficient transport of voice over IP over cellular links | |
| CN100428733C (zh) | 移动通信网络中ip报头压缩的错误恢复方法及装置 | |
| JP2009501500A5 (pt) | ||
| TWI538459B (zh) | 蜂巢式無線通信網路上支援網路語音服務方法及裝置 | |
| CN109936864A (zh) | 一种跨站切换中构建头压缩上下文的方法和装置 | |
| CN121125703A (zh) | 语音报文的解压缩方法、装置、解压缩设备及存储介质 | |
| CN121218258A (zh) | 一种报文处理方法、设备、装置及存储介质 | |
| Yoshimura et al. | Network Working Group C. Bormann, Editor, TZI/Uni Bremen Request for Comments: 3095 C. Burmeister, Matsushita Category: Standards Track M. Degermark, Univ. of Arizona H. Fukushima, Matsushita H. Hannu, Ericsson |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| B06F | Objections, documents and/or translations needed after an examination request according [chapter 6.6 patent gazette] | ||
| B06T | Formal requirements before examination [chapter 6.20 patent gazette] | ||
| B11E | Dismissal acc. art. 34 of ipl - requirements for examination incomplete | ||
| B11T | Dismissal of application maintained [chapter 11.20 patent gazette] |