PT1221239E - Método e sistema para comprimir e descomprimir cabeçalhos de pacotes - Google Patents

Método e sistema para comprimir e descomprimir cabeçalhos de pacotes Download PDF

Info

Publication number
PT1221239E
PT1221239E PT970868T PT00970868T PT1221239E PT 1221239 E PT1221239 E PT 1221239E PT 970868 T PT970868 T PT 970868T PT 00970868 T PT00970868 T PT 00970868T PT 1221239 E PT1221239 E PT 1221239E
Authority
PT
Portugal
Prior art keywords
header
packet
packets
receiver
transmitter
Prior art date
Application number
PT970868T
Other languages
English (en)
Inventor
Khiem Le
Christopher Clanton
Haihong Zheng
Zhigang Liu
Original Assignee
Nokia Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Corp filed Critical Nokia Corp
Publication of PT1221239E publication Critical patent/PT1221239E/pt

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/0078Avoidance of errors by organising the transmitted data in a format specifically designed to deal with errors, e.g. location
    • H04L1/0079Formats for control data
    • H04L1/0082Formats for control data fields explicitly indicating existence of error in data being transmitted, e.g. so that downstream stations can avoid decoding erroneous packet; relays
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1809Selective-repeat protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829Arrangements specially adapted for the receiver end
    • H04L1/1854Scheduling and prioritising arrangements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04Protocols for data compression, e.g. ROHC
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/164Adaptation or special uses of UDP protocol
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/40Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/65Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22Parsing or analysis of headers

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)
  • Communication Control (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Small-Scale Networks (AREA)
  • Packages (AREA)

Description

ΕΡ1221239Β1
DESCRIÇÃO
MÉTODO E SISTEMA PARA COMPRIMIR E DESCOMPRIMIR CABEÇALHOS
DE PACOTES A presente invenção refere-se à compressão e descompressão de cabeçalhos nas transmissões de pacotes de dados.
Relativamente à multimédia em tempo real baseada no Protocolo de Internet (IP - Internet Protocol), o Protocolo de Transferência em Tempo Real (RTP - Real-Time Transfer Protocol) é utilizado predominantemente em cima do Protocolo de Datagrama de Utilizador (UDP - User Datagram Protocol/IP). 0 RTP é descrito em pormenores em RFC 1889. 0 tamanho dos cabeçalhos IP/UDP/RTP combinados é de, pelo menos, 40 bytes para IPv4 e de, pelo menos, 60 bytes para IPv6. Um total de 40 a 60 bytes de overhead (espaço sem dados) por pacote pode ser considerado pesado nos sistemas (por exemplo, tal como redes celulares) em que a eficiência espetral é uma preocupação principal. Consequentemente, são necessários mecanismos de compressão de cabeçalhos IP/UDP/RTP adequados. Um esquema de compressão de cabeçalhos atual é descrito em RFC 2508, por S. Casner, V. Jacobson, "Compressing IP/UDP/RTP Headers for Low Speed Serial Links", Internet Engineering Task Force (IETP), Fevereiro de 1999, e que é capaz de comprimir o cabeçalho IP/UDP/RTP de 40/60 bytes até 2 ou 4 bytes através de ligações ponto a ponto. Os algoritmos de compressão de cabeçalhos existentes baseiam-se na observação de que a maioria dos campos dos cabeçalhos de pacote IP permanece constante num fluxo de pacotes durante uma sessão. Deste modo, é possível comprimir as informações de cabeçalho estabelecendo um estado de compressão (as informações de cabeçalho completo) no descompressor e transportando simplesmente a quantidade mínima de informações de 1 ΕΡ1221239Β1 cabeçalho do compressor para o descompressor.
Os esquemas de compressão de cabeçalhos IP/UDP/RTP, conforme descrito, por exemplo, em RFC 2508, tiram partido do fato de determinados campos de informação transportados no cabeçalho 1.) não serem alterados (campos de cabeçalho de 'Tipo 1') ou 2.) serem alterados de uma forma completamente previsível (campos de cabeçalho de 'Tipo 2'). Outros campos, denominados campos de cabeçalho de 'Tipo 3', variam de tal modo que têm de ser transmitidos de alguma forma em todos os pacotes (ou seja, não são compressíveis).
Os exemplos de campos de cabeçalho de Tipo 1 são o endereço IP, número de porta UDP, RTP SSRC (fonte de sincronização), etc. Estes campos só necessitam de ser transmitidos ao recetor/descompressor uma vez durante o curso de uma sessão (como parte dos pacotes transferidos no estabelecimento da sessão, por exemplo). Os campos de Tipo 1 são igualmente designados por campos 'inalteráveis'.
Os exemplos de campos de cabeçalho de Tipo 2 são os campos de carimbo de hora RTP, número de sequências RTP e IP ID. Todos têm uma tendência para incrementar em alguma quantidade constante de pacote(n) para pacote (n+1). Deste modo, não é necessário transmitir estes valores em todos os cabeçalhos. Só é preciso que o recetor/descompressor se já informado do valor de incremento constante, doravante referido como a diferença de primeira ordem (FOD - First Order Difference), associada a cada campo que apresente este comportamento. O recetor/descompressor utiliza estes FODs para regenerar os valores de campo de Tipo 2 atualizados ao reconstruir o cabeçalho original. Os campos de Tipo 2 fazem parte dos campos 'alteráveis'.
Convém realçar que, às vezes, os campos de Tipo 2 serão alterados de alguma forma irregular. A frequência desses eventos depende de diversos fatores, incluindo o tipo de multimédia que está a ser transmitido (por exemplo, voz ou vídeo), a fonte de multimédia efetiva (por exemplo, 2 ΕΡ1221239Β1 para voz, o comportamento pode variar entre altifalantes), e o número de sessões que partilham simultaneamente o mesmo endereço IP.
Um Exemplo de um campo de cabeçalho de Tipo 3 é o M-bit RTP (Marcador), que indica a ocorrência de alguma fronteira na multimédia (por exemplo, o fim de um fotograma de vídeo) . Uma vez que a multimédia varia normalmente de formas imprevisíveis, estas informações não podem ser fielmente previstas. Os campos de Tipo 3 fazem parte dos campos 'alteráveis'. 0 descompressor mantém as informações de contexto de descompressão que contêm todas as informações pertinentes relacionadas com a reconstrução do cabeçalho. Estas informações são essencialmente campos de Tipo 1, valores FOD e outras informações. Quando os pacotes se perdem ou ficam danificados, o descompressor pode perder a sincronização com o compressor, de modo a não poder mais reconstruir pacotes corretamente. A perda de sincronização pode ocorrer quando os pacotes se perdem ou ficam danificados durante a transmissão entre o compressor e o descompressor.
Dado o referido acima, o compressor necessita de transmitir três tipos diferentes de cabeçalhos durante o curso de uma sessão: • Cabeçalho Completo (FH - Full Header): contém o conjunto completo de todos os campos de cabeçalho (Tipos 1, 2 e 3) . Este tipo de cabeçalho é o menos ideal para enviar devido ao seu tamanho grande (por exemplo, 40 bytes para IPv4). Em geral, é desejável enviar um pacote FH apenas no início da sessão (para estabelecer dados de Tipo 1 no recetor). A transmissão de pacotes FH adicionais tem efeitos adversos na eficiência do algoritmo de compressão. Quando o compressor transmite pacotes FH, é referido como 3 ΕΡ1221239Β1 estando no 'estado FH'.
Primeira Ordem (FO - First Order) : contém informações de cabeçalho mínimas (por exemplo campos de Tipo 3), campos de controlo específicos de compressor/descompressor (específicos para o algoritmo de compressão em utilização), e informações que descrevem alterações nos campos FOD atuais. Um pacote FO é basicamente um pacote SO (descrito abaixo), com informações adicionais que estabelecem novas informações FOD para um ou mais campos de Tipo 2 no descompressor. Se a compressão de cabeçalhos estiver a ser aplicada num fluxo VoIP (voice over internet protocol - voz sobre protocolo de Internet), a transmissão de um pacote FO poderá ser acionada pela ocorrência de um segmento contínuo de voz após um intervalo de silêncio na voz. Esse evento resulta em alguma alteração inesperada no valor de carimbo de hora RTP e numa necessidade de atualizar o carimbo de hora RTP no recetor por um valor que não o FOD atual. 0 tamanho de pacotes FO depende do número de campos de Tipo 2 cuja diferença de primeira ordem foi alterada (e a quantidade do valor absoluto de cada alteração). Quando o compressor transmite pacotes FO, é referido como estando no 'estado FO'.
Segunda Ordem (SO - Second Order) : um pacote SO contém informações de cabeçalho mínimas (por exemplo campos de Tipo 3) , e campos de controlo específicos de compressor e descompressor. 0 modo preferido de funcionamento para o compressor e descompressor é a transmissão e receção de pacotes SO, devido ao seu tamanho mínimo (na ordem de apenas 2 bytes ou até menos). Quando o compressor transmite pacotes SO, é referido como estando no 'estado SO'. Os pacotes SO só são transmitidos se o cabeçalho atual se adaptar ao padrão de um FOD. 4 ΕΡ1221239Β1 0 RFC 2508 baseia-se no conceito de que, na maior parte das vezes, os campos RTP que mudam de um pacote para o seguinte, tal como o carimbo de hora RTP, podem ser previstos através de extrapolação linear de pacotes SO transmitidos. Essencialmente, a única informação que tem de ser enviada é um número de sequência, utilizado para deteção de erro e perda de pacotes (bem como um ID de informações de contexto) . Quando o transmissor determina que a extrapolação linear não pode ser aplicada no pacote atual relativamente ao pacote imediatamente anterior, é transmitido um pacote FO. Para iniciar a sessão, é transmitido um pacote FH. Além disso, quando o recetor determina que existe uma perda de pacotes (conforme detetado através de um número de sequências que é incrementado em mais de 1) , 0 recetor solicita explicitamente ao transmissor para transmitir o cabeçalho completo de modo a permitir uma nova sincronização.
Contudo, a compressão de cabeçalhos definida em RFC 2508 não é perfeitamente adequada para determinados ambientes (tais como ambientes celulares ou sem fios), em que a largura de banda tem uma grande procura e os erros são comuns. No esquema de compressão de cabeçalhos RFC 2508, parte-se do princípio de que o carimbo de hora RTP tem, na maior parte das vezes, um padrão linearmente crescente. Quando o cabeçalho está em conformidade com o padrão, essencialmente só é necessário um número de sequências abreviado enviado como SO no cabeçalho comprimido. Quando o cabeçalho não está em conformidade com o padrão, a diferença entre os carimbos de hora RTP do cabeçalho atual e do anterior é enviada no cabeçalho comprimido FO. O requisito de largura de banda adicional pode manifestar-se de várias formas, dependendo do ambiente de funcionamento. Por exemplo, nos sistemas celulares é, no geral, bastante aconselhável limitar a utilização da 5 ΕΡ1221239Β1 largura de banda o mais possível, uma vez que é um recurso escasso. 0 RFC 2508 sofre de falta de robustez para suportar perdas ou erros de cabeçalho, uma vez que a descompressão do cabeçalho atual só pode ser efetuada se o cabeçalho imediatamente anterior também tiver sido recebido sem erros e descomprimido. A compressão de cabeçalhos definida em RFC 2508 não é perfeitamente adequada para ambientes celulares, em que a largura de banda tem uma grande procura e não são invulgares grandes rajadas de erros. Em RFC 2508, quando é detetada uma perda de pacotes, os pacotes subsequentes com cabeçalhos comprimidos são invalidados, com um outro requisito que é necessário para enviar um cabeçalho de tamanho grande para recuperar do erro. Os cabeçalhos de tamanho grande consomem largura de banda e criam picos na procura de largura de banda que são mais difíceis de gerir. A utilização apenas de um número de sequências abreviado (um com um número limitado de bits) para detetar a perda de pacotes não é robusta para uma rede propensa a erros, tal como numa rede sem fios em que a grande perda pode acontecer a qualquer momento. Neste caso, a grande perda é definida como perda do ciclo de sequência ou de pacotes em fila. Numa situação de grande perda, pode perder-se uma série de pacotes no número de pacotes do ciclo de sequência com uma identificação de pacote definida por um número limitado de bits e, por consequência, o número de sequências no pacote recebido pelo descompressor (dispositivo de receção na ligação ascendente ou ligação descendente) do recetor é moldado (repete-se). Por exemplo, assumindo que o número de sequências consiste em bits k, o ciclo de sequência é igual a 2k.
Conforme ilustrado na Fig. 1, o compressor (dispositivo de transmissão na ligação ascendente ou ligação descendente) enviou o pacote com a seq=n no momento t0, e os seguintes 2k pacotes, a começar no pacote com a 6 ΕΡ1221239Β1 seq=n+l no momento ti e a terminar no pacote com a seq=n no momento t2. No momento t3, o compressor envia um pacote com um número de sequências igual a n+1 novamente. Partamos do principio de que um pacote com um número de sequências igual a n+1 é enviado no momento ti até o pacote com o número de sequências igual a n ser enviado no momento t2, em que todos se perdem devido a uma grande perda e, em seguida, o descompressor só recebe o pacote com o número de sequências igual a n enviado no momento to e o pacote com o número de sequências igual a n+1 enviado no momento t3. Com base no esquema de deteção de perda de pacotes atual definido em RFC 2508, o descompressor conclui que não existe nenhuma perda de pacotes e descomprime o pacote de uma forma errada. Isto não só afeta a exatidão da descompressão do pacote com um número de sequências igual a n+1, como também os pacotes subsequentes. A compressão do cabeçalho é revelada em, por exemplo, 'Compressing headers over WAN media (CIPX)', IETFIREQUEST FOR COMMENTS 1553. A invenção é definida pelas reivindicações. A presente invenção pode fornecer melhores transmissão e receção de pacotes em ambientes, tais como comunicações sem fios, que são propensas a interrupção periódica de receção de pacotes, tal como a causada pela diminuição de intensidade, etc. A invenção pode fornecer um melhor desempenho de transmissão e receção de pacotes em comparação com RFC 2508, incluindo a eliminação do problema de moldagem (wrap around) do estado da técnica descrito acima na Fig. 1. A descodificação adequada de um cabeçalho comprimido num pacote atual de acordo com a invenção não depende da descompressão correta de um pacote imediatamente anterior, tal como com RFC 2508.
Esta invenção proporciona um mecanismo que deteta uma grande perda ao nivel da compressão de cabeçalhos, bem como um esquema de recuperação correspondente após a deteção da grande perda. Geralmente, a invenção é aplicável a 7 ΕΡ1221239Β1 protocolos de comunicação onde a sincronização de sequências tem de ser mantida entre o transmissor e o recetor, na presença de grandes rajadas de erros. A compressão de cabeçalhos adaptável é uma estrutura geral para compressão de cabeçalhos robusta que pode ser parametrizada para explicar a existência/não-existência e as caracteristicas de desempenho de um canal inverso. A estrutura inclui três modos básicos de funcionamento: • Modo Determinista Bidirecional: Este modo é utilizado no caso de existir um canal inverso 'bem definido', que pode ser utilizado para transportar vários tipos de informações de retorno do descompressor para o compressor. Um exemplo desse retorno do descompressor é um reconhecimento utilizado, por exemplo, para passar de um estado de compressão inferior para um estado de compressão superior. • Modo Oportunista Bidirecional: Este modo de funcionamento é utilizado no caso de existir um canal inverso, mas é definido 'vagamente', ou seja, o canal pode não estar sempre disponível ou pode ser lento/não fidedigno. • Modo Unidirecional (Pessimista ou Otimista): este modo de funcionamento é utilizado quando não existe nenhum canal inverso de qualquer tipo. A Fig. 1 ilustra a deficiência da perda de pacotes COM RFC 2508. A Fig. 2 ilustra um exemplo de uma arquitetura de sistema que pode ser utilizada para praticar a presente invenção • A Fig. 3 ilustra conceptualmente as informações de contexto de compressão. A Fig. 4 ilustra conceptualmente as informações de contexto de descompressão. 8 ΕΡ1221239Β1
As Figs. 5A e 5B ilustram uma primeira forma de realização da presente invenção. A Fig. 6 ilustra a transição de um compressor a partir de cabeçalhos de transmissão com um número elevado de bits para cabeçalhos com um número inferior de bits utilizando reconhecimentos de acordo com a presente invenção. A Fig. 7 ilustra a transição de um compressor a partir de cabeçalhos de transmissão com uma primeira ordem de compressão para cabeçalhos com uma segunda ordem de compressão de acordo com a presente invenção. A Fig. 8 ilustra a deteção e recuperação de pacotes quando ocorre uma moldagem com um número de pacotes superior a 2k, em que são utilizados bits k para codificar números de sequência n definidos pelos bits k. A Fig. 9 ilustra o funcionamento de um compressor e descompressor utilizando reconhecimentos para controlar a transição entre números de sequência que contêm bits k e bits £ de extensão e novamente para bits k de acordo com a presente invenção. A Fig. 10 ilustra a redução de largura de banda alcançada através da transmissão de uma sequência de pacotes FH e FO antes de ser gerado um reconhecimento pelo descompressor significando a receção de um pacote FH. A Fig. 11 ilustra a extrapolação de pacotes recebidos pelo decompressor para recuperar cabeçalhos de pacote perdidos de acordo com a presente invenção. A Fig. 12 ilustra a compensação do número de sequências de acordo com a presente invenção quando os pacotes são perdidos. A Fig. 13 ilustra a deteção de erros a montante de um decompressor para reduzir a largura de banda de transmissão de acordo com a presente invenção. 9 ΕΡ1221239Β1
As Figs. 14A a F ilustram formatos de pacotes que são transmitidos pela presente invenção. A Fig. 15 ilustra a mudança de um estado de compressão de um compressor para um estado de compressão superior apenas depois de ser recebido um reconhecimento de um descompressor de acordo com a invenção. A Fig. 16 ilustra a mudança de um estado de compressão de um compressor para um estado de compressão superior antes de um número atual de pacotes chegar a uma descompressão quando é recebido um reconhecimento. A Fig. 17 ilustra a mudança de um estado de compressão de um compressor para um estado de compressão superior depois de um número predefinido de pacotes chegar a um descompressor antes de chegar um reconhecimento. A Fig. 18 ilustra a mudança de um estado de compressão de um compressor para um estado de compressão superior apenas depois de um número atual de pacotes chegar a uma descompressão. A Fig. 19 ilustra graficamente uma comparação da invenção com RFC 2508. A Fig. 20 ilustra uma análise gráfica do desempenho da presente invenção.
Melhor Modo Para Levar a Cabo a Invenção A Fig. 2 ilustra um sistema exemplar no qual as várias formas de realização da presente invenção podem ser praticadas. Contudo, convém compreender que a presente invenção não está limitada a isso, com outras arquiteturas de sistema sendo igualmente aplicáveis na prática da invenção. Um terminal 102 está ligado a uma rede IP 108. 0 terminal 102 pode ser, sem limitação, um computador pessoal ou afins a executar RTP/UDP/IP e proporcionar amostras de voz em pacotes RTP para transmissão através da rede IP 108. O terminal 102 inclui um ponto final RTP 104 que identifica 10 ΕΡ1221239Β1 este terminal (por exemplo, incluindo endereço IP, número de porta, etc.) como uma fonte e/ou destino de pacotes RTP. Contudo, embora a rede IP 108 seja fornecida como um exemplo de uma rede de pacotes, podem ser utilizados outros tipos de redes de comutação de pacotes ou afins em vez disso. 0 terminal 102 inclui igualmente um temporizador local 103 para gerar um carimbo de hora.
As inf raestruturas de rede de acesso (ANI - Access Network Infrastructures) 110 e 120, que podem residir num subsistema de estação de base (BSS - Base Station Subsystem) , estão ligadas à rede IP 108. As ANIs são entidades de rede e nós de rede. Vários terminais móveis sem fios, que são entidades de rede e nós de rede e funcionam como compressores móveis e descompressores móveis (são ilustrados dois terminais sem fios 130 e 150) , são acoplados através de ligações de radiofrequência (RF) 140 às ANIs 110 e 120. Quando um dos terminais móveis 130 e/ou 150 se desloca, é necessário que os terminais, de vez em quando, como uma consequência do movimento fora do alcance da ligação de rádio a uma ANI, sejam entregues a outra ANI. Quando a compressão e a descompressão de cabeçalhos são utilizadas e se encontram na ANI, este processo também necessita da transferência de informações de contexto de compressão e descompressão de uma ANI (antiga) para outra ANI (nova) para obter continuidade, por exemplo se os terminais móveis 130 e/ou 150 se deslocarem e forem entregues da ANI 110 à ANI 120. A transferência, conforme descrito abaixo, pode acontecer em vários momentos, mas para minimizar a interrupção deve estar concluída no momento em que a ANI nova assume o papel de compressão/descompressão de cabeçalhos da ANI antiga. O reposicionamento das funções de compressão/descompressão ocorre quando a nova entidade de rede assume o controlo num determinado momento. Por outro lado, a transferência de informações de contexto pode ser difundida através de um 11 ΕΡ1221239Β1 material de tempo e anteceder o reposicionamento. A ligação RF 140 inclui, conforme ilustrado, um tráfego de ligações ascendentes 142 (dos terminais móveis 130 e 150 para a ANI 110) e um tráfego de ligações descendentes 144 (da ANI 110 para os terminais móveis 130 e 150) . Os terminais móveis 130 e/ou 150 são entregues a partir de uma ANI, tal como ANI 110, quando um ou mais dos terminais móveis se deslocam para outra ANI, por exemplo ANI 120. Cada ANI funciona como interface com um ou mais dos terminais sem fios (ou radiofrequência) (incluindo o terminal 130) numa região para a rede IP 108, incluindo a conversão entre sinais fixos (fornecidos a partir da rede IP 108) e sinais sem fios ou RF (fornecidos a ou a partir dos terminais 130 e 150) . Deste modo, cada ANI permite que os pacotes, tais como, mas não se limitando a, pacotes RTP transmitidos e recebidos a partir da rede IP 108, sejam enviados através da ligação RF 140 a, pelo menos, um dos terminais sem fios 130 e 150, e permite que a transmissão de pacotes, tais como pacotes RTP, mas não se limitando a pacotes RTP, seja efetuada a partir dos terminais 130 e 150 e através da rede IP 108 para outro terminal, tal como o terminal 102.
Cada ANI inclui uma pluralidade de entidades. A representação e explicação mais pormenorizadas da ANI 110 são proporcionadas para facilitar a compreensão da arquitetura e do funcionamento de todas as ANIs existentes na rede. Todas as ANIs podem pertencer à mesma arquitetura da ANI 110, mas não são ilustradas no mesmo grau de pormenores. A ANI 110 inclui um ou mais adaptadores ANI (ANI_AD), tais como ANI_AD 112 (ilustrado em pormenores) e ANI_AD 114, em que cada um inclui preferencialmente um temporizador 113 para proporcionar um carimbo de hora. Cada ANI_AD efetua a compressão (antes do tráfego de ligações descendentes) e a descompressão (depois do tráfego de ligações ascendentes) de cabeçalhos. Os cabeçalhos (um ou mais campos de cabeçalho, tais como um carimbo de hora e 12 ΕΡ1221239Β1 número de sequência) para pacotes RTP recebidos a partir da rede IP 108 são comprimidos por ANI_AD 112 antes da transmissão para os terminais 130 e 150 através do tráfego de ligações descendentes 142, e os cabeçalhos de pacote recebidos a partir dos terminais móveis 130 e 150 são descomprimidos por ANI_AD 112 antes da transmissão para a rede IP 108. O ANI_AD 110 funciona como um transmissor/recetor (transcetor) e especificamente como um compressor/descompressor 115 com o compressor a comprimir pacotes de dados antes da transmissão e o descompressor a descomprimir pacotes de dados após a receção. O ANI_AD 110 funciona como interface com terminais localizados numa área especifica ou diferente na região para a rede IP 108. O ANI_AD 112 inclui um temporizador 113 para implementar uma técnica de descompressão baseada no temporizador. O ANI_AD 112 inclui igualmente uma função de redução de instabilidade de sinal (JRF - Jitter Reduction Function) 116 que funciona para medir a instabilidade de sinal nos pacotes (ou cabeçalhos) recebidos através da rede 108 e rejeitar quaisquer pacotes/cabeçalhos que tenham instabilidade de sinal excessiva.
Cada terminal inclui uma pluralidade de entidades. A explicação mais pormenorizada do terminal móvel 130 é proporcionada para facilitar a compreensão da conceção e do funcionamento de todos os terminais móveis 130 e 150 existentes na rede que têm uma conceção e um funcionamento semelhantes. Cada um dos terminais móveis também pode funcionar como um compressor/descompressor nas comunicações fora do alcance das ANIs 110 e 120 e, especificamente, com outras redes. O terminal móvel 130 inclui um ponto final RTP 132 que é uma fonte (transmissor) e/ou destino (recetor) para pacotes RTP e identifica o endereço IP, o número de porta, etc. do terminal. O terminal móvel 130 inclui um adaptador de terminal (MS_AD) 136 que efetua a compressão (pacotes para serem transmitidos através do 13 ΕΡ1221239Β1
tráfego de ligações ascendentes 142) e a descompressão (pacotes recebidos através do tráfego de ligações descendentes 144) de pacotes. Deste modo, o adaptador de terminal (MS_AD) 136 pode ser considerado como um compressor/descompressor (transcetor) de cabeçalhos 137, semelhante ao compressor/descompressor ANI_AD. A terminologia MS_AD tem o mesmo significado de AD. 0 MS_AD 136 inclui igualmente um temporizador 134 (um temporizador recetor) para calcular uma aproximação (ou estimativa) de um carimbo de hora RTP de um cabeçalho atual e para medir o tempo decorrido entre os pacotes recebidos sucessivamente para localizar a perda de pacotes durante a transmissão para o terminal através da degradação sem fios, tal como a diminuição de intensidade. 0 MS_AD 136 pode utilizar informações adicionais no cabeçalho RTP para aperfeiçoar ou corrigir a aproximação de carimbo de hora, conforme descrito no Pedido de Patente copendente n.° de série 0 9/377.913 . A aproximação de carimbo de hora pode ser corrigida ou ajustada com base no carimbo de hora comprimido proporcionado no cabeçalho RTP. Deste modo, é possível utilizar um temporizador local e um carimbo de hora comprimido para regenerar o carimbo de hora correto para cada cabeçalho RTP.
Os pacotes RTP, incluindo pacotes com cabeçalhos comprimidos e não comprimidos, são transmitidos na rede, tal como, mas sem limitação, a rede exemplar da Fig. 2, através de uma ligação de dados (tal como uma ligação sem fios 140) , em que a largura de banda tem uma grande procura e os erros não são invulgares. A presente invenção não é limitada a uma ligação sem fios, mas é aplicável a uma grande variedade de ligações (incluindo ligações fixas, etc.). A Fig. 3 ilustra conceptualmente as informações de contexto de compressão e os exemplos. As informações de contexto de compressão são um conjunto, um subconjunto ou 14 ΕΡ1221239Β1 uma representação de um subconjunto de informações que podem ser de qualquer tipo num cabeçalho utilizado pelo compressor como uma entrada para o algoritmo de compressão para produzir um cabeçalho comprimido e podem ser transmitidas de uma entidade para outra entidade. A outra entrada é a partir da fonte dos cabeçalhos a serem comprimidos. A Fig. 4 ilustra conceptualmente as informações de contexto de descompressão e os exemplos. As informações de contexto de descompressão são um conjunto, um subconjunto ou uma representação de um subconjunto de informações que podem ser de qualquer tipo num cabeçalho utilizado pelo descompressor como uma entrada para o algoritmo de descompressão para produzir um cabeçalho descomprimido e podem ser transmitidas de uma entidade para outra entidade. A outra entrada é a partir da fonte dos cabeçalhos a serem descomprimidos.
Tanto as informações de contexto de compressão como de descompressão são dinâmicas, ou seja, podem ser atualizadas pelo compressor e descompressor respetivamente. A frequência de atualizações depende do esquema de compressão de cabeçalhos. Os eventos que podem resultar numa atualização das informações de contexto de compressão no compressor incluem a compressão de um cabeçalho de entrada ou a receção do retorno a partir do descompressor. Os eventos que podem resultar numa atualização das informações de contexto de descompressão no descompressor incluem a descompressão de um cabeçalho de entrada. A Compressão de Cabeçalhos Adaptável (ACE - Adaptive Header Compression) é uma estrutura geral para compressão de cabeçalhos robusta que pode ser parametrizada para explicar a existência/não-existência e as caracteristicas de desempenho de um canal de retorno. A estrutura inclui três modos básicos de funcionamento: 15 ΕΡ1221239Β1
Modo Determinista Bidirecional: este modo é utilizado no caso de existir um canal inverso 'bem definido', que pode ser utilizado para transportar vários tipos de informações de retorno do descompressor para o compressor. Um exemplo desse retorno do descompressor é o reconhecimento (ACK) utilizado, por exemplo, para passar de um estado de compressão inferior para um estado de compressão superior. Através da receção de ACKs por meio de um canal bem definido, o compressor tem o conhecimento de que foi recebido algum cabeçalho específico. 0 compressor tira partido desse conhecimento para comprimir de forma mais fidedigna e mais eficaz.
Modo Oportunista Bidirecional: este modo de funcionamento é utilizado no caso de existir um canal inverso, mas é definido 'vagamente', ou seja, o canal pode não estar sempre disponível ou pode ser lento/não fidedigno. Existem muitas aplicações importantes que são bidirecionais. Um exemplo principal é a voz ou o vídeo de conversação. Nesses casos, existe inerentemente um canal inverso, que pode transportar o retorno.
Modo Unidirecional (Pessimista ou Otimista): este modo de funcionamento é utilizado quando não existe nenhum canal inverso de qualquer tipo. Uma vez que não existe qualquer retorno do descompressor relativamente ao respetivo estado atual, o compressor tem de enviar ocasionalmente algumas informações de atualização ao descompressor, que podem ser utilizadas para restabelecer o sincronismo no caso de algo ter corrido mal. Dependendo de vários fatores (por exemplo, condições do canal) , que podem ser conhecidos do compressor, a abordagem neste modo pode ser pessimista (atualizações mais frequentes) ou otimista (atualizações menos frequentes). Além disso, existem 16 ΕΡ1221239Β1 eventos que podem acionar o compressor para enviar informações FH, atualizar o descompressor e reduzir a possibilidade de descompressão incorreta. 0 compressor ACE pode ser caracterizado por estar a avançar através de uma série de estados. 0 compressor abandona um estado de compressão inferior e entra num estado de compressão superior quando tiver confiança suficiente de que o descompressor recebeu algumas informações.
No caso da compressão de cabeçalhos RTP, os estados são Cabeçalho Completo, Primeira Ordem e Segunda Ordem. • Estado de Cabeçalho Completo (FH): 0 compressor entra neste estado quando está no momento da inicialização ou quando ocorre algum evento excecional (avaria da CPU ou perda de memória). Neste estado, o compressor transmite essencialmente informações de cabeçalho FH ao descompressor. Um cabeçalho FH contém o conjunto completo de todos os campos de cabeçalho, mais algumas informações adicionais. Estas informações podem incluir dados específicos de compressor/descompressor, tais como o CID (Context Identifier - Identificador de Contexto, utilizado para discriminar múltiplos fluxos). 0 compressor permanece neste estado até ter adquirido confiança suficiente de que o descompressor recebeu as informações de cabeçalho FH. Os pacotes FH são os menos ideais para transmitir devido ao seu tamanho grande (por exemplo, pelo menos 40 bytes para IPv4, 60 bytes para IPv6). O compressor abandona este estado e entra no estado FO quando tiver confiança suficiente de que o descompressor recebeu corretamente um cabeçalho FH. Essa confiança pode advir, por exemplo, da receção de um ACK a partir do descompressor ou do envio de um número predefinido de FHs . 17 ΕΡ1221239Β1 • Estado de Primeira Ordem (FO) : 0 compressor entra neste estado quando é iniciada uma nova cadeia, depois de ter abandonado o estado FH. Neste estado, o compressor transmite essencialmente informações de cabeçalho FO. Um cabeçalho FO contém campos específicos de compressor/descompressor, e algumas informações que descrevem alterações irregulares que ocorreram nos campos alteráveis essenciais. 0 compressor permanece neste estado até ter adquirido confiança suficiente de que as informações de cabeçalho FO foram recebidas pelo descompressor. Essa confiança pode advir, por exemplo, da receção de Reconhecimentos a partir do descompressor ou do envio de um número predefinido de FOs. • Estado de Segunda Ordem (SO): 0 compressor está neste estado quando o cabeçalho a ser comprimido está em conformidade com o padrão de uma cadeia, e o compressor está suficientemente confiante de que o descompressor adquiriu o padrão da cadeia. Neste estado, o compressor transmite cabeçalhos SO. Um cabeçalho SO contém essencialmente apenas um número de sequência. 0 modo preferido de funcionamento para o compressor/descompressor é a transmissão/receção de pacotes SO, devido ao seu tamanho mínimo (na ordem de apenas alguns bits).
Resumindo, uma sessão é iniciada com o compressor no estado FH. Nessa fase, o compressor envia um cabeçalho completo ao descompressor para estabelecer um contexto no descompressor. Isto inicia uma cadeia. Em seguida, o compressor entra no estado FO ou SO. No estado FO, envia as informações de atualização de campos alteráveis essenciais necessárias ao descompressor. No estado SO, envia as informações mínimas ao descompressor. 0 descompressor efetua uma extrapolação 18 ΕΡ1221239Β1 simples com base nas informações trocadas nos pacotes FH e FO anteriores até a cadeia terminar. Quando outra cadeia é iniciada, o compressor entra novamente no estado FO e o processo repete-se.
Os modos de transmissão bidirecionais utilizam reconhecimentos para várias funções: • para informar o compressor de que as informações FH foram recebidas; nesse caso, o compressor sabe que o descompressor adquiriu as informações necessárias para descomprimir cabeçalhos FO e, por conseguinte, o compressor pode transitar de forma fidedigna para o estado de compressão superior, FO; este tipo de ACK é referido como FH-ACK; para informar o compressor de que as informações FO foram recebidas; nesse caso, o compressor sabe que o descompressor adquiriu as informações necessárias para descomprimir cabeçalhos SO e, por conseguinte, o compressor pode transitar de forma fidedigna para o estado de compressão superior, SO; este tipo de ACK é referido como FO-ACK; para informar o compressor de que o cabeçalho com um número especifico n foi recebido; nesse caso, o compressor sabe que o descompressor pode determinar o número de sequências sem qualquer ambiguidade causada pela moldagem de contador até ao número de cabeçalho n + seq_ciclo, em que seq_ciclo corresponde ao ciclo de contador; o compressor pode utilizar de forma fidedigna bits k para o número de sequências de cabeçalhos, sem se preocupar com a descodificação de número de sequências ambígua ou incorreta no descompressor; este tipo de ACK é referido como S0-ACK.
0 controlo de transição dos estados FH para FO para SO através de Reconhecimentos garante que não existe nenhuma 19 ΕΡ1221239Β1 propagação de erros. Ou seja, um cabeçalho comprimido que não seja recebido com erro pode ser sempre descomprimido corretamente, uma vez que a sincronização nunca se perde.
Existe muita flexibilidade relativamente a quando e com que frequência o descompressor envia os reconhecimentos. A ACE também é extremamente resistente aos ACKs que se perdem ou atrasam. 0 compressor adapta constantemente a respetiva estratégia de compressão com base nas informações atuais a serem comprimidas e nos ACKs recebidos. Por exemplo, a perda ou atraso de um FO-ACK pode fazer com que o compressor fique mais tempo no estado FO. A perda ou atraso de um SO-ACK pode fazer com que o compressor envie mais bits para o número de sequência, de modo a impedir qualquer descompressão incorreta no descompressor, causada pela moldagem de contador.
Os ACKs podem ser transmitidos periodicamente ou não periodicamente. A frequência dos reconhecimentos não periódicos pode ser diminuída ou aumentada a partir de uma taxa periódica. Um ACK pode ser enviado com menos frequência, uma vez que os ACKs se perdem devido a erros ou congestionamento da rede, ou os ACKs não podem ser transmitidos devido à disponibilidade intermitente do canal inverso ou a algumas condições do descompressor. Um ACK também pode ser transmitido em intervalos mais curtos do que o ACK periódico tradicional. Por exemplo, quando o canal inverso está muito levemente carregado e disponível, o descompressor pode transmitir ACKs com mais frequência e, por consequência, o compressor pode funcionar de forma mais eficaz e fidedigna.
Consequentemente, o canal de retorno utilizado para transmitir os ACKs pode ter requisitos muito vagos. Isto deve-se ao fato de os ACKs só afetarem a eficiência de compressão, e não a exatidão. 0 atraso ou a perda de ACKs pode fazer com que o tamanho dos cabeçalhos comprimidos aumente, mas mesmo nesses casos o aumento é logarítmico. 20 ΕΡ1221239Β1
No modo determinista bidirecional, a transição de FH/FO para FO/SO é baseada no reconhecimento. No modo unidirecional, nunca é enviado um ACK, pelo que o número de pacotes FH/FO que são enviados antes da transição para o estado FO/SO depende de um valor predefinido ou selecionado de forma dinâmica/adaptável. No modo oportunista bidirecional, o ACK pode atrasar-se, pelo que a transição de FH/FO para FO/SO não se baseia estritamente em ACK, mas depende do que acontecer primeiro entre 1) a transmissão de um número de FH/FO predefinido ou selecionado de forma dinâmica/adaptável, e 2) a receção de, pelo menos, um ACK.
Resumindo, o número de pacotes FO/FH a enviar antes de mudar para o estado FO/SO depende do fato de ser necessário um ACK antes da mudança e/ou de um parâmetro m ajustável que pode ser predefinido ou selecionado de forma dinâmica/adaptável. Abaixo, são descritos quatro casos. A Fig. 15 ilustra a mudança do estado de compressão do compressor com base apenas na chegada de um ACK apropriado. Uma sequência de, pelo menos, um cabeçalho de um estado especifico que, conforme ilustrado sem limitação, corresponde a cabeçalhos FH ou FO é transmitida ao descompressor. 0 descompressor, ao receber o primeiro cabeçalho FH(n) ou FO(n) (pode ser um cabeçalho que não o primeiro cabeçalho), transmite novamente um Ack(n) que, na receção, faz com que o compressor transite para um estado de compressão superior que, conforme ilustrado, corresponde a FO(N+i+1) ou SO(n+i+l) que é o pacote transmitido imediatamente após a receção de ACK(n).
As Figs. 16 e 17 ilustram a mudança do estado de compressão do compressor com base num parâmetro m que corresponde a um número de cabeçalhos transmitidos ou ACK (mudar o acesso sempre que forem transmitidos m cabeçalhos FO/FH ou for recebido ACK) . A forma de realização da Fig. 16 não é limitada à transmissão de cabeçalhos FH/FO/SO através do compressor. Na Fig. 16, um ACK(n) chega antes de 21 ΕΡ1221239Β1 o número de cabeçalhos FO/FH transmitidos atingir m, o que, como resultado do número predefinido de cabeçalhos FH/FO a serem transmitidos, faz com que o compressor mude para um estado de compressão superior e transmita o pacote FO(n+i) ou SO(n+i). A forma de realização da Fig. 17 não é limitada à transmissão de cabeçalhos FH/FO/SO através do compressor. Na Fig. 17, um ACK chega depois de m cabeçalhos serem transmitidos. A Fig. 18 ilustra que a mudança do estado de compressão do compressor ocorre depois de um número definido de cabeçalhos ser enviado sem quaisquer reconhecimentos.
Em modos diferentes, a estratégia de funcionamento do compressor e descompressor é diferente.
Modos de Funcionamento do Compressor • Baseado estritamente em ACK: neste modo, o compressor depende estritamente da receção dos ACKs. Se um ACK não tiver chegado a tempo devido a perda, disponibilidade do canal, condições do descompressor, etc., o compressor muda para um modo menos comprimido, por exemplo, aumentando o comprimento dos campos de codificação, e só pode regressar a um modo mais comprimido depois de receber ACKs apropriados. • Baseado vagamente em ACK: neste modo, o ACK ajuda a melhorar a eficiência e fiabilidade quando é recebido, mas o compressor não depende estritamente da receção do ACK. Se o compressor receber um ACK apropriado, muda de um estado menos comprimido para um estado mais comprimido, ou mantém-se no estado atual se já se encontrar no estado mais comprimido. Se não tiver recebido um ACK apropriado, muda de um estado menos comprimido para um estado mais comprimido com base noutros critérios, por exemplo, o envio de um 22 ΕΡ1221239Β1 determinado número de cabeçalhos menos comprimidos, em vez da receção de ACK. • Não baseado em ACK: o compressor funciona normalmente neste modo quando não nenhum canal inverso está disponível. Neste modo, o critério de transição de um estado menos comprimido para um estado mais comprimido não é baseado em ACK. De preferência, o compressor pode mudar de um estado menos comprimido para um estado mais comprimido depois de ter sido transmitido um determinado número de cabeçalhos menos comprimidos. Esse número pode ser um parâmetro ajustável. Além disso, existem eventos que podem acionar o compressor para enviar informações menos comprimidas, de modo a atualizar o descompressor e reduzir a possibilidade de descompressão incorreta.
Modos de Funcionamento do Descompressor • Envio de ACK determinista: neste modo, o descompressor envia ACKS periodicamente e quando recebe pacotes FH/FO. Além disso, o descompressor pode enviar ACKs de volta para o compressor mais frequentemente do que periodicamente quando o canal inverso está levemente carregado e disponível. • Envio de ACK oportunista: neste modo, o descompressor não envia estritamente ACKs periodicamente. Só envia um ACK quando tem uma oportunidade para o enviar, por exemplo, quando o canal inverso está disponível para transportar o ACK. • Nenhum ACK: neste modo, o compressor não envia quaisquer ACKs.
Uma aplicação de exemplo em que o esquema de compressão e descompressão de cabeçalhos é útil é aquela em que os pacotes VoIP (Voice over IP) (ou telefonia IP) são 23 ΕΡ1221239Β1 transmitidos através de sistemas celulares. Quando VoIP é aplicado nos sistemas celulares, é importante minimizar o overhead do cabeçalho IP/LUDP/RTP devido à largura de banda limitada da interface sem fios ou aérea (RF) . Num sistema desses, por exemplo, ANI_AD funciona como interface entre a rede IP e um terminal de computador que executa RTP/UDP/IP (por exemplo, terminal 130) com uma interface celular ou RF para receber pacotes RTP através da ligação sem fios ou RF. Esta é meramente uma aplicação de exemplo da técnica de compressão/descompressão da presente invenção.
Definições n: Número de sequência atribuído pelo compressor e transportado nos cabeçalhos. O número n é sempre incrementado em 1 para cada novo pacote e independentemente do número de sequências RTP. Note que n pode ser codificado em bits k (= (CD_SN)k) ou íjoits de extensão (= (CD_SN)£_de extensão) . CD_SN 139: contador interno correspondente a η. O compressor e o descompressor mantêm os respetivos contadores. É possível escolher um tamanho suficientemente grande para contadores internos, de modo a evitar qualquer ambiguidade durante a sessão, por exemplo, 32 bits. (CD_SN)k: bits k menos significativos de CD_SN. (CD_SN)k é normalmente enviado no cabeçalho comprimido. (CD_SN)£_de extensão: bits £_de extensão menos significativos de CD_SN. (CD_SN) ^_de extensão é enviado no cabeçalho comprimido no modo de extensão. S_RFH: CD_SN do pacote cujo cabeçalho é conhecido por ser corretamente reconstruído pelo descompressor; S_RFH é continuamente atualizado pelo compressor com base no retorno do descompressor. S_RFH é enviado na forma de bits k ou í_de extensão menos significativos. 24 ΕΡ1221239Β1 N_decorrido: um contador mantido pelo compressor para controlar o número de pacotes enviados desde o último pacote reconhecido. N_decorrido = CD_SN atual - S_RFH, se S_RFH for sempre definido como igual ao último pacote reconhecido pelo compressor quando recebe um ACK. R_RFH: CD_SN do pacote de referência no descompressor, que é definido como igual a S_RFH quando um pacote FO (n, S_RFH) é recebido. SN(n): o número de sequências RTF do último pacote enviado pelo compressor. Se o compressor não efetuar uma reordenação, SN(n) não é necessariamente uma sequência crescente de forma monótona, em que n é definido por valores de bit dos bits k ou ^ de extensão. TS (n) : 0 carimbo de hora RTP do último pacote enviado pela compressão. CFO (n) : Diferença de primeira ordem atual no pacote n. Note que se trata de um vetor, com cada um dos respetivos componentes individuais igual à diferença entre o campo correspondente no pacote n e no pacote (n-1); por exemplo, o componente de carimbo de hora de CFO (n) é calculado como TS (n) - TS(n-l). FO_DIF (n2, ni) : diferença de primeira ordem no pacote n2, relativamente ao pacote ηχ. Cada um dos respetivos campos individuais é igual à diferença entre o campo correspondente no pacote n2 e no pacote ni; por exemplo, o campo de carimbo de hora de FO_DIF (n2, ni) é calculado como TS (n2) - TS (ni) . N_Última_Interr: 0 CD_SN correspondente à interrupção mais recente (ou seja, alteração não linear). É atualizado (pelo compressor) para n sempre que CFO (n) ! = CFO(n-1). S_DFOD: diferença de primeira ordem predefinida noremetente. S_DFOD é um vetor que especifica o padrão atual. S_DOD é utilizado pelo compressor para determinar se o cabeçalho atual está em conformidade com o padrão. 0 cabeçalho atual n está em conformidade com o padrão se 25 ΕΡ1221239Β1 cabeçalho (n)= cabeçalho(n-1)+ S_DFOD. Quando o padrão não muda de uma cadeia para a outra, S_DFOD é estático. Caso contrário, o compressor tem de determinar S_DFOD numa base dinâmica. TS_DFOD e SN_DFOD: os componentes no S_DFOD correspondentes ao carimbo de hora e número de sequências RTP, respetivamente. R_DFOD: Diferença de primeira ordem predefinida no compressor. R_DFOD é um vetor que especifica o padrão atual. R_DOD é utilizado pelo descompressor para descomprimir cabeçalhos SO. Quando o padrão não muda de uma cadeia para a outra, R_DFOD é estático. Caso contrário, o descompressor tem de determinar R_DFOD numa base dinâmica. Intencionalmente, S_DFOD e R_DFOD são sempre iguais durante o estado SO.
Sinalizador_de extensão: um sinalizador mantido pelo compressor. Se for VERDADEIRO, serão utilizados bits í_de extensão para o CD_SN e serão enviados outros parâmetros de sequência nos cabeçalhos. Caso contrário, será enviado (CD_SN)k. Note que este próprio sinalizador é igualmente transportado nos cabeçalhos, de modo a que o descompressor saiba que codificação de CD_SN é utilizada. Cabeçalho (n): Um termo utilizado genericamente para referir as informações de cabeçalho enviadas pelo compressor. 0 cabeçalho (n) pode ser enviado de várias formas, FH(n), FO (n, S_RFH), SO(n), dependendo do estado do compressor. Note que, no cabeçalho, n está efetivamente codificado como (CD_SN)k ou (CD_SN)£_de extensão, dependendo do sinalizador de extensão.
Dif (n2, ni) : A verdadeira distância entre n2 e ni, que estão codificados como (CD_SN)k ou (CD_SN) £_de extensão. Dif 1 (n2, ni) = CD_SN (n2) CD_SN (n±) , em que CD_SN(n2) e CD_SN(ni) são o CD_SN correspondente a n2 e nif respetivamente. Por exemplo, se o primeiro pacote transportar (CD_SN)k = 14 e o segundo transportar 26 ΕΡ1221239Β1 (CD_SN)k = 1, a verdadeira distância é (16 + 1 - 14) = 3, e não (1 - 14) = -13. FH_Req: Enviado pelo descompressor para solicitar ao compressor para funcionar no estado FH. Isto é utilizado, por exemplo, quando o descompressor acabou de recuperar de uma avaria e já não tem informações fidediqnas sobre o estado. ACK(n) : Enviado em resposta ao cabeçalho (n) . Um ACK significa que o pacote (n) é recebido corretamente. Seq_ciclo: seq_ciclo -1 é o número máximo atingido pelo número de sequências antes da moldagem e do regresso a 0. Seq_ciclo = 2k. SEQ Ext_ciclo : = 2-í-de extensão . HSW 117: 0 compressor mantém uma janela deslizante de cabeçalhos enviados ao descompressor (HSW): cabeçalho (n), cabeçalho (n+1), cabeçalho (n+2), etc. Os cabeçalhos podiam ter sido enviados na forma de FH, FO ou SO. Quando o compressor recebe um ACK(n), irá eliminar qualquer Cabeçalho (p) , em que p <n2-ni, e mover igualmente Cabeçalho (p=n) para Cabeçalho(S_RFH). Os campos estáticos não necessitam de ser armazenados como entradas múltiplas em HSW. Apenas é necessária uma única cópia dos campos estáticos. Note que, em HSW, cada cabeçalho é marcado com uma cor, ou verde ou vermelho.
Cor de um cabeçalho (pacote): é verde se o CD_SN transportado no cabeçalho (pacote) estiver codificado em bits k. Caso contrário, é vermelho, por exemplo, bits ^ de extensão. Na implementação, pode ser utilizado um sinalizador de 1 bit para armazenar a cor. A cor é utilizada para ajudar o compressor a identificar exclusivamente um cabeçalho quando receber um ACK. OAW 135: o descompressor mantém uma janela deslizante de cabeçalhos que descomprimiu e reconheceu com êxito: cabeçalho (nl), cabeçalho (n2) , cabeçalho (n3) . Note que os ACKs não são certamente conhecidos por serem recebidos 27 ΕΡ1221239Β1 pelo compressor. A janela será referida como a janela Ack excelente (OAW - Outstanding Ack Window) . Os campos estáticos não necessitam de ser armazenados como entradas múltiplas em OAW. Apenas é necessária uma única cópia dos campos estáticos. R_Último_Descomp: 0 CD_SN do último pacote reconstruído pelo descompressor. 0 descompressor mantém o cabeçalho completo correspondente que é referido como FH (Último_Descomp) . Nota:
Os cabeçalhos IP, UDP e RTP originais são transferidos, exceto para as alterações descritas abaixo. • 0 campo Comprimento Total do cabeçalho IP (2 bytes) é substituído por sinalizador_de extensão (1 bit) , núm_seq (4 ou 8 bits), e outras informações opcionais. 0 sinalizador de extensão é igual a 1, núm_seq tem um comprimento de 8 bits, ou seja, o pacote é enviado no modo de extensão. ♦ 0 campo Comprimento no cabeçalho UDP (2 bytes) é igualmente substituído pelo ID de contexto para compressão de cabeçalhos, referido como CID. 0 compressor pode comprimir em simultâneo múltiplos fluxos RTP independentemente uns dos outros. A cada fluxo é atribuído um CID exclusivo. Na implementação, o CID pode ter um comprimento de 1 byte ou 2 bytes, dependendo do número máximo de fluxos RTP num determinado momento.
Uma primeira forma de realização da invenção, que pode ser praticada com o sistema da Fig. 2, aumenta a probabilidade de receção de pacotes do tipo FH e FO de modo que existe uma progressão oportuna em direção ao melhor estado SO ótimo. A probabilidade de receção pode ser aumentado por meio da aplicação de proteção de erros 28 ΕΡ1221239Β1 adicional aos pacotes FH e FO na forma de • Códigos de Correção de Erros • Códigos de Correção de Erros + Intercalagem
• Transmissão em Duplicata de dados de cabeçalho de FH e FO A primeira forma de realização da invenção proporciona proteção extra contra perda de pacotes de dados sobre um meio de transmissão não permanente, por exemplo, sem fios sem alocar recursos de canais adicionais ao compressor e descompressor. A largura de banda extra é obtida por meio do atraso da transmissão do fluxo de dados por algum intervalo de tempo, 'Τ', conforme ilustrado nas Figs. 5A e 5B, tal que existe tempo suficiente para enviar os pacotes de dados extra. 0 intervalo de atraso pode ser usado para enviar pacotes de FH, e pacotes de FO iniciais em qualquer momento.
Transmissão de pacotes de FH Inicial: Assume-se que a largura de banda no canal de comunicação foi alocada sob a presunção de que os pacotes FO e SO principalmente serão transmitidos (isto é, muito poucos pacotes de FH são transmitidos). Isto é uma presunção razoável na maioria dos casos, uma vez que a eficácia do esquema de compressão como um todo é dependente da operação principalmente no estado SO. No entanto, existe sempre uma necessidade de enviar algum número de pacotes de FH (de forma ideal, justo um) no inicio de uma sessão. 0 tamanho de um pacote de FH é significativamente maior que esse de pacotes de SO ou FO. Isto significa que a largura de banda adicional é requerida com a finalidade de entregar o pacote dentro do mesmo período de tempo que esse alocado para os pacotes de SO e FO. A transmissão de parte do pacote de FH ocorre no canal primário e o resto em algum canal secundário. 29 ΕΡ1221239Β1 0 intervalo mencionado anteriormente de atraso, 'Τ' ilustrado nas Figs. 5A e 5B, é utilizado para transmitir os dados adicionais portados dentro de um pacote de FH. Ao fazer isso elimina-se a necessidade de usar um canal secundário. A economia pode ser significativa, uma vez que o canal secundário pode ser difícil (em termos de protocolo) , custoso (se for necessário que seja um canal dedicado que é usado somente ocasionalmente), e desacelerar a preparação (se for necessário que seja um canal à base de pacote partilhado, atrasos de contenção indesejados seriam observados). Note que, dependendo do valor de 'T' e tamanho dos blocos de transmissão, pode ser possível incluir a codificação de correção de erros (ECC) no bloco de largura de banda'extra' também.
Transmissão de pacotes de FO: Este esquema é aplicável somente quando a necessidade de transmitir o pacote de FO coincide com uma pausa na transmissão de fluxo de dados. Devido a que, por definição, os pacotes de FO são gerados quando existe uma disrupção no fluxo de dados normal, esta condição é quase sempre cumprida. Por exemplo, intervalos de silêncio causam saltos irregulares no carimbo de tempo de RTP que pode acionar a transmissão de pacotes de FO. 0(s) transmissor(s)/recetor (es) (compressor(es)/descompressor(es) de Fig. 2) pode(m) operar num estado mais ótimo quando proteção de erros adicional é usada. Na técnica anterior, a operação menos frequente no estado ótimo SO ocorre. A penalidade para esta operação aumentada no estado ótimo é um atraso fixado que está sempre presente no fluxo de dados. No entanto, este atraso pode ser facilmente tolerado dentro de limites específicos aos dados a serem transmitidos.
Como um exemplo, assumir dados de fala + dados de cabeçalho do tipo FO prontamente ajusta-se em um bloco de transmissão celular de tamanho p bytes, correspondente a um 30 ΕΡ1221239Β1 intervalo de tempo equivalente a 20 mS. Assumir um atraso, 'Τ' = 20 mS é aplicado na maneira descrita acima, é possível enviar o FO + dados de fala + uma quantidade equivalente de dados para aumentar a probabilidade de receção. Algumas configurações potenciais são: • Dados de fala + cabeçalho do tipo FO + bits de código convolucional de ½ taxa são enviados para aumentar a probabilidade de receção de dados. Isto aumenta consideravelmente a probabilidade de receção correta. Um código de ^ taxa utiliza completamente a largura de banda adicional propiciada pelo atraso. • Duas cópias idênticas dos dados de fala + cabeçalho do tipo FO podem ser enviadas; o que aumenta a probabilidade de receção, particularmente quando a multimédia de transmissão é submetida a perda de pacote aleatória.
Uma segunda forma de realização da invenção, que pode ser praticada com o sistema da Fig. 2, baseia-se nos campos IP/UDP/RTP que, na maior parte das vezes, são constantes ou podem ser extrapolados de uma forma linear. Nesses casos, o cabeçalho comprimido apenas transporta um número de sequências de não-extensão múltiplo com bits k que proporciona informações suficientes para extrapolação linear. Tal como RFC 2508, com a invenção em que a extrapolação linear resulta na reconstrução de cabeçalho incorreta, o transmissor envia informações de diferença FO. Ao contrário de RFC 2508, as informações de diferença são calculadas relativamente a um pacote de referência conhecido por ser recebido corretamente, em vez do que antecede imediatamente o pacote atual. Esta funcionalidade garante que o cabeçalho atual pode ser reconstruído de forma fidedigna, mesmo em caso de perda de um ou mais pacotes antigos. Uma vez que o cabeçalho pode ser reconstruído de forma fidedigna dessa maneira, não é 31 ΕΡ1221239Β1 necessário enviar um cabeçalho completo. A referência é determinada e atualizada pelo compressor do recetor de acordo com os reconhecimentos recebidos a partir do descompressor. 0 compressor utiliza como cabeçalho de referência um cabeçalho que é conhecido por ser descomprimido corretamente com base nos reconhecimentos (ACKs) recebidos, conforme ilustrado geralmente na Fig. 6. 0 compressor envia uma série de pacotes de cabeçalho completo FH(n)...FH (n+i+1)...que abrange uma sequência de tempo mesmo antes de t2, momento esse em que é recebido o reconhecimento ACK(n) produzido pelo compressor que recebe o pacote de cabeçalho completo FH (n). A transição de FH para FO (FO(n+j) conforme ilustrado) é síncrona. A sequência de tempo para t2 depende do tempo de transmissão de rádio de ida e volta. A Fig. 7 ilustra a transição do compressor relativamente à transmissão de pacotes de primeira ordem FO (FO (n) para FO (n+i + 1) . . . com, pelo menos, um reconhecimento ACK(n) e, opcionalmente, ACK(n+l) sendo gerado pelo descompressor antes de o compressor transitar sincronamente para os pacotes de segunda ordem SO (SOn+j) com um atraso de rádio de ida e volta para o momento t2 necessário para a sincronização. 0 número de ACKs necessário pelo compressor antes da transição do estado FO para o estado SO depende das variações entre pacotes. Por exemplo, se a variação entre pacotes for linear com parâmetros constantes, apenas é necessário um ACK para a transição do estado FO para o estado SO. Para poder descomprimir o cabeçalho atual, o descompressor só necessita de saber o cabeçalho de referência em vez do cabeçalho imediatamente anterior, tal como com RFC 2508. Neste esquema, o compressor envia cabeçalhos completos (cabeçalhos de tipo FH) na inicialização. Envia informações de diferença de primeira ordem (cabeçalhos de tipo FO) quando a extrapolação linear não se aplica. Contudo, o 32 ΕΡ1221239Β1 compressor não transmite cabeçalhos de diferença SO até o FH ou FO anterior ser reconhecido e a extrapolação linear ser aplicada.
No compressor, o pacote de referência é definido como sendo o último cujo ACK foi recebido. Especificamente, quando o transmissor recebe ACK(n), um reconhecimento para o pacote n, irá obter o pacote n armazenado anteriormente na memória e guardá-lo como o pacote de referência (o pacote n foi armazenado na memória quando foi enviado). Subsequentemente, toda a compressão de cabeçalhos é efetuada relativamente a esse pacote, até ser recebido um novo ACK, ponto esse em que o pacote que acabou de ser reconhecido se torna o novo pacote de referência. A memória do transmissor onde os potenciais pacotes de referência são armazenados é referida como a janela de cabeçalho enviado (HSW - Header Sent Window) representada como entidade 117 na Fig. 2. Se tiverem de ser enviadas informações de diferença FO no cabeçalho comprimido, o compressor irá incluir explicitamente o número de sequências do pacote de referência (número de sequências de referência).
No descompressor, quando um ACK(n) é enviado, o cabeçalho(n) é armazenado na janela de reconhecimento excelente (OAW) representada como 135 na Fig. 2. Subsequentemente, quando um cabeçalho de diferença FO é recebido, o descompressor irá determinar o pacote de referência a partir do número de sequências de referência, obter o pacote de referência correspondente a partir da OAW 135 e utilizá-lo para reconstruir o cabeçalho completo. A invenção utiliza a linearidade dos carimbos de hora RTP gerados no compressor que seguem rigorosamente um padrão linear como uma função de relógio. Com base no temporizador 134 mantido no descompressor do recetor e através da utilização de um número de sequências de extensão para pacotes FO definido por bits € de extensão, é possível detetar e recuperar toda uma grande perda dentro 33 ΕΡ1221239Β1 de um limiar.
Com a voz sendo assumida, se o intervalo de tempo entre amostras de voz e pacotes consecutivos for t ms, o carimbo de hora RTP do cabeçalho n (gerado no momento n* t ms) é igual ao carimbo de hora RTP do cabeçalho 0 (gerado no momento 0) mais TS_passo * n, em que TS_passo corresponde a uma constante dependente de um codec de voz da fonte de voz do transmissor. Consequentemente, o carimbo de hora RTP nos cabeçalhos recebidos pelo descompressor segue um padrão linear como uma função de tempo, mas menos rigorosamente do que o compressor, devido à instabilidade de sinal de atraso entre o compressor e o descompressor. No funcionamento normal (ausência de avarias ou falhas), a instabilidade de sinal de atraso é limitada, para cumprir os requisitos de tráfego em tempo real de conversação.
Uma cadeia ocorre como uma sequência de cabeçalhos, todos em conformidade com um determinado padrão. Especificamente, o número de sequências (SN - Sequence Number) RTP é incrementado em 1 de um cabeçalho para o outro. 0 carimbo de hora (TS - Time Stamp) RTP não é decrescente e segue algum padrão previsível: se os cabeçalhos ni e n2 estiverem na mesma cadeia, o TS do cabeçalho n2 pode derivar do TS do cabeçalho n2 e da função de padrão. Os outros valores de campo, exceto talvez a soma de teste UDP e o IP Id, não são alterados na cadeia. Deste modo, depois de um cabeçalho, por exemplo n2, ser corretamente descomprimido, os cabeçalhos subsequentes na mesma cadeia podem ser descomprimidos através de extrapolação de acordo com o padrão. Assim que o compressor determina que um cabeçalho foi descomprimido com êxito e que o padrão foi adquirido pelo descompressor, só tem de enviar um número de sequências de bits k, indicado por (CD_SN)k, como um cabeçalho comprimido, para os pacotes subsequentes na mesma cadeia. (CD_SN)k corresponde aos bits k menos significativos de um número de sequências de 34 ΕΡ1221239Β1 descompressor (compressor) maior (CD_SN).
Neste esquema, o descompressor utiliza o temporizador 134 ou outro temporizador não ilustrado na Fig. 2 para obter o tempo decorrido entre dois pacotes recebidos consecutivamente. Com base nessas informações de temporização e na regra de compressão especifica que é utilizada pelo compressor juntamente com o número de sequência, o descompressor pode detetar e/ou recuperar da grande perda.
Suponhamos que • HDR(i) é o cabeçalho com o número de sequências abreviado i • HDR(ni) é o último cabeçalho que foi descomprimido com êxito • HDR(n2) é o cabeçalho que foi recebido imediatamente após HDR(ni) • TS_passo é o incremento TS RTP a cada t ms • SEQ_CICLO é o ciclo do número de sequências utilizado em HDR. • DIF (n2, ni) é a diferença entre pacotes com o número de sequências n2 e n2. É definido conforme apresentado em seguida: • DIF (n2, ni) = n2 quando n2>n2 • DIF (n2, n2) = n2 + 2k-n2 quando n2^n2
Ao receber HDR (n2) imediatamente após receber HDR(ni), o descompressor determina se aconteceu ou não uma grande perda entre estes dois pacotes, ou seja, se existem ou não pacotes DIF (n2, n2) perdidos ou se existem pacotes SEQ_CICLO * p + DIF (n2, nj (p>l) perdidos. 0 esquema de deteção também depende do tipo de HDR(n2) . Com base nos três tipos de cabeçalho definidos nos esquemas de compressão de cabeçalhos, são listados abaixo 2 casos.
Caso 1: HDR (m) , SO (n2) 35 ΕΡ1221239Β1
Caso 2: HDR (ni) , FO (n2)
Recuperação e Deteção de Grande Perda para o Caso 1
Para detetar se existe ou não uma grande perda no caso 1, um temporizador (por exemplo temporizador 134) é mantido no compressor, e é verificado e atualizado sempre que um pacote é recebido. Suponhamos que • T é o momento em que HDR(n2) é recebido • Τ+ΔΤ é o momento em que HDR(n2) é recebido
0 compressor só envia pacotes SO se um ou mais pacotes FH ou FO anteriores tiverem sido reconhecidos, bem como se a extrapolação linear se aplicar a partir do cabeçalho reconhecido. Por conseguinte, se HDR(n2) for SO independentemente do tipo de HDR(n2), a extrapolação linear aplica-se de HDR(n2) a HDR(n2). Isto significa basicamente que o carimbo de hora RTP e o número de sequências RTP para os pacotes n2 a n2, quando gerados no compressor, seguem rigorosamente um padrão linear como uma função de relógio. Consequentemente, os cabeçalhos relacionados com o descompressor também seguem um padrão linear como uma função de tempo, mas com oscilação devido à instabilidade de sinal entre o transmissor e o recetor.
Partindo do principio de que o limite superior de instabilidade de sinal é sempre inferior a (SEQ_CICLO * t) ms, aplica-se a seguinte regra para detetar uma grande perda: [Regra 1] • se (DIF (n2, n2) * t ms < ΔΤ < (DIF (n2, ni) + SEQ_CICLO) (t ms) , apenas se perdem os pacotes DIF (n2, nj ; •se ( (DIF (n2, ni) + SEQ_CICLO) * t ms < ΔΤ < (DIF (n2, ni) + 2 * SEQ_CICLO) * t ms) , perdem-se os pacotes 36 ΕΡ1221239Β1 (SEQ_CICLO + DIF (n2,ni)); • Em geral, se ((DIF(n2, η2) + i* SEP CICLO) * t ms ^ ΔΤ < (DIF (n2, ni) + (i +1) * SEQ_CICLO) * t ms) , perdem-se os pacotes (i *SEO CICLO + DIF (n2, n2) ) ;
Para recuperar o carimbo de hora RTP e o número de sequências RTP de uma grande perda, apenas é necessário o número de pacotes perdidos.
Suponhamos que • Nperda é o número de pacotes perdidos entre o pacote ni e o pacote n2 que pode ser obtido com base na regra 1 • TS (i) e SEQ(i) são o carimbo de hora RTP e o número de sequências RTP do pacote i 0 carimbo de hora RTP e o número de sequências RTP podem derivar do carimbo de hora RTP e do número de sequências RTP do pacote ni , bem como Nperda que são ilustrados na seguinte fórmula.
TS (n2) = TS(ni) + Nperda * TS_PASSO SEQ (n2) = SEQ ( Πι) + Nperda A Fig. 8 ilustra uma forma de realização da invenção que deteta e recupera de uma grande perda no caso 1 para detetar uma grande perda quando ocorre uma modelação na perda, onde se perdem mais pacotes do que 2k, em que k corresponde ao número de bits no número de sequências SN (n) dos pacotes. Partindo do principio de que o descompressor recebe HDR(n), que é enviado no momento tO, e todos os pacotes enviados entre tl e t3 se perderam, o descompressor recebe S0(n+1), que é enviado no momento t3. Uma vez que o pacote n+1 enviado no momento t3 é um pacote SO que indica que todos os pacotes enviados de tO a t3 pertencem à mesma cadeia, ou seja, o número de sequências 37 ΕΡ1221239Β1 RTP Sn (n) destes pacotes segue um padrão linear como uma função de relógio, o número de pacotes perdidos entre tO e t3 pode ser detetado pelo temporizador 134 mantido no descompressor. 0 procedimento é conforme apresentado em seguida:
Partindo do principio de gue o intervalo de tempo entre amostras de voz e pacotes consecutivos é de t ms, o descompressor inicia o respetivo temporizador local 134 (com o valor ts) quando recebe HDR(n) enviado no momento tO e, em seguida, o temporizador aumenta com base no relógio. Quando S0(n+1), enviado no momento t3, é recebido no descompressor, o temporizador atingirá um valor aproximadamente igual a ts+(2k+l)t devido à instabilidade de sinal. Uma vez que a diferença de tempo entre ts e tc (à volta de (2k+l)t) é superior a t ms, o pacote n enviado no momento tO e o pacote n+1 enviado no momento t3 não serão pacotes enviados consecutivamente e acontecerá uma grande perda entre estes dois pacotes. Além disso, uma vez que a diferença de tempo entre ts e te é inferior a (2k+1+l)t, não haverá mais de um ciclo de sequência de perda de pacotes. Por conseguinte, o descompressor pode concluir que existem 2k pacotes perdidos.
Recuperação e Deteção de Grande Perda para o Caso 2 0 esquema de recuperação e deteção de grande perda não pode ser aplicado no caso 2, em que o cabeçalho FO é recebido após um cabeçalho SO, FO ou FH. Neste caso, mesmo que a diferença de tempo ΔΤ entre os pacotes n2 e n2 seja superior a (DIF (n2, n2) + SEP CICLO) * t ms, não significa que ocorreu uma grande perda, uma vez que pode dever-se ao período de silêncio do compressor. Neste caso, com base nas informações proporcionadas no cabeçalho FO, o TS RTP pode ser regenerado com êxito, ao contrário do número de 38 ΕΡ1221239Β1 sequências RTP, uma vez que não é possível distinguir uma grande perda ou o silêncio apenas com base na temporização. Para resolver este problema, é utilizado um número de sequências de extensão com bits ^_de extensão (bits ^_de extensão>k de não extensão) para os primeiros pacotes FO numa série FO, em que todos os pacotes pertencem à mesma cadeia, até ser enviado novamente ACK para FO a partir do descompressor. Este esquema deteta e recupera de uma grande perda partindo do princípio de que o limite superior de i i „ x j- _ „ „ de-extensão u- j_ w „ grande perda e inferior a 2 - * t ms.
Para implementar este esquema, um contador interno CD_SN 139 para pacotes é mantido pelo compressor. 0 CD_SN 139 conta todos os pacotes enviados a partir do compressor do transmissor. 0 número de sequências enviado no cabeçalho completo modificado e no cabeçalho comprimido é apenas um instantâneo dos bits k de não-extensão ou ^_de extensão menos significativos do CD_SN 139. Com base na regra do esquema de compressão/descompressão de cabeçalhos, o descompressor é capaz de reconstruir o número absoluto atual dos pacotes recebidos.
Suponhamos que CD_SN_ÚLTIMO é o número de pacote absoluto do último pacote recebido, ou seja, pacote n; CD_SN_ATUAL é o número de sequências absoluto para o pacote FO atual, ou seja, pacote n2; e DIF(CD_SN_ATUAL, CD_SN_ÚLTIMO) é definido como (CD_SN_ATUAL)-(CD_SN_ÚLTIMO). Com base na seguinte regra, é possível detetar com êxito uma grande perda no limite superior de 2 '-d—tensão * t ms. 39 ΕΡ1221239Β1 [Regra 2] se (DIF(CD_SN_ATUAL, CD_SN_ÚLTIMO) > 2k, é detetada uma grande perda. 0 número de pacotes perdidos Nperda pode ser calculado com a seguinte fórmula:
Nperda = DIF (CD_SN_ATUAL, CD_SN_ÚLTIMO) = (CD_SN_)-( CD_SN_ÚLTIMO).
Com base em Nperda /- o número de sequências RTP pode ser regenerado pelo descompressor segundo as fórmulas seguintes, e o carimbo de hora RTP pode ser regenerado com base no cabeçalho de referência e no delta correspondente. SEQ (n2) = SEQ(ni) + Nperda
Uma vez que o número de sequências de extensão utiliza mais largura de banda do que o número de sequências normal, tendo em conta o respetivo número superior de bits, não convém que o utilize frequentemente, mas apenas para os primeiros pacotes FO até o ACK para esta série de FO regressar ao compressor.
Convém referir que este esquema não pode detetar e recuperar de uma grande perda que seja superior a 2f_de_extensao * t ms; por conseguinte, ^_de extensão deve ser selecionado cuidadosamente, de modo a poder detetar a grande perda que não pode ser indicada a partir da camada inferior da pilha de protocolos. Se a grande perda for superior a 2 extensao * t ms, é necessário que uma camada inferior possa proporcionar a indicação dessa perda extremamente grande, e a desconexão na camada inferior ou outros métodos de recuperação de uma grande perda, por exemplo, o envio de um pedido ao compressor, são aplicados.
Quando o compressor necessitar de enviar uma série de 40 ΕΡ1221239Β1 pacotes de tipo FO, em que todos os pacotes pertencem à mesma cadeia, utilizará o número de sequências com bits ^_de extensão até, pelo menos, um ACK para esta série de pacotes regressar a partir do descompressor. Contudo, quando for necessário enviar um pacote SO, o compressor apenas utiliza um número de sequências de bits k.
No compressor, o temporizador 134 (ou outro temporizador não ilustrado na Fig. 2) é iniciado sempre que chega um pacote. 0 temporizador é executado até chegar o pacote seguinte. Se o pacote de entrada for do tipo FH, não são necessárias quaisquer informações de temporização, e o temporizador deve ser reposto.
Se o pacote de entrada for do tipo FO, a regra 2 é aplicada para verificar se aconteceu ou não uma grande perda e qual deve ser o esquema de recuperação correspondente para transmissão de pacotes FO. São necessárias quaisquer informações de temporização e o temporizador deve ser reposto.
Se o pacote de entrada for de tipo SO, a diferença de tempo de chegada entre o pacote atual e o pacote anteriormente recebido deveria ser calculada de acordo com o temporizador, e a regra 1 será aplicada para verificar se aconteceu ou não uma grande perda e o esquema de recuperação correspondente para transmissão de pacotes SO deveria ser usado para recuperar a grande perda se aconteceu. 0 temporizador 134 (ou outro temporizador) deveria ser reposto logo após a verificação.
Em resumo, a utilização do temporizador 134 (ou outro temporizador) e um número de sequências de extensão para os primeiros pacotes de FO podem detetar de maneira bem-sucedida e recuperar a grande perda dentro de um limiar (2 '-de~extensao * £ ms) e melhorar a robustez sem adicionar muito overhead (espaço sem dados) e complexidade.
Outra forma de realização da invenção, praticada com o sistema da Fig. 2, utiliza o fato de os campos IP/UDP/RTP 41 ΕΡ1221239Β1 serem constantes ou poderem ser extrapolados a partir de um padrão previsível. Nesses casos, o cabeçalho comprimido apenas transporta um número de sequências de não-extensão com bits k que proporciona informações suficientes para extrapolação. Quando a extrapolação resultar na descompressão incorreta de um ou mais campos, o compressor envia informações adicionais necessárias para esses campos (informações de atualização).
Para proporcionar robustez aos erros e às rajadas de erros, o compressor codifica as informações de atualização relativamente a um cabeçalho de referência conhecido por ser corretamente descomprimido. 0 compressor sabe que um cabeçalho é corretamente descomprimido quando recebe o reconhecimento correspondente. Um mecanismo ACK garante que o cabeçalho atual pode ser reconstruído de forma fidedigna, mesmo em caso de perda de um ou mais cabeçalhos antigos.
Uma cadeia é definida como uma sequência de cabeçalhos, todos em conformidade com um determinado padrão. 0 número de sequências (SN) RTP é incrementado em 1 de um cabeçalho para o outro. 0 carimbo de hora (TS - Time Stamp) RTP não é decrescente e segue algum padrão previsível. Se os cabeçalhos ni e n2 estiverem na mesma cadeia, o TS do cabeçalho n2 pode derivar do produto do desvio de número de sequências p entre n2 e n2 e TS e a função de padrão. Os outros valores de campo, exceto talvez uma soma de teste UDP e o IP Id, não são alterados na cadeia. Deste modo, depois de um cabeçalho, n2, ser corretamente descomprimido, os cabeçalhos subsequentes na mesma cadeia podem ser descomprimidos através de extrapolação de acordo com o padrão. Assim que o compressor é informado de que um cabeçalho foi descomprimido com êxito e de que o padrão foi adquirido pelo descompressor (conforme demonstrado pelos ACKs), apenas envia um número de sequência, como um cabeçalho comprimido, para os pacotes subsequentes na mesma cadeia. 42 ΕΡ1221239Β1
No caso da voz, o TS tem um padrão linearmente crescente. Deste modo, o TS do cabeçalho (n2) pode ser calculado como: TS (n2) = TS (ni) + TS_passo * p, em que TS_passo corresponde ao incremento de carimbo de hora entre dois cabeçalhos consecutivos e p corresponde ao desvio de número de sequências entre os pacotes n2 e n2. Um intervalo silencioso quebra a relação linear e faz com que uma cadeia termine. Uma nova cadeia é iniciada com um novo segmento continuo de voz.
Deste modo, o compressor passa por três fases diferentes: inicialização, atualização e extrapolação. Uma sessão é iniciada com uma fase de inicialização. Nessa fase, o compressor envia os cabeçalhos completos ao descompressor até ser recebido um ACK. Depois de concluída a inicialização, quando uma cadeia é iniciada, o compressor do transmissor entra numa fase de atualização, na qual envia as informações de atualização necessárias ao descompressor. Assim que o compressor recebe um ACK ou ACKs a indicar que o descompressor adquiriu as informações necessárias para efetuar a extrapolação, o compressor transita para a fase de extrapolação. Na fase de extrapolação, o compressor só envia um número de sequências como cada cabeçalho comprimido, até a cadeia terminar. Quando é iniciada outra cadeia, o compressor do transmissor entra noutra fase de atualização, e todo o processo é repetido. Os cabeçalhos enviados nas fases de inicialização, atualização e extrapolação são FH, FO e SO. FH, FO e SO transportam um número de sequências incrementado em 1 em cada cabeçalho enviado pelo compressor SO, que consiste essencialmente apenas nesse número de sequência. No seguimento, os ACKs enviados em resposta a FH e FO denominam-se FH ACK e FO ACK respetivamente.
Grande rajada de erros e perda de sincronização - ACKs Periódicos
Se o número de sequências acima estiver codificado com 43 ΕΡ1221239Β1 bits k, será moldado em cada cabeçalho seq_ciclo (seq_ciclo = 2k) . Por conseguinte, se uma rajada de erros durar mais do que os cabeçalhos seq_ciclo, o descompressor não pode determinar claramente o número de cabeçalhos decorridos apenas a partir do número de sequências e, consequentemente, não pode efetuar uma descompressão adequada. Para abordar este problema de grande rajada e moldagem, são utilizados reconhecimentos (ACKs) periódicos. A Fig. 9 ilustra o funcionamento da invenção utilizando os números de sequência de bits k e os números de bits t de extensão com a colaboração de reconhecimentos (ACKs) periódicos que são gerados sincronamente pelo descompressor em todos os pacotes recebidos 2k detetados. Partindo do principio de que o compressor recebe o ACK(n) para o pacote n antes de enviar o pacote SO n+i com um número de sequências de bits k, o compressor está a espera de outro ACK para o pacote (n+2k+N_RT) a partir do descompressor antes de enviar o pacote (n+i+2k+N_RT) . Partindo do principio de que ACK (n+2k+N_RT) se perde durante a transmissão, o compressor é transferido para o estado de extensão utilizando bits £ e envia o pacote (n+i + 2k+N_RT) com um número de sequências de bits € de extensão. Quando o descompressor recebe o pacote (n+i + 2k+N_RT) com um número de sequências de ( de extensão, envia um ACK (n + i + 2k+N_RT) de volta para o compressor. Quando o compressor recebe o ACK (n+l+2k+N_RT) , é transferido novamente para o estado de não extensão, e envia o pacote SO(n+j) com apenas um número de sequências de bits k. É esperado que o descompressor envie um ACK em intervalos regulares, curtos o suficiente para que, normalmente, o compressor receba um ACK pelo menos uma vez em cada 2k cabeçalhos seq_ciclo. 0 compressor mantém um contador, N_decorrido, para controlar o número de pacotes decorridos desde o último ACK recebido. Se N_decorrido > 2k cabeçalhos seq_ciclo, o compressor funciona no modo de extensão, em que são utilizados bits 44 ΕΡ1221239Β1 £_de extensão, em vez de um número menor de bits k de não-extensão, para o número de sequência, com o número de bits €_de extensão > o número de bits k de não-extensão. 0 número de sequências de bits €_de extensão e o número reduzido de bits k no número de sequências de não-extensão podem ser vistos como os bits menos significativos do número de sequências de não-extensão e os bits £_de extensão são os bits menos significativos do contador CD_SN 139 do transmissor. São indicados por (CD_SN) k e (CD_SN) £_d.e extensão respetivamente. N_decorrido será incrementado em 1 para cada pacote enviado pelo compressor. 0 número de sequências SN só diminui quando o compressor recebe um ACK do descompressor, e permite que o compressor regresse ao modo normal, ou seja, utilizar o número atual dos bits menos significativos de CD_SN. Estes ACKs são referidos como ACKs periódicos. Os ACKs podem ser não periódicos conforme descrito abaixo quando, por exemplo, o canal no qual os ACKs são enviados está ocupado, o que requer o atraso do ACK de uma forma não periódica.
Para explicar o atraso de ida e volta, o descompressor do recetor necessita de antecipar o momento do envio de um ACK periódico. 0 descompressor tem de enviar um ACK periódico cedo o suficiente para que o compressor receba normalmente ACKs pelo menos uma vez em cada seq_ciclo. Levando em consideração o tempo de ida e volta, o descompressor tem de enviar ACKs pelo menos uma vez em cada cabeçalho (seq_ciclo - N_RT). A quantidade N_RT é calculada como EST_RTT/T_H, arredondada para cima até ao número inteiro mais elevado seguinte. A quantidade EST_RTT é uma estimativa do atraso de ida e volta atual calculado pelo descompressor e pode ser avaliada de forma dinâmica com base em medições recentes ou definida simplesmente para RTT_n (definido abaixo). Na prática, T_H pode derivar de caracteristicas de codec do transmissor ou do espaçamento efetivo observado. 45 ΕΡ1221239Β1
Suposições
Para garantir a exatidão e obter um desempenho elevado, é necessário fazer algumas suposições sobre o canal de comunicações entre o compressor e o descompressor (CD-CC) . 0 canal pode ser uma ligação ou uma concatenação de ligações (rede ou redes).
Os pacotes transferidos através do canal inverso e de avanço podem ficar danificados ou perder-se, mas as respetivas ordens são mantidas (ou seja, canal FIFO). A quantidade MAX_EB é definida como o número máximo de pacotes consecutivos que podem perder-se através de CD-CC. Na prática, para as ligações celulares, MAX_EB é reforçado pelas camadas inferiores da pilha de protocolos que decidem perder a ligação quando é atingido um limiar de pacotes perdidos consecutivos. 0 canal pode efetuar a fragmentação e a nova montagem no descompressor, mas mantém e proporciona o comprimento dos pacotes que estão a ser transferidos. Note que esta fragmentação é diferente da fragmentação IP.
Este esquema presume que existe um mecanismo para detetar erros entre o compressor e o descompressor. Parte-se do princípio de que o canal proporciona essa deteção de erros. Se não existir nenhuma deteção de erros disponível a partir do canal, o esquema pode ser alargado de uma forma simples através da adição de um código de deteção de erros ao nível do compressor-descompressor. A correção de erros é benéfica, mas opcional. 0 atraso de ida e volta entre o compressor e o descompressor é definido como o tempo para enviar e processar um cabeçalho (n) , de o processar e devolver um ACK(n). Para evitar qualquer ambiguidade na mensagem original que está a ser reconhecida, o ACK não pode sofrer nenhum atraso de ida e volta muito longo que o (CD_SN) £_de extensão na direção de avanço tenha moldado. É 46 ΕΡ1221239Β1 razoável assumir que o tempo para enviar e processar o cabeçalho (n) é limitado, devido aos requisitos de tráfego em tempo real. 0 tempo para devolver ACK(n) depende do canal inverso utilizado para transmiti-lo. Por exemplo, se o canal for baseado na contenção, pode sofrer um atraso devido à fila de espera. Parte-se do principio de que as camadas inferiores impõem um limite de atraso na transmissão de ACK, se necessário através da rejeição desses ACKs que ficaram na fila durante muito tempo. Com base nestas considerações, parte-se do principio de que existe um limite superior do atraso de ida e volta: RTT_UB. Além disso, existe um atraso de ida e volta nominal, indicado por RTT_n, que é o atraso de ida e volta mais provável durante o funcionamento normal. Obviamente, RTT_n < RTT_UB. A estimativa de RTT_n deve ser efetuada antes da implementação, uma vez que é utilizado RTT_n para determinar o valor ideal de k (para obter uma explicação, consulte abaixo). Note que, no tempo de execução, o recetor necessita de estimar o atraso de ida e volta efetivo. Os detalhes são apresentados abaixo.
Com base nas suposições 1 e 4, para garantir a exatidão do esquema proposto, o valor de ê_de extensão deve satisfazer as seguintes condições:
1. 2^-de-extensão * T_H > RTT_UB, em que T_H corresponde ao espaçamento temporal entre dois cabeçalhos consecutivos; isto é necessário para evitar a ambiguidade no ACK 2. 2'^-de-extensao > MAX_EB; isto é necessário para manter a sincronização de sequências mesmo quando ocorrem grandes rajadas
Existe alguma flexibilidade para escolher o valor de €. Contudo, para obter um desempenho ideal, o mesmo deve ser ajustado com base na distribuição de rajadas de erros de canal (tanto na direção inversa como de avanço) e no atraso de ida e volta. Em seguida, são apresentadas algumas 47 ΕΡ1221239Β1 considerações : 3. 2k * T_H > RTT_n, para reduzir a possibilidade de o compressor mudar para o modo de extensão devido a ACKs em atraso. 4. 2k > o número mais provável de perdas de pacotes consecutivos. Isto é necessário para reduzir a possibilidade de o compressor mudar para o modo de extensão devido a grandes rajadas de erros. 5. K não deve ser demasiado pequeno. Caso contrário, serão enviados demasiados ACKs periódicos do descompressor para o compressor, provocando a inundação do canal inverso e a diminuição da eficiência de compressão. Por outro lado, um grande valor de k irá resultar num overhead transportado em cada cabeçalho. 0 conceito básico é que, quando a condição do canal se deteriorar, o compressor e o descompressor recuam utilizando bits £_de extensão (CD_SN) para garantir a exatidão. Por outro lado, serão utilizados bits k (CD_SN) mais pequenos durante as condições de canal normais para obter a melhor eficiência. Os pormenores da mudança entre os dois modos são descritos abaixo. A Fig. 10 ilustra uma forma de realização de redução da largura de banda que envia, pelo menos, uma sequência de pacotes de dados, que transita em cada sequência entre estados diferentes de consumo de cabeçalhos, do compressor para o descompressor antes de um reconhecimento (ACK), gerado pelo descompressor, ser recebido pelo compressor para fazer com que o compressor transite a compressão de cabeçalhos para um grau mais elevado de compressão de cabeçalhos. Uma vez que o compressor, antes de receber qualquer reconhecimento, transmite periodicamente cabeçalhos com, pelo menos, alguma compressão, o número mais pequeno de bits resultante transmitido antes de receber um reconhecimento poupa largura de banda. Na fase de inicialização, o compressor pode, sem limitação, 48 ΕΡ1221239Β1 alternar entre cabeçalhos completos (FH) e cabeçalhos de primeira ordem (FO), ou seja, um conjunto de FH, depois um conjunto de FO, depois um conjunto de FH, depois um conjunto de FO, e assim sucessivamente, até ser recebido um ACK. Cada conjunto pode incluir, pelo menos, um cabeçalho. 0 descompressor transmite um ACK quando recebe corretamente um FH. Na Fig. 10, os cabeçalhos FH e FO alternados são transmitidos um a seguir ao outro, ou seja, FH(0), FO(l), FH (2), F0(3), até o compressor receber o ACK (0) para o pacote 0 e utiliza o FH(0) como cabeçalho de referência a partir dessa altura para a descompressão.
Extrapolação múltipla A Fig. 11 ilustra um forma de realização da invenção em que o descompressor realiza extrapolação múltipla. Quando um ou múltiplos cabeçalhos SO consecutivos que pertencem a uma cadeia são perdidos ou corrompidos, o descompressor pode descomprimir cabeçalhos SO subsequentes por meio da aplicação de uma função de extrapolação de um número necessário de vezes. Como mostrado na Fig. 11, é assumido que SO(n+l) e SO(n+2) são todos perdidos. Suponhamos que o correspondente valor de alteração em SO(i) seja X(i), então X(n+3) pode ser regenerado. No caso quando a função de extrapolação é linear e o deslocamento entre dois pacotes consecutivamente enviados é X_Passo, a regeneração de SO(n+3) é realizada por meio da aplicação de uma função de extrapolação duas vezes com base em SO (n) , isto é, X(n+3)=X(n) + X_Passo *((n+3)-n).
No caso quando a função de extrapolação não é linear e varia num padrão(ões) não linear(es), o descompressor pode regenerar os cabeçalhos de acordo com o(s) padrão(ões) não linear(es). Por exemplo, se um valor de alteração de X entre pacotes consecutivos está em padrão X_Passol, X_Passo2, X_Passol, X_Passo2, e assim por diante, então o 49 ΕΡ1221239Β1 descompressor regenera X(n+3) como X (n+3)=X(n) + (X_Passol+X_Passo2) .
Exemplos de X poderiam ser o carimbo de hora e número de sequências no cabeçalho RTP com extrapolações múltiplas usando funções de extrapolação diferentes que são usadas. Uma função de uma função de extrapolação é, por exemplo, um produto de constantes diferentes e uma função de extrapolação constante.
Cada cabeçalho que chega no compressor do transmissor pode ser modelado como um vetor multidimensional com cada componente sendo igual ao valor de um campo alterável no cabeçalho. Por exemplo, se o número de sequências SN de RTP e o carimbo de hora de RTP forem os únicos campos alteráveis num cabeçalho, cada cabeçalho a ser comprimido corresponde a um ponto no espaço 2-D. Portanto, com a passagem do tempo o compressor simplesmente observa uma sequência de pontos neste espaço multidimensional.
As coordenadas de um ponto podem ser derivadas por meio da aplicação de uma função de extrapolação multidimensional ao ponto imediatamente anterior na sequência. A função de extrapolação pode variar de pacote a pacote (ou ponto a ponto no espaço). No entanto, se permanecer o mesmo para uma subsequência de pontos, essa subsequência se torna uma cadeia. Note que a função de extrapolação pode ter quaisquer caracteristicas, embora tipicamente sejam lineares. 0 conceito da cadeia pode ser otimizado ainda pelo descompressor que realiza a extrapolação múltipla. Quando um ou mais cabeçalhos SO consecutivos que pertencem a uma cadeia são perdidos ou corrompidos entre o compressor e descompressor, o descompressor pode ainda descomprimir cabeçalhos SO subsequentes por meio da aplicação da função de extrapolação o número de vezes necessário. 0 número de vezes é determinado pelo salto em CD_SN. Note que a sincronização no CD_SN é mantida quando o 50 ΕΡ1221239Β1 contador tem modelações.
Se um ou múltiplos cabeçalhos SO são corrompidos durante a transmissão, o descompressor pode ser capaz de reparar os cabeçalhos corrompidos com base nos cabeçalhos anteriormente e atualmente corretamente recebidos e funções de extrapolação. Quando o descompressor recebe pacotes com cabeçalhos corrompidos, armazena temporariamente o pacote corregido ao invés de descartar o pacote corregido. Após o descompressor receber o seguinte pacote sem corrupção, o descompressor compara o número de pacotes armazenado temporariamente nos mesmos e o número de sequências deslocado entre o atual pacote corretamente recebido e o anterior pacote corretamente recebido. Se o número de sequências deslocado se corresponde ao número de pacotes armazenado temporariamente, e todos esses pacotes estão na mesma cadeia, então o descompressor pode recuperar os cabeçalhos corrompidos com base na(s) função(ões) conhecida(s) de extrapolação.
Conforme ilustrado na Fig. 11, assumindo que a função de extrapolação para o valor X no cabeçalho é linear e o deslocamento entre dois pacotes consecutivamente enviados é X_Passo, quando o descompressor receber S0(n+1) e S0(n+2) com cabeçalhos corrompidos, o descompressor armazena temporariamente os pacotes e espera o seguinte pacote. Quando o descompressor receber S0(n+3) e observe que o número de sequências deslocado entre pacote atual corretamente recebido S0(n+3) e pacote anterior corretamente recebido SO(n) é 2 e o número de pacotes armazenado temporariamente nos mesmos entre estes dois pacotes são 2 também, o descompressor pode regenerar o valor X dos dois pacotes com cabeçalhos corrompidos como X(n+1)=X(n)+X_Passo e X(n+2)=X(n)+2*X_Passo. Exemplos de valor X podem ser carimbo de hora e número de sequências em cabeçalho RTP. Este processo tem aplicações em que o atraso pode ser tolerado tal como com transmissão em fluxo. 51 ΕΡ1221239Β1
Outra melhora é a compensação do compressor do número de sequências. 0 compressor realiza a compensação do número de sequências quando o número de sequências de RTP do cabeçalho a ser comprimido não aumenta em 1 (aumenta em mais de 1 ou diminui) , mas o compressor determina que o cabeçalho ainda pertence à mesma cadeia a cadeia anterior. Isto acontece quando alguns cabeçalhos numa cadeia são perdidos ou mal ordenados no caminho ao compressor. Nesse caso, o cabeçalho é comprimido como um cabeçalho FO, mas somente uma diferença SND de número de sequências de RTP é enviada como informação de atualização. SND = (RTP real SN do cabeçalho comprimido) - (RTP SN do cabeçalho obtido por extrapolação reta do CD_SN). SND permite que o descompressor determine o número de sequências de RTP correto. Por exemplo, considere a sequência de cabeçalhos com Número de Sequência de RTP =5, 6, 7, 8 e 9 todos os quais pertencem à mesma cadeia. No caminho ao compressor do transmissor, os cabeçalhos 7 e 8 são perdidos. Consequentemente, o compressor vê um incremento de mais de 1 quando o cabeçalho 9 é recebido. No entanto, da inspeção dos campos não comprimidos, o compressor do transmissor determina que o cabeçalho 9 pertence à mesma cadeia que o cabeçalho 6. Assumir que o cabeçalho 6 foi comprimido com CD_SN = 3. Agora o cabeçalho 9 é comprimido com CD_SN = 4, uma vez que o CD_SN é sempre incrementado em 1. 0 compressor do transmissor também envia um SND =9-7=2. 0 descompressor do recetor adiciona SND ao CD_SN, então aplica o algoritmo de descompressão normal para SO.
Num caso de mal ordenamento somente (nenhuma perda de pacote antes do compressor), haverá uma sequência de cabeçalhos SO com SNDs, mas eventualmente o SND será zero. Uma vez que o SND seja zero, nenhum SND é necessário no cabeçalho comprimido, e o cabeçalho comprimido é justo um SO normal. Se os pacotes forem perdidos antes de alcançarem o compressor do transmissor, o SND não irá a zero. 0 SND 52 ΕΡ1221239Β1 precisa ser portado em cada cabeçalho até o compressor receber um reconhecimento do descompressor. De outro modo, se o cabeçalho contiver o SND é perdido, o descompressor não pode descomprimir corretamente. A Fig. 12 ilustra um forma de realização da invenção em que a compensação do número de sequências do compressor ocorre quando o número de sequências de RTP do cabeçalho a ser comprimido não aumenta em 1 devido à perda de pacote, e o compressor determina que o cabeçalho ainda pertence à mesma cadeia que o anterior. É assumido neste exemplo, os pacotes com número de sequências de RTP N+l, N+2, N+3 são todos perdidos. 0 compressor somente recebe pacotes com número de sequências de RTP N e N+4, com N e N+4 que pertencem à mesma cadeia. Quando o compressor envia o cabeçalho comprimido para o pacote com o número de sequências de RTP N+4, além do número pequeno de sequências n+2, o compressor também precisa enviar uma diferença SND de número de sequências de RTP que no exemplo igual a (N+5)-(N+2) . Quando o descompressor recebe tal pacote, adiciona o SND ao CD_SN para derivar o número de sequências correto, então aplica o algoritmo de descompressão normal para SO. A Fig. 13 ilustra um forma de realização da invenção que realiza a deteção de erros e regeneração de código de deteção de erros que é usado para limitar a largura de banda de transmissão. É assumido na seguinte descrição que um mecanismo de deteção de erros, tal como uma soma de verificação de UDP (2 bytes), não é transferido sobre o canal de comunicação entre o compressor e descompressor como o (CD_CC) . Isto não é um problema se a soma de verificação de UDP não for usada pela aplicação final. Se a aplicação final usar a soma de verificação de UDP, e for necessário enviar a soma de verificação de UDP ponto a ponto, a forma de realização pode ser estendida de uma forma direta por meio da adição da soma de verificação de 53 ΕΡ1221239Β1 UDP não comprimido em cada cabeçalho comprimido. No entanto, mesmo se a soma de verificação de UDP não for enviada como o CD_CC, alguma informação relacionada com a soma de verificação de UDP pode ser transmitida ao compressor.
Uma opção é dividir a soma de verificação de UDP ponto a ponto em duas partes: o segmento entre a origem e o compressor é denominado como o segmento a montante e o segmento entre o compressor e o descompressor é denominado como o segmento a jusante. 0 processo de deteção de erros usando a soma de verificação pode ser somente portado para fora no segmento a montante. Antes de enviar um pacote UDP, o compressor verifica se a soma de verificação é consistente com os dados e o compressor comprime o pacote. Se não for, o pacote será descartado ou o pacote é enviado com a soma de verificação descartada e um sinalizador de erros adicionado que informa o descompressor que o pacote recebido contém dados erróneos com o descarte dos bits de deteção de erros na forma da soma de verificação (ou outros bits de deteção de erros) antes de transmissão assim economizar a largura de banda de transmissão. 0 descompressor depende ao invés disso das capacidades de deteção de erros do CD_CC. Se nenhum erro for relatado ao descompressor, o descompressor recalcula a soma de verificação após o qual descomprime o pacote.
As soluções acima funcionam somente se existir um mecanismo de deteção de erros no CD_CC e tiver a mesma capacidade ou capacidade maior que a soma de verificação de UDP.
Antes de comprimir um pacote, o compressor verifica se a soma de verificação é consistente com os dados. Se for, como indicado acima, o compressor comprime o pacote sem incluir a soma de verificação no pacote comprimido e transmite o pacote comprimido ao descompressor. Se não for, o compressor pode descartar o pacote, ou transmitir o 54 ΕΡ1221239Β1 pacote com a soma de verificação, ou transmitir o pacote sem a soma de verificação, mas com ou sem indicação de erros.
As Figs. 14A a F ilustram um exemplo do formato de pacotes SO, ACK, FO, FH, FO EXT e FH REQ que podem ser utilizados com a prática da presente invenção. Aplicam-se as seguintes abreviaturas: PT corresponde ao tipo de pacote, C_RTP_SN corresponde ao número de sequência RTP comprimido, C_RTP_TS corresponde ao carimbo de hora RTP comprimido e C_IP_ID corresponde ao IP_ID comprimido. Contudo, convém compreender que a presente invenção não é limitada a isso. 0 campo PT para o pacote SO pode ser codificado como 0, o pacote ACK como 10, o pacote FO como 110, o pacote FH como 1110, o pacote FO_EXT como 11110 e o pacote F H_RE Q como 111110. Nos pacotes FO e FO_EXT, M corresponde a um marcador de bits no cabeçalho RTP. No pacote FO, T corresponde a um sinalizador de um bit 1 que é definido para 1 se C_RTP_TS estiver presente e, caso contrário, para zero, e I corresponde a um sinalizador de um bit que é definido para 1 se C_IP_ID estiver presente e, caso contrário, para zero. Nos pacotes FH, os cabeçalhos IP e UDP podem ser comprimidos se o comprimento do pacote for proporcionado por uma camada inferior no descompressor. O pacote FO_EXT só é transmitido se vários campos não essenciais tiverem sofrido alterações; a máscara de bits é utilizada para indicar que campos estão presentes, e C_RTP_TS e C_IP_ID estão sempre presentes, tornando os sinalizadores de bits T e I desnecessários. Finalmente, o pacote FH__REQ só é enviado em circunstâncias excecionais, tal como uma avaria no sistema.
Talvez seja necessário adicionar um campo de identificador de contexto (CID) a cada um dos cabeçalhos acima se forem comprimidos múltiplos fluxos RTP e a camada inferior não proporcionar diferenciação entre fluxos. O CID pode apenas ser necessário para uma direção, tal como num 55 ΕΡ1221239Β1 sistema celular, quando a estação móvel (MS) tiver só um fluxo RTP em cada direção, e o CID não é necessário para o tráfego de ligações descendentes (incluindo ACKs). 0 CID de quantidade tem de ser incluído para o tráfego de ligações ascendentes (incluindo ACKs), uma vez que a descompressão no lado da rede lida sempre com múltiplos fluxos.
Em seguida, é apresentado um exemplo de pseudocódigo que pode ser utilizado para escrever o código para o compressor.
Este exemplo ilustra o caso em que são necessários dois ACKs para a transição da fase de atualização para a fase de extrapolação. Para facilitar, a alternância de pacotes FH e FO, conforme ilustrado na Fig. 8, e a compensação de número de sequência não são ilustradas no pseudocódigo.
Neste exemplo, parte-se do princípio de que S_DFOD e R_DFOD são não estáticos. Por conseguinte, os mesmos são determinados pelo compressor e descompressor numa base dinâmica, conforme apresentado em seguida: 0 S_DFOD de quantidade é calculado como CFO(m) quando o compressor recebe ACK(n) e ACK(n-p) e (n-p) ú N_Última_Interr. Note que p não é necessariamente igual a 1. • 0 descompressor calcula R_DFOD quando recebe o primeiro pacote SO após um pacote não SO. 0 R_DFOD de quantidade é calculado através da utilização de uma extrapolação linear baseada nos últimos dois cabeçalhos reconhecidos armazenados em OAW 135. 0 comportamento do compressor pode ser modelado como uma máquina de estado, especificado pelo quadro a seguir.
Para abordar o problema de moldagem de contador e grande rajada de erros, o compressor espera receber um ACK pelo menos uma vez em cada cabeçalho seq_ciclo, e mantém um sinalizador de extensão. Se o sinalizador for verdadeiro, o compressor deverá funcionar no modo de extensão, ou seja, 56 ΕΡ1221239Β1 enviar (CD-SN)í_de extensão. Caso contrário, envia (CD-SN)k. 0 sinalizador de extensão é definido como verdadeiro sempre que N_decorrido > seq_ciclo. Caso contrário, é definido como falso. Note que N_decorrido continua a aumentar, a menos que o transmissor receba um ACK (para obter pormenores, consulte o pseudocódiqo). No modo de extensão, se ext_ciclo tiver decorrido sem um reconhecimento, o transmissor transita para o estado FH. 0 compressor entra no estado SO quando, pelo menos, dois pacotes com CUD_SN > N_Última_Interr tiverem sido reconhecidos. Em seguida, define S_DFOD como igual ao CFO mais recente.
Inicialmente, o compressor inicia a sessão no estado FH. A HSW 117 está vazia. 0 N_decorrido de quantidade é definido como zero. 0 sinalizador_de extensão é definido como falso. É necessário executar procedimentos adicionais no caso de entrega. Para facilitar, os mesmos não são incluídos aqui .
Estado FH
Evento Ação receber ACK(n) para FH (n) ♦ ver o compressor a processar o ACK(n) pseudocódigo ♦ estado <- ESTADO FO;
No estado FH, o procedimento para enviar o cabeçalho(n) é { calcular CFO(n) e atualizar N_Última_Interr; enviar como FH (n); armazenar o cabeçalho (n) em HSW, cor B vermelha; /* n em FH é codificado em bits k_de extensão */ } 57 ΕΡ1221239Β1
Estado FO
Evento Ação Receber ACK(n) para FO(n, m) ♦ ver o compressor a processar o ACK(n) pseudocódigo Receber FH_Req ♦ Estado <- ESTADO FH;
No estado FO, o procedimento para enviar o cabeçalho(n) é { calcular CFO(n) e atualizar N_Última_Interr; se N_decorrido >= seq_ciclo sinalizador_de extensão B VERDADEIRO; mais sinalizador_de extensão B FALSO; se N_decorrido >= ext_ciclo { enviar FH(n), armazenar o cabeçalho(n) em SHW, cor B vermelha; estado β ESTADO_FH; N_decorrido B 0; } se tiver recebido mais de dois ACKs, E os dois mais recentes CD_SNs forem reconhecidos >= N_Última_Interr { S_DFOD B CFO(n); enviar SO(n), armazenar o cabeçalho(n) em HSW, cor B cor_atual(); /* ver função abaixo */ estado B ESTADO_SO; } mais enviar FO(n, S_RFH); armazenar o cabeçalho (n) em HSW, cor B cor_atual (); N_decorrido B N_decorrido + 1; } cor_atual() {
se sinalizador_de extensão = VERDADEIRO 58 ΕΡ1221239Β1 devolver vermelho; mais devolver verde; }
Estado SO
Evento Ação Receber ACK(n) • ver o compressor a processar o ACK(n) pseudocódigo Receber FH_Req • Estado <- ESTAD0_FH;
No estado SO, o procedimento para enviar o cabeçalho(n) é { calcular CFO(n) e atualizar N_Última_Interr; se N_decorrido >= seq_ciclo sinalizador_de extensão B VERDADEIRO; mais sinalizador_de extensão B FALSO; se N_decorrido >= ext_ciclo { enviar FH(n), armazenar o cabeçalho(n) em SHW, cor = vermelha; estado B ESTADO_FH; N_decorrido B 0; }
se CFO(n) = S_DFOD enviar SO(n); armazenar o cabeçalho(n) em HSW, cor B cor_atual() ; mais { enviar FO(n, S_RFH); armazenar o cabeçalho (n) em HSW, cor B cor_atual (); estado B ESTADO_FO; } N_decorrido BN_decorrido + 1; }
Compressor a processar ACK(n) 59 ΕΡ1221239Β1 { se a cor de ACK(n) for verde /* n é codificado em bits k */ h_ack β um cabeçalho verde em HSW 117 cujo (CD_SN) k = n; /* consultar abaixo para obter pormenoresr */ mais /* n é codificado em k_de extensão bits */ h_ack (3 um cabeçalho vermelho em HSW 117 cujo (CD_SN)k_de extensão = n; S_RFH (3 CD_SN de h_ack;
Eliminar todos os cabeçalhos em HSW anteriores a (mais antigos do que) h_ack;
Mover h_ack para Cabeçalho(S_RFH); N_decorrido β Dif (atual | CD_SN, S_RFH): | } É possível provar que, no procedimento acima, só e apenas um cabeçalho em HSW 117 pode ser corretamente identificado como o cabeçalho que está a ser reconhecido, ou seja, não existirá qualquer ambiguidade do ACK. Se o ACK(n) for vermelho, ou seja, n for codificado utilizando bits €_de extensão, apenas um cabeçalho vermelho pode corresponder ao ACK, uma vez que existem, no máximo, cabeçalhos de 2 ^-de-extensao no HSW 117. Caso contrário, se o ACK(n) for verde, será demonstrado que o mesmo ainda pode ser mapeado exclusivamente para um cabeçalho verde em HSW 117 .
Partamos do princípio de que é sempre tirado um instantâneo da HSW 117 depois de o compressor enviar um pacote, e o mesmo é representado com uma cadeia de letras Rs (para cabeçalhos vermelhos) e Gs (para cabeçalhos verdes) . Suponhamos que S é a cadeia correspondente a um instantâneo arbitrário. Note que S começa com o pacote mais antigo enviado pelo transmissor e termina com o mais novo. Além isso, entre o envio de dois pacotes consecutivos pelo compressor, a cadeia S não sofre alterações, a menos que um ACK chegue durante esse tempo, que corresponderá a algumas letras do início do S. 60 ΕΡ1221239Β1
Agora, suponhamos que G1 indica o G mais à direita (mais novo) no S, e SI como o prefixo de S até (incluindo) G1. Em seguida, existem apenas dois casos possíveis, conforme ilustrado abaixo. 1_ s f 3 1 X X — X G1 R-R XX —XGt t— —I' si -i S1 Caso 1 Caso 2 Suponhamos que len(Sl) indica o comprimento de S 1. No caso 1, uma vez que existe um R a seguir a Gl, len(Sl) tem de ser igual a seq_ciclo (=2k) . Caso contrário, o compressor não terá enviado o pacote a seguir a G1 como um vermelho. No caso 2, len (Sl) < seq_ciclo tem de ser verdadeiro. Caso contrário, o compressor terá enviado G1 como um vermelho. Por conseguinte, em qualquer dos casos, len(Sl) é igual ou inferior a seq_ciclo.
Uma vez que G1 é a letra verde mais à direita em S, é demonstrado que, no máximo, 2k cabeçalhos verdes podem existir em HSW 117 a qualquer momento. Deste modo, quando um ACK verde é recebido pelo compressor, o CD_SN de bits k no ACK pode ser utilizado para identificar exclusivamente um cabeçalho verde em HSW.
Note que o descompressor tem de cooperar com o compressor para garantir que a sincronização de CD_SN é mantida durante a transição entre os dois modos. Primeiro, se o descompressor receber um pacote vermelho e decidir reconhecer esse pacote, tem de enviar um ACK vermelho que transporta (CD_SN) €_de extensão.
Segundo, se o descompressor receber um pacote FO, FO (n, m) , o cabeçalho de referência correto tem de ser o cabeçalho mais novo (mais recente) em OAW 135, cujos bits k (se m for bit k) ou €_de extensão (se m for bit k_de extensão) menos significativos correspondem a m. Note que isto se baseia na suposição de que, em cada direção, o 61 ΕΡ1221239Β1 canal se comporta como um FIFO. A Fig. 19 ilustra a segunda condição. Neste exemplo, NTO e NT2 são os valores de CD_SN nos momentos TO e T2, respetivamente. Suponhamos que, em TI, o compressor envia o pacote ACK (NTO) , em que NTO é codificado em bits €_de extensão. Em T2, o compressor recebe o ACK(NTO). Em seguida, calcula N_decorrido igual a (NT2-NT0) e descobre que N_decorrido<seq_ciclo. Ao mesmo tempo, um pacote RTP chega ao compressor e o compressor decide enviá-lo como um pacote FO, utilizando o cabeçalho(NTO) como referência. Uma vez que N_decorrido<seq_ciclo (=2k) , ο NT2 e NTO no pacote FO são codificados em bits k. Em T3, o FO chega ao descompressor. Para obter o cabeçalho de referência correto, o descompressor procura simplesmente na respetiva OAW de uma ponta (o mais recente) à outra (o mais antigo), e encontra o primeiro cabeçalho cujos bits k menos significativos do respetivo CD_SN correspondem a (NTO)k.
Note que, em T3, a OAW 135 do descompressor pode conter mais de 2k cabeçalhos. Contudo, o funcionamento acima proporciona sempre o cabeçalho de referência correto. Devido à propriedade FIFO do canal de avanço, tudo o que for recebido (e, deste modo, reconhecido) pelo descompressor entre TI e T3 tem de ser enviado pelo compressor entre TO e T2. Por outras palavras, se A indicar o conjunto de cabeçalhos em OAW 135 que foram adicionados a seguir ao cabeçalho (NTO), e B indicar o conjunto de cabeçalhos em HSW 117 em T2, mantém-se sempre A c b. Uma vez que |A | <2k, temos |B |<2k. Por conseguinte, não existem dois cabeçalhos no conjunto B para que os bits k menos significativos dos respetivos CD_SNs correspondam a (NTO)k no pacote F0(NT2, NTO).
Em seguida, é apresentado um exemplo de pseudocódigo para o descompressor: 0 descompressor é, em geral, acionado por aquilo que é recebido pelo compressor (ou seja, FH, FO ou SO) . 62 ΕΡ1221239Β1 A seguir, "recebido corretamente" significa que não foi detetado nenhum erro no cabeçalho recebido (FH, FO ou SO) . Além das informações de estado acima mencionadas, o descompressor mantém igualmente uma cópia do último cabeçalho reconstruído, ou seja, cabeçalho (R_Último_Descomp). Ao receber um pacote FO, o descompressor irá utilizar o procedimento descrito acima relativamente ao pseudocódigo do compressor para obter o cabeçalho de referência correto.
Se FH (n) for recebido corretamente { reconstruir o cabeçalho (n) a partir de FH(n); enviar ACK(n); R_Último_Reconhecido-n;
Armazenar cabeçalho(n) na 0AW135 e igualmente o cabeçalho(R_Último_Descomp); } se FO(n, m) for recebido corretamente { se não for possível encontrar o cabeçalho (m) na OAW 135/*, tal só pode acontecer devido a falhas no sistema */
Enviar FH_Req; mais { obter o cabeçalho (m) a partir da OAW 135 ou o cabeçalho (R_RFH); eliminar os cabeçalhos em OAW que são mais antigos do que o cabeçalho (R_RFH); reconstruir o cabeçalho(n)-F0_DIF(n, m) + cabeçalho(m); se R_RFH!=m R_RFH-m e armazenar o cabeçalho(m) como o cabeçalho(R_RFH); se FO (n, m) for um dos primeiros dois pacotes FO recebidos ou os pacotes N_RT FO foram recebidos desde o último pacote FO reconhecido { 63 ΕΡ1221239Β1
Enviar ACK(n) ; R_Último_Reconhecido-n; armazenar o cabeçalho(n) na OAW: } armazenar o cabeçalho reconstruído (n) no cabeçalho(R_Último_Descomp); }
Se SO(n) for recebido corretamente {
se for o primeiro pacote SO a seguir a um pacote não SO { encontrar os dois cabeçalhos reconstruídos mais recentemente em OAW 135; se não for encontrado /*, tal só pode acontecer devido a uma falha no sistema */
Enviar FH_Req; mais /*suponhamos que os dois cabeçalhos são o cabeçalho (p) e cabeçalho (q), p<q*/ R_DFOD+FO_DIF(q,p)/Dif(q,p); } reconstruir o cabeçalho(n)-R_DFOD * Dif (n, R_Último_Descomp) + cabeçalho(R_Último_Descomp) ; armazenar o cabeçalho(n) no cabeçalho(R_Último_Descomp); se 1) os pacotes (seq_ciclo - N_RT) tiverem decorrido desde R_Último_Reconhecido, ou, /* tempo para enviar um ack periódico */ 2) o sinalizador_de extensão em SO estiver ON e este for o primeiro pacote desses, ou, /* o compressor mudar para o modo de extensão; enviar ack para que o compressor regresse ao modo normal */
3) tiverem sido recebidos mais de N_RT pacotes com sinalizador_de extensão ON desde R_Último_ACK /* aparentemente o ack anterior não foi recebido; enviar outro ack * / {
Enviar ACK(n); n é codificado no modo de extensão se for cumprida 64 ΕΡ1221239Β1 a condição 2 ou 3 R_Último_Reconhecido-n: armazenar o Cabeçalho (n) na OAW; } } armazenar cabeçalho(n) na OAW135 e igualmente o cabeçalho(R_Último_Descomp) ; } se FO(n, m) for recebido corretamente { se não for possível encontrar o cabeçalho (m) na OAW 1355 /*, tal só pode acontecer devido a falhas no sistema */
Enviar FH_Req; mais { obter o cabeçalho (m) a partir da OAW 135 ou o cabeçalho (R_RFH); eliminar os cabeçalhos em OAW que são mais antigos do que o cabeçalho (R_RFH); reconstruir o cabeçalho(n)-FO_DIF(n, m) + cabeçalho (m); se R_RFH!=m R_RFH-m e armazenar o cabeçalho(m) como o cabeçalho(R_RFH); se FO (n, m) for um dos primeiros dois pacotes FO recebidos ou os pacotes N_RT FO tiverem sido recebidos desde o último pacote FO reconhecido {
Enviar ACK(n) ; R_Último_Reconhecido-n; armazenar o cabeçalho(n) na OAW: } armazenar o cabeçalho reconstruído(n) no cabeçalho(R_Último_Descomp); }
Se SO(n) for recebido corretamente {
se for o primeiro pacote SO a seguir a um pacote não SO { 65 ΕΡ1221239Β1 encontrar os dois cabeçalhos reconstruídos mais recentemente em OAW 135; se não for encontrado /*, tal só pode acontecer devido a uma falha no sistema */
Enviar FH_Req; mais /*suponhamos que os dois cabeçalhos são o cabeçalho (p) e cabeçalho (q), p<q*/ R_DFOD+FO_DIF(q,p)/Dif(q,p); } reconstruir o cabeçalho(n)-R_DFOD * Dif (n, R_Último_Descomp) + cabeçalho(R_Último_Descomp); armazenar o cabeçalho(n) no cabeçalho (R_Último_Descomp); se 1) os pacotes (seq_ciclo - N_RT) tiverem decorrido desde R_Último_Reconhecido, ou, /* tempo para enviar um ack periódico */ 2) o sinalizador_de extensão em SO estiver ON e este for o primeiro pacote desses, ou, /* o compressor mudar para o modo de extensão; enviar ack para que o compressor regresse ao modo normal */
3) tiverem sido recebidos mais de N_RT pacotes com sinalizador_de extensão ON desde R_Último_ACK /* aparentemente o ack anterior não foi recebido; enviar outro ack * / {
Enviar ACK(n); n é codificado no modo de extensão se for cumprida a condição 2 ou 3 R_Último_Reconhecido-n: armazenar o Cabeçalho (n) na OAW; } } HSW 117 e OAW 135
No pior dos casos, em que o atraso de ida e volta é efetivamente igual a RTT_UB, pode ser necessário que a OAW 135 ou HSW 117 mantenha 2 ^-de-extensao cabeçalhos. Contudo, isso é muito improvável de acontecer. Na maioria dos casos, 66 ΕΡ1221239Β1 é necessário manter menos de 2k entradas na HSW 117 ou OAW 135. Na prática, isto significa um número muito pequeno de entradas para OAW e HSW. Por exemplo, 16 (k=4) entradas irão proporcionar 320 ms de tempo de ida e volta, assumindo um espaçamento de 20 ms por pacote.
Os campos estáticos não necessitam de ser armazenados como entradas múltiplas em HSW 117 ou OAW 135. Apenas é necessária uma única cópia dos campos estáticos.
Em RFC 2508, cada cabeçalho comprimido transporta um número de sequência. Na maioria dos casos, o número de sequência é suficiente para reconstruir o cabeçalho completo através de extrapolação linear. Para esses pacotes em que a extrapolação linear resulta na reconstrução incorreta de cabeçalhos, o compressor envia informações de uma diferença de primeira ordem relativamente ao pacote imediatamente anterior. Deste modo, a perda de um pacote irá invalidar os pacotes subsequentes com cabeçalhos comprimidos, uma vez que o pacote perdido pode estar a transportar informações de diferença FO. O RFC 2508 depende unicamente do número de sequência de 4 bits para detetar perdas de pacotes. O número de sequência é moldado a cada 16 pacotes. Quando ocorre uma rajada de erros superior a 16 pacotes, existe uma probabilidade de 1 em 16 de não serem detetados erros, o que é inaceitavelmente elevado. Além disso, mesmo que o descompressor fosse capaz de detetar erros e recuperar de erros, o descompressor tem de solicitar ao compressor para enviar um cabeçalho de tamanho grande através do envio de uma mensagem ESTADO_CONTEXTO. Deste modo, foi provocado um atraso de ida e volta antes de o cabeçalho solicitado chegar ao recetor. No caso de tráfego de conversação em tempo real, este atraso é convertido numa interrupção da conversação. Além disso, o envio de um cabeçalho de tamanho grande é dispendioso em termos de largura de banda.
Uma forma de realização da presente invenção utiliza 67 ΕΡ1221239Β1 um número de sequência de bits k (k pode ser definido igual a 4) para extrapolação linear. Tal como RFC 2508, quando a extrapolação linear resulta na reconstrução incorreta de cabeçalhos, o compressor envia informações de uma diferença FO. Ao contrário de RFC 2508, a diferença é calculada relativamente a um pacote de referência conhecido por ser recebido corretamente. Esse pacote não é necessariamente o que antecede imediatamente o pacote atual. Esta funcionalidade garante que o cabeçalho atual pode ser reconstruído de forma fidedigna, mesmo em caso de perda de um ou mais pacotes antigos. Uma vez que o cabeçalho pode ser reconstruído de forma fidedigna dessa maneira, não é necessário enviar um cabeçalho completo. As informações de diferença de primeira ordem podem, na maior parte das vezes, ser codificadas com menos bits do que o valor absoluto do cabeçalho completo. 0 cabeçalho de diferença FO tem um campo adicional que transporta o número de referência, ou seja, o número de sequência do pacote de referência. Para garantir que os erros serão detetados mesmo na presença de grandes rajadas de erros, o descompressor envia um ACK com frequência suficiente, de modo a que o compressor receba um ack, pelo menos, uma vez em cada pacote seq_ciclo. Na ausência desse ACK, o compressor irá presumir que pode existir uma grande rajada de erros. Em seguida, na maioria dos casos, basta que o compressor mude simplesmente para um número de sequência de bits €_ _de extensão, em que €_de extensão é suficientemente grande para evitar qualquer ambiguidade. Aconteça o que acontecer, a perda de um pacote não irá invalidar pacotes subsequentes com cabeçalhos comprimidos. Por conseguinte, quando o descompressor deteta uma perda de pacotes, não tem de solicitar a retransmissão.
A Fig. 20 abaixo ilustra resultados comparativos do RFC 2508 do estado da técnica com a invenção. É assumido um atraso unidirecional (fixo) de 60 ms neste teste. O 68 ΕΡ1221239Β1 espaçamento intermédio entre pacotes RTP é de 30 ms. O modelo de erro aleatório é utilizado com taxas de erro de pacote de média diferente. A relação de compressão é definida como a relação entre o tamanho médio de cabeçalhos comprimidos e o tamanho dos cabeçalhos IP/UDP/RTP originais. Note que, com a invenção, o tamanho dos pacotes ACK é incluido no cálculo do tamanho de cabeçalho comprimido médio. A invenção supera o RFC 1508 assim que a taxa de erro de pacote for superior a 0,4 %. O esquema robusto da invenção necessita que o compressor e o descompressor mantenham as filas HSW 117 e OAW 135, respetivamente. Assumindo que as idas e voltas são inferiores a 320 ms, o tamanho das filas é de 16 entradas + uma cópia dos campos estáticos.
Ipv4 Ipv6 Tamanho dos campos estáticos 18 40 (em bytes) Tamanho de uma entrada (em 22 20 bytes) Tamanho total de HSW ou OAW (16*22 + 18)* (16*20 + para uma sessão bidirecional (em bytes) 2 = 740 40)*2 = 720
Cerca de 1 megabyte de memória irá permitir lidar com mais de 1400 sessões em simultâneo. A carga de processamento para gerir as filas é muito moderada, uma vez que envolve a manipulação de ponteiro.
Embora a invenção tenha sido descrita em termos das respetivas formas de realização preferidas, convém compreender que podem ser efetuadas diversas modificações da invenção sem sair do âmbito da mesma. É pretendido que essas modificações façam parte do âmbito das reivindicações em anexo. 69 ΕΡ1221239Β1
REFERÊNCIAS CITADAS NA DESCRIÇÃO
Esta lista de referências citadas pelo requerente é apenas para a conveniência do leitor. A mesma não faz parte do documento de Patente Europeia. Embora tenha sido tomado muito cuidado na compilação das referências, não se poderão excluir erros e omissões e o IEP não assume qualquer responsabilidade neste sentido.
Documentos de Patente citados na descrição • US 09377913 B [0021]
Lisboa, 26 de Novembro de 2014 70

Claims (18)

  1. ΕΡ1221239Β1 REIVINDICAÇÕES 1. Um método de funcionamento de um sistema que tem um transmissor que transmite uma pluralidade de pacotes contendo, cada um, um cabeçalho a um recetor, o método compreende sincronizar a transmissão de cabeçalhos comprimidos entre o transmissor e o recetor por meio de: a transmissão de um pacote atual do transmissor ao recetor contendo informações de que o transmissor está preparado para enviar pacotes subsequentemente transmitidos em que os cabeçalhos nos mesmos são para serem comprimidos em comparação com o cabeçalho contido no pacote atual, em que o cabeçalho do pacote atual é um cabeçalho completo ou um cabeçalho comprimido de primeira ordem; a transmissão do recetor ao transmissor de um pacote de reconhecimento de que o recetor recebeu o pacote atual; e em resposta a receber no transmissor o pacote de reconhecimento, o envio subsequentemente de pacotes transmitidos em que o cabeçalho comprimido dos pacotes subsequentemente transmitidos é um cabeçalho comprimido de segunda ordem.
  2. 2. Um método de acordo com a reivindicação 1, que compreende: o transmissor que armazena o cabeçalho do pacote atual, que foi reconhecido como sendo recebido pelo recetor, como um cabeçalho de referência que é usado na transmissão dos pacotes subsequentemente transmitidos como um cabeçalho de referência a ser usado pelo recetor para descomprimir os cabeçalhos subsequentes; o recetor que armazena o cabeçalho do pacote atual, que é reconhecido para descomprimir os cabeçalhos comprimidos 1 ΕΡ1221239Β1 dos pacotes subsequentemente transmitidos; o transmissor que transmite pacotes subsequentes usando o cabeçalho armazenado do pacote atual como um cabeçalho de referência; e o recetor que descomprime os cabeçalhos comprimidos dos pacotes recebidos subsequentemente transmitidos usando o cabeçalho de referência armazenado para produzir um cabeçalho completo que não é comprimido.
  3. 3. Um método de acordo com a reivindicação 2, que compreende: o recetor que deteta pelo menos um pacote perdido nos pacotes subsequentemente transmitidos por meio da comparação de números de sequências de pacotes transmitidos sucessivamente recebidos.
  4. 4. Um método de acordo com a reivindicação 2 ou reivindicação 3 que compreende: determinar um número de pacotes em falta entre um pacote imediatamente anteriormente recebido e o pacote atual; adicionar o número de pacotes em falta determinados a um número de pacotes do pacote imediatamente anteriormente recebido a um número do pacote atual para atualizar um número do pacote atual numa sequência de transmissão da pluralidade de pacotes; e descomprimir um número de sequências do pacote atual usando o número atualizado e descomprimir campos adicionais de informações usando o cabeçalho de referência armazenado.
  5. 5. Um método de funcionamento de um transmissor que transmite uma pluralidade de pacotes contendo, cada um, um cabeçalho a um recetor, o método compreende sincronizar a 2 ΕΡ1221239Β1 transmissão de cabeçalhos comprimidos entre o transmissor e o recetor por meio de: a transmissão de um pacote atual do transmissor ao recetor contendo informações de que o transmissor está preparado para enviar pacotes subsequentemente transmitidos em que os cabeçalhos nos mesmos são para serem comprimidos em comparação com o cabeçalho contido no pacote atual, em que o cabeçalho do pacote atual é um cabeçalho completo ou um cabeçalho comprimido de primeira ordem; receção do recetor de um pacote de reconhecimento que o recetor recebeu o pacote atual; e em resposta a receber no transmissor o pacote de reconhecimento, o envio subsequentemente de pacotes transmitidos em que o cabeçalho comprimido dos pacotes subsequentemente transmitidos é um cabeçalho comprimido de segunda ordem.
  6. 6. Um método de acordo com a reivindicação 5, que compreende: o transmissor que armazena o cabeçalho do pacote atual, que foi reconhecido como sendo recebido pelo recetor, como um cabeçalho de referência que é usado na transmissão dos pacotes subsequentemente transmitidos como um cabeçalho de referência a ser usado pelo recetor para descomprimir os cabeçalhos subsequentes; e o transmissor que transmite pacotes subsequentes usando o cabeçalho armazenado do pacote atual como um cabeçalho de referência.
  7. 7. Um sistema que compreende: um transmissor (108, 110, 120, 130, 150) configurado para transmitir uma pluralidade de pacotes contendo, cada um, 3 ΕΡ1221239Β1 um cabeçalho; um recetor (102, 108, 110, 120, 130, 150) configurado para receber a pluralidade transmitida de pacotes; e em que o transmissor é configurado para transmitir um pacote atual ao recetor contendo informações de que o transmissor está preparado para enviar pacotes subsequentemente transmitidos em que os cabeçalhos nos mesmos são para serem comprimidos em comparação com o pacote atual, em que o cabeçalho do pacote atual é um cabeçalho completo ou um cabeçalho comprimido de primeira ordem, e o recetor é configurado para transmitir um pacote de reconhecimento que o recetor recebeu o pacote atual; e em resposta a receber no transmissor o pacote de reconhecimento, o envio subsequentemente de pacotes transmitidos em que o cabeçalho comprimido dos pacotes subsequentemente transmitidos é um cabeçalho comprimido de segunda ordem.
  8. 8. Um sistema de acordo com a reivindicação 7, em que: o transmissor é configurado para armazenar o cabeçalho do pacote atual, que foi reconhecido como sendo recebido pelo recetor, como um cabeçalho de referência que é usado na transmissão dos pacotes subsequentemente transmitidos como um cabeçalho de referência a ser usado pelo recetor para descomprimir os cabeçalhos subsequentes; o recetor é configurado para armazenar o cabeçalho do pacote atual, que é reconhecido como um cabeçalho de referência, para descomprimir os cabeçalhos comprimidos dos pacotes subsequentemente transmitidos; o transmissor é configurado para transmitir pacotes subsequentes contendo o cabeçalho comprimido de segunda ordem usando o cabeçalho armazenado do pacote atual como um cabeçalho de referência; e 4 ΕΡ1221239Β1 o recetor é configurado para descomprimir os cabeçalhos comprimidos dos pacotes recebidos subsequentemente transmitidos usando o cabeçalho de referência armazenado para produzir um cabeçalho completo que não é comprimido.
  9. 9. Um sistema de acordo com a reivindicação 8, em que: o recetor é configurado para detetar pelo menos um pacote perdido nos pacotes subsequentemente transmitidos por meio da comparação de números de sequências de pacotes transmitidos sucessivamente recebidos; e o recetor é configurado para descomprimir o cabeçalho de um pacote recebido imediatamente após um último pacote perdido no decurso do tempo usando um número detetado de pacote perdidos e/ou o cabeçalho de referência armazenado.
  10. 10. Um sistema de acordo com a reivindicação 9, em que: o recetor é configurado para determinar um número de pacotes em falta entre um pacote imediatamente anteriormente recebido e o pacote atual; o recetor é configurado para adicionar o número de pacotes em falta determinados a um número de pacotes do pacote imediatamente recebido a um número do pacote atual para atualizar um número do pacote atual numa sequência de transmissão da pluralidade de pacotes; e o recetor é configurado para descomprimir uma número de sequências do pacote atual usando o número atualizado e campos adicionais de informações usando o cabeçalho de referência armazenado.
  11. 11. Aparelho (110, 120) que compreende: um transmissor (102, 108, 130, 150) configurado para 5 ΕΡ1221239Β1 transmitir uma pluralidade de pacotes contendo, cada um, um cabeçalho a um recetor (102, 108, 130, 150) , em que o transmissor é configurado para transmitir um pacote atual ao recetor contendo informações de que o transmissor está preparado para enviar pacotes subsequentemente transmitidos em que os cabeçalhos nos mesmos são para serem comprimidos em comparação com o pacote atual, em que o cabeçalho do pacote atual é um cabeçalho completo ou um cabeçalho comprimido de primeira ordem; o aparelho é configurado para receber do recetor um pacote de reconhecimento de que o recetor recebeu o pacote atual; e em resposta a receber no transmissor o pacote de reconhecimento, o envio subsequentemente de pacotes transmitidos em que o cabeçalho comprimido dos pacotes subsequentemente transmitidos é um cabeçalho comprimido de segunda ordem.
  12. 12. Aparelho de acordo com a reivindicação 11, em que: o transmissor é configurado para armazenar o cabeçalho do pacote atual, que foi reconhecido como sendo recebido pelo recetor, como um cabeçalho de referência que é usado na transmissão dos pacotes subsequentemente transmitidos como um cabeçalho de referência a ser usado pelo recetor para descomprimir os cabeçalhos subsequentes; e o transmissor é configurado para transmitir pacotes subsequentes contendo o cabeçalho comprimido de segunda ordem usando o cabeçalho armazenado do pacote atual como um cabeçalho de referência.
  13. 13. Um recetor (102, 130, 150) configurado; para receber de um transmissor (108, 130, 150) uma pluralidade de pacotes contendo, cada um, um cabeçalho, 6 ΕΡ1221239Β1 em que o recetor é configurado para receber um pacote atual contendo informações de que o transmissor está preparado para enviar pacotes em que os cabeçalhos nos mesmos são para serem comprimidos em comparação com o pacote atual, em que o cabeçalho do pacote atual é um cabeçalho completo ou um cabeçalho comprimido de primeira ordem; para armazenar o cabeçalho do pacote atual como um cabeçalho de referência; em resposta a receber o pacote atual, para enviar um pacote de reconhecimento ao transmissor que indica que o recetor recebeu o pacote atual; subsequentemente para receber um pacote subsequentemente transmitido que tem um cabeçalho comprimido de segunda ordem; e para usar o cabeçalho do pacote atual para descomprimir o cabeçalho comprimido de segunda ordem do pacote subsequentemente transmitido para produzir um cabeçalho completo que não é comprimido.
  14. 14. Um recetor de acordo com a reivindicação 13, em que: o recetor é configurado para detetar pelo menos um pacote perdido nos pacotes subsequentemente transmitidos por meio da comparação de números de sequências de pacotes transmitidos sucessivamente recebidos; e o recetor é configurado para descomprimir o cabeçalho de um pacote recebido imediatamente após um último pacote perdido no decurso do tempo ser descomprimido usando um número detetado de pacote perdidos e/ou o cabeçalho de referência armazenado.
  15. 15. Um recetor de acordo com a reivindicação 14, em que: o recetor é configurado para determinar um número de pacotes em falta entre um pacote imediatamente 7 ΕΡ1221239Β1 anteriormente recebido e o pacote atual; o recetor é configurado para adicionar o número de pacotes em falta determinados a um número de pacotes do pacote imediatamente recebido a um número do pacote atual para atualizar um número do pacote atual numa sequência de transmissão da pluralidade de pacotes; e o recetor é configurado para descomprimir uma número de sequências do pacote atual usando o número atualizado e campos adicionais de informações usando o cabeçalho de referência armazenado.
  16. 16. Um método de funcionamento de um recetor (102, 130, 150), o método compreende; receber de um transmissor (108, 130, 150) uma pluralidade de pacotes contendo, cada um, um cabeçalho, em que a pluralidade de pacotes inclui um pacote atual contendo informações de que o transmissor está preparado para enviar pacotes em que os cabeçalhos nos mesmos são para serem comprimidos em comparação com o pacote atual, em que o cabeçalho do pacote atual é um cabeçalho completo ou um cabeçalho comprimido de primeira ordem; armazenar o cabeçalho do pacote atual como um cabeçalho de referência; em resposta a receber o pacote atual, enviar um pacote de reconhecimento ao transmissor que indica que o recetor recebeu o pacote atual; receber subsequentemente um pacote subsequentemente transmitido que tem um cabeçalho comprimido de segunda ordem; e usar o cabeçalho do pacote atual para descomprimir o cabeçalho comprimido de segunda ordem do pacote subsequentemente transmitido para produzir um cabeçalho completo que não é comprimido. 8 ΕΡ1221239Β1
  17. 17. Um método de acordo com a reivindicação 16, o método compreende detetar pelo menos um pacote perdido nos pacotes subsequentemente transmitidos por meio da comparação de números de sequências de pacotes transmitidos sucessivamente recebidos.
  18. 18. Um método de acordo com a reivindicação 16 ou reivindicação 17, que compreende: determinar um número de pacotes em falta entre um pacote imediatamente anteriormente recebido e o pacote atual; adicionar o número de pacotes em falta determinados a um número de pacotes do pacote imediatamente anteriormente recebido a um número do pacote atual para atualizar um número do pacote atual numa sequência de transmissão da pluralidade de pacotes; e descomprimir um número de sequências do pacote atual usando o número atualizado e descomprimir campos adicionais de informações usando o cabeçalho de referência armazenado. Lisboa, 26 de Novembro de 2014 9
PT970868T 1999-10-14 2000-10-13 Método e sistema para comprimir e descomprimir cabeçalhos de pacotes PT1221239E (pt)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US15936099P 1999-10-14 1999-10-14
US09/536,639 US6882637B1 (en) 1999-10-14 2000-03-28 Method and system for transmitting and receiving packets

Publications (1)

Publication Number Publication Date
PT1221239E true PT1221239E (pt) 2014-12-03

Family

ID=26855882

Family Applications (2)

Application Number Title Priority Date Filing Date
PT71217756T PT1926282E (pt) 1999-10-14 2000-10-13 Método e sistema para comprimir e descomprimir cabeçalhos de pacotes
PT970868T PT1221239E (pt) 1999-10-14 2000-10-13 Método e sistema para comprimir e descomprimir cabeçalhos de pacotes

Family Applications Before (1)

Application Number Title Priority Date Filing Date
PT71217756T PT1926282E (pt) 1999-10-14 2000-10-13 Método e sistema para comprimir e descomprimir cabeçalhos de pacotes

Country Status (10)

Country Link
US (1) US6882637B1 (pt)
EP (5) EP2383953A3 (pt)
JP (3) JP3845581B2 (pt)
CN (1) CN1270496C (pt)
AU (1) AU8018700A (pt)
CA (1) CA2386837C (pt)
DK (2) DK1926282T3 (pt)
ES (2) ES2397710T3 (pt)
PT (2) PT1926282E (pt)
WO (1) WO2001028180A2 (pt)

Families Citing this family (112)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1496654B1 (en) * 1999-05-25 2006-07-12 Lucent Technologies Inc. Method for telecommunications using internet protocol
US6300887B1 (en) * 1999-11-09 2001-10-09 Nokia Networks Oy Efficient handoff procedure for header compression
JP3423930B2 (ja) * 1999-12-27 2003-07-07 富士通株式会社 バンプ形成方法、電子部品、および半田ペースト
US6496520B1 (en) * 2000-01-21 2002-12-17 Broadcloud Communications, Inc. Wireless network system and method
EP1146713B1 (en) * 2000-03-03 2005-04-27 NTT DoCoMo, Inc. Method and apparatus for packet transmission with header compression
DE10015640A1 (de) * 2000-03-29 2001-10-04 Bosch Gmbh Robert Verfahren zur Signalisierung unterschiedlicher Kopfinformationen
FR2809900B1 (fr) * 2000-05-31 2002-11-29 Mitsubishi Electric Inf Tech Procede et systeme de transmission de donnees bi-mode, emetteur et recepteur correspondant
US7788211B2 (en) * 2000-06-16 2010-08-31 Nokia Networks Oy Robust and efficient compression of list of items
WO2002009386A1 (de) * 2000-07-25 2002-01-31 Siemens Aktiengesellschaft Header-kompressionsverfahren für netzwerkprotokolle
US7469297B1 (en) * 2000-08-04 2008-12-23 Intellon Corporation Mechanism for using a quasi-addressed response to bind to a message requesting the response
US7352770B1 (en) * 2000-08-04 2008-04-01 Intellon Corporation Media access control protocol with priority and contention-free intervals
EP1187416B1 (en) * 2000-09-07 2005-03-23 Matsushita Electric Industrial Co., Ltd. Method and apparatus for transmitting data packets
JP3323483B2 (ja) * 2000-09-12 2002-09-09 松下電器産業株式会社 パケット送信装置およびパケット伝送方法
US6649567B2 (en) * 2001-10-11 2003-11-18 Isp Investments Inc. Controlled release microbiocide for porous surfaces
WO2002032080A1 (en) * 2000-10-11 2002-04-18 Broadcom Corporation Cable modem system and method for supporting packet pdu compression
US7046672B2 (en) * 2000-11-16 2006-05-16 Microsoft Corporation Robust, inferentially synchronized transmission of compressed transport-layer-protocol headers
US7136395B2 (en) * 2000-11-30 2006-11-14 Telefonaktiebolaget L M Ericsson (Publ) Method and system for transmission of headerless data packets over a wireless link
US20050036496A1 (en) * 2001-03-19 2005-02-17 Bob Tang Method for guaranteeing quality of service on the internet by routing data along nodes without error correction processing capability
US7187666B1 (en) * 2001-03-30 2007-03-06 Ipr Licensing, Inc. Employing simulated acknowledgment signals for efficient handoffs in cellular packet networks
US7212511B2 (en) * 2001-04-06 2007-05-01 Telefonaktiebolaget Lm Ericsson (Publ) Systems and methods for VoIP wireless terminals
US7310336B2 (en) 2001-05-18 2007-12-18 Esa Malkamaki Hybrid automatic repeat request (HARQ) scheme with in-sequence delivery of packets
EP1265124B1 (de) * 2001-06-07 2004-05-19 Siemens Aktiengesellschaft Verfahren zum Übermitteln von Zeitinformation über ein Datenpaketnetz
KR100595583B1 (ko) * 2001-07-09 2006-07-03 엘지전자 주식회사 이동통신시스템에서 핸드오버에 따른 패킷 데이터 전송 방법
US20030023746A1 (en) * 2001-07-26 2003-01-30 Koninklijke Philips Electronics N.V. Method for reliable and efficient support of congestion control in nack-based protocols
US7856660B2 (en) * 2001-08-21 2010-12-21 Telecommunication Systems, Inc. System for efficiently handling cryptographic messages containing nonce values
JP3617967B2 (ja) 2001-09-28 2005-02-09 松下電器産業株式会社 ヘッダ圧縮パケット受信装置及び方法
US7155521B2 (en) * 2001-10-09 2006-12-26 Nokia Corporation Starting a session in a synchronization system
EP1446925A1 (en) * 2001-10-25 2004-08-18 Worldcom, Inc. Communication session quality indicator
DE60229482D1 (de) * 2001-11-24 2008-12-04 Lg Electronics Inc Verfahren zur Übertragung von Paketdaten in komprimierter Form in einem Kommunikationssystem
FI113324B (fi) * 2001-12-21 2004-03-31 Nokia Corp Parannettu laitejärjestely, päätelaite ja menetelmä audiosignaalin siirrossa pakettikytkentäisessä tiedonsiirtoverkossa
US20030126196A1 (en) * 2001-12-27 2003-07-03 Todd Lagimonier System for optimizing the invocation of computer-based services deployed in a distributed computing environment
KR100883063B1 (ko) * 2002-02-16 2009-02-10 엘지전자 주식회사 문맥 재할당 방법
US7106733B2 (en) * 2002-03-20 2006-09-12 Intel Corporation Method and apparatus for network header compression
EP1349285A1 (en) * 2002-03-28 2003-10-01 Matsushita Electric Industrial Co., Ltd. Method for making efficient use of the bits allocated to the sequence number when transmitting compressed header data
US7558196B2 (en) * 2002-04-08 2009-07-07 Alcatel-Lucent Usa Inc. Method and apparatus for system resource management in a communications system
ITTO20020325A1 (it) * 2002-04-12 2003-10-13 Telecom Italia Lab Spa ,,procedimento per organizzare la comunicazione fra oggetti gestori ed oggetti gestiti in una rete telematica.relativa architettura e prodot
CA2432594C (en) * 2002-06-12 2011-01-11 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for increased internet protocol (ip) headers compression performance by reporting cause of missing packets
KR100497357B1 (ko) * 2002-06-26 2005-06-23 삼성전자주식회사 인터넷 프로토콜 기반 네트워크 환경에 있어서 헤더 압축및 패킷 다중화 장치와 그 방법
US8149703B2 (en) 2002-06-26 2012-04-03 Qualcomm Atheros, Inc. Powerline network bridging congestion control
US7120847B2 (en) * 2002-06-26 2006-10-10 Intellon Corporation Powerline network flood control restriction
US7324516B2 (en) * 2002-08-14 2008-01-29 Intel Corporation Data packet header conversion
US20040059835A1 (en) * 2002-09-25 2004-03-25 Zhigang Liu Method and system for in-band signaling between network nodes using state announcement or header field mechanisms
AU2002361716A1 (en) 2002-11-12 2004-06-03 Zetera Corporation Data storage devices having ip capable partitions
US8005918B2 (en) 2002-11-12 2011-08-23 Rateze Remote Mgmt. L.L.C. Data storage devices having IP capable partitions
US7355974B2 (en) * 2003-01-27 2008-04-08 International Business Machines Corporation Method for forwarding data packets by a router
GB0303812D0 (en) * 2003-02-19 2003-03-26 British Telecomm Tracking audience size
US20040165585A1 (en) * 2003-02-25 2004-08-26 Koji Imura Packet transmission apparatus and packet transmission method
TW200425690A (en) * 2003-05-13 2004-11-16 Benq Corp A header format of transmission control protocol/Internet protocol
GB2403877A (en) * 2003-07-09 2005-01-12 Motorola Inc Packet communication with header compression
US7822067B2 (en) 2003-08-08 2010-10-26 Qualcomm Incorporated Header compression enhancement for broadcast/multicast services
US7398325B2 (en) * 2003-09-04 2008-07-08 International Business Machines Corporation Header compression in messages
KR100608715B1 (ko) * 2003-09-27 2006-08-04 엘지전자 주식회사 QoS보장형 멀티미디어 스트리밍 서비스 시스템 및 방법
US7567559B2 (en) * 2003-09-30 2009-07-28 Intel Corporation Device, system and method for data transfer optimization
US7430617B2 (en) * 2003-12-19 2008-09-30 Nokia Corporation Method and system for header compression
DE102004003551A1 (de) * 2004-01-23 2005-08-18 Siemens Ag Kompressionsverfahren für einen Bytestrom in Netzwerkprotokollen
US7613185B2 (en) * 2004-03-17 2009-11-03 Verizon Corporate Services Group Inc. Packet header compression for lossy channels
US7231587B2 (en) * 2004-03-29 2007-06-12 Lsi Corporation Embedded picture PSNR/CRC data in compressed video bitstream
SE0401346D0 (sv) * 2004-05-24 2004-05-24 Ericsson Telefon Ab L M Methods for Increased Tolerance Against Packet Reordering for the Secure Reference Principle in Robust Header Compression
EP1603339A1 (en) * 2004-06-01 2005-12-07 STMicroelectronics S.r.l. Method and system for communicating video data in a packet-switched network, related network and computer program product therefor
US8254379B1 (en) * 2004-07-15 2012-08-28 Sprint Spectrum L.P. Method and system for application based compression profile selection
KR100703494B1 (ko) * 2004-08-09 2007-04-03 삼성전자주식회사 이동통신 시스템에서 사용자 데이터 프로토콜 체크섬을 포함하는 음성패킷망의 패킷 송/수신 방법 및 장치
US7924731B2 (en) * 2004-11-15 2011-04-12 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for handling out-of-sequence packets in header decompression
US7817628B2 (en) * 2004-11-15 2010-10-19 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for header compression with transmission of context information dependent upon media characteristic
US8165104B2 (en) * 2004-12-08 2012-04-24 Qualcomm Incorporated Methods and systems for enhancing local repair in robust header compression
EP1686732B1 (de) * 2005-01-28 2007-10-31 Siemens Aktiengesellschaft Verfahren und System zur Übertragung von Telegrammen
US7620981B2 (en) 2005-05-26 2009-11-17 Charles William Frank Virtual devices and virtual bus tunnels, modules and methods
US20060277322A1 (en) * 2005-06-03 2006-12-07 Nokia Corporation System and method for implementing reference-based electronic mail compression
US8804765B2 (en) * 2005-06-21 2014-08-12 Optis Wireless Technology, Llc Dynamic robust header compression
KR100800794B1 (ko) 2005-07-01 2008-02-04 삼성전자주식회사 패킷망을 통해 음성 서비스를 지원하는 이동통신시스템에서 음성 서비스의 전송률을 제어하는 방법 및 장치
US8009699B2 (en) * 2005-07-12 2011-08-30 Qualcomm Incorporated Efficient encoding of out of order data packets in a network
US8054826B2 (en) * 2005-07-29 2011-11-08 Alcatel Lucent Controlling service quality of voice over Internet Protocol on a downlink channel in high-speed wireless data networks
CN100463445C (zh) * 2005-08-09 2009-02-18 大唐移动通信设备有限公司 数据包序列号计算方法及数据包传输方法
US8819092B2 (en) 2005-08-16 2014-08-26 Rateze Remote Mgmt. L.L.C. Disaggregated resources and access methods
WO2007024161A1 (en) 2005-08-23 2007-03-01 Telefonaktiebolaget L M Ericsson (Publ) Method and arrangement for measuring transmission quality in a packet mode communication network
GB2432748A (en) * 2005-11-25 2007-05-30 Ericsson Telefon Ab L M SIP messaging in an IP Multimedia Subsystem wherein a local user identity is added to message header as a basis for application server processing
US7620870B2 (en) * 2005-11-22 2009-11-17 Cisco Technology, Inc. Data compression method and system
US7924881B2 (en) * 2006-04-10 2011-04-12 Rateze Remote Mgmt. L.L.C. Datagram identifier management
US7948989B2 (en) * 2006-05-04 2011-05-24 Qualcomm, Incorporated Methods and systems for enhancing local repair in robust header compression
WO2008001422A1 (fr) * 2006-06-26 2008-01-03 Panasonic Corporation Système de communication radio et dispositif de communication radio
US8948206B2 (en) * 2006-08-31 2015-02-03 Telefonaktiebolaget Lm Ericsson (Publ) Inclusion of quality of service indication in header compression channel
EP2102676B1 (en) * 2007-01-18 2014-10-29 Telefonaktiebolaget LM Ericsson (publ) Improved load estimation for a cell in a wireless network
TWI334293B (en) * 2007-03-06 2010-12-01 Xtera Comm Taiwan Co Ltd Method for transmitting network packets
WO2008111820A1 (en) * 2007-03-15 2008-09-18 Lg Electronics Inc. Method of managing data blocks during handover
KR101364932B1 (ko) * 2007-03-15 2014-02-20 엘지전자 주식회사 데이터 생성 패턴을 이용한 데이터 전송 방법
CN101141639B (zh) * 2007-09-28 2010-08-18 上海华为技术有限公司 一种识别流媒体视频帧边界的方法和装置
CN101453298B (zh) * 2007-12-07 2013-06-05 华为技术有限公司 一种无线网络中头压缩的处理方法及系统、装置
FR2924887B1 (fr) * 2007-12-07 2011-07-15 Thales Sa Procede et dispositif de transmission robuste d'en-tetes reseau compresses
US8289640B2 (en) * 2008-08-11 2012-10-16 International Business Machines Corporation Error burst detection and amelioration
US8867566B2 (en) * 2008-08-20 2014-10-21 Qualcomm Incorporated Methods of header compression within a wireless communications network
JP5066064B2 (ja) * 2008-11-28 2012-11-07 日本放送協会 一方向伝送路に用いる送信端末、受信端末及び伝送システム
JP5127745B2 (ja) * 2009-02-23 2013-01-23 三菱電機株式会社 無線通信システムおよび通信制御方法
US8655143B2 (en) * 2009-04-01 2014-02-18 Cisco Technology, Inc. Supplementary buffer construction in real-time applications without increasing channel change delay
US8457048B2 (en) * 2009-08-31 2013-06-04 Research In Motion Limited Methods and apparatus to avoid mobile station transmission of duplicate event-based and polled acknowledgments
US8731000B2 (en) * 2009-09-30 2014-05-20 Cisco Technology, Inc. Decoding earlier frames with DTS/PTS backward extrapolation
US9923995B1 (en) * 2010-02-27 2018-03-20 Sitting Man, Llc Methods, systems, and computer program products for sharing information for detecting an idle TCP connection
JP5509438B2 (ja) * 2010-03-03 2014-06-04 株式会社日立製作所 データ転送装置及びデータ転送システム
EP2698002B1 (en) 2011-04-12 2016-06-15 Telefonaktiebolaget LM Ericsson (publ) A method and system for transmitting data from a radio network controller to a user equipment
RU2627033C1 (ru) * 2011-06-28 2017-08-03 Самсунг Электроникс Ко., Лтд. Способ и устройство для кодирования и декодирования изображения, используя внутреннее предсказание
US8717698B2 (en) 2011-10-12 2014-05-06 International Business Machines Corporation Hierarchical control of tiered error recovery for storage devices
JP6053692B2 (ja) 2011-12-20 2016-12-27 キヤノン株式会社 データ転送装置、データ転送方法およびチップ間通信システム
JP6258312B2 (ja) * 2012-06-29 2018-01-10 アボセント・ハンツビル・エルエルシーAvocent Huntsville,LLC 複数の異なるビデオ圧縮技術に対応する単一のkvmクライアントに対するシステムおよび方法
US9894421B2 (en) * 2012-10-22 2018-02-13 Huawei Technologies Co., Ltd. Systems and methods for data representation and transportation
JP6523249B2 (ja) * 2013-04-17 2019-05-29 トムソン ライセンシングThomson Licensing パケットヘッダを圧縮する方法及び装置
JP2015136059A (ja) 2014-01-17 2015-07-27 ソニー株式会社 通信装置、通信データ生成方法、および通信データ処理方法
KR101764636B1 (ko) 2014-03-11 2017-08-03 엘지전자 주식회사 방송 신호 송/수신 처리 방법 및 장치
GB2536827B (en) * 2014-05-09 2017-07-05 Imagination Tech Ltd Time stamp replication within a wireless network
US9485179B2 (en) * 2014-11-13 2016-11-01 Cavium, Inc. Apparatus and method for scalable and flexible table search in a network switch
US20190052512A1 (en) * 2016-02-15 2019-02-14 Nec Corporation Wireless base station, terminal device, and communication system
WO2017214969A1 (en) * 2016-06-17 2017-12-21 Nokia Technologies Oy Enhanced uplink beam selection for massive mimo system
US11284229B2 (en) * 2017-02-17 2022-03-22 Nippon Telegraph And Telephone Corporation Sensing system and time stamp correction method
US20190141567A1 (en) * 2017-11-06 2019-05-09 Mediatek Inc. Uplink Data Compression Transaction Flow
US10701124B1 (en) * 2018-12-11 2020-06-30 Microsoft Technology Licensing, Llc Handling timestamp inaccuracies for streaming network protocols

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS57184349A (en) 1981-05-08 1982-11-13 Fujitsu Ltd Data transmitting system
CA1220830A (en) 1984-12-28 1987-04-21 David S. Drynan Transmitting sequence numbers of information in a packet data transmission system
CA2065578C (en) * 1991-04-22 1999-02-23 David W. Carr Packet-based data compression method
US5446736A (en) * 1993-10-07 1995-08-29 Ast Research, Inc. Method and apparatus for connecting a node to a wireless network using a standard protocol
US5579316A (en) * 1994-05-02 1996-11-26 Adtran Communications technique for transmitting limited size digital data frames using macro headers to represent multiple header code patterns associated with encapsulation protocols and signal processing operations to which transmitted data are subjected
JP3068002B2 (ja) 1995-09-18 2000-07-24 沖電気工業株式会社 画像符号化装置、画像復号化装置及び画像伝送システム
US5835730A (en) * 1996-07-31 1998-11-10 General Instrument Corporation Of Delaware MPEG packet header compression for television modems
AU4497097A (en) * 1996-09-25 1998-04-17 Qualcomm Incorporated Method and apparatus for detecting bad data packets received by a mobile telephone using decoded speech parameters
US6011796A (en) 1997-06-17 2000-01-04 Qualcomm Incorporated Extended range sequence numbering for selective repeat data transmission protocol
US6041054A (en) * 1997-09-24 2000-03-21 Telefonaktiebolaget Lm Ericsson Efficient transport of internet protocol packets using asynchronous transfer mode adaptation layer two
US6032197A (en) * 1997-09-25 2000-02-29 Microsoft Corporation Data packet header compression for unidirectional transmission
JP3045715B2 (ja) 1998-01-23 2000-05-29 松下電器産業株式会社 伝送システム、送信装置、記録再生装置、および記録装置
US6304914B1 (en) * 1998-09-22 2001-10-16 Microsoft Corporation Method and apparatus for pre-compression packaging
US6198735B1 (en) * 1999-05-20 2001-03-06 Motorola, Inc. Method for retransmitting a data packet in a packet network
EP1496654B1 (en) 1999-05-25 2006-07-12 Lucent Technologies Inc. Method for telecommunications using internet protocol
MXPA01012521A (es) 1999-06-18 2002-07-02 Ericsson Telefon Ab L M Codificacion delta robusta, con informacion de historia.
US6542931B1 (en) * 1999-11-05 2003-04-01 Nokia Corporation Using sparse feedback to increase bandwidth efficiency in high delay, low bandwidth environment
US6300887B1 (en) * 1999-11-09 2001-10-09 Nokia Networks Oy Efficient handoff procedure for header compression

Also Published As

Publication number Publication date
EP2381639A3 (en) 2017-05-31
CA2386837A1 (en) 2001-04-19
EP2034691B1 (en) 2012-11-21
JP2003511981A (ja) 2003-03-25
WO2001028180A2 (en) 2001-04-19
EP2323337A2 (en) 2011-05-18
WO2001028180A3 (en) 2001-12-20
US6882637B1 (en) 2005-04-19
DK1221239T3 (en) 2014-11-17
JP2009135974A (ja) 2009-06-18
JP4364877B2 (ja) 2009-11-18
ES2397710T3 (es) 2013-03-08
EP1221239A2 (en) 2002-07-10
CA2386837C (en) 2007-08-14
EP2383953A2 (en) 2011-11-02
PT1926282E (pt) 2013-01-25
CN1409915A (zh) 2003-04-09
ES2525641T3 (es) 2014-12-26
EP2034691A1 (en) 2009-03-11
CN1270496C (zh) 2006-08-16
JP2006311517A (ja) 2006-11-09
DK1926282T3 (da) 2013-02-11
AU8018700A (en) 2001-04-23
EP2323337A3 (en) 2017-06-07
JP5091893B2 (ja) 2012-12-05
EP2381639A2 (en) 2011-10-26
EP1221239B1 (en) 2014-09-17
EP2383953A3 (en) 2017-06-07
JP3845581B2 (ja) 2006-11-15

Similar Documents

Publication Publication Date Title
PT1221239E (pt) Método e sistema para comprimir e descomprimir cabeçalhos de pacotes
US7539130B2 (en) Method and system for transmitting and receiving packets
JP3940159B2 (ja) ヘッダ圧縮のための効率的ハンド・オフ処理手順
US6680955B1 (en) Technique for compressing a header field in a data packet
KR100663586B1 (ko) 헤더 압축에 의한 패킷 데이터의 송신 방법 및 장치
RU2424627C2 (ru) Динамическое надежное уплотнение заголовка
AU2001243533A1 (en) A technique for compressing a header field in a data packet
EP1187417B1 (en) Method and apparatus for transmitting data packets
US7962653B2 (en) Methods for increased tolerance against packet reordering for the secure reference principle in robust header compression
EP1926282B1 (en) Method and system for compressing and decompressing packet headers
Yang et al. Compression Techniques for VoIP Transport over Wireless Interfaces