Isabela Lopes Miranda Nathalia Medeiros Gomes da Silva

(1)

Universidade Federal Fluminense Escola de Engenharia

Curso de Gradua¸ c˜ ao em Engenharia de Telecomunica¸ c˜ oes

Isabela Lopes Miranda

Nathalia Medeiros Gomes da Silva

Estudo te´ orico e com simula¸c˜ oes da arquitetura MEC em redes 5G

Niter´ oi – RJ

2022

(2)

Isabela Lopes Miranda Nathalia Medeiros Gomes da Silva

Estudo te´orico e com simula¸c˜oes da arquitetura MEC em redes 5G

Trabalho de Conclusão de Curso apresentado ao Curso de Gradua¸cão em Engenharia de Teleco- munica¸cões da Universidade Federal Fluminense, como requisito parcial para obten¸cão do Grau de Engenheiro de Telecomunica¸cões.

Orientador: Prof. Dr. Tadeu Nagashima Ferreira

Coorientador: Profa. Dra. Fernanda Gon¸calves de Oliveira Passos

Niter´oi – RJ 2022

(3)

ii

Ficha catalográfica automática - SDC/BEE Gerada com informações fornecidas pelo autor

Bibliotecário responsável: Debora do Nascimento - CRB7/6368 S586e Silva, Nathalia Medeiros Gomes da

Estudo teórico e com simulações da arquitetura MEC em redes 5G / Nathalia Medeiros Gomes da Silva, Isabela Lopes Miranda ; Tadeu Nagashima Ferreira, orientador ; Fernanda Gonçalves de Oliveira Passos, coorientadora. Niterói, 2022.

92 f. : il.

Trabalho de Conclusão de Curso (Graduação em Engenharia de Telecomunicações)-Universidade Federal Fluminense, Escola de Engenharia, Niterói, 2022.

1. Arquitetura MEC. 2. Redes 5G. 3. Simulação. 4. Simu5G.

5. Produção intelectual. I. Miranda, Isabela Lopes. II.

Ferreira, Tadeu Nagashima, orientador. III. Passos, Fernanda Gonçalves de Oliveira, coorientadora. IV. Universidade Federal Fluminense. Escola de Engenharia. V. Título.

CDD -

(4)

Isabela Lopes Miranda Nathalia Medeiros Gomes da Silva

Estudo te´orico e com simula¸c˜oes da arquitetura MEC em redes 5G

Trabalho de Conclusão de Curso apresentado ao Curso de Gradua¸cão em Engenharia de Teleco- munica¸cões da Universidade Federal Fluminense, como requisito parcial para obten¸cão do Grau de Engenheiro de Telecomunica¸cões.

Aprovada em 22 de Julho de 2022.

BANCA EXAMINADORA

Prof. Dr. Tadeu Nagashima Ferreira - Orientador Universidade Federal Fluminense - UFF

Profa. Dra. Fernanda Gon¸calves de Oliveira Passos - Coorientador Universidade Federal Fluminense - UFF

Prof. Dr. Cledson Oliveira de Souza Universidade Federal Fluminense - UFF

Prof. Dra. Dianne Scherly Varela de Medeiros Universidade Federal Fluminense - UFF

Prof. Dr. Diego Gimenez Passos Universidade Federal Fluminense - UFF

Niter´oi – RJ 2022

(5)

iv

Resumo

A crescente demanda por tarefas computacionais mais complexas, o aumento do volume de tráfego e servi¸cos que necessitam de baixa latência, como é o caso da tele- medicina e Internet das coisas, por exemplo, torna cada vez mais importante o uso de uma tecnologia que suporte essas demandas. Este trabalho tem como objetivo apresentar a tecnologia MEC (Multi-Access Edge Computing) como propulsora das redes de quinta gera¸cão (5G), prometendo levar velocidade de comunica¸cão e alta capacidade de processamento para mais perto do usuário, possibilitando as mudan¸cas demandadas. A pesquisa

é baseada em um estudo teórico da estrutura de redes 5G em conjunto com a arquitetura MEC, além de um estudo de caso já existente no simulador Simu5G. No cenário estudado

é usado o servi¸co de localiza¸cão de um MEC host, onde é poss´ıvel gerar notifica¸cões de alerta para o aplicativo dos usuários conforme se movimentam em dire¸cão a uma zona de monitoramento solicitada. A partir desse estudo teórico e de caso, é poss´ıvel compreender como as arquiteturas 5G e MEC podem ser utilizadas de forma integrada e como funcionam seus servi¸cos e aplica¸cões.

Palavras-chaves: MEC. 5G. Simu5G. MEChost. Internet das Coisas.

(6)

Abstract

The growing demand for more complex computational tasks, the increase of network traffic and services that require low latency, such as telemedicine and Internet of things, for example, increase the importance of using a technology that supports these demands.

This work aims to present the MEC (Multi-Access Edge Computing) technology as a booster of fifth generation (5G) networks, promising to bring communication speed and high processing capacity closer to the user, enabling the demanded changes. The research is based on a theoretical study of the structure of 5G networks in conjunction with the MEC architecture, in addition to an existing case study in the Simu5G simulator. In the studied scenario, the location service of a MEC host is used, where it is possible to generate alert notifications for the users’s application as they move towards a requested monitoring zone. From this theoretical and case study, it is possible to understand how 5G and MEC architectures can be used in an integrated way and how their services and applications work.

Keywords: MEC. 5G. Simu5G. MEC host. Internet of Things.

(7)

Aos nossos pais.

(8)

Agradecimentos

Agrade¸co inicialmente ao meu mestre Dr. Daisaku Ikeda por constantemente in- centivar jovens do mundo inteiro a persistirem nos seus sonhos e estudos.

A Nathalia Medeiros por ter sido minha dupla incr´ıvel durante todo esse tempo.` Conseguimos desenvolver uma pequena ideia inicial de tema em um trabalho final que me orgulho. Muito obrigada!

Ao meu pai, Antonio Lopes, que sempre batalhou e trabalhou muito para proporcionar tudo que nós temos hoje. À minha mãe, Solange Miranda, meu grande alicerce da vida. Tenho certeza que todos os momentos desafiadores enfrentados serão lembran¸cas de um inverno, que não falhou em se tornar primavera, assim como diz o Buda Nichiren em seus incentivos.

Ao meu irmão, Caio Lopes, por sempre me ajudar da melhor forma. À minha avó, Altinea Miranda, quem proporcionou meu estudos em 2012, mudando minha trajetória acadêmica. Ao meu tio, Reinaldo Miranda, e minhas primas Leticia e Carolina Miranda, que sempre estiveram ao meu lado.

A todos os amigos que pude compartilhar os momentos de faculdade. Em especial, Larissa Moraes (juntas desde os tempos de CEFET), Amanda Louise, Layanne Issa, Lucas Baptista, Paulo Victor, João Victor Moura e Daniel Guedes. Vocês tornaram todos os dramas acadêmicos em muita risada e descontra¸cão. Muito obrigada por tudo.

As minhas queridas amigas de infˆ` ancia, Mariana Guimar˜aes e Amanda Santos, que sempre me fazem enxergar o melhor lado da vida.

Aos professores Tadeu Ferreira e Fernanda Passos por nos orientarem da melhor forma poss´ıvel. E aos professores Cledson Oliveira, Dianne Scherly e Diego Passos pela disponibilidade em fazer parte da banca.

Isabela Lopes Miranda

(9)

viii Agrade¸co primeiramente a Deus por me guiar at´e aqui.

A Isabela Lopes por topar fazer essa parceria que deu muito certo. Sem d´` uvidas s´o foi poss´ıvel fazer esse trabalho pela troca de conhecimentos e por ajudarmos uma a outra.

A minha m˜` ae que sempre esteve ao meu lado e sempre fez tudo por mim, me dando suporte em todos os momentos e me ajudando a seguir meus sonhos.

A minha gata, principalmente nos per´ıodos de EAD, que sempre deitava em cima` do teclado, lembrando o carinho que tinha por mim. Me alegrou e me deu amor mesmo nos dias mais dif´ıceis.

Ao Julio Cesar Almeida, por todo apoio nessa trajetória da faculdade de engenharia e na vida. Agrade¸co por você ser essa pessoa maravilhosa que me incentiva e me ajuda nos momentos mais dif´ıceis. Sou grata por dividir a vida com você.

A Amanda Yasmim e K´ıssila Souza, por serem minhas melhores amigas desde a` Faetec, eu sei que posso compartilhar meus sonhos e minhas dores e sempre serei apoiada.

Vocˆes foram muito importantes em toda essa trajet´oria.

Aos amigos que conheci ao longo do curso, por terem tornado esses anos de engenharia mais leves. Aos amigos da vida, por sempre se fazerem presentes, mesmo com a rotina pesada.

Ao professor Tadeu Ferreira e `a professora Fernanda Passos, por aceitarem nos ajudar a construir este trabalho. Aos professores Cledson Oliveira, Dianne Scherly e Diego Passos pela disponibilidade em fazer parte da banca deste trabalho.

Ao time incr´ıvel com quem trabalho, na Nokia, que fazem meus dias serem mais leves e sei que posso contar com todos. Agrade¸co principalmente `a Nathalia Cuciniello que sempre torceu por mim e me ajudou nessa jornada, e tamb´em agrade¸co ao meu gestor Bruno Barata por ter confiado em mim e me dado a oportunidade de fazer parte dessa equipe e por contribuir com meu desenvolvimento profissional.

Nathalia Medeiros Gomes da Silva

(10)

Lista de Figuras

2.1 Cen´arios de categorias de servi¸cos [24]. . . 6

2.2 Espectros de banda baixa, m´edia e alta para 5G. Adaptado de [17]. . . 7

2.3 EPC tradicional. Adaptado de [24]. . . 10

2.4 EPC CUPS. Adaptado de [24]. . . 12

2.5 Op¸c˜oes do NSA. Adaptado de [24]. . . 13

2.6 Op¸c˜oes de SA. Adaptado de [24]. . . 14

2.7 Arquitetura baseada em servi¸cos da rede de n´ucleo 5GC. Adaptado de [24]. 15 3.1 Tipos de Hypervisor. . . 19

3.2 Virtualiza¸c˜ao baseada em Contˆeiner. . . 21

3.3 Arquitetura em alto n´ıvel de NFV. Adaptado de [42]. . . 22

3.4 Diferen¸ca da rede tradicional para a definida por Software. . . 24

3.5 Arquitetura SDN. Adaptado de [44]. . . 24

3.6 Sistema SDN-NFV. Adaptado de [44]. . . 26

3.7 Exemplo de fatias de rede isoladas em uma infraestrutura compartilhada [48], onde a cor cinza representa a infraestrutura de rede em comum e as demais cores representam as fatias virtuais. . . 27

4.1 Modelo de computa¸c˜ao de borda [55]. . . 31

4.2 Arquitetura em n´ıveis do MEC [68]. . . 34

4.3 Arquitetura gen´erica de referˆencia MEC [68]. . . 35

4.4 Arquitetura MEC de seguran¸ca de rede [71]. . . 39

4.5 Arquitetura de seguran¸ca centralizada para MEC [67]. . . 39

4.6 Arquitetura integrada entre MEC e 5G [72]. . . 42

4.7 Cen´arios de implementa¸c˜ao MEC integrados ao 5G [72]. . . 43

5.1 Arquitetura do plano de dados de uma rede celular 5G [75]. . . 45 ix

(11)

x

5.2 Principais m´odulos do Simu5G [80]. . . 46

5.3 Modelagem dos componentes do n´ıvel de sistema MEC [80]. . . 48

5.4 Modelagem dos componentes do n´ıvel de MEC host [80]. . . 49

5.5 Topologia MultiMecHost do Simu5G [80]. . . 52

5.6 Fluxo de requisi¸c˜oes ao sistema MEC. Adaptado de [69]. . . 53

5.7 Arquivo de descri¸c˜ao do aplicativo do usu´ario. . . 54

5.8 Zona de perigo representada pelo c´ırculo vermelho. . . 55

5.9 Evidˆencia do conte´udo do pacote defeedback do carro para agNodeB. . . . 56

5.10 Exemplo de um harqFeedback. . . 57

5.11 Parte de umairframe enviado pelo car[2]. . . 57

5.12 In´ıcio de estabelecimento de conex˜oes. . . 58

5.13 Escolha do MEC host. . . 59

5.14 Mensagens trocadas de entrada na zona de perigo quando o mecHost1 ´e o escolhido pelo orquestrador. . . 60

5.15 Diagrama de sequˆencia da notifica¸c˜ao de alerta da zona de perigo. Adap- tado de [69]. . . 61

5.16 Escolha do MEC host com recursos iguais para o mecHost1 e mecHost2. . 62

5.17 Mensagens trocadas de entrada na zona de perigo quando o mecHost2 ´e o escolhido pelo orquestrador. . . 63

(12)

Lista de Tabelas

2.1 Requisitos m´ınimos do 5G [12]. . . 5 2.2 Compara¸cão dos parâmetros entre 4G e 5G. . . 6 5.1 Compara¸cão dos recursos dispon´ıveis em cada MEC host. . . 58

(13)

Lista de siglas e abrevia¸ c˜ oes

1G 1st Generation 2G 2nd Generation 3G 3rd Generation

3GPP 3rd Generation Partnership Project 4G 4th Generation

5G 5th Generationn 5GC 5G Core

ACK Acknowledge

AF Application Function

AMF Access and Mobility Management Function API Aplication Programming Interface

AUSF Authentication Server Function BLER Block Error Rate

BS Base Station

CFS Customer Facing Service CN Core Network

CNF Cloud-Native Network Function CPU Central Processing Unit

xii

(14)

CQI Channel Quality Indicator

CUPS Control and User Plane Separation DHCP Dynamic Host Configuration Protocol DNS Domain Name System

E-UTRA Evolved Universal Terrestrial Radio Access

E-UTRAN Evolved Universal Terrestrial Radio Access Network EB Exabytes

eMBB Enhanced Mobile Broadband eNodeB evolved Node B

EPC Evolved Packet Core

ETSI European Telecommunications Standard Institute FEC Forward Error Correction

GPRS General Packet Radio Service GTP GPRS Tunneling Protocol

HARQ Hybrid Automatic Repeat Request HSS Home Subscriber Server

HTTP Hypertext Transfer Protocol

IEEE Institute of Electrical and Electronics Engineersn IMT International Mobile Telecommunications

IoT Internet of Things IP Internet Protocol

IPsec Internet Protocol Security ISG Industry Specification Group

(15)

xiv ITU-R International Telecommunications Union - Radiocommunication Sector

JSON JavaScript Object Notation LTE Long Term Evolution M2M Machine-to-Machine MAC Medium Access Control

MANO Management and Orchestration MCC Mobile Cloud Computing

MEC Multi-Access Edge Computing MECPM MEC Platform Manager MIMO Multiple Input Multiple Output MIPS Million Instruction per Seconds MME Mobility Management Entity

mMTC Massive Machine Type Communication mmWave Millimeter Wave

NACK Not-Acknowledgement NED Network Description

NEF Network Exposure Function NFV Network Functions Virtualization NFVI NFV Infrastructure

NR New Radio

NRF Network Repository Function NS Network Simulator

NSA Non Standalone

(16)

NSSF Network Slice Selection Function ONF Open Networking

OSS Operations Support System P-GW Packet Data Network Gateway PCF Policy Control Function

PCRF Policy Control and charging Rules Function PDU Protocol Data Unit

PoPs Points of Presence PPP Point-to-point Protocol QoE Quality of Experience QoS Quality of Service RAN Radio Access Network RNI Radio Network Information

RNIS Radio Network Information Service S-GW Serving Gateway

SA Standalone

SBA Service Based Architecture SDN Software Defined Network SMF Session Management Function SNR Signal-to-Noise Ratio

TCP Transmission Control Protocol TI Tecnologia da Informa¸c˜ao TLS Transport Layer Security

(17)

xvi TTI Transmission Time Interval

UALCMP User Application Lifecycle Management Proxy UDC User Data Convergence

UDM Unified Data Management UDP User Datagram Protocol UDR Unified Data Repository UE User Equipment

UPF User Plane Function URL Uniform Resource Locator

URLLC Ultra-Reliable Low Latency Communication VIM Virtualized Infrastructure Manager

VM Virtual Machine

VNF Virtualized Network Functions VNFM VNF Manager

(18)

Sum´ ario

Resumo iv

Abstract v

Agradecimentos vii

Lista de Figuras x

1 Introdu¸c˜ao 1

2 Evolu¸c˜ao das redes m´oveis do 4G ao 5G 3

2.1 Introdu¸cão à evolu¸cão das redes móveis . . . 3

2.2 Requisitos para atender o 5G . . . 4

2.3 Categorias de servi¸co . . . 6

2.4 Caracter´ısticas da camada f´ısica . . . 7

2.4.1 Espectro de uso . . . 7

2.4.2 Tecnologia MIMO massiva . . . 8

2.4.3 C´elulas pequenas . . . 9

2.5 Evolu¸c˜ao da arquitetura do 4G ao 5G . . . 9

2.5.1 Arquitetura 4G tradicional . . . 9

2.5.2 Evolu¸c˜ao da arquitetura 4G . . . 11

2.5.3 Arquitetura 5G . . . 11

3 Tecnologias centrais para o 5G 17 3.1 Virtualiza¸c˜ao . . . 17

3.1.1 Virtualiza¸c˜ao baseada em hypervisor . . . 18

3.1.2 Virtualiza¸c˜ao baseada em contˆeiner . . . 20

xvii

(19)

xviii

3.1.3 Arquitetura NFV . . . 21

3.2 Redes definidas por software . . . 23

3.2.1 Arquitetura SDN . . . 24

3.3 Rela¸c˜ao da virtualiza¸c˜ao de rede com as redes definidas por software . . . . 25

3.4 Fatiamento de rede . . . 26

3.4.1 Entendendo o conceito de fatiamento . . . 26

3.4.2 Rela¸c˜ao das tecnologias de virtualiza¸c˜ao e o fatiamento de rede . . . 28

4 Computa¸cão na borda de acesso múltiplo (MEC) 29 4.1 Computa¸cão em nuvem (Cloud Computing) . . . 29

4.2 Computa¸c˜ao na borda (edge computing) . . . 30

4.3 Evolu¸c˜ao de MCC para MEC . . . 32

4.4 Modelo de referˆencia para arquitetura MEC . . . 33

4.4.1 Arquitetura de referˆencia do sistema MEC . . . 33

4.4.2 N´ıvel MEC host . . . 34

4.4.3 N´ıvel de sistema MEC . . . 36

4.5 Servi¸cos e aplica¸c˜oes MEC . . . 37

4.6 Seguran¸ca no ambiente MEC . . . 38

4.6.1 Arquiteturas de seguran¸ca com MEC . . . 38

4.7 MEC em redes 5G . . . 39

4.7.1 Integra¸c˜ao MEC e 5G . . . 41

4.7.2 Cen´arios de implementa¸c˜ao MEC integrados ao 5G . . . 42

5 Cen´ario MEC no Simu5G 44 5.1 Introdu¸c˜ao ao Simu5G . . . 45

5.2 Modelando a arquitetura MEC com Simu5G . . . 46

5.2.1 Modelagem dos componentes do n´ıvel de sistema MEC . . . 47

5.2.2 Modelagem dos componentes do n´ıvel de MEC host . . . 48

5.2.3 Modelagem dos aplicativos (endpoints) . . . 49

5.2.4 Modelagem dos servi¸cos MEC . . . 50

5.3 Simulando um cen´ario MEC integrado ao 5G dentro do Simu5G . . . 51

5.3.1 Cen´ario MultiMecHost e seu fluxo de requisi¸c˜oes . . . 51

5.4 Resultados observados do cen´ario MultiMecHost . . . 54

(20)

5.4.1 Intera¸c˜ao entre gNodeB e UE . . . 55

5.4.2 Estabelecimento de conex˜ao entre os demais elementos . . . 57

5.4.3 Escolha do Mec host pelo orquestrador . . . 57

5.4.4 Comportamento da aplica¸c˜ao . . . 59

5.4.5 Modifica¸cão dos parâmetros de recursos da aplica¸cão . . . 61

6 Conclus˜ao e Trabalhos Futuros 64

Referˆencias Bibliogr´aficas 66

(21)

Cap´ıtulo 1 Introdu¸ c˜ ao

As redes móveis vêm evoluindo cada vez mais rápido e de forma mais eficaz ao longo dos tempos, tendo sua demanda elevada conforme as necessidades dos usuários aumentam. Com in´ıcio a partir do sinal analógico, na primeira gera¸cão (1G) [1], para o digital, na segunda gera¸cão (2G), permitindo comunica¸cão através de voz e mensagens de texto. Através da terceira gera¸cão (3G), teve-se acesso à comuta¸cão de pacotes, usadas para fornecer servi¸cos de banda larga ou multim´ıdia. Como exemplos disso, podem ser citados a telefonia de banda larga não fixa, as videochamadas, dados enviados por rede sem fio de banda larga, bem como o envio de correios eletrônicos e acesso a URLs (Uniform Resource Locator) de qualquer lugar dependendo da cobertura da operadora, porém tudo ainda de forma limitada.

Foi na quarta gera¸cão (4G) que houve um avan¸co tecnológico significativo, fazendo com que os usuários explorem novas velocidades e capacidades de download, podendo ter acesso via dados móveis a servi¸cos que até então eram feitos apenas por rede de banda larga fixa, como assistir um filme pelo celular, participar de jogoson-line, entre outros. O uso do celular cresceu substancialmente ao longo desses anos. Hoje é muito fácil pensar que é poss´ıvel participar de redes sociais, comunicando-se com pessoas ao redor do mundo, ao mesmo tempo em que é visto um filme ou um v´ıdeo no Youtube, por exemplo, o que era muito dif´ıcil imaginar há alguns anos. O 4G já consegue proporcionar essa conectividade, porém a quinta gera¸cão (5G), que é o foco deste trabalho, vem como um avan¸co para muito além do uso pessoal de Internet móvel [2].

Al´em de uma taxa muito elevada, o 5G traz a possibilidade de conectividade massiva para outros aparelhos al´em do celular, sendo dispositivos que podem estar localizados

(22)

no ambiente doméstico e no ambiente industrial. O 5G vem com o objetivo não somente de conectar pessoas, mas também de conectar qualquer dispositivo que tenha acesso à In- ternet, sendo um componente muito importante para o desenvolvimento abrangente das comunica¸cões Máquina-a-Máquina (M2M) e da Internet das Coisas (IoT) [2].

IoT se tornou o termo para definir a conexão entre objetos usados no dia-a-dia, como eletrodomésticos e até mesmo meios de transporte, a fim de facilitar a vida de usuários e automatizar processos que hoje são feitos pelo ser humano de forma manual e mais demorada. É viável, portanto, entender que haverá uma crescente demanda por tarefas computacionais de aplica¸cões, aumentando o volume de tráfego, além de servi¸cos demandando um tempo de atraso praticamente nulo. No entanto, a maioria dos usuários finais possui capacidade limitada de armazenamento e processamento [3].

Tendo isso em vista, este trabalho possui como objetivo apresentar a tecnologia MEC (Multi-Access Edge Computing), ou seja, computa¸cão na borda da rede de dados, como propulsora do 5G para otimizar a execu¸cão de tarefas e tempo de resposta das aplica¸cões através da aproxima¸cão da capacidade de recursos de computa¸cão em nuvem para os usuários finais. Além de trazer, também, o uso do Simu5G, como simulador de um cenário existente, para compreensão da arquitetura MEC integrada com as redes 5G.

A organiza¸cão desse trabalho é estruturado em 6 Cap´ıtulos. O Cap´ıtulo 2 inicia com uma visão geral de redes móveis, evidenciando a evolu¸cão da arquitetura 4G até o 5G, além de abordar as caracter´ısticas da quinta gera¸cão. Já no Cap´ıtulo 3, são abordadas algumas tecnologias importantes para a implementa¸cão do 5G, como virtualiza¸cão e redes definidas por software. No Cap´ıtulo 4, é apresentada a arquitetura MEC a partir do conceito de computa¸cão de borda, trazendo sua importância para a implementa¸cão do 5G.

No Cap´ıtulo 5, é apresentado um cenário existente de simula¸cão do Simu5G que ilustra o uso da arquitetura MEC em conjunto com o 5G, tendo como objetivo a demonstra¸cão dos conceitos abordados e complementar o conhecimento adquirido nesse trabalho. Por fim, o Cap´ıtulo 6 traz a s´ıntese do desenvolvimento do estudo com os resultados encontrados e as propostas para poss´ıveis trabalhos futuros.

(23)

Cap´ıtulo 2

Evolu¸ c˜ ao das redes m´ oveis do 4G ao 5G

Desde a cria¸cão da primeira gera¸cão de redes móveis nos anos 1970, o mundo passou por revolu¸cões importantes na forma como as pessoas se comunicam. A necessidade por conectividade tornou-se primordial para a dissemina¸cão de informa¸cão e a tecnologia vem sendo a maior aliada para diminuir as fronteiras entre as na¸cões. Este cap´ıtulo, a fim de evidenciar essas mudan¸cas, abordará os requisitos e caracter´ısticas de servi¸co do 5G, evidenciando, as faixas de frequências de rádio utilizadas e a evolu¸cão das redes móveis, passando pela arquitetura adotada para a quarta gera¸cão (4G) até a que será utilizada para o 5G.

2.1 Introdu¸ c˜ ao ` a evolu¸c˜ ao das redes m´ oveis

Devido à crescente demanda por consumo de dados, como aplica¸cões de realidade virtual, Internet das Coisas e inteligência artificial, surge a necessidade de prover servi¸cos que sejam capazes de suprir requisitos de baixa latência, alta largura de banda e boa qualidade de servi¸co. Estima-se que, em 2027, o tráfego de dados móveis será de 282 Exabytes (EB) por mês [4] globalmente. Tendo isso em vista, a quinta gera¸cão da conexão de Internet móvel, introduz-se como tecnologia que é capaz de dar suporte ao aumento de tráfego e demandas computacionais. Assim, é esperado que, em 2027, 62% do tráfego total de dados móveis sejam de redes 5G [5].

As redes 5G são capazes de prover baixa latência e taxas de transmissão acima de 1 Gb/s, permitindo que diversos setores do mercado, tais como indústria, entretenimento, agricultura e saúde, alavanquem suas etapas de evolu¸cão [6]. Fica claro, portanto, que

3

(24)

essa nova gera¸cão não trará apenas benef´ıcios a usuários comuns, mas também irá abrir uma nova perspectiva de avan¸cos para comunica¸cões entre máquinas.

As empresas serão fortemente beneficiadas com a chegada do 5G, com o seu foco na automa¸cão industrial, tendo seus processos e máquinas operadas à distância, em uma comunica¸cão sem fio, durante toda a linha de produ¸cão [7]. Na indústria automobil´ıstica é esperada uma mudan¸ca tanto na parte de automa¸cão do processo de cria¸cão, quanto após a confeçcão, onde automóveis possam estar conectados, permitindo intera¸cão entre servi¸cos e pessoas, contando com recursos variados, como diagnóstico do ve´ıculo, suporte através de uma central de atendimento, entre outros, trazendo conforto, praticidade e seguran¸ca ao usuário [8]. Na área da saúde, o 5G também terá muita relevância, trazendo melhorias e suporte para servi¸cos como cirurgia remota assistida por robótica, podendo salvar vidas em lugares remotos, por exemplo, assim como o rastreamento de ativos hospitalares, monitoramento remoto de dados de saúde, medica¸cão inteligente e muitos outros recursos [9].

Em termos de padroniza¸cão, o grupo de rádio-comunica¸cão da União Internacional de Telecomunica¸cões (ITU-R), desenvolveu as especifica¸cões IMT-2020 (International Mo- bile Telecommunications-2020) para atender as redes 5G, a fim de estabelecer os requisitos para a constru¸cão da tecnologia. Com base nesses requisitos, o 3GPP (3rd Generation Partnership Project), que é a organiza¸cão que desenvolve aspectos de tecnologias de rádio e elementos de rede, lan¸cou especifica¸cões para o sistema de interface de rádio 5G New Radio (NR), e da rede de núcleo 5G Core (5GC) para atendê-los [10].

2.2 Requisitos para atender o 5G

Em fevereiro de 2017 houve uma reunião com membros da ITU-R juntamente com os Estados Membros, reunidos em Genebra, para completar uma rodada de estudos sobre os requisitos necessários de desempenho da tecnologia 5G para o IMT-2020. En- tre os membros presentes estavam os principais participantes da indústria, organiza¸cões nacionais e regionais de desenvolvimento de padrões, fóruns da indústria, reguladores, operadores de rede, fabricantes de equipamentos, assim como institui¸cões acadêmicas e de pesquisa [11]. Nessa reunião foi desenvolvido o documento ITU-R SG05 Contribution 40 [12], com os requisitos m´ınimos para atender as performances necessárias das interfaces

(25)

5 de r´adio IMT-2020.

Dentre as diretrizes requeridas neste documento, estão as taxas teóricas máximas de pico de downlink e uplink, de 20 Gb/s e 10 Gb/s, respectivamente. As taxas de pico são são taxas de dados máximas alcan¸cáveis sob condi¸cões ideais. Já na parte prática, levando em conta a experiência do usuário, a taxa de dados de downlink é de 100 Mb/s, enquanto a taxa de uplink fica em 50 Mb/s. Esses requisitos são definidos para fins de avalia¸cão no cenário de uso do eMBB (Enhanced Mobile Broadband).

Em rela¸cão à latência do plano de usuário, que de modo simplificado diz respeito ao tempo unidirecional levado para entregar um pacote da camada de aplica¸cão com sucesso até a sua chegada no destino em uma interface de rádio para uplink ou downlink [12], os requisitos são de 4 ms para o tráfego de banda larga eMBB e 1 ms para tráfegos URLLC (Ultra-Reliable Low Latency Communication), que são aplica¸cões mais sens´ıveis que requerem uma baix´ıssima latência. Tais cenários citados aqui serão explicados mais a fundo na Se¸cão 2.3. Na parte de mobilidade, a velocidade máxima da esta¸cão móvel em que uma qualidade de servi¸co pode ser alcan¸cada é de 500 km/h em um ve´ıculo de alta velocidade, mas esse parâmetro se divide em mais outras classes: estacionário (parado) e veicular, que vai de 10 km/h a 120 km/h [12][13].

Esses e mais alguns requisitos est˜ao resumidos na Tabela 2.1.

Tabela 2.1: Requisitos m´ınimos do 5G [12].

Capacidade Requisitos

Taxa de pico dedownlink 20 Gb/s

Taxa de pico de uplink 10 Gb/s

Taxa de dados downlink (experiência do usuário) 100 Mb/s Taxa de dados uplink (experiência do usuário) 50 Mb/s

Latˆencia 4 ms / 1 ms

Mobilidade 500 km/h

Densidade de conexão (dispositivos por km²) 1000000/km² Eficiência energética Igual à do 4G Capacidade de tráfego da área 10 Mb/s/m²

A partir dos requisitos esperados para o 5G, é poss´ıvel realizar uma compara¸cão com o 4G para sermos capazes de analisar a evolu¸cão entre duas gera¸cões. Na Tabela 2.2

(26)

pode-se ver a diferen¸ca de desempenho entre alguns parˆametros mais relevantes das duas gera¸c˜oes.

Tabela 2.2: Compara¸c˜ao dos parˆametros entre 4G e 5G.

Latência Taxa de transferência Conexões Mobilidade Fatiamento 5G 1 ms 10 Gb/s 1000000/km² 500km/h Dezenas de redes

Diferen¸ca 30∼50x 100x 100x 1.5x ≥10x

4G 30∼50ms 100Mb/s 10000/km² 350km/h Rede ´unica

2.3 Categorias de servi¸co

De acordo com a necessidade dos usuários, seja de uso convencional ou para milhares de dispositivos conectados à rede, apenas um cenário não é capaz de descrever os requisitos citados na Se¸cão 2.2. Com o objetivo de suprir isso, foram definidos três cená- rios de categorias de servi¸cos que agrupam caracter´ısticas comuns para o 5G, sendo eles eMBB, URLLC e mMTC (Massive Machine Type Communication).

Tais cen´arios e seus servi¸cos que ser˜ao atendidos podem ser visualizados na Figura 2.1.

Figura 2.1: Cen´arios de categorias de servi¸cos [24].

O cenário de eMBB consiste em servi¸cos que requerem conexões estáveis com alta taxa de transmissão que sejam capazes de abranger uma grande área de cobertura. É um servi¸co direcionado para usuários finais comuns, sendo uma extensão do servi¸co de 4G [14], que permite melhorar a experiência do usuário com rela¸cão à qualidade. Alguns usos

(27)

7 que est˜ao associados a essa categoria s˜ao de realidade aumentada e realidade virtual [15].

O cenário de URLLC diz respeito aos servi¸cos de pontos chaves como transmissões com baixa latência, confiabilidade e disponibilidade [16]. Esse cenário vai permitir o desenvolvimento de novas aplica¸cões que poderão ser utilizadas com robótica, automa¸cão, aprendizado de máquinas e inteligência artificial e vão requerer resposta com baixo tempo de resposta. Desbloqueiam-se, assim, comunica¸cão entre ve´ıculos, Internet táctil, cirurgia remota e controle remoto de máquinas.

O cenário de mMTC será caracterizado por suportar conexões para um grande nú- mero de dispositivos de Internet das Coisas, transmitindo relativamente um baixo volume de dados que não sejam sens´ıveis a atrasos [16]. Assim, possui como requisito uma alta importância para densidade de conexão. Esse servi¸co torna-se ideal para redes de sensores sem fio, cidades inteligentes, transporte e log´ıstica.

No 5G, a coexistência desses três grupos de servi¸cos em uma mesma arquitetura de rede será poss´ıvel gra¸cas ao surgimento da utiliza¸cão de fatiamento da rede (Network Slicing). Essencialmente, o fatiamento da rede permite alocar recursos de computa¸cão, armazenamento e comunica¸cão entre os servi¸cos ativos com a finalidade de garantir isolamento e prover bom desempenho [14]. O conceito de fatiamento é aprofundado na Se¸cão 3.4.

2.4 Caracter´ısticas da camada f´ısica

2.4.1 Espectro de uso

Para oferecer uma boa experiência de uso com o 5G, é preciso espectro de rádio suficiente que seja capaz de atender os servi¸cos. Com isso, a nova tecnologia de rádio 5G NR divide o espectro em três faixas de frequências, de acordo com a Figura 2.2.

Figura 2.2: Espectros de banda baixa, m´edia e alta para 5G. Adaptado de [17].

(28)

Bandas Baixas situam-se em frequências abaixo de 1 GHz [17], capazes de abranger grandes áreas geográficas, como ambientes internos, urbanos, suburbanos e rurais. Terá melhor performance para equipamentos que estejam próximos da esta¸cão, mas é um bom ponto para in´ıcio das redes 5G.

Bandas Médias são frequências que estão entre 1 GHz e 6 GHz, que são ideais para entregar grande quantidade de dados sobre distâncias significativas com taxas esperadas entre 600 Mb/s e 900 Mb/s [17].

Bandas Altas compreendem frequências acima de 6 GHz [17], caracterizadas por ondas milimétricas, também conhecidas comommWave. AsmmWave são ondas que ope- ram em frequências entre 30 GHz a 300 GHz e poderão atender os servi¸cos que requisitam baixa latência, podendo fornecer até 10 vezes mais largura de banda comparada com a banda 4G [18]. Todavia elas são limitadas em cobertura, devido a seu comprimento de onda ser menor, não são capazes de ultrapassar edif´ıcios e obstáculos e tendem a serem absorvidas pela chuva [18].

Geralmente as frequências abaixo de 6 GHz são usadas para comunica¸cão celular, enquanto frequências maiores são usadas em servi¸cos como exame de imagem, na área de medicina, assim como sensoriamento remoto por micro-ondas, radioastronomia, entre outros [18]. O exacerbado aumento de tráfego faz com que o espectro de rádio fique con- gestionado, limitando a largura de banda para cada usuário e, assim, afetando a conexão.

Uma solu¸cão para este problema é o uso de frequências acima de 6 GHz para conexões sem fio, que não eram usadas para banda larga móvel [18].

2.4.2 Tecnologia MIMO massiva

Uma das principais tecnologias consideradas para o 5G é omassive MIMO (Multiple- Input Multiple-Output), que é uma evolu¸cão dos sistemas MIMO utilizados nas redes sem fio atuais e vistos como uma solu¸cão para o problema criado pelo tráfego massivo de dados e usuários. Essa tecnologia agrupa milhares de antenas atendendo centenas de usuários simultaneamente [19].

Conforme a quantidade de antenas aumenta, os feixes que são irradiados tornam- se mais estreitos e são focados espacialmente na dire¸cão do usuário, aumentando assim a sua taxa de transferência e reduzindo interferências para outros usuários que estejam próximos. As antenas usadas servirão para concentrar energia em uma região menor do

(29)

9 espa¸co, fornecendo melhor eficiˆencia e rendimento espectral [18].

2.4.3 C´ elulas pequenas

As células pequenas são esta¸cões base de baixa potência que abrangem pequenas

´

areas geográficas, podendo ter sua posi¸cão em qualquer lugar que tenha uma maior demanda ou uma cobertura densa, e tem como objetivo ampliar o sinal de transmissão.

Elas foram adicionadas em um primeiro momento no Release 9 da norma do 3GPP da tecnologia LTE (Long Term Evolution), em 2008 [20].

No 5G, trabalhando em conjunto com as ondas milimétricas e a tecnologia MIMO massiva, as células pequenas podem utilizar um número elevado de antenas formando feixes direcionais aos aparelhos móveis dos usuários com uma transmissão simultânea [21].

2.5 Evolu¸ c˜ ao da arquitetura do 4G ao 5G

2.5.1 Arquitetura 4G tradicional

A fim de cumprir com as demandas da quinta gera¸cão de redes móveis, como aumento da capacidade, altas taxas de transmissão, baixa latência e melhor qualidade de servi¸co, também se fez necessária uma evolu¸cão nos aspectos de arquitetura de rede [22].

No entanto, apesar da chegada dessa nova tecnologia, o 4G continuará existindo e atuará em conjunto com o 5G. Sendo assim, torna-se necessário apresentar as caracter´ısticas da rede 4G para ser viável compreender a transi¸cão e coexistência com o 5G.

A arquitetura tradicional para a quarta gera¸cão LTE é totalmente baseada em protocolo IP (Internet Protocol) e é formada, basicamente, por: núcleo da rede, também conhecida como EPC (Evolved Packet Core), sendo responsável por gerenciar a mobilidade, autentica¸cão, roteamento, e mais; E-UTRAN (Evolved Universal Terrestrial Radio Access Network), que é composta pelos equipamentos de usuários, UE (User Equipment), e eNodeBs (evolved Node B); e E-UTRA (Evolved Universal Terrestrial Radio Access), que é um sistema de interface de rádio [23].

O EPC tradicional ´e composto por alguns equipamentos de redes, destacando-se:

S-GW (Serving Gateway), P-GW (Packet Data Network Gateway), MME (Mobility Ma-

(30)

nagement Entity), HSS (Home Subscriber Server) e PCRF (Policy Control and charging Rules Function). Na Figura 2.3, pode-se visualizar a disposi¸c˜ao dos elementos e suas conex˜oes.

Figura 2.3: EPC tradicional. Adaptado de [24].

Abaixo, s˜ao descritos brevemente os componentes do EPC tradicional [23]:

• S-GW: É responsável por encaminhar os pacotes dos usuários.

• P-GW: provê a conectividade ao usuário para a rede externa de dados, sendo o ponto de entrada e sa´ıda de tráfego para o UE.

• MME: entidade responsável pela autentica¸cão, gerenciamento de mobilidade e han- dover, ou seja, as decisões mais importantes passam pelo MME. Permite a comunica¸cão e troca de sinaliza¸cão entre os equipamentos dos usuários e o EPC, assim como entre os eNodeBs e EPC.

• HSS: é o componente que contém o banco de dados central com as informa¸cões relativas ao usuário, incluindo a verifica¸cão do tipo de assinatura contratada com a operadora de rede.

(31)

11

• PCRF: garante que as pol´ıticas, qualidade de servi¸co de cada sess˜ao iniciada, e regras de tarifa¸c˜ao sejam cumpridas.

2.5.2 Evolu¸ c˜ ao da arquitetura 4G

Com a necessidade de maior flexibilidade e escalabilidade, foi introduzida pelo 3GPP, noRelease 14, a evolu¸cão da rede núcleo EPC tradicional para EPC CUPS (Con- trol and User Plane Separation), com separa¸cão dos planos controle e de usuário. Isso foi poss´ıvel porque alguns dos componentes requerem mais recursos de controle, como sinaliza¸cão. Outros podem precisar de pouca sinaliza¸cão, porém com alta demanda de tráfego de dados [25]. Com o surgimento do conceito de SDN (Software Defined Network) e NFV (Network Functions Virtualization), a separa¸cão desses planos foi viabilizada. Tais conceitos citados são detalhados nas Se¸cões 3.1 e 3.2.

EPC CUPS possibilita um uso mais eficiente da rede, uma vez que concentra o plano de controle centralizando suas fun¸cões, e deixa o tráfego de dados, que é o maior interesse do usuário, livre para desempenhar seu papel de entregar acesso aos servi¸cos e aplica¸cões. Além disso, o uso do CUPS possibilita a expansão independente de elementos de plano de usuário, sem necessidade de fazer o mesmo para elementos de plano de controle [24]. No EPC tradicional, os elementos que sofrem essa separa¸cão, são S-GW e P-GW, com SGW-C e PGW-C para o plano de controle e SGW-U e PGW-U para o plano de usuário.

A partir do CUPS, pode-se colocar os planos de usuários mais próximos da borda da rede, introduzindo o conceito deedge computing, pois permite que as aplica¸cões tenham menor tempo de resposta. Desse modo, o CUPS torna-se um dos primeiros passos para o in´ıcio da implementa¸cão da rede para o 5G. Na Figura 2.4, conseguimos analisar que a separa¸cão dos planos ocorre nos elementos citados no parágrafo anterior.

2.5.3 Arquitetura 5G

O 5G usa uma arquitetura de núcleo, conhecida como 5GCore (5GC), que enfatiza o NFV, computa¸cão em nuvem nativa (Cloud Native) e SDN como conceitos fundamentais para compor a implementa¸cão da infraestrutura MEC (Multi-Access Edge Computing), ou seja, computa¸cão na borda de acesso múltiplo, sendo foco central para os princ´ıpios da arquitetura da quinta gera¸cão [26].

(32)

Figura 2.4: EPC CUPS. Adaptado de [24].

Solu¸c˜oes de implementa¸c˜ao

Foram propostas duas solu¸cões pelo 3GPP para a nova gera¸cão. São elas:

• 5G Non Standalone (NSA) - utiliza o acesso ao rádio LTE existente, como suporte para gerenciamento de mobilidade e cobertura, e o 5G NR, conhecido como dupla conectividade, com a infraestrutura do 4G. É uma solu¸cão que permite implementa-

¸cão mais rápida, uma vez que usa uma infraestrutura já existente, e que custa mais barato para as operadoras.

• 5G Standalone (SA) - utiliza rede 5GC com acesso ao r´adio NR, ou seja, com infraestrutura independente do 4G, que ser´a capaz de desempenhar de fato as novas funcionalidades relacionadas ao fatiamento da rede com base nos servi¸cos.

Para aplicar essas solu¸cões, foram estabelecidas algumas op¸cões pelo 3GPP. Para o 5G NSA, pode-se visualizar as descri¸cões abaixo e as figuras correspondentes, onde as linhas cheias representam o plano de usuário e as tracejadas o plano de controle:

Op¸c˜ao 3 - usa a rede EPC e a interface de r´adio LTE como principal e 5G NR como

(33)

13 secund´aria. ´E representada pela Figura 2.5a.

Op¸cão 4 - usa a rede 5GC e a interface de rádio 5G NR como principal e a LTE como secundária. É representada pela Figura 2.5b.

Op¸cão 7 - usa a rede 5GC e a interface de rádio LTE como principal e 5G NR como secundária. É representada pela Figura 2.5c.

(a) Op¸cão 3 (b) Op¸cão 4 (c) Op¸cão 7

Figura 2.5: Op¸c˜oes do NSA. Adaptado de [24].

Para o 5G SA, pode-se visualizar as descri¸c˜oes abaixo e as figuras correspondentes, onde as linhas cheias representam o plano de usu´ario e as tracejadas o plano de controle:

Op¸cão 2 - usa a rede 5GC e a interface de rádio 5G NR exclusivamente. É representada pela Figura 2.6a.

Op¸cão 5 - usa a rede 5GC e a interface de rádio LTE exclusivamente. É representada pela Figura 2.6b.

(34)

(a) Op¸c˜ao 2 (b) Op¸c˜ao 5

Figura 2.6: Op¸c˜oes de SA. Adaptado de [24].

5G Core

Como evolu¸cão da arquitetura de núcleo EPC, os seguintes elementos principais da arquitetura baseada em servi¸cos da rede de núcleo 5GC [24] [3] podem ser verificados pela Figura 2.7:

• AMF (Access and Mobility Management Function): responsável pelas tarefas de conectividade, gerenciamento de mobilidade, autentica¸cão e autoriza¸cão do usuário.

Possui parte das funcionalidades do MME, SGW-C e PGW-C no EPC CUPS.

• SMF (Session Management Function): desempenha a funcionalidade de gerenciamento da sessão de acordo com as pol´ıticas de controle com a fun¸cão de plano do usuário. Possui parte das funcionalidades do MME, SGW e PGW no EPC.

• UPF (User Plane Function): realiza opera¸c˜oes de roteamento e encaminhamento de pacotes para a rede externa de dados e aloca¸c˜ao de endere¸cos IP. Possui parte das funcionalidades do PGW-U do EPC CUPS.

• NSSF (Network Slice Selection Function): provˆe a aloca¸c˜ao de recursos das fatias

(35)

15

Figura 2.7: Arquitetura baseada em servi¸cos da rede de n´ucleo 5GC. Adaptado de [24].

de rede, determinando o conjunto de AMF para o equipamento de usu´ario.

• NRF (Network Repository Function): suporta a descoberta das fun¸c˜oes de rede e seus servi¸cos.

• NEF (Network Exposure Function): fornece um meio para expor de forma segura os servi¸cos suportados pelas fun¸c˜oes de energia, promovendo comunica¸c˜ao segura.

• PCF (Policy Control Function): unifica as pol´ıticas de rede e promove regras para as fun¸c˜oes do plano de controle. Possui parte das funcionalidades do PCRF no EPC.

• UDM (Unified Data Management): lida com as subscri¸cões do usuário e servi¸cos de identifica¸cão, possuindo parte das funcionalidades do HSS no EPC.

• UDR (Unified Data Repository): banco de dados que possui as informa¸c˜oes dos usu´arios.

• UDC (User Data Convergence): composto pelos elementos UDR, UDM, AUSF e PCF.

(36)

• AUSF (Authentication Server Function): ´e um servidor que realiza procedimentos de autentica¸c˜ao. Possui parte das funcionalidades do HSS no EPC.

• AF (Application Function): é responsável por verificar as aplica¸cões classificadas como confiáveis para a operadora.

Essa abordagem do 5GC permite que o volume de tráfego de dados seja roteado na borda da rede, através de UPFs distribu´ıdos geograficamente para que estejam próximos dos usuários, possibilitando que o plano de controle possa estar centralizado com seus servi¸cos espec´ıficos, ancorando esses UPFs. Através do conceito de distribui¸cão dos planos de usuários, é poss´ıvel prover aplica¸cões MEC.

(37)

Cap´ıtulo 3

Tecnologias centrais para o 5G

A necessidade de distribuir geograficamente os recursos de computa¸cão para atender aos usuários requer que mais elementos de rede sejam utilizados, o que ocasiona um aumento de custo para implementa¸cão de projetos se os equipamentos fossem de uso dedicado. Assim, este Cap´ıtulo inicia com a conceitua¸cão da virtualiza¸cão baseada em hypervisor e em contêiner, que possibilita a melhor utiliza¸cão dos recursos dispon´ıveis.

Em seguida, é dado enfoque às redes definidas por software (Software Defined Networks - SDN) para evidenciar as vantagens da separa¸cão dos planos de controle e de dados. Além disso, é explicada a rela¸cão da virtualiza¸cão com as redes definidas por software, tornando poss´ıvel abordar o conceito deNetwork Slicing a partir da sua rela¸cão com essas tecnologias, bem como a importância da computa¸cão em nuvem e borda em sua implementa¸cão. Desse modo, são relatadas as tecnologias essenciais e facilitadores para o funcionamento do 5G.

3.1 Virtualiza¸ c˜ ao

Com rela¸cão aos equipamentos f´ısicos que desempenham as fun¸cões de rede, era comum que fossem dedicados para algum servi¸co ou aplica¸cão espec´ıfica. Recursos como memória, armazenamento, placas de rede, CPU (Central Processing Unit) precisavam ser de uso exclusivo, mesmo que isso implicasse ficar eventualmente ociosos. Porém, com o surgimento da virtualiza¸cão, foi poss´ıvel dissociar o hardware das fun¸cões virtuais de rede [27], permitindo que os recursos sejam utilizados de forma mais eficiente e sendo alocados conforme a necessidade.

17

(38)

Pode-se imaginar como exemplo, um servidor DNS (Domain Name System) e um servidor de e-mail operando de forma individual e em equipamentos separados. Porém, em um cenário em que os recursos não são utilizados em sua capacidade total, há desper- d´ıcio do potencial do hardware, ocupa¸cão f´ısica em um ambiente de data center e gasto de energia. Ou seja, custos que podem ser reduzidos com a implementa¸cão da virtualiza¸cão. Com a virtualiza¸cão, tanto o servidor de DNS e de e-mail podem coexistir sobre um mesmohardware, cada um com seus recursos alocados e funcionando de maneira isolada. Consolidando, desse modo, servidores com diferentes funcionalidades em um mesmo equipamento f´ısico a fim de se obter melhor aproveitamento.

Existem alguns tipos de virtualiza¸cão como a de dados, ambientes de trabalho, servidores, sistemas operacionais, e fun¸cões de redes [28]. Fora os tipos mencionados, também há as diferentes formas de virtualizar, podendo ser baseada em hypervisor ou contêiner.

3.1.1 Virtualiza¸ c˜ ao baseada em hypervisor

Uma alternativa aos dispositivos dedicados são as máquinas virtuais (Virtual Ma- chines - VMs), que podem ser executadas sobre a mesma infraestrutura f´ısica, desempe- nhando diferentes servi¸cos. Ao utilizar a virtualiza¸cão baseada em hypervisor, pode-se aumentar a eficiência energética, assim como diminuir a utiliza¸cão de espa¸co emdata centers, devido à otimiza¸cão no uso dos recursos dehardware, por exemplo [29, 30]. Diversos servi¸cos podem ser colocados dentro da mesma infraestrutura dehardware, evitando oci- osidade de recursos, o que é chamado de consolida¸cão de servidores, e consequentemente, o custo operacional diminui. Além disso, a recupera¸cão de desastres em um ambiente virtual é muito mais rápida do que um equipamento f´ısico exclusivo. Caso haja falha no hardware, as VMs podem ser movidas para uma outra infraestrutura de servidor, tornando o problema mais fácil de ser resolvido [29, 30].

Para separar a infraestrutura f´ısica dos servi¸cos e aplica¸cões, é utilizado um hypervisor, também conhecido como monitor de VMs. O hypervisor é uma camada desoftware que gerencia a cria¸cão, armazenamento e o controle das máquinas virtuais, tratando os recursos comopool que podem ser realocados para VMs existentes ou para novas [28, 30].

E o´ hypervisor que vai permitir a cria¸cão e a defini¸cão de configura¸cões das máquinas virtuais, fazendo a comunica¸cão com ohardware da máquina real propriamente dita. Através

(39)

19 dele, v´arios sistemas operacionais diferentes podem ser executados de forma isolada em um mesmo computador.

Existem dois tipos dehypervisors, do tipo 1 e 2 [30]. O tipo 1, também chamado de bare metal ou nativo, é executado nohardware, tendo acesso direto aos recursos. Ele atua como uma camada desoftwareentre ohardwaree as máquinas virtuais. É responsável pelo suporte as cópias do hardware real (VMs), sendo similar aos processos que um sistema operacional real executa [29, 30]. Alguns exemplos do tipo 1 são VMWare vSphere e Hyper-V [30].

O tipo 2, também conhecido comohosted, é implementado comosoftware sobre um sistema operacional. Ele atua como um processo dentro do sistema operacional real/an- fitrião [30]. Tem-se o hardware e, em seguida, o sistema operacional que tem diversas aplica¸cões, e entre esses diversos programas um deles é o hypervisor. Logo, o tipo 2 concorre com os recursos de hardware com as outras aplica¸cões. Sendo assim, pode-se afirmar que o hypervisor do tipo 1 tem um melhor desempenho, tendo em vista que ele não compartilha recursos. Alguns exemplos do tipo 2 sãoVMware Workstation eOracle VirtualBox [30, 29]. Pode-se visualizar os tipos de hypervisor na Figura 3.1.

(a) Tipo 1 (b) Tipo 2

Figura 3.1: Tipos de Hypervisor.

Um dos desafios do uso da virtualiza¸cão é o investimento inicial no hardware que aloque tantos recursos, assim como o custo com manuten¸cão. Também pode ser citado como um desafio a sobrecarga necessária para cada máquina virtual individual em seu servidor f´ısico. Como há uma camada a mais de software (hypervisor), é necessário um processamento maior para o funcionamento das máquinas do que seria para um ambiente sem virtualiza¸cão, pois parte dos recursos do hardware são usados para o funcionamento

(40)

dessa camada [31].

3.1.2 Virtualiza¸ c˜ ao baseada em contˆ einer

A arquitetura da virtualiza¸cão baseada em contêiner, vista na Figura 3.2, é um pouco diferente da baseada emhypervisor, vista na subse¸cão 3.1.1. Com ohypervisor, um servidor executa diversas VMs, cada uma com um sistema operacional próprio, usando múltiplos recursos, o que gera sobrecarga. Por outro lado, nos contêineres não é necessário ter uma camada de emula¸cão ou um hypervisor para serem executados, ao invés disso, é usado uma interface no n´ıvel do sistema operacional.

Em [32], a conteineriza¸cão é definida como um mecanismo que empacota arquivos, códigos, configura¸cão e dependências de aplica¸cões por uma tecnologia chamada contêiner, abrangendo caracter´ısticas de portabilidade, escalabilidade, isolamento e economicidade de recursos. Tal tecnologia tornou-se uma alternativa leve e flex´ıvel a ambientes que exi- gem agilidade, pois os contêineres oferecem maximiza¸cão da produtividade e desempenho das opera¸cões [33]. Os contêineres são carregados sobre o kernel do sistema operacional, logo as instâncias são executadas diretamente no sistema operacional hospedeiro sem utilizar um hypervisor, o que garante redu¸cão na sobrecarga dos recursos e aumenta o desempenho das tarefas executadas [34, 35].

O ambiente conteinerizado, visto na Figura 3.2, é composto pelo sistema operacional hospedeiro, o mecanismo de distribui¸cão que faz o gerenciamento dos contêineres e três contêineres com seus respectivos processos e bibliotecas de cada aplica¸cão. Um exemplo de gerenciador de contêineres muito usado no mercado é chamado Docker, que é uma solu¸cão de código aberto, desenvolvido em 2008 pela equipe Docker, capaz de construir, distribuir e executar contêineres [36].

Assim, são criados os contêineres, onde são armazenados apenas os arquivos neces- sários para executar um ou mais processos das aplica¸cões, como aplicativos Java, aplicativos daWeb, entre outros [37, 38]. Cada aplicativo é executado em cima de um contêiner isolado, e, por mais que usem o mesmo sistema operacional, eles não podem ver os recursos uns dos outros, não existindo dependências entre eles.

Uma das maiores vantagens dos contêineres é que eles podem inicializar rapidamente, o que é uma diferen¸ca significativa em rela¸cão à virtualiza¸cão comhypervisor, onde os sistemas operacionais podem demorar para inicializar, pois precisam carregar arquivos

(41)

21 na memória e iniciar diversos servi¸cos e processos que podem levar um tempo, enquanto a imagem inicializada no contêiner possui apenas dependências e binários para o carrega- mento dos arquivos de aplica¸cão [32]. Uma outra vantagem é que eles são eficientes em termos de recursos, não precisam ter várias instâncias do sistema operacional subjacente, o contêiner só precisa da memória necessária para ter o aplicativo executado. Nesse caso, não há sobrecarga [37].

De uma forma resumida, independentemente se for na forma de máquinas virtuais ou contêineres, a virtualiza¸cão é capaz de prover independência entre servi¸cos heterogê- neos, abstra¸cão de recursos e isolamento entre as opera¸cões [39]. De um modo geral, os contêineres são mais leves do que as VMs e possuem um sistema operacional comparti- lhado, sendo ideais para ambientes nativos em nuvem. Com máquinas virtuais, pode-se executar mais opera¸cões do que em contêineres e é poss´ıvel ter um sistema operacional para cada VM [40]. Desse modo, a escolha da forma de virtualizar, irá depender da necessidade do ambiente.

Figura 3.2: Virtualiza¸c˜ao baseada em Contˆeiner.

3.1.3 Arquitetura NFV

NFV (Network Function Virtualization) ou Virtualiza¸cão de Fun¸cões de Rede, é uma tecnologia com intuito de decompor servi¸cos de telecomunica¸cões em fun¸cões virtuais, chamadas VNFs (Virtualized Network Functions), que funcionam em máquinas virtuais ou contêineres ao invés de dispositivos f´ısicos especializados, podendo ser instaladas em data centers centralizados ou em PoPs (Points of Presence), na borda da rede.

Gerenciar máquinas virtuais ou contêineres pode ser uma tarefa árdua à medida em que crescem na quantidade. A arquitetura NFV promete diversos benef´ıcios para o

(42)

ambiente MEC, facilitando o gerenciamento, pois permite aprovisionamento flex´ıvel de recursos computacionais, implementa¸cão rápida de novos servi¸cos e redu¸cão de custo de hardwareatravés da virtualiza¸cão [41], o que é ideal para o cenário do 5G que precisará de diferentes elementos de redes. A arquitetura NFV foi padronizada pelo ETSI (European Telecommunications Standards Institute) e pode ser visualizada pela Figura 3.3.

Figura 3.3: Arquitetura em alto n´ıvel de NFV. Adaptado de [42].

A arquitetura NFV, em alto n´ıvel, pode ser visualizada em trˆes blocos funcionais principais na Figura 3.3: NFVI (NFVInfrastructure), VNF (Virtualized Network Functi- ons) e NFV MANO (Management and Orchestration) [42].

O bloco NFVI provê recursos f´ısicos, virtuais e desoftware necessários para suportar a execu¸cão das fun¸cões virtuais de rede, ou seja, apresenta os recursos de infraestrutura como recursos virtuais, através da camada de virtualiza¸cão, para serem alocados para as VNFs.

O bloco VNF é a implementa¸cão de software da fun¸cão de rede que é capaz de rodar sobre a infraestrutura NFV (NFVI) e é implementada por máquinas virtuais. No caso da implementa¸cão por contêineres, também é conhecida como CNF (Cloud-Native Network Function). Esse bloco pode exemplificar as fun¸cões dos elementos da rede 5GC como SMF, AMF, PCF e UPF.

O bloco NFV MANO realiza a orquestra¸c˜ao e gerenciamento do ciclo de vida de recursos f´ısicos e/ou desoftware, podendo ser descrito por trˆes elementos: VIM (Virtua-

(43)

23 lized Infrastructure Manager), respons´avel por gerenciar os recursos providos pelo NFVI;

VNFM (VNF Manager) realiza o gerenciamento de ciclo de vida das VNFs, ou seja, controla a instancia¸c˜ao, termina¸c˜ao e escalonamento das VNFs; e o Orquestrador, que coordena todos esses elementos e gerencia os servi¸cos fim-a-fim entre diferentes VNFs.

3.2 Redes definidas por software

Tradicionalmente, em um mesmo dispositivo de rede como um roteador, por exemplo, existem os planos de dados e de controle não desacoplados. O plano de dados é responsável por encaminhar os pacotes gerados pelos usuários de acordo com uma po- l´ıtica estabelecida, enquanto o plano de controle realiza a descoberta de topologia para tomar decisões de roteamento. Esse funcionamento torna o processo de gerenciamento custoso [41]. A rede definida por software, SDN, surge como uma estrutura capaz de separar esses planos de forma que seja viável oferecer melhor controle e gerenciamento sobre a rede através de uma arquitetura flex´ıvel e altamente programável.

Na Figura 3.4 é percept´ıvel notar as diferen¸cas entre uma arquitetura de rede tradicional e uma arquitetura SDN. Em 3.4a, nota-se que existe um plano de controle para cada plano de dados. Já em 3.4b, isso muda para o SDN, existindo apenas um plano de controle centralizado tomando decisões para os diversos planos de dados. Continuar com o uso apenas de uma rede tradicional, que acopla em um mesmo dispositivo o plano de dados e controle, pode ser prejudicial para a expectativa de aumento de tráfego, uma vez que necessita de configura¸cão e gerenciamento individual por equipamento. A rede SDN abre a possibilidade de controlar de forma unificada diversos dispositivos, tornando o processo mais ágil e escalável para a expansão e crescimento das redes.

Além das defini¸cões citadas, a ONF (Open Networking), que iniciou o movimento de SDN, também descreve a arquitetura como: ágil, por abstrair o controle do encaminhamento de dados, permitindo que administradores de rede ajustem o fluxo de tráfego conforme necessidade; gerenciada centralmente, por manter uma visão global da rede; e configurável por programa¸cão, pois permite gerenciar e otimizar recursos de rede de forma dinâmica e automática através de programas que não dependem do software proprietário [43].

(44)

(a) Rede tradicional (b) Rede definida porSoftware

Figura 3.4: Diferen¸ca da rede tradicional para a definida por Software.

3.2.1 Arquitetura SDN

A rede definida por software, representada pela Figura 3.5, possui uma arquitetura composta por três planos diferentes [44]. Em redes SDN, aparecem os conceitos de Northbound, em dire¸cão ao norte, e Southbound, em dire¸cão ao sul, APIs (Application Programming Interface) para descrever a dire¸cão da interface a partir da controladora SDN. A seguir, é descrita a arquitetura SDN e sua rela¸cão com as interfaces:

Figura 3.5: Arquitetura SDN. Adaptado de [44].

• Plano de aplica¸cão: diz respeito às aplica¸cões e seus servi¸cos de rede que se comuni-

(45)

25 cam com a controladora SDN atrav´es daNorthbound API, que permite a utiliza¸c˜ao de programas de alto n´ıvel para controlar a rede [45].

• Plano de controle: é a parte central e controladora da SDN, que mantém uma visão global e dinâmica da rede, recolhendo as requisi¸cões da camada de aplicativos e gerencia o comportamento dos dispositivos de rede através de protocolos padrões, como o OpenFlow.

• Plano de dados: contempla a infraestrutura de elementos de rede como switches, roteadores e fun¸cões de rede virtualizadas. Realiza comunica¸cão com a controladora SDN através da Southbound API, que permite a aplica¸cão controlar as pol´ıticas de encaminhamento por meio de programa¸cão.

3.3 Rela¸ c˜ ao da virtualiza¸ c˜ ao de rede com as redes definidas por software

NFV e SDN s˜ao muito importantes para desenvolver a abordagem de computa-

¸cão na borda para as redes móveis, porque são capazes de promover alta escalabilidade, enquanto os usuários finais estão mudando suas localiza¸cões rapidamente. Apesar de ambas as tecnologias se basearem em abstra¸cão de rede, são abordagens diferentes, po- rém complementares. Quando implementado o SDN em uma infraestrutura de NFV, por exemplo, a SDN encaminha os pacotes de um dispositivo de rede para o outro, contro- lando o roteamento, as pol´ıticas e as aplica¸cões que rodam sobre VMs ou contêineres por meio da capacidade de programabilidade. Torna-se viável compreender, portanto, que a virtualiza¸cão pode ser abordada nos três planos que compõem a SDN, nas aplica¸cões, nas controladoras SDN e nos dispositivos de rede.

Como exemplo, em [44] é proposto um sistema definido por software NFV, visto na Figura 3.6, com virtualiza¸cão baseada em hypervisor. Este sistema é composto por um módulo de controle, dispositivos de encaminhamento e plataforma NFV na borda da rede. A controladora SDN é responsável por determinar a lógica de encaminhamento de pacotes que é implementada pelos dispositivos de encaminhamento através de tabelas de roteamento. A plataforma NFV implementa as fun¸cões de rede sobre VMs, possibilitando alta largura de banda. O módulo de controle possui a controladora SDN e o orquestrador

(46)

NFV como componentes, sendo o último responsável por aprovisionar as fun¸cões virtuais de rede que são controladas pela controladora SDN pelas interfaces padronizadas.

Figura 3.6: Sistema SDN-NFV. Adaptado de [44].

3.4 Fatiamento de rede

O fatiamento de rede, ouNetwork Slicing, é uma abordagem de rede muito importante para o futuro do 5G. A sua importância dá-se devido à possibilidade de aloca¸cão de recursos de computa¸cão, isolando a rede e garantindo um maior desempenho. Assim, ele provê a coexistência dos grupos de servi¸cos eMBB, URLLC e mMTC, conforme citados na se¸cão 2.3.

3.4.1 Entendendo o conceito de fatiamento

De acordo com o 3GPP, o fatiamento permite que a operadora crie redes per- sonalizadas, fornecendo otimiza¸c˜oes diferentes para diversos cen´arios do mercado, com requisitos espec´ıficos exigidos para cada um, em termos de funcionalidade, desempenho e isolamento [46].

(47)

27 Como o próprio nome diz, são criadas “fatias da rede”, que são redes lógicas (virtuais), cada uma com suas próprias caracter´ısticas em cima de recursos f´ısicos comparti- lhados. Cada fatia pode ser dedicada a servi¸cos e clientes diferentes com caracter´ısticas espec´ıficas. Sendo assim, podem existir várias fatias dentro de uma mesma rede f´ısica fornecendo flexibilidade e eficiência no uso de recursos.

Para exemplificar, suponha dois cenários de aplica¸cões. Uma rede de ve´ıculos autônomos, onde é necessário que a rede provenha uma baixa latência e alta confiabilidade para garantir que não haja perda de pacotes e, assim, não afete a seguran¸ca do ve´ıculo e do usuário que estiver utilizando o servi¸co. Em outro cenário, é poss´ıvel ter uma aplica¸cão de realidade virtual, que exige um alto rendimento da rede com confiabilidade menor, pois uma resolu¸cão mais baixa não interfere na entrega do servi¸co. Com o fatiamento da rede, os parâmetros diferentes dos dois cenários podem ser entregues, ao mesmo tempo, em cima do mesmo hardware. Nesse caso, utilizando os mesmos recursos f´ısicos, uma fatia da rede seria usada para suportar o servi¸co de baixa latência, referente aos ve´ıculos, e outra fatia seria utilizada para fornecer uma alta taxa de transferência para a aplica¸cão de realidade virtual [47].

A Figura 3.7 ilustra fatias de rede isoladas em uma infraestrutura f´ısica compartilhada, onde cada fatia ´e adaptada `as necessidades de um caso de uso.

Figura 3.7: Exemplo de fatias de rede isoladas em uma infraestrutura compartilhada [48], onde a cor cinza representa a infraestrutura de rede em comum e as demais cores representam as fatias virtuais.

(48)

3.4.2 Rela¸ c˜ ao das tecnologias de virtualiza¸c˜ ao e o fatiamento de rede

O avan¸co das tecnologias citadas nas Se¸cões 3.1 e 3.2 são de suma importância para a implementa¸cão do fatiamento de rede. O fatiamento será poss´ıvel gra¸cas ao SDN, que atua no controle de vários dispositivos envolvidos, em conjunto com o NFV, que cria fun-

¸cões lógicas dedicadas para cada segmento. Enquanto o SDN atua no gerenciamento das fatias, aplicando as regras definidas para cada caso de uso, o NFV permite a virtualiza¸cão de fun¸cões originalmente baseadas em hardware, permitindo encadeamento de servi¸cos e gerenciamento de VNFs [49].

Os servi¸cos avan¸cados de 5G s˜ao projetados para serem oferecidos na borda da rede, estando muito mais perto do usu´ario, a fim de melhorar o atraso e o seu desempenho.

Sendo assim, a computa¸cão em nuvem e borda também será de grande importância para a implementa¸cão do fatiamento da rede. A computa¸cão em nuvem e a computa¸cão de borda permite o uso de recursos computacionais e de rede em várias plataformas, assim como recursos de armazenamento para habilitar uma fatia de rede [49]. A computa¸cão de borda fornece gerenciamento e análise de dados nas proximidades do usuário final, o que garante uma latência muito baixa e altas taxas de dados [50]. Uma arquitetura padrão da computa¸cão em borda é o MEC, que terá uma abordagem mais aprofundada no Cap´ıtulo 4.

(49)

Cap´ıtulo 4

Computa¸ c˜ ao na borda de acesso m´ ultiplo (MEC)

As arquiteturas tradicionais de rede sofrem com problemas de latência, cobertura e custo. Em [51], é relatado que 83% dos l´ıderes globais de tecnologia da informa¸cão têm a latência como um maior parâmetro que mais afeta o desempenho de suas aplica¸cões, e três em cada quatro se preocupam com a alta latência afetando a qualidade dos servi¸cos.

Para a solu¸cão de tal problema de latência e para ter uma economia de custos no longo prazo, é necessária uma arquitetura de computa¸cão de borda distribu´ıda e segura que opere mais perto dos seus usuários finais que produzem e consomem dados [51].

Sendo assim, este cap´ıtulo tem como objetivo mostrar uma op¸cão de tal arquitetura de borda, chamada arquitetura MEC (Multi-Access Edge Computing), passando pelo seu conceito vinculado ao edge computing e sua evolu¸cão vinda da computa¸cão em nuvem, assim como sua importância para a implementa¸cão do 5G, evidenciando seus servi¸cos e aplica¸cões, e também a parte de seguran¸ca.

4.1 Computa¸ c˜ ao em nuvem (Cloud Computing )

Com o advento do crescimento da Internet, tornou-se mais desafiador gerenciar os recursos de rede de forma eficiente. Na perspectiva dos dispositivos dos usuários, também há limita¸cões com rela¸cão ao tempo de vida de bateria de seus dispositivos de acesso, energia computacional e memória para processos complexos [52]. Tendo isso em vista, a computa¸cão em nuvem surge como ambiente capaz de suportar essas opera¸cões

29

(50)

mais complexas, movendo a execu¸cão das tarefas computacionais dos dispositivos para a nuvem. Mais especificamente, o MCC (Mobile Cloud Computing), é termo usado para a arquitetura de computa¸cão em nuvem implementada no cenário de redes móveis.

A computa¸cão em nuvem abrange o conceito de disponibiliza¸cão de recursos como armazenamento, banco de dados, e capacidade computacional para servi¸cos e aplica¸cões, que podem ser requisitados conforme necessidade, através da internet, podendo reduzir os custos operacionais. No entanto, costuma estar distante de dispositivos finais, por possuir uma arquitetura centralizada emdata centers, o que pode provocar atraso e má qualidade de experiência para aplica¸cões sens´ıveis à latência, como parte das que pretendem ser atendidas pelo 5G [53]. A partir disso, é poss´ıvel compreender o surgimento da ideia da computa¸cão na borda, ouedge computing em inglês. A computa¸cão na borda apresenta- se como novo paradigma capaz de realizar tarefas computacionais na borda da rede, de modo que esteja mais próximo do usuário e da origem dos dados, permitindo que o armazenamento e processamento seja mais leve para dados locais e de menor escala [54].

4.2 Computa¸ c˜ ao na borda (edge computing )

Com o uso da nuvem a rede ganha capacidade computacional e redu¸cão de custos, o que traz maior flexibilidade. Já a computa¸cão de borda fornece um meio de melhorias extras de desempenho, sobretudo em rela¸cão a análise de dados e tomada de decisões.

Pode-se afirmar que as duas tecnologias devem ser usadas em conjunto, pois uma com- plementa a outra.

A computa¸cão de borda é um modelo que permite a utiliza¸cão de servidores na borda em mini-nuvens (edge), que possuem a capacidade da nuvem em uma escala menor e são localizados mais próximos dos usuários finais, conforme visto na Figura 4.1. É um modelo diferente dos data centers usados na computa¸cão em nuvem que são localizados mais longe do usuário, de forma centralizada no core da rede, estando distantes dos UEs [55]. Essa proximidade do usuário é uma vantagem no processamento de dadoshard real- time, que são dados que possuem latência rigorosamente pré-definida [55]. Esse e outros tipos de dados são classificados na Se¸cão 4.7.

Sendo assim, ´e poss´ıvel expandir a capacidade computacional para a ponta da rede, tornando poss´ıvel a execu¸c˜ao de tarefas massivas e o armazenamento de grande quantidade