BR102013030809A2 - ARCHITECTURE OF INTEGRATION AND CENTRALIZATION OF WLAN CONTROLLER Wi-Fi IN LENGTH OF LENGTH / 4G OF NON-3GPP ACCESS - Google Patents

Abstract

arquitetura de integração e centralização de controlador wlan wi-fi em cenário lte/4g de acesso não 3gpp que trata de modelo de referência de arquitetura baseado no padrão 3gpp com a centralização do controlador wlan wi-fi, expandindo desta forma a limitação de opção de arquitetura de uso do controlador dentro do padrão 3gpp, o qual especifica a integração da rede lte/4g com a rede de acesso wi-fi (acesso não 3gpp) com possibilidade de cenário para o controlador wlan wi-fi somente em arquitetura distribuída. a invenção trata de inclusão, alteração e integração de alguns protocolos e mensagens dentro da arquitetura de rede lte/4g conforme padrão 3gpp para wi-fi offload, e do padrão aberto capwap para controlador wlan, sendo que as alterações e inclusões a serem tratadas englobam os protocolos capwap, dtls, gtpv2-c, gtp-u, dsmipv6 e mipv6; e os elementos: acces point wifi (wtp) e gateway samog em cenário de acesso s2a; gateway para acesso dsmipv6 em cenário de acesso s2c; p-gw integrado com o controlador wlan. adicionalmente, o cenário de acesso s5 é atendido no caso de se ter terminal lte/4g integrado junto ao access point wi-fi. a partir das compatibilizações propostas pela presente invenção, é possível fazer uso do controlador wlan no cenário wi-fi offload (acesso lte/4g com opção de acesso wifi) de modo centralizado (e não distribuído, conforme estado da técnica) junto ao núcleo da rede lte/4g.

Description

ARQUITETURA DE INTEGRAÇÃO E CENTRALIZAÇÃO DE CONTROLADOR WLAN Wi-Fi EM CENÁRIO LTE/4G DE ACESSO NÃO 3GPP

Campo da Invenção: O presente relatório descritivo de Patente de Invenção se refere a uma arquitetura de integração e centralização do elemento controlador WLAN Wi-Fi, em um cenário LTE/4G de acesso não 3GPP confiável, junto ao núcleo da rede LTE/4G (P-GW) provendo acesso Wi-Fi Offload.

Acrônimos utilizados: AC - Access Controller CAPWAP - Control And Provisioning of Wireless Access Points DTLS - Datagram Transport Layer Security EMS - Element Management System EPC - Evolved Packet Core DSMIPvô - Dual Stack Mobile IP version 6 GTP - GPRS Tunneling Protocol IETF - Internet Engineering Task Force LTE - Long Term Evolution LMA - Local Mobility Anchor MAG - Mobile Access Gateway MIPv4 - Mobile IP version 4 NMS - NetWork Management System PANA - Protocol for carrying Authentication for Network Access P-GW - PDN Gateway ΡΜΙΡνβ - Proxy Mobile IP version 6 PSK - Pre Shared Key PKI - Public-Key Infrastructure RRM - Radio Resource Management SON - Self Organizing Network STA - Station UE - User Equipment WTP - Wireless Termination Point Antecedentes da Técnica: O elemento controlador WLAN (WLAN Controller, ou Wireless LAN Controller ou WLC), foi proposto como uma solução para controle e operação de um conjunto de Access Points Wi-Fi, sendo este elemento extremamente importante quando a rede tem uma quantidade consideravelmente grande de Access Points Wi-Fi.

Pensando em criar um padrão para este controlador, o IETF criou como padrão aberto o protocolo CAPWAP (RFC 5415) para o controlador WLAN, o qual é atualmente amplamente adotado em equipamentos comerciais.

Nos equipamentos comerciais existem as opções de operação no modo distribuído ou centralizado. No caso de operação no modo centralizado, é possível o controle de uma grande quantidade de Access Points Wi-Fi, e, por isso, é o modelo mais adequado para redes de Operadoras de Telecomunições, em que a redução de OPEX (Operational Expenditures, despesas operacionais) é um fator de grande relevância, e a centralização do controle dos elementos de rede atende a este requisito. A solução de controlador centralizado é implementada de forma mais usual em cenário não tratado pelo 3GPP, isto é, fora de uma rede celular móvel onde se tem os componentes de núcleo EPC centralizados. O padrão 3GPP inclui a integração da rede LTE/4G com a rede de acesso Wi-Fi (conforme padrão TS 23.402), que faz parte da rede genérica chamada de rede de acesso não 3GPP (non-3GPP) em arquitetura para aplicação Wi-Fi Offload, que permite o acesso do terminal (designado como UE no padrão 3GPP) à rede LTE/4G, e alternativamente à rede Wi-Fi, permitindo a mobilidade deste terminal entre estas duas opções de acesso (LTE/4G e Wi-Fi) sem a perda de conexão, e sem a necessidade de haver a reautenticação na entrada em cada uma destas redes de acesso.

Os documentos de Patente relacionados a seguir ilustram exemplos do estado da técnica para controlador WLAN utilizando protocolo CAPWAP. Já se conhece do estado da técnica diversos exemplos para controlador WLAN utilizando protocolo CAPWAP, como, por exemplo, no documento de patente EP2645765, relativo à “METHOD AND SYSTEM FOR IMPLEMENTING NETWORK MANAGEMENT BASE D ΟΝ THIN WIRELESS ACCESS POINT ARCHITECTURE”, pelo qual é proposto o gerenciamento SNMP utilizando CAPWAP, sem no entanto considerar o cenário de acesso não 3GPP confiável (Wi-Fi Offload). Já é conhecido também do estado da técnica o documento de Patente CN103036648, relativo à “CONTROL AND PROVISIONING OF WIRELESS ACCESS POINT (CAPWAP) MESSAGE PROCESSING METHOD AND PROCESSING DEVICE”, através do qual são propostas melhorias nas mensagens CAPWAP, porém também sem considerar o cenário de acesso não 3GPP confiável (Wi-Fi Offload). Já é conhecido também do estado da técnica o documento de Patente CN102958051, relativo à “CAPWAP (CONTROL AND PROVISIONING OF WIRELESS ACCESS POINTS) ARCHITECTURE ACCESS CONTROLLER AND KEY MANAGEMENT METHOD THEREOF”, através do qual é proposto o gerenciamento de chaves para autenticação do terminal utilizando padrão IEEE 802.11r (Fast BSS Transition). Já é conhecido também do estado da técnica o documento de Patente W02008034357, relativo à “METHOD AND SYSTEM FOR CAPWAP INTRADOMAIN AUTHENTICATION USING 802.11R”, o qual propõe o gerenciamento de chaves para autenticação do terminal utilizando padrão IEEE 802.11 r (Fast BSS Transition).

Os documentos de Patente relacionados a seguir ilustram exemplos do estado da técnica para acesso não 3GPP (Wi-Fi Offload). Já é conhecido também do estado da técnica o documento de Patente MX2012013658, relativo à “SYSTEM AND METHOD FOR WIRELESS NETWORK OFFLOADING”, que também propõe um método ou esquema de WiFi Offload, sem considerar o cenário com Controlador WLAN. Já é conhecido também do estado da técnica o documento de Patente WO2013126918, relativo à “WIRELESS SERVICES GATEWAY”, o qual propõe um Wireless Services Gateway (WSG) para acesso à rede através de WiFi ou via celular, sem considerar o cenário com Controlador WLAN. Já é conhecido também do estado da técnica o documento de Patente WO2012093349, relativo “LTE/WI-FI COEXISTENCE”, que propõe um terminal com coexistência de sistema LTE e sistema WiFi com estágio de RF comum.

Os documentos de Patente anteriores não consideram melhorias no cenário de acesso não 3GPP (Wi-Fi Offload) junto com uso de Controlador WLAN, o qual constitui o objetivo da presente invenção.

Objetivos da Invenção: A arquitetura de integração e centralização do elemento controlador WLAN Wi-Fi, em um cenário LTE/4G de acesso não 3GPP confiável, ora proposta, se constitui um modelo de referência de arquitetura baseado no padrão 3GPP, pelo qual é possível o uso do controlador WLAN, compatível com o padrão CAPWAP em cenário centralizado, junto ao núcleo da rede LTE/4G (EPC) em redes de acesso não 3GPP confiáveis para o controle de um grande número de Access Point Wi-Fi.

Adicionalmente, a invenção ora proposta prevê ainda o cenário com o equipamento terminal LTE/4G integrado junto ao Access Point Wi-Fi, para que este sirva como Hot Spot Wi-Fi utilizando o LTE/4G como backhaul.

Sumário da Invenção: O controle e a operação de um grande número de Access Points Wi-Fi, de forma individual, em redes de acesso Wi-Fi, se torna inviável devido principalmente ao requisito mandatório de baixo OPEX para este tipo de acesso. Para contornar esta deficiência, existem controladores WLAN Wi-Fi, que permitem o este controle e a operação de um grande número de Access Points Wi-Fi de forma centralizada, permitindo a realização de itens tais como: provisionamento, configuração, controle de versão, atualização de software de um único ponto. O padrão 3GPP inclui a possibilidade de integração da rede LTE/4G com a rede de acesso Wi-Fi (acesso não 3GPP), contudo, somente permite a inclusão do controlador WLAN Wi-Fi na forma distribuída sem a opção do uso deste elemento de forma centralizada. Contudo esse modelo distribuído não se adequa à arquitetura da rede de núcleo LTE/4G, na qual os componentes desta rede de núcleo EPC centralizam o controle e operação de uma quantidade de eNodeBs e terminais. O objeto da presente invenção, que é uma proposta de integração e centralização do controlador WLAN Wi-Fi em cenário LTE/4G de acesso não 3GPP, se refere à adoção de uma arquitetura que possibilite a integração do controlador WLAN Wi-Fi, não mais de forma distribuída, mas centralizada, junto ao núcleo da rede LTE/4G (EPC ou mais especificamente junto ao P-GW), para o cenário de acesso não 3GPP confiável, ou seja para aplicação de acesso Wi-Fi Offload.

As vantagens do controlador WLAN centralizado frente ao estado da técnica são: • Centralização do controle de um grande número de Access Points Wi-Fi; • Possibilidade de integração na gerência dos elementos Access Points Wi-Fi (EMS/NMS); • Possibilidade de integração funcional com RRM e SON; • Possibilidade de unificação das funcionalidades SON aplicáveis às redes de acesso LTE/4G e Wi-Fi; • Possibilidade de substituição de sistema com uso de padrões tal como o TR-069; • Possibilidade de obtenção de uma rede de acesso Wi-Fi escalável, sem restrições quanto ao crescimento da rede; • Possibilidade atendimento de um grande número de Access Points Wi-Fi pelo Gateway SaMOG; • Implementação de melhorias no gerenciamento com a centralização das informações; • Minimização de OPEX.

Em relação à proposta para centralização do controlador WLAN, têm-se as seguintes vantagens e características adicionais: • Uso de protocolo CAPWAP, que é padrão de mercado; • Alteração mínima (conforme descrito na descrição detalhada da invenção) na especificação do protocolo de comunicação CAPWAP; • Inexistência de perda das funcionalidades principais do protocolo CAPWAP; • Dispensa da necessidade de alteração (conforme descrito na descrição detalhada da invenção) na pilha de protocolos especificada para o cenário de acesso não 3GPP; • Inclusão da pilha de protocolos CAPWAP com DTLS nos elementos Gateway SaMOG e P-GW.

Descrição das Figuras: A Figura 1 representa um controlador WLAN em cenário não 3GPP, já conhecido no estado da técnica. A Figura 2 é uma réplica da Figura 6.1.1-1 da referência 3GPP TR 23.852 (mantidos os termos originais em inglês), que apresenta a arquitetura do cenário de acesso não 3GPP considerando a interface de referência S2a, conhecida no estado da técnica. A Figura 3 é uma réplica da Figura 4.2.2-2 da referência 3GPP TS 23.402 (mantidos os termos originais em inglês), que mostra a arquitetura do cenário de acesso não 3GPP considerando a interface de referência S2c, conhecida no estado da técnica.

A Figura 4 é uma réplica da Figura 8.2.3.1.4-1 da referência 3GPP TR 23.852 (mantidos os termos originais em inglês), que representa a pilha de protocolos GTPv2-C e GTP-U sobre a interface de referência S2a, conhecida no estado da técnica. A Figura 5 é uma réplica da Figura 6.1.2-1 da referência 3GPP TS 23.402 (mantidos os termos originais em inglês), que mostra a pilha de protocolo DSMIPv6 sobre a interface de referência S2c, conhecida no estado da técnica. A Figura 6 é uma réplica da Figura 5.1.2.1-1 da referência 3GPP TS 23.401 (mantidos os termos originais em inglês), que apresenta a pilha de protocolo GTP-U sobre a interface de referência S5, conhecida no estado da técnica.

A Figura 7 é uma réplica da Figura 8.2.9.2.2.1-1 da referência 3GPP TR 23.852 (mantidos os termos originais em inglês), que ilustra o fluxo de mensagens para attach inicial sobre a interface de referência S2a utilizando túnel GTP, conhecida no estado da técnica. A Figura 8 é uma réplica da Figura 6.3-1 da referência 3GPP TS 23.401 (mantidos os termos originais em inglês), que mostra um fluxo de mensagens para attach inicial sobre a interface de referência S2c utilizando túnel DSMIPv6, conhecida no estado da técnica. A Figura 9 apresenta as compatibilizações necessárias na interface de referência S2a para a formação dos túneis CAPWAP com DTLS, GTPv2-C e GTP-U, conforme proposta da presente invenção. A Figura 10 apresenta a compatibilização na pilha do protocolo GTP-C para o plano de controle na interface S2a (túnel 1) e a inclusão do túnel DTLS para as mensagens CAPWAP (túnel 2), conforme proposta da presente invenção. A Figura 11 apresenta as compatibilizações necessárias na interface de referência S2c para a formação dos túneis CAPWAP com DTLS, DSMIPv6 e MIPv6, conforme proposta da presente invenção. A Figura 12 apresenta a compatibilização na pilha do protocolo para o plano de controle na interface S2c, com a criação dos túneis 1 e 2 para a inclusão do DTLS, conforme proposta da presente invenção. A Figura 13 apresenta as compatibilizações necessárias na interface de referência S5 para a formação do túnel CAPWAP sobre GTP-U, conforme proposta da presente invenção. A Figura 14 apresenta a compatibilização na pilha do protocolo na interface S5 para inclusão do plano de controle do protocolo CAPWAP, conforme proposta da presente invenção.

Descrição Detalhada das Realizações da Invenção: Para melhor compreensão e contextualização da presente invenção, inicialmente será feita a descrição de aspectos principais de um controlador WLAN e dos padrões atuais aplicáveis ao dito controlador WLAN para acesso não 3GPP (Wi-Fi Offload). Desse modo, tornar-se-ão mais evidentes as diferenças entre a presente invenção e o atual estado da técnica.

Controlador WLAN em cenário não 3GPP (não Wi-Fi Offload) A Figura 1 apresenta a arquitetura com controlador WLAN no cenário não 3GPP. O controlador WLAN tem como protocolo CAPWAP, que é o padrão dominante de mercado, conforme especificações IETF RFC 5415 e RFC 5416, tendo, na especificação RFC 5415, as seguintes nomenclaturas para os elementos: AC - Controlador WLAN; WTP - Access Point Wi-Fi; e STA - Terminal Wi-Fi. As linhas tracejadas e numeradas (algarismos romanos I a IV) indicam as seguintes etapas: I. Estabelecimento da sessão DTLS entre WTP e AC; II. Autenticação WPA2 do Terminal (STA) feita pelo Plano de controle; III. Mensagens CAPWAP do Plano de controle; IV. Plano de dados do Terminal (STA). O protocolo CAPWAP é um padrão aberto, e engloba a especificação do protocolo de comunicação, entre o AC e o WTP (plano de controle), junto com a especificação da segurança desta comunicação, bem como a especificação de um conjunto de funcionalidades, realizadas dentro do elemento AC, de controle e operação remota de forma centralizada dos elementos WTP, que, por sua vez, realiza o controle dos terminais STA. Algumas destas funcionalidades básicas são: • Descoberta de AC; • Segurança; • Provisionamento do WTP; • Configuração do WTP; • Configuração da interface de RF do WTP: taxas, canal, potência, SSID; • Gerência EMS do elemento WTP; • Atualização de software do WTP; • Controle de sessão dos STAs; • Estatística de sessão dos STAs. O protocolo CAPWAP utiliza como segurança o protocolo DTLS (RFC 4347) para autenticação do WTP junto ao AC, bem como para a criação de túnel seguro entre estes (WTP e AC) no plano de controle, sendo que, para o plano de dados, esta segurança é opcional, sendo a opção mais comum para a autenticação o uso de certificados X.509, existindo outras mais simples tal como o uso de PSK, que adota chaves pré-compartilhadas armazenadas nos elementos.

As funções de autenticação, de associação e de dissociação do STA são compartilhadas entre o WTP e o AC, devendo haver comunicação entre o elemento AC e o servidor AAA, no caso de se utilizar WPA2/EAP, de acordo com o padrão IEEE 802.11 i (Advanced Encryption Standard).

Acesso não 3GPP confiável (Wi-Fi Offload) Cenários para acessos não 3GPP são diferenciados em confiável (trusted) e não confiável (un-trusted). Neste último caso (un-trusted), a rede de acesso é operada por terceiros fora do escopo de uma Operadora da rede LTE/4G, e sendo a gestão dos Access Points Wi-Fi realizada por terceiros, e não faz parte do escopo desta Operadora o controle dos Access Points Wi-Fi, e dos controladores WLAN correspondentes. Desse modo, a inclusão do elemento controlador WLAN centralizado, junto ao núcleo da rede LTE/4G, tem sentido e tem maior relevância para o cenário confiável, em ambiente de Operadora.

Na arquitetura considerando o acesso confiável, as interfaces definidas nos padrões importantes para o acesso não 3GPP são: S2a; STa; Gxa; Gx; e S6b. A arquitetura com os pontos de referência é apresentada na Figura 2. A mobilidade é tratada como uma questão importante para o offload entre as redes de acesso LTE/4G e a rede de acesso Wi-Fi, e a referência 3GPP TS 24.302 descreve as especificações da EPC em cenário de acesso não 3GPP, considerando a questão de mobilidade ou a função de offload entre as redes de acesso LTE/4G e Wi-Fi. A referência 3GPP TS 23.402 apresenta como uma das opções para este controle de mobilidade o protocolo GTP, tendo na referência 3GPP TR 23.852 um estudo detalhado da mobilidade sobre a interface S2a baseada em protocolo GTP (SaMOG). As referências 3GPP TS 29.274 e 3GPP TS 29.281 detalham os protocolos GTPv2-C (plano de controle) e GTP-U (plano de dados).

Além da mobilidade, outra questão importante para o acesso Wi-Fi nesta arquitetura seria a segurança, que é descrita nas referências 3GPP TS 29.273 (EPS AAA interfaces) e 3GPP TS 33.234 (WLAN interworking security).

Outro cenário previsto na referência 3GPP TS 24.302, considerando a mobilidade, é o uso do protocolo DSMIPv6, onde os acessos são baseados no ponto de referência S2c, conforme apresentado na Figura 3.

No caso do equipamento terminal LTE/4G integrado junto ao Access Point Wi-Fi, utiliza-se a interface S5, cujas especificações são descritas na referência 3GPPTS 23.401.

Resumindo, as interfaces consideradas de acesso Wi-Fi os quais fazem parte do escopo da realização da presente invenção são: S2a; S2c; e S5. Essas interfaces serão melhor detalhadas mais adiante.

Mobilidade com GTP e DSMIPv6 A interface S2a suporta o acesso do terminal (UE) à EPC, via rede de acesso Wi-Fi confiável, permitindo o encaminhamento do tráfego originado e terminado no UE através da entidade P-GW. Esta interface é baseada no protocolo GTP (3GPP TS 23.402; e TS 29.274) e não requer mudanças no UE. O modelo de túnel ou bearer suportado por esta interface para conectividade à PDN é similar ao suportado pela interface S5/S8 baseada no protocolo GTP (3GPP TS 23.401 e TS 29.274), onde cada bearer tem associado um conjunto de filtros de pacotes IP, permitindo que o tráfego de usuário (plano de dados) seja encaminhado ao bearer adequado, conforme as necessidades específicas de QoS. O mecanismo de filtragem é realizado no uplink e no downlink pelo UL TFT (Uplink Traffic Flow Template) e DL TFT (Downlink Traffic Flow Template), respectivamente.

Outra opção para acesso à EPC, via rede de acesso Wi-Fi confiável, é através da interface S2c, que é baseada no protocolo DSMIPv6 (3GPP TS 23.402) e requer que o UE suporte este protocolo. O DSMIPv6 cria um túnel entre o UE e a entidade PDN Gateway (P-GW) que é usado para encaminhar todo o tráfego terminado no UE e o tráfego originado pelo UE. Desta forma, a entidade P-GW tem completa visibilidade do tráfego de usuário e pode aplicar políticas de controle e tarifação da mesma maneira que o faz para sessões LTE.

Pilha de protocolos GTP e DSMIPv6 As pilhas de protocolos para os protocolos GTPv2-C e GTP-U sobre a interface de referência S2a são apresentadas na Figura 4. Na Figura 4, os seguintes termos e legendas devem ser observados: • 802.11: refere-se às camadas 1 e 2 (layer 1, layer 2 - ou L1, L2) definido por IEEE Std. 802.11-2007. A camada 2 do padrão 802.11 é usada como “attach trigger” e “detach trigger”. L2 “attach trigger” é obrigatório para PDN tipo IPv6 e IPv4v6, e opcional para PDN tipo IPv4. • L3 trigger: refere-se ao DHCPv4, que pode ser usado como um L3 “attach trigger” opcional em PDN tipo IPv4. • GTP-C: O Plano de controle do GPRS Tunneling Protocol consiste na sinalização de mensagens entre um elemento AC (controlador WLAN) em cenário confiável e um P-GW (PDN Gateway) via interface S2a, conforme definido no padrão TS 29.274.

• GTP-U: O Plano de dados do GPRS Tunneling Protocol estabelece um canal para os dados do usuário entre um elemento AC (controlador WLAN) em cenário confiável e um P-GW (PDN Gateway) via interface S2a, conforme definido no padrão TS 29.281. • UDP: (User Datagram Protocol) Este é o protocolo da camada de transporte sobre o qual tanto o GTP-C quanto o GTP-U são empilhados. • IPv4/IPv6: referem-se a protocolos de camada de rede. Em cenário WLAN confiável, inclui o encaminhamento de pacotes IP do plano de dados entre o UE (equipamento de usuário) link ponto-a-ponto e o túnel S2a para o UE. A pilha de protocolos para o protocolo DSMIPv6 sobre a interface de referência S2c é apresentada na Figura 5. A pilha de protocolos para o protocolo GTP-U sobre a interface de referência S5 é apresentada na Figura 6.

Fluxo de mensagens GTP e DSMIPv6 em cenário confiável As Figuras 7 e 8Eito! Fonte de referência não encontrada, apresentam OS fluXOS de mensagens para attach inicial sobre as interfaces de referência S2a e S2c respectivamente com a apresentação do processo de autenticação do UE e criação dos túneis GTP e PMIP.

Cenário atual para Controlador WLAN dentro do acesso não 3GPP O uso do controlador WLAN dentro da arquitetura de acesso não 3GPP (acesso Wi-Fi Offload) é possível somente no modo distribuído devido à forma como foram especificados os protocolos das interfaces apresentadas na arquitetura de acesso não 3GPP, ou seja S2a e S2c, bem como para o acesso 3GPP LTE/4G, através da interface S5.

Inclusão do Controlador centralizado WLAN em cenário de acesso não 3GPP confiável Offload O objetivo da presente invenção é a inclusão do controlador WLAN, apresentado na Figura 1, junto ao núcleo EPC da rede LTE/4G, mais especificamente, integrado ao elemento PDN Gateway (P-GW), presente nas arquiteturas apresentadas nas Figuras 2 e 3. Desta forma, o controlador se estabelece centralizado no núcleo da rede LTE/4G, podendo assim controlar e operar os Access Points Wi-Fi utilizando as interfaces S5, S2a e S2c. Esta arquitetura atende plenamente o cenário, por exemplo, de Operadoras de Telecom que possuem um núcleo de rede para uma extensa área regional. O uso da interface S5 se aplica quando se tem o elemento UE integrando a função de Access Point Wi-Fi, constituindo produto com função de Hot Spot Wi-Fi e com utilização de backhaul LTE/4G. A presente invenção elimina a dificuldade de operação do controlador WLAN distribuído no cenário de Wi-Fi Offload, e possibilita prover acesso LTE/4G, inclusive com opção de Wi-Fi, com controlador localizado junto ao núcleo da rede LTE/4G, compatibilizando o cenário de centralização da gestão da rede das Operadoras, e, para isto, engloba a inclusão, a alteração, e a integração de alguns protocolos e mensagens dentro da arquitetura de rede LTE/4G, de acordo com o padrão 3GPP para Wi-Fi Offload e com o padrão aberto CAPWAP para o controlador WLAN, e onde as alterações e inclusões englobam os protocolos CAPWAP, DTLS, GTPv2-C, GTP-U, DSMIPv6.

Materialização da Invenção: A arquitetura de integração e centralização do elemento controlador WLAN Wi-Fi, em um cenário LTE/4G de acesso não 3GPP, ora proposta, prevê compatibilizações (inclusão, alteração e integração) dos protocolos, que se desdobram em: • Modificações no protocolo CAPWAP; • Inclusão do protocolo e funcionalidades CAPWAP com DTLS no Gateway SaMOG; • Inclusão do protocolo e funcionalidades CAPWAP no elemento P-GW; • Integração do protocolo de comunicação CAPWAP na interface S5; • Especificação do protocolo CAPWAP para suporte ao DSMIPv6.

Estas compatibilizações estão associadas a cada uma das interfaces de acesso Wi-Fi (S2a, S2c) e à interface S5, conforme detalhamento a seguir.

Compatibilização na interface S2a: A Figura 9 apresenta as compatibilizações necessárias para a formação dos túneis CAPWAP com DTLS, GTPv2-C e GTP-U. Na Figura 9, as linhas tracejadas e numeradas (algarismos arábicos 9.1 a 9.5) indicam as seguintes etapas: 9.1) Estabelecimento da sessão DTLS entre WTP e Gateway SaMOG; 9.2) Estabelecimento da sessão DTLS entre WTP e AC; 9.3) Mensagens CAPWAP no plano de controle; 9.4) Autenticação 802.1x e attach do terminal STA (plano de controle); 9.5) Plano de dados do terminal (STA/UE).

Supondo que o WTP é compatível com o protocolo CAPWAP, os detalhes referentes à compatibilização nos elementos identificados nesta figura são: A. Inclusão do protocolo CAPWAP com DTLS dentro do Gateway SaMOG, tendo ainda: - Inclusão da funcionalidade de descoberta do protocolo CAPWAP, realizado entre o WTP e o Gateway SaMOG, e autenticação do túnel DTLS usando chaves pré-compartilhadas PSK; - Criação do túnel 1 DTLS permanente para o plano de controle de mensagens geradas pelo STA relativas à autenticação 802.1x da UE/STA e attach inicial, e mapeamento do túnel CAPWAP/DTLS em túneis GTPv2-C, por UE/STA; - Relay no Gateway SaMOG para protocolo CAPWAP com DTLS, para o plano de controle entre WTP e AC; - Criação do túnel 2 com alteração do protocolo CAPWAP/DTLS no WTP para que se trabalhe com dois túneis (túnel 1 e 2). B. Inclusão de pilha CAPWAP com DTLS no P-GW; Alteração no protocolo CAPWAP para o estabelecimento do túnel 2 sem a fase de descoberta; inclusão de interface de acesso à infraestrutura de PKI para autenticação do WTP; comunicação com AAA (diameter) para autenticação de terminal na interface S6b; e estabelecimento de QoS diferenciado para o túnel 2. C. Alteração no protocolo CAPWAP para o plano de dados escoar pelo túnel 3 GTP-U. A Figura 10 apresenta a compatibilização na pilha do protocolo GTP-C para o plano de controle na interface S2a (túnel 1) e a inclusão do túnel DTLS para as mensagens CAPWAP (túnel 2). Para o plano de dados, não há alteração para o protocolo GTP-U.

Com esta compatibilização na interface S2a, a seguinte sequência é realizada com a adição de um novo WTP e UE/STA na rede: Passo 1. Ao ligar o novo elemento WTP na rede, este vai realizar a descoberta do Gateway SaMOG e irá formar o túnel 1 (CAPWAP/DTLS) de forma permante enquanto WTP estiver em operação;

Passo 2. Após o estabelecimento do túnel 1, procede-se a criação do túnel 2, que neste caso o Gateway SaMOG realiza o relay destas mensagens e, com isto estabelece-se o canal no plano de controle para as mensagens CAPWAP;

Passo 3. O protocolo CAPWAP irá realizar o provisionamento de WTP utilizando o túnel 2 e após isto, este irá entrar em operação regular;

Passo 4. Ao UE/STA iniciar o processo de autenticação WPA2/EAP ou EAP-AKA junto ao WTP. Esta requisição caminha para o Gateway SaMOG e servidor AAA na interface STa utilizando protocolo diameter;

Passo 5. As demais etapas de autenticação são conforme o padrão 3GPP, apresentadas na Figura 7, com as mensagens do plano de controle caminhando pelo túnel 1 DTLS e o Gateway SaMOG realizando o mapeamento na interface S2a para um túnel GTPv2-C;

Passo 6. Após completar o attach, é criado o túnel 3 GTP-U por onde será encaminhado o plano de dados da UE/STA, sem uso de protocolo CAPWAP.

Como resultado desta compatibilização na interface S2a, têm-se as características; • Atendimento total às especificações da referencia TS 23.402 para o plano de controle e plano de dados assim, não havendo alterações nos processos e fluxos de mensagens; • Total compatibilidade com as funcionalidades e mensagens do protocolo CAPWAP; • Inclusão de funcionalidades e protocolo CAPWAP/DTLS nos elementos Gateway SaMOG e P-GW; • Alteração/adaptação na pilha de protocolos nos elementos Gateway SaMOG e P-GW; • Autenticação EAP-AKA do terminal UE/STA; • Compatibilidade com protocolo GTP-v2C e GTP-U na interface S2a.

Uma alternativa à criação do túnel 1 seria a utilização do protocolo PANA, conforme padrão IETF RFC 1591, neste caso elimina-se a necessidade do protocolo CAPWAP, pois as mensagens EAP trafegam direto na camada IP. Essa opção requer a inclusão do protocolo PANA, tanto no WTP como no Gateway SaMOG.

Compatibilização na interface S2c: A Figura 11 apresenta as compatibilizações necessárias na interface de referência S2c para a formação dos túneis CAPWAP com DTLS, DSMIPv6 e MIPv6, sendo que estas compatibilizações são as mesmas para o caso do uso de interface S2a, com pequena mudança no mecanismo de acesso do UE/STA, devido ao uso do protocolo DSMIPvõ.

Na Figura 11, as linhas tracejadas e numeradas (algarismos arábicos 11.1 a 11.6) indicam as seguintes etapas: 11.1) Estabelecimento da sessão DTLS entre WTP e Gateway SaMOG; 11.2) Estabelecimento da sessão DTLS entre WTP e AC; 11.3) Mensagens CAPWAP no plano de controle; 11.4) Autenticação 802.1x e attach do terminal STA (plano de controle); 11.5) Associação/Autenticação para mensagens DSMIPv6 entre UE/STA e P-GW; 11.6) Plano de dados do terminal (STA/UE).

Supondo que o WTP é compatível com o protocolo CAPWAP, os detalhes referentes à compatibilização e mudanças nos elementos identificados nesta figura são: A. Inclusão do protocolo CAPWAP com DTLS dentro do Gateway, tendo ainda: - Inclusão da funcionalidade de descoberta do protocolo CAPWAP realizado entre o WTP e o Gateway, e autenticação do túnel DTLS utilizando chaves pré-compartilhadas PSK; - Criação do túnel 1 DTLS permanente para o plano de controle de mensagens geradas pelo STA relativas à autenticação 802.1 x da UE/STA; - Relay no Gateway para protocolo CAPWAP com DTLS, para o plano de controle entre WTP e AC, e criação do túnel 2 com alteração (quais ?) do protocolo CAPWAP/DTLS no WTP; B. Inclusão de pilha CAPWAP com DTLS no P-GW; alteração no protocolo CAPWAP para o estabelecimento do túnel 2 sem a fase de descoberta; inclusão de interface de acesso à infraestrutura de PKI para autenticação do WTP, e estabelecimento de QoS diferenciado para o túnel 2; C. Suporte do WTP para comunicação das mensagens de associação/autenticação relativas ao DSMIPv6 entre UE/STA e P-GW (túnel 3), e D. Alteração no protocolo CAPWAP para o plano de dados escoar pelo túnel 4 MIPv6. A Figura 12 apresenta a compatibilização na pilha do protocolo para o plano de controle na interface S2c, com a criação dos túneis 1 e 2 para a inclusão do DTLS (autenticação 802.1 x do UE e para as mensagens CAPWAP). Para o plano de dados, não há alteração para o protocolo MIPv6.

Com esta compatibilização na interface S2c, a seguinte sequência é realizada com a adição de um novo WTP e UE/STA na rede: 1. Ao ligar o novo elemento WTP na rede, este vai realizar a descoberta do Gateway e irá formar o túnel 1 (CAPWAP/DTLS) de forma permante enquanto WTP estiver em operação; 2. Após o estabelecimento do túnel 1, procede-se a criação do túnel 2, que neste caso o Gateway realiza o relay destas mensagens e, com isto estabelece-se o canal no plano de controle para as mensagens CAPWAP; 3. O protocolo CAPWAP irá realizar o provisionamento de WTP utilizando o túnel 2 e após isto, este irá entrar em operação regular; 4. Ao UE/STA iniciar o processo de autenticação WPA2/EAP ou EAP-AKA junto ao WTP. Esta requisição caminha para o Gateway e servidor AAA na interface STa utilizando protocolo Diameter; 5. As demais etapas de autenticação são, conforme o padrão 3GPP, apresentadas na Figura 8, e a comunicação no plano de controle caminha pelo túnel 3 DSMIPv6; 6. Após completar o attach, é criado o túnel 4 ΡΜΙΡνδ por onde será encaminhado o plano de dados da UE/STA, sem uso de protocolo CAPWAP.

Como resultado desta compatibilização na interface S2c, se tem as seguintes características: • Atendimento total às especificações da referencia TS 23.402 para o plano de controle e plano de dados assim, não havendo alterações nos processos e fluxos de mensagens; • Total compatibilidade com as funcionalidades e mensagens do protocolo CAPWAP; • Inclusão de funcionalidades e protocolo CAPWAP/DTLS nos elementos Gateway e P-GW; • Alteração/adaptação na pilha de protocolos nos elementos Gateway e P- GW; • Autenticação EAP-AKA do terminal UE/STA; • Compatibilidade com protocolo DSM!Pv6/MIPv6 na interface S2c.

Uma alternativa à criação do túnel 1, seria a utilização do protocolo PANA conforme padrão IETF RFC 1591, e, neste caso elimina-se a necessidade do protocolo CAPWAP pois as mensagens EAP trafegam direto na camada IP, sendo que opção requer a inclusão do protocolo PANA, tanto no WTP como no Gateway.

Compatibilização na interface S5: A Figura 13 apresenta as compatibilizações necessárias à formação do túnel CAPWAP sobre GTP-U. Na Figura 13, as linhas tracejadas e numeradas (algarismos arábicos 13.1 a 13.3) indicam as seguintes etapas: 13.1. Mensagens CAPWAP no plano de controle do WTP; 13.2. Autenticação EAP do terminal STA (plano de controle); 13.3. Plano de dados do terminal (UE/STA).

Supondo que o WTP é compatível com o protocolo CAPWAP, os detalhes referentes à compatibilização nos elementos identificados nesta figura são: A. Inclusão do protocolo CAPWAP sem DTLS dentro dos elementos WTP/UE e P-GW; eliminação de funcionalidade de descoberta do AC; B. Encapsulamento de mensagens de controle geradas pelo STA relativas ao 802.1x em CAPWAP, encaminhamento para o túnel GTP-U (bearer 1) e comunicação com o AC; encapsulamento do plano de controle de mensagens CAPWAP dentro do protocolo GTP-U (bearer 1); comunicação com AAA (diameter) para autenticação de terminal na interface S6b, e estabelecimento de QoS diferenciado para o túnel GTP-U, e C. Alteração no protocolo CAPWAP para o plano de dados escoar pelo túnel GTP-U (bearer 2). A Figura 14 apresenta a compatibilização na pilha do protocolo na interface S5 para inclusão do plano de controle do protocolo CAPWAP. Para o plano de dados, não há alteração para o protocolo GTP-U. Com esta compatibilização na interface S5, a seguinte sequência é realizada com a adição de um novo WTP/UE e STA na rede: 1. Ao ligar o novo elemento WTP/UE na rede, este vai realizar o attach conforme especificação do padrão 3GPP e serão criados na interface S5 os bearers 1 e 2 relativos a túneis 1 e 2 GTP-U na interface S5; 2. Após attach inicial, a comunicação CAPWAP é estabelecida e é realizado o processo de provisionamento do componente Access Point (WTP) da UE através do bearer 1; 3. Ao STA iniciar o processo de autenticação WPA2/EAP junto ao WTP, esta requisição é encapsulada no protocolo CAPWAP e encaminhada ao bearer 1; 4. No elemento P-GW a requisição de autenticação EAP é direcionada para o servidor AAA na interface S6b utilizando protocolo Diameter; 5. Após a autenticação e associação do STA, o plano de dados deste é encaminhado ao bearer 2 sem uso do protocolo CAPWAP.

Como resultado desta compatibilização na interface S5, se tem as seguintes características: • Atendimento total às especificações da referencia 3GPP TS 23.401 para o plano de controle e plano de dado, e portanto não havendo alterações nos processos e fluxos de mensagens; • Eliminação da camada de tunelamento DTLS para o protocolo CAPWAP; • Total compatibilidade com as funcionalidades e mensagens do protocolo CAPWAP exceto a funcionalidade de descoberta;

• Inclusão de funcionalidades e protocolo CAPWAP nos elementos P-GW e UE; • Alteração/adaptação na pilha de protocolos no elemento P-GW; • Autenticação WPA2 do terminal STA; • Compatibilidade com os protocolos GTP-v2C e GTP-U na interface S5.

REIVINDICAÇÕES

Claims (6)

1. ARQUITETURA DE INTEGRAÇÃO E CENTRALIZAÇÃO DE CONTROLADOR WLAN Wi-Fi EM CENÁRIO LTE/4G DE ACESSO NÃO 3GPP, caracterizada por prever atuação centralizada para o controlador WLAN Wi-Fi junto ao núcleo da rede LTE/4G (P-GW) para o cenário de acesso não 3GPP (Wi-Fi Offload) confiável, pela inclusão, alteração e integração dos protocolos, onde se tem as modificações no protocolo CAPWAP; inclusão do protocolo e funcionalidades CAPWAP com DTLS no Gateway SaMOG; inclusão do protocolo e funcionalidades CAPWAP no elemento P-GW; integração do protocolo de comunicação CAPWAP na interface S5, e especificação do protocolo CAPWAP para suporte ao DSMIPv6, sendo estas compatibilizações associadas a cada uma das interfaces de acesso Wi-Fi, S2a, S2c, e à interface S5.

2. ARQUITETURA DE INTEGRAÇÃO E CENTRALIZAÇÃO DE CONTROLADOR WLAN Wi-Fi EM CENÁRIO LTE/4G DE ACESSO NÃO 3GPP (Wi-Fi Offload), de acordo com a reivindicação 1, caracterizada pelo fato de que, para a interface S2a, as compatibilizações necessárias à formação dos túneis CAPWAP com DTLS, GTPv2-C e GTP-U, supondo que o WTP é compatível com o protocolo CAPWAP, são: (A) inclusão do protocolo CAPWAP com DTLS dentro do Gateway SaMOG, tendo ainda: inclusão da funcionalidade de descoberta do protocolo CAPWAP, realizado entre o WTP e o Gateway SaMOG, e autenticação do túnel DTLS usando chaves pré-compartilhadas PSK; criação do túnel 1 DTLS permanente para o plano de controle de mensagens geradas pelo STA relativas à autenticação 802.1x da UE/STA e attach inicial, e mapeamento do túnel CAPWAP/DTLS em túneis GTPv2-C, por UE/STA; relay no Gateway SaMOG para protocolo CAPWAP com DTLS, para o plano de controle entre WTP e AC, e criação do túnel 2 com alteração do protocolo CAPWAP/DTLS no WTP; (B) inclusão de pilha CAPWAP com DTLS no P-GW; alteração no protocolo CAPWAP para o estabelecimento do túnel 2 sem a fase de descoberta; inclusão de interface de acesso à infraestrutura de PKI para autenticação do WTP; comunicação com AAA (diameter) para autenticação de terminal na interface S6b, e estabelecimento de QoS diferenciado para o túnel 2, e (C) alteração no protocolo CAPWAP para o plano de dados escoar pelo túnel 3 GTP-U.

3. ARQUITETURA DE INTEGRAÇÃO E CENTRALIZAÇÃO DE CONTROLADOR WLAN Wi-Fi EM CENÁRIO LTE/4G DE ACESSO NÃO 3GPP, de acordo com a reivindicação 2, caracterizada pelo fato de que, opcionalmente à criação do túnel 1, pode ser utilizado protocolo PANA, conforme padrão IETF RFC 1591, com a eliminação da necessidade do protocolo CAPWAP, e inclusão do protocolo PANA, tanto no WTP como no Gateway SaMOG.

4. ARQUITETURA DE INTEGRAÇÃO E CENTRALIZAÇÃO DE CONTROLADOR WLAN Wi-Fi EM CENÁRIO LTE/4G DE ACESSO NÃO 3GPP, de acordo com a reivindicação 1, caracterizada pelo fato de que, para a interface S2c, as compatibilizações necessárias à formação dos túneis CAPWAP com DTLS, DSMIPv6 e MIPv6, são as mesmas para o caso do uso de interface S2a, com mudança no mecanismo de acesso do UE/STA, devido ao uso do protocolo DSMIPv6, e, supondo que o WTP é compatível com o protocolo CAPWAP, são: (A) inclusão do protocolo CAPWAP com DTLS dentro do Gateway, tendo ainda: a inclusão da funcionalidade de descoberta do protocolo CAPWAP realizado entre o WTP e o Gateway, e autenticação do túnel DTLS utilizando chaves pré-compartilhadas PSK; criação do túnel 1 DTLS permanente para o plano de controle de mensagens geradas pelo STA relativas à autenticação 802.1x da UE/STA; relay no Gateway para protocolo CAPWAP com DTLS, para o plano de controle entre WTP e AC, e criação do túnel 2 com alteração do protocolo CAPWAP/DTLS no WTP; (B) inclusão de pilha CAPWAP com DTLS no P-GW; alteração no protocolo CAPWAP para o estabelecimento do túnel 2 sem a fase de descoberta; inclusão de interface de acesso à infraestrutura de PKI para autenticação do WTP, e estabelecimento de QoS diferenciado para o túnel 2; (C) suporte do WTP para comunicação das mensagens de associação/autenticação relativas ao DSMIPv6 entre UE/STA e P-GW (túnel 3), e (D) alteração no protocolo CAPWAP para o plano de dados escoar pelo túnel 4 MIPv6.

5. ARQUITETURA DE INTEGRAÇÃO E CENTRALIZAÇÃO DE CONTROLADOR WLAN Wi-Fi EM CENÁRIO LTE/4G DE ACESSO NÃO 3GPP, de acordo com a reivindicação 4, caracterizada pelo fato de que, opcionalmente à criação do túnel 1, pode ser utilizado o protocolo PANA conforme padrão IETF RFC 1591, com a eliminação da necessidade do protocolo CAPWAP, e inclusão do protocolo PANA, tanto no WTP como no Gateway.

6. ARQUITETURA DE INTEGRAÇÃO E CENTRALIZAÇÃO DE CONTROLADOR WLAN Wi-Fi EM CENÁRIO LTE/4G DE ACESSO NÃO 3GPP, de acordo com a reivindicação 1, caracterizada pelo fato de que, para a interface S5, as compatibilizações necessárias à formação do túnel CAPWAP sobre GTP-U, supondo que o WTP é compatível com o protocolo CAPWAP, são: (A) inclusão do protocolo CAPWAP sem DTLS dentro dos elementos WTP/UE e P-GW; eliminação de funcionalidade de descoberta do AC; (B) encapsulamento de mensagens de controle geradas pelo STA relativas ao 802.1x em CAPWAP, encaminhamento para o túnel GTP-U (bearer 1) e comunicação com o AC; encapsulamento do plano de controle de mensagens CAPWAP dentro do protocolo GTP-U (bearer 1); comunicação com AAA (diameter) para autenticação de terminal na interface S6b, e estabelecimento de QoS diferenciado para o túnel GTP-U, e (C) alteração no protocolo CAPWAP para o plano de dados escoar pelo túnel GTP-U (bearer 2).