BR112017018018B1 - Método operacional em um dispositivo cliente, dispositivo cliente,método operacional em um dispositivo gateway, dispositivo gateway e método operacional em um nó de acesso associado a um dispositivo cliente - Google Patents
Método operacional em um dispositivo cliente, dispositivo cliente,método operacional em um dispositivo gateway, dispositivo gateway e método operacional em um nó de acesso associado a um dispositivo cliente Download PDFInfo
- Publication number
- BR112017018018B1 BR112017018018B1 BR112017018018-9A BR112017018018A BR112017018018B1 BR 112017018018 B1 BR112017018018 B1 BR 112017018018B1 BR 112017018018 A BR112017018018 A BR 112017018018A BR 112017018018 B1 BR112017018018 B1 BR 112017018018B1
- Authority
- BR
- Brazil
- Prior art keywords
- network token
- network
- token
- client device
- access node
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims description 114
- 230000011664 signaling Effects 0.000 claims abstract description 57
- 238000012795 verification Methods 0.000 claims abstract description 42
- 230000004044 response Effects 0.000 claims description 70
- 238000012545 processing Methods 0.000 claims description 35
- 238000009795 derivation Methods 0.000 claims description 20
- 238000007689 inspection Methods 0.000 claims description 12
- 238000012986 modification Methods 0.000 claims description 11
- 230000004048 modification Effects 0.000 claims description 11
- 230000004913 activation Effects 0.000 claims description 8
- 238000011017 operating method Methods 0.000 claims 3
- 238000013459 approach Methods 0.000 abstract description 2
- 230000006870 function Effects 0.000 description 61
- 238000010586 diagram Methods 0.000 description 20
- 238000010200 validation analysis Methods 0.000 description 19
- 238000004891 communication Methods 0.000 description 14
- 230000008569 process Effects 0.000 description 12
- 238000001914 filtration Methods 0.000 description 10
- 230000001413 cellular effect Effects 0.000 description 8
- 230000008901 benefit Effects 0.000 description 7
- 239000000969 carrier Substances 0.000 description 6
- 230000003287 optical effect Effects 0.000 description 6
- 238000007726 management method Methods 0.000 description 5
- 230000003213 activating effect Effects 0.000 description 4
- 238000012913 prioritisation Methods 0.000 description 3
- 230000011218 segmentation Effects 0.000 description 3
- 238000012546 transfer Methods 0.000 description 3
- 230000005641 tunneling Effects 0.000 description 3
- 230000005540 biological transmission Effects 0.000 description 2
- 230000000295 complement effect Effects 0.000 description 2
- 238000000605 extraction Methods 0.000 description 2
- 238000013507 mapping Methods 0.000 description 2
- 239000002245 particle Substances 0.000 description 2
- 238000013475 authorization Methods 0.000 description 1
- 230000010267 cellular communication Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000007717 exclusion Effects 0.000 description 1
- 230000007774 longterm Effects 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 230000006855 networking Effects 0.000 description 1
- 230000000246 remedial effect Effects 0.000 description 1
- 239000013589 supplement Substances 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
- H04L47/2475—Traffic characterised by specific attributes, e.g. priority or QoS for supporting traffic characterised by the type of applications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
- H04L12/1485—Tariff-related aspects
- H04L12/1496—Tariff-related aspects involving discounts
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/38—Flow based routing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/20—Traffic policing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/215—Flow control; Congestion control using token-bucket
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
- H04L47/2483—Traffic characterised by specific attributes, e.g. priority or QoS involving identification of individual flows
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0227—Filtering policies
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/02—Traffic management, e.g. flow control or congestion control
- H04W28/10—Flow control between communication endpoints
- H04W28/12—Flow control between communication endpoints using signalling between network elements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/24—Accounting or billing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/10—Connection setup
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
imposição de política eficiente com o uso de tokens de rede para abordagem de plano c de serviços. trata-se de um dispositivo que estabelece fluxos associados a um ou mais aplicativos com o uso de sinalização de plano de controle. um dispositivo de porta de comunicação obtém uma solicitação para um token de rede durante a sinalização de plano de controle. o dispositivo de porta de comunicação deriva o token de rede e envia o mesmo para o dispositivo e/ou um nó de acesso durante a sinalização de plano de controle. o dispositivo e/ou nó de acesso obtêm o token de rede, em que o token de rede é associado a um primeiro fluxo do um ou mais fluxos, um primeiro aplicativo dentre o um ou mais aplicativos, e provisionado para o dispositivo ou nó de acesso por meio da sinalização de plano de controle. o token de rede pode ser incluído em um pacote enviado do plano de usuário a partir do dispositivo. o token de rede pode ser verificado no nó de acesso e/ou no dispositivo de porta de comunicação com o uso de uma função criptográfica e enviado para seu destino com base nos resultados da verificação.
Description
[0001] Este pedido reivindica a prioridade do Pedido Provisório no U.S. 62/120.135, depositado em 24 de fevereiro de 2015, intitulado Efficient Policy Enforcement Using Network Access Tokens For Services C-Plane Approach, e Pedido Não Provisório no U.S. 14/832.965, depositado em 21 de agosto de 2015, cujos conteúdos são incorporados ao presente documento a título de referência.
[0002] Um aspecto refere-se, de maneira geral, a tokens de rede, e, mais especificamente, à derivação, provisionamento e uso de tokens de rede que são associados a fluxos de dados para facilitar o direcionamento de pacote e/ou verificação de que um dispositivo esteja acessando apenas serviços de aplicativo autorizados.
[0003] Alguns dispositivos do cliente podem ter acesso à rede, mas seu acesso à rede pode ser limitado a um conjunto de serviços de aplicativo. Em um exemplo, um acesso à rede do dispositivo cliente pode ser promovido por um provedor de serviço de aplicativo particular. O dispositivo cliente pode ser limitado a serviços de aplicativo executados pelo provedor de serviço de aplicativo em seu servidor. Em outro exemplo, um dispositivo cliente com acesso a rede pode ser parte de um acordo que permite carregamento ou manuseio de dados especial (por exemplo, taxa de bits de qualidade de serviço) associado a um dado serviço de aplicativo. Por exemplo, um dispositivo cliente pode ter uma assinatura de celular através de um provedor de celular e esse provedor de celular pode desejar impor uma ou mais restrições ao dispositivo cliente. Em um exemplo, uma corporação que hoje é conhecida como um provedor de mídia social, mas não conhecida como um provedor de celular, pode desempenhar um papel como um provedor de celular. Nesse exemplo, o dispositivo cliente pode ter uma assinatura com a corporação. Como parte de seu acordo de assinatura, o dispositivo cliente pode obter acesso à Internet, mas pode ser restrito a usar o site da mídia social da corporação à exclusão de outros sites de mídia social. Como outro exemplo, um dispositivo cliente pode ter uma assinatura com um provedor de serviços de mídia de transmissão contínua. Nesse exemplo, como parte de um acordo, o dispositivo cliente pode obter acesso à Internet através de vários provedores de celular, mas pode ser restrito por acordo (entre o provedor de serviços de mídia de transmissão contínua e os vários provedores de celular e/ou o usuário do dispositivo cliente) a usar o site do provedor serviços de mídia de transmissão contínua para todos os serviços de mídia de transmissão contínua. Como ainda mais outro exemplo, para certos nomes de ponto de acesso (APNs), pode ser permitido que apenas certo tráfego seja enviado a partir de um dispositivo cliente com base em uma política ou limitação de assinatura.
[0004] Políticas podem ser instituídas em conexão com serviços de aplicativo para garantir que um dispositivo cliente não esteja violando quaisquer acordos, esteja recebendo acesso a um dado serviço de aplicativo e/ou esteja recebendo um nível de serviço acordado. Tais políticas podem ser impostas a pacotes de enlace ascendente (UL) enviados a partir de um dispositivo cliente em direção a, por exemplo, um servidor em uma rede de dados em pacote (por exemplo, a Internet).
[0005] Atualmente, a imposição de política a serviços de aplicativo ocorre em um gateway para uma rede. Um exemplo desse gateway é um gateway de rede de dados em pacote (P-GW), que serve como um gateway entre uma rede principal (por exemplo, rede principal de pacotes evoluída (EPC)) e uma rede de dados em pacote, tal como a Internet. Existe um problema em que a imposição de políticas de acesso a serviço pode exigir uma P-GW para validar todos os pacotes de UL enviados a partir de um dispositivo cliente. Além disso, cada pacote de UL pode precisar ser dirigido para seu endereço de destino por meio de um portador particular.
[0006] A validação de pacotes de UL na P-GW pode ser necessária para garantir que um dispositivo cliente esteja apenas enviando pacotes para um serviço de aplicativo autorizado. A validação pode incluir verificar o endereço de destino ou o endereço de destino e número de porta de pacotes que passam através da P-GW. Adicionalmente, verificar o endereço de fonte de cada pacote pode ser útil para antifalsificação (por exemplo, impedindo-se que pacotes a partir de dispositivos do cliente não autorizados enganem o sistema parecendo chegar a partir de um dispositivo cliente autorizado). O direcionamento de pacote pode ser necessário para garantir que uma qualidade de serviço (QoS) contratada seja alcançada.
[0007] As práticas atuais incorrem em sobrecarga substancial e adicionam latência de encaminhamento devido a atraso de processamento. A prática atual é, tipicamente, realizada com o uso de inspeção de pacote (por exemplo, inspeção profunda de pacotes, inspeção superficial de pacotes) e modelo de fluxo de tráfego (TFT) e modelos de fluxo de dados de serviço (SDF). A P-GW confirma que os pacotes de UL se conformam para um modelo de TFT/SDF definido para o serviço (ou serviços) inspecionando-se os cabeçalhos de cada pacote.
[0008] Controle refinado de política (por exemplo, por aplicativo) é difícil devido ao fato de que controle adicional de política incorreria em sobrecarga adicional e atraso de processamento devido ao fato de que um pacote precisaria para ser testado contra regras de filtragem adicionais realizadas por modelos de TFT/SDF. Além disso, o uso de modelos de TFT/SDF não é escalonável para a conectividade promovida. Um aumento no número de promotores de serviços diferentes (talvez milhares de serviços nos próximos anos) significaria um aumento no tempo necessário para filtrar pacotes através de um número aumentado correspondentemente de modelos de TFT/SDF. Isso, novamente, incorreria em sobrecarga e atraso de processamento adicionais.
[0009] Portanto é exigida uma alternativa para complementar e/ou aprimorar a inspeção de pacote.
[0010] De acordo com um aspecto, um método pode ser operacional em um dispositivo. O método pode incluir estabelecer um conjunto de um ou mais fluxos associados a um ou mais aplicativos com o uso de sinalização de plano de controle e obter, no dispositivo durante a sinalização de plano de controle, um primeiro token de rede. O primeiro token de rede pode ser associado a um primeiro fluxo do conjunto de um ou mais fluxos, associado a um primeiro aplicativo dentre os um ou mais aplicativos, e provisionado para o dispositivo por meio da sinalização de plano de controle. O método também pode incluir enviar o primeiro token de rede a partir do dispositivo com um pacote que é associado ao primeiro fluxo. De acordo com alguns aspectos, o método pode incluir enviar o primeiro token de rede a partir do dispositivo sendo que cada pacote enviado a partir do dispositivo é associado ao primeiro fluxo. O primeiro token de rede pode ser derivado de acordo com uma política de acesso de rede. O mesmo pode ser usado para dirigir um pacote no primeiro fluxo para o primeiro aplicativo.
[0011] O primeiro token de rede pode ser provisionado em resposta a uma solicitação explícita ou implícita para o primeiro token de rede. A solicitação implícita pode incluir uma dentre uma mensagem de solicitação de conexão de rede de dados em pacote (PDN), uma mensagem de solicitação de ativação portador dedicado ou uma mensagem de solicitação de modificação portador.
[0012] De acordo com alguns aspectos, o primeiro token de rede pode ser transportado a partir do dispositivo para um dispositivo gateway em um cabeçalho shim em uma camada shim entre uma camada de protocolo Internet (IP) e uma camada de controle de acesso ao meio (MAC), um cabeçalho de protocolo de convergência de dados em pacote (PDCP), e/ou um cabeçalho de extensão de IP conforme definido em IP versão 6 (IPv6). Quando transportado no cabeçalho shim, o primeiro token de rede pode ser transparente para um nó de acesso. De acordo com alguns aspectos, o primeiro token de rede pode ser transportado a partir do dispositivo para um nó de acesso em um cabeçalho shim em uma camada shim entre uma camada de protocolo Internet (IP) e uma camada de controle de acesso ao meio (MAC), e/ou um cabeçalho de protocolo de convergência de dados em pacote (PDCP).
[0013] De acordo com alguns aspectos, um segundo token de acesso à rede pode ser obtido no dispositivo durante a sinalização de plano de controle. O segundo token de rede pode ser derivado por um segundo dispositivo que é diferente de um primeiro dispositivo que derivou o primeiro token. O mesmo pode ser associado ao primeiro fluxo do conjunto de um ou mais fluxos, associado ao primeiro aplicativo dentre os um ou mais aplicativos, e provisionado para o dispositivo por meio da sinalização de plano de controle.
[0014] O dispositivo pode incluir uma interface de rede e um circuito de processamento acoplado à interface de rede. O circuito de processamento pode ser configurado para estabelecer um conjunto de um ou mais fluxos associados a um ou mais aplicativos com o uso de sinalização de plano de controle, obter, no dispositivo durante a sinalização de plano de controle, um token de rede, em que o token de rede é associado a um primeiro fluxo do conjunto de um ou mais fluxos, associado a um primeiro aplicativo dentre os um ou mais aplicativos, e provisionado para o dispositivo por meio da sinalização de plano de controle.
[0015] De acordo com um aspecto, um método, operacional em um dispositivo gateway, pode incluir obter, no dispositivo gateway, uma solicitação para um token de rede durante a sinalização de plano de controle associada ao estabelecimento, ativação ou modificação de conexão de dados associado a um dispositivo cliente. O método pode adicionalmente incluir derivar, no dispositivo gateway, o token de rede, o token de rede associado a um fluxo e um serviço de aplicativo de acordo com uma política de acesso e enviar, por meio de sinalização de plano de controle, o token de rede para o dispositivo cliente ou para um nó de acesso associado ao dispositivo cliente durante a sinalização de plano de controle. O token de rede pode ser usado para dirigir pacotes que transitam entre o dispositivo cliente e o serviço de aplicativo durante a transmissão por uma rede através do dispositivo gateway. A solicitação para o token de rede pode ser explícita. A solicitação para o token de rede pode ser implícita. A solicitação pode ser reconhecida implicitamente em decorrência de obter, no dispositivo gateway, uma solicitação de conexão à rede de dados em pacote (PDN), uma solicitação de ativação portador dedicado ou uma solicitação de modificação portador.
[0016] De acordo com um aspecto, a derivação do token de rede pode ser com base em uma chave secreta específica para um nó de acesso ao qual o dispositivo cliente está conectado. Um método de acordo com esse aspecto pode incluir enviar a chave secreta para o nó de acesso.
[0017] De acordo com um aspecto, o token de rede pode ser derivado como um token de rede de enlace ascendente e um token de rede de enlace descendente, diferente do token de rede de enlace ascendente. A derivação do token de rede de enlace ascendente pode ser com base em uma chave conhecida pelo dispositivo gateway e em um parâmetro associado ao dispositivo cliente. A derivação do token de rede de enlace descendente pode ser com base na chave conhecida pelo dispositivo gateway e em um parâmetro associado a um servidor de aplicativos. De acordo com esse aspecto, o método pode incluir enviar o token de rede de enlace ascendente e o token de rede de enlace descendente para o dispositivo cliente.
[0018] De acordo com um aspecto, um dispositivo gateway pode obter um primeiro pacote que inclui o token de rede. O dispositivo gateway pode dirigir o primeiro pacote entre o dispositivo cliente e o serviço de aplicativo com o uso de dados associados ao token de rede incluído no primeiro pacote sem o uso de inspeção de pacote. O dispositivo gateway pode verificar o token de rede com o uso de uma chave conhecida pelo dispositivo gateway . O dispositivo gateway pode atuar descartando-se o primeiro pacote que inclui o token de rede caso a verificação não seja bem sucedida. O dispositivo gateway pode atuar dirigindo-se o primeiro pacote entre o dispositivo cliente e o serviço de aplicativo com o uso do token de rede incluído no primeiro pacote sem o uso de inspeção de pacote caso a verificação seja bem sucedida. A verificação do token de rede pode incluir derivar um token de rede de verificação a partir de uma função que tem um conjunto de parâmetros de entrada que inclui a chave conhecida pelo dispositivo gateway, e um índice de parâmetro de token de rede, endereço de protocolo Internet (IP) de fonte, número de porta de origem, endereço IP de destino, número de porta de destino, identificador (ID) de protocolo, ID de aplicativo, prioridade e/ou um identificador de classe de qualidade de serviço (QCI). A verificação pode, então, incluir adicionalmente comparar o token de rede ao token de rede de verificação. Em alguns aspectos, o índice de parâmetro de token de rede, endereço de protocolo Internet (IP) de fonte, número de porta de origem, endereço IP de destino, número de porta de destino, identificador (ID) de protocolo, ID de aplicativo, prioridade e/ou identificador de classe de qualidade de serviço (QCI) são obtidos a partir do pacote.
[0019] De acordo com alguns aspectos, um método pode incluir identificar um índice de parâmetro de token de rede antes de verificar o token de rede, em que o índice de parâmetro de token de rede define uma lista de parâmetros de entrada. Esse método também pode incluir derivar um token de rede de verificação a partir de uma função que tem, como entrada, a chave conhecida pelo dispositivo gateway e a lista de parâmetros de entrada. O índice de parâmetro de token de rede pode definir um identificador (ID) de aplicativo. A lista de parâmetros de entrada pode ser armazenada em uma tabela no dispositivo gateway . O token de rede pode ser transportado em um cabeçalho shim separado de um cabeçalho de IP. O token de rede pode ser transportado em um cabeçalho de protocolo de túnel (GTP) de serviço de rádio de pacote geral (GPRS). O token de rede pode ser transportado em um cabeçalho de extensão de IP definido no protocolo Internet (IP) versão 6 (IPv6).
[0020] De acordo com um aspecto, um dispositivo gateway pode incluir uma interface de rede e um circuito de processamento acoplado à interface de rede. O circuito de processamento pode ser configurado para obter uma solicitação para um token de rede durante a sinalização de plano de controle associada ao estabelecimento, ativação ou modificação de conexão de dados associada a um dispositivo cliente, obter o token de rede, em que o token de rede é associado a um fluxo e um serviço de aplicativo de acordo com uma política de acesso, e enviar, por meio de sinalização de plano de controle, o token de rede para o dispositivo cliente ou para um nó de acesso associado ao dispositivo cliente durante a sinalização de plano de controle.
[0021] De acordo com alguns aspectos, um método, operacional em um nó de acesso, pode incluir obter, no nó de acesso durante a sinalização de plano de controle, um token de rede. O token de rede pode ser associado a um primeiro fluxo de um conjunto de um ou mais fluxos, associado a um primeiro aplicativo dentre um ou mais aplicativos, e provisionado para o nó de acesso por meio da sinalização de plano de controle. O método pode adicionalmente incluir enviar, a partir do nó de acesso, o token de rede com um pacote associado ao primeiro fluxo. O método pode adicionalmente incluir enviar, a partir do nó de acesso, o token de rede com cada pacote associado ao primeiro fluxo. O token de rede pode ser associado ao conjunto de um ou mais fluxos associados a um ou mais aplicativos.
[0022] De acordo com outro aspecto, um método, operacional em um nó de acesso, pode incluir obter, na sinalização de plano de controle, uma chave secreta específica para o nó de acesso a partir de um dispositivo gateway . O método pode adicionalmente incluir obter, na sinalização de plano de usuário, um pacote no nó de acesso a partir de um dispositivo cliente, em que o pacote inclui um token de rede. O nó de acesso pode atuar verificando-se o token de rede com o uso de uma chave secreta específica para o nó de acesso obtida a partir do dispositivo gateway e enviar o pacote e token de rede para o dispositivo gateway caso o token de rede seja verificado, ou descartar o pacote e token de rede caso o token de rede não seja verificado. O token de rede pode ser transportado em um cabeçalho de protocolo de túnel (GTP) de serviço de rádio de pacote geral (GPRS) para o dispositivo gateway . O token de rede pode ser copiado de um cabeçalho de protocolo de convergência de dados em pacote (PDCP) para um cabeçalho de protocolo de túnel de serviço de rádio de pacote geral (cabeçalho de GTP) e transportado no cabeçalho de GTP para o dispositivo gateway . De acordo com alguns aspectos, o token de rede é para impor uma política de acesso associada a um serviço de aplicativo e a chave secreta específica para o nó de acesso é para validar o token de rede incluído em pacotes recebidos no nó de acesso antes de enviar os pacotes para o dispositivo gateway para impedir que pacotes não autorizados alcancem o dispositivo gateway .
[0023] De acordo com um aspecto, um nó de acesso pode incluir uma interface de rede e um circuito de processamento acoplado à interface de rede. O circuito de processamento pode ser configurado para obter, na sinalização de plano de controle, uma chave secreta específica para o nó de acesso a partir de um dispositivo gateway . O circuito de processamento pode ser configurado adicionalmente para obter, na sinalização de plano de usuário, um pacote no nó de acesso a partir de um dispositivo cliente, o pacote que inclui um token de rede. O circuito de processamento pode ser ainda configurado adicionalmente para verificar o token de rede com o uso de uma chave secreta específica para o nó de acesso obtida a partir de um dispositivo gateway e enviar o pacote e token de rede para um dispositivo gateway caso o token de rede seja verificado, ou descartar o pacote e token de rede caso o token de rede não seja verificado.
[0024] De acordo com alguns aspectos, um método, operacional em um dispositivo gateway , pode incluir obter, no dispositivo gateway , um pacote a partir de um servidor de aplicativos. O pacote pode incluir um token de rede de enlace descendente. O método pode incluir verificar o token de rede de enlace descendente com o uso de uma chave conhecida pelo dispositivo gateway , descartar o pacote caso a verificação não seja bem sucedida, e descartar o token de rede de enlace descendente e enviar o pacote para um dispositivo cliente com base em parâmetros representados pelo token de rede de enlace descendente caso a verificação seja bem sucedida. O pacote pode ser um pacote de dados de protocolo Internet (IP).
[0025] A Figura 1 ilustra um ambiente operacional exemplificativo.
[0026] A Figura 2 ilustra uma operação de enlace ascendente exemplificativa.
[0027] A Figura 3 é um diagrama que ilustra um fluxo de chamada exemplificativo em que um token de rede pode ser emitido para um dispositivo cliente por uma P-GW.
[0028] A Figura 4 é um diagrama que ilustra um fluxo de chamada exemplificativo em que um token de rede pode ser emitido para um nó de acesso (por exemplo, eNóB) por uma P-GW.
[0029] A Figura 5 é um diagrama que ilustra um fluxo de chamada exemplificativo em que uma P-GW pode emitir um token de rede para um dispositivo cliente e também pode emitir uma chave secreta específica para um nó de acesso para o nó de acesso.
[0030] A Figura 6 é um diagrama que ilustra um fluxo de chamada exemplificativo em que um primeiro token de rede (por exemplo, token de rede 1) pode ser emitido para um dispositivo cliente por uma P-GW e um segundo token de rede (por exemplo, token de rede 2), diferente do primeiro, pode ser emitido para o dispositivo cliente por um nó de acesso associado ao dispositivo cliente.
[0031] A Figura 7 é um diagrama que ilustra um fluxo de chamada exemplificativo em que dois tokens de rede (por exemplo, um token de rede de enlace ascendente e um token de rede de enlace descendente) podem ser emitidos para um dispositivo cliente por uma P-GW.
[0032] A Figura 8 é uma ilustração exemplificativa de pilhas de protocolos do plano de usuário de um sistema de acordo com um aspecto descrito no presente documento.
[0033] A Figura 9 é uma ilustração exemplificativa de pilhas de protocolos do plano de usuário de um sistema, de acordo com outro aspecto descrito no presente documento.
[0034] A Figura 10 é uma ilustração exemplificativa de pilhas de protocolos do plano de usuário de um sistema de acordo com ainda outro aspecto descrito no presente documento.
[0035] A Figura 11 é uma ilustração exemplificativa de pilhas de protocolos do plano de usuário de um sistema de acordo com ainda outro aspecto descrito no presente documento.
[0036] A Figura 12 é uma ilustração exemplificativa de pilhas de protocolos do plano de usuário de um sistema de acordo com ainda outro aspecto descrito no presente documento.
[0037] A Figura 13 é uma ilustração exemplificativa de pilhas de protocolos do plano de usuário de um sistema de acordo com ainda outro aspecto descrito no presente documento.
[0038] A Figura 14 é um diagrama de blocos que ilustra um dispositivo exemplificativo adaptado para suportar acesso de aplicativo com base em token de rede.
[0039] A Figura 15 é um método exemplificativo através do qual um dispositivo pode obter um token de rede.
[0040] A Figura 16 é um método exemplificativo através do qual um dispositivo pode obter um token de rede a partir de um dispositivo gateway e um token de rede separado a partir de um nó de acesso.
[0041] A Figura 17 é um diagrama de blocos que ilustra um nó de acesso exemplificativo adaptado para suportar acesso de aplicativo com base em token.
[0042] A Figura 18 ilustra um método exemplificativo de estabelecer (por exemplo, derivar um token de rede e provisionar o token de rede para um dispositivo cliente) um token de rede em um nó de acesso (por exemplo, eNóB).
[0043] A Figura 19 é um fluxograma de um método exemplificativo operacional em um nó de acesso.
[0044] A Figura 20 é um fluxograma de outro método exemplificativo operacional em um nó de acesso.
[0045] A Figura 21 é fluxograma de ainda outro método exemplificativo operacional em um nó de acesso.
[0046] A Figura 22 é um diagrama de blocos que ilustra um gateway exemplificativo adaptado para suportar acesso de aplicativo com base em token.
[0047] A Figura 23 ilustra um método exemplificativo de estabelecer (por exemplo, derivar um token de rede e provisionar o token de rede para um dispositivo cliente) um token de rede em um gateway (por exemplo, uma P-GW).
[0048] A Figura 24 ilustra um método exemplificativo de estabelecer tokens de rede de enlace ascendente e de enlace descendente em um gateway (por exemplo, uma P-GW).
[0049] A Figura 25 é fluxograma de um método exemplificativo, operacional em um gateway.
[0050] Na descrição a seguir, é feita referência aos desenhos anexos em que são mostradas, a título de ilustração, modalidades específicas em que a revelação pode ser praticada. As modalidades são destinadas a descrever aspectos da revelação em detalhes suficientes para permitir que as pessoas versadas na técnica pratiquem a invenção. Outras modalidades podem ser utilizadas e mudanças podem ser feitas às modalidades reveladas sem que se afaste do escopo da revelação. A descrição detalhada a seguir não deve ser considerada em um sentido limitante, e o escopo da presente invenção é definido apenas pelas reivindicações anexas.
[0051] O termo “dispositivo” pode ser usado no presente documento para se referir a um componente de chip e/ou um dispositivo cliente, tal como um “dispositivo móvel”, “telefone móvel”, “dispositivos de comunicação móveis”, “dispositivos de computação móveis”, “computadores do tipo tablet digitais”, “telefones inteligentes”, “equipamento de usuário”, “dispositivo de usuário”, “terminal” entre outros dispositivos.
[0052] A Figura 1 ilustra um ambiente operacional exemplificativo 100. Nesse ambiente operacional exemplificativo 100 um ou mais dispositivos do cliente 102, 104 (por exemplo, dispositivo cliente A, dispositivo cliente B) podem se comunicar por conexão sem fio com um nó de acesso 106 (por exemplo, Nó B, eNóB, ponto de acesso (AP)). O nó de acesso 106 pode ser incluído dentro de uma rede de acesso de rádio (RAN) 108 (por exemplo, rede de acesso de rádio terrestre universal evoluída (E-UTRAN)). Conforme conhecido pelas pessoas versadas na técnica, a RAN 108, tipicamente, inclui mais do que um nó de acesso 106. Apenas um nó de acesso 106 é ilustrado para reduzir a desorganização no desenho. Em um exemplo não limitante de um sistema de comunicação celular (por exemplo, 4G, LTE, LTE-A) a RAN 108 pode comunicar sinais de controle e tráfego de dados para uma rede principal (CN) 110 (por exemplo, rede principal de pacotes evoluída (EPC)). Na ilustração da Figura 1, linhas tracejadas representam trajetórias de sinal de controle e linhas sólidas representam trajetórias de tráfego de dados. É dito que os sinais de controle são transportados por meio de um plano de controle. É dito que os dados de usuário são transportados por meio de um plano de usuário.
[0053] Uma CN 110 pode incluir uma entidade de gerenciamento de mobilidade (MME) 112, um gateway de serviço (S-GW) 116, um servidor de assinante doméstico (HSS) 118, e um gateway de rede de pacotes (P-GW) 120. A P-GW 120 pode se comunicar com uma rede de dados em pacote (PDN) 122 (por exemplo, a Internet). Mais especificamente, a P-GW 120 pode se comunicar com os servidores 124, 126, 128, 130 (por exemplo, servidores de aplicativos) na PDN 122. Os servidores 124, 126, 128, 130 podem ser associados a provedores de serviços, tais como, por exemplo, provedores de serviços que fornecem serviços de vendas, serviços de informações, serviços de transmissão contínua de vídeo e serviços de mídias sociais.
[0054] A Figura 2 ilustra uma operação de enlace ascendente exemplificativa 200. As operações de enlace ascendente exemplificativas 200 são apresentadas no contexto de um sistema de evolução de longo prazo (LTE) por conveniência. O exemplo não é destinado a colocar qualquer limitação ao escopo de quaisquer aspectos descritos no presente documento.
[0055] Em A Figura 2 são representados um dispositivo cliente 202 (por exemplo, equipamento de usuário, dispositivo de usuário, terminal, dispositivo móvel), um nó de acesso 204 (por exemplo, eNóB), um gateway de serviço (S-GW) 206, um gateway de pacote (P-GW) 208 e uma rede de dados em pacote (PDN) 210 (por exemplo, a Internet).
[0056] As operações de enlace ascendente exemplificativas 200 da Figura 2 são descritas agora. Os fluxos de IP 214 (por exemplo, a partir de aplicativos/serviços de aplicativo 212 do dispositivo cliente 202) são aplicados a filtros de pacote (não mostrados) incluídos com um modelo de fluxo de tráfego (TFT) 216. O número de fluxos de IP 214 representados é ilustrativo e não destinado a ser limitante.
[0057] Os filtros de pacote do TFT 216 filtram os fluxos de IP nos portadores 218 (por exemplo, portadores de sistema de pacotes evoluído (EPS)). Três portadores 218 (por exemplo, portador 1, portador N-1, e portador N) são ilustradas para propósitos demonstrativos. Em um aspecto, um portador pode ser compartilhada por múltiplos aplicativos/serviços de aplicativo. Cada portador pode ser associado a um conjunto único de parâmetros.
[0058] Os fluxos de IP 214 podem ser mapeados, por exemplo, para um portador padrão ou para um ou mais portadores dedicados. O portador padrão pode, tipicamente, ter uma taxa de bits não garantida, enquanto os portadores dedicados podem, tipicamente, ter taxas de bits garantidas ou não garantidas. Os portadores podem passar através do nó de acesso 204 e da S-GW 206. Aspectos do nó de acesso 204 e da S-GW 206 não são descritos no presente documento e são conhecidos pelas pessoas de habilidade comum na técnica.
[0059] Em um aspecto, os fluxos de IP 214 a partir dos portadores 218 podem ser passados para um circuito/função/módulo de decisão e processamento 220. O circuito/função/módulo de decisão e processamento 220 pode fazer com que pacotes de UL recebidos a partir dos portadores 218 sejam passados para um circuito/função/módulo de validação criptográfica e direção de tráfego 222 ou para modelos de fluxo de dados de serviço (SDF) 224 e filtros de pacote incluídos nos mesmos (não mostrados).
[0060] Os pacotes de UL que têm tokens de rede incluídos nos mesmos podem ser passados para o circuito/função/módulo de validação criptográfica e direção de tráfego 222. A imposição de uma ou mais políticas associadas a um token de rede pode ser realizada mediante validação bem sucedida do token de rede.
[0061] Os pacotes de UL que não têm tokens de rede incluídos nos mesmos podem ser passados para os modelos de SDF 224 pelo circuito/função/módulo de decisão e processamento 220. O uso dos filtros de pacote dos modelos de SDF 224 pode exigir mais recursos de processamento e memória do que o uso do circuito/função/módulo de validação criptográfica e direção de tráfego 222. Para realizar filtragem com o uso dos filtros de pacote dos modelos de SDF 224, por exemplo, a P-GW 208 precisa manter uma entrada de tabela separada para cada SDF.
[0062] Consequentemente, o uso de tokens de rede (e o consequente uso do circuito/função/módulo de validação criptográfica e direção de tráfego 222) economiza recursos e reduzi latência. Em um aspecto, um token de rede criptográfico (por exemplo, um token de software) pode ser usado para complementar/aprimorar a inspeção de pacote. Uma vantagem desse aspecto inclui escalabilidade. Isto é, nenhuma entrada de tabela ou estado precisa ser mantido em uma trajetória rápida (também conhecida como, passagem rápida). Outra vantagem desse aspecto inclui baixa latência. Isto é, uma única operação criptográfica (por exemplo, hash ou padrão de encriptação avançado (AES), seja qual for pode rodar mais rápido ou pode ser determinada apropriada) pode ser suficiente para controle de acesso.
[0063] Ainda outra vantagem pode incluir flexibilidade. Isto é, o token de rede criptográfico pode ser derivado com base em vários metadados. Tais metadados não são limitados aos parâmetros que são filtrados em modelos de TFT/SDF. Adicionalmente, várias políticas (por exemplo, políticas de autenticidade e/ou autorização de políticas de pacote) podem ser aplicadas ao token de rede. Ainda outra vantagem pode incluir uma resiliência a ataques de negação de serviço distribuídos (DDoS). Isto é, qualquer pacote que inclui um token de rede criptográfico errado/impróprio/não autêntico será descartado antes de ser enviado para um servidor (por exemplo, servidor 124, 126, 128, 130 da Figura 1) impedindo, desse modo, a inundação do servidor com pacotes. Ainda outra vantagem pode estar em uma característica de relocabilidade. A realização dessa vantagem pode ser entendida definindo-se/mapeando-se uma regra (ou conjunto de regras) de filtragem para uma chave secreta correspondente no primeiro gateway, e, então, compartilhando-se a chave secreta com o segundo gateway. Desse modo, durante uma mudança automática entre o primeiro e segundo gateway, o aspecto permite uma realocação de filtros de SDF por meio de uma transferência/compartilhamento da chave secreta. Isso elimina uma necessidade de transferir todos os dados relacionados à regra (ou conjunto de regras) de filtragem associada a um dado filtro de SDF. A vantagem de relocabilidade, portanto, libera recursos de processamento, que podem de outra forma ter sido usados para transferir todos os dados, para outros fins.
[0064] Uma característica se refere, em geral, a uma derivação por um dispositivo, tal como um dispositivo gateway, de um token de rede. O token de rede pode ser denominado no presente documento como um token, um token de rede ou um token de rede criptográfico. O token de rede pode ter como base um perfil de assinatura que reflita uma política de rede associada a um aplicativo e um dispositivo cliente. Em alguns aspectos, o token de rede pode ser derivado pelo dispositivo gateway e pode ser verificado apenas pelo dispositivo gateway . O token de rede pode ser associado a um fluxo de dados entre um serviço de aplicativo e um dispositivo cliente (por exemplo, dispositivo móvel, equipamento de usuário, dispositivo de usuário). O dispositivo gateway pode provisionar o token de rede para o dispositivo cliente. O dispositivo cliente pode incluir o token de rede em um ou mais pacotes de dados enviados para o serviço de aplicativo por meio do dispositivo gateway . O dispositivo gateway pode verificar o token de rede associado a cada um dentre o um ou mais pacotes e pode usar as informações associadas ao token de rede para dirigir o pacote para o serviço de aplicativo. Dois processos amplos são exemplificados no presente documento em conexão com aspectos exemplificativos relacionados a tokens de rede.
[0065] Um primeiro processo se refere ao “estabelecimento” dos tokens de rede. O estabelecimento pode envolver a derivação e provisionamento de um token de rede por meio de qualquer um dentre sinalização/mensagens no plano de controle (plano C). Exemplos não limitantes de estabelecimento de tokens de rede por meio de sinalização ou mensagens no plano C são fornecidos abaixo.
[0066] Um segundo processo se refere ao uso, e imposição de políticas com o uso, de tokens de rede. O uso e/ou imposição pode envolver incluir um token de rede em um ou mais pacotes de UL, em que a inclusão do token de rede em um pacote pode ocorrer, por exemplo, em um dispositivo cliente (por exemplo, dispositivo cliente 202, Figura 2) e/ou um nó de acesso (por exemplo, nó de acesso 204, Figura 2). O token pode ser adicionado ao pacote ou de outra forma associado ao mesmo. O uso e/ou imposição pode envolver adicionalmente uma função de rede de validação do token de rede. A validação do token de rede pode ocorrer, por exemplo, em uma P-GW (por exemplo, P-GW 208, Figura 2). Em alguns aspectos, a P-GW que derivou um token de rede enviado para um dispositivo cliente será a P-GW que valida o token de rede recebido a partir do dispositivo cliente. Em outras palavras, em alguns aspectos o nó (por exemplo, P-GW) que deriva o token é o único nó que também pode validar o token. A validação não envolveria necessariamente qualquer necessidade de filtragem. Uma única operação criptográfica (por exemplo, hash, AES) pode ser implantada. A pesquisa em memória, exigida quando se usa inspeção de pacote com modelos de TFT/SDF, pode não ser necessária.
[0067] No presente documento são apresentados exemplos de métodos e dispositivos que fazem uso de tokens de rede criptográficos para complementar, ou como uma alternativa a, métodos de acesso/controle de admissão conhecidos em sistemas de comunicação. Um gateway (por exemplo, uma P-GW) pode usar os tokens de rede criptográficos para filtrar tráfego não autorizado sem manter estados de fluxo, isto é, filtro sem estado. Além disso, um dispositivo cliente pode usar o token de rede criptográfico para associar um ou mais pacotes de UL com um fluxo de dados acordado (por exemplo, portador) e para dirigir os pacotes para um destino autorizado. Outras regras de controle de acesso podem ser incluídas, ou associadas, ao token de rede.
[0068] No presente documento são descritos métodos exemplificativos para estabelecer tokens para acesso/admissão e fluxo de tráfego de pacotes em uma rede de dados em pacote (PDN). Em seguida ao estabelecimento de token, são descritos no presente documento métodos exemplificativos de imposição de políticas de acesso/admissão por verificação do token de rede. Algoritmos criptográficos básicos (por exemplo, hash, AES) podem ser usados. Ao contrário de métodos atuais, nenhuma pesquisa em memória é necessária para impor políticas de acesso/admissão.
[0069] Nos aspectos descritos no presente documento, fluxos de IP, fluxos de dados ou fluxos, não precisam ser limitados a portadores conforme apresentado na ilustração exemplificativa da Figura 2. Um dispositivo cliente pode operar ou rodar um ou mais aplicativos. Cada aplicativo cliente pode ser mapeada para um serviço de aplicativo que opera ou roda em um servidor de aplicativos. Um fluxo pode, portanto, ser definido com base no aplicativo que opera no dispositivo e no servidor de aplicativos. Um fluxo pode ser definido como uma trajetória que os pacotes tomam entre o aplicativo que roda no dispositivo cliente e o serviço de aplicativo que roda no servidor de aplicativos. Embora um fluxo possa ser associado a um aplicativo que opera no dispositivo cliente, o fluxo não necessariamente identifica o dispositivo cliente. Um token de rede pode ser usado para identificar um ou mais fluxos. Consequentemente, um token de rede pode ser associado a múltiplos fluxos.
[0070] Um fluxo pode ser mapeado para múltiplos serviços que rodam no mesmo servidor em uma rede. Por exemplo, um dispositivo cliente pode usar um serviço oferecido por um provedor em um servidor. O servidor, tipicamente, tem um endereço de IP. No entanto, o serviço pode hospedar múltiplos aplicativos no servidor. Os múltiplos aplicativos podem incluir, por exemplo, um aplicativo de mapeamento, um aplicativo de busca de informações e um aplicativo de rede social. As múltiplos aplicativos, portanto, têm o mesmo endereço IP de destino, assim, da perspectiva de um gateway de uma rede principal (por exemplo uma P-GW), as múltiplos aplicativos podem ser consideradas como um único fluxo em vez de múltiplos fluxos. Consequentemente, um único fluxo pode ser mapeado para múltiplos serviços.
[0071] Um fluxo pode ser associado a múltiplos serviços. Além disso, um token de rede pode ser associado a múltiplos serviços em que os serviços podem ser rodados por múltiplos provedores de serviço de aplicativo. Por exemplo, um dispositivo cliente pode ter múltiplos promotores (por exemplo, múltiplos provedores de serviços). Em aspectos descritos no presente documento, um gateway pode derivar um token de rede que é associado aos múltiplos provedores de serviço de aplicativo. Consequentemente, um único token pode ser mapeado para um ou mais serviços de aplicativo que são, por sua vez, associados a um ou mais fluxos.
[0072] Em diversos exemplos fornecidos no presente documento, um token de rede pode ser derivado com base em um identificador de aplicativo (App ID). A derivação de tokens de rede, no entanto, não é limitada a tais exemplos. Outros parâmetros, e combinações de parâmetros podem ser usados para derivar um token de rede. O App ID pode ser associado a um ou mais servidores. Por exemplo, um dado provedor de serviço pode ter diferentes centros de processamento de dados (cada um com seu próprio servidor) em diferentes localizações geográfica. Nesse caso, o App ID seria associado a mais do que um servidor. O token pode usar, vantajosamente, o App ID em vez de um endereço IP do servidor. Um gateway pode verificar que o pacote, associado a um token de rede, está se encaminhando para um servidor de um dado provedor de serviço, mesmo que o token de rede não especifique um endereço IP do servidor destino.
[0073] Os exemplos apresentados no presente documento podem se aplicar a um procedimento de solicitação de conectividade de PDN inicial (durante o qual um portador padrão pode ser estabelecida) e a procedimentos de estabelecimento portador dedicado (durante os quais um ou mais portadores dedicados podem ser estabelecidos).
[0074] A Figura 3 é um diagrama que ilustra um fluxo de chamada exemplificativo 300 em que um token de rede pode ser emitido para um dispositivo cliente 302 por uma P- GW 310. O fluxo de chamada pode ser implantado no plano C. Um nó de acesso 304 (por exemplo, um eNóB) pode ser um independente. Isto é, o nó de acesso 304 pode não saber que um dispositivo cliente 302 enviou uma solicitação para um token de rede para a P-GW 310. A solicitação, e troca de tokens de rede, pode ser transparente para um nó de acesso independente 304. A Figura 3 inclui representações do dispositivo cliente 302, um nó de acesso 304, uma MME 306, uma S-GW 308, a P-GW 310, um servidor de função de política e regras de carregamento (PCRF) 312 e um servidor de assinante doméstico (HSS) 314.
[0075] No fluxo de chamada exemplificativo 300 da Figura 3, um dispositivo cliente 302 pode levar etapas para estabelecer uma conexão em geral, ou estabelecer uma conexão com um serviço. Em um aspecto, o dispositivo cliente 302 pode enviar 316 uma solicitação de conectividade de PDN para uma MME 306. Uma solicitação para um token de rede pode ser reconhecida implicitamente em conexão com ações tomadas pelo dispositivo cliente 302 para estabelecer a conexão. Por exemplo, uma solicitação para um token de rede pode ser reconhecida implicitamente em conexão com a solicitação de conectividade de PDN do dispositivo cliente 302. Alternativamente, a solicitação para o token de rede pode ser incluída explicitamente na solicitação de conexão enviada a partir do dispositivo cliente. Por exemplo, uma solicitação para um token de rede pode ser incluída explicitamente com a solicitação de conectividade de PDN. A solicitação para o token de rede pode incluir um identificador de aplicativo (App ID). Como ainda outra alternativa, o dispositivo cliente 302 pode não solicitar o token de rede, mas o token de rede pode ser atribuído no plano C. Por exemplo, outro nó, ou alguma política, pode exigir o uso de tokens de rede. Nesse aspecto alternativo, mesmo que o dispositivo cliente 302 não solicite o token de rede, um token de rede pode ainda assim ser provisionado para o dispositivo cliente no plano de controle.
[0076] Em resposta ao recebimento da solicitação de conectividade de PDN, a MME pode enviar 318 uma solicitação de sessão de criação para a S-GW 308. A solicitação para o token de rede pode ser copiada para, ou de outra forma incluída com, a solicitação de sessão de criação. A solicitação para o token de rede também pode incluir o identificador de aplicativo (App ID).
[0077] Em resposta ao recebimento da solicitação de sessão de criação, a S-GW 308 pode enviar 320 uma solicitação de sessão de criação para a P-GW 310. A solicitação para o token de rede pode ser copiada para, ou de outra forma incluída com, a solicitação de sessão de criação. A solicitação para o token de rede também pode incluir o identificador de aplicativo (App ID).
[0078] Em resposta ao recebimento da solicitação de sessão de criação, a P-GW 310 pode realizar 324 etapas para estabelecimento/modificação para uma rede de acesso de conectividade de IP (IP-CAN). Conforme conhecido para as pessoas versadas na técnica, uma IP-CAN é uma rede de acesso que fornece conectividade de protocolo de Internet (IP). O termo pode ser aplicável a redes celulares (por exemplo, redes 3GPP) bem como redes de área local sem fio (WLAN) (por exemplo, WiFi, HotSpot, etc.).
[0079] Além disso, em resposta ao recebimento da solicitação para o token de rede, a P-GW 310 pode obter ou derivar 326 o token de rede. Conforme usado no presente documento, o termo “derivar” pode significar derivar localmente ou obter a partir de outro dispositivo. Um token de rede pode ser um hash de parâmetros de entrada associados a um pacote. Em um aspecto, um token de rede pode ser validado em uma P-GW 310 recriando-se um token com o uso dos parâmetros de entrada do pacote e, então, comparando-se o token recriado com o token incluído com o pacote. Uma chave secreta conhecida pela P-GW 310 pode ser usada em uma função criptográfica para derivar o token de rede. Em um exemplo, a P-GW 310 pode derivar o token de rede em vista de uma política de acesso de aplicativo recuperada a partir de uma função de aplicativo (AF). Em um aspecto, a política de acesso pode associar um fluxo a um aplicativo. O token de rede pode adicionalmente ser derivado em vista do App ID, por exemplo, caso o App ID seja incluído com a solicitação para o token de rede. Em alguns aspectos, o token de rede pode incluir informações criptografadas. A decriptação pode ser realizada com o uso de uma função criptográfica que tem como sua entrada, em um exemplo, uma chave secreta conhecida pela P-GW 310. A título de exemplo, a decriptação bem sucedida do token de rede pode produzir um valor que pode indicar, em associação com o pacote de UL que incluía o token de rede, um endereço de destino de um servidor e/ou serviço de aplicativo e/ou um endereço de fonte de um dispositivo cliente e/ou de um nó de acesso a partir do qual o pacote de UL foi originado. Em um aspecto, a capacidade para obter, por exemplo, endereço de destino de um servidor e/ou serviço de aplicativo a partir de um token de rede pode significar que o pacote associado ao token é autorizado a ser enviado para aquele destino e pode adicionalmente significar que os modelos de SDF 224 (e seus filtros de pacote associados) não são necessários. A inspeção de pacote pode, portanto, ser evitada. A P-GW 310 pode emitir o token de rede para o dispositivo cliente 302 como a seguir.
[0080] A P-GW 310 pode enviar 328 uma resposta de sessão de criação para a S-GW 308. A P-GW 310 pode incluir o token de rede na resposta de sessão de criação enviada para a S-GW 308. Em resposta a resposta de sessão de criação, a S-GW 308 pode enviar 330 uma resposta de sessão de criação para a MME 306. A S-GW 308 pode incluir o token de rede na resposta de sessão de criação enviada para a MME 306. Em resposta a resposta de sessão de criação, a MME 306 pode enviar 332 uma solicitação de estabelecimento portador/aceitação de conectividade de PDN para o nó de acesso 304. O MME 306 pode incluir o token de rede na solicitação de estabelecimento portador/aceitação de conectividade de PDN enviada para o nó de acesso 304. Em resposta à solicitação de estabelecimento portador/aceitação de conectividade de PDN o nó de acesso 304 pode enviar 334 uma reconfiguração de conexão de RRC para o dispositivo cliente. O nó de acesso 304 pode incluir o token de rede na reconfiguração de conexão de RRC enviada para o dispositivo cliente. O dispositivo cliente 302 pode receber o token de rede incluído na reconfiguração de conexão de RRC recebida a partir do nó de acesso 304.
[0081] Uma vez que o dispositivo cliente 302 tenha o token de rede, o dispositivo cliente 302 pode incluir o token de rede com um ou mais pacotes de UL construídos para a transmissão de dados para o serviço de aplicativo.
[0082] A Figura 4 é um diagrama que ilustra um fluxo de chamada exemplificativo 400 em que um token de rede pode ser emitido para um nó de acesso (por exemplo, eNóB) 404 por uma P-GW 410; o dispositivo cliente 402 pode não receber o token de rede. Aqui, o dispositivo cliente 402 pode ser considerado um independente. Isto é, de acordo com esse exemplo, o dispositivo cliente 402 pode não ser a entidade que inclui o token de rede em um ou mais pacotes de UL destinados a um serviço de aplicativo. O fluxo de chamada pode ser implantado no plano C. A Figura 4 inclui representações de um dispositivo cliente 402, um nó de acesso 404, uma MME 406, uma S-GW 408, a P-GW 410, um PCRF 412 e um HSS 414.
[0083] No fluxo de chamada exemplificativo da Figura 4, um dispositivo cliente 402 pode levar etapas para estabelecer uma conexão em geral, ou estabelecer uma conexão com um serviço. Em um aspecto, o dispositivo cliente 402 pode enviar 416 uma solicitação de conectividade de PDN para uma MME 406. Uma solicitação para um token de rede pode ser reconhecida implicitamente em conexão com ações tomadas pelo dispositivo cliente 402 para estabelecer a conexão. Por exemplo, uma solicitação para um token de rede pode ser reconhecida implicitamente em conexão com a solicitação de conectividade de PDN do dispositivo cliente 402. Alternativamente, a solicitação para um token de rede pode ser incluída explicitamente na solicitação de conexão do dispositivo cliente 402. Por exemplo, uma solicitação para um token de rede pode ser incluída explicitamente com a solicitação de conectividade de PDN. A solicitação para o token de rede pode incluir um identificador de aplicativo (App ID). Como ainda outra alternativa, o dispositivo cliente 402 pode não solicitar o token de rede, mas o token de rede pode ser atribuído no plano C.
[0084] Em resposta ao recebimento da solicitação de conectividade de PDN, a MME 406 pode enviar 418 uma solicitação de sessão de criação para a S-GW 408. A solicitação para o token de rede pode ser copiada para, ou de outra forma incluída com, a solicitação de sessão de criação. A solicitação para o token de rede pode incluir o identificador de aplicativo (App ID).
[0085] Em resposta ao recebimento da solicitação de sessão de criação, a S-GW 408 pode enviar 420 uma solicitação de sessão de criação para a P-GW 410. A solicitação para o token de rede pode ser copiada para, ou de outra forma incluída com, a solicitação de sessão de criação. A solicitação para o token de rede pode incluir o identificador de aplicativo (App ID).
[0086] Em resposta ao recebimento da solicitação de sessão de criação, a P-GW 410 pode realizar 424 etapas para estabelecimento/modificação para uma sessão de IP-CAN. Além disso, em resposta ao recebimento da solicitação para o token de rede, a P-GW 410 pode derivar 426 o token de rede. Uma chave secreta conhecida pela P-GW 410 pode ser usada em uma função criptográfica para derivar o token de rede. Em um exemplo, a P-GW 410 pode derivar o token de rede em vista de uma política de acesso de aplicativo recuperada a partir de uma função de aplicativo (AF). Em um aspecto, a política de acesso pode associar um fluxo a um aplicativo. O token de rede pode adicionalmente ser derivado em vista do App ID, por exemplo, caso o App ID seja incluído com a solicitação para o token de rede. A P- GW 410 pode emitir o token de rede para o nó de acesso 404 como a seguir.
[0087] A P-GW 410 pode enviar 428 uma resposta de sessão de criação para a S-GW 408. A P-GW 410 pode incluir o token de rede na resposta de sessão de criação enviada para a S-GW 408. Em resposta à resposta de sessão de criação, a S-GW 408 pode enviar 430 uma resposta de sessão de criação para a MME 406. A S-GW 408 pode incluir o token de rede na resposta de sessão de criação enviada para a MME 406. Em resposta à resposta de sessão de criação, a MME 406 pode enviar 432 uma solicitação de estabelecimento portador/aceitação de conectividade de PDN para o nó de acesso 404. A MME 406 pode incluir o token de rede na solicitação de estabelecimento portador/aceitação de conectividade de PDN enviada para o nó de acesso 404. Nessa maneira exemplificativa, o nó de acesso 404 pode obter o token de rede a partir da P-GW 410.
[0088] O fluxo de chamada pode continuar. Por exemplo, em resposta à solicitação de estabelecimento portador/aceitação de conectividade de PDN o nó de acesso 404 pode enviar 434 uma reconfiguração de conexão de RRC para o dispositivo cliente 402. Nesse segundo exemplo, o nó de acesso 404 pode não incluir o token de rede na reconfiguração de conexão de RRC para o dispositivo cliente 402.
[0089] Uma vez que o nó de acesso 404 tenha o token de rede, o nó de acesso 404 pode incluir o token de rede com cada pacote de UL construído para transmissão de dados para o serviço de aplicativo.
[0090] A Figura 5 é um diagrama que ilustra um fluxo de chamada exemplificativo 500 em que uma P-GW 510 pode emitir um token de rede para um dispositivo cliente 502 e também pode emitir uma chave secreta específica para um nó de acesso 504 para o nó de acesso 504. A chave secreta específica para o nó de acesso 504 pode ser uma função de uma chave secreta mantida pela P-GW 510 e, por exemplo, um identificador do nó de acesso 504. O exercício desse terceiro fluxo de chamada exemplificativo 500 pode permitir que o nó de acesso 504 verifique tokens de rede incluídos com um ou mais pacotes de UL recebidos a partir do dispositivo cliente 502, antes de encaminhar os pacotes de UL (com seus tokens de rede incluídos) para a rede principal. Isso pode facilitar uma operação de “filtragem de primeira milha”, em que, durante processos de uso/imposição (a serem descritos posteriormente no presente documento) o nó de acesso 504 pode ser autorizado a verificar um pacote de UL com base em uma função criptográfica em relação ao token de rede recebido e a chave secreta específica para o nó de acesso 504. Isso pode permitir que um nó de acesso “confiável” 504 descarte pacotes de UL não autorizados recebidos a partir de um dispositivo cliente 502 antes de os pacotes serem enviados para a rede principal. O fluxo de chamada pode ser implantado no plano C. A Figura 5 inclui representações do dispositivo cliente 502, do nó de acesso 504, de uma MME 506, de uma S- GW 508, a P-GW 510, de um PCRF 512 e de um HSS 514.
[0091] No fluxo de chamada exemplificativo 500 da Figura 5, um dispositivo cliente 502 pode levar etapas para estabelecer uma conexão em geral, ou estabelecer uma conexão com um serviço. Em um aspecto, o dispositivo cliente 502 pode enviar 516 uma solicitação de conectividade de PDN para uma MME 506. Uma solicitação para um token de rede pode ser reconhecida implicitamente em conexão com ações tomadas pelo dispositivo cliente 502 para estabelecer a conexão. Por exemplo, uma solicitação para um token de rede pode ser reconhecida implicitamente em conexão com uma solicitação de conectividade de PDN do dispositivo cliente 502. Alternativamente, a solicitação para um token de rede pode ser incluída explicitamente em uma solicitação de conexão enviada a partir do dispositivo cliente 502. Por exemplo, uma solicitação para um token de rede pode ser incluída explicitamente com a solicitação de conectividade de PDN. A solicitação para o token de rede pode incluir um identificador de aplicativo (App ID). Como ainda outra alternativa, o dispositivo cliente 502 pode não solicitar o token de rede, mas o token de rede pode ser atribuído no plano C.
[0092] Em resposta ao recebimento da solicitação de conectividade de PDN, a MME 506 pode enviar 518 uma solicitação de sessão de criação para a S-GW 508. A solicitação para o token de rede pode ser copiada para, ou de outra forma incluída com, a solicitação de sessão de criação. A solicitação para o token de rede também pode incluir o identificador de aplicativo (App ID).
[0093] Em resposta ao recebimento da solicitação de sessão de criação, a S-GW 508 pode enviar 520 uma solicitação de sessão de criação para a P-GW 510. A solicitação para o token de rede pode ser copiada para, ou de outra forma incluída com, a solicitação de sessão de criação. A solicitação para o token de rede também pode incluir o identificador de aplicativo (App ID).
[0094] Em resposta ao recebimento da solicitação de sessão de criação, a P-GW 510 pode realizar 524 etapas para o estabelecimento/modificação para uma sessão de IP-CAN (item 4). Além disso, em resposta ao recebimento da solicitação para o token de rede, a P-GW 510 pode derivar 526 o token de rede. Uma chave secreta específica para um nó de acesso 504 que é derivado pela P- GW 510 pode ser usada em uma função criptográfica para derivar o token de rede. A P-GW 510 pode derivar uma chave secreta específica para o nó de acesso 504 para cada nó de acesso 504 derivando-se aquela chave secreta (KNT, eNB) a partir de uma chave secreta (KNT) conhecida pela P-GW 510. Por exemplo, a chave secreta específica para um nó de acesso 504 pode ser derivada com o uso de uma função de derivação de chave (KDF) que pode ser uma função de, por exemplo, KNT e um identificador de nó de acesso (por exemplo, “eNB ID”) (isto é, KNT, eNB = KDF(KNT, eNB ID)). Dessa forma, cada token de rede derivado pode ser associado a (por exemplo, ligado a) um nó de acesso específico 504. Em um exemplo, a P-GW 510 pode derivar o token de rede em vista de uma política de acesso de aplicativo recuperada a partir de uma função de aplicativo (AF). Em um aspecto, a política de acesso pode associar um fluxo a um aplicativo. O token de rede pode adicionalmente ser derivado em vista do App ID, caso o App ID seja incluído com a solicitação para o token de rede. A P-GW 510 pode emitir o token de rede para o dispositivo cliente 502, e pode emitir a chave secreta específica para o nó de acesso (KNT, eNB) para o nó de acesso 504, conforme a seguir.
[0095] A P-GW 510 pode enviar 528 uma resposta de sessão de criação para a S-GW 508. A P-GW 510 pode incluir o token de rede e a chave secreta KNT, ΘNB na resposta de sessão de criação enviada para a S-GW 508. Em resposta à resposta de sessão de criação, a S-GW 508 pode enviar 530 uma resposta de sessão de criação para a MME 506. A S-GW 508 pode incluir o token de rede e a chave secreta KNT, ΘNB na resposta de sessão de criação enviada para a MME 506. Em resposta à resposta de sessão de criação, a MME 506 pode enviar 532 uma solicitação de estabelecimento portador/aceitação de conectividade de PDN para o nó de acesso 504. A MME 506 pode incluir o token de rede e a chave secreta KNT, eNB na solicitação de estabelecimento portador/aceitação de conectividade de PDN enviada para o nó de acesso 504. Consequentemente, o nó de acesso 504 agora terá obtido a chave secreta KNT, eNB. Em resposta à solicitação de estabelecimento portador/aceitação de conectividade de PDN o nó de acesso 504 pode enviar 534 uma reconfiguração de conexão de RRC para o dispositivo cliente 502. O nó de acesso 504 pode incluir o token de rede na reconfiguração de conexão de RRC para o dispositivo cliente 502. O dispositivo cliente 502 pode receber o token de rede incluído na reconfiguração de conexão de RRC recebida a partir do nó de acesso 504. Consequentemente, o dispositivo cliente 502 agora terá obtido o token de rede.
[0096] Uma vez que o dispositivo cliente 502 tenha o token de rede, o dispositivo cliente 502 pode incluir o token de rede com um ou mais pacotes de UL construídos para a transmissão de dados para o serviço de aplicativo.
[0097] A Figura 6 é um diagrama que ilustra um fluxo de chamada exemplificativo 600 em que um primeiro token de rede (por exemplo, token de rede 1) pode ser emitido para um dispositivo cliente 602 por uma P-GW 610 e um segundo token de rede (por exemplo, token de rede 2), diferente do primeiro, pode ser emitido para o dispositivo cliente 602 por um nó de acesso 604 associado ao dispositivo cliente 602. Esse exemplo pode não envolver o compartilhamento de chaves secretas. Isto é, o primeiro token de rede pode ser derivado com uma primeira chave secreta, que é conhecida apenas para a P-GW 610, enquanto o segundo token de rede pode ser derivado com uma segunda chave secreta que é conhecida pelo nó de acesso 604, em que a primeira e segunda chaves secretas são diferentes. Esse exemplo pode ser útil, por exemplo, em circunstâncias sob as quais uma assunção de confiança entre o nó de acesso 604 e a P-GW 610 é menor do que desejada ou está ausente. O fluxo de chamada exemplificativo 600 pode ser implantado no plano C. A Figura 6 inclui representações do dispositivo cliente 602, do nó de acesso 604, de uma MME 606, de uma S-GW 608, da P-GW 610, de um PCRF 612 e de um HSS 614.
[0098] No fluxo de chamada exemplificativo 600 da Figura 6, um dispositivo cliente 602 pode levar etapas para estabelecer uma conexão em geral, ou estabelecer uma conexão com um serviço. Em um aspecto, o dispositivo cliente 602 pode enviar 616 uma solicitação de conectividade de PDN para uma MME 606. Uma solicitação para um token de rede pode ser reconhecida implicitamente em conexão com ações tomadas pelo dispositivo cliente 602 para estabelecer a conexão. Por exemplo, uma solicitação para um token de rede pode ser reconhecida implicitamente em conexão com uma solicitação de conectividade de PDN de um dispositivo cliente 602. Alternativamente, a solicitação para um token de rede pode ser incluída explicitamente em uma solicitação de conexão de um dispositivo cliente 602. Por exemplo, uma solicitação para um token de rede pode ser incluída explicitamente com a solicitação de conectividade de PDN. A solicitação para o token de rede pode incluir um identificador de aplicativo (App ID). Como ainda outra alternativa, o dispositivo cliente 602 pode não solicitar o token de rede, mas o token de rede pode ser atribuído no plano C.
[0099] Em resposta ao recebimento da solicitação de conectividade de PDN, a MME 606 pode enviar 618 uma solicitação de sessão de criação para a S-GW 608. A solicitação para o token de rede pode ser copiada para, ou de outra forma incluída com, a solicitação de sessão de criação. A solicitação para o token de rede também pode incluir o identificador de aplicativo (App ID).
[0100] Em resposta ao recebimento da solicitação de sessão de criação, a S-GW 608 pode enviar 620 uma solicitação de sessão de criação para a P-GW 610. A solicitação para o token de rede pode ser copiada para, ou de outra forma incluída com, a solicitação de sessão de criação. A solicitação para o token de rede também pode incluir o identificador de aplicativo (App ID).
[0101] Em resposta ao recebimento da solicitação de sessão de criação, a P-GW 610 pode realizar 624 etapas para estabelecimento/modificação para uma sessão de IP-CAN. Além disso, em resposta ao recebimento da solicitação para o token de rede, a P-GW 610 pode derivar 626 um primeiro token de rede (por exemplo, token de rede 1). Uma chave secreta conhecida pela P-GW 610 pode ser usada em uma função criptográfica para derivar o token de rede. Em um exemplo, a P-GW 610 pode derivar o token de rede em vista de uma política de acesso de aplicativo recuperada a partir de uma função de aplicativo (AF). Em um aspecto, a política de acesso pode associar um fluxo a um aplicativo. O token de rede pode adicionalmente ser derivado em vista do App ID, caso o App ID seja incluído com a solicitação para o token de rede. A P-GW 610 pode emitir o token de rede para o dispositivo cliente 602 como a seguir.
[0102] A P-GW 610 pode enviar 628 uma resposta de sessão de criação para a S-GW 608. A P-GW 610 pode incluir o token de rede na resposta de sessão de criação enviada para a S-GW 608. Em resposta à resposta de sessão de criação, a S-GW 608 pode enviar 630 uma resposta de sessão de criação para a MME 606. A S-GW 608 pode incluir o token de rede na resposta de sessão de criação enviada para a MME 606. Em resposta à resposta de sessão de criação, a MME 606 pode enviar 632 uma solicitação de estabelecimento portador/aceitação de conectividade de PDN para o nó de acesso 604. A MME 606 pode incluir o token de rede na solicitação de estabelecimento portador/aceitação de conectividade de PDN enviada para o nó de acesso 604.
[0103] Em resposta à solicitação de estabelecimento portador/aceitação de conectividade de PDN o nó de acesso 604 pode derivar 633 um segundo token de rede (por exemplo, token de rede 2). Uma chave secreta conhecida pelo nó de acesso 604 pode ser usada em uma função criptográfica para derivar o segundo token de rede. Em um exemplo, o nó de acesso 604 pode derivar o segundo token de rede em vista de uma política de acesso de aplicativo recuperada a partir de uma função de aplicativo (AF). Em um aspecto, a política de acesso pode associar um fluxo a um aplicativo. O segundo token de rede pode adicionalmente ser derivado em vista do App ID, caso o App ID seja incluído com a solicitação para o token de rede.
[0104] Além disso, em resposta à solicitação de estabelecimento portador/aceitação de conectividade de PDN o nó de acesso 604 pode enviar 634 uma reconfiguração de conexão de RRC para o dispositivo cliente 602. O nó de acesso 604 pode incluir o primeiro token de rede derivado na P-GW 610 e adicionalmente pode incluir o segundo token de rede derivado no nó de acesso 604 na reconfiguração de conexão de RRC enviada para o dispositivo cliente 602. Portanto, o dispositivo cliente 602 pode receber tanto o primeiro token de rede derivado na P-GW 610 como o segundo token de rede derivado no nó de acesso 604 na reconfiguração de conexão de RRC recebida a partir do nó de acesso 604.
[0105] Uma vez que o dispositivo cliente 602 tem tanto o primeiro token de rede derivado na P-GW 610 como o segundo token de rede derivado no nó de acesso 604, o dispositivo cliente 602 pode incluir tanto o primeiro token de rede derivado na P-GW 610 como o segundo token de rede derivado no nó de acesso 604 com pacotes de UL construídos para transmissão de dados para o serviço de aplicativo.
[0106] A Figura 7 é um diagrama que ilustra um fluxo de chamada exemplificativo 700 em que dois tokens de rede (por exemplo, token de rede de UL e token de rede de enlace descendente (DL)) podem ser emitidos para um dispositivo cliente 702 por uma P-GW 710. Esse fluxo de chamada exemplificativo pode ser útil em conexão com o uso de tokens de enlace descendente (DL) para priorização e filtragem.
[0107] Em um aspecto, o dispositivo cliente 702 pode incluir o token de rede de UL com pacotes destinados a um dado aplicativo/serviço de aplicativo/servidor de aplicativos em uma PDN. Em um aspecto o dispositivo cliente 702 pode esperar receber o token de rede de DL em pacotes recebidos a partir do dado aplicativo/serviço de aplicativo/servidor de aplicativos na PDN. O dispositivo cliente 702 pode enviar 736 o token de rede de DL para o aplicativo (APP) 715 na PDN, nesse ponto pode-se esperar que a APP 715 na PDN inclua uma cópia do token de rede de DL em um ou mais pacotes que a mesma envia para o dispositivo cliente 702.
[0108] O fluxo de chamada exemplificativo 700 pode ser implantado no plano C. A Figura 7 inclui representações do dispositivo cliente 702, do nó de acesso 704, de uma MME 706, de uma S-GW 708, da P-GW 710, de um PCRF 712, de um HSS 714 e de um aplicativo/serviço de aplicativo/servidor de aplicativos (APP) 716 na PDN.
[0109] No fluxo de chamada exemplificativo 700 da Figura 7, um dispositivo cliente 702 pode levar etapas para estabelecer uma conexão em geral, ou estabelecer uma conexão com um serviço. Em um aspecto, o dispositivo cliente 702 pode enviar 7016 uma solicitação de conectividade de PDN para uma MME 706. Uma solicitação para um token de rede pode ser reconhecida implicitamente em conexão com ações tomadas pelo dispositivo cliente 702 para estabelecer a conexão. Por exemplo, uma solicitação para um token de rede pode ser reconhecida implicitamente em conexão com uma solicitação de conectividade de PDN de um dispositivo cliente 702. Alternativamente, a solicitação para um token de rede pode ser incluída explicitamente em uma solicitação de conexão de um dispositivo cliente 702. Por exemplo, uma solicitação para um token de rede pode ser incluída explicitamente com a solicitação de conectividade de PDN. A solicitação para o token de rede pode incluir um identificador de aplicativo (App ID). Como ainda outra alternativa, o dispositivo cliente 702 pode não solicitar o token de rede, mas o token de rede pode ser atribuído no plano C.
[0110] Em resposta ao recebimento da solicitação de conectividade de PDN, a MME 706 pode enviar 718 uma solicitação de sessão de criação para a S-GW 708. A solicitação para o token de rede pode ser copiada para, ou de outra forma incluída com, a solicitação de sessão de criação. A solicitação para o token de rede também pode incluir o identificador de aplicativo (App ID).
[0111] Em resposta ao recebimento da solicitação de sessão de criação, a S-GW 708 pode enviar 720 uma solicitação de sessão de criação para a P-GW 710. A solicitação para o token de rede pode ser copiada para, ou de outra forma incluída com, a solicitação de sessão de criação. A solicitação para o token de rede também pode incluir o identificador de aplicativo (App ID).
[0112] Em resposta ao recebimento da solicitação de sessão de criação, a P-GW 710 pode realizar 724 etapas para estabelecimento/modificação para uma sessão de IP-CAN. Além disso, em resposta ao recebimento da solicitação para o token de rede, a P-GW 710 pode derivar 726 o token de rede de UL e em alguns aspectos pode derivar um token de rede de enlace descendente (DL). Uma chave secreta conhecida pela P-GW 710 pode ser usada em uma função criptográfica para derivar o token de rede de UL. Em um exemplo, a P-GW 710 pode derivar o token de rede de UL em vista de uma política de acesso de aplicativo recuperada a partir de uma função de aplicativo (AF). Em um aspecto, a política de acesso pode associar um fluxo a um aplicativo. O token de rede de UL pode adicionalmente ser derivado em vista do App ID, caso o App ID seja incluído com a solicitação para o token de rede de UL. A derivação do token de rede de DL pode ser com base na chave conhecida pela P-GW 710 e em um parâmetro associado a um servidor de aplicativos. A P-GW 710 pode emitir o token de rede de UL e, em alguns aspectos, o token de rede de DL para o dispositivo cliente 702 conforme a seguir.
[0113] A P-GW 710 pode enviar 728 uma resposta de sessão de criação para a S-GW 708. A P-GW 710 pode incluir o token de rede de UL na resposta de sessão de criação enviada para a S-GW 708. A P-GW 710 também pode incluir o token de rede de DL na resposta de sessão de criação enviada para a S-GW 708. Em resposta à resposta de sessão de criação, a S-GW 708 pode enviar 730 uma resposta de sessão de criação para a MME 706. A S-GW 708 pode incluir o token de rede de UL e o token de rede de DL na resposta de sessão de criação enviada para a MME 706. Em resposta à resposta de sessão de criação, a MME 706 pode enviar 732 uma solicitação de estabelecimento portador/aceitação de conectividade de PDN para o nó de acesso 704. A MME 706 pode incluir o token de rede de UL e o token de rede de DL na solicitação de estabelecimento portador/aceitação de conectividade de PDN enviada para o nó de acesso 704.
[0114] Em resposta à solicitação de estabelecimento portador/aceitação de conectividade de PDN o nó de acesso 704 pode enviar uma reconfiguração de conexão de RRC para o dispositivo cliente 702. O nó de acesso 704 pode incluir o token de rede de UL e o token de rede de DL com a reconfiguração de conexão de RRC enviada para o dispositivo cliente 702. Portanto, o dispositivo cliente 702 pode receber tanto o token de rede de UL como o token de rede de DL, tanto pode ter sido derivado na P-GW 710 como entregue para o dispositivo cliente 702 na reconfiguração de conexão de RRC recebida a partir do nó de acesso 704.
[0115] Em alguns aspectos, o dispositivo cliente 702 pode enviar 736 o token de rede de DL para a APP 715 na PDN. A APP 715 pode, então, incluir o token de rede de DL com um ou mais pacotes de enlace descendente enviados a partir da APP 715 para a P-GW 710 no enlace descendente. Nesse aspecto, a P-GW 710 pode ser capaz de com mais eficiência direcionar fluxos de IP na direção de enlace descendente bem como na direção de enlace ascendente. Devido ao fato de que o token de rede de DL original foi derivado pela P-GW 710, a P-GW 710 pode ser capaz de validar o token de rede de DL recebido com pacotes a partir da APP 715. Essa pode ser uma alternativa útil para inspeção de pacote de enlace descendente com o uso de TFT/SDF.
[0116] Os aspectos de uso e imposição em conexão com os tokens de rede descritos acima serão apresentados agora.
[0117] O uso dos tokens de rede pode ser descrito em relação ao movimento dos tokens de rede entre as pilhas de protocolos do plano de usuário de um dispositivo cliente, um nó de acesso, um gateway e um servidor de aplicativos. No presente documento são ilustradas seis Figuras que ilustram conjuntos exemplificativos de pilhas de protocolos do plano de usuário. Cada Figura é diferente da seguinte em sua representação de movimento de token de rede entre as pilhas de protocolos. Muitas das camadas representadas nas pilhas de protocolos, e as interconexões entre as camadas, são bem conhecidas. Essas camadas serão descritas brevemente em relação à ilustração da Figura 8. Suas descrições não serão repetidas para cada Figura exemplificativa para evitar repetição e melhorar a concisão do pedido. Quatro das Figuras incluem uma camada corretiva, que pode ser considerada como uma camada utilizada para o movimento de tokens de rede em conexão com os respectivos aspectos ilustrados pelas quatro Figuras.
[0118] A Figura 8 é uma ilustração exemplificativa de pilhas de protocolos do plano de usuário 800 de um sistema de acordo com um aspecto descrito no presente documento. A Figura 8 representa um dispositivo cliente 802, um nó de acesso 804, um gateway 806 e um servidor de aplicativos 808. Na ilustração exemplificativa da Figura 8, uma pilha de protocolos do dispositivo cliente 802 pode incluir, a partir da camada mais baixa para cima, uma camada física (PHY) 810, uma camada de controle de acesso ao meio (MAC) 812, uma camada de controle de enlace de rádio (RLC) 814, uma camada de protocolo de convergência de dados em pacote (PDCP) 816, e uma camada de protocolo Internet (IP) 818. Em um aspecto, um token de rede poderia ser transportado em um cabeçalho de extensão de IP definido no protocolo Internet (IP) versão 6 (IPv6).
[0119] Em um aspecto, uma camada shim 820 pode ser adicionada à pilha de protocolos de plano de usuário de um dispositivo cliente 802 e uma camada shim 822 correspondente pode ser adicionada à pilha de protocolos do gateway 806. A camada shim 820 e camada shim 822 correspondente facilita o movimento de tokens de rede a partir do dispositivo cliente 802 para o gateway 806 de acordo com aspectos descritos no presente documento. Em um aspecto, a camada shim 820 fica abaixo da camada de IP 818 e acima da camada de MAC 812 do dispositivo cliente 802. Nesse aspecto, a camada shim 822 correspondente fica abaixo da camada de IP 824 e acima da camada de GTP-U 826 do gateway 806.
[0120] O aspecto ilustrado pela Figura 8 pode ser útil para movimento de um token de rede 860 a partir do dispositivo cliente 802 para o gateway 806 sem necessidade de qualquer processamento pelo nó de acesso 804. Métodos alternativos são aceitáveis. A título de exemplo, o dispositivo cliente 802 pode receber um token de rede a partir do gateway 806 por meio de uma sinalização de plano de controle/método de estabelecimento de mensagem descrito acima (não ilustrado na Figura 8). De acordo com um aspecto do uso do token de rede, o dispositivo cliente 802 pode incluir o token de rede em pacotes destinados ao servidor de aplicativos 808. O token de rede 860 pode ser transportado em um cabeçalho shim da camada shim 820 para o gateway 806 conforme mostrado na Figura 8. O token de rede 860 pode ser transportado no cabeçalho shim separado de um cabeçalho de IP.
[0121] Caso a verificação do token de rede (descrita abaixo) no gateway 806 seja bem sucedida, o gateway 806 pode encaminhar o pacote para o servidor de aplicativos 808 após descartar o token de rede. Caso a verificação do token de rede 860 no gateway 806 não seja bem sucedida, o gateway 806 pode descartar o pacote e o token de rede. De acordo com o aspecto ilustrado, nenhuma mudança seria necessária no servidor de aplicativos 808 para suportar acesso de aplicativo com base em token de rede.
[0122] Para a plenitude da descrição, as camadas das pilhas de protocolos do plano de usuário do nó de acesso 804, gateway 806 e servidor de aplicativos 808 serão descritas agora brevemente. Na ilustração exemplificativa da Figura 8, uma pilha de protocolos do nó de acesso 804 pode incluir, a partir da camada mais baixa para cima, uma camada física (PHY) 830, uma camada de controle de acesso ao meio (MAC) 832, uma camada de controle de enlace de rádio (RLC) 834 e uma camada de protocolo de convergência de dados em pacote (PDCP) 836, que se unem, respectivamente, com camadas nomeadas de forma semelhante (1210, 812, 814 e 816) do dispositivo cliente 802. Na ilustração exemplificativa da Figura 8, uma pilha de protocolos do nó de acesso 804 pode adicionalmente incluir, a partir da camada mais baixa para cima, uma camada Ethernet 840, uma camada de MAC 842, uma camada de IP 844, uma camada protocolo de datagrama de usuário (UDP) 846 e uma camada de GTP-U 848. Essas camadas respectivas se unem com camadas nomeadas de forma semelhante (1250, 852, 854, 856 e 826) do gateway 806. Na ilustração exemplificativa da Figura 8, a camada de IP de dispositivo cliente 818 se une a camada de IP 824 do gateway 806, enquanto a camada de IP 824 do gateway 806 se une a camada de IP 858 do servidor de aplicativos 808.
[0123] A Figura 9 é uma ilustração exemplificativa de pilhas de protocolos do plano de usuário de um sistema, de acordo com outro aspecto descrito no presente documento. A Figura 9 representa um dispositivo cliente 902, um nó de acesso 904, um gateway 906 e um servidor de aplicativos 908.
[0124] O aspecto ilustrado pela Figura 9 pode ser útil para movimento de um token de rede 960 a partir do dispositivo cliente 902 para o gateway 906 por meio do nó de acesso 904. Nesse aspecto, uma camada shim não é exigida. A título de exemplo, o dispositivo cliente 902 pode receber um token de rede 960 a partir do gateway 906 por meio de uma sinalização de plano de controle/método de estabelecimento de mensagem descrito acima (não ilustrado na Figura 9). De acordo com um aspecto do uso do token de rede, o dispositivo cliente 902 pode incluir o token de rede 960 em pacotes destinados ao servidor de aplicativos 908. O pacote que inclui o token de rede 960 pode ser transportado em um cabeçalho de camada de PDCP 916 a partir do dispositivo cliente 902 para a camada de PDCP 936 do nó de acesso 904. O nó de acesso 904 pode copiar o token de rede encontrado no cabeçalho de PDCP para um cabeçalho de GTP-U. O pacote que inclui o token de rede 960 pode, então, ser transportado no cabeçalho de camada de GTP-U 948 a partir do nó de acesso 904 para a camada de GTP-U 926 do gateway 906. Isto é, em um aspecto, o token de rede pode ser transportado em um cabeçalho de protocolo de túnel (GTP) de serviço de rádio de pacote geral (GPRS). Em um aspecto exemplificativo, o token de rede enviado originalmente para o dispositivo cliente 902 a partir do gateway 906 pode ter sido criado com o uso de uma chave secreta conhecida pelo gateway. Nesse aspecto, o nó de acesso 904 seria incapaz de verificar o token de rede (devido ao fato de que o mesmo não possuiria a chave secreta necessária para a verificação). Consequentemente, um propósito exemplificativo do nó de acesso 904 na ilustração da Figura 9 é copiar o token de rede de um cabeçalho para outro encaminhando, desse modo, o token de rede a partir do dispositivo cliente 902 para o gateway 906 por meio do cabeçalho camada de PDCP 936 e do cabeçalho de camada de GTP-U 948 já existentes. Uma vez que o token de rede chega ao gateway, caso a verificação do token de rede (descrito abaixo) no gateway 906 seja bem sucedida, o gateway 906 pode encaminhar o pacote para o servidor de aplicativos 908 após descartar o token de rede. Caso a verificação do token de rede 960 no gateway 906 não seja bem sucedida, o gateway 906 pode descartar o pacote e o token de rede. De acordo com o aspecto ilustrativo, nenhuma mudança seria necessária no servidor de aplicativos 908 para suportar o acesso de aplicativo com base em token.
[0125] As camadas das pilhas de protocolos do plano de usuário do dispositivo cliente 902, nó de acesso 904, gateway 906 e servidor de aplicativos 908 que não foram descritas em conexão com A Figura 9 não serão descritas uma vez que suas descrições são as mesmas ou similares àquelas de camadas nomeadas de forma semelhante na Figura 8.
[0126] A Figura 10 é uma ilustração exemplificativa de pilhas de protocolos do plano de usuário de um sistema, de acordo com ainda outro aspecto descrito no presente documento. A Figura 10 representa um dispositivo cliente 1002, um nó de acesso 1004, um gateway 1006 e um servidor de aplicativos 1008.
[0127] O aspecto ilustrado pela Figura 10 pode ser útil para o movimento de um token de rede 1060 a partir do nó de acesso 1004 para o gateway 1006. Esse aspecto pode ser útil caso o dispositivo cliente 1002 seja restrito a acessar um serviço específico no servidor de aplicativos 1008 e um portador estabelecido para transportar tráfego a partir do dispositivo cliente 1002 para o gateway 1006 é estabelecida como tal (por exemplo, conectividade promovida). Esse aspecto também pode ser útil quando uma relação de confiança não puder existir entre o dispositivo cliente 1002 e o nó de acesso 1004, ou entre o dispositivo cliente 1002 e o gateway 1006. A título de exemplo, no aspecto ilustrado pela Figura 10, o dispositivo cliente 1002 não recebe um token de rede a partir do gateway 1006. No aspecto ilustrado pela Figura 10, o nó de acesso 1004 pode receber o token de rede 1060 a partir do gateway 1006 por meio de uma sinalização de plano de controle/método de estabelecimento de mensagem descrito acima (não ilustrado na Figura 10). De acordo com um aspecto do uso do token de rede, o nó de acesso 1004 pode incluir o token de rede 1060 nos pacotes do dispositivo cliente 1002 destinados ao servidor de aplicativos 1008. O pacote do dispositivo cliente 1002, que inclui o token de rede 1060, pode ser transportado em um cabeçalho camada de GTP-U 1048 a partir do nó de acesso 1004 para a camada de GTP-U 1026 do gateway 1006. Uma vez que o token de rede chega ao gateway, caso a verificação do token de rede (descrito abaixo) no gateway 1006 seja bem sucedida, o gateway 1006 pode encaminhar o pacote para o servidor de aplicativos 1008 após descartar o token de rede. Caso a verificação do token de rede 1060 no gateway 1006 não seja bem sucedida, o gateway 1006 pode descartar o pacote e o token de rede. De acordo com o aspecto ilustrativo, nenhuma mudança seria necessária no servidor de aplicativos 1008 para suportar o acesso de aplicativo com base em token.
[0128] As camadas das pilhas de protocolos do plano de usuário do dispositivo cliente 1002, nó de acesso 1004, gateway 1006 e servidor de aplicativos 1008 que não foram descritas em conexão com A Figura 10 não serão descritas uma vez que suas descrições são as mesmas ou similares àquelas de camadas nomeadas de forma semelhante na Figura 8.
[0129] A Figura 11 é uma ilustração exemplificativa de pilhas de protocolos do plano de usuário de um sistema de acordo com ainda outro aspecto descrito no presente documento. A Figura 11 representa um dispositivo cliente 1102, um nó de acesso 1104, um gateway 1106 e um servidor de aplicativos 1108.
[0130] Em um aspecto, uma camada shim 1162 pode ser adicionada à pilha de protocolos de plano de usuário de um dispositivo cliente 1102, uma camada shim 1164 correspondente pode ser adicionada à pilha de protocolos do nó de acesso 1104, e uma camada shim 1166 adicionalmente correspondente pode ser adicionada à pilha de protocolos do gateway 1106. As camadas corretivas 1162, 1164 e 1166 facilitam o movimento de tokens de rede a partir do dispositivo cliente 1102 para o nó de acesso 1104 e a partir do nó de acesso 1104 para o gateway 1106, de acordo com aspectos descritos no presente documento. Em um aspecto, a camada shim 1162 fica abaixo da camada de IP 1118 e acima da camada de MAC 1112 do dispositivo cliente 1102. Nesse aspecto, a camada shim 1164 correspondente fica acima de uma camada de PDCP 1136 do nó de acesso 1104. Nesse aspecto, a camada shim 1166 correspondente adicional fica abaixo da camada de IP 1124 e acima da camada de GTP-U 1126 do gateway 1106.
[0131] O aspecto ilustrado pela Figura 11 pode ser útil para o movimento de um token de rede 1160 a partir do dispositivo cliente 1102 para o gateway 1106 por meio do nó de acesso 1104, em que o nó de acesso 1104 é receptor de uma chave secreta específica para o nó de acesso (KNT, eNB) que pode ser usado para validar um token de rede. A título de exemplo, o dispositivo cliente 1102 pode receber um token de rede a partir do gateway 1106 por meio de uma sinalização de plano de controle/método de estabelecimento de mensagem descrito acima (não ilustrado na Figura 11). Além disso, o nó de acesso 1104 pode receber uma chave secreta específica para o nó de acesso (KNT, eNB) derivada pelo gateway 1106 e usada pelo gateway 1106 para derivar o token de rede enviado para o dispositivo cliente 1102 por meio de uma sinalização de plano de controle/método de estabelecimento de mensagem descrito acima (não ilustrado na Figura 11). De acordo com um aspecto do uso do token de rede, o dispositivo cliente 1102 pode incluir o token de rede em pacotes destinados ao servidor de aplicativos 1108. O cabeçalho shim da camada shim 1162 pode transportar o token de rede 1160 para a camada shim 1164 correspondente do nó de acesso 1104 conforme mostrado na Figura 11. O nó de acesso 1104 pode usar a chave secreta específica para o nó de acesso fornecida para o mesmo pelo gateway 1106 para verificar o token de rede incluído no pacote de dispositivo cliente. Caso a verificação do token de rede (descrita abaixo) no nó de acesso 1104 seja bem sucedida, o nó de acesso 1104 pode encaminhar o pacote de dispositivo cliente e o token de rede para o gateway 1106. Caso a verificação do token de rede 1160 no nó de acesso 1104 não seja bem sucedida, o nó de acesso 1104 pode descartar o pacote e token de rede. Caso a verificação do token de rede (descrita abaixo) no nó de acesso 1104 tenha sido bem sucedida e o pacote de dispositivo cliente e token de rede tenham sido encaminhados para o gateway 1106, um segundo processo de verificação pode ser conduzido no gateway 1106. Caso a verificação do token de rede (descrita abaixo) no gateway 1106 seja bem sucedida, o gateway 1106 pode encaminhar o pacote para o servidor de aplicativos 1108 após descartar o token de rede. Caso a verificação do token de rede 1160 no gateway 1106 não seja bem sucedida (apesar do sucesso no nó de acesso 1104), o gateway 1106 pode descartar o pacote e o token de rede. De acordo com o aspecto ilustrativo, nenhuma mudança seria necessária no servidor de aplicativos 1108 para suportar o acesso de aplicativo com base em token.
[0132] De acordo com o aspecto ilustrado na Figura 11, o nó de acesso 1104 pode verificar um token enviado para o dispositivo cliente 1102 pelo gateway 1106. A verificação no nó de acesso 1104 é possível devido ao fato de que o gateway 1106 pode derivar uma chave secreta específica para o nó de acesso (derivação explicada acima em conexão com o estabelecimento do token). Isso pode permitir que um nó de acesso 1104 filtre tráfego de dispositivo cliente não autorizado destinado a um servidor de aplicativos antes de aquele tráfego ser injetado profundamente na rede, que, desse modo, pode impedir que os recursos de rede sejam usados para entregar tráfego não autorizado.
[0133] As camadas das pilhas de protocolos do dispositivo cliente 1102, nó de acesso 1104, gateway 1106 e servidor de aplicativos 1108 que não foram descritas em conexão com A Figura 11 não serão descritas uma vez que suas descrições são as mesmas ou similares àquelas de camadas nomeadas de forma semelhante na Figura 8.
[0134] A Figura 12 é uma ilustração exemplificativa de pilhas de protocolos do plano de usuário de um sistema, de acordo com ainda outro aspecto descrito no presente documento. A Figura 12 representa um dispositivo cliente 1202, um nó de acesso 1204, um gateway 1206 e um servidor de aplicativos 1208.
[0135] Em um aspecto, uma camada shim 1272 pode ser adicionada à pilha de protocolos de um dispositivo cliente 1202, uma camada shim 1274 correspondente pode ser adicionada à pilha de protocolos do nó de acesso 1204, e uma camada shim 1276 adicionalmente correspondente pode ser adicionada à pilha de protocolos do gateway 1206. As camadas corretivas 1272, 1274 e 1276 facilitam o movimento de tokens de rede a partir do dispositivo cliente 1202 para o nó de acesso 1204 e a partir do nó de acesso 1204 para o gateway 1206 de acordo com aspectos descritos no presente documento. Em um aspecto, a camada shim 1272 fica abaixo da camada de IP 1218 e acima da camada de MAC 1212 do dispositivo cliente 1202. Nesse aspecto, a camada shim 1274 correspondente fica acima de uma camada de PDCP 1236 do nó de acesso 1204. Nesse aspecto, a camada shim 1276 correspondente adicional fica abaixo da camada de IP 1224 e acima da camada de GTP-U 1226 do gateway 1206.
[0136] O aspecto ilustrado pela Figura 12 pode ser útil para o movimento de um token de rede 1260 a partir do dispositivo cliente 1202 para o gateway 1206 por meio do nó de acesso 1204, em que tanto o nó de acesso 1204 como o gateway 1206 podem emitir tokens de rede para o dispositivo cliente 1202. A título de exemplo, o dispositivo cliente 1202 pode receber um token de rede NT2 a partir do nó de acesso 1204 e um token de rede separado NT1 a partir do gateway 1206 por meio de uma sinalização de plano de controle/método de estabelecimento de mensagem descrito acima (não ilustrado na Figura 12). de acordo com um aspecto do uso dos tokens de rede, NT1, NT2 recebidos a partir do gateway 1206 e do nó de acesso 1204, respectivamente, o dispositivo cliente 1202 pode incluir os tokens de rede NT1, NT2 em pacotes destinados ao servidor de aplicativos 1208. O cabeçalho shim da camada shim 1272 pode transportar os tokens de rede NT1, NT2 para a camada shim 1274 correspondente do nó de acesso 1204 conforme mostrado na Figura 12. O nó de acesso 1204 pode usar uma chave secreta conhecida pelo nó de acesso 1204 para verificar o token de rede NT2 incluído com o pacote de dispositivo cliente. Caso a verificação do token de rede NT2 no nó de acesso 1204 seja bem sucedida, o nó de acesso 1204 pode descartar o token de rede NT2 e encaminhar o pacote e o token de rede NT1 para o gateway 1206. Caso a verificação do token de rede NT2 no nó de acesso 1204 não seja bem sucedida, o nó de acesso 1204 pode descartar o pacote e os tokens de rede.
[0137] Caso A verificação do token de rede NT2 no nó de acesso 1204 tenha sido bem sucedida e o pacote e tokens de rede NT1 tenham sido encaminhados para o gateway 1206, um segundo processo de verificação pode ser conduzido no gateway 1206. Caso a verificação do token de rede NT1 no gateway 1206 seja bem sucedida, o gateway 1206 pode encaminhar o pacote para o servidor de aplicativos 1208 após descartar o token de rede NT1. Caso a verificação do token de rede NT1 no gateway 1206 não seja bem sucedida (apesar do sucesso no nó de acesso 1204), o gateway 1206 pode descartar o pacote e o token de rede NT1. De acordo com o aspecto ilustrado, nenhuma mudança seria necessária no servidor de aplicativos 1208 para suportar o acesso de aplicativo com base em token.
[0138] De acordo com o aspecto ilustrado na Figura 12, o nó de acesso 1204 pode verificar um token enviado para o dispositivo cliente 1202, em que o token de rede foi derivado pelo próprio nó de acesso 1204. Isso pode permitir que um nó de acesso 1204 filtre o tráfego de dispositivo cliente não autorizado destinado a um servidor de aplicativos antes de aquele tráfego ser injetado profundamente na rede, o que, desse modo, pode impedir que recursos de rede sejam usados para entregar tráfego não autorizado. Esse aspecto pode ser útil quando não há nenhuma relação de confiança assumida entre o nó de acesso 1204 e o gateway 1206. Consequentemente, essa opção pode ser mais útil caso o nó de acesso 1204 e o gateway 1206 sejam de propriedade/rodados por operadores diferentes.
[0139] As camadas das pilhas de protocolos do dispositivo cliente 1202, nó de acesso 1204, gateway 1206 e servidor de aplicativos 1208 que não foram descritas em conexão com A Figura 12 não serão descritas uma vez que suas descrições são as mesmas ou similares àquelas de camadas nomeadas de forma semelhante na Figura 8.
[0140] A Figura 13 é uma ilustração exemplificativa de pilhas de protocolos do plano de usuário de um sistema, de acordo com ainda outro aspecto descrito no presente documento. A Figura 13 representa um dispositivo cliente 1302, um nó de acesso 1304, um gateway 1306 e um servidor de aplicativos 1308.
[0141] Em um aspecto, uma camada shim 1320 pode ser adicionada à pilha de protocolos de um dispositivo cliente 1302 e uma camada shim 1322 correspondente pode ser adicionada à pilha de protocolos do gateway 1306. A camada shim 1320 e camada shim 1322 correspondente facilita o movimento de tokens de rede a partir do dispositivo cliente 1302 para o gateway 1306 de acordo com aspectos descritos no presente documento. Em um aspecto, a camada shim 1320 fica abaixo da camada de IP 1318 e acima da camada de MAC 1312 do dispositivo cliente 1302. Nesse aspecto, a camada shim 1322 correspondente fica abaixo da camada de IP 1324 e acima da camada de GTP-U 1326 do gateway 1306.
[0142] Adicionalmente, a Figura 13 representa tokens de rede de enlace descendente, NTD. O token de enlace descendente pode ser usado para priorização e filtragem. O token de rede de enlace descendente foi descrito em conexão com o estabelecimento do token (acima). A título de exemplo, o dispositivo cliente 1302 pode receber um token de rede NT a partir do gateway 1306 por meio de uma sinalização de plano de controle/método de estabelecimento de mensagem descrito acima (não ilustrado na Figura 13). O dispositivo cliente 1302 também pode receber um segundo token de rede NTD a partir do gateway 1306 por meio de um sinalização de plano de controle/método de estabelecimento de mensagem descrito acima (não ilustrado na Figura 13). De acordo com um aspecto do uso dos tokens de rede, o token de rede de enlace descendente NTD pode ser entregue para o servidor de aplicativos 1308 a partir do dispositivo cliente 1302 por meio de uma sinalização de plano de controle/método de estabelecimento de mensagem descrito acima (não ilustrado na Figura 13). Depois disso, em uso, o servidor de aplicativos 1308 pode incluir o token de rede de enlace descendente NTD em pacotes de enlace descendente enviados para o gateway 1306 e destinados ao dispositivo cliente 1302. O gateway 1306 pode usar o token de rede de enlace descendente TD para priorização e filtragem.
[0143] As camadas das pilhas de protocolos do dispositivo cliente 1302, nó de acesso 1304, gateway 1306 e servidor de aplicativos 1308 que não foram descritas em conexão com A Figura 13 não serão descritas uma vez que suas descrições são as mesmas ou similares àquelas de camadas nomeadas de forma semelhante na Figura 8.
[0144] A Figura 14 é um diagrama de blocos que ilustra um dispositivo exemplificativo 1400 adaptado para suportar acesso de aplicativo com base em token de rede. Conforme usado no presente documento, o termo “dispositivo” pode descrever um componente de chip e/ou um dispositivo de usuário final tal como um dispositivo cliente (por exemplo, dispositivo móvel, equipamento de usuário, dispositivo de usuário). Em um exemplo, o dispositivo exemplificativo 1400 pode incluir um circuito de interface de comunicação 1402, um circuito de processamento 1404 acoplado ao circuito de interface de comunicação 1402, e um dispositivo de memória 1406 (por exemplo, dispositivo magnético e/ou óptico para armazenar dados) acoplado ao circuito de processamento 1404. Essa lista não é limitante.
[0145] O circuito de interface de comunicação 1402 pode incluir um primeiro circuito/função/módulo de entrada/saída 1408 para operações de entrada/saída com um usuário. O circuito de interface de comunicação 1402 pode incluir um circuito/função/módulo de receptor/transmissor 1410 para comunicação sem fio com nós de acesso. Essa lista não é limitante.
[0146] O circuito de processamento 1404 pode incluir ou implantar um ou mais processadores, processadores de aplicativo específica, módulos de hardware e/ou software, etc., que são adaptados para suportar o acesso de aplicativo com base em token. Por exemplo, um módulo/circuito/função que incorpora token de rede 1412 pode ser adaptado para incorporar (incluir) tokens de rede em pacotes encaminhados para um nó de acesso e/ou um gateway. Esse exemplo não é limitante.
[0147] O dispositivo de memória 1406 pode ser adaptado para incluir instruções que incorporam token de rede 1422, instruções de validação/verificação criptográfica 1424 e armazenamento e instruções de chave secreta. Essa lista não é limitante.
[0148] A Figura 15 é um método exemplificativo 1500 através do qual um dispositivo pode obter um token de rede. O método exemplificativo 1500 pode ser operacional no dispositivo. Em um aspecto, o dispositivo pode estabelecer uma conexão com um nó de acesso com o uso de sinalização de plano c. Por exemplo, nesse aspecto, um portador pode ser estabelecido em um nó de acesso. Em um aspecto, o dispositivo pode estabelecer 1504 um conjunto de um ou mais fluxos associados a um ou mais aplicativos com o uso de sinalização de plano de controle. O um ou mais fluxos podem ser definidos com base em uma política. A política pode ser uma política de rede tal como uma política de acesso de rede. O dispositivo pode obter 1506, durante a sinalização de plano de controle, um token de rede, em que o token de rede pode ser derivado de acordo com uma política de acesso de rede, associado a um primeiro fluxo do conjunto de um ou mais fluxos, associado a um primeiro aplicativo dentre os um ou mais aplicativos, e provisionado para o dispositivo por meio da sinalização de plano de controle.
[0149] Em um aspecto, antes de estabelecer o conjunto de um ou mais fluxos associados a um ou mais aplicativos com o uso de sinalização de plano de controle, o dispositivo pode, opcionalmente, determinar 1502 se o serviço de aplicativo exige um token de rede.
[0150] Em um aspecto, o método exemplificativo 1500 pode adicionalmente incluir enviar 1508, a partir do dispositivo, o token de rede com um pacote associado ao primeiro fluxo. O método não é limitado a enviar apenas um token de rede com um pacote. O método pode incluir enviar o token de rede com um ou mais pacotes associados ao primeiro fluxo ou pode incluir enviar o token de rede com cada pacote associado ao primeiro fluxo.
[0151] Em um aspecto, o serviço de aplicativo pode ser associado ao portador ou a um nome de ponto de acesso (APN). O estabelecimento do portador pode ser iniciado em uma rede por uma entidade de gerenciamento de mobilidade (MME) ou um gateway de rede de pacotes (P-GW). Conforme usado no presente documento, o estabelecimento de um portador pode incluir a ativação de um portador padrão, a ativação de um portador dedicado ou a modificação de um portador já estabelecido. As etapas de estabelecer o portador e obter o token de rede podem ser implantadas em mensagens de controle. O token de rede pode ser associado a (por exemplo, ligado a) o dispositivo e serviço de aplicativo. O token de rede pode ser associado a um ou mais fluxos e um ou mais aplicativos.
[0152] Em um aspecto, o estabelecimento do portador pode ser iniciado pelo dispositivo. As etapas que podem ser implantadas para estabelecer o portador, ou um APN, podem incluir enviar, a partir do dispositivo, uma solicitação de conexão à rede de dados em pacote (PDN); enviar, a partir do dispositivo, uma solicitação de ativação portador dedicado; ou enviar, a partir do dispositivo, uma solicitação de modificação portador.
[0153] Em um aspecto, estabelecer o portador pode incluir solicitar um token de rede, em que a solicitação pode ser implícita ou explícita. A solicitação pode incluir identificar o serviço de aplicativo por um identificador de aplicativo (App ID) ou um fluxo de dados de serviço (SDF) em uma mensagem de controle.
[0154] Conforme indicado acima, um dispositivo pode determinar se o serviço de aplicativo exige o token de rede antes de solicitar o token de rede. Nesse caso, a determinação pode ser com base em uma indicação recebida a partir de uma rede, uma indicação recebida a partir do serviço de aplicativo, uma configuração do serviço de aplicativo e/ou uma resposta a uma consulta.
[0155] A título de exemplo, a indicação recebida a partir da rede pode ser incluída em uma mensagem camada de transporte de sinalização (SIB) ou uma mensagem de estrato não de acesso (NAS) como parte de um processo de conexão. A indicação recebida a partir da rede pode ser armazenada em conexão com a configuração do serviço de aplicativo. A indicação recebida a partir da rede pode ser recebida durante a criação de uma assinatura para o serviço de aplicativo ou transferida por download como uma atualização de software para o serviço de aplicativo. A indicação recebida a partir da rede pode ser recebida como parte de uma política.
[0156] A título de exemplo, a configuração do serviço de aplicativo pode ser com base em uma política do serviço de aplicativo ou em uma política de um provedor de conectividade que hospeda um serviço de transporte ou conexão para o serviço de aplicativo.
[0157] A Figura 16 é um método exemplificativo 1600 através do qual um dispositivo pode obter um token de rede a partir de um dispositivo gateway e um token de rede separado a partir de um nó de acesso. O método exemplificativo 1600 pode ser operacional no dispositivo. Em um aspecto, o dispositivo pode estabelecer uma conexão com um nó de acesso com o uso de sinalização de plano c. Por exemplo, nesse aspecto, um portador pode ser estabelecido em um nó de acesso. Em um aspecto, o dispositivo pode estabelecer 1602 um conjunto de um ou mais fluxos associados a um ou mais aplicativos com o uso de sinalização de plano de controle. O um ou mais fluxos podem ser definidos com base em uma política. A política pode ser uma política de rede tal como uma política de acesso de rede. o dispositivo pode obter 1604, durante a sinalização de plano de controle, um primeiro token de rede, em que o primeiro token de rede pode ser derivado por um primeiro dispositivo (por exemplo, uma P-GW, um dispositivo gateway ) de acordo com uma política de acesso de rede. O primeiro token de rede pode ser associado a um primeiro fluxo do conjunto de um ou mais fluxos, um primeiro aplicativo dentre os um ou mais aplicativos, e pode adicionalmente ser provisionado para o dispositivo por meio da sinalização de plano de controle.
[0158] Uma política de acesso de rede pode associar um fluxo a partir de um dispositivo para um serviço de aplicativo. O método pode, então, incluir obter, no dispositivo, um primeiro token de rede para associar pacotes ao fluxo de acordo com a política de acesso de rede 1604. O método pode adicionalmente continuar incluindo-se o primeiro token de rede em pacotes associados ao fluxo, que são destinados ao serviço de aplicativo. Em um aspecto, o dispositivo pode incluir 1606 o primeiro token de rede em um ou mais pacotes destinados ao aplicativo. O método pode adicionalmente incluir uma etapa opcional de obter, no dispositivo, um segundo token de rede para associar pacotes a um fluxo de acordo com uma política de acesso 1608. Em seguida à etapa opcional, o método pode adicionalmente incluir uma etapa opcional de incluir o segundo token de rede em um ou mais pacotes destinados ao aplicativo 1610.
[0159] O primeiro e segundo tokens de rede podem ser obtidos pelo dispositivo em uma mensagem de controle.
[0160] A Figura 17 é um diagrama de blocos que ilustra um nó de acesso exemplificativo 1700 (por exemplo, eNóB) adaptado para suportar o acesso de aplicativo com base em token. Em um exemplo, o nó de acesso exemplificativo 1700 pode incluir um circuito de interface de comunicação de rede 1702, um circuito de processamento 1704 acoplado ao circuito de interface de comunicação de rede 1702 e um dispositivo de memória 1706 (por exemplo, dispositivo magnético e/ou óptico para armazenar dados) acoplados ao circuito de processamento 1704. Essa lista não é limitante.
[0161] O circuito de interface de comunicação de rede 1702 pode incluir um primeiro circuito/função/módulo de entrada/saída 1708 para comunicação com uma P-GW por meio de uma S-GW. O circuito de interface de comunicação de rede 1702 pode incluir um circuito/função/módulo de receptor/transmissor 1710 para comunicação sem fio com dispositivos do cliente. Essa lista não é limitante.
[0162] O circuito de processamento 1704 pode incluir ou implantar um ou mais processadores, processadores de aplicativo específica, módulos de hardware e/ou software, etc., que são adaptados para suportar o acesso de aplicativo com base em token. Por exemplo, um circuito/função/módulo que deriva token de rede 1712 pode ser adaptado para derivar tokens com base em um uma chave secreta conhecida apenas para um gateway, ou uma chave secreta conhecida pelo gateway e/ou outra entidade, tal como uma chave secreta específica para um nó de acesso, que pode ser armazenada no dispositivo de memória 1706. A título de outro exemplo, um circuito/função/módulo de extração/incorporação de token de rede 1714 pode ser adaptado para extrair tokens de rede de pacotes enlace ascendente a partir de um dispositivo cliente e/ou incorporar (incluir) tokens de rede em pacotes encaminhados para um gateway. A título de ainda outro exemplo, um módulo/circuito/função de validação/verificação criptográfica 1716 pode ser adaptado para validar/verificar tokens de rede recebidos, por exemplo, a partir de dispositivos do cliente. Essa lista não é limitante.
[0163] O dispositivo de memória 1706 pode ser adaptado para incluir instruções de derivação de token de rede 1720, instruções de extração/incorporação de token de rede 1722, instruções de validação/verificação criptográfica 1724 e armazenamento e instruções de chave secreta. Essa lista não é limitante.
[0164] A Figura 18 ilustra um método exemplificativo 1800 de estabelecer (por exemplo, derivar um token de rede e provisionar o token de rede para um dispositivo cliente) um token de rede em um nó de acesso (por exemplo, eNóB).
[0165] A título de exemplo, o nó de acesso pode estabelecer uma conexão com um dispositivo cliente 1802. O nó de acesso pode derivar, a partir de uma chave conhecida pelo nó de acesso, um token de rede 1804. O nó de acesso pode enviar o token de rede derivado no nó de acesso para o dispositivo cliente 1806. O token de rede derivado no nó de acesso pode ser enviado para o dispositivo cliente por meio de sinalização de plano de controle. Em um aspecto, um dispositivo cliente pode receber um token de rede derivado em uma P-GW e o token de rede derivado no nó de acesso por meio de sinalização de plano de controle. Os tokens de rede podem ser diferentes entre si. O token de rede derivado na P-GW pode ser derivado a partir de uma chave secreta conhecida pela P-GW, e o token de rede derivado no nó de acesso pode ser derivado a partir de uma chave secreta conhecida pelo nó de acesso. A chave secreta conhecida pela P-GW pode ser conhecida apenas pela P-GW. A chave secreta conhecida pelo nó de acesso pode ser conhecida apenas pelo nó de acesso. A chave secreta conhecida pela P-GW e a chave secreta conhecida pelo nó de acesso podem ser diferentes entre si. Incluir um token de rede derivado no nó de acesso, bem como um token de rede derivado na P-GW com pacotes de UL enviados a partir de um dispositivo cliente pode permitir que o nó de acesso verifique o pacote de UL antes de enviar o mesmo mais profundamente na rede.
[0166] No exemplo descrito acima, o estabelecimento de contato com um dispositivo cliente e o envio do token de rede a partir do nó de acesso para o dispositivo cliente podem ser implantados em mensagens de controle. O token de rede derivado no nó de acesso pode ser associado (por exemplo, ligado a) ao dispositivo cliente, ao nó de acesso e a um serviço de aplicativo.
[0167] A Figura 19 é o fluxograma de um método exemplificativo 1900 operacional em um nó de acesso. O método pode incluir estabelecer uma conexão com um dispositivo cliente 1902. O método pode incluir estabelecer um contexto para o dispositivo cliente como uma parte de estabelecer a conexão 1904. O método pode continuar incluindo-se um token de rede em pacotes associados ao dispositivo cliente e a um serviço de aplicativo 1906. O contexto pode incluir um token de rede, em que o token de rede é associado (por exemplo, ligado a) ao dispositivo cliente e ao serviço de aplicativo. O método pode adicionalmente incluir receber ou obter um pacote a partir do dispositivo cliente que inclui um token de rede 1908. Uma determinação da validade do token de rede pode ser realizada 1910. Caso o token de rede seja uma cópia de um token de rede associado ao dispositivo cliente e ao serviço de aplicativo, pode ser determinado que o token de rede é válido 1912. O método pode adicionalmente incluir enviar o pacote que inclui a cópia do token de rede para um gateway caso o token de rede seja válido 1914. Caso seja determinada que o token de rede é inválido, o nó de acesso pode descartar o pacote e o token de rede 1916.
[0168] A Figura 20 é fluxograma de outro método exemplificativo 2000, operacional em um nó de acesso. O método pode incluir estabelecer uma conexão com um dispositivo cliente 2002. O método pode incluir receber ou obter um pacote a partir do dispositivo cliente 2004. O método pode adicionalmente incluir enviar o pacote que inclui uma cópia de um token de rede para um gateway, em que o token de rede foi obtido pelo nó de acesso em uma mensagem de controle 2006.
[0169] A Figura 21 é fluxograma de ainda outro método exemplificativo 2100, operacional em um nó de acesso. O método pode incluir estabelecer uma conexão com um dispositivo cliente 2102. O método pode incluir obter um pacote a partir do dispositivo cliente que inclui um primeiro token de rede e um segundo token de rede, em que o primeiro token de rede é associado a (por exemplo, ligado a) um gateway e o segundo token de rede é associado (por exemplo, ligado a) ao nó de acesso 2104. O método pode continuar com validação/verificação do segundo token de rede no nó de acesso 2106. Caso a validação/verificação seja bem sucedida, o nó de acesso pode descartar 2108 o segundo token de rede. O nó de acesso pode, então, enviar 2110 o pacote que inclui o primeiro token de rede para um gateway. Caso a validação/verificação não seja bem sucedida, o nó de acesso pode descartar o pacote e o primeiro e segundo tokens de rede 2112.
[0170] A Figura 22 é um diagrama de blocos que ilustra um gateway exemplificativo 2200 adaptado para suportar o acesso de aplicativo com base em token. Em um exemplo, o gateway exemplificativo 2200 pode incluir um circuito de interface de comunicação de rede 2202, um circuito de processamento 2204 acoplado ao circuito de interface de comunicação de rede 2202 e um dispositivo de memória 2206 (por exemplo, dispositivo magnético e/ou óptico para armazenar dados) acoplado ao circuito de processamento 2204. Essa lista não é limitante.
[0171] O circuito de interface de comunicação de rede 2202 pode incluir um primeiro circuito/função/módulo de entrada/saída 2208 para comunicação com um gateway de serviço e um segundo circuito/função/módulo de entrada/saída 2210 para comunicação com uma rede de dados em pacote. O primeiro circuito/função/módulo de entrada/saída 2208 pode manipular múltiplos fluxos de IP estabelecidos em múltiplos portadores. O segundo circuito/função/módulo de entrada/saída 2210 pode manipular múltiplos fluxos de IP com múltiplos servidores na rede de dados em pacote. Essa lista não é limitante.
[0172] O circuito de processamento 2204 pode incluir ou implantar um ou mais processadores, processadores de aplicativo específica, módulos de hardware e/ou software, etc., que são adaptados para suportar o acesso de aplicativo com base em token. Por exemplo, um circuito/função/módulo que deriva token de rede 2212 pode ser adaptado para derivar tokens com base em uma chave secreta que pode ser armazenada no dispositivo de memória 2206. A chave secreta pode ser conhecida apenas pelo gateway. A título de outro exemplo, um circuito/função/módulo de derivação de chave 2214 pode ser adaptado para derivar uma chave secreta específica para um nó de acesso com base, por exemplo, na chave secreta que pode ser armazenada no dispositivo de memória 2206 e em um identificador de um dado nó de acesso. A título de ainda outro exemplo, um circuito/função/módulo de decisão e processamento 2216 pode ser adaptado para decidir se pacotes de enlace ascendente recebidos a partir dos portadores de EPS, ou pacotes de enlace descendente recebidos a partir de um servidor de aplicativos, incluem tokens de rede e, em caso afirmativo, pode ser adicionalmente adaptado para passar os pacotes recebidos para um circuito/função/módulo de validação criptográfica e direção de tráfego 2218. O circuito/função/módulo de decisão e processamento 2216 pode ser adicionalmente adaptado para passar pacotes recebidos que não incluem tokens de rede para um banco de filtro de fluxo de dados de serviço (não mostrado). Essa lista não é limitante.
[0173] O dispositivo de memória 2206 pode ser adaptado para incluir instruções de derivação de token de rede 2220, chave derivação instruções 2222, instruções de decisão e processamento 2224, instruções de validação criptográfica e direção de tráfego 2226 e armazenamento e instruções de chave secreta. Essa lista não é limitante.
[0174] A Figura 23 ilustra um método exemplificativo 2300 de estabelecer (por exemplo, derivar um token de rede e provisionar o token de rede para um dispositivo cliente) um token de rede em um gateway (por exemplo, uma P-GW).
[0175] A título de exemplo, um gateway pode receber uma solicitação para um token de rede durante estabelecimento, ativação, ou modificação portador associado a um dispositivo cliente 2302. Como uma etapa opcional, pode ser feita uma determinação da necessidade de derivar uma chave secreta específica para um nó de acesso (por exemplo, eNóB) para a derivação do token de rede 2304. Caso a etapa opcional 2304 não seja usada, ou caso a determinação da necessidade de derivar a chave secreta específica para o nó de acesso resulte em uma decisão para não derivar a chave secreta específica para o nó de acesso, o método pode avançar para derivar 2306, no gateway, a partir de uma chave secreta conhecida apenas para o gateway, o token de rede. O gateway pode, em seguida, enviar o token de rede para o dispositivo cliente ou para um nó de acesso associado ao dispositivo cliente durante o estabelecimento, ativação, ou modificação do portador 2308. Caso a etapa opcional 2304 seja usada, ou caso a determinação da necessidade de derivar uma chave secreta específica para o nó de acesso resulte em uma decisão para derivar uma chave secreta específica para o nó de acesso, o método pode avançar para uma etapa de derivar a chave secreta específica para o nó de acesso 2310. A chave secreta específica para o nó de acesso (por exemplo, eNB) pode ser derivada com o uso de uma função de derivação de chave (KDF) que tem entradas que incluem, por exemplo, a chave secreta conhecida apenas pelo gateway (por exemplo, KNT) e, por exemplo, um identificador de um nó de acesso (por exemplo, identificador de eNB). Consequentemente, em um aspecto exemplificativo, KNT, eNB = KDF (KNT, eNB ID). Esse aspecto exemplificativo não é destinado a ser limitante.
[0176] De acordo com um aspecto, o token de rede pode ser derivado 2312 a partir de uma chave secreta específica para um nó de acesso ao qual o dispositivo cliente está conectado. O método pode incluir enviar o token de rede para o dispositivo cliente, e enviar a chave secreta específica para o nó de acesso para o nó de acesso 2314.
[0177] De acordo com um aspecto, um serviço de aplicativo para o dispositivo cliente pode ser identificado, em que o token de rede enviado para o dispositivo cliente ou para o nó de acesso pode ser associado ao serviço de aplicativo.
[0178] De acordo com um aspecto, recebimento ou obtenção de uma solicitação para o token de rede e o envio do token de rede (e, em alguns exemplos, a chave secreta derivada específica para o nó de acesso) são implantados em mensagens de controle.
[0179] De acordo com um aspecto, a derivação do token de rede pode ser com base em uma política de acesso. De acordo com ainda outro aspecto, o envio do token de rede para o dispositivo cliente pode adicionalmente compreender enviar o token de rede para uma entidade de gerenciamento de mobilidade (MME) e enviar o token de rede para o dispositivo cliente a partir da MME.
[0180] Conforme ilustrado na Figura exemplificativa 23, o token de rede pode ser derivado diretamente a partir de uma chave secreta conhecida apenas pelo gateway (consultar a etapa 2306) ou pode ser derivado indiretamente a partir da mesma chave secreta conhecida apenas pelo gateway, que pode ser usada para derivar uma chave secreta específica para o nó de acesso (consultar as etapas 2310, 2312).
[0181] Em alguns aspectos, o portador pode ser associada a um identificador (ID) de aplicativo e/ou a um ID de dispositivo cliente. Em alguns aspectos o serviço de aplicativo pode ser associado ao portador ou a um nome de ponto de acesso (APN). Em alguns aspectos, o token de rede pode ser associado (por exemplo, ligado a) ao dispositivo cliente e ao serviço de aplicativo.
[0182] Em alguns aspectos, o portador pode incluir uma pluralidade de modelos de fluxo de tráfego (TFTs). A pluralidade de TFTs pode corresponder a uma pluralidade de serviços de aplicativo.
[0183] De acordo com ainda outro aspecto, o envio do token de rede para o dispositivo cliente e o envio da chave secreta específica para o nó de acesso para o nó de acesso pode compreender adicionalmente enviar o token de rede e a chave secreta específica para o nó de acesso para uma entidade de gerenciamento de mobilidade (MME), enviar o token de rede para o dispositivo cliente a partir da MME, e enviar a chave secreta específica para o nó de acesso para o nó de acesso a partir da MME.
[0184] Em outro aspecto, o token de rede pode ser usado para impor uma política de acesso associada ao serviço de aplicativo e a chave secreta específica para o nó de acesso pode ser usada para validar o token de rede incluído em pacotes recebidos no nó de acesso antes de enviar os pacotes para o gateway para impedir que pacotes não autorizados alcancem o gateway.
[0185] A Figura 24 ilustra um método exemplificativo 2400 de estabelecer tokens de rede de enlace ascendente e de enlace descendente em um gateway (por exemplo, uma P-GW). Em um aspecto, uma solicitação para um token de rede durante o estabelecimento, ativação ou modificação portador associado a um dispositivo cliente pode ser recebida em um gateway 2402. Um serviço de aplicativo para o dispositivo cliente pode ser identificado 2404. Um token de rede de UL pode ser derivado no gateway 2406. Um token de rede de DL, diferente do token de rede de UL, também pode ser derivado no gateway 2408. Em um aspecto, o gateway pode enviar o token de rede de UL e o token de rede de DL para o dispositivo cliente 2410. Opcionalmente, o dispositivo cliente pode enviar o token de rede de enlace descendente para a APP na PDN 2412
[0186] Em um aspecto, a recepção ou obtenção de uma solicitação para um token de rede e o provisionamento do token de rede de UL e do token de rede de DL podem ser implantados em mensagens de controle.
[0187] Em um aspecto, derivar o token de rede de enlace ascendente tem como base uma chave conhecida pelo gateway e um parâmetro associado ao dispositivo cliente e derivar o token de rede de enlace descendente tem como base a chave conhecida pelo gateway e um parâmetro associado a um servidor de aplicativos.
[0188] Em um aspecto, enviar o token de rede de enlace ascendente e o token de rede de enlace descendente para o dispositivo cliente compreende adicionalmente enviar o token de rede de UL e o token de rede de DL para uma entidade de gerenciamento de mobilidade (MME) e enviar o token de rede de enlace ascendente e o token de rede de enlace descendente para o dispositivo cliente a partir da MME.
[0189] A Figura 25 é fluxograma de um método exemplificativo 2500, operacional em um gateway. O método pode incluir receber ou obter, no gateway, um pacote que inclui um token de rede 2502. O método pode continuar com validação/verificação do token de rede com o uso de uma chave conhecida pelo gateway 2504. Caso o token de rede seja válido, 2506, o método pode continuar descartando-se o token de rede e enviando-se o pacote para um servidor de aplicativos 2508. Caso o token de rede não seja válido, 2506, o método pode continuar descartando-se o pacote e o token de rede 2510.
[0190] Em um aspecto verificar o token de rede pode incluir derivar um token de rede de verificação a partir de uma função que tem um conjunto de parâmetros de entrada que inclui: a chave conhecida pelo gateway; e um índice de parâmetro de token de rede, endereço de protocolo Internet (IP) de fonte, número de porta de origem, endereço IP de destino, número de porta de destino, identificador (ID) de protocolo, ID de aplicativo, prioridade e/ou um identificador de classe de qualidade de serviço (QCI); e comparar o token de rede ao token de rede de verificação.
[0191] Em um aspecto, um método exemplificativo, operacional em um gateway, pode incluir receber ou obter, no gateway, um pacote a partir de um servidor de aplicativos, em que o pacote inclui um token de rede de enlace descendente, verificar o token de rede de enlace descendente com o uso de uma chave conhecida pelo gateway, descartar o pacote e token de rede de enlace descendente caso a verificação não seja bem sucedida, e descartar o token de rede de enlace descendente e enviar o pacote para um dispositivo cliente, com base em parâmetros representados pelo token de rede de enlace descendente, caso a verificação seja bem sucedida.
[0192] As implantações específicas mostradas e descritas são apenas exemplos e não devem ser interpretados como a única forma para implantar a presente revelação a menos que especificado de outra forma no presente documento. Fica prontamente evidente para uma pessoa de habilidade comum na técnica que os vários exemplos na presente revelação podem ser praticados por inúmeras soluções de segmentação diferentes.
[0193] Um ou mais dos componentes, atos, características e/ou funções descritos no presente documento e ilustrados nos desenhos podem ser reorganizados e/ou combinados em um componente, ato, característica ou função única ou incorporados em diversos componentes, atos, características ou funções. Elementos, componentes, atos e/ou funções adicionais também podem ser adicionados sem que se afaste da invenção. Os algoritmos descritos no presente documento também podem ser implantados de forma eficiente em software e/ou incorporados em hardware.
[0194] Na descrição, elementos, circuitos, funções e módulos podem ser mostrados na forma de diagrama de blocos para não para obscurecer a presente revelação em detalhes desnecessários. Ao contrário, implantações específicas mostradas e descritas são apenas exemplificativas e não devem ser interpretadas como a única forma para implantar a presente revelação a menos que especificado de outra forma no presente documento. Adicionalmente, definições de bloco e segmentação de lógica entre vários blocos são exemplificativas de uma implantação específica. Fica prontamente evidente para uma pessoa de habilidade comum na técnica que a presente revelação pode ser praticada por inúmeras soluções de segmentação diferentes. Em sua maior parte, os detalhes que dizem respeito às considerações de temporização e similares foram omitidos pelo fato de que tais detalhes não são necessários para obter um entendimento completo da presente revelação e estão dentro dos conhecimentos de pessoas de habilidade comum na técnica relevante.
[0195] Além disso, é observado que as modalidades podem ser descritas como um processo que é representado como um fluxograma, um diagrama de fluxo, um diagrama de estrutura ou um diagrama de blocos. Embora um fluxograma possa descrever as operações como um processo sequencial, muitas das operações podem ser realizadas em paralelo ou concorrentemente. Além disso, a ordem das operações pode ser reorganizada. Um processo é terminado quando suas operações são concluídas. Um processo pode corresponder a um método, uma função, um procedimento, uma sub-rotina, um subprograma, etc. Quando um processo corresponde a uma função, seu término corresponde a um retorno da função para a função solicitante ou da função principal.
[0196] As pessoas de habilidade comum na técnica compreenderiam que as informações e sinais podem ser representados com o uso de qualquer uma dentre uma variedade de tecnologias e técnicas diferentes. Por exemplo, dados, instruções, comandos, informações, sinais, bits, tokens e chips que podem ser referenciados ao longo dessa descrição podem ser representados por tensões, correntes, ondas eletromagnéticas, campos ou partículas magnéticas, campos ou partículas ópticas, ou qualquer combinação dos mesmos. Alguns desenhos podem ilustrar sinais como um único sinal para clareza de apresentação e descrição. Será compreendido por uma pessoas de habilidade comum na técnica que o sinal pode representar um barramento de sinais, em que o barramento pode ter uma variedade de larguras de bits e a presente revelação pode ser implantada em qualquer número de sinais de dados, que inclui um único sinal de dados.
[0197] Deve ser compreendido que qualquer referência a um elemento no presente documento com o uso de uma designação tal como “primeiro”, “segundo” e assim por diante não limita a quantidade ou ordem desses elementos, a menos que tal limitação seja apresentada explicitamente. Ao invés disso, essas designações podem ser usadas no presente documento como um método conveniente para distinguir entre dois ou mais elementos ou instâncias de um elemento. Assim, uma referência ao primeiro e ao segundo elementos não significa que somente dois elementos podem ser empregados no mesmo ou que o primeiro elemento deve preceder o segundo elemento de algum modo. Além disso, a menos que exposto de outra forma, um conjunto de elementos pode compreender um ou mais elementos.
[0198] Além disso, uma mídia de armazenamento pode representar um ou mais dispositivos para armazenar dados, que incluem memória apenas de leitura (ROM), memória de acesso aleatório (RAM), mídias de armazenamento magnético, mídias de armazenamento óptico, dispositivos de memória flash e/ou outras mídias legíveis por máquina e, mídias legíveis por processador, e/ou mídias legíveis por computador para armazenar informações. Os termos “mídia legível por máquina”, “mídia legível por computador” e/ou “mídia legível por processador” podem incluir, porém, sem limitações, mídias não transitórias tais como dispositivos de armazenamento portáteis ou fixos, dispositivos de armazenamento óptico e várias outras mídias capazes de armazenar, conter ou transportar instrução (ou instruções) e/ou dados. Portanto, os vários métodos descritos no presente documento podem ser total ou parcialmente implantados por instruções e/ou dados que podem ser armazenados em uma “mídia legível por máquina”, “mídia legível por computador” e/ou “mídia legível por processador” e executados por um ou mais processadores, máquinas e/ou dispositivos.
[0199] Além disso, modalidades podem ser implantadas por hardware, software, firmware, middleware, microcódigo, ou qualquer combinação dos mesmos. Quando implantada em software, firmware, middleware, ou microcódigo, o código de programa ou segmentos de código para realizar as tarefas necessárias podem ser armazenados em uma mídia legível por máquina tal como uma mídia de armazenamento ou outro armazenamento (ou armazenamentos). Um processador pode realizar as tarefas necessárias. Um segmento de código pode representar um procedimento, uma função, um subprograma, um programa, uma rotina, uma sub- rotina, um módulo, um pacote de software, uma classe, ou qualquer combinação de instruções, dados estruturas, ou instruções de programas. Um segmento de código pode ser acoplado a outro segmento de código ou um circuito de hardware através da passagem de informações, dados, argumentos, parâmetros ou conteúdos de memória. As informações, argumentos, parâmetros, dados, etc. podem ser passados, encaminhados, ou transmitidos por meio de qualquer meio adequado que inclui compartilhamento de memória, passagem de mensagem, passagem de token, transmissão de rede, etc.
[0200] Os vários blocos lógicos, elementos, circuitos, módulos, funções e/ou componentes ilustrativos descritos em conexão com os exemplos revelados no presente documento podem ser implantados ou realizados com um processador de propósito geral, um processador de sinal digital (DSP), um circuito integrado de aplicativo específica (ASIC), uma matriz gateways programáveis no campo (FPGA) ou outro componente lógico programável, porta distinta ou lógica de transistor, componentes de hardware distintos, ou qualquer combinação dos mesmos projetada para realizar as funções descritas no presente documento. Um processador de propósito geral pode ser um microprocessador, mas como uma alternativa, o processador pode ser qualquer processador, controlador, microcontrolador, ou máquina de estado convencional. Um processador também pode ser implantado como uma combinação de componentes de computação, por exemplo, uma combinação de um DSP e um microprocessador, um número de microprocessadores, um ou mais microprocessadores em conjunto com um núcleo de DSP, ou qualquer outra configuração semelhante. Um processador de propósito geral, configurado para executar as modalidades descritas no presente documento, é considerado um processador de propósito especial para realizar tais modalidades. De maneira similar, um computador de propósito geral é considerado um computador de propósito especial quando configurado para realizar as modalidades descritas no presente documento.
[0201] Os métodos ou algoritmos descritos em conexão com os exemplos revelados no presente documento podem ser incorporados diretamente em hardware, em um módulo de software executável por um processador, ou em uma combinação de ambos, na forma de unidade de processamento, instruções de programação, ou outras direções, e pode ser contido em um único dispositivo ou distribuído por múltiplos dispositivos. Um módulo de software pode residir em memória RAM, memória flash, memória ROM, memória EPROM, memória EEPROM, registradores, disco rígido, um disquete, um CD-ROM, ou qualquer outra forma de mídia de armazenamento conhecida na técnica. Uma mídia de armazenamento pode ser acoplada ao processador de modo que o processador possa ler informações de, e gravar informações em, a mídia de armazenamento. Como uma alternativa, a mídia de armazenamento pode ser integrada ao processador.
[0202] As pessoas versadas na técnica avaliariam adicionalmente que os vários blocos lógicos, circuitos, funções, módulos, e etapas de algoritmo ilustrativos descritos em conexão com as modalidades reveladas no presente documento podem ser implantados como hardware eletrônico, software de computador, ou combinações de ambos. Para ilustrar claramente essa intercambialidade de hardware e software, vários elementos, componentes, blocos, circuitos, funções, módulos, e etapas ilustrativos foram descritos acima, de maneira geral, em termos de sua funcionalidade. A implantação dessa funcionalidade como hardware, software, ou uma combinação dos mesmos depende do aplicativo particular e seleções de projeto impostas ao sistema em geral.
[0203] As várias características da invenção descritas no presente documento podem ser implantadas em sistemas diferentes sem que se afaste da invenção. Deve ser observado que as modalidades expostas acima são meramente exemplos e não devem ser interpretadas como limitantes à invenção. A descrição das modalidades é destinada a ser ilustrativa, e não a limitar o escopo das reivindicações. Como tal, os presentes ensinamentos podem ser prontamente aplicados a outros tipos de aparelhos e muitas alternativas, modificações e variações ficarão evidentes para as pessoas versadas na técnica.
Claims (14)
1. Método operacional em um dispositivo cliente (202), caracterizado pelo fato de que compreende: estabelecer um conjunto de um ou mais fluxos associados a um ou mais aplicativos com o uso de sinalização de plano de controle; obter, a partir de um dispositivo gateway, no dispositivo cliente durante sinalização de plano de controle, um primeiro token de rede, em que o primeiro token de rede é: derivado com base em metadados; associado a um primeiro fluxo do conjunto de um ou mais fluxos; associado a um primeiro aplicativo dentre os um ou mais aplicativos; e provisionado para o dispositivo cliente através da sinalização de plano de controle; e derivado como um token de rede de enlace ascendente e um token de rede de enlace descendente, diferente do token de rede de enlace ascendente, em que: a derivação do token de rede de enlace ascendente baseia-se em uma chave conhecida pelo dispositivo gateway e em um parâmetro associado ao dispositivo cliente; e a derivação do token de rede de enlace descendente baseia-se na chave conhecida pelo dispositivo gateway e em um parâmetro associado a um servidor de aplicativos, e transportar o primeiro token de rede a partir do dispositivo cliente para um dispositivo gateway em: um cabeçalho shim em uma camada shim entre uma camada de protocolo Internet, IP, e uma camada de controle de acesso ao meio, MAC; um cabeçalho de protocolo de convergência de dados em pacote, PDCP; e/ou um cabeçalho de extensão de IP conforme definido em IP versão 6, IPv6.
2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende adicionalmente: enviar, a partir do dispositivo cliente, o primeiro token de rede com um ou todos os pacotes associados com o primeiro fluxo.
3. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que: o primeiro token de rede é provisionado em resposta a uma solicitação implícita para o primeiro token de rede; e a solicitação implícita inclui um dentre: uma mensagem de solicitação de conexão de rede de dados em pacote, PDN, uma mensagem de solicitação de ativação portador dedicado, ou uma mensagem de solicitação de modificação portador.
4. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que o primeiro token de rede é transparente para um nó de acesso.
5. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende adicionalmente: obter, no dispositivo cliente durante a sinalização de plano de controle, um segundo token de rede, em que o segundo token de rede é: derivado por um segundo dispositivo que é diferente de um primeiro dispositivo que derivou o primeiro token; associado ao primeiro fluxo do conjunto de um ou mais fluxos; associado ao primeiro aplicativo dentre os um ou mais aplicativos; e provisionado para o dispositivo através da sinalização de plano de controle.
6. Dispositivo cliente (202), caracterizado pelo fato de que compreende: uma interface de rede (210); e um circuito de processamento (212) acoplado à interface de rede, o circuito de processamento configurado para realizar o método conforme definido em qualquer uma das reivindicações 1 a 5.
7. Método operacional em um dispositivo gateway (208), caracterizado pelo fato de que compreende: obter, no dispositivo gateway, uma solicitação para um token de rede durante sinalização de plano de controle associada à configuração, ativação ou modificação de conexão de dados associada a um dispositivo cliente; derivar, no dispositivo gateway, o token de rede, o token de rede associado a um fluxo e um serviço de aplicativo de acordo com uma política de acesso; e enviar, através de sinalização de plano de controle, o token de rede para o dispositivo cliente durante a sinalização de plano de controle, em que o token de rede é derivado como um token de rede de enlace ascendente e um token de rede de enlace descendente, diferente do token de rede de enlace ascendente, a derivação do token de enlace ascendente baseia-se em uma chave conhecida pelo dispositivo gateway e em um parâmetro associado ao dispositivo cliente; e a derivação do token de rede de enlace descendente baseia-se na chave conhecida pelo dispositivo gateway e em um parâmetro associado a um servidor de aplicativos, e o método compreendendo adicionalmente enviar o token de enlace ascendente e o token de enlace descendente para o dispositivo cliente.
8. Método, de acordo com a reivindicação 7, caracterizado pelo fato de que compreende adicionalmente: obter, no dispositivo gateway, um primeiro pacote que inclui o token de rede; e direcionar o primeiro pacote entre o dispositivo cliente e o serviço de aplicativo utilizando dados associados ao token de rede incluído com o primeiro pacote sem o uso de inspeção de pacote.
9. Método, de acordo com a reivindicação 7, caracterizado pelo fato de que compreende adicionalmente: obter, no dispositivo gateway, um primeiro pacote que inclui o token de rede; verificar o token de rede com o uso de uma chave conhecida pelo dispositivo gateway; descartar o primeiro pacote que inclui o token de rede caso a verificação não seja bem sucedida; e direcionar o primeiro pacote entre o dispositivo cliente e o serviço de aplicativo com o uso do token de rede incluído com o primeiro pacote sem o uso de inspeção de pacote caso a verificação seja bem sucedida.
10. Método, de acordo com a reivindicação 9, caracterizado pelo fato de que a verificação do token de rede inclui: derivar um token de rede de verificação a partir de uma função que tem um conjunto de parâmetros de entrada incluindo: a chave conhecida pelo dispositivo gateway; e um índice de parâmetro de token de rede, endereço de protocolo Internet, IP, de origem, número de porta de origem, endereço IP de destino, número de porta de destino, identificador de protocolo, ID, ID de aplicativo, prioridade e/ou um identificador de classe de qualidade de serviço, QCI; e comparar o token de rede ao token de rede de verificação.
11. Método, de acordo com a reivindicação 10, caracterizado pelo fato de que compreende adicionalmente: identificar um índice de parâmetro de token de rede antes de verificar o token de rede, em que o índice de parâmetro de token de rede define uma lista de parâmetros de entrada; e derivar um token de rede de verificação a partir de uma função que tem, como entrada, a chave conhecida pelo dispositivo gateway e a lista de parâmetros de entrada, em que o índice de parâmetro de token de rede define adicionalmente um identificador de aplicativo, ID, ou a lista de parâmetros de entrada é armazenada em uma tabela no dispositivo gateway, ou o token de rede é portado em um cabeçalho shim separado de um cabeçalho IP, ou o token de rede é portado em um cabeçalho de protocolo de túnel, GTP, de serviço de rádio de pacote geral, GPRS, ou o token de rede é portado em um cabeçalho de extensão de IP definido em protocolo Internet, IP, versão 6, IPv6.
12. Dispositivo gateway (208) caracterizado pelo fato de que compreende: uma interface de rede; e um circuito de processamento (220) acoplado à interface de rede, o circuito de processamento é configurado para realizar o método conforme definido em qualquer uma das reivindicações 7 a 11.
13. Método operacional em um nó de acesso (204), associado a um dispositivo cliente, caracterizado pelo fato de que compreende: obter, no nó de acesso durante a sinalização de plano de controle, um token de rede, em que o token de rede é: associado a um primeiro fluxo de um conjunto de um ou mais fluxos; associado a um primeiro aplicativo dentre um ou mais aplicativos associados aos um ou mais fluxos; e provisionado para o nó de acesso através da sinalização de plano de controle, e em que o token de rede é derivado como um token de enlace ascendente e um token de rede de enlace descendente, diferente do token de enlace ascendente; a derivação do token de rede de enlace ascendente baseia-se em uma chave conhecida por um dispositivo gateway e em um parâmetro associado a um dispositivo cliente; e a derivação do token de rede de enlace descendente baseia-se na chave conhecida pelo dispositivo gateway e em um parâmetro associado a um servidor de aplicativos.
14. Método, de acordo com a reivindicação 13, caracterizado pelo fato de que compreende adicionalmente: enviar, a partir do nó de acesso, o token de rede com um ou todos os pacotes associados com o primeiro fluxo.
Applications Claiming Priority (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US201562120135P | 2015-02-24 | 2015-02-24 | |
| US62/120,135 | 2015-02-24 | ||
| US14/832,965 US9819596B2 (en) | 2015-02-24 | 2015-08-21 | Efficient policy enforcement using network tokens for services C-plane approach |
| US14/832,965 | 2015-08-21 | ||
| PCT/US2016/018104 WO2016175909A2 (en) | 2015-02-24 | 2016-02-16 | Efficient policy enforcement using network tokens for services c-plane approach |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| BR112017018018A2 BR112017018018A2 (pt) | 2018-04-10 |
| BR112017018018B1 true BR112017018018B1 (pt) | 2024-01-16 |
Family
ID=56690619
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| BR112017018018-9A BR112017018018B1 (pt) | 2015-02-24 | 2016-02-16 | Método operacional em um dispositivo cliente, dispositivo cliente,método operacional em um dispositivo gateway, dispositivo gateway e método operacional em um nó de acesso associado a um dispositivo cliente |
Country Status (8)
| Country | Link |
|---|---|
| US (1) | US9819596B2 (pt) |
| EP (1) | EP3262813B1 (pt) |
| JP (1) | JP6438593B2 (pt) |
| KR (1) | KR101846155B1 (pt) |
| CN (1) | CN107251522B (pt) |
| BR (1) | BR112017018018B1 (pt) |
| TW (1) | TWI625951B (pt) |
| WO (1) | WO2016175909A2 (pt) |
Families Citing this family (22)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10171463B1 (en) * | 2015-12-21 | 2019-01-01 | Amazon Technologies, Inc. | Secure transport layer authentication of network traffic |
| EP3378249B1 (en) | 2016-01-27 | 2021-08-04 | Samsung Electronics Co., Ltd. | Method and apparatus for reducing signaling overhead and reducing battery of terminal |
| WO2018108261A1 (en) * | 2016-12-14 | 2018-06-21 | Nokia Technologies Oy | Handover in communications network |
| US10395036B2 (en) * | 2017-03-16 | 2019-08-27 | Dell Products, L.P. | Continued runtime authentication of information handling system (IHS) applications |
| US10231250B2 (en) * | 2017-03-20 | 2019-03-12 | Qualcomm Incorporated | Policy communication via control plane signaling |
| US10700959B2 (en) | 2017-04-09 | 2020-06-30 | Barefoot Networks, Inc. | Source routing design with simplified forwarding elements |
| ES2964955T3 (es) | 2017-05-09 | 2024-04-10 | Network Next Inc | Métodos de intercambio de paquetes bidireccional a través de vías nodales |
| WO2018205148A1 (zh) * | 2017-05-09 | 2018-11-15 | 华为技术有限公司 | 一种数据包校验方法及设备 |
| US10757105B2 (en) * | 2017-06-12 | 2020-08-25 | At&T Intellectual Property I, L.P. | On-demand network security system |
| US10701587B2 (en) * | 2017-10-15 | 2020-06-30 | Qualcomm Incorporated | Policy provisioning at a user equipment (UE) |
| RU2746923C1 (ru) * | 2018-02-15 | 2021-04-22 | Телефонактиеболагет Лм Эрикссон (Пабл) | Способ для улучшения безопасности передачи данных |
| DK3777047T3 (da) * | 2018-03-30 | 2023-01-09 | V2Com S A | System og fremgangsmåde til ressourceforvaltning og ressourceallokering i et selvoptimerende netværk af heterogene behandlingsknudepunkter |
| CN108848037B (zh) * | 2018-05-31 | 2023-06-20 | 平安医疗科技有限公司 | 业务请求处理方法、装置、计算机设备和存储介质 |
| US20220060901A1 (en) * | 2019-01-11 | 2022-02-24 | Nec Corporation | Source base station, ue, method in wireless communication system |
| WO2020191095A1 (en) * | 2019-03-20 | 2020-09-24 | Network Next, Inc. | Network route optimization using excess private network capacity |
| CN113767654A (zh) * | 2019-04-25 | 2021-12-07 | 瑞典爱立信有限公司 | 用于使属于归属网络的用户设备能够接入拜访网络中的数据通信服务的受信解决方案 |
| CN110149211B (zh) * | 2019-05-15 | 2023-04-07 | 杭州朗和科技有限公司 | 服务鉴权方法、服务鉴权装置、介质以及电子设备 |
| CN110392061A (zh) * | 2019-08-06 | 2019-10-29 | 郑州信大捷安信息技术股份有限公司 | 一种网络接入控制系统及方法 |
| CN114040398A (zh) * | 2020-07-21 | 2022-02-11 | 中国电信股份有限公司 | 服务质量保障提供方法、系统、网络设备和存储介质 |
| CN113542150B (zh) * | 2021-07-14 | 2023-06-02 | 杭州海康威视数字技术股份有限公司 | 一种数据传输方法、装置及中心端网桥 |
| CN113691596B (zh) * | 2021-08-12 | 2023-06-30 | 北京奇艺世纪科技有限公司 | 一种网关控制方法、装置、电子设备及存储介质 |
| KR102463051B1 (ko) * | 2021-11-23 | 2022-11-03 | 펜타시큐리티시스템 주식회사 | 선박 네트워크 접근제어 방법 및 장치 |
Family Cites Families (30)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1332627B1 (en) | 2000-11-06 | 2007-10-10 | Telefonaktiebolaget LM Ericsson (publ) | Method and apparatus for coordinated charging of services in a multimedia session |
| US7916700B2 (en) | 2004-06-30 | 2011-03-29 | Nokia Corporation | Dynamic service information for the access network |
| JP5239341B2 (ja) * | 2008-01-08 | 2013-07-17 | 日本電気株式会社 | ゲートウェイ、中継方法及びプログラム |
| WO2010066295A1 (en) | 2008-12-10 | 2010-06-17 | Telefonaktiebolaget Lm Ericsson (Publ) | Token-based correlation of control sessions for policy and charging control of a data session through a nat |
| JP2010177752A (ja) * | 2009-01-27 | 2010-08-12 | Hitachi Ltd | ネットワーク通信装置 |
| KR101679891B1 (ko) * | 2009-03-27 | 2016-11-25 | 샤프 가부시키가이샤 | 이동 단말 장치 및 그 통신 방법, 외부 게이트웨이 장치 및 그 통신 방법, 및 이동체 통신 시스템 |
| KR101528496B1 (ko) * | 2009-04-17 | 2015-06-15 | 삼성전자주식회사 | 이동 통신 시스템에서 비계층 프로토콜을 이용하여 응급 콜 서비스를 지원하는 방법 및 시스템 |
| US8547931B2 (en) * | 2009-05-21 | 2013-10-01 | Microsoft Corporation | Conserving call logic during handoff |
| US9398517B2 (en) * | 2010-01-11 | 2016-07-19 | Blackberry Limited | System and method for enabling discovery of local service availability in local cellular coverage |
| US20120020818A1 (en) | 2010-07-20 | 2012-01-26 | Peter Chen | Air compressor structure for paint spraying |
| JP2012044344A (ja) * | 2010-08-17 | 2012-03-01 | Nippon Telegr & Teleph Corp <Ntt> | ゲートウェイ装置およびｉｐトンネル選択方法 |
| KR101941634B1 (ko) | 2011-01-28 | 2019-01-24 | 삼성전자 주식회사 | 이동통신 시스템의 과금 제어장치 및 방법 |
| KR101673622B1 (ko) | 2011-01-28 | 2016-11-08 | 삼성전자주식회사 | 무선통신 시스템에서 서비스품질에 따른 서비스 제공 방법 및 장치 |
| EP2727401A1 (en) * | 2011-07-01 | 2014-05-07 | InterDigital Patent Holdings, Inc. | Method and apparatus for supporting local ip access -lipa- mobility |
| WO2013010567A1 (en) | 2011-07-15 | 2013-01-24 | Telefonaktiebolaget L M Ericsson (Publ) | Policy tokens in communication networks |
| WO2013017176A1 (en) | 2011-08-04 | 2013-02-07 | Telefonaktiebolaget L M Ericsson (Publ) | Providing content related quality of service in packet switched communication network |
| KR101929299B1 (ko) * | 2011-12-06 | 2019-03-13 | 삼성전자주식회사 | 이동통신 네트워크에서 요금 지불을 대행하는 인터넷 서비스 제공 방법 및 장치 |
| EP2805470B1 (en) * | 2012-01-20 | 2018-09-12 | Interdigital Patent Holdings, Inc. | Identity management with local functionality |
| KR102148341B1 (ko) * | 2012-01-20 | 2020-10-14 | 삼성전자 주식회사 | 데이터 전송의 우선권 설정 방법 및 장치 |
| EP2898662A4 (en) * | 2012-09-20 | 2016-05-25 | Nec Corp | METHOD AND SYSTEM FOR CONTROLLING INVOICING IN A COMMUNICATION NETWORK |
| US20150264739A1 (en) * | 2012-10-08 | 2015-09-17 | Nokia Solutions And Networks Oy | Methods, devices, and computer program products for keeping devices attached without a default bearer |
| US10516984B2 (en) * | 2013-03-26 | 2019-12-24 | Sharp Kabushiki Kaisha | Terminal device, base station device, and control device |
| US10111060B2 (en) * | 2013-06-12 | 2018-10-23 | Cisco Tecnology, Inc. | Client app service on mobile network |
| US9749476B2 (en) | 2013-06-27 | 2017-08-29 | Orange | System and method for providing toll-free application data access |
| US10547651B2 (en) | 2013-07-26 | 2020-01-28 | Apple Inc. | System and method for providing telephony services over WiFi for non-cellular devices |
| US9537659B2 (en) | 2013-08-30 | 2017-01-03 | Verizon Patent And Licensing Inc. | Authenticating a user device to access services based on a device ID |
| WO2015105183A1 (ja) * | 2014-01-10 | 2015-07-16 | シャープ株式会社 | 通信制御方法、位置管理装置、基地局装置、端末装置および通信システム |
| GB201402308D0 (en) * | 2014-02-11 | 2014-03-26 | Nec Corp | Communication system |
| US20160277956A1 (en) * | 2014-03-03 | 2016-09-22 | Telefonaktiebolaget L M Ericsson (Publ) | Methods and Devices for Improving Connection Procedures in Radio Access Networks |
| US9980310B2 (en) * | 2014-10-17 | 2018-05-22 | Mediatek Inc. | Method for processing unsuccessful PDN establishment request |
-
2015
- 2015-08-21 US US14/832,965 patent/US9819596B2/en active Active
-
2016
- 2016-02-15 TW TW105104337A patent/TWI625951B/zh active
- 2016-02-16 BR BR112017018018-9A patent/BR112017018018B1/pt active IP Right Grant
- 2016-02-16 CN CN201680011578.4A patent/CN107251522B/zh active Active
- 2016-02-16 WO PCT/US2016/018104 patent/WO2016175909A2/en active Application Filing
- 2016-02-16 EP EP16753730.7A patent/EP3262813B1/en active Active
- 2016-02-16 KR KR1020177023277A patent/KR101846155B1/ko active IP Right Grant
- 2016-02-16 JP JP2017544301A patent/JP6438593B2/ja active Active
Also Published As
| Publication number | Publication date |
|---|---|
| KR101846155B1 (ko) | 2018-04-06 |
| EP3262813B1 (en) | 2020-06-03 |
| US9819596B2 (en) | 2017-11-14 |
| KR20170118752A (ko) | 2017-10-25 |
| BR112017018018A2 (pt) | 2018-04-10 |
| EP3262813A2 (en) | 2018-01-03 |
| TWI625951B (zh) | 2018-06-01 |
| US20160248686A1 (en) | 2016-08-25 |
| JP2018509090A (ja) | 2018-03-29 |
| WO2016175909A9 (en) | 2017-08-17 |
| WO2016175909A3 (en) | 2017-02-09 |
| CN107251522A (zh) | 2017-10-13 |
| TW201644236A (zh) | 2016-12-16 |
| JP6438593B2 (ja) | 2018-12-19 |
| WO2016175909A2 (en) | 2016-11-03 |
| CN107251522B (zh) | 2018-09-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| BR112017018018B1 (pt) | Método operacional em um dispositivo cliente, dispositivo cliente,método operacional em um dispositivo gateway, dispositivo gateway e método operacional em um nó de acesso associado a um dispositivo cliente | |
| US11910191B2 (en) | Efficient policy enforcement using network tokens for services—user-plane approach | |
| US11290382B2 (en) | Efficient policy enforcement for downlink traffic using network access tokens—control-plane approach | |
| KR102517014B1 (ko) | 서비스 레이어에서의 트래픽 스티어링 | |
| BR112021005537A2 (pt) | sistemas e método para proteção de segurança de mensagens nas | |
| BR112017020675B1 (pt) | Acordo de autenticação e chave com sigilo perfeito de emissão | |
| US20140041022A1 (en) | Method and apparatus for providing notification of detected error conditions in a network | |
| BR112015016050B1 (pt) | Sistemas e métodos para acessar uma rede | |
| BR112017019799B1 (pt) | Método operacional em um dispositivo de usuário e dispositivo de usuário, método operacional em um dispositivo de rede de comunicação de longa distância sem fio e dispositivo de rede de comunicação de longa distância sem fio | |
| BR112021006571A2 (pt) | sistemas e método para atualizações seguras de parâmetros de configuração provisionados em equipamento do usuário | |
| BR112014018430B1 (pt) | Aparelho e método para comunicação em uma rede de comunicação sem fio de acesso múltiplo, memória legível por computador e aparelho para comunicação por um dispositivo sem fio em uma rede de comunicação sem fio de acesso múltiplo | |
| EP3552367B1 (en) | Method and intermediate network node for managing tcp segment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| B06U | Preliminary requirement: requests with searches performed by other patent offices: procedure suspended [chapter 6.21 patent gazette] | ||
| B09A | Decision: intention to grant [chapter 9.1 patent gazette] | ||
| B16A | Patent or certificate of addition of invention granted [chapter 16.1 patent gazette] |
Free format text: PRAZO DE VALIDADE: 20 (VINTE) ANOS CONTADOS A PARTIR DE 16/02/2016, OBSERVADAS AS CONDICOES LEGAIS |