Cen´ ario MEC no Simu5G
5.2 Modelando a arquitetura MEC com Simu5G
O Simu5G permite modelar a arquitetura MEC, retratando seus principais elemen-tos. Antes de iniciar a modelagem da arquitetura MEC, ´e necess´ario entender como s˜ao modelados os elementos anteriores `a entrada no sistema MEC. Na Figura 5.2, podem-se visualizar os principais m´odulos, no que diz respeito aos equipamentos de redes m´oveis e disponibilizados pelo Simu5G, que s˜ao compostos pelo equipamento do usu´ario, gNodeB e o UPF [80].
Figura 5.2: Principais m´odulos do Simu5G [80].
No caso do UPF, ´e implementado o protocolo GPRS (General Packet Radio Ser-vice), permitindo que o roteamento de pacotes da RAN para a Internet ocorra atrav´es da rede n´ucleo 5G (5GC). J´a para a comunica¸c˜ao entre os UEs e gNodeBs, ´e utilizado o protocolo NR de camada 2, implementados pelo m´odulo NR NIC UE da camada f´ısica.
47 E interessante destacar que o Simu5G descreve um dos quadros trocados entre os UEs e´ gNodeBs como quadrosair frame. Esses quadros possuem 10 ms de dura¸c˜ao e consistem de 10 sub-quadros, cada um com 1 ms. Tais quadros podem ent˜ao ser divididos em slots de tempos, que s˜ao chamados de TTI (Transmission Time Interval), onde cada quadro de 1 ms corresponde a um TTI [75].
Com rela¸c˜ao ao UE, pela Figura 5.2, vˆe-se que todas as camadas do modelo de protocolo TCP/IP s˜ao representadas por m´odulos fornecidos pela utiliza¸c˜ao da biblioteca INET usada no OMNeT++, desde a camada de acesso `a rede, atrav´es do m´odulo NR NIC UE, at´e a aplica¸c˜ao. Para o gNodeB, o m´odulo inclui protocolos at´e a camada de rede (IP) e possui duas interfaces de enlace dispon´ıveis: uma NR, implementada pela NR NIC GNB, e uma executando o protocolo PPP (Point-to-point Protocol) para conectividade cabeada para a rede de n´ucleo 5G [75].
Por ser um framework capaz de modelar apenas o cen´ario que envolve o plano de usu´ario (user plane) da arquitetura da rede de n´ucleo 5G, vista na Subse¸c˜ao 2.5.3 do Cap´ıtulo 2, o Simu5G possui um m´odulo especial que representa a totalidade do plano de controle (control plane), chamado debinder. Al´em disso, tamb´em h´a um m´odulo chamado de carrierAggregation, e tanto esse como o binder conseguem manter uma vis˜ao global das informa¸c˜oes de rede que podem ser solicitadas por outros m´odulos [75].
A responsabilidade, especificamente, de conhecer quais UEs pertencem a determi-nados gNodeBs, ´e dado pelo binder. Essa escolha de modelagem apresenta vantagens, pois mant´em de forma centralizada um reposit´orio unificado de informa¸c˜oes relevantes, que simplificam o tratamento de tarefas distribu´ıdas em diversas fun¸c˜oes e elementos do control plane da rede 5G. Tamb´em auxilia na abstra¸c˜ao dessas mesmas fun¸c˜oes e elemen-tos, pois as substitui por requisi¸c˜oes ao binder para informa¸c˜oes importantes.
5.2.1 Modelagem dos componentes do n´ıvel de sistema MEC
Como visto na Subse¸c˜ao 4.4.3 do Cap´ıtulo 4, o n´ıvel de sistema MEC ´e composto, principalmente, pelo orquestrador e UALCMP. O Simu5G os implementa como m´odulos do OMNeT++. O orquestrador ´e um m´odulo simples que possui uma conex˜ao direta, chamado degate, com o UALCMP e, para o orquestrador, s˜ao apresentadas as listas de MEChosts associados, para que seja poss´ıvel ter uma vis˜ao global dos requisitos e servi¸cos dispon´ıveis para definir os MEC hosts adequados para executar os MEC apps [69]. O
UALCMP implementa a pilha TCP/IP e fornece o RESTful API que ´e consumido pelo aplicativo do usu´ario para instanciar ou finalizar a execu¸c˜ao de MEC apps pelo ponto de referˆencia Mx2 [80].
Na Figura 5.3, pode-se visualizar com mais detalhes a pilha de protocolos usada pelo UALCMP, desde a camada f´ısica at´e a de aplica¸c˜ao, e sua liga¸c˜ao com o orquestra-dor atrav´es de gates. A comunica¸c˜ao entre esses dois elementos ´e feita por mensagens OMNeT++, enquanto intera¸c˜oes com as entidades do n´ıvel de MEC host s˜ao realizados por chamadas diretas (direct method calls), sem envio de mensagens OMNet++ [80].
Figura 5.3: Modelagem dos componentes do n´ıvel de sistema MEC [80].
5.2.2 Modelagem dos componentes do n´ıvel de MEC host
O n´ıvel de MEC host, descrito na Subse¸c˜ao 4.4.2 do Cap´ıtulo 4, ´e modelado pelo Simu5G com a composi¸c˜ao das entidades de gerenciamento, como VIM (Virtualization Infrastructure Manager) e MECPM (MEC Platform Manager), dos m´odulos necess´arios para executar os MECapps, e os m´odulos em si da plataforma MEC e infraestrutura de virtualiza¸c˜ao. Os recursos disponibilizados pelos MEC hosts s˜ao retratados nos arquivos INI e NED, por exemplo, com o n´umero m´aximo de MECapps que podem ser instanciados, capacidade de mem´oria principal, espa¸co de disco e n´umero de instru¸c˜oes por segundo.
Pela Figura 5.4, tem-se a demonstra¸c˜ao da modelagem do n´ıvel de MEC host do Simu5G. Podem ser verificadas as entidades dos MEC apps, que est˜ao ligados `a pilha de protocolos TCP/IP e tamb´em o uso de GTP (GPRS Tunneling Protocol), sendo o m´odulo que possibilita que o MEC host seja localizado em qualquer parte de uma rede n´ucleo 5G [80]. Al´em disso, tamb´em pode-se verificar a plataforma MEC, possuindo sua pr´opria pilha TCP/IP, que ´e conectada `a infraestrutura de virtualiza¸c˜ao por uma conex˜ao
49 Ethernet. Cont´em, inclusive, os servi¸cos MEC e o registro de servi¸co, implementados como aplica¸c˜oes TCP [69] que s˜ao servidores RESTful HTTP. O uso de servidor HTTP se deve ao fato do Simu5G trazer a possibilidade de operar como emulador com aplica¸c˜oes reais. Isso permite que um usu´ario seja capaz de criar um servi¸co MEC compat´ıvel com o ETSI, implementando os m´etodos HTTP (GET,POST, entre outros) de acordo com o comportamento do servi¸co [69].
Figura 5.4: Modelagem dos componentes do n´ıvel de MEC host [80].
5.2.3 Modelagem dos aplicativos (endpoints)
MECapp
Como citado na Se¸c˜ao 4.5, cada MEC app tem suas regras e requisitos. Tais parˆametros s˜ao modelados ao aplicativo atrav´es de um arquivo JSON (JavaScript Object Notation) chamado Application Descriptor, que ´e composto por campos necess´arios para a integra¸c˜ao de um pacote de aplicativos no sistema MEC. Esses campos s˜ao descritos a seguir [69].
• appDId - identificador do Application Descriptor;
• appName - nome do MEC app;
• appProvider - nome do m´odulo necess´ario para executar o aplicativo;
• appServiceRequired - servi¸cos necess´arios para a execu¸c˜ao do aplicativo;
• virtualComputeDescriptor - recursos de computa¸c˜ao, como mem´oria, disco e pro-cessamento, que s˜ao necess´arios para a execu¸c˜ao do aplicativo em um MEC host.
User equipment (UE)
A intera¸c˜ao do UE com o sistema MEC ´e feita atrav´es de duas entidades, chamadas UE app edevice app [69]. O primeiro ´e o ponto final da comunica¸c˜ao no plano de dados entre o UE e o MECapp, enquanto device app ´e respons´avel pela interface com o sistema MEC, solicitando a instancia¸c˜ao ou encerramento do MECapp [69]. Pode-se concluir que o UE app ´e a parte gr´afica que o usu´ario do UE enxerga e faz a solicita¸c˜ao do servi¸co e o device app ´e a parte que o usu´ario do UE n˜ao vˆe, isto ´e, toda parte de c´odigo e interface que solicita o servi¸co ao sistema MEC. Por fim, o cliente s´o come¸ca a utilizar o servi¸co solicitado depois que odevice app tem a confirma¸c˜ao da instancia¸c˜ao do MEC app.
Odevice app se conecta ao UE app atrav´es de um soquete UDP por uma interface simples atrav´es de mensagens de cria¸c˜ao, encerramento ou reconhecimento (acknowledg-ment) de um MEC app, cujas mensagens podem ser identificadas comoSTART mecApp-Name, STOP mecAppName e ACK endpoint. Esse soquete ´e codificado no framework atrav´es da linguagem C++. Essa interface fornecida pelo framework pode ser utilizada para aplicativos UE internos e externos, nesse ´ultimo caso sendo um cen´ario de emula¸c˜ao.
Em rela¸c˜ao ao UE app, ele tamb´em pode ser interno ou externo ao Simu5G. Se for um cen´ario de simula¸c˜ao, ou seja, interno, ele ´e executado para emitir solicita¸c˜oes com uma taxa predefinida e registrar medidas estat´ısticas [69].
5.2.4 Modelagem dos servi¸ cos MEC
Foram vistos na Se¸c˜ao 4.5 alguns servi¸cos padronizados e compat´ıveis com o ETSI, conforme a sua documenta¸c˜ao [70]. No Simu5G, ´e fornecido um m´odulo chamado Mec-ServiceBase, que ´e usado para prototipagem r´apida desses servi¸cos. Tal m´odulo usado no framework implementa o servi¸co de informa¸c˜oes da rede de r´adio (RNIS) e servi¸co de localiza¸c˜ao, contendo requisitos necess´arios para executar um servidor HTTP, assim como existe um conjunto de m´odulos eNodeB/gNodeB associados aos MEC hosts na sua interface [69].
Com a ajuda do servi¸co de RNI, informa¸c˜oes atualizadas sobre a condi¸c˜ao da rede e os UEs conectados `a esta¸c˜ao base associada aos MEC hosts podem ser coletadas e analisadas em tempo real pelos aplicativos MEC [81]. Esses dados de desempenho da rede podem ajudar no aprimoramento da Qualidade de Experiˆencia (QoE) dos clientes finais e em um melhor uso dos recursos dispon´ıveis. Pode-se implementar um subconjunto da
51 API RNIS, que possuem recursos de medi¸c˜oes da camada 2 dogNodeB. Alguns exemplos de medi¸c˜oes poss´ıveis s˜ao atraso de pacote, taxa de transferˆencia, utiliza¸c˜ao de c´elulas, taxa de dados de pacotes, quantidade de UEs ativos, bem como o tr´afego de downlink e uplink de cada UE [69]. Tais informa¸c˜oes s˜ao obtidas pelo RNIS atrav´es de m´odulos gNodeB dentro doframework Simu5G.
Com o servi¸co de localiza¸c˜ao, ´e poss´ıvel obter informa¸c˜oes precisas da posi¸c˜ao de cada UE ou esta¸c˜ao base. Esse servi¸co proporciona ao cliente o rastreamento de loca-liza¸c˜ao de um dispositivo ativo, assim como a recomenda¸c˜ao de servi¸co baseado em sua localiza¸c˜ao. A API implementada ´e vista em [82]. Com ajuda da bibliotecaINET Mobility implementada noframework, as posi¸c˜oes dos UEs s˜ao expressas como coordenadas eucli-dianas tridimensionais, e elas s˜ao atualizadas periodicamente e armazenadas nosgNodeBs [69]. O aplicativo MEC pode consultar a localiza¸c˜ao de um ´unico UE, ou um grupo de UEs, sendo esse segundo caso implementado na pr´oxima se¸c˜ao. Como referenciado em [82], tamb´em est´a presente a UE area subscribe. Esse procedimento permite que aplicati-vos sejam notificados sobre a movimenta¸c˜ao de UEs em rela¸c˜ao a uma ´area geogr´afica.