GTP-C Proxy: pools de PGW multivendor sem reconfigurar SGW e MME

Sobre a solução

Stingray GTP-C Proxy permite agrupar PGWs de diferentes fabricantes em pools comuns, distribuir os assinantes conforme as regras da operadora e gerenciar falhas sem alterar a configuração do SGW e do MME: basta apontar o APN para o proxy no DNS uma única vez.

A solução suporta GTPv1 e GTPv2, ajuda a evoluir a rede sem reconfigurar SGW e MME e preserva o estado das conexões quando o proxy é reiniciado.

Stingray GTP-C Proxy está registrado no Registro de Software Russo do Ministério do Desenvolvimento Digital

Por que a operadora precisa do GTP-C Proxy

PGWs de diferentes fabricantes na mesma rede

O GTP-C Proxy agrupa os gateways em pools comuns, gerenciados por regras unificadas. Não é preciso alterar a configuração existente do SGW e do MME.

Seleção de PGW conforme as regras da operadora

Os assinantes são direcionados aos gateways adequados por IMSI, MSISDN, APN, PLMN, tipo de acesso de rádio (RAT) e localização do assinante (ULI), bem como por suas combinações. Pesos dos pools e PGWs de reserva permitem ajustar a distribuição aos requisitos da rede.

Resposta a falhas sem comutação manual

Se um PGW falhar, o GTP-C Proxy o exclui do pool e direciona as novas conexões para PGWs operacionais com versão de GTP compatível. O estado das conexões é mantido no Redis, inclusive quando o próprio proxy é reiniciado.

Transições entre 2G/3G e LTE

O GTP-C Proxy suporta GTPv1 e GTPv2 e realiza a troca de versão do protocolo quando o assinante transita entre gerações de rede.

Como funciona o Stingray GTP-C Proxy

O GTP-C Proxy atua no plano de controle GTP-C entre SGW / SGSN e PGW. Para o SGW, o proxy se apresenta como um PGW; para o PGW, como um SGW. O DNS da operadora aponta o APN para o proxy, que seleciona o PGW de destino conforme as regras configuradas e encaminha a sinalização para ele.

O tráfego de usuário GTP-U flui diretamente entre SGW e PGW. O GTP-C Proxy não participa do caminho dos dados do usuário.

Com isso, a operadora ganha um nível adicional de controle sobre a seleção de PGW, mantendo a arquitetura existente da rede de acesso. A interação utiliza mensagens GTP padrão.

Solicite uma demonstração personalizada e um teste da solução

Escalabilidade

O desempenho cresce com o número de threads

Como a infraestrutura escala?

O GTP-C Proxy escala em três níveis: threads de processamento no servidor, instâncias do proxy e armazenamento de estado. Cada nível é expandido de forma independente.

Threads de processamento

A sinalização é processada por várias threads de trabalho vinculadas aos núcleos do processador. Em uma bancada de testes de nível industrial, o desempenho de processamento chega a 348 mil operações Modify Bearer por segundo em quatro núcleos.

Instâncias do proxy

Várias instâncias do GTP-C Proxy trabalham com armazenamento comum e regras de roteamento comuns. O estado das sessões é armazenado de forma centralizada, por isso a falha de uma instância não causa perda de conexões. A comutação entre instâncias é feita via BGP.

Armazenamento de estado

Um único servidor Redis suporta cerca de 105 mil Modify Bearer/s. Para cargas maiores, utiliza-se um cluster Redis com réplicas e failover automático em caso de falha do nó principal.

Regras sem reinicialização

Pools de PGW, pesos e regras de roteamento ficam em um único documento (arquivo YAML ou Redis) e são aplicados a todas as instâncias em tempo real, sem reinicialização e sem perda de sessões.

Tolerância a falhas

No máximo 2,03 s (tempo máximo de comutação em caso de falha do nó principal do Redis em teste sob carga)

Reinicialização do proxy

O estado é armazenado no Redis, por isso as conexões são preservadas.

Falha ou reinicialização do PGW

O PGW com falha é retirado do pool, e as novas conexões são direcionadas para PGWs operacionais com versão de GTP compatível. A reinicialização do PGW é detectada por mensagens Echo.

Reinicialização do SGW

As sessões são preservadas e restauradas conforme o procedimento do 3GPP TS 23.007 (seção 27).

Sobrecarga

Os assinantes ativos são atendidos com prioridade; novas conexões são rejeitadas.

Redundância de instâncias

Comutação entre instâncias do proxy via BGP.

Recursos do Stingray GTP-C Proxy

Protocolos e roteamento

GTPv2 em S5/S8 e GTPv1 em Gn/Gp.
Continuidade da sessão na transição entre 2G/3G e LTE.
Pools de PGWs de diferentes fabricantes.
Roteamento e redistribuição de novas conexões entre PGWs, substituição de parâmetros de sessão e relatórios de localização para S5/S8 e Gn/Gp.
Preservação das conexões na reinicialização do SGW conforme o TS 23.007, seção 27.

Confiabilidade, capacidade e gerenciamento

Desempenho de até 348 mil operações Modify Bearer por segundo em quatro threads.
Controle de carga e temporizador watchdog.
Interface web, Prometheus e Grafana.
Visualização de sessões e configuração de pools Gn/Gp na interface web.
Fornecido em pacotes RPM para VEOS 8.x e EL8.

Gerenciamento centralizado

Interface web

Sessões, histórico do documento de roteamento, status das instâncias e dos PGWs, perfis de administrador e observador.

Prometheus

Métricas de mensagens, transações, falhas, armazenamento e PGWs por versão de GTP.

Grafana

Painéis de monitoramento integrados com autenticação pela interface web.

Requisitos de implantação

Parâmetro	Requisitos
SO	VEOS 8.x ou EL8, x86_64; glibc 2.28, systemd 239
Fornecimento	Pacotes RPM gtpcproxy e gtpcproxy-web. Instalação, atualização e rollback via dnf
Virtualização	KVM ou VMware. Recomenda-se usar vCPUs dedicadas na proporção 1:1 com os núcleos físicos de um único nó NUMA
Rede	Buffer de recepção de sinalização de 8 MiB: CAP_NET_ADMIN ou net.core.rmem_max de no mínimo 8 MiB
Redis	O Redis deve responder sem pausas superiores a 250 ms (por exemplo, durante a migração ao vivo de uma VM). Recomenda-se migrar a máquina virtual com o Redis em uma janela de manutenção
CPU e memória	Para 348 mil Modify Bearer/s: 19 núcleos dedicados no total, dos quais 4 para processamento de sinalização
Contêiner	Podman (rootless)

Solicite uma demonstração gratuita do GTP-C Proxy

Entraremos em contato com você, especificaremos a tarefa, forneceremos acesso à documentação e responderemos às suas perguntas.

Discutiremos a situação atual: volume de tráfego, equipamento disponível, a funcionalidade de que você precisa.

Nossos engenheiros instalam o software selecionado e o adaptam às suas tarefas específicas. Contrato – somente após o teste ser bem-sucedido.

Nome *

E-mail *

Número de telefone *

Nome da empresa *

Comentários

Concordo com a Política de Privacidade e com o Contrato de Licença da VAS Experts

Soluções relacionadas

GTP-C Proxy

Sobre a solução

Stingray GTP-C Proxy está registrado no Registro de Software Russo do Ministério do Desenvolvimento Digital

Por que a operadora precisa do GTP-C Proxy

PGWs de diferentes fabricantes na mesma rede