Modos de Conexão, WLCP e Mobilidade

Visão Geral

Este guia explica os modos de conexão do TWAG, o Protocolo de Controle WLAN (WLCP) e o comportamento de transferência. Ele descreve o que o software OmniTWAG faz hoje. Também marca cada área que é parcial ou ainda não integrada, para que os operadores não planejem em torno de comportamentos que o código não executa.

O TWAG segue o modelo WLAN Confiável na Seção 16 do 3GPP TS 23.402. Para o plano de dados, autenticação e sinalização S2a que esses modos utilizam, veja:

• Arquitetura: plano de dados, ciclo de vida da sessão e interfaces
• Autenticação: EAP-AKA / EAP-AKA' e material de chave
• S2a GTP-C: Criar Sessão, Deletar Sessão e sinalização de bearer
• Sessões: a sessão autenticada e seu ciclo de vida de status
• Plano do Usuário: entrega GRE, GTP-U e DHCP
• Segredos Compartilhados RADIUS: breakout por AP e cobrança aplicada após a autenticação

Índice

• Visão Geral e Comparação de Modos
• Negociação de Modos
• Modo de Conexão Única Transparente (TSCM)
• Modo de Conexão Única (SCM)
• Modo de Múltiplas Conexões (MCM) e WLCP
• Transferência e Mobilidade
• Configuração
• Observabilidade
• Status da Implementação

Visão Geral e Comparação de Modos

O TWAG suporta três modos de conexão para um UE que acessa o EPC através de uma WLAN Confiável. O modo controla como o UE aprende seu endereço IP, se o UE pode sinalizar um APN e se o UE pode manter mais de uma conexão PDN.

Propriedade	TSCM	SCM	MCM
Código do modo	0	1	2
Nome completo	Modo de Conexão Única Transparente	Modo de Conexão Única	Modo de Múltiplas Conexões
Conexões PDN por UE	Uma	Uma	Muitas
Entrega de endereço IP	DHCP	EAP	EAP / WLCP
Seleção de APN sinalizada pelo UE	Não	Sim	Sim (por conexão)
Transferência com preservação de IP	Não	Sim	Sim
Bearers dedicados	Não	Sim	Sim
Protocolo de controle do UE	Nenhum	Nenhum	WLCP (TS 24.244)
UE ciente do S2a	Não	Sim	Sim

TSCM é o modo padrão. TSCM corresponde ao comportamento anterior à Release-12, onde o UE não sinaliza a rede. O TWAG seleciona o APN, cria uma conexão PDN e entrega o endereço IP alocado pelo PGW através do DHCP.

Os códigos de modo 0, 1 e 2 seguem o AVP TWAN-Connection-Mode no 3GPP TS 29.273.

Negociação de Modos

O modo de conexão é negociado durante a autenticação, na troca STa que transporta EAP. Veja Autenticação para o fluxo EAP em si. O design é:

1. O TWAG anuncia os modos que suporta ao servidor AAA. O conjunto anunciado vem da chave de configuração connection_modes.
2. O servidor AAA retorna o modo selecionado na resposta STa DEA, no AVP TWAN-Connection-Mode.
3. Se o servidor AAA não indicar um modo, o TWAG usa TSCM como padrão.

Se o servidor AAA selecionar um modo que o TWAG não suporta, o TWAG reverte. A ordem de fallback prefere TSCM, depois SCM, e por último MCM. O TWAG seleciona o primeiro modo suportado dessa ordem.

O TWAG lê o modo selecionado de qualquer uma dessas chaves na resposta AAA, na seguinte ordem: twan_connection_mode, TWAN-Connection-Mode, connection_mode ou Connection-Mode. O valor pode ser um código numérico (0/1/2) ou um átomo (:tscm/:scm/:mcm). Um valor não reconhecido padrão é TSCM.

No caminho STa, o STa DER anuncia o modo suportado preferido do TWAG no AVP TWAN-Connection-Mode. A leitura do STa DEA analisa o modo negociado e padrão para TSCM quando o DEA não transporta nenhum.

Status: o modo negociado não é aplicado no caminho da sessão ativa. O cliente STa (StaClient) anuncia o modo suportado no DER e lê o modo negociado do DEA. O módulo de modo de conexão está presente e testado unitariamente. No entanto, o caminho de autenticação de passagem STa não é o caminho de autenticação RADIUS ativo, e o cliente ativo nunca aplica o modo negociado: o ponto de entrada store_connection_mode não tem chamador no caminho de anexação, e o caminho de anexação e dados sempre se comporta como TSCM (IP através do DHCP, sem WLCP, sem transferência sinalizada pelo UE ou APN). Hoje, cada sessão ativa segue o caminho TSCM. Veja Status da Implementação.

Modo de Conexão Única Transparente (TSCM)

TSCM é o modo padrão e o comportamento que o caminho da sessão ativa executa hoje. O UE não sinaliza a rede. TSCM é descrito no ciclo de vida da sessão da Arquitetura e é resumido aqui.

No TSCM:

• O UE mantém uma conexão PDN.
• O TWAG seleciona o APN. O UE não pode solicitar um APN.
• O UE recebe seu endereço IP através do DHCP, servido pelo TWAG sobre o túnel GRE. Veja Plano do Usuário.
• Não há sinalização WLCP.
• Transferência com preservação de IP, bearers dedicados e seleção de APN sinalizada pelo UE não estão disponíveis.

O TWAG cria a sessão S2a automaticamente após a autenticação. Ele envia uma Solicitação de Criação de Sessão ao PGW com a flag de Indicação de Transferência limpa. Em seguida, pré-aloca o endereço IP atribuído pelo PGW em seu servidor DHCP para o endereço MAC do UE. Veja S2a GTP-C para os detalhes da Criação de Sessão e Sessões para a sessão resultante e seu ciclo de vida de status. A cobrança pela sessão, quando habilitada, segue através do Gy. Veja Cobrança Online (Gy).

Modo de Conexão Única (SCM)

SCM mantém uma única conexão PDN por UE, mas o UE está ciente do S2a. O SCM adiciona essas capacidades sobre o TSCM:

• O UE recebe seu endereço IP através do EAP, não do DHCP.
• O UE pode selecionar um APN não padrão.
• O UE mantém seu endereço IP durante a transferência de 3GPP para WLAN e de WLAN para 3GPP.
• O PGW pode criar bearers dedicados.

O módulo de modo de conexão relata essas capacidades do SCM. Ele classifica o SCM como um modo que entrega IP através do EAP, suporta transferência, suporta seleção de APN e suporta bearers dedicados.

Status: o SCM ainda não é um caminho de execução distinto. O modelo de capacidade para SCM existe, mas o código de estabelecimento de sessão ainda não ramifica no modo negociado. Um UE que o servidor AAA coloca no SCM ainda é servido através do caminho TSCM (PDN auto-criada, IP através do DHCP). Não confie em IP entregue por EAP ou seleção de APN sinalizada pelo UE para SCM nesta versão.

Modo de Múltiplas Conexões (MCM) e WLCP

O MCM permite que um UE mantenha várias conexões PDN ao mesmo tempo. O UE gerencia cada conexão com o Protocolo de Controle WLAN (WLCP), definido no 3GPP TS 24.244. Após a autenticação, o TWAG não cria automaticamente uma conexão PDN. Em vez disso, o UE envia Solicitações de Conexão PDN WLCP. O TWAG mapeia cada conexão PDN para uma sessão S2a GTP-C separada em direção ao PGW.

Transporte WLCP

O TWAG executa um servidor WLCP na porta UDP 2156, a porta padrão do WLCP. O servidor roteia cada pacote para um manipulador de sessão WLCP por UE, baseado na identidade do UE. O servidor mapeia o IP de origem do UE e a porta para a identidade após a autenticação.

Na produção, a sinalização WLCP é realizada sobre DTLS conforme a Seção 16.1.4A.3.1 do TS 23.402. O servidor atual lida apenas com a camada UDP simples. DTLS ainda não foi aplicado.

Formato da Mensagem WLCP

Cada mensagem WLCP tem um cabeçalho fixo, seguido por uma lista de Elementos de Informação (IEs).

Tipo de Mensagem (1 byte) | Comprimento (2 bytes) | ID da Transação (1 byte) | IEs...

Cada IE tem este formato:

Tipo de IE (1 byte) | Comprimento do IE (2 bytes) | Valor do IE (variável)

O campo Comprimento conta a mensagem completa, incluindo o cabeçalho de 4 bytes.

Tipos de Mensagens WLCP

Código	Mensagem	Direção	Propósito
0x01	Solicitação de Conexão PDN	UE para TWAG	Solicitar uma nova conexão PDN
0x02	Aceitação de Conexão PDN	TWAG para UE	Conexão criada, com IP / DNS / QoS
0x03	Rejeição de Conexão PDN	TWAG para UE	Conexão recusada, com uma causa
0x04	Solicitação de Desconexão PDN	UE para TWAG	Liberar uma conexão PDN
0x05	Aceitação de Desconexão PDN	TWAG para UE	Conexão liberada
0x06	Notificação de Dados de Downlink	TWAG para UE	Notificar o UE sobre dados de downlink pendentes

Elementos de Informação WLCP

Código	IE	Notas
0x01	APN	String do Nome do Ponto de Acesso
0x02	Tipo de PDN	1 IPv4, 2 IPv6, 3 IPv4v6
0x03	PCO	Opções de Configuração de Protocolo
0x04	Endereço PDN	Endereço IP alocado do UE (IPv4, IPv6 ou IPv4v6)
0x05	QoS do Bearer	Valores de QCI e MBR / GBR
0x06	TFT	Modelo de Fluxo de Tráfego
0x07	Causa	Valor da causa do resultado
0x08	ID do Bearer	Identidade do Bearer EPS (EBI)
0x09	Endereço DNS	Um ou mais endereços de servidor DNS

Valores de Causa WLCP

Código	Causa	Significado
0x10	request_accepted	Solicitação aceita
0x20	apn_not_allowed	APN não permitido para este UE
0x21	no_resources	Nenhum recurso disponível
0x22	unknown_apn	APN desconhecida
0x23	user_auth_failed	Falha na autenticação do usuário
0x24	network_failure	Falha na rede (por exemplo, falha no S2a)
0x25	pdn_type_not_supported	Tipo de PDN solicitado não suportado
0x30	request_rejected	Solicitação rejeitada

Configuração da Conexão PDN

Quando uma Solicitação de Conexão PDN chega, o manipulador de sessão WLCP realiza os seguintes passos:

1. Lê o APN, tipo de PDN e PCO da mensagem. Se o APN estiver ausente, usa internet. Se o tipo de PDN estiver ausente, usa IPv4.
2. Verifica se o APN é permitido. Veja allowed_apns em Configuração.
3. Se o UE não tiver um IMSI conhecido, rejeita a solicitação com a causa user_auth_failed.
4. Cria uma sessão S2a GTP-C em direção ao PGW para aquele APN, com tipo de RAT 3 (WLAN) e a flag de Indicação de Transferência limpa.
5. Em caso de sucesso, registra o túnel GTP-U e armazena a conexão PDN, com base no EBI. Em seguida, envia uma Aceitação de Conexão PDN com o endereço IP do UE e, quando presente, os servidores DNS, QoS do bearer e EBI.
6. Em caso de falha no S2a, envia uma Rejeição de Conexão PDN com a causa network_failure.

Desconexão da Conexão PDN

Quando uma Solicitação de Desconexão PDN chega, o manipulador encontra a conexão PDN pelo EBI. Se o EBI for desconhecido, responde com uma Rejeição de Conexão PDN e causa request_rejected. Se o EBI for conhecido, deleta a sessão S2a GTP-C, desregistra o túnel GTP-U, remove a conexão e responde com uma Aceitação de Desconexão PDN. Quando o UE não tiver mais conexões PDN, o manipulador de sessão WLCP para.

Se o PGW deletar um bearer, o manipulador remove a conexão PDN correspondente e libera o túnel GTP-U local. Ele não envia uma Deletar Sessão neste caso, porque o PGW já liberou o bearer.

Derivação de Chave WLCP

A chave WLCP K_WLCP protege a sinalização WLCP. Ela é derivada da Chave de Sessão Mestre (MSK) que a autenticação EAP produz. A derivação segue a Seção 6.2 e o Anexo A do 3GPP TS 33.402.

K_WLCP = HMAC-SHA-256(MSK, FC | P0 | L0)

FC = 0x21
P0 = endereço IP do TWAG (4 bytes para IPv4, 16 bytes para IPv6)
L0 = comprimento de P0 (2 bytes, big-endian)

A saída é de 32 bytes (256 bits). O TWAG vincula a chave ao seu pr��prio endereço IP através do parâmetro P0. Uma variante simplificada deriva a chave da MSK e de um rótulo fixo quando o IP do TWAG ainda não é conhecido.

Status: MCM e WLCP são parciais e não integrados. O codec WLCP, o servidor UDP WLCP, o manipulador de sessão por UE e a derivação de chave existem e são testados unitariamente. Eles não são iniciados pela aplicação e não são acionados pelo fluxo de autenticação. Os seguintes itens não estão implementados:

• Proteção DTLS para WLCP. Apenas UDP simples é tratado.
• Gerenciamento de bearer dedicado dentro do MCM. O codec transporta IEs de QoS e TFT, mas o manipulador não atua na criação de bearer dedicado iniciada pelo PGW.
• Transferência dentro do MCM.
• A mensagem de Notificação de Dados de Downlink é definida no codec, mas não é gerada pelo manipulador de sessão.

Trate o MCM como uma prévia. Não o habilite para UEs de produção.

Transferência e Mobilidade

O TWAG modela três cenários de mobilidade conforme o TS 23.402. Apenas a mobilidade inter-AP está ativa no caminho da sessão ativa hoje.

Transferência de 3GPP para WLAN

Quando um UE se move de LTE para WiFi, o TWAG deve manter a sessão IP existente. Para fazer isso, o TWAG envia uma Solicitação de Criação de Sessão com a flag de Indicação de Transferência (HI) definida. O PGW então preserva o endereço IP existente e o contexto do bearer, em vez de alocar um novo endereço. Veja S2a GTP-C para os detalhes da Criação de Sessão e do IE de Indicação.

A Solicitação de Criação de Sessão S2a suporta a flag de Indicação de Transferência. O manipulador de transferência pode rotear um evento de entrada de transferência para o processo cliente do UE com a flag de transferência definida.

Status: o caminho da sessão principal não define a flag de transferência. O estabelecimento automático de sessão sempre envia Criação de Sessão com a flag de Indicação de Transferência limpa. Como resultado, a preservação de IP na transferência de 3GPP para WLAN n��o é exercitada pelo caminho de anexação normal nesta versão.

Transferência de WLAN para 3GPP

Quando um UE se move de WiFi para LTE, o PGW envia uma Solicitação de Deletar Bearer. O valor da causa indica uma mudança de RAT. O TWAG trata esses valores de causa como uma transferência de mudança de RAT:

Código de Causa	Nome
4	RAT alterado (3GPP para não-3GPP)
5	desativação do ISR
10	Acesso alterado de não-3GPP para 3GPP

Em uma Deletar Bearer de mudança de RAT, o TWAG limpa a sessão WiFi localmente. Ele não envia uma Deletar Sessão GTP-C, porque o PGW já liberou o bearer. O UE mantém seu endereço IP no lado LTE.

Status: o manipulador de deletar-bearer não ramifica na causa hoje. O processo cliente do UE lida com uma Deletar Bearer do PGW executando a limpeza local e, em seguida, parando, para qualquer causa. A classificação de mudança de RAT existe como um auxiliar, mas o cliente não usa a causa para escolher um caminho de finalização diferente.

Mobilidade Inter-AP

Quando um UE se move entre APs WiFi dentro do mesmo TWAN, o túnel S2a GTP permanece ativo. O UE mantém a mesma identidade, mas chega com um NAS-IP-Address e Called-Station-Id diferentes. O TWAG atualiza os dados de rastreamento de AP no processo cliente do UE e não finaliza a sessão. Isso mantém o endereço IP do UE estável durante a mudança de AP.

A mobilidade inter-AP é o único caminho de mobilidade que o código da sessão ativa executa. Ele atualiza os campos do processo cliente do UE para NAS-IP e Called-Station-Id, e registra o novo AP no estado de rastreamento de AP. Veja Contabilidade por AP para os dados de rastreamento de AP.

Configuração

Modos de Conexão

Defina os modos que o TWAG anuncia com a chave connection_modes. O valor é uma lista de átomos de modo. O padrão é [:tscm].

config :omnitwag,
  # Modos de conexão que este TWAG anuncia ao servidor AAA.
  connection_modes: [:tscm, :scm]

Parâmetro	Tipo	Requerido	Padrão	Descrição
connection_modes	Lista	Não	[:tscm]	Modos que o TWAG anuncia. Use :tscm, :scm e :mcm. A ordem não importa. Os códigos anunciados são ordenados antes do uso.

Nota. O conjunto anunciado é lido pelo módulo de modo de conexão e o cliente STa envia o modo preferido no STa DER. O caminho da sessão RADIUS ativa ainda não age no modo negociado. Veja Status da Implementação. Mantenha o padrão [:tscm] para produção até que SCM e MCM sejam integrados.

Servidor WLCP (MCM)

As configurações do servidor WLCP estão sob a chave :wlcp. O servidor WLCP é relevante apenas para MCM.

config :omnitwag,
  wlcp: %{
    enabled: true,
    port: 2156,
    allowed_apns: :all
  }

Parâmetro	Tipo	Requerido	Padrão	Descrição
enabled	Booleano	Não	false	Habilitar o servidor WLCP. Deixe false a menos que você teste o MCM.
port	Inteiro	Não	2156	Porta UDP para WLCP. 2156 é a porta padrão do WLCP.
allowed_apns	Átomo ou Lista	Não	:all	Lista de permissão de APN para solicitações PDN WLCP. Use :all para permitir todos os APNs, ou uma lista de strings de APN, por exemplo, ["internet", "ims"]. Uma solicitação para um APN não na lista é rejeitada com a causa apn_not_allowed.

Nota. O servidor WLCP não é iniciado pelo supervisor da aplicação nesta versão. A chave enabled é definida para uso futuro.

Configuração Relacionada

O caminho de configuração da PDN do MCM reutiliza as configurações GTP para suas sessões S2a. Veja o resumo de configuração da Arquitetura para o bloco gtp, incluindo pgw_ip, local_ip, mcc e mnc.

Observabilidade

O servidor WLCP e os manipuladores de sessão emitem eventos de telemetria. Esses eventos alimentam o pipeline de métricas. Veja Métricas para o catálogo de métricas.

Evento de Telemetria	Emitido quando
[:wlcp, :packet, :received]	Um pacote WLCP chega. Transporta bytes.
[:wlcp, :packet, :malformed]	Um pacote falha ao decodificar.
[:wlcp, :packet, :unregistered]	Um pacote chega de um endereço de origem não mapeado.
[:wlcp, :pdn, :request]	Uma Solicitação de Conexão PDN é recebida.
[:wlcp, :pdn, :accept]	Uma conexão PDN é estabelecida.
[:wlcp, :pdn, :reject]	Uma conexão PDN é rejeitada. Transporta a causa.
[:wlcp, :pdn, :disconnect_request]	Uma Solicitação de Desconexão PDN é recebida.
[:wlcp, :pdn, :disconnect_accept]	Uma conexão PDN é liberada.
[:twag, :handover, :in]	Um evento de entrada de transferência de 3GPP para WLAN é roteado. Transporta source.
[:twag, :handover, :out]	Uma mudança de RAT de WLAN para 3GPP é tratada. Transporta cause.
[:twag, :handover, :ap_change]	Um evento de mobilidade inter-AP é tratado.

O servidor WLCP e os manipuladores de sessão também registram em nível de informação. Eles registram cada solicitação de conexão PDN, aceitação, rejeição e desconexão, com a identidade do UE, APN e EBI. O manipulador de transferência registra cada entrada de transferência, mudança de RAT e mudança de AP, com a identidade do UE.

Status da Implementação

Esta tabela resume o que está em execução no caminho da sessão ativa, o que existe, mas não está integrado, e o que não está implementado. Use-a para planejar em torno do comportamento real.

Recurso	Status
TSCM (padrão, PDN auto-criada, IP via DHCP)	Ativo
Mobilidade inter-AP (túnel S2a preservado)	Ativo
S2a Criar Sessão com flag de Indicação de Transferência	Suportado no codificador S2a, mas o caminho de anexação sempre limpa
Lógica de negociação de modo de conexão e fallback	Presente como um módulo, testado unitariamente
STa DER anuncia modos suportados	Conectado (STa DER transporta o TWAN-Connection-Mode preferido, além de SSID / BSSID)
STa DEA lê modo selecionado	Conectado (StaClient analisa o modo negociado, padrão para TSCM)
Modo negociado aplicado à sessão ativa	Não conectado (store_connection_mode não tem chamador no caminho de anexação)
SCM como um caminho de execução distinto (EAP IP, seleção de APN)	Não integrado (servido como TSCM)
Codec WLCP (todos os tipos de mensagem e IEs)	Presente, testado unitariamente
Servidor UDP WLCP e manipulador de sessão por UE	Presente, não iniciado pela aplicação
Derivação de chave WLCP (K_WLCP, FC=0x21)	Presente, testado unitariamente
MCM várias conexões PDN simultâneas	Presente no manipulador, não integrado de ponta a ponta
Proteção DTLS para WLCP	Não implementado (apenas UDP simples)
Gerenciamento de bearer dedicado no MCM	Não implementado
Geração de Notificação de Dados de Downlink WLCP	Não implementado (apenas codec)
Transferência no MCM	Não implementado
Preservação de IP de 3GPP para WLAN no caminho de anexação	Não exercitado (anexação limpa a flag HI)
Finalização de WLAN para 3GPP pela causa de mudança de RAT	Não ramificado (limpeza de deletar-bearer é independente da causa)