• Nenhum resultado encontrado

Conclus˜ ao e Trabalhos Futuros

De acordo com o objetivo do trabalho de estudar a arquitetura MEC em redes 5G, foi vi´avel compreender como essa integra¸c˜ao vai habilitar o potencial m´aximo da nova gera¸c˜ao de redes m´oveis. O conte´udo apresentado e distribu´ıdo ao longo dos cap´ıtulos anteriores permitiu analisar os requisitos necess´arios para implementar o 5G, desde os seus conceitos envolvidos e tecnologias centrais de suporte, at´e uma infraestrutura de computa¸c˜ao capaz de suprir as especifica¸c˜oes esperadas de baixa latˆencia, qualidade de servi¸co e alta taxa de transmiss˜ao de dados.

Foi poss´ıvel avaliar que a arquitetura de computa¸c˜ao na borda, gra¸cas a tecno-logias complementares de virtualiza¸c˜ao e redes definidas por software, ´e primordial para tratar dados estritamente em tempo real. De tal modo, que a preocupa¸c˜ao encontra-se na an´alise dos dados gerados por usu´arios pr´oximos fisicamente, sem precisar percorrer grandes distˆancias para o processamento e armazenamento das informa¸c˜oes. Traz, por-tanto, os benef´ıcios da computa¸c˜ao em nuvem para perto da origem dos dados, tornando a rede mais confi´avel, com alta disponibilidade e veloz. Esses benef´ıcios da computa¸c˜ao na borda s˜ao primordiais para a constru¸c˜ao da arquitetura MEC, padronizada pelo ETSI, e integra¸c˜ao com 5G a fim de satisfazer as especifica¸c˜oes determinadas pelo IMT-2020.

A arquitetura MEC possibilita mover as aplica¸c˜oes para a borda da rede, que em conjunto com a rede de acesso 5G, aprimoram a experiˆencia do usu´ario. E com o prop´osito de agregar valor ao entendimento de tal arquitetura integrada ao 5G, foi trazida a an´alise de uma simula¸c˜ao existente do Simu5G, biblioteca de 5G para oframework de simula¸c˜ao OMNet++, para observar como os elementos do sistema MEC e 5G se relacionam. Com o Simu5G, houve a possibilidade de entender o fluxo de requisi¸c˜oes de uma aplica¸c˜ao.

64

65 Especificamente, para a simula¸c˜ao, a aplica¸c˜ao envolve o monitoramento de carros com rela¸c˜ao a zonas de perigo, que para o mundo real poderiam ser caracterizadas por ´areas de risco. Como j´a escrito no Cap´ıtulo 5, o cen´ario simulado ´e composto por uma topologia de plano de dados, onde a parte de controle ´e representada pelo elementobinder e o plano de usu´ario pelo UPF.

Pode ser observado que, desde os carros at´e os MEChosts, s˜ao poucos saltos, com-provando que ´e evidenciada uma arquitetura de computa¸c˜ao na borda capaz de processar de forma mais dinˆamica e eficiente as informa¸c˜oes requisitadas pela aplica¸c˜ao, sendo essa a parte mais importante para o usu´ario. Atrav´es dos logs de simula¸c˜ao apresentados no Cap´ıtulo 5, foi poss´ıvel analisar como os elementos da rede comunicam-se atrav´es de seus m´odulos no simulador. Quando o device app solicita o servi¸co ao proxy, o UALCMP, que encaminha a requisi¸c˜ao ao orquestrador, este escolhe o MEC host com capacidade suficiente para a aplica¸c˜ao requerida, que no caso dessa simula¸c˜ao ´e o mecHost1, por´em esse elemento n˜ao cont´em o servi¸co de localiza¸c˜ao desejado. Isso acontece devido ao fato domecHost2 n˜ao satisfazer a solicita¸c˜ao m´ınima de parˆametros de taxa de processamento em MIPS definidas pela aplica¸c˜ao, apesar de possuir o servi¸co de localiza¸c˜ao necess´ario em sua plataforma MEC.

Em um segundo momento, em que foram equiparados os parˆametros de recursos dos dois MEChosts envolvidos na simula¸c˜ao para fins de compreens˜ao, pˆode-se notar que o mecHost2 ´e escolhido para instanciar a aplica¸c˜ao. E a partir do instante que o carro entra na zona de perigo, pode-se verificar menos saltos realizados, desde a notifica¸c˜ao de perigo dada pelo mecHost2 at´e chegar ao carro. De forma ideal, para atividades e aplica¸c˜oes cr´ıticas do 5G, ´e leg´ıtimo recomendar que servi¸cos e aplica¸c˜oes sejam atendidos por um mesmo MEChost a fim de otimizar o roteamento de dados cruciais para o usu´ario.

Como visto no Cap´ıtulo 5, por ser um cen´ario totalmente simulado, n˜ao h´a evidˆ en-cias de perdas de pacotes ou falhas na comunica¸c˜ao entre os elementos da rede, tendo em vista que n˜ao foi encontrada nenhuma mensagem NACK que indicasse a necessidade de retransmiss˜ao de informa¸c˜ao. Al´em disso, foi verificado tamb´em que o CQI trazido pelo pacote de feedback ´e sempre de valor m´aximo, igual a 15, mostrando que a qualidade do canal ´e sempre ´otima. Por ser um canal ideal, o esperado foi atingido, por´em para um poss´ıvel trabalho futuro seria interessante usar este simulador para cen´arios com perdas e interferˆencias a fim de verificar se o comportamento da rede tem varia¸c˜oes.

Para que isso seja vi´avel, existe a possibilidade de adicionar configura¸c˜oes de inter-ferˆencia entre as c´elulas configuradas atualmente no cen´ario. Ou seja, pode-se adicionar na simula¸c˜ao uma c´elula de background, com UEs de fundo recebendo um tr´afego com uma certa quantidade de taxa de bits (em kb/s, por exemplo). Essas c´elulas de fundo s˜ao modelos simplificados de UEs e tˆem o ´unico objetivo de criar interferˆencia no cen´ario simulado [87]. Com isso ´e esperado que o valor de CQI para o UE de primeiro plano diminua, e o seu n´umero de blocos de recursos alocados no downlink aumente [87].

O Simu5G pode ser usado tamb´em como emulador. O cen´ario emulado n˜ao foi testado neste trabalho, por´em ´e uma possibilidade para um trabalho futuro, como forma de aprimoramento para a proposta executada de an´alise de comportamento da arquite-tura MEC com redes 5G. Para esse caso, seria poss´ıvel utilizar o Simu5G simulando a parte de plano de dados, por´em os pontos finais (endpoints) de acesso, bem como seus respectivos aplicativos MEC instanciados, poderiam ser externos, ou seja, reais. Dessa forma, seria necess´ario configurar as tabelas de roteamento dos dispositivos da rede si-mulada para permitir o encaminhamento de pacotes destinados aos aplicativos externos.

Adicionalmente, seria necess´ario introduzir um campo chamado emulatedMecApplication nas configura¸c˜oes do aplicativo MEC, contendo o endere¸co IP e informa¸c˜ao da porta com o intuito de identificar oendpoint real [80].

Como as interfaces s˜ao externas, no ambiente de emula¸c˜ao, seria importante ve-rificar se o mesmo cen´ario ideal permanece, sem evidˆencias de perdas de pacotes. Al´em de observar se o tempo percorrido de resposta das aplica¸c˜oes s˜ao equivalentes ao visto na simula¸c˜ao, podendo entender se ´e acrescentado latˆencia.

Em suma, sabe-se que as operadoras e fornecedores de equipamentos de rede e r´adio est˜ao em uma corrida para implementar a tecnologia 5G no Brasil. Sendo assim, foi evidenciado a importˆancia deste trabalho como forma de aprimorar os conhecimentos dessa nova gera¸c˜ao e destacar a combina¸c˜ao poderosa do 5G com a topologia MEC. Esta combina¸c˜ao proporciona o uso de aplica¸c˜oes mais avan¸cadas para os usu´arios, principal-mente no meio industrial, possibilitando o uso de servi¸cos de IoT, telemedicina, ou at´e mesmo no setor agr´ario, como por exemplo, o monitoramento de equipamentos agr´ıcolas em tempo real.

Documentos relacionados