Capítulo 4: Rede de Acesso da Rádio

A descrição de alto nível da RAN no Capítulo 2 quase não citou a estrutura interna da RAN. Vamos agora nos deter aos detalhes, e assim, explicar como a estrutura interna da RAN está sendo transformada no 5G.

Você pode pensar a RAN como tendo uma tarefa principal: transferir pacotes do CORE para um conjunto de UEs. Isso significa que a RAN está intimamente envolvida com o gerenciamento e escalonamento do espectro que foi discutido no último capítulo, porém há mais do que isto. Começaremos descrevendo o estágio do pipeline de processamento de pacote na RAN, e então mostraremos como esses estágios estão sendo desagregados, distribuídos e implementados.

Note que a desconstrução da RAN apresentada neste capítulo representa uma combinação de especificações padronizadas e estágios de implementação. O primeiro continua no âmbito do 3GPP, mas o segundo é primariamente influenciado por uma segunda organização: a Open-RAN Alliance (O-RAN) introduzida no Capítulo 1. A O-RAN é liderada por uma rede de operadoras com o objetivo de desenvolver uma implementação da RAN baseada em software que quebra o monopólio dos vendedores. Essas forças de negócio são certamente um fator em que as redes móveis 5G estão baseadas, mas nosso objetivo neste capítulo é projetar as decisões envolvidas nesta evolução.

4.1 Pipeline de Processamento de Pacotes

Figure 24 mostra os estágio de processamento de pacotes historicamente realizado na estação base, como especificado no padrão 3GPP. Note que a figura descreve uma estação base como um pipeline (enviando pacotes da esquerda para a direita em direção ao UE) mas também é válido vê-la como uma pilha de protocolos (como tipicamente é feito nos documentos do 3GPP). Também note que (por enquanto) somos agnósticos de como esses estágios são implementados. Como estamos caminhando para uma implementação baseada em nuvem, uma possível estratégia de implementação pode ser um microsserviço por bloco.

_images/Slide110.png

Figure 24. Pipeline de processamento na RAN, incluindo ambos os componentes do plano de controle e de usuários.

Os estágios chave estão descritos a seguir.

  • RRC (Controle de Recursos de Rádio - Radio Resource Control) → Responsável pela configuração de alto nível e aspectos relacionados a políticas do plano de controle da RAN. O RRC roda no plano de controle da RAN; ele não processa pacotes do plano de usuário.

  • PDCP (Packet Data Convergence Protocol) → Responsável pela compressão e descompressão de cabeçalhos IP, criptografia e proteção da integridade, e tomar uma decisão de encaminhamento “inicial” (i.e., quando enviar pacotes para a UE ou para outra estação base).

  • RLC (Radio Link Control) → Responsável pela segmentação e reagrupamento, incluindo o envio e recepção de segmento pela implementação de uma forma de pedido de repetição automática (ARQ - automatic repeat request ).

  • MAC (Media Access Control) → Responsável por armazenar (buffering), multiplexação e demultiplexação de segmentos, incluindo decisões de escalonamento em tempo real sobre quais segmentos são transmitidos. É também hábil realizar uma decisão “atrasada” de encaminhamento (i.e., para frequências alternativas, incluindo Wi-Fi).

  • PHY (Camada Física - Physical Layer) → Responsável pela modulação e codificação (como discutido no Capítulo 3), incluindo FEC.

Os últimos dois estágios na Figure 24 (conversão D/A e front-end de RF) estão fora do escopo deste livro.

Enquanto é simples ver os estágios na Figure 24 puramente como um pipeline da esquerda para a direita, o Escalonador descrito na Seção 3.2 (denotado por “S” na figura) roda no estágio do MAC, e implementa o “laço principal” para o tráfego de saída (outbound traffic): ele lê dados do upstream RLC e escalona transmissões para o downstream PHY. Como o escalonador determina o número de bytes para transmitir a uma certa UE durante cada período de tempo (baseado em todos os fatores destacados no Capítulo 3), ele pode solicitar (obter) um segmento de um certo comprimento da fila. Na prática, o tamanho do segmento pode ser transmitido no lugar de uma única UE durante um único intervalo de escalonamento pode durar de uns poucos bytes a um pacote IP inteiro.

Também note que uma combinação do RRC e PDCP são responsáveis pela observação feita na Seção 2.3: que uma “estação base pode ser vista como um encaminhador especializado”. A lógica do plano de controle que decide quando esta base pode continuar processando um pacote ou encaminhar para outra estação base rodando no RRC, e o mecanismo do plano de dados correspondente que carrega a decisão de encaminhamento no PDCP. A interface entre estes dois elementos é definida pelas especificações do 3GPP, mas a lógica de implementação é uma escolha de implementação (e historicamente proprietária). Este controle é geralmente referenciado como Radio Resource Management (RRM), não sendo confundido com o estágio RRC definido por padrão descrito na Figure 24.

4.2 RAN Particionada

O próximo passo é entender como a funcionalidade descrita acima é particionada entre elementos físicos, e como, “particionar” entre localizações centralizadas ou distribuídas. A opção dominante pode historicamente de “não particionar”, com o pipeline inteiro mostrado na Figure 24 rodando na estação base. Indo em frente, o padrão 3GPP foi estendido para permitir múltiplos pontos de partição, com a partição mostrada na Figure 25 sendo ativamente perseguida pela Aliança O-RAN que é o operador líder. Este é o particionamento que adotamos pelo resto deste livro. Note que o particionamento entre os componentes centralizado e distribuídos espelha o particionamento feito na SDN, como motivações similares. A seguir discutiremos a seguir como técnicas SDN são aplicadas a RAN.

_images/Slide23.png

Figure 25. Pipeline de processamento da RAN particionada distribuído entre uma unidade central (Central Unit - CU), unidade distribuída (Distributed Unit - DU), e unidade de rádio (Radio Unit - RU).

Isto resulta em configuração completa da RAn similar a mostrada na Figure 26, onde uma unidade central (Central Unit - CU) rodando em servidores na nuvem serve múltiplas unidades distribuídas (Distributed Units - DUs), cada uma por sua vez servindo a várias unidades de rádio (Radio Units - RUs). Criticamente, a RRC (centralizada na CU) é responsável por fazer somente configuração quase em tempo real e decisões de controle, enquanto o escalonador que é parte do estágio MAC é responsável por todas as decisões de escalonamento.

_images/Slide32.png

Figure 26. Hierarquia de particionamento da RAN, com uma CU servindo múltiplas DUs, cada uma servindo múltiplas RUs.

Como as decisões de escalonamento para transmissão de rádio são feitas pela camada MAC em tempo real, uma DU precisa estar “próxima” (dentro de 1ms) das RUs que gerencia. (Você não pode tomar decisões de escalonamento baseadas em informações desatualizadas sobre o canal). Uma configuração familiar é localizar uma DU e uma RU em uma torre celular. Mas quando uma RU corresponde a uma pequena célula, muito do que pode ser espalhado em uma área geográfica de tamanho modesto (e.g. shopping, campus, ou fábrica), então uma única DU provavelmente pode servir a múltiplas RUs. O uso de ondas milimétricas no 5G provavelmente tornará essa configuração mais comum.

Note também que a RAN particionada muda a natureza da rede Backhaul, que originalmente é conectada a estação base e o Core. Com a RAN particionada existem múltiplas conexões, que são oficialmente rotuladas como segue,

  • A conexão RU-DU é chamada de Fronthaul

  • DU-CU de Midhaul, e

  • CU-Mobile Core de Backhaul.

Para mais detalhes sobre considerações de projeto para interconexão de componentes distribuídos de uma RAN particionada, recomendamos o relatório da NGMN Alliance.

Leitura Adicional

RAN Evolution Project: Backhaul and Fronthaul Evolution. NGMN Alliance Report, March 2015.

Uma observação sobre a CU (que se torna relevante no Capítulo 6 quando a incorporamos em um serviço de nuvem gerenciado) é que pode colocar a CU e o Core no mesmo cluster, significando que o backhaul é implementado no cluster switching fabric. Nesta configuração, o midhaul efetivamente serve como o mesmo propósito que o backhaul original, e o fronthaul é restringido pelos requisitos predizíveis/baixa-latência do escalonador de tempo-real do MAC. Esta situação fica complicada pelo fato que o Core em si pode ser desagregado, como discutido no Capítulo 5.

Uma segunda observação sobre o CU mostrada na Figure 25 é que ela tem dois blocos funcionais — o RRC e o PDCP— que ficam nos planos de controle e de usuário da RAN, respectivamente. Esta separação é consistente com a ideia do CUPS introduzida no Capítulo 2, e tem uma papel cada vez mais importante à medida que entramos nos detalhes de como a RAN é implementada. Por agora, notamos que as duas partes são algumas vezes referidas como a CU-C e CU-U, respectivamente.

Concluímos nossa descrição da arquitetura da RAN particionada com a descrição alternativa da Figure 27. Para completude, esta figura identifica às interfaces padrão entre os componentes (e.g., N2, N3, F1-U, F1-C, and Open Fronthaul). Não vamos descrever essas interface, exceto que elas existem e há uma especificação 3GPP correspondente que trata destes detalhes. Ao invés disso, vamos comentar que existem implementações de código aberto (open source) para cada componente.

_images/Slide101.png

Figure 27. Descrição alternativa dos componentes da RAN compartilhada, mostrando as inter-unidades especificadas no 3GPP.

Com respeito a Unidade Central, muito da complexidade está na CU-C, que, como veremos na próxima seção, está sendo redesenhada usando SDN, com soluções de código aberto disponíveis. Com respeito a Unidade de Rádio, quase toda complexidade está na conversão D/A e como o sinal analógico resultante é amplificado. Várias empresas têm conhecimento proprietário significativo sobre este aspecto, e que certamente não estarão dispostas a divulgar.

Com respeito a Unidade Distribuída, a novidade é mista, e a figura mostra mais detalhes. O módulo High-PHY - que corresponde aos passos para a modulação RF da Figure 17 na Seção 3.1 - é uma das componentes mais complexas da pilha da RAN. Uma implementação open-source do High-PHY, conhecida como FlexRAN, está disponível e é amplamente usada em produtos comerciais. A única restrição é que às licenças de software restringem ao uso de processadores Intel, por isto também é o caso que o software FlexRAN explora as potencialidades específicas do hardware Intel. Para o resto da DU, o MAC é outra fonte de tecnologia fechada de alto valor, particularmente como o escalonamento é realizado. Existe uma versão de código aberto disponível pela Open Air Initiative (OAI), mas seu uso é restrito somente a desenvolvimento de pesquisas.

4.3 RAN Definida por Software

Vamos descrever como a RAN está sendo implementada de acordo com os princípios do SDN (Software Defined Newtork), resultando em uma SD-RAN. A chave para o insight arquitetural é mostrada na Figure 28, onde a RRC da Figure 24 é particionada em duas sub-componentes: o da direita provê uma forma compatível com 3GPP para a interface da RAN com o plano de controle de RAN (a figura rotula estes sub-componentes como um “Proxy”), enquanto o da direita abre uma nova API programática para exercer um controle baseado em software sobre o pipeline que implementa o plano da usuário da RAN.

Para ser mais específico, o sub-componente da esquerda simplesmente encaminha pacotes de controle entre o Core e o PDCP, provendo um caminho em que o Core pode se comunicar com a UE para fins de controle, enquanto isso o sub-componente da direita implementa o núcleo da funcionalidade de controle do RRC (conforme foi explicado na Seção 4.1 também é conhecida como RRM). Este último componente é comumente referenciado como RAN Intelligent Controller (RIC) nos documentos da arquitetura O-RAN, então vamos adotar essa terminologia. O qualificador “quase em tempo real” (“Near-Real Time”) indica que o RIC é parte dos 10-100ms do loop de controle implementado na CU, em oposição ao loop de controle de ~1ms requerido pelo escalonador do MAC rodando na DU.

_images/Slide42.png

Figure 28. RRC desagreagado em um plano de controle Mobile Core (a proxy) e um Near-Real-Time Controller.

Embora não mostrado na Figure 28, tenha em mente que (da Figure 25) o RRC e o PDCP, formam a CU. Juntar essas duas figuras ficou um pouco bagunçado, mas como uma primeira aproximação, o PDCP corresponde ao CU-U e o RRC-Proxy corresponde ao CU-C, com o RIC levantado e responsável por supervisionar ambos. Vamos deixar um diagrama descrevendo essa relação até a Sessão 4.5, onde vamos sumarizar o resultado fim a fim. Por enquanto, a visão importante é que a inspiração em SDN está refatorando a RAN que fica livre para mover as funcionalidades para novos limites, desde que mantenha as interfaces originais definidas pelo 3GPP.

_images/Slide52.png

Figure 29. Exemplo do conjunto de aplicações de controle (xApps) rodando sobre o Near-Real-Time RAN Controller (RIC), controlando um conjunto distribuído de elementos da RAN particionada (CU, DU, RU).

Completando a cena, a Figure 29 mostra o Near-RT RIC implementado como um controlador SDN portando os apps de controle. O RIC mantém uma RAN Network Information Base (R-NIB)—um conjunto de informações comuns que podem ser consumidas pelos vários apps de controle. A R-NIB include os valores médios no tempo do CQI e outros estados por sessão (e.g., identificadores de túneis GTP, valores de QCI para o tipo de tráfego), quanto o MAC (como parte da DU) mantém o valores instantâneos do CQI necessários para o escalonador de tempo-real. Mais geralmente, o R-NIB inclui os seguintes estados:

  • Nós Fixos (Atributos RU/DU/CU)

    • Identificadores

    • Versão

    • Report de Configuração

    • RRM config

    • Utilização de recursos PHY

  • Nós Móveis (Atributos UE)

    • Equipamentos

      • Identificadores

      • Capacidades

      • Medições de Config

      • Estado(Ativo/Inativo)

    • Enlaces (Atuais e Potenciais)

      • Identificadores

      • Tipo do Enlace

      • Parâmetros Config/Bearer

      • Valores QCI

  • Construtores Virtuais (Atributos do Slice)

    • Enlaces

    • Bearers/Fluxos

    • Parído de Validade

    • KPIs Desejados

    • Configuração MAC RRM

    • Controle de Configuração RRM

  • Virtual Constructs (Slice Attributes)

    • Links

    • Bearers/Flows

    • Validity Period

    • Desired KPIs

    • MAC RRM Configuration

    • RRM Control Configuration

Os quatro exemplos de Apps de Controle (xApps) na Figure 29 não constituem uma lista exaustiva, mas representam um ponto adequado para SDN com ênfase no controle central sobre o encaminhamento distribuído. Estas funções —Link Aggregation Control, Interference Management, Load Balancing, and Handover Control—são normalmente implementadas individualmente em cada estação base tendo somente visibilidades local, mas tem consequências globais. O approach SDN é de forma centralizada coletar os dados disponíveis, tomar uma decisão ótima global, e então enviar os respectivos parâmetros de controle para execução na estação base. Uma analogia interessante é o que se tem feito para otimizar redes geograficamente distribuídas ( veja por exemplo B4).

Leitura Adicional

Por exemplo de como os princípios do SDN tem sido aplicados com sucesso na construção de uma rede, nós recomendamos B4: Experience with a Globally-Deployed Software Defined WAN. ACM SIGCOMM, August 2013.

Uma forma de caracterizar xApps é se basear na prática atual de controlar o enlace da rede móvel em dois níveis. Em um nível mais fino, os controles por nó e por enlace são conduzidos usando as funções RRM que são distribuídas ao longo das estações base.1 Funções RRM incluem o escalonador, controle de handover, controle de agregação de portadora e de enlace, bearer control, e controle de acesso. Em um nível macro, otimização e configuração regional da rede móvel são conduzidos usando funções Self-Organizing Network (SON). Essas funções veem listas de vizinhos, gerenciam o balanceamento de carga, otimizam a cobertura e a capacidade, buscam mitigar a interferência na rede como um todo, de forma centralizada configuram parâmetros, e assim por diante. Como consequência desses dois níveis de controle, é comum ver referência a aplicações RRM e aplicações SON, respectivamente, nos documentos O-RAN para SD-RAN. Por exemplo, os xApps de gerenciamento de interferência e balanço de carga na Figure 29 são aplicações SON, enquanto outros xApps são aplicações RRM.

1

De forma pedante, Radio Resource Management (RRM) é outro nome para a coleção de funções de controle tipicamente implementadas no estágio RRC da pipeline RAN.

Tenha em mente, entretanto, que esta caracterização dos xApps é baseada nas implementações do passado (pre-SDN). Isto ajuda nas transições da indústria para o SD-RAN, mas a situação está prestes a mudar. SDN está transformando a RAN, então novas formas de controlar a RAN - resultando em aplicações que não se encaixam especificamente na dicotomia RRM vs SDN- são esperadas com o tempo.

4.4 RIC Tempo Quase Real

Afundando nos níveis de detalhes, Figure 30 mostra um exemplo da implementação de uma RIC baseada em um redirecionaamento o Open Network OS (ONOS) para o caso da SD-RAN. ONOS (descrito no livro sobre SDN) foi originalmente projetado para suportar redes cabeadas tradicionais usando interfaces padrão (OpenFlow, P4Runtime, etc.). Para o caso do SD-RAN, o RIC baseado em ONOS por sua vez suporta um conjunto de interfaces sul e norte da RAN, mas internamente toma vantagem das mesma coleção de subsistemas (microsserviços) como no caso das redes cabeadas.2

2

Tecnicamente, a definição de RIC da O-RAN se refere a combinação de xApps e a plataforma base (no nosso caso ONOS), mas enfatizamos a distinção entre os dois, metendo o modelo SDN que distingue entre o OS de rede e a suite de Apps de Controle que roda nele.

_images/Slide62.png

Figure 30. RAN Intelligent Controller (RIC) compatível com O-RAN construída pela adaptação e extensão do ONOS.

Especificamente, o RIC baseado em ONOS inclui a Topologia de Serviço para manter o registro da infraestrutura fixa da RAN, um serviço de equipamento que acompanha às UEs, e um serviço de configuração que gerencia o estado de configuração de toda a RAN. Todos esses três serviços são implementados como microsserviços baseados em Kubernetes, e tomam vantagem de um armazenamento Key/Store escalável.

Uma das três interfaces mostradas na Figure 30, as interfaces A1 e E2 são baseadas em padrões pré-existentes do 3GPP. A terceira, xApp SDK é específica da implementação baseada em ONOS. A O-RAN Alliance é usada para direcionar uma API unificada (e a SDK correspondente) para construir xApps RIC-agnóstico.

A interface A1 provê um meio para o plano de gerenciamento das operadoras - tipicamente chamado de OSS/BSS (Operations Support System / Business Support System) no mundo da telecomunicações - configurar a RAN. Fizemos uma breve introdução sobre a OSS/BSS na Seção 2.5, mas tudo o que precisamos saber sobre ela para nossos propósitos é que este componente está no topo da pilha de software de telecom. Ele é a fonte de todas as configurações e lógicas de negócios necessárias para operar uma rede. Você pode pensar como a contrapartida da RAN para o gNMI/gNOI (gRPC Network Management Interface/gRPC Network Operations Interface), um par de APIs de configuração comumente usada para configurar o hardware da nuvem.

O Near-RT RIC usa a interface E2 para controlar os elementos de suporte a RAN, incluindo as CU, DUs e RUs. Um elemento necessário da interface E2 é que ela seja hábil a conectar o Near-RT RIC a diferentes tipos de RAN de diferentes marcas. Esta amplitude de possibilidades se reflete na API, e se deve a abstração do modelo de serviço. A ideia é que cada elemento da RAN divulgue um Modelo de Serviço, que efetivamente define o conjunto de funções que os elementos da RAN são capazes de suportar. O RIC então usa uma das seguintes quatro operações contra este Modelo de Serviço.

  • Report: RIC pergunta aos elementos um relatório de valores específicos das configurações das funções.

  • Insert: RIC instrui os elementos a ativar a função do plano de usuário.

  • Control: RIC instrui os elementos a ativar a função de plano de controle.

  • Policy: RIC configura uma política de parâmetros em uma das funções ativadas.

Claro, ele é um elemento da RAN, então publica sem Modelo de Serviço, que define os conjuntos de funções relevantes que podem ser ativados, às variáveis que podem ser reportadas e às políticas que podem ser configuradas. A comunidade O-RAN está trabalhando em dois Modelos de Serviço agnóstico ao vendedor. O primeiro, chamado Medição de Parâmetros Chave (Performance Measurement - E2SM-KPM), especifica que métricas podem ser obtidas dos elementos da RAN. O segundo, chamado de RAN Control (E2SM-RC), especifica os parâmetros que podem ser configurados para controlar os elementos da RAN.

Em termos simples, E2SM-KPM define que valor pode ser lido e E2SM-RC define que valores podem ser escritos. Como os possíveis valores podem ser altamente variáveis entre todos os possívei dispotitivo, podemos esperar que diferentes fabricantes irão suportar somente uma parcela desses equipamentos. Isto limitará a üniversalidade” que a O-RAN estava desejando em um esforço para quebrar a hegemonia dos fabricantes, mas o resultado é familiar para os operadores de rede que vem lidando com as Bases de Informação de Gerenciament ( Management Information Bases - MIBs) divergentes desde os primeiros dias da Internet.

Finalmente, o xApp SDK, que é especificado na implementação baseada em ONOS, é atualmente um pouco mais do que “caminho de passagem” da interface E2. Isto implica que os xApps são esperados estarem cientes dos Modelos de Serviço. Um dos desafios que o SDK tem é como dados são passados de e para os elementos da RAN são codificados. Por razões históricas, a interface E2 usa a formatação ASN.1, enquanto o ONOS-RIC internamente usa gRPC e Buffers de Protocolo para comunicação entre os conjuntos de microsserviços. A interface south-bound E2 na Figure 30 traduz entre os dois formatos. O SDK atual faz a API baseada em gRPC-based API disponível para os xApps.

Leitura Adicional

Para aprender mais sobre os detalhes do ONOS e suas interfaces, recomendamos o capítulo no livro sobre SDN que cobre o assunto em detalhes Software-Defined Networks: A Systems Approach. Chapter 6: Network OS.

4.5 Laços de Controle

Concluímos a descrição da parte interna da RAN revisitando a sequência de passos envolvidos na desagregação, que, como as três seções anteriores revelaram, está sendo perseguida em múltiplas camadas. Ao fazer isto, conectaremos vários pontos soltos, e focaremos a atenção nos três laços de controle resultantes.

Na primeira camada de desagregação, o 3GPP define múltiplas opções de como a RAN pode ser particionada e distribuída, com o pipeline mostrado na Figure 24 desagregado em componentes CU, DU, e RU operando independemente como mostrado na Figure 31. A aliança O-RAN selecionou opções de desagregação específicas do 3GPP e está desenvolvendo uma interface aberta entre esses componentes.

_images/Slide72.png

Figure 31. Primeira camada de desagregação da RAN: RAN particionada.

A segunda camada de desagregação foca na separação dos planos de controle/usuário da CU, resultando na CU-U e CU-C mostradas na Figure 32. O plano de controle em questão é o plano de controle do 3GPP, onde a CU-U realiza o pipeline para tráfego de usuário e o CU-C foca nas mensagens de sinalização de controle entre o Core e os componentes da RAN desagregada (como também com o UE).

_images/Slide82.png

Figure 32. Segunda camada de desagregação da RAN: CUPS.

A terceira camada segue o paradigma SDN separando muito do controle da RAN (Funções RRC) dos componentes da RAN desagregada, e logicamente os centralizado como aplicações rodando no Controlador SDN, que corresponde ao Near-RT RIC mostrado previamente nas Figures 28 e 29. Esta desagregação baseada em SDN é repetida na Figure 33, que também mostra as interfaces A1 e E2 da O-RAN introduzidas na seção anterior. (Note que todas as bordas na Figures 31 e 32 correspondem às interfaces definidas no 3GPP, como identificado na Seção 4.2, mas os seus detalhes estão fora do escopo desta discussão).

_images/Slide92.png

Figure 33. Terceira camada de desagregação a RAN: SDN.

Tomadas em conjunto, as interface A1 e E2 completam dois dos maiores laços de controle da RAN: o laço externo (non-real-time) que tem o Non-RT RIC como um ponto de controle e o laço do meio (near-real-time) que tem o Near-RT RIC como ponto de controle. O terceiro laço de controle (mais interno) - mostrado na Figure 33 rodando dentro da DE- inclui o Escalonador embarcado no estádio MAC do pipeline da RAN. Os dois outros laços têm limites de >>1sec e >10ms, respectivamente, como mostrado no Capítulo 2, o controle em tempo real é assumido ser <1ms.

Isto levanta a questão de como uma funcionalidade específica é distribuída entre o Non-RT RIC, Near-RT RIC, e DU. Começando com o segundo par (i.e., os dois laços internos), este é o caso em que nem todas as funções RRC podem ser centralizadas; algumas precisam ser implementadas na DU. A desagregação baseada em SDN então foca naquelas que podem ser centralizadas, com o Near-RT RIC suportando as aplicações RRC e as aplicações SON mencionadas na Secção 4.3.

Para os outros dois laços de controle, o Near RT-RIC abre a possibilidade de introduzir uma política baseada no controle da RAN, quando interrupções (exceções) às políticas definidas pelo operador podem sinalizar a necessidade do laço externo estar envolvido. Por exemplo, podemos imaginar controles baseados em aprendizado, onde a interface dos engines para esses controles podem rodar aplicações como o Near RT-RIC, e as contrapartidas de tempo não real podem rodar em qualquer lugar. O Non-RT RIC pode interagir com o Near-RT RIC para entregar políticas relevantes ao operador ao Plano de Gerenciamento para o Near RT-RIC sobre a interface A1.