PT115587B - Método e dispositivo para transmissão em direto em contínuo com partilha de carga oportunista por computação em nuvem periférica móvel - Google Patents

Abstract

A CRESCENTE DEMANDA POR TRANSMISSÕES EM DIRETO EM CONTÍNUO DE ALTA QUALIDADE ESTÁ A IMPULSIONAR A NECESSIDADE DE MELHORES INFRAESTRUTURAS DE REDE, ESPECIALMENTE AO DISSEMINAR CONTEÚDOS EM ÁREAS ALTAMENTE CONGESTIONADAS, COMO ESTÁDIOS, CONCERTOS E MUSEUS. AS ABORDAGENS TRADICIONAIS PARA LIDAR COM ESSE TIPO DE CENÁRIO BASEIAM-SE NUMA COMBINAÇÃO DE DADOS CELULARES, ATRAVÉS DE ARRANJOS DE ANTENAS DISTRIBUÍDOS POR 4G (DAS), COM UMA ALTA CONTAGEM DE PONTOS DE ACESSO WIFI (802.11). ISSO OBVIAMENTE REQUER UM CUSTO INICIAL SUBSTANCIAL PARA EQUIPAMENTOS, PLANEAMENTO E IMPLANTAÇÃO. RECENTEMENTE, NOVOS ESFORÇOS FORAM INTRODUZIDOS PARA ALAVANCAR COM SEGURANÇA AS CAPACIDADES DE TRAJETOS MÚLTIPLOS SEM FIOS, INCLUINDO MULTIDIFUSÃO WIFI E 4G E COMUNICAÇÕES DISPOSITIVO-PARA-DISPOSITIVO. PARA RESOLVER ESSES PROBLEMAS, PROPOMOS UMA ABORDAGEM QUE DIMINUI OS REQUISITOS IMPOSTOS ÀS INFRAESTRUTURAS SEM FIOS E, AO MESMO TEMPO, POTENCIALMENTE EXPANDE A COBERTURA SEM FIOS POR MEIO DE COLABORAÇÃO COLETIVA DE DISPOSITIVOS MÓVEIS. PARA O CONSEGUIR, PROPOMOS UMA NOVA ABORDAGEM ABRANGENTE QUE COMBINA SISTEMAS DISTRIBUÍDOS SEGUROS, MULTIDIFUSÃO WIFI, CODIFICAÇÃO DE ELIMINAÇÃO, CODIFICAÇÃO DE ORIGEM E PARTILHA DE CARGA OPORTUNISTA QUE UTILIZA EDGE CLOUDS MÓVEIS HIPERLOCAIS. MOSTRAMOS EMPIRICAMENTE QUE A NOSSA SOLUÇÃO É CAPAZ DE OFERECER UMA REDUÇÃO DE 11 VEZES NO USO DA LARGURA DE BANDA WIFI INFRAESTRUTURA I SEM PRECISAR DE MODIFICAR QUAISQUER PILHAS DE SOFTWARE OU FIRMWARE EXISTENTES, GARANTINDO AO MESMO TEMPO A INTEGRIDADE, A AUTORIZAÇÃO E A AUTENTICAÇÃO DO FLUXO.

Description

DESCRIÇÃO

MÉTODO E DISPOSITIVO PARA TRANSMISSÃO EM DIRETO EM CONTÍNUO COM PARTILHA DE CARGA OPORTUNISTA POR COMPUTAÇÃO EM NUVEM PERIFÉRICA MÓVEL

DOMÍNIO TÉCNICO

[0001] A presente divulgação refere-se a uma abordagem abrangente que combina sistemas distribuídos seguros, multidifusão WiFi, codificação de eliminação, codificação de origem e partilha de carga oportunista que utiliza computação em nuvem periférica móvel (do Inglês mobile edge clouds) _r hiperlocal. Em particular, esta divulgação refere-se a um método e dispositivo para transmissão em direto em contínuo (do Inglês streaming) com partilha de carga oportunista em edge cloud móvel.

ANTECEDENTES

[0002] Os sistemas atuais de transmissão em direto em contínuo para cenários de alta densidade tentam resolver o problema de fiabilidade com diferentes abordagens. A maioria dessas ofertas são comerciais, portanto, poucas informações estão disponíveis. As soluções atuais de sistemas completos que realmente têm implementações executáveis e não simulações, compreendem o sistema StadiumVision da Cisco e o sistema Streambolico.

[0003] 0 StadiumVision da Cisco usa multidifusão WiFi para fornecer conteúdos de transmissão em direto em contínuo a utilizadores finais enquanto usa uma solução FEC (Forward Error Correction - Correção de erros sem canal de retorno) proprietária. Além disso, nenhum mecanismo de retransmissão está em uso. Baseia-se exclusivamente na paridade e na qualidade da ligação sem fios para garantir a transmissão em continuo de video adequada. Esta solução parece não permitir a seleção do codec de video a ser usado.

[0004] A solução da Streambolico oferece apenas retransmissões multidifusão baseadas na codificação de origem para encontrar a melhor combinação linear a ser usada, portanto, nenhum mecanismo FEC está em uso. A unidifusão é usada pelos clientes para enviar periodicamente os seus relatórios de volta ao servidor. Oferece uma abordagem agnóstica em relação ao codec de video usado. Assim como na solução da Cisco, nenhum deles suporta nenhum tipo de partilha de carga em edge cloud, trajetos múltiplos, escalonamento, dados móveis e não apresentam segurança por natureza, por exemplo, integridade do fluxo.

[0005] 0 Pullcast concentra-se no uso de redes em malha P2P de 1 salto para suportar multidifusão de video usando WiFi. Ao contrário da nossa abordagem, a infraestrutura garante apenas o fluxo de multidifusão a partir da rede principal. Cabe à rede em malha local a possível recuperação dos pacotes em falta. Como os principais fornecedores, como a Extreme Networks, impõem um limite na fila de saída para a faixa de multidifusão nas suas APs, é comum que alguns pacotes de multidifusão sejam descartados na AP.

[0006] Além disso, se nenhum dos nós dentro da rede em malha tiver um pacote especifico, então a recuperação será impossível e, dentro da sua rede em malha, usarão a unidifusão para executar retransmissões.

[0007] No entanto, abstraem as conexões P2P, portanto, nenhuma comunicação D2D verdadeira é usada/simulada.

[0008] A transmissão em continuo de video através de redes sem fios usando multidifusão e unidifusão, mas na camada IP, é abordada por A. Majumda, et al. Apresenta um novo algoritmo híbrido Automatic Repeat re-Quest (ARQ) que funde FEC com o protocolo ARQ para transmissão em contínuo em unidifusão e oferece uma abordagem que usa o FEC para codificação de vídeo progressiva em multidifusão baseada no MPEG-4 FGS. Esta solução não é capaz de fazer uso de processos de comunicação de nível superior fornecidos por dispositivos móveis sem exigir uma quantidade não trivial de refactoring de sistemas operativos móveis e opera sob uma janela de tempo (agrupamento), com o envio de reconhecimentos após a receção com êxito do agrupamento, em que pacotes de origem são enviados antes dos pacotes FEC potenciais. Se nenhuma perda ocorrer durante a transmissão dos pacotes de origem, então nenhuma paridade será enviada (já que nenhum pacote foi perdido).

[0009] Como alternativa, a abordagem adotada no DiCoR aborda o problema da transmissão em contínuo de vídeo 3G (através da radiodifusão) , a saber, a partilha de carga do tráfego de retransmissões do 3G por meio de um algoritmo cooperativo de reparação P2P fora da banda (CPR) que usa IEEE 802.11 ad-hoc. Assume que todos os nós presentes na rede em malha P2P são altruístas e não se desviam da implementação especificada do DiCoR. Como em A. Majumda, et al., se um pacote não estiver disponível no P2P, então não há como recuperá-lo (e não ocorrerá convergência), no entanto, há uma sugestão para o uso de retransmissões explícitas forçando o uso de 3G (embora não seja apresentado ou simulado).

[0010] Por fim, o DiCoR evita o uso de FEC, pois argumentase que o retorno associado aos relatórios dos clientes pode potencialmente levar a uma implosão do retorno (como também confirmámos). No entanto, o íris contorna esse problema com uma representação compacta de pacotes pendentes, inclusivamente na presença de alta perda de pacotes.

[0011] 0 PeerCast [42] usa uma abordagem cooperativa centralizada para WLANs baseadas em 802.11. O principal pressuposto é que a capacidade do canal para redes sem fios, principalmente para multidifusão, é prejudicada pela presença de clientes associados a baixas taxas de dados. Em vez de voltar à taxa de dados mais baixa para permitir a receção a partir de um número maior de clientes, ela usa a taxa de dados mais alta possível para aumentar a taxa de transferência e usa relê de pacotes para compensar a perda de pacotes. Para atinqir esse relê, um subconjunto de nós com altas taxas de dados é selecionado para encaminhar os dados para outros nós estrateqicamente posicionados ou nós mais fracos.

[0012] A presente divulqação também partilha alquns pontos em comum com o PeerCast, uma vez que também utiliza o relé, embora inteqrado com mecanismos de recuperação adicionais, isto é, FEC, intercalação e escalonamento. No entanto, o sistema e o método divulqados não optam pela maior taxa de dados possível, pois, pela nossa experiência, isso tem um efeito composto sobre as perdas de pacotes. Em vez disso, fazemos uso criterioso da larqura de banda de multidifusão para transmissões em contínuo e retransmissões de vídeo. Além disso, operamos na camada da aplicação para fazer uso de todas as comunicações D2D possíveis pronto a usar, sem exiqir qualquer modificação na pilha de rede, em oposição ao PeerCast que opera na camada de liqação, exiqindo modificações nos OSes.

[0013] D. Jurca et al. fornece uma abordaqem teórica para o suporte de trajetos múltiplos de baixo nível através do uso de várias estratéqias de escalonamento que usam transmissão em continuo de vídeo como um caso de aplicação. Em relação aos aspetos de segurança, aborda um esquema seguro para P2P, mas não considera o rastreamento por multidifusão. Usa o código de autenticação de mensagem com chave hash, ou escrutínio, (HMAC) para integridade que o torna inadequado para o nosso cenário.

[0014] Tanto quanto sabemos, nenhum dos sistemas mencionados acima integra sem descontinuidade multidifusão, segurança, integridade do fluxo e partilha de carga em edge cloud fiáveis.

DESCRIÇÃO GERAL

[0015] A presente divulgação permite usar uma abordagem sofisticada usando um mecanismo intercalado duplo que usa a monitorização de canais para ajustar a paridade no momento, o que minimiza o impacto da latência, aqui designado de íris.

[0016] Além disso, utiliza uma representação compacta, que faz uso de compactação, para representar pacotes em falta no nosso mecanismo de reconhecimento. Em vez de usar números de sequência completos, a presente divulgação usa bítmaps para economizar espaço.

[0017] É divulgada uma abordagem alternativa à de A. Majumda, mas poderia facilmente tornar os dados móveis como o principal canal de comunicação e, em seguida, usar canais de comunicação alternativos, por exemplo, WiFi, Bluetooth, para recuperar pacotes. A partir de agora, construímos retransmissão explícita que é acionada quando várias tentativas ou um limiar de tempo são ultrapassados, para forçar o uso de dados móveis, se permitido/presente. É importante notar que isso é completamente integrado no nosso processo de escalonamento modular, e o comportamento pode ser facilmente ajustado.

[0018] O sistema e método divulgados permitem usar um esquema de assinatura dupla para não repúdio e suporte ao FEC, em conjunto com a rotação simétrica de chaves para garantir sigilo de encaminhamento. Além disso, o método divulgado pode potencialmente ter autenticação federada, na qual os vizinhos partilham um esquema de encriptação exclusivo, ou seja, independente do OAuth de back-end, do Português parte de retaguarda ou de suporte, (embora mantendo o esquema de assinatura dupla para não repúdio). Isso permite o uso de chaves simétricas independentes, que podem ser usadas para minimizar o comportamento parasitário (do Inglês leechíng) de dispositivos não cooperantes próximos.

BREVE DESCRIÇÃO DOS DESENHOS

[0019] As figuras a seguir fornecem formas de realização preferidas para ilustrar a descrição e não devem ser vistas como limitativas do âmbito da invenção.

[0020] Figura 1: Mostra uma representação esquemática de uma forma de realização da transmissão em continuo ao longo de uma secção de estádio.

[0021] Figura 2: Representação ilustrativa de uma forma de realização da Visão Geral do Sistema.

[0022] Figura 3: Representação esquemática da matriz de transmissão, onde (1) representa a codificação coluna, (2) representa a codificação linha, (A) representa os dados, (B) representa a paridade linha, (C) representa a paridade coluna e (D) representa a paridade de linha sobre paridade de coluna.

[0023] Figura 4: Representação esquemática de uma forma de realização do Processo do Escalonador de Rede.

[0024] Figura 5: Representação esquemática de uma forma de realização da estrutura de dados do relatório de retorno.

[0025] Figura 6: Representação esquemática de uma forma de realização do esquema de assinatura dupla.

[0026] Figura 7: Representação esquemática de uma forma de realização da recuperação de um pacote perdido.

[0027] Figura 8: Representação esquemática de uma forma de realização da implementação de front-end, do Português parte frontal.

[0028] Figura 9: Representação esquemática de uma forma de realização do uso total da largura de banda de descarregamento WiFi sem 4G e partilha de carga edge.

[0029] Figura 10: Representação esquemática de uma forma de realização dos prazos perdidos sem 4G e partilha de carga edge.

[0030] Figura 11: Representação esquemática de uma forma de realização da latência de transmissão em continuo sem 4G e partilha de carga edge.

[0031] Figura 12: Mostra uma representação esquemática de uma forma de realização do impacto de 4G no uso total de largura de banda sem partilha de carga edge.

[0032] Figura 13: Representação esquemática de uma forma de realização da eficiência de previsão em relação à largura de banda sem partilha de carga edge.

[0033] Figura 14: Representação esquemática de uma forma de realização da eficiência de previsão em relação a prazos perdidos sem partilha de carga edge.

[0034] Figura 15: Mostra uma representação esquemática de uma forma de realização do uso total da largura de banda de descarregamento WiFi (250Kbit/s, 500Kbit/s e lOOOKbit/s) com partilha de carga edge.

[0035] Figura 16: Mostra uma representação esquemática de uma forma de realização do uso total da largura de banda de descarregamento 4G (250Kbit/s, 500Kbit/s e lOOOKbit/s) com partilha de carga edge.

[0036] Figura 17: Representação esquemática de uma forma de realização da latência de arranque de vídeo (250Kbit/s, 500Kbit/s e lOOOKbit/s) com partilha de carga edge.

[0037] Figura 18: Representação esquemática de uma forma de realização dos prazos perdidos (250Kbit/s, 500Kbit/s e lOOOKbit/s).

[0038] Figura 19: Representação esquemática de uma forma de realização das perdas de pacotes de rajada (do Inglês burst) usando multidifusão 802.11η usando iperf.

DESCRIÇÃO DETALHADA

[0039] Há um problema do mundo real que enfrenta ambientes de alta densidade, como estádios, arenas, salas de concertos e museus, no que diz respeito à crescente demanda por mais largura de banda e latências mais baixas por WiFi para aplicações móveis altamente interativas, especialmente no que concerne à transmissão em contínuo de vídeo direta.

[0040] O custo para fornecer cobertura sem fios que inclui o DAS (Distributed Antenna Array) e o WiFi para um grande estádio atingiu aproximadamente US $ 18 milhões em 2016. Apesar dos melhores esforços dos fornecedores de rede para fornecer cobertura sem fios sem descontinuidade, fontes aleatórias de interferência, e até o comportamento do utilizador, podem causar estragos na experiência do utilizador.

[0041] Em resposta a esses problemas, os fornecedores de telecomunicações e de tecnologia sem fios procuram ativamente por soluções mais descentralizadas, como o 5G, num esforço para aumentar a cobertura e a taxa de transferência da rede. Simultaneamente, a busca por abordagens alternativas para soluções centralizadas, como forma de evitar um ponto de falha único, levou a um interesse renovado na computação periférica (edge) .

[0042] Além disso, a adoção cada vez maior de dispositivos móveis está a aumentar o interesse na exploração potencial dos recursos inexplorados que esses dispositivos possuem. O impacto social pode ser facilmente percebido, pois a colaboração coletiva (do Inglês crowdsourcíng) desses dispositivos pode facilmente criar opções alternativas de rede em cenários em que as opções de infraestruturas tradicionais, por exemplo, APs 802.11η (Pontos de Acesso) e estações de base LTE/4G, são limitadas, indisponíveis ou comercialmente inviáveis.

[0043] As grandes implantações sem fios (comerciais e educacionais) indicam que os fornecedores de rede são extremamente conservadores em relação às modificações nos seus produtos, portanto, quaisquer alterações na infraestrutura foram excluídas, pois isso limitaria a aplicabilidade da nossa solução.

[0044] Ao usar dados 4G, o sistema e o método divulgados tentam fazer uso criterioso do uso da largura de banda, pois pode ter custos potenciais para o utilizador final (um utilizador é livre de bloquear o uso de dados móveis).

[0045] Numa forma de realização para obter melhores resultados, o sistema e o método divulgados alavancam o uso, a segurança, a latência e a fiabilidade da largura de banda AP, visando garantir a Qualidade de Experiência (QoE) aos utilizadores finais. Para garantir latência reduzida e fiabilidade da transmissão em continuo, algumas vezes a economia de largura de banda deve ser perdida, ou seja, um utilizador sentado num local de baixa cobertura WiFi, para garantir uma melhor experiência do utilizador.

[0046] Os utilizadores são desativados se o fluxo estiver em pausa por mais de 5 segundos. Com isso em mente, o nosso design visa fornecer uma latência abaixo desse limite superior. Como não estamos a modificar quaisquer pilhas de software, tanto na infraestrutura sem fios quanto nos dispositivos móveis, a introdução de um novo protocolo de transporte não foi considerada. Para facilitar a adoção pelos utilizadores, a solução descrita é construída inteiramente na camada da aplicação.

[0047] 0 Protocolo de Extensão de Mensagens em Tempo Real (RTMP) foi substituído pelo sistema e método divulgados. Isso permitiu diminuir a complexidade e adicionar mais flexibilidade para acomodar edge clouds e vários trajetos sem fios (802.11η e 4G) . No entanto, é totalmente viável incorporar a nossa solução no RTMP.

[0048] É assumida a existência de uma entidade fiável que fornece fluxos de vídeo selecionados e com reforço de segurança. Como os direitos de difusão podem estar em vigor, também é assumida a necessidade de um mecanismo de imposição de direitos digitais DRM. O protocolo DRM apenas fornece imposição ao nivel da rede. É considerada fora do âmbito toda a engenharia necessária para proteger o reprodutor multimédia, como o uso do TrustZone da ARM.

[0049] Numa forma de realização, pode ser considerado como foco principal uma implementação de Android (baseada no Android vanilla) porque é uma plataforma aberta que permite mais flexibilidade, embora o design suporte os sistemas operacionais Android e iOS.

[0050] Numa forma de realização, as Ligações Semi-Duplex Assimétricas de WiFi podem ser consideradas: Os dispositivos móveis têm substancialmente menos recursos de rádio, e isso é ainda mais exacerbado na ligação a montante. Isso pode ser facilmente explicado pelas restrições de energia nessas plataformas, onde menos energia disponível está disponível para os rádios sem fios. Por outro lado, os pontos de acesso possuem rádios sem fios substancialmente mais potentes, tornando a comunicação a jusante mais eficiente. Dada esta limitação, a largura de banda a montante é limitada e o seu uso deve ser conservador.

[0051] Numa forma de realização, o Suporte de Multidifusão Parcial a partir de OSes Móveis pode ser considerado: O suporte à multidifusão no sistema operativo móvel é atualmente abaixo do ideal. Certos dispositivos não suportam adequadamente o IGMP, por exemplo, o Google Nexus 5 apenas suporta o IGMP v6 devido a um bug, do português erro informático, no processo de compilação do kernel, do português núcleo do sistema operativo. Outros oferecem apenas suporte parcial, como o iPhone 5 da Apple (entre outros), que não suporta respostas de consulta IGMP. Por fim, a multidifusão por si só não é suficiente para garantir a transmissão de dados e, portanto, outros mecanismos devem estar em uso como alternativa.

[0052] Numa forma de realização, pode ser considerada a Perda de Pacote de Rajada: o sistema e o método divulgados assumem que nenhuma conversão multidifusão - unidifusão é executada na AP. Além disso, as redes sem fios que usam multidifusão tendem a ser afetadas principalmente pela perda de pacotes de rajada.

[0053] Numa forma de realização, o Comportamento do Utilizador pode ser considerado: Do ponto de vista comportamental, o sistema e o método divulgados assumem que os utilizadores não se moverão durante a transmissão em continuo. Isso torna o problema um pouco mais tratável, pois isola a nossa solução de alguns problemas de rede de baixo nivel, como transferências de WiFi. Também é uma suposição realista se, no presente caso especifico, presumir gue a maioria dos utilizadores apenas transmite enquanto estiverem sentados/em pé, por exemplo, intervalos, ou enquanto aguardam pontos de interesse próximos, como postos de concessão (de alimentos).

[0054] Numa forma de realização, a Implantação de Edge Cloud Móvel pode ser considerada: A implantação de edge clouds e a maneira como as redes em malha são construídas são estritamente controladas pela entidade anfitriã do sistema. Esse requisito decorre da necessidade de controlar o ambiente de radiofrequência (RE). Em alguns cenários, a interferência adicionada por Bluetooth e pontos de acesso à Internet sem fios pode potencialmente ser prejudicial para serviços já implantados, por exemplo, a televisão de circuito fechado herdada (CCTV) pode funcionar mal com contenção adicional sobre o espectro de RE.

[0055] 0 texto seguinte refere-se às melhorias no estado da técnica atual.

[0056] Numa forma de realização, o Esquema AL-FEC Ajustável em Tempo de Execução pode ser considerado: Dado que a perda de pacotes de rajada exibe por WiFi, em particular para multidifusão, um mecanismo FEC ajustável que faz uso da intercalação de transmissão para aumentar o AL-FEC (Correção de Erros sem Canal de Retorno ao nível da Aplicação) foi eficientemente projetado. É utilizado um algoritmo de codificação de eliminação de bloco comum, pronto a usar e amplamente testado, especificamente o Reed-Solomon, embora outros possam ser usados. 0 nível de redundância é ajustado no momento para enfrentar melhor as condições de rede em mudança usando um algoritmo baseado em janela deslizante.

[0057] Numa forma de realização, os Relatórios de Clientes Eficientes podem ser considerados: Para contornar a assimetria das ligações de carregamento, em particular no 802.11, foi projetado um mecanismo de reconhecimento/relatório com economia de espaço, aproveitando algoritmos de compressão que, se úteis, também atuarão como uma pulsação para a gestão de filiação do servidor.

[0058] Numa forma de realização, o Processo do Escalonador de Múltiplos Trajetos pode ser considerada: A solução de escalonamento back-end descrita permite que subescalonadores (um por primitivo de comunicação, por exemplo, multidifusão WiFi ou unidifusão 4G) , possam ser reorganizados para atender a uma necessidade de implantação específica. Por exemplo, se a multidifusão de WiFi não estiver disponível, então podemos simplesmente configurar o pípelíne, do Português encadeamento, sem o estágio de multidifusão.

[0059] Além disso, informações históricas e relatórios de clientes são usados para criar um serviço preditivo para estimar melhor a perda de pacotes. Ao contrário de outras abordagens que usam modelos estatísticos, a divulgação descrita pode fazer uso de um algoritmo supervisionado de aprendizagem de máquina, chamado Random Forest, para obter melhor uso da largura de banda e reduzir prazos perdidos.

[0060] Numa forma de realização, a Segurança e a Integridade podem ser consideradas: A infraestrutura de Chave Pública (PKI) é usada como base para uma infraestrutura segura. A abordagem atual permite apenas ataques de desempenho, até um certo ponto. Se um dispositivo sofrer queda de pacotes, porque não está a receber transmissão em continuo de multidifusão e/ou retransmissões suficientes, ele recua e solicita uma nova posição na edge cloud. A inteqridade do fluxo é garantida o tempo todo, inclusivamente na presença de dispositivos maliciosos.

[0061] Foi projetado um esquema de assinatura dupla que impõe a inteqridade, autenticação e não-repúdio ao lonqo de pacotes de rede e trechos de video. Cada pacote único é assinado diqitalmente pelo servidor fiável ou por um nó da edge cloud para qarantir que o remetente seja autorizado, enquanto um trecho de video válido deve ser assinado pelo servidor fiável. Para qarantir a confidencialidade, usamos chaves simétricas rotativas para encriptar carqas úteis de dados. Esta infraestrutura fiável oferece sequrança como serviço de modo a suportar a autenticação e autorização sem descontinuidade para edge clouds.

[0062] Numa forma de realização, a Partilha de Carqa em Edge Cloud Móvel pode ser considerada: Através da colaboração coletiva de dispositivos móveis, é oferecida uma nova abordaqem para suportar a partilha de carqa oportunista. Esta faz uso de todas as tecnoloqias de dispositivo para dispositivo (D2D) atualmente disponíveis no OS Android, nomeadamente Bluetooth [16] e WiFi-Direct [17], para criar edge clouds.

[0063] Numa forma de realização, a arquitetura pode ser considerada a representação esquemática da arquitetura qeral da presente divulqação representada na Figura 2. Enquanto a arquitetura descrita abaixo reflete uma única secção, por uma questão de clareza, a presente abordagem pode ser dimensionada horizontalmente conforme necessário.

[0064] 0 vídeo originado de uma câmara local é codificado no seu formato raw, normalmente usando uma interface SDI, para ο H265 (ou H264). Essa codificação pode ser realizada por um codificador local, usando software ou hardware, ou pode ser enviada para a cloud (mostrada como linhas tracejadas). O fluxo codificado final é então injetado nos servidores de transmissão em contínuo edge.

[0065] Cada secção é suportada por um servidor de transmissão em contínuo edge (que pode ser implantado como um microsservidor num pool de armazenamento) e a agregação destes forma uma cloudlet. A necessidade de usar servidores edge deriva do requisito de latência menor, principalmente nas retransmissões de pacotes, enquanto a codificação de vídeo real pode ser realizada na cloud.

[0066] Na Figura 2, é representado que a secção do estádio 110 é tratada pelo servidor de transmissão em contínuo edge 1. Este servidor é responsável por suportar a transmissão em contínuo de vídeo (segura), usando WiFi e 4G, para essa secção específica. O uso de edge clouds não é obrigatório, mas, se usado, é governado pelo servidor de transmissão em contínuo que supervisiona essa secção específica. No exemplo dado, o servidor de transmissão em contínuo edge 1 lida com a edge cloud 1, que é formada através da colaboração coletiva dos dispositivos presentes na secção do estádio 110. Além disso, cada secção é servida de WiFI e potencialmente 4G. Para WiFi, podemos usar unidifusão e potencialmente multidifusão, enquanto que para 4G estamos limitados a unidifusão, embora existam várias empresas de telecomunicações que estão atualmente a realizar testes de campo para avaliar a implantação de multidifusão por cima do 4G. 0 íris pode fazer uso imediato desta tecnologia, assim que se torne disponível para uso geral.

[0067] Numa forma de realização, o método da presente divulgação pode compreender um Servidor de Transmissão em contínuo.

[0068] Um servidor de transmissão em contínuo edge é responsável por manipular uma única secção (ou uma parte do espaço total). Dentro de cada servidor, existe um Source Stream Handler, do Português Gestor de Fluxo Fonte, que lida com o fluxo de vídeo codificado recebido, um Network Scheduler Framework, do Português Processo de Escalonador de Rede, que lida com o escalonamento de transmissão em contínuo e retransmissões multicanal, um Overlay Manager, do Português Gestor de Camada Superior, que supervisiona as diferentes sobreposições de camadas de rede em malha (uma para cada tipo de tecnologia) e, por fim, um Security/Membership Manager do Português Gestor de Segurança e Filiação, que oferece segurança como serviço para lidar com a encriptação da transmissão em contínuo e com a autenticação e autorização necessárias (incluindo o suporte a tokens, do português testemunhos de autenticação, seguros para as edge clouds) .

[0069] Numa forma de realização, o método da presente divulgação pode compreender um Gestor de Fluxo Fonte.

[0070] Este manipulador armazena em memória intermédia (do Inglês buffer) segmentos MPEG-TS codificados (188 bytes por cada vez), do codificador no local ou de um codificador hospedado numa cloud pública. Esses segmentos são então agregados em grupos usando um limiar predefinido (que é abaixo de 802.11η RTS (Solicitação de Envio)), que normalmente envolve 11 segmentos, mas é dependente da configuração do WiFi.

[0071] Devido à natureza não confiável do UDP e ao comportamento de perda de pacotes de Rajada do 802.11η, ou seja, quando a multidifusão é usada, a codificação de eliminação foi escolhida para adicionar pró-ativamente redundância aos fluxos, promovendo menos retransmissões. Obviamente, mais redundância resultará inerentemente em mais consumo de largura de banda; alternativamente, menos redundância pode potencialmente resultar em mais retransmissões.

[0072] Numa forma de realização, a Correção de Erro de Encaminhamento Ajustável pode ser considerada na presente divulgação.

[0073] Numa forma de realização, o método da presente divulgação pode optar por usar Reed-Solomon (RS) como nosso algoritmo de codificação de eliminação devido à sua eficiência na codificação e descodificação para um pequeno número de eliminações. No entanto, é bastante simples adotar um algoritmo diferente na presente arquitetura. A única restrição é que é aconselhável ter um código de distância máxima separável (MDS), para que qualquer combinação de erros e eliminações possa ser recuperada, até ao número de eliminações usadas. Este é um requisito do presente mecanismo de intercalação de pacotes.

[0074] De modo a melhorar a eficiência, foi introduzido um novo esquema de codificação de eliminação, que está intimamente ligado à presente estratégia de transmissão. Para efetivamente executar a codificação, primeiro uma matriz de transmissão é construída, como mostra a Figura 3. Os dados de origem (pacotes originais) usados pela codificação de eliminação são fornecidos pelo Source Stream

Handler (Gestor de Fluxo Fonte). Depois de criar pacotes de dados suficientes (dos segmentos de vídeo recebidos) para preencher uma matriz de transmissão, ocorre então a codificação de eliminação real da matriz.

[0075] A primeira fase codifica todas as colunas, seguida pela segunda fase que codifica todas as linhas, incluindo as linhas geradas no passo anterior como paridade de coluna. Isso oferece novos pacotes de paridade ajustável e paridade diagonal (paridade de linha sobre paridade de coluna, ou seja, os pacotes de cores mais escuras na Figura 3).

[0076] Numa forma de realização, o Processo do Escalonador de Rede pode ser considerado na presente divulgação.

[0077] Numa forma de realização, o presente processo de escalonamento de rede, representado na Figura 4, lida com o fluxo de multidifusão de base, mostrado como uma seta entre o Gestor de WiFI multifusão e o WiFI AP, que é depois complementada com as retransmissões necessárias para compensar os pacotes em falta para cada cliente com defeito.

[0078] Utiliza uma composição de subescalonadores seguindo um estilo de pipeline, em que cada estágio, isto é, subescalonador, pode potencialmente retransmitir pacotes pendentes. Todos os pacotes que não puderam ser retransmitidos num estágio específico são encaminhados para o próximo subescalonador do pipeline, com exceção da cauda, onde os pacotes podem ser reescalonados (em loop de retorno), para futura retransmissão, ou descartados, dependendo da estratégia usada.

[0079] A configuração do pipeline é modular, no sentido de que os módulos podem ser reorganizados para cumprir uma estratégia de retransmissão específica, embora a presente solução considere a configuração com subescalonadores de multidifusão WiFi, unidifusão WiFi e unidifusão 4G, nesta ordem específica. Esta configuração permite minimizar a carga imposta nas ligações 4G e, assim, evitar possíveis altos custos de dados para os utilizadores finais, respeitando as limitações atuais do uso de redes WiFi, especialmente aquelas relacionadas a cenários de alta densidade.

[0080] Cada subescalonador apresenta um gestor de largura de banda e um componente de filtragem. O primeiro serve como contador da largura de banda usada, globalmente (multidifusão) ou individualmente por cliente (unidifusão).

Visto que a filtragem é usada para excluir pacotes que não atendem a um conjunto específico de critérios, ou seja, o serviço de previsão da presente solução foi usado para determinar quais pacotes devem ser filtrados, mas também outras heurísticas foram impostas, como limitar o número de vezes que um pacote é considerado para retransmissões multidifusão (como uma maneira de desviar mais largura de banda multidifusão para pacotes mais recentes). As sessões do cliente são mantidas globalmente e são os espaços reservados para todas as informações sobre os clientes. Os clientes reconhecem a receção do seu pacote atual enviando relatórios periodicamente para o seu servidor de transmissão em contínuo (que é tratado internamente pelo escalonador de rede). Esses relatórios contêm uma representação das matrizes de transmissão pendentes (as que ainda têm pacotes em falta) e são explorados mais adiante.

[0081] Numa forma de realização, os Relatórios de Cliente com Espaço Eficiente podem ser considerados na presente divulgação.

[0082] A assimetria das ligações sem fios, onde as ligações a montante têm substancialmente menos largura de banda, requere uma abordagem de reconhecimento leve. Além desse problema, alguns OSes móveis, como o iOS, possuem pequenas memórias intermédias na sua pilha de rede que, uma vez preenchidas, fazem com que a aplicação entre num estado incorreto, do qual não é possível recuperar-se, exceto se forçando o reinicio da aplicação.

Tabela 1: Resultados da compactação

	CPU i.ii	Espaço (bytes)	Compactação
gzip	2.8Í0.26	606.lil.66	-39%.
7z	7<6±0.66	644.9i0.20	—35%
rar	13.9i2.91	708.9il.97	—28%

[0083] Numa forma de realização, isso motivou-nos a não usar reconhecimentos padrão positivos (ack) ou negativos (nack) , uma vez que eles impõem requisitos de largura de banda significativamente mais altos, sendo que o primeiro exige um ack para cada pacote recebido, enquanto o último requer um nack para cada deteção de perda de pacotes.

[0084] Como alternativa às técnicas de reconhecimento padrão, foi implementada uma estratégia de reconhecimento periódico que usa bítmap para eficiência de espaço, conforme mostrado na Figura 5. Quando comparada, a presente divulgação requer menos largura de banda à custa de uma latência um pouco mais alta, embora ajustável.

[0085] 0 primeiro campo do pacote indica o tipo de ligação (WiFi ou 4G). Isto é seguido pelo valor RSSI (indicação de intensidade do sinal recebido). O terceiro campo é o último número da matriz que foi despachado (onde todos os pacotes necessários foram recebidos ou ocorreu um tempo de interrupção), seguido pelos bitmaps compactados de todas as matrizes pendentes (dos quais usamos 0 para codificar um pacote em falta e 1 caso contrário).

[0086] Estes relatórios de cliente são enviados para os coletores de relatórios WiFi e 4G e são alimentados aos subescalonadores para serem usados na sua filtragem de préprocessamento .

[0087] Para a compactação real, usamos o gzíp, pois oferece a melhor taxa de compactação, e usa menos CPU, para a nossa estrutura de dados específica entre os que testamos, a saber 7z e rar. A Tabela 1 ilustra que, apresentando o intervalo de confiança médio e 95%, foi produzido executando 10 vezes cada algoritmo de compactação, usando uma CPU Intel Core 17 6700HQ, em comparação com 10 pacotes de reconhecimento diferentes (com tamanho fixo de 990 bytes) .

[0088] Numa forma de realização, o Serviço de Previsão pode ser considerado na presente divulgação.

[0089] Aprendizagem de máquina (ML) foi utilizada para criar um serviço de previsão que permitia prever a perda potencial de pacotes numa primitiva de transmissão específica (multidifusão WiFi, unidifusão WiFi ou unidifusão 4G) . Com isso, podemos reduzir efetivamente o consumo geral de largura de banda, pois evitamos desperdiçar largura de banda da rede e, no caso da codificação de origem multidifusão, podemos otimizar melhor as combinações lineares dos pacotes da retransmissão.

[0090] A integração do serviço de previsão é alcançada no subcomponente Filtragem, para cada subescalonador.

[0091] Foram construídos três classificadores distintos para lidar com multidifusão WiFi, unidifusão WiFi e unidifusão 4G, separadamente (um para cada subescalonador disponível), tendo considerado os seguintes atributos: rssí, Indicação de Intensidade do Sinal Recebido; clíents, número de clientes ativos; cols, o número de colunas na matriz de transmissão; rows, o número de linhas na matriz de transmissão; m, paridade de linha; z, paridade de coluna; report, relatório do cliente. 0 atributo clíents é considerado apenas para WiFi, pois não temos o número de clientes que estão conectados a uma estação de base móvel específica.

[0092] Para multidifusão, a ideia é usar o atributo report para prever a configuração da próxima matriz de transmissão. A matriz é projetada num único valor numérico, em que cada bit representa se o pacote está presente ou não (seguindo a mesma abordagem usada nos relatórios de feedback mostrados na Figura 5, ou seja, a configuração dos bítmaps da matriz de transmissão). Enquanto na unidifusão, o atributo report representa a taxa de perda de pacotes.

Tabela 2: Comparação entre diferentes algoritmos de Aprendizagem de Máquina.

Forests

C RAE RRE

Logística

C RAE RRE

SVM

C RAE RRE

IBk REPTree

C RAE RRE C RAE RRE

NaiveBayes

A RAE RRE

W.M 0.85 32.1% 52.1%

W.U 0.99 04.8% 13.0%

4.U 0.98 08.7% 22.12%

0.19 94.1% 98.1%

0.73 59.7% 07.5'%

0.39 93.2% 91.81%

0.07 69.3% 103.5%

0.71 39.9% 74.2%

0.95 09.4% 31.4%

0.82 31.7% 57.1% 0.81 37.5% 58.5%

0.98 03.2% 15.4%. 0.96 11.1% 20.0%

0.99 01.3% 15.8% 0.94 09.3% 31.4%.

48.7% 66.5% 81.4%

91.2% 26.3% 51.8%

96.1% 37.6% 54.5%

[0093] Os conjuntos de dados de treino usados para criar os classificadores foram recolhidos registando estatísticas da rede durante as execuções com o serviço de previsão desativado.

[0094] Os seguintes algoritmos foram considerados: Regressão Logística (Logística); Árvores de Classificação e Regressão (REPTree); k-Vizinhos mais próximos (IBk); Máquinas de Vetores de Suporte (SVM); Florestas Aleatórias (Florestas); e Naive Bayes.

[0095] Para esta experiência, foi realizada uma validação cruzada de 10 vezes contra esses algoritmos para Multidifusão WiFi (W.M), Unidifusão WiFi (W.U) e, por último, Unidifusão

4G (4.U). Como métricas, selecionamos Correlação (C), Erro absoluto relativo (RAE) e Erro ao quadrado relativo da raiz (RRE). Para Naive Bayes, instâncias classificadas corretamente (A) são mostradas em vez de correlação, pois tivemos que converter os atributos numéricos em representação nominal.

[0096] A Random Forests foi estabelecida como o algoritmo ML, uma vez que oferece uma melhor previsão para Multidifusão WiFi, oferecendo desempenho quase semelhante para a unidifusão quando comparado ao IBk. Para o futuro, pretendemos estender a API grpc do serviço de previsão da presente solução para permitir uma aprendizagem reforçada, em que cada serviço de transmissão em contínuo irá injetar os dados de monitorização coletados nos relatórios de reconhecimento dos dispositivos.

[0097] Numa forma de realização, o Subescalonador de Rede de Multidifusão WiFi pode ser considerado na presente divulgação.

[0098] A divulgação descrita aproveita a natureza de transmissão da multidifusão e utilizou-a para realizar a transmissão em contínuo de vídeo, visando a economia óbvia de largura de banda. Assim, além de cuidar das retransmissões de multidifusão, o subescalonador de multidifusão WiFi também envia o fluxo de base, que é depois seguido pelos ciclos de retransmissões para recuperar os pacotes em falta.

[0099] Em vez de depender apenas de retransmissões para se recuperar pacotes em falta, a solução atual usa proativamente o FEC como uma maneira de adicionar redundância ao fluxo. Como os pacotes de paridade estão a ser transmitidos, a solução descrita pode efetivamente minimizar a sobrecarga no uso da largura de banda, ou seja, ao contrário do uso do FEC em fluxos de unidifusão, onde os custos aumentam linearmente com o número de clientes.

[00100] Em vez de ter uma configuração fixa para a quantidade de paridade usada, para pacotes de paridade de linha e coluna, foi implementada uma correção de erro de encaminhamento ajustável em tempo de execução, conforme mostrado no Alqoritmo 1, que ajusta dinamicamente a quantidade de redundância para melhor atender às atuais condições de rede.

Alqoritmo tabela 1 vai; íto // s?4r$ .·<?« va?:: .^; :-<;<.« / /' i aU ,ϊ ·;·.·Ά ϊτωftpa c3 iwRf' sepçí;s í?

VÃSÚ 8 ...SvCiA:- // FEC ·ίϊΐίο»ι4ίόπ : praCÃAS.K* L /Jí;;;: i.AííC iiHK&nr!

A 'ΛΊΪ1 Aav TivsffiC *— 7i8£::7$qA::rf-L>'..v .-.:.7117-71:. < Λ c; < : 1' „ '1 < WK . . ν’, ií C í :i Õ> siy.. Trafíií. í besiPàrrty < (Ô_f 6) i7Wê'-.«'fsi nhÁU-OXt v TTMWséy X U > kOV®-ΆϊίΠ í Ás w&Wíw è >0 whil® roiPsiSv i ífc

ΪΧ frAík. hi^târie.. >·»* 7 ..v i s ,çísíPaW) :i? if ' oi: 'x then

A «<s7tF''.--í7 :'Ά mi-íX-. «ilPirfy;

$.3 rfw ; S -and íí

SS âmâ wkilô

1'? smtó wSsil®

3.δ ''-íií^k.o íh^Fstíy:

[00101] Este alqoritmo cria um histórico sobre confiqurações passadas e usa essas informações para a seleção da quantidade de paridade a ser usada. Opera sob uma janela deslizante de tempo, na qual são recolhidos relatórios de todos os utilizadores ativos (linha 2) . Após atualizar os dados do histórico referentes à confiquração atual (linhas 3-4), procura a melhor confiquração nas informações do histórico (linhas 5-17) e, finalmente, atualiza a quantidade de paridade a ser usada na transmissão em continuo de multidifusão (linha 18).

[00102] 0 nosso esquema de codificação está fortemente associado à nossa estratégia de intercalação de pacotes e ao pedido de transmissão, como uma maneira de maximizar a eficiência do FEC em ambientes WiFi, que são dominados pela perda de pacotes de rajada.

[00103] Numa forma de realização, o Pedido de Intercalação e Transmissão de Pacotes pode ser considerado na presente divulgação.

[00104] Foi adotado um esquema intercalado ajustável, como mostrado na Figura 3, que lida com o comportamento de perda de pacotes de rajada e aleatórios para acomodar diferentes padrões de perda. Para aumentar a eficiência da correção de erros, transmitimos uma matriz de transmissão por coluna e não por linha; usando o exemplo da Figura 3, a ordem na qual os pacotes são enviados é {0, 7, 14, 21, 28, 35, 1, 8, 15, . ..}. Com esta estratégia, podemos dispersar a perda de pacotes por várias linhas.

[00105] No entanto, esta abordagem não lida com a perda de pacotes aleatórios, que foi abordada por nós através da introdução da paridade de colunas. Até agora, deve ficar claro que, se aumentarmos a paridade da coluna, estaremos então a adicionar mais proteção contra perdas de pacotes aleatórios, e a adição de mais paridade de linha fornecerá mais proteção contra perda de pacotes de rajada.

[00106] Numa forma de realização, as Retransmissões de Multidifusão WiFi podem ser consideradas na presente divulgação.

[00107] 0 algoritmo de retransmissão de Multidifusão WiFi da presente divulgação é baseado no conceito de codificação de origem. Embora inspirado nas heurísticas anteriores, ele oferece uma nova abordagem que tem conhecimento do FEC que é capaz de acomodar o serviço de previsão e oferece controlo de largura de banda sobre a quantidade máxima de largura de banda de multidifusão a ser usada. A sua configuração foi orientada pelas limitações do meio subjacente, mais especificamente a quantidade relativamente baixa de largura de banda de multidifusão (acima de 802.11) para retransmissões e a necessidade de processamento rápido para garantir baixa latência (para evitar a falta de prazos de retransmissões). A nossa implementação visou por último a velocidade às custas de alguma precisão, ou seja, não superando possíveis mínimos locais.

[00108] Antes de executar o algoritmo de codificação de origem da presente descrição, a matriz de codificação de rede (NC) contendo as informações de pacotes de cada cliente foi construída. Todos os relatórios enviados periodicamente por cada cliente são recolhidos.

[00109] Cada linha reflete o estado de um único cliente, enquanto cada coluna indica o estado do pacote, que pode estar PACKET MISSING (o pacote excedeu o tempo e precisa de retransmissão), PACKET AVAILABLE (o pacote já foi reconhecido), PACKET NOT AVAILABLE (o pacote não é considerado para uma execução) . O tamanho da linha é dado pelo intervalo fornecido pela diferença entre as sequências de pacotes mínima e máxima (em falta) em todos os clientes.

Algoritmo tabela 2 í gsxGeeàur» “ 7«.sçS.í:í. (j

CCNii^ítíS * . η -1Z : Ϊ <:',· <.<. 5 < J ; &Ο3¥ *·· '. ΓΛ ?ccs.Ϊ cra/ks ’ for y - 4; y ' «Ιλλε; > àc § paekfít -ί- r» ay {y j

Sí íf Ι.ΐίίί.ΐνϊ i JSácXísdi) then sy> ?^C£V.lAv?TLAf.U.£ & «1 ®® xf p-xA^t . x. OC.íi r.oar· x f v-t ' , s rh»n

1: if Od Xí-Í ^χ Ό - U ξ.&όΏ a: if x s> -= 1 i ,s\\ \' < X κ 'Çu .

$ aís® :& if àff,»v.’_s\ > ΐ-ΛΑ iu 0,. ^eS eis® nnvhC ’' VOU-i· XVO\A\'?U\As- .5 là esd i£

J& anú xf

È1S®'>:O. ^ΙίΛΚίίδν^'Μ.^*·/ zl y. >: , áá-iísh-sisí:

end xf

X-.4 »..” ®lS3SÍf>?p/ a ànjsyH'⁴ eisd x£ «Ιββ/ΐΓστ íiRêout»/ áííáyp $

2§ esssá ±£ m if λϊ ®nsá for jl WvtT 'à?r8y;

X j erd preesdssir®

[00110] A construção da matriz NC é realizada através do uso da função auxiliar createMulticastRow (), como mostrado no Algoritmo 2. Essa função é chamada para todos os clientes que excederam o tempo limite de pacotes que requerem retransmissão e onde a variável de argumento pendingArray possui as informações de meta e estado sobre todos os pacotes no intervalo predeterminado.

[00111] Para cada pacote nesse intervalo, a presente solução verifica se já foi reconhecido (linhas 6-8) e, se for o caso, preenche essa coluna em particular com PACKET AVAILABLE. Caso contrário, a solução atual precisa de verificar se o pacote é adequado para retransmissão de multidifusão. Para focar em pacotes mais recentes, temos um limiar predefinido (padrão 2) que limita o número de vezes que um pacote pode ser retransmitido usando multidifusão (linha 11) . Se o pacote estiver abaixo desse limiar, verificaremos então se uma previsão está disponível. Se nenhuma previsão estiver disponível, então a solução descrita sempre considerará o pacote para retransmissão de multidifusão. Caso contrário, a solução descrita usa a previsão (pelo serviço de previsão da solução) para decidir se o pacote deve ser considerado pelo algoritmo de codificação de origem (linhas 15-20) . Se o pacote não tiver excedido o tempo ou se não estiver em falta, então será considerado especulativamente disponível.

[00112] 0 algoritmo de codificação de origem real da solução descrita é mostrado no Algoritmo 3. Ele tenta encontrar a melhor combinação linear entre os pacotes em falta, de modo a reduzir o uso da largura de banda. Ele usa a matriz NC construída chamando createMulticastRow () (Algoritmo 2) para todos os clientes que requerem retransmissões de pacotes.

Algoritmo tabela 3 vísX·: NP Λί’Γΐ\ ν&ϊΐ LXsíSCS^X Js. h // *Ot -’3 3<31 2 3 ί.Ά- i' K.Ji.· 1Λ V v&r }^_Vxx _t' >> .- I - -\ -v- <,

V&JÍ.· // befS’.· -J.ís\Si· Ονϊί'ί.’ί.Γ.'βί.’άΰ.·' of i proc^doír^ Sourç^Cvdxrs; Cmírts l^wC®^fW? O.iírf®5iSwéf .: i f ·. i thé.n ΐ\^:;';.ο.ΐο dmsàsiomò} s ssrA i f . X' í ,> íFX·»·. ' há ΊμΛΙ' th*r>

l «·. :> X · í: Í HÍSAítl otn 0 j <’ esid if s «ví. qs>- ò«:s .Ox^x^ .'c s x.-px. í s j fere^ah wl » ό« :& Ôocsiíi «· sc.o.ypdlwàrCôfVib mij s: if Fi®*çSaSs4 .* ejíTxHitSeçsrè thçn

1? * ηώϊ . Ά >xx'?· i) • 3 fW-sfc^ >í t x 1 : ?<í; \wr_: >«'1 > í 1 ) i hn<xsf'C ISwàpÇ&fttb toS iS rí.-t.urt» íf eçftl, So íx osfxxi 1χ·« íf>wMa*., [irs^Comb, new&s.wl } : -¾ «ÀS»

1? '. v\:.-. «yrtó. Sis^fromh?

X b x&EXSX L f

M @:sid fo-raach a»<s gx«o®dur®

[00113] Dado o espaço de pesquisa potencialmente grande, é imposto um prazo no tempo máximo para este cálculo (linhas 2-4). 0 uso da largura de banda também é estimado e termina o cálculo mais cedo se a cota de largura de banda de multidifusão tiver sido esgotada (linhas 5-7). Por uma questão de clareza, as otimizações de implementação são omitidas, tal como o pré-cálculo dos dados nas matrizes (linha 8).

[00114] A presente solução projetou uma estratégia gananciosa que tenta recursivamente combinar pacotes linearmente das colunas que exibem mais perda de pacotes. Em cada passo, a nova combinação linear é avaliada (linha 10), a pontuação sendo o total de pacotes em falta (considerando o FEC). Quando pacotes adicionais são recuperados do FEC, eles são então atribuídos como PACKET AVAILABLE (para o caso atual) .

[00115] Se a nova combinação melhorar a pontuação atual, então ela será aplicada a uma cópia da matriz NC e o algoritmo será chamado recursivamente (linhas 11 a 15). Por outro lado (linha 17), se a nova coluna não melhorar a combinação linear atual, ela será descartada e a combinação anterior será retornada.

[00116] O subescalonador de multidifusão, mostrado no

Algoritmo 4, chama o algoritmo de codificação de origem enquanto está disponível largura de banda suficiente e o prazo não expirou (linhas 7-9). Neste processo, ele adiciona cada novo pacote (combinação linear de pacotes de origem, linha 10) à lista de retransmissão, retornando-o no final (linha 12).

Algoritmo tabela 4

VSS3V —// »riX

S í !’SWí..S.

y ? if íir^íÇôrsíb - j iô *·· * líwOmb i; end whil® v? Ui : S ensá jjsraftdííure

[00117] Um exemplo da execução do algoritmo de codificação de origem é mostrado em (1). São considerados 4 clientes. A última linha indica o número total de pacotes em falta por coluna. Para o primeiro passo (mais à esquerda), o pacote 2 é aplicado. No segundo passo, 1 φ 3 (combinação linear dos pacotes 1 e 3) é aplicado. Neste ponto, não há mais pacotes em falta. O pacote (2) e o pacote (1φ3) serão transmitidos por multidifusão para todos os clientes.

[00118] Numa forma de realização, os Subescalonadores de Rede de Unidifusão WiFi e 4G podem ser considerados na presente divulgação.

[00119] 0 mesmo algoritmo para suportar retransmissões de unidifusão WiFi e 4G é usado, pois partilham as mesmas restrições subjacentes, isto é, canais de unidifusão sem fios com perdas.

[00120] 0 subescalonador de unidifusão manipula cada cliente separadamente, ao contrário da abordagem usada no subescalonador de multidifusão. Aqui, todos os pacotes que requerem retransmissão por cliente são determinados, para cada matriz de transmissão pendente, isto é, que contém pacotes que requerem retransmissões.

[00121] Antes de chamar o nosso algoritmo de retransmissão de unidifusão, o Algoritmo 6, uma representação da matriz intermediária que usa previsão, se disponível, foi construída como mostrado no Algoritmo 5. Assim como a matriz NC para o algoritmo de retransmissão de multidifusão ganancioso, essa matriz intermediária serve como o espaço reservado temporário.

[00122] Os nossos algoritmos de unidifusão seguem uma abordagem otimista em relação à receção de pacotes retransmitidos. Conforme mostrado na função auxiliar, mostrada no Algoritmo 5, a solução atual desabilita esse comportamento otimista apenas ao executar o algoritmo para 4G, de modo a forçar retransmissões, se necessário (uma vez que o subescalonador 4G é a cauda do pipeline) , ou se a matriz tiver passado metade do tempo limite na tentativa de evitar prazos perdidos, para os subescalonadores de unidifusão de WiFi e 4G (linhas 7-12) .

[00123] Cada matriz de retransmissão pendente foi examinada em busca de pacotes que excederam o tempo que não foram considerados por subescalonadores anteriores do pípelíne, isto é, pacotes que ainda requerem retransmissão (linhas 1617) . Para estes, se não houver uma previsão disponível, então o pacote será considerado para retransmissão (linha 19). No entanto, se uma previsão estiver disponível, então primeiro verificaremos se o pacote tem paridade (linha 21). Como não retransmitimos pacotes de paridade, atribuímos um estado de PACKET MISSING apenas para indicar que ele não foi reconhecido, mas não será considerado para retransmissão (necessário para verificações apropriadas de recuperação do FEC). Para pacotes de origem, é realizada uma avaliação para determinar se o pacote será recebido pelo cliente (linhas 24 a 28) .

Algoritmo tabela 5 í/ i f ítiFf, AiAi 3-3 irax: hasátbirA // ' pr<sced«re f i À t ?: «» < r ?. / ; «ϊρ4ΪΛί>ϊΐ3!ί. *· t. .Wc: í ÍS-»f?-'í-íL«t -S·· ;

í síxxx < peso; sym. , rows í 1 3 íôkifnf^ pend·! .<zolVW>sO 8 ísA í— ί.ΓΛ :w«si [»?κΐ5·:8: ” i£ <»A t < «3 fehes s &ijí.íísss3;o «“ U;s^:í í 2 if . j. aiAsι Η* 1 i ϊ is^ous. i j ther.

i: ορΑ'Αρρί.· ísiss?

U «Kd. if Í3 ÍOS s - 8; >: < rCAS; X r~: d<S is for y “ 0; y ’. aclwa-r.a; ys - do . 3 B*ík8S pe od: íipda U .í ; í v ;

< ií pàfeked. isTiíxeoei (i fedes í ' àf p-K-fe. : sl® s :A :vs ; tsseo Js if iw&dif.fewírs » -.5 t'h»â. 13 ifeAS x ) Ϊy| * .ί-Α·'1ΕΛ\3Γί35ϊ·3« '. ela s A-»' i t h p r o At c i i ο n * / i£ £·μ><.·κ·5?Ϊ . '. sP*í:;.ty {i theii :A iyí *“ ^A^KET.ÍÍISnn^G is β 1 a« / * .ο» ~ pí r i : y χ / sá f ϊγλ . ⁴ í.?5âS $··· dld. Of: ^f. G * :.C8 ií P'31 ρ^'.·’·ιν fede» ;' ^«.cs-gtReCeívsS * i«2se . S ir if == >.Σ'« tb.es 'fed \\ s \ '

3i eis® v -i· iA<^sa\Av.AA?^^ es.d if

3s ®ssd if 33 essd â£

3v »X«eZ*not rsi ssi-rsq*/ ' ' if óy-réA.g -- ; ϊ ·λ« £h&»

ÍSMÍA.] í® 13 3 eis® í, χ”ί x Ά x' í^tí^tbsí A ΑΛΛ i t

A esd sf is elsWxc-dt tueesjatW ss if opdmisde true I&S&

~ maífxHyi ζμ:κ£τ®λ7α;.α«:.ε 33 else í “ màs · X s (y. í 3- ^íástFts.. i S ÃóWd í 3:

«.«d if c 1 ead i£ 3y eilsS far ΐ 1 end for »(fsatj ‘ i end ps-OdeAír^

[00124] Se for previsto que o pacote seja recebido, então ele será considerado para retransmissão (linha 30), caso contrário, será atribuído, para o caso atual do algoritmo em execução, como PACKET AVAILABLE (será contabilizado como disponível pelo algoritmo de descodificação FEC) e é adiado para retransmissão em estágios posteriores do pípelíne (linha 32) . Deve-se notar que essa alteração de estado é aplicada apenas à representação intermediária, e não ao estado atual do pacote pendente.

[00125] Para todos os pacotes que não excederam o tempo limite (linha 16) e que não estão em falta (linha 17), temos dois resultados possíveis. Se o comportamento otimista (linhas 37 e 44) estiver ativo, é assumido que o pacote está disponível (linhas 38 e 45), caso contrário, usa-se o marcador do pacote de acordo com seu estado de reconhecimento (linhas 40 e 47, usando a função está Acked ()).

[00126] Depois de construir a representação intermediária de uma matriz de retransmissão pendente, o algoritmo de retransmissão de unidifusão pode continuar para o chamamento, mostrado no Algoritmo 6. É também um algoritmo ganancioso que utiliza a codificação FEC para minimizar o número de pacotes necessários para retransmissão, para que o cliente possa recuperar com êxito os dados em falta. Ele retorna a lista completa de pacotes originais necessários para recuperar toda a matriz de retransmissão pendente, a menos que o prazo tenha decorrido ou a cota de largura de banda de unidifusão tenha sido esgotada (linhas 4-9).

Algoritmo tabela 6 var: fee // « à gor.r t ή;?· bs ns&d var: bandííxdfSi. // iPi&ibz' & Inibia bfsn-ataidrh var: deatáiine // for >s i g<srr t àra executíon var: isíAfr // t me j Y ^111, fãlS® fOX 4G wr: kasáSLi^ // dg viçg AA ^roCèdur e Un.-. r a stGre^rfyScneda 1 sv i

S m «·· A. r i x ipetKÉiti&Matf while : íae. . eCar aCDKip.':m? (Bàs do <s if dodesse > rxcw (í then re t« r d g i rwarComb) é end if if Used£«r>dwi.<íth (pl-tL^t-sia·® (} ΐ· 11 > bâMwiíMr ther.

$ x ® tvixm (pkt List í efi.d xf ié tíw *·· unas. gftv.Rciw^ :.-. íiLess^r^kt.? ()

Á · CfJ í· tfkLt. ·:5<ίν o UaU -. V; f-&SSW :U: Í.f gKC.Vs. S í. : DÇjfk”:; ; < «f .

than

Síí t . i i 1 1 Oswf >. r .;. :·;ΓχΟΚ f IS ®ls® i5 mat. i i 1 iQrs^Fkí TrsCol icol 1

IS- esd i£ i '? end whil e

3B £ozâach (x.«) λλ dd1S if mat. is8kt5’íis«xn^í? íx. yf and

J rnaf. i sPktFECRsícove rs_:ò bg 7J thes

3Ú pklL&i í- p^lLiàt ·♦· ϋ «rsd if . 3 «isd f oreach rv?:í3ríL{pHfLb!.j

3·$ ssid pxocedure

[00127] Para cada iteração, ele compara qual a linha (linha 10) ou coluna (linha 11) que tem menos pacotes em falta, usando as funções getRowWithLesserPkts () e getColWithLesserPkts (), respetivamente. Em seguida, ele tenta preencher um pacote, numa linha (linha 13) ou numa coluna (linha 15) . Nos dois casos, ele considera apenas pacotes que não são recuperáveis usando o FEC, ou seja, ao procurar um pacote numa linha, considera apenas aqueles que não são recuperáveis usando paridade de coluna e vice-versa.

[00128] 0 procedimento termina com o retorno de todos os pacotes que foram selecionados nas várias iterações, excluindo os que podem ser recuperáveis usando o FEC (função isPktFECRecovered ()) (linhas 18-23).

[00129] Numa forma de realização, a Análise de Complexidade pode ser considerada para fornecer uma análise mais detalhada da presente divulgação, uma análise de complexidade para os vários mecanismos é apresentada na Tabela 3.

[00130] É assumido que o fluxo é composto por um conjunto discreto de matrizes. Como uma matriz atua como uma época, todos os seus pacotes partilham a mesma época comum. O prazo (absoluto) D associado a uma época é calculado adicionando um deslocamento relativo, por exemplo 2s, para o relógio de parede (no momento da criação da matriz). Todos os pacotes pendentes são considerados perdidos após o prazo. Por sua vez, as retransmissões ocorrem periodicamente em intervalos Rint, por exemplo, 200 ms, até D, permitindo até R = D/Rint ciclos de retransmissões.

[00131] A matriz é transmitida inicialmente via multidifusão, do servidor para todos os clientes, oferecendo um padrão de comunicação um-para-todos em cima da primitiva de multidifusão da rede e, assim, dando-nos complexidade de 0(1) bi ts.

[00132] Se a paridade presente na matriz for suficiente para superar a perda de pacotes no momento da transmissão, então não serão necessários mais ciclos de comunicação. Caso contrário, não havia paridade suficiente para atender às condições da rede e são necessários ciclo(s) adicional(ais) de retransmissão, potencialmente até R ciclos, para garantir a entrega de pacotes em falta.

[00133] Como mostrado anteriormente, o servidor usa um processo de escalonamento para otimizar as retransmissões. Para cada ciclo, os pacotes em falta podem ser retransmitidos usando multidifusão (WiFi) ou unidifusão (WiFi, 4G) . A retransmissão de multidifusão usa uma combinação linear de pacotes para superar vários pacotes em falta num conjunto de clientes. Na melhor das hipóteses, um único pacote é recuperado em cada cliente, dando-lhe uma complexidade de 0(1) bíts, enquanto, na pior das hipóteses, apenas um único pacote é recuperado em todo o conjunto, dando-lhe uma complexidade de 0(n) bíts.

[00134] Ao usar unidifusão para retransmissão, tanto para WiFi quanto para 4G, o servidor replica cada pacote individual entre os n clientes autenticados, fornecendo assim uma complexidade de 0(n) bíts que exibe um padrão de comunicação um-para-todos.

[00135] 0 íris possui um mecanismo de continuidade de chave interna, em que cada matriz possui a próxima chave simétrica para a sessão de transmissão em continuo, com a rotação da chave ocorrendo periodicamente em intervalos predefinidos. Se uma condição de rede grave impedir que um cliente receba um pacote por mais que esse intervalo, então o cliente perderá uma rotação de chave. Para solucionar este problema, ocorre uma renegociação baseada em SSL, na qual o cliente recebe as chaves em falta necessárias do servidor. Se a interrupção da rede for global, então todos os clientes solicitarão a renegociação de chave, levando à complexidade de 0(n) bíts.

Tabela 3: Complexidade da presente divulgação

Filiação dvavs

[00136] Os serviços de filiação são baseados num handshake baseado em SSL, em que cada cliente se autentica no servidor, exibindo assim uma complexidade de O(n) bíts.

[00137] Por último, a nossa implementação atual de partilha de carga D2D força todos os nós a solicitar periodicamente pacotes em falta de todos os seus vizinhos, levando à complexidade de O(n2) bíts, num padrão de comunicação todospara-todos.

[00138] Numa forma de realização, a Segurança pode ser considerada pela introdução de nós não confiáveis, via edge clouds, exigindo a configuração de protocolos seguros desde o inicio. Além disso, é assumida a presença de fluxos selecionados de feeds institucionais, por exemplo, equipas desportivas, museus e, portanto, exigindo integridade do fluxo. Ao mesmo tempo, é necessário ter um forte mecanismo de autenticação e autorização.

[00139] Numa forma de realização, o Modelo de Ameaça pode ser considerado pelo modelo de ameaça que considera dois tipos de adversários. O primeiro tipo tentará injetar fluxos indesejados no sistema, enquanto o segundo tipo tenta abusar da rede P2P fornecida pela edge cloud.

[00140] Numa forma de realização, os certificados de chave pública de Autenticação, Autorização e Modelo de Confiança são usados como a base para o modelo de identidade. Se o cliente não tiver um certificado, ele inicia gerando uma nova solicitação de assinatura de certificado (CSR) e enviaa à autoridade de certificação (CA) para que possa ser assinada. O token seguro externo para assinar esta solicitação de certificado não é usado, mas pode ser facilmente integrado na nossa infraestrutura ou, alternativamente, usando um canal lateral seguro para efetuar a validação do CSR.

[00141] Esta parte é considerada dependente da instituição de destino que hospeda o sistema. Obviamente, a não implementação de uma maneira eficaz de validar os CSRs deixaria o sistema aberto aos ataques de Sybil. Embora a criação de múltiplas identidades seja útil para ataques de desempenho, isso não afetará a integridade do fluxo.

[00142] O esquema de autorização descrito depende de autenticação forte, em que o cliente apenas é capaz de transmitir ou participar na edge cloud somente se tiver um certificado assinado pela nossa CA. Como os utilizadores trazem os seus próprios dispositivos e podem se desviar do protocolo original, impomos este modelo de confiança rigoroso. No entanto, as edge clouds exigem que seja necessária alguma confiança para mesclar nós vizinhos, em particular para nós que hospedam grupos herdados do WiFiDirect, ou seja, pontos de acesso à Internet sem fios. Por natureza, a presença de nós maliciosos afetará apenas o desempenho e não a integridade, uma vez que apenas os trechos de video assinados digitalmente pelo nosso servidor confiável são considerados para reprodução. Se um nó retiver maliciosamente pacotes de retransmissão ou rejeitar conexões P2P, então teremos que fazer um fallback para a infraestrutura sem fios (WiFi AP ou 4G) ou outros nós da malha.

[00143] Numa forma de realização, o Sigilo de Encaminhamento e a Integridade do Fluxo são garantidos ao impor a rotação da chave ao longo da vida útil do fluxo. A rotação da chave é governada por épocas, em que a época é uma quantidade definível de matrizes de transmissão em continuo, por exemplo, uma nova época a cada 20 matrizes. Cada pacote de transmissão em continuo inclui a chave da próxima época, encriptada com a chave da época atual. Isso evita a necessidade, no trajeto livre de falhas, de usar permanentemente um canal seguro para recuperar essas chaves. 0 trajeto livre de falhas é considerado quando as matrizes são recuperadas sequencialmente sem lacunas. Para que essas lacunas ocorram, uma matriz precisa atingir o tempo limite sem reter nenhum pacote de dados, por exemplo, perda prolongada da associação WiFi com a AP.

[00144] A presença de lacunas nas matrizes de transporte requer a configuração do mecanismo de fallback. Para esse propósito, uma infraestrutura TLS segura é usada para recuperar as chaves em falta do nosso servidor.

[00145] Numa forma de realização, o Esquema de Assinatura Dupla pode ser considerado para garantir a integridade do fluxo, autenticação e não repúdio, sendo todos os pacotes sinais digitais. Seria muito caro ajustar assinaturas RSA, que deveriam ter pelo menos 2048b~256B de comprimento, nos nossos cabeçalhos UDP. Uma alternativa seria agrupar pacotes e efetuar uma assinatura no conjunto, mas um pacote em falta impediria a verificação da assinatura. Em vez disso, numa forma de realização para obter melhores resultados, foi usada uma criptografia de curva elíptica, a saber ECDSA prime256vl de 256 bits [24], que impõe apenas uma sobrecarga de ~72B por pacote.

[00146] Foi utilizado um esquema de assinatura dupla, como mostrado na Figura 6. A assinatura de pacote permite a verificação da identidade do remetente, que é o servidor confiável ou um nó na edge cloud, enquanto a assinatura de dados de vídeo permite a verificação do criador do trecho, que sempre se origina do servidor confiável.

[00147] A reconstrução de um pacote em falta por um nó, como mostrado na Figura 7, usa o trecho de vídeo recuperado para criar um novo pacote que é depois assinado usando a chave privada do nó. Quando este pacote é partilhado com outros nós, eles usam a assinatura do pacote para verificar se o remetente está realmente autorizado a fazê-lo. Isso foi seguido por uma segunda verificação na assinatura do trecho de vídeo, que é comparada com o certificado do servidor confiável (e descartada se falhar) . Observe-se que, se uma assinatura de pacote pertencer à entidade confiável, a verificação do trecho de vídeo não será mais necessária, permitindo uma redução da carga computacional. Mesmo se um nó mal-intencionado tentar introduzir um trecho de vídeo corrompido, ele não conseguirá, pois não possui a chave privada do servidor confiável. Somente o servidor confiável é capaz de criar novos trechos de vídeo, garantindo assim a integridade do fluxo o tempo todo.

[00148] Numa forma de realização, a Segurança-como-serviço para Edge Clouds Móveis pode ser considerada pelos tokens seguros gue são usados para autorizar as conexões entre os nós na edge cloud. Esses tokens são gerados apenas no servidor e enviados aos nós da edge para fornecer autorização para ligações P₂P locais para Bluetooth e WiFi Direct (P2P e ponto de acesso à Internet sem fios) . No caso do Bluetooth e do WiFi Direct P2P, o token seguro também serve como um método de autenticação alternativo. Isso permite-nos configurar conexões sem exigir a interação do utilizador, como inserir um PIN, o que dificultaria a usabilidade.

[00149] Para o WiFi Direct no modo de ponto de acesso à Internet sem fios, o token seguro substitui a autenticação baseada em senha. Depois de se associar a um ponto de acesso à Internet sem fios, o cliente precisa de enviar o seu token seguro para provar que tem permissão para ingressar, caso contrário, será desassociado. Isso foi feito para garantir que, se a senha gerada pelo Android for transmitida, apenas clientes autorizados terão permissão para ingressar na rede em malha.

[00150] Numa forma de realização, a Partilha de Carga em Edge Cloud Móvel pode ter impostas várias restrições na construção de edge clouds. Ao se opor à abordagem ad-hoc normal da construção de rede em malha que usa mecanismos de baixo nivel, como o Multicast Network Service Discovery (DNS), esta gestão e descoberta são centralizadas no nosso back-end. Este é um mandato essencial dos requisitos de configuração para se ajustar a diferentes cenários de implantação. Além disso, garantimos que as conexões locais sejam autorizadas, portanto, nenhuma ligação P2P é estabelecida sem as credenciais adequadas ou os tokens seguros.

[00151] As conexões WiFi Adhoc não são usadas, pois exigiria que os dispositivos fossem enraizados (do Inglês rooted) .

[00152] Numa forma de realização, o Bluetooth pode ser considerado na presente divulgação.

[00153] 0 Bluetooth Low Energy (BLE) não foi considerado e usou-se apenas a versão Bluetooth (BT) 4.0 para aumentar a capacidade de largura de banda. Teoricamente, o BT é capaz de atingir 2Mbit/s por curtos intervalos. Observe-se que essa largura de banda é partilhada entre todas as conexões ativas, portanto, aumentar o número de vizinhos resultará em menor largura de banda por conexão/ponto.

[00154] Numa forma de realização, o WiFi-Direct pode ser considerado na presente divulgação.

[00155] Atualmente, apenas o Android suporta a especificação WiFi Direct. A Apple fornece uma abordagem alternativa com base nos seus processos multipeer e bonj our, que são considerados fora do âmbito.

[00156] 0 suporte no Android para WiFi Direct vem em dois tipos, um é uma ligação P2P verdadeira que permite ao dispositivo manter acesso a um ponto de acesso, e o outro é um modo legado que fornece um ponto de acesso à Internet sem fios que permite que outros dispositivos se conectem a ele.

[00157] Para o primeiro método funcionar, foi necessário recorrer à reflexão para evitar a confirmação manual do utilizador de cada ligação estabelecida com o seu dispositivo (por meio de uma janela pop-up). O Android não fornece uma permissão para evitar esse comportamento (apesar de ser solicitado ativamente pelos agentes de desenvolvimento). O próximo suporte à especificação WiFi-Aware no hardware de dispositivos Android fornecerá um suporte limpo para o uso de conexões WiFi P2P. Atualmente, apesar de ser suportado pelo Android Oreo, apenas recentemente os dispositivos começaram a fornecer suporte para ele, como o Samsung S9 (versão europeia do exynos).

[00158] Para o segundo, o nó que hospeda o ponto de acesso à Internet sem fios, chamado Proprietário do Grupo (GO) , ainda pode manter uma conexão com o ponto de acesso, enquanto os clientes associados ao ponto de acesso à Internet sem fios não podem manter uma ligação para o ponto de acesso. O Google oferece uma implementação um tanto limitada para o WiFi direct, pois não permite que qualquer configuração de rede seja executada (a sub-rede é fixa como 192.168.49.0) .

[00159] Uma limitação adicional é a falta de conectividade com a Internet pelos clientes, pois o ponto de acesso à Internet sem fios não fornece NAT pronto para uso. Uma solução alternativa para esse problema pode ser obtida implantando um proxy HTTP embutido na aplicação. Eles não requerem acesso à root, pois podem ser totalmente implementados ao nível da aplicação. A implementação da solução atual contém um proxy HTTP(s) que permite que os dispositivos dos clientes mantenham a conectividade com a Internet.

[00160] Numa forma de realização, a Partilha de Carga em Edge-Cloud pode ser considerada na presente divulgação.

[00161] A abordagem de partilha de carga da presente divulgação é ativamente adotada pelos dispositivos móveis. O back-end fornece apenas serviços de segurança e descoberta para dar suporte à construção da rede em malha. Cada dispositivo individual deve solicitar periodicamente aos seus nós vizinhos os pacotes em falta. A partir de agora, as solicitações de pacotes em falta estão distribuídas uniformemente por todas as topologias de rede em malha disponíveis, ou seja, BT e WiFi Direct.

[00162] Numa forma de realização, a Implementação de Frontend pode ser considerada na presente divulgação.

[00163] A implementação da presente divulgação pretendia fornecer uma abordagem portátil para que futuras portas pudessem ser facilmente realizadas. Aqui está ilustrada a implementação do Android, com os vínculos específicos ao sistema operativo Android.

[00164] Embora os OSes móveis normalmente forneçam um processo de média, por exemplo, MediaCodec para Android e VideoToolBox para iOS, o objetivo era alcançar um reprodutor multimédia capaz de lidar com a aceleração de hardware para descodificação de video.

[00165] Numa forma de realização, o Reprodutor Multimédia Portátil pode ser considerado na presente divulgação: A presente divulgação depende do VLC, um projeto de código aberto bem conhecido que suporta a aceleração de hardware no Android e iOS, enquanto fornece uma infraestrutura de decodificação de software, usando ffmpeg, como fallback. A presente divulgação integra-se sem descontinuidade no reprodutor multimédia adicionando um novo protocolo de transporte para ffmpeg, íris dobrado. Isso foi conseguido com a implementação de um novo módulo de transporte que consiste em quatro primitivas, a saber: a) abrir, b) ler, c) procurar e d) fechar.

[00166] Numa forma de realização, a Biblioteca de Multidifusão Fiável Segura e Portátil pode ser considerada na presente divulgação: Por conveniência, foi implementada uma única biblioteca que contém código de front-end e backend, uma vez que uma quantidade significativa de código é partilhada entre os dois. No entanto, para uma melhor organização, fazemos amplo uso de namespaces, do Português espaço de nomes, e seguimos uma configuração de projeto semelhante a Java para arquivos, ou seja, cada sub-namespace num diretório separado, seguindo uma hierarquia de árvore. O código é implementado usando C/C++ num esforço para tornálo portátil e eficiente. Atualmente, possui 31 mil linhas de código C/C++ e 1 mil de código Java. São aproveitadas as bibliotecas de código aberto existentes para redes (poco), codificação de eliminação (openfec) , ordenamento (protobuffers) e criptografia (openssl) . Além disso, foi usado o RPC (grpc) para conectar a base de código C++ de back-end da presente solução com WEKA [31], para o serviço de previsão.

[00167] Numa forma de realização, o Front-end Especifico de Android pode ser considerado na presente divulgação: Para reduzir a latência, foi projetado um serviço Android que executa em segundo plano e executa toda a gestão necessária para suportar o sistema de transmissão em continuo seguro da presente solução, mais especificamente, validação de certificado, entrada em sessão e configuração da edge cloud. Usando essa abordagem, pode de imediato iniciar a transmissão em continuo com suporte de edge cloud desde o inicio.

[00168] Este serviço Android, representado na Figura 8, fornece um manipulador de servidor que permite a gestão de fluxo a partir de aplicações de clientes. O lado do cliente é implementado como um plug-in VLC. Fornecemos uma nova camada de transporte com o único objetivo de interagir com o seu serviço (parte mais à esquerda da imagem).

[00169] 0 serviço Android da presente divulgação fornece suporte para edge clouds e transmissão em continuo. Cada fluxo é tratado por um IrisCient separado, correspondente a um fluxo de multidifusão independente. Note-se que o suporte para edge clouds é modular e é partilhado por todos os fluxos presentes no sistema. Ao desativar este módulo, estamos apenas a remover a capacidade de partilha de carga, mas o sistema continua a funcionar conforme o esperado, ou seja, depende apenas da infraestrutura para obter o(s) fluxo(s) usando WiFi e possivelmente 4G.

[00170] Dentro de cada IrisClient, a solução descrita possui manipuladores de rede para receber pacotes UDP de multidifusão (Recetor de Multidifusão) e unidifusão (Recetor de Unidifusão de Retransmissão). O Key Store fornece toda a gestão de chaves necessária, como chaves simétricas usadas no fluxo de multidifusão, tokens seguros usados para edge clouds e certificados para PKI.

[00171] 0 módulo Proprietário do Grupo oferece a funcionalidade Grupo WiFi (Ponto de Acesso à Internet sem fios), que inclui retransmissões, gestor de filiação e um remetente de multidifusão. O primeiro, tem o mesmo objetivo que o encontrado no back-end, menos a capacidade de executar a codificação de origem. Essa solução de configuração foi criada para minimizar a sobrecarga computacional no dispositivo.

[00172] Numa forma de realização, a Camada de Adaptação do Android pode ser considerada: O front-end interage com a Dalvik ATM por meio da Interface Nativa Java (JNI) padrão. Isso é necessário para aceder a partes da API do Android que não possuem ligações nativas, ou pelo menos públicas. É evitado o uso de bibliotecas API privadas para aumentar a compatibilidade, pois as suas modificações podem potencialmente quebrar a nossa abordagem. Além disso, certos subsistemas, como o Bluetooth, estão disponíveis apenas através do esquema de permissão regular, que, por sua vez, estão disponíveis apenas nas APIs Java.

[00173] Para evitar o problema de ter que expor uma API grande por meio da JNI e facilitar o ajuste às novas chamadas do sistema, um mecanismo RPC genérico baseado em protobuffers foi implementado para abstrair as chamadas entre o nosso código C/C++ e Java. A adaptação da solução descrita possui dois componentes principais, um gestor de Bluetooth e um gestor de WiFi. O primeiro suporta todo o encanamento necessário para oferecer uma interface orientada a ficha de alimentação, incluindo chamadas de sistema ao nível da ficha de alimentação de baixo nível, como ler (), escrever (), fechar (), escutar () e conectar () . Todas as operações relacionadas a WiFi são tratadas pelo nosso gestor de WiFi, que suporta a gestão de WiFi-Direct e de infraestrutura WiFi, incluindo a criação e destruição de grupos de WiFi e associação e dissociação de e para SSIDs de WiFi.

[00174] Numa forma de realização, a Avaliação pode ser considerada na presente divulgação.

[00175] A avaliação está centrada em três preocupações principais, a saber, latência inicial do vídeo, largura de banda usada no ponto de acesso e, finalmente, energia usada pelos dispositivos móveis. Dado o espaço combinatório para todos os parâmetros presentes no sistema da solução descrita, seria intratável realizar uma análise completa de todas as combinações possíveis.

[00176] Esta avaliação é para demonstrar praticamente a viabilidade da sua abordagem. Primeiro, é fornecida uma comparação com o estado da técnica sem o uso da partilha de carga em edge cloud, uma vez que essas abordagens carecem de suporte para tal. Isso servirá como uma medida de desempenho da linha de base em relação à economia de largura de banda pela infraestrutura e latência experimentada pelos utilizadores, enquanto experimenta níveis variados de condições de rede.

[00177] Na segunda parte da avaliação, a partilha de carga em edge clouds é incluída num esforço para avaliar o impacto que tem na solução de base e verificar empiricamente os seus méritos para responder às perguntas colocadas na declaração do problema atual.

[00178] Numa forma de realização, a Configuração e Metodologia Experimentais podem ser consideradas na presente divulgação.

[00179] A configuração experimental é composta por 28 dispositivos móveis, incluindo 8 dispositivos Nexus 5X e 20 Samsung. Todos os dispositivos usaram o Android 7 (Nougat). Devido a problemas com o Nexus 5X em relação às comunicações D2D, eles foram excluídos da segunda parte da avaliação (com partilha de carga em edge cloud) .

[00180] Todos os dispositivos e um ponto de acesso Cisco 3700 numa área de 2 m² foram descartados. A AP foi configurada para usar um canal de 40 MHz em canais fixos, manteve os 100 ms padrão para a intercalação de beacon, alterou o DTIM (Mensagem de Indicação de tráfego de entrega) de 2 para 1 e desativou todas as taxas básicas abaixo de 24 Mbps.

[00181] Cada teste foi realizado 5 vezes, com uma duração de 5 minutos para cada execução. A codificação de video foi realizada usando a aceleração de hardware NVENC para HEVC da NVIDIA, suportada por uma GPU ASUS GTX 1060. Por fim, foi utilizado um servidor Intel Haswell 6 core com 32 GB de RAM.

[00182] Numa forma de realização, a Avaliação Comparativa Sem Edge clouds pode ser considerada na presente divulgação.

[00183] Para avaliar a abordagem, sem a partilha de carga em edge cloud, ela foi medida em relação ao HTTP Transmissão em Direto em Continuo (HLS) (que é o padrão atual para transmissão em direto em continuo por unidifusão, serve como linha de base), StadiumVision e Streambolico (C4S) da Cisco. Nos últimos dois, e como são soluções de código fechado, foram realizadas alterações na plataforma da presente solução, incluindo alterações no código de origem e nas configurações, para acomodar as descrições de sistema da Cisco e Streambolico.

[00184] Para a Streambolico, o suporte da unidifusão foi removido e configurado o sistema para não usar o FEC. Para essa finalidade, a matriz de transporte foi projetada num vetor de dimensão 4 (isto é, uma matriz com uma única linha e 4 colunas). Para a Cisco, também foi desativada a unidifusão e configurado o FEC para ~150% sobre os pacotes de origem originais, apresentando 4 linhas, 4 colunas de dados, 1 linha de paridade e 1 coluna de paridade (representando 25 pacotes totais em 16 pacotes de origem para uma sobrecarga de 156,25%).

[00185] 0 máximo aconselhável do uso de multidifusão deve estar entre 30% a 40% da largura de banda total disponível, conforme indicado pelos principais fornecedores de rede. Assumindo o pior cenário, com clientes a conectarem-se a uma taxa de 24 Mbit/s, e usando uma taxa de 30%, então haverá 7,2 Mbit/s de multidifusão. Como a presente solução ainda precisa de acomodar o fluxo de multidifusão original que vai até lOOOKbit/s (sem considerar o FEC), foi decidido definir um limite rígido de 6 Mbit/s de largura de banda de multidifusão para retransmissões, tanto em C4S como em íris. Além disso, para o íris, foi definido lOMbit/s como o limite máximo para unidifusão WiFi e 2Mbit/s para unidifusão 4G dentro dos gestores de largura de banda, por cliente.

[00186] Foram avaliadas três taxas de bits, incluindo 250 Kbit/s (baixa qualidade), 500 Kbit/s (qualidade média) e 1000 Kbit/s (alta qualidade), em três conjuntos distintos de clientes contendo 7, 14 e 28. Além disso, a perda de pacotes para testar a robustez foi introduzida artificialmente. Foi variada essa perda entre 0%, 20% e 40% e, em condições estáveis, a 802.11η já introduz até 10% de perda de pacotes, a perda final de pacotes introduzida nas várias experiências varia de [0,10]%, [20,30]% e [40,50]%.

[00187] Em todas as legendas, o último número reflete a taxa de bíts usada, por exemplo, íris 4G 1000 usa uma taxa de bíts de 1000 Kbit/s. Todos os resultados mostram média com intervalo de confiança correspondente de 95%.

[00188] Numa forma de realização, a Transmissão em Direto em Contínuo Apenas Usando WiFi pode ser considerada na presente divulgação.

[00189] O desempenho da presente divulgação contra HLS, StadiumVision e C4S, foi analisado principalmente sem suporte 4G. Isso foi feito para fornecer uma linha de base, pois apenas o íris é capaz de suportar 4G. Consequentemente, o serviço de previsão do íris foi desativado por não ter capacidades de trajetos múltiplos.

[00190] Numa forma de realização, o Uso de Largura de Banda - Somente WiFi pode ser considerado na presente divulgação.

[00191] 0 uso da largura de banda é mostrado na Figura 9. Deve ser observado que, como o HLS usa HTTP(S) que executa em cima do TCP, ele é exposto às suas limitações inerentes. A mais problemática é o retorno exponencial para cada retransmissão que é mais adequado para conexões com fios e não para ligações sem fios. Por esse motivo, não foram considerados os resultados do HLS para taxas de perda de pacotes acima de 10%, uma vez que a transmissão em continuo seria interrompida continuamente.

[00192] Como o StadiumVision usa uma configuração multidifusão fixa, requer uma quantidade fixa de largura de banda de ~22, ~40 e ~74 MB para 250, 500 e 1000 Kbit/s, em todas as taxas de perda de pacotes e independentemente do número de clientes.

[00193] Numa forma de realização, para [0,10]% de perda de pacote: o HLS exibe um uso máximo da largura de banda de download de ~1120 MB (e 34 MB para upload) com 28 clientes. De um modo geral, o HLS tem o desempenho esperado, dobrando a largura de banda de download usada, pois a taxa de blts ou o número de clientes é dobrado. O C4S e a divulgação mostram um aumento linear da largura de banda de download com o dimensionamento linear da taxa de blts e dos clientes. Quando comparada ao C4S, a presente divulgação usa ~136 MB contra ~80 MB do C4S, enquanto usa 1000 Kbit/s e 28 clientes.

[00194] Numa forma de realização, para [20,30]% de perda de pacotes: a diferença entre C4S e íris fecha-se. Apenas olhando a largura de banda de download usada, parece contraintuitivo que isso aconteça. No entanto, isso é explicado com a introdução dos dados referentes a prazos perdidos (Figura 10).

[00195] Numa forma de realização, para [40,50]% de perda de pacotes: a presente divulgação requer mais que o dobro da largura de banda de download quando comparado ao C4S. Isso deve-se ao uso da largura de banda de unidifusão pelo íris, que oferece apenas capacidade de retransmissão 1 para 1, e não o 1-n da multidifusão. No entanto, a oferta de QoE da C4S é bastante impactada pela sua configuração.

[00196] A presente divulgação utilizou ~251 MB de largura de banda de download e ~15,5 MB de largura de banda de upload, enquanto o C4S usou ~90 MB e ~20 MB, em média, para download e upload, respetivamente. O aumento do uso da largura de banda de upload pelo C4S é indicativo de que os relatórios enviados pelos clientes são maiores que os enviados pelos clientes do íris. Isso significa que o número de matrizes que possuem pacotes em falta é maior no caso do C4S e, portanto, exibe um mecanismo de transporte menos eficiente.

[00197] Numa forma de realização, os Prazos Perdidos Escalonadores apenas de WiFi podem ser considerados na presente divulgação.

[00198] A Figura 10 mostra, numa forma de realização, o número de prazos perdidos com o número crescente de clientes e a taxa de blts e taxas variáveis de perda de pacotes. O StadiumVision revela o pior comportamento do grupo, com prazos perdidos a dobrar a cada aumento na taxa de bíts para todos os cenários de perda de pacotes. Na pior das hipóteses, o StadiumVision exibe ~6460, em média, para 28 clientes ao usar uma taxa de bíts de 1000 Kbit/s quando exposto a [40,50]% de perda de pacotes.

[00199] Numa forma de realização, para [0,10]% de perda de pacote: as perdas são residuais para C4S e para a presente divulgação. Para o StadiumVision, exibe ~497 prazos perdidos que, embora aparentemente pareçam baixos, têm um impacto visível na qualidade da transmissão em continuo. Se um prazo em falta afetar um quadro-chave, isso significa que o video ficará paralisado até que o próximo quadro-chave esteja disponível, enquanto que num caso menos grave, afetará os quadros B ou P que introduzirão imediatamente artefactos com níveis variados de impacto, dependendo principalmente do dinamismo da cena, por exemplo, imagens desportivas serão mais afetadas do que um desenho animado lento.

[00200] Numa forma de realização, para [20,30]% de perda de pacotes: o C4S tem ~117 prazos perdidos que começam a afetar severamente a qualidade do fluxo, para 28 clientes e taxa de bíts de 1000 Kbit/s. Os prazos perdidos do StadiumVision atingem ~1715 para a mesma configuração. Ambas as abordagens têm aumentos lineares na escala de clientes e taxas de bíts.

[00201] Numa forma de realização, para [40,50]% de perda de pacotes: o StadiumVision e o C4S não conseguem fornecer um fluxo fiável, apresentando um alto nível de corrupção de video e paralisando todas as configurações. Para 28 clientes e taxa de bíts de 1000 Kbit/s, o StadiumVision possui ~6460, enquanto o C4S tem ~3772 prazos perdidos, em média.

[00202] O íris é a única abordagem que tem prazos perdidos residuais em todas as configurações e taxas de perda de pacotes.

[00203] Numa forma de realização, a Latência - Apenas WiFi pode ser considerada na presente divulgação.

[00204] A latência é uma métrica bem conhecida para avaliar QoE e foi demonstrado que os utilizadores interromperão o fluxo de video se o video não iniciar dentro de 5 segundos. Mostramos esse limite rígido com uma linha horizontal na Figura 11. O C4S é a única abordagem que não consegue atender a esse requisito mantendo-se estável acima de 5s e, no pior caso, [40-50]% de perda de pacotes com 28 clientes e taxa de blts de 1000 Kbit/s, a sua latência atinge aproximadamente 9s. O StadiumVision é capaz de permanecer abaixo desse limite para perda de pacotes abaixo de 30%; mas para perdas de pacotes mais altas, não é capaz de estar abaixo desse limiar, atingindo um máximo de 8716 ± 3289 de latência.

[00205] Numa forma de realização, o íris oferece a melhor latência: que é capaz de vencer o HLS, com uma latência mínima de 861 ± 117 ms e um máximo de 2014 ± 642 ms para todas as configurações.

[00206] Numa forma de realização, a Transmissão em Direto em Contínuo Usando Trajetos Múltiplos (WiFi e 4G) pode ser considerada na presente divulgação.

[00207] Avaliamos agora o impacto do 4G e do serviço de previsão. Para facilitar a interpretação, C4S e íris (com o serviço de previsão desativado) também foram adicionados anteriormente. Note-se que apenas o íris é capaz de suportar trajetos múltiplos e 4G.

[00208] Numa forma de realização, o Uso de Largura de Banda

WiFi e 4G também pode ser considerado na presente divulgação.

[00209] Nos resultados anteriores, o serviço de previsão foi desativado, pois havia apenas um único trajeto (WiFi), ou seja, multidifusão e unidifusão WiFi são primitivas diferentes que partilham o mesmo meio físico, portanto, a alternativa real é usar 4G como um trajeto de comunicação complementar.

[00210] Aqui, começou a analisar o impacto da adição de 4G à divulgação. Devido aos custos associados aos dados móveis, os testes para taxa de bíts de apenas 1000 Kbit/s foram restritos, por ser a mais exigente. Mesmo com essa restrição, ultrapassou os 100 GB de dados móveis usados em todas as experiências. É importante ressaltar que o serviço de previsão para o nosso estágio de pípelíne 4G foi desativado. Isso foi feito porque foram forçadas retransmissões pendentes, que não puderam ser enviadas por multidifusão e unidifusão WiFi, a serem enviadas por 4G.

[00211] A Figura 12 mostra o impacto da adição de 4G com e sem o modelo de previsão descrito, apelidado de iris_4G_1000 e iris_4G_nofilter_1000 dobrado, respetivamente. A outra barra mostrada são resultados de benchmarks anteriores que foram colocados lado a lado para permitir uma comparação mais fácil, a saber, íris no4G apresenta resultados apenas com comunicações WiFi e c4s 1000 reflete o comportamento do C4S para uma taxa de bíts de 1000 Kbit/s. A quantidade de dados móveis usados (na configuração iris_4G_1000) é mostrada como iris_4G_1000_mobiledata.

[00212] Como avaliado anteriormente, tanto o C4S como o íris mostram um aumento linear com o dimensionamento de clientes e taxas de bíts. 0 C4S requer menos largura de banda às custas dos prazos perdidos, como mostra a Figura 10.

[00213] Para a presente divulgação, mostra que a introdução do 4G sem usar o nosso modelo de previsão só pode oferecer uma melhoria mínima, para perda de pacotes abaixo de 30%, em todas as taxas de bíts e número de clientes. No entanto, com a introdução do nosso modelo de previsão, passamos de ~251 MB e ~16 MB, para largura de banda de download e upload, para ~136 MB e ~17 MB para largura de banda de download e upload para o nosso 4G com previsão, no caso de teste mais exigente de [40,50]% de perda de pacotes, 28 clientes e taxa de bíts de 1000 Kbit/s.

[00214] Isso representa uma economia de 45% com cada cliente usando apenas ~5,2 MB de dados móveis, em média, para um fluxo de vídeo de 5 minutos, resultando em ~142 Kbit/s que representam 14,2% dos 1000 Kbit/s originais.

[00215] Impacto do Serviço de Previsão

[00216] Para melhor avaliar a eficiência do modelo de previsão, três cenários distintos foram comparados, como mostra a Figura 13. O primeiro chamado de previsão incorreta, em que o oráculo sempre respondia com uma previsão de perda de pacotes, uma configuração fixa, na qual o resultado da perda de pacotes com base na taxa real de perda de pacotes pré-configurada foi prevista, ou seja, para uma configuração de [40,50]% de perda de pacotes, usámos o limite superior, 50%, e realizámos um teste com moedas baseado nessa percentagem para prever a perda de pacotes, e a última (ml), o original que usava a mesma estratégia, mas usava taxa variável de perda de pacotes com base no oráculo de aprendizagem de máquina.

[00217] A configuração de previsão incorreta basicamente força todos os pacotes em falta a serem adiados especulativamente para um estágio posterior do pípelíne, começando com a multidifusão, passando pela unidifusão e afundando na ligação 4G. Os pacotes em falta são revertidos apenas para o estágio de multidifusão inicial se não houver mais largura de banda 4G disponível. Por esse motivo, é observado um aumento significativo no uso de dados móveis quando comparado com as outras duas alternativas.

[00218] As diferenças entre fixa e ml podem ser explicadas pela melhor previsão do posterior. Deve-se notar que foi introduzida uma quantidade predefinida de perda de pacotes nos clientes, ou seja, 0%, 20% e 40%, mas essa quantidade é aumentada com a perda real de pacotes do meio, que nas condições das soluções descritas variam em torno de 10%. Essa diferença de 10% na previsão é o fator que contribui para que o ml tenha melhor desempenho e, portanto, indica que o oráculo de aprendizagem de máquina está a comportar-se conforme o esperado.

[00219] Numa forma de realização, os Prazos Perdidos - WiFi e 4G podem ser considerados na presente divulgação.

[00220] A Figura 14 mostra apenas os resultados para [40,50]% de perda de pacotes, uma vez que nos demais intervalos de perda de pacotes as perdas eram residuais para três configurações de previsão. Uma quantidade substancial de prazos perdidos é observada para a configuração de previsão incorreta. Isso ocorre devido à exaustão da largura de banda de 2 Mbit/s disponível para retransmissões em 4G, conforme confirmado pelo consumo médio de dados móveis de ~1 Mbit/s. Quando sob grandes perdas de pacotes de rajada, os 1 Mbit/s de reserva são rapidamente esgotados (pois limitamos o 4G a 2 Mbit/s).

[00221] Numa forma de realização, o Uso de Energia, CPU e Memória pode ser considerado na presente divulgação.

[00222] A avaliação do uso de energia usando 4G foi realizada e o modelo de previsão baseado em aprendizagem de máquina. Independentemente da taxa de perda de pacotes, a energia utilizada foi dominada pela descodificação de vídeo. Assim, a taxa de bíts foi o único fator verdadeiro que alterou significativamente a energia utilizada: para 1000 Kbit/s, 500 Kbit/s e 250 Kbit/s, foi medida em torno de 3%, 2,25% e 1,15% da percentagem média de uso da bateria (para uma execução de 5 minutos), respetivamente. Isso está alinhado com um reprodutor multimédia de vídeo normal, permitindo 166 minutos (2,7 h) de reprodução contínua, para uma capacidade de bateria comum de 2700 mAh.

[00223] Utilizando a mesma configuração, foram medidos cerca de 25% do uso da CPU e 60 ± 10 MB de uso de memória, em todas as taxas de bíts. Deve-se notar que o uso da CPU permanece bastante constante devido ao facto de a descodificação de vídeo real ser partilhada em carga com a GPU. Embora não tenha sido medido o uso da GPU diretamente, é trivial inferir esse comportamento diretamente do padrão de uso de energia.

[00224] Numa forma de realização, a Avaliação de Partilha de Carga da divulgação pode ser: como nem o Streambolico nem a Cisco têm suporte para a partilha de carga em edge cloud, esta secção concentra-se apenas no desempenho do íris. Para avaliar o impacto da introdução da partilha de carga em edge cloud com e sem 4G, os dispositivos Nexus 5X foram removidos porque exibiam alguns problemas ao executar as comunicações dispositivo-para-dispositivo (D2D), nomeadamente, impossibilitando fazer conexões Bluetooth a partir de ou com esses dispositivos (algo que não aconteceu com os dispositivos da Samsung). Além disso, ao atuar como um ponto de acesso à Internet sem fios, o Nexus 5X desconecta aleatoriamente os clientes.

[00225] As seguintes configurações foram usadas para o íris: a) sem partilha de carga em edge cloud (noe) ; b) sem partilha de carga em edge cloud com 4G (noe 4g) ; c) partilha de carga usando ponto de acesso à Internet sem fios (go (Proprietários de Grupo)); d) partilha de carga com pontos de acesso à Internet sem fios usando 4G (go 4g); e) partilha de carga usando WiFi P2P (wd); f) partilha de carga usando WiFi P2P e 4G (wd 4g) ; g) e, finalmente, partilha de carga usando Bluetooth (bt). O Bluetooth com 4G ou WiFi Direct não foi considerado porque enfrentava vários problemas com a pilha Bluetooth do Android que causavam degradação geral do sistema.

[00226] Para experiências WiFi-Direct (go e go 4g) , um servidor proxy teve de ser implantado em todos os dispositivos para permitir que potenciais clientes WiFiDirect possam aceder ao nosso servidor. Por padrão, o Android não executa NAT nos grupos WiFi-Direct. Além disso, o número de nós por grupo foi limitado a 4. Para taxas de bíts mais altas, grupos maiores tornaram-se instáveis.

[00227] Numa forma de realização, o Uso da Largura de Banda - Partilha de Carga pode ser considerado pelo impacto no uso da largura de banda que foi avaliado com a introdução da partilha de carga edge, para WiFi (Figura 15) e 4G (Figura 16) . A melhor configuração para o íris, com menos de [0-10]% de perda de pacotes, foi alcançada ao usar go 4g exibindo 22, 63 ± 1,06 (MB), 34,7 ± 0,99 (MB) e 70,29 ± 1,91 (MB), para 250 Kbit/s, 500 Kbit/s e 1000 Kbit/s, respetivamente.

[00228] Numa forma de realização, para [20-30]% de perda de pacotes: a melhor configuração do íris para 250Bkit/s foi alcançada com go 4g com 27,24 ± 3,27 (MB). Deve-se notar que o go 4g utilizou apenas 0,19 ± 0,25 (MB) dos dados 4G. Nesta configuração, apenas os proprietários de grupo (pontos de acesso à Internet sem fios) podem usar 4G, pois os outros dispositivos recebem apenas retransmissões do proprietário do grupo. Ao transmitir em continuo a 500 Kbit/s, alcançou 47,77 ±2,2 (MB) ao usar go 4g, enquanto utilizava 0,12 ± 0,05 (MB) de dados 4G. Quando não está a usar 4G, a configuração go usa 61,81 ± 4,89 (MB) . Na taxa de blts mais alta (1 OOOKbit/s) , o termo go 4g usa 96, 08 ± 5,51 (MB) enquanto usa 0,48 ± 0,22 (MB) de dados 4G.

[00229] Numa forma de realização, para [40-50]% de perda de pacotes: ao usar 250 Kbit/s, a melhor configuração do íris foi atingida por go 4g com 33,27 ± 1,55 (MB), ao usar 0,17 ± 0,07 (MB ) de dados 4G. Ao transmitir em continuo a 500Kbit/s, o go 4g atinge 60,93 ± 1,27 (MB) enquanto usa 0,31 ± 0,13 (MB) de dados 4G. Por fim, ao transmitir em continuo a 1000 Kbit/s, o go 4g apresenta 118,36 ± 0,82 (MB) enquanto usa 6,23 ± 1,48 (MB) de dados 4G.

[00230] Numa forma de realização, a Latência - Partilha de Carga pode ser considerada na presente divulgação.

[00231] A latência de arranque da transmissão em continuo de video reflete a quantidade de tempo necessária antes de começar a ser exibida no telefone móvel do utilizador após solicitação inicial. A Figura 17 mostra os resultados da latência do video ao usar partilha de carga edge e 4G.

[00232] Numa forma de realização, para [0-10]% de perda de pacotes: a configuração noe teve a melhor latência, apresentando 893,42 ± 40,64 (ms) para 250 Kbit/s, 861,93 ± 38,4 (ms) para 500 Kbit/s e 1247,58 ± 78,54 (ms) para 1000 Kbit/s.

[00233] Numa forma de realização, para [20-30]% de perda de pacotes: a melhor configuração íris foi wd mobile para todas as taxas de bíts, com 1038,33 ± 65,13 (ms) para 250 Kbit/s, 1051,51 ± 34,76 (ms) para 500 Kbit/s, e 1099,26 ± 46,69 (ms) para 1000 kbit/s.

[00234] Numa forma de realização, Para [40-50]% de perda de pacotes: seguindo a tendência anterior, wd 4g é a melhor configuração em todas as taxas de bíts atingindo 1030,95 ± 47,32 (ms) para 250 Kbit/s, 1015,09 ± 39,82 (ms) para 500 Kbit/s, e 1057,17 ± 53,17 (ms) para 1000 Kbit/s.

[00235] Numa forma de realização, os Prazos Perdidos Partilha de carga podem ser considerados na presente divulgação.

[00236] Para avaliar a fiabilidade, mediu-se o número de pacotes perdidos, como resultado de prazos perdidos, e apresentou-se na Figura 18.

[00237] A presente divulgação experimentou apenas prazos perdidos residuais ao transmitir em continuo a 1000 Kbit/s sob [40-50]% de perda de pacotes. Aqui a pior configuração foi wd 4g com uma média abaixo de 1 e uma variação menor que 2. Dado que o número total de pacotes enviados no fluxo de base (sem contar retransmissões) é de cerca de 19000 (com uma carga útil de 2068 bytes por pacote) para uma execução de 5 minutos usando uma taxa de bíts de 1000 Kbit/s, então a taxa de perda de prazo é inferior a 0,0001%. Todas as outras configurações tiveram prazos perdidos insignificantes.

Claims (26)

1. REIVINDICAÇÕES

   1. Um sistema implementado por computador para transmissão em direto em continuo de video através de uma rede ou redes sem fio multicanal, compreendendo pelo menos um servidor de transmissão em continuo conectado a uma pluralidade de dispositivos móveis de utilizador como clientes de transmissão em continuo, em que o servidor de transmissão em continuo compreende:

   um gestor de fluxo para obter pacotes de dados a partir de uma transmissão em direto em continuo de video recebida, e um escalonador de rede para escalonar a transmissão, e retransmissão quando considerado necessário pelo servidor de transmissão em continuo, de pacotes de dados de transmissão e pacotes de dados de retransmissão, respetivamente;

   em que o servidor de transmissão em continuo está configurado em FEC, Forward Erasure Correctíon (Correção de erros sem canal de retorno), codifica os pacotes de dados obtidos para pacotes de dados de transmissão para a transmissão a clientes de transmissão em contínuo;

   em gue a rede ou redes sem fio multicanal compreendem uma pluralidade de canais multicanal, em que os referidos canais multicanal compreendem dois ou mais tipos de tecnoloqia sem fios distintos;

   em que o escalonador de rede compreende um subescalonador para cada canal sem fios e está confiqurado de forma que:

   1/7 os pacotes de dados de transmissão são escalonados para transmissão por um primeiro subescalonador;

   os pacotes de transmissão que são determinados como ausentes mais do que um número de vezes predeterminado num subescalonador específico são passados para um subescalonador subsequente;

   em que a rede sem fios multicanal compreende um canal WiFi multidifusão de uma rede sem fios de área local, canal WiFi unidifusão de uma rede sem fios de área local, e um canal de rede móvel unidifusão de uma rede móvel celular de banda larga.
2. 2. Sistema de acordo com a reivindicação anterior, em que o servidor de transmissão em contínuo está configurado para codificar uma matriz de transmissão através de:

   colocar pacotes de transmissão num número de linhas predeterminado e num número de colunas predeterminado usando a ordem principal da linha até esperar que a matriz de transmissão esteja cheia;

   calcular uma paridade de codificação de eliminação para cada coluna a adicionar a paridade de coluna calculada no final da respetiva coluna num ou mais blocos da matriz para formar uma ou mais linhas de paridade da coluna;

   calcular uma paridade de codificação de eliminação para cada linha, incluindo as linhas de paridade de coluna calculadas, e adicionar a paridade de linha calculada no final da respetiva linha num ou mais blocos da matriz para formar uma ou mais colunas de paridade da linha, de modo que os blocos pertencentes aos dados de paridade de linha e aos dados de paridade de coluna são dados de paridade de linha sobre paridade de coluna;

   2/7 transmitir a matriz na ordem principal da coluna.
3. 3. Sistema de acordo com a reivindicação anterior, em que a codificação FEC é ajustável em tempo de execução ao dinamicamente se ajustar o número de linhas de paridade e o número de linhas de paridade de colunas.
4. 4. Sistema de acordo com a reivindicação 2 ou 3, em que a paridade é calculada usando o método de codificação Reed-Solomon.
5. 5. Sistema de acordo com qualquer uma das reivindicações 2-4, em que o servidor de transmissão em contínuo está configurado para não retransmitir pacotes de paridade.
6. 6. Sistema de acordo com a reivindicação anterior, em que cada cliente de transmissão em contínuo está disposto para reportar a receção de pacotes transmitindo um relatório de receção ao servidor de transmissão em contínuo ao qual está conectado, o número da última matriz de transmissão que foi totalmente recebida seguido por uma representação de bítmap de cada uma das matrizes de transmissão pendentes, em que um 0 codifica um pacote ausente e um 1 o caso contrário, ou viceversa.
7. 7. Sistema de acordo com a reivindicação anterior, em que a representação de bítmap é compactada usando um método de compactação de imagem sem perdas, em particular um método de compactação gzip.
8. 8. Sistema de acordo com a reivindicação 6 ou 7, em que cada cliente de transmissão em contínuo está adicionalmente disposto para reportar a receção de pacotes transmitindo o relatório de receção através de cada canal sem fios, em que o relatório de receção para cada canal sem fios compreende também o RSSI respetivo,

   3/7 indicação de intensidade do sinal recebido, e tipo de tecnologia sem fios utilizada.
9. 9. Sistema de acordo com qualquer uma das reivindicações anteriores, em que o escalonador de rede está configurado de modo que os pacotes de retransmissão que são determinados como ausentes mais do que um número de vezes predeterminado num último subescalonador são descartados ou passados de volta para o primeiro subescalonador.
10. 10. Sistema de acordo com qualquer uma das reivindicações anteriores, em que cada subescalonador compreende um filtro para filtrar os pacotes a serem excluídos da retransmissão.
11. 11. Sistema de acordo com a reivindicação anterior, em que o filtro compreende um classificador de aprendizagem de máquina para prever a razão de perda de pacotes para transmissão unidifusão e para prever a configuração de bítmaps da matriz de transmissão para transmissão multidifusão, para excluir os pacotes da retransmissão.
12. 12. Sistema de acordo com a reivindicação anterior, em que o mesmo método de aprendizagem de máquina é usado tanto para unidifusão como para multidifusão, em particular o método de aprendizagem de máquina sendo um método de aprendizagem de máquina Random Forest, método de aprendizagem de máquina de Aprendizagem Reforçada, ou uma combinação dos mesmos.
13. 13. Sistema de acordo com qualquer uma das reivindicações anteriores, em que a codificação FEC é AL-FEC, FEC ao nível da aplicação, em que a codificação FEC é operada dentro da camada da aplicação.

    4/7
14. 14. Sistema de acordo com qualquer uma das reivindicações anteriores, em que os clientes de transmissão em contínuo estão configurados para receber o vídeo de transmissão em direto em contínuo e solicitar e receber pacotes de dados retransmitidos na camada da aplicação.
15. 15. Sistema de acordo com qualquer uma das reivindicações anteriores, em que os tipos de tecnologia sem fios incluem rede sem fios de área local como WiFi, e rede móvel celular de banda larga, como 3G, 4G ou 5G.
16. 16. Sistema de acordo com qualquer uma das reivindicações anteriores em que os canais sem fio compreendem ainda um canal de rede móvel de transmissão multícast de uma rede de telefone móvel celular de banda larga.
17. 17. Sistema de acordo com qualquer uma das reivindicações anteriores, que compreende um partilha de carga oportunista de periferia de rede, em que os clientes de transmissão em contínuo estão configurados para: solicitar periodicamente pacotes perdidos de todos os clientes de transmissão em contínuo vizinhos disponíveis utilizando uma conexão de entrelaçamento em malha.
18. 18. Sistema de acordo com a reivindicação anterior, em que os clientes de transmissão em contínuo vizinhos são conectados por WiFi Direto ou Bluetooth BR/EDR (Bluetooth Clássico) ou ambos.
19. 19. Sistema de acordo com a reivindicação 17 ou 18, em que todos os pacotes transmitidos e retransmitidos são assinados digitalmente, quer agrupados quer

    5/7 individualmente, em particular utilizando uma assinatura de criptográfica de curva elíptica.
20. 20. Sistema de acordo com a reivindicação anterior em que os pacotes são assinados individualmente pelo remetente do pacote e assinados em grupo dentro de um bloco de video pelo criador do fluxo de vídeo.
21. 21. Sistema de acordo com a reivindicação 19 ou 20, em que a assinatura é obtida por chaves simétricas independentes.
22. 22. Sistema de acordo com qualquer uma das reivindicações anteriores compreendendo uma pluralidade de ditos servidores de transmissão em continuo, em que cada servidor de transmissão em continuo está configurado para transmitir para uma secção geográfica especifica que é distinta das secções geográficas dos outros servidores de transmissão em continuo, em particular a secção geográfica especifica não se sobrepondo às secções geográficas dos outros servidores de transmissão em continuo.
23. 23. Sistema de acordo com qualquer uma das reivindicações anteriores em que o servidor de transmissão em continuo está configurado para codificar uma codificação de fonte para pacotes de dados de retransmissão para transmissão para transmissão aos clientes de transmissão em continuo, usando uma combinação linear de pacotes para superar os pacotes em falta nos clientes de transmissão em continuo.

    6/7
24. 24. Sistema de acordo com a reivindicação anterior em que os pacotes que não são necessários devido à codificação FEC não são retransmitidos e não estão incluídos na codificação fonte.
25. 25. Sistema de acordo com a reivindicação 23 ou 24, em que a codificação de fonte é intercalada para comunicação entrelaçada dual.
26. 26. Sistema de acordo com qualquer uma das reivindicações anteriores, em que o cliente de transmissão em contínuo está confiqurado para fornecer um protocolo estendido de mensaqem em tempo real (RTMP) de substituição.

    7/7