BRPI0721599A2 - mÉtodo, interface e nà para uso em um sistema de telecomunicaÇÕes de acesso sem fio - Google Patents

Abstract

METODO, INTERFACE E Nà PARA USO EM UM SISTEMA DE TELECOMUNICAÇÕES DE ACESSO SEM FIO. Um método (300) para um sistema de telecomunicação sem fio 5 (200) com equipamento de usuário, UE (110), e um primeiro nó (120) para que um UE possa enviar uma solicitação para acesso a um serviço, e uma função de controle (160) com informação sobre os direitos de acesso para serviços específicos para UEs no sistema. O sistema (200) compreende uma interface (150) entre o primeiro nó (120) mencionado e a função de controle (160), e método (300) compreende o estágio (3) de deixar o primeiro nó mencionado receber informação sobre os direitos de acesso do EU proveniente da função de controle mencionada, e deixar o primeiro nó tratar as solicitações de acesso a um serviço, provenientes de um UE usando a informação de direitos de acesso proveniente da função de controle. O método adicionalmente compreende o estágio (3) de deixar a informação de direitosde acesso proveniente da função de controle mencionada para o primeiro nó mencionado compreende um código (X, Y, Z) considerando serviços para os quais o UE tem acesso negado.

Description

"MÉTODO, INTERFACE E NÓ PARA USO EM UM SISTEMA DE TELECOMUNICAÇÕES DE ACESSO SEM FIO" CAMPO TÉCNICO

A presente invenção divulga um método e um dispositivo por meio do qual autorização de serviço melhorado pode ser obtido em um sistema de telecomunicações de acesso sem fio. FUNDAMENTO

No presente, em alguns sistemas de telecomunicações de acesso sem fio, tal como, por exemplo, sistemas de 2 G e 3G, tal como 3 G- GPRS, há funções no sistema para permitir ou negar acesso dos usuários aos serviços dentro do sistema ou serviços fora do sistema. Na maioria dos sistemas de 2G e 3G, as funções para permitir e ou negar a um usuário tal acesso, são designadas na seguinte maneira: um usuário solicita acesso para um serviço por meio de uma solicitação para um nó no sistema, em um sistema GPRS, o assim chamado GGSN, o nó de Suporte de Portão de Passagem de GPRS.

O GGSN obteve conhecimento dos direitos do usuário e que serviços o usuário pode acessar, por meio de uma outra função no sistema, usualmente conhecida como a PCRF, Função de Regra de Cobrança e Política. Usualmente, quando um UE solicita uma nova sessão, e. g. é ligado inicialmente, o GGSN solicita, e recebe proveniente da PCRF, uma lista que define aqueles serviços que o usuário pode ou não pode acessar. Esta lista é então usado pelo GGSN durante a sessão em questão, de modo a permitir ou negar o acesso do usuário aos serviços que o usuário solicita acesso. Se um usuário solicita acesso a um serviço para o qual o

GGSN deseja, de acordo com a informação proveniente da PCRF, para negar acesso a ele, a solicitação pode ser re-direcionada para uma função separada no sistema, que trata a negação das solicitações de serviço. Esta função separada vai enviar uma mensagem para o UE informando o usuário sobre a negação, e. g. ele vão receber uma mensagem tal como "Acesso Negado" ou "Serviço não Autorizado".

No contexto de permitir ou negar acesso a um usuário, o GGSN assume um papel referenciado como Função de Imposição de Política de Cobrança, PCEF. A PCEF acessa a PCRF por meio de uma interface conhecida como Gx.

Alguns serviços que normalmente é permitido a um usuário ter acesso podem temporariamente não ser autorizados, e. g. devido a um número de políticas de PCRF definidas: · Um serviço que a um usuário normalmente é permitido ter

acesso pode não ser autorizado se o usuário vagueia em uma rede diferente,

• Alguns serviços podem ser autorizados durante somente certos períodos do dia, e. g. entre 09:00 e 18:00 somente nos dias de semana.

• Certos serviços podem somente ser autorizados em caso que o canal de transporte solicitado forneça qualidade bastante boa.

• Limitações no equipamento terminal do usuário.

Mesmo embora seja claro qual a razão que um ou mais serviços podem ser negados para um usuário, a interface Gx somente fornece informação considerando se a um usuário é ou não permitido acesso para um serviço ou não.

Por exemplo, é impossível para a PCEF / GGSN conhecer se a um usuário é negado acesso a um determinado serviço devido ao fato que o terminal do usuário não suporta o serviço em questão, ou se a negação é devida ao fato que o usuário está vagueando em uma outra rede, na qual o serviço em questão é negado. Então, a única ação que a PCEF pode tomar no caso de uma negação é re-direcionar as solicitações de serviço emitidas proveniente do terminal de usuário para um endereço de redirecionamento genérico que informa ao usuário que o serviço é negado por uma razão não específica, como exemplificado pelas mensagens acima. SUMÁRIO Como emergente da descrição acima, há assim uma necessidade para um método por meio do qual um nó tal como, por exemplo, uma PCEF / GGSN possa fornecer a um usuário que é negado acesso a um serviço para o qual ele solicitou acesso, mais informação considerando a razão para a negação do que é possível no presente.

Esta necessidade é abordada pela presente invenção na qual divulga um método para uso em um sistema de telecomunicação sem fio, no qual sistema pode haver um número de equipamentos de usuário, UE, e um primeiro nó para o qual um UE pode enviar uma solicitação para acesso a um serviço específico.

O sistema no qual a invenção pode ser aplicada também compreende uma função de controle que mantém informação sobre os direitos de acesso a serviços específicos para uma pluralidade de UEs no sistema, e o sistema adicionalmente compreende uma interface entre o primeiro nó mencionado e a função de controle.

O método da invenção compreende o estágio de deixar o processo o primeiro nó receber informação sobre os direitos de acesso de um UE proveniente da função de controle, e também compreende o estágio de deixar o primeiro nó tratar solicitações de acesso a um serviço provenientes de um UE usando a informação de direitos de acesso proveniente da função de controle. O método também compreende o estágio de deixar a informação de direitos de acesso proveniente da função de controle para o primeiro nó compreender um código considerando serviços para os quais é negado acesso ao UE.

Assim sendo, por meio da presente invenção, o primeiro nó, e. g. o PCEF / GGSN pode usar o código obtido proveniente da função de controle, e. g. a PCRF, de modo a fornecer usuários com informação mais detalhada considerando a razão pela qual a ele sé negado acesso para um determinado serviço. Em uma modalidade preferida da presente invenção, o código é usado pelo primeiro nó (PCEF / GGSN) de modo a re-direcionar a solicitação de acesso para uma segunda função no sistema, e nesta modalidade, o método também compreende o estágio de deixar a segunda função enviar uma mensagem explícita considerando a razão para a negação para o UE solicitante. Contudo, também é totalmente possível deixar o primeiro nó conter uma lista dos códigos mencionados, tal que um código pode ser "decodificado" no primeiro nó, em qual caso a mensagem que corresponde ao código em questão pode ser enviada para o UE proveniente do primeiro nó.

Em adição ao problema de "mensagens de negação" que não contêm quantidades suficiente de informação, um problema adicional nos sistemas atuais é que um operador pode querer conceder a certos usuários, acesso a serviços durante um intervalo limitado no tempo, tal como por exemplo, entre 08:00 às 18:00 nos dias de semana. De modo a alcançar isto com o atual protocolo padrão de Gx, a informação de autorização na PCEF para todas as sessões afetadas vai necessitar ser atualizada essencialmente ao mesmo tempo. Isto vai causar picos maciços na sinalização de Gx, que é altamente indesejável.

Este problema é também abordado pela presente invenção, na qual a invenção em uma particular modalidade compreende o estágio de deixar a informação de direitos de acesso proveniente da função de controle (e. g. PCRF) para o primeiro nó (e. g. PCEF / GGSN) conter informação sobre períodos no tempo quando ao UE é permitido ou negado acesso para um ou mais dos serviços mencionados.

Assim sendo, por meio da presente invenção, é tornado possível informar aos usuários aos quais é negado acesso a um determinado serviço da razão para a negação, e também é possível melhorar a maneira na qual aos usuários pode ser negado ou concedido acesso aos serviços com base em intervalos de tempo. Essa e outras vantagens da presente invenção se tornarão bem mais aparentes com a seguinte descrição detalhada.

A invenção também divulga uma interface aprimorada para uso entre o primeiro nó (e. g. PCEF / GGSN) e a função de controle (e. g. PCRF), assim como um nó para uso como o primeiro nó mencionado. DESCRIÇÃO BREVE DOS DESENHOS

A invenção será descrita em mais detalhes a seguir com referência aos desenhos anexos, nos quais

Fig 1 mostra um sistema da arte anterior, e

Fig 2 mostra o sistema da fig 1, com a invenção aplicada, e

Figs 3 e 4 mostram exemplos de diagramas de eventos da

invenção.

DESCRIÇÃO DETALHADA

Fig 1 mostra um exemplo de um sistema da arte anterior 100, mostrado de modo a facilitar o entendimento do leitor da invenção. Na Fig 1, assim como na descrição abaixo, a invenção será descrita com a ajuda de componentes e nomes de sistema do sistema 3G GPRS, mas deve ser entendido que isto é à título de exemplo somente, a invenção pode ser aplicada para virtualmente qualquer sistema no qual é desejado resolver os problemas que são abordados por meio da invenção.

Como mostrado na Fig 1, no sistema 100 pode haver um número de equipamento de usuário, UE, 110, e um primeiro nó 120, um GGSN, que neste texto será referenciado de forma alternativa com uma PCEF, uma Função de Imposição de Política de Cobrança, já que o GGSN neste contexto constitui a PCEF para GPRS.

Pode ser assinalado que um sistema GPRS compreende numerosos componentes que não são mostrado na Fig 1. Isto é devido ao fato que somente aqueles componentes que são de interesse imediato para a presente invenção serão mostrados nos desenhos e descritos neste texto. Por exemplo, ao sistema de 3G GPRS compreende uma função conhecida como o SGSN, que é posicionado entre o UE 110 e o PCEF / GGSN 120. Contudo, as mensagens com os quais esta invenção está envolvida são "passado através" do SGSN em seu caminho entre o UE e o PCEF / GGSN, que significa que o SGSN é de menos interesse para esta invenção.

A PCRF 160 tem informação sobre que serviços que ao UE 110 deve ser concedido ou negado acesso. Esta informação é comunicada para o PCEF / GGSN, usualmente na solicitação de serviço de canal de transporte do UE inicial, embora o procedimento possa da mesma forma acontecer em outros momentos no tempo. A interface entre a PCRF 160 e a PCEF / GGSN 120 é conhecida como a interface Gx.

Assim sendo, a PCRF 160 comunica para o PCEF / GGSN 120 uma lista de serviços para a qual ao UE 130 deve ser negado ou concedido acesso. Como um exemplo, todos os serviços que não são concedidos na lista podem ser considerados negados. O PCEF / GGSN armazena esta lista, e quando um UE 110 envia uma mensagem de solicitação, mostrada pela seta 1 na Fig 1 para o PCEF / GGSN 120, solicitando acesso a um determinado serviço, o seguinte pode acontecer: · O PCEF / GGSN 120 concede acesso ao UE 110 para o

serviço em questão com base na informação fornecida proveniente da PCRF através da interface Gx. A solicitação é encaminhada / passada adiante pelo PCEF / GGSN para sua destinação.

• O PCEF / GGSN 120, por meio da informação fornecida proveniente da PCRF através da interface Gx, vê que ao UE 110 pode não ser concedido acesso para o serviço que ele solicitou acesso. Neste caso, a seta 2 do PCEF / GGSN intercepta a solicitação e envia uma "resposta de redirecionamento", mostrada pela seta 2 na Fig 1, para o UE, i. e. uma mensagem que redireciona a solicitação do UE para uma segunda função 170 no sistema, para a qual a solicitação do UE é redirecionada, mostrada como a seta 3 na Fig 1. A segunda função 170 envia uma mensagem, mostrada por meio da seta 4, para o UE 110. No sistema da arte anterior 100 da fig. 1, esta mensagem somente pode ser um "mensagem de negação" padronizada tal como "Acesso Negado" ou "Serviço não Autorizado".

Fig 2 mostra um sistema 200 da invenção. Componentes e funções que pode ser encontrados no sistema 100 da fig 1 foram dado os mesmos números de referência na Fig 1, e não serão explicados de novo aqui.

No sistema 200 da invenção, a função de controle 160, i. e. a PCRF, pode enviar informação para o PCEF / GGSN considerando os direitos de acesso do UE para um número de serviços através da interface Gx. Contudo, no sistema 200, como oposto ao sistema 100 da fig 1, a informação enviada proveniente da PCRF 160 para o PCEF / GGSN 120 pode ter a seguinte estrutura, como também indicado na Fig 2:

Exemplos de informação de autorização de serviço sobre a interface Gx proveniente da PCRF para o PCEF / GGSN:

Serviço "A": OK

Serviço "B": não OK, "NOK", código 2

Serviço "C": OK

Serviço "D": NOK; código 4.

Assim sendo, como pode ser visto, para serviços para os quais ao usuário 110 é negado acesso, a PCRF usa a interface Gx para informar de forma explícita ao PCEF / GGSN 120 não somente sobre quais serviços que são autorizados, mas também que serviços que não são autorizados (NOK), que pode ser temporariamente, acoplados junto com um código para a razão para a negação.

Subseqüentemente, quando o UE solicita acesso a um serviço para o qual a ele, de acordo com a informação proveniente da PCRF, deve ser negado acesso, o PCEF / GGSN usa os códigos contidos na mensagem da Gx mensagem como a seguir:

• O UE 110 envia sua mensagem de solicitação, seta 1 na Fig 2.

• O PCEF / GGSN 120 identifica o serviço selecionado e vê que ao UE 110 deve ser negado acesso para o serviço em questão e envia uma

mensagem de redirecionamento, seta 2 para o UE 110. Contudo, como oposto a esta seqüência de eventos no sistema da anterior sistema 100, o PCEF / GGSN agora tem informação adicional acoplada à negação de acesso, a informação adicional mencionada sendo o código mostrado acima. Em uma determinada modalidade da presente invenção, o código é usado de modo a redirecionar a solicitação de acesso proveniente do UE para uma de um número de funções especificadas, mostradas como 180-182 na Fig 2. A solicitação redirecionada é mostrada por meio de uma seta 3, e a resposta proveniente da função 180-182 é mostrada por meio de uma seta 4. Já que a solicitação negada pode ser redirecionada a uma de

um número de funções 180-182, o conteúdo da "mensagem de negação" para o UE 110 pode ser construído em uma maneira que tem sido impossível até agora. Preferencialmente, cada código de NOK está amarrado a uma das funções 180-182 especificadas, por meio da qual cada código NOK pode ser feito para corresponder a uma determinada mensagem de negação.

Assim sendo, cada uma das funções 180-182 é preparada com uma determinada, exemplo da qual poderia ser:

• O serviço solicitado pode somente ser alcançado de sua PLMN de Origem,, Rede de Terminais de Comunicação Móveis Terrestre

Publica.

• O serviço solicitado não pode ser acessado a partir deste tipo de terminal. Por favor, contate o suporte à cliente para requisitos mínimo do terminal.

• O serviço solicitado pode somente ser acessado entre 07:00 e 18:00 de Segunda à Sexta.

• O serviço solicitado requer uma conexão de 3G.

Naturalmente, o número de "função de mensagem de negação" 180-182 mostrado na Fig 2 são somente exemplos, o número pode ser variado mais ou menos de modo infinito.

Deve também ser assinalado que as funções de mensagem de negação 180-182 são meramente um meio de utilização de mensagens de Gx aprimoradas da invenção. Também é perfeitamente possível deixar o PCEF / GGSN compreender uma função de "decodificar" os próprios códigos proveniente da PCRF, tal que as mensagens de negação são enviadas diretamente a partir do PCEF / GGSN 120 para o UE 110 através de uma função para isto no PCEF / GGSN.

Em adição, também é possível deixar a função de mensagem de negação 180-182 ser externa ao PCEF / GGSN como mostrado na Fig 2, mas deixar ela ser uma função só, que como tal compreenda a habilidade para decodificar todo os códigos enviados proveniente da PCRF considerando as razões para negação.

Como surgiu da descrição acima, a presente invenção compreende estender o protocolo da Gx tal que a PCRF pode comunicar mais informação para o PCEF considerando razões para negar a um UE acesso a um serviço. As extensões para o protocolo da Gx podem ser referenciadas como Equivalências de Valores de Atributos, AVPs, um termo que pode ser usado abaixo, AVPs sendo blocos de informação usados pelo protocolo da Gx.

Fig 3 mostra uma seqüência de sinalização 300 na qual as

AVPs da presente invenção são usadas. A sinalização é entre um UE, uma PCEF, uma PCRF e um servidor de Redirecionamento que corresponde às funções 180-182 da figura 2.

A seqüência é como a seguir: 1. Estabelecer solicitação de serviço de canal de transporte: O UE envia uma solicitação para o PCEF / GGSN para configurar um canal de transporte. Para GPRS, esta seria uma Solicitação para Ativar Contexto de PDP.

2. CCR da Gx, Solicitação de Controle de Crédito, inicial. A

PCEF inicia uma sessão de Gx com a PCRF, e inclui a identidade do UE e, a QoS solicitada, ID da PLMN, etc.

3. CCA inicial da Gx. A PCRF responde com um CCA, Resposta de Controle de Crédito, contendo uma Instalação de Regra de

Cobrança para uma Base de Regra de Cobrança que está autorizada e um Nome de Regra de Cobrança que normalmente está disponível somente na PLMN de Origem. Já que o UE neste exemplo, esta correntemente vagueando em uma outra rede de operador, o serviço é temporariamente não autorizado. A CCA em questão pode conter a seguinte informação: AVP de Instalação de Regra de Cobrança

Nome Base de Regra de Cobrança = 1 AVP de Instalação de Regra de Cobrança Nome de Regra de Cobrança = 5 AVP de Autorização de Regra de Cobrança Estado de Autorização= DENIEDRO AMING

4. Estabelecer Solicitação de Serviço de Canal de Transporte. O canal de transporte Solicitado é aceito. Para GPRS, isto seria uma Aceitação para Ativar Contexto de PDP.

5. O UE solicita acesso a uma página da web, e. g. URL "χ". A PCEF detecta que URL "x" corresponde á e. g. Regra Nr 5 de Cobrança, que é

temporariamente não autorizada devido a estar vagueando.

6. A PCEF envia uma resposta para o UE com uma indicação de redirecionamento que inclui o endereço de servidor de redirecionamento configurado usado somente para DENIED ROAMING (uri "y") 7. O UE emite uma solicitação para uri "y"

8. O servidor de redirecionamento em URL "y" responde para o UE que a página de web solicitada pode somente ser acessado a partir da PLMN de Origem.

A seguir, à título de exemplo somente, alguns exemplos de

AVPs da presente invenção serão dados. AVP de Instalação de Regras de Cobrança

O estado de autorização para o corrente e próximo período de tempo está incluído na AVP de Instalação de Regra de Cobrança, inserindo uma nova AVP; A AVP de Autorização de Regra de Cobrança: Instalação de Regra de Cobrança:= < cabeçalho de AVP: 1001 >

* [ Definição de Regra de Cobrança ]

* [ Nome de Regra de Cobrança ]

*[ Nome Base de Regra de Cobrança ] [Autorização de Regra de Cobrança]

*[ AVP]

A informação de autorização fornecida na AVP de Autorização de Regra de Cobrança é válida para todos Nomes de Regra de Cobrança e Nomes Base de Regra de Cobrança fornecidos naquela circunstância da AVP de Instalação de Regra de Cobrança AVP fornecida em uma CCA ou RAR, Re- Solicitação de Re-autorização.

Se nenhuma AVP de Autorização de Regra de Cobrança está presente na AVP de Autorização de Regra de Cobrança então isto implica que todas as Definições de Regra de Cobrança, Nome de Regra de Cobranças e Nome Base de Regra de Cobranças são autorizadas sem quaisquer restrições (solução padrão).

AVP de Autorização de Regra de Cobrança

A AVP de Autorização de Regra de Cobrança agrupa os AVPS que são requeridos para definir o estado de autorização para o corrente e próximo período de tempo para as regras de cobras associadas e as bases de regra de cobrança.

A AVP de Autorização de Regra de Cobrança é compartilhado na mesma Instalação de Regra de Cobrança para aqueles Nomes de Regra de Cobranças ou Nome Base de Regra de Cobranças que têm o mesmo estado de Autorização.

A AVP de Autorização de Regra de Cobrança pode parecer

como a seguir:

Autorização de Regra de Cobrança = < cabeçalho de AVP:

1055, Id do Vendedor : 193 >

{Estado de Autorização}

[Tempo de Mudança de Estado de Autorização]

[Próximo Estado de Autorização]

*[ AVP ]

AVP de Estado de Autorização

A AVP de Estado de Autorização pode ser do tipo "enumerado", e especifica o estado de autorização e a razão para não autorização para as regras de cobrança e bases de regra de cobrança fornecidas na AVP de Instalação de Regra de Cobrança AVP.

Os seguintes valores podem ser definido para as AVP de

Estado de Autorização:

AUTHORIZED 0

DENIEDCALENDARTEMPO 1

DENIEDROAMING 2 DENIEDQUALITYOFSERVIÇO 3

DENIEDBLACKLISTED 4

DENIEDTERMINAL 5

DENIEDOPERATORREASONONE 6

DENIED_ OPERATORREASONTWO 7 DENIED_ OPERATOR REASON THREE 8 DENIED_ OPERATORREASONFOUR 9 DENIED_ OPERATORREASONFIVE 10

DENIEDUNKNOWNREASON 11

Com foi visto da descrição dada acima, por meio da invenção, um problema associado com " mensagens de negação de acesso" pode ser abordado. Um outro problema que pode ser resolvido através de uma particular modalidade da invenção é que um operador de um sistema pode querer autorizar alguns serviços para um grande número de usuários durante um período de tempo limitado, tal como um particular intervalo de um dia, tal como, por exemplo, entre 08:00 às 18:00 em dias de semana. Para alcançar isto com o protocolo de Gx atual que é usado entre a PCRF e a PCEF, a informação de autorização na PCEF de todas as sessões afetadas necessitam ser atualizados mais ou menos ao mesmo ponto de tempo no tempo. Isto causa picos maciços na sinalização da Gx no sistema, que são indesejáveis.

De modo a abordar este problema, a modalidade mencionada da presente invenção compreende o estágio de deixar a informação de direitos de acesso proveniente da função de controle, i. e. a PCRF, para o primeiro nó, i. e. um PCRF / GGSN, compreende informação sobre períodos no tempo quando a um UE é permitido ou negado acesso a um ou mais serviços.

Como um exemplo, alguns serviços podem ser autorizados para um certo usuário durante somente um período de tempo específico, e. g. para 24 horas do momento quando o serviço é ativado, ou durante períodos do dia recorrentes, e. g. entre 07:00 - 18:00 em dias de semana.

De modo a fornecer tal informação para a PCEF, o "código de autorização" descrito acima, fornecido pela PCRF para o PCEF, a assim chamada regra de PCC, pode ser associada com informação considerando um específico ponto no tempo quando o estado de autorização muda. O próximo estado de autorização que é válido após a mudança de estado de autorização precisa também ser fornecido para estes tipos de serviços. Desta maneira, será possível para a PCEF determinar que e. g. a um determinado usuário é para ser concedido acesso a um determinado serviço até, neste exemplo,, 18:00, e daqui em diante ao usuário deve ser negado acesso para o serviço, devido as restrições de tempo do calendário. É claro que o oposto também é possível, i. e. o serviço é primeiro temporariamente negado ao usuário devido às restrições de tempo do calendário, mas após 18:00, no presente exemplo, ao usuário é concedido acesso para o serviço.

Um outro "bloco de construção" no tempo de calendário baseado na modalidade da invenção é um contador de tempo de validade que programa a PCEF para solicitar nova informação de política proveniente da PCRF. O contador de tempo de validade é fornecido pela PCRF para o PCEF, e deve tipicamente ser configurado mais longo do que o momento de mudança de estado de autorização, e. g. mais longo do que 18:00 no presente exemplo, mas curto o bastante para pegar nova informação de política antes que o próximo consecutivo momento de mudança de estado ocorra, neste i. e. neste exemplo, o mais tardar às 07:00 da manhã seguinte.

Assim sendo, por meio de tempo de calendário baseado na modalidade de autorização da invenção, picos de sinalização da Gx podem ser evitados.

De modo a explicar o tempo baseado na autorização ou negação / concessão de acesso a determinados serviços, referência será agora feita para a fig 4, que é um diagrama de sinalização 400 no qual o tempo baseado em negação / concessão de acesso é usado.

A sinalização na Fig 4 está entre um UE, uma PCEF e uma PCRF. A sinalização é como a seguir, com referência às setas horizontais mostrado na Fig 4:

1'. Estabelecer solicitação de serviço de canal de transporte. O UE envia uma solicitação para o PCEF / GGSN para configurar um canal de transporte. Para GPRS, isto seria uma Solicitação de Ativação de Contexto de PDP.

2'. CCR inicial da Gx. O PCEF / GGSN inicia uma sessão da Gx com a PCRF, e inclui a identidade do UE, QoS Solicitado, Id de PLMN, etc.

3'. CCA inicial da Gx. A PCRF responde com a CCA contendo uma Instalação de Regra de Cobrança para uma Base de Regra de Cobrança que é autorizada e um Nome de Regra de Cobrança que é correntemente não autorizado devido ao tempo de calendário. O tempo de mudança do estado de autorização é configurado para ser em 07:00 para a manhã seguinte. Quando o tempo de mudança de estado de autorização passou, acesso para o serviço é concedido para o usuário (próximo estado de autorização). Em adição, os estados de tempo de validade de autorização que a informação de política precisa ser atualizada pela PCEF antes das 18:00 do próximo dia. A CCA em questão pode ter o seguinte formato:

Evento de Acionamento = TIME CHANGE AVP de Instalação de Regra de Cobrança AVP Nome Base de Regra de Cobrança = 1 AVP de Instalação de Regra de Cobrança AVP Nome de Regra de Cobrança = 5

AVP de Autorização de Regra de Cobrança Estado de Autorização= NEGADO CALENDAR TEMPO Tempo de Mudança de Estado de Autorização = 07/08/01, 07:00 UTC Próximo Estado de Autorização = AUTHORIZED Tempo de Validade de Autorização = 07 / 08 / 01, 18:00 UTC

4'. Estabelecer Solicitação de Serviço de Canal de Transporte. O canal de transporte Solicitado é aceito. Para GPRS esta seria uma Aceitação de Ativação de Contexto de PDP. Todas as solicitações de serviço associadas com o Nome de Regra de Cobrança em questão será redirecionada para um servidor de redirecionamento para DENIEDCALENDARTIME para este canal de transporte.

5'. Em 07:00, as mudanças do estado de autorização de DENIED CALENDAR TIME para AUTHORIZED. De agora em diante, a PCEF não vai mais redirecionar solicitações de serviço para Nome de Regra de Cobrança em questão, mas as solicitações serão passadas através dela.

6'. Atualização de CCR. Em um ponto no tempo antes de 18:00, a PCEF emite uma nova CCR de modo a atualizar a informação de política. A PCEF é responsável para distribuir este tipo de solicitações de modo a evitar picos de sinalização no caso que há muitas sessões que compartilham o mesmo Tempo de Validade de Autorização.

7', Atualização de CCA. A PCRF responde com nova informação de política. A Regra de Cobrança em questão agora tem o estado de autorização AUTHORIZED e um próximo estado de autorização que é DENIEDCALENDARTEMPO. O tempo de mudança de estado de autorização é em 18:00, e a informação de política precisa ser atualizada de novo o mais tardar em 07:00 do dia seguinte. Os novos valores podem parecer com a seguir.

Evento de Acionamento = TIME CHANGE

AVP de Instalação de Regra de Cobrança

Nome de Regra de Cobrança = 5

AVP de Autorização de Regra de Cobrança

Estado de Autorização = AUTHORIZED

Tempo de Mudança de Estado de Autorização = 07 / 08 /01,

18:00 UTC

Próximo Estado de Autorização =

DENIEDCALENDARTEMPO

Tempo de Validade de Autorização = 07 / 08 / 02, 07:00 UTC Alguns exemplos de AVPs da invenção que podem ser usados com o calendário baseado em concessão ou negação de acesso aos serviços são mostrados abaixo. Deve ser assinalado que as AVPs abaixo são meramente exemplos, e são de nenhuma maneira para serem vistas como restritivo para o escopo de proteção pensado para a presente invenção.

AVP de Tempo de Mudança de Estado de Autorização

O Tempo de Mudança de Estado de Autorização é uma gravura de tempo identificando a date e hora quando o estado de autorização fornecido na AVP de Estado de Autorização não vai mais ser válida. Um exemplo de uma AVP de Tempo de Mudança de Estado de Autorização é que ele é do tipo "Hora" e inclui o tempo em segundos desde 1 de janeiro de 1900, 00:00 UTC.

AVP do Próximo Estado de Autorização

Um exemplo da AVP do Próximo Estado de Autorização é que ele é do tipo "enumerado", e especifica o estado de autorização e a razão para não autorização após o tempo de validade, definido na AVP de Tempo de Mudança de Estado de Autorização, ter passado. Os seguintes valores podem ser definidos para a AVP do Próximo Estado de Autorização: AUTHORIZED 0

DENIEDCALENDARTIME 1

AVP de Tempo de Validade de Autorização

O AVP de Tempo de Validade de Autorização pode ser incluído em uma Resposta de Controle de Crédito, CCA, ou em uma Solicitação de Re-autorização, RAR. O Tempo de Validade de Autorização é uma gravura de tempo identificando a data e hora quando a informação de autorização, fornecida nas AVPs de Instalação de Regra de Cobrança, não vai mais ser válida. Um exemplo de uma específica AVP de Tempo de Validade de Autorização é que ele é do tipo "Hora", e inclui o tempo em segundo desde 1 de janeiro de 1900, 00:00 UTC. AVP de Evento de Acionamento A AVP de Evento de Acionamento é de forma adequada do tipo "Enumerado". O Evento de Acionamento indica um evento que vai forçar uma re-solicitação de Regras de PCC. O seguinte valor pode ser definido para esta AVP:

TIMECHANGE 100

Este valor é usado para indicar que antes do determinado tempo, especificado na AVP de Tempo de Validade de Autorização, novas regras de PCC deve ser solicitado.

Note: se para Evento de Acionamento 100 e a AVP do Tempo de Validade de Autorização não são fornecidos, mas a AVP do Tempo de Mudança de Estado de Autorização foi fornecido em uma AVP de Autorização de Regra de Cobrança, então o próximo estado de autorização será um estado permanente de autorização, até novas decisões de PCC são fornecidos pela PCEF. Isto é útil para realizar subscrições baseadas no tempo, e. g. 12 hora de acesso para serviço "A".

A invenção também compreende como tal um nó 120 como mostrado acima, o nó mencionado de forma adequada sendo um PCEF / GGSN de um sistema de 2G ou de 3G tal como o sistema de 3G GPRS. Tal um nó vai compreender meios para receber a informação sobre os direitos de acesso do UE proveniente da função de controle 160. Esses meios 145 simbolicamente foram mostrados como um processador 145 na Fig 2, mas os meios também pode ser uma adequada combinação de hardware ou software.

Um nó da invenção também vai compreender meios para tratar solicitações de acesso a um serviço proveniente de um UE usando a informação de direitos de acesso proveniente da função de controle mencionada, esses meios também de forma adequada sendo o processador 145, que também vai ser capaz para tratar a informação de direitos de acesso proveniente da função de controle, a PCRF, incluindo um código, Χ, Υ, Z, considerando serviços para os quais ao UE é negado acesso. De forma adequada, o processador 145 também trata o redirecionamento das solicitações de acesso a serviços que a um UE é negado acesso, como mostrado acima, assim como tratar informação sobre períodos no tempo quando ao UE 110 é permitido ou negado acesso a um ou mais dos serviços mencionados, tal que a um UE que solicita acesso a um determinado serviço a partir do nó 120 pode ser negado ou concedido acesso pelo nó 120 com base no tempo do dia, semana, mês etc que a solicitação é feita.

Em conclusão, a autorização de serviço aprimorada de uma interface Gx como divulgada pela presente invenção permite ao PCEF / GGSN realizar um serviço de redirecionamento seletivo para um servidor de redirecionamento que pode fornecer informação detalhada a um usuário final, i. e. a um UE considerando porque ao UE foi negado acesso para um determinado serviço para o qual ele solicitou acesso, e para qual serviço ao usuário é normalmente permitido ter acesso. O tempo de calendário baseado na informação de autorização

conduzida através da interface Gx como divulgado pela presente invenção fornece ao PCEF / GGSN informação que permite ele realizar serviço baseado em controle de acesso para serviços que são autorizados somente para um determinado período de tempo, ou somente durante, por exemplo, certo tempos do dia ou da semana.

Por meio desta informação, será possível evitar os picos de sinalização que soluções de Gx nos dias atuais iriam implicar para estes tipos de serviços, quando a informação de política de grandes números de sessões necessita ser atualizada ao mesmo tempo. A invenção não é restrita aos exemplos das modalidades

descritas acima e mostrada nos desenhos, mas pode ser variada livremente dentro do escopo das reivindicações anexas.

Claims (12)

1. Método (300) para uso em um sistema de telecomunicações de acesso sem fio (200), cujo sistema pode haver um número de equipamento de usuário, UE (110), e um primeiro nó (120) para o qual um UE pode enviar uma solicitação para acesso a um serviço específico, o sistema (200) também compreendendo uma função de controle (160) que mantém informação sobre os direitos de acesso à serviços específicos para uma pluralidade de UEs no sistema, o sistema (200) em adição compreendendo uma interface (150) entre o primeiro nó (120) e a função de controle (160), o método (300) compreendendo o estágio (3) de deixar o primeiro nó mencionado receber informação sobre os direitos de acesso dos UE proveniente da função de controle, e o estágio (5) de deixar o primeiro nó mencionado tratar as solicitações de acesso a um serviço proveniente de um UE usando a informação de direitos de acesso da função de controle mencionada, o método sendo caracterizado pelo fato de que ele adicionalmente compreende o estágio (3) de deixar a informação de direitos de acesso proveniente da função de controle mencionada para o primeiro nó mencionado compreender um código (Χ, Υ, Z) considerando os serviços para a que o UE tem acesso negado.

2. Método (300) de acordo com a reivindicação 1, caracterizado pelo fato de que se um UE (110) solicita acesso a um serviço para ao qual ele tem acesso negado de acordo com a informação proveniente da função de controle (160), o código (Χ, Υ, Z) mencionado é usado pelo primeiro nó (120) de modo a redirecionar a solicitação de acesso para uma segunda função (180-182) no sistema, o método (300) também compreende o estágio (8) de deixar a segunda função (180-182) enviar uma mensagem explícita considerando a razão para a negação para o UE solicitante.

3. Método (300, 400) de acordo com a reivindicação 1 ou 2, adicionalmente caracterizado pelo fato de compreender o estágio (3') de deixar a informação de direitos de acesso proveniente da função de controle mencionada (160) para o primeiro nó mencionado (120) compreender informação sobre períodos no tempo quando ao UE (110) tem acesso permitido ou negado a um ou mais dos serviços mencionados.

4. Método (300, 400) de acordo com qualquer uma das reivindicações anteriores, caracterizado pelo fato de que o primeiro nó mencionado (120) é o GGSN de um sistema de 2G ou de 3G, configurado para atuar como uma PCEF, Função de Imposição de Política de Controle, e a função de controle é a PCRF, Função de Regra de Cobrança e Política do sistema.

5. Interface (150 para uso em um sistema de telecomunicações de acesso sem fio (200), cujo sistema pode haver um número de equipamento de usuário, UE (110), e um primeiro nó (120) para o qual um UE pode enviar uma solicitação para acesso a um serviço específico, o sistema (200) também compreendendo uma função de controle (160) que mantém informação sobre os direitos de acesso à serviços específicos para uma pluralidade de UEs no sistema, a interface mencionada sendo a interface (150) usada entre o primeiro nó (120) e a função de controle (160), de modo a conduzir, à propósito, informação proveniente da função de controle mencionada para o primeiro nó (120) mencionado, sobre os direitos de acesso dos UE para certos serviços, a interface (150) sendo caracterizada pelo fato de que ela compreende, junto com a informação de direitos de acesso mencionada, um ou mais códigos (Χ, Υ, Z) considerando os serviços para que o UE tem negado acesso.

6. Interface (150) de acordo com a reivindicação 5, caracterizada pelo fato de que os códigos (Χ, Υ, Z) mencionados podem ser usados pelo primeiro nó mencionado se um UE (110) solicita acesso para um serviço para o qual lhe é negado acesso de acordo com a informação proveniente da função de controle (160), de modo a redirecionar a solicitação de acesso para uma segunda função(180-182) no sistema.

7. Interface de acordo com a reivindicação 5 ou 6, caracterizada pelo fato de que a informação de direitos de acesso proveniente da função de controle mencionada (160) para o primeiro nó mencionado (120) compreende informação sobre períodos no tempo quando ao UE (110) tem acesso permitido ou negado a um ou mais dos serviços mencionados.

8. Interface (150) de acordo com qualquer uma das reivindicações 5-7, caracterizada pelo fato de que a interface Gx em um sistema 2G ou 3G, tal como o sistema de 3G GPRS sistema.

9. Nó (120) para uso em um sistema de telecomunicações de acesso sem fio (200), cujo sistema pode haver um número de equipamento de usuário, UE (110), cujo nó (120) um UE pode enviar uma solicitação para acesso a um serviço específico, o nó compreendendo meios para trocar informação com uma função de controle (160) no sistema que mantém informação sobre os direitos de acesso à serviços específicos para uma pluralidade de UEs no sistema, a troca de informação mencionada sendo realizada sobre uma interface (150) entre o nó (120) e a função de controle (160), o nó (120) compreendendo meios (145) para receber a informação sobre os direitos de acesso de um UE proveniente da função de controle mencionada (160) e meios (145) para tratar solicitações de acesso a um serviço proveniente de um UE usando a informação de direitos de acesso proveniente da função de controle mencionada, o nó (120) sendo caracterizado pelo fato de que ele adicionalmente compreende meios (145) para tratar a informação de direitos de acesso proveniente da função de controle mencionada incluindo um código (Χ, Υ, Z) considerando os serviços para os quais ao UE tem acesso negado.

10. Nó (120) de acordo com a reivindicação 9, caracterizado pelo fato de que os meios (145) mencionados para tratar a informação de direitos de acesso usa um ou mais dos códigos (Χ, Υ, Z) mencionados se um UE (110) solicita acesso a um serviço para o qual lhe é negado acesso de acordo com a informação proveniente da função de controle (160) mencionada, o código (Χ, Υ, Z) mencionado sendo usado pelos meios mencionados (145) de modo a redirecionar a solicitação de acesso para um de um número de segundas funções (180-182) no sistema, o código sendo usado de modo a selecionar a segunda função apropriada.

11. Nó (120) de acordo com a reivindicação 9 ou 10, adicionalmente caracterizado pelo fato de compreender meios (145) para tratar a informação de direitos de acesso proveniente da função de controle mencionada (160) que compreende informação sobre períodos no tempo quando ao UE (110) tem acesso permitido ou negado para um ou mais dos serviços mencionados, tal que a um UE que solicita acesso a um determinado serviço proveniente do nó (120) pode ser negado ou concedido acesso pelo nó (120) com base no tempo do dia, semana, mês etc que a solicitação é feita.

12. Nó (120) de acordo com qualquer das reivindicações 9-11, caracterizado pelo fato de ser um GGSN de um sistema de 2G ou a 3G configurado para atuar como uma PCEF, Função de Imposição de Política de Cobrança, no sistema.