BRPI0418723B1

BRPI0418723B1 - método para o reparo de dados em um sistema capaz de comunicações ponto-multiponto, sistema de comunicação e dispositivo emissor

Info

Publication number: BRPI0418723B1
Application number: BRPI0418723A
Authority: BR
Inventors: Leon David; Mehta Harsh; Danilo Diego Curcio Igor; Walsh Rod
Original assignee: Nokia Corp; Nokia Technologies Oy
Priority date: 2004-03-29
Filing date: 2004-10-01
Publication date: 2018-10-16
Also published as: CN1957554B; JP2007531458A; CN1957554A; EP1730870A4; ATE477632T1; BRPI0418723A8; DE602004028665D1; BRPI0418723A; KR100883576B1; EP1730870B1; AU2004318925B2; EP1730870A1; AU2004318925A1; CA2561712C; KR20070010037A; CA2561712A1; WO2005104421A1

Abstract

"método e sistema para reparar os dados nas comunicações ponto-para-múltiplos pontos, produto de código de computador, e, dispositivo transmissor". método, sistema, dispositivo, e produto de código de computador são descritos, nos quais o transmissor (10) transmite os dados para uma pluralidade de receptores (20) através da sessão ponto-para-multipontos. o receptor envia os pedidos de reparo de dados para o transmissor (10) solicitando os dados esperados mas não recebidos e o transmissor (10) retransmite os dados esperados mas não recebidos através da sessão ponto-para-multipontos. o transmissor (10) pode também programar as sessões de reparo de dados ponto-a-ponto com receptores individuais se a retransmissão através da sessão de ponto-para-multipontos não corrige todos os erros. o transmissor (10) pode ser configurado para retardar as sessões de reparo ponto-a-ponto usando um mecanismo randômico baseado no número de receptores usando a sessão ponto-para-multipontos.

Description

(54) Título: MÉTODO PARA O REPARO DE DADOS EM UM SISTEMA CAPAZ DE COMUNICAÇÕES PONTO-MULTIPONTO, SISTEMA DE COMUNICAÇÃO E DISPOSITIVO EMISSOR (51) lnt.CI.: H04L 1/18; G06F 11/30 (30) Prioridade Unionista: 29/03/2004 US 10/813,343, 30/09/2004 US 60/614,602 (73) Titular(es): NOKIA TECHNOLOGIES OY (72) Inventor(es): DAVID LEON; IGOR DANILO DIEGO CURCIO; ROD WALSH; HARSH MEHTA (85) Data do Início da Fase Nacional: 06/10/2006

1/18

MÉTODO PARA O REPARO DE DADOS EM UM SISTEMA CAPAZ DE COMUNICAÇÕES PONTO-MULTIPONTO, SISTEMA DE COMUNICAÇÃO E DISPOSITIVO EMISSOR

Campo da Invenção

A invenção relaciona à tecnologia e aos serviços de transmissão de multiponto e de radiodifusão, quer dizer, os serviços com ao menos uma fonte de dados (ou transmissor) e ao menos um receptor. Mais particularmente, a invenção relaciona aos melhoramentos de reparos de dados de transmissão multiponto ou de radiodifusão.

Descrição da Técnica Anterior

Os serviços de um-para-muitos (i.e. ponto-para-multipontos) nos sistemas tais como nos serviços multiponto IP, na difusão de dados IP (IPDC) e nos serviços de radiodifusão/multiponto de multimídia (MBMS), a entrega de arquivo (ou entrega de mídia discreta ou transferência de arquivo) é um serviço importante. Várias das características para entregar os arquivos nos protocolos ponto-a-ponto tais como o protocolo de transferência de arquivo (FTP) e o protocolo de transferencia de hipertexto (HTTP) são problemáticas para os cenários de um-para-muitos. Em particular, a entrega confiável dos arquivos - quer dizer a enrega garantida dos arquivos - usando os protocolos de reconhecimento (ACK) similares de um-para-um (i.e., ponto-a-ponto), tal como o protocolo de controle de transmissão TCP não é possível.

O Transporte de Multiponto Confiável (RMT) do Grupo de Trabalho da Força Tarefa de Engenharia Internet (IETF) está em processo de padronização de duas categorias de protocolos de transporte de multiponto resilientes a erro. Na primeira categoria, a confiabilidade é implementada através do uso da correção (pró-ativa) de erro direta (FEC), quer dizer, o envio de uma certa quantia de dados redundantes pode ajudar o receptor na reconstrução dos dados errôneos. Na segunda categoria, a realimentação do receptor é usada para implementar o transporte de multipontos confiável. A codificação em camadas assíncrona (ALC, RFC 3450) é uma instanciação do protocolo que pertence a primeira categoria,

Petição 870180067238, de 02/08/2018, pág. 13/18

2/18

Χ3 enquanto ο protocolo de Multiponto Confiável Orientado-NACK apresenta um exemplo da segunda categoria. Os detalhes dos protocolos ALC e NORM são discutidos em maiores detalhes nas publicações intituladas “Instanciação de Protocolo de Codificação em Camadas Assíncrono (ALC)” (IETF RFC 3450) e “Protocolo de Multipontos Confiável Orientado-NACK” (Projeto Internet) preparado pelo Grupo de Trabalho do IETF. Os conteúdos destas publicações são completamente incorporados aqui por referência.

As redes de acesso nas quais estes protocolos podem ser usados incluem, mas não estão limitados, as redes de acesso múltiplo sem fio tal como as redes de acesso de rádio do sistema de Serviços de Telecomunicações Móvel Universal (UMTS), as redes de área local sem fio (WLAN), as redes de Radiodifusão de Vídeo Digital - Terrestre (DVB-T), as redes de Radiodifusão de Vídeo Digital - Satélite (DVB-S) e as redes de Radiodifusão de Vídeo Digital Portáteis (DVB-H).

Resumindo, o protocolo ALC é um esquema baseado-FEC pró-ativo que permite aos receptores reconstruir os pacotes danificados ou os pacotes que não têm sido recebidos. O protocolo ALC usa a codificação FEC nos canais múltiplos, permitindo ao transmissor enviar os dados em múltiplas taxas (canais) para os receptores possivelmente heterogêneos. Adicionalmente, o protocolo ALC usa um mecanismo de controle de congestionamento para manter diferentes taxas em diferentes canais.

O protocolo ALC é escalável em termos do número de usuários, porque nenhuma sinalização de enlace ascendente é requerida. Então, ao adicionar mais receptores não dispõe uma demanda aumentada no sistema. Contudo, o protocolo ALC não é 100% confiável porque a recepção não é garantida, assim este pode ser geralmente descrito como robusto, preferível do que confiável.

NORM especifica o uso das mensagens de reconhecimento negativo (NACK) para sinalizar quais pacotes de dados (ou por outro lado definidos “blocos de dados”) foram esperados para chegar no receptor não foram recebidos no

3/18 receptor (ou foram recebidos incorretamente). Em outras palavras, os receptores empregam as mensagens NACK para indicar perda ou perigo dos pacotes transmitidos para o transmissor. Adequadamente, o receptor que “perdeu” alguns blocos de dados de uma transmissão de dados pode enviar uma mensagem NACK para o transmissor solicitando ao transmissor para retransmitir o bloco de dados perdido ou blocos. O protocolo NORM também opcionalmente permite o uso da codificação FEC a nível de pacote para as transmissões robustas pró-ativas.

A Entrega de Arquivo no Transporte Unidirecional (FLUTE) é um protocolo de transporte de um-para-muitos construído no FEC (RFC 3452) e nos blocos de construção ALC. É pretendido a entrega de arquivo do transmissor (es) para o receptor(es) nos sistemas unidirecionais. Este tem especializações que tornam adequado para os sistemas (multi-ponto/radiodifusão) ponto-paramultipontos sem fio. Os detalhes do protocolo FLUTE são discutidos em maiores detalhes na publicação intitulada de “FLUTE - File Delivery over Unidirectional Transport” (Projeto Internet) preparado pelo Grupo de Trabalho mencionado acima do IETF. Os conteúdos desta publicação são totalmente incorporados aqui por referência.

As mensagens NACK não são geralmente NORM específicas, mas elas podem ser usadas em conexão com outros protocolos ou sistemas, tal como FLUTE. Um ACK é uma mensagem de resposta que o receptor envia após receber um ou mais pacotes de dados para reconhecimento de que eles foram recebidos corretamente. A NACK é a resposta que o receptor envia para o transmissor sobre os pacotes que estavam esperando chegar, mas não foram recebidos.

Quando no ambiente de multipontos ou radiodifusão, a transmissão de dados ocorre na sessão de um-para-muitos. Se a transmissão não é livre de erro e diferentes receptores são sujeitos a diferentes taxas de erro (por exemplo, nos usuários MBMS em diferentes células podem experimentar uma qualidade de sinal diferente e, como consequência, uma taxa de erro diferente), há o problema de prover uma confiabilidade de dados aumentada. Esta pode ser alcançada através do uso do FEC e/ou através do uso das sessões de reparo.

4/18

FEC provê uma certa quantia de redundância para os dados transmitidos, para permitir um certo grau de resiliência de erro para permitir ao receptor reconstruir os dados transmitidos. Contudo, um problema do FEC é que este usualmente não provê uma recuperação livre de erro, ou este provê toda a recuperação de erro no custo de alto uso da redundância de dados, que aumenta as exigências de largura de banda do canal.

A sessão de reparo (entre o receptor e o transmissor) pode ser empregada para complementar o FEC (para reduzir ou eliminar a taxa de erro de canal residual), ou pode ser usada sozinha como o método apenas para recuperação de erro. A sessão de reparo pode ocorrer no canal ponto-a-ponto usando uma sessão separada. Neste caso, todos os receptores que tem perdido alguns dados durante a transmissão de multiponto/radiodifusão, envia os pedidos NACK para o transmissor para solicitar a retransmissão dos pacotes perdidos. Contudo, se todos os receptores perdem ao menos um pacote de dados, todos os receptores estabelecerão simultaneamente as conexões ponto-a-ponto com o transmissor ocasionando a implosão de realimentação, i.e., o congestionamento na rede (na direção de enlace ascendente para um número maior de NACKs e na direção de enlace descendente para um número maior de retransmissão concorrente e os pedidos de conexão de rede) e a sobrecarga do transmissor. Esta situação é crítica ao considerar, por exemplo, milhões de usuários, como pode ser o caso nas redes MBMS.

Como tal, há uma necessidade para um dispositivo melhorado, sistema e método para reparar os dados que são escaláveis e prover um reparo eficiente das mensagens nos ambientes multipontos e de radiodifusão.

Resumo da Invenção

Várias incorporações dos sistemas, métodos, dispositivos, e produtos de programa de computador são descritas de acordo com a presente invenção. As várias incorporações são capazes de comunicações ponto-para-multipontos e podem incluir transmitir os dados do transmissor para uma pluralidade de receptores através da sessão ponto-para-multipontos, determinando se quaisquer

5/18 dados esperados não foram recebidos, enviar um pedido de reparo de dados para o transmissor se os dados estiverem perdidos, e retransmitir os dados perdidos através da sessão de ponto-para-multipontos. O transmissor também pode ser configurado para programar e executar as sessões de reparo ponto-a-ponto se a retransmissão ponto-para-multipontos não corrige o problema de perda de dados.

O mecanismo randômico pode ser usado para retardar o reparo de dados ponto-a-ponto até após o transmissor retransmitir os dados indicados como não recebidos através da sessão ponto-para-multipontos. O mecanismo randômico pode ser configurado para levar em conta o número de receptores incluído em uma pluralidade de receptores. Alternativamente (ou adicionalmente), o transmissor pode enviar um reparo ponto-a-ponto para uma pluralidade de receptores para anunciar quando o reparo ponto-a-ponto iniciará.

Em outro aspecto da invenção, o método para reparar os dados no sistema compreende um dispositivo transmissor, ao menos um receptor capaz de receber os dados do dispositivo transmissor, um servidor HTTP e um servidor FLUTE é descrito. O método pode incluir determinar se alguns dados esperados não foram recebidos por ao menos um receptor, enviar o pedido de dados de ao menos um receptor para o servidor HTTP, enviar uma mensagem redirecionar HTTP do servidor HTTP para ao menos um receptor, a mensagem redirecionar incluindo um URI FLUTE, enviar um pedido de sessão de ao menos um receptor para o servidor FLUTE, e iniciar a sessão FLUTE entre o servidor FLUTE e ao menos um receptor.

Breve Descrição das Figuras

Figura 1A - é um diagrama em blocos ilustrando um cenário de transmissão ponto-para-multipontos de acordo com uma incorporação da invenção;

Figura 1B - é um diagrama em blocos ilustrando diferentes métodos de reparo de dados perdidos de acordo com as incorporações da invenção;

Figura 2A - é um fluxograma ilustrando uma incorporação de um método para reparar os dados de acordo com a presente invenção;

Figura 2B - é um fluxograma ilustrando uma outra incorporação de

6/18 um método para reparar os dados de acordo com a presente invenção;

Figura 3 - é um diagrama em blocos de um sistema e um dispositivo receptor de acordo com uma incorporação da invenção;

Figura 4 - é um diagrama em blocos ilustrando o dispositivo transmissor de acordo com uma incorporação da invenção;

Figura 5 - é uma representação de uma incorporação de um mecanismo de reparo de acordo com a presente invenção.

Descrição Detalhada da Invenção

Existem vários métodos e sistemas para reparar os dados em um sistema de multipontos ou de radiodifusão. O pedido de patente US intitulado “Reparo de Dados” (número de série 10/782,371) depositado em 18 de Fevereiro de 2004, os conteúdos dos quais são incorporados totalmente aqui por referência, descreve métodos eficientes para reparar os dados. Este pedido propõe que após a recepção de um certo número de pedidos NACK dos receptores, o transmissor pode decidir, baseado nas suas próprias estratégias de decisão, retransmitir através da parte de ponto-para-multipontos o número total de pacotes que não foram reconhecidos NACK pelos receptores, por exemplo, estes pacotes que são mais solicitados dos receptores. O transmissor pode também fechar as conexões ponto-a-ponto para salvar os recursos de rede.

Uma desvantagem com os métodos tal como estes é que a retransmissão apenas da maior parte dos pacotes não reconhecidos NACK pode não conduzir a uma recuperação de erro total no caso onde existe um pouco de correlação estática entre os pedidos NACK de diferentes usuários. Por exemplo, se uma situação de erro particular é tal que o receptor #1 não reconhece NACK os pacotes 1, 2 e 3, e o receptor #2 não reconhece NACKs os pacotes 4, 5 e 6, e assim por diante, o transmissor pode não ser capaz de derivar quais são “os pacotes mais solicitados” e, como conseqüência, o reparo ponto-para-multipontos pode perder sua eficiência. A invenção propõe métodos melhorados, dispositivos e sistemas para reparar os dados.

A Figura 1A apresenta um cenário de transmissão de dados de

7/18 acordo com uma incorporação da invenção. O transmissor 10 pode ser um servidor, um dispositivo baseado em IP, um dispositivo DVB, um dispositivo GPRS (ou UMTS) ou um dispositivo similar que pode usar a correção de erro direta próativa, tal como o mecanismo ALC e/ou mecanismo FEC, para enviar os blocos de dados multipontos (ou pacotes) para os receptores 20 na sessão de um-paramuitos. Cada receptor 20 pode ser configurado para enviar as mensagens de reconhecimento negativo NACK (ou pedidos) para o transmissor 10 referindo aos blocos perdidos (blocos não recebidos ou recebidos incorretamente).

Os dados podem ser transferidos do transmissor 10 para o receptor(es) 20 como objetos. Por exemplo, um arquivo, uma imagem JPEG, e uma fatia de arquivo são todos objetos. Os objetos podem ser enviados como uma série de blocos de dados. Cada bloco de dados pode ter um número denominado de número do bloco da fonte (SBN) ou um identificador similar, que pode ser usado para identificar cada bloco. Os blocos podem ser representados por um grupo de símbolos de codificação. O identificador de símbolo de codificação (ESI) ou identificador similar pode indicar como os símbolos de codificação carregados na carga útil do pacote de dados (ou bloco) foram gerados do objeto mencionado acima (por exemplo, arquivo).

No sistema ponto-para-multipontos, o transmissor 10 pode radiodifundir os blocos de dados ou os pacotes representando um objeto para muitos receptores 20 simultaneamente. Se um receptor 20 não recebe todos os pacotes que este espera, este pode enviar uma mensagem NACK de volta para o transmissor 10 indicando quais pacotes não foram recebidos. A Figura 1B ilustra diferentes métodos de reparo de dados de acordo com as incorporações da presente invenção. Em geral o reparo dos dados perdidos pode ser executado ao usar a sessão de reparo ponto-a-ponto estabelecida entre um transmissor 10 e um receptor 20 ou ao usar a sessão ponto-para-multipontos entre o transmissor 10 e mais de um receptor 20. Na sessão de reparo, os dados perdidos no total ou em parte (dependendo do caso) podem ser retransmitidos do transmissor 10 para os receptor(es) 20 ou toda a transmissão pode ser repetida. O reparo pode ser

8/18 realizado do transmissor original 10 ou do “servidor de terceira parte” ou servidor de reparo (ou simplesmente um servidor separado (não apresentado)) que tem uma conexão com o servidor original e é configurado para armazenar os dados/informação de transmissão. Este servidor pode, por exemplo, ser colocalizado com o transmissor original (por exemplo, um servidor MBMS, também denominado de BM-SC (Centro de Serviços de Radiodifusão para Multipontos)), ou, por exemplo, ser um servidor separado dentro da rede do operador UMTS.

Tem sido observado que, em geral, os sistemas multipontos confiáveis apresentam o problema de requerer o controle do receptor-servidor e a transmissão de mensagens de dados que, devido a uma natureza de multi-partes de multipontos, apresenta os problemas de escalabilidade. Existem várias áreas, em particular, as quais são referenciadas. Por exemplo:

a) largura de banda de rádio limitada e recursos de ativação, onde o tempo que este levaria para ativar vários canais de rádio e a largura de banda de rádio torna este inviável permitir vários reparos para ocorrer simultaneamente;

b) capacidade do servidor limitada, onde o sistema servidor, que está provendo os dados de “conteúdo de reparo”, pode controlar o número de pedidos limitados (mensagem) e os dados de contexto de sessão associados dentro de uma certa janela de tempo e uma quantia limitada de sessões de transferência de dados simultânea; e

c) largura de banda de extremo-a-extremo limitada, devido a um ou mais engarrafamentos em todo o sistema. Aqui a taxa de dados, que poderia ser feita disponível para todos os usuários que requerem reparos simultaneamente, em muitos casos, é insuficiente para prover este serviço.

Assim, um fator que pode ser usado para aumentar a escalabilidade em qualquer ou em todas estas limitações pode ser distribuir a mensagem no tempo, ou evitar esta totalmente se possível. Uma incorporação da presente invenção refere-se a métodos, dispositivos, e sistemas que pode permitir uma supressão NACK para prover uma comunicação multipontos confiável escalável.

Uma incorporação da presente invenção propõe que todos os pacotes

9/18 que são solicitados por ao menos um receptor 20 sejam retransmitidos pelo servidor 10 na portadora de ponto-para-multipontos. Nesta incorporação, os receptores 20 podem ser configurados para ter a configuração da portadora pontoa-ponto (pap) e a portadora ponto-para-multipontos (ppm) ao mesmo tempo. A portadora pap pode ser usada, por exemplo, para os pedidos de reparo de serviço como descrito no pedido de Patente US 10/782,371. Uma incorporação da presente invenção pode usar regras de randomização similares a estas descritas no pedido de patente acima mencionado. Contudo, a incorporação da presente invenção pode retransmitir os dados perdidos na portadora ppm de enlace descendente ao invés de usar a portadora pap de enlace descendente.

Nesta incorporação, os receptores 20 cujos pedidos não têm ainda vindos por causa do valor randômico de redundância de potência que eles calcularam, pode ter a oportunidade para reparar a sua própria perda ao receber os pacotes perdidos retransmitidos através do canal ppm. Se o receptor 20 recebe o pacote de dados perdido através do canal ppm, este pode reconstruir o arquivo usando estes dados e remover o pacote de dados perdido da sua lista de pacotes a solicitar. Pode ser possível que o receptor 20 possa receber todos os seus dados perdidos antes do seu tempo de solicitação calculado, neste caso poderia refrear de fazer quaisquer pedidos de reparo.

Em outra incorporação da presente invenção, o reparo pap pode ser oferecido ao transmissor 10 em conjunção com o mecanismo de reparo ppm descrito acima. Isto pode ser útil, em particular, para as sessões quando nem todos os receptores 20 são capazes de ter uma portadora pap e ppm abertas ao mesmo tempo. Neste caso, para uma maior eficiência, o transmissor 10 pode especificar um mecanismo de randomização de forma a retardar os pedidos para reparo pap. Isto permite o reparo na portadora ppm que pode beneficiar de um número mais elevado de receptores 20 a ser feito primeiro. Uma forma para fazer isso, por exemplo, pode ser através do uso dos valores limiares (tal como X, Y, Z) enviados pelo transmissor 10 para os receptores 20. O receptor 20 poderia então ser configurado para programar os seus pedidos de reparo. Uma regra da amostra

10/18

para os receptores 20 programa os pedidos de reparo de acordo com uma incorporação da presente invenção, a qual poderia ser:

Se o reparo ppm for possível, então randomizar uniformemente o NACK(s) em um período de tempo X, iniciando do final da sessão de entrega inicial;

senão esperar até após um certo tempo Y após a sessão inicial terminar, e então randomizar o NACK(s) em um período de tempo Z.

O transmissor 10 poderia também explicitamente sinalizar quando o reparo pap deveria iniciar. Para este fim, o transmissor pode enviar um símbolo de reparo pap para os receptores 20 para anunciar quando o reparo pap pode iniciar (quando o reparo pap inicia, a sessão de reparo pap pode estar sujeita às regras de randomização normais.) Antes de enviar o símbolo de reparo pap, todos os reparos são feitos na portadora ppm. Os receptores 20 que não são capazes de ter duas portadoras concorrentes (por exemplo, pap e ppm) pode então esperar pelo símbolo antes dele configurar a sua portadora de reparo pap. O símbolo de reparo pode ser transmitido usando qualquer protocolo de comunicação em quaisquer das camadas 1-7 da pilha de protocolos ISO OSI, incluindo, por exemplo, através do SDP em um “anúncio” separado após a transmissão multipontos/radiodifusão. Este também pode ser incluído na entrega do arquivo FLUTE na transmissão multipontos/radiodifusão. O valor do Identificador Objeto de Transporte (TOI) separado pode ser usado para distinguir entre o próprio conteúdo do arquivo e o conteúdo de reparo pap. Em uma incorporação da presente invenção, o receptor 20 que já usou o reparo ppm pode também usar o reparo pap. Este pode ser útil se o reparo ppm não foi bem sucedido, i.e., o pacote que foi re-enviado na portadora ppm foi perdido.

Enquanto a randomização pode ajudar a impedir a implosão de reaiimentação, é preferível que os tempos de redução de potência sejam calculados de acordo com o número de receptores 20 no sistema, para aumentar a eficiência. Se os tempos de redução de potência são escolhidos para serem

11/18 menores, o risco de implosão de realimentação pode não ser minimizado, especialmente se existem um número amplo de receptores 20 na sessão. Se, por um lado, os tempos de redução de potência são muito grandes, o risco de implosão de realimentação diminui mais o esquema torna-se ineficiente se existem apenas alguns receptores na sessão, uma vez que cada receptor será requerido para esperar uma quantia enorme de tempo desnecessariamente antes de ser capaz de fazer um pedido de reparo.

Se o transmissor 10 conhece o número de receptores 20 na sessão, o transmissor 10 pode ser capaz de escalar os seus valores de randomização baseado no número de receptores 20 para otimizar a performance do sistema. Um tipo de sessão é a sessão de multipontos MBMS, onde o transmissor 10 é capaz de derivar o número de receptores 20 como uma necessidade posterior para sinalizar os procedimentos de entrada de sessão e saída. Em uma incorporação, a relação linear entre o número de receptores 20 na sessão e os valores de randomização podem ser usados para calcular os valores limiares necessários. Por exemplo, ao usar o método de randomização proposto no Pedido de Patente US 10/782,371:

Se abaixo da taxa de erro limiar W então randomizar uniformemente o NACK(s) em um período de tempo X, iniciando do final da sessão de entrega inicial;

Os valores de W, X, Y e Z podem ser fixados e escolhidos de acordo com o número de participantes (número de receptores) na sessão. A tabela de consulta, tal como apresentada abaixo, pode ser armazenada no transmissor 10 e a consulta na própria entrada da tabela pode ser usada para escolher os valores limiares.

# de receptores	W(%)	X(seg.)	Y (seg.)	Z (seg.)
100	5	5	25	10

12/18

200	5	10	30	20
500	5	15	35	30
1000	5	20	40	40
5000	5	30	50	60
10000	5	60	80	120
50000	5	200	250	400
100000	5	400	450	800
500000	5	2000	2100	4000
1000000		4000	4200	8000

Deveria ser observado que a tabela acima é meramente um exemplo. Outros valores e estruturas de tabelas podem ser usados sem sair do conceito inventivo e escopo da invenção.

Os quatros valores (ou em geral os valores para randomizar o tempo inicial da sessão de reparo) podem ser comunicados do transmissor para os receptores através do SDP ou de quaisquer outros meios adequados. Os valores podem ser comunicados para os receptores a qualquer tempo entre o anúncio do serviço e o tempo inicial da sessão ou o tempo de união posterior. Por exemplo, se uma sessão é agora iniciada através do SDP, e programada para iniciar após duas horas (ou alternativamente o tempo de adesão da última sessão após 1.5 horas da entrega do anúncio de serviço), o segundo SDP com os parâmetros de randomização podem ser enviados, usando o segundo anúncio ou símbolo que leva em conta o número de receptores 20 que aderiram a sessão a qualquer momento antes do início da sessão. Neste caso, os receptores 20 obtém uma indicação do tempo de randomização, que leva em conta o número de receptores real e atualizado que aderiram a sessão. Alternativamente, os parâmetros podem ser comunicados dentro do FDT de uma sessão FLUTE ou apenas um sub-grupo destes valores pode variar com o número de receptores.

Referindo agora à Figura 2A, uma incorporação do método para prover o reparo de dados é descrito. O método descrito na Figura 2A compreende enviar os pacotes de dados do transmissor para uma pluralidade de receptores

13/18 através de uma sessão ponto-para-multipontos 100. Se quaisquer dos receptores determina que este não recebeu alguns dados esperados este envia uma mensagem NACK de volta para o transmissor solicitando os pacotes de dados que não foram devidamente recebidos e o receptor recebe estas mensagens NACK 102. A seguir, o transmissor retransmite os pacotes de dados solicitados para os receptores através da sessão ponto-para-multipontos 104.

Outra incorporação da invenção é apresentada na Figura 2B. Nesta incorporação, o transmissor indica o início da sessão ponto-para-multipontos 110 e então coleta a informação sobre o número de receptores usando a sessão 120. O transmissor então calcula os valores de randomização baseado no número de receptores usando a sessão 130 e envia os valores de randomização para os receptores 140. A seguir, o transmissor inicia o envio dos pacotes de dados para os receptores através da sessão ponto-para-multipontos 150. Se quaisquer dos receptores não recebe todos os pacotes de dados esperados, este envia a mensagem NACK de volta para o transmissor solicitando a retransmissão dos pacotes de dados perdidos. O transmissor recebe estas mensagens NACK 160 e retransmite os pacotes de dados solicitados na sessão ponto-para-multipontos. Então, o servidor inicia o serviço de quaisquer dos pedidos de reparo de dados restante através da sessão ponto-a-ponto 180. As sessões ponto-a-ponto são randomizadas em um período de tempo baseado nos valores de randomização calculados pelo transmissor baseado no número de receptores usando a sessão ponto-para-multipontos.

Os métodos de reparo de dados descritos aqui provêem vantagens distintas quando comparado com os métodos da técnica anterior. Por exemplo, ao enviar um bloco de reparo que o receptor 20 solicita através de reparo pap através do ppm ao invés do pap de enlace descendente carrega o canal pap e ajuda outros receptores 20 que podem necessitar do mesmo bloco de reparo. Também, ao escalar os valores de randomização de acordo com o número de receptores ajuda a evitar o risco de implosão de realimentação enquanto ainda minimiza o retardo necessário para enviar os pedidos.

14/18

Ao usar um mecanismo, tal como FLUTE, para transmitir os dados para muitos usuários de maneira eficiente, um método para identificar, o reconhecimento negativo e retransmitir os dados perdidos é necessário. Em uma incorporação da invenção, é possível usar HTTP para fazer isso. Por exemplo, o terminal de recepção pode usar o HTTP para solicitar ao servidor de transmissão retransmitir um certo arquivo ou parte de um arquivo. Em alguns casos, o servidor pode ser requerido para retransmitir os arquivos para vários terminais ou pode não ter o arquivo e conseqüentemente pode necessitar redirecionar o pedido para outro servidor. Um aspecto desta invenção provê um sistema eficiente e um método para reparo ppm para FLUTE ou outras sessões.

Enquanto os pedidos HTTP podem ser usados para obter um grupo de dados perdido da transmissão, é desejável ter um mecanismo de reparo que pode permitir um grande número de receptores para receber uma certa transmissão novamente. Em uma incorporação, esta pode ser alcançada ao usar o mecanismo redirecionar HTTP com a URI de transferência para FLUTE. A URI de transferência para FLUTE pode ser análoga a URL HTTP. Quer dizer, esta é similar a URL HTTP, mas aplicável para FLUTE. O URI FLUTE pode referenciar a um arquivo de sinal transmitido durante uma certa sessão FLUTE. Usando o URI FLUTE, o arquivo de uma certa sessão FLUTE pode ser unicamente identificado.

Nesta incorporação, o servidor HTTP pode indicar para o receptor a fonte da qual o arquivo requerido pelo receptor está disponível. Ao usar o mecanismo de redirecionar HTTP, o servidor HTTP pode redirecionar um ou mais terminais que não receberam a transmissão corretamente para o servidor FLUTE, que então inicia uma nova sessão de reparo ppm para múltiplos receptores.

Em outro aspecto desta incorporação, o mecanismo redirecionar HTTP pode também ser usado para indicar ao receptor a localização do arquivo da descrição da sessão FLUTE (tal como um arquivo SDP). Ao usar o arquivo de descrição de sessão, o receptor pode aderir a sessão FLUTE e obter este arquivo(s) de interesse. O cliente pode então correlacionar com as descrições de sessão já recebidas e armazenadas para verificar se esta já recebeu o arquivo de

15/18 descrição da sessão particular. Este pode tentar buscar o arquivo/pacotes/recurso perdido usando HTTP/FLUTE, etc. Neste exemplo, o URI FLUTE pode ser o URI de um arquivo SDP que descreveu a sessão FLUTE para a qual o arquivo em questão pertence (i.e., a sessão FLUTE na qual este foi transmitido e durante o qual o terminal recebeu este arquivo).

Em outra incorporação, o re-direcionamento HTTP pode também conter o arquivo de descrição de sessão como carga útil. Esta pode ser feita usando um URI absoluto na carga útil e/ou ao usar o código de re-direcionamento. Quando o arquivo de descrição de sessão é usado para fazer o re-direcionamento, este pode ser desejável para a versão do arquivo de descrição de sessão. Este pode ser alcançado ao usar um cabeçalho de extensão ou ao usar o envelope de metadados. O envelope de metadados encapsula ou referencia ao arquivo de descrição de sessão e provê um mecanismo de versão. Neste exemplo, o URL do arquivo pode ser incluído no cabeçalho da mensagem de re-direcionamento HTTP, tal como na forma www.example.com/file/mp3.

A Figura 5 ilustra uma incorporação do método para usar o URI FLUTE e o mecanismo de re-direcionamento HTTP para lançar a sessão de reparo de arquivo ppm. Como apresentado na Figura 5, na transmissão da sessão FLUTE, o receptor pode verificar que não recebeu o arquivo completo. Neste caso, o receptor pode enviar um pedido de reparo para o servidor HTTP. O endereço do servidor HTTP pode ser conhecido para o receptor da informação de reparo transmitida durante a sessão FLUTE. Na obtenção do pedido de reparo, o servidor HTTP pode decidir que é mais eficiente conduzir uma sessão ppm usando FLUTE do que várias sessões pap individuais usando HTTP. Isto pode ser feito por várias razões, tal como o número de pedidos de reparo recebidos são tão altos para o servidor HTTP que este não possui o arquivo solicitado. Neste caso, o servidor HTTP pode enviar um re-direcionamento para o receptor com o URI FLUTE do arquivo. Na obtenção, o re-direcionamento do servidor HTTP, o receptor pode enviar um “pedido de sessão” para o servidor FLUTE. O servidor FLUTE pode então iniciar uma sessão FLUTE ppm com muitos receptores potencialmente

16/18 <3 “sintonizados”. É possível para o FLUTE e os servidores HTTP serem entidades separadas, mas ainda serem localizadas na mesma máquina física.

Um exemplo de um arquivo SDP que pode ser usado para as descrições de sessão é:

v=0 o=usuário123 2890844526 2890842807 IN IP6

2201:056D::112E:144A:1E24 s=exempio de sessão de entrega de arquivo i=Mais informação t=2873397496 2873404696 a=filtro-fonte:incl IN IP6 * 2001:210:1:2:240:96FF:FE25:8EC9 a=flute-tsi:3 a=flute-ch:2 m=aplicação 12345 FLUTE/UDP 0 c=IN IP6 FF1E:03AD::7F2E:172A:1E24/1 m=aplicação 12346 FLUTE/UDP 0 c= IN IP6 FF1E:03AD::7F2E:172A:1E30/1

Este arquivo de exemplo descreve como o receptor pode se unir a sessão FLUTE. Este provê a informação em relação ao endereço IP do transmissor, o número de canais na sessão, o endereço IP de destino e o número da porta para cada canal na sessão, o identificador de Sessão de Transporte (TSI) da sessão, e os tempos de início e fim da sessão.

A Figura 3 ilustra uma incorporação de um sistema 5 e de um dispositivo receptor 20 de acordo com a presente invenção. O sistema 5 pode incluir um dispositivo transmissor 10, uma rede de transmissão 30, por exemplo, uma rede IP ou outra rede fixa, uma rede sem fio ou uma combinação de rede fixa e sem fio (celular), etc., e o dispositivo receptor 20. O dispositivo receptor 20 pode ser, por exemplo, um telefone celular, um telefone de satélite, um assistente digital pessoal, um dispositivo Bluetooth, um dispositivo WLAN, um dispositivo DVB, ou outro dispositivo sem fio similar. O receptor 20 pode incluir uma memória interna

17/18

21, um processador 22, um sistema operacional 23, programas de aplicação 24, uma interface de rede 25, e um mecanismo NACK e de reparo 26. A memória interna 21 pode ser configurada para acomodar o processador 22, o sistema operacional 23 e os programas de aplicação 24. O mecanismo NACK e de reparo 26 pode permitir os procedimentos de não reconhecimento NACK e reparo em resposta aos dados perdidos ou danificados na transmissão de dados. O dispositivo receptor 20 pode ser capaz de comunicação com o dispositivo transmissor 10 e com outros dispositivos através da interface de rede 25 e a rede 30.

A Figura 4 ilustra uma incorporação do dispositivo transmissor 10 de acordo com a presente invenção. O dispositivo transmissor 10 pode ser, por exemplo, um servidor de rede ou qualquer dispositivo adequado pretendido para a entrega de arquivo (ou mídia). O dispositivo transmissor 10 pode incluir uma memória interna 11, um processador 12, um sistema operacional 13, programas de aplicação 14, uma interface de rede 15, um mecanismo de transmissão e reparo 16, e um armazenador de dados 17. A memória interna 11 pode ser configurada para acomodar o processador 12, o sistema operacional 13, e os programas de aplicação 14. O mecanismo de transmissão e reparo 16 pode ser configurado para permitir a transmissão dos pacotes de dados para os dispositivos receptores 20. Em adição, este pode ser configurado para permitir a retransmissão dos pacotes de dados nas sessões de reparo. Os dados a serem enviados para os dispositivos receptores 20 e os dados a serem retransmitidos podem ser armazenados no armazenador de dados 17. Alternativamente, os dados podem ser armazenados em um dispositivo separado co-Iocalizado com ou externo ao dispositivo transmissor 10. O dispositivo transmissor 10 pode ser configurado para comunicar com o dispositivo receptor 20 e outros dispositivos através da interface de rede 15 e a rede 30.

Os procedimentos relativos ao reparo dos dados perdidos podem ser implementados por um programa. O produto de programa de computador compreende o código de programa armazenado no dispositivo receptor 20 e roda

18/18 no processador 22, o qual pode ser usado para implementar os procedimentos na extremidade de recepção da sessão de transmissão, considerando que o produto de programa de computador compreende um código de programa armazenado no dispositivo transmissor 10 e roda no processador 12, o qual pode ser usado para implementar os procedimentos na extremidade de transmissão.

As incorporações da invenção têm sido ilustradas com exemplos ou intitulações transmissor/servidor lógico e unidades de recepção, o uso de outras entidades entre os pedidos de reparo, e as respostas de reparo (se apropriado), são também contempladas e consideradas dentro do escopo da presente ío invenção. Tal entidade pode prover uma barreira de proteção, Proxy, e/ou serviços de autorização.

Enquanto as incorporações exemplares ilustradas nas figuras e descritas acima são atualmente preferidas, deveria ser entendido que estas incorporações são oferecidas por meio de exemplo apenas. Outras incorporações podem incluir, por exemplo, diferentes técnicas para executar as mesmas operações. A invenção não é limitada a uma incorporação particular, mas estende a várias modificações, combinações, e permutações, as quais estão dentro do escopo e conceito inventivo das reivindicações apensas.

1/4

Claims

REIVINDICAÇÕES

1. Um método para o reparo de dados em um sistema capaz de comunicações ponto-multiponto, tal método compreendendo:

transmitir dados de um emissor (10) para diversos receptores (20) através de uma sessão ponto-a-multiponto; determinar se algum dado esperado não foi recebido; se alguns dados esperados não foram recebidos, enviar uma solicitação de reparo de dados ao remetente (10) solicitando que os dados esperados, mas não recebidos, sejam reenviados; e retransmitir do remetente (10) os dados solicitados através da sessão ponto-a-multiponto;

caracterizado por:

após o remetente (10) retransmitir os dados solicitados, se alguns dados ainda não foram recebidos, agendar sessões de reparo ponto-aponto para receptores específicos (20) que esperavam dados que não foram recebidos;

em que agendar sessões de reparo ponto-a-ponto compreende ainda a especificação de um mecanismo de aleatorização para aleatorizar a reparo de dados ponto-a-ponto durante um determinado período após o remetente (10) ter retransmitido os dados esperados, mas não recebidos; e enviar dados ainda não recebidos para os receptores específicos (20) através de sessões ponto-a-ponto de acordo com a programação da sessão de reparo ponto-a-ponto.
2. Método de acordo com a reivindicação 1, caracterizado por o agendamento de sessões de reparo ponto-a-ponto compreender ainda:

se o reparo ponto-a-multiponto for possível para um receptor (20), uniformemente aleatorizar pedidos de reparo de dados ao longo de um período X a partir do final da transmissão inicial de dados do emissor (10) para os receptores (20) através da sessão de ponto-a-multiponto; senão, aguardar até um determinado horário Y após a transmissão inicial de dados do emissor (10) para os receptores (20) através da

Petição 870180067238, de 02/08/2018, pág. 14/18

2/4 sessão de ponto-a-multiponto e, então, aleatorizar os pedidos de reparo de dados ao longo de um período Z.
3. Método de acordo com a reivindicação 1, caracterizado por o agendamento de sessões de reparo ponto-a-ponto compreender o envio de um token de reparo ponto-a-ponto do emissor (10) para os diversos receptores (20) para anunciar que o reparo ponto-a-ponto será iniciado.
4. Método de acordo com a reivindicação 1, caracterizado por o mecanismo de aleatorização estar configurado para levar em conta o número de receptores (20) incluídos nos diversos receptores (20).
5. Método de acordo com a reivindicação 4, caracterizado por compreender ainda:

determinar o número de receptores (20) nos diversos receptores (20); e calcular os valores de aleatorização para o mecanismo de aleatorização com base no número determinado de receptores (20).
6. Método de acordo com a reivindicação 5, caracterizado por o cálculo dos valores de aleatorização compreender ainda procurar os valores de aleatorização em uma tabela de consulta com base no número determinado de receptores (20).
7. Um sistema de comunicação ponto-a-multiponto capaz de reparar dados, tal sistema compreendendo:

um dispositivo emissor (10), para transmitir dados via comunicações ponto-a-multiponto;

diversos receptores (20), para receber dados do dispositivo emissor (10);

em que o dispositivo emissor (10) está configurado para transmitir dados para os diversos receptores (20) através de uma sessão pontoa-multiponto;

Petição 870180067238, de 02/08/2018, pág. 15/18

3/4 os diversos receptores (20) estão configurados para receber dados transmitidos pelo dispositivo emissor (10), determinar se algum dado esperado não foi recebido e, em nesse caso, enviar um pedido de reparo de dados de volta ao dispositivo emissor (10) solicitando que os dados esperados, mas não recebidos, sejam reenviados; e o dispositivo emissor (10) está configurado para receber solicitações de reparo de dados dos diversos receptores (20) e para retransmitir os dados solicitados através da sessão ponto-a-multiponto;

caracterizado por:

o dispositivo emissor (10) estar ainda configurado para agendar sessões de reparo de dados ponto-a-ponto com os diversos receptores (20) após a retransmissão dos dados solicitados esperados mas não recebidos se alguns dados ainda não foram recebidos;

em que o dispositivo emissor (10) está ainda configurado para especificar um mecanismo de aleatorização para aleatorizar o reparo de dados ponto-a-ponto durante um certo período após o remetente (10) ter retransmitido os dados esperados, mas não recebidos; e o dispositivo emissor (10) está configurado para enviar dados esperados, mas não recebidos para os diversos receptores (20) de acordo com a programação de sessões ponto-a-ponto.
8. Sistema de acordo com a reivindicação 7, caracterizado por o emissor (10) poder determinar o número de receptores na sessão ponto-a-multiponto e poder calcular um mecanismo de aleatorização baseado no número determinado de receptores (20).
9. Sistema de acordo com a reivindicação 7, caracterizado por o emissor (10) estar configurado para enviar um token de reparo ponto-a-ponto para os diversos receptores (20) para anunciar quando o reparo ponto-a-ponto será iniciado.

Petição 870180067238, de 02/08/2018, pág. 16/18

Μ
10. Sistema de acordo com a reivindicação 7, caracterizado por compreender ainda uma tabela de consulta para determinar o agendamento de reparo ponto-a-ponto.
11. Um dispositivo emissor (10) para utilização em um sistema de comunicação ponto-a-multiponto, tal dispositivo emissor (10), compreendendo:

meios para transmitir dados aos diversos receptores (20) através de uma sessão ponto-a-multiponto;

meios para receber pedidos de reparo de dados a partir dos diversos receptores (20), solicitando os dados esperados, mas não recebidos; meios para retransmitir os dados esperados, mas ainda não recebidos, através de uma sessão ponto-a-multiponto;

caracterizado por o dispositivo emissor (10) compreender ainda:

meios para agendar de sessões de reparo de dados ponto-a-ponto com os diversos receptores (20) depois de retransmitir os dados esperados, mas ainda não recebidos, se alguns dados ainda não foram recebidos; em que os meios para agendar sessões de reparo de dados ponto-aponto estão configurados ainda para especificar um mecanismo de aleatorização para aleatorizar a reparo de dados ponto-a-ponto durante um determinado período após o remetente (10) ter retransmitido os dados solicitados esperados, mas não recebidos; e o dispositivo emissor (10) compreende ainda meios para enviar dados ainda não recebidos para os receptores específicos (20) através de sessões ponto-a-ponto de acordo com o agendamento da sessão de reparo ponto-a-ponto.
12. Dispositivo emissor de acordo com a reivindicação 11, caracterizado por compreender ainda meios para a determinação do número de receptores (20) utilizando a sessão de ponto-a-multiponto, em que o emissor (10) está configurado para marcar as sessões de reparo de dados ponto-a-ponto com base no número determinado de receptores (20).

Petição 870180067238, de 02/08/2018, pág. 17/18 ι/6

ο Ο 04 OJ

Ο Ο 04 04

ο

CQ τ— §

ο ο

2/6

FIGURA 2Α

3/6

FIGURA 2Β

4/6 ο

LU

5/6

LU α

UJ □ί ο <σ>

<

α.

'tf <

Qí

ZD

Ο

IX.

6{Ç>

SERVIDOR FLUTE

RECEPTOR

SERVIDOR HTTP

SESSÃO FLUTE ORIGINAL 4 L l-1-1-l±-J- . PEDIDO DE REPARO REDIRECIONAR PEDIDO DE SESSÃO NOVA SESSÃO FLUTE P-P-M - -......... -........ -.....-- - - -- - ......- ..............¹ ......^{J J}·· ^J>

FIGURA 5