BRPI0722125B1

BRPI0722125B1 - Método, sistema 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

Info

Publication number: BRPI0722125B1
Application number: BRPI0722125-8A
Authority: BR
Inventors: Mingquan Wu; Hang Liu
Original assignee: Interdigital Ce Patent Holdings
Priority date: 2007-10-23
Filing date: 2007-10-23
Publication date: 2020-03-03
Also published as: US20100260180A1; KR20100070361A; CN101861709A; CN101861709B; KR20140098259A; BRPI0722125A2; JP5591708B2; US8499212B2; KR101571145B1; WO2009054822A1; JP2011501613A

Abstract

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 a presente invenção refere-se a um método e um aparelho para aumentar a confiabilidade da multitransmissão, incluindo 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 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.

Description

“MÉTODO, SISTEMA 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 usados aqui de forma intercambiável. Como usado aqui, “l” denota nomes alternativos para os mesmos componentes ou estruturas ou similares. Isto é, um “l” pode ser obtido como significado de “ou” como usado aqui.

As redes de área local sem fio (WLANs), por causa de sua flexibilidade e baixo custo, foram usadas extensivamente em residências, hotéis, em campi e outros pontos de acesso, 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últiplos 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 FED, 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 pacotes/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étodo 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 cliente/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 algoritmo 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.

Petição 870190087188, de 05/09/2019, pág. 6/36

2/18

FEC é uma forma eficaz de otimizar a confiabilidade para aplicativos de multitransmissã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 entrelaç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 operação XOR, mas sua capacidade de correção de erro é correspondentemente limitada. ProMPEG 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 possivelmente 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 aplicativo 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 qualidade do serviço em redes sem fio. Entretanto, esquemas da técnica anterior não consideraram retransmissão de ARQ. Se a perda de pacote para um receptor é mais do que a capacidade do código FEC, os pacotes perdidos não podem ser recuperados. Ademais, um receptor 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 camadas 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 nas 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 N e K não são fixos para diferentes blocos FEC, N e K precisam ser incluídos

Petição 870190087188, de 05/09/2019, pág. 7/36

3/18 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 anterior, 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 sequência dos pacotes 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 diferentes clientes/dispositivos móveis para recuperar diferentes perdas.

Diferentes cenários podem usar diferentes esquemas de correção de erro. Em alguns casos, FEC pode ser mais eficaz enquanto em outros casos, ARQ pode ser uma escolha 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 confiabilidade 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 transmissã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 combinado, 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 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.

Um método e um aparelho são descritos para aumentar a confiabilidade da multitransmissão, incluindo receber conteúdo e uma primeira camada de uma pluralidade de pacotes codificados de correção de erro de encaminhamento de um primeiro grupo de multitransmissã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

Petição 870190087188, de 05/09/2019, pág. 8/36

4/18 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 encaminhamento, 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 recebimento 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 encaminhamento, mediante recebimento de um pedido de conteúdo de pedido de repetição automática.

Dever-se-ia notar que cada uma das camadas dos pacotes FEC poderia ser múltiplos 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 segunda 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 aplicativos 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 processamento 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 alguns casos, FEC pode ser mais eficaz enquanto em outros casos, ARQ pode ser uma mePetição 870190087188, de 05/09/2019, pág. 9/36

5/18 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 confiabilidade 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 transmissã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 capacidade 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 servidor ARQ e o servidor de transmissão contínua podem ser colocalizados em um aparelho/máquina/dispositivo. Um cliente/dispositivo móvel adere a um grupo ARQ FEC via IGMP,

Petição 870190087188, de 05/09/2019, pág. 10/36

6/18 se pacotes FEC atrasados não foram suficientes para recuperar os pacotes/dados perdidos/danificados.

Os pacotes FEC para um fluxo de conteúdo/fonte/vídeo/áudio são divididos em diferentes 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 gerados. 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 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 Gerenciamento 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 suficientes 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 correspondentes serão recebidos para recuperar os pacotes perdidos de conteúdo/dados pelo cliente/dispositivo móvel. Para economizar largura de banda sem fio, os dados FEC atrasados 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 esse 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 pacotes 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á muitos 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 deslocamento 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 configurados.

Petição 870190087188, de 05/09/2019, pág. 11/36

7/18

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 manter 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 multitransmissão FEC, envia NACKs ARQ ao servidor ARQ, recebe pacotes de mídia e FEC retransmitidos, 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, Fonte/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 separados e entram no módulo Proxy cliente FEC 330 da presente invenção. O conteúdo recuperado 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 qualquer 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 dispositivo de exibição 355.

No lado do servidor de conteúdo, antes da operação de codificação FEC é executada, 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 codificação FEC é executada em cada trilha respectivamente. Diferentes trilhas de mídia têm diferentes 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 armazenador 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; 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 é

Petição 870190087188, de 05/09/2019, pág. 12/36

8/18 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 projeto. 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 variante 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 pacotes 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 armazenamento 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 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 N e K variantes pode resolver o problema de 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 N e K 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 geração é criada com base em maxK e maxN, e é inicializada somente uma vez em ambos o 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 encurtados/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 retransmissã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 perdidos/danificados a partir dos pacotes de paridade (FEC) e enviará os pacotes de mídia recuperados 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

Petição 870190087188, de 05/09/2019, pág. 13/36

9/18 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 processo 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 grupo de multitransmissão. O processo principal também executará estimativa de canal, processamento FEC adaptativo e decodificação FEC. O processamento ARQ e o encaminhamento 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 armazenador 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 cliente/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 principal. 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 dados (por exemplo, lista vinculada) de acordo com seu número de sequência base. O número de sequência base de um bloco FEC é o menor número de sequê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 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 restaura 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 decodificação FEC. Se o bloco FEC não foi decodificável, então o algoritmo FEC adaptativo é convocado em 495. Isto é, o Proxy cliente adere a um grupo de multitransmissão FEC atrasado

Petição 870190087188, de 05/09/2019, pág. 14/36

10/18 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 é inserido 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 enviados à tela, a estrutura de bloco FEC é apagada e a memória é liberada. O FEC adaptativo é então ativado em 491 para decidir se o cliente recebeu pacotes de paridade desnecessá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 para determinar se o pacote recebido é um pacote de mídia. Se o pacote recebido é um pacote 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 sequência. 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 sequência do pacote de mídia, no número de sequê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. O processamento então prossegue para 485.

É também possível que os pacotes de paridade para um certo bloco FEC sejam totalmente 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 pertencem 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 pacotes de mídia são perdidos/danificados (bloco FEC não é decodificável). O cliente/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.

Petição 870190087188, de 05/09/2019, pág. 15/36

11/18

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 RTCP, então este é processado em 480. Os pacotes RTCP recebidos são inseridos no armazenador fonte de acordo com o tempo em que eles foram recebidos desde que números de sequência nos pacotes RTCP não são atribuídos de acordo com os pacotes RTP. O processamento 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 armazenador 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 manipulado. 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 reprodutor 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 armazenador 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 temPetição 870190087188, de 05/09/2019, pág. 16/36

12/18 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 cliente/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últiplos 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 paridade/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 cliente/dispositivo móvel é capaz de localizar essa estrutura de bloco FEC a partir da lista vinculada com base no número de sequência do pacote de mídia, no número de sequê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 vinculada) de acordo com o número de sequência como mostrado em 505a, 505b, ..., 505α+1. Se a estrutura de dados de bloco FEC a qual o pacote de mídia recebido pertence não foi alocada 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 N e K 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 sequê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 armazenador fonte correspondente (por exemplo, lista vinculada). Os números de sequência

Petição 870190087188, de 05/09/2019, pág. 17/36

13/18 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 pacotes 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 armazenador 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 sequência base, N e K, etc.

Quando um cliente/dispositivo móvel recebe um pacote de paridade (FEC), o cliente/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 de bloco não foi ainda alocada, então uma estrutura de dados de bloco é alocada. Uma estrutura de dados de bloco FEC é inserida na estrutura de dados (por exemplo, lista vinculada) de acordo com seu número de sequência base como mostrado em 510a, 510b, ..., 510β+1. O número de sequência base de um bloco FEC é o menor número de sequência dos pacotes de mídia que pertencem a 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 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 decodificação FEC (485 e 490 da FIG. 4B). Subsequentemente, se um pacote de mídia ou um pacote FEC é recebido para esse bloco FEC, a informação desse bloco é atualizada correspondentemente.

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 sequência do pacote de mídia, no número de sequê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 armazenador de decodificação que é usado para armazenar pacotes FEC para esse bloco. Um armazenador de memória, que é exigido para executar decodificação FEC, é também alocado no armazenador de decodificação.

Petição 870190087188, de 05/09/2019, pág. 18/36

14/18

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 totalmente 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-(o + 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 ativará 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 mostrado 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 decodificar um bloco FEC. Se o cliente/dispositivo móvel não recebeu e de decodificou o pacote 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 grupo_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 áudio 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 sessã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 pode 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

Petição 870190087188, de 05/09/2019, pág. 19/36

15/18

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 (i). 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:

k =________”________

14·

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 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 atualizar 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 cliente/dispositivo móvel não tem que aderir a quaisquer novos grupos FEC ou enviar um pedido ARQ. Entretanto, se o cliente/dispositivo móvel aderiu a mais grupos FEC, então o cliente/dispositivo móvel pode receber símbolos/pacotes de paridade redundantes. Isto é, o cliente/dispositivo móvel pode receber mais pacotes de paridade/símbolos do que o cliente/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 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 modalidade é aderir a um grupo FEC adicional primeiro. Após algum atraso, o cliente/dispositivo móvel então verifica para determinar se recebeu suficientes pacotes/símbolos 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) + α * 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 paridaPetição 870190087188, de 05/09/2019, pág. 20/36

16/18 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:

S = min 0: cficfa) / S ffi - 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 cliente/dispositivo móvel adere a todos os grupos FEC adaptativos, mas ainda não pode decodificar 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) * T_s e (K - msg_perdida + 1) * T_s. 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 paridade pedidos por outro cliente/dispositivo móvel é maior do que seu próprio pedido, o cliente/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 determina 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 é especificado como Tx = 100 ms antes do próximo tempo de atraso do grupo FEC:

temporizador_expira(i) = tempo_atual + atraso (i+1) - T_x (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 último 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

Petição 870190087188, de 05/09/2019, pág. 21/36

17/18 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 aderir, 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 ft = min Çí: percftt méefÍÉSt) (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 diferentes 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 multitransmissã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 multitransmissã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

Petição 870190087188, de 05/09/2019, pág. 22/36

18/18

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 sequê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 implementado como um programa aplicativo incorporado em um dispositivo de armazenamento de programa. O programa aplicativo pode ser carregado e executado por uma máquina compreendendo qualquer arquitetura adequada. Preferencialmente, a máquina é implementada em uma plataforma de computador tendo hardware tal como uma ou mais unidades de processamento central (CPU), uma memória de acesso aleatório (RAM), e interface(s) de entrada/saída (I/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 podem ser conectados à plataforma de computador tal como um dispositivo de armazenamento 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 implementados 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 é programada. 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ção.

Claims

REIVINDICAÇÕES

1. Método para aumentar a confiabilidade de multitransmissão, compreendendo:

gerar (105, 110) uma pluralidade de camadas de pacotes codificados de correção de erro de encaminhamento;

receber (115) um pedido para aderir a um primeiro grupo de multitransmissão de modo a receber conteúdo e a primeira camada da pluralidade de camadas de pacotes codificados de correção de erro de encaminhamento; e transmitir (115) o conteúdo e uma primeira camada da pluralidade dos pacotes codificados de correção de erro de encaminhamento,

CARACTERIZADO pelo fato de compreender adicionalmente:

receber (115) um pedido para aderir a um segundo grupo de multitransmissão de modo a receber a segunda camada da pluralidade de camadas de pacotes codificados de correção de erro de encaminhamento se o conteúdo não foi recuperável a partir do conteúdo e a primeira camada de uma pluralidade dos pacotes codificados de correção de erro de encaminhamento a partir do primeiro grupo de multitransmissão; e transmitir (115) uma segunda camada da pluralidade dos pacotes codificados de correção de erro de encaminhamento mediante recebimento do pedido, onde a transmissão da segunda camada da pluralidade dos pacotes codificados de correção de erro de encaminhamento é atrasada.
2. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que compreende adicionalmente:

transmitir uma terceira camada da pluralidade dos pacotes codificados de correção de erro de encaminhamento mediante recebimento de um terceiro pedido; e retransmitir o conteúdo e uma quarta camada da pluralidade dos pacotes 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 pelo fato de que compreende adicionalmente receber um pedido para aderir a um terceiro grupo de multitransmissão de modo a receber a terceira camada da pluralidade de camadas de pacotes codificados de correção de erro de encaminhamento se o conteúdo não foi recuperável a partir do conteúdo recebido, da primeira camada da pluralidade dos pacotes codificados de correção de erro de encaminhamento e da segunda camada da pluralidade de pacotes codificados de correção de erro de encaminhamento, onde a transmissão da terceira camada da pluralidade dos pacotes codificados de correção de erro de encaminhamento é atrasada.
4. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que compreende adicionalmente receber um reconhecimento negativo de pedido de repetição automática e um pedido para aderir a um quarto grupo de multitransmissão de modo a receber conteúdo perdido de retransmissão e uma quarta camada da pluralidade de camadas de

Petição 870190087188, de 05/09/2019, pág. 24/36

2/7 pacotes codificados de correção de erro de encaminhamento se o conteúdo não foi recuperável a partir do conteúdo recebido, da primeira camada da pluralidade dos pacotes codificados de correção de erro de encaminhamento, da segunda camada da pluralidade de pacotes codificados de correção de erro de encaminhamento e da terceira camada da pluralidade de pacotes codificados de correção de erro de encaminhamento, onde a transmissão da retransmissão do conteúdo perdido e da quarta camada da pluralidade de camadas de 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 retransmissão do conteúdo perdido e da quarta camada da pluralidade dos 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 segunda camada da pluralidade dos 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 segunda camada da pluralidade dos pacotes codificados de correção de erro de encaminhamento é 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 pluralidade de camadas é configurável.
9. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que o conteúdo inclui múltiplas trilhas de mídia.
10. Sistema para aumentar a confiabilidade de multitransmissão, compreendendo: dispositivo (115) para gerar uma pluralidade de camadas de pacotes codificados de correção de erro de encaminhamento;

dispositivo (115) para receber um pedido para aderir a um primeiro grupo de multitransmissão de modo a receber conteúdo e a primeira camada da pluralidade de camadas de pacotes codificados de correção de erro de encaminhamento; e dispositivo (115) para transmitir o conteúdo e uma primeira camada da pluralidade dos pacotes codificados de correção de erro de encaminhamento;

CARACTERIZADO pelo fato de que compreende adicionalmente:

dispositivo (115) para receber um pedido para aderir a um segundo grupo de multitransmissão de modo a receber a segunda camada da pluralidade de camadas de pacotes codificados de correção de erro de encaminhamento se o conteúdo não foi recuperável a partir do conteúdo e a primeira camada de uma pluralidade dos pacotes codificados de correção de erro de encaminhamento a partir do primeiro grupo de multitransmissão; e dispositivo (115) para transmitir uma segunda camada da pluralidade dos pacotes

Petição 870190087188, de 05/09/2019, pág. 25/36

3/7 codificados de correção de erro de encaminhamento mediante recebimento de um primeiro pedido, onde a transmissão da segunda camada da 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 que compreende:

dispositivo para transmitir uma terceira camada da pluralidade de pacotes codificados de correção de erro de encaminhamento mediante recebimento de uma mensagem de pedido de repetição automática; e dispositivo para retransmitir o conteúdo e uma quarta camada da pluralidade dos pacotes codificados de correção de erro de encaminhamento, mediante recebimento de um pedido de conteúdo de pedido de repetição automática.
12. Sistema, de acordo com a reivindicação 10, CARACTERIZADO pelo fato de que compreende adicionalmente dispositivo para receber um pedido para aderir a um terceiro grupo de multitransmissão de modo a receber a terceira camada da pluralidade de camadas de pacotes codificados de correção de erro de encaminhamento se o conteúdo não foi recuperável a partir do conteúdo recebido, da primeira camada da pluralidade dos pacotes codificados de correção de erro de encaminhamento e da segunda camada da pluralidade de pacotes codificados de correção de erro de encaminhamento, onde a transmissão da terceira camada da pluralidade dos pacotes codificados de correção de erro de encaminhamento é atrasada.
13. Sistema, de acordo com a reivindicação 10, CARACTERIZADO pelo fato de que compreende adicionalmente dispositivo para 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 modo a receber o conteúdo e uma quarta camada da pluralidade de camadas de pacotes codificados de correção de erro de encaminhamento se o conteúdo não foi recuperável a partir do conteúdo recebido, da primeira camada da pluralidade dos pacotes codificados de correção de erro de encaminhamento, da segunda camada da pluralidade de pacotes codificados de correção de erro de encaminhamento e da terceira camada da pluralidade de pacotes codificados de correção de erro de encaminhamento, onde a transmissão do conteúdo e da quarta camada da pluralidade de camadas de pacotes codificados de correção de erro de encaminhamento é atrasada.
14. Sistema, de acordo com a reivindicação 10, CARACTERIZADO pelo fato de que o conteúdo e a quarta camada da pluralidade dos pacotes 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 segunda camada da pluralidade dos pacotes codificados de correção de erro de en

Petição 870190087188, de 05/09/2019, pág. 26/36

4/7 caminhamento é 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 segunda camada da 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 de codificação de correção de erro de encaminhamento aplicada em cada uma da pluralidade de camadas é configurável.
18. Sistema, de acordo com a reivindicação 10, CARACTERIZADO pelo fato de que o conteúdo inclui múltiplas trilhas de mídia.
19. Método para aumentar a confiabilidade de multitransmissão, compreendendo: receber (430) 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 aderir (405, 410, 415, 420, 425) ao primeiro grupo de multitransmissão de modo a receber o conteúdo e a primeira camada da pluralidade dos pacotes codificados de correção de erro de encaminhamento,

CARACTERIZADO pelo fato de compreender adicionalmente aderir (494, 499) 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.
20. Método, de acordo com a reivindicação 19, CARACTERIZADO pelo fato de que o ato de aderir é executado se o conteúdo não foi recuperável a partir do conteúdo e da primeira camada de uma pluralidade dos 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 pelo fato de que compreende adicionalmente aderir ao primeiro grupo de multitransmissão de modo a receber o conteúdo e a primeira camada da pluralidade dos pacotes codificados de correção de erro de encaminhamento.
22. Método, de acordo com a reivindicação 21, CARACTERIZADO pelo fato de que aderir a um segundo grupo de multitransmissão de modo a receber uma segunda camada da pluralidade dos pacotes codificados de correção de erro de encaminhamento é executado, se o conteúdo não foi recuperável a partir do conteúdo recebido e da primeira camada da pluralidade dos pacotes codificados de correção de erro de encaminhamento.
23. Método, de acordo com a reivindicação 22, CARACTERIZADO pelo fato de que aderir a um terceiro grupo de multitransmissão de modo a receber uma terceira camada da pluralidade dos pacotes codificados de correção de erro de encaminhamento é executado,

Petição 870190087188, de 05/09/2019, pág. 27/36

5/7 se o conteúdo não foi recuperável a partir do conteúdo recebido, da primeira camada da pluralidade dos pacotes codificados de correção de erro de encaminhamento e da segunda camada da pluralidade de pacotes codificados de correção de erro de encaminhamento.
24. Método, de acordo com a reivindicação 23, CARACTERIZADO pelo fato de que aderir a um quarto grupo de multitransmissão de modo a receber de novo conteúdo perdido e uma outra quarta camada da pluralidade dos pacotes codificados de correção de erro de encaminhamento é executado, se o conteúdo não foi recuperável a partir do conteúdo recebido, da primeira camada da pluralidade dos pacotes codificados de correção de erro de encaminhamento, da segunda camada da pluralidade de pacotes codificados de correção de erro de encaminhamento e da terceira camada da pluralidade de pacotes codificados de correção de erro de encaminhamento.
25. Método, de acordo com a reivindicação 24, CARACTERIZADO pelo fato de que uma decisão de aderir ao quarto grupo é feita se um número de pacotes de conteúdo perdido excede um limite e adicionalmente compreende transmitir um reconhecimento negativo de pedido de repetição automática.
26. Método, de acordo com a reivindicação 19, CARACTERIZADO pelo fato de que compreende adicionalmente encaminhar conteúdo recuperado a um dispositivo de reprodução.
27. Método, de acordo com a reivindicação 19, CARACTERIZADO pelo fato de que as ações são executadas por um módulo proxy cliente.
28. 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.
29. Método, de acordo com a reivindicação 19, CARACTERIZADO pelo fato de que o conteúdo inclui múltiplas trilhas de mídia.
30. Aparelho para aumentar a confiabilidade de multitransmissão, compreendendo: dispositivo (305) 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 (330) para aderir ao primeiro grupo de multitransmissão de modo a receber o conteúdo e a primeira camada da pluralidade dos pacotes codificados de correção de erro de encaminhamento,

CARACTERIZADO pelo fato de compreender adicionalmente:

dispositivo (330) 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 encaminhamento e o conteúdo junto com uma camada adicional da pluralidade de pacotes codificados de correção de erro de encaminhamento.
31. Aparelho, de acordo com a reivindicação 30, CARACTERIZADO pelo fato de

Petição 870190087188, de 05/09/2019, pág. 28/36

6/7 que compreende adicionalmente dispositivo para aderir ao primeiro grupo de multitransmissão para receber o conteúdo e a primeira camada da pluralidade dos pacotes codificados de correção de erro de encaminhamento.
32. 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 pluralidade dos pacotes codificados de correção de erro de encaminhamento é ativado, se o conteúdo não foi recuperável a partir do conteúdo recebido e da primeira camada da pluralidade dos pacotes codificados de correção de erro de encaminhamento.
33. Aparelho, de acordo com a reivindicação 32, CARACTERIZADO pelo fato de que o dispositivo para aderir a um terceiro grupo de multitransmissão de modo a receber uma terceira camada da pluralidade dos pacotes codificados de correção de erro de encaminhamento é ativado, se o conteúdo não foi recuperável a partir do conteúdo recebido, da primeira camada da pluralidade dos pacotes codificados de correção de erro de encaminhamento e da segunda camada da pluralidade dos pacotes codificados de correção de erro de encaminhamento.
34. Aparelho, de acordo com a reivindicação 33, CARACTERIZADO pelo fato de que o dispositivo para aderir a um quarto grupo de multitransmissão de modo a receber novamente o conteúdo e uma quarta camada da pluralidade dos pacotes codificados de correção de erro de encaminhamento é ativado, se o conteúdo não foi recuperável a partir do conteúdo recebido, da primeira camada da pluralidade dos pacotes codificados de correção de erro de encaminhamento, da segunda camada da pluralidade dos pacotes codificados de correção de erro de encaminhamento e da terceira camada da pluralidade de pacotes codificados de correção de erro de encaminhamento.
35. Aparelho, de acordo com a reivindicação 34, CARACTERIZADO pelo fato de que uma decisão de aderir ao quarto grupo de multitransmissão é feita se um número de pacotes de conteúdo perdido excede um limite e adicionalmente compreende dispositivo para transmitir um reconhecimento negativo de pedido de repetição automática.
36. Aparelho, de acordo com a reivindicação 30, CARACTERIZADO pelo fato de que compreende adicionalmente dispositivo para encaminhar conteúdo recuperado a um dispositivo de reprodução.
37. Aparelho, de acordo com a reivindicação 30, CARACTERIZADO pelo fato de que compreende um módulo proxy cliente.
38. Aparelho, de acordo com a reivindicação 30, CARACTERIZADO pelo fato de que uma pluralidade de grupos de multitransmissão adicionais é aderida ao mesmo tempo.
39. Aparelho, de acordo com a reivindicação 30, CARACTERIZADO pelo fato de que o conteúdo inclui múltiplas trilhas de mídia.

Petição 870190087188, de 05/09/2019, pág. 29/36

7/7
40. Aparelho, de acordo com a reivindicação 30, CARACTERIZADO pelo fato de que o dispositivo para aderir é executado se o conteúdo não foi recuperável a partir do conteúdo e da primeira camada de uma pluralidade dos pacotes codificados de correção de erro de encaminhamento a partir de um primeiro grupo de multitransmissão.