Laboratório de Comunicações Sem Fio

Sumário:

1. Camadas de Protocolo
2. Pilha TCP/IP
3. SCTPLB e SCTP
4. L2TP
5. Protocolos de Ethernet Industrial

 

1 Camadas de Protocolo

O modelo OSI (Open Systems Interconnection) é um modelo de referência baseado em uma proposta da ISO (International Standards Organization) para padronização dos protocolos utilizados em redes. Ele consiste em sete camadas e foi projetado seguindo os seguintes princípios de [1,2]:

• Criação de uma camada sempre que uma nova abstração é necessária [1].
• Cada camada possui uma função bem definida [1].
• Seleção das funções de cada camada com o objetivo de estabelecer protocolos internacionalmente padronizados [1].
• Os limites entre as camadas devem ser escolhidos de forma a minimizar o fluxo de informações através das interfaces [1].
• O número de camadas deve ser grande o suficiente para evitar a necessidade de agrupar funções distintas na mesma camada por necessidade, mas também deve ser pequeno o suficiente para evitar que a arquitetura se torne complicada [1].

O modelo OSI (Figura 1) foi desenvolvido para permitir a conexão de sistemas abertos, ou seja, sistemas que podem se comunicar com outros sistemas [1].

Figura 1 – Ilustração do modelo OSI [2].

A camada de aplicação tem como função o registro de requisições. Aqui, um protocolo como o HTTP — protocolo base da World Wide Web — carrega informações do webserver e as passa para as camadas abaixo (de uma maneira que as informações sejam interpretáveis) [4].

A camada de transporte é responsável pela comunicação fim-a-fim, em outras palavras, aplicações dessa camada só se comunicam com seu receptor. São dois os principais protocolos dessa camada. Um deles é o TCP (Transmission Control Protocol), que é um protocolo orientado à conexão — o que significa que a transmissão dos dados só acontece se antes for estabelecida uma conexão (que é fechada após a transmissão dos dados), e que garante que os dados são entregues e livres de erro — e é adequado ao envio de informações que devem ser recebidas de forma confiável, como uma página web e um e-mail. O outro é o UDP (User Datagram Protocol), que envia os pacotes sem nenhum tipo de retransmissão (não garantindo assim que todas as informações serão recebidas e que não haverá erros), e que é adequado para comunicações sensíveis ao tempo, em que descartar pacotes é melhor do que esperar, como o live streaming [4].

Na camada de rede, um protocolo como o IP (Internet Protocol) coloca os pacotes na rota de destino correta. O responsável por esse processo são os roteadores — dispositivos que implementam apenas as três camadas mais baixas da pilha de protocolos —, que fazem isso ao inspecionar o endereço IP de destino [4].

A camada de enlace, gerencia a transmissão dos pacotes de um dispositivo ao outro, garantindo que ele seja re-transmitindo adiante caso ainda não tenha chegado ao seu destino final [4]. Exemplo: Ethernet.

Por fim, a camada física lida com detalhes mais finos da comunicação, como a tensão do sinal transmitido [4].

Em todos os níveis da transmissão um protocolo recebe um pacote de dados proveniente do protocolo que se encontra na camada acima na forma de uma unidade de serviço de dados, ou SDU (Service Data Unit). Ele processa o pacote, adiciona um cabeçalho que descreve o processamento realizado e gera o resultado na forma de uma unidade de dados de protocolo, ou PDU (Protocol Data Unit). Esse processo se repete em todos os níveis do modelo OSI, onde a recém gerada PDU servirá como o SDU da próxima camada. Isso continua até que o pacote atinja a camada mais baixa de todas, momento em que ele é transmitido. O receptor inverte todas essas operações, usando os cabeçalhos que foram definidos durante a transmissão, de modo a desfazer o processamento feito pelo transmissor [4].

2 Pilha TCP/IP

O ARPANET (Advanced Research Projects Agency Network), uma rede de pesquisa financiada pelo Departamento de Defesa dos Estados Unidos, foi um marco importante na história das redes de computadores. Inicialmente, conectava universidades e instituições governamentais por meio de linhas telefônicas alugadas. Com o tempo, a adição de redes via satélite e rádio apresentou desafios de interoperabilidade com os protocolos existentes, levando à necessidade de uma nova arquitetura de referência [1,2].

Essa arquitetura resultou no Modelo de Referência TCP/IP (Figura 2), nomeado após seus principais protocolos. Criado por Vinton Cerf e Robert Kahn, o TCP/IP foi descrito em 1974 e posteriormente refinado e padronizado pela comunidade da internet. O modelo foi projetado para permitir a conexão contínua de múltiplas redes, oferecendo uma base sólida para o funcionamento da internet como a conhecemos hoje [1,2].

Além de promover a conectividade entre redes, o TCP/IP também foi desenvolvido com foco na resiliência. O Departamento de Defesa tinha a preocupação de que a rede pudesse sobreviver a possíveis ataques e falhas de hardware sem interromper as comunicações em andamento. Dessa forma, mesmo que parte da infraestrutura fosse danificada, as conexões permaneceriam intactas, desde que as máquinas de origem e destino estivessem funcionando [1,2].

Uma característica importante do TCP/IP é sua flexibilidade para atender a diferentes requisitos de aplicativos. Desde a transferência de arquivos até a transmissão de voz em tempo real, o modelo foi projetado para acomodar uma ampla variedade de necessidades, tornando-se a base para a comunicação eficiente na internet [1,2].

Figura 2 – Ilustração do modelo OSI vs. TCP/IP [2].

3 SCTPLB e SCTP

SCTPLB (Stream Control Transmission Protocol Load Balancer), é uma solução de balanceamento de carga projetada para lidar com o protocolo SCTP (Stream Control Transmission Protocol). O SCTP é um protocolo de transporte orientado a conexão que oferece recursos avançados em relação ao TCP (Transmission Control Protocol), como suporte a múltiplas streams e controle de congestionamento [1].

O SCTPLB é uma implementação de balanceamento de carga específica para o protocolo SCTP, que distribui o tráfego entre múltiplos servidores ou destinos finais. Ele atua como um intermediário entre os clientes SCTP e os servidores SCTP, garantindo uma distribuição equilibrada das conexões e cargas de trabalho [1].

Uma das principais finalidades do SCTPLB é melhorar a escalabilidade e a disponibilidade dos serviços SCTP. Ele pode ser usado em cenários onde há um grande número de conexões SCTP e a carga precisa ser distribuída de forma eficiente para garantir o desempenho e a capacidade de resposta dos servidores [1].

O SCTPLB funciona interceptando as conexões SCTP dos clientes e redirecionando-as para os servidores de destino. Ele realiza a distribuição de carga com base em diferentes algoritmos, como round-robin (cada servidor recebe uma conexão sequencialmente), balanceamento de carga ponderado (atribui pesos diferentes a servidores com capacidades diferentes) ou algoritmos baseados em métricas de desempenho, como latência ou carga atual dos servidores [1].

Além do balanceamento de carga, o SCTPLB também pode oferecer recursos adicionais, como monitoramento de servidores, detecção de falhas e failover. Ele pode verificar periodicamente o estado dos servidores e remover ou adicionar servidores à configuração do balanceador de carga com base em seu status. Isso ajuda a garantir que apenas servidores saudáveis recebam o tráfego SCTP e melhora a resiliência do sistema [1,3].

4 L2TP

L2TP, em português Protocolo de Tunelamento de Camada 2, é um protocolo de túnel que fornece um método de encapsulamento para frames do tipo PPP, permitindo assim a transmissão de dados do tipo L2 através de uma rede IP, ou L3 [4]. Foi definido inicialmente na RFC (Request for Comments) 2661 [5], de agosto de 1999, e é baseado em dois protocolos de túnel mais antigos: o L2F (Layer 2 Forwarding Protocol) da Cisco, e o PPTP (Point-to-Point Tunnelling Protocol) da Microsoft [4]. É bastante utilizado na implementação de VPN (Virtual Private Network), quase sempre em conjunto com IPsec – já que o L2TP não oferece nenhum tipo de criptografia ou confiabilidade por si só [4].

Uma nova versão do protocolo, chamada de L2TPv3 (Layer 2 Tunnelling Protocol version 3), definida na RFC 3931 [6], datada de março de 2005, foi criada com objetivo de fornecer recursos de segurança adicionais, encapsulamento melhorado e a capacidade de conduzir outros enlaces de dados além do PPP, como por exemplo frames do tipo Ethernet [4].

O túnel L2TP é estabelecido através do encapsulamento de um frame L2TP dentro de um pacote do tipo UDP, que é então encapsulado dentro de um pacote do tipo IP. O endereço de origem e destino desse pacote IP são os responsáveis por definir os endpoints da conexão a ser criada. Uma vez que um túnel é estabelecido, o tráfego de dados é bidirecional [4,7].

O protocolo L2TP separa os frames de dados e de controle. Os frames de dados são manuseados pelo driver do Kernel, enquanto os frames de controles são manuseados no espaço do usuário. Os frames de controle L2TP transportam mensagem entre clientes e servidores e são utilizados para configurar/desmontar túneis e sessões [4,7].

Cada túnel é implementado utilizando um soquete UDP ou L2TPIP. Cada sessão L2TP cria interfaces de rede que seguem a nomenclatura l2tpethN. Para cada túnel e para cada sessão que utilize o túnel são atribuídos, respectivamente, um tunnel_id e session_id exclusivos. Esses ids são usados pelo driver L2TP para a tomada de decisões de como lidar com os pacotes [4,7].

5 Protocolos de Ethernet Industrial

O termo “Ethernet Industrial” se refere a uma série de expansões feitas ao padrão Ethernet — definido no IEEE 802.3 — com objetivo de adequá-lo ao uso na indústria; a fim de se permitir a comunicação em tempo real entre controladores, máquinas e sensores [4,8].

Atualmente, são vários os protocolos industriais baseados no Ethernet, dentre os quais pode-se citar: EtherCAT, Sercos III, Ethernet/IP, PROFINET7, CC-Link IE Field e Modbus TCP [9]. Esses protocolos são, portanto, conhecidos como protocolos Ethernet Industrial. Em comparação com protocolos usualmente utilizados em redes, estes têm necessidades específicas [4,8]:

• Encaminhamento na camada 2 (sem endereço IP), usualmente feito através do endereço MAC ou VLANs;
• Transmissão de dados determinística, com tempos de resposta e taxas de dados garantidos;
• Tempos de ciclo de comunicação curtos e ciclos de comunicação simultâneos com tempo variante;
• Proteção contra falha de componentes;
• Sincronização altamente precisa.

Os protocolos Ethernet Industrial foram divididos em três classes, que variam em relação ao desempenho e em parâmetros de implementação, como a necessidade de comunicação em tempo real e o custo. Normalmente, o desempenho da rede melhora da Classe A para a Classe B, e assim sucessivamente. A divisão das classes, bem como sua organização em relação ao modelo OSI, pode ser vista na Figura 3 [4].

Figura 3 – Classificação dos protocolos Ethernet Industrial [9].

A Classe A utiliza hardware Ethernet comercial e a pilha TCP/IP para comunicação. Alguns dos protocolos presentes nessa classe são: Ethernet/IP, Modbus TCP e Fieldbus [4,9].

A Classe B também faz uso de hardware Ethernet comercial padrão, mas não emprega a pilha TCP/IP na comunicação. Ao invés disso, ela implementa um protocolo de dados dedicado que é transmitido diretamente dentro do frame Ethernet. Protocolos pertencentes a esta classe são: PROFINET RT, POWERLINK e EtherCAT Automation Protocol (EAP) [4,9].

A Classe C é a mais performática de todas pois emprega hardware dedicado até a camada 2. Como exemplo de protocolos pertencentes a esta classe, têm-se: EtherCAT, PROFINET IRT, Sercos III e CC-Link IE [4,9].

A rede industrial Ethernet não é otimizada apenas para as necessidades da comunicação em tempo real, ela também foi pensada para ser de fácil utilização em maquinários. Isso é possível por oferecer uma configuração simples e monitoramento de diagnóstico da rede, a fim de reduzir os tempos de configuração dos equipamentos e o tempo de inatividade em caso de falhas. Normalmente, as máquinas industriais operam 24 horas por dia, 7 dias por semana, o que requer 100% de disponibilidade de rede [4].

Referências:

[1] Liao, Douglas. Implementação de QoS em rede 5G através do Network Slicing.  2023. 75 f. TCC (Graduação) – Curso de Engenharia de Controle e Automação, Departamento de Engenharia de Controle, Automação e Computação, Universidade Federal de Santa Catarina. Campus Blumenau, Blumenau, 2023. Disponível em: https://repositorio.ufsc.br/handle/123456789/248721. Acesso em: 13 jul. 2023.

[2] TANENBAUM, Andrew S. Computer networks. 4. ed. [S.l.]: Prentice Hall, 2002. ISBN 0130661023; 9780130661029.

[3] ROMMER, S. et al. 5G Core Networks: Powering Digitalization. [S.l.]: Academic Press, 2019.

[4] BARETTA, José Luis Maziero. Encapsulamento de protocolos Ethernet Industrial utilizando a rede 5G. 2022. 74 f. TCC (Graduação) – Curso de Engenharia de Controle e Automação, Departamento de Engenharia de Controle, Automação e Computação, Universidade Federal de Santa Catarina. Campus Blumenau, Blumenau, 2022. Disponível em: https://repositorio.ufsc.br/handle/123456789/243552. Acesso em: 01 abr. 2023.

[5] IETF. Layer Two Tunneling Protocol “L2TP”. [S.l.: s.n.].  Disponível em: https://www.rfc-editor.org/rfc/rfc2661. Acesso em: 03 nov. 2022.

[6] IETF. Layer Two Tunneling Protocol – Version 3 (L2TPv3). [S.l.: s.n.]. Disponível em: https://www.rfc-editor.org/rfc/rfc3931. Acesso em: 03 nov. 2022.

[7] KERNEL.ORG. L2TP. [S.l.: s.n.]. Disponível em: https://www.kernel.org/doc/html/v5.8/networking/l2tp.htm. Acesso em: 03 nov. 2022.

[8] SIEMENS. Industrial Communication – SIMATIC NET Industrial Ethernet Networking Manual, 2008.

[9] 5G ACIA. Integration of Industrial Ethernet Networks with 5G Networks, 2019.

O modelo da (QoS) do 5G é baseado em fluxos de QoS, que possuem identificadores únicos. Existem dois tipos de fluxos: com GBR (Taxa de Bits Garantida) e sem GBR. Esses fluxos são utilizados para diferenciar o tratamento de tráfego de usuário. No nível do usuário, os pacotes são filtrados e mapeados para os fluxos de QoS. No nível de acesso, os fluxos de QoS são mapeados para as Portadoras de Rádio de Dados (DRBs). Cada fluxo de QoS possui um perfil com parâmetros e características que podem ser padronizadas ou configuradas dinamicamente [1].

Parâmetros da QoS

Cada fluxo de QoS possui um identificador único chamado Identificador de Fluxo de QoS (QFI). Existem dois tipos de fluxos: Fluxos de QoS com Taxa de Bits Garantida (GBR) e Fluxos de QoS não GBR. O Fluxo de QoS é a menor granularidade de diferenciação de QoS na Sessão PDU. O tráfego da Plataforma do Usuário (UP) com o mesmo QFI recebe o mesmo tratamento de encaminhamento. Cada fluxo de QoS possui um perfil de QoS que inclui parâmetros de QoS e características deles. Os parâmetros aplicáveis dependem do tipo de fluxo GBR ou não GBR. As características de QoS são padronizadas ou configuradas dinamicamente [1,2]. Os parâmetros da QoS para o 5G (5QI) estão listados nos Quadros 1, 2 e 3.

Quadro 1 – Mapeamento padronizado de 5QI para características de QoS com recurso GBR [6].

Valor 5QI	Nível de prioridade	Limite de atraso de pacote	Taxa de erro de pacote	Volume máximo de dados	Janela de média	Exemplo
1	20	100 ms	10^(−2)	N/A	2000 ms	Voz
2	40	150 ms	10^(−3)	N/A	2000 ms	Live Streaming
3	30	50 ms	10^(−3)	N/A	2000 ms	Jogo em tempo real; V2X
4	50	300 ms	10^(−6)	N/A	2000 ms	Vídeo Não Conversacional (Streaming em Buffer)
65	7	75 ms	10^(−2)	N/A	2000 ms	Voz em Tempo Real Crítica para a Missão Crítica (Push to Talk)
66	20	100 ms	10^(−2)	N/A	2000 ms	Voz em Tempo Real Não Crítica para a Missão (por exemplo, Push to Talk – PTT Não Crítico para a Missão)
67	15	100 ms	10^(−3)	N/A	2000 ms	Mission Critical Video user plane
75	25	50 ms	10^(−2)	N/A	2000 ms	Mensagens V2X
71	56	150 ms	10^(−6)	N/A	2000 ms	Uplink Streaming
72	56	300 ms	10^(−4)	N/A	2000 ms	Uplink Streaming
73	56	300 ms	10^(−8)	N/A	2000 ms	Uplink Streaming
74	56	500 ms	10^(−8)	N/A	2000 ms	Uplink Streaming
76	56	500 ms	10^(−4)	N/A	2000 ms	Uplink Streaming

Quadro 2 – Mapeamento padronizado de 5QI para características de QoS com recurso Non-GBR [6].

Valor 5QI	Nível de prioridade	Limite de atraso de pacote	Taxa de erro de pacote	Volume máximo de dados	Janela de média	Exemplo
5	10	100 ms	10^(−6)	N/A	N/A	Sinalização IMS
6	60	300 ms	10^(−6)	N/A	N/A	Vídeo (buffered streaming) baseado em TCP
7	70	100 ms	10^(−3)	N/A	N/A	Voz; vídeo (transmissão ao vivo); jogos interativos
8	80	300 ms	10^(−6)	N/A	N/A	Vídeo (transmissão ao vivo) baseado em TCP (por exemplo, www, e-mail, chat, ftp, compartilha- mento de arquivos p2p, vídeo progres- sivo)
9	90	300 ms	10^(−6)	N/A	N/A	Vídeo (buffered streaming) baseado em TCP (por exemplo, www, e-mail, chat, ftp, compartilhamento de arquivos p2p, vídeo progressivo)
10	90	1100 ms	10^(−6)	N/A	N/A	Vídeo (buffered streaming) baseado em TCP e qualquer outro serviço que pode ser usado por acesso via satélite com essas características
69	5	60 ms	10^(−6)	N/A	N/A	Sinalização sensível ao atraso de missão crítica (e.g., sinalização MCPTT)
70	55	200 ms	10^(−6)	N/A	N/A	Dados de Missão Crítica
79	65	50 ms	10^(−2)	N/A	N/A	Mensagens V2X
80	68	10 ms	10^(−6)	N/A	N/A	Aplicações eMBB de baixa latência; reali- dade aumentada

Quadro 3 – Mapeamento padronizado de 5QI para características de QoS com recurso Delay Critical GBR [6].

Valor 5QI	Nível de prioridade	Limite de atraso de pacote	Taxa de erro de pacote	Volume máximo de dados	Janela de média	Exemplo
82	19	10 ms	10^(−4)	255 bytes	2000 ms	Automação Discreta
83	22	10 ms	10^(−4)	1354 bytes	2000 ms	Automação Discreta; Mensagens Vehicle-to-Everything (V2X)
84	24	30 ms	10^(−5)	1354 bytes	2000 ms	Sistemas   de    transporte inteligentes
85	21	5 ms	10^(−5)	255 bytes	2000 ms	Distribuição de energia – alta tensão; mensagens V2X
86	18	5 ms	10^(−4)	1354 bytes	2000 ms	Mensagens V2X
87	25	5 ms	10^(−3)	500 bytes	2000 ms	Serviço  interativo – dados de rastreamento de movimento
88	25	10 ms	10^(−3)	1125 bytes	2000 ms	Serviço  interativo – dados de rastreamento de movimento
89	25	15 ms	10^(−4)	17000 bytes	2000 ms	Conteúdo visual para renderização em nuvem/borda
90	25	20 ms	10^(−4)	63000 bytes	2000 ms	Conteúdo visual para renderização em nuvem/borda

Alguns Detalhes importantes para ressaltar:

• Identificador de QoS 5G (5QI): Um identificador para características de QoS que influenciam pesos de agendamento, limites de admissão, limites de gerenciamento de fila, configuração do protocolo de camada de enlace, etc.
• Prioridade de Alocação e Retenção (ARP): Informações sobre nível de prioridade, capacidade de substituição (pode substituir recursos atribuídos a outros fluxos de QoS) e vulnerabilidade à substituição (pode ser substituído por outros fluxos de QoS).
• Taxa de Fluxo Garantida (GFBR): Medida ao longo da Janela de Tempo Médio. Recomendado como a taxa de bits mais baixa na qual o serviço sobreviverá.
• Taxa de Fluxo Máxima (MFBR): Limita a taxa de bits ao máximo esperado por este fluxo de QoS.
• Taxa Máxima de Bits Agregada (AMBR): Session-AMBR é por sessão PDU em todos os seus fluxos de QoS. UE-AMBR é para cada UE.
• Controle de Notificação de QoS (QNC): Configura a NG-RAN para notificar o se o GFBR não puder ser atendido. Útil se a aplicação puder se adaptar às condições em mudança. Se perfis de QoS alternativos forem configurados, a NG-RAN indica se um deles corresponde às métricas de desempenho atualmente atendidas.
• Taxa Máxima de Perda de Pacotes: No [3], isso é limitado à mídia de voz.
• Packet Error Loss Rate (PELR): A Taxa de Perda de Erros de Pacote (PELR) é uma métrica que estabelece um limite superior para a taxa de perda de pacotes que ocorrem devido a erros no nível da camada de enlace de uma rede. Ele representa a proporção de Unidades de Dados de Serviço (SDUs) processadas pelo remetente de um protocolo de camada de enlace, mas que não são entregues com sucesso pelo receptor correspondente à camada superior [4]
• Packet Delay and Budget (PDB): Define um limite superior para o tempo que um pacote pode ser atrasado entre o UE (Equipamento do Usuário) e o ponto de terminação N6 na UPF. O PDB se aplica ao pacote DL recebido pela UPF na interface N6 e ao pacote UL enviado pelo UE. Para um determinado 5QI, o valor do PDB é o mesmo no UL e DL [5].

Saiba mais sobre slicing, uma das tecnologias importantes para QoS em 5G, no seguinte artigo: Fatiamento de Rede (slicing) no 5G

Atenção: O texto acima foi extraído do TCC de Douglas Liao, intitulado Implementação de QoS em rede 5G através do Network Slicing, disponível em: https://repositorio.ufsc.br/handle/123456789/248721.

Referências:

[1] LIAO, Douglas. Implementação de QoS em rede 5G através do Network Slicing.  2023. 75 f. TCC (Graduação) – Curso de Engenharia de Controle e Automação, Departamento de Engenharia de Controle, Automação e Computação, Universidade Federal de Santa Catarina. Campus Blumenau, Blumenau, 2023. Disponível em: https://repositorio.ufsc.br/handle/123456789/248721. Acesso em: 13 jul. 2023.

[2] DEVOPEDIA. 5G Quality of Service. 2021. Disponível em: https://devopedia.org/5g-quality-of-service. Acesso em: 6 jun. 2023.

[3] 3GPP. Release 16. 2020. Disponível em: https://www.3gpp.org/specifications-technologies/releases/release-16. Acesso em: 6 jun. 2023.

[4] 3GPP. Digital cellular telecommunications system. 2011. Disponível em: https://www.etsi.org/deliver/etsi%5C_ts/123200%5C_123299/123203/09.09.00%5C_60/ts%5C_123203v090900p.pdf. Acesso em: 6 jun. 2023.

[5] 3GPP. 5G QoS characteristics. 2022. Disponível em: https://www.tech-invite.com/3m23/toc/tinv-3gpp-23-501%5C_za.html. Acesso em: 6 jun. 2023.

[6] 3GPP. 5G; System architecture for the 5G System (5GS). TS 23.501, version 17.9.0, Release 17, July. 2023. Disponível em: https://www.etsi.org/deliver/etsi_ts/123500_123599/123501/17.09.00_60/ts_123501v170900p.pdf. Acesso em: 22 jul. 2022.

Rede de Longa Distância Definida por Software (SD-WAN), é uma tecnologia de rede que simplifica a administração e operação de uma rede de longa distância (WAN) [1].

Uma WAN é uma rede que conecta dispositivos ou outras redes que estão distantes entre si, geralmente em diferentes locais. Geralmente as WANs são utilizadas por empresas para conectar suas sedes a filiais, data centers e serviços na nuvem [1].

A parte de “SD” é a sigla para “Software Defined“, ou “Definido por Software”, em tradução direta. Tradicionalmente, a administração de uma rede era fortemente dependente do hardware e exigia a configuração manual de roteadores e outros dispositivos. Com a SD-WAN, a administração da rede é abstraída do hardware e gerida por um software. Isso permite que a rede seja configurada de maneira otimizada e seu monitoramento seja feito de maneira centralizada e automática [1,2].

Com esse roteamento inteligente, é possível escolher o melhor caminho para o tráfego de dados com base nas condições da rede em tempo real, e a capacidade de utilizar simultaneamente várias conexões de rede, como banda larga, conexões via satélite e 5G [1].

A interseção da SD-WAN e do 5G abre um leque de possibilidades para gerenciar e otimizar redes. À medida que mais dispositivos se tornam capazes de se conectar via 5G, o tráfego de rede está propenso a aumentar substancialmente. Nesse contexto, a SD-WAN pode ser usada para gerenciar eficientemente esse aumento de tráfego de rede, garantindo que as redes não fiquem congestionadas e o desempenho não seja comprometido [1].

A flexibilidade e a gestão centralizada da SD-WAN podem facilitar o gerenciamento de redes 5G. Além disso, a capacidade da SD-WAN de utilizar várias conexões simultaneamente podem permitir que os administradores de rede combinem conexões 5G 3GPP e NON3GPP para maximizar o desempenho e a confiabilidade da rede [1].

Atenção: O texto acima foi extraído do TCC de Lucas Kienen Rota, intitulado Avaliação e validação da interoperabilidade das Redes Non3GPP com as redes 5G fim a fim (UE a UE), disponível em: https://repositorio.ufsc.br/handle/123456789/248729.

Referências:

[1] ROTA, Lucas Kienen. Avaliação e validação da interoperabilidade das Redes Non3GPP com as redes 5G fim a fim (UE a UE).  2023. 88 f. TCC (Graduação) – Curso de Engenharia de Controle e Automação, Departamento de Engenharia de Controle, Automação e Computação, Universidade Federal de Santa Catarina. Campus Blumenau, Blumenau, 2023. Disponível em: https://repositorio.ufsc.br/handle/123456789/248729. Acesso em: 13 jul. 2023.

[2] SEGEČ, P.; MORAVČIK, M.; URAMOVÁ, J.; PAPÁN, J.; YEREMENKO, O. SD-WAN – architecture, functions and benefits. IEEE Xplore, 2021.

O termo NON3GPP se refere a redes de comunicação que não são padronizadas pelo 3GPP. Isso inclui uma ampla variedade de tecnologias e redes sem fio que não seguem os padrões e especificações estabelecidos, como redes de acesso sem fio não licenciadas como Wi-Fi, redes ad-hoc, redes satelitais, redes de sensores sem fio, entre outras.

Os UEs são capazes de se conectar à rede principal 5G por meio de redes de acesso NON3GPP, como o IEEE Wi-Fi 802.11, usado para redes locais sem fio WLANs. A versão 15 realizada pela 3GPP oferece suporte para acesso em redes sem fio não confiáveis, em que a rede principal 5G assume que a rede de acesso não é segura. Já a versão 16 estende esse suporte para redes sem fio confiáveis e para acesso com fio. Embora o acesso NON3GPP começou a ser especificado na versão 8 do padrão 3GPP durante a era do 4G, a arquitetura 5G está mais alinhada com o acesso. A Figura 1 apresenta as funções de rede mais importantes nessa arquitetura [1,2].

 
Figura 1 – Arquitetura de acesso para rede NON3GPP [1].

Nessa arquitetura, o termo 5G-AN (5G Access Network) abrange tanto as redes de acesso 3GPP NG-RAN quanto as redes de acesso NON3GPP, como Wi-Fi. Em ambos os casos, o servidor AMF (Access and Mobility Management Function) controla o dispositivo móvel e realiza a autenticação dele junto ao AUSF (Authentication Server Function). O AMF se comunica com o dispositivo móvel através do ponto de referência N1 e com a rede de acesso através do ponto de referência N2, utilizando os mesmos procedimentos de sinalização que utiliza para o acesso 3GPP [1,2].

N3IWF

No núcleo do 5G existe uma função de rede nova, conhecida como N3IWF (Non3GPP Interworking Function), que possibilita a incorporação de redes que não estão incluídas no acesso estabelecido pelo 3GPP, isto é, permite a conexão das redes NON3GPP ao núcleo da rede 5G.

O N3IWF cria novos pontos de referência N2 e N3. Essa função atua como uma interface entre a rede de acesso e o núcleo 5G, protegendo as comunicações do dispositivo móvel na rede de acesso. Para tanto, estabelece um túnel seguro para o dispositivo móvel utilizando mensagens de sinalização sobre um ponto de referência chamado NWu [1,2].

Essa função é geralmente implementada em gateways ou pontos de interconexão. Essa interconexão é feita através do estabelecimento de túneis IKEv2 (Internet Key Exchange version 2) e IPsec (IP Security Protocol) entre N3IWF e UE [1,3]. A Figura 1 ilustra a utilização do N3IWF para conectar uma rede não 3GPP ao núcleo 5G.

NWu

NWu é um componente chave na configuração de uma rede móvel que conecta dispositivos através de acessos NON3GPP, a uma rede móvel 3GPP, como uma rede 5G.

O NWu é um túnel seguro e criptografado IPsec que é estabelecido entre o UE e um elemento de rede chamado N3IWF. O propósito deste túnel NWu é permitir que o tráfego de sinalização e de dados seja encaminhado entre o dispositivo e a rede móvel.

O NWu é estabelecido sobre duas outras conexões, Y1 e Y2, que o UE utiliza para se conectar à rede NON3GPP e depois à Internet, respectivamente. A conexão Y1 é tipicamente uma interface aérea WiFi, e a Y2 pode ser a própria Internet pública. Essas conexões Y1 e Y2 não são controladas nem especificadas pela 3GPP.

Em outras palavras, o NWu é uma solução de tunelamento seguro que permite a um dispositivo usar acessos de redes NON3GPP para se conectar a uma rede móvel 3GPP. O tráfego de dados é roteado através deste túnel NWu, de modo que o dispositivo possa interagir com a rede móvel como se estivesse conectado diretamente a ela [1].

Atenção: O texto acima foi extraído do TCC de Lucas Kienen Rota, intitulado Avaliação e validação da interoperabilidade das Redes Non3GPP com as redes 5G fim a fim (UE a UE), disponível em: https://repositorio.ufsc.br/handle/123456789/248729.

Referências:

[1] ROTA, Lucas Kienen. Avaliação e validação da interoperabilidade das Redes Non3GPP com as redes 5G fim a fim (UE a UE).  2023. 88 f. TCC (Graduação) – Curso de Engenharia de Controle e Automação, Departamento de Engenharia de Controle, Automação e Computação, Universidade Federal de Santa Catarina. Campus Blumenau, Blumenau, 2023. Disponível em: https://repositorio.ufsc.br/handle/123456789/248729. Acesso em: 13 jul. 2023.

[2] COX, C. An Introduction to 5G: The New Radio, 5G Network and Beyond. [S.l.]: Wiley, 2020. P. 19, 37. ISBN 9781119602682

[3] MAILER, Christian. Plataforma de CORE 5G em nuvem para disponibilização de funções de rede como serviço. 2020. 54 f. TCC (Graduação) – Curso de Engenharia de Controle e Automação, Departamento de Engenharia de Controle, Automação e Computação, Universidade Federal de Santa Catarina. Campus Blumenau, Blumenau, 2020. Disponível em: https://repositorio.ufsc.br/handle/123456789/209624. Acesso em: 13 jul. 2023.

UERANSIM

O UERANSIM é uma solução de software de código aberto, desenvolvida em C++, destinada à simulação de redes 5G. Esta ferramenta, que se destaca por oferecer uma implementação completa do UE e da gNB, permite a simulação de processos essenciais da rede 5G, tais como procedimentos de registro, estabelecimento de serviço, configuração de segurança, entre outros [1].

Essa plataforma de simulação fornece um ambiente controlado e reproduzível para experimentação e desenvolvimento da tecnologia 5G, sem a necessidade de acesso à infraestrutura real da rede 5G. Adicionalmente, seu caráter de código aberto permite que os usuários possam alterar e aprimorar o software conforme suas necessidades específicas, contribuindo para a evolução constante da ferramenta. Por isso, o UERANSIM se apresenta como um recurso valioso para pesquisadores, desenvolvedores e engenheiros que atuam com a tecnologia 5G [1,2].

Aether-in-a-box

O Aether-in-a-Box é um projeto de pesquisa e desenvolvimento no contexto do 5G que visa criar uma plataforma de testes e experimentação para a tecnologia 5G e suas aplicações. Esse projeto é financiado e apoiado por várias empresas líderes da indústria de telecomunicações, incluindo fornecedores de equipamentos, operadoras de rede e instituições acadêmicas [3].

O objetivo do Aether-in-a-Box é fornecer uma solução completa e de ponta a ponta para testes e validação de tecnologias 5G, incluindo equipamentos de rede, dispositivos móveis e aplicações. Ele busca criar um ambiente controlado e flexível, onde pesquisadores e desenvolvedores possam explorar os recursos do 5G, avaliar o desempenho de novos serviços e experimentar novas ideias em redes privadas [3].

A pesquisa realizada no âmbito do projeto Aether-in-a-Box abrange diversas áreas relacionadas ao 5G, como redes de acesso sem fio, virtualização de redes, computação em nuvem, internet das coisas (IoT), segurança e muito mais. Os pesquisadores envolvidos têm a oportunidade de explorar os desafios e as oportunidades apresentadas pelo 5G, contribuindo para o avanço dessa tecnologia e suas aplicações [3].

O Aether-in-a-Box surgiu como uma resposta à crescente demanda por plataformas de testes 5G mais acessíveis e flexíveis e também a rede privada é um conceito de grande impacto. A ideia por trás do projeto é permitir que empresas e instituições de pesquisa tenham acesso a um ambiente de teste realista e controlado, sem a necessidade de grandes investimentos em infraestrutura [3].

Ao disponibilizar uma plataforma aberta e modular, o Aether-in-a-Box incentiva a colaboração e o compartilhamento de conhecimento entre diferentes atores da indústria de telecomunicações. Isso contribui para impulsionar a inovação e acelerar o desenvolvimento de novas aplicações e serviços baseados no 5G [3].

No decorrer do projeto, várias empresas estão envolvidas no financiamento e suporte, incluindo fornecedores de equipamentos de rede, fabricantes de dispositivos móveis, operadoras de telecomunicações e instituições de pesquisa. Essa colaboração entre diferentes stakeholders é fundamental para impulsionar o desenvolvimento do 5G e garantir sua adoção bem-sucedida [3].

No geral, o projeto Aether-in-a-Box representa um esforço conjunto para impulsionar a pesquisa pela ONF, desenvolvimento e adoção do 5G, fornecendo uma plataforma de testes aberta e flexível. Com o envolvimento de várias empresas e instituições, ele está contribuindo para a evolução contínua do 5G e a criação de um ecossistema inovador para as futuras redes de telecomunicações [3,4].

Free5GC / Free5GC Compose

O Free5GC Compose é uma versão em Docker Compose do Free5GC, que por sua vez é um projeto em código aberto para simulação de processos e aplicações do core 5G mantido pela Universidade Nacional Chiao Tung (NCTU – National Chiao Tung University), localizada em Hsinchu, Taiwan. O objetivo final do projeto Free5GC é implementar o core da rede 5G definido na Release 15 (R15) e posteriores. A licença do Free5GC é a Apache 2.0, isto é, qualquer um pode usar o Free5GC para fins comerciais sem pagar taxas [5,6].

No estágio 3, o Free5GC apresenta um core 5G completamente funcional e suporta funcionalidades de operação, administração, e gerenciamento (OAM – Operation, Administration and Management) além de orquestração. Foram adicionadas as funções N3IWF e a funcionalidade de classificador de Uplink (ULCL – UpLink Classifier) [6], além das já suportadas funções: NSSF, NRF, UDM, PCF, AUSF, AMF, SMF, e UPF [5].

Além dos containers contendo cada uma das NFs isoladas, o Free5GC Compose possui um container com a implementação de uma interface Web (WebUI). A WebUI permite cadastrar os dispositvos de usuário no Core com uma série de configuraçãoes como: Identidade Internacional de Assinante Móvel (IMSI – International Mobile Subscriber Identity), S-NSSAI, DNN e configurações de QoS. Podendo através da WEBUI também, visualizar informações da conexão como consumo de dados em tempo real, endereço IP do assinante e entre outras funções. A plataforma Free5GC Compose utiliza o protocolo HTTP2 para implementar a arquitetura de representação do estado de Transferência (REST – Representational State Transfer) [5,6].

OpenAirInterface

O OAI (OpenAirInterface) é uma plataforma de software de código aberto criada com intuito de oferecer ferramentas para o desenvolvimento de redes de telecomunicações móveis definidas por software com base nos padrões 3GPP. O projeto é mantido pelo Eurecom, um instituto francês de pesquisa em telecomunicações [7,8]. O OpenAirInterface implementa o NG-RAN e o 5GC em hardware genérico, subdivididos em dois projetos [7,9].

O OpenAirInterface segue o conceito Open-RAN, que tem a premissa de implementar o rádio do 5G através de iniciativas de código aberto, removendo assim a necessidade de estar preso a tecnologias proprietárias e garantindo interoperabilidade e flexibilidade para escolher diferentes fornecedores durante a implantação de rede [7].

Usando o simulador OAI, pesquisadores e desenvolvedores podem avaliar o desempenho de protocolos e algoritmos de rede sem fio em várias condições e cenários. Isso permite que eles identifiquem possíveis problemas e otimizem o desempenho de seus sistemas sem fio antes de implantá-los em ambientes do mundo real [7].

5G-LENA

O simulador 5G-LENA, com código aberto, é um simulador de ponta a ponta, a nível de sistema, que é oferecido como um módulo do software ns-3 e é mantido pela instituição CCTC (Centre Tecnològic de Telecomunicacions de Catalunya), localizada na Espanha, possuindo licença GPLv2 [10].

Seu desenvolvimento se deu a partir de um fork do simulador ns–3 mmWave [10,11], que, por sua vez, foi baseado no simulador LENA (para 4G) que havia sido desenvolvido pelo CCTC [10,12].

Já que o simulador funciona sobre o ns-3, é possível utilizar outros módulos de simulação como Ethernet, Wi-Fi, LTE, entre outros, juntamente ao 5G-LENA, sendo possível conduzir simulações com interoperabilidade de tecnologias, o que aumenta a versatilidade dos testes e a relevância dos resultados [10].

As camadas PHY e MAC foram implementadas seguindo-se os padrões do rádio 5G, no entanto, as camadas e protocolos RLC, PDCP, RRC, NAS e o Core são ainda os mesmos do simulador LENA (4G) [10,12]. A camada SDAP, por não existir no 4G, também não está presente no 5G-LENA [10,12].

Dentre as funcionalidades do rádio 5G (NR) relevantes do simulador estão:

• configuração flexível e automática da estrutura do quadro NR através de múltiplas numerologias [10,12];
• acesso baseado em Orthogonal Frequency-Division Multiple Access (OFDMA) com TTIs (Transmission Time Interval) variáveis [10,12];
• novos schedulers flexíveis de MAC que consideram simultaneamente recursos de domínio de tempo e frequência (blocos de recursos e símbolos) tanto para esquemas de acesso Time-Division Multiple Access (TDMA) quanto para esquemas de acesso baseados em OFDMA com TTI variável [10,12];
• tempos de processamento em acordo com o rádio 5G [10,12];
• novos gerenciadores de Bandwidth Part (BWP) e arquitetura com suporte a múltiplas BWPs [10,12];
• suporte a frequências mmWave e bandas de 400 MHz [10].

Algumas outras funcionalidades, não específicas do 5G, são:

• suporte a configuração de potência de transmissão [10];
• configuração da quantidade de antenas [10];
• configuração da velocidade dos nós [10];
• beamforming [10];
• suporte a vários modelos de propagação [10].

Scapy

Scapy é um poderoso programa interativo de manipulação de pacotes. É capaz de forjar e decodificar pacotes de um grande número de protocolos, enviá-los, capturá-los, casar requisições e respostas, entre outros [5,13]. Uma das funcionalidades mais interessantes do Scapy é a capacidade de criar pacotes customizáveis, especificando as diferentes camadas e protocolos de rede, bem como alterar cada um dos campo dos cabeçalhos destes pacotes [5].

Essa criação e customização é facilitada com o uso da interface por linha de comando e pela sintaxe simples e direta, uma vez que o Scapy é implementado em Python. Outra funcionalidade que auxilia na criação de fluxos de pacotes é a função rdpcap em que é possível ler arquivos de gravação de tráfego (.pcap), arquivos estes que podem ser gerados em capturas de ferramentas como Tcpdump e Wireshark [5].

Outra funcionalidade implementada pela biblioteca Scapy é o método sniff. Esta função é responsável por capturar pacotes e armazená-los em uma estrutura que pode, posteriormente ser manipulada e tratada utilizando Python [5].

No código fonte 1 é possível observar o commando sniff para a captura de cem pacotes, esta quantidade é configurada através do parâmetro count. O comando se utiliza de um filtro que seleciona somente pacotes cujo protocolo da camada de transporte é UDP (User Data Protocol) e cujas portas são 67 ou 68, ambas referentes ao protocolo DHCP (Dynamic Host Configuration Protocol) e vindos do endereços IP de origem 8.8.8.8 através do parâmetro filter [5].

Além disto este comando filtra qual interface de rede desejada para interceptar os pacotes, neste caso eth0, uma interface do tipo Ethernet padrão, presente em sistema operacionais Linux. Por fim, todos estes pacotes interceptados são armazenados em uma variável pacotes para posterior tratamento e manipulação.

Código fonte 1 – Exemplo de utilização do comando sniff da biblioteca Scapy

pacotes = sniff(filter="src 8.8.8.8 udp port 67 or 68", iface="eth0", count=100)

Simuladores

A melhor forma de se avaliar sistemas para entender a influência de cada conjunto de configurações nos índices de desempenho finais é por meio de simulações [10].

Alguns exemplos de simuladores de redes utilizados na academia são o ns-3 e o OMNeT++. Ambos possuem bibliotecas com suporte a simulação de redes móveis e são muito versáteis, possuindo um grande leque de configurações disponíveis. Além disso, oferecem suporte à integração de recursos físicos e interfaces de redes do sistema operacional, permitindo a interação entre diferentes softwares e hardwares, como por exemplo: UE e interface de rádio simulada interagindo com um Core 5G e uma rede de dados real [10].

Também, softwares como o MATLAB são bastante utilizados para simulações de nível de enlace, pois possuem uma vasta biblioteca de funcionalidades para estudos de sistemas de controle, sinais e modulações, permitindo o desenvolvimento de códigos em linguagem própria que facilitam o acesso a tais recursos [10].

O Quadro 1 ilustra uma lista de simuladores de código aberto para sistemas 5G e uma breve descrição de cada um [10].

Quadro 1­ – Simuladores de 5G de código aberto

Simulador	Características principais
OpenAirInterface [9]	Pode ser utilizado com hardware SDR para testes reais controlando o acesso ou o UE. Possui também um simulador para simular a parte de rádio do 5G, porém não permite configurações avançadas como distância, beamforming, obstáculos, velocidade, entre outros.
NYUSIM [14]	Simulador de nível de enlace (link) para modelagem estatística de canal, código de simulação com interface fácil de usar e frequências de portadora de 2 a 73 GHz. Escrito para MATLAB.
Vienna 5G Simulators [15]	Simuladores de nível de enlace e de sistema para simulações em grande escala (incluindo centenas de nós) e suporte à paralelização. Escrito para MATLAB.
WiSE [16]	Simulador de nível de sistema para orientações multicamadas.
GTEC 5G Simulator [17]	Simulador de nível de enlace. Para MATLAB.
5G Toolbox by Matlab [18]	Simulador de nível de enlace, focado em modelagem de canal e geração de sinal. Para MATLAB.
Simu5G [19]	Simulador de ponta a ponta em nível de sistema baseado em OMNeT++.
5G-air-simulator [20]	Simulador em nível de sistema, de ponta a ponta, para modelar a interface de ar (air) 5G.
ns–3 mmWave [11]	Simulador em nível de sistema de ponta a ponta com pilha de protocolos completa para simular bandas de ondas milimétricas do rádio 5G (NR). Para ns-3.
5G-LENA [12]	Simulador em nível de sistema de ponta a ponta com pilha de protocolos completa para simular bandas de 0,5 até 100 GHz do rádio 5G (NR). Para ns-3.

Fonte: [21]. Traduzido e adaptado por [10]

Referências:

[1] ROTA, Lucas Kienen. Avaliação e validação da interoperabilidade das Redes Non3GPP com as redes 5G fim a fim (UE a UE).  2023. 88 f. TCC (Graduação) – Curso de Engenharia de Controle e Automação, Departamento de Engenharia de Controle, Automação e Computação, Universidade Federal de Santa Catarina. Campus Blumenau, Blumenau, 2023. Disponível em: https://repositorio.ufsc.br/handle/123456789/248729. Acesso em: 13 jul. 2023.

[2] UERANSIM. UERANSIM. Acessado em: 21 de Junho de 2023. 2023. Disponível em: https://github.com/aligungr/UERANSIM.

[3] LIAO, Douglas. Implementação de QoS em rede 5G através do Network Slicing.  2023. 75 f. TCC (Graduação) – Curso de Engenharia de Controle e Automação, Departamento de Engenharia de Controle, Automação e Computação, Universidade Federal de Santa Catarina. Campus Blumenau, Blumenau, 2023. Disponível em: https://repositorio.ufsc.br/handle/123456789/248721. Acesso em: 13 jul. 2023.

[4] FOUNDATION, Open Networking. Aether-in-a-Box for Developers. 2020. Disponível em: https://docs.aetherproject.org/master/developer/aiabhw5g.html. Acesso em: 6 jun. 2023.

[5] SILVA, Gabriel Henrique Davanço. Classificação de tráfego por classes de serviço no núcleo 5G. 2022. 80 f. TCC (Graduação) – Curso de Engenharia de Controle e Automação, Departamento de Engenharia de Controle, Automação e Computação, Universidade Federal de Santa Catarina. Campus Blumenau, Blumenau, 2022. Disponível em: https://repositorio.ufsc.br/handle/123456789/237577. Acesso em: 26 ago. 2022.

[6] NATIONAL CHIAO TUNG UNIVERSITY AND NATIONAL CHUNG CHENG UNIVERSITY. free5GC Link The Word! 2019. Disponível em: . Acesso em: 14 abr. 2022.

[7] BARETTA, José Luis Maziero. Encapsulamento de protocolos Ethernet Industrial utilizando a rede 5G. 2022. 74 f. TCC (Graduação) – Curso de Engenharia de Controle e Automação, Departamento de Engenharia de Controle, Automação e Computação, Universidade Federal de Santa Catarina. Campus Blumenau, Blumenau, 2022. Disponível em: https://repositorio.ufsc.br/handle/123456789/243552. Acesso em: 01 abr. 2023.

[8] MALLASEN QUINTANA, S. Deployment and analysis of a 5G NR radio access network based on Open RAN, using USRPs and OpenAirInterface. [S.l.: s.n.], Acesso em: 7 dez. 2022. Disponível em:http://hdl.handle.net/10251/187834.

[9] KALTENBERGER, F. et al. The OpenAirInterface 5G New Radio Implementation: Current Status and Roadmap. WSA 2019; 23rd International ITG Workshop on Smart Antennas, pp. 1-5, 2019.

[10] MAILER, Christian. Desenvolvimento e análise de um modelo de simulação para arquiteturas 5G industriais. 2022. 86 f. Dissertação (Mestrado) – Curso de Ciência da Computação, Centro Tecnológico, Universidade Federal de Santa Catarina, Florianópolis, 2022. Disponível em: https://repositorio.ufsc.br/handle/123456789/244587. Acesso em: 01 abr. 2023.

[11] MEZZAVILLA, M. et al. End-to-End Simulation of 5G mmWave Networks. IEEE Communications Surveys & Tutorials, vol. 20, no. 3, pp. 2237-2263, Abr. 2018, doi: 10.1109/COMST.2018.2828880.

[12] PATRICIELLO, N. et al. An E2E Simulator for 5G NR Networks. Simulation Modelling Practice and Theory, vol. 96, n. 101933, Nov. 2019, doi: 10.1016/j.simpat.2019.101933.

[13] BIONDI, P. Scapy: Packet Crafting for Python2 and Python3. 2021. Disponível em: . Acesso em: 12 jul. 2022.

[14] SUN, S.; MACCARTNEY, G. R.; RAPPAPORT, T. S. A novel millimeter-wave channel simulator and applications for 5G wireless communications. 2017 IEEE International Conference on Communications (ICC), pp. 1-7, Jul. 2017, doi: 10.1109/ICC.2017.7996792.

[15] MÜLLER, M. et al. Flexible multi-node simulation of cellular mobile communications: the Vienna 5G System Level Simulator. Journal on Wireless Communications and Networking, vol. 2018, n. 227, Set. 2018, doi: 10.1186/s13638-018-1238-7.

[16] JAO, C. -K. et al. WiSE: A System-Level Simulator for 5G Mobile Networks. IEEE Wireless Communications, vol. 25, no. 2, pp. 4-7, Abr. 2018, doi: 10.1109/MWC.2018.8352614.

[17] DOMINGUEZ-BOLANO, T. et al. The GTEC 5G link-level simulator. 1st International Workshop on Link- and System Level Simulations (IWSLS). 2016, pp. 1-6, doi: 10.1109/IWSLS.2016.7801585.

[18] MATHWORKS. 5G Toolbox, 2021. Simulate, analyze and tests 5G communications Systems. Math works. Disponível em: https://www.mathworks.com/products/5g.html. Acesso em: 07 nov. 2022.

[19] NARDINI, G. et al. Simu5G: A System-level Simulator for 5G Networks. Proceedings of the 10th International Conference on Simulation and Modeling Methodologies, Technologies and Applications, pp. 68-80, 2020, doi: 10.5220/0009826400680080.

[20] MARTIRADONNA, S. et al. 5G-Air-simulator: An open-source tool modeling the 5G air interface. Computer Networks, vol. 173, n. 107151, Maio 2020, doi: 10.1016/j.comnet.2020.107151.

[21] KOUTLIA, K. et al. Calibration of the 5G-LENA System Level Simulator in 3GPP reference scenarios. Elsevier Simulation Modelling Practice and Theory (SIMPAT), vol. 119, n. 102580, Maio 2022, doi: 10.1016/j.simpat.2022.102580.

A computação de borda trata de deixar os serviços mais próximos do local onde serão entregues. Os serviços aqui incluem potência de computação e memória necessária para, por exemplo, rodar uma requisição de um aplicativo. A computação de borda, portanto, visa trazer os aplicativos, dados e poder de computação (serviços) que se encontram longe em pontos centralizados (central de dados) para locais mais próximos do usuário (como centrais de dados distribuídas). O objetivo é atingir uma latência mais baixa e reduzir os custos de transmissão e tráfego no Core da rede. Aplicativos que usam grandes volumes de dados e/ou requerem tempos de resposta curtos, por exemplo, jogos de realidade virtual em tempo real, inspeção de qualidade por vídeo na indústria 4.0, carros autônomos, cidades inteligentes etc., são alguns dos candidatos que podem se beneficiar da computação de borda [1].

A 3GPP não especifica nenhuma solução ou arquitetura especial para computação de borda, em vez disso, a 3GPP define várias ferramentas gerais que podem ser usadas para fornecer um eficiente caminho para o usuário. Essas ferramentas não são específicas para computação de borda, mas podem ser usadas como facilitadores na sua implantação [2].

1 Seleção da UPF pela SMF

A SMF é responsável pela seleção da UPF. Os detalhes de como isso é feito não são padronizados e dependem de vários aspectos, por exemplo, aspectos de implantação relacionados à topologia de rede das UPFs implantadas, bem como, os requisitos do serviço que será entregue.

Quando a SMF faz a seleção de uma UPF, um pré-requisito é que a própria SMF esteja ciente de quais UPFs estão disponíveis em suas respectivas configurações, como recursos da UPF, sequência de carregamento no caso de mais de uma UPF, etc. Uma das formas é que a SMF pode ser configurada com as UPFs disponíveis. Essa configuração pode incluir informações relacionadas à topologia para que a SMF esteja ciente sobre a localização da UPF e de que forma as UPFs estão conectados. Isso permite que a SMF selecione UPFs adequadas, por exemplo, dependendo da localização do UE.

Uma vez que a SMF sabe sobre a(s) UPF(s) disponíveis e há uma necessidade da SMF selecionar uma ou mais UPFs para uma sessão de PDU, como exemplo, no estabelecimento de sessão de PDU ou em algum evento de mobilidade, a SMF pode levar diferentes informações em consideração para selecionar uma UPF. Os detalhes não são padronizados, mas deixados para implementação e configuração do operador [1]. Algumas dessas informações são recebidas da UPF, outras são recebidas da AMF, enquanto que algumas podem ser pré-configuradas na SMF, como as informações relacionadas à topologia do plano do usuário e terminações do plano do usuário.

2 Formas de classificação de tráfego para a DN

Uma sessão de PDU tem no caso mais simples uma única sessão PDU âncora (PSA PDU Session Anchor) denominada de PSA UPF e, portanto, uma única interface N6 para a DN [1]. Mas uma sessão de PDU também pode ter mais do que uma PSA UPF e, portanto, várias interfaces N6 para uma DN conforme a Figura 1.

1. 1. 1. 1. PSA UPF: Esta é a UPF que faz a conexão com a DN através da interface N6.

         2. UPF intermediária (I-UPF): Esta é a UPF que é inserida no caminho do plano do usuário entre a AN e a PSA UPF. Ela encaminha o tráfego entre a AN e o PSA UPF.

         3. UPF com classificador de Up-Link (UL-CL) ou ponto de ramificação (BP): Esta é uma UPF que está “bifurcando” o tráfego para uma sessão de PDU na conexão ascendente e “mesclando” caminhos Up-Link descendente, fazendo funções relacionadas a QoS.

Figura 1 – Configurações de UPF. A: PSA único. B: PSA + I-UPF. C: UL-CL + 2 PSAs [1].

Essa última opção apresentada na Figura 1 pode ser usada para rotear seletivamente o tráfego do plano do usuário para diferentes interfaces N6, por exemplo, rotear de uma PSA UPF com interface N6 para um site periférico local e outra PSA UPF com interface N6 para um data center Remoto [1]. Essa funcionalidade é de suma importância para este trabalho, pois pode ser usada em aplicações da computação de borda 5G.

3 Classificação de Up-Link

Classificação de Up-Link é uma funcionalidade que é suportada por uma UPF onde a UPF desvia parte do tráfego para uma PSA UPF diferente (local) conforme é apresentado na Figura 2. O UL CL fornece encaminhamento de tráfego de ligação ascendente para diferentes Âncoras de Sessão PDU e desvia o tráfego de ligação descendente para o UE, isto é, o desvio do tráfego de diferentes Âncoras de Sessão PDU na ligação para o UE. O UL CL desvia o tráfego com base nas regras de detecção e encaminhamento de tráfego, fazendo uso de filtros de tráfego fornecidos pela SMF. Assim, o UL CL aplica as regras de filtragem, por exemplo, para examinar o endereço IP de destino dos pacotes IP da conexão ascendente enviados pelo UE e determina como o pacote deve ser encaminhado. A UPF que suporta um UL CL também pode ser controlada pela SMF para oferecer suporte à medição de tráfego e aplicar cobranças. O uso do UL CL se aplica a Sessões de PDU do tipo IPv4 ou IPv6 ou IPv4v6 ou Ethernet, de modo que a SMF possa fornecer filtros de tráfego [1].

Figura 2 – Acesso local a DN usando o UL CL [1].

Quando a SMF decide desviar o tráfego, ela insere um UL CL no caminho de dados e uma PSA adicional. Isso pode ser feito a qualquer momento durante a vida útil de uma sessão de PDU. A PSA adicional pode ser colocada na mesma UPF que o UL CL ou pode ser uma UPF autônoma. Quando a SMF determina que o UL CL não é mais necessário, ele pode ser removido do caminho de dados pela SMF [1].

O UE desconhece o desvio de tráfego por parte do UL CL e não participa na inserção e na remoção do UL CL. A solução com o UL CL, portanto, não requer nenhuma funcionalidade específica do UE.

Atenção: O texto acima foi extraído do TCC de Dener Kraus, intitulado Computação de borda para indústria utilizando a rede 5G, disponível em: https://repositorio.ufsc.br/handle/123456789/228613.

Referências:

[1] ROMMER, S. et al. 5G Core Networks: Powering Digitalization. [S.l.]: Academic Press, 2019.

[2] 3GPP. Universal Mobile Telecommunications System (UMTS); LTE; General UMTS Architecture (3GPP TS 23.101 version 8.0.0 Release 8). Acesso em: 26/08/2021. Disponível em:<https://www.etsi.org/deliver/etsi_ts/123100_ 123199/123101/08.00.00_60/ts_123101v080000p.pdf>.

Na Tabela 1 é apresentado as principais empresas no depósito de patentes, declaração de patentes essenciais a padrões (SEP – Standard-Essential Patent) e desenvolvimento de padrões relacionados com computação de borda 5G. Essas empresas são do ramo de computação em nuvem ou de setores de dados e software.

	Cessionário atual/ Desenvolvedor de padrões	Pedidos de patente	Declaração SEP	Contribuições de padrões
1	Huawei (CN)	821	138	862
2	Intel (US)	686	42	488
3	Nokia (FN)	576	87	439
4	SAS Institute (US)	426	0	0
5	Apple (US)	386	72	41
6	Samsung Electronics (KR)	287	16	536
7	Verizon (US)	196	0	50
8	Microsoft (US)	188	0	0
9	Cisco (US)	168	0	39
10	Ericsson (SE)	163	6	374
11	LG Electronics (KR)	160	33	144
12	NEC (JP)	158	3	55
13	Pure Storage (US)	155	0	0
14	IBM (US)	125	0	0
15	Siemens (DE)	120	0	30
16	Sony (JP)	119	0	66
17	AT&T (US)	99	0	130
18	TE (CN)	96	4	193
19	Qualcomm (US)	68	6	256
20	Tencent (CN)	64	0	117
21	Convida Wireless (US)	60	0	88
22	CATT Datang Mobile (CN)	55	2	0
23	China Mobile (CN)	54	0	206
24	Deutsche Telekom (DE)	47	0	64
25	InterDigital (US)	46	2	77
26	SoftBank (JP)	46	0	4
27	Orange (FR)	41	0	60
28	Hewlett Packard Enterprise (US)	39	0	19
29	ETRI (KR)	37	1	29
30	Fraunhofer (DE)	35	11	17
31	Robert Bosch (DE)	34	0	10
32	Sharp (JP)	30	2	0

Tabela 1 – Relação empresas/desenvolvedores e número de patentes que descrevem tecnologias de computação de borda [1].

Fabricantes de chips, celulares e redes como Huawei (China), Intel (EUA), Nokia (Finlândia), Apple (EUA), Samsung Electronics (Coréia) e Ericsson (Suécia) contribuem fortemente para o desenvolvimento de padrões e, ao mesmo tempo, possuem grandes carteiras de patentes, algumas das quais são declaradas essenciais como padrão, isto é, uma patente que se torna um padrão que outros desenvolvedores ou empresas devem seguir. Além disso, muitas das operadoras de telecomunicações podem ser encontradas na lista dos principais proprietários de patentes e desenvolvedores de padrões, como Verizon (EUA), AT&T (EUA), China Mobile (China), Deutsche Telekom (Alemanha) e Orange (França).

Os líderes de tecnologia listados na Tabela 1 são de extrema importância para o sucesso da computação de borda, pois têm desenvolvido dispositivos, chips, redes, aplicativos, serviços, sensores e padrões de conectividade para realizar os primeiros casos de uso da computação de borda. Prevê-se que o mercado global da computação de borda em nuvem crescerá para US$12 bilhões ainda em 2021 [1]. Supõe-se que, até 2023, cerca de 70% das empresas estarão realizando parte de seus processamentos de dados usando a computação de borda 5G [1]. Assim, o interesse por uma parcela desse mercado é propagado entre várias empresas do ramo de desenvolvimento de tecnologia.

Uma dessas empressas interessada na computação de borda 5G é a WEG que tem criado parcerias com empresas da Tabela 1, como: Nokia e Qualcomm, além da já existente cooperação com a Agência Brasileira de Desenvolvimento Industrial (ABDI), a Agência Nacional de Telecomunicações (Anatel) e a Claro. O Open Lab 5G – V2COM da WEG em uma das fábricas, localizada na cidade de Jaraguá do Sul no estado de Santa Catarina (BR) completou testes práticos de conectividade à rede 5G. Foram realizados testes para avaliação de desempenho e a convivência de dispositivos e antenas com a tecnologia 5G em ambiente real para reunir informações sobre faixas de frequência, latência, potência e outras características necessárias às aplicações industriais [2].

De acordo com o relatório de resultados preliminares do Open Lab 5G – V2COM [3], foram obtidos dados experimentais utilizando a ferramenta iPerf [4], com transmissão de dados tanto TCP como em UDP ativando tráfego em cinco premissas de equipamentos de usuário (CPEs – Customer-premises equipment) parados e a uma distância de aproximadamente cinco metros de uma Small Cell: rede privada independente da Nokia na banda n78 (3,5 GHz), faixa de 3,7 GHz a 3,8 GHz, operando com largura de canal de 100 MHz, no modo SA (Stand Alone) e TDD (Time-Division Duplex) com distribuição 3:7 e saída de potência (Effective Isotropic Radiated Power – E.I.R.P.) de 23 dBm.

Um dos testes do relatório de resultados preliminares do Open Lab 5G – V2COM [3] é o de Throughput, latência e perda de pacotes versus a distância entre a Small Cell e um dos CPEs. Tais testes foram realizados posicionando fisicamente os CPEs a diferentes distâncias da Small Cell 4 da rede privativa independente – SA representada na Figura3, ou seja, apenas uma Small Cell ligada e as outras três desligadas.

Figura 1 – Topologia do teste da rede privativa independente – SA [3].

Foramrealizados testes utilizando-se a ferramenta iPerf com transmissão de dados em TCP para esta topologia em específico. As verificações foram feitas com o CPE parado às distâncias de 5, 20, 40 e 60 metros da Small Cell. Os valores de Throughput máximo, médio e mínimo obtidos durante o tempo de um minuto de medição são apresentados na Figura 2 e Figura 3. Também são apresentados nas mesmas figuras, os valores de latência médios obtidos durante quinze segundos antes do início do envio dos pacotes de dados, durante o um minuto em que são enviados os pacotes de dados e durante quinze segundos depois do envio dos pacotes de dados. Todas essas medições são apresentadas para cada uma das quatro distâncias em um mesmo gráfico para melhor visualização e comparação. São apresentados também, para as diferentes distâncias, os percentuais de redução de Throughput obtidos com relação ao Throughput a 5 metros.

Figura 2 – Uplink – Latência vs Throughput máximo (TCP) [3].

Figura 3 – Downlink – Latência vs Throughput máximo (TCP) [3].

Atenção: O texto acima foi extraído do TCC de Dener Kraus, intitulado Computação de borda para indústria utilizando a rede 5G, disponível em: https://repositorio.ufsc.br/handle/123456789/228613.

Referências:

[1] Pohlmann, T. Who is leading the 5G patent race for edge computing? Acesso em: 26/08/2021. Disponível em:<https://www.managingip.com/article/ b1rznbcc4dsk23/who-is-leading-the-5g-patent-race-for-edge-computing>.

[2] WEG. WEG completa testes práticos de conectividade à rede 5G. Acesso em: 26/08/2021. Disponível em:<https://www.weg.net/institutional/BR/pt/news/ produtos-e-solucoes/weg-completa-testes-praticos-de-conectividade-a-rede-5g>.

[3] WEG-V2COM OPEN LAB. RESULTADOS PRELIMINARES WEG-V2COM OPEN LAB 5G. Acesso em: 04/09/2021. Disponível em:<https://sei.anatel.gov.br/sei/modulos/pesquisa/md_pesq_documento_consulta_externa. php?eEP-wqk1skrd8hSlk5Z3rN4EVg9uLJqrLYJw_9INcO6fX6o9bVPoiTHX_ HKDp8z4jNp1Hsw31wuTQX8J-fqjddyWo1pe5dZRrEvwZXjQvETUCBSxxyrrpuXwu\ EBod27a>.

[4] iPerf. iPerf – The ultimate speed test tool for TCP, UDP and SCTP. Acesso em: 07/09/2021. Disponível em:<https://iperf.fr/>.

O Core é a estrutura responsável por gerenciar os recursos de rede e as conexões dos usuários, como autenticação, QoS, segurança, roteamento, encaminhamento de pacotes, mobilidade, interceptação legal e outros. Juntamente com a interface de acesso via rádio, Radio Access Network (RAN), compõe a rede móvel de telecomunicações.

No 5G, o Core foi concebido tendo-se como foco uma arquitetura baseada em serviços, ou seja, uma estrutura flexível em que suas funcionalidades são divididas em nós ligados a um barramento comum que interagem entre si de forma independente. Essa abordagem permite a utilização de recursos em nuvem, de orquestração e de edge computing para escalonar a rede e adaptá-la continuamente a variações na carga de processamento, atingindo-se, assim, maior eficiência e estabilidade.

Para comunicação entre os nodos, chamados de Network Functions (NFs), a 3GPP definiu uma API (Application Programming Interface) que funciona sobre o protocolo HTTP (Hypertext Transfer Protocol) e que segue o modelo REST (Representational State Transfer). O modelo REST, proposto em 2000, conta com amplo suporte nas linguagens de programação e é muito empregado na Web, onde muitas empresas disponibilizam uma API em REST para interação com seus produtos.

As funções de rede essenciais do Core 5G (mostradas na Figura 1) são: AMF, UDM (Unified Data Management), AUSF (Authentication Server Function), UDR (Unified Data Repository), SMF (Session Management Function), NRF (Network Repository Function) e UPF. São elas que gerenciam a autenticação, estabelecimento de sessão, roteamento, interface com a rede de rádio, interface com o equipamento do usuário (UE), mobilidade, estabelecimento de túnel com a rede de dados ou Data Network (DN), entre outras funcionalidades. No entanto, há ainda funções de rede adicionais que estendem as capacidades do Core (mostradas na Figura 2), como a PCF (Policy Control Function), NSSF (Network Slice Selection Function), N3IWF (Non-3GPP Inter Working Function), AF (Application Function), NEF (Network Exposure Function), SMSF (Short Message Service Function), LMF (Location Management Function) e outras.

Figura 1 – Elementos essenciais de uma rede 5G [2].

Figura 2 – Funções de rede de um Core 5G [2].

O conjunto de protocolos NAS (Non Access Stratum), composto por 5GMM (5GS Mobility Management) e 5GSM (5GS Session Management), intermedia a conexão entre o UE e o Core. Para as mensagens de controle entre UE e AMF, destinadas ao gerenciamento do registro de dispositivos, mobilidade e segurança, o protocolo 5GMM é utilizado, enquanto que para as mensagens entre UE e SMF, como as destinadas ao gerenciamento das sessões PDUs (Protocol Data Unit), utiliza-se o protocolo 5GSM.

As próximas subseções descrevem as principais função de rede do Core 5G.

AMF

O AMF (Access and Mobility Management Function) é responsável por estabelecer a conexão com a RAN, através da interface N2, e com o UE, através da interface N1. O AMF gerencia o registro, autenticação e mobilidade do UE, além de gerenciar a encriptação e integridade das mensagens NAS. Também, retransmite as mensagens de gerenciamento de sessão, Session Management (SM), entre UE e SMF, as mensagens SMS (Short Message Service) entre UE e SMSF, as mensagens dos serviços de localização entre UE e LMF e entre RAN e LMF e as mensagens de política entre UE e PCF. Por fim, conta ainda com suporte para entrega de mensagens de aviso públicas, Public Warning System (PWS), e interface para interceptação legal, Lawful Interceptation (LI). Ressalta-se que um determinado UE só poderá ser servido por um AMF em um instante de tempo. A Figura 3 ilustra as interfaces utilizadas pelo AMF para interação com as demais funções de rede.

Figura 3 – Interfaces de rede utilizadas pelo AMF [2].

SMF

O SMF (Session Management Function) estabelece e gerencia a conexão entre o UE e a rede de dados (DN). Para isso, ele seleciona o UPF de acordo com os requisitos da conexão e estabelece uma sessão PDU (Protocol Data Unit) entre o acesso e o UPF ou entre UPFs quando necessário. A interface de comunicação entre SMF e UPF é chamada de N4. O protocolo PFCP (Packet Forwarding Control Protocol), desenvolvido para o 4G e evoluído para o 5G, é utilizado na camada de aplicação da interface N4 e atua em cima do protocolo UDP. O estabelecimento da sessão PDU, bem como de suas características, depende dos requisitos do UE, das informações dos bancos de dados do UDM/UDR e das políticas de serviço e QoS configuradas no PCF. O SMF também pode alocar endereços IPs para as sessões PDUs e possui suporte para interface de interceptação legal (LI). A Figura 4 ilustra as interfaces utilizadas pelo SMF para interação com as demais funções de rede.

Figura 4 – Interfaces de rede utilizadas pelo SMF [3].

UPF

O UPF (User Plane Function) é a função de rede que gerencia o tráfego do usuário. Suas interfaces de rede estão expostas na Figura 5. Ele é escolhido e controlado pelo SMF, no que tange as políticas de serviço, e serve como ponte entre a rede de dados (DN) e o UE, roteando, processando e direcionando os pacotes de acordo com as regras do SMF. Desse modo, atua como ponto de ancoragem para a sessão PDU, abstraindo os eventos de mobilidade na rede e armazenando os pacotes que não podem ser entregues ao UE em um buffer para posterior encaminhamento. Pode ser disposto de forma geograficamente centralizada ou distribuída, não havendo restrições no número de UPFs servindo uma sessão PDU, conforme especificações da 3GPP. Além disso, podem ser implementados em série, encaminhando-se o tráfego com base em regras de roteamento.

O UPF é responsável, também, por coletar dados estatísticos de tráfego, gerar relatórios, aplicar QoS de acordo com a demanda da rede e replicar o tráfego para monitoramento legal.

Há uma funcionalidade no UPF chamada de Up Link Classifier (UL CL) que permite direcionar o tráfego para diferentes UPFs baseado em regras de encaminhamento fornecidas pelo SMF. O UL CL gerencia o envio dos pacotes do UE para as diferentes redes e das redes de volta para o UE, podendo ser adicionado ou removido a qualquer momento pelo SMF. A Figura 6 ilustra o funcionamento do UL CL.

Figura 5 – Interfaces de rede utilizadas pelo UPF [3].

Figura 6 – Direcionamento de tráfego através de UL CL [2].

NRF

O NRF (Network Repository Function) serve como repositório das funções de rede (NFs) disponíveis para o Core. Ele armazena as características que descrevem cada NF registrado e permite que outras NFs consultem seu banco de dados para obter o endereço, na rede, dos serviços desejados. A grande vantagem trazida pelo NRF é a não exigência de conhecimento prévio dos endereços e perfis dos elementos do Core que compõem a rede, podendo ser requisitados no momento em que uma determinada NF necessitar de um serviço de outra NF. Cada NF, ou entidade representando a NF, é responsável por registrar-se no NRF e atualizar seu status, porém, o NRF dispõe de um mecanismo keep alive que identifica elementos que não estão mais disponíveis. Mudanças na estrutura do Core ou de escalabilidade são simplesmente efetuadas através de atualizações do status da NF alterada no NRF, sem necessidade de alterar-se as configurações internas das outras NFs. Dentre as informações de perfis disponíveis no NRF, pode-se citar: tipo da NF, ID (identificação), endereço, capacidade, serviços suportados e informações de autorização.

UDM

O UDM (Unified Data Management) acessa e gerencia os dados de inscrições armazenados no UDR, envia dados relevantes para as NFs que servem o UE, como AMF e SMF, autoriza acessos e serviços, autentica usuários, gerencia identificação de usuários e oferece suporte a serviços SMS. De forma geral, o UDM fornece uma interface de acesso aos bancos de dados com informações da rede, permitindo que um usuário utilize múltiplos UDMs para transações diferentes.

UDR

O UDR (Unified Data Repository) armazena e fornece acesso de dados de inscrições para o UDM, dados de políticas para o PCF e dados estruturados para exposição para o NEF.

AUSF

O AUSF (Authentication Server Function) realiza a autenticação primária e o estabelecimento de chaves entre o UE e a rede, utilizando para isso informações do UDM. Suas interfaces com o AMF e o UDM podem ser visualizadas na Figura 7.

Figura 7 – Interfaces de rede utilizadas pelo AUSF [3].

PCF

O PCF (Policy Control Function) é responsável por armazenar e prover as políticas de serviço para as NFs. Para o SMF, as políticas fornecidas são os níveis de QoS e regras de tráfego e cobrança, as relacionadas ao estabelecimento da sessão PDU e as relacionadas ao tráfego local que podem influenciar a escolha do UPF por parte do SMF. Para o AMF, o PCF fornece as regras de acesso e mobilidade, como restrições de áreas de serviço e prioridades de acesso. Para o UE, o PCF fornece, através do AMF, políticas relacionadas ao acesso não 3GPP, políticas de escolha de fatias na rede (slicing), de escolha de redes de dados (DN), entre outras. As interfaces de rede do PCF estão expostas na Figura 8.

As políticas são determinadas considerando-se fatores como condição da rede, políticas da operadora local, requisitos de aplicativo e dados de assinatura do usuário.

Figura 8 – Interfaces de rede utilizadas pelo PCF [3].

NSSF

O NSSF (Network Slice Selection Function) é o elemento que seleciona as fatias de rede para serem utilizadas pelo UE. Tal procedimento é realizado com base no parâmetro de Single Network Slice Selection Assistance Information (S-NSSAI), que define a fatia desejada. Também, o NSSF lista os AMFs que podem servir o UE, podendo consultar o NRF para isso.

N3IWF

O N3IWF (Non-3GPP Inter Working Function) permite a integração de redes que não são parte do acesso definido pela 3GPP, como WiFi, ao Core 5G. Essa interconexão é feita através do estabelecimento de túneis IKEv2 (Internet Key Exchange) e IPsec (IP Security Protocol) entre N3IWF e UE. A Figura 9 ilustra a utilização do N3IWF para conectar uma rede não 3GPP ao Core 5G.

Figura 9 – N3IWF conectando uma rede não 3GPP ao Core 5G [2].

NWDAF

A função NWDAF (Network Data Analysis Function) é responsável por coletar dados de outras funções de rede por meio de serviços que expõem eventos dessas funções [4]. Ela também coleta dados de sistemas, operações e gerenciamento e do repositório unificado de dados (UDR). Qualquer outra função de rede ou até mesmo aplicativos externos podem teoricamente consumir os serviços oferecidos pela NWDAF [4,5]. Os principais consumidores da NWDAF são a NSSF e a PCF. Ao coletar dados, a NWDAF pode realizar análises, como resumos históricos ou estatísticos, ou previsões de valores futuros [4]. As análises realizadas pela NWDAF podem ser usadas por outras funções de rede para realizar ações específicas na rede, como modificar uma fatia específica ou modificar a qualidade de serviço (QoS) de um serviço [2,4].

Atenção: O texto acima foi extraído do TCC de Christian Mailer, intitulado Plataforma de CORE 5G em nuvem para disponibilização de funções de rede como serviço, disponível em: https://repositorio.ufsc.br/handle/123456789/209624.

Referências:

[1] MAILER, Christian. Plataforma de CORE 5G em nuvem para disponibilização de funções de rede como serviço. 2020. 54 f. TCC (Graduação) – Curso de Engenharia de Controle e Automação, Departamento de Engenharia de Controle, Automação e Computação, Universidade Federal de Santa Catarina. Campus Blumenau, Blumenau, 2020. Disponível em: https://repositorio.ufsc.br/handle/123456789/209624. Acesso em: 15 abr. 2021.

[2] ROMMER, S. et al. 5G Core Networks: Powering Digitalization. [S.l.]: Academic Press, 2019.

[3] PENTTINEN, J. 5G Explained: Security and Deployment of Advanced Mobile Communications. 1. ed. Hoboken, NJ, EUA: Wiley, 2019.

[4] ROTA, Lucas Kienen. Avaliação e validação da interoperabilidade das Redes Non3GPP com as redes 5G fim a fim (UE a UE).  2023. 88 f. TCC (Graduação) – Curso de Engenharia de Controle e Automação, Departamento de Engenharia de Controle, Automação e Computação, Universidade Federal de Santa Catarina. Campus Blumenau, Blumenau, 2023. Disponível em: https://repositorio.ufsc.br/handle/123456789/248729. Acesso em: 13 jul. 2023.

[5] SILVA, Gabriel Henrique Davanço. Classificação de tráfego por classes de serviço no núcleo 5G. 2022. 80 f. TCC (Graduação) – Curso de Engenharia de Controle e Automação, Departamento de Engenharia de Controle, Automação e Computação, Universidade Federal de Santa Catarina. Campus Blumenau, Blumenau, 2022. Disponível em: https://repositorio.ufsc.br/handle/123456789/237577. Acesso em: 26 ago. 2022.

Com o surgimento de conceitos e tecnologias como IoT (Internet of Things), Indústria 4.0, Blockchain, Big Data e outras que são voltadas ao acumulo de informações e comunicação, deparou-se com um empecilho: a falta de recursos das tecnologias sem fio existentes para lidar com grandes volumes de dados e prover o gerenciamento adequado desses dados na rede.

A solução que visa resolver esse problema é a nova geração de comunicação sem fio chamada de 5G, que aumenta consideravelmente a velocidade de troca de informações, apresenta baixa latência e maior eficiência espectral comparada às gerações anteriores. Além disso, essa nova geração conta com recursos que possibilitam gerenciar o tráfego de informações baseado na exigência de cada dispositivo, como fatiamento de rede (network slicing), permitindo que operadoras disponibilizem redes como serviço para seus clientes.

Ressalta-se a importância de tecnologias como Software Defined Networking (SDN) e Network Function Virtualization (NFV) para o 5G, termos que, respectivamente, nomeiam redes que são estabelecidas em ambiente virtual e funções de rede que, também, são criadas e executadas virtualmente.

A tecnologia 5G não melhora somente a velocidade de transmissão, mas também torna a comunicação mais estável, eficiente e disponibiliza novos serviços de Core. Altas frequências (aproximadamente 27 GHz) e MIMO (Multiple Input Multiple Output) são algumas das técnicas que possibilitam esses avanços, no entanto, as antenas de alta frequência possuem curto alcance (300 m).

O componente por trás da infraestrutura que fará o gerenciamento dos dispositivos de usuário e das virtualizações de rede é o Core Network, porém, até o 4G, essa tecnologia ficou restrita às operadoras de telecomunicações. O Core do 5G, chamado de 5G Core, foi concebido de forma a suprir as deficiências do Core do 4G (Evolved Packet Core) e baseia-se em conceitos como micro serviços, nuvem, container, virtualização e automação.

A arquitetura de uma rede 5G Standalone pode ser resumida em Acesso, Core e Rede de Dados. Tal arquitetura pode ser visualizada na Figura 1. O dispositivo que irá acessar a rede 5G é chamado de User Equipment (UE). Diferentemente das gerações anteriores, no 5G os UEs não serão representados apenas por smartphones, mas, sim, por uma ampla gama de dispositivos como sensores, carros e até mesmo robôs cirúrgicos.

Figura 1 – Elementos essenciais de uma rede 5G. Os retângulos representam as funções de rede do Core. Fonte: [2].

De forma genérica, são três as classes de uso que visam ser atendidas pelo 5G: enhanced mobile broadband (eMBB), massive machine-type communication (mMTC) e ultra-reliable and low-latency communication (URLLC). A Figura 2 ilustra as três classes citadas.

Figura 2 – Classes de uso do 5G. Fonte: [3]

Enhanced mobile broadband é a evolução da banda larga móvel existente para suportar maior capacidade de troca de informações. Visa atender áreas densamente povoadas, podendo atingir altas velocidades de envio e recebimento de dados.

Massive machine-type communication é a comunicação entre um grande número de dispositivos, como aplicações de Internet das Coisas. Uma característica comum desse tipo de comunicação é a troca de mensagens de pequeno tamanho, normalmente contendo dados como medições ou comandos para atuadores. Os dispositivos que usufruem desse serviço também necessitam de um baixo consumo de energia, uma vez que uma longa duração de bateria é essencial para a Internet das Coisas.

Ultra-reliable and low-latency communication é a comunicação voltada para serviços que exijam troca de dados em tempo real e com confiabilidade elevada, como carros autônomos, automação industrial e controle de tráfego. A latência, que deve ser menor do que 1 ms, é mais importante do que banda para essas aplicações.

Atenção: O texto acima foi extraído do TCC de Christian Mailer, intitulado Plataforma de CORE 5G em nuvem para disponibilização de funções de rede como serviço, disponível em: https://repositorio.ufsc.br/handle/123456789/209624.

Referências:

[1] MAILER, Christian. Plataforma de CORE 5G em nuvem para disponibilização de funções de rede como serviço. 2020. 54 f. TCC (Graduação) – Curso de Engenharia de Controle e Automação, Departamento de Engenharia de Controle, Automação e Computação, Universidade Federal de Santa Catarina. Campus Blumenau, Blumenau, 2020. Disponível em: https://repositorio.ufsc.br/handle/123456789/209624. Acesso em: 15 abr. 2021.

[2] ROMMER, S. et al. 5G Core Networks: Powering Digitalization. [S.l.]: Academic Press, 2019.

[3] CHANDRAMOULI, D.; LIEBHART, R.; PIRSKANEN, J. 5G for the Connected World. [S.l.]: Wiley, 2019.