BRPI0513969B1 - Método para transmitir símbolos de dados, sistema para transmissão de símbolos de dados, transmissor em um sistema, elemento de rede e receptor - Google Patents

Método para transmitir símbolos de dados, sistema para transmissão de símbolos de dados, transmissor em um sistema, elemento de rede e receptor Download PDF

Info

Publication number
BRPI0513969B1
BRPI0513969B1 BRPI0513969-4A BRPI0513969A BRPI0513969B1 BR PI0513969 B1 BRPI0513969 B1 BR PI0513969B1 BR PI0513969 A BRPI0513969 A BR PI0513969A BR PI0513969 B1 BRPI0513969 B1 BR PI0513969B1
Authority
BR
Brazil
Prior art keywords
flute
header
point
type
repair
Prior art date
Application number
BRPI0513969-4A
Other languages
English (en)
Inventor
Ramakrishna Vedantham
David Leon
Igor Curcio
Rod Walsh
Original Assignee
Nokia Technologies Oy
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Technologies Oy filed Critical Nokia Technologies Oy
Publication of BRPI0513969A publication Critical patent/BRPI0513969A/pt
Publication of BRPI0513969B1 publication Critical patent/BRPI0513969B1/pt

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1863—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast comprising mechanisms for improved reliability, e.g. status reports
    • H04L12/1868—Measures taken after transmission, e.g. acknowledgments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/326—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the transport layer [OSI layer 4]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W99/00—Subject matter not provided for in other groups of this subclass
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607—Details of the supervisory signal
    • H04L1/1628—List acknowledgements, i.e. the acknowledgement message consisting of a list of identifiers, e.g. of sequence numbers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1809—Selective-repeat protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/189—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast in combination with wireless systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)
  • Eye Examination Apparatus (AREA)
  • Exchange Systems With Centralized Control (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Small-Scale Networks (AREA)
  • Optical Communication System (AREA)
  • Vehicle Body Suspensions (AREA)
  • Stored Programmes (AREA)

Abstract

método e sistema para transmitir símbolos de dados, transmissor, elemento de rede e receptor em um sistema para transmitir símbolos de dados, e, aplicativo de software esta invenção relaciona-se a um método, um sistema, um transmissor, um elemento de rede, um receptor e aplicativos de software em um sistema para transmitir símbolos de dados, em que um ou mais símbolos de dados são transmitidos de um transmissor para um ou mais receptores dentro de uma sessão de transmissão de ponto para multiponto, em que ditos símbolos de dados são fornecidos com cabeçalhos de primeiro tipo obedecendo um protocolo de entrega de arquivo, em que um ou mais símbolos de dados de reparo são transmitidos de um servidor de reparo para um receptor específico de ditos receptores dentro de uma sessão de reparo de ponto a ponto, e em que ditos símbolos de dados de reparo são fornecidos com um ou mais cabeçalhos de segundo tipo obedecendo pelo menos parcialmente dito mesmo protocolo de entrega de arquivo.

Description

Esta invenção relaciona-se a um método, um sistema, um transmissor, um elemento de rede, um receptor e aplicativos de software em um sistema para transmitir símbolos de dados, em que um ou mais símbolos de dados são transmitidos de um transmissor para um ou mais receptores em uma sessão de transmissão de ponto para multiponto, e em que um ou mais símbolos de dados de reparo são transmitidos de um servidor de reparo para um receptor específico de ditos receptores dentro de uma sessão de reparo de ponto a ponto.
FUNDAMENTO DA INVENÇÃO
Para serviços de ponto para multiponto (ptM) (também denotados como serviços de um para muitos) através de sistemas tal como a multidifusão de Protocolo de Internet (IP), o Lanamento de dados de IP (IPDC) e os Serviços de Radiodifusão/Multidifusão de Multimídia (MBMS), entrega de arquivo tal como por exemplo o carregamento de arquivos de multimídia, é um serviço importante.
Porém, muitas das características para entregar arquivos através de protocolos de ponto a ponto (PtP), tal como por exemplo o Protocolo de Transferencia de Arquivo (FTP) e o Protocolo de Transferencia de Hipertexto (HTTP), são problemáticos para cenários de PtM. Em particular, a entrega segura de arquivos, isto é, a entrega garantida de arquivos, usando protocolos de reconhecimento de PtP (ACK) semelhantes tal como o Protocolo de Controle de Transporte (TCP), não é possível.
O Grupo de Trabalo de Transporte de Multidifusão Segura (RMT) da Força - Tarefa de Engenharia Internacional (IETF) está atualmente
Petição 870180130973, de 17/09/2018, pág. 14/24
no processo de padronizar duas categorias de protocolos de transporte de multidifusão resiliente a erro. Na primeira categoria, confiabilidade é implementada pelo uso de realimentação de receptor, isto é, pelo receptor enviando reconhecimentos (ACKs) ou não reconhecimentos (NACKs) relativos a dados recebidos.
Codificação em Camadas Assíncrona (ALC) é uma exemplificação de protocolo pertencendo à primeira categoria, enquanto o protocolo de Multidifusão Segura orientado para NACK (NORM) pertence à segunda categoria. As redes de acesso nas quais estes protocolos poderiam ser usados incluem, mas não estão limitadas, a redes de acesso múltiplo sem fios tal como o Sistema de Telecomunicação Móvel Universal (UMTS, incluindo o Sistema Global para Rede de Acesso de Rádio de Evolução de Comunicação Móvel (GERAN) e a Rede de Acesso de Rádio Terrestre de UMTS (UTRAN), Redes de Área local Sem Fios (WLAN), Redes Terrestres de Radiodifusão de Vídeo Digital (DVB-T) e Redes de Satélite de Radiodifusão de Vídeo Digital (DVB-S).
Mensagens de NACK não são geralmente especificas de NORM, mas elas também podem ser usadas em relação a outros protocolos ou sistemas, por exemplo, com sistemas que suportam sessões que são controladas pelo protocolo de Entrega de Arquivo através de Transporte Unidirecional (FLUTE).
FLUTE é um protocolo de transporte de um para muitos que r
constrói blocos construtivos de FEC e ALC. E pretendido para entrega de arquivo de transmissores para receptores através de sistemas unidirecionais.
Tem especializações que o fazem adequado para sistemas de ponto para multiponto sem fios. Os detalhes do protocolo de FLUTE são discutidos em mais detalhe na publicação intitulada FLUTE - File Delivery Over Unidirectional Transport (Minuta de Internet) preparada pelo supracitado Grupo de Trabalho de RMT da IETF.
• · « · · · • · · • · · · • • · •
• · • · · • · • • · • · • «
• · • · · • • • · • * • ·
•
• · · < • • · · • • · • • ·
O uso de FLUTE é por exemplo especificado pelo Projeto de Sociedade de Terceira Geração (3GPP) para carregamento de arquivo em sessões do sistema de MBMS. FEC pode ou não ter sido usado em tais sessões de FLUTE. Em qualquer caso, nem todos os receptores na sessão podem ser esperados receberem o arquivo inteiro quando a sessão termina. Para este fim, 3GPP está no processo de definir sessões de reparo de ponto a ponto, em que os receptores são permitidos sinalizar pedidos para retransmissões de pacote de dados a um transmissor ou servidor de reparo por mensagens de NACK a fim de ser capaz de reconstruir o conteúdo carregado.
Em ditas mensagens de NACK, ditos símbolos de dados de reparo requeridos por ditos receptores têm que ser identificados suficientemente, de forma que o servidor de reparo possa determinar quais símbolos de dados têm que ser transmitidos ou re-transmitidos.
Quando um receptor é programado para uma sessão de reparo, uma sessão de PtP, por exemplo uma sessão de HTTP, é então estabelecida entre o receptor e o servidor de reparo, no qual os símbolos de dados de reparo requeridos são transmitidos ao receptor.
Embora os símbolos de dados sejam transmitidos em uma sessão de PtM, que é baseada em um protocolo não segura, como por exemplo o Protocolo de Datagrama de Usuário (UDP), e os símbolos de dados de reparo são transmitidos em uma sessão de PtP, que é baseada em um protocolo segura, tal como por exemplo o Protocolo de Controle de Transporte (TCP), símbolos de dados de reparo são fornecidos atualmente com a mesma informação de cabeçalho como os símbolos de dados. Esta informação de cabeçalho inclui:
- um cabeçalho de Transporte de Codificação em Camadas (LCT) prefixado;
- uma seção de Extensões de Cabeçalho de LTC; e
- uma seção de ID de Carga útil de FEC.
• · • · · · · · · • · · · • • · •
• α • · · * · • • · ·· • ·
• · • · 9 · • • 4 • · • ·
« · · « * • · · • • · • > «
O cabeçalho de LCT inclui:
- uma primeira seção com um arranjo de indicadores, um campo de comprimento de cabeçalho de LCT e um campo de Ponto de Código para sinalizar o ID de Codificação de FEC;
- uma Informação de Controle de Congestão (CCI);
- um Identificador de Sessão de Transporte (TSI);
- um Identificador de Objeto de Transporte (TOI);
- um Tempo Atual de Remetente (SCT); e
- um Tempo Residual Esperado (ERT).
Porém, símbolos de dados de reparo deveríam ser enviados do modo mais eficiente tal que o receptor possa identificar facilmente os símbolos de dados de reparo e terminar decodificação dos arquivos que foram carregados parcialmente durante a sessão de PtM de multidifiisão/radiodifusão. O custo incorrido na transmissão de símbolos de dados de reparo, que representa normalmente uma retransmissão de símbolos de dados já enviados, deveria assim ser mantido pequeno para reduzir o tempo de resposta de PtP enquanto mantendo as operações de receptor simples.
SUMÁRIO DA INVENÇÃO
Assim existe uma necessidade por um método, sistema, transmissor, elemento de rede, receptor e aplicativo de software mais eficientes em um sistema para transmitir símbolos de dados em ambas sessões de ponto para multiponto e de ponto a ponto.
É proposto um método para transmitir símbolos de dados, incluindo transmitir um ou mais símbolos de dados de um transmissor para um ou mais receptores dentro de uma sessão de transmissão de ponto para multiponto, em que ditos símbolos de dados são fornecidos com cabeçalhos de primeiro tipo obedecendo um protocolo de entrega de arquivo; e transmitir um ou mais símbolos de dados de reparo de um servidor de reparo para um
9 · • « A • • · · • • · · • • · 9
• < • • « ·· • 9 9 9 9 9 9
(' · • • • c • • · 9 9 9 ·
• • • · • • · • • 9 9
• • · · • • · « • 9 9 9 9
receptor específico de ditos receptores dentro de uma sessão de reparo de ponto a ponto, em que ditos símbolos de dados de reparo são fornecidos com um ou mais cabeçalhos de segundo tipo obedecendo pelo menos parcialmente dito mesmo protocolo de entrega de arquivo.
Dito sistema pode representar qualquer sistema de sem fios ou ligado por fios, em que símbolos de dados são transmitidos de pelo menos um transmissor para um ou mais receptores. Dita transmissão de ponto para multiponto pode ser tanto uma transmissão radiodifundida, na qual todos os receptores são endereçados por dito transmissor, ou uma transmissão de multidifusão, na qual só um subgrupo de todos os receptores é endereçado por dito transmissor. Dito sistema pode ser desdobrado por exemplo no contexto de UMTS, uma LAN, um WLAN, DVB-T ou DVB-S, e pode ser pretendido para distribuir conteúdo tal como por exemplo arquivos de multimídia para uma pluralidade de receptores. Dita transmissão de ditos um ou mais símbolos de dados pode ser executada em ligações de transmissão unidirecionais ou bidirecionais.
Ditos símbolos de dados transmitidos podem por exemplo ser relacionados a conteúdo que é para ser transferido a ditos receptores. Este conteúdo pode ser segmentado e processado para permitir a transmissão a ditos receptores, enquanto ditos símbolos de dados são para serem entendidos como o resultado desta segmentação e processamento. Por exemplo, um símbolo de dados pode representar um ou mais símbolos de codificação (por exemplo, um pacote de codificação) obtido por codificação de FEC de um objeto de transporte, por exemplo um arquivo de multimídia, ou partes dele.
Nele, cada símbolo de dados pode representar só uma unidade portadora de informação, por exemplo um dígito binário (bit), ou uma pluralidade de unidades portadoras de informação.
Dito símbolos de dados são fornecidos com cabeçalhos de primeiro tipo obedecendo um protocolo de entrega de arquivo, por exemplo o • · ··« • · <
• · ·· • · • · · • « · • · · ··· · ·· · • · · · · · • « · ·· · · • ·· · · ·· • · · * < · protocolo de FLUTE. Dito fornecimento pode ser executado por exemplo adicionando dito cabeçalho a ditos símbolos de dados ou por outras técnicas de criar uma associação entre dito cabeçalho de primeiro tipo e ditos símbolos de dados. Dito símbolos de dados de primeiro tipo e seus símbolos de dados associados podem formar por exemplo um pacote de FLUTE. Os cabeçalhos de primeiro tipo podem por exemplo conter informação relacionada à transferência lógica de ditos símbolos de dados entre entidades de protocolo em dito transmissor e ditos receptores.
Pelo menos em um de ditos receptores, que e denotado como receptor específico, uma recepção de símbolos de dados de reparo é requerida, que pode ser devido a uma pluralidade de razões, tal como por exemplo recepção incorreta ou perda de símbolos de dados transmitidos. Dito receptor específico pode se tomar ciente do requisito para receber símbolos de dados de reparo durante dita transmissão de símbolos de dados ou depois que a transmissão de símbolos de dados terminou.
Dito símbolos de dados de reparo podem ser por exemplo cópias simples dos símbolos de dados transmitidos que não foram recebidos por dito receptor específico. Igualmente bem, eles podem ser diferentes com respeito a ambos codificação e conteúdo atual. Símbolos de dados de reparo servem ao propósito de prover dito receptor específico com essa quantidade de informação que é requerida por dito receptor específico.
A fim de ativar uma transmissão de símbolos de dados de reparo de dito servidor de reparo, dito receptor específico pode sinalizar informação de dados de reparo para dito servidor de reparo em uma mensagem de pedido de reparo. Isto pode acontecer em uma transferência de ponto a ponto. O servidor de reparo é assim habilitado a gerar os símbolos de dados de reparo apropriados e transmiti-los ao receptor específico. Esta transferência de símbolos de dados de reparo é executada em uma sessão de reparo de ponto a ponto.
• · · · • · · · ·
Ditos símbolos de dados de reparo são fornecidos com um ou mais cabeçalhos de segundo tipo obedecendo pelo menos parcialmente dito mesmo protocolo de entrega de arquivo. Ditos cabeçalhos de símbolos de dados de segundo tipo assim podem por exemplo obedecer completamente dito protocolo de entrega de arquivo, que então é requerido para definir pelo menos dois tipos diferentes de cabeçalhos de símbolos de dados. Igualmente bem, ditos cabeçalhos de segundo tipo podem representar uma modificação de um ou mais cabeçalhos de símbolos de dados que são definidos por dito protocolo de entrega de arquivo, em que dita modificação pode incluir todas as formas de adicionar, remover ou mudar parâmetros de ditos cabeçalhos de primeiro tipo como também combinar vários cabeçalhos de primeiro tipo possivelmente modificados. Preferivelmente, ditas modificações podem só incluir uma redução de ditos cabeçalhos de primeiro tipo removendo pelo menos um parâmetro de dito cabeçalho de primeiro tipo. Dito fornecimento pode ser realizado por exemplo adicionando um cabeçalho de segundo tipo a um símbolo de dados de reparo, ou por outras técnicas de associar ditos símbolos de dados de reparo com ditos cabeçalhos de segundo tipo. Por exemplo, vários símbolos de dados de reparo podem ser combinados em um pacote de HTTP, e um cabeçalho de segundo tipo também pode ser incluído em dito pacote de HTTP, em que dito cabeçalho de segundo tipo então inclui informação válida para todos os símbolos de dados de reparo em dito pacote de HTTP.
A presente invenção assim propõe usar tipos diferentes de cabeçalhos para transferência de símbolos de dados, por um lado, e símbolos de dados de reparo, por outro lado. Esta proposta considera o fato que símbolos de dados são transmitidos em sessões de ponto para multiponto que são baseadas’ em protocolos não confiáveis (por exemplo, UDP), enquanto símbolos de dados de reparo são transmitidos em sessões de ponto a ponto que são baseadas em protocolos confiáveis (por exemplo, TCP), de forma que • ·
pelo menos alguns dos parâmetros que têm que ser incluídos em cabeçalhos de primeiro tipo que são usados para os símbolos de dados não tem que ser contidos em cabeçalhos de símbolos de dados de segundo tipo que são usados por símbolos de dados de reparo. Esta abordagem de acordo com a presente invenção permite uma transferência mais eficiente de símbolos de dados de reparo com um custo significativamente reduzido. Com os cabeçalhos de segundo tipo obedecendo pelo menos parcialmente dito protocolo de entrega de arquivo, nenhuma ou só mudanças secundárias podem ser requeridas em ambos os exemplos de protocolo do servidor de reparo e dos receptores e as implementações correspondentes.
De acordo com a presente invenção, dito cabeçalho de primeiro tipo pode conter pelo menos um parâmetro que não está contido em dito cabeçalho de segundo tipo, e dito parâmetro pode ser relacionado à transmissão de ponto para multiponto. Dito parâmetro pode por exemplo ser uma Informação de Controle de Congestão (CCI), um Tempo Atual de Remetente (SCT), um Tempo Residual Esperado (ERT), e em alguns casos, um Identificador de Sessão de Transporte (TSI).
De acordo com a presente invenção, em dita sessão de transmissão de ponto para multiponto, dito protocolo de entrega de arquivo pode usar os serviços do Protocolo de Datagrama de Usuário.
De acordo com a presente invenção, em dita sessão de reparo de ponto a ponto, dito protocolo de entrega de arquivo pode usar os serviços do Protocolo de Controle de Transporte.
De acordo com a presente invenção, em dita sessão de reparo de ponto a ponto, dito protocolo de entrega de arquivo pode usar os serviços do Protocolo de Transferência de Hipertexto. Este protocolo pode por sua vez usar os serviços do Protocolo de Controle de Transporte.
De acordo com a presente invenção, dito protocolo de entrega de arquivo pode ser o protocolo de Entrega de Arquivo através de Transporte • ·
Unidirecional, FLUTE, e ditos símbolos de dados e ditos símbolos de dados de reparo podem representar símbolos de codificação de FLUTE. Ditos símbolos de codificação de FLUTE podem ser por exemplo obtidos através de codificação de correção de erro dianteira de porções de um objeto de transporte que é para ser entregue a dito um ou mais receptores em dita sessão de ponto para multiponto. Cada símbolo de dados pode por exemplo representar um ou vários símbolos de codificação.
De acordo com a presente invenção, dito protocolo de FLUTE pode usar os serviços do Protocolo de Transferência de Hipertexto, HTTP, e dito HTTP pode transferir pacotes de HTTP entre dito servidor de reparo e dito receptor específico. Para este fim, ditos símbolos de dados e seus associados um ou mais cabeçalhos de segundo tipo podem ser incorporados como carga útil em ditos pacotes de HTTP.
De acordo com uma primeira concretização da presente invenção, uma combinação de um símbolo de codificação de FLUTE e um cabeçalho de segundo tipo associado forma um pacote de FLUTE comprimido, e pelo menos um de ditos pacotes de HTTP inclui um cabeçalho de pacote de HTTP e um ou mais de ditos pacotes de FLUTE comprimidos.
De acordo com dita primeira concretização da presente invenção, dito cabeçalho de segundo tipo de ditos pacotes de FLUTE comprimidos pelo menos inclui uma porção de um cabeçalho de Transporte de Codificação em Camadas, um identificador de dito símbolo de codificação de FLUTE em dito pacote de FLUTE comprimido, e um tamanho de dito símbolo de codificação de FLUTE. Dito cabeçalho de Transporte de
Codificação em Camadas pode se originar do bloco construtivo de Transporte de Codificação em Camadas no qual a camada de protocolo de FLUTE está construída em cima. Dito identificador de dito símbolo de codificação de FLUTE pode ser por exemplo um ID de Carga útil de FEC provendo um Número de Bloco de Fonte (SBN) e um Identificador de Símbolo de • · ···· ··· · • · · · · ·Λ · ··
Codificação (ESI) correspondendo a dito símbolo de codificação de FLUTE.
De acordo com uma segunda concretização da presente invenção, dito pelo menos um pacote de HTTP tem uma estrutura de Extensões de Correio de Internet de Multi-propósito de multi-partes, MIME, e ditos pacotes de FLUTE comprimidos são separados de dito cabeçalho de pacote de HTTP e entre si por limites de MIME. Dita separação por limites de MIME então pode permitir saltar um parâmetro para o tamanho de símbolo de codificação em ditos cabeçalhos de segundo tipo.
De acordo com dita segunda concretização da presente invenção, dito cabeçalho de segundo tipo de ditos pacotes de FLUTE comprimidos inclui uma porção de um cabeçalho de Transporte de Codificação em Camadas, e um identificador de dito símbolo de codificação de FLUTE em dito pacote de FLUTE comprimido.
De acordo com uma terceira concretização da presente invenção, pelo menos um de ditos pacotes de HTTP inclui um cabeçalho de pacote de HTTP, um ou mais blocos que incluem pelo menos dois símbolos de codificação de FLUTE e identificadores associados respectivos, e um cabeçalho de segundo tipo respectivo para cada um de ditos blocos, em que cada cabeçalho de segundo tipo respectivo é válido para todos os símbolos de codificação de FLUTE de um bloco respectivo. A combinação de símbolos de codificação de FLUTE em blocos permite usar só um cabeçalho de segundo tipo para cada bloco em vez de ter que prover um cabeçalho de segundo tipo por símbolo de codificação de FLUTE. Ditos símbolos de codificação de FLUTE combinados em um bloco vantajosamente têm as mesmas características, por exemplo mesmo tamanho, mesmo TOI e mesmo TSI, e as características que são diferentes para cada símbolo de codificação de FLUTE então podem ser incorporadas em ditos blocos de símbolos de codificação de FLUTE.
De acordo com dita terceira concretização da presente
invenção, dito pelo menos um pacote de HTTP tem uma estrutura de MIME, e dito cabeçalho de pacote de HTTP, ditos blocos e dito cabeçalhos de segundo tipo estão separados mutuamente por limites de MIME. Pode então não ser requerido transmitir explicitamente o tamanho do bloco de símbolos de codificação de FLUTE.
De acordo com dita terceira concretização da presente invenção, ditos cabeçalhos de segundo tipo respectivos incluem uma porção de um cabeçalho de Transporte de Codificação em Camadas e um tamanho de ditos símbolos de codificação de FLUTE em ditos blocos respectivos.
De acordo com dita terceira concretização da presente invenção, pelo menos um de ditos blocos inclui um símbolo de codificação de FLUTE, um identificador associado respectivo, um comprimento de cabeçalho de Transporte de Codificação em Camadas respectivo e pelo menos uma extensão de cabeçalho de Transporte de Codificação em Camadas. Dita extensão de cabeçalho de LCT pode ser por exemplo uma EXT_FTI ou uma EXTJFDT. Dito comprimento de cabeçalho de LCT respectivo pode indicar se uma ou mais de ditas extensões de cabeçalho de LCT estão presentes ou não.
De acordo com uma quarta concretização da presente invenção, pelo menos um de ditos pacotes de HTTP inclui um cabeçalho de pacote de HTTP, um cabeçalho de segundo tipo e um ou mais blocos que incluem pelo menos dois símbolos de codificação de FLUTE. Então, só um cabeçalho de segundo tipo é usado para todos os símbolos de codificação de FLUTE contidos em dito pacote de HTTP, que serve como um objeto de índice que provê toda a informação de cabeçalho para todos de ditos símbolos de codificação de FLUTE. Dito cabeçalho de segundo tipo então pode ser por exemplo segmentado em subcabeçalhos que estão relacionados a cada um de ditos blocos de símbolos de codificação de FLUTE.
De acordo com dita quarta concretização da presente invenção,
dito pelo menos um pacote de HTTP tem uma estrutura de MIME, e dito cabeçalho de pacote de HTTP, dito um cabeçalho de segundo tipo e dito um ou mais blocos estão separados mutuamente por limites de MIME. Isto pode permitir saltar a transmissão explícita do tamanho dos blocos de símbolos de codificação de FLUTE.
De acordo com dita quarta concretização da presente invenção, dito cabeçalho de segundo tipo inclui um subcabeçalho respectivo para cada bloco respectivo em dito pacote de HTTP, e cada um de ditos subcabeçalhos respectivos inclui uma porção de um cabeçalho de Transporte de Codificação em Camadas, o tamanho de ditos símbolos de codificação de FLUTE em dito bloco respectivo, o número de símbolos de codificação de FLUTE em dito bloco respectivo, e um identificador para cada símbolo de codificação de FLUTE em dito bloco respectivo.
De acordo com dita quarta concretização da presente invenção, pelo menos um de ditos subcabeçalhos inclui um comprimento de cabeçalho de Transporte de Codificação em Camadas para cada símbolo de codificação de FLUTE em dito bloco respectivo, e pelo menos uma extensão de cabeçalho de Transporte de Codificação em Camadas para pelo menos um de ditos símbolos de codificação de FLUTE em dito bloco respectivo. Dita extensão de cabeçalho de LCT pode ser por exemplo uma EXT_FDT ou uma EXTFTI. Dito comprimento de cabeçalho de LCT pode indicar se uma ou mais de ditas extensões de cabeçalho de LCT estão presentes ou não.
De acordo com a presente invenção, dito cabeçalho de segundo tipo pode ademais incluir um identificador de dita sessão de transmissão de ponto para multiponto. Dito identificador pode ser por exemplo um Identificador de Sessão de Transporte (TSI). Porém, se só uma sessão de transmissão estiver presente ou se estiver implicitamente claro do contexto a qual sessão de transmissão ditos símbolos de codificação de FLUTE se referem, dito identificador de dita sessão de transmissão pode não ser requerido.
De acordo com a presente invenção, dito cabeçalho de segundo tipo pode ademais incluir um identificador de um objeto de transporte ao qual ditos símbolos de codificação de FLUTE estão relacionados. Este identificador pode ser por exemplo um Identificador de Objeto de Transporte (TOI). Porém, se só um objeto de transporte for transmitido por sessão de transporte, dito identificador pode não ser requerido.
De acordo com a presente invenção, dito cabeçalho de segundo tipo pode ademais incluir extensões de cabeçalho de Transporte de Codificação em Camadas. Estas Extensões de cabeçalho de LTC podem ser por exemplo uma EXT_FTI ou uma EXTJFDT.
De acordo com a presente invenção, dita porção de dito cabeçalho de Transporte de Codificação em Camadas pode incluir um número de versão de Transporte de Codificação em Camadas, um indicador de Controle de Congestão, um espaço reservado, um indicador de Identificador de Sessão de Transporte, um indicador de Identificador de Objeto de Transporte TOI, um indicador de Meia-palavra, um indicador de Tempo Corrente de Remetente, um indicador de Tempo Residual Esperado, um indicador de Fechar Sessão, um indicador de Fechar Objeto, um comprimento de cabeçalho de Transporte de Codificação em Camadas, e um Ponto de Código. Dita porção de dito cabeçalho de Transporte de Codificação em Camadas pode ser por exemplo de 4 bytes de comprimento.
r
E ademais proposto um sistema para transmitir símbolos de dados, incluindo um transmissor, um ou mais receptores, e um servidor de reparo, em que um ou mais símbolos de dados são transmitidos de dito transmissor para dito um ou mais receptores dentro de uma sessão de transmissão de ponto para multiponto, em que ditos símbolos de dados são fornecidos com cabeçalhos de primeiro tipo obedecendo um protocolo de entrega de arquivo, em que um ou mais símbolos de dados de reparo são transmitidos de dito servidor de reparo para um receptor específico de ditos receptores dentro de uma sessão de reparo de ponto a ponto, e em que ditos símbolos de dados de reparo são fornecidos com um ou mais cabeçalhos de segundo tipo obedecendo pelo menos parcialmente dito mesmo protocolo de entrega de arquivo.
De acordo com o sistema da presente invenção, dito cabeçalho de primeiro tipo pode conter pelo menos um parâmetro que não está contido em dito cabeçalho de segundo tipo, e dito parâmetro pode ser relacionado à transmissão de ponto para multiponto.
r
E ademais proposto um transmissor em um sistema para transmitir símbolos de dados, incluindo meio arranjado para transmitir um ou mais símbolos de dados de dito transmissor para um ou mais receptores dentro de uma sessão de transmissão de ponto para multiponto, em que ditos símbolos de dados são fornecidos com cabeçalhos de primeiro tipo obedecendo um protocolo de entrega de arquivo, em que um ou mais símbolos de dados de reparo são transmitidos de um servidor de reparo para um receptor específico de ditos receptores dentro de uma sessão de reparo de ponto a ponto, e em que ditos símbolos de dados de reparo são fornecidos com um ou mais cabeçalhos de segundo tipo obedecendo pelo menos parcialmente dito mesmo protocolo de entrega de arquivo. Dito transmissor e dito servidor de reparo podem ser co-localizados ou até mesmo idênticos.
De acordo com o transmissor da presente invenção, dito cabeçalho de primeiro tipo pode conter pelo menos um parâmetro que não está contido em dito cabeçalho de segundo tipo, e dito parâmetro pode ser relacionado à transmissão de ponto para multiponto.
É ademais proposto um elemento de rede em um sistema para transmitir símbolos de dados, em que um ou mais símbolos de dados são transmitidos de um transmissor para um ou mais receptores dentro de uma sessão de transmissão de ponto para multiponto, e em que ditos símbolos de dados são fornecidos com cabeçalhos de primeiro tipo obedecendo um protocolo de entrega de arquivo, dito elemento de rede incluindo meio arranjado para transmitir um ou mais símbolos de dados de reparo de dito elemento de rede para um receptor específico de ditos receptores dentro de uma sessão de reparo de ponto a ponto, em que ditos símbolos de dados de reparo são fornecidos com um ou mais cabeçalhos de segundo tipo obedecendo pelo menos parcialmente dito mesmo protocolo de entrega de arquivo. Dito transmissor e dito elemento de rede podem ser co-localizados ou até mesmo idênticos. Dito elemento de rede pode ser por exemplo um servidor de reparo.
De acordo com o elemento de rede da presente invenção, dito cabeçalho de primeiro tipo pode conter pelo menos um parâmetro que não está contido em dito cabeçalho de segundo tipo, e dito parâmetro pode ser relacionado à transmissão de ponto para multiponto.
E ademais proposto um aplicativo de software executável em um elemento de rede de um sistema para transmitir símbolos de dados, em que um ou mais símbolos de dados são transmitidos de um transmissor para um ou mais receptores dentro de uma sessão de transmissão de ponto para multiponto, e em que ditos símbolos de dados são fornecidos com cabeçalhos de primeiro tipo obedecendo um protocolo de entrega de arquivo, o aplicativo de software incluindo código de programa para fazer o elemento de rede transmitir um ou mais símbolos de dados de reparo de dito elemento de rede para um receptor específico de ditos receptores dentro de uma sessão de reparo de ponto a ponto, em que dito símbolos de dados de reparo são fornecidos com um ou mais cabeçalhos de segundo tipo obedecendo pelo menos parcialmente dito mesmo protocolo de entrega de arquivo.
Dito aplicativo de software também pode ser um produto de programa de computação, incluindo código de programa que é armazenado • · · · · ·· · · ·· • · · · · · · ··· · • · ··· · ·· · ·>
em um meio, como por exemplo uma memória de dito elemento de rede.
De acordo com o aplicativo de software da presente invenção, dito cabeçalho de primeiro tipo pode conter pelo menos um parâmetro que não está contido em dito cabeçalho de segundo tipo, e dito parâmetro pode ser relacionado à transmissão de ponto para multiponto.
r
E ademais proposto um receptor em um sistema para transmitir símbolos de dados, incluindo meio arranjado para receber um ou mais símbolos de dados transmitidos de um transmissor para um ou mais receptores dentro uma sessão de transmissão de ponto para multiponto, em que ditos símbolos de dados são fornecidos com cabeçalhos de primeiro tipo obedecendo um protocolo de entrega de arquivo; e meio arranjado para receber um ou mais símbolos de dados de reparo de um servidor de reparo dentro de uma sessão de reparo de ponto a ponto, em que ditos símbolos de dados de reparo são fornecidos com um ou mais cabeçalhos de segundo tipo obedecendo pelo menos parcialmente dito mesmo protocolo de entrega de arquivo.
De acordo com o receptor da presente invenção, dito cabeçalho de primeiro tipo pode conter pelo menos um parâmetro que não está contido em dito cabeçalho de segundo tipo, e dito parâmetro pode ser relacionado à transmissão de ponto para multiponto.
É ademais proposto um aplicativo de software executável em um receptor de um sistema para transmitir símbolos de dados, o aplicativo de software incluindo código de programa para fazer o receptor receber um ou mais símbolos de dados transmitidos de um transmissor para um ou mais receptores dentro de uma sessão de transmissão de ponto para multiponto, em que ditos símbolos de dados são fornecidos com cabeçalhos de primeiro tipo obedecendo um protocolo de entrega de arquivo; e código de programa para fazer o receptor receber um ou mais símbolos de dados de reparo de um servidor de reparo dentro de uma sessão de reparo de ponto a ponto, em que • · · • · · · • · · • · · ·
2i ditos símbolos de dados de reparo são fornecidos com um ou mais cabeçalhos de segundo tipo obedecendo pelo menos parcialmente dito mesmo protocolo de entrega de arquivo.
Dito aplicativo de software também pode ser um produto de 5 programa de computação, incluindo código de programa que é armazenado em um meio, como por exemplo uma memória de dito receptor.
De acordo com o aplicativo de software da presente invenção, dito cabeçalho de primeiro tipo pode conter pelo menos um parâmetro que não está contido em dito cabeçalho de segundo tipo, e dito parâmetro pode ser relacionado à transmissão de ponto para multiponto.
Estes e outros aspectos da invenção serão aparentes e elucidados com referência às concretizações descritas em seguida.
BREVE DESCRIÇÃO DOS DESENHOS
Nas figuras mostram:
Figura la: uma apresentação esquemática de uma transmissão de símbolos de dados em uma sessão de transmissão de ponto para multiponto (PtM) de acordo com a presente invenção;
Figura lb: uma apresentação esquemática da sinalização de um pedido para símbolos de dados de reparo dentro de uma sessão de reparo de ponto a ponto (PtP) de acordo com a presente invenção;
Figura lc: uma apresentação esquemática da transmissão de símbolos de dados de reparo em uma sessão de reparo de PtP de acordo com a presente invenção;
Figura 2a: uma apresentação esquemática da pilha de protocolo usada para a transmissão de símbolos de dados na sessão de transmissão de PtM de acordo com a presente invenção;
Figura 2b: uma apresentação esquemática da pilha de protocolo usada para a transmissão de símbolos de dados de reparo na sessão de reparo de PtP de acordo com a presente invenção;
Figura 3a: uma apresentação esquemática de um pacote de FLUTE comprimido de acordo com uma primeira concretização da presente invenção;
Figura 3b: uma apresentação esquemática do embutimento de 5 pacotes de FLUTE comprimidos em um pacote de HTTP de acordo com a primeira concretização da presente invenção;
Figura 4a: uma apresentação esquemática de um pacote de FLUTE comprimido de acordo com uma segunda concretização da presente invenção;
Figura 4b: uma apresentação esquemática do embutimento de pacotes de FLUTE comprimidos em um pacote de HTTP de acordo com a segunda concretização da presente invenção;
Figura 5a: uma apresentação esquemática de um pacote de HTTP de acordo com uma terceira concretização da presente invenção;
Figura 5b: uma apresentação esquemática de um cabeçalho de
FLUTE comum de acordo com a terceira concretização da presente invenção;
Figura 5c: uma apresentação esquemática de um bloco de símbolos de codificação de acordo com a terceira concretização da presente invenção;
Figura 5d: uma apresentação esquemática de um bloco alternativo de símbolos de codificação no caso que extensões de cabeçalho de LTC são usadas de acordo com a terceira concretização da presente invenção;
Figura 6a: uma apresentação esquemática de um pacote de HTTP de acordo com uma quarta concretização da presente invenção;
Figura 6b: uma apresentação esquemática de um cabeçalho de objeto de índice de acordo com a quarta concretização da presente invenção;
Figura 6c: uma apresentação esquemática de um bloco de símbolos de codificação de acordo com a quarta concretização da presente invenção;e
Figura 7: um fluxograma exemplar do método de acordo com a presente invenção.
DESCRIÇÃO DETALHADA DA INVENÇÃO
Como uma observação inicial, deveria ser notado que o assunto da parte introdutória deste pedido de patente pode ser usado para suportar esta descrição detalhada.
A presente invenção propõe usar dois tipos de cabeçalho diferentes para a transmissão de PtM de símbolos de dados de um transmissor para uma pluralidade de receptores, por um lado, e a transmissão de PtP ou símbolos de dados de reparo de um servidor de reparo para um de ditos receptores, por outro lado. Isto considera o fato que a transmissão de símbolos de dados é baseada em protocolos não confiáveis, como por exemplo o UDP, e assim requer mais informação de custo como a transmissão de símbolos de dados de reparo, que é baseada em protocolos mais confiáveis tal como por exemplo o TCP.
Nesta descrição detalhada da invenção, freqüentemente referência será feita ao caso onde FLUTE/UDP é usado no caso de transmissão de PtM e onde HTTP/TCP é usado no caso de transmissão de PtP. Deveria ser notado que esta escolha só é de natureza exemplar e que a presente invenção pode ser aplicada igualmente bem em cenários semelhantes onde símbolos de dados, que obedecem um certo protocolo e são transmitidos em um cenário de PtM primeiro, então tem que ser re-transmitidos em um cenário de PtP e nele pelo menos parcialmente tem que aderir a dito protocolo.
Figura la descreve uma sessão de PtM, em que símbolos de dados são transmitidos de um transmissor 1 para uma pluralidade de receptores 3-1,..., 3-3. O transmissor está conectado a uma rede 2, por exemplo a Internet, e assim tem acesso a conteúdo que é para ser distribuído a dita pluralidade de receptores em uma sessão de radiodifusão ou multidifusão,
por exemplo na extensão do sistema de MBMS de 3GPP. Para este fim, o transmissor inclui um processador 10, uma memória 11 e um exemplo de transmissão/recepção (Tx/Rx). Conteúdo é coletado da rede 2 sob o controle do processador 10, possivelmente armazenado intermediariamente na memória 11 e então codificado e modulado para transmissão pelo exemplo de Tx/Rx 12 aos exemplos de Tx/Rx 32 dos receptores 3-1,..., 3-3. Dito processador 10 é entendido implementar a funcionalidade de todas as camadas da pilha de protocolo de ISO/OSI, em particular a codificação de conteúdo em símbolos de codificação de FLUTE que, junto com um cabeçalho de FLUTE, formam um pacote de FLUTE, e a geração destes cabeçalhos de FLUTE é executada por dito processador 10.
Em ditos receptores 3-1,..., 3-3, dos quais só o receptor específico 3-1 é descrito em mais detalhe, os pacotes de FLUTE são recebidos pelo exemplo de Tx/Rx 32, demodulados e decodificados pelo processador 30 e armazenados na memória 31 como entrada para qualquer tipo de aplicativo correndo em dito receptor ou um dispositivo anexado.
Figura lb descreve o caso quando pacotes de FLUTE não foram recebidos corretamente em dito receptor específico 3-1, ou quando pacotes de FLUTE não suficientes foram recebidos em dito receptor específico 3-1, de forma que a transmissão de símbolos de dados de reparo que permitem a dito receptor específico 3-1 reconstruir o conteúdo completo que é distribuído por dito transmissor 1 tenha que ser pedida. Para este fim, uma mensagem de pedido de reparo é enviada de receptor 3-1 para um servidor de reparo 4, que tem uma instalação semelhante como transmissor 1 e pode até mesmo ser idêntica a dito transmissor 1. A transmissão de ditas mensagens de pedido de reparo pode acontecer por exemplo em uma sessão de HTTP. Dito servidor de reparo 4 então processa dita mensagem de pedido de reparo, que contém informação relacionada aos pacotes de FLUTE requeridos por dito receptor específico 3-1.
Figura lc descreve o resultado deste processamento do servidor de reparo 4. Quando o servidor de reparo 4 determinou os símbolos de codificação de FLUTE que têm que ser enviados ao receptor específico 3-1 como símbolos de dados de reparo em uma resposta de reparo, busca informação requerida para gerar estes símbolos de dados de reparo da rede 2, por exemplo o objeto de transporte ou partes dele às quais os símbolos de codificação de FLUTE requeridos se relacionam. Baseado neste objeto de transporte, os símbolos de dados de reparo (símbolos de codificação de FLUTE) são gerados por processador 40, fornecidos com um cabeçalho de FLUTE comprimido para obter um pacote de FLUTE comprimido, e então transmitidos ao receptor específico 3-1 em uma mensagem de resposta de reparo.
De acordo com a presente invenção, o servidor de reparo 4 assim usa um cabeçalho de FLUTE comprimido para os símbolos de dados de reparo como comparado ao cabeçalho de FLUTE que é usado para os símbolos de dados no pacote de FLUTE, isto é, o cabeçalho de FLUTE comprimido inclui menos parâmetros ou informação do que dito cabeçalho de FLUTE. Por exemplo, todos os parâmetros que são específicos para transmissão de PtM e não são requeridos em uma transmissão de PtP podem ser saltados em dito cabeçalho de FLUTE comprimido. Também é possível que vários símbolos de codificação de FLUTE compartilhem o mesmo cabeçalho de FLUTE comprimido.
Figura 2a descreve esquematicamente a pilha de protocolo que é usada para a transmissão de PtM de símbolos de codificação de FLUTE (contidos em pacotes de FLUTE) de entidades de protocolo de FLUTE no transmissor 1 para entidades de protocolo de FLUTE de par nos receptores 31,..., 3-3. Para transferir os pacotes de FLUTE, a camada de FLUTE 51 usa os serviços da camada de UDP 53, que por sua vez usa os serviços da camada de Protocolo de Internet (IP) 53. A transferência atual dos pacotes de IP é então
• · • · • · * • · realizada pelas camadas inferiores 54 da pilha de protocolo. Nelas, um cabeçalho de FLUTE em correspondência com o protocolo de FLUTE é usado.
Figura 2b descreve esquematicamente a pilha de protocolo que é usada para a transmissão de PtP de símbolos de codificação de FLUTE (contidos em pacotes de FLUTE comprimidos) de entidades de protocolo de FLUTE no servidor de reparo 4 para entidades de protocolo de FLUTE de par no receptor específico 3-1. Neste caso, cabeçalhos de FLUTE comprimidos são usados. Em contraste à pilha de protocolo da Figura 2a, a camada de protocolo de FLUTE 51 agora usa o serviço de transmissão de PtP da camada de HTTP 55 subjacente, que reside no topo da camada de TCP 56. Para este fim, os pacotes de FLUTE comprimidos são embutidos em pacotes de HTTP que então são transferidos entre entidades de HTTP semelhantes no servidor de reparo 4 e no receptor específico 3-1. Para esta transferência, o HTTP/TCP usa os serviços da camada de IP 53 subjacente. Semelhante à Figura 2a, os pacotes de IP são então transferidos pelas camadas inferiores 54.
PRIMEIRA CONCRETIZAÇÃO DA INVENÇÃO
Figura 3a descreve um pacote de FLUTE comprimido 8 de acordo com uma primeira concretização da presente invenção. Este pacote de FLUTE comprimido 8 consiste em um cabeçalho de FLUTE comprimido 6 e um símbolo de codificação 7 como carga útil.
Certos campos nos pacotes de FLUTE que são usados na transmissão de PtM não são precisados mais na sessão de reparo de PtP porque a resposta de reparo é entregue através de uma ligação de TCP segura ao invés de pacotes de FLUTE na sessão de PtM que são entregues através de ligações de UDP não confiáveis. Assim, a presente invenção propõe fragmentar os pacotes de FLUTE a um mínimo enquanto assegurando que só os campos essenciais sejam incluídos no formato de carga útil de resposta de PtP que é usado na sessão de reparo.
Ti
♦ * • · · • • · · «
• · A • * • · ·
• « • • · *· ·
• * • « · • ·
• • · • · ·
• · · • • · ·
* · · · · • · · · • ♦ · ·· • · * · • · · · • * * · ··
O cabeçalho de FLUTE comprimido da Figura 3 a inclui os primeiros 4 bytes do cabeçalho de Transporte de Codificação em Camadas (LCT) 61 prefixado. Os campos 6100-6111 correspondentes e seus significados permanecem os mesmos. Os campos de indicador de TSI 6103, indicador de TOI 6104 e indicador de Meia-palavra 6105 provêem informação sobre o tamanho do campo de TSI 62 e campo de TOI 63. O campo de Ponto de Código 6111 é usado para sinalizar o ID de Codificação de FEC como especificado pelo protocolo de FLUTE. Alguns campos como o indicador de Controle de Congestão 6101, o Indicador de Tempo Atual de
Remetente 6106, o indicador de Tempo Residual Esperado 6107, o indicador de Fechar Sessão 6108, e o indicador de Fechar Objeto 6109 podem não ser enviados na resposta de PtP porque eles não são úteis quando enviados através de uma conexão de PtP segura. O conteúdo e tamanhos em bits dos campos da seção de cabeçalho de LCT 61 podem ser resumidos como segue:
V = Número de versão de LCT (4 bits)
C = indicador de Controle de Congestão (2 bits)
R = Reservado (2 bits)
S = indicador de TSI (1 bit)
O = indicador de TOI (2 bits)
H = indicador de Meia-palavra (1 bit)
T = indicador de Tempo Atual de Remetente (1 bit)
R = indicador de Tempo Residual Esperado (1 bit)
Um = indicador de Fechar sessão (1 bit)
B = indicador de Fechar objeto (1 bit)
HDRJLEN = comprimento de cabeçalho de LCT (8 bits)
CP = Ponto de Código (8 bits)
O campo de TSI 62 do cabeçalho de FLUTE comprimido 6 pode ter um tamanho de 0, 16, 32 ou 48 bits. O TSI é precisado para identificar a sessão. O receptor específico pode ter participado em mais de
• · •
• • J • • ·
• • • • ··
• • • •
• • ♦ ♦ *
··· • • • ·
··· · ·· · • · * · · « • · · ·· · · • «· β · »· • · · · · · < *· · ·· uma sessão de carregamento de FLUTE do mesmo transmissor antes da sessão de reparo de PtP. O receptor específico assim tem que especificar a sessão para a qual está pedindo o reparo de PtP em seu pedido de reparo de PtP. O servidor de reparo envia o TSI na resposta de reparo de PtP de forma que o receptor específico será capaz de identificar a sessão à qual o símbolo de dados de reparo pertence. O endereço do transmissor e o TSI identificam exclusivamente a sessão.
O campo de TOI 63 do cabeçalho de FLUTE comprimido 6 pode ter um tamanho de 0, 16, 32, 48, 64, 80, 96 ou 112 bits. O TOI é precisado para identificar o objeto de transporte dentro da sessão. O carregamento de FLUTE pode consistir em mais de um objeto de transporte (arquivo) em uma única sessão. Por exemplo, um arquivo de áudio e um arquivo de vídeo poderíam ter sido carregados na mesma sessão de FLUTE. O receptor específico tem que especificar o objeto de transporte para qual está pedindo um reparo de PtP. O (TOI, TSI) identifica exclusivamente o objeto de transporte.
O ID de Carga útil de FEC 64 do cabeçalho de FLUTE comprimido 6 depende do ID de Codificação de FEC. O mapeamento entre o ID de Codificação de FEC e ID de Carga útil de FEC é o mesmo como foi definido na publicação RFC 3452 Forward Error Correction Building Block e publicação RFC 3695 Compact Forward Error Correction (FEC) Schemes pela IETF e a minuta da Internet de IETF mais recente Simple Forward Error Correction Schemes, por M. Luby, Digital Fountain, 7 de junho de 2004 (disponível em http://www.ietf.org/mail- archive/web/rmt/current/msg00312.html).
Por exemplo, de acordo com RFC 3695 (adotado por MBMS
FLUTE), para ID de Codificação de FEC = 0 (FEC Sem código), o ID de Carga útil de FEC consiste no seguinte:
SBN = Número de Bloco de Fonte (2 bytes)
« · • * · • ··· ·
• e • • • • ·
• · 4 • 4
• · • • • •
• • • • ·
··· < • • *
··· 4 • · · • · · • ·· • · · • ·· ·· • · • · »· • t
ESI = ID de Símbolo de Codificação (2 bytes).
O campo de Tamanho de Símbolo de Codificação 65 do cabeçalho de FLUTE comprimido 6 tem um comprimento de 2 bytes e contém o tamanho do símbolo de codificação 7 que está contido no pacote de
FLUTE comprimido 8 como carga útil.
Aparentemente, o cabeçalho de FLUTE comprimido 6 de acordo com a primeira concretização da presente invenção não inclui mais a Informação de Controle de Congestão (CCI), o Tempo Atual de Remetente (SCT) e o Tempo Residual Esperado (ERT), embora estes parâmetros estejam presentes no cabeçalho de FLUTE que é usado para a transmissão de PtM de FLUTE/UDP. Estes parâmetros suportam transporte inseguro e capacidade de graduação massiva e assim não têm que serem incluídos no cabeçalho de FLUTE comprimido 6 que é usado para transmissão de PtP de FLUTE/HTTP.
A informação do cabeçalho de FLUTE comprimido 6 como dada na Figura 3a pode ser considerada como informação básica precisada para uma reconstrução no receptor específico 3-1. Outras implementações da invenção podem adicionar qualquer número de campos a esta informação mínima. Porém, concretizações diferentes da invenção podem fazer uso de um pacote de FLUTE comprimido que pode diferir em alguns modos do pacote de FLUTE comprimido 8 mostrado na Figura 3a. Por exemplo, nem todos os campos podem estar presentes se eles puderem ser derivados do contexto. Por exemplo, o campo de TOI 63 pode ser omitido se for assumido que só um único objeto (arquivo) foi entregue na sessão de FLUTE. Nas concretizações mais comuns da presente invenção, pode ser provável que o receptor específico não peça dados de reparo com referência a mais de uma sessão de transmissão. Nesse caso, o TSI é implícito do contexto e permanece o mesmo para todos os pacotes enviados em uma resposta de reparo de PtP. Assim o campo de TSI pode ser omitido dos cabeçalhos de FLUTE comprimidos. O cabeçalho de pacote de FLUTE 6 como dado na Figura 3 também pode incluir seções adicionais, como por exemplo seções de extensão de cabeçalho de LTC tais como EXT_FTI e EXTFDT.
Além disso, o servidor de reparo 4 também pode enviar o endereço de IP do transmissor 1 da sessão de transmissão de PtM a fim de identificar completamente esta sessão pelo endereço de IP do transmissor e o TSI se não puder ser conhecido do contexto.
Figura 3b ilustra o embutimento de uma pluralidade dos pacotes de FLUTE comprimidos 8-1,..., 8-M da Figura 3a em um pacote de HTTP 9, que então é transferido pelo HTTP/TCP entre as entidades de protocolo semelhantes no servidor de reparo 4 e receptor específico 3-1. Nele, o pacote de HTTP 9 ademais inclui um cabeçalho de HTTP 9 com um tipo de conteúdo experimental x-flutePtP/compressedFlutePkt, que denota que o corpo de mensagem do pacote de HTTP 9 contém pacotes de FLUTE comprimidos 8-1,..., 8-M.
A resposta de HTTP de PtP transmitida do servidor de reparo 4 ao receptor específico 3-1 então toma a forma seguinte:
HTTP/1.1 200 OK
Content-Type: X-flutePtP/compressedFlutePkt Content-Length: TOTAL_LENGTH
Content-Transfer-Encoding: binary
Compressed FLUTE Packet - 1 Compressed FLUTE Packet - 2
Compressed FLUTE Packet - M
Nisso, o TOTAL_LENGTH é o tamanho de todos os pacotes de FLUTE comprimidos.
SEGUNDA CONCRETIZAÇÃO DA INVENÇÃO
A informação contida no pacote de HTTP 9 de acordo com a primeira concretização da presente invenção (veja Figuras 3a e 3b) pode ser comprimida ou re-arranjada de modos diferentes.
Por exemplo, de acordo com uma segunda concretização da presente invenção, uma estrutura de MIME de multi-parte pode ser usada para separar e enviar pacotes de FLUTE comprimidos. Em uma estrutura de MIME de multi-parte, carreiras de limite separam as partes constituintes. Assim, o campo de Tamanho de Símbolo de Codificação 65 do cabeçalho de FLUTE comprimido 6 da Figura 3a pode ser omitido, produzindo o cabeçalho de FLUTE comprimido 6' contido no pacote de FLUTE comprimido 8' de acordo com a Figura 4a.
Figura 4b descreve o pacote de HTTP 9' correspondente. Nele, o campo de cabeçalho de HTTP Tipo de Conteúdo é colocado a multiparte/misturado. O subtipo primário para multi-parte, misturado, é pretendido para uso quando as partes de corpo de HTML são independentes e precisam ser acondicionadas em uma ordem particular. Outros tipos de conteúdo pertinentes, por exemplo multi-parte/paralelo ou multiparte/relacionado também podem ser usados. Em particular, em uma entidade de multi-parte/paralela, a ordem de partes de corpo não é significante. O tipo de conteúdo de multi-parte/relacionado provê um mecanismo comum para representar objetos que são agregados de partes de corpo de MIME relacionadas. Qualquer subtipo de multi-parte que uma implementação não reconhece deve ser tratado como sendo de subtipo multiparte/misturado.
De acordo com a segunda concretização da presente invenção, uma carreira de limite de costume (BQUNDARY P2P REPAIR RESPONSE) 92 é assim definida para marcar o começo de cada parte de uma estrutura de MIME de multi-parte no pacote de HTTP 9' da Figura 4b. Esta carreira de limite 92 pode ser tão longa quanto 70 caracteres. É vantajosamente escolhida de tal modo que não se pareça (ou
apareça com probabilidade tendendo a zero) em qualquer parte de corpo. A carreira de limite depois da parte final é seguida por
A codificação de transferência de Conteúdo de cada parte do MIME de multi-parte é colocada a binário desde que os pacotes de FLUTE comprimidos 8' são objetos inerentemente binários que podem ser lidos um byte de cada vez. O esquema de codificação binário não envolve qualquer custo. Outros esquemas de codificação pertinentes tal como base64 também pode ser usado. A codificação de base64 pode resultar em 33% de custo.
O pacote de HTTP 9' da Figura 4b, incluindo o cabeçalho de
HTTP 91, carreiras de limite 92 e pacotes de FLUTE comprimidos 8'-l,..., 8'M, então podem ser expressos por meio do pseudo-código seguinte como:
HTTP/1.1 200 OK
Content-Type: multipart/mixed; boundary - BOUNDARY_P2P_REPAIR_RESPONSS —BOUNDAR Y_ P2P_RE PAIR_RESPONSE
Content-Type: x-flutePtP/compressedFlutePkt Content-Transfer-Encoding: binary Compressed FLUTE Packet - 2 —B0UlvDARY_P2P_REPAIR_RESP0NSE
Content-Type: x-flutePtP/compressedFlutePkt Content-Transfer-Encoding: binary Compressed FLUTE Packet - 2 —BOUNDARY_P2P_REPAIR_RESPONSE
Content-Type: x-flutePtP/compressedFlutePkt Content-Transfer-Encoding: binary Compressed FLUTE Packet - M —BOUNDAR Y_P2P_REPAIR_RESPO!tSE-TERCEIRA CONCRETIZAÇÃO DA INVENÇÃO
De acordo com uma terceira concretização da presente invenção, a informação da resposta de HTTP de PtP de MIME de multi-parte também pode ser transmitida de um modo mais eficiente quando comparado à segunda concretização. Esta terceira concretização será descrita agora com
referência às Figuras 5a-5c.
O servidor de reparo 4 pode processar todos os pacotes de FLUTE que têm o mesmo TSI e TOI e combinar seus símbolos de codificação de FLUTE 7 em M blocos 7-m de pacotes de FLUTE que compartilham cabeçalhos de FLUTE comuns respectivos 6-m, em que o inteiro m varia de 1 a M. Deste modo, uma repetição de partes idênticas de cabeçalhos de FLUTE comprimidos é evitada.
Isto pode ser implementado por exemplo usando a estrutura de MIME de multi-parte que já é suportada por HTTP. Para este fim, os tipos de conteúdo experimentais seguintes são introduzidos para identificar o conteúdo de cada parte na estrutura de MIME de multi-parte:
x-flutePtP/encSymbolHdr denota que o corpo de mensagem contém o cabeçalho de FLUTE comum 6-m que é comum a todos os símbolos de codificação na próxima parte (o bloco 7-m de símbolos de codificação de FLUTE) da estrutura de MIME de multi-parte.
x-flutePtP/encSymbolVideo denota que o corpo de mensagem contém símbolos de codificação de FLUTE 7-1-m,..., 7-Mm-m (com seus IDs de Carga útil de FEC correspondentes 64-1-m,..., 64-Mm-m, em que Mm denota o número de símbolos de codificação de FLUTE por bloco 7-m) correspondendo a um objeto de vídeo.
x-flutePtP/encSymbolAudio denota que o corpo de mensagem contém símbolos de codificação de FLUTE 7-1-m,..., 7-Mm-m (com seus IDs de Carga útil de FEC correspondentes 64-1-m,..., 64-Mm-m) correspondendo a um objeto de áudio.
x-flutePtP/encSymbolOther denota que o corpo de mensagem contém símbolos de codificação de FLUTE 7-1-m,..., 7-Mm-m (com seus IDs de Carga útil de FEC correspondentes 64-1-m,..., 64-Mm-m) correspondendo a outros objetos.
Altemativamente, algumas concretizações podem escolher não
diferenciar entre tipos de mídia diferente e por exemplo usar um tipo de conteúdo genérico como x-flutePtP/encSymbolData.
A estrutura resultante da resposta de HTTP de PtP 9 é ilustrado na Figura 5a, o cabeçalho de FLUTE comum 6-m é mostrado na
Figura 5b, e o formato do bloco 7- m de símbolos de codificação de FLUTE é mostrado na Figura 5c. Como pode ser visto da Figura 5c, o ID de Carga útil de FEC 64-1-m,..., 64-Mm-m para cada símbolo de codificação de FLUTE Ί1-m,..., 7-Mm-m (com m denotando um inteiro variando de 1 a M) é vantajosamente movido no bloco 7-m de símbolos de codificação de FLUTE porque é específico de símbolos de codificação de FLUTE. Além disso, como os símbolos de codificação de FLUTE não são separados mutuamente por limites de MIME, o tamanho 65-m dos símbolos de codificação de FLUTE Ί1-m,..., 7-Mm-m tem que ser definido no cabeçalho de FLUTE comum 6-m, veja Figura 5b.
A resposta de HTTP 9 da Figura 5a pode ser expressa por meio de pseudo-código como (comentários são começados com um golpe dianteiro duplo):
HTTP/1.1 200 OK
MIME Version: 1.0 Content-Type: multipart/mixed;
boundary ~ —BOUNDARY_P2P_REPAIR_RESPONSE —BOUNDAR P2P_REPAIR_RESPOUSE
Content-Type: x-flutePtP/encSymbolHdr Content-Transfer-Encoding: binary // Include the TSI, TOI and Encoding Symbol Size common // to all FLUTE encoding symbols of the following part.
// (In this example, the following part contains all the // encoding symbols that belong to a video object).
--BOUNDAR Y__ P2P_REPAIR_RESPOUSE
Content-Type: X-flutePtP/encSymbolVideo Content-Transfer-Encoding: binary • · 9 · · 9 · · ··«· • · · ·· fr··· // Include all the FLUTE encoding symbols (with their FEC // Payload IDs) that belong to the Video object.
FEC Payload ID - 1, Encoding Symbol - 1
FEC Payload ID -2, Encoding Symbol - 2
FEC Payload ID - Ml, Encoding Symbol Ml. —BOUUDARY P2P RE PAI R RESPONSE
Con t ent-Type: x-flutePtP/encSymbo 1Kdr
Content-Transfer-Encoding: binary // Include the TSI, TOI and Encoding Symbol Sise common // to all FLUTE encoding symbols of the following part.
// (In this example, the following part contains all the // encoding symbols that belong to the Audio object) .
- -BOUNDAR Y_ P2P_RE PAI R_RES POUSE
Content-Type: x-flutePtP/encSymbolAudio
Content-Transfer-Encoding: binary // Include all the FLUTE encoding symbols (with their FEC // Payload IDs) that belong to the Audio object.
FEC Payload ID - 1, Encoding Symbol - 1
FEC Payload ID -2, Encoding Symbol - 2
FEC Payload ID - M2, Encoding Symbol - M2.
—BOUNDAR Y_ P2P_REPAIR_RESPOUSE
Content-Type: x-flutePtP/encSymbolHdr
Content-Transfer-Encoding: binary // Include the TSI, TOI and Encoding Symbol Size common // to all FLUTE encoding symbols of the following part.
// (In this example, the following part contains all the // encoding symbols that belong to the Audio object).
--BOUNDARY_P2P_REPAIR_RESPONSE
Content-Type: x~flutePtP/encSymbolOther
Content-Transfer-Encoding: binary // Include all the FLUTE encoding symbols (with their FEC // Payload IDs) that belong to the Audio object.
FEC Payload ID - 1, Encoding Symbol - 1
FEC Payload ID -2, Encoding Symbol - 2
FEC Payload ID - MM, Encoding Symbol - MM.
—BOUMDARY P2P RE PAI R RESPONSEA terceira concretização da presente invenção até agora assumiu que nenhuma extensão de cabeçalho de LTC tal como EXT_FTI e EXTJFDT está contida no cabeçalho de FLUTE. O bloco 7-m de símbolos de codificação de FLUTE como mostrado na Figura 5 c assim não inclui nenhuma extensão de cabeçalho de LTC.
Porém, se extensões de cabeçalho de LTC forem usadas por pelo menos alguns dos símbolos de codificação de FLUTE, a terceira concretização da presente invenção como apresentado até agora com referência às Figuras 5a-5c somente, tem que ser alteradas com respeito à instalação do bloco 7-m de símbolos de codificação de FLUTE. Isto é descrito exemplarmente na Figura 5 d, que serve como uma alternativa ao bloco da Figura 5c e assim mantém os mesmos numerais.
De acordo com a Figura 5c, o bloco 7-m de símbolos de codificação de FLUTE ainda inclui símbolos de codificação 7-1-m,..., 7-Mmm, onde o inteiro m varia de 1 a M, e em que Mm é o número de símbolos de codificação por bloco m e M é o número global de blocos. Como na Figura 5c, os IDs de Carga útil de FEC 64-1-m,..., 64-Mm-m para cada símbolo de codificação estão contidos em dito bloco antes do respectivo símbolo de codificação. Porém, para considerar o uso de extensões de cabeçalho de LTC por pelo menos alguns dos símbolos de codificação, campos de comprimento de cabeçalho de LCT (HDR_LEN) 6110-1-m,..., 6110-Mm-m para cada símbolo de codificação respectivo 7-1-m,..., 7-Mm-m são introduzidos no bloco 7-m. Estes campos de comprimento de cabeçalho de LCT indicam se extensões de cabeçalho de LTC são usadas, e quantas delas estão associadas com cada símbolo de codificação. Estas extensões de cabeçalho de LCT 68-1m,..., 68-Mm-m são então contidas depois dos campos de comprimento de cabeçalho de LCT, respectivamente.
No exemplo da Figura 5d, dois EXTJFTI estão presentes no primeiro símbolo de codificação, nenhum EXT_FTI no segundo símbolo de codificação, e um EXTJFTI no último símbolo de codificação do bloco.
Neste caso, o campo de HDR_LEN 6110 incluído no cabeçalho de símbolo de codificação comum (6-m mostrado na Figura 5b) pode ter nenhum significado.
E prontamente compreendido que o método acima descrito para suportar o uso de extensões de cabeçalho de LTC também trabalha para casos de cabeçalho de LCT EXT-FDT, que são usados quando símbolos de codificação pertencem a um Exemplo de Tabela de Distribuição de Arquivo (FDT).
QUARTA CONCRETIZAÇÃO DA INVENÇÃO
Ainda outra concretização da invenção é obtida re-arranjando a informação contida na resposta de HTTP de PtP como descrito em seguida com referência às Figuras 6a-6c.
De acordo com esta concretização da presente invenção, símbolos de codificação de FLUTE associados com os mesmo TSI e TOI são armazenados uma vez mais em blocos 7'-m de símbolos de codificação de FLUTE (com m variando de 1 a M), e cabeçalhos de FLUTE comuns são usados para os símbolos de codificação de FLUTE de cada bloco; porém, em contraste à terceira concretização, os campos de todos os cabeçalhos de FLUTE comuns são combinados em um objeto de índice 6', e também os IDs de Carga útil de FEC de todos os símbolos de codificação de FLUTE contidos em um bloco 7' -m de símbolos de codificação de FLUTE não são mais armazenados em ditos blocos de símbolos de codificação de FLUTE como na terceira concretização, mas em arranjos específicos de bloco de IDs de Carga útil de FEC 64-1-m,..., 64-Mm-m, que também estão incorporados em dito objeto de índice 6'. Isto permite acesso aleatório a cada símbolo de codificação de FLUTE desejado na resposta de HTTP de PtP 9'.
Esta resposta de HTTP (pacote) 9' é ilustrada na Figura 6a.
Novamente, uma estrutura de MIME de multi-parte com limites de MIME 92 pode ser usada para separar o objeto de índice 6' e os blocos 7'-m de símbolos de codificação de FLUTE de tipos diferentes. Um novo tipo de conteúdo x-flutePtP/IndexObject é definido aqui, que denota que o corpo de mensagem contém um objeto de índice 6'.
Figura 6b mostra o formato do objeto de índice 6' que contém a informação (TSI, TOI, Comprimento de Símbolo de Codificação, ID de Carga útil de FEC) de todos os símbolos de codificação enviados na resposta de HTTP 9'. O objeto de índice 6' pode ser entendido como sendo composto de M subcabeçalhos (cabeçalhos de FLUTE comuns modificados da terceira concretização) indexados com m = 1,..., M, em que cada um de ditos subcabeçalhos se relaciona a um TSI, TOI, tamanho de símbolo de codificação de FLUTE especifico e, naturalmente, vários símbolos de codificação de FLUTE Mm para cada bloco 7'-m de símbolos de codificação de FLUTE, e em que estas quantidades são armazenadas em campos 62-m, 63-m, 65-m e 67-m, respectivamente. Cada um de ditos subcabeçalhos ademais inclui uma porção de um cabeçalho de LCT 61-m, e dito arranjo específico de bloco de IDs de Carga útil de FEC 64-1 -m,..., 64-Mm-m.
Desta informação, o receptor específico 3-1 pode mapear cada
ID de Carga útil de FEC a uma única gama de byte no fluxo de byte recebido. Assim, o receptor específico 3-1 pode ter acesso aleatório a qualquer símbolo de codificação desejado. O formato dos blocos 7'-m de símbolos de codificação de FLUTE (com m variando de 1 a M e M denotando o número de blocos de símbolos de codificação de FLUTE) é mostrado na Figura 6c.
Aparentemente, e em contraste com a terceira concretização da presente invenção, nenhum ID de Carga útil de FEC está contido nos blocos de símbolos de codificação de FLUTE, porque estes estão agora contidos no objeto de índice 6'.
A resposta de HTTP 9' da Figura 6a pode ser expressa em
• · • · · · » · · • · · · * * •
4» * • · · • • • · * * • ·
• · • · · · • * • « • · • ♦
•
• · · « • · · • « · * • ·
pseudo-código como (comentários são começados com um golpe dianteiro duplo):
HTTP/1.1 200 OK
MIME Version: 1.0 Content-Type: multipart/mixed;
bouiidary = —BOUNDARY_P2P_RE PAI R_RES PONSE —B0UNDARY_P2P_REPAIR_RESP0NSE Content-Type: x-flutePtP/IndexObject Content-Transfer-Encoding: binary // Include the Index object that contains a 11 the // necessaty Information to access any ELUTE encoding // Symbol uniquely identified by (TSIf TOI, FEC Payload // ID).
--BOUNDAR Y_P2P_REPAIR_RES PONSE
Content-Type: x-flutePtP/encSymbolVideo Content-Transfer-Encoding: binary // Include all the ELUTE encoding symbols that belong to // the Video object.
Encoding Symbol - 1 Encoding Symbol - 2
Encoding Symbol - Ml.
- -B OUNDAR Y_ P2P_REPAIR_ RES PONSE
Content-Type: x-flutePtP/encSymbolAudio Content-Transfer-Encoding: binary // Include all the FLUTE encoding symbols that belong to // the Audio object.
Encoding Symbol - 1 Encoding Symbol - 2
Encoding Symbol - M2.
—BOUNDAR Y_ P2P_RE PAIRARES PONSE
* 9 • · · • • · · « • ft · 9 • · 9 • •
9 > w « * • · • • 9 • · • •
• 9 • · • • • 9 9 · • •
• · · * • • · • • 9 9 •
Content-Type: x-flutePtP/encSymbolOther Content-Transfer-Encoding: binary //Include all the encoding symbols that belong to the //Other object.
Encoding Symbol - 1 Encoding Symbol - 2
Encoding Symbol - MM.
—BOUNDAR Y_ P2 P_REPAIR_RESPONSE
A descrição da quarta concretização da presente invenção assumiu que nenhuma extensão de cabeçalho de LCT como EXT_FTI e EXTFDT está associada com os símbolos de codificação. Deveria ser notado porém que uma técnica semelhante como aplicada na terceira concretização da presente invenção (veja Figura 5d) também pode ser adotada para a quarta concretização da presente invenção. Para este fim, simplesmente um arranjo de comprimentos de cabeçalho de LCT é incluído em cada subcabeçalho, que indica para cada símbolo de codificação se e quantas extensões de cabeçalho de LCT são usadas. As entradas deste arranjo então denotam o número de extensões de cabeçalho de LTC que são armazenadas em uma estrutura de dados específica de símbolo de codificação em cada subcabeçalho.
Figura 7 descreve um fluxograma exemplar de um método para transmitir símbolos de dados de acordo com a presente invenção. Neste fluxograma, para simplicidade de apresentação, é assumido que o transmissor 1 e servidor de reparo 4 estão concretizados pelo mesmo dispositivo.
Em uma primeira etapa 701, o transmissor 1 gera símbolos de codificação de FLUTE, por exemplo por porções de codificação de FEC de um objeto de transporte que é para ser transferido a uma pluralidade de receptores 3-1,..., 3-3 em uma sessão de PtM. Estes símbolos de codificação de FLUTE são então fornecidos com cabeçalhos de FLUTE (cabeçalhos de primeiro tipo) que obedecem o protocolo de FLUTE em uma etapa 702, produzindo pacotes de FLUTE, que são então transmitidos para dita
·· ···> · <*·· · ·ί· · ·· · ·«·«·· ·· · 9 · · ·· • · * · « »· · · · · ·· ·» ·· · · · · * · · · * ·· • *····· ·· · · · · • · · * · ··· · ·· · ·· pluralidade de receptores em uma etapa 703. Isto pode ser por exemplo realizado usando os serviços do UDP e do protocolo de IP subjacente. Os pacotes de FLUTE transmitidos são então recebidos nos receptores 3-1,..., 33, e pelo menos um de ditos receptores, o receptor específico 3-1, uma recepção adicional de pacotes de dados de reparo é achada ser requerida devido à perda ou recepção incorreta de pacotes ou devido a outras razões. O receptor específico 3-1 então sinaliza um pedido de reparo para o servidor de reparo, que neste caso exemplar, é idêntico ao transmissor.
Em dito servidor de reparo 4, dito pedido de reparo é recebido em uma etapa 704, e a informação de reparo contida nele, por exemplo um quádruplo de TSI, TOI, SBN e ESI de símbolos de codificação de FLUTE perdidos, é usado para determinar quais símbolos de codificação de FLUTE têm que ser gerados como símbolos de dados de reparo. Isto é executado pelo servidor de reparo 4 na etapa 705. Os símbolos de codificação de FLUTE gerados são então fornecidos com um cabeçalho de FLUTE comprimido (cabeçalho de segundo tipo) obedecendo o protocolo de FLUTE na etapa 706, por exemplo o cabeçalho de FLUTE comprimido 6 da primeira concretização da presente invenção de acordo com Figura 3a. Os símbolos de codificação de FLUTE e o cabeçalho de FLUTE comprimido então formam o pacote de
FLUTE comprimido 8 da Figura 3a. Este pacote de FLUTE comprimido 8 é então transmitido pelo servidor de reparo ao receptor específico em uma sessão de reparo de PtP, veja etapa 707, por exemplo embutindo uma pluralidade de pacotes de FLUTE comprimidos 8-1,..., 8-M em um pacote de HTTP 9 (veja Figura 3b) que serve como uma resposta ao pedido de reparo, e usando os serviços do HTTP/TCP para transferir estes pacotes de HTTP entre entidades do servidor de reparo 4 e o receptor específico 3-1.
A invenção foi descrita acima por meio de concretizações preferidas. Deveria ser notado que há modos alternativos e variações que são óbvias a uma pessoa qualificada na arte e podem ser implementadas sem desviar da extensão e espírito das reivindicações anexas. Em particular, a extensão da presente invenção não deverá por nenhum meio ser restringida a aplicação no contexto do protocolo de FLUTE ou do sistema de MBMS de 3GPP. Isto é devido ao fato que o princípio inventivo de usar tipos diferentes de cabeçalhos do mesmo protocolo para transmissões de PtM, por um lado, e transmissão de PtP, por outro lado, não está ligado a qualquer protocolo ou sistema específico.

Claims (40)

1. Um método para transmitir símbolos de dados, caracterizado por compreender:
- transmitir (703) um ou mais símbolos de dados de um transmissor (1) para um ou mais receptores (3-1,3-2, 3-3) dentro de uma sessão de transmissão pontoa-multiponto, em que os referidos símbolos de dados são fornecidos com cabeçalhos de primeiro tipo obedecendo a um protocolo de entrega de arquivos (51), e em que na referida sessão de transmissão ponto-a-multiponto o referido protocolo de entrega de arquivos utiliza os serviços do Protocolo de Datagrama do Usuário (52);
- transmitir um ou mais símbolos de dados de reparo de um servidor de reparo (4) para um receptor específico (3-1) dos referidos receptores (3-1, 3-2, 3-3) dentro de uma sessão de reparo ponto-a-ponto, em que os referidos símbolos de dados de reparo são fornecidos com um ou mais cabeçalhos de segundo tipo (6; 6'; 6”-m; 6”’) obedecendo pelo menos parcialmente ao mesmo protocolo de entrega de arquivos (51), e em que cabeçalhos de segundo tipo (6; 6’; 6’’m; 6’’’) representam uma modificação dos referidos cabeçalhos de primeiro tipo obtidos pela remoção de pelo menos um parâmetro dos referidos cabeçalhos de primeiro tipo.
2. Método de acordo com a reivindicação 1, caracterizado por o referido cabeçalho de primeiro tipo conter pelo menos um parâmetro que não está contido no referido cabeçalho de segundo tipo (6; 6’; 6’’-m; 6’’’), e em que o referido parâmetro está relacionado à transmissão ponto-a-multiponto.
3. Método de acordo com a reivindicação 1, caracterizado por o referido protocolo de entrega de arquivo (51) utilizar os serviços do Protocolo de Controle de Transporte (56) na referida sessão de reparo ponto-a-ponto.
4. Método de acordo com a reivindicação 1, caracterizado por o referido protocolo de entrega de arquivos (51) utilizar os serviços do Protocolo de Transferência de Hipertexto (55) na referida sessão de reparo ponto-a-ponto.
Petição 870180130973, de 17/09/2018, pág. 15/24
2/9
5. Método de acordo com a reivindicação 1, caracterizado por o referido protocolo de entrega de arquivos (51) ser o protocolo Entrega de Arquivos via Transporte Unidirecional, FLUTE, e em que os referidos símbolos de dados e os referidos símbolos de dados de reparo representam símbolos de codificação FLUTE.
6. Método de acordo com a reivindicação 5, caracterizado por o referido protocolo FLUTE (51) utilizar os serviços do Protocolo de Transferência de Hipertexto (55), HTTP, e em que o referido HTTP (55) transfere pacotes HTTP entre o referido servidor de reparo (4) e o referido receptor específico (3-1).
7. Método de acordo com a reivindicação 6, caracterizado por uma combinação de um símbolo de codificação FLUTE (7) e um cabeçalho de segundo tipo associado (6; 6') formar um pacote comprimido de FLUTE (8; 8'), e em que pelo menos um dos referidos pacotes HTTP (9; 9') compreende um cabeçalho de pacote HTTP (91) e um ou mais dos referidos pacotes FLUTE comprimidos (8; 8').
8. Método de acordo com a reivindicação 7, caracterizado por o referido cabeçalho de segundo tipo (6) dos referidos pacotes FLUTE comprimidos (8) compreender pelo menos uma parte de um cabeçalho de Transporte de Codificação em Camadas (61), um identificador (64) do referido símbolo de codificação FLUTE (7) no referido pacote FLUTE comprimido (8), e um tamanho (65) do referido símbolo de codificação FLUTE (7).
9. Método de acordo com a reivindicação 8, caracterizado por pelo menos um pacote HTTP (9) possuir uma estrutura Extensões Multifuncionais para Mensagens de Internet, MIME, e em que os pacotes FLUTE comprimidos (8') são separados do cabeçalho do pacote HTTP (91) e uns dos outros pelos limites MIME (92).
10. Método de acordo com a reivindicação 9, caracterizado por o referido cabeçalho de segundo tipo (6') dos referidos pacotes FLUTE comprimidos (8') compreender uma parte de um cabeçalho de Transporte de Codificação em Camadas (61) e um identificador (64) do referido símbolo de codificação FLUTE no referido pacote FLUTE comprimido (8').
Petição 870180130973, de 17/09/2018, pág. 16/24
3/9
11. Método de acordo com a reivindicação 6, caracterizado por pelo menos um dos referidos pacotes HTTP (9) compreender um cabeçalho de pacote HTTP (91), um ou mais blocos (7’-m) que compreendem pelo menos dois símbolos de codificação FLUTE e respectivos identificadores associados, e um respectivo cabeçalho de segundo tipo (6’’-m) para cada um dos referidos blocos (7’’-m), em que cada respectivo cabeçalho de segundo tipo (6’’-m) é válido para todos os símbolos de codificação FLUTE de um bloco respectivo (7’’-m).
12. Método de acordo com a reivindicação 11, caracterizado por pelo menos um dos referidos pacotes HTTP (9”) possuir uma estrutura MIME, e em que o referido cabeçalho de pacote HTTP (91), os referidos blocos (7’-m) e os referidos cabeçalhos de segundo tipo (6’’-m) serem mutuamente separados por limites MIME (92).
13. Método de acordo com a reivindicação 12, caracterizado por os referidos cabeçalhos de segundo tipo (6’’-m) compreenderem uma parte de um cabeçalho de transporte de codificação em camadas (61-m) e um tamanho (65-m) dos referidos símbolos de codificação FLUTE nos referidos blocos respectivos (7’’-m).
14. Método de acordo com a reivindicação 11, caracterizado por pelo menos um dos referidos blocos (7’’-m) compreender um símbolo de codificação FLUTE, um respectivo identificador associado, um respectivo comprimento de cabeçalho de Transporte de Codificação em Camadas, e pelo menos um cabeçalho extensão de Transporte de Codificação em Camadas.
15. Método de acordo com a reivindicação 6, caracterizado por pelo menos um dos referidos pacotes HTTP (9”’) compreender um cabeçalho de pacote HTTP (91), um cabeçalho de segundo tipo (6’’’) e um ou mais blocos (7’’’-m) que compreendem pelo menos dois símbolos de codificação FLUTE.
16. Método de acordo com a reivindicação 15, caracterizado por o referido pelo menos um pacote HTTP (9’’’) possuir uma estrutura MIME, e em que o referido cabeçalho de pacote HTTP (91), o referido cabeçalho de segundo tipo (6’’’) e o referido um ou mais blocos (7’’’-m) serem mutuamente separados por limites MIME (92).
Petição 870180130973, de 17/09/2018, pág. 17/24
4/9
17. Método de acordo com a reivindicação 16, caracterizado por o referido cabeçalho de segundo tipo (6”’) compreender um respectivo sub-cabeçalho para cada bloco respectivo (7’’’-m) no referido pacote HTTP (9’’’), e em que cada um dos referidos subcabeçalhos compreende uma parte de um cabeçalho de Transporte de Codificação em Camadas, o tamanho dos referidos símbolos de codificação FLUTE no referido bloco respectivo, o número de símbolos de codificação FLUTE no referido bloco respectivo, e um identificador para cada símbolo de codificação FLUTE no referido bloco respectivo (7’’’- m).
18. Método de acordo com a reivindicação 17, caracterizado por pelo menos um dos referidos sub-cabeçalhos compreender um comprimento de cabeçalho de Transporte de Codificação em Camadas para cada símbolo de codificação FLUTE no referido bloco (7’’’-m), e pelo menos um extensão de cabeçalho de Transporte de Codificação em Camadas para pelo menos um dos referidos símbolos de codificação FLUTE no referido bloco respectivo (7’’’-m).
19. Método de acordo com as reivindicações 8, 10, 13 e 17, caracterizado por o referido cabeçalho de segundo tipo (6; 6’; 6’’-m; 6’’’) compreender ainda um identificador (62; 62’-m) da referida sessão de transmissão ponto-a-multiponto.
20. Método de acordo com as reivindicações 8, 10, 13 e 17, caracterizado por o referido cabeçalho de segundo tipo (6; 6’; 6’’-m; 6’’’) compreender ainda um identificador de um objeto de transporte (63; 63-m) com o qual os referidos símbolos de codificação FLUTE estão relacionados.
21. Método de acordo com as reivindicações 8, 10, 13 e 17, caracterizado por o referido cabeçalho de segundo tipo (6; 6’; 6’’-m; 6’’’) compreender ainda extensões de cabeçalho de Transporte de Codificação em Camadas.
22. Método de acordo com as reivindicações 8, 10, 13 e 17, caracterizado por a referida parte do referido cabeçalho de Transporte de Codificação em Camadas compreender um número de versão de Transporte de Codificação em Camadas, um sinalizador de Controle de Congestionamento, um espaço reservado, um sinalizador de Identificador de Sessão de Transporte, um sinalizador de Identificador de Objeto
Petição 870180130973, de 17/09/2018, pág. 18/24
5/9 de Transporte TOI, um sinalizador de meia palavra, um sinalizador de Horário Atual do Emissor, um sinalizador de Horário Residual Esperado, um sinalizador de Encerrar de Sessão, um sinalizador de Encerrar Objeto, um comprimento de cabeçalho de Transporte de Codificação em Camadas, e um Ponto de Código.
23. Método de acordo com a reivindicação 1, caracterizado por o referido protocolo de entrega de arquivos (51) ser o protocolo Entrega de Arquivos via Transporte Unidirecional, FLUTE.
24. Método de acordo com a reivindicação 1, caracterizado por a sessão ponto-amultiponto ser uma sessão de serviço de broadcast/multicast de multimídia 3GPP.
25. Um sistema para transmissão de símbolos de dados, caracterizado por compreender:
- um transmissor (1)
- um ou mais receptores (3-1, 3-2, 3-3), e
- um servidor de reparo (4), em que um ou mais símbolos de dados são transmitidos do referido transmissor (1) para um ou mais dos referidos receptores (3-1, 3-2, 3-3) dentro de uma sessão de transmissão ponto-a-multiponto, em que os referidos símbolos de dados são fornecidos com cabeçalhos de primeiro tipo obedecendo a um protocolo de entrega de arquivos (51), em que o referido protocolo de entrega de arquivos (51) utiliza os serviços do Protocolo de Datagramas do Usuário (52) na referida sessão de transmissão ponto-a-multiponto, em que um ou mais símbolos de dados de reparo são transmitidos do referido servidor de reparo (4) para um receptor específico (3-1) dos referidos receptores (3-1, 3-2, 3-3) dentro de uma sessão de reparo ponto-aponto, em que os referidos símbolos de dados de reparo são fornecidos com um ou mais cabeçalhos de segundo tipo (6; 6'; 6”-m; 6’’’) obedecendo pelo menos parcialmente ao mesmo protocolo de entrega de arquivos (51), e em que os referidos cabeçalhos de segundo tipo (6; 6; 6’’-m; 6’’’) representam uma modificação dos
Petição 870180130973, de 17/09/2018, pág. 19/24
6/9 referidos cabeçalhos de primeiro tipo obtidos pela remoção de pelo menos um parâmetro dos referidos cabeçalhos de primeiro tipo.
26. Sistema de acordo com a reivindicação 25, caracterizado por o referido cabeçalho de primeiro tipo conter pelo menos um parâmetro que não está contido no referido cabeçalho de segundo tipo (6; 6'; 6”-m; 6’’’), e em que o referido parâmetro está relacionado à transmissão ponto-a-multiponto.
27. Sistema de acordo com a reivindicação 25, caracterizado por o referido protocolo de entrega de arquivos (51) ser o protocolo Entrega de Arquivos via Transporte Unidirecional, FLUTE.
28. Sistema de acordo com a reivindicação 25, caracterizado por a sessão de pontoa-multiponto ser uma sessão de serviço de broadcast/multicast de multimídia 3GPP.
29. Um transmissor (1) em um sistema para transmitir símbolos de dados, caracterizado por compreender:
- meios dispostos para transmitir um ou mais símbolos de dados do referido transmissor (1) para um ou mais receptores (3-1, 3-2, 3-3) em uma sessão de transmissão ponto-a-multiponto, em que os referidos símbolos de dados são fornecidos com cabeçalhos de primeiro tipo obedecendo a um protocolo de entrega de arquivos (51), em que o referido protocolo de entrega de arquivos (51) utiliza os serviços do Protocolo de Datagramas de Usuário (52) na referida sessão de transmissão ponto-a-multiponto, em que um ou mais dados de reparo símbolos são transmitidos de um servidor de reparo (4) para um receptor específico (3-1) dos referidos receptores (3-1, 3-2, 3-3) dentro de uma sessão de reparo ponto-a-ponto, em que os referidos símbolos de dados de reparo estão equipados com um ou mais cabeçalhos de segundo tipo (6; 6’; 6’’-m; 6’’’) obedecendo pelo menos parcialmente ao mesmo protocolo de entrega de arquivos (51), e em que os referidos cabeçalhos de segundo tipo (6; 6’; 6’’-m; 6’’’) representam uma modificação dos referidos cabeçalhos de primeiro tipo obtidos pela remoção de pelo menos um parâmetro dos referidos cabeçalhos de primeiro tipo.
Petição 870180130973, de 17/09/2018, pág. 20/24
7/9
30. Transmissor (1) de acordo com a reivindicação 29, caracterizado por o referido cabeçalho de primeiro tipo conter pelo menos um parâmetro que não está contido no referido cabeçalho do segundo tipo (6; 6'; 6”-m; 6”’), e em que o referido parâmetro está relacionado com a transmissão ponto-a-multiponto.
31. Transmissor (1) de acordo com a reivindicação 29, caracterizado por o referido protocolo de entrega de arquivos (51) ser o protocolo de Entrega de Arquivos via Transporte Unidirecional, FLUTE.
32. Transmissor (1) de acordo com a reivindicação 29, caracterizado por a sessão ponto-a-multiponto ser uma sessão de serviço de broadcast/multicast de multimídia 3GPP.
33. Um elemento de rede (4) em um sistema para transmitir símbolos de dados, em que um ou mais símbolos de dados são transmitidos de um transmissor (1) para um ou mais receptores (3-1, 3-2, 3-3) dentro de uma sessão de transmissão ponto-amultiponto, em que os referidos símbolos de dados são fornecidos com cabeçalhos de primeiro tipo obedecendo a um protocolo de entrega de arquivos (51), e em que o referido protocolo de entrega de arquivos (51) utiliza os serviços do Protocolo de Datagrama do Usuário (52) na referida sessão de transmissão ponto-a-multiponto, o referido elemento de rede (4) caracterizado por compreender:
- meios dispostos para transmitir um ou mais símbolos de dados de reparo do referido elemento de rede (4) para um receptor específico (3-1) dos referidos receptores (3-1, 3-2, 3-3) dentro de uma sessão de reparo ponto a ponto, em que os referidos símbolos de dados de reparo são fornecidos com um ou mais cabeçalhos de segundo tipo (6; 6’; 6’’-m; 6’’’) obedecendo pelo menos parcialmente ao referido protocolo de entrega de arquivos (51), e os referidos cabeçalhos de segundo tipo (6; 6’; 6’’-m; 6’’’) representam uma modificação dos referidos cabeçalhos de primeiro tipo obtidos pela remoção de pelo menos um parâmetro dos referidos cabeçalhos de primeiro tipo.
34. Elemento de rede (4) de acordo com a reivindicação 33, caracterizado por o referido cabeçalho de primeiro tipo conter pelo menos um parâmetro que não está
Petição 870180130973, de 17/09/2018, pág. 21/24
8/9 contido no referido cabeçalho de segundo tipo (6; 6'; 6”-m; 6”’), e em que o referido parâmetro está relacionado com a transmissão ponto-a-multiponto.
35. Elemento de rede (4) de acordo com a reivindicação 33, caracterizado por o referido protocolo de entrega de arquivo (51) ser o protocolo de Entrega de Arquivos via Transporte Unidirecional, FLUTE.
36. Elemento de rede de acordo com a reivindicação 33, caracterizado por a sessão ponto-a-multiponto ser uma sessão de serviço de broadcast/multicast de multimídia 3GPP.
37. Um receptor (3-1) em um sistema para transmitir símbolos de dados, caracterizado por compreender:
- meios dispostos para receber um ou mais símbolos de dados transmitidos de um transmissor (1) para um ou mais receptores (3-1, 3-2, 3-3) dentro de uma sessão de transmissão ponto-a-multiponto, em que os referidos símbolos de dados são fornecidos com cabeçalhos de primeiro tipo obedecendo a um protocolo de entrega de arquivos (51), e em que o referido protocolo de entrega de arquivos (51) utiliza os serviços do Protocolo de Datagrama do Usuário (52) na referida sessão de transmissão ponto-a-multiponto; e
- meios dispostos para receber um ou mais símbolos de dados de reparo de um servidor de reparo (4) em uma sessão de reparo ponto a ponto, em que os referidos símbolos de dados de reparo são fornecidos com um ou mais cabeçalhos de segundo tipo (6; 6’; 6’’-m; 6’’’) obedecendo pelo menos parcialmente ao mesmo protocolo de entrega de arquivos (51), e em que os referidos cabeçalhos de segundo tipo (6; 6’; 6’’-m; 6’’’) representam uma modificação dos referidos cabeçalhos de primeiro tipo obtidos pela remoção pelo menos um parâmetro dos referidos cabeçalhos do primeiro tipo.
38. Receptor (3-1) de acordo com a reivindicação 37, caracterizado por o referido cabeçalho de primeiro tipo conter pelo menos um parâmetro que não está contido no
Petição 870180130973, de 17/09/2018, pág. 22/24
9/9 referido cabeçalho de segundo tipo (6; 6'; 6”-m; 6’’’), e em que o referido parâmetro está relacionado com a transmissão ponto-a-multiponto.
39. Receptor de acordo com a reivindicação 37, caracterizado por o referido protocolo de entrega de arquivos (51) ser o protocolo de Entrega de Arquivos via Transporte Unidirecional, FLUTE.
40. Receptor de acordo com a reivindicação 37, caracterizado por a sessão pontoa-multiponto ser uma sessão de serviço de broadcast/multicast de multimídia 3GPP.
BRPI0513969-4A 2004-07-30 2005-07-27 Método para transmitir símbolos de dados, sistema para transmissão de símbolos de dados, transmissor em um sistema, elemento de rede e receptor BRPI0513969B1 (pt)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US10/903,260 2004-07-30
US10/903,260 US7376150B2 (en) 2004-07-30 2004-07-30 Point-to-point repair response mechanism for point-to-multipoint transmission systems
PCT/IB2005/002434 WO2006013460A1 (en) 2004-07-30 2005-07-27 Point-to-point repair response mechanism for point-to-multipoint transmission systems

Publications (2)

Publication Number Publication Date
BRPI0513969A BRPI0513969A (pt) 2008-05-20
BRPI0513969B1 true BRPI0513969B1 (pt) 2019-04-16

Family

ID=35124443

Family Applications (1)

Application Number Title Priority Date Filing Date
BRPI0513969-4A BRPI0513969B1 (pt) 2004-07-30 2005-07-27 Método para transmitir símbolos de dados, sistema para transmissão de símbolos de dados, transmissor em um sistema, elemento de rede e receptor

Country Status (15)

Country Link
US (1) US7376150B2 (pt)
EP (1) EP1771992B1 (pt)
JP (1) JP4625080B2 (pt)
CN (1) CN1969528B (pt)
AT (1) ATE456239T1 (pt)
AU (1) AU2005268493B2 (pt)
BR (1) BRPI0513969B1 (pt)
CA (1) CA2574083C (pt)
DE (1) DE602005019051D1 (pt)
MX (1) MXPA06013544A (pt)
PL (1) PL1771992T3 (pt)
RU (1) RU2371863C2 (pt)
TW (1) TWI307591B (pt)
WO (1) WO2006013460A1 (pt)
ZA (1) ZA200700792B (pt)

Families Citing this family (63)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6307487B1 (en) 1998-09-23 2001-10-23 Digital Fountain, Inc. Information additive code generator and decoder for communication systems
US7068729B2 (en) 2001-12-21 2006-06-27 Digital Fountain, Inc. Multi-stage code generator and decoder for communication systems
US9240810B2 (en) 2002-06-11 2016-01-19 Digital Fountain, Inc. Systems and processes for decoding chain reaction codes through inactivation
KR101143282B1 (ko) 2002-10-05 2012-05-08 디지털 파운튼, 인크. 연쇄 반응 코드의 체계적 인코딩 및 디코딩
EP1665539B1 (en) 2003-10-06 2013-04-10 Digital Fountain, Inc. Soft-Decision Decoding of Multi-Stage Chain Reaction Codes
US7430617B2 (en) * 2003-12-19 2008-09-30 Nokia Corporation Method and system for header compression
EP1743431A4 (en) 2004-05-07 2007-05-02 Digital Fountain Inc SYSTEM FOR DOWNLOADING AND RECORDING AND CONTINUOUS READING OF FILES
DE602004003933T2 (de) 2004-08-06 2007-04-12 Matsushita Electric Industrial Co., Ltd., Kadoma Rückkopplungssteuerung für Multicast und Broadcast Dienste
ATE405058T1 (de) * 2005-02-15 2008-08-15 Ericsson Telefon Ab L M Empfänger und empfängersteuerverfahren
US7970015B2 (en) * 2005-09-12 2011-06-28 Hob Gmbh & Co. Kg Method for transmitting a message by compressed data transmission between a sender and a receiver via a data network
KR20070057587A (ko) * 2005-12-02 2007-06-07 삼성전자주식회사 무선 개인영역 네트워크에서의 국부 혼잡 회피 방법
US8462627B2 (en) * 2005-12-30 2013-06-11 Altec Lansing Australia Pty Ltd Media data transfer in a network environment
WO2007095550A2 (en) 2006-02-13 2007-08-23 Digital Fountain, Inc. Streaming and buffering using variable fec overhead and protection periods
US9270414B2 (en) 2006-02-21 2016-02-23 Digital Fountain, Inc. Multiple-field based code generator and decoder for communications systems
US8595581B2 (en) * 2006-04-11 2013-11-26 Thomson Licensing Data reception method, repair method and corresponding terminal
WO2007134196A2 (en) 2006-05-10 2007-11-22 Digital Fountain, Inc. Code generator and decoder using hybrid codes
US9178535B2 (en) 2006-06-09 2015-11-03 Digital Fountain, Inc. Dynamic stream interleaving and sub-stream based delivery
US9209934B2 (en) 2006-06-09 2015-12-08 Qualcomm Incorporated Enhanced block-request streaming using cooperative parallel HTTP and forward error correction
US9432433B2 (en) 2006-06-09 2016-08-30 Qualcomm Incorporated Enhanced block-request streaming system using signaling or block creation
US9386064B2 (en) 2006-06-09 2016-07-05 Qualcomm Incorporated Enhanced block-request streaming using URL templates and construction rules
US9419749B2 (en) 2009-08-19 2016-08-16 Qualcomm Incorporated Methods and apparatus employing FEC codes with permanent inactivation of symbols for encoding and decoding processes
US9380096B2 (en) 2006-06-09 2016-06-28 Qualcomm Incorporated Enhanced block-request streaming system for handling low-latency streaming
WO2008084441A1 (en) * 2007-01-10 2008-07-17 Nokia Corporation System and method for implementing mbms handover during download delivery
WO2008119673A1 (en) * 2007-03-30 2008-10-09 Thomson Licensing Robust file casting for mobile tv
US8780777B2 (en) * 2007-04-20 2014-07-15 Blackberry Limited Method and apparatus for user equipment for long term evolution multimedia broadcast multicast services
US7852795B2 (en) 2007-04-20 2010-12-14 Research In Motion Limited Polling method and apparatus for long term evolution multimedia broadcast multicast services
CA2697764A1 (en) 2007-09-12 2009-03-19 Steve Chen Generating and communicating source identification information to enable reliable communications
US8537746B2 (en) 2008-06-09 2013-09-17 Lg Electronics Inc. Method for mapping signaling information to announcement information and broadcast receiver
CN101668027B (zh) * 2008-09-04 2013-04-24 中国电信股份有限公司 多媒体内容的提供方法、系统和客户端
CN101365000B (zh) * 2008-09-24 2012-06-27 清华大学 一种流媒体数据传送方法及网络节点
TWI486040B (zh) 2008-10-10 2015-05-21 Thomson Licensing 在接收器要求失落符號之方法及其接收器
CN101420317B (zh) * 2008-11-21 2011-10-26 华为终端有限公司 媒体文件录制错误的修复方法、录制终端、服务器和系统
US9369516B2 (en) 2009-01-13 2016-06-14 Viasat, Inc. Deltacasting
US9281847B2 (en) 2009-02-27 2016-03-08 Qualcomm Incorporated Mobile reception of digital video broadcasting—terrestrial services
US9634845B2 (en) 2009-07-08 2017-04-25 Telefonaktiebolaget Lm Ericsson (Publ) Session switching during ongoing data delivery in a network
US9015564B2 (en) 2009-08-19 2015-04-21 Qualcomm Incorporated Content delivery system with allocation of source data and repair data among HTTP servers
US9288010B2 (en) 2009-08-19 2016-03-15 Qualcomm Incorporated Universal file delivery methods for providing unequal error protection and bundled file delivery services
US9917874B2 (en) 2009-09-22 2018-03-13 Qualcomm Incorporated Enhanced block-request streaming using block partitioning or request controls for improved client-side handling
US20110295931A1 (en) * 2010-05-27 2011-12-01 Robert Paul Morris Methods, systems, and computer program products for processing a combined command response
US9596447B2 (en) 2010-07-21 2017-03-14 Qualcomm Incorporated Providing frame packing type information for video coding
US9456015B2 (en) 2010-08-10 2016-09-27 Qualcomm Incorporated Representation groups for network streaming of coded multimedia data
US9270299B2 (en) 2011-02-11 2016-02-23 Qualcomm Incorporated Encoding and decoding using elastic codes with flexible source block mapping
US8958375B2 (en) * 2011-02-11 2015-02-17 Qualcomm Incorporated Framing for an improved radio link protocol including FEC
EP4024760A1 (en) 2011-06-14 2022-07-06 ViaSat Inc. Transport protocol for anticipatory content
US8750179B2 (en) 2011-08-15 2014-06-10 Blackberry Limited Efficient multimedia broadcast multicast service continuity methods
US9253233B2 (en) 2011-08-31 2016-02-02 Qualcomm Incorporated Switch signaling methods providing improved switching between representations for adaptive HTTP streaming
US9843844B2 (en) 2011-10-05 2017-12-12 Qualcomm Incorporated Network streaming of media data
US9407355B1 (en) 2011-10-25 2016-08-02 Viasat Inc. Opportunistic content delivery using delta coding
US9294226B2 (en) 2012-03-26 2016-03-22 Qualcomm Incorporated Universal object delivery and template-based file delivery
US9264481B2 (en) * 2012-03-30 2016-02-16 Qualcomm Incorporated Responding to hypertext transfer protocol (HTTP) requests
US9438883B2 (en) * 2012-04-09 2016-09-06 Intel Corporation Quality of experience reporting for combined unicast-multicast/broadcast streaming of media content
US8432808B1 (en) 2012-06-15 2013-04-30 Viasat Inc. Opportunistically delayed delivery in a satellite network
US9723523B2 (en) * 2012-08-03 2017-08-01 Blackberry Limited Maintaining MBMS continuity
US20140098745A1 (en) * 2012-10-04 2014-04-10 Qualcomm Incorporated Method and system for compressing data packets in lte evolved multicast broadcast multimedia service
EP3036909A4 (en) * 2013-08-19 2017-05-17 LG Electronics Inc. Broadcast transmitting device, broadcast receiving device, operating method of the broadcast transmitting device, and operating method of the broadcast receiving device
JP2017511014A (ja) 2014-01-02 2017-04-13 エルジー エレクトロニクス インコーポレイティド 放送伝送装置、放送伝送装置の動作方法、放送受信装置及び放送受信装置の動作方法
EP3133817A4 (en) 2014-04-18 2017-11-15 LG Electronics Inc. Broadcast signal transmitting apparatus, broadcast signal receiving apparatus, broadcast signal transmitting method and broadcast signal receiving method
US9621618B2 (en) * 2014-12-22 2017-04-11 Telefonaktiebolaget Lm Ericsson (Publ) Packet analyzer device and method to measure a video quality of transmitted IP multicast media
CN106063190B (zh) * 2014-12-25 2019-06-28 华为技术有限公司 一种文件修复的方法、相关装置及系统
US10454985B2 (en) * 2015-03-04 2019-10-22 Qualcomm Incorporated File format based streaming with dash formats based on LCT
US9673937B2 (en) 2015-10-12 2017-06-06 International Business Machines Corporation Adaptive network communication protocols
TWI634483B (zh) * 2017-09-14 2018-09-01 和碩聯合科技股份有限公司 檔案合成方法、檔案還原方法以及使用此些方法的電子裝置
WO2022240198A1 (ko) * 2021-05-11 2022-11-17 엘지전자 주식회사 무선 통신 시스템에서 harq-ack 정보 송수신 방법 및 장치

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH05207023A (ja) * 1992-01-24 1993-08-13 Hitachi Ltd 大量データ伝送方法
US6516435B1 (en) * 1997-06-04 2003-02-04 Kabushiki Kaisha Toshiba Code transmission scheme for communication system using error correcting codes
US7363569B2 (en) * 2001-06-29 2008-04-22 Intel Corporation Correcting for data losses with feedback and response
US6912231B2 (en) * 2001-07-26 2005-06-28 Northrop Grumman Corporation Multi-broadcast bandwidth control system
US7017102B1 (en) * 2001-12-27 2006-03-21 Network Equipment Technologies, Inc. Forward Error Correction (FEC) for packetized data networks
AU2003238968A1 (en) 2002-06-11 2003-12-22 Meshnetworks, Inc. System and method for multicast media access in ad-hoc communication networks
CN1228974C (zh) * 2003-01-09 2005-11-23 北京泰美世纪科技有限公司 数字多媒体广播系统中的信号通讯的传送系统和方法
US7502474B2 (en) * 2004-05-06 2009-03-10 Advanced Micro Devices, Inc. Network interface with security association data prefetch for high speed offloaded security processing

Also Published As

Publication number Publication date
EP1771992A1 (en) 2007-04-11
WO2006013460A1 (en) 2006-02-09
PL1771992T3 (pl) 2010-06-30
DE602005019051D1 (de) 2010-03-11
AU2005268493B2 (en) 2009-10-08
CN1969528A (zh) 2007-05-23
CA2574083A1 (en) 2006-02-09
RU2371863C2 (ru) 2009-10-27
US20060023652A1 (en) 2006-02-02
CA2574083C (en) 2011-04-26
ZA200700792B (en) 2009-04-29
JP4625080B2 (ja) 2011-02-02
ATE456239T1 (de) 2010-02-15
RU2007101528A (ru) 2008-09-10
CN1969528B (zh) 2012-10-03
EP1771992B1 (en) 2010-01-20
JP2008508762A (ja) 2008-03-21
TWI307591B (en) 2009-03-11
MXPA06013544A (es) 2007-01-26
AU2005268493A1 (en) 2006-02-09
US7376150B2 (en) 2008-05-20
TW200635306A (en) 2006-10-01
BRPI0513969A (pt) 2008-05-20

Similar Documents

Publication Publication Date Title
BRPI0513969B1 (pt) Método para transmitir símbolos de dados, sistema para transmissão de símbolos de dados, transmissor em um sistema, elemento de rede e receptor
KR100855386B1 (ko) 손실 부분들의 식별 및 재전송
EP1771964B1 (en) Point-to-point repair request mechanism for point-to-multipoint transmission systems
KR100883576B1 (ko) 멀티캐스트/브로드캐스트 데이터 배포를 위한 데이터 복구강화
KR100870236B1 (ko) 점-대-다중점 송신 시스템을 위한 점-대-점 보수 응답메커니즘
MXPA06008486A (es) Identificacion y retransmision de partes perdidas
MXPA06011288A (en) Data repair enhancements for multicast/broadcast data distribution

Legal Events

Date Code Title Description
B25A Requested transfer of rights approved

Owner name: NOKIA TECHNOLOGIES OY (FI)

B06T Formal requirements before examination [chapter 6.20 patent gazette]
B15K Others concerning applications: alteration of classification

Ipc: H04L 12/18 (2006.01), H04L 29/08 (2006.01), H04L 2

B09A Decision: intention to grant [chapter 9.1 patent gazette]
B16A Patent or certificate of addition of invention granted [chapter 16.1 patent gazette]

Free format text: PRAZO DE VALIDADE: 10 (DEZ) ANOS CONTADOS A PARTIR DE 16/04/2019, OBSERVADAS AS CONDICOES LEGAIS. (CO) 10 (DEZ) ANOS CONTADOS A PARTIR DE 16/04/2019, OBSERVADAS AS CONDICOES LEGAIS