BR112019024070A2

BR112019024070A2 - Método de ingestão e de distribuição de mídia, aparelho empacotador de mídia, servidor de origem, nó de ponto terminal, e, rede de transmissão contínua em mídia

Info

Publication number: BR112019024070A2
Application number: BR112019024070-5A
Authority: BR
Inventors: Lohmar Thorsten; John Slssingar Michael
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2017-05-16
Filing date: 2017-05-16
Publication date: 2020-06-02
Also published as: WO2018210411A1; US20200077161A1; CN110915180A; US11019409B2; EP3625943B1; EP3625943A1; US11800200B2; US20210274266A1; CN110915180B

Abstract

são descritos um sistema e um método de distribuição de mídia em que uma rede de transmissão contínua em mídia inclui uma parte da rede de ingestão de mídia configurada para prover o carregamento com baixa latência dos fragmentos de mídia de um fluxo contínuo de mídia ao vivo segmentado usando a codificação de transferência aglomerada (cte) http. em uma modalidade, um ou mais fragmentos de um segmento são carregados ou de outra forma ingeridos em uma base aglomerado por aglomerado antes da íntegra dos dados de mídia do segmento ficar disponível. uma parte da rede de distribuição de difusão seletiva por ip acoplada na parte da rede de ingestão de mídia é operativa para distribuir os dados de mídia aglomerado para um ou mais destinatários de difusão seletiva por ip usando um protocolo de difusão seletiva por ip. uma aplicação cliente é operativa para a transferência dos dados de mídia em uma sessão de distribuição http cte com um destinatário de difusão seletiva por ip de serviço.

Description

MÉTODO DE INGESTÃO E DE DISTRIBUIÇÃO DE MÍDIA, APARELHO EMPACOTADOR DE MÍDIA, SERVIDOR DE ORIGEM, NÓ DE PONTO TERMINAL, E, REDE DE TRANSMISSÃO CONTÍNUA EM MÍDIA

Campo da Descrição

[001] A presente descrição, no geral, refere-se a redes de comunicação. Mais particularmente, e não a título de nenhuma limitação, a presente descrição é direcionada a uma arquitetura de rede, um sistema, dispositivos e métodos para facilitar a ingestão e distribuição de mídia de baixa latência usando difusão seletiva confiável através de uma ou mais redes fixas, redes sem fio e/ou qualquer combinação das mesmas.

Fundamentos da Invenção

[002] Com as crescentes taxas de dados oferecidas por redes fixas e móveis, os serviços de transmissão contínua de multimídia estão recebendo distribuição mais ampla. O consumo de vídeo móvel também está explodindo, dado o sempre crescente número de telefones inteligentes no mercado. A fim de realizar a transmissão contínua de vídeo, o Protocolo de Transmissão Contínua em Tempo Real (RTSP) e o Protocolo de Descrição da Sessão (SDP) para a configuração e o controle de sessão e o Protocolo de Transporte em Tempo Real (RTP) para o transporte de fala, áudio e vídeo em tempo real são amplamente usados. Para lidar com taxas de bits flutuantes no caminho de transmissão, as técnicas de transmissão contínua RTP adaptativas também são usadas. Entretanto, é bem conhecido que a transmissão contínua RTSP/RTP tem diversas deficiências em ambientes de rede que incluem travessias por firewalls e tradução de endereço de rede (NAT).

[003] A tecnologia de transmissão contínua adaptativa com base em

Protocolo de Transferência por Hipertexto (HTTP) está sendo implementada para tratar crescentes demandas do consumidor para o conteúdo da transmissão contínua (por exemplo, filmes/TV de difusão e sob demanda,

Petição 870200002271, de 06/01/2020, pág. 7/144

2/103 etc.) através de uma variedade de infraestruturas de rede para estações assinantes com desempenho e protocolos amplamente diferentes, em ambientes de rede tanto gerenciados quanto não gerenciados. A difusão seletiva por IP (Protocolo da Internet) está sendo perseguida em arquiteturas de rede tanto fixas quanto móveis para alavancar as economias de escala, bem como para abordar problemas, tais como largura de banda, proteção de conteúdo, escalonabilidade e alcançabilidade, além de alcançar os indicadores de desempenho chave (KPI), entre outros. Enquanto que os avanços na tecnologia de distribuição de mídia continuam rapidamente, diversos problemas permanecem desafiadores, especialmente, em relação a distribuição de mídia ao vivo.

Sumário da Invenção

[004] Para os fluxos contínuos de mídia ao vivo adaptativos, é desejável reduzir o atraso ponta a ponta geral, de forma que a mídia visualizada pelo consumidor final seja tão próxima quanto possível no tempo da realidade. Os atrasos podem ser causados por diversos fatores, todos os quais podem contribuir para o atraso ponta a ponta geral em uma rede de transmissão contínua em mídia. Por exemplo, em relação a um evento ao vivo, há um componente de atraso em relação à captura, à codificação e ao processamento de mídia. Quando a segmentação de mídia for implementada em uma arquitetura de transmissão contínua de taxa de bits adaptativa (ABR), pode haver um atraso de carregamento quando os segmentos não puderem ser disponibilizados para os nós servidores até que os segmentos sejam completamente processados.

[005] A presente descrição de patente é amplamente direcionada para sistemas, métodos, aparelhos, bem como nós de rede e mídia legível por computador associada não transitória para facilitar a distribuição de mídia em uma rede de transmissão contínua em mídia que inclui uma parte da rede de ingestão de mídia configurada para prover o carregamento com baixa latência

Petição 870200002271, de 06/01/2020, pág. 8/144

3/103 dos fragmentos de mídia de um fluxo contínuo de mídia ao vivo segmentado usando a codificação de transferência aglomerada (CTE) HTTP. Em uma modalidade de exemplo, um ou mais fragmentos de um segmento são carregados ou de outra forma providos, por exemplo, incluindo, mas sem limitações, mecanismos de transferência de dados disparados por empurrar, puxar e/ou híbrido, em uma base aglomerado por aglomerado, antes da íntegra dos dados de mídia do segmento ficar disponível. Uma parte da rede de distribuição de difusão seletiva por IP acoplada na parte da rede de ingestão de mídia é operativa para distribuir os dados de mídia aglomerados para um ou mais destinatários de difusão seletiva por IP usando um protocolo de difusão seletiva por IP. Em uma modalidade, uma aplicação cliente é operativa para a transferência dos dados de mídia em uma sessão de distribuição HTTP CTE com um destinatário de difusão seletiva por IP de serviço. Em uma outra modalidade, uma aplicação cliente pode ser integrada com a funcionalidade do receptor de difusão seletiva por IP, em que as chamadas API adequadas podem ser usadas em vez de HTTP CTE para localizar e carregar os dados de mídia.

[006] Em um aspecto, um método de ingestão de mídia de baixa latência, por exemplo, incluindo puxar, empurrar, etc., é descrito. O método compreende, entre outras coisas, gerar, por um nó empacotador de mídia, um fluxo contínuo de mídia segmentado a partir de um fluxo contínuo de mídia de entrada, em que cada segmento compreende uma pluralidade de fragmentos, cada fragmento compreendendo um ou mais quadros de dados de mídia, por exemplo, quadros de áudio, quadros de vídeo, ou uma combinação dos mesmos. O fluxo contínuo segmentado é identificado para ser para distribuição usando a difusão seletiva por IP, e é associado com um grupo de difusão seletiva por IP em particular. Opcionalmente, um protocolo de difusão seletiva por IP em particular (por exemplo, NORM, FLUTE, FCAST, etc.) pode ser identificado. Uma sessão CTE HTTP é iniciada entre o nó

Petição 870200002271, de 06/01/2020, pág. 9/144

4/103 empacotador de mídia e um nó servidor de origem. Isto pode ser feito pelo nó empacotador de mídia, por exemplo, em um cenário empurrar, pelo servidor de origem, por exemplo, em um cenário puxar, ou por um nó de controle adicional. O servidor de origem pode ser, por exemplo, associado com uma rede de distribuição de conteúdo (CDN), ou pode ser um nó do centro de serviço de difusão seletiva para difusão, BMSC, de uma rede de telecomunicações móveis. Para cada segmento N do fluxo contínuo segmentado, os seguintes atos são realizados: começar a ingestão de fragmentos do segmento N para o nó servidor de origem antes da íntegra dos dados de mídia para o segmento N estar disponível, em uma base aglomerado por aglomerado por meio da sessão CTE HTTP, em que um ou mais aglomerados são providos para transmitir cada fragmento; e enviar um sinal de último aglomerado para o nó servidor de origem depois que todos os fragmentos do segmento N tiverem sido transmitidos. Em algumas modalidades, o segmentador pode ser configurado para carregar os fragmentos apenas depois de receber uma solicitação HTTP GET. Em outras modalidades, o segmentador pode carregar os fragmentos de acordo com o tempo de disponibilidade do segmento. Em ainda uma outra variação, o método de ingestão de mídia pode incluir enviar uma indicação para o nó servidor de origem, antes de começar o carregamento dos fragmentos, para indicar o número de aglomerados providos para empacotar e transmitir cada fragmento.

[007] Em um outro aspecto, um aparelho empacotador de mídia é descrito, o aparelho compreendendo pelo menos uma interface de rede configurada para receber os fluxos contínuos de mídia ao vivo a partir de uma ou mais fontes de conteúdo. O aparelho empacotador de mídia é configurado para segmentar um fluxo contínuo de mídia ao vivo recebido em uma pluralidade de segmentos, em que cada segmento compreende uma pluralidade de fragmentos, cada fragmento compreendendo um ou mais

Petição 870200002271, de 06/01/2020, pág. 10/144

5/103 quadros de dados de mídia, para identificar que o fluxo contínuo segmentado deve ser distribuído usando a difusão seletiva por IP e associar o fluxo contínuo segmentado com um grupo de difusão seletiva por IP em particular e para iniciar uma sessão de codificação de transferência aglomerada, CTE, HTTP com um nó servidor de origem. O mesmo é adicionalmente configurado para começar a ingestão de fragmentos de um segmento N para o nó servidor de origem por meio da sessão CTE antes da íntegra dos dados de mídia para o segmento N estar disponível, em que um ou mais aglomerados são providos para transmitir cada fragmento e enviar um sinal de último aglomerado para o nó servidor de origem depois que todos os fragmentos do segmento N tiverem sido transmitidos. O aparelho empacotador de mídia pode compreender um codificador para gerar uma pluralidade de representações de taxa de bits para cada fluxo contínuo de mídia ao vivo e/ou um segmentador configurado para segmentar cada representação de taxa de bits de um fluxo contínuo de mídia ao vivo em particular em uma pluralidade de segmentos. O mesmo pode compreender adicionalmente um ou mais processadores e um ou mais módulos de memória persistentes com instruções de programa armazenadas nos mesmos que, quando executadas pelos um ou mais processadores, realizam as etapas expostas.

[008] Em um outro aspecto, um método de distribuição de mídia que é adaptado para a transmissão de fragmentos de baixa latência é descrito. O método compreende, entre outras coisas, receber em um nó servidor de origem uma mensagem proveniente de um nó empacotador de mídia para começar uma sessão CTE HTTP com o nó empacotador de mídia, em que a mensagem inclui uma indicação de que os dados de mídia de um fluxo contínuo de mídia ao vivo serão ingeridos para o nó servidor de origem. Para cada segmento N do fluxo contínuo de mídia, um ou mais cabeçalhos HTTP são recebidos a partir do nó empacotador de mídia. Posteriormente, um ou mais fragmentos do segmento são recebidos, em uma base aglomerado por

Petição 870200002271, de 06/01/2020, pág. 11/144

6/103 aglomerado por meio da sessão CTE HTTP, cada aglomerado tendo uma marca de limite de aglomerado, em que cada fragmento contém um ou mais quadros de dados de mídia e é recebido antes da íntegra dos dados de mídia para o segmento estar disponível no nó empacotador de mídia. A marca de limite de aglomerado pode ser, por exemplo, realizada através da indicação do tamanho do aglomerado, que é provida no início de um aglomerado HTTP. Os objetos de transporte, particularmente, os objetos de transporte em difusão seletiva por IP, são gerados para cada aglomerado, que pode ser dependente do protocolo (difusão seletiva por IP) usado. Os objetos de transporte, que podem conter fragmentos completos ou fragmentos parciais, são transportados para uma pluralidade de receptores, por exemplo, nós de borda CDN, particularmente, as portas de comunicação domésticas e/ou os terminais de usuário. Dependendo da implementação, a sinalização explícita ou inerente pode ser provida para indicar transmissão/recepção de um último aglomerado a partir do nó empacotador de mídia, por exemplo, depois que todos os fragmentos do segmento tiverem sido carregados. Em uma variação adicional, responsivo a um sinal de último aglomerado, os tamanhos de todos os aglomerados podem ser somados para gerar uma indicação de tamanho do objeto associada com o segmento e sinalizada para a pluralidade de receptores de difusão seletiva em borda.

[009] Em um outro aspecto, um servidor de origem é descrito, que compreende um servidor e/ou cliente de codificação de transferência aglomerada, CTE, HTTP e um emissor de difusão seletiva por IP. O servidor de origem é configurado para receber uma mensagem a partir de um nó empacotador de mídia para começar uma sessão CTE HTTP com o nó empacotador de mídia, a mensagem incluindo uma indicação de que os dados de mídia de um fluxo contínuo de mídia ao vivo segmentado são providos em uma distribuição aglomerada, e para receber, para cada segmento N do fluxo contínuo de mídia ao vivo, um ou mais cabeçalhos HTTP a partir do nó

Petição 870200002271, de 06/01/2020, pág. 12/144

7/103 empacotador de mídia e um ou mais fragmentos do segmento, em uma base aglomerado por aglomerado por meio da sessão CTE HTTP, cada aglomerado tendo uma marca de limite de aglomerado, em que cada fragmento contém um ou mais quadros dos dados de mídia e é recebido antes da íntegra dos dados de mídia para o segmento estar disponível no nó empacotador de mídia. O mesmo é adicionalmente configurado para gerar os objetos de transporte, particularmente, os objetos de transporte em difusão seletiva por IP, para os aglomerados recebidos e transmitir os objetos de transporte para uma pluralidade de receptores, e para receber um sinal de último aglomerado a partir do nó empacotador de mídia depois que todos os fragmentos do segmento tiverem sido ingeridos.

[0010] Nos aspectos expostos, o servidor de origem pode ser, por exemplo, associado com uma rede de distribuição de conteúdo (CDN), ou pode ser um nó do centro de serviço de difusão seletiva para difusão, BMSC, de uma rede de telecomunicações móveis. Adicionalmente, a ingestão pode, neste contexto, significar carregamento, por exemplo, pelo nó empacotador de mídia para o nó servidor de origem, descarregamento, por exemplo, pelo nó servidor de origem a partir do nó empacotador de mídia, ou outra forma de transferência do nó empacotador de mídia para o nó servidor de origem. Em uma modalidade exemplar, o sinal de último aglomerado pode ser realizado pelo envio de um aglomerado HTTP com zero byte de tamanho. Isto indica que a transmissão da parte do corpo HTTP está concluída.

[0011] Em um aspecto adicional, um método de distribuição de mídia com base na recepção de fragmentos de baixa latência é descrito. O método compreende, entre outras coisas, receber, em um receptor de difusão seletiva por IP, uma mensagem da informação de difusão seletiva por IP em relação à distribuição de dados de mídia de um fluxo contínuo de mídia ao vivo a partir de um emissor de difusão seletiva por IP. Em um arranjo, a mensagem da informação de difusão seletiva por IP pode incluir os cabeçalhos HTTP que

Petição 870200002271, de 06/01/2020, pág. 13/144

8/103 contêm a informação de local, o tipo de MIME, e outros metadados. Os objetos de transporte em difusão seletiva por IP específicos de protocolo que incluem os pacotes de dados de mídia são recebidos a partir do emissor de difusão seletiva por IP. Com base na informação do ID de carga útil, por exemplo, o ID de carga útil da FEC, os pacotes são ordenados e podem ser empacotados em segmentos, fragmentos e/ou, particularmente, aglomerados. Nisto, cada segmento, fragmento e/ou aglomerado compreende um ou mais quadros de dados de mídia. Responsivo à recepção de uma solicitação de canal a partir de um dispositivo cliente pelo fluxo contínuo de mídia ao vivo, um ou mais cabeçalhos HTTP são gerados, e os aglomerados são servidos em uma base aglomerado por aglomerado para o dispositivo cliente por meio de uma sessão de codificação de transferência aglomerada (CTE) HTTP. Os cabeçalhos HTTP podem, nisto, ser usados pelo dispositivo cliente para descarregamento dos dados do segmento, do fragmento ou do aglomerado a partir do emissor de difusão seletiva por IP por meio da sessão CTE HTTP em uma base aglomerado por aglomerado para cada segmento.

[0012] Neste método, o emissor de difusão seletiva por IP pode ser um servidor de origem, como exposto, isto é, por exemplo, um servidor de borda associado com a rede de distribuição de conteúdo (CDN), ou um nó do centro de serviço de difusão seletiva para difusão, BMSC, de uma rede de telecomunicações móveis.

[0013] No último caso, quando o emissor de difusão seletiva por IP for um nó BMSC, uma modalidade do método de distribuição de mídia pode ser um método de difusão de mídia operativo em uma rede de telecomunicações móveis que serve uma pluralidade de dispositivos de equipamento de usuário (UE) sem fio, cada qual incluindo um cliente de difusão. Este método compreende, entre outras coisas, receber, no nó do centro de serviço de difusão seletiva para difusão (BMSC) da rede de telecomunicações móveis, um ou mais fragmentos de cada segmento de um

Petição 870200002271, de 06/01/2020, pág. 14/144

9/103 fluxo contínuo de mídia segmentado em uma base aglomerado por aglomerado por meio de uma sessão CTE HTTP com um nó empacotador de mídia, em que cada fragmento é recebido antes da íntegra dos dados de um segmento estar disponível no nó empacotador de mídia. Um objeto FLUTE pode ser criado em relação aos dados de mídia. Em um caso, um objeto de transporte FLUTE pode ser criado para cada aglomerado HTTP. Em um outro caso, múltiplos aglomerados HTTP para um fragmento podem ser coletados e transmitidos como um único objeto de transporte FLUTE. Os um ou mais objetos FLUTE podem ser transmitidos para a pluralidade de dispositivos UE sem fio em uma sessão de difusão, em que o objeto FLUTE é associado com os metadados do segmento e do aglomerado através de uma instância da Tabela de Distribuição de Arquivo (FDT). Depois que todos os fragmentos (também referidos como “Aglomerados” em alguns arranjos e/ou certas literaturas técnicas) para o segmento tiverem sido recebidos, uma indicação de sinal de último aglomerado pode ser provida na instância FDT para a pluralidade de dispositivos UE sem fio. Em uma implementação, a instância FDT é estendida para incluir um parâmetro Comprimento do Aglomerado para identificar que os dados de mídia dos segmentos são providos em distribuição aglomerada, que também pode ser configurada para indicar o tamanho do objeto FLUTE (por exemplo, em bytes). Em uma variação adicional, a instância FDT pode ser estendida para incluir um parâmetro Deslocamento do Aglomerado para indicar um local relativo, por exemplo, em referência a um localizador de base. Cada aglomerado pode ser conduzido como um objeto de transporte FLUTE com um ID do Objeto de Transporte (TOI) exclusivo. Quando o emissor coletar todos os aglomerados de um fragmento, então, cada fragmento pode ser conduzido como um objeto de transporte FLUTE. Logicamente, em um arranjo, o transmissor é operativo para criar um novo aglomerado pela combinação de todos os aglomerados de um fragmento em um novo e maior aglomerado. O Deslocamento do

Petição 870200002271, de 06/01/2020, pág. 15/144

10/103

Aglomerado pode ser configurado para identificar o local relativo dos dados no segmento abrangente. O Deslocamento do Aglomerado e o Tamanho do Aglomerado podem ser úteis em certas modalidades para detectar os aglomerados ausentes no fluxo. Em ainda um outro aspecto, é descrito um nó de ponto terminal associado com uma rede de distribuição de difusão seletiva por IP, que compreende um receptor de difusão seletiva por IP. O nó de ponto terminal é configurado para receber uma mensagem da informação de difusão seletiva por IP em relação à distribuição de dados de mídia de um fluxo contínuo de mídia ao vivo a partir de um emissor de difusão seletiva por IP e objetos de transporte em difusão seletiva por IP a partir do emissor de difusão seletiva por IP, os objetos de transmissão da difusão seletiva por IP incluindo os pacotes de dados de mídia. O mesmo é adicionalmente configurado para ordenar os pacotes de dados de mídia com base na informação de ID de carga útil sequencial, para gerar os aglomerados de dados de mídia com base nos pacotes ordenados e, responsivo à recepção de uma solicitação de canal a partir de um cliente para o fluxo contínuo de mídia ao vivo, servir os aglomerados para o dispositivo cliente. A fim de realizar estas funções, podem ser previstos um ou mais processadores que são operativos para executar as instruções de programa que podem ser armazenadas em uma memória, particularmente, uma memória persistente e não volátil.

[0014] Em uma modalidade do nó de ponto terminal, o receptor de difusão seletiva por IP pode ser integrado com um dispositivo UE sem fio, particularmente, um UE operativo para receber mídia de difusão/difusão seletiva em uma rede LTE. O dispositivo UE compreende, entre outras coisas, um servidor ou proxy de codificação HTTP CTE e um cliente do serviço de difusão/difusão seletiva multimídia evoluído (eMBMS) que pode incluir um cliente e respectivo receptor de difusão seletiva por IP e um receptor HTTP CTE. O dispositivo UE é configurado para receber, no receptor de difusão seletiva por IP, uma mensagem da informação de difusão seletiva por IP em

Petição 870200002271, de 06/01/2020, pág. 16/144

11/103 relação à distribuição de dados de mídia de um fluxo contínuo de mídia segmentado a partir de um emissor de difusão seletiva por IP associado com um nó BMSC, receber, no receptor de difusão seletiva por IP, uma pluralidade de objetos FLUTE (por exemplo, um objeto FLUTE por cada aglomerado HTTP, ou um objeto FLUTE por todos os aglomerados de um fragmento, da forma apresentada previamente), cada qual contendo os pacotes dos dados de mídia para um fragmento de um segmento no fluxo contínuo de mídia segmentado, e para criar os aglomerados dos dados de mídia com base nos pacotes ordenados. Opcionalmente, os aglomerados provenientes de múltiplos objetos FLUTE podem ser combinados para formar os segmentos dos dados de mídia. Responsivo à recepção uma solicitação de segmento a partir do receptor HTTP CTE, podem ser gerados um ou mais cabeçalhos HTTP, que podem ser utilizados pelo receptor CTE para descarregamento dos segmentos a partir de um servidor HTTP CTE por meio da(s) sessão(ões) CTE HTTP em uma base aglomerado por aglomerado para cada segmento. Os dados de aglomerado recebidos podem ser providos para um armazenamento temporário do reprodutor de mídia para renderização em um visor do dispositivo UE sem fio.

[0015] Em ainda um outro aspecto, é provida uma rede de transmissão contínua em mídia, que compreende uma parte da rede de ingestão de mídia configurada para prover o carregamento com baixa latência dos fragmentos de mídia de um fluxo contínuo de mídia ao vivo segmentado usando a codificação de transferência aglomerada, CTE, HTTP em que um ou mais fragmentos de um segmento são ingeridos em uma base aglomerado por aglomerado antes da íntegra dos dados de mídia do segmento ficar disponível, uma parte da rede de distribuição em difusão seletiva por Protocolo da Internet, IP, acoplada na parte da rede de ingestão de mídia, a parte da rede de distribuição de difusão seletiva por IP configurada para distribuir os dados de mídia aglomerados para um ou mais destinatários de difusão seletiva por IP

Petição 870200002271, de 06/01/2020, pág. 17/144

12/103 usando um protocolo de difusão seletiva por IP e uma parte da rede de distribuição configurada para distribuir os dados de mídia para um cliente em uma sessão de transferência HTTP CTE com um destinatário de difusão seletiva por IP de serviço. A rede de transmissão contínua em mídia pode compreender um empacotador de mídia, um servidor de origem e/ou um nó de ponto terminal, como exposto.

[0016] Os benefícios da presente invenção incluem, mas sem limitações, prover uma arquitetura de rede e sistemas e métodos associados em que o atraso de transmissão no interior de uma CDN ou uma rede de difusão móvel pode ser significativamente reduzido mesmo quando um protocolo de difusão seletiva por IP confiável for usado para a distribuição de mídia. Desta maneira, os benefícios da difusão seletiva por IP podem ser vantajosamente alavancados sem impactar negativamente a experiência da qualidade do usuário em ambientes com fios bem como sem fio. Adicionalmente, a introdução da condução DASH/ISOBMFF em uma implementação de difusão LTE com baixa latência também é vantajosa em redes de segurança pública. Os benefícios e as vantagens adicionais das modalidades ficarão aparentes em vista da seguinte descrição e dos desenhos anexos.

[0017] Em aspectos ainda adicionais, uma ou mais modalidades de uma mídia legível por computador não transitória ou mídia distribuída que contém as instruções de programa executáveis por computador ou partes de código armazenados na mesma são descritas para realizar uma ou mais modalidades dos métodos da presente invenção quando executadas por uma entidade processadora de um nó de rede, elemento, utensílio virtual, dispositivo UE e congêneres, mutatis mutandis. Os recursos adicionais das várias modalidades são da forma reivindicada e definida nas reivindicações dependentes.

Breve Descrição dos Desenhos

Petição 870200002271, de 06/01/2020, pág. 18/144

13/103

[0018] As modalidades da presente descrição são ilustradas a título de exemplo, e não a título de limitação, nas figuras dos desenhos anexos, em que referências iguais indicam elementos similares. Deve-se notar que referências diferentes a “alguma” ou “uma” modalidade nesta descrição não são necessariamente à mesma modalidade, e tais referências podem significar pelo menos uma. Adicionalmente, quando um recurso, estrutura ou característica em particular forem descritos em conexão com uma modalidade, é subentendido que está no conhecimento dos versados na técnica efetuar tais recurso, estrutura ou característica em conexão com outras modalidades, seja ou não explicitamente descrito.

[0019] Os desenhos anexos são incorporados e formam uma parte da especificação para ilustrar uma ou mais modalidades exemplares da presente descrição. Várias vantagens e recursos da descrição serão entendidos a partir da seguinte descrição detalhada tomada em conexão com as reivindicações anexas e em relação aos desenhos anexos, nos quais:

a figura 1 representa um exemplo generalizado da arquitetura de rede em que uma ou mais modalidades da presente invenção podem ser praticadas para facilitar as ingestões e a distribuição de mídia de baixa latência de acordo com os preceitos aqui expostos;

a figura 2 representa adicionalmente os aspectos do exemplo da arquitetura de rede da figura 1 que ilustra os detalhes adicionais em uma implementação;

a figura 3A representa um exemplo da rede de difusão seletiva de alto nível para praticar uma modalidade da invenção;

a figura 3B é um fluxograma das etapas, blocos ou atos que podem ser refinados, combinados ou arranjados em uma ou mais modalidades e/ou fluxogramas adicionais para facilitar a ingestão e a distribuição de mídia de baixa latência no exemplo da rede de difusão seletiva de alto nível mostrado na figura 3A;

Petição 870200002271, de 06/01/2020, pág. 19/144

14/103 as figuras 4A-4C representam os fluxogramas de mensagem que representam a ingestão e a distribuição de mídia em uma implementação com base em CDN de acordo com uma modalidade de exemplo;

as figuras 5-7 representam vários aspectos de uma arquitetura da rede de telecomunicações móveis configurada para difusão de mídia com os propósitos de uma modalidade da presente invenção;

a figura 8 representa uma sequência de agendamento de sessão em um exemplo da rede de telecomunicações móveis com os propósitos de uma modalidade da presente invenção;

a figura 9 representa um fluxograma de mensagem que representa a ingestão e a distribuição de mídia em um implementação com base em difusão móvel de acordo com uma modalidade de exemplo;

as figuras 10A-10C são os fluxogramas de várias etapas, blocos ou atos que podem ser combinados ou arranjados em uma ou mais modalidades para facilitar a ingestão e a distribuição de mídia de baixa latência em um exemplo de rede de transmissão contínua de acordo com os preceitos do presente pedido de patente;

as figuras 11A e 11B são fluxogramas de várias etapas, blocos ou atos que podem ser combinados ou arranjados em uma ou mais modalidades para facilitar adicionalmente os aspectos de um sistema e um método de ingestão e distribuição de mídia de baixa latência de acordo com os preceitos do presente pedido de patente;

a figura 12 é um fluxograma de várias etapas, blocos ou atos que podem ser combinados ou arranjados em uma ou mais modalidades para facilitar adicionalmente os aspectos de um sistema e um método de ingestão e distribuição de mídia de baixa latência de acordo com os preceitos do presente pedido de patente;

a figura 13 é um fluxograma de várias etapas, blocos ou atos que podem ser combinados ou arranjados em uma ou mais modalidades para

Petição 870200002271, de 06/01/2020, pág. 20/144

15/103 facilitar ainda adicionalmente os aspectos de um sistema e um método de ingestão e distribuição de mídia de baixa latência de acordo com os preceitos do presente pedido de patente;

a figura 14 representa um diagrama de blocos de um aparelho que pode ser configurado ou arranjado como diferentes elementos ou nós de rede operativos para serem implementados em um ou mais estágios de uma rede de transmissão contínua por difusão seletiva com os propósitos de uma ou mais modalidades do presente pedido de patente; e a figura 15 representa um diagrama de blocos de um aparelho que pode ser configurado ou arranjado como um dispositivo tipo equipamento nas dependências ou um dispositivo tipo equipamento de usuário (UE) com os propósitos de uma ou mais modalidades do presente pedido de patente. Descrição Detalhada dos Desenhos

[0020] Na descrição aqui exposta para as modalidades da presente invenção, inúmeros detalhes específicos são providos, tais como exemplos de componentes e/ou métodos, para prover um criterioso entendimento das modalidades da presente invenção. Os versados na técnica irão reconhecer, entretanto, que uma modalidade da invenção pode ser praticada sem um ou mais dos detalhes específicos, ou com outros aparelhos, sistemas, conjuntos, métodos, componentes, materiais, partes e/ou congêneres. Em outras instâncias, estruturas, materiais ou operações bem conhecidos não são especificamente mostrados ou descritos com detalhes para evitar obscurecer os aspectos das modalidades da presente invenção. Desta maneira, será percebido pelos versados na técnica que as modalidades da presente descrição podem ser praticadas sem tais componentes específicos. Deve ser adicionalmente reconhecido que os versados na técnica, com o auxílio da descrição detalhada aqui apresentada e tomando referência aos desenhos anexos, serão capazes de fazer e usar uma ou mais modalidades sem experimentação indevida.

Petição 870200002271, de 06/01/2020, pág. 21/144

16/103

[0021] Adicionalmente, os termos, tais como “acoplado” e “conectado”, juntamente com seus derivados, podem ser usados nas seguintes descrição, reivindicações ou ambas. Entende-se que estes termos não são necessariamente pretendidos como sinônimos uns dos outros. “Acoplado” pode ser usado para indicar que dois ou mais elementos, que podem ou não estar em contato físico ou elétrico direto uns com os outros, cooperam ou interagem uns com os outros. “Conectado” pode ser usado para indicar o estabelecimento de comunicação, isto é, um relacionamento comunicativo, entre dois ou mais elementos que são acoplados uns com os outros. Adicionalmente, em uma ou mais modalidades de exemplo aqui apresentadas, falando no geral, um elemento, componente ou módulo podem ser configurados para realizar uma função se o elemento puder ser programado para realizar ou de outra forma ser estruturalmente arranjado para realizar esta função.

[0022] Da forma aqui usada, um elemento, nó ou subsistema de rede podem ser compostos por uma ou mais peças de equipamento de rede de serviço, incluindo hardware e software que interconectam comunicativamente outro equipamento em uma rede (por exemplo, outros elementos de rede, estações terminais, IP-STBs, STBs legados, etc.), e são adaptados para hospedar uma ou mais aplicações ou serviços, em um ambiente tanto virtualizado quanto não virtualizado, em relação a uma pluralidade de assinantes e equipamentos de usuário associados que são operativos para receber/consumir conteúdo em uma rede de transmissão contínua em mídia em que os ativos do conteúdo de mídia podem ser carregados, distribuídos e distribuídos usando mecanismos de transporte de distribuição aglomerada por HTTP e/ou de difusão seletiva por IP. Como tal, alguns elementos de rede podem ficar dispostos em um ambiente de rede de rádio sem fio enquanto que outros elementos de rede podem ficar dispostos em uma infraestrutura de rede comutada de pacotes pública, incluindo ou de outra forma envolvendo uma

Petição 870200002271, de 06/01/2020, pág. 22/144

17/103 infraestrutura da rede de distribuição/entrega de conteúdo (CDN) e/ou uma infraestrutura da rede da fonte de conteúdo (CSN) adequadas. Adicionalmente, uma ou mais modalidades aqui apresentadas podem envolver redes de portadora fixas e/ou redes de portadora móveis, por exemplo, infraestruturas de distribuição em banda larga terrestre e/ou via satélite, que podem ser exemplificadas por uma arquitetura de rede tipo Linha de Assinante Digital (DSL), uma arquitetura do Sistema de Término do Modem a Cabo (CMTS) em conformidade com a Especificação da Interface do Serviço de Dados Sobre Cabo (DOCSIS), arquitetura IPTV, arquitetura de Difusão de Vídeo Digital (DVB), arquitetura de rede de vídeo digital comutado (SDV), uma arquitetura de rede tipo Fibra-Coaxial Híbrida (HFC), uma arquitetura de rede de acesso via satélite adequada ou uma arquitetura de rede de acesso sem fio em banda larga sobre conectividade celular e/ou WiFi. Desta maneira, alguns elementos de rede podem compreender “múltiplos elementos de rede de serviços” que proveem suporte para múltiplas funções com base em rede (por exemplo, gerenciamento de política da distribuição de mídia A/V, controle de sessão, cumprimento da política de QoS, gerenciamento do agendamento da largura de banda, gerenciamento de política de prioridade do provedor de conteúdo, gerenciamento de política de transmissão contínua e congêneres), além de prover suporte para múltiplos serviços de aplicação (por exemplo, aplicações de dados e de multimídia). As estações terminais de assinante ou os dispositivos clientes de exemplo podem compreender vários dispositivos com capacidade de transmissão contínua que podem consumir ou distribuir ativos do conteúdo de mídia usando tecnologias de transmissão contínua e/ou de transferência com base em arquivo, que podem envolver algum tipo de adaptação de taxa em certas modalidades. Os dispositivos clientes ou os dispositivos tipo equipamento de usuário (UE) ilustrativos podem, portanto, incluir qualquer dispositivo configurado para executar, entre outras coisas, um ou mais aplicações clientes de transmissão contínua para

Petição 870200002271, de 06/01/2020, pág. 23/144

18/103 receber, gravar, armazenar e/ou renderizar conteúdo, mídia ao vivo e/ou mídia estática/sob demanda, provenientes de um ou mais provedores de conteúdo, por exemplo, por meio de um rede de acesso em banda larga, de acordo com uma ou mais tecnologias de transmissão contínua ABR com base em arquivo, tais como, por exemplo, Transmissão Contínua Uniforme Microsoft® Silverlight®, transmissão contínua HTTP (por exemplo, Transmissão Contínua Adaptativa Dinâmica sobre HTTP ou DASH, Transmissão Contínua Ao vivo HTTP ou HLS, Transmissão Contínua Dinâmica HTTP ou HDS, etc.), Icecast, e congêneres, bem como redes de transmissão contínua sobre Protocolo de Transferência em Tempo Real (RTP) com base em Fluxo Contínuo de Transporte (TS) MPEG. Desta maneira, tais dispositivos clientes podem incluir codificadores/decodificadores integrados (STBs) legados, STBs com base em IP da próxima geração, TVs em rede, gravadores de vídeo pessoal/digital (PVR/DVRs), projetores de mídia em rede, laptops portáteis, netbooks, palmtops, tablets, telefones inteligentes, telefones com multimídia/vídeo, equipamento de usuário móvel/sem fio, reprodutores de mídia portáteis, sistemas ou consoles de jogos portáteis (tais como o Wii®, PlayStation 3®, etc.) e congêneres, que podem acessar ou consumir conteúdo/serviços providos por meio de uma rede de distribuição de difusão seletiva por IP de acordo com uma ou mais modalidades aqui apresentadas.

[0023] Uma ou mais modalidades da presente descrição de patente podem ser implementadas usando diferentes combinações de software, software embarcado e/ou hardware. Assim, uma ou mais das técnicas mostradas nas figuras (por exemplo, fluxogramas) podem ser implementadas usando código e dados armazenados e executados em um ou mais dispositivos eletrônicos ou nós (por exemplo, um dispositivo cliente de assinante ou estação terminal, um elemento de rede, etc.). Tais dispositivos eletrônicos podem armazenar e comunicar (intemamente e/ou com outros dispositivos eletrônicos através de uma rede) código e dados usando mídia legível por

Petição 870200002271, de 06/01/2020, pág. 24/144

19/103 computador, tais como mídia de armazenamento legível por computador não transitória (por exemplo, discos magnéticos, discos ópticos, memória de acesso aleatório, memória exclusiva de leitura, dispositivos de memória flash, memória de mudança de fase, etc.), mídia de transmissão legível por computador transitória (por exemplo, elétrica, óptica, acústica ou outra forma de sinais propagados - tais como ondas portadoras, sinais infravermelhos, sinais digitais), etc. Além do mais, tais elementos de rede podem tipicamente incluir um conjunto de um ou mais processadores acoplados em um ou mais outros componentes, tais como um ou mais dispositivos de armazenamento (por exemplo, mídia de armazenamento legível por máquina não transitória), bem como base(s) de dados de armazenamento, dispositivos de entrada/saída do usuário (por exemplo, um teclado, uma tela sensível ao toque, um dispositivo de apontamento e/ou um visor), e conexões de rede para efetuar a sinalização e/ou transmissão de mídia portadora. O acoplamento do conjunto de processadores e outros componentes pode ser, tipicamente, através de um ou mais barramentos e pontes (também chamados de controladores de barramento), arranjados em quaisquer arquiteturas conhecidas (por exemplo, multiprocessamento simétrico/compartilhado) ou até aqui desconhecidas. Assim, o dispositivo ou componente de armazenamento de um dado dispositivo eletrônico ou elemento de rede podem ser configurados para armazenar o código e/ou os dados para execução em um ou mais processadores deste elemento, nó ou dispositivo eletrônico com os propósitos de implementação de uma ou mais técnicas da presente descrição.

[0024] Agora, em relação aos desenhos e, mais particularmente, à figura 1, é aqui representado um exemplo generalizado da arquitetura de rede 100 para facilitar a ingestão e a distribuição/entrega de mídia de baixa latência de acordo com uma ou mais modalidades do presente pedido de patente. Como será visto a seguir, o conteúdo pode ser distribuído e/ou entregue usando tanto técnicas de difusão seletiva quanto técnicas de difusão ponto a

Petição 870200002271, de 06/01/2020, pág. 25/144

20/103 ponto. Em um mecanismo de difusão ponto a ponto, um receptor assinante pode ser provido com um caminho bidirecional direto e exclusivo através da rede de distribuição todo o caminho de volta até um servidor de mídia de serviço que supre o fluxo contínuo de dados exigido. A atividade de transmissão contínua principal é gerenciada em uma base um para um entre o receptor e o servidor de origem em uma sessão de comunicação. A rede entre o servidor de origem e o receptor pode, tipicamente, compreender uma série de servidores intermediários instalados nos nós de rede, que podem não ser diretamente envolvidos no serviço, mas apenas suportar a transferência de um fluxo contínuo de pacotes. Tipicamente, os protocolos usados para suportar as transmissões são simples formas do próprio Protocolo da Internet (IP) aumentado por um ou mais protocolos de camada superior para prover controle de fluxo. Estes protocolos se estendem através da amplitude da conexão de rede entre o servidor de origem e um dado receptor.

[0025] Um sistema de difusão ponto a ponto pode suportar transmissão contínua ABR (Taxa de Bits Adaptativa), que permite alguma forma de adaptação de taxa. Um dado serviço pode ser codificado em uma seleção de diferentes taxas de bits (conhecidas como representações, da forma aqui notada em outro local), com pontos limites sincronizados em locais definidos (por exemplo, a cada 50 quadros). Para cada representação, o conteúdo entre pontos limites sucessivos é convertido em um arquivo discreto. Os Clientes localizam e carregam um segmento de uma das representações por sua vez. Se uma taxa de bit superior ou uma inferior for exigida, o próximo segmento é localizado e carregado a partir de uma das outras representações. Os segmentos são construídos de maneira tal que não haja descontinuidade nas figuras/áudio decodificados se o cliente comutar entre as representações nos pontos limites. Este sistema pode exigir um caminho de difusão ponto a ponto bidirecional entre a fonte e o receptor para solicitar os arquivos e distribuir os arquivos solicitados.

Petição 870200002271, de 06/01/2020, pág. 26/144 / 103

[0026] A distribuição/entrega por difusão seletiva faz uso mais eficiente da largura de banda pelo compartilhamento dos fluxos contínuos de conteúdo entre diversos receptores. Os elementos de rede intermediários (por exemplo, roteadores ou comutadores) estão, agora, mais intimamente envolvidos na distribuição de serviço, de maneira tal que algumas funções de controle e gerenciamento sejam delegadas a partir do servidor de origem. Este controle é suportado por protocolos mais extensivos idealizados para este tipo de aplicação, tais como, por exemplo, Difusão Seletiva Independente de Protocolo (PIM), Protocolo de Difusão Seletiva em Grupo da Internet (IGMP), RTP/MPEG-TS sobre UDP e difusão seletiva por IP para difusão seletiva com base em fluxo contínuo, Difusão Seletiva Confiável Orientada por NACK (NORM), Distribuição de Arquivos através de Transporte Unidirecional (FLUTE), FCAST, etc. Quando um receptor solicitar um dado item ou ativo de mídia, o sistema roteador da rede encontra um fluxo contínuo existente deste conteúdo já na rede e direciona uma cópia do mesmo para este receptor a partir de uma cabeça de rede de cabo de serviço, uma agência central de vídeo ou um nó de rede apropriadamente próximo em uma rede de distribuição na borda. Isto é, a difusão seletiva pode ser todo o caminho desde um empacotador da cabeça de rede ou um servidor de origem nacional (por exemplo, em um centro de dados nacional) até um nó de distribuição na borda de serviço disposto em uma rede de acesso adequada ou em um nó de rede nas dependências, finalmente até uma estação de usuário final que tem apropriada funcionalidade de cliente de difusão seletiva por IP. O receptor solicitante pode ser provido com a capacidade de se associar a este fluxo contínuo existente sob condições controladas que não afetam adversamente os receptores existentes. Qualquer receptor neste grupo também pode ser provido com a capacidade de deixar o fluxo contínuo, ou pausar seu consumo, sem afetar os outros.

[0027] Os versados na técnica irão perceber que, enquanto

Petição 870200002271, de 06/01/2020, pág. 27/144 / 103 “distribuição” pode ser, no geral, usada para descrever o provisionamento de mídia na rede central e para fora até os servidores de borda, a “distribuição” da mídia ocorre entre o servidor de borda e o cliente, embora tais termos possam ser um tanto intercambiavelmente usados no contexto de uma ou mais modalidades do presente pedido. No geral, os termos “conteúdo de mídia”, “ativo digital”, “arquivo de conteúdo”, “segmentos de mídia”, ou termos de sentido similar (ou, simplesmente, “conteúdo”), da forma usada em referência a pelo menos algumas modalidades da presente descrição de patente, podem incluir ativos digitais ou ativos de programa, tais como qualquer tipo de conteúdo de áudio/vídeo (A/V) que pode compreender mídia de captura ao vivo ou mídia sob demanda estática/armazenada, por exemplo, espetáculos ou programas de televisão de rede livre sobre o ar (TV), programas de difusão de TV paga por meio de redes a cabo ou redes via satélite, espetáculos de TV via satélite livre para o ar, programas IPTV, Over-The-Top (OTT) e espetáculos ou programas em Vídeo Sob Demanda (VOD) ou Filme Sob Demanda (MOD), conteúdo de TV deslocado no tempo (TSTV), alcance do conteúdo de serviço, conteúdo de Realidade Virtual (VR), conteúdo de Realidade Aumentada (AR), conteúdo ABR, etc. A título de ilustração, uma ou mais fontes de conteúdo ao vivo 108, uma ou mais fontes de conteúdo TSTV 110, uma ou mais fontes de conteúdo estático/sob demanda 112 (por exemplo, serviços VOD e fontes de conteúdo DVR em nuvem/rede), bem como alcance dos serviços de TV 114, são mostrados na arquitetura de rede 100 para servir como fontes de conteúdo generalizadas em relação à mídia de transmissão contínua para um amplo arranjo de dispositivos UE 190-1 a 190-N, pelo menos alguns dos quais podem ficar dispostos nas dependências de um assinante e ser servidos por equipamento nas dependências adequado, tais como portas de comunicação, STBs, modems, etc. (não especificamente mostrados). Os ativos do conteúdo de mídia das fontes de conteúdo podem ser processados, codificados/transcodificados e/ou preparados por instalações de

Petição 870200002271, de 06/01/2020, pág. 28/144 / 103 preparação mídia adequadas 106 em conjunto com o empacotamento 116 acoplado em ou de outra forma associado com uma rede da fonte de conteúdo 104 para a transmissão sobre uma rede de distribuição de difusão seletiva por IP 118. Adicionalmente, apropriadas funções de gerenciamento de direitos digitais (DRM), encriptação e aplicação de marca d’água digital (DWM) também podem ser configuradas para operar em associação com o empacotamento 116 em relação aos fluxos contínuos de mídia de conteúdo antes do carregamento da mídia empacotada na rede de difusão seletiva por IP 118 em certas modalidades. Vários tipos de redes de borda e redes de acesso (fixas ou móveis), cumulativamente referidas pelo número de referência 124, podem ser interfaceados entre UEs/nós nas dependências e elementos de rede à montante nas respectivas infraestruturas da rede de distribuição para facilitar a distribuição de mídia sobre tecnologias com fios e/ou sem fio, da forma notada previamente.

[0028] Um exemplo de sistema de processamento de mídia associado com a rede da fonte de conteúdo 104, por exemplo, em uma cabeça de rede global, pode ser configurado para aceitar o conteúdo de mídia a partir de fontes ao vivo e/ou fontes de arquivo estáticas, por exemplo, provedores de conteúdo on-line, tais como Hulu®, Netflix®, YouTube®, ou Amazon® Prime, bem como catálogo ou provedores de conteúdo ou estúdios VOD, tais como, por exemplo, Disney, Warner, Sony, etc. O conteúdo de mídia proveniente das fontes ao vivo pode compreender programação ao vivo capturada em relação a qualquer tipo de evento, por exemplo, eventos esportivos/de entretenimento/de jogos, concertos, espetáculos de TV ao vivo, fontes de difusão de noticiário ao vivo, tais as, por exemplo, difusoras nacionais (por exemplo, NBC, ABC, etc.), bem como canais difusores a cabo, como canais Time Warner de CNN, ESPN, CNBC, etc., além das difusoras locais e/ou regionais, redes de segurança pública, etc. Na operação geral, um exemplo do sistema de preparação de mídia 106 pode ser configurado, sob o

Petição 870200002271, de 06/01/2020, pág. 29/144 / 103 controle de um ou mais processadores que executam código de programa apropriado armazenado em um módulo de memória persistente, para efetuar a preparação de mídia como segue. Inicialmente, o conteúdo de mídia da fonte é transcodificado ou de outra forma codificado com diferentes taxas de bits (por exemplo, transcodificação multitaxas) usando codificador(es) aplicável(is). Por exemplo, o conteúdo de um ativo do conteúdo de mídia ou um programa em particular pode ser transcodificado em cinco fluxos contínuos de vídeo usando taxas de bits variáveis (ou, sinonimamente, “taxas de bits” ou “resoluções”), que variam de baixas a altas taxas de bits (500 Kbps a 10 Mbps, a título de ilustração). O conteúdo em particular é, portanto, codificado como cinco diferentes “versões”, em que cada taxa de bits é chamada de um perfil ou uma representação. Um servidor de segmentação ou segmentador é operativo como o empacotador 116 para dividir cada versão do conteúdo de mídia codificado em segmentos de duração fixa, que têm, tipicamente, entre dois e dez segundos de duração, desse modo, gerando uma pluralidade de fluxos contínuos de segmento e/ou fluxos contínuos segmentados virtuais, dependendo da implementação. Os versados na técnica irão reconhecer que segmentos mais curtos podem reduzir a eficiência de codificação, enquanto que segmentos maiores podem impactar a adaptabilidade às mudanças na taxa de transferência da rede e/ou à rápida mudança de comportamento cliente. Independente do tamanho, os segmentos podem ser alinhados ao Grupo de Figuras (GOP) em uma modalidade, de maneira tal que todos os perfis de codificação tenham os mesmos segmentos. Adicionalmente, o empacotador 116 inclui ou opera em associação com um fragmentador de mídia configurado para gerar um ou mais fragmentos para cada segmento de mídia, que podem ser carregados para nós de rede adequados na rede de difusão seletiva por IP 118 usando a codificação de transferência aglomerada (CTE) HTTP para baixa latência, como será apresentado com detalhes adicionais a seguir.

Petição 870200002271, de 06/01/2020, pág. 30/144 / 103

[0029] A figura 2 representa os aspectos adicionais do exemplo de arquitetura de rede 100 da figura 1, que ilustra os detalhes adicionais em uma implementação ponta a ponta que envolve a distribuição de mídia ao vivo e a distribuição usando uma rede de portadora fixa e/ou uma rede de portadora móvel em conjunto com uma ou mais redes de serviço/provedoras de conteúdo. A título de ilustração, uma parte da rede provedora de conteúdo 220, uma parte da rede de portadora fixa 235 e uma parte da rede de portadora móvel 230 são exemplificadas na arquitetura de rede 200. Os versados na técnica irão perceber que um exemplo de implementação 200 pode ser hierarquicamente organizado quando uma instalação de cabeça de rede ou super cabeça de rede de um centro de dados nacional (NDC) for configurada para codificar e preparar a mídia em segmentos e subsegmentos (isto é, fragmentos) e prover os fragmentos para servidores centralizados para distribuição para receptores finais/de borda por meio de um ou mais níveis de infraestruturas de rede intermediárias (por exemplo, como parte de uma infraestrutura de rede gerenciada ou uma parte da mesma, partes de uma rede móvel/fixa, ou uma CDN) usando a difusão seletiva por IP. Várias estações terminais de usuário com aplicações clientes apropriadas são operativas para transferir ou puxar os segmentos de mídia provenientes receptores finais/de borda de difusão seletiva por IP usando distribuição com base em HTTP CTE por meio de uma ou mais redes de acesso móveis/fixas e redes domésticas/nas dependências, dependendo de onde a funcionalidade do receptor de difusão seletiva por IP é implementada. Da forma ilustrada, uma pluralidade de alimentações via satélite ou fibra 208 proveem conteúdo de mídia da fonte correspondente a um ou mais canais 206 para codificadores apropriados 210, que codificam/comprimem os dados de mídia em fluxos contínuos de taxa de bits de alta qualidade 205, por exemplo, fluxos contínuos de difusão seletiva ou operações de memória direta, em um formato de contêiner padrão, tais como, por exemplo, MPEG2-TS ou M2TS, de acordo com ISO/IEC 13818-1,

Petição 870200002271, de 06/01/2020, pág. 31/144 / 103 em uma implementação. Os empacotadores e os codificadores também podem ler o conteúdo a partir de um sistema de arquivo local, em vez de uma alimentação de satélite ou fibra, em um arranjo adicional ou alternativo. Embora não mostrado na figura 2, um ou mais mecanismos de emenda nacionais podem ser providos em uma modalidade de exemplo para inserir qualquer conteúdo de mídia secundário, por exemplo, anúncios, nos fluxos contínuos de mídia para o processamento por um módulo codificador/transcodificador/empacotador de cabeça de rede 202, que pode ser distribuído em múltiplos elementos ou componentes em alguns arranjos como parte de um servidor ou sistema de mídia, e pode ser associado com nós ou elementos adicionais, tal como servidores de anúncio (ADS), etc. Preferivelmente, um componente transcodificador do nó de cabeça de rede 202 pode ser configurado para gerar uma pluralidade de fluxos contínuos TS adaptativos (ATS), bem como manifestos do fluxo contínuo associados em relação a cada canal de conteúdo de mídia para difusão seletiva, em que os fluxos contínuos ATS compreendem representações específicas da taxa de bits do ativo do conteúdo de mídia do canal, incluindo pontos limites de codificação (EBP) ou informação de segmento virtual, sinalização de conteúdo secundário, por exemplo, sinalização SCTE 35, etc.

[0030] Em um exemplo de implementação, pelo menos uma parte da rede de difusão seletiva por IP 118 da figura 1 pode compreender a rede provedora de conteúdo 220 que pode ser arquitetada como uma CDN de sobreposição, da forma exemplificada na figura 2. Como uma CDN, a rede 220 pode compreender uma montagem multinível, hierarquicamente organizada, interconectada de servidores de rede para prover trajetórias ou “dutos” de mídia de um ou mais nós de distribuição centrais (servidores de origem nacionais) até um ou mais níveis de nós de distribuição regionais que são conectados em um ou mais servidores de borda locais configurados para servir uma pluralidade de usuários finais ou assinantes em respectivas áreas

Petição 870200002271, de 06/01/2020, pág. 32/144 / 103 locais de serviço por meio de infraestruturas de rede de acesso adequadas. Deve ser percebido que um nó de distribuição regional pode operar como um nó pai para um ou mais servidores de borda/origem filhos e um nó de distribuição central ou nacional pode, por sua vez, operar como um nó pai para um ou mais nós de distribuição regionais filhos para suportar uma árvore de distribuição por difusão seletiva por IP. Adicionalmente, os versados na técnica entendem que uma arquitetura de CDN configurada para suportar difusão seletiva por IP pode ser implementada como uma CDN pública, uma CDN privada ou uma CDN híbrido, ou uma rede de redes, que podem incluir infraestruturas ou centros de dados com base em nuvem. A título de ilustração, um nó 214 e os nós 216-1 a 216-N de origem nacionais são exemplificados como parte da CDN 220, qualquer um de tais nós de borda pode ser interfaceado com a infraestrutura de rede fixa 235 por meio de porta de comunicação de borda (BGW 241) adequada acoplada em MCTx 243 (Função Transmissora por Difusão Seletiva, que age como função de ingestão na rede fixa). Os elementos de infraestrutura de exemplo adicionais, tais como DSLAMs, nós CMTS, etc., não são explicitamente mostrados. Uma porta de comunicação nas dependências do assinante 234 (que também pode incluir a Função Receptora de Difusão Seletiva ou MCRx) para servir um ou mais STBs 236 e dispositivos UE 238, 239 por meio de uma rede nas dependências 240, 242 é ilustrativa de uma parte no lado do cliente da infraestrutura. Deve ser adicionalmente percebido que a Função do Receptor de Difusão Seletiva também é colocalizada com um STB em uma implementação adicional ou alternativa.

[0031] Os versados na técnica irão reconhecer que, além dos servidores de distribuição de mídia (algumas vezes também referidos como “nós de distribuição de conteúdo”), uma CDN também pode incluir e/ou interoperar com vários elementos de rede configurados para efetuar mecanismos de redirecionamento ou rerroteamento de solicitação, bem como

Petição 870200002271, de 06/01/2020, pág. 33/144 / 103 sistemas de back office relacionados, tais como sistemas de gerenciamento de assinante, sistemas de agendamento da largura de banda, sistemas de conta/faturamento e congêneres, que podem ser implementados como parte de um back office da rede de transmissão contínua em mídia (não especificamente mostrado).

[0032] Em uma modalidade adicional ou alternativa, uma porta de comunicação de ingestão móvel 231 da rede de portadora móvel 230 pode ser acoplada em um ou mais nós da rede de serviço de conteúdo 220, por exemplo, servidor de origem 214, servidor de borda 216-N, para receber os fragmentos de mídia em qualquer número de mecanismos de transferência de dados, por exemplo, mecanismos de transferência disparados por empurrar, puxar e/ou híbrido. Em uma modalidade ainda adicional, o nó fonte do empacotador/segmentador de cabeça de rede 202 pode ser configurado para carregar, transferir, transmitir, ou de outra forma prover os fragmentos de mídia para a porta de comunicação de ingestão móvel 231. Em um arranjo, a porta de comunicação de ingestão móvel 231 pode ser configurada para operar como um nó do serviço de difusão/difusão seletiva adequado da rede de portadora 230 adaptado para facilitar a distribuição por difusão seletiva por IP de acordo com os preceitos apresentado com detalhes a seguir. Em um outro arranjo, a porta de comunicação de ingestão móvel 231 pode transferir os segmentos e os fragmentos, disparada pelo sincronismo e descrições de URL provenientes de um arquivo de manifesto. Uma pluralidade de dispositivos ou dispositivos tipo equipamento de usuário (UE) sem fio ou móveis exemplares 236-1 a 236-N são mostrados como sendo operacionais no ambiente sem fio da rede de portadora móvel exemplar 102. Na discussão aqui exposta, os termos “rede sem fio”, “rede móvel”, “rede de comunicação móvel”, “rede de portadora”, ou termos de sentido similar podem ser usados intercambiavelmente para se referir a uma rede de comunicação sem fio (por exemplo, uma rede celular, uma rede de comunicação de dados proprietária,

Petição 870200002271, de 06/01/2020, pág. 34/144 / 103 uma rede corporativa sem fio, etc.) que facilita as comunicações de voz, dados e/ou multimídia com diferentes tipos de dispositivos não acessados por ponte (por exemplo, os dispositivos 236-1 a 236-N). Em uma modalidade, tais dispositivos podem compreender telefones inteligentes, tablets, computadores móveis/laptops, notebooks, leitores eletrônicos, assistentes pessoais digitais (PDAs), dispositivos de jogos VR/AR, etc., capazes de receber conteúdo A/V adaptativamente transmitido em fluxo contínuo a partir da rede 230 em uma sessão de distribuição por difusão/difusão seletiva e reproduzir o mesmo usando um cliente/reprodutor de mídia ABR local em execução nos mesmos. [0033] Os dispositivos UE sem fio 236-1 a 236-N são mostrados em comunicação sem fio (por meio de respectivos enlaces de rádio 238-1 a 238N) com a rede sem fio 230 através de uma ou mais estações bases, por exemplo, a estação base (BS) 234, operativas para prover a interface de ar/rádio (na forma de enlaces de Radiofrequência (RF) adequados, dependendo da tecnologia de comunicações móveis em particular) para os dispositivos 236-1 a 236-N por meio de elementos de antena apropriados. A título de exemplo, a estação base 104 pode compreender um nó em uma rede da 3^a/4^a/5^a Gerações ou da Próxima Geração, e pode ser interfaceada ou integrada com um nó controlador de rede 232 operativamente acoplado na porta de comunicação de ingestão móvel 231. Por exemplo, o exemplo da rede de portadora sem fio 230 pode compreender uma rede da Evolução de Longo Prazo (LTE), cuja infraestrutura será descrita com detalhes adicionais a seguir com os propósitos de uma modalidade da presente invenção.

[0034] Será reconhecido que, embora não especificamente mostrado na figura 2, um exemplo de dispositivo UE não acessado por ponte também pode transferir a mídia usando as comunicações por rádio de curto alcance (por exemplo, padrões IEEE 802.11b, IEEE 802.11a, IEEE 802.11g, HiperLan e HiperLan II, padrão Wi-Max, padrão OpenAir, padrão Bluetooth, etc.), por meio de hotspots ou pontos de acesso adequados em uma rede WiFi,

Petição 870200002271, de 06/01/2020, pág. 35/144

30/103 por exemplo. Em uma modalidade ainda adicional, pode ser implementada uma arquitetura DVB que envolve pelo menos partes dos componentes da infraestrutura de rede mostrados na figura 2. Em um arranjo ainda adicional, a porta de comunicação de ingestão móvel 231 pode fazer interface com o nó segmentador/empacotador 202, adicionalmente ou altemativamente aos arranjos apresentados anteriormente para receber os segmentos de mídia, os fragmentos e/ou os aglomerados.

[0035] A figura 3 A representa uma representação de alto nível de um exemplo de ambiente de rede de difusão seletiva 300A para praticar uma modalidade da presente invenção. Os versados na técnica irão perceber que o ambiente de rede de difusão seletiva 300A é uma versão resumida das redes 100 ou 200 apresentadas anteriormente, aqui simplificadas para não distrair dos componentes chaves e conceitos relevantes para uma modalidade exemplar. Amplamente, o ambiente de rede 300A é composto por uma parte de ingestão de mídia 304A, 304B, uma parte de distribuição 308-1 a 308-N, e uma parte de distribuição do cliente 314-1 a 314-K, em que a parte da rede de ingestão de mídia 304A/304B e a parte de distribuição do cliente 314-1 a 314K podem ser efetuadas usando os mecanismos de transferência de dados com base em HTTP CTE em uma modalidade de exemplo. Em modalidades adicionais, a parte da rede de ingestão de mídia 304A/B pode ser configurada para efetuar qualquer mecanismo de transferência de dados de mídia adequado, por exemplo, empurrar/puxar, disparado por empurrar/puxar, para transferir ou de outra forma prover os dados de mídia para um ou mais nós de rede de ingresso de mídia, como será apresentado a seguir. Desta maneira, deve ser percebido que os termos “ingerir” ou “ingestão”, ou variantes relacionadas, podem incluir qualquer tipo de mecanismo de transferência de dados, incluindo CTE, com os propósitos de transferir os dados de mídia para um nó de ingestão de acordo com os preceitos aqui expostos. Em uma modalidade, a parte da rede de distribuição 308-1 a 308-N pode ser com base

Petição 870200002271, de 06/01/2020, pág. 36/144

31/103 em transporte em difusão seletiva por IP confiável usando um protocolo de difusão seletiva por IP adequado, tais como NORM, FLUTE, FCAST, etc. Preferivelmente, os mecanismos de transporte de difusão seletiva por IP são estendidos ou de outra forma modificados de acordo com os preceitos aqui expostos para facilitar a distribuição de mídia a partir de um elemento de rede à montante no qual a mídia é carregada ou de outra forma provida mesmo antes da íntegra dos dados de mídia para os segmentos ficar disponível.

[0036] Um nó segmentador/empacotador fonte 302 inclui uma funcionalidade de processamento para fragmentar cada segmento de mídia em múltiplos fragmentos, cada fragmento compreendendo um ou mais quadros de dados de áudio, vídeo e/ou A/V, e para ingestão dos fragmentos em um ou mais elementos de rede 306A, 306B operativos como nós de ingresso de difusão seletiva por IP, usando respectivas sessões HTTP CTE estabelecidas entre os mesmos. Em uma modalidade, o elemento de rede 306A/306B pode compreender um servidor de origem da CDN (por exemplo, um nó de origem nacional, um nó de distribuição regional ou um nó de distribuição de borda, dependendo de qual nó é provido como o ponto de ingestão de difusão seletiva por IP). Em uma outra modalidade, o elemento de rede 306A/306B pode compreender um nó do centro de serviço de difusão/difusão seletiva (BMSC) LTE. Um ou mais receptores de difusão seletiva em borda 310-1 a 310-M podem ficar dispostos como pontos terminais da rede de difusão seletiva por IP 308-1 a 308-N para receber os dados de mídia em objetos de transporte em difusão seletiva por IP específicos de protocolo. Várias aplicações clientes (ou clientes em resumo) 312-1 a 312-K são operativas, em ambientes acessados por ponte e/ou não acessados por ponte, para transferir os dados de mídia a partir dos receptores de borda 310-1 a 310-M usando a distribuição aglomerada por HTTP por meio de respectivas sessões HTTP CTE, dependendo de com quais grupos de difusão seletiva por IP as mesmas são associadas. Deve-se notar que o conteúdo de mídia pode ser empacotado

Petição 870200002271, de 06/01/2020, pág. 37/144

32/103 de uma maneira para se beneficiar da distribuição HTTP CTE. Da forma notada em outra parte do presente pedido de patente, a funcionalidade de receptor IP pode ser colocalizada ou de outra forma integrada em diferentes níveis, por exemplo, estações de usuário final, STBs ou portas de comunicação, e pode ser adicionalmente integrada com a funcionalidade do receptor HTTP CTE e/ou a funcionalidade do reprodutor de mídia, dependendo da implementação.

[0037] A figura 3B é um fluxograma de um esquema de alto nível 300B que compreende etapas, blocos ou atos que podem ser refinados, combinados, ou (re)arranjados em uma ou mais modalidades e/ou em fluxogramas adicionais para facilitar a ingestão e a distribuição de mídia de baixa latência em um fluxo ponta a ponta no exemplo da rede de difusão seletiva de alto nível mostrada na figura 3A. No bloco 350, um nó de rede fonte de conteúdo é configurado para criar múltiplos fragmentos de dados para cada segmento de mídia e para carregamento ou, de outra forma, ingestão dos fragmentos de mídia (por exemplo, já que os mesmos ficam disponíveis em um serviço de mídia ao vivo), por exemplo, usando a distribuição aglomerada para um nó servidor HTTP CTE associado com um ponto de ingestão de difusão seletiva por IP. A distribuição por difusão seletiva da mídia aglomerada é facilitada por meio da geração e da transmissão de objetos de transporte IP adequados para um ou mais receptores de difusão seletiva por IP de borda (isto é, destinatários), da forma apresentada no bloco 352. A transferência/distribuição do conteúdo de mídia a partir dos destinatários de borda é efetuada por um ou mais clientes (bloco 354), que podem ser um mecanismo com base em HTTP CTE idêntico ao mecanismo CTE usado para o carregamento de mídia no nó de rede fonte de conteúdo, ou um mecanismo CTE diferente (por exemplo, usando diferentes tamanhos do aglomerado), ou um mecanismo de transferência de dados HTTP normal (por exemplo, para aplicações clientes legadas). Adicionalmente,

Petição 870200002271, de 06/01/2020, pág. 38/144 / 103 dependendo de onde a funcionalidade do receptor de difusão seletiva por IP é integrada (por exemplo, o reprodutor de mídia consumindo diretamente os objetos de transporte em difusão seletiva por IP), um reprodutor de mídia ou uma aplicação cliente podem ser configurados para usar as chamadas da interface de programação de aplicação (API) diretas, as sub-rotinas, os protocolos, as chamadas funcionais, etc. para emular as operações de arquivo “tipo HTTP” para obter os dados de mídia para reprodução, da forma apresentada no bloco 354. Desta maneira, em uma modalidade como esta, a funcionalidade de recepção associada com o bloco 352 e a funcionalidade de consumo do bloco 354 do processo ponta a ponta exemplar 300B podem ser combinadas em um único nó do UE que opera como o ponto terminal da difusão seletiva por IP de uma árvore de difusão seletiva por IP para um canal de mídia solicitado.

[0038] Os versados na técnica irão reconhecer que as diferentes sessões de transferência/consumo de mídia entre os destinatários de borda e os clientes associados podem ocorrer assincronamente umas em relação às outras. De maneira similar, os dados em relação a vários canais de mídia podem ser carregados a partir de um ou mais empacotadores de carregamento de mídia em interface inicial para um ponto de ingestão de difusão seletiva por IP em diferentes sessões de carregamento HTTP CTE em execução por meio de diferentes portas/interfaces de rede, independente se um ou mais clientes estão associando ou sintonizando nos grupos de difusão seletiva associados com os canais de mídia.

[0039] Em uma modalidade de exemplo, portanto, a codificação de transferência aglomerada pode ser provida como parte do bloco 350 como um mecanismo de transferência de dados em HTTP ver. 1.1 em que os dados de mídia podem ser enviados em um ou mais “aglomerados” para cada fragmento de um segmento do fluxo contínuo do canal de mídia através de todas as representações de taxa de bits provisionadas na rede (por exemplo,

Petição 870200002271, de 06/01/2020, pág. 39/144

34/103 qualidade de definição padrão (SD), qualidade de alta definição (HD), qualidade ultra HD (UHD), qualidade 4K, etc.). Em uma implementação, o mecanismo de transferência de dados com base em CTE pode usar o cabeçalho HTTP de Transferência-Codificação no lugar do cabeçalho de Comprimento do Conteúdo, que é normalmente exigido em uma típica sessão HTTP. Em virtude de o cabeçalho de Comprimento do Conteúdo não ser usado, um emissor não precisa estar ciente do comprimento/tamanho do conteúdo antes da transmissão para um receptor. Em uma implementação, o tamanho de cada aglomerado pode ser sinalizado em um ponto no tempo de transmissão adequado (por exemplo, configurável), de forma que um receptor HTTP CTE possa determinar quando o aglomerado completo foi recebido. Por exemplo, o tamanho do aglomerado pode ser transmitido exatamente antes da transmissão do próprio aglomerado em uma modalidade ilustrativa. Em uma modalidade adicional, a transferência de dados pode ser terminada por um aglomerado final de comprimento zero.

[0040] Em uma modalidade adicional, um mecanismo de transferência com base em CTE pode ser configurado para suportar e manter uma conexão HTTP persistente entre um empacotador de carregamento e um servidor de origem, por exemplo, preferivelmente, para conteúdo dinamicamente gerado. Os versados na técnica também irão perceber que a codificação aglomerada pode ser configurada para permitir que um emissor envie campos de cabeçalho adicionais depois do corpo da mensagem em certas modalidades, o que pode ser vantajoso em casos em que os valores de um campo não podem ser conhecidos até que o conteúdo tenha sido produzido, por exemplo, quando o conteúdo de mídia precisar ser digitalmente assinado ou receber marca d’água.

[0041] Em um exemplo do esquema de formatação CTE, se um campo de Transferência-Codificação com um valor de “aglomerado” for especificado em uma mensagem HTTP (tanto uma solicitação enviada por um

Petição 870200002271, de 06/01/2020, pág. 40/144 / 103 cliente quanto a resposta proveniente do servidor, em que o cliente e o servidor são designados pontos terminais de uma sessão CTE HTTP), o corpo da mensagem pode conter um número de aglomerados não especificado, um aglomerado de terminação, um rastro, e uma sequência CRLF (retomo de condução seguido por avanço de linha) final. Cada aglomerado pode iniciar com um número de octetos dos dados que o mesmo embute, expressado como um número hexadecimal, por exemplo, seguido por parâmetros opcionais (por exemplo, parâmetros de extensão do aglomerado) e uma sequência CRLF de terminação, seguida pelos dados aglomerados, em que o aglomerado é terminado por CRLF (por exemplo, operativo como um marcador de limite do aglomerado). Se as extensões do aglomerado forem providas, o tamanho do aglomerado pode ser terminado por um ponto e vírgula e seguido pelos parâmetros, cada qual também delimitado por pontos e vírgulas. Cada parâmetro pode ser codificado como um nome de extensão seguido por um sinal de igual e valor opcionais, que podem ser usados para suportar os serviços adicionais, por exemplo, executando compilações de mensagem ou assinaturas digitais, indicações do progresso de transferência de dados estimado, etc. O aglomerado de terminação pode ser provido como um aglomerado regular, mas com um comprimento do aglomerado de zero, que pode ser seguido por um ou mais rastros.

[0042] Será percebido mediante referência ao presente que uma modalidade da presente invenção provê um sistema de distribuição/entrega troca para troca (E2E) para distribuição com baixo atraso dos segmentos de mídia (por exemplo, segmentos DASH) através de uma rede de distribuição fixa ou móvel, que utiliza difusão seletiva por IP para enviar o conteúdo do nó de origem para as estações destinatárias de borda. Amplamente, em um exemplo de implementação, um segmentador/empacotador ao vivo (também referido como um nó fonte de conteúdo) pode ser configurado para criar segmentos relativamente grandes, por exemplo, com 5 segundos de duração.

Petição 870200002271, de 06/01/2020, pág. 41/144

36/103

Cada segmento pode ser subdividido em uma pluralidade de fragmentos que são carregados usando HTTP CTE. Por exemplo, um fragmento pode conter apenas uma única amostra de mídia, como um quadro de vídeo codificado, por exemplo, um quadro de Atualização de Decodificador Instantânea (IDR) (um tipo especial de quadro I), embora outras variações sejam possíveis.

[0043] Os versados na técnica irão perceber que, para comunicação ao vivo de baixa latência que usa DASH/ISOBMFF, por exemplo, um exemplo de processo de segmentação/fragmentação pode ser configurado para gerar fragmentos relativamente curtos construídos a partir dos quadros, em que um GOP pode ser separado em dois ou mais fragmentos. O nó segmentador/empacotador pode ser configurado para tomar o conteúdo disponível apenas quando todos os quadros (amostras de figuras e/ou áudio de vídeo) para este fragmento do segmento tiverem sido completamente recebidos a partir da fonte ao vivo. Um GOP pode ser provido como uma sequência codificada de figuras de vídeo entre dois quadros chaves (por exemplo, quadros IDR), em que um decodificador pode iniciar a decodificação da sequência de vídeo do GOP apenas com o quadro chave seguido por um ou mais quadros delta. Em um caso extremo, o segmentador/empacotador pode gerar um novo fragmento para cada novo quadro, de forma que o fragmento fique disponível uma vez que todos os dados do quadro estejam disponíveis para o segmentador. Deve ser percebido que, em um caso como este, todos os quadros P e quadros B também são empacotados em fragmentos individuais.

[0044] Em relação ao exemplo de ambiente de rede ponta a ponta 300A mostrado na figura 3A, será percebido que, enquanto que a distribuição por difusão seletiva por IP confiável é usada no interior de uma rede de distribuição (por exemplo, uma CDN) para conduzir os objetos do servidor de origem HTTP para a borda de difusão seletiva por IP, os nós, tais como codificadores/segmentadores ao vivo, bem como os clientes HTTP são

Petição 870200002271, de 06/01/2020, pág. 42/144 / 103 externos a esta rede e podem não necessariamente estar cientes do uso da difusão seletiva por IP no interior da CDN.

[0045] Como pelo menos algumas modalidades de exemplo da presente invenção particularmente referem-se a ISOBMFF, uma breve visão geral é apresentada imediatamente a seguir. ISOBMFF define uma estrutura de contêiner ou embrulhador geral em um formato flexível, extensível, que facilita o intercâmbio, o gerenciamento, a edição e a apresentação de arquivos multimídia com base em tempo, tais como áudio e vídeo, que pode formar uma base para outros formatos de contêiner, em que a apresentação pode ser local, ou por meio de uma rede ou outro mecanismo de distribuição com base em arquivo. No geral, a formato do arquivo de mídia apresenta uma estrutura de arquivo orientada a objeto e contém o sincronismo, a estrutura e a informação de mídia para sequências temporizadas de dados de mídia, tais como apresentações audiovisuais. Um arquivo pode ser decomposto em objetos básicos em que a estrutura dos objetos pode ser implicada a partir de seu tipo. Os arquivos que se conformam com o padrão ISOBMFF (ISO/IEC 14496-12, aqui incorporado pela referência) são formados como uma série de objetos, referidos como “caixas”, em que todos os dados ficam contidos em caixas e não pode haver outros dados no arquivo. A “caixa” é um bloco de construção orientado a objeto definido por um identificador de tipo e comprimento exclusivos. Uma apresentação (sequência de movimento) pode estar contida em diversos arquivos. Toda a informação de sincronismo e enquadramento (posição e tamanho) deve estar no arquivo de mídia base ISO e os arquivos auxiliares podem, essencialmente, usar qualquer formato até o limite em que os mesmos são capazes de descrição pelos metadados definidos em formato do arquivo de mídia base ISO. A fim de identificar as especificações com as quais um arquivo com base em ISOBMFF se conforma, marcas podem ser usadas como identificadores no formato do arquivo, que pode ser definido em uma caixa chamada Caixa Tipo de Arquivo

Petição 870200002271, de 06/01/2020, pág. 43/144

38/103 (“ftyp”), ou um “styp” no caso de segmentos de mídia, que deve ser colocada no início do arquivo. Um arquivo que suporta a transmissão contínua inclui a informação sobre as unidades de dados a transmitir em fluxo contínuo (por exemplo, como servir os dados de fluxo contínuo elementar no arquivo através de protocolos de transmissão contínua). As caixas adicionais em relação à transmissão contínua incluem a caixa “moov”, a caixa “mdat”, a caixa “moof”, etc., que podem ser providas como parte de um fragmento ISOBMFF de baixa latência com os propósitos da presente invenção, como será apresentado a seguir. Deve ser percebido que a caixa do tipo de segmento ou de arquivo (styp) ou outras caixas ISO-BMFF adicionais podem ser providas com o primeiro fragmento no mesmo aglomerado HTTP, ou podem ser providas através de aglomerados HTTP separados. A caixa styp indica a informação sobre a estrutura do fragmento e do segmento e alguma informação de compatibilidade.

[0046] Quando uma modalidade de exemplo envolver um segmentador DASH ao vivo como o nó fonte 302, o mesmo pode ser configurado para usar ISOBMFF como o formato do segmento, embora outros esquemas de segmentação/formatação também possam ser usados (por exemplo, Formato de Aplicação de Mídia Comum (CMAF), bem como outros tipos de formato de Transmissão Contínua Adaptativa HTTP (HAS), etc.). Da forma notada previamente, os receptores de difusão seletiva por IP podem ser frequentemente localizados em uma borda da CDN, que pode ficar localizada em diferentes níveis, por exemplo, na porta de comunicação doméstica ou até mesmo colocalizada com o cliente no mesmo dispositivo ou utensílio UE físico. Em um exemplo de implementação, o nó fonte 302 pode ser configurado para receber um fluxo contínuo de mídia contínuo de cada representação de múltiplas taxas de bits de um canal de mídia ao vivo e segmentar o mesmo em segmentos de mídia individuais, e subdividir adicionalmente um segmento de um fluxo contínuo de mídia segmentado em

Petição 870200002271, de 06/01/2020, pág. 44/144

39/103 múltiplos fragmentos. Por exemplo, um segmento de 5 segundos pode conter 5 fragmentos, cada qual contendo 1 segundo de dados de mídia, por exemplo, um GOP completo. Para baixa latência, um fragmento pode conter apenas uma fração de um GOP. Como uma ilustração, quando um codificador produzir um fluxo contínuo com GOP de 1 segundo, o segmentador 302 pode ser configurado para criar segmentos de 5 segundos, cada qual contendo dez fragmentos de 0,5 segundo (isto é, metade de um GOP).

[0047] Em uma modalidade, o segmentador/empacotador ao vivo 302 é operativo para carregar a informação de local do conteúdo, por exemplo, um localizador de recurso uniforme (URL) de um arquivo, com operações PUT ou POST HTTP iniciais para o servidor de origem operando como ou em associação com um ponto de ingestão de difusão seletiva por IP; isto pode ser considerado um exemplo para um mecanismo push, como exposto. Responsivo a isto, o servidor de origem pode ser configurado para notificar o nó destinatário de borda sobre o recurso de mídia HTTP recentemente recebido, embora o tamanho do arquivo e o conteúdo real não sejam recebidos. No geral, os nós destinatários de borda podem ser configurados para começar a servir qualquer solicitação proveniente dos clientes HTTP assim que a informação do recurso de mídia HTTP (por exemplo, o URL) for conhecida pelo nó destinatário de borda, por exemplo, preferivelmente, por meio de um mecanismo HTTP CTE, já que o nó destinatário de borda não sabe o real tamanho do arquivo e nem o mesmo tem os dados reais disponíveis.

[0048] Da forma notada previamente, o segmentador/empacotador ao vivo 302 é operativo para criar uma pluralidade de segmentos de um fluxo contínuo de mídia através de múltiplas representações de taxa de bits, em que cada segmento pode conter um ou mais fragmentos. Em uma modalidade de exemplo, o nó segmentador/empacotador 302 pode ser configurado para enviar cada fragmento como um ou mais aglomerados HTTP assim que os

Petição 870200002271, de 06/01/2020, pág. 45/144

40/103 dados para o fragmento ficarem disponíveis. Em decorrência disto, o atraso da segmentação é reduzido no processo de carregamento, já que o segmentador/empacotador não precisa esperar que a íntegra do segmento seja criada. De acordo com os preceitos aqui expostos, um emissor de difusão seletiva por IP associado com o servidor HTTP CTE do nó de origem é operativo para começar a criar um novo objeto de transporte em difusão seletiva por IP para cada fragmento ou cada aglomerado HTTP de um novo segmento (isto é, quando nova informação de recurso HTTP for recebida), em que os fragmentos são carregados em aglomerados HTTP. Adicionalmente, o emissor de difusão seletiva também pode ser configurado para gravar continuamente os aglomerados (por exemplo, depois de um curto armazenamento temporário em algumas implementações de exemplo) em correspondentes objetos de transporte, o que pode envolver remover os cabeçalhos do aglomerado em algumas implementações de exemplo. Quando um aglomerado vazio for recebido, o emissor de difusão seletiva fica operativo para determinar o tamanho do fragmento do arquivo pela soma dos tamanhos de todos os aglomerados previamente recebidos, o que pode ser sinalizado pelo envio de um indicador de limite para indicar um “último pacote” e iniciar um novo objeto de transporte. Deve ser percebido que vários outros métodos para indicar um “último aglomerado” podem ser implementados no escopo da presente invenção.

[0049] Voltando para as figuras 4A-4C, são representados nas mesmas os fluxogramas de mensagem que ilustram a ingestão e a distribuição de mídia de baixa latência em uma implementação com base em CDN de acordo com uma modalidade de exemplo do esquema geral aqui apresentado anteriormente. Em particular, o número de referência 400A na figura 4A, no geral, refere-se a um fluxo de mensagem em relação a um processo ponta a ponta de carregamento, distribuição e entrega de mídia em relação a uma arquitetura de difusão seletiva por IP com base em CDN. Um exemplo de

Petição 870200002271, de 06/01/2020, pág. 46/144 / 103 rede ou nó fontes 402 inclui o segmentador (também chamado de um empacotador) 403 operativo para efetuar uma sessão CTE HTTP com um nó de origem da CDN 404 que pode incluir um servidor HTTP CTE 405 e um emissor de difusão seletiva (MC) 407, que pode ser arquitetado como uma plataforma de computação distribuída em uma modalidade. Um nó de borda da CDN 406 pode igualmente incluir um receptor de MC 409 e um servidor HTTP CTE 411. Um dispositivo UE capaz de distribuição aglomerada por HTTP pode ser provido com um cliente 408 que inclui um receptor HTTP CTE 413 e um reprodutor/armazenamento temporário de mídia 415. Embora um único nó de borda da CDN 406 e um único UE/cliente 408 sejam exemplificados na figura 4A, os versados na técnica irão entender que uma pluralidade de nós de borda CDN, cada qual servindo um ou mais UE/clientes, podem ser providos em uma arquitetura de difusão seletiva por IP com base em CDN.

[0050] Em um arranjo, o segmentador 403 pode ser configurado para carregar ou de outra forma transmitir cada fragmento de um segmento usando HTTP CTE para o servidor HTTP CTE do nó de origem 405 assim que o fragmento ficar disponível. Da forma notada previamente, um segmento pode ser subdividido em uma pluralidade de fragmentos, por exemplo, os fragmentos 416-1 a 416-N para o Segmento n° N, em que cada fragmento pode ser carregado ou de outra forma provido para o servidor HTTP CTE 405 usando um ou mais aglomerados. O Uri do Segmento (também referido como URL do objeto HTTP) e um ou mais cabeçalhos HTTP 418 em relação ao começo de uma transmissão de segmento podem ser providos para o servidor HTTP CTE 405, que podem ser propagados como URL do segmento e cabeçalhos HTTP 422 para a instalação do emissor MC 407 com base em uma indicação de início de novo objeto provida para o mesmo. O benefício de enviar o URL do segmento e os cabeçalhos HTTP para o segmento recentemente criado anteriormente ao primeiro fragmento (isto é, no momento

Petição 870200002271, de 06/01/2020, pág. 47/144 / 103 em que o último segmento for finalizado e o segmentador se voltar para o próximo segmento) é que os nós à jusante ficam cientes anteriormente sobre o segmento recentemente criado. Adicionalmente, em alguns casos, pode ser benéfico enviar, também, alguns metadados adicionais, como a caixa styp, como o primeiro aglomerado HTTP com os cabeçalhos e o URL do segmento, de forma que qualquer cliente já possa solicitar uma parte dos dados binários. A título de ilustração, os números de referência 420, 437, 444, 451 se referem a transmissões de aglomerado entre o segmentador 403 e o servidor HTTP CTE 405 em relação aos fragmentos 416-1 a 416-N do Segmento n° N, preferivelmente, usando mensagens CTE adequadamente formatadas, da forma aqui apresentada anteriormente para conduzir os dados de mídia. Deve-se notar que os dados de mídia nos aglomerados HTTP são providos apenas durante o tempo entre 420 e 437 (e, posteriormente, entre 444 e 451). O nó Segmentador 403 não está enviando os dados de mídia entre 418 e 420 (e, posteriormente, entre 437 e 451). Quando o segmento contiver mais do que dois fragmentos ou quando o segmentador 403 estiver subdividindo um fragmento em mais aglomerados HTTP, então, o procedimento é repetido desta maneira, da forma exemplificada na figura 4B, por exemplo.

[0051] Em uma modalidade de exemplo, quando o nó fonte 402 iniciar um novo segmento (por exemplo, o Segmento n° N), a lógica de serviço apropriada associada com o nó fonte 402 é operativa para incluir várias peças de informação de metadados nos cabeçalhos HTTP 418, por exemplo, a informação em relação ao tipo de MIME, o local do conteúdo (isto é, o URL do segmento, que pode ser em relação a ou indexado a partir de um URL base), etc., em uma transmissão inicial para o servidor de origem 404. Em uma modalidade adicional, os cabeçalhos HTTP 418 também podem incluir uma indicação de codificação de transferência aglomerada HTTP para carregamento do segmento. Em um arranjo, depois que o nó fonte 402 tiver

Petição 870200002271, de 06/01/2020, pág. 48/144 / 103 indicado a criação de um novo segmento e tiver provido os cabeçalhos HTTP e o URL do segmento (como parte da linha do método HTTP), o nó fonte 402 é operativo para coletar/processar todos os dados para o fragmento. Deve ser percebido que, durante esta fase de coleta de dados, o nó fonte 402 pode não estar enviando os dados de mídia. Desta maneira, em um cenário como este, o nó fonte 402 pode ser configurado para iniciar o envio dos dados de um fragmento usando um ou mais aglomerados HTTP apenas depois que o nó fonte 102 tiver criado o fragmento de acordo. Opcionalmente ou altemativamente, o nó fonte 402 pode ser configurado para atrasar a indicação da criação de um novo segmento (isto é, o método HTTP com o URL HTTP e os cabeçalhos HTTP) até que os dados para o primeiro fragmento estejam disponíveis.

[0052] Da forma ilustrada na figura 4A, um sinal de “último aglomerado” 452 pode ser provido para o nó servidor de origem pelo nó fonte 402 depois que todos os fragmentos de um segmento (por exemplo, o Segmento n° N) tiverem sido carregados. Antes da recepção do sinal de último aglomerado 452, a lógica de serviço apropriada em execução no nó de origem da CDN 404, por exemplo, em associação com o componente do servidor HTTP CTE 405 e/ou componente do emissor MC constituintes 407, pode ser configurada para efetuar várias comunicações, sinais e/ou mensagens entre os componentes do nó de origem da CDN 404, por exemplo, o servidor HTTP CTE 405 (que pode ser referido como um servidor HTTP CTE à montante) e o emissor MC 407, para o processamento dos metadados recebidos (por exemplo, os cabeçalhos HTTP), bem como os aglomerados de dados HTTP para a transmissão à jusante por meio de difusão seletiva por IP adequada assim que a informação relevante estiver disponível. A transmissão ou a propagação dos cabeçalhos HTTP 422, bem como a transmissão ou a propagação dos dados aglomerados em relação a um ou mais fragmentos 4161 a 416-N, da forma exemplificada pelas transmissões de dados de

Petição 870200002271, de 06/01/2020, pág. 49/144 / 103 aglomerado 430, 438, 446, são ilustrativas em uma modalidade de exemplo. Adicionalmente, a lógica de serviço em execução no nó de origem da CDN 404, por exemplo, em associação com o emissor MC 407, pode ser configurada para gerar os objetos de transporte em difusão seletiva por IP apropriados (por exemplo, dependendo do(s) protocolo(s) de difusão seletiva por IP configurado(s) para o servidor de origem da CDN 404), que podem ser configurados para conduzir a informação do cabeçalho HTTP e os dados de mídia para o receptor de MC 409 associado com o nó de borda da CDN 406, como será apresentado com detalhes adicionais a seguir. A título de ilustração, a transmissão 424 é ilustrativa da condução da informação do cabeçalho HTTP em um objeto de transporte adequadamente empacotado de acordo com o protocolo de difusão seletiva por IP que é usado. Igualmente, as transmissões 434, 440, 448 são ilustrativas da condução dos dados de mídia de um segmento parcial, novamente, em objetos de transporte adequadamente empacotados de acordo com o protocolo de difusão seletiva por IP que é usado. A lógica de serviço apropriada em execução no nó de borda da CDN 406, por exemplo, em associação com o componente do receptor de MC 409 e o componente do servidor HTTP CTE constituintes 406 (que podem ser referidos como um servidor CTE à jusante) e/ou o emissor MC 407, pode ser configurada para efetuar várias comunicações, sinais e/ou mensagens entre os componentes do nó de borda da CDN 406, por exemplo, o servidor HTTP CTE 411 e o emissor MC 409, para o processamento dos metadados recebidos (por exemplo, os cabeçalhos HTTP), bem como os dados de mídia nos objetos de transporte, dependendo de onde a funcionalidade do receptor de MC fica localizada/integrada, se um cliente é capaz de consumir diretamente os objetos da difusão seletiva por IP, etc. Da forma ilustrada na figura 4A, os cabeçalhos HTTP podem ser providos para o servidor HTTP CTE à jusante 411 por meio de uma transmissão 426, os objetos podem ser temporariamente armazenados no armazenamento temporário do servidor por

Petição 870200002271, de 06/01/2020, pág. 50/144 / 103 meio de uma ação de armazenamento 428, e os aglomerados HTTP podem ser criados para os múltiplos fragmentos do segmento, da forma indicada pelos números de referência 436, 442, 450, em relação à distribuição à jusante para o cliente 408 quando houver uma solicitação pela mídia (por exemplo, o cliente sintonizando em ou comutando para um canal correspondente ao fluxo contínuo de mídia ao vivo). Os versados na técnica irão perceber que os aglomerados/segmentos de dados de mídia recebidos podem ser armazenados em locais de armazenamento identificados de acordo com a informação do cabeçalho HTTP, por exemplo, em URLs relativos indexados a partir de um URL base para um segmento, tanto no nó de borda 406 quanto em algum outro nó de armazenamento de mídia associado com o mesmo.

[0053] Da forma previamente notada, as operações no lado do UE/cliente em relação à solicitação e a transferência de dados de mídia podem ser efetuadas usando os mecanismos de transferência de dados HTTP CTE (por exemplo, por um UE/aplicação cliente em conformidade com CTE) ou os mecanismos HTTP normais (por exemplo, por um UE/aplicação cliente legados). Na modalidade ilustrativa da figura 4A, a lógica de serviço apropriada associada com o cliente em conformidade com CTE 408, por exemplo, em associação com o receptor HTTP CTE 413, é operativa para gerar uma solicitação HTTP CTE 433 para o segmento (por exemplo, com base em um arquivo de manifesto ou MPD recebidos por meio de um mecanismo de transmissão fora de banda ou em banda; o MPD contém a informação em que o cliente pode começar a localização e carregamento dos segmentos antes de os segmentos estarem completamente disponíveis), de acordo com o que, os dados de mídia do segmento são providos por meio da distribuição aglomerada por HTTP em uma pluralidade de transmissões de aglomerado, por exemplo, as transmissões de aglomerado 435 em relação ao fragmento 416-1 e as transmissões de aglomerado em relação ao fragmento final 416-N. Da forma indicada pelo número de referência 431, os dados de

Petição 870200002271, de 06/01/2020, pág. 51/144 / 103 mídia recebidos podem ser providos para o armazenamento temporário do reprodutor de mídia 415 para renderização em um visor adequado.

[0054] Em uma modalidade de exemplo, a lógica de serviço em execução no nó de origem da CDN 404 é operativa para remover as marcas de limite de aglomerado em relação aos aglomerados HTTP carregados a partir do nó fonte 402. Em uma modalidade de exemplo, responsivo ao sinal de último aglomerado proveniente do nó fonte 402, o nó de origem da CDN 404 pode ser configurado para somar os tamanhos de todos os aglomerados para gerar uma indicação de tamanho do objeto 453 associado com o segmento para sinalização da indicação de tamanho do objeto para os receptores de difusão seletiva em borda, por exemplo, o nó de borda da CDN 406. Em uma outra modalidade, as indicações de limite de aglomerado podem ser providas para o receptor de MC 409 do nó de borda da CDN 406, que pode somar os tamanhos de todos os fragmentos. Uma vez que o tamanho do arquivo é conhecido pelo nó de borda da CDN 406 (tanto por sinalização explícita proveniente do servidor de origem da CDN 404 quanto por meio de uma determinação interna pelo receptor de MC), um sinal de “último aglomerado” 454 pode ser gerado para o cliente 408, que pode ser propagado para o reprodutor de mídia, da forma indicada pelo sinal 456. Dependendo da configuração do cliente, uma solicitação HTTP 460 por um próximo segmento (por exemplo, o Segmento n° N+l) pode ser com base na recepção do sinal de último aglomerado propagado 456. Em uma outra modalidade de exemplo, o cliente pode ser configurado para gerar as próximas solicitações de segmento 460 em intervalos preconfigurados sem a necessidade de receber um sinal de último aglomerado 456.

[0055] Na figura 4A e na figura 4B, a origem da CDN 404 usa o URL base Empurrar para determinar a informação da transmissão da difusão seletiva por IP base associada, tais como o endereço da difusão seletiva por IP, a porta UDP e o protocolo (NORM ou FLUTE). Um URL base Empurrar

Petição 870200002271, de 06/01/2020, pág. 52/144 / 103 pode ser comparado com uma pasta de diretório em um sistema de arquivos, em que todos os arquivos ou objeto nesta pasta são associados com uma transmissão. Um nó controlador separado, tipicamente, provê o URL base Empurrar e os parâmetros de transmissão da difusão seletiva por IP associados. O nó de origem da CDN associou uma função do Emissor de Difusão Seletiva (407) a cada URL base Empurrar e pode substituir a parte do URL base Empurrar com um URL visível. Para cada segmento e aglomerado individual recebido, a Função do Emissor de Difusão Seletiva (407) está, então, atribuindo um identificador do Objeto de Transporte exclusivo.

[0056] Em relação à distribuição por difusão seletiva por IP na CDN, uma modalidade de exemplo que envolve NORM (RFC 5740, aqui incorporada pela referência) é apresentada, com detalhes adicionais a seguir. Em uma modalidade, o emissor MC 407 pode ser configurado para criar um Objeto de Transporte NORM para cada aglomerado HTTP, independente se um aglomerado HTTP contém um fragmento completo ou um fragmento parcial. Se um objeto de transporte por IP contém um fragmento completo ou um fragmento parcial pode não ter um impacto significativo em um ambiente de conexão com fios, por exemplo, rede DSL/cabo, em que as velocidades de transmissão são, no geral, mais altas e a perda de pacote é mínima (isto é, os dados são recuperáveis). Por outro lado, em redes de telecomunicações móveis em que os dispositivos UE móveis não podem estabelecer prontamente os enlaces ascendentes, as perdas que envolvem os fragmentos parciais são usualmente não recuperáveis, desse modo, causando potencialmente problemas de sincronismo no lado do reprodutor, especialmente, quando quadros chaves, tais como IDR ou quadros I forem perdidos. Como será apresentado a seguir, os refinamentos adicionais em relação à distribuição por difusão seletiva por IP em uma rede de telecomunicações móveis LTE exemplar são descritos de acordo com uma modalidade da presente invenção. Os versados na técnica irão reconhecer,

Petição 870200002271, de 06/01/2020, pág. 53/144 / 103 entretanto, que pelo menos alguns aspectos do esquema de distribuição por difusão seletiva por IP aqui descrito também podem ser aplicáveis em uma modalidade de distribuição por difusão seletiva por IP ou por difusão com base em rede móvel, mutatis mutandis, por exemplo, em uma rede que emprega FLUTE.

[0057] Em um arranjo, um Cabeçalho Aglomerado HTTP (por exemplo, <size>\r\n, que é algumas vezes também chamado de marcador de limite do aglomerado ou indicação de limite do aglomerado) e um rastro (trailing \r\n) podem ser removidos dos aglomerados HTTP recebidos. A lógica de serviço em execução no nó emissor MC 407 é operativa para usar a carga útil do aglomerado para gerar o Objeto de Transporte NORM, em que o Tamanho do Objeto de Transporte NORM (isto é, equivalentemente, o tamanho do aglomerado HTTP) pode ser sinalizado tanto com o cabeçalho de extensão da Informação de Transferência de Arquivo (EXT_FTI) quanto como parte de uma mensagem NORM INFO (por exemplo, em uma ou mais opções, como será apresentado a seguir). Será percebido que em uma modalidade de distribuição por difusão seletiva por IP com base em rede móvel, por outro lado, pode ser benéfico sempre enviar os fragmentos de segmento completos como Objetos. Em um cenário como este, o número de aglomerados HTTP usados para um fragmento de mídia tanto pode ser sinalizado com um novo cabeçalho HTTP no início do segmento quanto pode ser separadamente configurado com o nó servidor de origem da CDN (tanto através de um arquivo de configuração no nó quanto por meio de um servidor de configuração e controle externo) ou um elemento de rede operativo como um servidor de origem para difusão/difusão seletiva ou seu equivalente funcional. Desta maneira, os versados na técnica irão reconhecer que, no caso de ambientes de distribuição por cabo/DSL com base em NORM, pode haver nenhum benefício tangível no alinhamento dos Objetos de Transporte NORM com os fragmentos de segmento.

Petição 870200002271, de 06/01/2020, pág. 54/144 / 103

[0058] Quando o servidor de origem da CDN 404 receber os cabeçalhos HTTP e o URL do segmento para um novo segmento, a lógica de serviço associada com o emissor MC 407 (por exemplo, configurada para suportar difusão seletiva confiável com base em NORM), é operativa para prover o URL do segmento e os cabeçalhos HTTP com uma mensagem NORM INFO associada com um ID do Objeto de Transporte (TOI) em particular, por exemplo, NORM INFO 477, da forma ilustrada no fluxograma de mensagem 400B da figura 4B, para um ou mais nós receptores de difusão seletiva em borda, por exemplo, o receptor de MC 409 associado com o nó de borda da CDN 406 (mostrado na figura 4A). Deve ser percebido que o servidor de origem da CDN 404 também pode tomar o segmento recebido disponível para distribuição por difusão ponto a ponto. Conceitualmente, o servidor de origem da CDN 404 e a borda da CDN 406 são, então, implementados no mesmo nó e a ingestão no Nó Servidor HTTP 405 é imediatamente disponibilizada no nó Servidor HTTP 406.

[0059] Em uma modalidade de exemplo, a mensagem NORM INFO pode ser associada com o primeiro aglomerado do segmento através do TOI (isto é, a mensagem NORM INFO conduz o mesmo TOI que o primeiro aglomerado do segmento). Deve-se notar que, enquanto a informação do cabeçalho HTTP na mensagem NORM INFO pode ser configurada para indicar distribuição aglomerada por HTTP, assim, a mesma pode não incluir um campo do cabeçalho de Comprimento do Conteúdo em uma modalidade de exemplo. Adicionalmente, o emissor MC 407 pode ser configurado para gerar uma mensagem NORM INFO (por exemplo, com os cabeçalhos HTTP e o URL do segmento) apenas para o primeiro aglomerado (isto é, um fragmento completo ou um fragmento parcial) do segmento de acordo com uma implementação, em que os aglomerados subsequentes do segmento não são providos com uma respectiva mensagem NORM INFO. Neste arranjo, o tamanho do aglomerado (também referido como tamanho do objeto de

Petição 870200002271, de 06/01/2020, pág. 55/144

50/103 transporte) pode ser sinalizado através do cabeçalho de extensão EXT_FTI, da forma previamente notada. O valor do TOI pode ser incrementado sequencialmente para os fragmentos subsequentes, por exemplo, aumentado iterativamente em um, em que um cliente de difusão seletiva pode ser configurado para associar o objeto recebido com o recurso HTTP para o qual recebeu por último uma mensagem NORM INFO. A título de exemplo, ο primeiro fragmento com o URL do segmento e os cabeçalhos HTTP pode ser enviado em um objeto com um valor do TOI de 20. Preferivelmente, o receptor/cliente de MC NORM é operativo para anexar todos os Objetos de Transporte NORM subsequentes (por exemplo, o Objeto de Transporte com TOI = 21) no objeto de transporte com TOI de 20, da forma ilustrada na figura 4B, em que múltiplas instâncias do número de referência 478 se referem a uma pluralidade de mensagens ou objetos de NORM DATA para conduzir dados de mídia e associadas com a mensagem NORM INFO 477. Os versados na técnica irão perceber que um benefício deste mecanismo de distribuição é que uma mensagem NORM INFO (por exemplo, mensagem NORM INFO 477) pode conter uma cópia exata do cabeçalho HTTP proveniente do nó fonte 402, ao mesmo tempo em que é desprovida de um indicador de tamanho indicativo do tamanho do primeiro aglomerado HTTP. Da forma notada previamente, o sinal de último aglomerado 452 pode ser provido para o nó de origem da CDN 404 depois que os dados do último fragmento de um segmento forem carregados em uma transação de distribuição do aglomerado HTTP 451, cujos dados de fragmento são processados e providos para o nó emissor MC 407 como transmissões de dados internas 446, 448.

[0060] Em uma outra modalidade exemplar, uma mensagem NORM INFO pode ser transmitida com cada Objeto de Transporte NORM, em que a mensagem NORM INFO para o primeiro aglomerado pode ser configurada para incluir o URL do segmento, os cabeçalhos HTTP, bem como uma

Petição 870200002271, de 06/01/2020, pág. 56/144

51/103 indicação de tamanho do tamanho do aglomerado HTTP. Por outro lado, as mensagens NORM INFO para todos os aglomerados subsequentes podem conter apenas o tamanho do aglomerado.

[0061] E apresentado a seguir um exemplo de mensagem NORM INFO para um primeiro aglomerado de acordo com uma modalidade:

<Metadata key= “httpHeaders ” value=“HTTP/l.l 200 OK

Servidor: Apache

Accept-Ranges: bytes Transfer-Encoding: chunked Content-Type: video/mp4 Connection: keep-alive ” /> <Metadata key= “chunkSize ” value=“1056” /> </SegmentMetadata >

[0062] Deve ser notado que o tamanho do aglomerado não é provido com os cabeçalhos HTTP, mas como uma entrada separada.

[0063] Um exemplo de formato de mensagem NORM INFO para os aglomerados subsequentes pode compreender o que é ilustrado a seguir:

Petição 870200002271, de 06/01/2020, pág. 57/144

52/103 </SegmentMetadata >

[0064] Em uma outra modalidade exemplar, uma mensagem NORM INFO pode ser transmitida com cada Objeto de Transporte NORM, em que todas as mensagens NORM INFO podem ser configuradas para incluir o URL do segmento, os cabeçalhos HTTP, bem como uma indicação de tamanho do tamanho do aglomerado HTTP. Para identificar o primeiro aglomerado, um número de aglomerado é introduzido em cada mensagem NORM INFO. Ο primeiro aglomerado de um segmento é sempre identificado por número de aglomerado zero (ou um outro número bem definido). Todos os aglomerados subsequentes são numerados com um número de aglomerado crescente.

[0065] E apresentado a seguir um exemplo de mensagem NORM INFO para um primeiro aglomerado de acordo com uma modalidade:

<Metadata key= “httpHeaders ” value=“HTTP/l.l 200 OK

Server: Apache

Accept-Ranges: bytes Transfer-Encoding: chunked Content-Type: video/mp4 Connecion: keep-alive” /> <Metadata key= “chunkSize ” value=“1056” /> <Metadata key= “ chunkNumber”

Petição 870200002271, de 06/01/2020, pág. 58/144 / 103 value=“0”/>

</SegmentMetadata >

[0066] Um exemplo de formato para os aglomerados subsequentes pode compreender o que é ilustrado a seguir:

<Metadata key= “httpHeaders ” value=“HTTP/l.l 200 OK

Server: Apache

Accept-Ranges: bytes

Transfer-Encoding: chunked

Content-Type: video/mp4 Connecion: keep-alive” /> <Metadata key= “chunkSize” value=“1156” />

</SegmentMetadata >

[0067] Enquanto que apenas o indicador chunkSize pode ser incluído em uma modalidade, da forma exemplificada anteriormente, uma variação adicional ou alternativa também pode suportar a provisão do URL do segmento, opcionalmente ou de outra forma. Os versados na técnica irão reconhecer, mediante referência aqui, que uma potencial desvantagem deste cenário é que a informação do cabeçalho HTTP e a informação do URL do

Petição 870200002271, de 06/01/2020, pág. 59/144

54/103 segmento podem precisar ser atrasadas até que o primeiro fragmento fique disponível.

[0068] Ainda uma outra variação envolve usar um deslocamento de aglomerado em vez de um número de aglomerado para definir a sequência dos aglomerados. Por exemplo, o deslocamento de aglomerado pode ser configurado para representar a posição de byte na qual um aglomerado é colocado no segmento abrangente. A título de ilustração, um deslocamento de aglomerado zero indica que o aglomerado é colocado no início do segmento abrangente. Um deslocamento de aglomerado 1000 pode indicar que o primeiro byte do aglomerado está posicionado no deslocamento de byte 1000 no segmento abrangente. A soma do deslocamento de aglomerado com o tamanho do aglomerado, tipicamente, dá o deslocamento de aglomerado para o próximo aglomerado. O benefício de usar um deslocamento de aglomerado, se comparado com um número de aglomerado, é que o receptor não pode apenas detectar perdas de aglomerado, mas ainda pode detectar a faixa de byte ausente do aglomerado ausente.

[0069] Uma variação ainda adicional também pode envolver a transmissão de uma mensagem NORM INFO para cada Objeto de Transporte NORM, mas duas mensagens NORM INFO são transmitidas para o primeiro aglomerado. Neste cenário, a primeira mensagem NORM INFO para o primeiro aglomerado pode ser configurada para conter apenas os cabeçalhos HTTP, ao mesmo tempo em que a segunda mensagem NORM INFO pode ser configurada para conter apenas o tamanho do aglomerado. Um exemplo de formato de mensagem NORM INFO que contém o URL do segmento e a informação do cabeçalho HTTP nesta modalidade é apresentado a seguir:

Petição 870200002271, de 06/01/2020, pág. 60/144 / 103 <Metadata key= “httpHeaders ” value=“HTTP/l.l 200 OK

Servidor: Apache

Accept-Ranges: bytes Transfer-Encoding: chunked Content-Type: video/mp4 Connection: keep-alive ” />

[0070] Um exemplo de formato de mensagem NORM INFO para o primeiro e todos os aglomerados subsequentes (contendo apenas o chunkSize e, opcionalmente, um segmentUrk) é apresentado a seguir:

</SegmentMetadata >

[0071] Os detalhes adicionais em relação ao processamento de um receptor de borda NORM (por exemplo, o receptor de MC 409 associado com o nó de borda da CDN 406 mostrado na figura 4A) são apresentados imediatamente a seguir.

[0072] Em uma modalidade de exemplo, assim que o componente do receptor de MC 409 associado com o nó de borda da CDN 406 receber a mensagem NORM INFO com o URL de Segmento e a informação do cabeçalho HTTP para o futuro segmento (por exemplo, a mensagem NORM INFO 477 no fluxograma de mensagem 400B da figura 4B ou por meio da mensagem da informação de difusão seletiva por IP 424 no fluxograma da mensagem 400A da figura 4A), o nó de borda da CDN 406 pode começar a servir uma solicitação do cliente em relação ao canal de mídia solicitado, embora nenhuma carga útil HTTP e/ou nenhuma informação de Comprimento

Petição 870200002271, de 06/01/2020, pág. 61/144

56/103 do Conteúdo ainda tenham sido recebidas. Em virtude da informação de Comprimento do Conteúdo não ser conhecida, o nó de borda da CDN 406 fica operativo para servir a resposta usando o servidor HTTP CTE à jusante associado 411 para efetuar a distribuição aglomerada por HTTP, já que o cabeçalho HTTP ^transfer-encoding: chiinkecT ainda está presente na carga útil da mensagem NORM INFO 477. Em um arranjo, a distribuição aglomerada da carga útil da mídia pode ocorrer preferivelmente até que o segmento completo seja recebido e submetido a cache. Em um outro arranjo, as respostas HTTP regulares podem ser providas, preferivelmente, depois que todos os fragmentos para o segmento forem recebidos.

[0073] O componente do servidor HTTP CTE 411 do nó de borda da CDN 406 pode ser configurado para começar a servir pelo envio da informação do cabeçalho HTTP, que inclui a informação de local do conteúdo aplicável (por exemplo, incluindo todas as traduções URL, se necessárias), bem como o cabeçalho de Transferência Aglomerada, em relação a um cliente em conformidade com CTE. Deve ser percebido que o primeiro aglomerado pode apenas ser gerado e transmitido quando todos os dados para esta parte de aglomerado forem recebidos, particularmente, quando a taxa de bits do enlace entre o cliente 408 e o nó de borda da CDN 406 for mais alta do que a taxa de bits da difusão seletiva.

[0074] Em uma modalidade adicional ou alternativa, o nó de borda da CDN 406 pode ser configurado para armazenar temporariamente o objeto de transporte por uma quantidade de tempo configurável (por exemplo, relativamente pequena) e/ou até que os dados suficientes para um aglomerado sejam recebidos. A título de ilustração, um limite de armazenamento temporário de 1.400 bytes pode ser provido (isto é, o servidor HTTP 411 armazena temporariamente os dados até que 1.400 bytes tenham sido recebidos), que pode ser a carga útil de um pacote UDP.

[0075] Os refinamentos ainda adicionais em relação a uma ou mais

Petição 870200002271, de 06/01/2020, pág. 62/144 / 103 das modalidades expostas são apresentados nas seguintes seções. Da forma previamente notada, o nó fonte 402 pode iniciar o envio do primeiro fragmento do segmento assim que o segmentador 403 tiver finalizado o fragmento, por exemplo, todos os quadros para os fragmentos foram recebidos e codificados antes da criação do fragmento. Além do mais, as funcionalidades adicionais, tais como DRM/DWM, políticas de conteúdo, etc. podem ser introduzidas no plano de dados nesta conjuntura em uma modalidade adicional. O componente do emissor MC 407 associado com o nó de origem da CDN 404 pode ser configurado para receber os dados, excluindo os cabeçalhos do aglomerado HTTP do componente do servidor HTTP CTE à montante 405 associado, e embrulha os dados em cargas úteis de pacote NORM. Um Objeto de Transporte NORM é particionado em um ou mais pacotes de dados NORM. Em uma implementação, o componente do emissor MC 407 pode ser configurado para aumentar continuamente um identificador de pacote ou um identificador de carga útil sequenciais, que podem ser configurados independente se um esquema de correção de erro, por exemplo, esquema FEC, é implementado para a distribuição por difusão seletiva por IP, e adicionar os mesmos em cada novo pacote dos objetos de transporte IP. Por exemplo, um ID do Símbolo de Codificação no cabeçalho do ID da Carga Útil de FEC pode ser incrementado e adicionado em cada um dos novos pacotes NORM ou FCAST. A numeração do pacote pode ser uma hierarquicamente organizada, significando um número do bloco fonte e um número do pacote ou símbolo. Adicionalmente, cada pacote também pode conter o campo TOI (Id do Objeto de Transporte), da forma notada previamente, que pode ser configurado para associar exclusivamente cada pacote com o objeto HTTP ou o aglomerado HTTP. Em uma configuração, a entidade receptora de MC 409 pode ser configurada para monitorar o identificador de carga útil/pacote sequencial (por exemplo, o ID da carga útil da FEC) dos pacotes recebidos e ordenar os pacotes de acordo com o ID de carga útil da FEC e encaminhar o

Petição 870200002271, de 06/01/2020, pág. 63/144

58/103 fluxo contínuo ordenado para o servidor HTTP CTE à jusante associado 411. Quando os pacotes ausentes forem detectados (por exemplo, com base no ID de carga útil da FEC), uma modalidade do receptor de MC 409 pode ser configurada para reter o fluxo contínuo até que o pacote tenha sido recuperado. Os versados na técnica irão perceber que este recurso é particularmente relevante em uma modalidade da presente invenção em que a distribuição Em Ordem dos objetos HTTP ou dos aglomerados HTTP pode ser exigida para HTTP CTE.

[0076] Em relação à indicação da última transmissão de aglomerado em uma sessão de carregamento HTTP CTE, diversas variações podem ser praticadas de acordo com os preceitos aqui expostos. Em uma modalidade, quando o segmentador 403 tomar o último fragmento de um segmento disponível, o nó de rede fonte 402 fica operativo para carregar o fragmento usando a distribuição aglomerada por HTTP e sinaliza o final do objeto HTTP usando um mecanismo Esvaziar Aglomerado para indicar o “fim do objeto HTTP”, isto é, como um sinal de último aglomerado 452 apresentado nas figuras 4A e 4B. Da forma notada previamente, quando o componente do servidor HTTP CTE 405 receber o sinal de “último aglomerado de objeto”, o mesmo fica operativo para calcular o tamanho do objeto pela soma de todos os tamanhos de aglomerados recebidos. Em uma modalidade para sinalizar implicitamente o “fim da distribuição aglomerada” usando NORM, o componente do receptor de MC 409 associado com o nó de borda da CDN 406 pode ser configurado para tratar a recepção de uma nova mensagem NORM INFO com um novo URL do segmento e novos cabeçalhos HTTP como uma indicação da conclusão da distribuição aglomerada anterior ou atual. Os versados na técnica irão reconhecer, mediante referência ao presente, que uma potencial desvantagem de uma solução como esta é que o cliente de difusão seletiva (por exemplo, o receptor de MC) não pode fechar um objeto aglomerado até que um novo objeto seja iniciado. Em uma

Petição 870200002271, de 06/01/2020, pág. 64/144

59/103 modalidade adicional, uma nova mensagem de comando (CMD) NORM pode ser gerada para a sinalização explícita do “fim da distribuição aglomerada” para as entidades destinatárias de difusão seletiva por IP. Uma nova mensagem CMD NORM pode ser gerada como uma mensagem de controle dedicada, que pode ser definida de novo, ou uma mensagem CMD existente pode ser reusada ou reconfigurada para sinalizar explicitamente uma indicação de fim de objeto para o(s) receptor(es) de MC. Em uma modalidade ainda adicional, uma mensagem NORM INFO associada com um Objeto de Transporte NORM de tamanho zero pode ser gerada para sinalizar uma indicação de fim de objeto. Os versados na técnica irão perceber que esta modalidade é aplicável apenas em um arranjo em que uma mensagem NORM INFO é transmitida com cada aglomerado, que foi aqui descrito como uma modalidade de exemplo anteriormente. Em uma modalidade ainda adicional, o último pacote NORM do último aglomerado pode ser configurado para conter um indicador de último aglomerado, similar a um Indicador B. Em ainda uma outra variação, o componente do emissor MC 407 pode ser configurado para transmitir um Objeto de Transporte NORM vazio (ainda com um ESI e um TOI válidos) com o cabeçalho de extensão EXT_FTI, em que o cabeçalho de extensão pode ser configurado para conter o tamanho do objeto, para o(s) receptor(es) de MC da rede de distribuição.

[0077] A figura 4C representa um fluxograma da mensagem 400C em relação a uma outra modalidade variante de ingestão que envolve usar HTTP GET para ingestão de segmentos e aglomerados de mídia na origem 404. Nesta variação, um nó segmentador/empacotador 485, também referido como origem do segmentador, é configurado para tomar os segmentos disponíveis através de um servidor HTTP local. O nó de origem 404 inclui um Cliente ABR 487, que pode ser configurado para localizar e carregar os segmentos, da forma descrita e disparada por um manifesto ABR. A título de ilustração, o manifesto ABR pode ser uma Descrição de Apresentação da Mídia (MPD)

Petição 870200002271, de 06/01/2020, pág. 65/144

60/103

DASH ou um outro formato de manifesto. O manifesto descreve os URLs do segmento e o sincronismo no qual os segmentos ficam disponíveis. O URL do manifesto e a associação com uma função do emissor de difusão seletiva (407) são providos por um nó de controle separado. Os nós controladores proveem o endereço da difusão seletiva por IP, a porta UDP e, talvez, o protocolo como FLUTE ou NORM. Para cada objeto ou aglomerado HTTP recentemente recebidos, o emissor MC atribui um identificador do Objeto de Transporte exclusivo. O Cliente ABR 487 fica operativo para determinar, para cada segmento, um tempo de Início de Disponibilidade do Segmento que define o tempo a partir do qual o segmento fica disponível para transferência usando HTTP GET. Quando o segmentador/empacotador 485 criar segmentos multifragmentos, o segmentador/empacotador 485 fica operativo para tomar os fragmentos de segmento anteriores e usa a codificação de transferência aglomerada HTTP quando um Cliente ABR começar a localização e carregamento do segmento antes da íntegra do segmento estar disponível. O Manifesto DASH pode conter uma indicação (isto é, Deslocamento do Tempo de Disponibilidade, ASTO) que indica que os fragmentos de segmento estão disponíveis um deslocamento de tempo antes do segmento completo.

[0078] Responsivo a ser disparado pelo tempo de início de disponibilidade do segmento (calculado a partir de um manifesto DASH) e corrigido pelo deslocamento de tempo ASTO, o Cliente ABR 487 fica operativo para enviar uma solicitação de segmento 489 que contém o URL do segmento do segmento solicitado. A origem do segmentador 485 começa a enviar uma resposta 491 que contém os cabeçalhos HTTP para o segmento e o primeiro aglomerado HTTP. Mediante a recepção, o Cliente ABR 487 dispara o emissor MC 407 que passa no URL do segmento (proveniente da solicitação do segmento 489) e os cabeçalhos HTTP provenientes de 491 usando o gatilho 422, que indica a codificação de transferência aglomerada HTTP. O Cliente ABR 487 transmite os dados de resposta HTTP, removendo

Petição 870200002271, de 06/01/2020, pág. 66/144 / 103 os marcadores de limite do aglomerado HTTP, para o emissor MC 407. O Cliente ABR 487 continua o encaminhamento dos aglomerados HTTP (por exemplo, os aglomerados 437), removendo os marcadores de limite do aglomerado HTTP. Quando o Cliente ABR 487 receber um indicador de último aglomerado (por exemplo, o indicador 451, como exposto), o mesmo fica operativo para disparar uma indicação correspondente no caminho de difusão seletiva (por exemplo, o caminho 418). Depois disto, o Cliente ABR 487 determina o tempo de início do próximo segmento considerando o deslocamento de tempo (ASTO) e dispara a localização e carregamento do segmento 493 do próximo URL de Segmento. Então, o Cliente ABR 487 dispara o emissor MC 407 usando o URL do segmento proveniente da solicitação de localização e carregamento 493 e os cabeçalhos HTTP por meio do caminho 495. Deve-se notar que o Cliente ABR 487 está recebendo apenas o fragmento relacionado aos dados de mídia entre 420 e 437 (e, posteriormente, entre 444 e 451). Ao mesmo tempo em que o segmentador 485 está criando o fragmento, o segmentador não está enviando nenhum dos dados relacionados aos fragmentos (isto é, nenhum dos dados de fragmento entre 491 e 420 e entre 437 e 444). Quando o segmento contiver mais do que dois fragmentos ou quando o segmentador 485 estiver subdividindo um fragmento em mais aglomerados HTTP, então, o procedimento é repetido desta maneira.

[0079] As figuras 5-7 representam vários aspectos de uma arquitetura de rede de telecomunicações móveis LTE configurada para difusão de mídia com os propósitos de uma modalidade da presente invenção. Voltando para a figura 5 em particular, a rede LTE 500 é ilustrada com um nó BMSC 504 (por exemplo, operativo como uma porta de comunicação de ingestão móvel 231 mostrada na figura 2) que fica disposto em um Núcleo de Pacote Evoluído (EPC) 553, que é configurado para suportar Serviços de Difusão Multimídia Evoluídos (eMBMS) em relação a uma área de serviço de difusão 552

Petição 870200002271, de 06/01/2020, pág. 67/144

62/103 composta por uma pluralidade de células 554-1 a 544-N em uma modalidade de exemplo. Por meio de ilustração adicional, um ou mais nós eNB 556 são providos como parte da infraestrutura celular para servir usuários/dispositivos móveis 558 dispostos na área de serviço 552. Preferivelmente, um nó ou rede fonte de conteúdo 502 ficam operativos para carregar os fragmentos de segmento para o nó BMSC 504 usando a distribuição aglomerada por HTTP da forma aqui apresentada com detalhes a seguir. Uma porta de comunicação de serviço (SGW) e/ou uma porta de comunicação (PGW) da rede de dados em pacote (PDN) associada, mostradas como um elemento comum 510 na figura 5, podem ser providas como parte de EPC 553 e podem ser acopladas no nó BMSC 504 por meio da interface SGi 509. Uma Entidade de Gerenciamento de Mobilidade (MME) 508 pode ser acoplada no elemento S/PGW 510 por meio da interface de controle Sll 511. Um nó da porta de comunicação (GW) MBMS 506 pode ser acoplado na MME 508 por meio da interface Sm 519 e no BMSC 504 por meio da interface do plano de controle SGmb 507 e da interface do plano de dados SGi-mb 505. Cada nó eNB 556 pode ser acoplado na MME 508 por meio de uma respectiva interface do plano de controle M3/S2-MME 515 e na MBMS-GW 506 por meio de uma respectiva interface do plano de dados Ml 517. O elemento S/PGW 510 também pode ser provido com a interface do plano de dados Sl-U 513 para suportar a difusão ponto a ponto.

[0080] Em um exemplo de arranjo da arquitetura da rede LTE 500, os canais de rádio de difusão e difusão ponto a ponto podem ser configurados para coexistir na mesma célula e compartilhar a capacidade disponível, em que um subconjunto dos recursos de rádio disponíveis pode ser temporariamente atribuído a um canal de rádio de difusão. Enquanto que uma rede LTE convencional é tradicionalmente desenhada para a comunicação por difusão ponto a ponto, com um canal de rádio separado servindo cada dispositivo móvel (em que os recursos alocados no dispositivo dependem da

Petição 870200002271, de 06/01/2020, pág. 68/144 / 103 taxa de dados exigida pelo serviço, da qualidade do canal de rádio e dos volumes de tráfego gerais na célula), as comunicações por difusão/difusão seletiva podem ser implementadas em uma modalidade de exemplo como uma extensão para uma arquitetura do Sistema de Pacote Evoluído (EPS) que compreende a parte de EPC 553 acoplada na rede da fonte de conteúdo 502 de acordo com os preceitos do presente pedido de patente. Uma implementação da arquitetura da rede LTE 500 pode, portanto, ser configurada de acordo com a especificação 3GPP TS 23.246 (Arquitetura MBMS), aqui incorporada pela referência, em que a difusão de mídia/difusão seletiva podem coexistir com os serviços de dados e voz de difusão ponto a ponto, embora deva ser percebido que as modalidades da presente invenção não são limitadas a esta. Em um arranjo, os cenários de caso de uso tanto da transmissão contínua ao vivo quanto da distribuição de arquivo podem ser suportados, em que diferentes combinações de serviço podem ser distribuídas simultaneamente através da mesma portadora. Em um arranjo, a ativação do serviço de difusão pode ser configurada para disparar a alocação de recursos de rádio no exemplo de rede LTE 500 com base na necessidade. Por exemplo, uma sessão de difusão pode ficar ativa por um curto tempo, diversos minutos ou por períodos mais longos, por exemplo, ou diversos dias, em alguns casos. Quando a sessão não estiver mais ativa, os recursos de rádio e de sistema atribuídos podem ser realocados para uso por outros serviços. Adicionalmente, a difusão LTE pode ser ativada para pequenos locais geográficos, tais como estádios e centros de cidades, ou para grandes áreas, que cobrem, por exemplo, a íntegra de uma cidade ou região. Desde que haja capacidade suficiente na rede LTE 500, múltiplas sessões de difusão podem ficar ativas simultaneamente. Em um arranjo, os recursos para difusão podem, portanto, ser alocados dinamicamente, por exemplo, até 60 por cento dos recursos de rádio de duplexação por divisão de frequência (FDD) e/ou até 50 por cento para duplexação por divisão de tempo (TDD) podem ser atribuídos a uma transmissão por difusão.

Petição 870200002271, de 06/01/2020, pág. 69/144

64/103

[0081] Em um exemplo de arranjo da arquitetura da rede LTE 500, a interface de rádio pode ser com base em multiplexação por divisão de frequência ortogonal (OFDM) no enlace descendente, em que o canal de banda larga seletivo de frequência pode ser subdividido em canais de banda estreita ortogonais uns aos outros. Por exemplo, um quadro de rádio de 10 milissegundos (ms) no domínio de tempo pode consistir em subquadros de 1 ms cada; em que um subquadro é a menor unidade com domínio de frequência completo que pode ser alocada em uma transmissão por difusão. Em um exemplo de implementação de eMBMS, todos os usuários em uma área de difusão, por exemplo, a área 552, podem receber o conteúdo difundido, desde que os mesmos tenham o nível de assinatura correto e um dispositivo com capacidade MBMS (isto é, um UE com uma aplicação cliente eMBMS). Será aparente aos versados na técnica que, pela configuração de uma única portadora sobre a interface de rádio, um operador de rede pode distribuir um fluxo contínuo de dados para um número ilimitado de usuários. Embora seja possível distribuir a difusão em uma única célula de uma área de serviço (por exemplo, usando a transmissão ponto para multipontos (PTM)), uma modalidade da presente invenção também pode ser praticada usando uma arquitetura de rede de frequência única (SFN). Em um arranjo que envolve a SFN, a área de difusão pode compreender uma pluralidade de células eNB em que os dados de difusão podem ser transmitidos enviados sobre uma SFN sincronizada que é efetuada como transmissões idênticas estritamente sincronizadas a partir de múltiplas células, usando os mesmos conjunto de subquadros e esquema de modulação e de codificação. Os versados na técnica irão perceber que, em um arranjo como este, as transmissões de SFN são configuradas para aparecer para dispositivo como uma transmissão a partir de uma única grande célula sobre um canal dispersivo de tempo, o que pode melhorar a qualidade do sinal recebido e a eficiência espectral. Pelo uso de longa duração do símbolo de dados em OFDM, é possível mitigar o efeito da

Petição 870200002271, de 06/01/2020, pág. 70/144 / 103 interferência interssímbolo (ISI) causada por sinais atrasados em um exemplo da modalidade de distribuição em banda larga móvel da presente invenção com base na arquitetura SFN. Para proteção adicional contra atrasos de propagação, LTE/OFDM podem ser configurados para usar um intervalo de segurança, em que os sinais atrasados que chegam durante o intervalo de segurança não causam ISI e, então, a taxa de dados pode ser mantida. Deve ser percebido que, para SFN, diferente da difusão ponto a ponto, os sinais podem chegar a partir de muitas fontes geograficamente separadas e pode incorrer em grande propagação do atraso, o que pode causar perdas de pacote irrecuperáveis, desse modo, necessitando de refinamentos adicionais em um esquema de distribuição por difusão seletiva por IP que envolve a banda larga móvel com os propósitos da presente invenção. Como um dos fatores que limitam a capacidade de MBMS na rede é a autointerferência a partir dos sinais provenientes dos transmissores com um atraso que é maior do que o intervalo de segurança (isto é, baixa densidade do transmissor), um longo prefixo cíclico pode ser adicionado em subquadros reservados para MBSFN em uma variação adicional da rede LTE 500 para permitir que a diferença de tempo no receptor corresponda a uma distância interlocais (ISD) aceitável (por exemplo, de aproximadamente 5 km) que pode ser configurada com base na capacidade e na área de cobertura de banda larga.

[0082] Continuando em relação à figura 5, o nó BMSC 504 pode ser configurado como um ponto de ingresso chave de um exemplo da árvore de distribuição por difusão/difusão seletiva LTE suportada pela arquitetura da rede LTE 500. Os arquivos genéricos e/ou os fluxos contínuos de vídeo ao vivo (por exemplo, em formato MPEG-DASH) providos a partir da CSN 502 por meio da distribuição aglomerada por HTTP podem ser conduzidos como conteúdo através do nó BMSC 504 e disponibilizados para distribuição por difusão usando FLUTE, como será apresentado com detalhes adicionalmente a seguir. Em uma modalidade, a lógica de serviço apropriada em execução no

Petição 870200002271, de 06/01/2020, pág. 71/144 / 103 nó BMSC 504 pode ser configurada para adicionar resiliência à difusão pelo uso de um esquema de correção de erro de nível superior, por exemplo, FEC em Camada de Aplicação (AL-FEC), que não apenas adiciona a redundância no fluxo contínuo, de forma que os receptores possam recuperar as perdas de pacote, mas também suportem vários procedimentos de distribuição associados a 3GPP em certos arranjos adicionais ou alternativos. Por exemplo, tais procedimentos podem incluir reparo de arquivo base em difusão ponto a ponto - que permite que os receptores localizem e carreguem as partes restantes de um arquivo através de difusão ponto a ponto a partir do nó BMSC 504. Os procedimentos adicionais podem ser implementados para o relato de recepção, de acordo com o que, um operador de rede ou uma entidade de gerenciamento de rede podem coletar os relatos de QoE e determinar as medições de qualidade da sessão conforme possa ser necessário.

[0083] Em um exemplo de implementação da arquitetura da rede LTE 500, a lógica de serviço apropriada em execução em MBMS-GW 506 pode ser configurada para prover uma funcionalidade da porta de comunicação entre as partes da rede de rádio e de serviço. Em um arranjo, a MBMS-GW 506 encaminha os fluxos contínuos do nó BMSC 504 para todos os eNBs que participam da transmissão em SFN ou da transmissão em PTM. A difusão seletiva por IP é usada na interface Ml entre a porta de comunicação e os eNBs, de forma que a função da replicação de pacote dos roteadores existentes possa ser usada eficientemente. O nó da porta de comunicação 506 pode ser adicionalmente configurado para rotar a sinalização de controle de sessão de MBMS para uma ou mais MMEs 508 que servem a área 552. As MMEs 508 por sua vez, replicam, filtram e encaminham as mensagens do controle de sessão para os eNBs 556 que participam da sessão de difusão específica. Em um arranjo, os eNBs 556 podem ficar operativos para prover a funcionalidade para a configuração das áreas de SFN, bem como os dados de usuário MBMS de difusão e a sinalização de controle relacionada a MBMS na

Petição 870200002271, de 06/01/2020, pág. 72/144 / 103 interface de rádio para todos os dispositivos. Os versados na técnica irão reconhecer que, em um arranjo como este, um nó eNB pode ser provido com a função da Entidade de Coordenação Multicélula (MCE) 3GPP.

[0084] A figura 6 representa uma arquitetura eMBMS de exemplo 600 que ilustra várias interfaces que podem ser realizadas na rede LTE 500 da figura 5 com os propósitos de uma modalidade da presente invenção. Como diversos dos nós ou elementos representados na figura 6 são idênticos aos nós ou elementos da figura 5 apresentada anteriormente com detalhes, sua descrição detalhada não será aqui repetida. Uma interface ou um caminho de rede HTTP CTE 612 são providos entre CSN/nó codificador ao vivo 502 (que contém um segmentador/empacotador como 402/403 na figura 4A ou um nó 302 na figura 3) e BMSC 504 para efetuar as operações de carregamento de mídia de baixa latência da forma descrita previamente. A SGW 604 e a PGW 602 são separadamente mostradas nesta arquitetura exemplar, em que a SGW 604 fica operativa para rotar e encaminhar pacotes de dados de usuário, ao mesmo tempo em que também age como uma âncora de mobilidade para o plano do usuário durante as transferências inter-eNB, bem como a âncora para a mobilidade entre LTE e outras tecnologias 3GPP (quando providas). Para os UEs em estado ocioso, a SGW 604 termina o caminho de dados em enlace descendente e dispara a radios sinalização quando os dados em enlace descendente chegarem para o UE. A lógica de serviço apropriada em execução na SGW 604 fica adicionalmente operativa para gerenciar e armazenar o contexto do UE, por exemplo, os parâmetros do serviço da portadora IP, a informação de roteamento interno da rede, etc. A PGW 602 fica operativa para prover a conectividade de um dispositivo UE (por exemplo, o UE 558) na rede de dados em pacotes externa (PDNs) por ser o ponto de saída e entrada de tráfego para o UE. Um UE pode ter conectividade simultânea com mais do que uma PGW para acessar uma ou mais PDNs (por exemplo, a PDN 614). A lógica de serviço apropriada em execução na PGW

Petição 870200002271, de 06/01/2020, pág. 73/144 / 103

602 fica adicionalmente operativa para realizar cumprimento de política, filtragem de pacotes para cada usuário, suporte a cobrança, interceptação legal e triagem de pacote, etc. Dependendo da implementação, a PGW 602 pode ser adicionalmente configurada para agir como a âncora para a mobilidade entre as tecnologias 3GPP e não 3GPP, tais como as redes WiMAX e 3GPP2 (por exemplo, CDMA IX e EvDO). Enquanto que os nós de rede adicionais, tais como, por exemplo, o servidor de assinante doméstico (HSS), a função de descoberta e seleção da rede de acesso (ANDSF), a porta de comunicação de dados de pacote evoluída (ePDG), etc. não são mostrados na arquitetura eMBMS 600 da figura 6, deve ser percebido que tais nós ou elementos também podem ser incluídos em um exemplo do arranjo de rede, dependendo de uma implementação da infraestrutura do operador em particular.

[0085] Em uma modalidade, o UE 558 pode ser configurado como uma estação terminal habilitada a eMBMS, que pode incluir adicionalmente a funcionalidade do receptor de difusão seletiva por IP e/ou a funcionalidade do receptor HTTP CTE com os propósitos de uma modalidade da presente invenção. Uma interface HTTP 606 também pode ficar disposta entre UE 558 e BMSC 604. Dependendo das aplicações em execução no UE 558, uma interface de aplicação 610 pode ficar disposta entre o UE 558 e um ou mais servidores de aplicação 608. Um exemplo da plataforma do dispositivo UE 704 é ilustrado na figura 7 em relação a um ambiente da rede de banda larga móvel 700. Uma rede de difusão/difusão ponto a ponto LTE 702 é representativa de pelo menos uma parte das arquiteturas de rede 500, 600 aqui descritas anteriormente, que fica disposta entre o BMSC 504 e o UE 558. Em um arranjo, a plataforma do dispositivo UE 704 pode compreender um módulo de nível inferior 710 que incorpora as camadas de rádio LTE, que pode ser implementado em um conjunto de chips para suportar a difusão ponto a ponto, bem como a difusão. Um bloco ou módulo de software mediador 708 fica operativo para tratar um protocolo de difusão seletiva por

Petição 870200002271, de 06/01/2020, pág. 74/144 / 103

IP adequado (por exemplo, FLUTE em uma modalidade em particular descrita com detalhes adicionais a seguir), decodificação AL-FEC, reparo de arquivo em difusão ponto a ponto, funções de controle de transporte (incluindo agendamento de serviço), bem como um cache para o processamento de arquivo/fragmento pós-difusão. Dependendo da implementação, um bloco ou módulo nível superior 706 podem ser providos para facilitar uma ou mais interfaces de programação de aplicação (APIs) da plataforma em relação ao software mediador 708 e aos métodos de camada de conectividade, de acordo com o que, kits de desenvolvimento de software (SDKs) e entidades de transferência de aplicação 712 adequados podem ser interfaceados para desenvolvimento, teste e criação de aplicações habilitadas a eMBMS. Desta maneira, um exemplo de dispositivo UE pode compreender não apenas os telefones inteligentes e os tablets, mas, também, várias plataformas embutidas configuradas para comunicações M2M.

[0086] Da forma apontada previamente, e adicionalmente descrita com detalhes a seguir, um cenário de distribuição de vídeo ao vivo/arquivo em um exemplo de rede LTE com capacidade eMBMS utiliza FLUTE para difusão seletiva por IP a partir de um nó de serviço, tal como o nó BMSC 504. A transmissão contínua ao vivo em uma arquitetura eMBMS pode ser provida a fim de suportar os serviços para a difusão de vídeo e áudio em tempo real, enquanto que a distribuição de arquivo sob solicitação habilita os serviços, tais como descarregamento de difusão ponto a ponto (por exemplo, submissão a cache em dispositivo local), atualização de software e carregamento de arquivo M2M. Deve ser percebido que, de fato, quaisquer arquivo ou sequência de arquivos arbitrários podem ser distribuídos através de uma arquitetura eMBMS, cujos arquivos ou fragmentos podem ser carregados para um nó cabeça da árvore de distribuição por difusão, por exemplo, BMSC 504, usando distribuição HTTP CTE de baixa latência ou outros mecanismos. Em algumas implementações, uma área de difusão alvo para casos de uso

Petição 870200002271, de 06/01/2020, pág. 75/144

70/103 exemplares pode ter qualquer tamanho desejado - alguns cenários podem exigir uma pequena área de difusão, tais como um local ou um centro de compras, e outros casos exigem áreas muito maiores, até mesmo em cobertura nacional. Quando a Transmissão Contínua Adaptativa HTTP (HAS) (por exemplo, HLS, MPEG-DASH, HDS, HSS, CMAF, etc.) for utilizada em uma aplicação de vídeo ao vivo, uma arquitetura eMBMS de exemplo pode ser vantajosamente configurada para interoperar com o mesmo codificador ao vivo e clientes em comum para ofertas de difusão ponto a ponto e difusão. O protocolo IETF FLUTE (apresentado em RFC 3926, aqui incorporado pela referência) pode ser empregado em uma modalidade de exemplo que permite a distribuição de arquivos através de múltiplos enlaces unidirecionais usando UDP. Em um arranjo que envolve FLUTE, uma arquitetura de distribuição aninhada/hierárquica para as sessões eMBMS pode ser usada, em que a duração de uma sessão de distribuição pode abarcar uma ou mais sessões eMBMS. Em um arranjo, a difusão pode ficar ativa pela íntegra da sessão eMBMS, durante a qual os UEs podem receber o conteúdo.

[0087] No geral, as seguintes fases de um provisionamento de serviço de difusão seletiva eMBMS podem ser implementadas: (i) assinatura, (ii) anúncio do serviço, (iii) associação, (iv) início da sessão, (v) notificação de MBMS, (vi) transferência de dados, (vii) término da sessão, e (viii) saída. As fases de assinatura, associação, e saída podem ser realizadas individualmente por usuário. O resto das fases pode ser realizado com base em serviço por serviço, isto é, para todos os usuários interessados em um serviço em particular. A sequência de fases pode repetir, por exemplo, dependendo da necessidade de transferência dos dados. Adicionalmente, assinatura, associação, saída, anúncio do serviço, bem como notificação de MBMS, podem executar em paralelo a outras fases. Em um modo do serviço de difusão, as seguintes fases podem ser providas: (i) anúncio do serviço, (ii) início da sessão, (iii) notificação de MBMS, (iv) transferência de dados, e (v)

Petição 870200002271, de 06/01/2020, pág. 76/144

71/103 término da sessão. Como no modo de difusão seletiva, a sequência de fases no modo de difusão também pode repetir, por exemplo, dependendo da necessidade de transferência dos dados. Também é possível que as fases de anúncio do serviço e de notificação de MBMS possam executar em paralelo com outras fases, por exemplo, a fim de informar os UEs que ainda não receberam o serviço de difusão de mídia em particular.

[0088] O relacionamento entre as sessões de distribuição e as sessões eMBMS em um exemplo do cenário de agendamento de sessão 800 é mostrado na figura 8, em que uma sessão de distribuição FLUTE 802 abarca múltiplas sessões eMBMS 806, 808. O anúncio do serviço 804 pode ser usado para informar os dispositivos sobre as sessões de distribuição 802, bem como as sessões eMBMS 806, 808, por exemplo, pelo uso de uma descrição de agenda, de acordo com o que, os dispositivos UE não precisam monitorar a interface de rádio para as sessões eMBMS continuamente. No cenário ilustrado 800 da figura 8, a descrição de agenda instrui o UE a esperar uma sessão eMBMS entre certas faixas ou janelas de tempo, por exemplo, entre T2 e T3 e entre Tô e T7, em relação aos respectivos tempos de referência Ti e T5. Antes de o UE esperar uma sessão eMBMS 806, o mesmo é preferivelmente configurado para já ficar ativo na interface de rádio (isto é, Τι < T2). Quando se trata de serviços de distribuição de arquivo, é preferido que os dispositivos devam buscar por sessões antes do tempo de transmissão esperado no rádio, para garantir que os mesmos não percam o início de uma transmissão. Deve ser percebido que o cenário de exemplo 800 da figura 8 pode representar um serviço, tal como transferência de uma aplicação que permite que os usuários ativem, recebam e interajam com a difusão usando os serviços de difusão ponto a ponto a partir de um telefone, tablet ou televisão. A partir do ponto de vista do usuário e do software mediador do UE, as duas difusões 806, 808 pertencem ao mesmo serviço de usuário MBMS, que apresenta uma oferta completa que inclui ativação e desativação.

Petição 870200002271, de 06/01/2020, pág. 77/144

72/103

[0089] Para facilitar a descrição das modalidades que envolvem a distribuição FLUTE aglomerada para a difusão LTE, uma breve seção em FLUTE é apresentada imediatamente a seguir.

[0090] Em FLUTE, uma Tabela de Distribuição de Arquivo (FDT) é provida como um meio para descrever vários atributos associados com os arquivos que devem ser distribuídos em uma sessão de distribuição de arquivo. Como um mecanismo de base de dados, a FDT pode conter um mapeamento entre os Identificadores do Objeto de Transporte (TOI) (similar à identificação dos Objetos de Transporte NORM descrita previamente) e os metadados do arquivo, tais como o nome do arquivo, o local de conteúdo (por exemplo, URL/URI), o Tipo do arquivo, o tamanho do arquivo, o ID da Instância FEC, etc. O TOI é um valor integral, estampado em cada pacote UDP, que pertence ao arquivo. Um receptor/cliente pode ser configurado para determinar a associação dos pacotes IP/UDP com qualquer dado arquivo com base no valor do TOI. A partir do tamanho do arquivo, que é tipicamente provido com as instâncias FLUTE FDT para o cliente, o cliente pode derivar o número de pacotes UDP esperados para o arquivo com um valor do TOI específico. Um número de sequência (por exemplo, representado como o ID do Símbolo de Codificação e o Número do Bloco Fonte) permite que o cliente remonte o arquivo corretamente a partir de uma sequência de cargas úteis de pacote IP/UDP. A numeração em sequência dos pacotes também pode ser usada para a detecção da perda de pacote.

[0091] Em um arranjo, uma rede com base em FLUTE pode ser configurada para suportar a transmissão independente das instâncias FDT e os reais objetos de transporte FLUTE (da forma identificada pelo TOI). As instâncias FDT podem ser configuradas para prover um ou mais entradas de arquivo (que também contêm a associação de TOI para este arquivo) para o receptor. FLUTE não exige que o emissor envie os reais objetos de transporte FLUTE em combinação com as instâncias FDT. Em um exemplo da

Petição 870200002271, de 06/01/2020, pág. 78/144 / 103 implementação MBMS LTE, uma consideração implícita para as entradas de arquivo pode ser que uma instância FDT com a entrada de arquivo seja recebida antes de quaisquer dados do real objeto de transporte serem recebidos. Assim, considera-se que o cliente já tem os metadados do arquivo (tais como o nome do arquivo e o tamanho do arquivo) antes de o primeiro pacote com o TOI ser recebido. Em uma implementação de exemplo adicional, a informação da instância FDT para um arquivo pode ser combinada com o real objeto de transmissão, em que pode ser o caso que tem os metadados necessários, tais como nome do arquivo, tamanho do arquivo e tipo do conteúdo para cada objeto de transporte, similar ao protocolo IETF FCAST (RFC 6968), aqui incorporado pela referência. Em um arranjo adicional (por exemplo, em conformidade com a especificação MBMS API apresentada em 3GPP TS 26.347, aqui incorporada pela referência), qualquer arquivo recebido por meio de FLUTE em uma portadora MBMS pode ser oferecido por meio de HTTP para aplicações clientes para recuperação. De acordo com uma modalidade, portanto, um receptor/cliente MBMS pode ser configurado para receber um arquivo completo (por exemplo, um segmento de mídia DASH) e tornar o arquivo disponível em um servidor HTTP local. Os reais URLs do arquivo (que podem incluir os nomes do arquivo da distribuição FLUTE) podem ser tanto notificados através da API quanto descritos em um arquivo de metadados separado, tal como um arquivo da Descrição de Apresentação da Mídia (MPD) DASH.

[0092] Para suportar distribuição aglomerada em baixa latência em um ambiente eMBMS LTE com base em FLUTE, as modalidades aqui expostas proveem as extensões e modificações apropriadas para as instâncias FDT FLUTE para facilitar a transmissão dos objetos de transporte FLUTE como arquivos parciais (por exemplo, para os aglomerados HTTP de um único arquivo, fragmento ou segmento). Em uma implementação, uma extensão da instância FDT pode incluir a identificação sequencial dos objetos

Petição 870200002271, de 06/01/2020, pág. 79/144 / 103 de transporte FLUTE que se responsabiliza pela sinalização de um “indicador de último aglomerado”. Adicionalmente, uma entidade com base em FLUTE de acordo com uma modalidade da presente invenção pode ser configurada para transmitir o arquivo parcial assim que o mesmo for recebido e não esperar para montar todos os arquivos parciais (por exemplo, não há exigência de que apenas arquivos completos sejam transmitidos). Em um arranjo ainda adicional, como a ingestão de mídia toma-se com base em fragmento, uma entidade BMSC (operativa como um emissor FLUTE) pode ser configurada para analisar sintaticamente o fluxo contínuo de aglomerado HTTP de chegada a fim de encontrar os limites do fragmento. Em uma outra modalidade, a entidade fonte de conteúdo (por exemplo, um nó segmentador/empacotador) pode ser configurada para se comprometer a sempre colocar um fragmento no mesmo número fixo de aglomerados HTTP (por exemplo, o segmentador se compromete a enviar cada fragmento com dois aglomerados HTTP). Em relação ao tratamento das perdas nos objetos e/ou aglomerados de transporte, uma modalidade de exemplo pode envolver a aplicação de FEC ou Reparo de Arquivo em um arquivo parcial. Quando o arquivo parcial não puder ser reparado, uma modalidade de exemplo pode ser configurada para garantir que os arquivos parciais subsequentes sejam recebíveis, em que um objeto de transporte FLUTE pode ser configurado como uma sequência de um ou mais pacotes UDP, todos associados com o mesmo objeto por meio de um relacionamento de mapeamento de TOI.

[0093] Da forma previamente notada, uma modalidade do processo de segmentação e fragmentação de segmento da presente invenção envolve gerar os fragmentos relativamente curtos construídos a partir dos quadros (por exemplo, um GOP subdividido em dois ou mais fragmentos) para facilitar a ingestão de mídia de baixa latência. Em relação à sinalização dos fragmentos de baixa latência em um ambiente DASH, uma opção pode ser com base no uso da informação do Deslocamento do Tempo de Disponibilidade (ASTO)

Petição 870200002271, de 06/01/2020, pág. 80/144 / 103 proveniente de DASH MPD. Em um outro arranjo, um parâmetro chamado SegmentTimeline pode ser usado para sinalizar a disponibilidade do segmento para cada fragmento individual. Em um cenário de exemplo, considere cada segmento contendo o valor de 1 segundo de dados de mídia. Considerando que o conteúdo é codificado em 30 quadros por segundo (fps) e o segmentador/empacotador é configurado para empacotar 5 quadros em um fragmento, cada segmento contém 30/5 = 6 fragmentos em que cada fragmento contém 5 quadros = valor de 166,67 ms de dados de mídia (dado por 5 quadros / 30 fps). O segmentador anexa os fragmentos no segmento até que todos os fragmentos (neste caso, 6) do segmento sejam recebidos. Assim, para construir um segmento de 1 segundo, o segmentador anexa mais 5 fragmentos depois que o fragmento inicial foi gravado. No lado do cliente, o reprodutor DASH pode ser configurado para iniciar a reprodução do “primeiro” fragmento (em oposição a esperar que até todos os 6 cheguem) pela utilização do parâmetro @availabilityTimeOffset (ASTO) sinalizado em DASH MPD. Isto informa ao cliente quanto antes o cliente pode começar a “localização e carregamento”, se comparado com seu tempo de início de disponibilidade computado para todos os Segmentos de toda Representação associada. Neste cenário de exemplo, o parâmetro ASTO pode ser definido igual a 833,4 ms, o que indica para o reprodutor que a primeiro parte do segmento (isto é, o primeiro fragmento) fica disponível 833,34 ms antes da última parte do segmento (a partir da perspectiva do reprodutor). Desta maneira, o cliente pode ser configurado para emitir uma solicitação HTTP GET para o segmento 833,34 ms antes do tempo de início de disponibilidade do segmento (calculado a partir do MPD). Adicionalmente, o segmentador/empacotador pode ser configurado para empurrar todos os fragmentos subsequentes para o cliente usando a distribuição aglomerada por HTTP, uma vez que o primeiro fragmento foi solicitado usando HTTP GET. Neste arranjo, o cliente, portanto, emite uma solicitação HTTP GET e cada

Petição 870200002271, de 06/01/2020, pág. 81/144 / 103 segundo e o segmentador empurra os dados quando disponíveis (por exemplo, em um cenário de distribuição/entrega push-pull híbrido, que pode ser assíncrono). Como tal, o segmentador/empacotador não sabe o tamanho do segmento antes de o último fragmento do segmento ser criado e, portanto, não pode sinalizar o tamanho do conteúdo no cabeçalho HTTP no início.

[0094] Em um outro arranjo, o segmentador/empacotador pode ser configurado de maneira tal que cada segmento contenha apenas um único fragmento, em que o segmentador/empacotador notifica a disponibilidade do segmento do cliente de cada segmento/fragmento individual. Já que cada segmento contém apenas um fragmento, o servidor sabe o tamanho do segmento, uma vez que o fragmento está disponível. Considerando uma configuração de segmentação similar, da forma apresentada anteriormente (isto é, o conteúdo é codificado em 30 fps e o segmentador coloca 5 quadros em cada fragmento), o segmentador cria um novo segmento com 166,67 ms. Em virtude de o cliente dever emitir uma solicitação HTTP GET a cada 166,67 ms, seis tais solicitações são necessárias para obter o valor de 1 segundo de dados de mídia, em vez de uma solicitação HTTP GET no arranjo prévio. Desta maneira, deve ser percebido que, embora uma rede de distribuição com base em FLUTE ou NORM que envolve este arranjo de subsegmentação possa ser implementada em uma modalidade, isto exigiría um alto número de transações HTTP GET para distribuição de conteúdo, desse modo, potencialmente impactando o desempenho da rede.

[0095] Em uma modalidade de exemplo atualmente preferida da presente invenção, portanto, a quantidade de sobreprocessamento no nível de HTTP (por exemplo, URLs e cabeçalhos HTTP) pode ser reduzida significativamente, já que o dispositivo receptor/cliente é configurado para receber uma sequência de fragmentos linearmente através do duto HTTP com menor número de transações GET, mesmo para tamanhos de segmento relativamente grandes. Da forma notada anteriormente, as modalidades aqui

Petição 870200002271, de 06/01/2020, pág. 82/144 / 103 expostas envolvem estender/modificar o protocolo de difusão seletiva por IP (por exemplo, FLUTE, FCAST, etc.) para suportar a distribuição aglomerada por HTTP, de forma que cada aglomerado HTTP possa ser empacotado como um objeto de transporte individual em FLUTE/FCAST. Em um arranjo, a funcionalidade FLUTE/FCAST pode ser colocalizada com o segmentador, de maneira tal que um novo objeto de transporte seja gerado com cada novo fragmento com base nos mecanismos e comunicações de transferência de dados interna. Em um outro arranjo, o segmentador pode ser configurado para usar as sessões HTTP CTE no lado da ingestão para o carregamento para um nó BMSC, que pode ser configurado de acordo com os preceitos da presente invenção para analisar sintaticamente e tratar os aglomerados recebidos para determinar os limites do fragmento.

[0096] Amplamente, em um arranjo, as instâncias FDT FLUTE são estendidas com a informação relacionada ao aglomerado HTTP a fim de tirar vantagem de múltiplos fragmentos providos para cada segmento de mídia. Desta maneira, um exemplo do esquema da instância FLUTE FDT é configurado para incluir um parâmetro identificador de aglomerado, de maneira tal que uma instância FDT e/ou a FDT possam conter múltiplas entradas de arquivo com o mesmo URL do arquivo, mas diferentes números de aglomerado ou deslocamentos de aglomerado. Em uma implementação em particular, a instância FDT pode ser estendida com elementos de Início de Aglomerado HTTP (também chamados elemento de deslocamento de aglomerado, da forma notada anteriormente) e elementos de tamanho do aglomerado para cada objeto de transporte que contém um aglomerado HTTP. Altemativamente, o elemento de comprimento do conteúdo pode conter a informação do tamanho do aglomerado quando o elemento de início de aglomerado HTTP estiver presente para um objeto de transporte FLUTE. O início do aglomerado HTTP contém o deslocamento de byte do primeiro byte do aglomerado em relação ao início do arquivo abrangente (por exemplo, em

Petição 870200002271, de 06/01/2020, pág. 83/144 / 103 relação ao primeiro aglomerado do arquivo). A título de ilustração, quando o primeiro aglomerado for de 1.024 bytes, o valor do Início de Aglomerado HTTP para o segundo aglomerado pode ser configurado para ser 1.024. Quando o segundo aglomerado for do tamanho de 100 bytes, o deslocamento de byte do terceiro aglomerado é 1.124, e assim por diante. Os versados na técnica irão perceber que, em um arranjo como este, o valor do Início de Aglomerado HTTP também pode ser configurado para garantir a sequência de aglomerados HTTP, de acordo com o que, o cliente pode derivar a partir do Início de Aglomerado HTTP a posição precisa do aglomerado HTTP no arquivo real. Similar à distribuição HTTP CTE, um aglomerado vazio indica o último aglomerado do corpo HTTP. No caso de FLUTE, o emissor FLUTE apenas envia a instância FDT, que indica o URL do arquivo e o Início de Aglomerado HTTP, mas o Tamanho do Aglomerado é definido em zero. Desta maneira, neste arranjo, o emissor FLUTE não gera nenhum pacotes do objeto de transporte em relação à última sinalização de aglomerado na árvore de distribuição por difusão seletiva por IP. Em uma outra modalidade, o emissor FLUTE envia um objeto de transporte FLUTE de tamanho zero (isto é, somente um pacote FLUTE sem carga útil), quando a instância FDT indicar um Tamanho do Aglomerado de zero (isto é, indicador de último aglomerado).

[0097] Em uma implementação prática da rede com base em FLUTE, pode-se considerar que os objetos de transporte FLUTE individuais podem ficar corrompidos, em que os dados de redundância para correção (por exemplo, FEC) podem ser incapazes de recuperar o aglomerado HTTP. Da forma notada previamente, um exemplo do sistema MBMS LTE (por exemplo, as modalidades apresentadas nas figuras 5-7) pode se basear em mecanismos AL-FEC para aumentar a confiabilidade da transmissão. Desta maneira, durante o envio de aglomerados HTTP em uma modalidade de exemplo da presente invenção, um aglomerado HTTP pode ser configurado

Petição 870200002271, de 06/01/2020, pág. 84/144 / 103 como um bloco fonte de FEC.

[0098] Em um arranjo, um nó BMSC operativo como um emissor FLUTE pode ser configurado para sempre colocar um fragmento completo em um objeto de transporte. A fim de efetuar tal empacotamento, tanto a lógica de serviço apropriada em execução no nó BMSC pode ser configurada para analisar sintaticamente o fluxo contínuo de aglomerado HTTP de chegada para os limites do fragmento quanto o segmentador é configurado para subdividir o fragmento em um número fixo de aglomerados HTTP (por exemplo, dois aglomerados por fragmento, da forma notada anteriormente). Desta maneira, múltiplos aglomerados HTTP podem ser combinados/empacotados em um único novo objeto de transporte aglomerado FLUTE para a distribuição por difusão seletiva. Como a distribuição aglomerada por HTTP exige uma distribuição de transporte e em sequência confiável dos aglomerados HTTP, quando um aglomerado da frente ou no meio do fluxo contínuo de aglomerado for perdido ou corrompido, o receptor pode ser configurado para compensar pela perda, de forma que a sequência da distribuição de aglomerado ainda seja mantida. A fim de suportar um analisador sintático ISOBMFF, uma modalidade do receptor FLUTE da presente descrição pode ser configurada para criar caixas ISOBMFF adequadas, por exemplo, caixas ISOBMFF ‘free’ ou ‘skip’, no fluxo contínuo na direção do cliente. Em alguns casos, o cliente FLUTE pode ser configurado para gerar cabeçalhos de fragmento de filme completos, por exemplo, para sinalizar a duração do fragmento ausente. A fim de suportar este recurso, uma modalidade da instância FLUTE FDT pode ser configurada para conter um parâmetro do tempo de apresentação (por exemplo, Registro de Tempo de Apresentação ou PTS) associado com o fragmento na apresentação, de acordo com o que, o receptor fica operativo para introduzir um fragmento NULO com a duração de apresentação correta no fluxo contínuo. Será aparente aos versados na técnica, mediante a referência ao

Petição 870200002271, de 06/01/2020, pág. 85/144

80/103 presente, que, em uma modalidade de exemplo aqui exposta, o receptor é vantajosamente habilitado a derivar o tamanho do aglomerado e, opcionalmente, alguma informação de fragmento a partir de aglomerados subsequentes.

[0099] Voltando para a figura 9, é na mesma representado um fluxograma da mensagem 900 que representa a ingestão e a distribuição de mídia em uma implementação com base em difusão móvel de acordo com uma modalidade de exemplo. Deve ser percebido que o fluxograma da mensagem 900 é um tanto similar ao fluxograma da mensagem 400A da figura 4A (em relação a uma distribuição por difusão seletiva por IP com base em CDN). Desta maneira, as partes relevantes da descrição da figura 4A também podem ser aplicadas em relação à figura 9, mutatis mutandis, em que um exemplo da implementação de difusão LTE que envolve a distribuição por difusão seletiva com base em FLUTE é provido. Um exemplo da rede fonte 906 inclui um segmentador/empacotador 910 operativo para efetuar uma sessão CTE HTTP com um nó BMSC 909 que pode incluir um componente do servidor HTTP CTE 902 e um componente do emissor FLUTE MC 904, que podem ser arquitetados como uma plataforma de computação distribuída em uma modalidade. Um nó UE móvel 911 fica operativo como um ponto terminal de difusão seletiva que pode incluir um componente do receptor de MC 907 e um componente do servidor HTTP CTE 908. Uma aplicação cliente 912 capaz de distribuição aglomerada por HTTP pode ser provida com um receptor HTTP CTE 914 e um reprodutor/armazenamento temporário de mídia 916. Embora um único nó UE móvel 911 seja exemplificado na figura 9, os versados na técnica irão entender que uma pluralidade de nós UE que tomam parte em um serviço de difusão seletiva com base em assinatura podem ficar dispostos em uma área de difusão LTE, da forma supradescrita em referência a um exemplo de arquitetura LTE mostrado nas figuras 5-7. Adicionalmente, os nós ou elementos intermediários adicionais, tais como

Petição 870200002271, de 06/01/2020, pág. 86/144

81/103 portas de comunicação MBMS, nós eNB, etc. não são especificamente mostrados no fluxograma da mensagem 900 da figura 9.

[00100] Quando a fonte/segmentador 906/910 começar um novo segmento (por exemplo, Segmento n° N), o mesmo pode ser configurado para enviar em uma mensagem inicial 920 que contém cabeçalhos HTTP associados, tais como, por exemplo, tipo de MIME, informação de local do conteúdo (por exemplo, URL do segmento), etc. para o componente do servidor HTTP CTE 902 de BMSC 909. Os versados na técnica irão perceber que Pull HTTP também pode ser usado para a ingestão. Como antes, os cabeçalhos HTTP também incluem uma indicação de codificação de transferência aglomerada HTTP para carregamento/ingestão do segmento. Depois que a fonte/segmentador 906/910 tiver indicado a criação de um novo segmento e tiver provido os cabeçalhos HTTP e o URL do segmento, a fonte/segmentador 906/910 é configurada para coletar todos os dados para um fragmento 918-1. Uma vez que a fonte/segmentador 906/910 tiver criado o fragmento 918-1, a mesma fica operativa para enviar os dados do fragmento 918-1 usando um ou mais aglomerados HTTP. Similar à modalidade da figura 4A, o número de referência 934 refere-se a uma ou mais transmissões de aglomerado usadas para o carregamento dos dados de mídia do fragmento 918-1. Igualmente, os números de referência 946, 954 referem-se a uma pluralidade de transmissões de aglomerado usadas para o carregamento dos dados de mídia do último fragmento 918-N do Segmento n° 1. Em um exemplo da implementação da difusão LTE, o nó BMSC 909 fica operativo para empacotar cada fragmento em um Objeto de Transporte (isto é, o fragmento não é “dividido” através de múltiplos objetos da difusão seletiva por IP). Quando a fonte/segmentador 906/910 prover o fragmento usando múltiplos aglomerados HTTP, o nó BMSC 909 fica, portanto, operativo em uma modalidade para receber todos os aglomerados para um fragmento e empacotar o mesmo em um Objeto de Transporte com um TOI. A fim de

Petição 870200002271, de 06/01/2020, pág. 87/144

82/103 evitar analisar sintaticamente o fluxo contínuo de bytes, o nó BMSC 909 pode ser sinalizado em relação a quantos aglomerados HTTP a fonte/segmentador 906/910 cria para um único fragmento. Tanto um novo cabeçalho HTTP é criado, que é adicionado nos cabeçalhos HTTP de um segmento, quanto o nó BMSC 909 recebe a informação através da configuração de controle, por exemplo, usando inúmeras técnicas previamente apresentadas. Deve ser percebido que o recurso de empacotamento de todos os aglomerados de um fragmento (isto é, um fragmento completo) em um objeto de transporte de difusão seletiva não é necessariamente limitado às modalidades FLUTE, já que o mesmo também pode ser implementado em outros ambientes de difusão seletiva por IP (por exemplo, redes de distribuição por difusão seletiva com base em NORM).

[00101] Continuando em relação à figura 9, os números de referência 922, 934 se referem à propagação de cabeçalhos HTTP (por exemplo, de acordo com uma indicação de novo objeto) através da rede de difusão seletiva/difusão para o UE 911. Igualmente, os números de referência 936, 948, 956 se referem à propagação interna dos aglomerados entre o servidor HTTP 902 e o emissor FLUTE MC 904, que são empacotados em objetos de transporte FLUTE para as transmissões 938, 950, 958, respectivamente, para o componente do receptor de MC 907 do UE 911. Similar ao processamento em um nó de borda da CDN em um ambiente com base em NORM, da forma mostrada na figura 4A, os números de referência 926, 940, 952, 960 se referem ao processamento de cabeçalhos HTTP, armazenamento temporário/transmissão dos dados aglomerados no UE 911. As operações de transferência HTTP entre a aplicação cliente 912 e o componente do servidor HTTP CTE 908 do UE 911 são similarmente ilustradas como solicitação HTTP 928 para um segmento (por exemplo, Segmento n° N), seguido por transmissões de distribuição aglomerada CTE 935 em relação ao fragmento 918-1 e transmissões de distribuição aglomerada 945 em relação ao fragmento

Petição 870200002271, de 06/01/2020, pág. 88/144 / 103 final 918-N. Da forma indicada pelos números de referência 932, os dados de mídia recebidos podem ser providos para o armazenamento temporário do reprodutor de mídia 916 para renderização em um visor adequado.

[00102] Um sinal de último aglomerado 962 pode ser provido para o nó BMSC 909 para sinalizar a demarcação do limite do segmento. Como antes, o nó BMSC 909 fica operativo para somar todos os tamanhos do aglomerado e/ou prover uma indicação de último aglomerado 978 em uma instância FDT para o UE 911. Em resposta, o UE 911 pode prover uma indicação correspondente 949 para o cliente, que pode ser propagada para o reprodutor de mídia da forma indicada pelo sinal 964. Dependendo da configuração do UE/cliente, uma solicitação HTTP 966 para um próximo segmento (por exemplo, o Segmento n° N+l) pode ser com base na recepção do sinal de último aglomerado propagado 964. Em uma outra modalidade de exemplo, o cliente pode ser configurado para gerar as próximas solicitações de segmento 966 em intervalos preconfigurados sem exigir explicitamente um sinal de último aglomerado 964, similar ao fluxo de mensagens com base em NORM mostrado na figura 4A.

[00103] Deve ser percebido que os vários componentes no lado do cliente mostrados na figura 9, por exemplo, o receptor de MC 907, o servidor HTTP 908, o receptor HTTP 914 e o reprodutor/armazenamento temporário 916 podem ser integrados em diferentes arranjos, da forma aqui aludida anteriormente em relação a um exemplo da plataforma do dispositivo com capacidade de eMBMS 704 na figura 7. Por exemplo, quando o reprodutor for configurado para consumir a difusão seletiva por IP diretamente, a funcionalidade do receptor de MC por IP pode ser integrada na funcionalidade do reprodutor. Neste caso, a funcionalidade do reprodutor continua nas operações de arquivo “tipo HTTP”, mas por meio de chamadas API diretas e não chamadas HTTP. Adicionalmente, um cliente eMBMS pode incluir ou estar colocalizado com o receptor de difusão seletiva por IP, em que

Petição 870200002271, de 06/01/2020, pág. 89/144

84/103 uma aplicação pode incluir diretamente o cliente eMBMS, desse modo, evitando usar HTTP para localizar e carregar os arquivos. Desta maneira, deve ser percebido que não é necessário ter as operações de transferência HTTP CTE no lado do cliente em uma modalidade de exemplo. Em um outro arranjo, em vez disto, por exemplo, a API de acesso a arquivo direto pode ser usada em conjunto com a difusão seletiva FLUTE com os propósitos da presente invenção.

[00104] Da forma notada anteriormente, um exemplo do esquema de distribuição por difusão LTE com base em FLUTE envolve associar os objetos de transporte FLUTE com metadados HTTP e segmentar a informação de local (por exemplo, apontadores URL/URI) através das instâncias FDT. Um exemplo do esquema para uma instância FDT configurada para aglomeração HTTP é apresentado a seguir, em que as entradas para um primeiro fragmento de um segmento são ilustradas (note que o elemento Tamanho do Aglomerado é aqui chamado de Comprimento do Aglomerado e o Início de Aglomerado HTTP é aqui chamado de Deslocamento do Aglomerado).

< ?xml version= “1.0” encoding= “UTF-8” ?> <FDT-Instance xmlns= “urn:IETF: metadata :2005:FLUTE:FDT” xmlns:xsi= “http://www.w3.org/2001/XMLSchemainstance ”

FEC-OTI-FEC-Encoding-ID= “1 ” Expires=“331129600”> <File

Content-Type= “video/mp4”

Content-Location= “http://ex.eom/chnl/l 00.m4s ” Chunk-Length = “1024” Chunk-Offset=“0”

Petição 870200002271, de 06/01/2020, pág. 90/144 / 103

TOI=“2”

FEC-OTI-Encoding-Symbol-Length= “16” FEC-OTI-Scheme-Specific-Info= “AAEBBA==“ </File>

[00105] O exemplo exposto ilustra a associação do Objeto de Transporte com ID de Objeto 2 com um URL HTTP. Adicionalmente, um parâmetro Comprimento do Aglomerado é configurado para indicar que a distribuição aglomerada é usada, bem como o tamanho do aglomerado (por exemplo, que pode especificar ou representar o tamanho de um objeto de transporte em bytes).

[00106] Um exemplo de esquema para a instância FDT de um fragmento subsequente (e objeto de transporte) pode ser ilustrado como a seguir. Deve-se notar que o valor do parâmetro Local do Conteúdo é o mesmo URL que em todos os outros fragmentos, que pertencem a este objeto, em que a combinação do parâmetro Local do Conteúdo com o parâmetro Deslocamento do Aglomerado proporciona uma referência exclusiva para um fragmento em particular:

FEC-OTI-FEC-Encoding-ID= “1 ” Expires=“331229600”> <File

Content-Type= “video/mp4”

Content-Location= “http://ex.eom/chnl/l 00.m4s ”

Chunk-Length= “1024”

Chunk-Offset= “2048”

Petição 870200002271, de 06/01/2020, pág. 91/144 / 103

TOI=“4”

FEC-OTI-Encoding-Symbol-Length= “16” FEC-OTI-Schema-Specific-Info= “AAEBBA==“ </File>

[00107] O exemplo exposto da instância FDT é ilustrativo do terceiro fragmento na sequência, em que o primeiro fragmento inicia com o Deslocamento do Aglomerado 0, o segundo fragmento com o Deslocamento do Aglomerado 1.024 e o terceiro com o Deslocamento do Aglomerado 2.048. Em uma modalidade de exemplo, quando o Objeto de Transporte precedente for perdido (por exemplo, em virtude de as perdas de pacote serem muito altas), o objeto de transporte recebido pode ser claramente colocado no segmento abrangente com base em sua posição relativa.

[00108] Com base no exposto, deve ser percebido que várias entidades, tais como segmentos, fragmentos, aglomerados HTTP e objetos de transporte (FLUTE ou NORM), podem ser providas em uma arquitetura em camadas na prática de uma modalidade de exemplo da presente invenção. Por exemplo, um segmento pode compreender múltiplos fragmentos, em que cada fragmento pode ser conduzido por um ou mais aglomerados HTTP, cada aglomerado conduzido por um objeto de transporte. Uma pluralidade de pacotes UDP pode formar um objeto de transporte NORM ou FLUTE. No caso de NORM INFO, as seguintes peças de informação podem ser providas: TOI em cabeçalho de pacote NORM INFOR, URL, indicador de Aglomerado, Tamanho do Aglomerado, e Deslocamento ou Número do Aglomerado. Igualmente, no caso da Instância FLUTE FDT, as seguintes peças de informação podem ser providas: TOI, URL, indicador de Aglomerado, Tamanho do Aglomerado, e Deslocamento ou Número do Aglomerado.

[00109] As figuras 10A-10C são fluxogramas de várias etapas, blocos ou atos que podem ser combinados ou arranjados em uma ou mais

Petição 870200002271, de 06/01/2020, pág. 92/144 / 103 modalidades para facilitar a ingestão e a distribuição de mídia de baixa latência em um exemplo de rede de transmissão contínua com base em difusão seletiva por IP de acordo com os preceitos do presente pedido de patente.

[00110] Em particular, o processo 1000A mostrado na figura 10A é ilustrativo de várias etapas, blocos e/ou atos que podem ser executados por um nó de rede fonte, por exemplo, um empacotador/segmentador de mídia, para facilitar a ingestão de mídia de baixa latência de uma fonte de conteúdo ao vivo. No bloco 1002, uma sessão CTE HTTP pode ser iniciada entre o nó de rede fonte e um nó de ingresso de difusão seletiva por IP (por exemplo, um nó servidor de origem da CDN, um nó do serviço de difusão associado com uma rede de telecomunicações móveis, etc. configurados para suportar uma árvore de distribuição por difusão seletiva, da forma notada anteriormente). Em uma modalidade, o fluxo contínuo de mídia ao vivo é codificado, comprimido e/ou transcodificado em uma pluralidade de representações de taxa de bits. A medida que o fluxo contínuo de mídia ao vivo está sendo recebido, cada uma das correspondentes representações de taxa de bits pode ser sequencialmente segmentada em segmentos (bloco 1004). Cada segmento é fragmentado em um ou mais fragmentos, em que cada fragmento compreende um ou mais quadros de áudio, quadros de vídeo, ou quadros de áudio/vídeo (A/V) dos dados de mídia, ou quadros ISOBMFF (bloco 1006). No bloco 1008, o fluxo contínuo de mídia é identificado ou de outra forma determinado para a distribuição por difusão seletiva por IP e pode ser associado com um grupo de difusão seletiva por IP em particular.

[00111] As etapas, blocos e/ou atos adicionais que podem ser executados em associação com um nó de rede fonte são apresentados como o processo 1000B da figura 10B. Em um arranjo, uma indicação pode ser sinalizada para o nó de ingresso na rede que a difusão seletiva por IP deve ser usada para distribuir os dados de mídia, da forma apresentada no bloco 1020.

Petição 870200002271, de 06/01/2020, pág. 93/144 / 103

Para cada segmento N, as seguintes operações ou atos podem ser realizados pelo nó fonte de uma maneira iterativa, da forma notada no bloco 1022 (por exemplo, enquanto o fluxo contínuo de mídia ao vivo estiver sendo recebido). Um ou mais cabeçalhos HTTP que contêm informação de metadados apropriada podem ser providos para o nó de ingresso de difusão seletiva por IP, por exemplo, antes da, ou no início da, transmissão dos fragmentos do segmento (bloco 1024). A ingestão dos um ou mais fragmentos do segmento no nó de rede de difusão seletiva é começada antes da íntegra dos dados de mídia para o segmento estar disponível, em uma base aglomerado por aglomerado por meio da sessão CTE HTTP, em que um ou mais aglomerados são providos para transmitir cada fragmento (bloco 1026). Um sinal de último aglomerado pode ser provido para o nó de rede de difusão seletiva por IP depois que todos os fragmentos do segmento tiverem sido transmitidos (bloco 1028). Da forma previamente descrita, vários mecanismos de sinalização explícitos ou inerentes podem ser providos em um exemplo de implementação para indicar o término/demarcação do limite de um segmento.

[00112] As etapas, blocos e/ou atos ainda adicionais que podem ser executados em associação com um nó de rede fonte são apresentados como o processo 1000C da figura 10C. Em um arranjo, antes de começar o carregamento/ingestão dos fragmentos, uma indicação pode ser sinalizada para o nó de rede de difusão seletiva por IP para indicar o número de aglomerados providos para transmitir cada fragmento de um segmento de mídia (bloco 1040). Adicionalmente ou altemativamente, uma indicação de protocolo também pode ser sinalizada para o nó de rede de difusão seletiva por IP para indicar que a mídia carregada/ingerida deve ser distribuída usando um protocolo de difusão seletiva por IP em particular para um ou mais receptores de difusão seletiva por IP (bloco 1042). Tal indicação pode ser provida, por exemplo, por um nó empacotador de mídia, como o segmentador/empacotador de cabeça de rede 202, o

Petição 870200002271, de 06/01/2020, pág. 94/144 / 103 segmentador/empacotador fonte 302, ou a fonte/segmentador 402/403, respectivamente 906/910, por exemplo, em uma operação empurrar. A mesma também pode ser provida por um nó de controle separado, por exemplo, em operação puxar.

[00113] As figuras 1 IA e 11B são fluxogramas de várias etapas, blocos ou atos que podem ser combinados ou arranjados em uma ou mais modalidades para facilitar adicionalmente os aspectos de um sistema e um método de ingestão e distribuição de mídia de baixa latência de acordo com os preceitos do presente pedido de patente. Em particular, o processo 1100A mostrado na figura 11A é ilustrativo de várias etapas, blocos e/ou atos que podem ser executados por um nó de rede de difusão seletiva por IP que opera em associação com um nó de rede fonte de conteúdo, por exemplo, um empacotador/segmentador de mídia. No bloco 1102, uma mensagem pode ser recebida a partir do nó empacotador/segmentador de mídia para começar uma sessão CTE HTTP com o nó empacotador de mídia. Em uma modalidade, a mensagem pode incluir uma indicação explícita de que os dados de mídia de um fluxo contínuo de mídia ao vivo serão carregados ou de outra forma providos ou ingeridos para o nó de rede de difusão seletiva por IP através de múltiplas representações de taxa de bits usando distribuição aglomerada. Para cada segmento N do fluxo contínuo de mídia ao vivo, as seguintes operações ou atos podem ser realizados em relação a uma ou mais das representações de taxa de bits, de uma maneira iterativa, da forma notada no bloco 1104 (por exemplo, enquanto o processo de transferência de dados aglomerados continuar para o carregamento dos segmentos de mídia). No bloco 1106, um ou mais cabeçalhos HTTP que contêm várias peças de informação de metadados são recebidos a partir do nó empacotador de mídia. No bloco 1108, um ou mais fragmentos do segmento são recebidos, em uma base aglomerado por aglomerado por meio da sessão CTE HTTP, cada aglomerado tendo uma marca de limite de aglomerado, em que cada fragmento contém um ou mais

Petição 870200002271, de 06/01/2020, pág. 95/144

90/103 quadros de dados de mídia e é recebido antes da íntegra do segmento estar disponível no nó empacotador de mídia. Em uma modalidade de exemplo, um objeto de transporte em difusão seletiva por IP pode ser gerado para cada aglomerado para a transmissão para uma pluralidade de receptores de difusão seletiva em borda (bloco 1110). Um sinal de último aglomerado pode ser recebido a partir do nó empacotador de mídia depois que todos os fragmentos do segmento tiverem sido carregados ou de outra forma ingeridos (bloco 1112).

[00114] As etapas, blocos e/ou atos adicionais que podem ser executados em associação com o nó de rede de difusão seletiva por IP são apresentados como o processo 1100B da figura 11B. Em um arranjo, antes da recepção de um ou mais fragmentos do segmento, pode ser transmitida uma mensagem da informação de difusão seletiva por IP, que inclui os cabeçalhos HTTP e outra informação, para a pluralidade de receptores de difusão seletiva em borda, a mensagem da informação de difusão seletiva por IP incluindo adicionalmente uma indicação de início de novo objeto (bloco 1120). Responsivo a um sinal de último aglomerado, que pode ser explicitamente ou inerentemente sinalizado da forma notada previamente, os tamanhos de todos os aglomerados podem ser adicionados em conjunto para gerar uma indicação de tamanho do objeto associada com o segmento (bloco 1122). Em uma modalidade de exemplo, a indicação de tamanho do objeto pode ser sinalizada para a pluralidade de receptores de difusão seletiva em borda para indicar a demarcação do limite do segmento (bloco 1124).

[00115] A figura 12 é um fluxograma de várias etapas, blocos ou atos que podem ser combinados ou arranjados em uma ou mais modalidades para facilitar adicionalmente os aspectos de um sistema e um método de ingestão e distribuição de mídia de baixa latência implementado em uma rede de telecomunicações de difusão móvel de acordo com os preceitos do presente pedido de patente. O processo 1200 mostrado na figura 12 é particularmente

Petição 870200002271, de 06/01/2020, pág. 96/144 / 103 ilustrativo das várias etapas, blocos e/ou atos que podem ser executados por um nó BMSC de uma rede de telecomunicações móveis LTE que opera em associação com um nó da rede da fonte de conteúdo (CSN), por exemplo, um empacotador/segmentador de mídia. No bloco 1202, um ou mais fragmentos de cada segmento de um fluxo contínuo de mídia segmentado (por exemplo, em múltiplas representações de taxa de bits) são recebidos em uma base aglomerado por aglomerado por meio de uma sessão CTE HTTP a partir do nó CSN, cada aglomerado tendo uma marca de limite de aglomerado, em que um fragmento é recebido antes da íntegra dos dados de um segmento estar disponível no nó CSN. Um objeto FLUTE é gerado para cada fragmento de um segmento para a transmissão para um ou mais dispositivos UE sem fio em uma sessão de difusão, em que o objeto FLUTE é associado com os metadados do segmento através de uma instância da Tabela de Distribuição de Arquivo (FDT) (bloco 1204). Depois que todos os fragmentos para o segmento tiverem sido recebidos, uma indicação de sinal de último aglomerado pode ser provida na instância FDT para a pluralidade dos dispositivos UE sem fio (bloco 1206). Os fragmentos do fluxo contínuo de mídia segmentado podem continuar a ser recebidos por meio do processo de distribuição aglomerada por HTTP enquanto o fluxo contínuo de mídia estiver disponível para difusão ao vivo através da rede de telecomunicações móveis, por exemplo, em um serviço de difusão/difusão seletiva através de uma área de difusão que serve os dispositivos UE sem fio assinantes (bloco 1208).

[00116] A figura 13 é um fluxograma de várias etapas, blocos ou atos que podem ser combinados ou arranjados em uma ou mais modalidades para facilitar ainda adicionalmente os aspectos de um sistema e um método de ingestão e distribuição de mídia de baixa latência de acordo com os preceitos do presente pedido de patente. O processo 1300 mostrado na figura 13 é particularmente ilustrativo de várias etapas, blocos e/ou atos que podem ser executados em um receptor de difusão seletiva por IP, que pode ficar

Petição 870200002271, de 06/01/2020, pág. 97/144

92/103 colocalizado ou de outra forma ser integrado em diferentes níveis em uma árvore de distribuição por difusão seletiva por IP (por exemplo, em uma borda da CDN, um nó de porta de comunicação nas dependências, um STB, um dispositivo UE acessado por ponte ou não acessado por ponte, etc.). Em uma modalidade, uma mensagem da informação de difusão seletiva por IP em relação à distribuição de dados de mídia de um fluxo contínuo de mídia ao vivo pode ser recebida a partir de um emissor de difusão seletiva por IP (bloco 1302). Um ou mais objetos de transporte em difusão seletiva por IP podem, então, ser provenientes do emissor de difusão seletiva por IP, em que cada um dos objetos de transporte em difusão seletiva por IP inclui os pacotes de dados de mídia para um fragmento de um segmento do fluxo contínuo de mídia ao vivo segmentado (bloco 1304). No bloco 1306, os pacotes de dados de mídia podem ser ordenados com base na informação de ID da carga útil sequencial (por exemplo, FEC ID). Com base nos pacotes ordenados, os segmentos e/ou os aglomerados dos dados de mídia podem ser gerados, armazenados e/ou identificados (bloco 1308). Responsivo à recepção de uma solicitação de canal a partir de um dispositivo cliente pelo fluxo contínuo de mídia ao vivo, um ou mais cabeçalhos HTTP podem ser gerados com os metadados apropriados. Adicionalmente, os segmentos podem ser servidos para o dispositivo cliente por meio de uma sessão CTE HTTP em uma base aglomerado por aglomerado para cada segmento (bloco 1310). Da forma notada previamente, dependendo da integração no lado do cliente, uma modalidade alternativa ou adicional pode envolver a API de acesso a arquivo direto, que pode ser usada em vez da transferência/distribuição HTTP CTE com os propósitos da presente invenção.

[00117] A figura 14 representa um diagrama de blocos de um aparelho 1400 que pode ser configurado ou arranjado como diferentes elementos ou nós de rede operativos para ser implementados em um ou mais estágios de uma rede de transmissão contínua em difusão seletiva por IP com os

Petição 870200002271, de 06/01/2020, pág. 98/144 / 103 propósitos de uma ou mais modalidades do presente pedido de patente. Por exemplo, os versados na técnica irão reconhecer que o aparelho 1400 pode ser configurado ou arranjado como um elemento ou subsistema de rede operativo como um nó fonte de conteúdo, ou um nó emissor de difusão seletiva por IP, ou um nó receptor de difusão seletiva por IP para facilitar a ingestão e a distribuição de mídia de baixa latência em um ou mais ambientes de rede de acordo com uma modalidade da presente descrição de patente. Desta maneira, dependendo da implementação e/ou da arquitetura de rede de uma rede de comunicações de mídia, o aparelho 1400 pode ser configurado de diferentes maneiras adequadas para a operação em múltiplos níveis hierárquicos de uma CDN/CSN e/ou rede de difusão móvel, por exemplo, em um super nó de cabeça de rede, nó de cabeça de rede regional, nó de agência centralizadora de vídeo, nó servidor de origem ABR, nó de distribuição central ou regional ou de borda em uma CDN, nó BMSC de uma rede EPC, etc., com base em onde as alimentações da mídia fonte ou outras fontes de conteúdo são injetados em um exemplo de implementação. As interfaces de rede adequadas, por exemplo, I/F 1414-1 a 1414-L, podem, portanto, ser providas para efetuar as comunicações com outros elementos e bases de dados da infraestrutura de rede (por exemplo, alimentações fontes, bases de dados globais para armazenar fragmentos de mídia codificados, arquivos de metadados/manifesto, entidades DRM, etc.). Igualmente, as interfaces 1412-1 a 1412-K para efetuar as sessões de comunicações com um ou mais nós à jusante, por exemplo, emissores/receptores de difusão seletiva por IP, servidores de origem, centros de distribuição regionais, outros elementos de rede intermediários, etc., podem ser providas como parte do aparelho 1400. Um ou mais processadores 1402 podem ser providos como parte de uma arquitetura de computador adequada para prover o controle geral do aparelho 1400, cujo(s) processador(es) 1402 pode(m) ser configurado(s) para executar várias instruções de programa armazenadas em módulos ou blocos de

Petição 870200002271, de 06/01/2020, pág. 99/144

94/103 memória apropriados, por exemplo, a memória persistente 1404, bem como as instruções de programa específicas 1408, incluindo módulos ou blocos adicionais específicos de codificação/transcodificação, segmentação de mídia, geração e/ou conteinerização de fragmento, distribuição aglomerada por HTTP, etc. A título de ilustração, um bloco de codificação/transcodificação ABR 1410 fica operativo para gerar os segmentos de representações de múltiplas taxas de bits de várias mídias fontes, para as quais os arquivos de metadados adequados podem ser gerados por um gerador de manifesto (não especificamente mostrado). Um bloco de multiencriptação 1416 fica operativo para encriptar o conteúdo em uma pluralidade de esquemas de DRM/encriptação, dependendo da implementação. Um bloco de empacotamento de mídia 1406 para empacotamento da mídia em formatos DASH/ISOBMFF/CMAF e/ou MPEG-TS pode ser provido para operação em conjunto com um fragmentador de mídia 1413 para efetuar a fragmentação de segmento em vários níveis de granularidade (por exemplo, construção com base quadro por quadro) com os propósitos de uma ou mais modalidades da presente invenção. Em arranjos adicionais ou alternativos, um módulo de gerenciamento de política de empurrar conteúdo, um módulo de gerenciamento de política de largura de banda e conteúdo, titularidades de programa, etc., coletivamente mostrados como os módulos ou os blocos 1418, também podem ser providos como parte de um nó de gerenciamento ABR de difusão seletiva por IP em retaguarda em um exemplo de arquitetura de rede. Um módulo HTTP CTE 1420 fica operativo para prover as funcionalidades de transmissão/recepção de dados aglomerados em HTTP (dependendo de como qual ponto terminal HTTP CTE o aparelho 1400 é configurado). De maneira similar, um servidor/receptor de difusão seletiva por IP 1422 pode ser incluído em um arranjo ou rearranjo do aparelho 1400 para facilitar as operações de difusão seletiva por IP adaptadas para a distribuição dos fragmentos de baixa latência de acordo com vários protocolos de difusão

Petição 870200002271, de 06/01/2020, pág. 100/144 / 103 seletiva por IP, por exemplo, NORM, FCAST, FLUTE, etc. da forma aqui descrita anteriormente com detalhes. Da forma previamente notada, a funcionalidade do receptor IP pode ser integrada em um nível da porta de comunicação ou até mesmo como um dispositivo UE, dependendo de onde o ponto terminal da difusão seletiva por IP fica disposto. Os versados na técnica irão reconhecer adicionalmente que, em um ambiente de difusão móvel, o aparelho 1400 pode ser implementado como um nó BMSC, com as interfaces adequadas 1414-1 a 1414-L (por exemplo, para outros nós de infraestrutura EPS/EPC, nós CSN, etc.), bem como interfaces adequadas 1412-1 a 1412-K para as portas de comunicação MBMS, etc.

[00118] A figura 15 é um diagrama de blocos de um exemplo de equipamento nas dependências do cliente (CPE) 1500 configurado para realizar vários processos no lado do cliente de acordo com uma ou mais modalidades da presente descrição de patente. O dispositivo CPE 1500 é, no geral, representativo de uma pluralidade de dispositivos UE, por exemplo, STBs NXG, STBs legados, dispositivos de alcance, etc., mostrados em uma ou mais figuras supradescritas, e pode incluir componentes e subsistemas de hardware!software apropriados configurados para realizar qualquer um dos processos no lado do dispositivo (tanto individualmente quanto em qualquer combinação dos mesmos) em relação a acesso a cache local, geração de solicitação de conteúdo, análise sintática de metadados, processamento de solicitação/resposta HTTP CTE ou processamento de API para o consumo direto dos objetos da difusão seletiva por IP, etc., em conjunto com a recuperação e a renderização do segmento/fluxo contínuo de mídia, com os propósitos do presente pedido de patente, dependendo da implementação. Um ou mais microcontroladores/processadores 1502 são providos para o controle geral do dispositivo cliente 1500 e para a execução de várias instruções de programa armazenadas incorporadas em uma memória persistente, por exemplo, como um cliente eMBMS 1513, um receptor CTE 1515 e/ou uma

Petição 870200002271, de 06/01/2020, pág. 101/144 / 103 aplicação cliente de transmissão contínua ABR 1517, etc., que podem ser parte de um subsistema de memória 1511 operativo com um receptor de difusão seletiva por IP 1510 da estação de assinante 1500. O complexo controlador/processador referido pelo número de referência 1502 também pode ser representativo de outros módulos de processamento especializados, tais como processadores gráficos, processadores de vídeo, processadores de sinal digital (DSPs) e congêneres, que operam em associação com interfaces de vídeo e áudio adequadas (não especificamente mostradas). As interfaces apropriadas, tais como os módulos da I/F de rede 1504 e 1506 que envolvem ou operam com sintonizadores, demoduladores, desembaralhadores, decodificadores/demultiplexadores MPEG/H.264/H.265, podem ser incluídas para processamento e interface com a difusão seletiva por IP e outros sinais de conteúdo recebidos por meio de uma rede DSL/CMTS 1598 ou uma rede via satélite 1596. Quando um STB for configurado como um exemplo de dispositivo de ponto terminal, os demoduladores adequados 1517 (por exemplo, pode incluir um demodulador NTSC e/ou um demodulador ATSC/PAL e congêneres) também podem ser incluídos. Um ou mais reprodutores de mídia 1514 podem ser providos para operar em conjunto com os outros subsistemas do dispositivo cliente 1500 para facilitar o controle do usuário através da reprodução de mídia, incluindo as solicitações de mudança de canal. O exemplo dos reprodutores de mídia pode ser configurado para operar com uma ou mais funcionalidades de codificador/decodificador (codec) A/V com base em padrões ou especificações conhecidos ou até aqui desconhecidos, incluindo, mas sem limitações, por exemplo, codecs do Grupo de Especialistas em Figuras em Movimento (MPEG) (MPEG, MPEG-2, MPEG-4, etc.), codec H.264, codec de Codificação de Vídeo em Alta Eficiência ou HEVC (H.265) e congêneres.

[00119] Outras I/O ou interfaces, tais como uma interface de exibição 1515, um Guia Eletrônico de Programas (EPG) 1516 para identificar os canais

Petição 870200002271, de 06/01/2020, pág. 102/144 / 103 de serviço de mídia (por exemplo, em uma implementação de STB), uma interface de tela sensível ao toque ou teclado numérico 1520, as portas USB/HDMI 1518, uma I/F Ethernet 1508, e interfaces de conectividade sem fio de curto alcance e área ampla 1512, também podem ser providas, dependendo da configuração do dispositivo. Uma unidade de disco rígido (HDD) ou sistema DVR (não especificamente mostrados) podem ser incluídos em uma implementação de STB para armazenamento local de vários ativos de programa. Um bloco de suprimento de energia adequado 1522 pode incluir conversão de energia AC/DC para prover energia para o dispositivo 1500. Deve ser percebido que a real arquitetura de energia para o dispositivo de assinante 1500 pode variar pela plataforma de hardware usada, por exemplo, dependendo do SoC (Sistema em Chip) central, da memória, da interface inicial analógica, dos componentes e interfaces da cadeia de sinal analógico usados na plataforma específica e congêneres.

[00120] Com base no exposto, os versados na técnica irão reconhecer que as modalidades da presente invenção podem reduzir significativamente o atraso de transmissão no interior de uma CDN ou uma rede de difusão móvel, embora um protocolo de difusão seletiva por IP confiável seja usado para a distribuição de mídia. Em relação à distribuição de mídia móvel, deve ser percebido que uma modalidade em particular aqui apresentada provê vantajosamente uma solução para introduzir a condução DASH/ISOBMFF em uma implementação de difusão LTE com baixa latência. Os benefícios adicionais da presente invenção neste contexto podem ser realizados em vista do fato de que há uma forte necessidade tanto na mídia quanto na indústria, bem como a partir a perspectiva da segurança pública. Na área da mídia, crescentes cenários de caso de uso podem ser vistos em que um usuário final tem um ponto de referência temporal ou visual - significando que um usuário final percebe a latência como um importante atributo, especialmente, no consumo de mídia ao vivo. Os casos de uso de exemplo são encontrados em

Petição 870200002271, de 06/01/2020, pág. 103/144 / 103 “no estádio”, conteúdo ao vivo autogerado pelo usuário e potenciais casos de uso de realidade virtual/aumentada (VR/AR), em que uma modalidade da distribuição FLUTE aglomerada em uma rede de difusão LTE pode ser vantajosamente implementada. Na arena da segurança pública, exigências de baixa latência similares também estão sendo esperadas em uso crítico para missão da difusão LTE como parte da substituição em banda estreita TETRA, em que casos de uso de vídeo situacional próximo de tempo real são essenciais.

[00121] Os versados na técnica irão reconhecer que vários aparelhos, subsistemas, funcionalidades/aplicações e/ou um ou mais elementos de rede e/ou nós de ponto terminal, bem como as infraestruturas de rede básicas apresentadas anteriormente, podem ser arquitetados em um ambiente virtualizado de acordo com uma arquitetura de virtualização da função de rede (NFV) em modalidades adicionais ou alternativas da presente descrição de patente. Por exemplo, vários recursos físicos, bases de dados, serviços, aplicações e funções que executam em um exemplo da rede do presente pedido, incluindo certas funcionalidades GW/UE/CPE, podem ser providos como utensílios, máquinas ou funções virtuais, em que os recursos e as aplicações são virtualizados em funções de rede virtual (VNFs) ou elementos de rede virtual (VNEs) adequados por meio de uma camada de virtualização adequada. Os recursos que compreendem os recursos de computação, os recursos de memória e os recursos da infraestrutura de rede são virtualizados em correspondentes recursos virtuais, em que os recursos de computação virtual, os recursos de memória virtual e os recursos de rede virtual ficam coletivamente operativos para suportar uma camada de VNF, cuja funcionalidade de gerenciamento e orquestração geral pode ser suportada por um gerenciador de infraestrutura virtualizada (VIM) em conjunto com um gerenciador da VNF e um orquestrador da NFV. Um componente do Sistema de Suporte de Operação (OSS) e/ou do Sistema de Suporte de Negócio (BSS)

Petição 870200002271, de 06/01/2020, pág. 104/144 / 103 pode ser tipicamente provido para tratar as funcionalidades no nível da rede, tais como o gerenciamento da rede, o gerenciamento de falha, o gerenciamento de configuração, o gerenciamento de serviço e o gerenciamento de assinante, etc., que podem fazer interface com os componentes da camada VNF e da orquestração de NFV por meio das interfaces adequadas.

[00122] Além do mais, pelo menos uma parte de um exemplo da arquitetura de rede aqui descrita pode ser virtualizada da forma apresentada anteriormente e arquitetada em um ambiente de computação em nuvem que compreende um agrupamento compartilhado de recursos virtuais configuráveis. Várias peças de hardware!software, por exemplo, codificadores ABR, sistemas e esquemas de encriptação, mecanismos de segmentação e/ou fragmentação, empacotamento/conteinerização de ativo de mídia, bases de dados de segmento/manifesto, funcionalidade de difusão seletiva por IP, etc., bem como plataformas e infraestrutura de NDCs, RDCs, servidores de origem, elementos de rede MABR, podem ser implementados em uma arquitetura orientada a serviço, por exemplo, Software como um Serviço (SaaS), Plataforma como um Serviço (PaaS), Infraestrutura como um Serviço (laaS) etc., com múltiplas entidades provendo diferentes recursos de uma modalidade de exemplo da presente invenção, em que uma ou mais camadas de ambientes virtualizados podem ser instanciadas em hardware pronto para uso (COTS). Os versados na técnica também irão perceber que um ambiente de computação em nuvem como este pode compreender uma ou mais de nuvens privadas, nuvens públicas, nuvens híbridas, nuvens comunitárias, nuvens distribuídas, multinuvens e internuvens (por exemplo, “nuvem de nuvens”) e congêneres.

[00123] Na descrição exposta de várias modalidades da presente descrição, deve-se entender que a terminologia aqui usada é com o propósito de descrever modalidades em particular apenas, e não pretende-se que seja

Petição 870200002271, de 06/01/2020, pág. 105/144

100 / 103 limitante da invenção. A menos que de outra forma definida, todos os termos (incluindo termos técnicos e científicos) aqui usados têm o mesmo significado comumente entendido pelos versados na técnica à qual esta invenção pertence. Será adicionalmente entendido que os termos, tais como aqueles definidos em dicionários comumente usados, devem ser interpretados como tendo um significado que é consistente com seu significado no contexto desta especificação e da relevante tecnologia, e podem não ser interpretados em um sentido idealizado ou excessivamente formal expressamente assim aqui definido.

[00124] Pelo menos algumas modalidades de exemplo são aqui descritas em relação a ilustrações de diagramas de blocos e/ou fluxograma de métodos implementados por computador, aparelhos (sistemas e/ou dispositivos) e/ou produtos de programa de computador. Entende-se que um bloco das ilustrações de diagramas de blocos e/ou fluxograma, e as combinações dos blocos nas ilustrações de diagramas de blocos e/ou fluxograma, podem ser implementados pelas instruções de programa de computador que são realizadas por um ou mais circuitos de computador. Tais instruções de programa de computador podem ser providas para um circuito do processador de um circuito do computador de uso geral, circuito do computador de uso especial e/ou outro circuito de processamento de dados programável para produzir uma máquina, de forma que as instruções, que executam por meio do processador do computador e/ou outro aparelho de processamento de dados programável, transistores de transformação e controle, valores armazenados em locais de memória, e outros componentes de hardware em tais sistema de circuitos implementem as funções/atos especificados no bloco ou blocos dos diagramas de blocos e/ou do fluxograma e, desse modo, crie meio (funcionalidade) e/ou estrutura para implementar as funções/atos especificados no(s) bloco(s) dos diagramas de blocos e/ou do fluxograma. Adicionalmente, as instruções do programa de computador

Petição 870200002271, de 06/01/2020, pág. 106/144

101 / 103 também podem ser armazenadas em uma mídia legível por computador tangível que pode direcionar um computador ou outro aparelho de processamento de dados programável para funcionar de uma maneira em particular, de maneira tal que as instruções armazenadas na mídia legível por computador produzam um artigo de fabricação que inclui as instruções que implementam as funções/atos especificados no bloco ou blocos dos diagramas de blocos e/ou do fluxograma.

[00125] Da forma apontada previamente, a mídia tangível, legível por computador, não transitória pode incluir um sistema, aparelho ou dispositivo de armazenamento de dados eletrônico, magnético, óptico, eletromagnético ou semicondutor. Os exemplos mais específicos da mídia legível por computador irão incluir os seguintes: um disquete de computador portátil, um circuito de memória de acesso aleatório (RAM), um circuito de memória exclusiva de leitura (ROM), um circuito de memória exclusiva de leitura programável apagável (EPROM ou Memória flash), uma memória exclusiva de leitura em disco compacto portátil (CD-ROM), e uma memória exclusiva de leitura em disco de vídeo digital portátil (DVDÁBZw-ray). As instruções de programa de computador também podem ser carregadas sobre ou de outra forma transferidas para um computador e/ou outro aparelho de processamento de dados programável para fazer com que uma série de etapas operacionais seja realizada no computador e/ou outro aparelho programável para produzir um processo implementado por computador. Desta maneira, as modalidades da presente invenção podem ser incorporadas em hardware e/ou em software (incluindo software embarcado, software residente, microcódigo, etc.) que executa em um processador ou um controlador, que pode ser coletivamente referido como “sistema de circuitos”, “um módulo” ou variantes dos mesmos. Adicionalmente, um exemplo da unidade de processamento pode incluir, a título de ilustração, um processador de propósito geral, um processador de propósito especial, um processador convencional, um processador de sinal

Petição 870200002271, de 06/01/2020, pág. 107/144

102 / 103 digital (DSP), uma pluralidade de microprocessadores, um ou mais microprocessadores em associação com um núcleo do DSP, um controlador, um microcontrolador, circuitos integrados específicos de aplicação (ASICs), circuitos de arranjos de porta programáveis no campo (FPGAs), qualquer outro tipo de circuito integrado (IC) e/ou uma máquina de estado. Como pode ser percebido, um exemplo de unidade processadora pode empregar processamento distribuído em certas modalidades.

[00126] Adicionalmente, em pelo menos algumas implementações adicionais ou alternativas, as funções/atos descritos nos blocos podem ocorrer fora da ordem mostrada nos fluxogramas. Por exemplo, dois blocos mostrados em sucessão podem, de fato, ser executados de forma substancialmente concorrente ou os blocos podem, algumas vezes, ser executados na ordem reversa, dependendo da funcionalidade/atos envolvidos. Além do mais, a funcionalidade de um dado bloco dos fluxogramas e/ou dos diagramas de blocos pode ser separada em múltiplos blocos e/ou a funcionalidade de dois ou mais blocos dos fluxogramas e/ou dos diagramas de blocos pode ser pelo menos parcialmente integrada. Além do mais, embora alguns dos diagramas incluam setas nos caminhos de comunicação para mostrar uma direção de comunicação primária, deve-se entender que a comunicação pode ocorrer na direção oposta em relação às setas representadas. Finalmente, outros blocos podem ser adicionados/inseridos entre os blocos que são ilustrados.

[00127] Portanto, deve ser claramente entendido que a ordem ou a sequência dos atos, etapas, funções, componentes ou blocos ilustrados em qualquer um dos fluxogramas representados nas figuras dos desenhos da presente descrição podem ser modificados, alterados, substituídos, customizados ou de outra forma rearranjados em um fluxograma em particular, incluindo a deleção ou a omissão de um ato, uma etapa, uma função, um componente ou um bloco em particular. Além do mais, os atos, as etapas, as funções, os componentes ou os blocos ilustrados em um fluxograma

Petição 870200002271, de 06/01/2020, pág. 108/144

103 / 103 em particular podem ser intermisturados ou de outra forma interarranjados ou rearranjados com os atos, as etapas, as funções, os componentes ou os blocos ilustrados em um outro fluxograma a fim de efetuar as variações, as modificações e as configurações adicionais em relação a um ou mais processos com os propósitos de praticar os preceitos da presente descrição de patente.

[00128] Embora várias modalidades tenham sido mostradas e descritas com detalhes, as reivindicações não são limitadas a nenhuma modalidade ou exemplo em particular. Nada da descrição detalhada exposta deve ser lido como implicando que quaisquer componente, elemento, etapa, ato ou função em particular seja essencial, de maneira tal que o mesmo deva ser incluído no escopo das reivindicações. Não pretende-se que a referência a um elemento no singular signifique “um e apenas um”, a menos que explicitamente assim declarado, mas, em vez disto, “um ou mais”. Todos os equivalentes estruturais e funcionais aos elementos das modalidades supradescritas que são conhecidos pelos versados na técnica são expressamente aqui incorporados pela referência e pretende-se que sejam abrangidos pelas presentes reivindicações. Desta maneira, os versados na técnica irão reconhecer que as modalidades exemplares aqui descritas podem ser praticadas com várias modificações e alterações no espírito e no escopo das seguintes reivindicações anexas.

Claims

1. Método de ingestão de mídia, caracterizado pelo fato de que compreende:

gerar, por um nó empacotador de mídia, um fluxo contínuo de mídia segmentado a partir de um fluxo contínuo de mídia de entrada, em que cada segmento compreende uma pluralidade de fragmentos, cada fragmento compreendendo um ou mais quadros de dados de mídia;

identificar que o fluxo contínuo segmentado deve ser distribuído usando a difusão seletiva por IP e associando o fluxo contínuo segmentado com um grupo de difusão seletiva por IP em particular;

iniciar uma sessão de codificação de transferência aglomerada, CTE, HTTP entre o nó empacotador de mídia e um nó servidor de origem;

para cada segmento N, realizar o seguinte:

começar a ingestão, por meio da sessão CTE, dos fragmentos de um segmento N por meio da sessão CTE HTTP para o nó servidor de origem antes da íntegra dos dados de mídia para o segmento N estar disponível, em que um ou mais aglomerados são providos para transmitir cada fragmento; e enviar um último sinal de aglomerado para o nó servidor de origem depois que todos os fragmentos do segmento N tiverem sido transmitidos.

2. Método de ingestão de mídia de acordo com a reivindicação 1, caracterizado pelo fato de que a ingestão compreende um de um mecanismo push, um mecanismo pull, particularmente um mecanismo pull disparado, ou um mecanismo híbrido, em que a ingestão dos fragmentos é iniciada pelo nó empacotador de mídia quando um mecanismo push for usado e/ou pelo nó servidor de origem quando um mecanismo pull for usado.

3. Método de ingestão de mídia de acordo com qualquer uma das reivindicações 1 ou 2, caracterizado pelo fato de que compreende adicionalmente enviar uma indicação para o nó servidor de origem, antes de começar a ingestão dos fragmentos, para indicar o número de aglomerados

Petição 870200060061, de 14/05/2020, pág. 6/16

2/11 providos para transmitir cada fragmento.

4. Método de ingestão de mídia de acordo com qualquer uma das reivindicações 1 a 6, caracterizado pelo fato de que o fluxo contínuo de mídia ao vivo é codificado como múltiplas representações de taxa de bits adaptativa (ABR), cada representação de ABR sendo segmentada e carregada para o servidor de origem da CDN usando uma correspondente sessão CTE HTTP.

5. Aparelho empacotador de mídia, caracterizado pelo fato de que compreende:

pelo menos uma interface de rede configurada para receber os fluxos contínuos de mídia ao vivo a partir de uma ou mais fontes de conteúdo;

o aparelho empacotador de mídia sendo configurado para

- segmentar um fluxo contínuo de mídia ao vivo recebido em uma pluralidade de segmentos, em que cada segmento compreende uma pluralidade de fragmentos, cada fragmento compreendendo um ou mais quadros de dados de mídia;

- identificar que o fluxo contínuo segmentado deve ser distribuído usando a difusão seletiva por IP e associar o fluxo contínuo segmentado com um grupo de difusão seletiva por IP em particular;

- iniciar uma sessão de codificação de transferência aglomerada, CTE, HTTP com um nó servidor de origem;

- para cada segmento N, começar a ingestão de fragmentos de um segmento N para o nó servidor de origem por meio da sessão CTE antes da íntegra dos dados de mídia para o segmento N estar disponível, em que um ou mais aglomerados são providos para transmitir cada fragmento; e

- enviar um último sinal de aglomerado para o nó servidor de origem depois que todos os fragmentos do segmento N tiverem sido transmitidos.

6. Aparelho empacotador de mídia de acordo com a reivindicação 5, caracterizado pelo fato de que é adicionalmente configurado para incluir as instruções para gerar uma indicação para o nó servidor de

Petição 870200060061, de 14/05/2020, pág. 7/16

3/11 origem, antes de começar a ingestão dos fragmentos, para indicar o número de aglomerados providos para empacotar cada fragmento.

7. Método de distribuição de mídia, caracterizado pelo fato de que compreende:

receber, em um nó servidor de origem, uma mensagem a partir de um nó empacotador de mídia para começar uma sessão de codificação de transferência aglomerada, CTE, HTTP com o nó empacotador de mídia, a mensagem incluindo uma indicação de que os dados de mídia de um fluxo contínuo de mídia ao vivo serão ingeridos para o nó servidor de origem;

para cada segmento N do fluxo contínuo de mídia ao vivo:

- receber um ou mais cabeçalhos HTTP a partir do nó empacotador de mídia;

- receber um ou mais fragmentos do segmento, em uma base aglomerado por aglomerado por meio da sessão CTE HTTP, cada aglomerado tendo uma marca de limite de aglomerado, em que cada fragmento contém um ou mais quadros de dados de mídia e é recebido antes da íntegra dos dados de mídia para o segmento estar disponível no nó empacotador de mídia;

- gerar objetos de transporte, particularmente, objetos de transporte em difusão seletiva por IP, para os aglomerados recebidos e transmitir os objetos de transporte para uma pluralidade de receptores; e

- receber um último sinal de aglomerado a partir do nó empacotador de mídia depois que todos os fragmentos do segmento tiverem sido ingeridos.

8. Método de distribuição de mídia de acordo com a reivindicação 7, caracterizado pelo fato de que um fragmento é recebido em um ou mais aglomerados e cada aglomerado, ou todos os aglomerados que conduzem partes do mesmo fragmento, é/são transmitido(s) como um objeto de transporte para um ou mais da pluralidade de receptores, ou cada aglomerado é distribuído sobre uma pluralidade de objetos de transporte.

9. Método de distribuição de mídia de acordo com qualquer uma das reivindicações 7 ou 8, caracterizado pelo fato de que compreende

Petição 870200060061, de 14/05/2020, pág. 8/16

4/11 adicionalmente transmitir, antes da recepção de um ou mais fragmentos, uma mensagem da informação de difusão seletiva por IP que inclui os um ou mais cabeçalhos HTTP para a pluralidade de receptores, a mensagem da informação de difusão seletiva por IP incluindo adicionalmente uma nova indicação de início do objeto de transporte.

10. Método de distribuição de mídia de acordo com qualquer uma das reivindicações 7 a 9, caracterizado pelo fato de que compreende adicionalmente somar os tamanhos de todos os aglomerados, responsivo ao último sinal de aglomerado, para gerar uma indicação de tamanho do objeto associada com o segmento e sinalizar a indicação de tamanho do objeto para a pluralidade de receptores.

11. Método de distribuição de mídia de acordo com qualquer uma das reivindicações 7 a 10, caracterizado pelo fato de que compreende adicionalmente receber uma indicação de protocolo, por exemplo, a partir do nó empacotador de mídia, antes da recepção dos fragmentos, a indicação de protocolo especificando um protocolo de difusão seletiva por IP em particular, particularmente, pelo menos um do protocolo de Distribuição de Arquivos através de Transporte Unidirecional, FLUTE, do protocolo de Difusão Seletiva Orientada por NACK, NORM, e do protocolo FCAST para distribuir os dados de mídia para a pluralidade de receptores de difusão seletiva em borda, em que o protocolo de difusão seletiva por IP em particular compreende o protocolo NORM e a mensagem da informação de difusão seletiva por IP é gerada como uma mensagem NORM INFO que inclui os um ou mais cabeçalhos HTTP e um apontador de local de conteúdo associado com o segmento, e em que a mensagem NORM INFO é gerada apenas para o primeiro fragmento ou aglomerado do segmento ou a mensagem NORM INFO é transmitida para cada Objeto NORM, em que pelo menos a mensagem NORM INFO associada com um primeiro aglomerado inclui os um ou mais cabeçalhos HTTP, o apontador de local de conteúdo e um tamanho do aglomerado e em que as mensagens NORM INFO associadas com os aglomerados subsequentes do segmento contêm o apontador de local

Petição 870200060061, de 14/05/2020, pág. 9/16

5/11 de conteúdo, o respectivo tamanho do aglomerado e, opcionalmente, um respectivo deslocamento de aglomerado e/ou índice de aglomerado ou a mensagem NORM INFO é transmitida para cada Objeto NORM, em que cada Objeto NORM é ou compreende um aglomerado, e em que a mensagem NORM INFO contém informação de aglomerado, particularmente, um índice de aglomerado e/ou um deslocamento de aglomerado.

12. Método de distribuição de mídia de acordo com qualquer uma das reivindicações 7 a 11, caracterizado pelo fato de que um primeiro aglomerado do segmento é associado com um ID do Objeto de Transporte, TOI, que é incrementalmente aumentado em um para os aglomerados subsequentes do segmento.

13. Método de distribuição de mídia de acordo com qualquer uma das reivindicações 7 a 12, caracterizado pelo fato de que o fluxo contínuo de mídia ao vivo é codificado como múltiplas representações de taxa de bits adaptativa, ABR, cada representação de ABR sendo segmentada e carregada a partir do nó empacotador de mídia usando uma correspondente sessão CTE HTTP.

14. Método de distribuição de mídia de acordo com qualquer uma das reivindicações 8 a 13, caracterizado pelo fato de que compreende gerar um objeto de Distribuição de Arquivos através de Transporte Unidirecional, FLUTE, para cada fragmento de um segmento e transmitir o objeto FLUTE para uma pluralidade de dispositivos UE sem fio em uma sessão de difusão, em que o objeto FLUTE é associado com os metadados do segmento através de uma instância da Tabela de Distribuição de Arquivo, FDT; e depois que todos os fragmentos para o segmento tiverem sido recebidos, prover uma indicação de último sinal de aglomerado na instância FDT para a pluralidade de dispositivos UE sem fio, e em que a instância FDT compreende um campo de Comprimento de Aglomerado configurado para identificar que os dados de mídia dos segmentos são providos em distribuição aglomerado e, particularmente, para indicar um tamanho do objeto FLUTE

Petição 870200060061, de 14/05/2020, pág. 10/16

6/11 em bytes.

15. Servidor de origem, caracterizado pelo fato de que compreende:

um servidor e/ou cliente de codificação de transferência aglomerada, CTE, HTTP; e um emissor de difusão seletiva por IP;

o servidor de origem sendo configurado para realizar as seguintes operações:

receber uma mensagem a partir de um nó empacotador de mídia para começar uma sessão CTE HTTP com o nó empacotador de mídia, a mensagem incluindo uma indicação de que os dados de mídia de um fluxo contínuo de mídia ao vivo segmentado é provido em uma distribuição aglomerado;

para cada segmento N do fluxo contínuo de mídia ao vivo, receber um ou mais cabeçalhos HTTP a partir do nó empacotador de mídia;

receber um ou mais fragmentos do segmento, em uma base aglomerado por aglomerado por meio da sessão CTE HTTP, cada aglomerado tendo uma marca de limite de aglomerado, em que cada fragmento contém um ou mais quadros de dados de mídia e é recebido antes da íntegra dos dados de mídia para o segmento estar disponível no nó empacotador de mídia;

gerar os objetos de transporte, particularmente, os objetos de transporte em difusão seletiva por IP, para os aglomerados recebidos e transmitir os objetos de transporte para uma pluralidade de receptores; e receber um último sinal de aglomerado a partir do nó empacotador de mídia depois que todos os fragmentos do segmento tiverem sido ingeridos.

16. Servidor de origem de acordo com as reivindicação 15, caracterizado pelo fato de que é adicionalmente configurado para transmitir, antes da recepção de um ou mais fragmentos, uma mensagem da informação de difusão seletiva por IP que inclui os um ou mais cabeçalhos HTTP para uma pluralidade de receptores, a mensagem da informação de difusão seletiva

Petição 870200060061, de 14/05/2020, pág. 11/16

7/11 por IP incluindo adicionalmente uma nova indicação de início do objeto de transporte.

17. Servidor de origem de acordo com qualquer uma das reivindicações 15 ou 16, caracterizado pelo fato de que é adicionalmente configurado para adicionar os tamanhos de todos os aglomerados, responsivo ao último sinal de aglomerado, para gerar uma indicação de tamanho do objeto associada com o segmento e sinalizar a indicação de tamanho do objeto para a pluralidade de receptores de difusão seletiva em borda.

18. Servidor de origem de acordo com qualquer uma das reivindicações 15 a 17, caracterizado pelo fato de que é configurado para operar de acordo com um método como definido em qualquer uma das reivindicações 7 a 14.

19. Método de distribuição de mídia, caracterizado pelo fato de que compreende:

receber, em um receptor de difusão seletiva por IP, uma mensagem da informação de difusão seletiva por IP em relação à distribuição de dados de mídia de um fluxo contínuo de mídia ao vivo proveniente de um emissor de difusão seletiva por IP;

receber os objetos de transporte em difusão seletiva por IP a partir do emissor de difusão seletiva por IP, os objetos de transporte em difusão seletiva por IP incluindo os pacotes de dados de mídia;

ordenar os pacotes de dados de mídia com base na informação de ID de carga útil sequencial;

gerar os aglomerados dos dados de mídia com base nos pacotes ordenados, cada aglomerado compreendendo um ou mais quadros de dados de mídia; e responsivo à recepção de uma solicitação de canal a partir de um dispositivo cliente pelo fluxo contínuo de mídia ao vivo, gerar um ou mais cabeçalhos HTTP e servir os aglomerados para o dispositivo cliente por meio de uma sessão de codificação de transferência aglomerada, CTE, HTTP em uma base aglomerado por aglomerado.

Petição 870200060061, de 14/05/2020, pág. 12/16

8/11

20. Método de distribuição de mídia de acordo com a reivindicação 19, caracterizado pelo fato de que os um ou mais cabeçalhos HTTP incluem a informação de local do conteúdo e os um ou mais cabeçalhos HTTP são providos para o dispositivo cliente antes da íntegra dos dados de mídia para um segmento estar disponível.

21. Nó de ponto terminal associado com uma rede de distribuição de difusão seletiva por IP, caracterizado pelo fato de que compreende um receptor de difusão seletiva por IP;

o nó de ponto terminal sendo configurado para realizar as seguintes operações:

receber uma mensagem da informação de difusão seletiva por IP em relação à distribuição de dados de mídia de um fluxo contínuo de mídia ao vivo a partir de um emissor de difusão seletiva por IP;

receber os objetos de transporte em difusão seletiva por IP a partir do emissor de difusão seletiva por IP, os objetos de transmissão da difusão seletiva por IP incluindo os pacotes de dados de mídia;

gerar aglomerados de dados de mídia com base nos pacotes ordenados; e responsivo à recepção de uma solicitação de canal a partir de um cliente pelo fluxo contínuo de mídia ao vivo, servir os aglomerados para o dispositivo cliente.

22. Nó de ponto terminal de acordo com a reivindicação 21, caracterizado pelo fato de que o receptor de difusão seletiva por IP é integrado com um dispositivo tipo equipamento de usuário, UE, sem fio, que compreende:

um servidor ou proxy de codificação de transferência aglomerada, CTE, HTTP;

um cliente do serviço de difusão/difusão seletiva multimídia evoluído, eMBMS, que inclui o receptor de difusão seletiva por IP e um

Petição 870200060061, de 14/05/2020, pág. 13/16

9/11 receptor HTTP CTE;

o dispositivo UE sendo configurado para:

receber, no receptor de difusão seletiva por IP, a mensagem da informação de difusão seletiva por IP a partir de um emissor de difusão seletiva por IP associado com um nó do centro de serviço de difusão seletiva para difusão, BMSC, de uma rede de telecomunicações móveis;

receber, no receptor de difusão seletiva por IP, os objetos de transporte em difusão seletiva por IP como uma pluralidade de objetos de Distribuição de Arquivos através de Transporte Unidirecional, FLUTE, cada qual contendo os pacotes de dados de mídia para um fragmento de um segmento no fluxo contínuo de mídia segmentado;

criar os aglomerados de dados de mídia com base nos pacotes ordenados; e responsivo à recepção de uma solicitação a partir do receptor HTTP CTE, gerar um ou mais cabeçalhos HTTP e servir os fragmentos pelo servidor HTTP CTE por meio de uma sessão CTE HTTP em uma base aglomerado por aglomerado, em que os aglomerados são providos para um armazenamento temporário do reprodutor de mídia para renderização em um visor do dispositivo UE sem fio.

23. Nó de ponto terminal de acordo com a reivindicação 22, caracterizado pelo fato de que os um ou mais cabeçalhos HTTP são enviados juntamente com a informação de local do conteúdo e os um ou mais cabeçalhos HTTP são providos para o cliente eMBMS antes da íntegra dos dados de mídia para um segmento estar disponível.

24. Nó de ponto terminal de acordo com qualquer uma das reivindicações 22 ou 23, caracterizado pelo fato de que o fluxo contínuo de mídia segmentado compreende um fluxo contínuo de Transmissão Contínua Adaptativa Dinâmica sobre HTTP, DASH, e as instruções de programa compreendem adicionalmente as instruções para prover a informação do Deslocamento do Tempo de Disponibilidade, ATO, para o receptor HTTP CTE por meio de um arquivo de descrição de apresentação da mídia, MPD.

Petição 870200060061, de 14/05/2020, pág. 14/16

10/11

25. Nó de ponto terminal de acordo com qualquer uma das reivindicações 22 a 24, caracterizado pelo fato de que o receptor de difusão seletiva por IP é configurado para receber um sinal de indicação de último aglomerado em uma instância da Tabela de Distribuição de Arquivo, FDT, a partir do nó BMSC no final da transmissão de todos os fragmentos para um segmento e as instruções de programa compreendem adicionalmente as instruções para identificar a informação de limite do segmento com base no sinal de indicação de último aglomerado.

26. Rede de transmissão contínua em mídia, caracterizada pelo fato de que compreende:

uma parte da rede de ingestão de mídia configurada para prover o carregamento com baixa latência dos fragmentos de mídia de um fluxo contínuo de mídia ao vivo segmentado usando a codificação de transferência aglomerada, CTE, HTTP, em que um ou mais fragmentos de um segmento são ingeridos em uma base aglomerado por aglomerado antes da íntegra dos dados de mídia do segmento ficar disponível;

uma parte da rede de distribuição em difusão seletiva por Protocolo da Internet, IP, acoplada na parte da rede de ingestão de mídia, a parte da rede de distribuição de difusão seletiva por IP configurada para distribuir os dados de mídia aglomerado para um ou mais destinatários de difusão seletiva por IP usando um protocolo de difusão seletiva por IP; e uma parte da rede de distribuição configurada para distribuir os dados de mídia para um cliente em uma sessão de transferência HTTP CTE com um destinatário de difusão seletiva por IP de serviço, a rede de transmissão contínua em mídia compreendendo pelo menos um de:

- um aparelho empacotador de mídia como definido em qualquer uma das reivindicações 5 ou 6;

- um servidor de origem como definido em qualquer uma das reivindicações 15 a 18;

- um nó de ponto terminal como definido em qualquer uma das

Petição 870200060061, de 14/05/2020, pág. 15/16

11 / 11 reivindicações 21 a 25.