BRPI0722125A2 - Método e aparelho para correção de erro de encaminhamento adaptativo com pedido de repetição automática combinada para multitransmissão confiável em redes de área local sem fio - Google Patents

Description

“MÉTODO E APARELHO PARA CORREÇÃO DE ERRO DE ENCAMINHAMENTO ADAPTATIVO COM PEDIDO DE REPETIÇÃO AUTOMÁTICA COMBINADA PARA MULTITRANSMISSÃO CONFIÁVEL EM REDES DE ÁREA LOCAL SEM FIO”

Campo da Invenção

A presente invenção refere-se a redes de comunicação sem fio e, em particular, a aumentar a confiabilidade de aplicativos de multitransmissão aplicando uma combinação de correção de erro de encaminhamento e solicitação de repetição automática.

Fundamentos da Invenção

Como usado aqui, “conteúdo” é usado para incluir áudio, vídeo e qualquer outra forma de dados incluindo quaisquer dados multimídia. Os termos vídeo e conteúdo são usa- dos aqui de forma intercambiável. Como usado aqui, "1” denota nomes alternativos para os mesmos componentes ou estruturas ou similares. Isto é, um “I” pode ser obtido como signifi- cado de “ou” como usado aqui.

As redes de área local sem fio (WLANs), por causa de sua flexibilidade e baixo cus- to, foram usadas extensivamente em residências, hotéis, em campi e outros pontos de a- cesso, tal como aeroportos e estações de trem. Enquanto em muitos casos, os usuários se conectam a uma WLAN para navegar em sítios da rede ou verificar correio eletrônico, há uma demanda crescente por WLANs que suportem transmissão contínua de multimídia em tempo real. Entretanto, um canal sem fio pode sofrer de desvanecimento do sinal por múlti- plos caminhos e interferências, o que causar perdas de pacotes em rajadas e aleatórios e causar impacto na qualidade da reprodução do conteúdo de um aplicativo de transmissão contínua. Para otimizar a confiabilidade, esquemas de correção de erro, tal como correção de erro de encaminhamento (FEC) e/ou pedido de repetição automática (ARQ), podem ser usados. Em FED1 os pacotes de paridade são enviados com os dados/pacotes de mídia originais/fonte. Entretanto, como cada dispositivo pode experimental diferentes condições de canal, é difícil decidir quanto FEC enviar. FEC menor pode causar pouca proteção e paco- tes/dados perdidos podem não ser capazes de ser recuperados. FEC maior pode causar mais sobrecarga e gasta largura de banda da rede. A presente invenção descreve um méto- do adaptativo, que fornece a um cliente/dispositivo móvel a proteção apropriada enquanto ao mesmo tempo usar o recurso de largura de banda eficazmente.

Usando ARQ para correção de erro, a recuperação de dados/pacotes do clien- te/dispositivo móvel pode sofrer um longo atraso de tempo de viagem de ida e volta. Em aplicativos de multitransmissão, ARQ pode também resultar em problemas de explosão de retorno. Entretanto, quando o atraso de tempo de viagem de ida e volta é curto, e o algorit- mo de supressão de retorno apropriado é usado, ARQ é ainda um esquema de correção de erro possível para transmissão contínua de conteúdo em tempo real.

FEC é uma forma eficaz de otimizar a confiabilidade para aplicativos de multitrans- missão. Uma variedade de esquemas FEC pode ser empregada na camada de aplicativo para correção de erro em nível de pacote. Os candidatos incluem Pro-MPEG com/sem en- trelaçamento aleatório e Reed-Solomon (RS). Todos os esquemas FEC têm vantagens e desvantagens. FEC Pro-MPEG é um esquema muito leve já que ele somente emprega ope- ração XOR1 mas sua capacidade de correção de erro é correspondentemente limitada. Pro- MPEG não pode corrigir alguns padrões de erro mesmo se as perdas de pacote não são altas. RS tem melhor capacidade de correção de erro do que esquemas FEC baseados em XOR na maioria dos casos, já que ele funciona independentemente de padrões de erro. O custo de empregar RS é aumentado por recursos computacionais. No entanto, em alguns casos, RS tem desempenho mais baixo do que esquemas FEC baseados em XOR, já que o código RS (n, k) falha completamente nos casos de mais de n-k perdas de pacote dos n pacotes codificados em um bloco de codificação FEC. FEC baseado em XOR pode possi- velmente ainda corrigir parte dos dados/pacotes perdidos quando há mais de n-k perdas de pacotes.

O problema com FEC é decidir quando FEC enviar em primeiro lugar. Em um apli- cativo de multitransmissão, diferentes dispositivos móveis podem ter diferentes condições de canal e taxas de perda. Um único FEC estático não pode satisfazes às exigências de todos os dispositivos móveis. FEC em camadas é introduzido na técnica anterior acoplado à codificação de fonte escalável para otimizar a eficiência do uso da largura de banda e a qua- lidade do serviço em redes sem fio. Entretanto, esquemas da técnica anterior não considera- ram retransmissão de ARQ. Se a perda de pacote para um receptor é mais do que a capa- cidade do código FEC, os pacotes perdidos não podem ser recuperados. Ademais, um re- ceptor não pode obter a exata quantidade de pacotes FEC que precisa porque ele obtém FEC em camadas, em um número discreto de pacotes FEC. Em adição, o esquema em ca- madas da técnica anterior não considerou a sincronização entre múltiplas trilhas de uma sessão multimídia. Por exemplo, em uma sessão multimídia, frequentemente há uma trilha de áudio e uma trilha de vídeo, a trilha de vídeo tem taxa de bits muito mais alta do que a trilha de áudio, se o mesmo tamanho de bloco FEC é usado, levará muito mais tempo para a trilha de áudio preencher o armazenador temporário de FEC.

Em uma solução da técnica anterior, o número máximo de pacotes (maxK) que será usado para codificação FEC em um bloco FEC é ajustado. Quando o número de pacotes de vídeo (áudio) para uma trilha no armazenador temporário alcança maxK, a codificação FEC baseada nesses pacotes de vídeo (áudio) é executada. Ao mesmo tempo, a codificação FEC baseada na outras trilhas dos pacotes de mídia de áudio (vídeo) é também executada, não importa quantos pacotes estejam no outro armazenador temporário de áudio (vídeo). Como ambos NeK não são fixos para diferentes blocos FEC, NeK precisam ser incluídos no FEC principal e a informação, desse modo, passada ao cliente. Na técnica anterior, ARQ foi usado em multitransmissão quando o tempo médio de viagem de ida e volta de clientes ao servidor é baixo e o número de clientes em uma sessão de multitransmissão é pequeno. Frequentemente, a supressão de retorno é implementada para evitar o problema de explosão de retorno. Nos esquemas ARQ híbridos da técnica an- terior, um cliente/dispositivo móvel envia um pedido pelo número de pacotes de paridade que ele precisa para decodificar um bloco FEC ao invés do número de seqüência dos paco- tes de mídia originais. Os pacotes de paridade retransmitidos são transmitidos a todos os clientes na sessão de multitransmissão. Os pacotes de paridade podem ser usados por dife- rentes clientes/dispositivos móveis para recuperar diferentes perdas.

Diferentes cenários podem usar diferentes esquemas de correção de erro. Em al- guns casos, FEC pode ser mais eficaz enquanto em outros casos, ARQ pode ser uma esco- lha melhor. Seria vantajoso fornecer uma única solução para todos os cenários de aplica- ção.

Sumário da Invenção

A presente invenção descreve um método adaptativo para aumentar a confiabilida- de de aplicativos de multitransmissão em WLANs aplicando uma combinação de correção de erro de encaminhamento e pedido de repetição automática. Em um sistema de transmis- são/multitransmissão sem fio, pacotes/dados podem sofrer de perdas aleatórias e em rajada por causa de situações de desvanecimento do sinal por múltiplos caminhos, interferência, comutação automática, etc. Para otimizar a confiabilidade, os esquemas de correção de erro tais como correção de erro de encaminhamento (FEC) e pedido de repetição automática (ARQ) podem ser empregados. Há vantagens em combinar FEC e ARQ. Combinar FEC e ARQ pode aumentar a flexibilidade de implementação do sistema e otimizar o desempenho do sistema em cenários específicos. A presente invenção descreve um esquema combina- do, denotado aqui como um esquema ARQ híbrido combinado, ou mhARQ. No sistema mhARQ da presente invenção, pacotes FEC são codificados e divididos em um ou mais grupos de multitransmissão FEC adaptativos e um grupo de multitransmissão ARQ. Um sis- tema de transmissão/multitransmissão WLAN pode assim ser configurado para usar ARQ ou FEC adaptativo ou ambos em um aplicativo de multitransmissão.

Um método e um aparelho são descritos para aumentar a confiabilidade da multi- transmissão, incluindo receber conteúdo e uma primeira camada de uma pluralidade de pa- cotes codificados de correção de erro de encaminhamento de um primeiro grupo de multi- transmissão e aderir a um grupo de multitransmissão adicional de modo a receber uma das camadas adicionais de pacotes codificados de correção de erro de encaminhamento e o conteúdo junto com uma camada adicional da pluralidade de pacotes codificados de corre- ção de erro de encaminhamento. São também descritos um método e um sistema para au- mentar a confiabilidade da multitransmissão, incluindo gerar uma pluralidade de camadas de pacotes codificados de correção de erro de encaminhamento, transmitir conteúdo e uma primeira camada da dita pluralidade dos pacotes codificados de correção de erro de enca- minhamento, transmitir uma segunda camada da pluralidade dos pacotes codificados de correção de erro de encaminhamento mediante pedido, transmitir uma terceira camada da pluralidade dos pacotes codificados de correção de erro de encaminhamento mediante re- cebimento de uma mensagem de pedido de repetição automática e retransmitir o conteúdo e uma quarta camada da pluralidade dos pacotes codificados de correção de erro de enca- minhamento, mediante recebimento de um pedido de conteúdo de pedido de repetição au- tomática.

Dever-se-ia notar que cada uma das camadas dos pacotes FEC poderia ser múlti- plos grupos de multitransmissão. Isto é, a segunda camada descrita acima poderia, de fato, ser várias subcamadas transmitidas por múltiplos grupos de multitransmissão. Para a se- gunda camada, há ou poderia haver vários grupos de multitransmissão. Para cada grupo de multitransmissão, o tempo de atraso é diferente (e configurável). Um cliente/dispositivo mó- vel não precisa aderir a todos os grupos de multitransmissão nessa camada, mas precisa somente aderir a grupos de multitransmissão que ele precisa de modo a receber suficientes pacotes de paridade/FEC para recuperar o conteúdo.

Breve Descrição dos Desenhos

A presente invenção é mais bem entendida a partir da seguinte descrição detalhada quando lida em conjunto com os desenhos em anexo. Os desenhos incluem as seguintes figuras brevemente descritas abaixo:

A FIG. 1 mostra um típico sistema de distribuição de vídeo LAN sem fio para aplica- tivos de transmissão WLAN de conteúdo multimídia (multitransmissão ao longo de uma WLAN).

A FIG. 2 mostra os três tipos de grupos FEC para um fluxo fonte.

A FIG. 3 é um diagrama de bloco/esquemático do cliente/dispositivo móvel do mé- todo ARQ híbrido combinado da presente invenção.

A FIG. 4A, 4B, 4C e 4D tomadas juntas são os fluxogramas dos três fluxos de pro- cessamento no módulo proxy cliente.

A FIG. 5 é um diagrama das estruturas de dados do proxy no lado do cliente da presente invenção.

A FIG. 6 é um diagrama de bloco/esquemático do lado do servidor do método ARQ híbrido combinado da presente invenção.

Descrição Detalhada das Modalidades Preferenciais

Diferentes cenários podem usar diferentes esquemas de correção de erro. Em al- guns casos, FEC pode ser mais eficaz enquanto em outros casos, ARQ pode ser uma me- lhor escolha. Em alguns cenários, esses dois esquemas podem ser combinados juntos para otimizar o desempenho. Seria vantajoso fornecer uma única solução a todos os cenários de aplicação.

A presente invenção descreve um método adaptativo para aumentar a confiabilida- de de aplicativos de multitransmissão em WLANs aplicando uma combinação de correção de erro de encaminhamento e pedido de repetição automática. Em um sistema de transmis- são/multitransmissão sem fio, pacotes/dados podem sofrer perdas aleatórias e em rajada por causa de situações de desvanecimento do sinal por múltiplos caminhos, interferência, comutação automática, etc. Há vantagens combinando FEC e ARQ. Combinar FEC e ARQ pode aumentar a flexibilidade de implementação do sistema e otimizar o desempenho do sistema nos cenários específicos. No sistema mhARQ da presente invenção, pacotes FEC são codificados e divididos em um ou mais grupos de multitransmissão FEC adaptativos e um grupo de multitransmissão ARQ. Um sistema de transmissão/multitransmissão WLAN pode assim ser configurado para usar ARQ ou FEC adaptativo ou ambos em um aplicativo de multitransmissão. Isto é, a presente invenção é uma única solução de recuperação de dados/pacotes integrados para aplicativos de conteúdo de multimídia de multitransmissão. Como usado aqui, o termo “grupo” denota grupo de multitransmissão a menos que indicado de outra forma.

A FIG. 1 mostra um típico sistema de distribuição LAN sem fio para aplicativos de transmissão WLAN (transmissão ao longo de uma WLAN) de conteúdo multimídia de pontos de acesso. Os servidores de conteúdo (conteúdo sob demanda 105 e conteúdo ao vivo 110) são conectados aos pontos de acesso sem fio 120a, 120b através de uma LAN de Ethernet em alta velocidade 125. Os servidores de conteúdo (conteúdo sob demanda (COD), conteú- do ao vivo) 105, 110 transmitem um ou mais programas (áudio e/ou vídeo) ao longo da rede por fio de alta velocidade aos pontos de acesso sem fio 120a, 120b. FEC em camada de aplicativo é executado e os pacotes FEC são enviados em grupos de multitransmissão FEC atrasada e não atrasada por um servidor de transmissão contínua 115 para fornecer capaci- dade de recuperação de erro. Os pontos de acesso 120a, 120b distribuem o conteúdo aos dispositivos sem fio 130a, 130b, 130c, 130d em multitransmissão ao longo das ligações sem fio 135. Os usuários dos dispositivos sem fio 130a, 130b, 130c, 130d podem visualizar um ou mais programas e simultaneamente acessar a Internet 140. O acesso à internet 140 é via as ligações sem fio 135, um ponto de acesso WLAN apropriado 120a, 120b, uma LAN de Ethernet de alta velocidade 125 e comutador de Ethernet 145, uma ligação de comunicação 150 e possivelmente uma barreira de segurança 155. O servidor ARQ 160 recebe NACKS a partir de clientes/dispositivos móveis e envia os pacotes ARQ FEC. Em alguns casos, o ser- vidor ARQ e o servidor de transmissão contínua podem ser colocalizados em um apare- lho/máquina/dispositivo. Um cliente/dispositivo móvel adere a um grupo ARQ FEC via IGMP, se pacotes FEC atrasados não foram suficientes para recuperar os pacotes/dados perdi- dos/danificados.

Os pacotes FEC para um fluxo de conteúdo/fonte/vídeo/áudio são divididos em dife- rentes camadas. Cada camada é transmitida em um diferente grupo de multitransmissão. Como mostrado na FIG. 2, há três tipos de grupos FEC para um fluxo fonte:

- Grupos FEC não atrasados: Os pacotes FEC nesses grupos não são atrasados a

partir do conteúdo/fonte, isto é, esses pacotes FEC são enviados contanto que eles são ge- rados. Para recuperação de perda aleatória, um cliente/dispositivo móvel adere a um ou mais grupos FEC não atrasados baseados em suas condições de canal de “longo prazo”. Se o membro é estático ou “semiestático” (em minutos), o cliente/dispositivo móvel não precisa 10 aderir a grupos FEC atrasados ou enviar ARQ. FEC não atrasado reduz o tráfego de retorno a partir de clientes/dispositivos móveis.

- Grupos FEC atrasados: A transmissão de pacotes FEC nesses grupos é atrasado a partir dos pacotes de mídia por um tempo configurável. Usando Protocolo de Gerencia- mento de Grupo de Internet (IGMP), um cliente/dispositivo móvel dinamicamente (por bloco

FEC) adere/deixa os grupos FEC atrasados se os pacotes FEC não atrasados não são sufi- cientes para recuperar perda de dados/conteúdo. Se o tempo de aderir é maior do que o deslocamento de tempo entre conteúdo e FEC atrasado, os pacotes de paridade correspon- dentes serão recebidos para recuperar os pacotes perdidos de conteúdo/dados pelo clien- te/dispositivo móvel. Para economizar largura de banda sem fio, os dados FEC atrasados 20 para um grupo de multitransmissão não seriam transmitidos pelo AP/roteador 120a, 120b na rede sem fio se nenhum cliente/dispositivo móvel associado com o AP/roteador adere a es- se grupo particular.

- Grupos ARQ FEC: Os pacotes FEC nos grupos ARQ FEC são enviados de acordo com o NACK a partir de clientes/dispositivos móveis. Um cliente/dispositivo móvel envia o

NACK ao servidor ARQ e adere aos grupos ARQ FEC correspondentes via IGMP se paco- tes FEC atrasados não são suficientes para recuperar os pacotes/dados perdidos.

- Grupos de Conteúdo/Fonte ARQ: Se o número de pacotes perdidos exceder um limite, o servidor ARQ pode retransmitir o bloco original de pacotes de mídia em um grupo de multitransmissão. A razão é que FEC é usado para ou recuperar todos os pacotes/dados

perdidos/danificados ou nenhum dos pacotes/dados perdidos/danificados. Quando há mui- tos pacotes/dados perdidos/danificados, o receptor é ao menos capaz de receber alguns dos pacotes de mídia retransmitidos.

Para flexibilidade, o número de grupos FEC atrasados e não atrasados, o desloca- mento de tempo entre o fluxo de conteúdo e fluxos FEC atrasados, bem como a quantidade de FEC em grupos FEC atrasados, não atrasados e grupos ARQ FEC podem ser configura- dos.

Reprodutores de vídeo/conteúdo gratuito e comercial disponíveis, por exemplo, Quicktime, Estrutura de Aplicativo Multimídia Thomsin (MMAF), e reprodutores de Cliente VideoLAN (VLC), não suportam FEC. O código fonte geralmente não está disponível para reprodutores comerciais. É difícil integrar FEC em cada reprodutor gratuito bem como man- ter e atualizar o código fonte mesmo se o código fonte de aplicativo gratuito está disponível.

A presente invenção inclui uma arquitetura proxy cliente como mostrado na FIG. 3. O proxy cliente pode funcionar com qualquer reprodutor de vídeo gratuito e comercial sem qualquer exigência para mudar o código do reprodutor. O proxy cliente recebe pacotes de mídia e FEC a partir de diferentes grupos de multitransmissão, adere ou deixa os grupos de multi- transmissão FEC, envia NACKs ARQ ao servidor ARQ, recebe pacotes de mídia e FEC re- 10 transmitidos, recupera pacotes de mídia perdidos e envia os pacotes de mídia recuperados ao reprodutor através de um soquete de comunicação.

Com relação ainda à FIG. 3, o cliente/dispositivo móvel recebe conteúdo a partir dos servidores de conteúdo 105, 110 via a interface WLAN 305 (via um ponto de acesso WLAN 120a, 120b). O cliente/dispositivo móvel pode ao mesmo tempo ser um membro de múltiplos grupos de multitransmissão (conteúdo, FEC, FEC atrasado, ARQ FEC, Fon- te/Conteúdo ARQ) cada um indicado por um fluxo separado (310a, 310b) através de uma pilha de protocolo de protocolo de internet/protocolo de datagrama de usuário (UDP/IP) 315. Na pilha de protocolo UDP/IP comum 315, o conteúdo 320 e os pacotes FEC 325 são sepa- rados e entram no módulo Proxy cliente FEC 330 da presente invenção. O conteúdo recupe- rado pode ser armazenado em um sistema de armazenamento 335, que poderia incluir qualquer forma de armazenamento tal como discos, fitas, CDs, memória, DVDs, etc. para reprodução posterior, ou o conteúdo recuperado pode ser enviado a um reprodutor (oi qual- quer dispositivo de exibição disponível e adequado) 355 via um soquete de comunicação, que inclui pilhas de protocolo UDP/IP 340 e 345 e pilha de protocolo UDP/IP 350 no disposi- tivo de exibição 355.

No lado do servidor de conteúdo, antes da operação de codificação FEC é execu- tada, um certo número de pacotes de mídia (K) é armazenado. O conteúdo multimídia pode incluir múltiplas trilhas, por exemplo, trilha de vídeo e trilha de áudio. A operação de codifi- cação FEC é executada em cada trilha respectivamente. Diferentes trilhas de mídia têm dife- 30 rentes taxas de bit, usualmente vídeo tem uma taxa de bits mais alta do que áudio. Usar o mesmo tamanho de bloco FEC para vídeo e áudio causará um problema de sincronização de áudio/vídeo no receptor. Por exemplo, quando o número de pacotes de vídeo no arma- zenador de vídeo alcança K, a codificação FEC é executada nesses pacotes, os pacotes FEC de vídeo são enviados e o armazenador temporário é esvaziado para o próximo bloco; 35 ao mesmo tempo, o número de pacotes de áudio no armazenador temporário de áudio pode ainda ter que esperar um tempo não específico antes que ele alcance K. Uma abordagem é usar diferentes tamanhos de blocos para vídeo e áudio. Para certo tamanho de bloco de vídeo, entretanto, como selecionar o tamanho de bloco para áudio é um problema de proje- to. Diferentes conteúdos podem exigir diferentes pareamentos de tamanho de bloco entre as trilhas de áudio e vídeo. Mesmo para o mesmo conteúdo, o conteúdo de taxa de bits varian- te pode precisar de diferentes Ks para áudio e vídeo em diferentes tempos.

Para fluxo de taxa de bits variante, o tempo de preencher um número fixo de paco-

tes de mídia em um armazenador temporário pode variar. Para ademais combater a latência na reprodução que pode ser incorrida por causa do armazenamento FEC, um tempo de ar- mazenamento temporário máximo (maxT) é ajustado para um bloco FEC na presente inven- ção. Se o tempo de armazenamento para o primeiro pacote no armazenador FEC de vídeo 10 ou de áudio for igual ou maior do que maxT, ou o número de pacotes de vídeo (ou áudio) para uma trilha no armazenador temporário alcança maxK (um tamanho de armazenador máximo), a codificação FEC nos pacotes em ambas as trilhas de vídeo e de áudio do conte- údo multimídia é executada.

Para aplicações em tempo real, usar NeK variantes pode resolver o problema de 15 sincronização de áudio e vídeo, mas pode causar sobrecarga de codificação e decodificação extra, porque as matrizes de geração para diferentes NeK são diferentes, e criar matrizes de geração é muito computacionalmente dispendioso. Para otimizar a eficácia da codifica- ção e decodificação, ambos maxK e maxN são fixos na presente invenção. A matriz de ge- ração é criada com base em maxK e maxN, e é inícializada somente uma vez em ambos o 20 lado do servidor e o lado do cliente. Todos os códigos (N, K), K á maxK e N á maxN, assim podem ser gerados usando a matriz de geração inicial com base em códigos encurta- dos/puncionados, o que reduz drasticamente o tempo de codificação e decodificação.

Os detalhes funcionais do proxy cliente 330 são mostrados nas FIGs. 4a, 4B, 4C e 4D. As funções/ações/etapas do proxy cliente podem ser implementadas em software, hardware, suporte lógico inalterado, circuitos integrados específicos de aplicativos (ASICs) e/ou arranjos de porta programável de campo (FPGAs) ou qualquer combinação dos acima ou qualquer outro dispositivo adequado. O proxy cliente recebe e armazena os pacotes de mídia e FEC recebidos, estima as condições de canal com base nas perdas de pacote. Se o proxy cliente não pode recuperar a mensagem original a partir de um bloco FEC, o proxy cliente aderirá a grupos FEC mais atrasados e/ou enviará um pedido ARQ para a retrans- missão de mais pacotes de mídia originais ou FEC. Um algoritmo de supressão de retorno ARQ é também implementado no proxy cliente. Se alguns pacotes são perdidos/danificados, mas o bloco FEC pode ser decodificado, o Proxy cliente recuperará os pacotes perdi- dos/danificados a partir dos pacotes de paridade (FEC) e enviará os pacotes de mídia recu- perados ao reprodutor. Se os pacotes são perdidos/danificados e o proxy cliente não pode decodificar o bloco FEC, quando o temporizador do armazenador temporário expira, o proxy cliente enviará os pacotes de mídia recebidos ao reprodutor mesmo se alguns pacotes de mídia são perdidos e não podem ser recuperados.

As tarefas do proxy cliente são executadas por três processos separados. O pro- cesso principal receberá e armazenará os pacotes de paridade/mídia. O processo principal também receberá e processará pedidos ARQ de outros clientes/dispositivos móveis no gru- 5 po de multitransmissão. O processo principal também executará estimativa de canal, pro- cessamento FEC adaptativo e decodificação FEC. O processamento ARQ e o encaminha- mento de pacotes são executados pelo segundo e pelo terceiro processos, respectivamente.

Com relação novamente às FIGs. 4A, 4B, 4C e 4D, que juntas mostram o método praticado no módulo proxy cliente 330 da FIG. 3. A FIG. 4A é a rotina principal e o armaze- 10 nador fonte é inicializado em 405. Em 410, o (segundo) processo de encaminhamento de pacote é convocado. A fila de eventos ARQ é inicializada em 415. O (terceiro) processo de evento ARQ é convocado em 420. Finalmente, o primeiro/principal processo que manipula o recebimento de pacotes de mídia, armazenando os pacotes de mídia e a recuperação de erro, etc. é convocado em 425.

A FIG. 4B é um fluxograma do primeiro/principal processo do método praticado pelo

módulo proxy cliente 330 da FIG. 3. EM 430, um pacote é recebido. As condições de canal são estimadas em 435. Um teste é executado em 440 para determinar se o pacote recebido é um pacote FEC. Se o pacote recebido é um pacote FEC, o pacote é processado em 465. Quando um cliente/dispositivo móvel recebe um pacote de paridade (FEC), o clien- 20 te/dispositivo móvel obtém toda a informação sobre o bloco FEC ao qual esse pacote de paridade pertence (no qual o pacote de paridade/FEC é incluído) a partir do bloco FEC prin- cipal. O cliente/dispositivo móvel primeiramente verifica se uma estrutura de dados de bloco foi alocada para o bloco FEC. Se uma estrutura de dados de bloco ainda não foi alocada, então uma estrutura de dados de bloco é alocada. Um bloco FEC é inserido na estrutura de 25 dados (por exemplo, lista vinculada) de acordo com seu número de seqüência base. O nú- mero de seqüência base de um bloco FEC é o menor número de seqüência dos pacotes de mídia que pertencem a (estão incluídos em) esse bloco FEC. Após um bloco FEC ter sido alocado, o cliente/dispositivo móvel examina o armazenador fonte e marca os pacotes de mídia que pertencem a esse bloco FEC, e atualiza a informação (tal como quantos pacotes 30 são perdidos, quais pacotes estão perdidos, etc.) correspondente a esse bloco. Um teste é executado em 485 para determinar se o bloco FEC foi decodificável. Após um bloco FEC ter sido alocado, o cliente/dispositivo móvel é capaz de examinar o armazenador fonte e restau- ra a informação (tal como quantos pacotes estão perdidos, quais pacotes estão perdidos, etc.) correspondente a esse bloco e usa a informação restaurada no processo de decodifi- 35 cação FEC. Se o bloco FEC não foi decodificável, então o algoritmo FEC adaptativo é con- vocado em 495. Isto é, o Proxy cliente adere a um grupo de multitransmissão FEC atrasado e solicita pacotes FEC atrasados. Um teste é então executado em 497 para determinar se ARQ é necessário. ARQ seria necessário se os pacotes FEC atrasados fossem insuficientes para recuperar os pacotes/dados perdidos/danificados. ARQ aqui inclui pacotes ARQ FEC e pedidos de pacote de conteúdo/fonte ARQ. Isso inclui aderir a grupos de multitransmissão de conteúdo/fonte ARQ e ARQ FEC. Se ARQ é necessário, então um pedido ARQ é inseri- 5 do na fila de eventos ARQ em 499. O processamento então retorna para 430. Se ARQ não é necessário, então o processamento retorna para 430.

Se o bloco FEC foi decodificável, então o pacote(s) recuperado(s) é/são inserido no armazenador fonte em 490. Os pacotes de mídia ou FEC recebidos após um FEC ter sido decodificado são extraídos. Quando todos os pacotes de mídia para um bloco FEC são en- 10 viados à tela, a estrutura de bloco FEC é apagada e a memória é liberada. O FEC adaptati- vo é então ativado em 491 para decidir se o cliente recebeu pacotes de paridade desneces- sários e necessita deixar/abandonar os grupos FEC já aderidos. O processamento então retorna para 430.

Se o pacote recebido não é um pacote FEC, então um teste é executado em 445 15 para determinar se o pacote recebido é um pacote de mídia. Se o pacote recebido é um pa- cote de mídia, então o pacote de mídia é processado em 470. Quando um cliente/dispositivo móvel recebe um pacote de mídia, o pacote de mídia recebido é inserido na estrutura de dados (por exemplo, lista vinculada) de acordo com o número de seqüência. Se um pacote de mídia é recebido após o bloco FEC ao qual esse pacote pertence ter sido alocado, o cli- 20 ente/dispositivo móvel é capaz de localizar essa estrutura de bloco FEC a partir da lista vin- culada com base no número de seqüência do pacote de mídia, no número de seqüência base, N e K do bloco FEC. O cliente/dispositivo móvel marca esse pacote de mídia e atuali- za a informação de bloco FEC. O processamento então prossegue para 485.

É também possível que os pacotes de paridade para um certo bloco FEC sejam to- 25 talmente perdidos, por exemplo, em uma comutação automática. O cliente/dispositivo móvel pode não ser capaz de obter qualquer informação FEC sobre os pacotes de mídia que per- tencem a esse bloco FEC. Se a diferença entre o último pacote de mídia não marcado e o primeiro pacote de mídia não marcado excede um certo limite (por exemplo, 3/2 do valor estimado de K), o cliente/dispositivo móvel conclui que todos os pacotes FEC para esses 30 pacotes de mídia são perdidos/danificados (bloco FEC não é decodificável). O clien- te/dispositivo móvel então ativará o algoritmo FEC adaptativo ou o processamento de pedido ARQ da presente invenção sem qualquer informação FEC sobre esses pacotes de mídia.

Se o pacote recebido não é um pacote de mídia, então um teste é executado em 450 para determinar se o pacote recebido é um pacote ARQ. Se o pacote recebido é um pacote ARQ, então a supressão de ARQ é executada em 475 para impedir um problema de explosão de retorno de ARQ. O processamento então retorna para 430.

Se o pacote recebido não é um pacote ARQ, então um teste é executado em 455 para determinar se o pacote recebido é um pacote RTCP. Se o pacote recebido é um pacote RTCP1 então este é processado em 480. Os pacotes RTCP recebidos são inseridos no ar- mazenador fonte de acordo com o tempo em que eles foram recebidos desde que números de seqüência nos pacotes RTCP não são atribuídos de acordo com os pacotes RTP. O pro- cessamento então retorna para 430. Se o pacote recebido não for um pacote RTCP, então o pacote recebido é extraído em 460. O processamento então retorna para 430.

A FIG. 4C é um fluxograma do segundo processo do método praticado pelo módulo Proxy cliente 330 da FIG. 3. O segundo processo manipula o encaminhamento de pacote fonte. Em 433, um teste é executado para determinar se o armazenador fonte está vazio. Se estiver, então o processamento retorna e está em um estado de espera até que o armaze- nador fonte não está mais vazio. O teste em 433 pode ser executado em alguma base de tempo ou qualquer outra base conveniente tal que uma determinação pode ser feita com relação ao estado do armazenador fonte. Se o armazenador fonte não estiver vazio, então um teste é executado em 443 para determinar se o tempo do armazenador de pacote para o pacote principal expirou. O pacote principal é o próximo pacote no armazenador a ser mani- pulado. Como o método da presente invenção pode usar uma estrutura de dados de lista vinculada, o próximo pacote no armazenador pode não ser o próximo pacote na estrutura, mas de preferência o próximo pacote a ser manipulado pode ser o próximo pacote apontado por um ponteiro da lista vinculada. Se o tempo do armazenador expirou, então o pacote principal é encaminhado para um reprodutor de mídia ou dispositivo de exibição de mídia em 453. Isto é, se um pacote de mídia ou RTCP recebido permanece no armazenador por mais do que um tempo T, então o cliente/dispositivo móvel encaminha o pacote para o re- produtor de mídia. O ponteiro para o pacote principal é ajustado para o próximo pacote no armazenador fonte em 463. O processamento então retorna para 433. Se o tempo do arma- zenador principal não expirou, então o processamento retorna para 433.

A FIG. 4D é um fluxograma do terceiro processo do método praticado pelo módulo Proxy cliente 330 da FIG. 3. O terceiro processo manipula o processamento ARQ. Em 437, um teste é executado para determinar se o armazenador de lista de eventos está vazio. Se o armazenador de lista de eventos está vazio, então o processamento retorna e está em um estado de espera até que o armazenador de lista de eventos não esteja mais vazio. O teste em 437 pode ser executado em alguma base de tempo ou qualquer outra base conveniente tal que uma determinação possa ser feita com relação ao estado do armazenador de lista de eventos. Se o armazenador de lista de eventos não está vazio, então um teste é executado em 447 para determinar se o temporizador de evento principal expirou. O temporizador de evento principal é o temporizador para manipular o próximo evento na fila de eventos. Se o temporizador de evento principal expirou, então um pedido ARQ é enviado em 457. O tem- porizador de evento principal é ajustado para o ponto do próximo evento na fila de eventos em 467. O processamento então retorna para 437. Se o temporizador de evento principal não expirou, então o processamento retorna para 437.

A estrutura de dados principal no lado do cliente é mostrada na FIG. 5. Um clien- te/dispositivo móvel mantém um armazenador fonte (armazenador de mídia) para cada trilha do fluxo de mídia em uma sessão. O armazenador fonte armazena T segundos dos pacotes de mídia. O armazenador fonte pode ser implementado usando uma estrutura de dados da lista vinculada. As estruturas de dados da presente invenção descritas abaixo são usadas pelos processos das FIGs. 4A, 4B, 4C e 4D. As estruturas de dados são usadas em múlti- plos pontos no tempo e para múltiplos propósitos nos processos das FIGs. 4A, 4B, 4C e 4D.

Um bloco FEC inclui um ou mais pacotes de mídia (até k pacotes de mídia). Assim, um pacote de mídia é dito pertencer a um bloco FEC. O bloco FEC também inclui um ou mais pacotes FEC (paridade) (até n-k pacotes de paridade/FEC). Assim, os pacotes de pari- dade/FEC são ditos pertencer a um bloco FEC. Aqui, n é o tamanho do bloco FEC, e k é o número de pacotes de mídia em um bloco FEC. Um pacote de mídia é marcado se o bloco FEC ao qual ele pertence foi alocado. Assim, se o bloco FEC foi alocado, o clien- te/dispositivo móvel é capaz de localizar essa estrutura de bloco FEC a partir da lista vincu- lada com base no número de seqüência do pacote de mídia, no número de seqüência base, e N e K do bloco FEC.

Na implementação da presente invenção, durante a codificação FEC no lado do servidor, os pacotes de mídia não são modificados. Toda a informação sobre os parâmetros de codificação FEC é incluída nos pacotes FEC. A implementação é retrocompatível porque mesmo se um cliente/dispositivo móvel não suporta FEC, ele ainda pode aderir ao grupo de multitransmissão de mídia, receber os pacotes de mídia e reproduzir o conteúdo recebido.

Quando o cliente/dispositivo móvel recebe um pacote de mídia, o pacote de mídia recebido é inserido na estrutura de dados do armazenador fonte (por exemplo, lista vincula- da) de acordo com o número de seqüência como mostrado em 505a, 505b..... 505a+1. Se a

estrutura de dados de bloco FEC a qual o pacote de mídia recebido pertence não foi aloca- da ainda, o cliente/dispositivo móvel não tem informação sobre o bloco FEC ao qual esse pacote de mídia pertence. Um pacote de mídia não inclui qualquer informação sobre o bloco FEC. Também, a presente invenção não usa NeK fixos na codificação FEC (de preferência maxN e maxK são fixos), a informação de índice de bloco FEC não pode ser derivada do número de seqüência. Se não há informação sobre o bloco FEC ao qual o pacote de mídia pertence, o pacote de mídia não é marcado.

Dever-se-ia notar que pacotes de protocolo de controle de transporte em tempo real (RTCP) para uma trilha de mídia são também inseridos em uma estrutura de dados de ar- mazenador fonte correspondente (por exemplo, lista vinculada). Os números de seqüência nos pacotes RTCP não são atribuídos de acordo com os pacotes RTP. De preferência, os pacotes RTCP são inseridos no armazenador fonte de acordo com o tempo em que os pa- cotes RTCP foram recebidos.

Se um pacote de mídia ou RTCP permanece no armazenador temporário por mais de um tempo T pré-determinado ou configurável, então o cliente/dispositivo móvel envia o pacote ao reprodutor de mídia.

Um cliente/dispositivo móvel também mantém uma estrutura de dados de armaze- nador de bloco FEC. Essa estrutura de dados pode também ser implementada como uma lista vinculada cada elemento na lista vinculada é uma estrutura de dados de bloco FEC que inclui toda a informação sobre um bloco FEC, tal como o número de seqüência base, N e K, etc.

Quando um cliente/dispositivo móvel recebe um pacote de paridade (FEC), o clien- te/dispositivo móvel obtém a informação sobre o bloco FEC ao qual esse pacote de paridade pertence a partir do bloco FEC principal. O cliente/dispositivo móvel primeiramente verifica se uma estrutura de dados de bloco foi alocado ao bloco FEC. Se uma estrutura de dados 15 de bloco não foi ainda alocada, então uma estrutura de dados de bloco é alocada. Uma es- trutura de dados de bloco FEC é inserida na estrutura de dados (por exemplo, lista vincula- da) de acordo com seu número de seqüência base como mostrado em 510a, 510b, ..., 510β+1. O número de seqüência base de um bloco FEC é o menor número de seqüência dos pacotes de mídia que pertencem a esse bloco FEC. Após um bloco FEC ter sido aloca- 20 do, o cliente/dispositivo móvel examina o armazenador fonte e marca os pacotes de mídia que pertencem a esse bloco FEC, e atualiza a informação (tal como quantos pacotes estão perdidos, quais pacotes estão perdidos, etc.) correspondente a esse bloco. A informação é usada no FEC adaptativo da presente invenção. A informação é também usada na decodifi- cação FEC (485 e 490 da FIG. 4B). Subsequentemente, se um pacote de mídia ou um paco- 25 te FEC é recebido para esse bloco FEC, a informação desse bloco é atualizada correspon- dentemente.

Se um pacote de mídia é recebido após o bloco FEC ao qual esse pacote pertence ter sido alocado, o cliente/dispositivo móvel é capaz de localizar essa estrutura de bloco FEC a partir da lista vinculada com base no número de seqüência do pacote de mídia, no número de seqüência base, N e K do bloco FEC. O cliente/dispositivo móvel marca esse pacote de mídia e atualiza a informação de bloco FEC.

Uma estrutura de dados de bloco FEC inclui um arranjo de ponteiros que apontam para todos os pacotes de mídia que pertencem a esse bloco. Ela também inclui um armaze- nador de decodificação que é usado para armazenar pacotes FEC para esse bloco. Um ar- mazenador de memória, que é exigido para executar decodificação FEC, é também alocado no armazenador de decodificação.

Se um bloco FEC é decodificável, a decodificação FEC é executada e os pacotes de mídia recuperados são inseridos no armazenador fonte. Os pacotes de mídia ou FEC após um bloco FEC ter sido decodificado são extraídos. Quando todos os pacotes de mídia para um bloco FEC são enviados à tela, a estrutura de bloco FEC é apagada e a memória é liberada.

É também possível que os pacotes de paridade para um certo bloco FEC sejam to- talmente perdidos, por exemplo, em uma comutação automática. O cliente/dispositivo móvel pode não ser capaz de obter qualquer informação FEC sobre esses pacotes de mídia. Um cliente/dispositivo móvel também mantém um ponteiro para o primeiro pacote de mídia não marcado no armazenador fonte, na FIG. 5, pkt-(a + 1) é o primeiro pacote não marcado.

Se a diferença entre o último pacote de mídia não marcado e o primeiro pacote de mídia não marcado exceder um certo limite (por exemplo, 3/2 do valor estimado de K), o cliente/dispositivo móvel conclui que todos os pacotes FEC para esses pacotes de mídia são perdidos/danificados (bloco FEC não é decodificável). O cliente/dispositivo móvel então ati- vará o algoritmo FEC adaptativo ou processamento de pedido ARQ da presente invenção sem qualquer informação FEC sobre esses pacotes de mídia. Porque na presente invenção, K não é fixo, um cliente/dispositivo móvel mantém uma estimativa do valor médio de K.

Cada cliente/dispositivo móvel mantém uma estrutura de dados de lista de eventos. Um evento pode ser um evento de processamento ARQ, que inclui toda a informação para um cliente/dispositivo móvel enviar um pedido ARQ ou processar supressão de ARQ. Cada evento é inserido na lista de eventos de acordo com seu tempo de expiração como mostra- do em 515a, 515b, ..., 515γ+1. Um evento pode também ser um evento de verificação. Por exemplo, após um cliente/dispositivo móvel enviar um pedido ARQ, o cliente/dispositivo mó- vel pode inserir um evento de verificação na lista de eventos para verificar posteriormente para determinar se ele recebeu os pacotes de paridade de retransmissão e foi capaz de de- codificar um bloco FEC. Se o cliente/dispositivo móvel não recebeu e de decodificou o paco- te de retransmissão, o cliente/dispositivo móvel pode enviar outro pedido ARQ.

Uma sessão de multitransmissão tem um grupo de mídia representado por gru- po_mídia. Cada trilha de mídia na sessão de multitransmissão também tem um número de grupos FEC. O número de grupos FEC pode ser diferente, por exemplo, para trilhas de áu- dio e vídeo como discutido acima. Os algoritmos FEC adaptativo e ARQ são desenvolvidos para cada trilha de mídia separadamente. Na seguinte discussão, assume-se que uma ses- são de multitransmissão que tem somente uma trilha de mídia para descrever o algoritmo ARQ e FEC adaptativo. Para uma sessão de multimídia com múltiplas trilhas, o método po- de ser usado para cada trilha.

Assume-se que um fluxo tem um total de m+1 grupos FEC (grupo (0), grupo (1), ..., grupo (m)), grupo (0) a grupo (m-1) são grupos FEC adaptativos, o grupo (m) é usado para ARQ. O primeiro grupo FEC é enviado imediatamente após o grupo de mídia (grupo FEC não atrasado). Um cliente sempre aderirá ao grupo de mídia e ao primeiro grupo FEC. No

seguinte, o número do grupo é usado para indexar os parâmetros associados com esse

grupo. Por exemplo, a sobrecarga do grupo (i) seria sobrecarga (i), e o atraso do grupo (i)

seria atraso (í). Se o código FEC tem um tamanho de bloco de η, o número de símbolos de

mensagem em cada bloco seria então:

n

k =

1+ Σ”^0 sobrecargaÇÍ)

O número de símbolos de paridade em cada grupo é:

num_paridade(i) = sobrecarga(i) * k.

Um cliente/dispositivo móvel estima a taxa de perda média e sua variância para os blocos FEC recebidos como taxa_perda_média e variância_média, respectivamente.

Quando um cliente/dispositivo móvel recebe o primeiro pacote FEC para um bloco FEC, significa que o cliente/dispositivo móvel recebeu o último símbolo/pacote de mídia do bloco FEC atual.

A partir do FEC principal, o cliente/dispositivo móvel extrai toda a informação sobre 15 esse bloco FEC, e tem o conhecimento se quaisquer pacotes de mídia foram perdidos e quantos pacotes foram perdidos para esse bloco FEC. Essa informação é usada para atuali- zar a estimativa da perda e variância médias. Nesse ponto, se o cliente/dispositivo móvel já recebeu suficientes pacotes/símbolos para decodificar o bloco FEC atual, o clien- te/dispositivo móvel não tem que aderir a quaisquer novos grupos FEC ou enviar um pedido 20 ARQ. Entretanto, se o cliente/dispositivo móvel aderiu a mais grupos FEC, então o clien- te/dispositivo móvel pode receber símbolos/pacotes de paridade redundantes. Isto é, o clien- te/dispositivo móvel pode receber mais pacotes de paridade/símbolos do que o clien- te/dispositivo móvel precisa. O cliente pode precisar deixar (não aderir) a esses grupos FEC.

Assumindo que o cliente não recebe suficientes símbolos para decodificar o bloco 25 FEC atual. O número de símbolos de mensagem/mídia perdidos é: msg_perdida = k - msg_recebida. O cliente/dispositivo móvel precisa decidir o número de grupos FEC que ele precisa aderir. Uma modalidade é aderir a todos os grupos de uma vez. Uma segunda mo- dalidade é aderir a um grupo FEC adicional primeiro. Após algum atraso, o clien- te/dispositivo móvel então verifica para determinar se recebeu suficientes pacotes/símbolos 30 para decodificar o bloco FEC. Se não, o cliente/dispositivo móvel adere ao próximo grupo FEC.

Em uma primeira modalidade, o número de símbolos que são necessários pode ser estimado por:

Simb_pedido = msg_perdida * (1 + taxa_perda_média) + a * variância_média Em redes sem fio, a variância de perda de pacote pode ser muito grande. Assim, na

maior parte do tempo, o cliente/dispositivo móvel pode superestimar os símbolos de parida- de necessários. Entretanto, é ainda possível subestimar os símbolos pedidos, que causa blocos FEC não decodificáveis. O número de grupos que o cliente/dispositivo móvel precisa aderir seria então:

g = min (/: 2{zlnitmporfifli((0 > sim_pedido) / < m - 1 (1)

Quando o cliente/dispositivo móvel adere a um grupo FEC de multitransmissão, o cliente/dispositivo móvel precisa especificar a duração que ele deveria permanecer aderido a esse grupo. Isso é especificado pelo parâmetro grp_expira.

grp_expira(i) = tempo_atual + atraso(i) + Te i<m-1 (2) onde Te é um parâmetro configurável, por exemplo, Te = 500 ms. Se o clien- te/dispositivo móvel adere a todos os grupos FEC adaptativos, mas ainda não pode decodi- ficar o bloco FEC, o cliente/dispositivo móvel terá que enviar um pedido ARQ. Para lidar com a explosão de retorno, o pedido ARQ não é enviado imediatamente. Um temporizador de pedido ARQ é inserido na fila de eventos, o tempo de expiração do temporizador é ajustado entre (K - msg_perdida) * Ts e (K - msg_perdida + 1) * Ts. Dessa forma, o cliente/dispositivo móvel que perdeu a maioria dos pacotes enviará o pedido ARQ primeiro. O pedido ARQ será transmitido ao grupo de multitransmissão de pedido ARQ. Outros clientes/dispositivos móveis, recebendo esse pedido ARQ, comparará o número de pacotes de paridade pedidos no pedido ARQ recebido com suas próprias necessidades. Se o número de pacotes de pari- dade pedidos por outro cliente/dispositivo móvel é maior do que seu próprio pedido, o clien- te/dispositivo móvel suprimirá seu próprio pedido ARQ e esperará obter a multitransmissão que terá mais pacotes de paridade do que ele precisa.

Na segunda modalidade, o cliente/dispositivo móvel primeiro adere a um grupo FEC atrasado adicional. Um temporizador é ajustado. O temporizador deveria expirar antes do tempo de atraso do próximo grupo FEC atrasado. Se o cliente/dispositivo móvel então de- termina que ele não pode ainda decodificar o bloco FEC, o cliente/dispositivo móvel tem tempo de aderir ao próximo grupo FEC. Por exemplo, se a latência de aderir a IGMP está entre vários a aproximadamente 50 ms, o tempo de expiração do temporizador é especifica- do como Tx = 100 ms antes do próximo tempo de atraso do grupo FEC: temporízador_expira(i) = tempo_atual + atraso (i+1) - Tx (3) onde Tx é um parâmetro configurável. Novamente, se o grupo FEC já foi aderido, o cliente/dispositivo móvel precisa somente atualizar o tempo de expiração do grupo, mas o temporizador ainda em que ser ajustado. Quando o cliente/dispositivo móvel aderiu ao últi- mo grupo FEC adaptativo, mas ainda não pode decodificar o bloco FEC, o cliente/dispositivo móvel terá que enviar um pedido ARQ.

Em alguns cenários, se o número de pacotes de mídia perdidos em um bloco FEC exceder um limite (por exemplo, 50% de K), pode não ser eficaz enviar um ARQ para pedir somente pacotes de paridade. Nesse caso, o cliente/dispositivo móvel pode enviar um ARQ para pedir a retransmissão dos pacotes de mídia originais. Se o cliente/dispositivo móvel recebeu suficiente pacotes/símbolos para decodificar o bloco FEC ou se o cliente/dispositivo móvel precisa de menos símbolos de paridade do que o fornecido pelos grupos FEC que ele aderiu, então o cliente/dispositivo móvel precisa verificar se ele deveria deixar (abandonar) um ou mais grupos de multitransmissão FEC. A Equação (1) fornece o número de grupos FEC que um cliente/dispositivo móvel deveria ade- rir, se o número de grupo atualmente aderido I é maior que g, então o cliente/dispositivo mó- vel deveria deixar o grupo (g+1) para o grupo (I). Para reduzir o número de aderências e abandonos, outro parâmetro é introduzido. Faz-se

h = min (j·. 2obrecarga{i) > taxaj?erda_média} (4)

e t = Max(g, h), se I > t, então o cliente/dispositivo móvel deixa o grupo (t+1) para o

grupo(l).

A FIG. 6 é um diagrama de bloco/esquemático do lado do servidor do método ARQ híbrido combinado da presente invenção. Especificamente, a FIG. 6 representa um servidor de transmissão contínua 105 e um servidor ARQ 160 da presente invenção. Como indicado acima, o servidor de transmissão contínua e o servidor ARQ podem ser localizados em dife- rentes máquinas ou colocalizados em uma máquina. O servidor de transmissão continua 105 recebe conteúdo do servidor de conteúdo 105 e/ou servidor de conteúdo ao vivo 110 na forma de pacotes RTP de conteúdo (mídia). O módulo FC 605 aloca esses pacotes de mídia em um bloco FEC e pacotes FEC/paridade são gerados e adicionados no bloco FEC tal que há k pacotes de mídia e n-k pacotes FEC/paridade em um bloco FEC. Os pacotes FEC/paridade são separados em camadas representando FEC/paridade crescente do que pode ser pedido e usado por um cliente/dispositivo móvel no evento em que o bloco FEC (incluindo os pacotes de mídia e FEC não atrasados) foi insuficiente para recuperar o conte- údo. O cliente/dispositivo móvel pede FEC adicional aderindo aos grupos de multitransmis- são que fornecem o FEC adicional. O FEC adicional é armazenado em um armazenador de atraso 610 no evento em que ele é necessário. Todos os dados (mídia, FEC não atrasado, e FEC atrasado) são encaminhados a um cliente/dispositivo móvel via a pilha de protocolo UDP/IP/Ethernet 615.

O conteúdo (pacotes de mídia) é encaminhado ao servidor ARQ 160 pelo servidor de transmissão contínua 115. O servidor de transmissão contínua 115 também encaminha os pacotes FEC no grupo ARQ FEC ao servidor ARQ 160. Ambos os pacotes ARQ FEC e de conteúdo são encaminhados via a pilha de protocolo UDP/IP/Ethernet 620 ao módulo de processo ARQ híbrido 625. Quando um cliente/terminal móvel envia um pedido de NACK para retransmissão de pacotes FEC ou pacotes de conteúdo, ele adere a um grupo de multi- transmissão de retransmissão ARQ de modo a receber a retransmissão de pacotes FEC ou pacotes de conteúdo. Há vários tipos de pedidos NACK/ARQ. Em um tipo de pedido NACK/ARQ, um cliente/dispositivo móvel pede o número de pacotes FEC que ele precisa. Em outro tipo de pedido NACK/ARQ, um cliente/dispositivo móvel pede que o servidor ARQ retransmita pacotes de conteúdo específicos. Nesse caso, o pedido NACK/ARQ inclui o nú- mero de seqüência dos pacotes de conteúdo que o cliente/dispositivo móvel precisa. Um terceiro tipo de pedido NACK/ARQ é a combinação dos dois pedidos NACK/ARQ acima. No terceiro caso, um cliente/dispositivo móvel pede um certo número de pacotes FEC e alguns pacotes de conteúdo. Quando um NACK é recebido a partir de um cliente/terminal móvel, a retransmissão do conteúdo original ou os pacotes FEC do grupo ARQ é processada pelo módulo de processo ARQ híbrido 625 e transmitida pela pilha de protocolo UDP/IP/Ethernet 620.

Entende-se que a presente invenção pode ser implementada em várias formas de hardware, software, suporte lógico inalterado, processadores de propósito especial, ou uma combinação desses. Preferencialmente, a presente invenção é implementada como uma combinação de hardware e software. Ademais, o software é preferencialmente implementa- do como um programa aplicativo incorporado em um dispositivo de armazenamento de pro- grama. O programa aplicativo pode ser carregado e executado por uma máquina compreen- dendo qualquer arquitetura adequada. Preferencialmente, a máquina é implementada em uma plataforma de computador tendo hardware tal como uma ou mais unidades de proces- samento central (CPU), uma memória de acesso aleatório (RAM), e interface(s) de entra- da/saída (l/O). A plataforma de computador também inclui um sistema operacional e código de microinstrução. Os vários processos e funções descritos aqui podem ou ser parte do có- digo de microinstrução ou parte do programa aplicativo (ou uma combinação desses), que é executado via o sistema operacional. Em adição, vários outros dispositivos periféricos po- dem ser conectados à plataforma de computador tal como um dispositivo de armazenamen- to adicional e um dispositivo de impressão.

Entende-se ademais que, porque alguns dos componentes de sistema constituinte e etapas de método representadas nas figuras em anexo são preferencialmente implemen- tados em software, as conexões reais entre os componentes de sistema (ou as etapas de processo) podem diferir dependendo da maneira na qual a presente invenção é programa- da. Dados os ensinamentos aqui fornecidos, um dos versados na técnica relacionada será capaz de observar essas e implementações ou configurações similares da presente inven-

Claims (42)

1. Método para aumentar a confiabilidade de multitransmissão, CARACTERIZADO pelo fato de que compreende: gerar uma pluralidade de camadas de pacotes codificados de correção de erro de encaminhamento; receber um pedido para aderir a um primeiro grupo de multitransmissão de modo a receber conteúdo e a dita primeira camada da dita pluralidade de camadas de pacotes codi- ficados de correção de erro de encaminhamento; transmitir o dito conteúdo e uma primeira camada da dita pluralidade dos ditos pa- cotes codificados de correção de erro de encaminhamento; receber um pedido para aderir a um segundo grupo de multitransmissão de modo a receber a dita segunda camada da dita pluralidade de camadas de pacotes codificados de correção de erro de encaminhamento se o dito conteúdo não foi recuperável a partir do dito conteúdo e a dita primeira camada de uma pluralidade dos ditos pacotes codificados de cor- reção de erro de encaminhamento a partir do dito primeiro grupo de multitransmissão; e transmitir uma segunda camada da dita pluralidade dos ditos pacotes codificados de correção de erro de encaminhamento mediante recebimento do pedido, onde a dita transmissão da segunda camada da dita pluralidade de pacotes codificados de correção de erro de encaminhamento é atrasada.

2. Método, de acordo com a reivindicação 1, CARACTERIZADO adicionalmente pelo fato de que compreende: transmitir uma terceira camada da dita pluralidade de pacotes codificados de corre- ção de erro de encaminhamento mediante recebimento de um terceiro pedido; e retransmitir o dito conteúdo e uma quarta camada da dita pluralidade dos ditos pa- cotes codificados de correção de erro de encaminhamento, mediante recebimento de um quarto pedido.

3. Método, de acordo com a reivindicação 1, CARACTERIZADO adicionalmente pelo fato de que compreende receber um pedido para aderir a um terceiro grupo de multi- transmissão de modo a receber a dita terceira camada da dita pluralidade de camadas de pacotes codificados de correção de erro de encaminhamento se o dito conteúdo não foi re- cuperável a partir do dito conteúdo recebido, da dita primeira camada da dita pluralidade dos ditos pacotes codificados de correção de erro de encaminhamento e da dita segunda cama- da da dita pluralidade de pacotes codificados de correção de erro de encaminhamento, onde a dita transmissão da dita terceira camada da dita pluralidade dos ditos pacotes codificados de correção de erro de encaminhamento é atrasada.

4. Método, de acordo com a reivindicação 1, CARACTERIZADO adicionalmente pelo fato de que compreende receber um reconhecimento negativo de pedido de repetição automática e receber um pedido para aderir a um quarto grupo de multitransmissão de mo- do a receber conteúdo perdido de retransmissão e uma quarta camada da dita pluralidade de camadas de pacotes codificados de correção de erro de encaminhamento se o dito con- teúdo não foi recuperável a partir do dito conteúdo recebido, da dita primeira camada da dita pluralidade dos ditos pacotes codificados de correção de erro de encaminhamento, da dita segunda camada da dita pluralidade de pacotes codificados de correção de erro de encami- nhamento e da dita terceira camada da dita pluralidade de pacotes codificados de correção de erro de encaminhamento, onde a dita transmissão da retransmissão do dito conteúdo perdido e da dita quarta camada da dita pluralidade dos ditos pacotes codificados de corre- ção de erro de encaminhamento é atrasada.

5. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que a dita retransmissão do dito conteúdo perdido e da dita quarta camada da dita pluralidade dos ditos pacotes codificados de correção de erro de encaminhamento são retransmitidos por um servidor de pedido de repetição automática.

6. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que a dita segunda camada da dita pluralidade dos ditos pacotes codificados de correção de erro de encaminhamento é transmitida por um servidor de transmissão contínua.

7. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que a dita segunda camada da dita pluralidade dos ditos pacotes de correção de erro de encami- nhamento é atrasada no tempo por um período de tempo configurável.

8. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que uma quantidade de codificação de correção de erro de encaminhamento aplicada a cada uma da dita pluralidade de camadas é configurável.

9. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que o dito conteúdo inclui múltiplas trilhas de mídia.

10. Sistema para aumentar a confiabilidade de multitransmissão, CARACTERIZADO pelo fato de que compreende: dispositivo para gerar uma pluralidade de camadas de pacotes codificados de cor- reção de erro de encaminhamento; dispositivo para receber um pedido para aderir a um primeiro grupo de multitrans- missão de modo a receber conteúdo e a dita primeira camada da dita pluralidade de cama- das de pacotes codificados de correção de erro de encaminhamento; dispositivo para transmitir o dito conteúdo e uma primeira camada da dita pluralida- de dos ditos pacotes codificados de correção de erro de encaminhamento; dispositivo para receber um pedido para aderir a um segundo grupo de multitrans- missão de modo a receber a dita segunda camada da dita pluralidade de camadas de paco- tes codificados de correção de erro de encaminhamento se o dito conteúdo não foi recupe- rável a partir do dito conteúdo e a dita primeira camada de uma pluralidade dos ditos paco- tes codificados de correção de erro de encaminhamento a partir do dito primeiro grupo de multitransmissão; e dispositivo para transmitir uma segunda camada da dita pluralidade dos ditos paco- tes codificados de correção de erro de encaminhamento mediante recebimento do pedido, onde a dita transmissão da segunda camada da dita pluralidade de pacotes codificados de correção de erro de encaminhamento é atrasada.

11. Sistema, de acordo com a reivindicação 10, CARACTERIZADO pelo fato de compreende: dispositivo para transmitir uma terceira camada da dita pluralidade de pacotes codi- ficados de correção de erro de encaminhamento mediante recebimento de um terceiro pedi- do; e dispositivo para retransmitir o dito conteúdo e uma quarta camada da dita pluralida- de dos ditos pacotes codificados de correção de erro de encaminhamento, mediante rece- bimento de um quarto pedido.

12. Sistema, de acordo com a reivindicação 10, CARACTERIZADO adicionalmente pelo fato de que compreende dispositivo para receber um pedido para aderir a um terceiro grupo de multitransmissão de modo a receber a dita terceira camada da dita pluralidade de camadas de pacotes codificados de correção de erro de encaminhamento se o dito conteú- do não foi recuperável a partir do dito conteúdo recebido, da dita primeira camada da dita pluralidade dos ditos pacotes codificados de correção de erro de encaminhamento e da dita segunda camada da dita pluralidade de pacotes codificados de correção de erro de encami- nhamento, onde a dita transmissão da dita terceira camada da dita pluralidade dos ditos pacotes codificados de correção de erro de encaminhamento é atrasada.

13. Sistema, de acordo com a reivindicação 10, CARACTERIZADO adicionalmente pelo fato de que compreende dispositivo para receber um reconhecimento negativo de pedi- do de repetição automática e receber um pedido para aderir a um quarto grupo de multi- transmissão de modo a receber conteúdo perdido de retransmissão e uma quarta camada da dita pluralidade de camadas de pacotes codificados de correção de erro de encaminha- mento se o dito conteúdo não foi recuperável a partir do dito conteúdo recebido, da dita pri- meira camada da dita pluralidade dos ditos pacotes codificados de correção de erro de en- caminhamento, da dita segunda camada da dita pluralidade de pacotes codificados de cor- reção de erro de encaminhamento e da dita terceira camada da dita pluralidade de pacotes codificados de correção de erro de encaminhamento, onde a dita transmissão da retrans- missão do dito conteúdo perdido e da dita quarta camada da dita pluralidade dos ditos paco- tes codificados de correção de erro de encaminhamento é atrasada.

14. Sistema, de acordo com a reivindicação 10, CARACTERIZADO adicionalmente pelo fato de que o dito conteúdo e a dita quarta camada da dita pluralidade dos ditos paco- tes codificados de correção de erro de encaminhamento são retransmitidos por um servidor de pedido de repetição automática.

15. Sistema, de acordo com a reivindicação 10, CARACTERIZADO pelo fato de que a dita segunda camada da dita pluralidade dos ditos pacotes codificados de correção de erro de encaminhamento é transmitida por um servidor de transmissão contínua.

16. Sistema, de acordo com a reivindicação 10, CARACTERIZADO pelo fato de que cada um da dita segunda camada da dita pluralidade dos pacotes codificados de corre- ção de erro de encaminhamento é atrasada no tempo por um período de tempo configurá- vel.

17. Sistema, de acordo com a reivindicação 10, CARACTERIZADO pelo fato de que uma quantidade da dita codificação de correção de erro de encaminhamento aplicada em cada uma da dita pluralidade de camadas é configurável.

18. Sistema, de acordo com a reivindicação 10, CARACTERIZADO pelo fato de que o dito conteúdo inclui múltiplas trilhas de mídia.

19. Método para aumentar a confiabilidade de multitransmissão, CARACTERIZADO pelo fato de que compreende: receber conteúdo e uma primeira camada de uma pluralidade de pacotes codifica- dos de correção de erro de encaminhamento a partir de um primeiro grupo de multitransmis- são; e aderir a um grupo de multitransmissão adicional de modo a receber uma das cama- das adicionais de pacotes codificados de correção de erro de encaminhamento e o dito con- teúdo junto com uma camada adicional da dita pluralidade de pacotes codificados de corre- ção de erro de encaminhamento.

20. Método, de acordo com a reivindicação 19, CARACTERIZADO pelo fato de que o dito ato de aderir é executado se o dito conteúdo não foi recuperável a partir do dito con- teúdo e a dita primeira camada de uma pluralidade dos ditos pacotes codificados de corre- ção de erro de encaminhamento a partir de um primeiro grupo de multitransmissão.

21. Método, de acordo com a reivindicação 19, CARACTERIZADO adicionalmente pelo fato de que compreende aderir ao dito primeiro grupo de multitransmissão de modo a receber o dito conteúdo e a dita primeira camada da dita pluralidade dos ditos pacotes codi- ficados de correção de erro de encaminhamento.

22. Método, de acordo com a reivindicação 20, CARACTERIZADO pelo fato de que aderir a um segundo grupo de multitransmissão de modo a receber uma segunda camada da dita pluralidade dos ditos pacotes codificados de correção de erro de encaminhamento é executado, se o dito conteúdo não foi recuperável a partir do dito conteúdo recebido e da dita primeira camada da dita pluralidade dos ditos pacotes codificados de correção de erro de encaminhamento.

23. Método, de acordo com a reivindicação 20, CARACTERIZADO pelo fato de que aderir a um terceiro grupo de multitransmissão de modo a receber uma terceira camada da dita pluralidade dos ditos pacotes codificados de correção de erro de encaminhamento é executado, se o dito conteúdo não foi recuperável a partir do dito conteúdo recebido, da dita primeira camada da dita pluralidade dos ditos pacotes codificados de correção de erro de encaminhamento e da dita segunda camada da dita pluralidade de pacotes codificados de correção de erro de encaminhamento.

24. Método, de acordo com a reivindicação 20, CARACTERIZADO pelo fato de que aderir a um quarto grupo de multitransmissão de modo a receber conteúdo perdido e uma quarta camada da dita pluralidade dos ditos pacotes codificados de correção de erro de en- caminhamento é executado, se o dito conteúdo não foi recuperável a partir do dito conteúdo recebido, da dita primeira camada da dita pluralidade dos ditos pacotes codificados de cor- reção de erro de encaminhamento, da dita segunda camada da dita pluralidade de pacotes codificados de correção de erro de encaminhamento e da dita terceira camada da dita plura- lidade de pacotes codificados de correção de erro de encaminhamento.

25. Método, de acordo com a reivindicação 19, CARACTERIZADO pelo fato de que uma primeira das ditas camadas adicionais da dita pluralidade de pacotes codificados de correção de erro de encaminhamento é recebida atrasada no tempo por um período de tem- po configurável e ademais onde o dito período de tempo configurável é maior do que um período de tempo necessário para aderir ao dito grupo de multitransmissão adicional.

26. Método, de acordo com a reivindicação 24, CARACTERIZADO pelo fato de que uma decisão de aderir ao dito quarto grupo é feita se um número de pacotes de conteúdo perdidos excede um limite e adicionalmente compreende transmitir um reconhecimento ne- gativo de pedido de repetição automática.

27. Método, de acordo com a reivindicação 19, CARACTERIZADO adicionalmente pelo fato de que compreende encaminhar conteúdo recuperado a um dispositivo de repro- dução.

28. Método, de acordo com a reivindicação 19, CARACTERIZADO pelo fato de que as ditas ações são executadas por um módulo proxy cliente.

29. Método, de acordo com a reivindicação 19, CARACTERIZADO pelo fato de que uma pluralidade de grupos de multitransmissão adicionais é aderida ao mesmo tempo.

30. Método, de acordo com a reivindicação 19, CARACTERIZADO pelo fato de que o dito conteúdo inclui múltiplas trilhas de mídia.

31. Aparelho para aumentar a confiabilidade da multitransmissão, CARACTERIZADO pelo fato de que compreende: dispositivo para receber conteúdo e uma primeira camada de uma pluralidade de pacotes codificados de correção de erro de encaminhamento a partir de um primeiro grupo de multitransmissão; e dispositivo para aderir a um grupo de multitransmissão adicional de modo a receber uma das camadas adicionais de pacotes codificados de correção de erro de encaminhamen- to e o dito conteúdo junto com uma camada adicional da dita pluralidade de pacotes codifi- cados de correção de erro de encaminhamento.

32. Aparelho, de acordo com a reivindicação 31, CARACTERIZADO adicionalmen- te pelo fato de que compreende dispositivo para aderir ao dito primeiro grupo de multitrans- missão para receber o dito conteúdo e a dita primeira camada da dita pluralidade dos ditos pacotes codificados de correção de erro de encaminhamento.

33. Aparelho, de acordo com a reivindicação 31, CARACTERIZADO pelo fato de que o dispositivo para aderir a um segundo grupo de multitransmissão de modo a receber uma segunda camada da dita pluralidade dos ditos pacotes codificados de correção de erro de encaminhamento é ativado, se o dito conteúdo não foi recuperável a partir do dito conte- údo recebido e da dita primeira camada da dita pluralidade dos ditos pacotes codificados de correção de erro de encaminhamento.

34. Aparelho, de acordo com a reivindicação 31, CARACTERIZADO pelo fato de que o dispositivo para aderir a um terceiro grupo de multitransmissão de modo a receber uma terceira camada da dita pluralidade dos ditos pacotes codificados de correção de erro de encaminhamento é ativado, se o dito conteúdo não foi recuperável a partir do dito conte- údo recebido, da dita primeira camada da dita pluralidade dos ditos pacotes codificados de correção de erro de encaminhamento e da dita segunda camada da dita pluralidade dos pacotes codificados de correção de erro de encaminhamento.

35. Aparelho, de acordo com a reivindicação 31, CARACTERIZADO pelo fato de que o dispositivo para aderir a um quarto grupo de multitransmissão de modo a receber no- vamente o dito conteúdo e uma quarta camada da dita pluralidade dos ditos pacotes codifi- cados de correção de erro de encaminhamento é ativado, se o dito conteúdo não foi recupe- rável a partir do dito conteúdo recebido, da dita primeira camada da dita pluralidade dos di- tos pacotes codificados de correção de erro de encaminhamento, da dita segunda camada da dita pluralidade dos pacotes codificados de correção de erro de encaminhamento e da terceira camada da dita pluralidade de pacotes codificados de correção de erro de encami- nhamento.

36. Aparelho, de acordo com a reivindicação 31, CARACTERIZADO pelo fato de que uma primeira das ditas camadas adicionais da dita pluralidade de pacotes codificados de correção de erro de encaminhamento é recebida atrasada no tempo por um período de tempo configurável e ademais onde o dito período de tempo configurável é maior do que um período de tempo necessário para aderir ao dito grupo de multitransmissão adicional.

37. Aparelho, de acordo com a reivindicação 36, CARACTERIZADO pelo fato de que uma decisão de aderir ao dito quarto grupo é feita se um número de pacotes de conteú- do perdidos excede um limite e adicionalmente compreende dispositivo para transmitir um reconhecimento negativo de pedido de repetição automática.

38. Aparelho, de acordo com a reivindicação 31, CARACTERIZADO adicionalmen- te pelo fato de que compreende dispositivo para encaminhar conteúdo recuperado a um dispositivo de reprodução.

39. Aparelho, de acordo com a reivindicação 31, CARACTERIZADO pelo fato de que compreende um módulo proxy cliente.

40. Aparelho, de acordo com a reivindicação 31, CARACTERIZADO pelo fato de que uma pluralidade de grupos de multitransmissão adicionais é aderida ao mesmo tempo.

41. Aparelho, de acordo com a reivindicação 31, CARACTERIZADO pelo fato de que o dito conteúdo inclui múltiplas trilhas de mídia.

42. Aparelho, de acordo com a reivindicação 31, CARACTERIZADO pelo fato de que o dito dispositivo para aderir é executado se o dito conteúdo não foi recuperável a partir do dito conteúdo e da dita primeira camada de uma pluralidade dos ditos pacotes codifica- dos de correção de erro de encaminhamento a partir de um primeiro grupo de multitransmis-