Isabela Lopes Miranda Nathalia Medeiros Gomes da Silva

Texto

(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˜ao de Curso apresentado ao Curso de Gradua¸c˜ao em Engenharia de Teleco- munica¸c˜oes da Universidade Federal Fluminense, como requisito parcial para obten¸c˜ao do Grau de Engenheiro de Telecomunica¸c˜oes.

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˜ao de Curso apresentado ao Curso de Gradua¸c˜ao em Engenharia de Teleco- munica¸c˜oes da Universidade Federal Fluminense, como requisito parcial para obten¸c˜ao do Grau de Engenheiro de Telecomunica¸c˜oes.

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´afego e servi¸cos que necessitam de baixa latˆencia, como ´e 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˜ao (5G), prometendo levar velocidade de comunica¸c˜ao e alta capacidade de processa- mento para mais perto do usu´ario, possibilitando as mudan¸cas demandadas. A pesquisa

´e baseada em um estudo te´orico da estrutura de redes 5G em conjunto com a arquitetura MEC, al´em de um estudo de caso j´a existente no simulador Simu5G. No cen´ario estudado

´e usado o servi¸co de localiza¸c˜ao de um MEC host, onde ´e poss´ıvel gerar notifica¸c˜oes de alerta para o aplicativo dos usu´arios conforme se movimentam em dire¸c˜ao a uma zona de monitoramento solicitada. A partir desse estudo te´orico e de caso, ´e poss´ıvel compre- ender como as arquiteturas 5G e MEC podem ser utilizadas de forma integrada e como funcionam seus servi¸cos e aplica¸c˜oes.

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 propor- cionar tudo que n´os temos hoje. `A minha m˜ae, Solange Miranda, meu grande alicerce da vida. Tenho certeza que todos os momentos desafiadores enfrentados ser˜ao lembran¸cas de um inverno, que n˜ao falhou em se tornar primavera, assim como diz o Buda Nichiren em seus incentivos.

Ao meu irm˜ao, Caio Lopes, por sempre me ajudar da melhor forma. `A minha av´o, Altinea Miranda, quem proporcionou meu estudos em 2012, mudando minha trajet´oria acadˆemica. 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˜ao Victor Moura e Daniel Guedes. Vocˆes tornaram todos os dramas acadˆemicos em muita risada e descontra¸c˜ao. 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´oria da faculdade de engenharia e na vida. Agrade¸co por vocˆe ser essa pessoa maravilhosa que me incentiva e me ajuda nos momentos mais dif´ıceis. Sou grata por dividir a vida com vocˆe.

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 enge- nharia 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˜ao dos parˆametros entre 4G e 5G. . . 6 5.1 Compara¸c˜ao 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˜ao `a evolu¸c˜ao das redes m´oveis . . . 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˜ao na borda de acesso m´ultiplo (MEC) 29 4.1 Computa¸c˜ao 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˜ao dos parˆametros de recursos da aplica¸c˜ao . . . 61

6 Conclus˜ao e Trabalhos Futuros 64

Referˆencias Bibliogr´aficas 66

(21)

Cap´ıtulo 1 Introdu¸ c˜ ao

As redes m´oveis vˆem evoluindo cada vez mais r´apido e de forma mais eficaz ao longo dos tempos, tendo sua demanda elevada conforme as necessidades dos usu´arios aumentam. Com in´ıcio a partir do sinal anal´ogico, na primeira gera¸c˜ao (1G) [1], para o digital, na segunda gera¸c˜ao (2G), permitindo comunica¸c˜ao atrav´es de voz e mensagens de texto. Atrav´es da terceira gera¸c˜ao (3G), teve-se acesso `a comuta¸c˜ao 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˜ao fixa, as videochamadas, dados enviados por rede sem fio de banda larga, bem como o envio de correios eletrˆonicos e acesso a URLs (Uniform Resource Locator) de qualquer lugar dependendo da cobertura da operadora, por´em tudo ainda de forma limitada.

Foi na quarta gera¸c˜ao (4G) que houve um avan¸co tecnol´ogico significativo, fazendo com que os usu´arios explorem novas velocidades e capacidades de download, podendo ter acesso via dados m´oveis a servi¸cos que at´e ent˜ao 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 ´e muito f´acil pensar que ´e poss´ıvel participar de redes sociais, comunicando-se com pessoas ao redor do mundo, ao mesmo tempo em que ´e visto um filme ou um v´ıdeo no Youtube, por exemplo, o que era muito dif´ıcil imaginar h´a alguns anos. O 4G j´a consegue proporcionar essa conectividade, por´em a quinta gera¸c˜ao (5G), que ´e o foco deste trabalho, vem como um avan¸co para muito al´em do uso pessoal de Internet m´ovel [2].

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

(22)

no ambiente dom´estico e no ambiente industrial. O 5G vem com o objetivo n˜ao somente de conectar pessoas, mas tamb´em de conectar qualquer dispositivo que tenha acesso `a In- ternet, sendo um componente muito importante para o desenvolvimento abrangente das comunica¸c˜oes M´aquina-a-M´aquina (M2M) e da Internet das Coisas (IoT) [2].

IoT se tornou o termo para definir a conex˜ao entre objetos usados no dia-a-dia, como eletrodom´esticos e at´e mesmo meios de transporte, a fim de facilitar a vida de usu´arios e automatizar processos que hoje s˜ao feitos pelo ser humano de forma manual e mais demorada. ´E vi´avel, portanto, entender que haver´a uma crescente demanda por tarefas computacionais de aplica¸c˜oes, aumentando o volume de tr´afego, al´em de servi¸cos demandando um tempo de atraso praticamente nulo. No entanto, a maioria dos usu´arios 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˜ao na borda da rede de dados, como propulsora do 5G para otimizar a execu¸c˜ao de tarefas e tempo de resposta das aplica¸c˜oes atrav´es da aproxima¸c˜ao da capacidade de recursos de computa¸c˜ao em nuvem para os usu´arios finais. Al´em de trazer, tamb´em, o uso do Simu5G, como simulador de um cen´ario existente, para compreens˜ao da arquitetura MEC integrada com as redes 5G.

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

No Cap´ıtulo 5, ´e apresentado um cen´ario existente de simula¸c˜ao do Simu5G que ilustra o uso da arquitetura MEC em conjunto com o 5G, tendo como objetivo a demonstra¸c˜ao 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˜ao da primeira gera¸c˜ao de redes m´oveis nos anos 1970, o mundo passou por revolu¸c˜oes importantes na forma como as pessoas se comunicam. A necessidade por conectividade tornou-se primordial para a dissemina¸c˜ao de informa¸c˜ao e a tecnologia vem sendo a maior aliada para diminuir as fronteiras entre as na¸c˜oes. Este cap´ıtulo, a fim de evidenciar essas mudan¸cas, abordar´a os requisitos e caracter´ısticas de servi¸co do 5G, evidenciando, as faixas de frequˆencias de r´adio utilizadas e a evolu¸c˜ao das redes m´oveis, passando pela arquitetura adotada para a quarta gera¸c˜ao (4G) at´e a que ser´a utilizada para o 5G.

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

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

As redes 5G s˜ao capazes de prover baixa latˆencia e taxas de transmiss˜ao acima de 1 Gb/s, permitindo que diversos setores do mercado, tais como ind´ustria, entretenimento, agricultura e sa´ude, alavanquem suas etapas de evolu¸c˜ao [6]. Fica claro, portanto, que

3

(24)

essa nova gera¸c˜ao n˜ao trar´a apenas benef´ıcios a usu´arios comuns, mas tamb´em ir´a abrir uma nova perspectiva de avan¸cos para comunica¸c˜oes entre m´aquinas.

As empresas ser˜ao fortemente beneficiadas com a chegada do 5G, com o seu foco na automa¸c˜ao industrial, tendo seus processos e m´aquinas operadas `a distˆancia, em uma comunica¸c˜ao sem fio, durante toda a linha de produ¸c˜ao [7]. Na ind´ustria automobil´ıstica ´e esperada uma mudan¸ca tanto na parte de automa¸c˜ao do processo de cria¸c˜ao, quanto ap´os a confec¸c˜ao, onde autom´oveis possam estar conectados, permitindo intera¸c˜ao entre servi¸cos e pessoas, contando com recursos variados, como diagn´ostico do ve´ıculo, suporte atrav´es de uma central de atendimento, entre outros, trazendo conforto, praticidade e seguran¸ca ao usu´ario [8]. Na ´area da sa´ude, o 5G tamb´em ter´a muita relevˆancia, trazendo melhorias e suporte para servi¸cos como cirurgia remota assistida por rob´otica, podendo salvar vidas em lugares remotos, por exemplo, assim como o rastreamento de ativos hospitalares, monitoramento remoto de dados de sa´ude, medica¸c˜ao inteligente e muitos outros recursos [9].

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

2.2 Requisitos para atender o 5G

Em fevereiro de 2017 houve uma reuni˜ao com membros da ITU-R juntamente com os Estados Membros, reunidos em Genebra, para completar uma rodada de estudos sobre os requisitos necess´arios de desempenho da tecnologia 5G para o IMT-2020. En- tre os membros presentes estavam os principais participantes da ind´ustria, organiza¸c˜oes nacionais e regionais de desenvolvimento de padr˜oes, f´oruns da ind´ustria, reguladores, operadores de rede, fabricantes de equipamentos, assim como institui¸c˜oes acadˆemicas e de pesquisa [11]. Nessa reuni˜ao foi desenvolvido o documento ITU-R SG05 Contribution 40 [12], com os requisitos m´ınimos para atender as performances necess´arias das interfaces

(25)

5 de r´adio IMT-2020.

Dentre as diretrizes requeridas neste documento, est˜ao as taxas te´oricas m´aximas de pico de downlink e uplink, de 20 Gb/s e 10 Gb/s, respectivamente. As taxas de pico s˜ao s˜ao taxas de dados m´aximas alcan¸c´aveis sob condi¸c˜oes ideais. J´a na parte pr´atica, levando em conta a experiˆencia do usu´ario, a taxa de dados de downlink ´e de 100 Mb/s, enquanto a taxa de uplink fica em 50 Mb/s. Esses requisitos s˜ao definidos para fins de avalia¸c˜ao no cen´ario de uso do eMBB (Enhanced Mobile Broadband).

Em rela¸c˜ao `a latˆencia do plano de usu´ario, que de modo simplificado diz respeito ao tempo unidirecional levado para entregar um pacote da camada de aplica¸c˜ao com sucesso at´e a sua chegada no destino em uma interface de r´adio para uplink ou downlink [12], os requisitos s˜ao de 4 ms para o tr´afego de banda larga eMBB e 1 ms para tr´afegos URLLC (Ultra-Reliable Low Latency Communication), que s˜ao aplica¸c˜oes mais sens´ıveis que requerem uma baix´ıssima latˆencia. Tais cen´arios citados aqui ser˜ao explicados mais a fundo na Se¸c˜ao 2.3. Na parte de mobilidade, a velocidade m´axima da esta¸c˜ao m´ovel em que uma qualidade de servi¸co pode ser alcan¸cada ´e de 500 km/h em um ve´ıculo de alta velocidade, mas esse parˆametro se divide em mais outras classes: estacion´ario (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ˆencia do usu´ario) 100 Mb/s Taxa de dados uplink (experiˆencia do usu´ario) 50 Mb/s

Latˆencia 4 ms / 1 ms

Mobilidade 500 km/h

Densidade de conex˜ao (dispositivos por km²) 1000000/km² Eficiˆencia energ´etica Igual `a do 4G Capacidade de tr´afego da ´area 10 Mb/s/m2

A partir dos requisitos esperados para o 5G, ´e poss´ıvel realizar uma compara¸c˜ao com o 4G para sermos capazes de analisar a evolu¸c˜ao entre duas gera¸c˜oes. 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ˆencia Taxa de transferˆencia Conex˜oes Mobilidade Fatiamento 5G 1 ms 10 Gb/s 1000000/km2 500km/h Dezenas de redes

Diferen¸ca 3050x 100x 100x 1.5x 10x

4G 3050ms 100Mb/s 10000/km2 350km/h Rede ´unica

2.3 Categorias de servi¸co

De acordo com a necessidade dos usu´arios, seja de uso convencional ou para mi- lhares de dispositivos conectados `a rede, apenas um cen´ario n˜ao ´e capaz de descrever os requisitos citados na Se¸c˜ao 2.2. Com o objetivo de suprir isso, foram definidos trˆes cen´a- 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´ario de eMBB consiste em servi¸cos que requerem conex˜oes est´aveis com alta taxa de transmiss˜ao que sejam capazes de abranger uma grande ´area de cobertura. ´E um servi¸co direcionado para usu´arios finais comuns, sendo uma extens˜ao do servi¸co de 4G [14], que permite melhorar a experiˆencia do usu´ario com rela¸c˜ao `a qualidade. Alguns usos

(27)

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

O cen´ario de URLLC diz respeito aos servi¸cos de pontos chaves como transmiss˜oes com baixa latˆencia, confiabilidade e disponibilidade [16]. Esse cen´ario vai permitir o desenvolvimento de novas aplica¸c˜oes que poder˜ao ser utilizadas com rob´otica, automa¸c˜ao, aprendizado de m´aquinas e inteligˆencia artificial e v˜ao requerer resposta com baixo tempo de resposta. Desbloqueiam-se, assim, comunica¸c˜ao entre ve´ıculos, Internet t´actil, cirurgia remota e controle remoto de m´aquinas.

O cen´ario de mMTC ser´a caracterizado por suportar conex˜oes para um grande n´u- mero de dispositivos de Internet das Coisas, transmitindo relativamente um baixo volume de dados que n˜ao sejam sens´ıveis a atrasos [16]. Assim, possui como requisito uma alta importˆancia para densidade de conex˜ao. Esse servi¸co torna-se ideal para redes de sensores sem fio, cidades inteligentes, transporte e log´ıstica.

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

2.4 Caracter´ısticas da camada f´ısica

2.4.1 Espectro de uso

Para oferecer uma boa experiˆencia de uso com o 5G, ´e preciso espectro de r´adio suficiente que seja capaz de atender os servi¸cos. Com isso, a nova tecnologia de r´adio 5G NR divide o espectro em trˆes faixas de frequˆencias, 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ˆencias abaixo de 1 GHz [17], capazes de abranger grandes ´areas geogr´aficas, como ambientes internos, urbanos, suburbanos e rurais. Ter´a melhor performance para equipamentos que estejam pr´oximos da esta¸c˜ao, mas ´e um bom ponto para in´ıcio das redes 5G.

Bandas M´edias s˜ao frequˆencias que est˜ao entre 1 GHz e 6 GHz, que s˜ao ideais para entregar grande quantidade de dados sobre distˆancias significativas com taxas esperadas entre 600 Mb/s e 900 Mb/s [17].

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

Geralmente as frequˆencias abaixo de 6 GHz s˜ao usadas para comunica¸c˜ao celular, enquanto frequˆencias maiores s˜ao usadas em servi¸cos como exame de imagem, na ´area de medicina, assim como sensoriamento remoto por micro-ondas, radioastronomia, entre outros [18]. O exacerbado aumento de tr´afego faz com que o espectro de r´adio fique con- gestionado, limitando a largura de banda para cada usu´ario e, assim, afetando a conex˜ao.

Uma solu¸c˜ao para este problema ´e o uso de frequˆencias acima de 6 GHz para conex˜oes sem fio, que n˜ao eram usadas para banda larga m´ovel [18].

2.4.2 Tecnologia MIMO massiva

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

Conforme a quantidade de antenas aumenta, os feixes que s˜ao irradiados tornam- se mais estreitos e s˜ao focados espacialmente na dire¸c˜ao do usu´ario, aumentando assim a sua taxa de transferˆencia e reduzindo interferˆencias para outros usu´arios que estejam pr´oximos. As antenas usadas servir˜ao para concentrar energia em uma regi˜ao menor do

(29)

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

2.4.3 C´ elulas pequenas

As c´elulas pequenas s˜ao esta¸c˜oes base de baixa potˆencia que abrangem pequenas

´

areas geogr´aficas, podendo ter sua posi¸c˜ao em qualquer lugar que tenha uma maior de- manda ou uma cobertura densa, e tem como objetivo ampliar o sinal de transmiss˜ao.

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´etricas e a tecnologia MIMO massiva, as c´elulas pequenas podem utilizar um n´umero elevado de antenas formando feixes direcionais aos aparelhos m´oveis dos usu´arios com uma transmiss˜ao simultˆanea [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˜ao de redes m´oveis, como aumento da capacidade, altas taxas de transmiss˜ao, baixa latˆencia e melhor qualidade de servi¸co, tamb´em se fez necess´aria uma evolu¸c˜ao nos aspectos de arquitetura de rede [22].

No entanto, apesar da chegada dessa nova tecnologia, o 4G continuar´a existindo e atuar´a em conjunto com o 5G. Sendo assim, torna-se necess´ario apresentar as caracter´ısticas da rede 4G para ser vi´avel compreender a transi¸c˜ao e coexistˆencia com o 5G.

A arquitetura tradicional para a quarta gera¸c˜ao LTE ´e totalmente baseada em protocolo IP (Internet Protocol) e ´e formada, basicamente, por: n´ucleo da rede, tamb´em conhecida como EPC (Evolved Packet Core), sendo respons´avel por gerenciar a mobili- dade, autentica¸c˜ao, roteamento, e mais; E-UTRAN (Evolved Universal Terrestrial Radio Access Network), que ´e composta pelos equipamentos de usu´arios, UE (User Equipment), e eNodeBs (evolved Node B); e E-UTRA (Evolved Universal Terrestrial Radio Access), que ´e um sistema de interface de r´adio [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: ´E respons´avel por encaminhar os pacotes dos usu´arios.

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

• MME: entidade respons´avel pela autentica¸c˜ao, gerenciamento de mobilidade e han- dover, ou seja, as decis˜oes mais importantes passam pelo MME. Permite a comu- nica¸c˜ao e troca de sinaliza¸c˜ao entre os equipamentos dos usu´arios e o EPC, assim como entre os eNodeBs e EPC.

• HSS: ´e o componente que cont´em o banco de dados central com as informa¸c˜oes relativas ao usu´ario, incluindo a verifica¸c˜ao 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˜ao da rede n´ucleo EPC tradicional para EPC CUPS (Con- trol and User Plane Separation), com separa¸c˜ao dos planos controle e de usu´ario. Isso foi poss´ıvel porque alguns dos componentes requerem mais recursos de controle, como sinaliza¸c˜ao. Outros podem precisar de pouca sinaliza¸c˜ao, por´em com alta demanda de tr´afego de dados [25]. Com o surgimento do conceito de SDN (Software Defined Network) e NFV (Network Functions Virtualization), a separa¸c˜ao desses planos foi viabilizada. Tais conceitos citados s˜ao detalhados nas Se¸c˜oes 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˜oes, e deixa o tr´afego de dados, que ´e o maior interesse do usu´ario, livre para desempenhar seu papel de entregar acesso aos servi¸cos e aplica¸c˜oes. Al´em disso, o uso do CUPS possibilita a expans˜ao independente de elementos de plano de usu´ario, sem necessidade de fazer o mesmo para elementos de plano de controle [24]. No EPC tradicional, os elementos que sofrem essa separa¸c˜ao, s˜ao 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´ario.

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

2.5.3 Arquitetura 5G

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

(32)

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

Solu¸c˜oes de implementa¸c˜ao

Foram propostas duas solu¸c˜oes pelo 3GPP para a nova gera¸c˜ao. S˜ao elas:

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

¸c˜ao mais r´apida, uma vez que usa uma infraestrutura j´a 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˜oes, foram estabelecidas algumas op¸c˜oes pelo 3GPP. Para o 5G NSA, 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˜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˜ao 4 - usa a rede 5GC e a interface de r´adio 5G NR como principal e a LTE como secund´aria. ´E representada pela Figura 2.5b.

Op¸c˜ao 7 - usa a rede 5GC e a interface de r´adio LTE como principal e 5G NR como secund´aria. ´E representada pela Figura 2.5c.

(a) Op¸c˜ao 3 (b) Op¸c˜ao 4 (c) Op¸c˜ao 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˜ao 2 - usa a rede 5GC e a interface de r´adio 5G NR exclusivamente. ´E representada pela Figura 2.6a.

Op¸c˜ao 5 - usa a rede 5GC e a interface de r´adio LTE exclusivamente. ´E 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˜ao da arquitetura de n´ucleo EPC, os seguintes elementos principais da arquitetura baseada em servi¸cos da rede de n´ucleo 5GC [24] [3] podem ser verificados pela Figura 2.7:

• AMF (Access and Mobility Management Function): respons´avel pelas tarefas de conectividade, gerenciamento de mobilidade, autentica¸c˜ao e autoriza¸c˜ao do usu´ario.

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

• SMF (Session Management Function): desempenha a funcionalidade de gerencia- mento da sess˜ao de acordo com as pol´ıticas de controle com a fun¸c˜ao de plano do usu´ario. 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˜oes do usu´ario e servi¸cos de identifica¸c˜ao, 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): ´e respons´avel por verificar as aplica¸c˜oes classificadas como confi´aveis para a operadora.

Essa abordagem do 5GC permite que o volume de tr´afego de dados seja roteado na borda da rede, atrav´es de UPFs distribu´ıdos geograficamente para que estejam pr´oximos dos usu´arios, possibilitando que o plano de controle possa estar centralizado com seus servi¸cos espec´ıficos, ancorando esses UPFs. Atrav´es do conceito de distribui¸c˜ao dos planos de usu´arios, ´e poss´ıvel prover aplica¸c˜oes MEC.

(37)

Cap´ıtulo 3

Tecnologias centrais para o 5G

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

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

3.1 Virtualiza¸ c˜ ao

Com rela¸c˜ao aos equipamentos f´ısicos que desempenham as fun¸c˜oes de rede, era comum que fossem dedicados para algum servi¸co ou aplica¸c˜ao espec´ıfica. Recursos como mem´oria, armazenamento, placas de rede, CPU (Central Processing Unit) precisavam ser de uso exclusivo, mesmo que isso implicasse ficar eventualmente ociosos. Por´em, com o surgimento da virtualiza¸c˜ao, foi poss´ıvel dissociar o hardware das fun¸c˜oes 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´em, em um cen´ario em que os recursos n˜ao s˜ao utilizados em sua capacidade total, h´a desper- d´ıcio do potencial do hardware, ocupa¸c˜ao f´ısica em um ambiente de data center e gasto de energia. Ou seja, custos que podem ser reduzidos com a implementa¸c˜ao da virtuali- za¸c˜ao. Com a virtualiza¸c˜ao, tanto o servidor de DNS e de e-mail podem coexistir sobre um mesmohardware, cada um com seus recursos alocados e funcionando de maneira iso- lada. 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˜ao como a de dados, ambientes de trabalho, servidores, sistemas operacionais, e fun¸c˜oes de redes [28]. Fora os tipos mencionados, tamb´em h´a as diferentes formas de virtualizar, podendo ser baseada em hypervisor ou contˆeiner.

3.1.1 Virtualiza¸ c˜ ao baseada em hypervisor

Uma alternativa aos dispositivos dedicados s˜ao as m´aquinas 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˜ao baseada em hypervisor, pode-se aumentar a eficiˆencia energ´etica, assim como diminuir a utiliza¸c˜ao de espa¸co emdata cen- ters, devido `a otimiza¸c˜ao 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 ´e chamado de consolida¸c˜ao de servidores, e consequentemente, o custo operacional diminui. Al´em disso, a recupera¸c˜ao de desastres em um ambiente virtual ´e muito mais r´apida 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´acil de ser resolvido [29, 30].

Para separar a infraestrutura f´ısica dos servi¸cos e aplica¸c˜oes, ´e utilizado um hyper- visor, tamb´em conhecido como monitor de VMs. O hypervisor ´e uma camada desoftware que gerencia a cria¸c˜ao, armazenamento e o controle das m´aquinas 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˜ao e a defini¸c˜ao de configura¸c˜oes das m´aquinas vir- tuais, fazendo a comunica¸c˜ao com ohardware da m´aquina real propriamente dita. Atrav´es

(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´em chamado de bare metal ou nativo, ´e executado nohardware, tendo acesso direto aos recursos. Ele atua como uma camada desoftwareentre ohardwaree as m´aquinas virtuais. ´E respons´avel pelo suporte as c´opias do hardware real (VMs), sendo similar aos processos que um sistema operacional real executa [29, 30]. Alguns exemplos do tipo 1 s˜ao VMWare vSphere e Hyper-V [30].

O tipo 2, tamb´em conhecido comohosted, ´e implementado comosoftware sobre um sistema operacional. Ele atua como um processo dentro do sistema operacional real/an- fitri˜ao [30]. Tem-se o hardware e, em seguida, o sistema operacional que tem diversas aplica¸c˜oes, e entre esses diversos programas um deles ´e o hypervisor. Logo, o tipo 2 concorre com os recursos de hardware com as outras aplica¸c˜oes. Sendo assim, pode-se afirmar que o hypervisor do tipo 1 tem um melhor desempenho, tendo em vista que ele n˜ao compartilha recursos. Alguns exemplos do tipo 2 s˜aoVMware 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˜ao ´e o investimento inicial no hardware que aloque tantos recursos, assim como o custo com manuten¸c˜ao. Tamb´em pode ser citado como um desafio a sobrecarga necess´aria para cada m´aquina virtual individual em seu servidor f´ısico. Como h´a uma camada a mais de software (hypervisor), ´e necess´ario um processamento maior para o funcionamento das m´aquinas do que seria para um ambiente sem virtualiza¸c˜ao, pois parte dos recursos do hardware s˜ao usados para o funcionamento

(40)

dessa camada [31].

3.1.2 Virtualiza¸ c˜ ao baseada em contˆ einer

A arquitetura da virtualiza¸c˜ao baseada em contˆeiner, vista na Figura 3.2, ´e um pouco diferente da baseada emhypervisor, vista na subse¸c˜ao 3.1.1. Com ohypervisor, um servidor executa diversas VMs, cada uma com um sistema operacional pr´oprio, usando m´ultiplos recursos, o que gera sobrecarga. Por outro lado, nos contˆeineres n˜ao ´e necess´ario ter uma camada de emula¸c˜ao ou um hypervisor para serem executados, ao inv´es disso, ´e usado uma interface no n´ıvel do sistema operacional.

Em [32], a conteineriza¸c˜ao ´e definida como um mecanismo que empacota arquivos, c´odigos, configura¸c˜ao e dependˆencias de aplica¸c˜oes por uma tecnologia chamada contˆeiner, 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ˆeineres oferecem maximiza¸c˜ao da produtividade e desempenho das opera¸c˜oes [33]. Os contˆeineres s˜ao carregados sobre o kernel do sistema operacio- nal, logo as instˆancias s˜ao executadas diretamente no sistema operacional hospedeiro sem utilizar um hypervisor, o que garante redu¸c˜ao na sobrecarga dos recursos e aumenta o desempenho das tarefas executadas [34, 35].

O ambiente conteinerizado, visto na Figura 3.2, ´e composto pelo sistema operaci- onal hospedeiro, o mecanismo de distribui¸c˜ao que faz o gerenciamento dos contˆeineres e trˆes contˆeineres com seus respectivos processos e bibliotecas de cada aplica¸c˜ao. Um exem- plo de gerenciador de contˆeineres muito usado no mercado ´e chamado Docker, que ´e uma solu¸c˜ao de c´odigo aberto, desenvolvido em 2008 pela equipe Docker, capaz de construir, distribuir e executar contˆeineres [36].

Assim, s˜ao criados os contˆeineres, onde s˜ao armazenados apenas os arquivos neces- s´arios para executar um ou mais processos das aplica¸c˜oes, como aplicativos Java, aplica- tivos daWeb, entre outros [37, 38]. Cada aplicativo ´e executado em cima de um contˆeiner isolado, e, por mais que usem o mesmo sistema operacional, eles n˜ao podem ver os recursos uns dos outros, n˜ao existindo dependˆencias entre eles.

Uma das maiores vantagens dos contˆeineres ´e que eles podem inicializar rapida- mente, o que ´e uma diferen¸ca significativa em rela¸c˜ao `a virtualiza¸c˜ao comhypervisor, onde os sistemas operacionais podem demorar para inicializar, pois precisam carregar arquivos

(41)

21 na mem´oria e iniciar diversos servi¸cos e processos que podem levar um tempo, enquanto a imagem inicializada no contˆeiner possui apenas dependˆencias e bin´arios para o carrega- mento dos arquivos de aplica¸c˜ao [32]. Uma outra vantagem ´e que eles s˜ao eficientes em termos de recursos, n˜ao precisam ter v´arias instˆancias do sistema operacional subjacente, o contˆeiner s´o precisa da mem´oria necess´aria para ter o aplicativo executado. Nesse caso, n˜ao h´a sobrecarga [37].

De uma forma resumida, independentemente se for na forma de m´aquinas virtuais ou contˆeineres, a virtualiza¸c˜ao ´e capaz de prover independˆencia entre servi¸cos heterogˆe- neos, abstra¸c˜ao de recursos e isolamento entre as opera¸c˜oes [39]. De um modo geral, os contˆeineres s˜ao mais leves do que as VMs e possuem um sistema operacional comparti- lhado, sendo ideais para ambientes nativos em nuvem. Com m´aquinas virtuais, pode-se executar mais opera¸c˜oes do que em contˆeineres e ´e poss´ıvel ter um sistema operacional para cada VM [40]. Desse modo, a escolha da forma de virtualizar, ir´a 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˜ao de Fun¸c˜oes de Rede, ´e uma tecnologia com intuito de decompor servi¸cos de telecomunica¸c˜oes em fun¸c˜oes virtuais, chamadas VNFs (Virtualized Network Functions), que funcionam em m´aquinas virtuais ou contˆeineres ao inv´es de dispositivos f´ısicos especializados, podendo ser instaladas em data centers centralizados ou em PoPs (Points of Presence), na borda da rede.

Gerenciar m´aquinas virtuais ou contˆeineres pode ser uma tarefa ´ardua `a 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˜ao r´apida de novos servi¸cos e redu¸c˜ao de custo de hardwareatrav´es da virtualiza¸c˜ao [41], o que ´e ideal para o cen´ario do 5G que precisar´a 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ˆe recursos f´ısicos, virtuais e desoftware necess´arios para supor- tar a execu¸c˜ao das fun¸c˜oes virtuais de rede, ou seja, apresenta os recursos de infraestrutura como recursos virtuais, atrav´es da camada de virtualiza¸c˜ao, para serem alocados para as VNFs.

O bloco VNF ´e a implementa¸c˜ao de software da fun¸c˜ao de rede que ´e capaz de rodar sobre a infraestrutura NFV (NFVI) e ´e implementada por m´aquinas virtuais. No caso da implementa¸c˜ao por contˆeineres, tamb´em ´e conhecida como CNF (Cloud-Native Network Function). Esse bloco pode exemplificar as fun¸c˜oes 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 exem- plo, existem os planos de dados e de controle n˜ao desacoplados. O plano de dados ´e respons´avel por encaminhar os pacotes gerados pelos usu´arios de acordo com uma po- l´ıtica estabelecida, enquanto o plano de controle realiza a descoberta de topologia para tomar decis˜oes 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´avel oferecer melhor controle e gerenciamento sobre a rede atrav´es de uma arquitetura flex´ıvel e altamente program´avel.

Na Figura 3.4 ´e 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´a em 3.4b, isso muda para o SDN, existindo apenas um plano de controle centralizado tomando decis˜oes 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´afego, uma vez que necessita de configura¸c˜ao e gerenciamento individual por equipamento. A rede SDN abre a possibilidade de controlar de forma unificada diversos dispositivos, tornando o processo mais ´agil e escal´avel para a expans˜ao e crescimento das redes.

Al´em das defini¸c˜oes citadas, a ONF (Open Networking), que iniciou o movimento de SDN, tamb´em descreve a arquitetura como: ´agil, por abstrair o controle do encami- nhamento de dados, permitindo que administradores de rede ajustem o fluxo de tr´afego conforme necessidade; gerenciada centralmente, por manter uma vis˜ao global da rede; e configur´avel por programa¸c˜ao, pois permite gerenciar e otimizar recursos de rede de forma dinˆamica e autom´atica atrav´es de programas que n˜ao dependem do software propriet´ario [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 arquite- tura composta por trˆes planos diferentes [44]. Em redes SDN, aparecem os conceitos de Northbound, em dire¸c˜ao ao norte, e Southbound, em dire¸c˜ao ao sul, APIs (Application Programming Interface) para descrever a dire¸c˜ao da interface a partir da controladora SDN. A seguir, ´e descrita a arquitetura SDN e sua rela¸c˜ao com as interfaces:

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

• Plano de aplica¸c˜ao: diz respeito `as aplica¸c˜oes 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: ´e a parte central e controladora da SDN, que mant´em uma vis˜ao global e dinˆamica da rede, recolhendo as requisi¸c˜oes da camada de aplicativos e gerencia o comportamento dos dispositivos de rede atrav´es de protocolos padr˜oes, como o OpenFlow.

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

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˜ao na borda para as redes m´oveis, porque s˜ao capazes de promover alta escalabilidade, enquanto os usu´arios finais est˜ao mudando suas localiza¸c˜oes rapidamente. Apesar de ambas as tecnologias se basearem em abstra¸c˜ao de rede, s˜ao abordagens diferentes, po- r´em 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˜oes que rodam sobre VMs ou contˆeineres por meio da capacidade de programabilidade. Torna-se vi´avel compreender, portanto, que a virtualiza¸c˜ao pode ser abordada nos trˆes planos que comp˜oem a SDN, nas aplica¸c˜oes, nas controladoras SDN e nos dispositivos de rede.

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

(46)

NFV como componentes, sendo o ´ultimo respons´avel por aprovisionar as fun¸c˜oes virtuais de rede que s˜ao 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, ´e uma abordagem de rede muito impor- tante para o futuro do 5G. A sua importˆancia d´a-se devido `a possibilidade de aloca¸c˜ao de recursos de computa¸c˜ao, isolando a rede e garantindo um maior desempenho. Assim, ele provˆe a coexistˆencia dos grupos de servi¸cos eMBB, URLLC e mMTC, conforme citados na se¸c˜ao 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´oprio nome diz, s˜ao criadas “fatias da rede”, que s˜ao redes l´ogicas (vir- tuais), cada uma com suas pr´oprias 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´arias fatias dentro de uma mesma rede f´ısica fornecendo flexibilidade e eficiˆencia no uso de recursos.

Para exemplificar, suponha dois cen´arios de aplica¸c˜oes. Uma rede de ve´ıculos autˆonomos, onde ´e necess´ario que a rede provenha uma baixa latˆencia e alta confiabilidade para garantir que n˜ao haja perda de pacotes e, assim, n˜ao afete a seguran¸ca do ve´ıculo e do usu´ario que estiver utilizando o servi¸co. Em outro cen´ario, ´e poss´ıvel ter uma aplica¸c˜ao de realidade virtual, que exige um alto rendimento da rede com confiabilidade menor, pois uma resolu¸c˜ao mais baixa n˜ao interfere na entrega do servi¸co. Com o fatiamento da rede, os parˆametros diferentes dos dois cen´arios 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ˆencia, referente aos ve´ıculos, e outra fatia seria utilizada para fornecer uma alta taxa de transferˆencia para a aplica¸c˜ao de realidade virtual [47].

A Figura 3.7 ilustra fatias de rede isoladas em uma infraestrutura f´ısica comparti- lhada, 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˜oes 3.1 e 3.2 s˜ao de suma importˆancia para a implementa¸c˜ao do fatiamento de rede. O fatiamento ser´a poss´ıvel gra¸cas ao SDN, que atua no controle de v´arios dispositivos envolvidos, em conjunto com o NFV, que cria fun-

¸c˜oes l´ogicas 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˜ao de fun¸c˜oes 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˜ao em nuvem e borda tamb´em ser´a de grande importˆancia para a implementa¸c˜ao do fatiamento da rede. A computa¸c˜ao em nuvem e a computa¸c˜ao de borda permite o uso de recursos computacionais e de rede em v´arias plataformas, assim como recursos de armazenamento para habilitar uma fatia de rede [49]. A computa¸c˜ao de borda fornece gerenciamento e an´alise de dados nas proximidades do usu´ario final, o que garante uma latˆencia muito baixa e altas taxas de dados [50]. Uma arquitetura padr˜ao da computa¸c˜ao em borda ´e o MEC, que ter´a 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ˆencia, cobertura e custo. Em [51], ´e relatado que 83% dos l´ıderes globais de tecnologia da informa¸c˜ao tˆem a latˆencia como um maior parˆametro que mais afeta o desempenho de suas aplica¸c˜oes, e trˆes em cada quatro se preocupam com a alta latˆencia afetando a qualidade dos servi¸cos.

Para a solu¸c˜ao de tal problema de latˆencia e para ter uma economia de custos no longo prazo, ´e necess´aria uma arquitetura de computa¸c˜ao de borda distribu´ıda e segura que opere mais perto dos seus usu´arios finais que produzem e consomem dados [51].

Sendo assim, este cap´ıtulo tem como objetivo mostrar uma op¸c˜ao de tal arquitetura de borda, chamada arquitetura MEC (Multi-Access Edge Computing), passando pelo seu conceito vinculado ao edge computing e sua evolu¸c˜ao vinda da computa¸c˜ao em nuvem, assim como sua importˆancia para a implementa¸c˜ao do 5G, evidenciando seus servi¸cos e aplica¸c˜oes, e tamb´em 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´arios, tamb´em h´a limita¸c˜oes com rela¸c˜ao ao tempo de vida de bateria de seus dispositivos de acesso, energia computacional e mem´oria para processos complexos [52]. Tendo isso em vista, a computa¸c˜ao em nuvem surge como ambiente capaz de suportar essas opera¸c˜oes

29

(50)

mais complexas, movendo a execu¸c˜ao das tarefas computacionais dos dispositivos para a nuvem. Mais especificamente, o MCC (Mobile Cloud Computing), ´e termo usado para a arquitetura de computa¸c˜ao em nuvem implementada no cen´ario de redes m´oveis.

A computa¸c˜ao em nuvem abrange o conceito de disponibiliza¸c˜ao de recursos como armazenamento, banco de dados, e capacidade computacional para servi¸cos e aplica¸c˜oes, que podem ser requisitados conforme necessidade, atrav´es 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´a qualidade de experiˆencia para aplica¸c˜oes sens´ıveis `a latˆencia, como parte das que pretendem ser atendidas pelo 5G [53]. A partir disso, ´e poss´ıvel compreender o surgimento da ideia da computa¸c˜ao na borda, ouedge computing em inglˆes. A computa¸c˜ao na borda apresenta- se como novo paradigma capaz de realizar tarefas computacionais na borda da rede, de modo que esteja mais pr´oximo do usu´ario 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˜ao de custos, o que traz maior flexibilidade. J´a a computa¸c˜ao de borda fornece um meio de melhorias extras de desempenho, sobretudo em rela¸c˜ao a an´alise de dados e tomada de decis˜oes.

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

A computa¸c˜ao de borda ´e um modelo que permite a utiliza¸c˜ao de servidores na borda em mini-nuvens (edge), que possuem a capacidade da nuvem em uma escala menor e s˜ao localizados mais pr´oximos dos usu´arios finais, conforme visto na Figura 4.1. ´E um modelo diferente dos data centers usados na computa¸c˜ao em nuvem que s˜ao localizados mais longe do usu´ario, de forma centralizada no core da rede, estando distantes dos UEs [55]. Essa proximidade do usu´ario ´e uma vantagem no processamento de dadoshard real- time, que s˜ao dados que possuem latˆencia rigorosamente pr´e-definida [55]. Esse e outros tipos de dados s˜ao classificados na Se¸c˜ao 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

Imagem

Referências

temas relacionados :