BRPI0907178B1

BRPI0907178B1 - Regras de controle de política e tarifação (pcc) com base em protocolo de mobilidade

Info

Publication number: BRPI0907178B1
Application number: BRPI0907178-4A
Authority: BR
Inventors: Gerardo Giaretta; Kalle I. Ahmavaara; Lorenzo Casaccia; George Tsirtsis; Arungundram C. Mahendran
Original assignee: Qualcomm Incorporated
Priority date: 2008-01-14
Filing date: 2009-01-14
Publication date: 2020-09-29
Also published as: US20090182883A1; EP2238712A1; IL206651A; KR20100108594A; CN101911588A; EP2238712B1; RU2010133991A; KR101436511B1; IL206651A0; UA99324C2; RU2484606C2; WO2009091776A1; EP3373512A1; AU2009205489B2; CA2710887A1; CN101911588B; BRPI0907178A2; MY157034A; CA2710887C; US8155020B2

Abstract

REGRAS DE CONTROLE DE DIRETIVA E TAXAÇÃO (PCC) COM BASE EM PROTOCOLO DE MOBILIDADE. Técnicas para suportar funções de controle política e taxação (pcc) em uma rede de comunicação sem fio são descritas. Em um projeto, uma função de regras controle de política e taxação (PCRF) pode receber uma solicitação de uma primeira entidade de rede ( por exemplo , um agente nativo) para estabelecer uma sessão de pcc para um equipamento de usuário (UE) acessar a primeira entidade de rede usando um protocolo de mobilidade (por exemplo, IP móvel). A PCRF pode determinar o protocolo de mobilidade utilizando pelo UE com base em um parâmetro tipo IP-CAN de pcc para sessão de pcc com base no protocolo mobilidade e pode enviar as regras de pcc para a primeira entidade de rede. A primeira entidade de rede pode aplicar as regras de pcc em pacotes para sessão de pcc e pode contar cada pacote para taxação . A segunda entidade de rede pode encaminhar os pacotes, mas não conta esses pacotes para taxação.

Description

CAMPO DA INVENÇÃO

[0001] A presente descrição refere-se, de modo geral, a comunicação e, mais especificamente a técnicas para suportar funções de controle de políticas e tarifação (PCC) em uma rede de comunicação sem fio.

DESCRIÇÃO DO ESTADO DA TÉCNICA

[0002] Redes de comunicação sem fio são amplamente utilizadas para prover serviços de comunicação tais como voz, video, dados por pacotes, mensagens, broadcast, etc. Estas redes sem fio podem ser de redes de acesso múltiplo capazes de suportar múltiplos usuários compartilhando os recursos de rede disponíveis. Exemplos dessas redes de acesso múltiplo incluem redes de Acesso Múltiplo por Divisão de Código (CDMA), redes de Acesso Múltiplo por Divisão de Tempo (TDMA), redes de Acesso Múltiplo por Divisão de Frequência (FDMA) , redes FDMA ortogonal (OFDMA) e redes FDMA de Única Portadora (SC-FDMA).

[0003] Um equipamento de usuário (UE) pode se comunicar com uma rede sem fio a fim de trocar dados com uma entidade remota (por exemplo, outro UE) . O UE pode trocar pacotes de dados com as entidades remotas, e estes pacotes podem ser roteados através de várias entidades de rede na rede sem fio. Os pacotes podem ser processados de forma diferente pelas entidades de rede dependendo de se o UE está utilizando um protocolo de mobilidade ou não, tal como Protocolo Internet Móvel (MIP) para suportar roaming. Pode ser desejável suportar adequadamente as funções PCC independentemente se um protocolo de mobilidade é usado pelo UE ou não.

SUMÁRIO DA INVENÇÃO

[0004] Técnicas para suportar funções PCC em uma rede de comunicação sem fio são descritas. Em um aspecto, regras de PCC para uma sessão de PCC podem ser determinadas com base (isto é, levando em consideração), um parâmetro que pode indicar se um protocolo de mobilidade é usado por um UE. Este parâmetro pode ser um parâmetro tipo IP-CAN que está presente em sinalização PCC. As regras de PCC determinadas desta forma podem prover algumas vantagens, como descrito abaixo.

[0005] Em um projeto, uma função de regras de controle de política e tarifação (PCRF) (ou uma entidade de rede equivalente) pode receber uma solicitação/indicação de uma primeira entidade de rede (por exemplo, um agente nativo) para estabelecer uma sessão de PCC para um UE acessara primeira entidade de rede usando um protocolo de mobilidade (por exemplo, MIP). A solicitação pode incluir o parâmetro tipo IP-CAN, que pode ser ajustado para o protocolo de mobilidade. A PCRF pode determinar o protocolo de mobilidade utilizado pelo UE com base no parâmetro tipo IP-CAN e pode determinar regras de PCC para a sessão de PCC com base no protocolo de mobilidade. As regras de PCC podem incluir um primeiro conjunto de pelo menos um filtro para identificar pacotes para a sessão de PCC, uma indicação de se conta os pacotes para tarifação, regras de qualidade de serviço (QoS) para os pacotes, cobra informações para a sessão de PCC, e/ou outras informações relacionadas à sessão de PCC. A PCRF pode enviar as regras de PCC para a primeira entidade de rede, que pode aplicar as regras de PCC nos pacotes para a sessão de PCC e pode contar cada pacote para tarifação.

[0006] Os pacotes para a sessão de PCC podem ser tunelados em pacotes tunelados, que podem ser trocados entre o UE e a primeira entidade de rede através de uma segunda entidade de rede (por exemplo, um gateway de serviço). Neste caso, A PCRF pode determinar a segunda regra de PCC para segunda entidade de rede. A segunda regra de PCC pode incluir (i) um segundo conjunto de pelo menos um filtro para identificar os pacotes tunelados e (ii) uma indicação para não contar os pacotes tunelados para tarifação, que pode ser implicitamente provida pela ausência de informações de tarifação na segunda regra de PCC. A PCRF pode enviar a segunda regra de PCC para segunda entidade de rede, que pode aplicar a segunda regra de PCC nos pacotes tunelados. Os pacotes tunelados podem ser contados apenas uma vez para tarifação pela primeira entidade de rede e não pela segunda entidade de rede.

[0007] Vários aspectos e características da divulgação são descritos em detalhes mais adiante.

BREVE DESCRIÇÃO DAS FIGURAS

[0008] A figura 1 mostra um exemplo de implantação de rede.

[0009] A figura 2 mostra processamento de pacote para tunelar um pacote de protocolo Internet (IP).

[0010] As figuras 3 e 4 mostram dois processos para suportar PCC usando tipo IP-CAN.

[0011] As figuras 5 e 6 mostram um processo e um equipamento, respectivamente, para suportar funções PCC por uma PCRF.

[0012] As figuras 7 e 8 mostram um processo e um equipamento, respectivamente, para suportar funções PCC por um agente nativo.

[0013] As figuras 9 e 10 mostram um processo e um equipamento, respectivamente, para suportar funções PCC por um gateway de serviço.

[0014] As figuras 11 e 12 mostram um processo e um equipamento, respectivamente, para suportar funções PCC por um UE.

[0015] A figura 13 mostra um diagrama de blocos de várias entidades de rede na figura 1.

DESCRIÇÃO DETALHADA DA INVENÇÃO

[0016] As técnicas descritas neste documento podem ser utilizadas para diversas redes de comunicação sem fio, tais como CDMA, TDMA, FDMA, OFDMA, SC-FDMA e outras redes. Os termos de "rede" e "sistema" são frequentemente usados alternadamente. A rede CDMA pode implementar uma tecnologia de rádio tal como Acesso Rádio Terrestre Universal (UTRA), cdma2000, etc UTRA inclui CDMA de banda larga (WCDMA) e outras variantes de CDMA. cdma2000 cobre padrões IS-2000 (CDMA2000 IX), IS-95 e IS-856. A rede TDMA pode implementar uma tecnologia de rádio tal como Sistema Global para Comunicações Móveis (GSM). Uma rede OFDMA pode implementar uma tecnologia de rádio tal como UTRA Desenvolvida (E-UTRA) , Banda larga Ultra Móvel (UMB), IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, Flash-OFDM®, etc. UTRA e E-UTRA fazem parte do Sistema de telecomunicação Móvel Universal (UMTS) . Evolução de Longo Alcance 3GPP (LTE) é uma versão futura de UMTS que usa E-UTRA. UTRA, E-UTRA, UMTS, GSM e LTE são descritos nos documentos de uma organização chamada "Projeto de parceria de 3o geração (3GPP)". cdma2000 e UMB são descritos nos documentos de uma organização chamada "projeto 2 de parceria de 3o Geração (3GPP2)". As técnicas descritas aqui podem ser usadas para as redes e tecnologias de rádio dadas acima, bem como outras redes e tecnologias de rádio. Para maior clareza, alguns aspectos das técnicas são descritos abaixo para LTE, e terminologia LTE é usada em grande parte da descrição a seguir.

[0017] A figura 1 mostra um exemplo de implantação de rede 100. O UE 110 pode se comunicar com uma Rede de Rádio Acesso Terrestre Universal Desenvolvida (E-UTRAN) 120a ou uma rede de rádio acesso não 3GPP (RAN) 120b a fim de receber um ou mais serviços de dados, tais como conectividade à Internet, serviço de mensagens curtas (SMS), mensagens instantâneas (IM), acesso a Protocolo de Aplicação Sem Fio (WAP), fluxo continuo de multimidia, troca de mensagens multimidia, etc. O UE 110 também pode ser referido como uma estação móvel, um terminal, um terminal de acesso, uma unidade de assinante, uma estação, etc. O UE 110 pode ser um telefone celular, um assistente pessoal digital (PDA), um modem sem fio, um dispositivo de comunicação sem fio, um dispositivo portátil, um computador laptop, um telefone sem fio, uma estação de loop local sem fio (WLL), etc.

[0018] E-UTRAN 120a pode incluir Nó Bs desenvolvido (eNBs) que suportam comunicação de rádio para UEs. Um eNB pode ser uma estação fixa que se comunica com os UEs e também pode ser referido como um Nó B, uma estação base, um ponto de acesso, etc. Um gateway de serviço (SGW) 130a pode cancelar a interface para E-UTRAN 120a e pode realizar várias funções tais como suporte para handover de UEs entre eNBs, buffering, roteamento e transmissão de dados para os UEs, iniciação de procedimento de solicitação de serviço acionado por rede, considerando funções para tarifação, etc. Um agente nativo (HA) 140 pode se comunicar com gateway de serviço 130 direta ou indiretamente, e pode suportar um ou mais protocolos de mobilidade, tais como MIP, Proxy MIP (PMIP), Dual Stack Mobile IPv6 (DSMIPvβ), Mobile IPv4 co-localizado com cuidados de endereço (MIPv4-CCoA), Serviços gerais de Rádio por Pacote (GPRS) Protocolo de Tunelamento (GTP), etc. Agente Nativo 140 pode manter informações sobre a localização atual para UES em roaming e pode rotear pacotes para estes UEs. Agente nativo 140 pode ser um gateway dedicado como um agente nativo ou um gateway que pode prover a funcionalidade de agente nativo, bem como outras funcionalidades.

[0019] Embora não seja mostrado na figura 1, um gateway de rede de dados em pacote (PDN) pode se acoplar entre gateway de serviço 130a e agente nativo 140. O gateway PDN pode realizar funções tal como filtragem de pacotes e alocação de endereços IP para os UEs, controle de porta de nivel de serviço e execução de taxa, funções Protocolo de Configuração Hospedeiro Dinâmica (DHCP) para cliente e servidor, funcionalidade de nó de suporte GPRS de gateway (GGSN), etc. Uma Autenticação, Autorização e Contabilidade/Servidor de Assinante nativo (AAA/HSS) 142 pode armazenar informações relacionadas com a assinatura (por exemplo, perfis de usuário) e informações de localização para os UEs. AAA/HSS 142 pode realizar autenticação e autorização de UES e pode prover informações para os UES solicitando entidades da rede.

[0020] RAN não 3GPP 120B pode ser uma rede CDMA2000 IX, uma rede WiMAX, uma rede Wi-Fi, ou algum outro tipo de RAN. RAN não 3GPP 120b pode realizar interface com um gateway 130b não 3GPP, que podem realizar funções semelhantes às realizadas pelo gateway de serviço 130.

[0021] Uma PCRF 150 e uma função de reforço de política e tarifação (PCEF) pode coletivamente suportar funções PCC. Uma instância da PCEF pode ser co-localizada com cada um dos gateways 130 e 130b e agente nativo 140, como mostrado na figura 1. PCRF 150 pode atuar como um controlador para o PCC, receber informações sobre o serviço de Funções de Aplicação (AFS), e prover regras de PCC para as PCEFs. As PCEFs podem aplicar as regras de PCC providas pela PCRF 150. Por exemplo, um PCEF pode configurar QoS para um fluxo de IP e pode prover a função de tarifação para o fluxo de IP com base nas regras de PCC. Um fluxo de IP pode também ser referido como um fluxo de dados, etc. O PCC, PCRF e PCEF são descritos em TS 3GPP 23.203, intitulado "POLICY AND CHARGING CONTROL ARCHITECTURE", que está disponível publicamente.

[0022] As entidades de rede na figura 1 podem também ser referidas por outros nomes. Por exemplo, o PCEF para um gateway de serviço pode ser referido como uma ligação de portador e Função de relatório de Evento (BBERF).

[0023] As RANS e entidades da rede na figura 1 podem pertencer a uma ou mais redes móveis terrestres públicas (PLMNs) . Por exemplo, uma PLMN nativa (HPLMN) pode incluir agente nativo 140 e AAA/HSS 142, e um PLMN visitada (VPLMN) pode incluir E-UTRAN 120a e gateway de serviço 130a. RAN não 3GPP e gateway não GPP 130b podem pertencer à HPLMN ou VPLMN. PCRF 150 pode incluir uma PCRF nativo (H-PCRF) no HPLMN e uma PCRF visitado (V-PCRF) no VPLMN. Cada PLMN pode incluir também outras entidades de rede não mostradas na figura 1.

[0024] A figura 1 mostra algumas entidades da rede que podem suportar rede de acesso com conectividade IP (IP- CAN). IP-CAN é uma coleção de entidades de rede e interfaces que proveem conectividade de transporte IP entre os UEs e entidades da rede núcleo. As entidades de rede na figura 1 podem se comunicar direta ou indiretamente com as outras, por exemplo, através de uma ou mais redes de dados. As entidades de rede na figura 1 são descritas em TS 3GPP 36.300, intitulado "Evolved Universal Terrestrial Radio Access (E-UTRA) e Evolved Universal Terrestrial Radio Access Network(E-UTRAN); Overall Description", e em TS 3GPP 23.401, intitulado "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E- UTRAN) ". Estes documentos estão disponíveis ao público de 3GPP.

[0025] O UE 110 pode obter conectividade com a Internet através de acesso a IP direto e/ou acesso a IP móvel. O acesso direto IP refere-se à troca de pacotes IP entre UE 110 e uma entidade remota sem nenhum suporte para mobilidade do UE. O acesso móvel IP refere-se a troca de pacotes IP entre UE 110 e uma entidade remota através de uma entidade de rede que pode rastrear o paradeiro do UE e encaminhar os pacotes IP para o UE através de tunelamento. Acesso a IP móvel pode ser suportado usando MIP, PMIP, DSMIPvβ, MIPv4-CCoA, GTP ou algum outro protocolo de mobilidade. Por exemplo, o UE 110 pode ter acesso a IP direto via gateway de serviço 130 ou gateway não 3GPP 130b e pode trocar pacotes IP através do gateway 130 ou 130b sem tunelamento. O UE 110 também pode obter acesso a IP móvel via agente nativo 140 usando um protocolo de mobilidade, tal como MIP. Para acesso a IP móvel, os pacotes IP podem ser tunelados entre o UE 110 e agente nativo 140 via gateway 130a ou 130b.

[0026] A figura 2 mostra um exemplo de processamento para tunelar um pacote IP enviado no uplink do UE 110 para o agente nativo 140. O UE 110 pode se comunicar com outro UE e pode gerar um pacote IP 210 para enviar para outro UE. Pacote IP 210 inclui um cabeçalho IP e uma carga útil. O cabeçalho IP contém vários campos incluindo um campo de endereço de origem, um campo de endereço de destino, e um campo de protocolo. O campo de endereço de origem pode ser definido como o endereço IP do UE 110 (endereço IP UE1), o campo de endereço de destino pode ser definido como o endereço IP do outro UE o (endereço IP UE2) e o campo de protocolo pode ser definido como um protocolo de camada de transporte (por exemplo, TCP, UDP, etc.) usado para os dados enviados na carga útil. A carga útil do pacote IP 210 pode portar um datagrama de camada de transporte, que pode incluir um cabeçalho e uma carga útil. O cabeçalho de camada de transporte pode incluir (i) um campo de porta de origem que pode ser configurado para uma porta no UE 110 (porta Y) e (ii) uma porta de destino que pode ser configurado para uma porta no outro UE (porta Z). O endereço de origem, endereço de destino, e os campos de protocolo do cabeçalho de pacote IP 210 e os campos de porta de origem e de destino do cabeçalho do datagrama de camada de transporte podem ser considerados como campos de um cabeçalho interno.

[0027] O pacote IP 210 é um pacote não tunelado e pode ser encapsulado em um pacote IP tunelado 220 pelo UE 110 para o uplink. Para pacote IP tunelado 220, o campo de endereço de origem pode ser definido como o endereço IP do UE 110 (endereço IP UE1), e o campo de endereço de destino pode ser definido como o endereço IP do agente nativo 140 (endereço IP HA). O endereço de origem, endereço de destino, e campos de protocolo do cabeçalho de pacote IP 220 podem ser considerados como campos de um cabeçalho externo.

[0028] Um pacote IP tunelado para o downlink pode ser gerado de maneira semelhante, embora com as seguintes diferenças. No cabeçalho externo, o endereço de origem pode ser definido como o endereço IP do agente nativo 140, e o endereço de destino pode ser definido como o endereço IP do UE 110.

[0029] Para o uplink, o UE 110 pode realizar tunelamento para pacotes IP, e o agente nativo 140 pode realizar destunelamento. O UE 110 pode enviar pacotes IP tunelados em direção ao gateway 130 ou 130b, que pode transmitir o pacote IP tunelado para agente nativo 140. Para o downlink, o agente nativo 140 pode realizar tunelamento de pacotes IP, e UE 110 pode realizar destunelamento. O agente nativo 140 pode enviar pacotes IP tunelados para gateway 130 ou 130b, que pode transmitir o pacote IP tunelado para o UE 110. Por simplicidade, os pacotes IP são também referidos simplesmente como pacotes na descrição abaixo.

[0030] Voltando à figura 1, PCRF 150 pode enviar as regras de PCC para as sessões PCC às PCEFs. A sessão de PCC pode ser estabelecida entre PCRF 150 e gateway de serviço 130a, gateway não 3GPP 130b, ou agente nativo 140 e pode cobrir um ou mais fluxos IP. Cada fluxo IP pode ser identificado por um conjunto de parâmetros, os quais podem incluir o endereço de origem, o endereço de destino, o protocolo de camada de transporte, a porta de origem e a porta de destino indicadas na figura 2. As regras de PCC para cada sessão de PCC podem incluir informações sobre os fluxos IP na sessão de PCC, regras ou políticas de QoS para aplicar sobre os fluxos de IP, taxar informações sobre os fluxos de IP e/ou outras informações relacionadas à sessão de PCC. As regras de QoS podem indicar a largura de banda, retardo e prioridade para os fluxos IP, se para bloquear ou passar pacotes nos fluxos IP, etc. A tarifação de informações pode indicar o mecanismo de tarifação para os fluxos IP, por exemplo, a taxa fixa, tempo com base em, ou contagem de tarifação com base em pacote.

[0031] Quando um protocolo de mobilidade tal como MIP é usado, os pacotes podem ser tunelados entre UE 110 e agente nativo 140 via gateway 130, que pode ser gateway de serviço 130a ou gateway não 3GPP 130b. Gateway 130 deve estar ciente de que os pacotes são tunelados, a fim de aplicar corretamente as regras de PCC aplicáveis.

[0032] Além disso, pode haver situações em que tanto o agente nativo 140 quanto o gateway 130 têm sessões PCC ativas para tarifação com PCRF 150. Isso pode ocorrer, por exemplo, se o UE 110 tiver acesso a IP direto via gateway 130 e também tiver acesso a IP móvel via agente nativo 140. Gateway 130 pode encaminhar tanto pacotes tunelados para o acesso a IP direto bem como pacotes tunelados do agente nativo 140 para o acesso a IP móvel. Uma vez que o gateway 130 e o agente nativo 140 encaminham os pacotes tunelados, esses pacotes devem ser contados apenas uma vez, a fim de evitar a duplicação de tarifação. 0 mesmo pode também se aplicar quando o agente nativo 140 e o gateway 130 são co- localizados, mas têm diferentes sessões PCC com PCRF 150.

[0033] Em um aspecto, as regras de PCC em uma sessão de PCC podem ser determinadas com base em um parâmetro que pode indicar se um protocolo de mobilidade é usado por um UE. Em um projeto, o parâmetro é um parâmetro tipo IP-CAN que está presente na sinalização PCC. O parâmetro tipo IP- CAN tipicamente provê informações sobre o tipo de acesso via rádio, por exemplo, E-UTRA, UTRA, CDMA2000 IX, WiMAX, Wi-Fi, etc. 0 parâmetro tipo IP-CAN pode ser expandido para prover informações sobre o protocolo de mobilidade. Por exemplo, o parâmetro tipo IP-CAN pode indicar (i) se um protocolo de mobilidade é usado ou não por um UE ou (ii) qual protocolo de mobilidade é utilizado, por exemplo, MIP, PMIP, DSMIPvβ, MIPv4-CCoA, GTP, etc. O parâmetro tipo IP-CAN pode ser usado para distinguir entre os pacotes tunelados e os pacotes não tunelados, conforme descrito abaixo.

[0034] Para uma sessão de PCC entre gateway 130 (por exemplo, gateway de serviço 130a ou gateway não 3GPP 130b) e PCRF 150 para acesso a IP direto, o parâmetro tipo IP-CAN pode ser definido como um tipo de acesso rádio. Gateway 130 pode então contar pacotes não tunelados para a sessão de PCC para tarifação, e o agente nativo 140 pode pular a contagem dos pacotes não tunelados.

[0035] Para uma sessão de PCC entre o agente nativo 140 e PCRF 150 para acesso a IP móvel, o parâmetro Tipo IP- CAN pode ser definido como um protocolo de mobilidade (por exemplo, MIP). Esta sessão de PCC pode estar associada com os pacotes tunelados, e as regras de PCC para a sessão de PCC podem se referir aos pacotes tunelados. Agente nativo 140 pode contar os pacotes tunelados para tarifação. O gateway 130 não irá contar os pacotes tunelados para tarifação uma vez que não teria uma sessão de PCC com o parâmetro tipo IP-CAN definido como um protocolo de mobilidade.

[0036] A tabela 1 resume a utilização do parâmetro tipo IP-CAN para transportar diferentes tipos de sessão de PCC. A Tabela 1 também resume a ação realizada por cada entidade de rede para cada tipo de sessão de PCC.

[0037] A figura 3 mostra um projeto de um processo 300 para suportar PCC usando o parâmetro Tipo IP-CAN. O UE 110 pode acessar uma RAN (por exemplo, E-UTRAN 120a ou RAN não 3GPP 120b na figura 1) e pode se comunicar com o gateway 130 (por exemplo, gateway de serviço 130 ou gateway não 3GPP 130b) para autenticação de acesso (etapa 1) . Gateway 130 pode ainda se comunicar com AAA/HSS 142 para AAA e autenticação de acesso de UE 110 (também etapa 1). O UE 110 pode então realizar configuração de endereços IP com gateway 130 e pode ser atribuído um endereço IP (etapa 2).

[0038] O Gateway 130 pode enviar uma solicitação/indicação de estabelecimento de sessão de portador de IP-CAN para PCRF 150 (etapa 3) . A solicitação pode incluir uma identidade UE para UE 110, o parâmetro tipo IP-CAN, e possivelmente outras informações. O parâmetro tipo IP-CAN pode identificar o tipo de acesso rádio (por exemplo, E-UTRA, UTRA, WiMAX, etc.) para uma sessão IP-CAN (ou sessão de PCC) a ser estabelecida. PCRF 150 pode determinar que a autorização PCC é necessária e pode solicitar a autorização de serviço permitido e informações sobre as regras de PCC a partir de uma entidade local ou externa (não mostrada na figura 3). PCRF 150 pode tomar uma decisão de autorização e politica sobre a solicitação a partir do gateway 130 e pode determinar as regras de PCC para a sessão de PCC com base no parâmetro tipo IP-CAN e outras informações. PCRF 150 pode retornar uma confirmação (ACK) de estabelecimento de sessão IP-CAN para gateway 130 (etapa 4). A confirmação pode incluir as regras de PCC, taxar informações e/ou outras informações para o PCEF no gateway 130. O PCEF pode aplicar as regras de PCC a partir dA PCRF 150.

[0039] A primeira sessão de PCC pode ser estabelecida entre gateway 130 e PCRF 150 nas etapas 3 e 4. Esta sessão de PCC pode estar associada com o tipo de acesso rádio dado no parâmetro tipo IP-CAN enviado na etapa 3 e o endereço IP atribuído ao UE 110 na etapa 2. Este sistema de sessão de PCC especifica acesso rádio também pode estar associada com pacotes não tunelados, que podem ser identificados com base em um modelo de fluxo de dados de serviço incluído nas regras de PCC providas pelA PCRF 150 na etapa 4. O modelo de fluxo de dados de serviço pode incluir um conjunto de filtros de fluxo de dados de serviço utilizados para identificar os pacotes não tunelados para fluxos IP cobertos pela sessão de PCC. Gateway 130 pode detectar pacotes não tunelados para a sessão de PCC com base no modelo de fluxo de dados de serviço e pode contar esses pacotes para tarifação, como indicado pelas informações de tarifação providas pela PCRF 150 (bloco 5) .

[0040] Em um momento posterior, o UE 110 pode desejar usar MIP. O UE 110 pode determinar que ele está se comunicando com uma rede visitada uma vez que o prefixo de endereço IP para sua rede doméstica (HNP) é diferente de um prefixo de endereço IP para a porta 130. O UE 110 pode realizar uma Troca de Chave de Internet (IKEv2) para estabelecer uma relação segura com o agente nativo 140 (etapa 6). O agente nativo 140 pode ainda se comunicar com AAA/HSS 142 para AAA para a Troca de Chave de Internet para o UE 110 (também etapa 6) . O UE 110 pode obter um novo endereço IP como um endereço nativo.

[0041] O UE 110 pode depois enviar uma atualização obrigatória e pode prover a sua localização atual para agente nativo 140 (etapa 7) . Agente nativo 140 pode então enviar uma solicitação / indicação de estabelecimento de sessão de portador IP-CAN para PCRF 150 (etapa 8). A solicitação pode incluir o parâmetro tipo IP-CAN, que pode identificar o protocolo de mobilidade (por exemplo, MIP) para a sessão IP- CAN a ser estabelecida. PCRF 150 pode determinar a autorização do PCC, se necessário, e pode tomar uma decisão sobre a solicitação proveniente do agente nativo 140. PCRF 150 pode então retornar uma confirmação de estabelecimento de sessão IP-CAN para o agente nativo 140 (etapa 9) . A confirmação pode incluir as regras de PCC, informações de cobrança, informações sobre tunelar cabeçalho de encapsulamento para o protocolo de mobilidade e/ou outras informações para a PCEF no agente nativo 140. O PCEF pode aplicar as regras de PCC providas pela PCRF 150. PCRF 150 pode também prover gateway 130 Com regras de PCC para os pacotes tunelados para a sessão de PCC entre o agente nativo 140 e A PCRF 150 (etapa 10). Gateway 130 pode usar as regras de PCC para suportar QoS para os pacotes tunelados e/ou realizar outras funções. O agente nativo 140 também pode retornar uma confirmação obrigatória para o UE 110 (etapa 11) .

[0042] A segunda sessão de PCC pode ser estabelecida entre o agente nativo 140 e A PCRF 150 nas etapas 8 e 9. Esta sessão de PCC pode estar associada com o protocolo de mobilidade dado no parâmetro tipo IP-CAN enviado na etapa 8 e o endereço IP atribuído ao UE 110 na etapa 6. Esta sessão de PCC especifica de protocolo de mobilidade também pode estar associada com os pacotes tunelados, que podem ser identificados com base em um modelo de fluxo de dados de serviço incluido nas regras de PCC providas pela PCRF 150 na etapa 9. O modelo de fluxo de dados de serviço pode incluir um conjunto de filtros de fluxo de dados de serviço utilizados para identificar os pacotes tunelados por Fluxos IP cobertos pela sessão de PCC. O agente nativo 140 pode detectar pacotes tunelados para a sessão de PCC com base no modelo de fluxo de dados de serviço e pode contar esses pacotes para tarifação, como indicado pelas informações de tarifação providas pela PCRF 150 blocos (12).

[0043] A figura 4 mostra um projeto de um outro processo 400 para suportar PCC usando o parâmetro Tipo IP- CAN. O UE 110 pode acessar E-UTRAN 120a, que pode pertencer ao HLPMN para o UE. O UE 110 pode se comunicar com o agente nativo 140 para configuração de endereços IP (etapa 1) . O agente nativo 140, que pode ser um gateway PDN no HLPMN, pode ainda se comunicar com AAA/HSS 142 para AAA e acessar autenticação de UE 110 (também etapa 1). O UE 110 pode obter um endereço IP e um prefixo de rede nativa (HNP) a partir do agente nativo 140.

[0044] O agente nativo 140 pode enviar uma solicitação/indicação de estabelecimento de sessão de portador IP-CAN para PCRF 150 (etapa 2). A solicitação pode incluir o parâmetro tipo IP-CAN, que pode identificar o tipo de acesso rádio (por exemplo, E-UTRA) para a sessão IP-CAN a ser estabelecida. PCRF 150 pode determinar a autorização do PCC, se necessário, e pode tomar uma decisão sobre a solicitação proveniente do agente nativo 140. PCRF 150 pode retornar uma confirmação de estabelecimento de sessão IP-CAN para agente nativo 140 (etapa 3). A confirmação pode incluir as regras de PCC, informações de tarifação e/ou outras informações para o PCEF no agente nativo 140. O PCEF pode aplicar as regras de PCC providas pela PCRF 150.

[0045] A primeira sessão de PCC pode ser estabelecida entre o agente nativo 140 e a PCRF 150 nas etapas 2 e 3. Esta sessão de PCC pode estar associada com o tipo de acesso rádio dado no parâmetro tipo IP-CAN enviado na etapa 2 e o HNP provido para o UE 110 na etapa 1. O agente nativo 140 pode detectar pacotes não tunelados para a sessão de PCC com base em um modelo de fluxo de dados de serviço provido pela PCRF 150 e pode contar esses pacotes de tarifação (bloco 4).

[0046] O UE 110 pode realizar uma Troca de Chave de Internet para estabelecer uma relação segura com o agente nativo 140 (etapa 5). O UE 110 pode perceber que ele está no HPLMN. Como resultado, um protocolo de mobilidade não pode ser ativado, e uma sessão de PCC para o protocolo de mobilidade não pode ser estabelecida.

[0047] Depois disso, o UE 110 pode avançar para RAN não 3GPP 120b e pode realizar a autenticação de acesso e configuração de endereços IP com o gateway não3 GPP 130b (etapa 6). Gateway 130b pode ainda se comunicar com AAA/HSS 142 para AAA para autenticação de acesso de UE 110 (também etapa 6). Gateway 130b pode se comunicar com PCRF 150 para estabelecer uma sessão de controle de gateway (etapa 7) e pode definir o parâmetro tipo IP-CAN para o tipo de acesso rádio (por exemplo, o WiMAX) (etapa 7) . PCRF 150 pode estabelecer a sessão de controle de gateway para gateway 130b e pode enviar uma confirmação para o estabelecimento da sessão de controle de gateway (etapa 8). A sessão de controle de gateway pode ser associada com o tipo de acesso rádio provido pelo gateway 130b.

[0048] O UE 110 pode depois enviar uma atualização obrigatória e pode prover a sua localização atual para o agente nativo 140 (etapa 9). O agente nativo 140 pode então enviar uma solicitação / indicação de estabelecimento de sessão de portador IP-CAN para PCRF 150 (etapa 10) . A indicação pode incluir o parâmetro tipo IP-CAN, que pode identificar o protocolo de mobilidade (por exemplo, DSMIPvβ) para a sessão IP-CAN a ser estabelecida. PCRF 150 pode determinar a autorização do PCC, se necessário, e pode tomar uma decisão sobre a solicitação proveniente do agente nativo 140. PCRF 150 pode retornar uma confirmação de estabelecimento de sessão IP-CAN para o agente nativo 140 (etapa 11) . A confirmação pode incluir as regras de PCC e outras informações para o PCEF no agente nativo 140. O PCEF pode aplicar as regras de PCC providas pela PCRF 150. PCRF 150 pode também prover gateway 130b com as regras de PCC para os pacotes tunelados para a sessão de PCC entre o agente nativo 140 e PCRF 150 (etapa 12). Gateway 130 pode usar as regras de PCC para suportar QoS para os pacotes tunelados e/ou realizar outras funções. O agente nativo 140 também pode retornar uma confirmação obrigatória para o UE 110 (etapa 13).

[0049] A segunda sessão de PCC pode ser estabelecida entre o agente nativo 140 e PCRF 150 nas etapas 10 e 11. Esta sessão de PCC pode estar associada com o protocolo de mobilidade dado no parâmetro tipo IP-CAN, o HNP de agente nativo 140, e os cuidados de endereço (CoA) para o UE 110. Agente nativo 140 pode detectar pacotes tunelados para a sessão de PCC com base em um modelo de fluxo de dados de serviço provido pela PCRF 150 na etapa 11 e pode contar esses pacotes para tarifação (bloco 14) .

[0050] Como mostrado nas figuras 3 e 4, PCC pode ser suportado indicando para o gateway 130 ou agente nativo 140 se as regras de PCC se aplicam apenas a pacotes não tunelados (por exemplo, para a primeira sessão de PCC das figuras 3 e 4), ou apenas a pacotes tunelados (por exemplo, para segunda sessão de PCC nas figuras 3 e 4), ou ambos pacotes tunelados e não tunelados (não mostrados nas figuras 3 e 4). O Gateway 130 ou agente nativo 140 pode contar todos os pacotes para a sua sessão de PCC para tarifação, e cada pacote seria contado apenas uma vez por qualquer gateway 130 ou agente nativo 140. Gateway 130 ou agente nativo 140 pode ser capaz de contar corretamente os pacotes para a sua sessão de PCC mesmo quando o tráfego tunelado (por exemplo, o tráfego MIP) e de tráfego não tunelado (por exemplo, o tráfego de fuga local) estão presentes, por exemplo, como mostrado na figura 4 .

[0051] As figuras 3 e 4 mostram dois projetos de utilização do parâmetro tipo IP-CAN para suportar PCC para os protocolos de mobilidade. As técnicas podem ser utilizadas para vários protocolos de mobilidade, tais como MIP, DSMIPvô, MIPv4-CCoA, PMIP, GTP, etc. Por exemplo, no caso de MIPv4, o parâmetro Tipo IP-CAN pode ser definido como MIPv4-CCoA em vez de MIP nas figuras 3 e 4.

[0052] Para maior clareza, alguns aspectos das técnicas têm sido descritos para LTE. As técnicas também podem ser usadas para outras redes sem fio, que podem incluir outras entidades de rede que podem realizar funções equivalentes as das entidades de rede mostradas na figura 1. Por exemplo, em UMTS versão 8, um gateway PDN pode atuar tanto como um gateway de serviço quanto um agente nativo para um UE. O gateway PDN pode ter duas sessões PCC para o UE. Em uma sessão de PCC, o gateway PDN pode agir como gateway de serviço para acesso a IP direto pelo UE através de uma UTRAN. Na outra sessão de PCC, o gateway PDN pode atuar como agente nativo para o acesso a IP móvel pelo UE através de outra RAN. 0 UE pode enviar tanto pacotes não tunelados para o Acesso a IP direto quanto pacotes tunelados para acesso a IP móvel. Os pacotes tunelados e não tunelados podem combinar com diferentes modelos de fluxo de dados de serviços no gateway PDN para as duas sessões PCC, e cada pacote pode ser contado apenas uma vez para a sessão de PCC apropriada. Este cenário pode ser mostrado pelo processo 400 na figura 4, neste caso o agente nativo 140 pode representar o gateway PDN, a primeira sessão de PCC pode ser para o acesso a IP direto, e a segunda sessão de PCC pode ser para o acesso a IP móvel.

[0053] A figura 5 mostra um projeto de um processo 500 para funções para suportar do PCC em uma rede sem fio. Processo 500 pode ser realizado por uma PCRF (como descrito abaixo), ou alguma entidade de rede. A PCRF pode receber uma solicitação / indicação de uma primeira entidade de rede (por exemplo, um agente nativo) para estabelecer uma sessão de PCC para um UE acessar a primeira entidade de rede usando um protocolo de mobilidade (por exemplo, MIP, PMIP, DSMIPvβ, MIPv4-CCoA, GTP, etc.) (Bloco 512) . A PCRF pode determinar o protocolo de mobilidade utilizado pelo UE com base na solicitação (bloco 514). Em um projeto, A PCRF pode obter o parâmetro tipo IP-CAN a partir da solicitação e determinar o protocolo de mobilidade utilizado pelo UE com base no parâmetro tipo IP-CAN. O protocolo de mobilidade também pode ser transmitido de outras maneiras, por exemplo, utilizando outros parâmetros enviados na solicitação.

[0054] A PCRF pode determinar as regras de PCC para a sessão de PCC com base no protocolo de mobilidade e, possivelmente, outras informações (bloco 516). As regras de PCC podem incluir um conjunto de pelo menos um filtro para identificar os pacotes para a sessão de PCC, uma indicação de se conta os pacotes para tarifação, regras de QoS para os pacotes, informações de tarifação sobre a sessão de PCC, e/ou outras informações relacionadas com a sessão de PCC. A PCRF pode enviar as regras de PCC para a primeira entidade de rede (bloco 518) .

[0055] Os pacotes para a sessão de PCC podem ser encapsulados em pacotes tunelados, que podem ser trocados entre o UE e a primeira entidade de rede através de uma segunda entidade de rede (por exemplo, um gateway de serviço). Neste caso, A PCRF pode determinar a segunda regra de PCC compreendendo (i) um conjunto de pelo menos um filtro para identificar os pacotes tunelados e (ii) uma indicação para não contar os pacotes tunelados para tarifação, que pode ser provida implicitamente pela ausência de informações de tarifação na segunda regra de PCC (bloco 520) . Por exemplo, a segunda regra de PCC pode incluir apenas as regras de QoS e um conjunto de pelo menos um filtro e nenhuma informação de tarifação. A PCRF pode enviar a segunda regra de PCC para segunda entidade de rede para aplicar os pacotes tunelados (bloco 522). Os pacotes tunelados podem ser contados uma vez para tarifação pela primeira entidade de rede e não pela segunda entidade de rede.

[0056] A PCRF pode receber uma segunda solicitação a partir de uma terceira entidade de rede (por exemplo, um outro gateway de serviço) para estabelecer uma segunda sessão de PCC para o UE. O UE pode ter acesso a IP direto com a terceira entidade de rede e pode trocar pacotes com a terceira entidade de rede sem tunelamento. A PCRF pode determinar um tipo de acesso rádio utilizado pelo UE para a terceira entidade de rede com base na segunda solicitação. Em um projeto, A PCRF pode obter o parâmetro tipo IP-CAN a partir da segunda solicitação e pode determinar o tipo de acesso rádio utilizado pelo UE com base no parâmetro tipo IP-CAN. A PCRF pode determinar a terceira regra de PCC para segunda sessão de PCC com base no tipo de acesso rádio utilizado pelo UE. A terceira regra de PCC pode incluir pelo menos um filtro para identificar pacotes não tunelados para segunda sessão de PCC e outras informações. A PCRF pode então enviar a terceira regra de PCC para a terceira entidade de rede.

[0057] A figura 6 mostra um projeto de um equipamento 600 para suportar funções PCC em uma rede sem fio. Equipamento 600 inclui um módulo 612 para receber uma solicitação de uma primeira entidade de rede para estabelecer uma sessão de PCC para um UE acessar a primeira entidade de rede usando um protocolo de mobilidade, um módulo 614 para determinar o protocolo de mobilidade utilizado pelo UE com base na solicitação, um módulo 616 para determinar as regras de PCC para a sessão de PCC com base no protocolo de mobilidade, um módulo 618 para enviar as regras de PCC para a primeira entidade de rede, um módulo 620 para determinar a segunda regra de PCC compreendendo um conjunto de pelo menos um filtro para identificar pacotes tunelados para a sessão de PCC e uma indicação para não contar os pacotes tunelados para tarifação, e um módulo 622 para enviar a segunda regra de PCC para segunda entidade de rede para aplicar os pacotes tunelados.

[0058] A figura 7 mostra um projeto de um processo 700 para suportar funções PCC. A primeira entidade de rede (por exemplo, um agente nativo) pode aceitar acesso de um UE com base em um protocolo de mobilidade (bloco 712) . A primeira entidade de rede pode enviar uma solicitação para uma segunda entidade de rede (por exemplo, uma PCRF) para estabelecer uma sessão de PCC para o UE (bloco 714) . A solicitação pode incluir o protocolo de mobilidade utilizado pelo UE. Em um projeto, a solicitação pode incluir o parâmetro Tipo IP-CAN, que pode ser definido como o protocolo de mobilidade utilizado pelo UE.

[0059] A primeira entidade de rede pode receber regras de PCC para a sessão de PCC a partir da segunda entidade de rede (bloco 716) . As regras de PCC podem ser determinadas pela PCRF com base no protocolo de mobilidade. As regras de PCC podem incluir um conjunto de pelo menos um filtro para identificar os pacotes para a sessão de PCC, uma indicação de se conta os pacotes para tarifação, as regras QoS para os pacotes, informações de tarifação sobre a sessão de PCC, e/ou outras informações para a sessão de PCC. A primeira entidade de rede pode aplicar as regras de PCC para trocar pacotes com o UE para a sessão de PCC (blocos 718). Estes pacotes podem ser enviados em pacotes tunelados. Em um projeto do bloco 718, a primeira entidade de rede pode identificar os pacotes para a sessão de PCC com base no conjunto de pelo menos um filtro obtido das regras de PCC. A primeira entidade de rede pode contar os pacotes para tarifação.

[0060] A figura 8 mostra um projeto de um equipamento 800 para suportar funções PCC. Equipamento 800 inclui um módulo 812 para aceitar o acesso por um UE com base em um protocolo de mobilidade em uma primeira entidade de rede, um módulo 814 para enviar uma solicitação a uma segunda entidade de rede para estabelecer uma sessão de PCC pelo UE, a solicitação compreendendo o protocolo de mobilidade utilizado pelo UE, um módulo 816 para receber as regras de PCC para a sessão de PCC a partir da segunda entidade de rede, as regras de PCC sendo determinadas com base no protocolo de mobilidade, e um módulo 818 para aplicar as regras de PCC aos pacotes trocados com o UE para a sessão de PCC.

[0061] A figura 9 mostra um projeto de um processo 900 para suportar funções PCC. A primeira entidade de rede (por exemplo, um gateway de serviço) pode receber as regras de PCC em uma sessão de PCC estabelecida pela segunda entidade de rede (por exemplo, um agente nativo) para um UE acessar a segunda entidade de rede usando um protocolo de mobilidade (por exemplo, MIP) (bloco 912). O UE e a segunda entidade de rede podem trocar pacotes tunelados, que podem ser enviados pela primeira entidade de rede. A primeira entidade de rede pode identificar os pacotes tunelados para a sessão de PCC com base em um primeiro conjunto de pelo menos um filtro obtido das regras de PCC (bloco 914) . A primeira entidade de rede pode saltar contagem dos pacotes tunelados para tarifação, com os pacotes tunelados sendo contados pela segunda entidade de rede para tarifação (bloco 916) .

[0062] A primeira entidade de rede pode enviar uma solicitação para estabelecer uma segunda sessão de PCC para o UE acessar a primeira entidade de rede usando acesso a IP direto (bloco 918). A solicitação pode incluir o parâmetro tipo IP-CAN definido para o tipo de acesso rádio utilizado pelo UE para a primeira entidade de rede. A primeira entidade de rede pode receber a segunda regra de PCC para segunda sessão de PCC, que pode ser determinada com base no tipo de acesso rádio utilizado pelo UE (bloco 920) . A primeira entidade de rede pode identificar pacotes não tunelados para segunda sessão de PCC com base em um segundo conjunto de pelo menos um filtro obtido da segunda regra de PCC (bloco 922) e pode contar os pacotes não tunelados para tarifação (bloco 924).

[0063] A figura 10 mostra um projeto de um equipamento 1000 para suportar funções PCC. Equipamento 1000 inclui um módulo 1012 para receber as regras de PCC em uma primeira entidade de rede, as regras de PCC sendo para uma sessão de PCC estabelecida por uma segunda entidade de rede para um UE acessar a segunda entidade de rede usando um protocolo de mobilidade, um módulo 1014 para identificar os pacotes tunelados para a sessão de PCC com base em um primeiro conjunto de pelo menos um filtro obtido das regras de PCC, um módulo 1016 para não contar os pacotes tunelados para tarifação, os pacotes tunelados sendo contados pela segunda entidade de rede para tarifação, um módulo 1018 para enviar uma solicitação para estabelecer uma segunda sessão de PCC para o UE acessar a primeira entidade de rede usando acesso a IP direto, um módulo 1020 para receber a segunda regra de PCC para segunda sessão de PCC, um módulo 1022 para identificar pacotes não tunelados para segunda sessão de PCC com base em um segundo conjunto de pelo menos um filtro obtido da segunda regra de PCC, e um módulo 1024 para contar os pacotes não tunelados para tarifação.

[0064] A figura 11 mostra um projeto de um processo 1100 realizado por um UE. O UE pode acessar uma primeira entidade de rede (por exemplo, um agente nativo) utilizando um protocolo de mobilidade (por exemplo, MIP) (bloco de 1112) . A primeira entidade de rede pode estabelecer uma sessão de PCC para o UE com base no protocolo de mobilidade, por exemplo, definindo o parâmetro tipo IP-CAN para o protocolo de mobilidade. O UE pode trocar pacotes tunelados com a primeira entidade de rede para a sessão de PCC (bloco 1114) . A primeira entidade de rede pode contar os pacotes tunelados para tarifação, em conformidade com as regras de PCC determinadas pela sessão de PCC com base no protocolo de mobilidade.

[0065] O UE pode acessar uma segunda entidade de rede (por exemplo, um gateway de serviço), utilizando o acesso a IP direto (bloco 1116) . A segunda entidade de rede pode estabelecer uma segunda sessão de PCC para o UE com base em um tipo de acesso rádio (por exemplo, E-UTRA, UTRA, WiMAX, Wi-Fi, etc.) utilizado pelo UE para segunda entidade de rede. O UE pode trocar pacotes não tunelados com a segunda entidade de rede para segunda sessão de PCC (bloco 1118). A segunda entidade de rede pode contar os pacotes não tunelados para tarifação em conformidade com a segunda regra de PCC determinada para segunda sessão de PCC com base no tipo de acesso rádio.

[0066] Os pacotes tunelados para a primeira sessão de PCC podem ser trocados entre o UE e a primeira entidade de rede via segunda entidade de rede. Os pacotes tunelados podem ser contados pela primeira entidade de rede para tarifação e não contados pela segunda entidade de rede.

[0067] A figura 12 mostra um projeto de um equipamento 1200 para um UE. Equipamento 1200 inclui um módulo 1212 para acesso a uma primeira entidade de rede pelo UE através de um protocolo de mobilidade, a primeira entidade de rede estabelecendo uma sessão de PCC para o UE com base no protocolo de mobilidade, um módulo 1214 para trocar pacotes tunelados com a primeira entidade de rede para a sessão de PCC, a primeira entidade de rede contando os pacotes tunelados para tarifação, em conformidade com as regras de PCC determinadas pela sessão de PCC com base no protocolo de mobilidade, um módulo 1216 para acessar uma segunda entidade de rede pelo UE usando acesso a IP direto, a segunda entidade de rede estabelecendo uma segunda sessão de PCC para o UE com base em um tipo de acesso rádio utilizado pelo UE para segunda entidade de rede, e um módulo 1218 para trocar pacotes não tunelados com a segunda entidade de rede para segunda sessão de PCC, a segunda entidade de rede contando os pacotes não tunelados para tarifação em conformidade com a segunda regra de PCC determinada para segunda sessão de PCC com base no tipo de acesso rádio.

[0068] Os módulos das figuras 6, 8, 10 e 12 podem incluir processadores, dispositivos eletrônicos, dispositivos de hardware, componentes eletrônicos, circuitos lógicos, memórias, códigos de software, códigos de firmware, etc., ou qualquer combinação dos mesmos.

[0069] A figura 13 mostra um diagrama de blocos de um projeto de UE 110, uma RAN 120, um gateway 130, um agente nativo 140 e PCRF 150. RAN 120 pode ser E-UTRAN 120a ou RAN não 3GPP 120b na figura 1 ou alguma outra RAN. Gateway 130 pode ser gateway de serviço 130 ou gateway não 3GPP 130b na figura 1 ou algum outro gateway. Para simplificar, a figura 13 mostra (i) um controlador/processador 1310, uma memória 1312, e um transmissor/receptor 1314 para o UE 110, (ii) um controlador/processador 1320, uma memória (Mem) 1322, um receptor/transmissor 1324, e uma unidade de comunicação (Comm) 1326 para RAN 120, (iii) um controlador/processador 1330, uma memória 1332, e uma unidade de comunicação 1334 para o gateway 130, (iv) um controlador/processador 1340, uma memória 1342, e uma unidade de comunicação 1344 para agente nativo 140, e (v) um controlador / processador 1350, uma memória 1352, e uma unidade de comunicação 1354 para PCRF 150. Em geral, cada entidade pode incluir qualquer número de controladores, processadores, memórias, receptores, unidades de comunicação, etc.

[0070] No downlink, RAN 120 pode transmitir dados e mensagens para UEs dentro de sua área de cobertura. Os dados e as mensagens podem ser processados pelo processador 1320 e condicionados pelo transmissor 1324 para gerar sinais de downlink, que podem ser transmitidos aos UEs. No UE 110, os sinais de downlink provenientes de RAN 120 podem ser recebidos e condicionados pelo receptor 1314 e processados pelo processador 1310 para recuperar os dados e as mensagens enviados ao UE 110. Memória 1312 pode armazenar os códigos de programa e dados para UE 110. O processador 1310 pode realizar ou processo direto 1100 na figura 11 e/ou outros processos para as técnicas descritas neste documento. O processador 1310 também pode realizar o processamento para o UE 110 em fluxos de mensagens 300 e 400 nas figuras 3 e 4, respectivamente.

[0071] No uplink, UE 110 pode transmitir dados e mensagens para RAN 120. Os dados e as mensagens podem ser processados pelo processador 1310 e condicionados pelo transmissor 1314 para gerar um sinal de uplink, que pode ser transmitido para RAN 120. Na RAN 120, os sinais de uplink provenientes do UE 110 e outros UEs podem ser recebidos e condicionados pelo receptor 1324 e posteriormente processados pelo processador 1320 para recuperar os dados e as mensagens enviados pelos UEs. A memória 1322 pode armazenar os códigos de programa e dados para RAN 120, que pode se comunicar com outras entidades de rede através da unidade de comunicação 1326.

[0072] No gateway 130, o processador 1330 pode realizar o processamento para o gateway, a memória 1332 pode armazenar códigos de programa e dados para o gateway, e unidade de comunicação 1334 pode permitir que o gateway se comunique com outras entidades de rede. 0 processador 1330 pode realizar ou por processo direto 900 na figura 9 e/ou outros processos para as técnicas descritas neste documento. O processador 1330 também pode realizar o processamento para gateway 130 em fluxo de mensagens 300 na figura 3 e para gateway não 3GPP 130b na mensagem 400 na figura 4.

[0073] No agente nativo 140, processador 1340 pode realizar o processamento para a agente nativo, a memória 1342 pode armazenar códigos de programa e dados para o agente nativo, e uma unidade de comunicação 1344 pode permitir que o agente nativo se comunique com outras entidades de rede. Processador 1340 pode realizar ou por processo direto 700 na figura 7 e/ou outros processos para as técnicas descritas neste documento. Processador 1340 também pode realizar o processamento para agente nativo 140 em fluxos de mensagens 300 e 400 nas figuras 3 e 4, respectivamente.

[0074] NA PCRF 150, processador 1350 pode realizar o processamento para A PCRF, a memória 1352 pode armazenar códigos de programa e dados para A PCRF, e a unidade de comunicação 1354 pode permitir que A PCRF se comunique com outras entidades de rede. Processador 1350 pode realizar ou processo direto 500 na figura 5 e/ou outros processos para as técnicas descritas neste documento. Processador 1350 também pode realizar o processamento de PCRF 150 em fluxos de mensagens 300 e 400 nas figuras 3 e 4, respectivamente.

[0075] Aqueles versados na técnica iriam compreender que a informação e os sinais podem ser representados por qualquer uma de uma variedade de tecnologias e técnicas diferentes. Por exemplo, dados, instruções, comandos, informações, sinais, bits, simbolos e chips que podem ser referenciados em toda a descrição acima podem ser representados por tensões, correntes, ondas eletromagnéticas, campos magnéticos ou partículas, campos ópticos ou partículas, ou qualquer combinação dos mesmos.

[0076] Aqueles versados iriam adicionalmente compreender que os diversos blocos lógicos ilustrativos, módulos, circuitos, e etapas de algoritmo descritos em conexão com a divulgação neste documento podem ser implementados como hardware eletrônico, software de computador, ou combinações de ambos. Para ilustrar claramente esse intercâmbio de hardware e software, vários componentes ilustrativos, blocos, módulos, circuitos, e os etapas têm sido descritos acima, geralmente em termos de sua funcionalidade. Se essa funcionalidade é implementada como hardware ou software depende da aplicação particular e restrições de projeto impostas ao sistema geral. Versados na técnica podem implementar a funcionalidade descrita em diferentes maneiras para cada aplicação especifica, mas as decisões de implementação não devem ser interpretadas como causa de um afastamento do escopo da presente divulgação.

[0077] Os vários blocos lógicos ilustrativos, módulos e circuitos descritos em conexão com a divulgação aqui podem ser realizados ou implementados com um processador de uso geral, um processador de sinal digital (DSP), um circuito integrado de aplicação especifica (ASIC), um arranjo de porta programável em campo (FPGA) ou outro dispositivo lógico programável, porta discreta ou lógica de transistor, componentes de hardware discretos, ou qualquer combinação destes projetada para realizar as funções descritas neste documento. Um processador de uso geral pode ser um microprocessador, mas em alternativa, o processador pode ser qualquer processador convencional, controlador, microcontrolador, ou máquina de estados. Um processador também pode ser implementado como uma combinação de dispositivos de computação, por exemplo, uma combinação de um DSP e um microprocessador, uma pluralidade de microprocessadores, um ou mais processadores em conjunto com um núcleo DSP, ou qualquer outra configuração desse tipo.

[0078] As etapas de um método ou algoritmo descritas em conexão com a divulgação neste documento podem ser incorporadas diretamente em hardware, em um módulo de software executado por um processador ou em uma combinação dos dois. Um módulo de software pode residir na memória RAM, memória flash, memória ROM, memória EPROM, memória EEPROM, registradores, disco rigido, um disco removível, um CD-ROM, ou qualquer outra forma de midia de armazenamento conhecida na técnica. Um meio de armazenamento exemplar é acoplado ao processador de tal forma que o processador pode ler informações do, e gravar informações, no meio de armazenamento. Em alternativa, o meio de armazenamento pode ser integral ao processador. 0 processador e o meio de armazenamento podem residir em um ASIC. 0 ASIC pode residir em um terminal de usuário. Em alternativa, o processador e o meio de armazenamento podem permanecer como componentes discretos em um terminal de usuário.

[0079] Em um ou mais projetos exemplares, as funções descritas podem ser implementadas em hardware, software, firmware, ou qualquer combinação destes. Se implementadas em software, as funções podem ser armazenadas ou transmitidas através de uma ou mais instruções ou código em um meio legivel por computador. Meios legiveis por computador incluem meios de armazenamento em comutador e meios de comunicação, incluindo qualquer meio que facilite a transferência de um programa de computador de um lugar para outro. Uma midia de armazenamento pode ser qualquer tipo de midia disponível, que pode ser acessada por um computador de uso geral ou aplicação especifica. A titulo de exemplo, e não de limitação, tais meios legiveis por computador podem incluir RAM, ROM, EEPROM, CD-ROM ou outro armazenamento em disco óptico, armazenamento em disco magnético ou outros dispositivos de armazenamento magnético, ou qualquer outro meio que possa ser utilizado para portar ou armazenar elementos de código do programa desejado sob a forma de instruções ou estruturas de dados e que pode ser acessado por um computador de uso geral ou aplicação especifica, ou processador de uso geral ou aplicação especifica. Além disso, qualquer conexão é devidamente considerada um meio legivel por computador. Por exemplo, se o software é transmitido a partir de um site, servidor ou outra fonte remota utilizando um cabo coaxial, cabo de fibra óptica, par trançado, linha de assinante digital (DSL), ou tecnologias sem fio, como infravermelho, rádio, e micro-ondas, então o cabo coaxial, cabo de fibra ótica, par trançado, DSL, ou tecnologias sem fio, como infravermelho, rádio e micro-ondas estão incluídos na definição de midia. Disco e disco, como usados aqui, incluem disco compacto (CD), disco a laser, disco óptico, disco versátil digital (DVD), disquete, e disco Blu-ray, em que disco e disco normalmente reproduzem dados magneticamente, enquanto discos reproduzem dados oticamente com lasers. Combinações dos acima também devem ser incluídas no escopo de midia legivel por computador

[0080] A descrição anterior da divulgação é provida para permitir que qualquer pessoa versada na técnica faça ou utilize a divulgação. Várias modificações à divulgação serão facilmente perceptíveis para aqueles versados na técnica, e os princípios genéricos definidos neste documento podem ser aplicados a outras variações, sem se afastar do espirito ou escopo da divulgação. Assim, a divulgação não se destina a limitar-se aos exemplos e aos projetos aqui descritos, mas deve ser concedido o mais amplo escopo consistente com os princípios e características inovadoras divulgados aqui.

Claims

1. Método para comunicação sem fio caracterizado pelo fato de que compreende: receber (512) uma solicitação de uma primeira entidade de rede para estabelecer uma sessão de controle de politica e taxação (PCC) denotada para um equipamento de usuário (UE) acessar a primeira entidade de rede usando um protocolo de mobilidade; determinar (514) o protocolo de mobilidade usado pelo UE (110) com base na solicitação, em que a determinação do protocolo de mobilidade utilizado pelo UE (110) compreende obter um parâmetro tipo rede de acesso de conectividade IP (IP-CAN) a partir da solicitação, e determinar o protocolo de mobilidade utilizado pelo UE (110) com base no parâmetro tipo IP-CAN; determinar (516) regras de PCC para a sessão de PCC com base no protocolo de mobilidade; e enviar (518) as regras de PCC para a primeira entidade de rede.

2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que as regras de PCC compreendem pelo menos um conjunto de pelo menos um filtro para identificar os pacotes para a sessão de PCC, uma indicação de se conta os pacotes para taxação, regras para a qualidade de serviço (QoS) para os pacotes, e informações de taxação para a sessão de PCC.

3. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que os pacotes para a sessão de PCC são encapsulados em pacotes tunelados trocados entre o UE (110) e a primeira entidade de rede através de uma segunda entidade de rede, o método adicionalmente compreendendo: determinar (520) a segunda regra de PCC compreendendo um conjunto de pelo menos um filtro para identificar os pacotes tunelados e uma indicação para não contar os pacotes tunelados para taxação; e enviar (522) a segunda regra de PCC para segunda entidade de rede para aplicar aos pacotes tunelados.

4. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende adicionalmente: receber uma segunda solicitação de uma segunda entidade de rede para estabelecer uma segunda sessão de PCC para o UE (110); determinar um tipo de acesso de rádio utilizado pelo UE (110) para segunda entidade de rede com base na segunda solicitação; determinar a segunda regra de PCC para segunda sessão de PCC com base no tipo de acesso de rádio utilizado pelo UE (110); e enviar a segunda regra de PCC para segunda entidade de rede.

5. Método, de acordo com a reivindicação 4, caracterizado pelo fato de que os pacotes para segunda sessão de PCC são trocados entre o UE (110) e a segunda entidade de rede sem tunelamento, e em que a segunda regra de PCC compreende pelo menos um filtro para identificar os pacotes não tunelados para segunda sessão de PCC.

6. Entidade de função de regras de controle de politica e taxação (PCRF) para comunicação sem fio, caracterizada pelo fato de que compreende: meios para receber uma solicitação de uma primeira entidade de rede para estabelecer uma sessão de controle de política e taxação (PCC) para um equipamento de usuário, UE (110) acessar a primeira entidade de rede usando um protocolo de mobilidade; meios para determinar o protocolo de mobilidade utilizado pelo UE (110) com base na solicitação, em que os meios para determinar o protocolo de mobilidade compreendem meios para obter um parâmetro tipo IP-CAN a partir da solicitação, e meios para determinar o protocolo de mobilidade utilizado pelo UE (110) com base no Parâmetro tipo IP-CAN; meios para determinar as regras de PCC para a sessão de PCC com base no protocolo de mobilidade; e meios para enviar as regras de PCC para a primeira entidade de rede.

7. Entidade de PCRF, de acordo com a reivindicação 6, caracterizada pelo fato de que os pacotes para a sessão de PCC são encapsulados em pacotes tunelados trocados entre o UE (110) e a primeira entidade de rede através de uma segunda entidade de rede, a entidade adicionalmente compreendendo: meios para determinar a segunda regra de PCC compreendendo um conjunto de pelo menos um filtro para identificar os pacotes tunelados e uma indicação para não contar os pacotes tunelados para taxação; e meios para enviar a segunda regra de PCC para segunda entidade de rede para aplicar aos pacotes tunelados.

8. Entidade de PCRF, de acordo com a reivindicação 6, caracterizada pelo fato de que adicionalmente compreende: meios para receber uma segunda solicitação de uma entidade de rede para estabelecer uma segunda sessão de PCC para o UE (110); meios para determinar um tipo de acesso de rádio utilizado pelo UE (110) para segunda entidade de rede com base na segunda solicitação; meios para determinar a segunda regra de PCC para segunda sessão de PCC com base no tipo de acesso de rádio utilizado pelo UE (110); e meios para enviar a segunda regra de PCC para segunda entidade de rede.

9. Método para comunicação sem fio, caracterizado pelo fato de que compreende: aceitar (712) o acesso por um equipamento de usuário, UE (110) com base em um protocolo de mobilidade a uma primeira entidade de rede; definir um parâmetro tipo IP-CAN com base no protocolo de mobilidade utilizado pelo UE (110); gerar a solicitação compreendendo o parâmetro tipo IP- CAN; enviar (714) uma solicitação para uma entidade de função de regras de controle de política e taxação (PCRF) para estabelecer uma sessão de controle de política e taxação (PCC) para o UE (110), a solicitação compreendendo o protocolo de mobilidade utilizado pelo UE (110); receber (716) as regras de PCC para a sessão de PCC a partir da entidade de PCRF, as regras de PCC sendo determinadas com base no protocolo de mobilidade; e aplicar (718) as regras de PCC aos pacotes trocados com o UE (110) para a sessão de PCC.

10. Primeira entidade de rede para comunicação sem fio, caracterizada pelo fato de que compreende: pelo menos um processador configurado para aceitar acesso por um equipamento de usuário (110) com base em um protocolo de mobilidade em uma primeira entidade de rede, para definir um parâmetro tipo IP-CAN com base no protocolo de mobilidade utilizado pelo UE (110), e gerar a solicitação compreendendo o parâmetro Tipo IP-CAN, enviar uma solicitação para uma entidade de função de regras de controle de políticas e taxação, PCRF, para estabelecer uma sessão de controle de política e taxação (PCC) para o UE (110), a solicitação compreendendo o protocolo de mobilidade utilizado pelo UE (110) receber as regras de PCC para a sessão de PCC a partir da entidade de PCRF, e aplicar as regras de PCC aos pacotes trocados com o UE (110) para a sessão de PCC.

11. Memória legivel por computador caracterizada pelo fato de que compreende instruções armazenadas na mesma, as instruções sendo executáveis por um computador para realizar o método conforme definido em qualquer uma das reivindicações 1 a 5 ou 9.