Contents

Introdução

Pré-requisitos

Requisitos

Componentes Utilizados

Informações de Apoio

Visão geral da arquitetura e da solução

Configurações necessárias em AMF/SMF

Exemplo de snap de pacotes

PODs DNS principais e configuração necessária na camada SMI

Introdução

Este documento descreve o aprofundamento da abordagem de comunicação SCP Model-D entre o Cisco AMF/SMF e a NF de terceiros.

Pré-requisitos

Requisitos

A Cisco recomenda que você tenha conhecimento destes tópicos:

- Funcionalidade da função de gerenciamento de acesso e mobilidade (AMF)

- Funcionalidade da Função de Gerenciamento de Sessão (SMF)

- Funcionalidade do Proxy de Comunicação de Serviço (SCP)

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Informações de Apoio

Operadores em todo o mundo podem escolher entre vários modelos de comunicação usando SCP para a descoberta da Função de Rede (NF) e comunicações subsequentes de NF para NF. Este tópico aborda os conceitos sobre vários modelos de comunicação e as alterações de fluxo/configuração de chamadas necessárias na Infraestrutura de Microsserviços de Assinante (SMI - Subscriber Microservices Infrastructure), AMF/SMF para ter comunicação baseada em SCP Model-D.

Visão geral da arquitetura e da solução

Na arquitetura baseada em serviço (SBA), o SCP atua como um intermediário, facilitando a comunicação indireta entre NFs ao lidar com roteamento, balanceamento de carga e descoberta de serviços, simplificando, em última análise, a arquitetura baseada em serviço.

O 3GPP 23.501 Anexo E detalha os quatro modelos de comunicação entre NF em uma implantação 5GC.

Figura A: (Modelos de comunicação diferentes envolvendo SCP)

Modelo A - Comunicação direta sem interação da Network Repository Function (NRF): Os consumidores são configurados com os "perfis de NF" dos produtores e se comunicam diretamente com um produtor de sua escolha. Esse é o tipo de seleção estática e nem NRF nem SCP são usados.

Modelo B - Comunicação direta com interação NRF: Os clientes realizam a descoberta consultando o NRF. Com base no resultado da descoberta, o consumidor faz a seleção. O consumidor envia o pedido ao produtor selecionado.

Modelo C - Comunicação indireta sem descoberta delegada: Os consumidores descobrem consultando o NRF. Com base no resultado da descoberta, o consumidor faz a seleção de um conjunto de NF ou de uma instância específica de NF do conjunto de NF. O consumidor envia a solicitação ao SCP contendo o endereço do produtor de serviço escolhido apontando para uma instância de serviço de NF ou um conjunto de instâncias de serviço de NF. Neste último caso, o SCP escolhe uma instância do Serviço de NF. Se possível, o SCP interage com o NRF para obter parâmetros de seleção como localização, capacidade e assim por diante. O SCP roteia a solicitação para a instância do produtor do serviço de NF escolhida.

Modelo D - Comunicação indireta com descoberta delegada: Os consumidores não estão envolvidos na descoberta ou na seleção. O consumidor adiciona à solicitação de serviço todos os parâmetros de descoberta e seleção necessários para encontrar um produtor adequado. O SCP usa o endereço de solicitação e os parâmetros de descoberta e seleção na mensagem de solicitação para rotear a solicitação para uma instância de produtor adequada. O SCP pode executar a descoberta com um NRF e obter um resultado de descoberta.

Mergulhe fundo na comunicação baseada em Modelo D: Quando Call Model-D é usado, o consumidor de NF não envia diretamente uma solicitação ao NRF, mas delega essa descoberta ao SCP. O cliente NF envia uma mensagem ao SCP e concatena para cada um desses fatores de descoberta a sequência '3gpp-sbi-discovery' com o nome do fator de Descoberta que será usado se a descoberta da NF for feita através do NRF.

Em um cenário em que o SMF procurará o Unified Data Management (UDM) com nomes de serviço nudm-sdm, os fatores de descoberta serão passados para o SCP:

- Cabeçalho da autoridade: a autoridade transporta o FQDN (Fully Qualified Domain Name, Nome de domínio totalmente qualificado) ou o endereço IP, com prioridade para a configuração do endereço IP.

- 3gpp-sbi-discovery-requester-nf-type: SMF

- 3gpp-sbi-discovery-target-nf-type: UDM

- 3gpp-Sbi-discovery-service-name: nudm-sdm

Figura B: (Comunicação SMF-UDM via SCP modelo D)

Note: O formato de nome 3gpp-sbi-discovery-service está em um formato de cadeia de caracteres simples e não em um formato de matriz de acordo com 3gpp 29.510 e definições de API aberta (estilo 4.7.12.4). No 29.510, 3gpp-sbi-discovery-service-name é mencionado como um formato de matriz.

Figura C: (Instantâneo das especificações 29.510)

No entanto, style:form e explode:false convertem a matriz em uma string simples, que é explicada tomando-se um exemplo de OpenAPI.

Figura D: (Instantâneo da API aberta: (4.7.12.4 Exemplos de estilo)

Você tem o controle CLI no AMF e no SMF para enviar o parâmetro 3gpp-sbi-discovery-service, pois ele é opcional (pode ser feito dependendo do ambiente de implantação).

No caso do Modelo B, se você pegar o exemplo de comunicação AMF e Authentication Server Function (AUSF), quando o AUSF for descoberto, o AMF enviará o POST para o AUSF com AUSF IP/FQDN e Port.

POST http://<ausf-fqdn>:<port>/nausf-auth/v1/ue-authentications.

Figura E: (Comunicação AMF-AUSF através do Modelo B)

No Modelo-D, conforme a descoberta é realizada pelo SCP, em vez de POST http(s)://<ausf-fqdn>:<ausf-port>/nausf-auth/v1/ue-authentications, o AMF envia a solicitação de POST modificada que é:

POST http(s)://<scp-fqdn>:<scp-port>/nausf-auth/v1/ue-authentication

Ou

POST http(s)://<scp-fqdn>:<scp-port>/nscp-route/nausf-auth/v1/ue-authentications(if apiroot=nscp-route)

Com

3gpp-Sbi-Discovery-target-nf-type: AUSF

3gpp-Sbi-Discovery-Localidade-preferida: LOC1

3gpp-Sbi-Discovery-service-name

Onde você pode ver que o AMF substituiu a raiz da API (<ausf-fqdn>:<ausf-port>) do AUSF pela raiz da API do SCP.

Figura F: (Comunicação AMF-AUSF via SCP-Modelo D)

Os parâmetros 3gpp-sbi-discovery permitem que o SCP recupere a melhor NF e, em seguida, encaminhe a solicitação POST, onde ela substitui a raiz da api do SCP pela raiz da api recebida do NRF após ter recebido a resposta à sua solicitação de descoberta.

Configurações necessárias em AMF/SMF

Para indicar para cada NF (por exemplo, UDM) qual modelo de chamada deve ser usado, a configuração do modelo de seleção de nf é usada dentro do "elemento de rede de perfil" associado.

profile network-element udm prf-udm-scp

[...]

nf-selection-model priority <>[local | nrf-query | nrf-query-peer-input | nrf-query-and-scp | scp]

exit

Depois que Model-D é escolhido, os parâmetros de consulta configurados para o elemento de rede associado ainda são usados e passados para o SCP no formato '3gpp-Sbi-Discovery-<query-param>'.

[smf] smf(config)# profile network-element udm prf-udm-scp

[smf] smf(config-udm-udm1)# query-params

Possible completions:

[  chf-supported-plmn  dnn  requester-snssais  tai  target-nf-instance-id  target-plmn ]

Eventualmente, o elemento de rede do perfil é mapeado para o perfil Data Network Name (dnn).

profile dnn ims

network-element-profiles udm prf-udm-scp

network-element-profiles scp prf-scp

exit

SCP(s) são definidos como elemento de rede.

o perfil de cliente nf e o perfil de tratamento de falhas são mapeados com o elemento de rede.

profile network-element scp <>

nf-client-profile        <>

failure-handling-profile <>

exit

O nf-client-profile do tipo scp-profile detalha as características do endpoint SCP.

Aqui nscp-route pode ser adicionado em api-root.

profile nf-client nf-type scp

scp-profile <>

locality LOC1

priority 30

service name type <>

responsetimeout 4000

endpoint-profile EP1

capacity   30

api-root   nscp-route

priority   10

uri-scheme http

endpoint-name scp-customer.com

priority 10

capacity 50

primary ip-address ipv4

primary ip-address port

fqdn name <>

fqdn port <>

exit

O FQDN SMF é configurado na interface descendente do ponto de extremidade (SBI).

endpoint sbi

relicas 2

nodes 2

fqdn <>

Exemplo de snap de pacotes

Figura G: ( AMF - comunicação nsmf-pdusession SMF via SCP Modelo D)

Você precisa do dnn do perfil para consultar o elemento de rede SCP que acabou de ser configurado.

profile dnn <>

network-element-profiles udm <>

network-element-profiles scp <>

exit

Se o tratamento de falha SCP for configurado com ação como repetição, o SMF tentará alternar o SCP com base na configuração SCP e na contagem de repetição.

Se o tratamento de falhas SCP for configurado com ação como repetição e fallback para um nome de serviço e tipo de mensagem específicos, ocorrerá o fallback para o Modelo A.

Esse Perfil de Tratamento de Falhas para SCP (FHSCP) será usado se o erro for disparado do SCP (cabeçalho do servidor indicando SCP) e a configuração do cliente de NF para o peer estiver presente.

profile nf-client-failure nf-type scp

profile failure-handling <>

service name type npcf-smpolicycontrol

responsetimeout 1800

message type PcfSmpolicycontrolCreate

status-code httpv2 0,307,429,500,503-504

retry  1

action retry-and-fallback

exit

Exemplo do perfil de cliente nf para a Policy Control Function (PCF) para o cenário em que a ação retry and falback está configurada para o tipo de mensagem PcfSmpolicycontrolCreate:

profile nf-client nf-type pcf

pcf-profile <>

locality LOC1

priority 1

service name type npcf-smpolicycontrol

endpoint-profile epprof

capacity   10

priority   1

uri-scheme http

endpoint-name ep1

priority 1

capacity 10

primary ip-address ipv4 <>

primary ip-address port <>

exit

endpoint-name ep2

priority 1

capacity 10

primary ip-address ipv4 <>

primary ip-address port <>

exit

PODs DNS principais e configuração necessária na camada SMI

Os pods CoreDNS, que fazem parte do namespace do sistema kube, são implantados como um conjunto de réplicas de 2 pods. Esses pods podem ser programados em qualquer um dos dois nós mestre/de controle e não dependem de onde o IP do servidor de nome está configurado no gerenciador de cluster.

No entanto, é recomendável configurar o IP do servidor de nome em todos os nós de controle/mestre, pois você não tem um controle de rotulação para girar os pods CoreDNS conforme seu desejo. Se a rota para servidores de nome não estiver presente em nenhum dos servidores mestre onde o CoreDNS está implantado, a sincronização do cluster SMF/AMF falhará.

Atualmente, o CoreDNS encaminha solicitações DNS para o servidor de nome especificado no arquivo resolv.conf do nó.

'kubectl edit configmap coredns -n kube-system' você tem:

{

forward ./etc/resolv.conf{

max_concurrent 1000

}

Ao verificar /etc/resolv.conf no nó mestre onde o serviço é iniciado, ele deve conter:

name server <>

name server <>

Exemplo de configuração de servidor de nome no nó mestre/controle:

nodes <>

initial-boot netplan vlans <>

dhcp4 false

dhcp6 false

addresses [<>]

nameserver addresses [<>]

id <>

link <>

exit