BR102019026713A2

BR102019026713A2 - Método, sistema e dispositivos para distribuição aprimorada de conteúdo de multimídia

Info

Publication number: BR102019026713A2
Application number: BR102019026713-5A
Authority: BR
Inventors: Jorge Hernández Pablo; Jorge HERNÁNDEZ PABLO; José Cano Hila Francisco; Antoni Silvestre Padrós
Original assignee: Telefonica, S.A.
Priority date: 2018-12-13
Filing date: 2019-12-13
Publication date: 2020-06-23
Also published as: ES2877338T3; EP3668052A1; EP3668052B1

Abstract

"método, sistema e dispositivos para distribuição aprimorada de conteúdo de multimídia a presente invenção se refere a um método, sistema e dispositivos para manter o mesmo servidor durante uma sessão de comunicação de multimídia (por exemplo, vídeo). a solução proposta modifica o nome de domínio adicionando uma âncora, geralmente durante os redirecionamentos de roteamento de solicitação; essa âncora permite que o roteador de solicitação retorne o mesmo endereço de ip do servidor para qualquer resolução de domínio durante uma sessão de vídeo do player, resolvendo os problemas encontrados nas técnicas anteriores

Description

MÉTODO, SISTEMA E DISPOSITIVOS PARA DISTRIBUIÇÃO APRIMORADA DE CONTEÚDO DE MULTIMÍDIA

CAMPO TÉCNICO

[001] A presente invenção se refere à distribuição de conteúdo de multimídia (especialmente vídeo, mas também texto, áudio, software ou qualquer outro conteúdo ou qualquer combinação deles) com o uso, por exemplo, de técnicas de streaming adaptáveis, em redes de comunicações. Mais particularmente, a presente invenção se refere a um método, sistema e dispositivo para aprimorar a distribuição de conteúdo em redes de comunicações, especialmente quando o streaming adaptativo é usado.

ANTECEDENTES DA INVENÇÃO

[002] Serviços como serviços de vídeo sob demanda, serviços de televisão na Internet, transmissão de eventos ao vivo..., nos quais um conteúdo de multimídia é fornecido aos usuários finais em uma sessão de comunicação (por exemplo, com o uso de streaming), estão sendo cada vez mais solicitados. Entre as técnicas de fornecimento de conteúdo, o streaming adaptável é um dos mais usados.

[003] O streaming adaptável, também chamado de fluxo de bitrate adaptativo (ABR, Adaptive Bitrate Streaming), é um mecanismo de distribuição de vídeo amplamente usado por HTTP (Hypertext Transport Protocol, Protocolo de Transporte de Hipertexto). Os provedores de serviços e as operadoras de rede implantam o streaming adaptativo geralmente como um recurso das redes de distribuição de conteúdo (CDNs) para fornecer QoE (qualidade da experiência) ininterrupta para os assinantes (usuários finais) nas redes, mesmo com a largura de banda flutuante. Existem vários protocolos HTTP definidos por grandes players da indústria do setor: HLS (HTTP Live Streaming, streaming ao vivo de HTTP) da Apple, HSS (HTTP Smooth Streaming, streaming suave de HTTP) da Microsoft, HDS (HTTP Dynamic Streaming, streaming dinâmico de HTTP) da Adobe, DASH (Dynamic Adaptive Streaming HTTP, streaming adaptativo dinâmico de HTTP) da MPEG... e eles compartilham o mesmo conceito básico de distribuição por HTTP e adaptação do streaming para as condições de reprodução. No lado do servidor, um servidor de conteúdo (por exemplo, um servidor de vídeo) distribui um manifesto ou lista de reprodução que define um conjunto de fluxos de taxa de bits, cada um composto por vários fragmentos, que o servidor de vídeo também distribui. No lado do cliente, um player de vídeo (geralmente um dispositivo eletrônico de usuário final) inicia a reprodução solicitando o manifesto ou a lista de reprodução, e solicitando sequencialmente os fragmentos necessários para renderizar o vídeo. O fragmento solicitado corresponde à taxa de bits que melhor se ajusta às condições de download e ao tempo de visualização.

[004] O player de vídeo geralmente baixa alguns fragmentos para preencher um buffer interno, para que o mesmo possa renderizar os fragmentos de vídeo já baixados enquanto a reprodução do vídeo está avançando. Caso o tempo para reproduzir um fragmento aumente (por exemplo, erros de rede, mobilidade do usuário, saturação do cliente ...), o tempo para fazer o download e renderizar um fragmento pode ser maior que o tempo de visualização desse fragmento. Nesse caso, o buffer interno diminui e o player de vídeo deve solicitar fragmentos de taxas de bits mais baixas (pior qualidade), cujo tamanho é menor e o tempo de download e renderização é menor. Posteriormente, o tempo de download pode melhorar e a taxa de bits solicitada pelo cliente é mais alta novamente, para reproduzir fragmentos de melhor qualidade.

[005] A distribuição explicada de manifestos e fragmentos geralmente é feita com mensagens de solicitação e respostas de HTTP, devido ao amplo suporte desse protocolo em praticamente qualquer dispositivo de consumidor. No entanto, o HTTP é um protocolo sem estado, portanto, cada solicitação é gerenciada independentemente das solicitações anteriores e isso não é um problema quando o mesmo servidor distribui as solicitações ao cliente de HTTP. Ou seja, o streaming adaptável distribui fragmentos de vídeo sequencialmente para os players de vídeo e, para evitar a abertura contínua de uma nova conexão, o mesmo servidor deve distribuir todos os fragmentos para cada único player (por exemplo, dispositivos do usuário final). No entanto, a distribuição de um streaming de vídeo em escala (por exemplo, com mecanismos de balanceamento de carga) geralmente não é feita pelo mesmo servidor para qualquer cliente simultâneo. Os principais motivos são as características do serviço de vídeo: a carga útil da distribuição é alta em comparação com o conteúdo da Web, má experiência do usuário na visualização de vídeo quando o conteúdo está atrasado, solicitações simultâneas do usuário para o mesmo conteúdo (por exemplo, eventos de TV).

[006] Por exemplo, vários players no mercado resolvem continuamente o domínio do URL (Uniform Resource Locator, Localizador de Recurso Uniforme) durante a sessão de vídeo e, nesses casos, se a resolução do domínio mudar (por exemplo, para ativar o balanceamento de carga com outro servidor), o player fecha a conexão e abra uma nova com outro servidor.

[007] A mudança de servidor durante a sessão de vídeo implica em abrir uma nova conexão e tem outras consequências indesejadas, especialmente quando o servidor está próximo ao ponto de saturação. Por exemplo, quando um streamer (um servidor de vídeo) informa que está cheio de capacidade (próximo ao ponto de saturação), o roteador de solicitação para de retornar o endereço de IP (Internet Protocol, Protocolo de Internet) na resolução do domínio. Em seguida, vários usuários finais já conectados a esse streamer são desconectados e conectados a novos streamers, provocando um efeito de avalanche. Essa avalanche foi responsável por um tempo de resposta mais longo, que poderia resultar no recarregamento (rebuffering) do player, piorando a experiência do usuário na visualização de um conteúdo de vídeo ou canal de TV.

[008] Para evitar esses efeitos indesejados, na medida do possível, o mesmo servidor deve distribuir todos os fragmentos para cada player (mesmo em cenários de saturação do servidor, o servidor não deve ser elegível para novas sessões de vídeo, mas seu IP ainda deve ser retornado para sessões de vídeo em andamento).

[009] Já existem algumas soluções conhecidas da técnica anterior para conseguir que o mesmo servidor distribua (o máximo possível) todos os fragmentos para cada único player durante uma sessão de vídeo (também chamada de roteamento fixo).

[0010] Por exemplo, a patente US8239445 obtém esse roteamento persistente por um mecanismo que modifica o caminho do URL, adicionando uma marca (um cookie), identificando univocamente o usuário e, quando o usuário solicita um conteúdo, o balanceador de carga reconhece a marca e envia o solicitações para o mesmo servidor.

[0011] Outras soluções da técnica anterior (como a usada por Akamai ou a divulgada na patente US8868756) propõem o uso de cookies (chamados de "cookies de aderência") para manter a sessão de vídeo sempre com o mesmo servidor. E, por exemplo, a Cisco obtém o roteamento persistente armazenando para cada usuário único que é o IP do servidor resolvido e, para as próximas solicitações de resolução de DNS, eles usam essas informações para retornar o mesmo IP do servidor.

[0012] Os mecanismos descritos na técnica anterior exigem que a solicitação seja roteada no nível de HTTP, até mesmo fixando o IP do servidor em um redirecionamento. Além disso, as soluções da técnica anterior implicam várias outras deficiências:

[0013] Os mecanismos de "cookies de aderência" exigem que os players aceitem o uso de cookies e retornem para as seguintes solicitações o mesmo cookie retornado anteriormente. A aceitação e o uso de cookies pode não ser compatível com alguns dispositivos com players ad hoc (por exemplo, set-top boxes) ou podem exigir a aceitação explícita do usuário. A presente invenção não utiliza cookies e baseia-se apenas na modificação do nome de domínio do URL com um redirecionamento de HTTP. Os redirecionamentos fazem parte da RFP HTTP, portanto, qualquer cliente de HTTP padrão oferece suporte.

[0014] O mecanismo usado por Cisco precisa armazenar e usar um mapa completo de usuários e servidores de IP, o que dificulta a escala da resolução entre os roteadores de solicitação distribuídos ou o tempo de resposta para uma resolução rápida.

[0015] A modificação do URL conforme proposto em US8239445 implicaria alterar o conteúdo do manifesto/lista de reprodução para adicionar a âncora à declaração de URLs dos fragmentos, tornando o conjunto mais complexo e lento. Além disso, o mecanismo proposto no US8239445 também implica o uso de cookies que, como afirmado anteriormente, limitam significativamente os players onde eles podem ser aplicados, porque alguns dispositivos não suportam cookies (por exemplo, ao usar o Smooth Streaming, a maioria dos players não suporta o uso de cookies).

[0016] Portanto, é necessário um mecanismo de roteamento aderente aprimorado para superar as limitações das soluções existentes da técnica anterior.

SUMÁRIO

[0017] Os problemas encontrados nas técnicas anteriores são geralmente resolvidos ou contornados, e as vantagens técnicas são geralmente alcançadas pelas modalidades divulgadas que fornecem um método, sistema e dispositivos para manter o mesmo streamer (servidor) durante uma sessão de vídeo. A solução proposta modifica o nome de domínio adicionando uma âncora ao URL, geralmente durante os redirecionamentos de roteamento de solicitação; essa âncora permite que o roteador de solicitação retorne o mesmo endereço de IP do servidor para qualquer resolução de domínio durante uma sessão de vídeo do player.

[0018] Na invenção proposta, o roteamento de solicitação usa um mecanismo de roteamento de Sistema de Nomes de Domínio (DNS) para conectar o player a um servidor com o uso de uma âncora, por isso é diferente do mecanismo da técnica anterior em que a solicitação é roteada no nível de HTTP, mesmo corrigindo o IP do servidor em um redirecionamento. A invenção proposta possibilita não definir o IP no redirecionamento e permite o balanceamento para um servidor diferente nos casos em que o servidor está realmente indisponível. Além disso, a invenção proposta não usa cookies para manter o servidor (evitando os problemas mencionados na técnica anterior em relação ao uso de cookies), mas baseia-se apenas na modificação do nome de domínio do URL com um redirecionamento de HTTP. Os redirecionamentos fazem parte da RFP HTTP (solicitação de proposta de HTTP), portanto, qualquer cliente de HTTP padrão oferece suporte. Além disso, a invenção proposta (ao contrário da técnica anterior da CISCO mencionada) não precisa armazenar esse tipo de mapas e não precisa compartilhar informações entre roteadores diferentes, mesmo em locais diferentes.

[0019] Consequentemente, algumas das principais vantagens do mecanismo proposto são:

[0020] Ele possibilita o uso de um mecanismo de roteamento de solicitação baseado em DNS.

[0021] É independente dos players, pois a resolução do domínio é implementada nas camadas da Internet de qualquer dispositivo.

[0022] Como ele não usa cookies, não força os players a suportar esse mecanismo (cookies).

[0023] Na presente invenção, o caminho do URL não é alterado (mas apenas o nome de domínio), o que implica um melhor desempenho, especialmente em protocolos de vídeo usando fragmentos criados a partir de um manifesto. A modificação do caminho do URL (conforme proposto no documento US8239445) implicaria em alterar o conteúdo do manifesto/lista de reprodução para adicionar a âncora à declaração de URLs dos fragmentos.

[0024] Na presente invenção, a âncora não identifica o usuário (ao contrário da solução proposta em US8239445), o que facilita o dimensionamento da solução.

[0025] Em um primeiro aspecto, é proposto um método para a distribuição aprimorada de conteúdo de multimídia para equipamentos de usuário final (em uma rede de distribuição de conteúdo que compreende vários servidores). A distribuição será feita através de uma ou mais redes de comunicação com o uso de qualquer técnica de distribuição, por exemplo, uma técnica de streaming e, mais especificamente, uma técnica de streaming adaptável. O método compreende:

- Um primeiro servidor (um servidor ideal) que recebe uma primeira mensagem (por exemplo, uma mensagem de HTTP e mais especificamente uma mensagem de GET) de um equipamento de usuário final, a mensagem uma incluindo um URL que inclui um primeiro nome de domínio (nome de host);
- Após receber a dita primeira mensagem, o primeiro servidor determina se o dito primeiro nome de domínio inclui um identificador de um servidor da rede de distribuição de conteúdo, chamado identificador de âncora e, caso contrário, o primeiro servidor envia de volta ao equipamento de usuário final uma mensagem de redirecionamento, incluindo um segundo nome de domínio no URL, sendo o dito segundo nome de domínio o resultado da adição ao primeiro nome de domínio de um identificador de âncora que identifica o primeiro servidor (ou seja, o servidor adiciona um identificador de si mesmo no nome de domínio como um identificador de âncora, se o nome de domínio ainda não incluir um identificador de âncora do primeiro servidor ou de outro servidor);

em que, quando um dispositivo de sistema de Nome de Domínio, DNS, da rede de distribuição de conteúdo recebe uma solicitação de resolução de nome de domínio (do equipamento de usuário final) para um nome de domínio incluindo o dito identificador de âncora, o dispositivo de DNS (por exemplo, um roteador) envia de volta (para o equipamento de usuário) uma mensagem respondendo à solicitação de resolução de nome de domínio, incluindo o endereço de IP do primeiro servidor, independentemente do nível de congestionamento do dito servidor, desde que o primeiro servidor esteja disponível (o servidor não está baixado e, consequentemente, está disponível para distribuição de um conteúdo). Em outras palavras, ou seja, o dispositivo de DNS determina se o dito primeiro servidor está disponível e, em caso afirmativo, sempre envia de volta o endereço de IP do dito primeiro servidor identificado pelo identificador de âncora, mesmo quando o servidor está congestionado.

[0026] O equipamento de usuário final pode ser um telefone celular, um tablet, um smartphone, um computador, um PC, um laptop ou qualquer dispositivo eletrônico capaz de receber conteúdo de multimídia através da rede de comunicação.

[0027] Em uma modalidade, as mensagens são mensagens de HTTP.

[0028] Em uma modalidade, o primeiro nome de domínio é um nome de domínio redirecionado, que é um nome de domínio já redirecionado por outro servidor (não um nome de host de solicitação original).

[0029] A primeira mensagem pode ser uma mensagem solicitando um manifesto para uma sessão de streaming de conteúdo de multimídia ou um fragmento do conteúdo de multimídia e em que, se o dito primeiro nome de domínio já incluir um identificador de um servidor da rede de distribuição de conteúdo, o primeiro servidor envia o manifesto ou fragmento solicitado para o equipamento de usuário final.

[0030] Em uma modalidade, o primeiro nome de domínio é um nome de domínio de solicitação original (que é uma CDN canônica ou um nome de domínio do cliente). Nesta modalidade, um aprimoramento de roteamento de solicitação pode ser permitido no primeiro servidor. Em outra modalidade, o primeiro nome de domínio não é um nome de domínio de solicitação original.

[0031] Em uma modalidade, o dispositivo de DNS é um roteador (por exemplo, um roteador de solicitação de uma rede de distribuição de conteúdo).

[0032] Em uma modalidade, o primeiro nome de domínio pertence a um grupo de domínios específicos para os quais a adição de um identificador de âncora é permitida, (ou seja, o redirecionamento de âncora é permitido apenas para um grupo específico de nomes de domínio, não para qualquer nome de domínio).

[0033] Em uma modalidade, o conteúdo de multimídia é conteúdo de vídeo.

[0034] Em um segundo aspecto, é proposto um servidor para a distribuição aprimorada de conteúdo de multimídia (por exemplo, streaming adaptável) para equipamentos de usuário final em uma rede de distribuição de conteúdo, o servidor compreendendo:

- Um receptor para receber, através da rede de distribuição de conteúdo, uma primeira mensagem (HTTP) de um equipamento de usuário final (da rede de distribuição de conteúdo), a mensagem incluindo um URL incluindo um primeiro nome de domínio (redirecionado);
- Um transmissor para transmitir mensagens através da rede de distribuição de conteúdo;

sendo o servidor caracterizado por compreender um processador configurado para:

- Após receber a dita primeira mensagem, determinar se o dito primeiro nome de domínio inclui um identificador de um servidor da rede de distribuição de conteúdo, chamado identificador de âncora e, caso contrário, enviar de volta ao equipamento de usuário final com o uso do transmissor, uma mensagem de redirecionamento, incluindo um segundo nome de domínio no URL, sendo o dito segundo nome de domínio o resultado da adição ao primeiro nome de domínio de um identificador de âncora que identifica o servidor.

[0035] Em um terceiro aspecto, é proposto um dispositivo de DNS (por exemplo, um roteador) para a distribuição aprimorada de conteúdo de multimídia para equipamentos de usuário final em uma rede de distribuição de conteúdo compreendendo vários servidores, sendo o dispositivo caracterizado por compreender:

- Um receptor para receber (de um equipamento de usuário final), através da rede de distribuição de conteúdo, uma solicitação de resolução de nome de domínio para um nome de domínio;
- Um transmissor para transmitir mensagens através da rede de distribuição de conteúdo;

sendo o dispositivo caracterizado por compreender um processador configurado para:

- Determinar se o dito nome de domínio inclui um identificador de âncora que identifica um servidor; em caso afirmativo, determinar se o dito servidor identificado pelo identificador de âncora está disponível e se o dito nome de domínio incluir um identificador de âncora que identifica um servidor e o servidor estiver disponível, enviar de volta com o uso do transmissor, uma mensagem respondendo à solicitação de resolução de nome de domínio, incluindo um endereço de IP do servidor identificado pelo identificador de âncora, independentemente do nível de congestionamento do dito servidor.

[0036] Em um quarto aspecto, é fornecido um sistema para a distribuição aprimorada de conteúdo de multimídia para equipamentos de usuário final em uma rede de distribuição de conteúdo, o sistema compreendendo:

- Um servidor que compreende:
- Um receptor para receber, através da rede de distribuição de conteúdo, uma primeira mensagem de um equipamento de usuário final, a mensagem incluindo um URL incluindo um primeiro nome de domínio (redirecionado);
- Um transmissor para transmitir mensagens através da rede de distribuição de conteúdo;
- Um dispositivo de DNS que compreende:
- Um receptor para receber, através da rede de distribuição de conteúdo, uma solicitação de resolução de nome de domínio para um nome de domínio;
- Um transmissor para transmitir mensagens através da rede de distribuição de conteúdo;

sendo o sistema caracterizado por:

- o servidor que compreende um processador configurado para, após receber a dita primeira mensagem, determinar se o dito primeiro nome de domínio inclui um identificador de um servidor da rede de distribuição de conteúdo, chamado identificador de âncora e, caso contrário, enviar de volta ao equipamento de usuário final com o uso de seu transmissor, uma mensagem de redirecionamento incluindo um segundo nome de domínio no URL, que é o resultado da adição ao primeiro nome de domínio de um identificador de âncora que identifica o servidor;
- o dispositivo de DNS que compreende um processador configurado para: determinar se o dito nome de domínio incluído na mensagem de solicitação de resolução de domínio inclui um identificador de âncora que identifica um servidor e se o dito nome de domínio incluir um identificador de âncora que identifica um servidor e o servidor estiver disponível, enviar de volta com o uso de seu transmissor, uma mensagem respondendo à solicitação de resolução de nome de domínio, incluindo um endereço de IP do servidor identificado pelo identificador de âncora, independentemente do nível de congestionamento do dito servidor.

[0037] Um último aspecto da invenção se refere a um produto de programa de computador compreendendo um código de programa de computador adaptado para executar o método da invenção, quando o dito código de programa é executado em um computador, um processador de sinal digital, uma matriz de portas programável em campo, um circuito integrado específico para aplicativo, um microprocessador, um microcontrolador ou qualquer outra forma de hardware programável. Um meio de armazenamento de dados digitais não transitório também é fornecido para armazenar um programa de computador que compreende instruções que fazem com que um computador que executa o programa realiza o método descrito acima.

BREVE DESCRIÇÃO DOS DESENHOS

[0038] Para completar a descrição que está sendo feita e com o objetivo de ajudar a uma melhor compreensão das características da invenção, de acordo com um exemplo preferido de modalidade prática da mesma, acompanhando a dita descrição como parte integrante da mesma, está um conjunto de desenhos em que, a título ilustrativo e não restritivo, o seguinte foi representado:

[0039] A Figura 1 mostra um diagrama esquemático das principais transações de uma sessão de streaming de vídeo em uma Rede de Distribuição de Conteúdo de acordo com um primeiro cenário da técnica anterior.

[0040] A Figura 2 mostra um diagrama esquemático das principais transações de uma sessão de streaming de vídeo em uma Rede de Distribuição de Conteúdo de acordo com um segundo cenário da técnica anterior.

[0041] As Figuras 3a, 3b e 3c mostram um diagrama esquemático das principais transações de uma sessão de streaming de vídeo de acordo com uma modalidade da invenção.

[0042] A Figura 4 mostra o número de players de HLS conectados a um servidor de CDN específico durante um evento de futebol ao vivo, ao aplicar a solução proposta de acordo com uma modalidade da invenção.

[0043] Nas Figuras, números de referência semelhantes se referem a elementos semelhantes.

DESCRIÇÃO DAS MODALIDADES

[0044] A presente invenção pode ser incorporada em outros dispositivos, sistemas e/ou métodos específicos. As modalidades descritas devem ser consideradas em todos os aspectos como apenas ilustrativas e não restritivas. Em particular, o escopo da invenção é indicado pelas reivindicações anexas, e não pela descrição e Figuras deste documento. Todas as mudanças que estão dentro do significado e alcance da equivalência das reivindicações devem ser abrangidas por seu escopo.

[0045] Os provedores de serviços e os operadores de rede usam cada vez mais a distribuição de conteúdo (e, mais especificamente, o streaming adaptável), para fornecer conteúdo de multimídia (por exemplo, vídeo) aos usuários finais através de redes de comunicação. As redes de comunicação podem ser redes de comunicação móvel (2G, 3G, 4G, LTE...) ou qualquer outro tipo ou redes de comunicação com ou sem fio. As Redes de Distribuição de Conteúdo (CDNs) são frequentemente usadas para dimensionar a distribuição de conteúdo em uma ou mais redes de comunicação e são muito úteis para transmissão de vídeo. Esse tipo de rede geralmente aproveita o mecanismo de DNS e HTTP para distribuir o conteúdo ao cliente de maneira transparente, endereçando a solicitação de usuário final a servidores ideais, dependendo de diferentes critérios, como a carga dos servidores, a topologia de rede, a disponibilidade do conteúdo... Os mecanismos para rotear essas solicitações dependem da tecnologia e implementação de cada CDN, mas geralmente são baseados em recursos de HTTP e DNS (Sistema de Nomes Dinâmicos), como redirecionamentos, cabeçalhos, cookies, CNAMEs (Nome Canônico)... Como qualquer solicitação de manifesto (definindo um conjunto de fluxos de taxa de bits) ou fragmento por HTTP é baixada com uma solicitação diferente, o mecanismo de roteamento de solicitação de uma CDN pode rotear todas as solicitações para diferentes servidores de CDN. Como explicado anteriormente, essa situação não é desejável da perspectiva de CDN (pior desempenho) e da experiência do usuário (novas conexões levam mais tempo para baixar).

[0046] Existem duas abordagens principais para evitá-lo:
Lado do cliente: Alguns players de vídeo (por exemplo, equipamentos de usuários finais) estão cientes do conceito de “sessão” de vídeo (no sentido de que agora as solicitações pertencem à mesma sessão de vídeo, ou seja, ao mesmo fluxo de conteúdo) e, assim que o primeiro manifesto é roteado para um servidor ideal, a conexão de HTTP é estabelecida e o manifesto é baixado; as solicitações dos fragmentos futuros são feitas no mesmo servidor enquanto o mesmo responde adequadamente às solicitações.
Lado de CDN: O conceito de “sessão” de vídeo é gerenciado internamente pela CDN, para que todas as solicitações para o mesmo conteúdo do mesmo usuário final sejam roteadas para o mesmo servidor enquanto esse servidor ainda é ideal para a distribuição dessa sessão.
No presente documento, uma sessão de conteúdo (por exemplo, uma sessão de vídeo) é definida como uma série de transações relacionadas para executar uma unidade de trabalho (para transmitir um conteúdo específico para um usuário final específico)

[0047] Atualmente, existem vários players, players do tipo A, (players de vídeo se o conteúdo distribuído incluir vídeo) implementando a abordagem do lado do cliente e, uma vez que a solicitação de processo de roteamento retorne o servidor ideal, o manifesto e os fragmentos de ABR serão solicitados ao mesmo servidor. Isso é mostrado na figura 1, em que o player (usuário final, 11) envia uma solicitação para resolver o host (resolução de domínio) para um nó (12) da rede (geralmente um roteador, chamado roteador de solicitação de CDN), este nó (após uma solicitação de processo de roteamento) informa ao usuário final que o servidor ideal é um determinado servidor (servidor n, 13) e, em seguida, o player solicita o manifesto e todos os fragmentos do conteúdo de vídeo ao mesmo servidor, como mostra a Figura 1. No presente documento, usaremos igualmente os termos player, player de vídeo ou equipamento de usuário final (ou simplificando “usuário final”) para nos referirmos ao mesmo conceito, o dispositivo eletrônico usado pelo usuário final para solicitar e reproduzir o streaming de vídeo. O dito dispositivo eletrônico pode ser um telefone celular, um tablet, um smartphone, um computador, um PC, um laptop ou um dispositivo eletrônico de fala geral que pode se comunicar através de uma rede de comunicação.

[0048] No entanto, outros players, players do tipo B, repetem algumas das etapas dos mecanismos de roteamento de solicitação, como resolver novamente o domínio ou solicitação redirecionada com o domínio original, durante uma única sessão de vídeo. Para esse segundo grupo de players, o ponto de extremidade ideal (o servidor ideal) retornado pela CDN pode ser diferente em algumas circunstâncias, sempre que os players solicitam a resolução do domínio. Isso é mostrado na figura 2, em que o player (usuário final, 21) envia uma solicitação para resolver o host/domínio (em outras palavras, para saber para qual nó ou servidor ele deve se endereçar para receber os fragmentos e/ou manifesto de conteúdo de vídeo) para um roteador de solicitação de CDN (22) da rede, este nó (após uma solicitação de processo de roteamento) informa ao player que o servidor ideal é um determinado servidor (servidor n, 23); o player solicita o manifesto para esse servidor. Depois que o player recebe o manifesto, ele repete o processo de "resolver o host" e, desta vez, o roteador 22 informa ao player que o servidor ideal (por exemplo, devido a uma alteração nas condições de tráfego devido ao balanceamento de carga) é agora outro servidor (servidor m, 24). Em seguida, o player solicita fragmentos do conteúdo de vídeo ao servidor m. Esse processo pode ser repetido e o servidor ideal (para o qual o player solicita os fragmentos de vídeo) pode alterar novamente (como mostrado na figura 2, onde após o fragmento 1, o roteador 22 informa ao player que o servidor ideal é o servidor n 23 novamente) dependendo das circunstâncias específicas.

[0049] Dependendo do roteamento de solicitação da CDN, essas circunstâncias podem variar, para que o servidor ideal retornado pela CDN possa variar durante uma sessão de vídeo (para players do tipo B). Um caso típico é a CDN parar de retornar um servidor específico como ideal quando o número de usuários finais conectados ao servidor atingir seu limite e retornar um servidor diferente. Nesse cenário, o seguinte comportamento foi observado em uma Rede de Distribuição de Conteúdo de um operador de telecomunicações:

[0050] Os players do tipo B mudam para outro servidor (servidor m) quando o primeiro servidor ideal (servidor n) atinge seu limite (saturação).

[0051] O número de usuários no servidor m aumenta para um número de players acima do seu limite, enquanto o número de players conectados ao servidor n diminui, pois os players do tipo B pararam de solicitar a esse servidor.

[0052] O tipo de player B muda novamente para um servidor ideal diferente, que poderia ser o servidor n se o número de players diminuir e estiver novamente abaixo do seu limite.

[0053] O número de usuários no servidor n pode ultrapassar seu limite e a solicitação de processo de roteamento de “pingue pongue” é iniciada novamente.

[0054] Isso foi observado, por exemplo, durante um evento de futebol ao vivo, quando o número de players de HLS conectados a um determinado servidor tinha um perfil sawtooth (mais uma vez e outra vez, passando de aproximadamente 3000 a 4500 players e depois novamente para 3000 players em um período muito curto).

[0055] Portanto, surge um problema sério quando os servidores da CDN estão próximos do ponto de saturação (por exemplo, durante momentos de alta audiência), o que pode afetar a experiência do usuário final (por exemplo, provocando um efeito de avalanche responsável por tempos de resposta mais longos).

[0056] Esses e outros problemas são resolvidos pela solução proposta no presente documento. Na solução proposta, uma âncora é adicionada ao nome de domínio do URL durante os redirecionamentos de roteamento de solicitação (ou seja, o nome de domínio é modificado). O domínio (ou nome de domínio) em uma solicitação de HTTP é um cabeçalho específico também chamado de HOST (é por isso que o nome de domínio também é chamado nome de host). Em uma solicitação de HTTP, o caminho/local do URL é incluído após o nome de domínio. Essa âncora permite que um dispositivo de DNS (por exemplo, um roteador de solicitação) retorne o mesmo IP de servidor para qualquer resolução de domínio durante uma sessão de vídeo do player, embora esse servidor não possa ser elegível para outros novos usuários finais devido ao seu nível de carga. Caso o servidor fique inoperante ou indisponível, a resolução mudará retornando um IP de servidor diferente. Esse mecanismo evita a alteração do servidor durante a sessão de vídeo, o que é especialmente importante quando o servidor está próximo ao ponto de saturação. Nesse ponto, o servidor não deve ser elegível para novas sessões de vídeo, mas seu endereço de IP ainda deve ser retornado para as sessões de vídeo em andamento. A âncora pode ser adicionada como um redirecionamento adicional, mesmo com o servidor ideal, que responderia com esse redirecionamento em vez de começar a distribuir a lista de reprodução/manifesto.

[0057] O roteador de solicitação é o nó em uma CDN responsável por direcionar as solicitações para o servidor ideal. Em uma modalidade preferida da presente invenção, o roteador de solicitação é um dispositivo de DNS que executa a ancoragem alterando o nome de domínio (e também rastreia o estado dos pontos finais ou servidores com o rastreador de DNS). De um modo geral, o nó que realiza essa ancoragem ou aderência será um dispositivo de DNS, já que isso é feito alterando o nome de domínio. O rastreador de DNS é uma parte (um componente) de um dispositivo de DNS encarregado de rastrearos pontos finais para decidir qual é o ideal. Portanto, quando, no presente texto, é mencionado que determinada ação é executada pelo rastreador de DNS, significa que a ação é executada pelo dispositivo de DNS (o dispositivo de DNS, em uma modalidade, sendo o roteador de solicitação de uma CDN).

[0058] As Figuras 3 mostra um diagrama esquemático das principais transações de uma sessão de streaming de vídeo de acordo com uma modalidade da invenção. Como a quantidade de transações era muito alta para ser claramente vista em apenas uma figura, ela foi dividida em três figuras (3a, 3b e 3c), sendo a figura 3b uma continuação (no tempo) da figura 3a e a figura 3c uma continuação da figura 3b. O diagrama inteiro deve ser visto como começando na figura 3a, continuando com a figura 3b e terminando na figura 3c.

[0059] As Figuras 3a, 3b e 3c mostram um exemplo de nós de uma rede em que a presente solução pode ser aplicada, tendo um caráter ilustrativo e não limitativo, de modo que a presente solução possa ser usada em qualquer tipo de rede com tipo, nome e número diferentes de nós que o exemplo mostrado nas figuras 3a, 3b e 3c. Na verdade, nas figuras 3a, 3b e 3c, para fins de simplicidade, apenas alguns nós são mostrados; no entanto, uma rede de distribuição de conteúdo real terá mais nós (mais DNS, pontos finais, equipamentos de usuário...).

[0060] No exemplo mostrado nas figuras 3a, 3b e 3c, há um equipamento de usuário final ou player de vídeo (usuário final 1 31), um nó de DNS de ISP (Internet Service Provider, Provedor de Serviços de Internet) 32, um DNS de TLD (Top Levei Domain, Domínio de Nível Superior) DNS 33, dois nós de DNS adicionais, por exemplo, roteadores de solicitação (DNS R1 34, DNS R2 35) e três pontos finais (EP1 36, EP2 37, EP3 38).

[0061] Os pontos finais podem ser qualquer nó eletrônico (geralmente um servidor) capaz de distribuir (transmitir) o conteúdo de vídeo solicitado ao usuário final. Os nós de DNS podem ser qualquer servidor, roteador... que execute a resolução de domínio. A resolução de nomes de domínio é hierárquica, é por isso que diferentes nós de DNS geralmente estão envolvidos em uma resolução completa de nomes de domínio: primeiro um DNS de ISP que roteia a solicitação de resolução para um TLD (domínios de nível superior como .com, .org...) DNS que direciona a solicitação de resolução para outro DNS... até que o DNS tenha a tradução final do nome de domínio específico para o IP correspondente ao ponto final (EP, end point) ao qual o usuário final deve se endereçar para receber o conteúdo de vídeo.

[0062] Para uma melhor compreensão da solução proposta, serão explicadas aqui as principais etapas do streaming de vídeo de acordo com uma modalidade da invenção em um cenário exemplificador (mostrado nas figuras 3a, 3b e 3c).

[0063] Primeiramente (figura 3a), o equipamento de usuário final (usuário final 1) envia uma mensagem (301) com um nome de domínio (899.cn.telefonica.com) para resolução de nomes de domínio ao DNS de ISP, que solicita (302) um DNS de TLD que informa (303) ao DNS de ISP o endereço de IP do próximo DNS (DNS R1) a ser consultado. O DNS de ISP envia (304) a resolução do domínio para o DNS R1 (que neste exemplo é o que possui a tradução final do nome de domínio específico). O DNS R1 envia ao DNS de ISP (305) os endereços de IP (em ordem aleatória) de dois pontos finais possíveis (EP1 e EP2) na região do usuário final a partir da qual o conteúdo de vídeo solicitado pode ser solicitado. O DNS de ISP envia (306) os ditos endereços de IP dos dois pontos finais para o usuário final 1.

[0064] Em seguida, o usuário final envia uma mensagem "GET" (307) para o primeiro Ponto Final, cujo endereço de IP foi recebido (EP1) para obter o manifesto (lista de reprodução) para o conteúdo de vídeo solicitado. Em seguida, o EP1 faz um redirecionamento regular e envia uma mensagem de redirecionamento (308) com um novo nome de domínio para o usuário final (na mensagem de redirecionamento, o símbolo significa redirecionamento intrarregiões). O usuário final envia (309) uma mensagem de resolução de nome de domínio (para o novo nome de domínio, 899-p14-h33.1.cdn.telefonica.com) para o DNS de ISP que o encaminha (310) para o DNS R1. Este rastreador de DNS aplica um mecanismo regular de seleção de terminais e fornece (311) os endereços de IP dos Pontos Finais mais adequados (dependendo, por exemplo, da carga dos pontos finais ou de qualquer outro fator; nesse caso, ditos pontos finais serão EP2 e EP3) para o DNS de ISP, que os envia (312) em ordem aleatória para o usuário final. O número de Pontos Finais (EPs) fornecidos pelo DNS dependerá de um parâmetro de projeto do sistema (chamado, por exemplo, numIPs) que especifica a quantidade de endereços de IP de Pontos Finais (EPs) retornados pelo DNS. No exemplo mostrado nas figuras 3a, 3b e 3c, “numIPs” = 2 (mas pode ter qualquer valor 1, 2, 3, 4... dependendo do projeto do sistema específico), o que significa que o DNS retornará o endereços de IP dos dois EPs mais adequados.

[0065] Até agora (301-312), todas as etapas explicadas descreviam o mecanismo de roteamento de solicitação regular para selecionar o servidor de vídeo ideal. Agora (313-XXX), será explicado como, para adicionar a aderência ao usuário, a âncora é adicionada ao domínio com um redirecionamento adicional, finalmente o usuário final recebendo a primeira fatia (fragmento) do conteúdo.

[0066] Após receber (312) os endereços de IP dos EPs mais adequados (neste caso, EP2 e EP3), o usuário final envia uma mensagem "GET" (313) para o primeiro Ponto Final, cujo endereço de IP foi recebido (EP3) para obter o manifesto (lista de reprodução) para o conteúdo de vídeo solicitado. Quando o EP3 recebe a dita mensagem "GET" do usuário final, ele aplica um redirecionamento adicional (redirecionamento de âncora) adicionando um parâmetro ou prefixo à âncora (chamado prefixo de âncora, identificador de âncora ou apenas âncora) ao ponto final ao qual o usuário final ficará bloqueado para esta sessão de vídeo (o prefixo de âncora será o identificador do ponto final ou do servidor). Em seguida, o EP3 envia uma mensagem de redirecionamento (314) incluindo a âncora para o usuário final. Como você pode ver na mensagem 314, nesse caso, a âncora adicionada ao nome de domínio é "aXX", que representa o servidor final EP3 (este é apenas um exemplo ilustrativo).

[0067] Como aconteceu anteriormente, quando o usuário final recebe a mensagem de redirecionamento com um novo nome de domínio, o usuário final envia (315) uma mensagem de resolução de nome de domínio (para o nome de domínio incluindo a âncora, neste caso, 899 p14 h33 aXX.1.cdn.telefonica.com) para o DNS de ISP que o encaminha (316) para o DNS apropriado (DNS R1). Nesse caso, o DNS (seu rastreador) não aplica um mecanismo de seleção regular de ponto final, mas identifica o prefixo da âncora no nome de domínio como representando o ponto final da âncora (neste caso, EP3) e, se o dito ponto final estiver disponível, o DNS o seleciona (independentemente de estar congestionado ou não). O DNS responderá a resolução do nome de domínio apenas com o endereço de IP do ponto final identificado pelo prefixo de âncora (neste caso, EP3). O dito endereço de IP será enviado ao DNS de ISP (317) e de lá para o usuário final (318).

[0068] De preferência, o número de servidores nos quais o servidor está preso (ancorado) é um. No entanto, em uma modalidade alternativa, pode ser mais de um ou pode existir um parâmetro de projeto do sistema (chamado, por exemplo, numlPs_stickiness ou numlPs_anchored) que especifica a quantidade de pontos finais (1, 2, 3...) para os quais a sessão de vídeo é bloqueado (e, consequentemente, a quantidade de endereços de IP retorna pelo DNS).

[0069] Após receber (318) o endereço de IP do EP ancorado (neste caso, EP3), o usuário final envia uma mensagem "GET" (319) para o ponto final para obter o manifesto (lista de reprodução) do conteúdo de vídeo solicitado. O EP recebe a dita mensagem “GET” e gerencia a solicitação, independentemente de ser o EP de âncora ou não (como a mensagem de “GET” inclui um nome de domínio com um prefixo de âncora, o ponto final sabe que uma âncora já foi adicionada, portanto, a mensagem não deve ser redirecionada novamente conforme feito anteriormente). Em outras palavras, o EP que recebe um nome de domínio com um prefixo de âncora (identificador de âncora) exibe o conteúdo ou manifesto solicitado, mesmo que o prefixo de âncora não corresponda a esse EP, porque se o dispositivo de DNS retornou esse endereço de IP do ponto final (com um prefixo de âncora que identifica outro EP) é porque o EP identificado pelo prefixo de âncora não estava disponível (caiu); isso é feito para evitar um efeito de pingue-pongue nos redirecionamentos. Portanto, o EP3 retorna o manifesto (320) ao usuário final, o usuário final solicita o primeiro fragmento do conteúdo de vídeo (321) para o EP3 e o ponto final retorna o fragmento (322). A partir de agora, o conteúdo é distribuído continuamente pelo mesmo servidor de vídeo ideal, apesar desse servidor estar saturado (congestionado). Ou seja, mesmo que o player (usuário final) resolva novamente o último nome de host durante a sessão de vídeo, o DNS retornará novamente o mesmo endereço de IP (do ponto final ancorado) e o usuário final solicitará o seguinte fragmento ao mesmo ponto final.

[0070] Isso é mostrado na figura 3b; depois de receber o primeiro fragmento, o usuário final decide resolver novamente o último nome de host. Para isso, o usuário final envia (323) uma mensagem de resolução de nome de domínio (para o nome de domínio incluindo a âncora 899 p14 h33 aXX.1 .cdn.telefonica.com) para o DNS de ISP que o encaminha (324) para o DNS apropriado (DNS R1). Nesse caso, o DNS (seu rastreador) não aplica um mecanismo de seleção regular de ponto final, mas identifica o prefixo da âncora no nome de domínio como representando o ponto final da âncora (neste caso, EP3) e, se o dito ponto final estiver disponível, o DNS o seleciona (independentemente de estar congestionado ou não). O DNS responderá a resolução do nome de domínio apenas com o endereço de IP do ponto final identificado pelo prefixo de âncora, neste caso EP3 (como numlPs-stickiness=1). O dito endereço de IP será enviado ao DNS de ISP (325) e de lá para o usuário final (326). Em seguida, o usuário final usa o endereço de IP retornado para solicitar o segundo fragmento do conteúdo de vídeo (327) para EP3 e o ponto final retorna o fragmento (328).

[0071] No exemplo mostrado na figura 3b, após a distribuição do dito segundo fragmento, o ponto final EP3 fica congestionado (329). No entanto (conforme mostrado na figura 3b), se o usuário final 1 decide resolver novamente o último nome de host, o DNS retornará ao usuário final o endereço de IP do EP3 (se estiver disponível, independentemente de estar congestionado) e o usuário final solicitará o fragmento de vídeo ao EP3 (consulte a figura 3b, etapas 330, 331, 332, 333, 334 e 335), exatamente como aconteceu antes do ponto final do EP3 estar congestionado.

[0072] Portanto, no mecanismo proposto, quando o servidor está congestionado, seu endereço de IP ainda é retornado para sessões de vídeo em andamento (evitando a alteração do servidor durante a sessão de vídeo); no entanto, o servidor congestionado não deve ser elegível para novas sessões de vídeo ou novos usuários finais.

[0073] Isso é mostrado na figura 3c, onde é mostrado que um novo usuário final (usuário final 2, 39) com um player de viscosidade inicia uma sessão de streaming para o mesmo conteúdo e, nesse caso, a partir do mesmo PID (ID da partição de rede). Dependendo do endereço de IP do usuário final, ele pertencerá a um determinado PID (e apenas a um). Graças ao ID de partição de rede, o rastreador de DNS pode atribuir EPs fechados ao usuário final (no nível da rede). Como será explicado agora, esse novo usuário será endereçado a um servidor de vídeo diferente, pois o primeiro (EP3) está saturado para novos usuários.

[0074] O novo equipamento de usuário final (usuário final 2) envia uma mensagem (336) com um nome de domínio (899.cdn.telefonica.com) para resolução de nomes de domínio ao DNS de ISP, que solicita (337) um DNS apropriado (DNS R1) a resolução de domínio para o DNS R1 (que neste exemplo é o que possui a tradução final do nome de domínio específico). O DNS R1 envia ao DNS de ISP (338) os endereços de IP (em ordem aleatória) de dois pontos finais possíveis (EP1 e EP2) na região do usuário final a partir da qual o conteúdo de vídeo solicitado pode ser solicitado. O DNS de ISP envia (339) os ditos endereços de IP dos dois pontos finais para o usuário final 2.

[0075] Em seguida, o usuário final 2 envia uma mensagem "GET" (340) para o primeiro Ponto Final, cujo endereço de IP foi recebido (EP1) para obter o manifesto (lista de reprodução) para o conteúdo de vídeo solicitado. Em seguida, o EP1, como o aprimoramento do roteamento de solicitação é desativado, faz um redirecionamento regular e envia uma mensagem de redirecionamento (341) com um novo nome de domínio para o usuário final. O usuário final envia (342) uma mensagem de resolução de nome de domínio (para o novo nome de domínio 899-p14-h33.1.cdn.telefonica.com) para o DNS de ISP que o encaminha (343) para o DNS R1. O rastreador de DNS R1 aplica um mecanismo regular de seleção de pontos finais para selecionar os pontos finais mais adequados, levando em consideração que o EP3 está congestionado, portanto, o EP3 não será selecionado. O DNS R1 envia (344) os endereços de IP dos ditos EPs selecionados ao DNS de ISP, que os envia (345) em ordem aleatória ao usuário final 2. Como antes, o número de pontos de extremidade (EPs) fornecidos pelo DNS depende de um parâmetro de projeto do sistema (chamado por exemplo numIPs) que especifica a quantidade de endereços de IP de pontos de extremidade (EPs) retornados pelo DNS. No exemplo mostrado nas figuras 3a, 3b e 3c, “numlPs”=2, o que significa que o DNS retornará os endereços de IP dos dois EPs mais adequados.

[0076] Após receber (345) os endereços de IP dos EPs mais adequados (neste caso, EP2 e EP1), o usuário final envia uma mensagem "GET" (346) para o primeiro Ponto Final, cujo endereço de IP foi recebido (EP2) para obter o manifesto (lista de reprodução) para o conteúdo de vídeo solicitado. Quando o EP2 recebe a dita mensagem "GET" do usuário final, ele aplica um redirecionamento adicional (redirecionamento de âncora) adicionando um prefixo à âncora (prefixo de âncora) ao ponto final ao qual o usuário final ficará bloqueado para esta sessão de vídeo (o dito prefixo de âncora será o identificador do ponto final ou do servidor). Em seguida, o EP2 envia uma mensagem de redirecionamento (347) incluindo a âncora para o usuário final. Como você pode ver na mensagem 347, nesse caso, a âncora adicionada ao nome de domínio é "aYY", que representa o servidor final EP2 (este é apenas um exemplo ilustrativo). A partir de agora (como explicado anteriormente no caso do usuário final 1 e EP3, etapas 315-335), a sessão de streaming do usuário final 2 será distribuída de EP2 enquanto estiver disponível mesmo quando o EP2 estiver congestionado.

[0077] O mecanismo acima é implementado no dispositivo de DNS (por exemplo, roteador de solicitação) e no ponto final (servidor de vídeo), como será explicado agora.

[0078]

- No roteador de solicitação (um dispositivo de DNS), o rastreador de DNS retorna o mesmo endereço de IP do servidor de vídeo quando o domínio é bloqueado, independentemente do nível de carga do servidor. Somente quando o servidor não estiver disponível (ou está desabilitado ou redirecionado), o endereço de IP de um servidor diferente é retornado. Ou seja, quando o dispositivo de DNS (o roteador de solicitação) recebe um nome de domínio (também chamado de nome de host) para a resolução do domínio, o dispositivo (rastreador) determina se o nome de host é um nome de host ancorado ou não (ou seja, determina se o nome de host recebido inclui uma âncora). Se o nome de host não estiver ancorado, o rastreador de DNS aplicará um mecanismo regular de seleção de pontos finais e retornará os endereços de IP dos EPs mais adequados. Se o nome de host estiver ancorado (inclui um prefixo de âncora), então o dispositivo de DNS determina se o EP identificado pelo prefixo de âncora está desativado ou parado. Em caso afirmativo, o rastreador de DNS aplica um mecanismo regular de seleção de pontos finais e retorna os endereços de IP dos EPs mais adequados. Caso contrário (o EP identificado pelo prefixo da âncora não está desabilitado ou redirecionado), o rastreador responderá apenas com o endereço de IP do(s) EP(s) identificado(s) pelo prefixo da âncora, se o dito EP estiver disponível. Se o EP não estiver disponível, o rastreador de DNS aplicará um mecanismo regular de seleção de pontos finais e retornará os endereços de IP dos EPs mais adequados.
- No ponto final (servidor de vídeo ou, de modo mais geral, servidor de conteúdo), ele redireciona a adição de âncora (redirecionamento da âncora) quando o nome de host recebido é o correspondente à seleção ideal do ponto final. Por exemplo, quando o servidor recebe uma mensagem solicitando um manifesto ou um fragmento (mensagem GET), ele lê o nome de host incluído na mensagem (o parâmetro Redir = True). Se o nome de host for um nome de host ancorado (o nome de host inclui um identificador de âncora, o EP fornecerá o conteúdo solicitado (manifesto ou fragmento), independentemente da âncora identificar ou não o dito ponto final; se o identificador da âncora não identificar o EP, mas outro EP (EP de âncora), significa que o EP de âncora não está disponível e é por isso que a mensagem foi direcionada para esse EP; portanto, em qualquer caso, o EP fornecerá o conteúdo solicitado.

[0079] Se o nome de host não for um nome de host ancorado (o nome de host não inclui um identificador de âncora), mas um nome de host redirecionado, isso significa que o ponto final já é o ponto final ideal em todos os pontos finais disponíveis e realiza o redirecionamento da âncora (ou seja, ele retorna uma mensagem de redirecionamento, incluindo um identificador de âncora que identifica esse EP).

[0080] Normalmente, se o nome de host for um nome de host de solicitação original (ou nome de domínio), esse é um nome canônico de uma CDN ou um nome de host do cliente, geralmente o redirecionamento normal (não o redirecionamento de âncora) é realizado (incluindo pid/hash). O nome de host da solicitação original é o nome de domínio (nome de host) incluído no URL na primeira solicitação de conteúdo de usuário final. Esse nome de domínio de solicitação original pode ser um nome de domínio de CDN (por exemplo, a CDN de um operador como uma Telefônica, cujo nome canônico no nível de DNS é b1.cdn.telefonica.com ou b99.cdn.telefonica.com, como no exemplo ou 3a, 3b e 3c) ou pode ser um nome de host do cliente (por exemplo, customer.com).

[0081] Em uma modalidade, há uma funcionalidade chamada aprimoramento de roteamento de solicitação na CDN e se o nome de host for um nome de host de solicitação original e se essa funcionalidade estiver ativada, o redirecionamento da âncora será realizado. Ou seja, nesta modalidade específica, se o nome de host for um nome de host de solicitação original, será determinado se o aprimoramento de roteamento de solicitação está habilitado. Em caso afirmativo, o redirecionamento da âncora é realizado pelo EP, incluindo pld+hash. Caso contrário, o redirecionamento normal (não o redirecionamento de âncora) é realizado (incluindo pid/hash).

[0082] Como mencionado anteriormente, quando o nome de host é um nome de host de solicitação original, o PID (ID da Partição de Rede) e o hash (identificando um grupo de conteúdo para distribuir igualmente a distribuição de conteúdo entre EPs próximos ao usuário final) geralmente são incluídos no redirecionamento.

[0083] Agora, um exemplo específico (apenas para fins ilustrativos, não limitativo) será divulgado para melhor explicar esse processo de ponto final. Por exemplo, em uma modalidade, o nome de domínio original do URL é BX.cdn.telefonica.com (onde X é um valor que depende da implementação específica, 99 no caso divulgado nas figuras 3a, 3b e 3c). Então, como o nome de domínio é um nome de host de solicitação original, é feito um redirecionamento normal, incluindo um PID (por exemplo, pY, em que Y é um valor que depende da implementação específica, 14 no caso divulgado na figura 3) e um hash (por exemplo, hZ, onde valor Z depende da implementação específica, 33 no caso divulgado nas figuras 3a, 3b e 3c). Portanto, o nome de domínio no dito redirecionamento é BX-pY-hZ.1.cdn.telefonica.com. Então, como mostrado nas figuras 3a, 3b e 3c, com o dito nome de domínio, o EP ideal é selecionado e uma mensagem é enviada pelo usuário final com o dito nome de domínio (BX-pY- hZ.1 .cdn.telefonica.com), ao dito EP ideal, se disponível. E, como o nome de domínio não é um nome de host de solicitação original (mas um nome de host redirecionado), o EP faz o último redirecionamento adicionando a âncora (por exemplo, aW, onde W é um valor que identifica o EP, aXX no caso divulgado nas figuras 3a, 3b e 3c); portanto, o nome de domínio modificado com a âncora será Bx-Py-hZ- aW.1 .cdn.telefonica.com.

[0084] As modalidades descritas devem ser consideradas em todos os aspectos como apenas ilustrativas e não restritivas anexadas como parte integrante das mesmas, tendo um caráter ilustrativo e não limitativo. Outras modalidades com características alternativas podem ser implementadas sem se afastar do escopo da presente invenção.

[0085] Por exemplo, em uma modalidade alternativa, no primeiro redirecionamento (o nome de domínio recebido é um nome de host de solicitação original), mesmo quando o aprimoramento de roteamento de solicitação está desativado, o redirecionamento ancorado para o EP ideal será realizado. Isso permite usar apenas um redirecionamento em vez de dois durante todo o mecanismo de roteamento de solicitação.

[0086] Em outras modalidades, a aderência não será usada para todos os domínios, mas pode ser configurada para ser usada apenas para domínios específicos. Isso possibilita evitar o seu uso no caso do dispositivo não suportar o redirecionamento ou apenas um limite baixo.

[0087] Com o mecanismo proposto, o problema explicado anteriormente que afetou a experiência do usuário final quando os servidores estão próximos ao ponto de saturação (por exemplo, durante momentos de grande audiência) é resolvido ou pelo menos minimizado. Isso é mostrado, por exemplo, na figura 4, que mostra o número de players de HLS conectados a um servidor de CDN específico durante um evento de alta audiência (evento de futebol ao vivo dia 17 de Setembro de 2017). Como pode ser visto na figura 4, o número de players de HLS conectados ao servidor não mostra um perfil de sawtooth agressivo, como mostrado anteriormente quando a solução proposta não foi aplicada, mas é bastante estável em torno de 4000 usuários por servidor, evitando a problemática de comportamento (efeito de pingue-pongue, efeito de avalanche) explicado anteriormente; porque com a solução proposta, um único servidor está distribuindo o conteúdo a cada usuário durante toda a sessão de vídeo.

[0088] Embora a maioria das modalidades acima da presente invenção tenha sido explicada para sistemas de comunicação com o uso de técnicas de streaming para distribuição de conteúdo (e mais especificamente técnicas de streaming adaptáveis), este foi apenas um exemplo. A invenção proposta pode ser aplicada não apenas às comunicações com o uso de streaming adaptável, mas para qualquer comunicação que implique o estabelecimento de uma sessão com solicitações consecutivas (por exemplo, solicitações de HTTPS). Graças ao mecanismo proposto, os clientes podem manter a localização/redirecionamento da primeira solicitação.

[0089] Uma pessoa versada na técnica reconheceria prontamente que etapas de vários métodos descritos acima podem ser executadas por computadores programados. Aqui, algumas modalidades também se destinam a cobrir dispositivos de armazenamento de programas, por exemplo, meio de armazenamento de dados digitais, que são legíveis por máquina ou por computador e codificam programas de instruções executáveis por máquina ou executáveis por computador, em que as ditas instruções executam algumas ou todas as etapas de ditos métodos acima descritos. Os dispositivos de armazenamento de programa podem ser, por exemplo, memórias digitais, mídia magnética de armazenamento, como discos magnéticos e fitas magnéticas, discos rígidos ou mídia de armazenamento digital de dados com leitura óptica. As modalidades também se destinam a cobrir computadores programados para executar as ditas etapas dos métodos descritos acima.

[0090] O conteúdo e o conteúdo de mídia podem se referir a qualquer tipo de material eletrônico, como música, vídeos, software, livros, apresentações multimídia, imagens, texto e outros dados eletrônicos que podem ser distribuídos como o fluxo ou transferidos, por exemplo, através de uma rede para um ou mais usuários.

[0091] A descrição e os desenhos ilustram meramente os princípios da invenção.

[0092] Embora a presente invenção tenha sido descrita com referência a modalidades específicas, deve ser entendido pelos versados na técnica que as alterações precedentes e várias outras alterações, omissões e adições na forma e detalhes das mesmas podem ser feitas na mesma sem se afastar do escopo da invenção como definido pelas reivindicações a seguir. Além disso, todos os exemplos aqui citados se destinam expressamente a ser apenas para fins pedagógicos, para ajudar o leitor a entender os princípios da invenção e os conceitos contribuídos pelo(s) inventor(es) para promover a técnica, e devem ser interpretados como estando sem limitação a exemplos e condições especificamente recitados. Além disso, todas as declarações aqui contidas que recitam princípios, aspectos e modalidades da invenção, bem como exemplos específicos dos mesmos, pretendem abranger equivalentes dos mesmos.

[0093] Deve ser apreciado pelos versados na técnica que quaisquer diagramas de blocos aqui apresentados representam vistas conceituais de circuitos ilustrativos que incorporam os princípios da invenção. Da mesma forma, será apreciado que quaisquer fluxogramas, diagramas de fluxo, diagramas de transição de estado, pseudocódigo e similares representam vários processos que podem ser substancialmente representados em meio legível por computador e assim executados por um computador ou processador, independentemente desse computador ou processador ser ou não mostrado explicitamente.

Claims

Método para a distribuição aprimorada de conteúdo de multimídia para equipamentos de usuário final em uma rede de distribuição de conteúdo compreendendo vários servidores, o método compreendendo:
- - Um primeiro servidor que recebe uma primeira mensagem de um equipamento de usuário final, a mensagem incluindo um URL que inclui um primeiro nome de domínio;
sendo o método caracterizado por:
- - Após receber a dita primeira mensagem, o primeiro servidor determina se o dito primeiro nome de domínio inclui um identificador de um servidor da rede de distribuição de conteúdo, chamado identificador de âncora e, caso contrário, o primeiro servidor envia de volta ao equipamento de usuário final uma mensagem de redirecionamento incluindo um segundo nome de domínio no URL, sendo o dito segundo nome de domínio o resultado da adição ao primeiro nome de domínio de um identificador de âncora que identifica o primeiro servidor;
em que, quando um dispositivo de sistema de Nome de Domínio, DNS, da rede de distribuição de conteúdo recebe uma solicitação de resolução de nome de domínio para um nome de domínio incluindo o dito identificador de âncora, o dispositivo de DNS envia de volta uma mensagem respondendo à solicitação de resolução de nome de domínio, incluindo o endereço de IP do primeiro servidor, independentemente do nível de congestionamento do dito servidor, desde que o primeiro servidor esteja disponível.
Método, de acordo com a reivindicação 1, caracterizado pelo fato de que o primeiro nome de domínio é um nome de domínio redirecionado.
Método, de acordo com qualquer uma das reivindicações anteriores, caracterizado pelo fato de que a primeira mensagem é uma mensagem que solicita um manifesto para uma sessão de streaming de conteúdo de multimídia ou um fragmento do conteúdo de multimídia e em que, se o dito primeiro nome de domínio já inclui um identificador de âncora de um servidor da rede de distribuição de conteúdo, o primeiro servidor envia o manifesto ou fragmento solicitado ao equipamento de usuário final.
Método, de acordo com qualquer uma das reivindicações anteriores, caracterizado pelo fato de que o primeiro nome de domínio não é um nome de domínio de solicitação original.
Método, de acordo com a reivindicação 1, caracterizado pelo fato de que o primeiro nome de domínio é um nome de domínio de solicitação original.
Método, de acordo com qualquer uma das reivindicações anteriores, caracterizado pelo fato de que o dispositivo de DNS é um roteador.
Método, de acordo com qualquer uma das reivindicações anteriores, caracterizado pelo fato de que o primeiro nome de domínio pertence a um grupo de domínios específicos para os quais a adição de um identificador de âncora é permitida.
Método, de acordo com qualquer uma das reivindicações anteriores, caracterizado pelo fato de que o conteúdo de multimídia é conteúdo de vídeo.
Método, de acordo com qualquer uma das reivindicações anteriores, caracterizado pelo fato de que o equipamento de usuário final é um telefone celular, um tablet, um smartphone, um computador, um PC, um laptop ou qualquer dispositivo eletrônico capaz de receber conteúdo de multimídia pela rede de comunicação.
Servidor para distribuição aprimorada de conteúdo de multimídia para equipamentos de usuário final em uma rede de distribuição de conteúdo, sendo o servidor caracterizado por compreender:
- - Um receptor para receber, através da rede de distribuição de conteúdo, uma primeira mensagem de um equipamento de usuário final, a mensagem incluindo um URL incluindo um primeiro nome de domínio;
- - Um transmissor para transmitir mensagens através da rede de distribuição de conteúdo;
sendo o servidor caracterizado por compreender um processador configurado para:
- - Após receber a dita primeira mensagem, determinar se o dito primeiro nome de domínio inclui um identificador de um servidor da rede de distribuição de conteúdo, chamado identificador de âncora e, caso contrário, enviar de volta ao equipamento de usuário final com o uso do transmissor, uma mensagem de redirecionamento, incluindo um segundo nome de domínio no URL, sendo o dito segundo nome de domínio o resultado da adição ao primeiro nome de domínio de um identificador de âncora que identifica o servidor.
Dispositivo de DNS para distribuição aprimorada de conteúdo de multimídia para equipamentos de usuário final em uma rede de distribuição de conteúdo compreendendo vários servidores, sendo o dispositivo caracterizado por compreender:
- - Um receptor para receber, através da rede de distribuição de conteúdo, uma solicitação de resolução de nome de domínio para um nome de domínio;
- - Um transmissor para transmitir mensagens através da rede de distribuição de conteúdo;
sendo o dispositivo caracterizado por compreender um processador configurado para:
- - Determinar se o dito nome de domínio inclui um identificador de âncora que identifica um servidor; em caso afirmativo, determinar se o dito servidor identificado pelo identificador de âncora está disponível e se o dito nome de domínio incluir um identificador de âncora que identifica um servidor e o servidor estiver disponível, enviar de volta com o uso do transmissor, uma mensagem respondendo à solicitação de resolução de nome de domínio, incluindo um endereço de IP do servidor identificado pelo identificador de âncora, independentemente do nível de congestionamento do dito servidor.
Sistema para distribuição aprimorada de conteúdo de multimídia para equipamentos de usuário final em uma rede de distribuição de conteúdo, o sistema compreendendo:
- - Um servidor que compreende:
- - Um receptor para receber, através da rede de distribuição de conteúdo, uma primeira mensagem de um equipamento de usuário final, a mensagem incluindo um URL incluindo um primeiro nome de domínio;
- - Um transmissor para transmitir mensagens através da rede de distribuição de conteúdo;
- - Um dispositivo de DNS que compreende:
- - Um receptor para receber, através da rede de distribuição de conteúdo, uma solicitação de resolução de nome de domínio para um nome de domínio;
- - Um transmissor para transmitir mensagens através da rede de distribuição de conteúdo;
sendo o sistema caracterizado por:
- - o servidor que compreende um processador configurado para, após receber a dita primeira mensagem, determinar se o dito primeiro nome de domínio inclui um identificador de um servidor da rede de distribuição de conteúdo, chamado identificador de âncora e, caso contrário, enviar de volta ao equipamento de usuário final com o uso de seu transmissor, uma mensagem de redirecionamento incluindo um segundo nome de domínio no URL, que é o resultado da adição ao primeiro nome de domínio de um identificador de âncora que identifica o servidor;
- - o dispositivo de DNS que compreende um processador configurado para: determinar se o dito nome de domínio incluído na mensagem de solicitação de resolução de domínio inclui um identificador de âncora que identifica um servidor e se o dito nome de domínio incluir um identificador de âncora que identifica um servidor e o servidor estiver disponível, enviar de volta com o uso de seu transmissor, uma mensagem respondendo à solicitação de resolução de nome de domínio, incluindo um endereço de IP do servidor identificado pelo identificador de âncora, independentemente do nível de congestionamento do dito servidor.
Meio de armazenamento de dados digitais não transitório para armazenamento de um programa de computador, caracterizado por compreender instruções que fazem com que um computador que executa o programa realize o método de acordo com qualquer uma das reivindicações 1 a 9.