BR112014001861B1 - Método para implementar um protocolo de túnel de serviço geral de rádio por pacotes, e, sistema computacional em nuvem para gerenciar a implementação de um protocolo de túnel de serviço geral de rádio por pacotes - Google Patents

Abstract

IMPLEMENTAÇÃO DE UM NÚCLEO DE PACOTE 3G EM UM COMPUTADOR EM NUVEM COM DADOS DE FLUXO ABERTO E PLANOS DE CONTROLE. Trata-se de um método para implementar um protocolo de túnel (GTP) de serviço geral de rádio por pacotes (GPRS) em um núcleo de pacote (PC) de uma rede de terceira geração (3G) tendo uma arquitetura dividida onde um plano de controle do PC da rede 3G se encontra em um sistema computacional em nuvem, sendo que o sistema computacional em nuvem inclui um controlador, sendo que o controlador executa uma pluralidade de módulos de plano de controle, sedo que o plano de controle se comunica com o plano de dados do PC através de um protocolo de plano de controle, sendo que o plano de dados é implementado em uma pluralidade de elementos de rede da rede 3G configurando-se comutadores que implementam um plano de dados do SGSN e do GGSN e comutadores intermediários para estabelecer um primeiro e um segundo ponto final de túnel GTP.

Description

CAMPO DA INVENÇÃO

[001] As modalidades da invenção referem-se a um método e a um sistema para implementar um plano de controle de um núcleo de pacote de terceira geração em um sistema computacional em nuvem. De modo específico, as modalidades da invenção se referem ao uso do protocolo OpenFlow para implementar um controle de um plano de dados pelo plano de controle sendo executado em um sistema computacional em nuvem.

FUNDAMENTOS

[002] O sistema geral de rádio por pacotes (GPRS) consiste em um sistema que é usado para transmitir pacotes de Protocolo da Internet entre dispositivos de usuário, tais como telefones celulares e a Internet. O sistema GPRS inclui a rede de núcleo GPRS, que consiste em uma parte integrada do sistema global para comunicação móvel (GSM). Esses sistemas são amplamente utilizados por provedoras de rede de telefonia celular para habilitar serviços de telefonia celular em áreas grandes.

[003] O protocolo de tunelamento GPRS (GTP) consiste em um protocolo de comunicação importante utilizado dentro da rede de núcleo GPRS. GTP habilita dispositivos de usuário final (por exemplo, telefones celulares) em uma rede GSM para se mover de um local para outro enquanto continua conectado à Internet. Os dispositivos de usuário final são conectados à Internet através de um nó de suporte GPRS de porta de acesso (GGSN). O GGSN rastreia os dados do dispositivo de usuário final a partir do nó de suporte GPRS de serviço do dispositivo de usuário final (SGSN) que estiver manuseando a sessão originária a partir do dispositivo de usuário final.

[004] Utilizam-se três formas de GTP pela rede de núcleo GPRS. GTP-U é usado para transferir dados de usuário em túneis separados para cada contexto de protocolo de dados de pacote (PDP). GTP-C é usado dentro da rede de núcleo GPRS para sinalização entre GGSN e SGSN. GTP' é usado para transmitir dados de carregado a partir da Função de Dados de Carregamento (CDF) da rede GSM ou UMTS à função de porta de acesso de carregamento (CGF), que fornece informações de uso do dispositivo de usuário final necessárias a um sistema de cobrança. GTP' usa a mesma estrutura de mensagens que GTP-C e GTP-U. SUMÁRIO

[005] Método para implementar um protocolo de túnel (GTP) de serviço geral de rádio por pacotes (GPRS) em uni núcleo de pacote (PC) de uma rede de terceira geração (3G) tendo uma arquitetura dividida onde um plano de controle do PC da rede 3G se encontra em um sistema computacional em nuvem, sendo que o sistema computacional em nuvem inclui um controlador, sendo que o controlador serve para executar uma pluralidade de módulos de plano de controle, sendo que o plano de controle se comunica com o plano de dados do PC através de um protocolo de plano de controle, sendo que o plano de dados é implementado em uma pluralidade de elementos de rede da rede 3G, sendo que o método compreende as etapas de: receber uma solicitação pelo controlador para criar um túnel GTP no PC da rede 3G entre um nó de suporte GPRS de serviço (SGSN) e um nó de suporte GPRS de porta de acesso (GGSN) para uma sessão de assinante; configurada um comutador que implementa um plano de dados do SGSN, através do protocolo de controle, para encapsular e desencapsular pacotes da sessão de assinante e estabelecer um primeiro ponto final de túnel GTP; configurar pelo menos um comutador em uma rota do túnel GTP, através do protocolo de plano de controle, para encaminhar pacotes da sessão de assinante de acordo com o túnel GTP; e configurar um comutador que implementa um plano de dados do GGSN, através do protocolo de plano de controle, para encapsular e desencapsular os pacotes da sessão de assinante e estabelecer um segundo ponto final de túnel GTP.

[006] Sistema computacional em nuvem que serve para gerenciar a implementação de um protocolo de túnel (GTP) de serviço geral de rádio por pacotes (GPRS) em um núcleo de pacote (PC) de uma rede de terceira geração (3G) tendo uma arquitetura dividida onde um plano de controle do PC da rede 3G se encontra em um sistema computacional em nuvem, sendo que o plano de controle serve para se comunicar com um plano de dados do PC através de um protocolo de plano de controle, sendo que o plano de dados é implementado em uma pluralidade de elementos de rede da rede 3G, sendo que o sistema computacional em nuvem compreende: uma pluralidade de servidores em comunicação entre si e em comunicação com uma pluralidade de elementos de rede que implementam o plano de dados do PC, sendo que a pluralidade de servidores executa, sendo que um controlador é configurado para executar uma pluralidade de módulos de plano de controle que implementa o plano de controle do PC, sendo que cada módulo de plano de controle serve para proporcionar um conjunto de funções de plano de controle para gerenciar o plano de dados, sendo que o controlador é configurado para receber uma solicitação para criar um túnel GTP no PC da rede 3G entre um nó de suporte GPRS de serviço (SGSN) e um nó de suporte GPRS de porta de acesso (GGSN) para uma sessão de assinante, sendo que o controlador é configurado para configurar um comutador que implementa um plano de dados do SGSN, através do protocolo de plano de controle, para encapsular e desencapsular os pacotes da sessão de assinante e estabelecer um primeiro ponto final de túnel GTP, sendo que controlador é configurado para configurar pelo menos um comutador em uma rota do túnel GTP, através do protocolo de plano de controle, para encaminhar pacotes da sessão de assinante de acordo com o túnel GTP, e o controlador é configurado para configurar um comutador que implementa um plano de dados do GGSN, através do protocolo de plano de controle, para encapsular e desencapsular os pacotes da sessão de assinante e estabelecer um segundo ponto final de túnel GTP; um gerenciador de nuvem comunicativamente acoplado ao controlador, sendo que gerenciador de nuvem é configurado para gerenciar a execução da pluralidade de módulos de plano de controle do PC.

BREVE DESCRIÇÃO DOS DESENHOS

[007] A presente invenção é ilustrada a título de exemplo, e não a guisa de limitação, nas figuras dos desenhos em anexo em que referências numéricas similares indicam elementos similares. Deve-se notar que as referências diferentes a "uma" modalidade nesta revelação não são necessariamente à mesma modalidade, e tais referências significam pelo menos uma. Ademais, quando um recurso, estrutura ou característica particular for descrito em conexão a uma modalidade, sugere-se que esteja dentro do conhecimento de um indivíduo versado na técnica efetuar tal recurso, estrutura ou característica em conexão a outras modalidades sejam explicitamente descritas ou não.

[008] A Figura 1 é um diagrama de uma modalidade de uma rede exemplificadora com um comutador OpenFlow.

[009] A Figura 2 é um diagrama que ilustra uma modalidade dos conteúdos de uma entrada de tabela de fluxo.

[0010] A Figura 3 ilustra outra arquitetura exemplificadora que implementa OpenFlow.

[0011] A Figura 4 ilustra uma modalidade do processamento de pacotes através de um pipeline de processamento de pacote de comutação OpenFlow.

[0012] A Figura 5 é um fluxograma de uma modalidade do processo de correspondência de regra OpenFlow.

[0013] A Figura 6 é um diagrama dos campos, que um processo de correspondência pode utilizar para identificar as regras a serem aplicadas a um pacote.

[0014] As Figuras 7A e 7B são um fluxograma de uma modalidade de um processo para processamento de cabeçalho OpenFlow.

[0015] A Figura 8 é um diagrama de uma modalidade de um núcleo de pacote (PC) de terceira geração (3G).

[0016] A Figura 9 é um diagrama de uma modalidade dos campos de cabeçalho no cabeçalho de encapsulação GTP-U primário.A Figura 10 é um diagrama de uma modalidade de um sistema computacional em nuvem que fornece serviço a um conjunto de clientes.

[0017] A Figura 11 é um diagrama de outra modalidade de um sistema computacional em nuvem que mostra o processo de adicionar um novo caso de serviço ao VPC de um cliente.A Figura 12 é um diagrama de uma modalidade do PC 3G implementado no sistema computacional em nuvem.A Figura 13 é um fluxograma de uma modalidade de um processo para a operação básica da rede PC 3G.

[0018] A Figura 14 é um diagrama de uma modalidade de como o PC 3G no sistema computacional em nuvem habilita a companhia de serviços gerenciados a gerenciar múltiplas redes operadoras dentre uma única central de dados.

[0019] A Figura 15 é um diagrama de uma modalidade de um processo para troca de tráfego e roteamento diferencial de PC 3G para um tratamento de serviço especializado.A Figura 16 é um diagrama de uma modalidade da modificação de tabela de fluxo OpenFlow para roteamento TEID GTP.A Figura 17 é um diagrama da estrutura de uma fileira de tabela de fluxo.As Figuras 18A a 18C são fluxogramas de criação, modificação e deletação de sessão no PC 3G.A Figura 19 é um diagrama de uma modalidade de um fluxo de mensagem OpenFlow para o procedimento de solicitação de sessão de criação.A Figura 20 é um diagrama de uma modalidade da sequência de mensagem OpenFlow para o procedimento de solicitação de sessão de modificação.A Figura 21 é um diagrama de uma modalidade da sequência de mensagem OpenFlow para o procedimento de solicitação de sessão de deletação

DESCRIÇÃO DETALHADA

[0020] Na descrição a seguir, apresentam-se vários detalhes específicos. No entanto, compreende-se que as modalidades da invenção podem ser praticadas sem esses detalhes específicos. Em outros casos, circuitos, estruturas e técnicas bem conhecidos não foram mostrados em detalhes a fim de não encobrir a compreensão desta descrição. No entanto, avaliar-se-á, por um indivíduo versado na técnica, que a invenção pode ser praticada sem esses detalhes específicos. Os indivíduos com conhecimento comum na técnica, com as descrições incluídas, serão capazes de implementar uma funcionalidade apropriada sem uma experimentação indevida.

[0021] As operações dos diagramas de fluxo serão descritas com referência às modalidades exemplificadoras das Figuras 8, 10 a 12, 14, e 15. No entanto, deve-se compreender que as operações dos diagramas de fluxo podem ser realizadas pelas modalidades da invenção além daquelas discutidas com referência às Figuras 8, 10 a 12, 14, e 15, e as modalidades discutidas com referência às Figuras 8, 10 a 12, 14, e 15 podem realizar operações diferentes daquelas discutidas com referência aos diagramas de fluxo das Figuras 5, 7, 13, 18, 19, 20 e 21.

[0022] As técnicas mostradas nas figuras podem ser implementadas usando um código de dados armazenados e executados em um ou mais dispositivos eletrônicos (por exemplo, uma estação final, um elemento de rede, etc.). Esses dispositivos eletrônicos armazenam e comunicam (internamente e/ou com outros dispositivos eletrônicos através de em uma rede) um código e dados usando meios não-transitórios legíveis por máquina ou legíveis por computador, tais como meios de armazenamento não-transitórios legíveis por máquina ou legíveis por computador (por exemplo, discos magnéticos; discos ópticos; memória de acesso aleatório; memória somente para leitura; dispositivos de memória flash; e memória de alteração de fase). Além disso, esses dispositivos eletrônicos tipicamente incluem um conjunto de um ou mais processadores acoplados a um ou mais outros componentes, tais como um ou mais dispositivos de armazenamento, dispositivos de entrada/saída (por exemplo, um teclado, uma tela sensível ao toque, e/ou um monitor), e conexões de rede. O acoplamento do conjunto de processadores e outros componentes ocorre tipicamente através de um ou mais barramentos e pontes (também designados como controladores de barramento). Os dispositivos de armazenamento representam um ou mais meios de armazenamento não-transitórios legíveis por máquina ou legíveis por computador e meios de comunicação não-transitórios legíveis por máquina ou legíveis por computador. Logo, o dispositivo de armazenamento de um dado dispositivo eletrônico armazena, tipicamente, um código e/ou dados para execução no conjunto de um ou mais processadores de tal dispositivo eletrônico. Naturalmente, uma ou mais partes de uma modalidade da invenção podem ser implementadas usando diferentes combinações de software, firmware, e/ou hardware.

[0023] Conforme o uso em questão, um elemento de rede (por exemplo, um roteador, um comutador, uma ponte, etc.) é uma peça de equipamento de rede, incluindo hardware e software, que interconecta de modo comunicativo outro equipamento na rede (por exemplo, outros elementos de rede, estações finais, etc.). Alguns elementos de rede são "elementos de rede de múltiplos serviços" que proporcionam suporte a múltiplas funções de rede (por exemplo, roteamento, transição, comutação, agregação de Camada 2, controle de fronteira de sessão, difusão múltipla, e/ou gerenciamento de assinante), e/ou proporcionam suporte a múltiplos serviços de aplicativo (por exemplo, dados, voz, e vídeo). As estações finais de assinante (por exemplo, servidores, estações de trabalho, laptops, palmtops, telefones móveis, smartphones, telefones multimídia, telefones de Protocolo de Voz sobre Internet (VOIP), reprodutores de midia portátil, unidades GPS, sistemas de jogos, decodificadores (STBs), etc.) acessam os conteúdos/serviços proporcionados pela Internet e/ou os conteúdos/serviços proporcionados em redes privadas virtuais (VPNs) sobrepostas à Internet. Os conteúdos e/ou serviços são tipicamente proporcionados por uma ou mais estações finais (por exemplo, estações finais de servidor) pertencentes a uma provedora de serviços ou conteúdos ou estações finais que participam de um serviço ponto a ponto, e podem incluir páginas da web públicas (conteúdo gratuito, fachadas de lojas, serviços de busca, etc.), páginas da web privadas (por exemplo, páginas da web acessadas por nome de usuário/senha que fornecem serviços de email, etc.), redes coorporativas por VPNs, IPTV, etc. Tipicamente, as estações finais de assinante são acopladas (por exemplo, através de um equipamento de premissa de consumidor acoplado a uma rede de acesso (com ou sem fio)) a elementos de rede de borda, que são acoplados (por exemplo, através de um ou mais elementos de rede de núcleo a outros elementos de rede de borda) a outras estações finais (por exemplo. estações finais de servidor).As modalidades da presente invenção proporcionam um método e um sistema para evitar as desvantagens da técnica anterior. As desvantagens da técnica anterior são aquelas implementações anteriores do núcleo de pacote que usa um pool de servidores que são dedicados a uma entidade de rede específica, tal como um pool de servidor que seja dedicado para hospedar um SGSN. Quando demandas de sinalização adicionais requererem uma capacidade extraordinária, então, um novo caso SGSN é instanciado no pool de servidor. No entanto, quando a demanda for alta para os serviços do servidor de assinante doméstico (HSS), o pool de servidor dedicado aos servidores HSS será expressivamente utilizado, porém, o pool de servidor para o SGSN é subutilizado. Estes pools de servidor subutilizados continuam a requerer manutenção e a agregar gastos operacionais, mas não estão proporcionando um desempenho ótimo para o operador de rede.

[0024] Em algumas situações, as companhias de serviços gerenciados constroem e executam redes de operadora móvel, enquanto a própria operadora móvel lida com as relações de marketing, cobrança, e consumidor. O tráfego de sinalização e dados para cada rede de operadora móvel é mantido privado e isolado do tráfego de suas concorrentes, apensar de sua rede e as redes de suas concorrentes poderem ser gerenciadas pela mesma companhia de serviços gerenciados. A companhia de serviços gerenciados deve manter um pool de servidor completamente separado e uma rede de sinalização física para cada operadora móvel que esta suporta. Como resultado, há uma grande duplicação de recursos e uma subutilização da capacidade do servidor. Isto aumenta os gastos operacionais para as companhias de serviços gerenciados e para a rede de operadora móvel devido às exigências adicionais de equipamento, energia e resfriamento.

[0025] A arquitetura de núcleo de pacote 3G conforme atualmente definida permite somente um ponto de presença (PoP) entre o núcleo fixo da operadora móvel/Internet e a rede de agregação móvel, ou seja, existe um único nó de suporte GPRS de porta de acesso (GGSN). As operadoras de rede móvel não podem ajustar múltiplos pontos de troca de tráfego e os PoPs entre as operadoras vizinhas dentro da rede de agregação. Isto reduziria a quantidade de tráfego que flui na rede de núcleo de operadora móvel, reduzindo, assim, a necessidade por atualizações de rede de núcleo caras e demoradas. Além disso, os pontos de troca de tráfego geralmente não têm custos às operadoras desde que os acordos de nível de serviço (SLA)s seja observados. No entanto, esta flexibilidade de implantação está indisponível às operadoras móveis devido à necessidade de ancorar seu PoP ao núcleo Internet em um único porta de acesso móvel.

[0026] A arquitetura de PC 3G também contém pouca flexibilidade para tratamento especializado de fluxos de usuários. Embora a arquitetura proporcione suporte para estabelecer qualidade de serviço (QoS), outros tipos de gerenciamento de dados não estão disponíveis. Por exemplo, serviços que envolvem middleboxes, tal como inspeção profunda de pacote especializada ou interação com recursos de armazenamento em cache e processamento de dados locais que podem ser utilizados para transcodificação ou aplicações de realidade aumentada são difíceis de suportar com a arquitetura de PC 3G atual. Quase todas as aplicações requerem que fluxos de pacote saiam através do GGSN, sendo, assim, 3G a partir de GTP, e a serem processados dentro da rede cabeada.

[0027] Implementar o plano de controle de um PC 3G em uma instalação de computação em nuvem e o plano de dados do PC 3G usando um conjunto de comutadores OpenFlow, nem como gerenciar a comunicação entre o plano de controle e o plano de dados usando o protocolo OpenFlow (por exemplo, OpenFlow 1.1) cria um problema que o protocolo OpenFlow não suporta GTP ou um roteamento de identificador de ponto final de túnel GTP (TEID), que é necessário para implementar o plano de dados do PC 3G

[0028] As modalidades da invenção superam essas desvantagens da técnica anterior. As desvantagens da técnica anterior são evitadas dividindo-se o plano de controle e o plano de dados para a arquitetura de PC 3G e para implementar o plano de controle implantando-se as entidades de plano de controle de PC 3G em uma instalação de computação em nuvem, enquanto o plano de dados é implementado por uma coleção distribuída de comutadores OpenFlow. O protocolo OpenFlow é usado para conectar os dois, com aprimoramentos para suportar um roteamento GTP. Embora a arquitetura de PC 3G já tenha uma divisão entre o plano de controle e o plano de dados, no sentido de que o SSGN e o GGSN são, primariamente, entidades de plano de dados enquanto o registro de localização doméstica (HLR), o servidor de assinante doméstico (HSS) e a central de autenticação (AUC) são, primariamente, entidades de plano de controle, esta divisão foi feita no nível do protocolo de gerenciamento de mobilidade, GTP.

[0029] A arquitetura de PC 3G padrão assume uma rede IP roteada padrão para transporte além daquela na qual as entidades e protocolos de rede móvel são implementadas. A arquitetura de PC 3G aprimorada descrita no presente documento é contrária ao nível de roteamento de IP e comutação de controle de acesso de midia (MAC). Ao invés de usar um roteamento L2 e protocolos de porta de acesso interno L3 para distribuir um roteamento de IP e gerenciar o roteamento de Ethernet

[0030] IP como uma coleção de entidades de controle distribuídas, o gerenciamento de roteamento L2 e L3 é centralizado em uma instalação de nuvem e o roteamento é controlado a partir da instalação de nuvem usando o protocolo OpenFlow. Conforme uso em questão, o "protocolo OpenFlow" se refere ao protocolo de rede OpenFlow à especificação de comutação definida na OpenFlow Switch Specification em www.openflowswitch.org um site da web hospedado pela Universidade de Stanford. Conforme o uso em questão, um "comutador OpenFlow" se refere a um elemento de rede que implementa o protocolo OpenFlow.

[0031] As entidades de plano de controle PC 3G padrão HSS, HLR, AUC, registro de localização de visitante (VLR), registro de identidade de equipamento (EIR), central de mensagem de entrelaçamento de serviço de mensagens curtas (SMS-IWMSC), central de mensagem de porta de acesso SMS (SMS-GMSC) e função de localização de assinante (SLF) e os aspetos de plano de controle do SGSN e GGSN são implantados na nuvem. O plano de dados consiste em comutadores OpenFlow padrão com aprimoramentos conforme necessário para rotear pacotes GTP, ao invés de roteadores de IP e comutadores Ethernet. No mínimo, as partes de plano de dados do SGSN e GGSN e a parte de roteamento de pacote do NodeB no E-UTRAN requerem aprimoramentos OpenFlow para um roteamento GTP. Aprimoramentos adicionais para um roteamento GTP podem ser necessários em outros comutadores dentro da arquitetura de PC 3G dependendo de quão compacto é o controle sobre o roteamento um operador requer. Os aprimoramentos para um roteamento GTP incluem processos para estabelecer túneis GTP, modificar túneis GTP e destruir túneis GTP dentro da arquitetura de PC 3G.

[0032] A divisão entre o controle e as partes de plano de dados do PC 3G pode ser usada junto a uma tecnologia de nuvem privada virtual (VPC) para implementar múltiplos PoPs dentro de um único PC 3G, proporcionar um roteamento de fluxo específico GTP para aplicações especializadas, e executar múltiplas redes operadoras a partir de uma única instalação de computação em nuvem.

[0033] Em uma modalidade, o sistema PC 3G baseado em nuvem pode ser implementado como um conjunto de dispositivos de hardware. Em outra modalidade, os componentes de sistema são implementados em software (por exemplo, microcódigo, linguagem de montagem ou linguagens de nível superior). Essas implementações de software podem ser armazenadas em um meio não-transitório legível por computador. Um meio não-transitório "legível por computador" pode incluir qualquer meio que possa armazenar informações. Exemplos do meio não-transitório legível por computador incluem uma memória somente para leitura (ROM), um disquete flexível, um CD Rom, um DVD, uma memória flash, um disco rígido, um disco óptico ou um meio similar. Redes OpenFlow 1.0

[0034] A Figura 1 é um diagrama de uma modalidade de uma rede exemplificadora com um comutador OpenFlow, conformando-se à especificação OpenFlow 1.0. O protocolo OpenFlow 1.0 habilita um controlador 101 a se conectar a um comutador habilitado para OpenFlow 1.0 109 usando um canal seguro 103 e controlar uma única tabela de encaminhamento 107 no comutador 109. o controlador 101 é um componente de software externo executado por um dispositivo computacional remoto que habilita um usuário a configurar o comutador OpenFlow 1.0 109. O canal seguro 103 pode ser proporcionado por qualquer tipo de rede, incluindo uma rede de área local (LAN) ou uma rede de área ampliada (WAN), tal como a Internet.

[0035] A Figura 2 é um diagrama que ilustra uma modalidade dos conteúdos de uma entrada de tabela de fluxo. A tabela de encaminhamento 107 é populada com entradas que consistem em uma regra 201 que define correspondências para campos em cabeçalhos de pacote; uma ação 203 associada à correspondência de fluxo; e uma coleção de estatísticas 205 sobre o fluxo. Quando um pacote de entrada for recebido, realiza-se uma pesquisa para uma regra de correspondência na tabela de fluxo 107. Se o pacote de entrada corresponder a uma regra particular, a ação associada definida em tal entrada de tabela de fluxo é realizada no pacote.

[0036] Uma regra 201 contém campos chave de vários cabeçalhos na pilha de protocolo, por exemplo, endereços de MAC Ethernet de origem e destino, endereços de IP de origem e destino, número de tipo de protocolo de IP, números de porta TCP ou UDP de entrada e saída. Para definir um fluxo, todos os campos de correspondência disponíveis podem ser usados. Porém, também é possível restringir a regra de correspondência a um subconjunto de campos disponíveis utilizando-se curingas para campos indesejados.

[0037] As ações que são definidas pela especificação de OpenFlow 1.0 são Drop, que abandona os pacotes de correspondência; Forward, que encaminha o pacote a urna ou a todas as portas de saída, a própria porta física de entrada, o controlador através do canal seguro, ou a pilha de rede local (caso exista). As unidades de dados de protocolo OpenFlow 1.0 (PDUs) são definidas com um conjunto de estruturas especificado usando a linguagem de programação C. Algumas das mensagens mais comumente usadas são: reportar uma mensagem de configuração de comutador; modificar as mensagens de estado (incluindo uma mensagem de entrada de fluxo de modificação e uma mensagem de modificação de porta); ler mensagens de estado, enquanto o sistema estiver rodando, a trajetória de dados pode ser questionada sobre seu estado atual usando esta mensagem; e enviar uma mensagem de pacote, que é usada quando o controlador desejar enviar um pacote através da trajetória de dados.OpenFlow 1.0 suporta "extensões de fornecedor" que permite que determinados elementos de protocolo sejam estendidos. As mensagens de protocolo e as ações de tabela podem ser estendidas, mas as regras de correspondência de fluxo não podem. O uso dessas extensões em conexão à arquitetura EPC baseada em nuvem será discutido mais adiante. Redes OpenFlow 1.1

[0038] A Figura 3 ilustra outra arquitetura exemplificadora que implementa OpenFlow, conformando-se à especificação OpenFlow 1.1. Nesta modalidade, há provisão explícita por múltiplas tabelas de fluxo 301. Isto permite que o pipeline de processamento de pacote se misture e corresponda a regras e ações particulares sem causar uma explosão combinatória no tamanho da tabela. Por exemplo, uma tabela de fluxo pode realizar um processamento QoS enquanto uma segunda tabela de fluxo realiza um roteamento.

[0039] A Figura 4 ilustra uma modalidade do processamento de pacotes através de um pipeline de processamento de pacote comutado OpenFlow 1.1. Um pacote recebido é comparado a cada uma das tabelas de fluxo 401. Após cada tabela de fluxo corresponder, as ações são acumuladas em um conjunto de ação. Se o processamento requerer uma correspondência a outra tabela de fluxo, as ações na regra correspondida incluem uma ação que direciona o processamento à próxima tabela no pipeline. Ausente a inclusão de unia ação no conjunto para executar todas as ações acumuladas imediatamente, as ações são executadas na extremidade 403 do pipeline de processamento de pacote. Uma ação permite a gravação de dados a um registrador de metadados, que é transportado no pipeline de processamento de pacote como o cabeçalho de pacote.

[0040] A Figura 5 é um fluxograma de uma modalidade do processo de correspondência de regra OpenFlow 1.1. OpenFlow 1.1 contém suporte à marcação de pacote. OpenFlow 1.1 permite uma correspondência com base em campos de cabeçalho e rótulos de comutação de rótulos multiprotocolo (MPLS). Um rótulo LAN virtual (VLAN) e um rótulo MPLS podem ser correspondidos por tabela. O processo de correspondência de regra é iniciado com a chegada de um pacote a ser processado (Bloco 501). Iniciando-se na primeira tabela 0, realiza-se uma pesquisa para determinar uma correspondência com o pacote recebido (Bloco 503). Não há correspondências nesta tabela, então, uma entre um conjunto de ações default é adotada (isto é, enviar o pacote ao controlador, abandonar o pacote ou continuar à próxima tabela) (Bloco 509). Se houver uma correspondência, então, uma atualização ao conjunto de ações é feita junto aos contadores, campos de conjunto de pacotes ou correspondências e metadados (Bloco 505). Realiza-se uma verificação para determinar a próxima tabela a processar, que pode ser a próxima tabela sequencialmente ou uma especificada por uma ação de uma regra de correspondência (Bloco 507). Uma vez que todas as tabelas tiverem sido processadas, então, o conjunto de ações resultante é executado (Bloco 511).

[0041] A Figura 6 é um diagrama dos campos, que um processo de correspondência pode utilizar para identificar regras para aplicar a um pacote. Ações permitem a manipulação de pilhas de tag colocando-se e tirando-se rótulos. Combinadas com múltiplas tabelas, as pilhas de rótulo VLAN ou MPLS podem ser processadas correspondendo-se um rótulo por tabela.

[0042] A Figura 7 é um fluxograma de uma modalidade de um processo de análise de cabeçalho. O processo de análise corresponde um cabeçalho de pacote inicializando-se um conjunto de campos de correspondência (Bloco 701) e verificando-se a presença de um conjunto de diferentes tipos de cabeçalho. O processo verifica um tag VLAN (Bloco 703). Se o tag VLAN estiver presente, então, existe unia série de etapas de processamento para o tag VLAN (Blocos 705 a 707). Se o comutador suportar MPLS (Bloco 709), então, existe uma série de etapas para detectar e processar as informações de cabeçalho MPLS (Blocos 711 a 715). Se o comutador suportar um protocolo de resolução de endereço (ARP), então, existe uma série de etapas para processar o cabeçalho ARP (Blocos 719 e 721). Se o pacote tiver um cabeçalho de IP (Bloco 723), então, existe uma série de etapas para processar o cabeçalho de IP (Blocos 725 a 733). Este processo é realizado para cada pacote recebido.

[0043] Em uma modalidade, uma tabela de grupo pode ser suportada em conjunto com o protocolo OpenFlow 1.1. As tabelas de grupo habilitam um método para permitir que uma única correspondência de fluxo dispare o encaminhamento em múltiplas portas. As entradas de tabela de grupo consistem em quatro campos: um identificador de grupo, que consiste em um inteiro sem sinal de 32 bit que identifica o grupo; um tipo de grupo que determinar a semântica do grupo; contadores que mantêm estatísticas sobre o grupo; e uma lista de bucket de ação, que consiste em uma lista ordenada de buckets de ação, onde cada bucket contém um conjunto de ações para executar junto a seus parâmetros.

[0044] Existem quatro tipos diferentes de grupos: All, que executam todas as ações na lista de bucket, este é usado para encaminhamento por radiodifusão ou difusão múltipla; Select, que executa um bucket por pacote, com base em um algoritmo determinado pelo comutador que esteja fora do protocolo OpenFlow, que é usado para implementar um encaminhamento em múltiplas trajetórias; Indirect, que executa o único bucket em todos os pacotes, este permite que múltiplos fluxos ou grupos apontem para uma única coleção de ações ao invés de ter as ações definidas em múltiplas entrada de tabela de encaminhamento; Fast Failover, que executar o primeiro bucket ao vivo, onde cada bucket está associado a uma porta que controla sua capacidade de estar ao vivo, este permite que o comutador realize um failover a outra porta sem envolver o controlador.

[0045] OpenFlow 1.1 pode ser utilizado para suportar portas virtuais. Uma porta virtual, conforme o uso em questão, é um "bloco de ação" que realiza algum tipo de ação de processamento além de simplesmente encaminhar o pacote a uma conexão de rede como as portas físicas fazem. Exemplos de algumas portas virtuais embutidas incluem: ALL, que encaminha a porta a todas as portas exceto pela porta de ingresso e quaisquer portas que estejam marcadas "Não encaminhar;" CONTROLLER, que encapsula o pacote e o envia ao controlador; TABLE, que insere o pacote no pipeline de processamento de pacote submetendo-o à primeira tabela de fluxo, esta ação é válida somente no conjunto de ação de uma mensagem embalada externa; e IN_PORT, que envia o pacote à porta de ingresso. Em outras modalidades, também podem existir portas virtuais definidas comutadas.

[0046] Arquitetura PC 3GA Figura 8 é um diagrama de uma modalidade de uma rede de núcleo de pacote 3G (PC 3G). Uma rede de PC 3G consiste em três domínios de interação: uma rede de núcleo (CN) 801, uma rede de acesso via rádio (RAN) 803 e um Equipamento de Usuário (UE) 805. O equipamento de usuário 805 pode ser um dispositivo computacional, um telefone celular e dispositivos similares. As redes de acesso via rádio 803 podem ser uma série ou uma combinação de redes incluindo um sistema de telecomunicações móvel universal (UMTS) 841 ou sistemas globais para redes de comunicações móveis (GSM) 843. Essas redes podem fazer interface com a rede de núcleo 801 através de uma central de rede via rádio (RNC) 831 ou uma unidade de controle de pacote (PCU) 833.

[0047] A função principal da rede de núcleo 801 consiste em proporcionar comutação, roteamento e trânsito ao tráfego de usuário a partir do equipamento de usuário 805. A rede de núcleo 801 também contém bancos de dados e funções de gerenciamento de rede. Esta é a rede de núcleo de pacote comum para GSM/GPRS, acesso múltiplo por divisão de código em banda larga (WCDMA)/ acesso de pacote em alta velocidade (HSPA) e redes móveis não-3GPP. A rede de núcleo 801 é usada para transmitir pacotes de Protocolo de Internet (IP). A rede de núcleo 801 faz interface com a Internet 851 e outras redes 853 através do GGSN 819.

[0048] A rede de núcleo 801 é dividida em domínios comutados por circuito e comutados por pacote. Os elementos comutados por circuito incluem uma central de comutação de serviços móveis (MSC) 811, um registro de localização de visitante (VLR) 813 e um Porta de acesso MSC 815. Os elementos comutados por pacote são SGSNs 817 e GGSN 819. Outros elementos de rede, como EIR 821, HLR 823, VLR 813 e AUC 825 são compartilhados por ambos os domínios.

[0049] A arquitetura da rede de núcleo 801 pode se alterar quando novos serviços e recursos forem introduzidos. Em outras modalidades, pode-se usar uma série de bancos de dados de portabilidade (NPDB) para habilitar um usuário a trocar redes enquanto mantém um número de telefone antigo. Um registro de localização de porta de acesso (GLR) pode ser usado para otimizar a manipulação de assinante entre os limites de rede.

[0050] As funções primárias da rede de núcleo 801 em relação à rede sem fio móvel são o gerenciamento de mobilidade e o QoS. Essas funções não são tipicamente proporcionadas em uma rede de banda larga fixa, mas são cruciais para redes sem fio. O gerenciamento de mobilidade é necessário para garantir uma conectividade de rede de pacote quando um terminal sem fio se mover de uma estação de base para outra. QoS é necessário porque, diferentemente das redes fixas, o link sem fio é severamente constrito em quanta largura de banda este pode proporcionar ao terminal, logo, a largura de banda precisa ser gerenciada mais rigidamente do que em redes fixas a fim de proporcionar ao usuário uma qualidade aceitável de serviço.

[0051] A sinalização para implementar as funções de gerenciamento de mobilidade e QoS é proporcionada pelo Protocolo de Tunelamento GPRS (GTP). GTP tem dois componentes: GTP-C - um protocolo de plano de controle que suporta o estabelecimento de túneis para gerenciamento de mobilidade e portadores para gerenciamento de QoS que correspondem o canal de transporte de retorno com fio canal de transporte de retorno e o núcleo de pacote QoS a um link de rádio QoS; e GTP-U - um protocolo de plano de dados usado para implementar túneis entre os elementos de rede que atuam como roteadores. Existem duas versões de protocolo GTP-C, isto é, versão GTP 1 (GTPv1-C e GTPv1-U) e versão GTP 2-C (projetada para LTE). GTPv1 é primariamente utilizada em conjunto com o sistema baseado em PC 3G sistema.

[0052] Os Serviços de Rede são considerados como sendo fim-a-fim , isto significa de um Equipamento de Terminal (TE) para outro TE. Um Serviço Fim-a-Fim pode ter uma determinada Qualidade de Serviço (QoS) que é proporcionada para o usuário de um serviço de rede. É o usuário que decide se ele está satisfeito com a QoS fornecida ou não. Para realizar um determinado Serviço QoS de rede com características e funcionalidade claramente definidos, este deve ser ajustado a partir da origem até o destino de um serviço.Além dos parâmetros QoS, cada portador tem um túnel GTP associado. Um túnel GTP consiste em um endereço de IP dos nós de ponto final de túnel (estação de base de rádio, SGSN, e GGSN), uma porta UDP de origem e destino, e um Identificador de Ponto final de Túnel (TEID). Os túneis GTP são unidirecionais, logo, cada portador está associado a dois TEIDs, urna para o túnel de enlace ascendente e um para o túnel de enlace descendente. Um conjunto de túneis GTP (enlace ascendente e enlace descendente) se estende entre a estação de base de rádio e o SGSN e um conjunto se estende entre o SGSN e o GGSN. O número de porta de destino UDP para GTP-U é 2152 enquanto o número de porta de destino para GTP-C é 2123. O número de porta de origem é dinamicamente alocado pelo nó de envio. A Figura 9 é um diagrama de uma modalidade dos campos de cabeçalho no cabeçalho de encapsulação GTP-U primário.

[0053] Computação em NuvemAs centrais de dados oferecem recursos de computação, armazenamento, e comunicação de rede aos consumidores externos. Os serviços oferecidos podem consistir em processamento elástico de imediato, armazenamento que para a maioria dos propósitos práticos se limita somente pela capacidade de o consumidor pagar, e largura de banda de rede na Internet. Este conjunto de serviços proporcionados por uma central de dados é referido no presente documento computação em nuvem.

[0054] A tecnologia de virtualização de servidor permite que um pool de servidores seja gerenciado como essencialmente um recurso de computação grande. Uma camada de software denominada como um hipervisor se encontra entre o sistema operacional e o hardware. O hipervisor agenda a execução de máquinas virtuais (VMs). Uma VM é uma imagem de sistema operacional embalada com alguns aplicativos. O hipervisor permite que uma VM seja suspensa e movida entre os servidores para um equilíbrio de carga. O equilíbrio e monitoramento de carga de execução de VM para capturar panes proporciona o mesmo tipo de tolerância a falhas e serviços de escalabilidade para aplicações empresariais que são alcançadas em custos muito maiores com soluções especializadas. Um sistema de gerenciador de nuvem inspeciona a execução de VMs, o agendamento de execução para satisfazer a demanda das VMs e a otimização da utilização de servidor e a minimização de consumo de energia. O gerenciador de nuvem ou sistema operacional em nuvem é um programa de software que pode agendar execução para permitir uma atualização em serviço de hardware e software sem impactar no provisionamento de serviços em andamento ás VMs e suas aplicações no sistema computacional em nuvem.

[0055] Para suportar o movimento arbitrário de VMs entre máquinas, a rede dentro da central de dados também deve ser virtualizada. Os sistemas computacionais em nuvem podem virtualizar a rede incorporando-se um comutador virtual no hipervisor. O comutador virtual proporciona portas de rede virtual às VMs que executam sob o controle do hipervisor. O software de comutador virtual também permite que os recursos de rede sejam virtualizados de maneira similar a como os recursos de servidor são virtualizados pelo hipervisor. O hipervisor e o comutador virtual podem, assim, cooperar para permitir que as VMs sejam movidas entre os servidores. Quando o hipervisor mover uma VM, ele se comunica com o comutador virtual sobre a nova localização, e o comutador virtual garante que as tabelas de roteamento de rede para os endereços de VM (endereço MAC L2, potencialmente também o endereço de IP) sejam atualizadas, logo, os pacotes são roteados à nova localização.

[0056] Um sistema computacional em nuvem pode ser composto por qualquer número de dispositivos computacionais tendo qualquer faixa de capacidades (por exemplo, energia de processamento ou capacidade de armazenamento). O sistema computacional em nuvem pode ser um sistema privado ou público. Os dispositivos computacionais podem estar em comunicação entre si através de qualquer sistema ou rede de comunicação. Um sistema computacional em nuvem pode suportar uma única nuvem ou serviço ou qualquer número de nuvens ou serviços discretos. Os serviços, aplicativos ou programas similares podem ser virtualizados ou executados como um código padrão. Em uma modalidade, os sistemas computacionais em nuvem podem suportar aplicativos de serviços da web. Os aplicativos de serviços da web consistem em um front-end de equilíbrio de carga que despacha solicitações a um pool de servidores da Web. As solicitações se originam a partir dos aplicativos em máquinas remotas na Internet e, portanto, os requerimentos de segurança e privacidade são muito mais livres do que para aplicativos em uma rede coorporativa privada.

[0057] Os sistemas computacionais em nuvem também podem suportar multitenancy seguro, em que o provedor de sistema computacional em nuvem oferece conexões tipo rede privada virtual (VPN) entre as redes de escritório distribuídas de cliente fora da nuvem e uma VPN dentro do sistema computacional em nuvem. Isto permite que os aplicativos do cliente dentro do sistema computacional em nuvem operem em um ambiente de rede que se assemelhe a um WAN coorporativo. Para centrais de dados privadas, em que os serviços são somente oferecidos a consumidores dentro da corporação proprietária da central de dados, os requerimentos de segurança e privacidade para multitenancy são relaxados. Porém, para centrais de dados públicas, o operador de nuvem deve garantir que o tráfego de múltiplos locatários seja isolado e não haja possibilidade de tráfego de um cliente para alcançar outra rede cliente.

[0058] A Figura 10 é um diagrama de uma modalidade de um sistema computacional em nuvem que prestar serviço a um conjunto de clientes. Um 'conjunto,' conforme o uso em questão, se refere a qualquer número inteiro positivo de itens. Na modalidade, mostrada na Figura 10, duas nuvens privadas virtuais (VPCs) são configuradas para dois consumidores empresariais externos diferentes. Uma VPC consiste em uma coleção de VMs, armazenamento, e recursos de rede que proporciona um multitenancy seguro às empresas que alugam o espaço na nuvem. Os consumidores empresariais se conectam nas VPCs através das VPNs pela Internet rodando em uma rede de operador público.

[0059] A Figura 11 é um diagrama de outra modalidade de um sistema computacional em nuvem que mostra o processo de adicionar um novo caso de serviço a uma VPC de cliente. Neste caso, a VPN em nuvem é implementada usando LANs Virtuais de camada MAC (VLANs). A VM é criada em um servidor gerenciado por hipervisor na VPC para a empresa que solicita o novo caso de serviço (etapa 1). O VLAN de comutador virtual é configurado para incluir a VM nova na VPN em nuvem empresarial, estabelecendo, assim, uma conectividade de serviço dentro da nuvem (etapa 2). O roteador de borda de consumidor virtual (CE) é atualizado para o novo serviço (etapa 3). O roteador de borda de provedor na rede de operador onde a VPN empresarial é rodada é atualizado com o novo serviço (etapa 4). Implementação de PC 3G em um Sistema Computacional em Nuvem

[0060] A Figura 12 é um diagrama de uma modalidade do EPC implementado no sistema computacional em nuvem. As entidades de plano de controle de PC 3G (AUC, HLR, HSS) 1207 e as partes de plano de controle dos nós de suporte (SGSN, GGSN) 1207, isto é, as partes que manuseiam a sinalização de GTP, são implementadas no sistema computacional em nuvem 1201 como parte do controlador OpenFlow 1205. As entidades de plano de controle 1207 e o controlador OpenFlow 1205 são embalados como VMs. A interface de programação de aplicativos (API) entre o controlador OpenFlow 1205 e as entidades de plano de controle 1207 pode ser uma interface chamada de procedimento remoto (RPC) ou uma interface similar. Esta tecnologia de implementação é favorável ao gerencialmente escalonável das entidades de plano de controle dentro da nuvem, visto que permite a execução das entidades de plano de controle 1207 e que o controlador 1205 seja gerenciado separadamente de acordo com a demanda. O gerenciador de nuvem 1203 pode ser uma VM ou um aplicativo executado dentro do sistema computacional em nuvem 1201.

[0061] O gerenciador de nuvem 1203 monitora a utilização da unidade de processador central (CPU) das entidades de plano de controle de PC 3G 1207 e o tráfego de plano de controle entre as entidades de plano de controle de PC 3G 1207 dentro da nuvem. Este também monitora o tráfego de plano de controle entre os dispositivos de usuário final (UEs) 1225 e os NodeBs 1217, que não tenham entidades de plano de controle no sistema computacional em nuvem 1201, e as entidades de plano de controle de PC 3G 1207. Se as entidades de plano de controle de PC 3G 1207 começar a exibir sinais de sobrecarga , tal como a utilização de muito tempo de CPU, ou o enfileiramento de muito tráfego a ser processado, a entidade de plano de controle sobrecarregada 1207 solicita que o gerenciador de nuvem 1203 inicie uma nova VM para manusear a carga . Adicionalmente, as próprias entidades de plano de controle de PC 3G 1207 podem lançar notificações ao gerenciador de nuvem 1203 se detectarem internamente que estão começando a experimentar uma sobrecarga.

[0062] O gerenciador de nuvem 1203 também proporciona confiabilidade e failover reiniciando-se uma VM para uma entidade de plano de controle particular 1207 ou função se qualquer uma das entidades de plano de controle de PC 3G 1207 entrar em pane. Durante este processo de reinicialização, o gerenciador de nuvem pode coletar dados de diagnósticos, salvar quaisquer arquivos de núcleo da entidade de plano de controle de PC 3G falha, e informar aos administradores do sistema que ocorreu uma falha. As entidades de plano de controle 1207 mantêm a mesma interface de protocolo entre elas conforme na arquitetura de PC 3G 3GPP mostrada na Figura 8.

[0063] O plano de controle OpenFlow 12321, mostrado como uma linha pontilhada, gerencia a configuração de roteamento e comutação na rede. O plano de controle OpenFlow 1221 conecta o sistema computacional em nuvem 1203 ao SGSN-Ds 1215 (isto é, o plano de dados do SGSN), os comutadores OpenFlow padrão 1213, e o GGSN-D 1211 (isto é, o plano de dados do GGSN). A implementação física do plano de controle OpenFlow 1221 pode ser corno uma rede física completamente separada, ou pode ser uma rede virtual rodando na mesma rede física que o plano de dados, implementado com uma VLAN priorizada ou com uma trajetória comutada de rótulo MPLS ou mesmo com uma encapsulação de roteamento genérica (GRE) ou outro túnel de IR O plano de controle OpenFlow 1221 pode, em princípio, usar as mesmas trajetórias físicas de plano de controle que o GTP-C e outra sinalização de rede móvel. O SGSN-Ds 1215 e o GGSN-Ds 1211 atuam como porta de acessos estendidos de GTP OpenFlow , sendo que os pacotes de encapsulação e desencapsulação usam as extensões de comutador GTP OpenFlow descritas mais adiante no presente documento.Os NodeBs 1217 não têm entidades de plano de controle na nuvem porque a sinalização de rede de acesso via rádio (RAN) requerida entre o PC 3G e o NodeB inclui parâmetros de rádio, e não apenas parâmetros de roteamento de IP. Portanto, não existe uma conexão de plano de controle OpenFlow 1221 entre o controlador OpenFlow 1205 no sistema computacional em nuvem 1201 e os NodeBs 1217. No entanto, os NodeBs 1217 podem agir como porta de acessos estendidos de GTP OpenFlow implementando-se um controle local à conexão de plano de dados usando OpenFlow. Isto permite que o lado de comutação de pacote dos NodeBs 1217 utilize as mesmas extensões de comutação GTP OpenFlow como os porta de acessos de pacote.

[0064] A operação do sistema computacional em nuvem de PC 3G funciona da seguinte forma . UE 1225, NodeB 1217, SGSN 1207 e o sinal GGSN 1207 ao HLR, HSS, AUC, SMS-GMSC 1207 usando os protocolos de PC 3G padrão, para estabelecer , modificar, e deletar túneis GTP. Esta sinalização dispara chamadas de procedimento com o controlador OpenFlow para modificar o roteamento no PC 3G conforme solicitado. O controlador OpenFlow configura os comutadores OpenFlow padrão, o SGSN Openflow 1215, e o GGSN 1211 com regras e ações de fluxo para habilitar o roteamento solicitado pelas entidades de plano de controle. Os detalhes desta configuração são descritos em maiores detalhes mais adiante.

[0065] A Figura 13 é um fluxograma de uma modalidade da operação básica do PC 3G. Em uma modalidade, o processo começa com a inicialização dos módulos de plano de controle do PC 3G dentro do controlador OpenFlow no sistema computacional em nuvem (Bloco 13401). Cada módulo de plano de controle na pluralidade de módulos de plano de controle é inicializado como uma VM separada pelo gerenciador de nuvem. Então, o gerenciador de nuvem monitora a utilização de recursos de cada módulo de plano de controle, bem como a quantidade e o tipo de tráfego de plano de controle manuseado por cada módulo de plano de controle (Bloco 1303). O gerenciador de nuvem pode monitorar diretamente estes dados, receber relatórios a partir dos módulos de plano de controle ou qualquer combinação destes.Se o gerenciador de nuvem detectar um nivel limiar de utilização de recursos ou carga de tráfego para qualquer um entre a pluralidade de módulos de plano de controle sendo monitorados (Bloco 1205), o gerenciador de nuvem pode adotar as etapas para responder automaticamente este cenário. O gerenciador de nuvem pode inicializar um novo módulo de plano de controle ou um caso de tal módulo de plano de controle como uma máquina virtual separada (Bloco 1207). Este módulo de plano de controle novo ou caso pode, então, compartilhar a carga de módulos de plano de controle existentes ou casos do mesmo tipo, aliviando, assim, a carga sobre esses módulos dinamicamente.

[0066] De modo similar, o gerenciador de nuvem pode detectar falhas ou a subutilização de um entre a pluralidade de módulos de plano de controle (Bloco 1209). O gerenciador de nuvem pode, então, reiniciar um módulo de plano de controle falho ou encerrar um módulo de plano de controle subutilizado (Bloco 1211). Reiniciar o módulo de plano de controle garante um nível de compartilhamento de carga para um pool de módulos de plano de controle. Desativar um módulo de plano de controle libera os recursos e reduz o overhead criado pelo módulo de plano de controle. O gerenciador de nuvem pode realizar essas funções por VPCs e operadoras móveis usando os recursos de sistema computacional em nuvem, maximizando, assim, o uso de recursos disponíveis e reduzindo os custos de operação enquanto mantém estrita a separação de dados e tráfego entre as operadoras móveis.

[0067] A Figura 14 é um diagrama de uma modalidade de como o PC 3G no sistema computacional em nuvem habilita uma companhia de serviços gerenciados a gerenciar múltiplas redes de operadora fora de uma única central de dados . A instalação de computação em nuvem de serviços gerenciados 1401 roda casos separados do plano de controle de PC 3G para cada operadora móvel com a qual a companhia de serviços gerenciados tem um contrato. Cada caso de PC 3G se encontra em um VPC 1403A,B que isola o tráfego de operadora móvel de outros locatários na instalação de computação em nuvem 1401 da central de dados. O caso de plano de controle de PC 3G para uma operadora móvel é conectado à malha de comutação de plano de dados OpenFlow PC 3G geograficamente distribuída da operadora móvel 1407A,B e às estações de base da operadora móvel através de um roteador de borda virtual 1409A,B. O roteador de borda virtual 1409A,B roteia um tráfego a partir da central de dados para e a partir da malha de comutação de plano de dados de PC 3G da operadora móvel apropriada 1407A,B. Em alguns casos, as operadoras móveis pode até mesmo compartilhar estações de base e malhas de comutação de PC 3G, embora a modalidade exemplificadora na Figura 14 mostre um caso onde as duas operadoras móveis têm malhas de comutação separadas. Troca de Tráfego de PC 3G e Roteamento Diferencial em um Sistema Computacional em Nuvem

[0068] A Figura 15 é um diagrama de uma modalidade de um processo para a troca de tráfego de PC 3G roteamento diferencial para um tratamento de serviço especializado. A sinalização OpenFlow, indicada pelas linhas contínuas e pelas setas 1501, configuram as regras e ações de fluxo nos comutadores e porta de acessos dentro do PC 3G para um roteamento diferencial. Essas regras de fluxo direcionam fluxos GTP a localizações particulares. Neste exemplo, a operadora neste caso troca de tráfego no seu PC 3G com duas outras operadoras fixas . O roteamento através de cada ponto de troca de tráfego é manuseado pelos respectivos GGSN1 e GGSN2 1503A, B. As linhas tracejadas e as setas 1505 mostram um tráfego a partir de uma UE 1507 que precise ser roteada a outra operadora de troca de tráfego. As regras de ações de fluxo para distinguir qual ponto de troca de tráfego o tráfego deve atravessar são instaladas nos comutadores OpenFlow 1509 e porta de acessos 1503A, B pelo controlador OpenFlow 1511. O controlador OpenFlow 1511 calcula essas regras e ações de fluxo com base nas tabelas de roteamento que mesmo mantém para tráfego externo, e a origem e o destino dos pacotes, bem como através de qualquer tratamento de encaminhamento especializado necessário para os pacotes marcos DSCP.

[0069] As linhas tracejadas longas e pontilhadas e as etapas 1515 mostram um exemplo de uma UE 1517 que está obtendo conteúdos a partir de uma fonte externa. Os conteúdos não são originalmente formulados para a tela da UE 1517, logo, o controlador OpenFlow 1511 instalou regras e ações de fluxo no GGSN1 1503B, SGSN 1519 e nos comutadores OpenFlow 1509 para rotear o fluxo através de um aplicativo de transcodificação 1521 na instalação de computação em nuvem. O aplicativo de transcodificação 1521 reformata os conteúdos de modo que de adeguem à tela da UE 1517. Um A solicita o tratamento especializado no momento em que a UE configurar sua sessão com a fonte de conteúdos externos através do Subsistema de Multimídia de IP (IMS) ou outro protocolo de sinalização. Roteamento TEID GTP

[0070] Em uma modalidade, OpenFlow é modificado para proporcionar regras para Roteamento TEID GTP. A Figura 16 é um diagrama de uma modalidade da modificação de tabela de fluxo OpenFlow para o roteamento TEID GTP. Um comutador OpenFlow que suporte roteamento TEID corresponde à coleção de 2 byte (16 bit) de campos de cabeçalho e TEID GTP de 4 byte (32 bit), além de outros campos de cabeçalho OpenFlow , em pelo menos uma tabela de fluxo (por exemplo, a primeira tabela de fluxo). O flag TEID GTP pode ser um curinga (isto é, as correspondências são "não se importa"). Em uma modalidade, os protocolos de PC 3G não atribuem nenhum significado a TEIDs diferente como um identificador de ponto final para túneis, como portas em protocolos de transporte UDP/TCP padrão. Em outras modalidades, os TEIDs podem ter um significado ou semântica correlacionados. O campo de flags de cabeçalho GTP também pode ser um curinga, este pode ser parcialmente correspondido combinando-se as seguintes máscaras de bit: OxFFOO - campo Match the Message Type; OxeO - campo Match the Version; Ox10 - campo Match the PT; 0x04 - campo Match the E; 0x02 - campo Match the S; e Ox01 - campo Match the PN.

[0071] Em uma modalidade, OpenFlow pode ser modificado para suportar portas virtuais para uma rápida encapsulação e desencapsulação de TEID GTP de trajetória. Um porta de acesso móvel OpenFlow pode ser usado para suportar encapsulação e desencapsulação GTP com portas virtuais. As portas virtuais de encapsulação e desencapsulação GTP podem ser usadas para uma rápida encapsulação e desencapsulação de pacotes de dados de usuário dentro de túneis GTP-U, e podem ser projetadas simples o suficiente para que possam ser implementadas em hardware ou firmware. Por esta razão, as portas virtuais GTP podem ter as seguintes restrições em tráfego que estas manipularão: campo Protoco! Type (PT) = 1, onde as portas de encapsulação GTP suportam somente GTP, não GTP' (campo PT = O); flag Extension Header (E) = O, onde nenhum cabeçalho de extensão é suportado, flag Sequence Number (S) = O, onde nenhum número de sequência é suportado; flag N-PDU (PN) = O; e tipo de Mensagem = 255, onde somente as mensagens G-PDU, isto é, dados de usuário tunelados, são suportadas na trajetória rápida.

[0072] Se um pacote necessitar de encapsulação ou chegar encapsulado com flags de cabeçalho diferentes de zero, extensões de cabeçalho, e/ou o pacote GTPU não for um pacote G-PDU (isto é, é um pacote de controle GTP-U), o processamento deve proceder através do plano de controle de trajetória lenta de porta de acesso (software). Os pacotes GTP-C e GTP' direcionados ao endereço de IP de porta de acesso são um resultado de configuração errônea e consistem em um erro . Eles devem ser enviados ao controlador OpenFlow, visto que esses pacotes são manipulados pelas entidades de plano de controle SGSN e GGSN no sistema computacional em nuvem ou à entidade de cobrança que manuseia GTP' e não os comutadores de plano de dados SGSN e GGSN.

[0073] As portas virtuais GTP são configuradas a partir do controlador OpenFlow usando um protocolo de configuração. Os detalhes do protocolo de configuração são dependentes do comutador. O protocolo de configuração deve suportar mensagens que realizem as seguintes funções: permitir que o controlador questione e retorne uma indicação se o comutador suporta portas virtuais de trajetória rápida GTP e quais números de porta virtual são usados para um processamento GTP-U de trajetória rápida ou trajetória lenta, e permitir que o controlador instancie uma porta virtual de trajetória rápida GTP-U dentro de uma trajetória de dados de comutador para uso na ação de ajuste de porta de saída da tabela OpenFlow . O comando de configuração deve ser rodado em uma transação de modo que, quando s resultados da ação forem reportados de volta ao controlador, uma porta virtual de trajetória rápida GTP-U para a trajetória de dados solicitada tenha sido instanciada ou um erro tenha retornado indicando porque a solicitação não poderia apreciada. O comando também permite que o controlador OpenFlow ligue uma porta virtual GTP-U a uma porta física. Para portas virtuais de desencapsulação, a porta física é uma porta de entrada. Para portas virtuais de encapsulação, a porta física é uma porta de saída.

[0074] O controlador OpenFlow instancia uma porta virtual para cada porta física que possa transmitir ou receber pacotes roteados através de um túnel GTP, antes de instalar quaisquer regras no comutador para roteamento TEID GTP.

[0075] Em uma modalidade, um porta de acesso GTP mantém uma tabela hash que mapeia TEIDs GTP nos campos de cabeçalho de túnel para seus portadores. A Figura 17 é um diagrama da estrutura de uma fileira de tabela de fluxo. As teclas hash TEID são calculadas usando um algoritmo hash adequado com baixa frequência de colisão, por exemplo, SHA-1. O porta de acesso mantém uma fileira de tabela de fluxo para cada TEID GTP/portador. O campo TEID contém o TEID GTP para o túnel. Os tags VLAN e os campos de rótulos MPLS contêm uma lista ordenada de tags VLAN efou rótulos MPLS que definem túneis nos quais o pacote precisa ser roteado. Os bits de prioridade VLAN e os bits de classe de tráfego MPLS estão incluídos nos rótulos. Esses túneis podem ou não ser necessários. Se eles não forem necessários, então, esses campos estão vazios. O endereço de IP de fonte de origem de túnel contém o endereço no porta de acesso de encapsulação ao qual qualquer tráfego de controle que envolve o túnel deve ser direcionado (por exemplo, indicações de erros). O campo de endereço de IP de destino final de túnel contém o endereço de IP do porta de acesso ao qual o pacote tunelado deve ser roteado, no qual o pacote será desencapsulado e removido do túnel GTP. O campo QoS DSCP contém o Ponto de Código DiffServe , se existir, para o portador no caso de um portador dedicado. Este campo pode estar vazio se o portador for um portador padrão com o QoS de melhor esforço, mas conterá valores diferentes de zero se o portador QoS for maior que o melhor esforço.Em uma modalidade, o suporte de trajetória lenta para GTP é implementado com um comutador de porta de acesso OpenFlow. Um comutador de porta de acesso móvel OpenFlow também contém um suporte no plano de controle de software para um processamento de pacote de trajetória lenta. Esta trajetória é adotada por pacotes G-PDU (tipo de mensagem 255) com campos de cabeçalho ou cabeçalhos de extensão diferentes de zero , e os pacotes de plano de dados de usuário que requerem encapsulação com tais campos ou a adição de cabeçalhos de extensão, e por pacotes de controle GTP-U. Por este propósito, o comutador suporta três portas locais no plano de controle de software: LOCAL_GTP_CONTROL - a trajetória rápida de comutador encaminha pacotes encapsulados GTP direcionados ao endereço de IP de porta de acesso que contenham mensagens de controle GTPU e o plano de controle de software de comutador local inicia ações de plano de controle local dependendo da mensagem de controle GTP-U; LOCAL GTP U DECAP - a trajetória rápida de comutador encaminha pacotes GPDU a esta porta que tem campos de cabeçalho ou cabeçalhos de extensão diferentes de zero (isto é, E != O, S != O, ou PN != O). Esses pacotes requerem uma manipulação especializada. A trajetória de software de comutador local processa os pacotes e realiza a manipulação especializada; e LOCAL_GTP_U_ENCAP - a trajetória rápida de comutador encaminha os pacotes de plano de dados de usuário a esta porta que requer uma encapsulação em um túnel GTP com campos de cabeçalho ou cabeçalhos de extensão diferentes de zero (isto é, E != O, S != O, ou PN != O). Esses pacotes requerem uma manipulação especializada. A trajetória lenta de software de comutador local encapsula os pacotes e realiza a manipulação especializada. Além de encaminhar os pacotes, a trajetória rápida de comutador torna o campo de metadados OpenFlow disponível ao software de trajetória lenta.

[0076] Para suportar uma encapsulação de trajetória lenta, o plano de controle de software no comutador mantém uma tabela hash com teclas calculadas a partir do GTP-U TEID. As teclas hash TEID sai calculadas usando um algoritmo hash adequado com baixa frequência de colisão, por exemplo, SHA-1. As entradas de tabela de fluxo contêm um registro de como o cabeçalho de pacote, incluindo o cabeçalho de encapsulação GTP, deve ser configurado. Isto inclui: os mesmos campos de cabeçalho para a tabela de encapsulação de hardware ou firmware na Figura 18; valores para os flags de cabeçalho GTP (PT, E, S, e PN); o número de sequência e/ou o número de N-PDU seja exista; se o flag E for 1, então, a tabela de fluxo contém uma lista de cabeçalhos de extensão, incluindo seus tipos, qual trajetória lenta deve ser inserida no cabeçalho GTP.

[0077] Em uma modalidade, o sistema implementa uma porta virtual de encapsulação GTP de trajetória rápida. Quando solicitado pelo software de plano de controle SGSN e GGSN rodando no sistema computacional em nuvem, o controlador OpenFlow programa o comutador de porta de acesso a instalar regras, ações, e entradas de tabela hash TEID para pacotes de roteamento e, túneis GTP através uma porta virtual de encapsulação GTP de trajetória rápida. As regras correspondem o filtro de pacote para o lado de entrada do portador do túnel GTP. Tipicamente, este será uma 4 tupla de: endereço de origem de IP; endereço de destino de IP: porta de origem de UDP/TCP/SCTP; e porta de destino de UDP/TCP/SCTP. O endereço de origem e o endereço de destino de IP são tipicamente os endereços para o tráfego de plano de dados de usuário, isto é, uma UE ou serviço de Internet com o qual uma UE está conduzindo, e similaridade com os números de porta. Para uma regra que corresponde ao lado de entrada de túnel de GTP-U, as instruções associadas são as seguintes: Gravar Metadados (GTP-TEID, OxFFFFFFFF) Aplicar Ações (Set-Output-Port GTP-Encap-VP).

[0078] O comutador também grava uma entrada na tabela hash TEID contendo os campos de cabeçalho de túnel para o pacote. GTP-TEID é o identificador de ponto final de túnel GTP. GTP-Enacap-VP é a porta virtual de encapsulação de trajetória rápida GTP ligada à porta física a partir da qual o pacote encapsulado será ultimamente roteado.

[0079] Quando um cabeçalho de pacote corresponder à porta virtual, o TEID GTP é gravado nos 32 bits inferiores dos metadados e o pacote é direcionado à porta virtual. A porta virtual calcula o hash do TEID e pesquisa as informações de cabeçalho de túnel na tabela de cabeçalho de túnel. Se nenhuma dessas informações de túnel estiver presente, o pacote é encaminhado ao controlador com uma indicação de erro. De outro modo, a porta virtual constrói um cabeçalho de túnel GTP e encapsula o pacote. Quaisquer bits DSCP ou bits de prioridade VLAN são adicionalmente ajustados nos cabeçalhos de túnel de IP ou MAC, e quaisquer tags VLAN ou rótulos MPLS são enviados pelo pacote. O pacote encapsulado é encaminhado à porta física na qual a porta virtual é ligada.

[0080] Em uma modalidade, o sistema implementa uma porta virtual de desencapsulação de trajetória rápida GTP . Quando solicitado pelo software de plano de controle SGSN e GGSN rodando no sistema computacional em nuvem, o comutador de porta de acesso instala regras e ações para rotear pacotes encapsulados GTP fora dos túneis GTP. As regras correspondem aos flags de cabeçalho GTP e ao TEID GTP para o pacote, na tabela de fluxo OpenFlow modificada mostrada na Figura 16 da seguinte forma: o endereço de destino de IP é um endereço de IP no qual o porta de acesso está esperando o tráfego GTP; o tipo de protocolo de IP é UDP (17); a porta de destino de UDP é a porta de destino GTPU (2152); e os campos de cabeçalho e o campo de tipo de mensagem serão um curinga com o flag OXFFFO e os dois bytes superiores do campo correspondem ao tipo de mensagem G-PDU (255) enquanto os dois bytes inferiores correspondem a 0x30, isto é, o pacote é um pacote GTP diferente de um pacote GTP' e o número de versão é 1. A porta virtual simplesmente remove o cabeçalho de túnel GTP e encaminha o pacote de plano de dados de usuário confinado à porta física ligada.

[0081] Em uma modalidade, o sistema implemente a manipulação de pacotes de controle GTP-U. O controlador OpenFlow programa o as tabelas de fluxo de comutador de porta de acesso com 5 regras para cada endereço de IP de comutador de porta de acesso usado para o tráfego GTP. Essas regras contêm valores específicos para os campos a seguir: o endereço de destino de IP é um endereço de IP no qual o porta de acesso está esperando o tráfego GTP; o tipo de protocolo de IP é UDP (17); a porta de destino UDP é a porta de destino GTP-U (2152); os flags de cabeçalho GTP e o campo de tipo de mensagem são um curinga com OxFFFO; o valor do campo de flags de cabeçalho é 0x30, isto é, o número de versão é 1 e o campo PT é 1; e o valor do campo de tipo de mensagem é um entre 1 (Solicitação de Eco), 2 (Resposta de Eco), 26 (Indicação de Erro), 31 (Suporte para Notificação de Cabeçalhos de Extensão), ou 254 (Marcador Final).A instrução associada com uma correspondência a uma dessas regras é: Aplicar Ações (Set-Output-Port LOCALGTP CONTROL)

[0082] Isto faz com que o pacote seja encaminhado à porta de controle GTP-U local do comutador de porta de acesso para processamento pelo plano de controle de software local. Os pacotes de controle GTP-U que são originados pelo comutador são gerados no plano de controle de software e são roteados pelo plano de controle.

[0083] Em uma modalidade, o sistema implementa a manipulação de pacotes GPDU com cabeçalhos de extensão, números de sequência, e números N-PDU. Os pacotes G-PDU com cabeçalhos de extensão, números de sequência, e números NP DU precisam ser encaminhados ao plano de controle de software de comutador local para processamento. O controlador OpenFlow programa 3 regras para este propósito. Os mesmos têm os seguintes campos de cabeçalho comuns: o endereço de destino de IP é um endereço de IP no qual o porta de acesso está esperando o tráfego GTP; e o tipo de protocolo de IP é UDP (17); a porta de destino UDP é a porta de destino GTP-U (2152).

[0084] Os flags de cabeçalho e os campos de tipo de mensagem para as três regras são um curinga com as seguintes máscaras de bit e correspondem da seguinte forma: máscara de bit OxFFF4 e os dois bytes superiores correspondem ao tipo de mensagem G-PDU (255) enquanto os dois bytes inferiores são 0x34, indicando que o número de versão é 1, o pacote é um pacote GTP, e existe um cabeçalho de extensão presente; máscara de bit OxFFF2 e os dois bytes superiores correspondente ao tipo de mensagem G-PDU (255) enquanto os dois bytes inferiores são 0x32, indicando que o número de versão é 1, o pacote é um pacote GTP, e existe um número de sequência presente; e a máscara de bit OxFF01 e os dois bytes superiores correspondem ao tipo de mensagem G-PDU (255) enquanto os dois bytes inferiores são 0x31, indicando que o número de versão é 1, o pacote é um pacote GTP, e um N-PDU está presente.

[0085] A instrução para essas regras é a seguinte: Aplicar Ações (Set-Output-Port LOCAL_GTP_U_DECAP).

[0086] Esta envia o pacote à trajetória de desencapsulação GTP-U de trajetória lenta de software para um processamento especial.

[0087] Em uma modalidade, o sistema implementa a manipulação dos pacotes de plano de dados de usuário que requerem uma encapsulação GTP-U com cabeçalhos de extensão, números de sequência, e números N-PDU. Os pacotes de plano de dados de usuário que requerem cabeçalhos de extensão, números de sequência, ou números N-PDU durante a encapsulação GTP requerem uma manipulação especial pela trajetória lenta de software. Para esses pacotes, o controlador OpenFlow programa uma regra que corresponde à 4 tupla: endereço de origem de IP; endereço de destino de IP; porta de origem UDP/TCP/SCTP; e porta de destino UDP/TCP/SCTP. As instruções para pacotes de correspondência são: Gravar Metadados (GTP-TEID, OxFFFFFFFF) Aplicar Ações (Set-Output-Port LOCAL_GTP_U_ENCAP )

[0088] Esta envia o pacote à porta de encapsulação GTP de trajetória lenta de software e, além disso, torna o TEID disponível à trajetória lenta.

[0089] A mensagem OpenFlow que programa a inserção de regra também inclui informações sobre os valores para o número de sequência, número N-PDU, ou o tipo e conteúdos do cabeçalho de extensão, bem como os campos de cabeçalho de pacote que designam o porta de acesso de desencapsulação e o transporte de portador e o TEID GTP. Estas informações são inseridas pelo software de plano de controle do comutador na tabela de encapsulação de software, vinculada pelo TEID.

[0090] Em uma modalidade, o sistema implementa a manipulação de pacotes de controle GTP-C e GTP'. Quaisquer pacotes de controle GTP-C e GTP' que são direcionados aos endereços de IP em um comutador de porta de acesso estão em erro. Esses pacotes precisam ser manipulados pelas entidades de protocolo SGSN, GGSN, e GTP' no sistema computacional em nuvem, não pelas entidades SGSN e GGSN nos comutadores . Para capturar tais pacotes, o controlador OpenFlow deve programar o comutador com as duas regras a seguir: o endereço de destino de IP é um endereço de IP no qual o porta de acesso está esperando o tráfego GTP; o tipo de protocolo de IP é UDP (17); para uma regra , a porta de destino UDP é a porta de destino GTP-U (2152), para a outra, a porta de destino UDP é a porta de destino GTP-C (2123); os flags de cabeçalho GTP e os campos de tipo de mensagem são um curinga.

[0091] Essas regras devem ser de prioridade menor entre todas as regras GTP na tabela de fluxo do comutador de porta de acesso. Estas corresponderão a quaisquer pacotes GTP que não correspondem a outras regras mais especificas. A instrução para essas regras é a seguinte: Aplicar Ações (Set-Output-Port CONTROLLER )

[0092] Esta encapsula o pacote e o envia ao controlador OpenFlow.

[0093] Em uma modalidade, o sistema implementa um roteamento GTP de não-porta de acesso. Um comutador Openflow estendido por GTP também pode cumprir o roteamento GTP sem realizar as funções de porta de acesso de encapsulação e desencapsulação. A função de roteamento GTP pode ser realizada por um comutador de porta de acesso além de sua função de porta de acesso, ou pode ser realizado por outro comutador que seja desprovido de uma função de porta de acesso, dentro da malha de comutação EPC distribuída.

[0094] Um comutador Openflow estendido por GTP contém pelo menos uma tabela de fluxo que manipula as regras que correspondem aos campos de cabeçalho GTP conforme na Figura 16. O controlador Openflow programa as regras de campo de cabeçalho GTP além de outros campos para realizar um roteamento GTP e adicionar ações apropriadas se a regra for correspondida. Por exemplo, a regra a seguir corresponde um pacote de controle GTP-C direcionado a uma entidade de plano de controle (MSC, SGSN,GGSN) no sistema computacional em nuvem, que não se encontra no plano de controle VLAN: o tag VLAN não é ajustado ao plano de controle VLAN, o campo de endereço de destino de IP é ajustado ao endereço de IP da entidade de plano de controle almejada, o tipo de protocolo de IP é UDP (17), a porta de destino UDP é a porta de destino GTP-C (2123), os flags de cabeçalho GTP e o tipo de mensagem são um curinga com OxFO e os campos de versão correspondida e tipo de protocolo são 2 e 1, indicando que o pacote é um pacote de plano de controle GTPv1 e não GTP'.

[0095] As ações a seguir enviam um tag de plano de controle VLAN no pacote e o encaminha à nuvem para processamento pela entidade de plano de controle relevante. O pacote é encaminhado sem nenhum processamento L3 (isto é, sem modificar o IP TTL): Gravar Ações (Set-VLAN-ID CP VLAN_TAG Gravar Ações (Set-Source-MAC-Address SWITCH MAC ADDR) Gravar Ações (Set-Dest-MAC-Address NEXT HOP MAC ADDR) Ajustar a Porta de Saída -Output-Port NEXT_HOP_PORT Extensões GTP para OpenFlow.

[0096] O protocolo OpenFlow pode ser modificado para proporcionar extensões para GTP que habilita o gerenciamento do PC 3G. OpenFlow utiliza estruturas de dados referidas como estruturas de correspondência de fluxo que habilitam o protocolo a definir critérios para regras correspondentes a fluxos particulares. A estrutura de correspondência de fluxo OpenFlow de ofp_match contém dois campos, tipo e comprimento, que permite que a estrutura de correspondência de fluxo seja estendida. O campo de tipo pode ser ajustado ao tipo da extensão e o campo de comprimento pode ser ajustado ao comprimento da estrutura ofp_match estendida. Em uma modalidade, define-se um novo tipo baseado em um número aleatório para correspondência de fluxo GTP: enum ofp match_type_ext { ERSMT GTP = 48696 }.

[0097] O tipo pode ser aleatoriamente gerado a fim de não interferir nos outros tipos estendidos. Atualmente, não existem mecanismos organizacionais para registrar os identificadores de tipo em OpenFlow.

[0098] A estrutura ersmt_gtp define os campos de tabela de fluxo para um roteamento de fluxo GTP como: struct ersmt_gtp { unit8_t gtp_wildcard; uintl6_t gtp_type_n_flags; uintl6_t gtp_flag_mask; uint32_t gtp_teid; };

[0099] O campo gtp type_n_flags contém o tipo de mensagem GTP nos 8 bits superiores e os flags de cabeçalho GTP nos 8 bits inferiores. O campo gtp_teid contém o TEID GTP. O campo gtp_wildcard indica se o tipo GTP e flags e TEID devem ser correspondidos. Se os quatro bits inferiores forem 1, o campo de tipo e flags deve ser ignorado, enquanto se os quatro bits superiores forem 1, o TEID deve ser ignorado. Se os bits inferiores forem O, os campos de tipo e flag devem ser correspondidos submetidos aos flags no campo gtp_flag_mask, enquanto se os bits superiores forem O, o TEID deve ser correspondido. A máscara é combinada com o campo de tipo de mensagem e cabeçalho do pacote usando a lógica AND; o resultado se torna o valor da correspondência. Somente essas partes do campo onde a máscara tem um valor 1 são correspondidas.

[00100] Além dos campos de tabela de fluxo, requer-se um objeto para codificar a encapsulação da entrada de tabela hash de porta virtual TEID. A estrutura ersmt_gtp_tuninfo pode ser usada para definir estas informações: struct ermst_mpls_lbl { uint8_t mplslbl_low; uint8_t mpls Ibl micl' uint8_t mpls Ibl_high; }; struct ersmt_gtp_tuninfo { uintl6_t gtp tuninfo_length; uint32_t gtp_tuninfo_saddr; uint32_t gtp tuninfo_daddr; uint8_t gtp_tuninfo_dscp; uint8_t gtp_tuninfo vlan_len; uniti 6_t gtp_tuninfo_vlan_tags [0]; /*variable length*/ uint8_t gtp_tuninfo_mpls_len; struct mpls_Ibl gtp_tuninfo_mpls_labels [0]; /*variable length*/ }.

[00101] A estrutura ermst_mpls Ibl proporciona uma estrutura de dados de 24 bits para codificar os rótulos MPLS. A estrutura ersmt_gtp_tunifo contém campos que descrevem um túnel GTP. Estes são inseridos na porta virtual de encapsulação. A estrutura tem comprimento variável porque contém um número variável de tags VLAN e/ou rótulos MPLS. O campo gtp_tuninfo_length contém o comprimento da estrutura. Os campos gtp_tuninfo saddr, gtp_tuninfo_daddr, e gtp_tuninfo_dscp contêm o endereço de origem do túnel (o endereço da interface no comutador que realiza a encapsulação), o endereço de destino do túnel (o comutador ao qual o pacote tunelado será roteado e que irá desencapsular o pacote), e o Ponto de Código DiffServ (caso exista ) atribuído ao portador do túnel. o portador DSCP será diferente de zero se o portador for um portador dedicado e não for um portador de melhor esforço.

[00102] Os campos gtp_tuninfo vlan_len e gtp_tuninfo_mpls_len contêm o comprimento do campo de tags VLAN e do campo de rótulos MPLS, respectivamente. Os campos gtp_tuninfo_vlan_tags [0] e gtp_tuninfo_mpls labels [0] contêm os tags VLAN atuais elou os rótulos MPLS que precisam ser enviados pelo cabeçalho de túnel do pacote. Esses campos estarão ausentes (e os campos de comprimento correspondentes serão iguais a zero) se nenhuma Trajetória Comutada de Rótulo VLAN ou MPLS (LSPs) for usada para o túnel.

[00103] Em uma modalidade. OpenFlow é modificado para adicionar mensagens de extensão para adicionar, deletar, ou modificar um portador PC 3G ou túnel GTP. A sinalização OpenFlow para adicionar, modificar, ou deletar um portador PC 3G ou túnel GTP consiste em uma mensagem OpenFlow, a mensagem ofp_flow_mod, contendo uma definição de fluxo GTP ersmt_gtp. A mensagem ofp_flow_mod OpenFlow padrão pode ser usada desde que o analisador de protocolo OpenFlow possa manipular fluxos estendidos. Se a modificação de fluxo requerer uma alteração à tabela hash TEID de porta virtual de encapsulação, o controlador OpenFlow deve lançar uma mensagem de extensão OpenFlow GTP contendo a entrada de tabela hash TEID. O controlador OpenFlow pode lançar ambas as mensagens sequencialmente, primeiro a mensagem ofp_flow_mod, então, a mensagem de modificação de tabela hash TEID , então, o controlador OpenFlow deve lançar uma mensagem OFPT_BARRIER REQUEST para forçar o processamento de ambas as mensagens pelo comutador OpenFlow.

[00104] A estrutura de cabeçalho de extensão de mensagem OpenFlow ofp_experimenter header contém um campo id experimentador, denominado como experimentador. Em uma modalidade, este campo pode ser ajustado ao OUI Ericsson IEEE, Ox01 ec ou fabricante similar ou OUI de provedor. O restante da estrutura contém as mensagens de extensão GTP. Essas mensagens podem ser identificadas pelos seguintes códigos de mensagem: enum ermst_gtp_message code { GTP ADD TEID TABLE ENTRY = O, GTP DEL TEID TABLE ENTRY = 1, };

[00105] A extensão OpenFlow GTP contém uma mensagem para adicionar e deletar uma entrada de tabela hash TEID. As entradas são modificadas deletandose primeiramente a entrada para o TEID, então, adicionando-se uma nova entrada para o mesmo TEID. A mensagem de extensão OpenFlow GTP para inserir uma nova entrada TEID na tabela hash de porta virtual de encapsulação é: struct ermst_teid_table_add { ermst gtp_message_code teid table_add_type; uint16 t teid table add teid; struct ermst_gtp_tuninfo teid table_add_entry; };

[00106] O campo The teidtable add_type é ajustado para GTP ADD_TEID_TABLE_ENTRY enquanto o campo teid_table_add_teid contém o TEID e teid table_add entry contém a entrada de tabela a ser adicionada . A mensagem de extensão OpenFlow GTP para deletar uma entrada TEID a partir da tabela hash de porta virtual de encapsulação é: struct ermst teid_table_del { ermst_gtp_message_code teid_table_del type; uint-16 t teidtabledel teid; }.

[00107] O campo teid_table_del_type é ajustado para GTP DEL TEID TABLE ENTRY enquanto o campo teid table del teid contém o TEID para que a entrada seja delatada.

[00108] Em uma modalidade, as extensões ao OpenFlow para GTP também abrangem uma configuração de comutador OpenFlow. Antes de aceitar quaisquer RPCs de atualização de roteamento GTP a partir das entidades de plano de controle de nuvem PC 3G, o controlador OpenFlow deve configurar as portas virtuais de encapsulação e/ou desencapsulação GTP nos comutadores de porta de acesso OpenFlow estendido por GTP. A configuração é cumprida usando um protocolo de configuração de comutador específico, e é descrita anteriormente.

[00109] Além da configuração de porta virtual nos porta de acessos OpenFlow estendidos por GTP, pode-se requerer urna configuração de fila QoS em qualquer comutador OpenFlow que estará enviando um tráfego de portador GTP melhor que o de melhor esforço . O protocolo OpenFlow não contém mensagens para filas de configuração, esta configuração é deixada ao protocolo de configuração, conforme o caso com portas virtuais. Antes de instalar quaisquer rotas de fluxo, o controlador OpenFlow deve configurar quaisquer filas para se conectar às portas físicas e/ou virtuais em comutadores que rotearão portadores GTP melhores que os de melhor esforço. Esta etapa de configuração deve ser realizada tanto para comutadores OpenFlow estendidos por GTP corno para comutadores OpenFlow padrão.

[00110] Em uma modalidade, os fluxos de mensagem OpenFlow para as operações GTP são modificados. Conforme descrito anteriormente, as entidades de plano de controle PC 3G, incluindo as partes de plano de controle PC 3G do SGSN e do SSSN residem em uma instalação de computação em nuvem em uma central de dados. O plano de controle do SGSN e GGSN se comunica através de chamadas de procedimento remoto (RPCs) ou através de um mecanismo similar com o controlador OpenFlow dentro da nuvem quando as alterações de roteamento forem disparadas pela sinalização GTP. O controlador OpenFlow executa as alterações no plano de dados aos porta de acessos de plano de dados habilitados a OpenFlow estendido por GTP, o plano de controle do SGSN e GGSN, e aos comutadores OpenFlow que são estendidos para um roteamento GTP, referindo no presente documento como 'GxOFS,' através de uma sinalização OpenFlow na rede de plano de controle que conecta a nuvem aos porta de acessos e aos comutadores.

[00111] Em geral, nenhuma sinalização é requerida ao GxOFS se nenhum tratamento de roteamento especial for requerido para os fluxos GTP. Casos onde tal tratamento pode ser requerido são, por exemplo: onde um PC 3G do operador tem pontos de troca de tráfego com a Internet em mais de um ponto e, consequentemente, tem mais de um porta de acesso, rotear ao porta de acesso ótimo pode requerer um tráfego de direção dentro do PC 3G em comutadores intermediários; e onde o fluxo GTP deve receber um tratamento especial a partir de um aplicativo em algum ligar dentro da rede do operador, por exemplo, dentro da nuvem. Um exemplo de tal tratamento especial é a transcodificação. Os comutadores intermediários podem requerer uma programação para rotear os pacotes de plano de usuário ao aplicativo de transcodificação. Esta lista não é exaustiva, muitos outros aplicativos de roteamento GTP em comutadores intermediários são possíveis.

[00112] Os túneis de contexto GTP PDP podem ser configurados usando as mensagens de solicitação de contexto PDP de criação de GTP-C. Este procedimento é usado em uma variedade de sequências de mensagem, por exemplo, em um procedimento de anexação inicial de E-UTRAN.

[00113] As Figuras 18A a 18C são fluxogramas da criação, modificação e deletação de sessão no PC 3G. O processo para criar uma sessão é ilustrado na Figura 18A. O processo é iniciado em resposta a uma solicitação para criar um túnel GTP entre um SGSN e um GGSN para uma sessão de assinante (Bloco 1801). A sessão de assinante é iniciada para conectar o equipamento de usuário no PC 3G a outro ponto final da sessão de assinante, que pode ser outro equipamento de usuário, um servidor ou ponto final similar. O túnel GTP estabelece a rota da sessão de assinante ao longo da rede de núcleo da rede PC 3G a um ponto de troca de tráfego, a Internet ou um ponto final similar. O controlador configura um comutador que implementa o SGSN a encapsular e desencapsular pacotes de dados para a sessão de assinante e estabelecer um primeiro ponto final de túnel GTP (Bloco 1803). O controlador também configura cada comutador na rota do túnel GTP para encaminhar pacotes em cada direção de acordo com a rota do túnel GTP (Bloco 1805). O controlador configura um plano de dados do GGSN para encapsular e desencapsular os pacotes da sessão de assinante e estabelecer um segundo ponto final do túnel GTP no GGSN (Bloco 1807).

[00114] O processo para modificar uma sessão é ilustrado na Figura 18B. O processo é iniciado em resposta a uma solicitação para modificar um túnel GTP entre um SGSN e um GGSN para uma sessão de assinante (Bloco 1811). A sessão de assinante conecta o equipamento de usuário no PC 3G a outro ponto final da sessão de assinante, que pode ser outro equipamento de usuário, um servidor ou um ponto final similar. O túnel GTP é uma rota estabelecida da sessão de assinante ao longo da rede de núcleo da rede PC 3G a um ponto de troca de tráfego, a Internet ou um ponto final similar. Um processo de modificação pode ser utilizar para re-rotear uma sessão de assinante ao longo da rede PC 3G aos mesmos pontos de terminação ou a pontos de terminação diferentes. Qualquer combinação dos pontos de terminação do túnel GTP e da trajetória do GTP pode ser alterada usando este processo. O controlador modifica a configuração do comutador que implementa o SGSN para encapsular e desencapsular pacotes de dados para a sessão de assinante e modificar um primeiro ponto final de túnel GTP (Bloco 1813). O controlador também configura cada comutador na rota atual e na nova rota do túnel GTP para encaminhar pacotes em cada direção de acordo com a rota do túnel GTP (Bloco 1815). O controlador modifica a configuração de um plano de dados do GGSN para encapsular e desencapsular os pacotes da sessão de assinante e estabelecer um segundo ponto final do túnel GTP no GGSN (Bloco 1817).

[00115] O processo para deletar uma sessão é ilustrado na Figura 18C. O processo é iniciado em resposta a uma solicitação para deletar um túnel GTP entre um SGSN e um GGSN para uma sessão de assinante (Bloco 1821). A sessão de assinante conecta o equipamento de usuário no PC 3G a outro ponto final da sessão de assinante, que pode ser outro equipamento de usuário, um servidor ou um ponto final similar. O túnel GTP é uma rota estabelecida da sessão de assinante ao longo da rede de núcleo da rede PC 3G a um ponto de troca de tráfego, a Internet ou um ponto final similar. A sessão de assinante e o túnel GTP associado são deletados quando o aplicativo associado no equipamento de usuário ou o aplicativo no outro equipamento de usuário ou o aplicativo de servidor na outra terminação da sessão de assinante encerrar a conexão. Então, os recursos de sessão de assinante são recuperados deletando-se a sessão de assinante e o túnel GTP. O controlador remove a configuração do túnel GTP em um comutador que implementa o SGSN que encapsulou e desencapsulou pacotes de dados para a sessão de assinante e, desse modo, remove um primeiro ponto final de túnel GTP (Bloco 1823). O controlador também remove a configuração para o túnel GTP a partir de cada comutador na rota do túnel GTP que encaminhou pacotes em cada direção de acordo com a rota do túnel GTP (Bloco 1815). O controlador remove a configuração para o túnel GTP a partir de um plano de dados do GGSN que encapsulou e desencapsulou os pacotes da sessão de assinante e, desse modo, remove um segundo ponto final do túnel GTP no GGSN (Bloco 1827).

[00116] Na Figura 19, mostra-se um exemplo dos fluxos de mensagem OpenFlow para o procedimento de solicitação de sessão de criação. No exemplo ilustrado, o componente de plano de controle SSGN envia uma solicitação de sessão de criação ao componente de plano de controle GGSN no sistema computacional em nuvem, que, então, envia a solicitação ao controlador através de uma chamada RPC de

[00117] atualização de roteamento GTP. A chamada RPC solicita que o controlador OpenFlow estabeleça um novo ponto final de túnel GTP no SGSN e GGSN no plano de dados, e instalar rotas para o novo portador GTP ou túnel em comutadores intermediários, caso seja necessário.

[00118] Antes de retornar uni resultado ao plano de controle GGSN a partir do RPC de atualização de roteamento GTP, o controlador OpenFlow lança uma sequência de mensagens OpenFlow à entidade de porta de acesso de plano de dados apropriada. Na modalidade exemplificadora, a sequência começa com um OFP BARRIER REQUEST para garantir que não existam mensagens pendentes que possam influenciar o processamento das mensagens seguintes. Então, uma mensagem OFPT_FLOW_MOD é lançada, incluindo a estrutura ofp_match com a extensão GTP corno o campo de correspondência e OFPFC_ADD como o campo de comando. A mensagem especifica ações e instruções, conforme descrito anteriormente, para estabelecer uma rota de fluxo para o túnel GTP que encapsula e desencapsula os pacotes através da porta virtual apropriada. Além disso, imediatamente após a mensagem OFPT_FLOW_MOD, o controlador OpenFlow lança uma mensagem GTP_ADD_TEID_TABLE ENTRY aos porta de acessos contendo as entradas de tabela hash TEID para a porta virtual de encapsulação. Conforme descrito anteriormente, as duas mensagens OpenFlow são seguidas por uma mensagem OFPT BARRIER REQUEST para forçar os porta de acessos a processar a rota de fluxo e a atualização de tabela hash TEID antes de proceder.

[00119] Antes de retornar a partir do RPC de atualização de roteamento GTP, o controlador OpenFlow também lança atualizações de roteamento de fluxo GTP a quaisquer Comutadores OpenFlow Estendidos por GTP (GxOFSs) que precisem estar envolvidos no roteamento de fluxo GTP customizado. As mensagens nessas atualizações consistem em um OFP_BARRIER_REQUEST seguido por uma mensagem OFPT_FLOW_MOD contendo a estrutura ofp_match com a extensão GTP para o novo fluxo GTP como o campo de correspondência e OFPFC_ADD como o campo de comando. e as ações e instruções descritas anteriormente para um roteamento de fluxo GTP customizado. Um OFP BARRIER REQUEST final força o comutador a processar a alteração antes de responder. As rotas de fluxo em quaisquer GxOFSs são instaladas após instalar a rota de ponto final de túnel GTP no SGSN no plano de dados e antes de instalar a rota de ponto final de túnel GTP no GGSN no plano de dados, conforme ilustrado na Figura 19. O controlador OpenFlow não responde ao RPC de plano de controle GGSN até que todas as atualizações de roteamento tenham sido cumpridas.

[00120] Uma vez que os RPCs tiverem retornado, o plano de controle GGSN e SGSN retornam as mensagens de resposta de contexto PDP de criação. As características do portador GTP são alteradas usando um processo de solicitação de contexto PDP de atualização. Essas alterações podem, por exemplo, incluir o QoS atribuído aos pacotes de IP. Este procedimento é usado em uma variedade de sequências de mensagem PC 3G, por exemplo, uma solicitação de serviço disparada por UE.

[00121] A Figura 20 é um diagrama de uma modalidade da sequência de mensagem OpenFlow para o procedimento de solicitação de sessão de modificação. Conforme na criação de sessão, o plano de controle SGSN em nuvem PC 3G lança uma mensagem de solicitação de contexto PDP de atualização ao plano de controle GGSN e o plano de controle GGSN lança um RPC de atualização de roteamento GTP ao controlador OpenFLow incluindo as novas informações de atualização de túnel. Então, o controlador OpenFlow lança as mensagens OpenFlow estendidas por GTP ao plano de dados SGSN, GxOFSes, e ao plano de dados GGSN.

[00122] Antes de retornar um resultado ao plano de controle GGSN a partir do RPC de atualização de roteamento GTP, o controlador OpenFlow lança uma sequência de mensagens OpenFlow à entidade de porta de acesso de plano de dados apropriada. A sequência começa com um OFP_BARRIER_REQUEST para garantir que não existam mensagens pendentes que possam influenciar o processamento das mensagens seguintes. Então, uma mensagem OFPT FLOW MOD é lançada, incluindo a estrutura ofp_match com a extensão GTP como o campo de correspondência OFPFC_MODIFY ou OFPFC_MODIFY_STRICT como o campo de comando. Caso seja necessário, a mensagem especifica ações e instruções, conforme descrito anteriormente, para estabelecer uma nova rota de fluxo para o túnel GTP que encapsula e desencapsula os pacotes através da porta virtual apropriada. Além disso, se alterações forem necessárias na tabela hash TEID, imediatamente após a mensagem OFPT FLOW MOD, o controlador OpenFlow lança um TP DEL TEID TABLE ENTRY para deletar a entrada seguida por uma mensagem TP ADD TEID TABLE ENTRY para instalar a nova entrada. Conforme descrito anteriormente, as duas mensagens OpenFlow são seguidas por uma mensagem OFPT BARRIER REQUEST para forçar os porta de acessos a processar a rota de fluxo e atualização de tabela hash TEID antes de proceder.

[00123] Antes de retornar a partir do RPC atualização de roteamento GTP, o controlador OpenFlow também lança atualizações de roteamento de fluxo GTP necessárias a quaisquer Comutadores OpenFlow Estendidos por GTP (GxOFSs) que precisam estar envolvidos em roteamento de fluxo GTP customizado. As mensagens nessas atualizações consistem em um OFP_BARRIER_REQUEST seguido por uma mensagem OFPT FLOW_MOD contendo a estrutura ofp_match com a extensão GTP para o novo fluxo GTP como o campo de correspondência e OFPFC MODIFY ou OFPFC MODIFY STRICT como o campo de comando, e, caso seja necessário, as ações e instruções, conforme descrito anteriormente, para um roteamento de fluxo GTP customizado. Um OFP BARRIER REQUEST final força o comutador a processar a alteração antes de responder. As rotas de fluxo em quaisquer GxOFSs são instaladas após instalar a rota de ponto final de túnel GTP no plano de dados SGSN e antes de instalar a rota de ponto final de túnel GTP no plano de dados GGSN, conforme ilustrado na Figura 20. O controlador OpenFlow não responde ao plano de controle GGSN RPC até que todas as atualizações de roteamento de fluxo tenham sido cumpridas. Uma vez que os RPCs tiverem retornado, o plano de controle GGSN e SGSN retornam as mensagens de contexto PDP de atualização.

[00124] Os túneis GTP são deletados usando o procedimento de solicitação de sessão de deletação. Este procedimento pode ser usado em uma variedade de sequências de mensagem PC 3G, por exemplo, uma solicitação de desanexação disparada por UE. A Figura 21 é um diagrama de uma modalidade da sequência de mensagem OpenFlow para o procedimento de solicitação de sessão de deletação. Similar à criação e modificação de sessão, o plano de controle SGSN de nuvem PC 3G lança uma mensagem de solicitação de contexto PDP de deletação ao plano de controle GGSN e o plano de controle GGSN lança um RPC de atualização de roteamento GTP ao controlador OpenFLow incluindo as informações de deletação de túnel. Então, o controlador OpenFlow lança mensagens OpenFlow estendidas por GTP ao plano de dados SGSN, GxOFSes, e ao plano de dados GGSN.

[00125] A sinalização OpenFlow é conduzida antes de retornar o RPC de atualização de roteamento GTP ao chamador. A sequência começa com um

[00126] OFP BARRIER REQUEST para garantir que não existem mensagens pendentes que possam influenciar o processamento das mensagens seguintes. Então, uma mensagem OFPT_FLOW_MOD é lançada, incluindo a estrutura ofp_match com a extensão GTP como o campo de correspondência e OFPFC DELETE ou

[00127] OFPFC DELETE STRICT como o campo de comando. Além disso, imediatamente após a mensagem OFPT_FLOW_MOD, o controlador OpenFlow lança um GTP DEL TEID TABLE ENTRY para deletar a entrada de tabela hash TEID. Conforme descrito anteriormente, esta mensagem OpenFlow é seguida por uma mensagem OFPT_BARRIER REQUEST para forçar os porta de acessos a processar a rota de fluxo e a atualização de tabela hash TEID antes de proceder.

[00128] Antes de retornar a partir do RPC de atualização de roteamento GTP, o controlador OpenFlow também lança atualizações de roteamento de fluxo GTP necessárias a quaisquer Comutadores OpenFlow Estendidos por GTP que precisem estar envolvidos no roteamento de fluxo GTP customizado. As mensagens nestas atualizações consistem em um OFP_BARRIER REQUEST seguido por uma mensagem OFPT_FLOW_MOD contendo a estrutura ofp_match com a extensão GTP para o novo fluxo GTP como o campo de correspondência e OFPFC_DELETE ou OFPFC DELETE STRICT como o campo de comando. Um OFP BARRIER REQUEST final força o comutador a processar a alteração antes de responder. As rotas de fluxo em quaisquer GxOFSs são instaladas antes de instalar a rota de ponto final de túnel GTP no plano de dados SGSN e antes de instalar a rota de ponto final de túnel GTP no plano de dados GGSN, conforme ilustrado na Figura 21. O controlador OpenFlow não responde à entidade de chamada ate que todas as atualizações de roteamento de fluxo tenham sido cumpridas. Implementações Alternativas

[00129] Em outras modalidades, a arquitetura dividida de PC 3G pode ser implementada em sistemas não-virtualizados e fora de nuvem. As entidades de plano de controle da arquitetura de PC 3G podem ser armazenadas e executadas em um único servidor ou distribuídas ao longo de qualquer número de servidores ou dispositivos computacionais similares. De modo similar, as entidades de plano de controle podem ser executadas como um código de software padrão e módulos sem virtualização ou sistemas similares. Essas entidades de plano de controle podem se comunicar entre si através do sistema local ou chamadas de procedimento, chamadas de procedimento remoto ou mecanismos similares. Em modalidades adicionais, um subconjunto de entidades de plano de controle pode ser virtualizado ou executado em um sistema computacional em nuvem enquanto outro subconjunto das entidades de plano de controle pode ser executado em um servidor, sistema de servidor distribuído ou sistema similar. As entidades de plano de controle podem se comunicar com o plano de dados através do uso do protocolo OpenFlow conforme descrito anteriormente ou através de outros protocolos de controle conforme descrito mais adiante.

[00130] O sistema computacional em nuvem descrito anteriormente é proporcionado a título de exemplo e não a guisa de limitação. Um indivíduo versado na técnica compreenderia que os princípios e recursos descritos anteriormente em relação ao sistema computacional em nuvem também podem ser implementados em outras configurações, tais como servidores únicos ou sistemas de servidor distribuído. Princípios e recursos similares àqueles descritos anteriormente podem ser implementados em sistemas de servidor único, sistemas de servidor distribuído e ambientes computacionais similares. Esses princípios e recursos também podem ser implementados usando um ambiente não-virtualizado incluindo entidades de plano de controle não-virtualizadas que são executadas em qualquer combinação de sistemas computacionais em nuvem, servidores únicos, sistemas de servidor distribuído e sistemas similares.

[00131] Em outras modalidades, outros protocolos de controle podem ser utilizados no lugar do OpenFlow conforme descrito no presente documento. O uso de OpenFlow é apresentado a título de exemplo e sem limitação. Outros protocolos de controle também podem ser utilizados para gerenciar a comunicação entre o plano de controle e o plano de dados e a configuração do plano de dados da arquitetura dividida de PC 3G. Um exemplo de tal protocolo é FORCES, um protocolo padrão IETF para dividir o plano de controle e encaminhar o plano em redes. A especificação do protocolo FORCES é descrita em RFC 5810. RFC 5812 descreve a arquitetura de um elemento de encaminhamento FORCES, o equivalente de um comutador OpenFlow. O próprio protocolo FORCES não suporta diretamente rotas de programação no elemento de encaminhamento, ao invés disso, este consiste em um arcabouço para manipular a interação entre o controlador FORCES e um elemento de encaminhamento FORCES. A arquitetura de elemento de encaminhamento descreve como projetar o protocolo que realmente permite que um controlador FORCES programe um elemento de encaminhamento FORCES. Um indivíduo versado na técnica compreenderia que um sistema baseado em FORCES poderia incluir recursos descritos no presente documento em relação à modalidade OpenFlow, tal como a extensão OpenFlow GTP, para permitir que o controlador programe os comutadores para um roteamento TEID GTP.

[00132] FORCES e OpenFlow são proporcionados a título de exemplo e sem limitação. Um indivíduo versado na técnica compreenderia que os princípios e recursos descritos anteriormente em relação aos protocolos FORCES e OpenFlow também podem ser implementados em outros protocolos de controle similares.

[00133] Portanto, descreveram-se um método, um sistema e um aparelho para implementar um PC 3G em um sistema computacional em nuvem. Deve-se compreender que a descrição anterior é destinada a ser ilustrativa e não restritiva.

[00134] Muitas outras modalidades se tornarão aparentes aos indivíduos versados na técnica mediante a leitura e a compreensão da descrição anterior. Portanto, o escopo da invenção deve ser determinado como referência às reivindicações em anexo, junto ao escopo completo de equivalentes aos quais tais reivindicações são designadas.

Claims (14)

1. Método para implementar um protocolo de túnel (GTP) de serviço geral de rádio por pacotes (GPRS) em um núcleo de pacote (PC) de uma rede de terceira geração (3G) tendo uma arquitetura dividida onde um plano de controle do PC da rede 3G se encontra em um sistema computacional em nuvem, sendo que o sistema computacional em nuvem inclui um controlador, sendo que o plano de controle se comunica com o plano de dados do PC através de um protocolo de plano de controle, o plano de dados implementado em uma pluralidade de elementos de rede da rede 3G separado do sistema computacional em nuvem, o método caracterizado pelo fato de que compreende as etapas de: receber uma solicitação pelo controlador para criar um túnel GTP no PC da rede 3G entre um nó de suporte GPRS de serviço (SGSN) e um nó de suporte GPRS de porta (GGSN) para uma sessão de assinante, o controlador executando uma pluralidade de módulos de plano de controle que gerenciam o plano de dados da pluralidade de elementos de rede através do protocolo de plano de controle; configurar um comutador que implementa um plano de dados do SGSN, através do protocolo de controle, para encapsular e desencapsular pacotes da sessão de assinante e estabelecer um primeiro ponto final de túnel GTP; configurar pelo menos um comutador em uma rota do túnel GTP, através do protocolo de plano de controle, para encaminhar pacotes da sessão de assinante de acordo com o túnel GTP; e configurar um comutador que implementa um plano de dados do GGSN, através do protocolo de plano de controle, para encapsular e desencapsular os pacotes da sessão de assinante e estabelecer um segundo ponto final de túnel GTP.

2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que receber a solicitação pelo controlador para criar um túnel GTP compreende ainda a etapa de receber uma solicitação de criação de contexto de pacote de dados de protocolo (PDP) a partir de um componente de plano de controle do SGSN.

3. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que receber a solicitação pelo controlador para criar um túnel GTP compreende ainda a etapa de receber uma solicitação de atualização de roteamento GTP a partir de um componente de plano de controle do GGSN.

4. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende ainda as etapas de: receber uma solicitação pelo controlador para modificar o túnel GTP no PC da rede 3G entre o SGSN e o GGSN para a sessão de assinante; modificar uma configuração do comutador que implementa o plano de dados do SGSN, através do protocolo de plano de controle, para encapsular e desencapsular pacotes da sessão de assinante e modificar o primeiro ponto final de túnel GTP; e modificar uma configuração do comutador que implementa o plano de dados do GGSN, através do protocolo de plano de controle, para encapsular e desencapsular os pacotes da sessão de assinante e modificar o segundo ponto final de túnel GTP.

5. Método, de acordo com a reivindicação 4, caracterizado pelo fato de que compreende ainda a etapa de remover a configuração de pelo menos um comutador na rota do túnel GTP, através do protocolo de plano de controle, para finalizar o encaminhamento de pacotes da sessão de assinante de acordo com o túnel GTP.

6. Método, de acordo com a reivindicação 5, caracterizado pelo fato de que compreende ainda a etapa de configurar um comutador em uma nova rota do túnel GTP, através do protocolo de plano de controle, para encaminhar pacotes da sessão de assinante de acordo com o túnel GTP.

7. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende ainda as etapas de: receber uma solicitação pelo controlador para deletar o túnel GTP no PC da rede 3G entre o SGSN e o GGSN para a sessão de assinante; remover uma configuração do comutador que implementa o plano de dados do SGSN, através do protocolo de plano de controle, para finalizar a encapsulação e a desencapsulação de pacotes da sessão de assinante e remover o primeiro ponto final de túnel GTP; e remover uma configuração do comutador que implementa o plano de dados do GGSN, através do protocolo de plano de controle, para finalizar a encapsulação e a desencapsulação dos pacotes da sessão de assinante e remover o segundo ponto final de túnel GTP.

8. Sistema computacional em nuvem para gerenciar a implementação de um protocolo de túnel (GTP) de serviço geral de rádio por pacotes (GPRS) em um núcleo de pacote (PC) de uma rede de terceira geração (3G) tendo uma arquitetura dividida onde um plano de controle do PC da rede 3G se encontra no sistema computacional em nuvem, sendo que o plano de controle se comunica com um plano de dados do PC através de um protocolo de plano de controle, o plano de dados implementado em uma pluralidade de elementos de rede da rede 3G separado do sistema computacional em nuvem, o sistema computacional em nuvem caracterizado pelo fato de que compreende: uma pluralidade de servidores em comunicação entre si e em comunicação com a pluralidade de elementos de rede que implementa o plano de dados do PC, sendo que a pluralidade de servidores executa, um controlador configurado para executar uma pluralidade de módulos de plano de controle que implementa o plano de controle do PC, sendo que cada módulo de plano de controle provê um conjunto de funções de plano de controle para gerenciar o plano de dados, o controlador configurado para receber uma solicitação para criar um túnel GTP no PC da rede 3G entre um nó de suporte GPRS de serviço (SGSN) e um nó de suporte GPRS de porta (GGSN) para uma sessão de assinante, o controlador configurado para configurar um comutador que implementa um plano de dados do SGSN, através do protocolo de plano de controle, para encapsular e desencapsular pacotes da sessão de assinante e estabelecer um primeiro ponto final de túnel GTP, o controlador configurado para configurar pelo menos um comutador em uma rota do túnel GTP, através do protocolo de plano de controle, para encaminhar pacotes da sessão de assinante de acordo com o túnel GTP, e o controlador configurado para configurar um comutador que implementa um plano de dados do GGSN, através do protocolo de plano de controle, para encapsular e desencapsular os pacotes da sessão de assinante e estabelecer um segundo ponto final de túnel GTP; e um gerenciador de nuvem comunicativamente acoplado ao controlador, o gerenciador de nuvem configurado para gerenciar a execução da pluralidade de módulos de plano de controle do PC.

9. Sistema computacional em nuvem, de acordo com a reivindicação 8, caracterizado pelo fato de que o controlador recebe a solicitação para criar um túnel GTP como uma solicitação de criação de contexto de pacote de dados de protocolo (PDP) a partir de um componente de plano de controle do SGSN.

10. Sistema computacional em nuvem, de acordo com a reivindicação 8, caracterizado pelo fato de que o controlador recebe a solicitação para criar um túnel GTP como uma solicitação de atualização de roteamento GTP a partir de um componente de plano de controle do GGSN.

11. Sistema computacional em nuvem, de acordo com a reivindicação 8, caracterizado pelo fato de que o controlador é configurado para receber uma solicitação para modificar o túnel GTP no PC da rede 3G entre o SGSN e o GGSN para a sessão de assinante, sendo que o controlador é configurado para modificar a configuração do comutador que implementa o plano de dados do SGSN, através do protocolo de plano de controle, para encapsular e desencapsular pacotes da sessão de assinante e modificar o primeiro ponto final de túnel GTP, e o controlador é configurado para modificar a configuração do comutador que implementa o plano de dados do GGSN, através do protocolo de plano de controle, para encapsular e desencapsular os pacotes da sessão de assinante e modificar o segundo ponto final de túnel GTP.

12. Sistema computacional em nuvem, de acordo com a reivindicação 11, caracterizado pelo fato de que o controlador é configurado para remover a configuração do pelo menos um comutador na rota do túnel GTP, através do protocolo de plano de controle, para finalizar o encaminhamento de pacotes da sessão de assinante de acordo com o túnel GTP.

13. Sistema computacional em nuvem, de acordo com a reivindicação 12, caracterizado pelo fato de que o controlador é configurado para configurar um comutador em uma nova rota do túnel GTP, através do protocolo de plano de controle, para encaminhar pacotes da sessão de assinante de acordo com o túnel GTP.

14. Sistema computacional em nuvem, de acordo com a reivindicação 8, caracterizado pelo fato de que o controlador é adaptado para receber uma solicitação pelo controlador para deletar o túnel GTP no PC da rede 3G entre o SGSN e o GGSN para a sessão de assinante, sendo que o controlador é configurado para remover a configuração do comutador que implementa o plano de dados do SGSN, através do protocolo de plano de controle, para finalizar a encapsulação e a desencapsulação de pacotes da sessão de assinante e remover o primeiro ponto final de túnel GTP, e o controlador é configurado para remover a configuração do comutador que implementa o plano de dados do GGSN, através do protocolo de plano de controle, para finalizar a encapsulação e a desencapsulação dos pacotes da sessão de assinante e remover o segundo ponto final de túnel GTP.

Images