PT2218270E

PT2218270E - Sistema e método para autenticar a transferência de um contexto

Info

Publication number: PT2218270E
Application number: PT08844578T
Authority: PT
Inventors: Valtteri Niemi; Marc Blommaert; Dan Forsberg; Frank Mademann
Original assignee: Nokia Corp
Priority date: 2007-10-29
Filing date: 2008-10-27
Publication date: 2012-01-24
Also published as: EP2218270B1; KR20100086013A; TWI489839B; TW200934195A; ATE535108T1; ES2375594T3; US9204295B2; EP2218270A2; KR101167781B1; CN101843126B; CN101843126A; PL2218270T3; WO2009056938A3; WO2009056938A2; US20090111428A1

Description

1

DESCRIÇÃO

"SISTEMA E MÉTODO PARA AUTENTICAR A TRANSFERÊNCIA DE UM CONTEXTO"

REFERÊNCIA CRUZADA RELATIVA AO REQUERIMENTO

Este requerimento reivindica o beneficio da Aplicação Provisional U.S. Ser. N.° 60/983, 450, arquivada em 29 de outubro de 2007 e intitulada "Sistema e Método para Autenticar uma Transferência de Contexto de MME para um Sistema 3GPP Legado".

ANTECEDENTES

Esta secção destina-se a providenciar uma base contextuai para o material que é descrito abaixo e / ou referido nas reivindicações. Esta secção de base pode incluir conceitos que poderiam ser seguidos, mas que não são necessariamente aqueles que tenham sido previamente concebidos ou seguidos. A menos que especificamente indicado de outra forma, esta secção não é arte anterior à descrição e reivindicações no presente requerimento e nada nesta secção é admitido como sendo arte anterior.

No Sistema de Telecomunicações Móveis Universal (UMTS) de acesso à Rede de Rádio Terrestre (UTRAN), é utilizada uma assinatura (assinatura do P-TMSI) do identificador de estação temporária móvel de rede de pacotes comutados (P-TMSI) para autenticar e autorizar a transferência de informações de contexto do equipamento do utilizador (UE) . Como é geralmente entendido na arte, o protocolo de pacotes de dados (PDP) de informação de contexto para um UE é um registo de valores de parâmetros que fornece as informações necessárias para estabelecer uma ligação. Esses parâmetros podem incluir informações sobre um tipo de contexto de PDP a ser utilizado, informação de Qualidade de Serviço (QoS), etc. A autenticação e autorização são executadas quando as informações de contexto do UE são transferidas entre 2 entidades de rede de um único sistema, ou entre entidades de rede de diferentes sistemas, quando um servidor do nó de suporte (SGSN) do Serviço de Rádio de Pacote Geral (GPRS) é alterado. Esta mudança pode ocorrer quando o UE está a ser transferido, devido à sua movimentação para uma localização diferente. Desta forma, o SGSN antigo (isto é, o SGSN a partir do qual o UE está a ser transferido) pode verificar se um pedido de transferência de contexto de um novo SGSN (isto é, o SGSN para o qual o UE está a transferir, também denominado SGSN cessionário) é válido e se é referente ao UE identificado no pedido de transferência de contexto. A sinalização Salto-a-Salto entre os elementos da rede pode ser protegida por segurança no domínio de rede (NDS), para que nenhum estranho possa modificar os pacotes.

Os mecanismos de autenticação de pedidos de transferência de informações de contexto, num sistema de Projeto de Parceria de 3.a Geração Evoluído (3GPP), são diferentes dos utilizados em sistemas UMTS e GPRS legados.

Num sistema 3GPP evoluído (também conhecido como UTRAN Evoluído (E-UTRAN) ou Evolução de Longo Prazo (LTE)), que é discutido por exemplo, na Especificação Técnica 3GPP (TS) 23.401, a assinatura do P-TMSI não deverá ser utilizada.

Em vez disso, o estrato de não-acesso (NAS) - a associação de segurança do nível e as chaves e os valores correspondentes COUNT são geridos durante o modo IDLE. Toda a sinalização de nível NAS é autenticada, pela proteção da integridade, com as teclas NAS. Conforme descrito na TS 23.401 e tal como é conhecida na arte, a mobilidade do UE numa rede 3GPP evoluída é controlada por um elemento conhecido como uma Entidade de Gestão da Mobilidade (MME). As funções de uma MME podem incluir sinalização de NAS, Gestão de Mobilidade (MM), segurança de sinalização de NAS e autenticação. Durante a mobilidade de um MME antigo para um MME novo, a MME antiga autentica um pedido de transferência de contexto e de sinalização de mobilidade, 3 com base num atributo NAS (NAS-Token) calculado com uma chave de proteção da integridade.

Quando um UE se movimenta entre UMTS, Sistema Global para Comunicações Móveis (GSM) ou GPRS e um sistema 3GPP evoluído, a transferência de contexto e de sinalização de mobilidade deve ser ainda autenticada. No entanto, há um problema relacionado com a forma como um sistema 3GPP evoluído autoriza os pedidos de transferência de contexto ou de sinalização de mobilidade que vêm de um sistema UMTS / GPRS, o qual não fornece os mesmos mecanismos de autorização que o sistema 3GPP evoluído. Em particular, um nó de rede UMTS / GPRS cessionário (um nó para cujo domínio um UE está a transferir) espera por uma assinatura do P-TMSI de um UE (isto é, um terminal móvel ou outro dispositivo) . 0 nó UMTS / GPRS fornece em seguida essa assinatura do P-TMSI a uma entidade de rede homóloga (por exemplo, um SGSN a partir do qual o UE está a transferir) ao solicitar informações de contexto para esse UE. No entanto, o sistema 3GPP evoluído (EPS) não proporciona a manipulação da assinatura do P-TMSI. De facto, partes do elemento de informação (IE) que mantêm a assinatura do P-TMSI numa mensagem de sinalização num sistema UTRAN, podem ser utilizadas para uma finalidade diferente num sistema 3GPP evoluído. Por exemplo, alguns dos bits do IE podem ser necessários num sistema 3GPP evoluído, para manter partes do Sistema TMSI de Pacotes Evoluído (S-TMSI). Isto reduz os bits disponíveis para utilizar material de autenticação para autorização de transferência de contexto. Arquitetura 3GPP TSG SA GT2 - S2#58 documento intitulado: "Procedimento RAU MME / SGW para pré-Rel-8 SGSN" divulga um pedido de transferência de contexto entre duas entidades pertencentes rede em sistemas diferentes. Arquitetura 3GPP TSG SA WG2 -S2#58 documento intitulado: "Procedimento RAU MME/SGW para pre-Rel-8 SGSN" divulga um pedido de transferência de contexto entre duas entidades de rede pertencentes a 4

sistemas diferentes. RESUMO

Este resumo é realizado com o intuito de apresentar uma seleção de conceitos de uma forma simplificada, os quais são descritos abaixo de forma mais completa, na Descrição Detalhada. Este resumo não se destina a identificar as características chave ou características essenciais da invenção.

De acordo com pelo menos algumas incorporações, um equipamento de utilizador (UE) e uma MME num sistema 3GPP evoluído geram, cada um deles, material de autenticação. Esse material de autenticação pode ser transportado dentro do campo de assinatura do P-TMSI de uma mensagem de sinalização UMTS pode ser realizada dentro do campo de assinatura do P-TMSI de uma mensagem de sinalização UMTS do UE para o SGSN UMTS / GPRS quando o UE está a transferir para um sistema de UTRAN / GERAN. Este material de autenticação pode também ser comunicado a partir do SGSN UMTS / GPRS para o MME (do sistema 3GPP evoluído) a partir do qual o UE está a transferir. Nesta combinação, o MME antigo pode então autenticar o pedido de transferência de contexto do sistema 3GPP legado, com base no material de autenticação transferido e no conhecimento a respeito de como criar esse material de autenticação.

Em pelo menos algumas incorporações, o MME e o UE obtêm o material de autenticação com base em chaves especificas do utilizador. 0 material de autenticação, o qual pode ser obtido quando as chaves NAS são criadas ou pedidas, pode então ser incorporado no conteúdo do campo de assinatura do P-TMSI para sinalização do 3GPP legado, do UE e do UMTS / GPRS para a SGSN MME. No caso de uma ou mais teclas NAS serem utilizadas (ou se forem utilizadas chaves derivadas das teclas NAS), o material de autenticação gerado pode ser alterado sempre que as chaves NAS são alteradas. Desta forma, não necessita de ser transferido um 5 número de sequência dentro do campo de assinatura do P-TMSI, proporcionando assim maior segurança sob as pré-determinadas restrições de comprimento do campo de assinatura do P-TMSI reutilizado. Se as teclas NAS mudarem sempre que o UE se movimenta, por exemplo, de UTRAN para E-UTRAN, o material de autenticação também será renovado quando o UE regressar ao UTRAN.

Com as várias incorporações aqui descritas, não é necessário nenhum mecanismo semelhante a uma assinatura do P-TMSI para o sistema 3GPP evoluído, ou seja, não há necessidade de criar uma assinatura do P-TMSI no MME antes da receção de um pedido de autenticação de transferência de contexto. Não há necessidade também de transferir um atributo ou assinatura do MME para o UE. 0 UE pode gerar material de autenticação (por exemplo, um atributo) a pedido, evitando assim os requisitos de armazenamento para o atributo. Esse atributo pode ser transportado nas mensagens de sinalização UMTS existentes.

Estas e outras vantagens e características, juntamente com a organização e a forma de funcionamento do mesmo, tornar-se-ão óbvias após a descrição detalhada que se segue, quando verificada em conjunto com os desenhos que a acompanham, onde cada elemento é identificado por um número, nos diversos desenhos descritos abaixo.

DESCRIÇÃO BREVE DOS DESENHOS A Figura 1 é um diagrama de blocos de uma arquitetura de roaming para a interoperação entre as primeiras Normas comunicadas e as dos 3GPP evoluídos, de acordo com pelo menos algumas incorporações. A Figura 2 é um gráfico que demonstra a troca de sinais num procedimento de atualização da área de roteamento de MME para SGSN, de acordo com pelo menos algumas incorporações. A Figura 3 é uma vista em perspectiva de um dispositivo eletrónico que pode ser utilizado em conjunto 6 com uma implementação de pelo menos algumas incorporações. A Figura 4 é uma representação esquemática do circuito que pode ser incluído no dispositivo eletrónico da Figura 3. A Figura 5 é um diagrama de blocos do MME apresentado na Figura 2.

DESCRIÇÃO DETALHADA

Em pelo menos algumas incorporações, um equipamento de utilizador (UE) e uma Entidade de Gestão da Mobilidade (MME) num sistema 3GPP evoluído, geram cada uma material de autenticação (por exemplo, um atributo). 0 material de autenticação pode ser transportado dentro de um campo de assinatura do P-TMSI de uma mensagem de sinalização do UMTS legado, do UE para um SGSN UMTS / GPRS num UTRAN ou numa Rede de Acesso de Rádio GSM / Edge (GERAN) para a qual o UE está a transferir. Por exemplo, o UE pode não saber se está a transferir para o domínio de um 3GPP MME evoluído ou para o domínio de um SGSN num UTRAN ou GERAN legado e, assim, o UE poderá utilizar sinalização legada para uma RAU (atualização da área de roteamento) de sinalização UE-SGSN. 0 material de autenticação também pode ser utilizado numa mensagem de sinalização do SGSN UMTS / GPRS para o MME antigo do sistema 3GPP evoluído, a partir do qual o UE está a transferir. Nesta combinação, o UE cria o material de autenticação e fornece-o para o SGSN, com o SGSN em seguida a fornecer esse material de autenticação para o MME antigo num pedido de transferência de contexto. 0 MME antigo, com o conhecimento de como o material de autenticação foi criado no UE, poderá então recriar o material de autenticação após a recepção de um pedido de transferência de contexto, identificando o UE e autenticar o pedido de transferência de contexto.

Em algumas incorporações, o MME e o UE obtêm o material de autenticação com base em pelo menos uma chave específica do utilizador (por exemplo, K_ASME, K_NASInt ou 7 K_NASenc). 0 material de autenticação pode ser obtido quando as chaves estrato de não-acesso (NAS) são criadas ou a pedido. Se uma ou mais teclas NAS forem utilizadas (ou se uma ou mais chaves derivadas das teclas NAS forem utilizadas), o material de autenticação gerado pode ser alterado cada vez que as chaves NAS forem alteradas. Portanto, não necessita de ser transferido um número de sequência dentro do campo de assinatura do P-TMSI, que fornece segurança melhorada sob as pré-determinadas restrições de comprimento do campo de assinatura do P-TMSI reutilizado. Se as teclas NAS mudarem sempre que o UE se movimenta, por exemplo, de UTRAN para E-UTRAN, o material de autenticação também será renovado quando o UE regressar ao UTRAN. Se a chave especifica do utilizador de nivel mais alto for utilizada (por exemplo, K_ASME) o material de autenticação pode ser baseado no valor atual do número de sequência crescente existente, como o valor COUNT de sinalização do estrato de não-acesso (NAS) de ligação ascendente ou descendente. COUNT é um número de sequência crescente de pacotes. Os COUNTs são armazenados na memória. Um certo número de bits mais altos do valor de COUNT, podem ser armazenados na memória e só os bits remanescentes pode ser assinalados nas mensagens. Sempre que há sinalização de NAS, os valores de COUNT são atualizados e, portanto, o material de autenticação também será renovado.

Com várias incorporações aqui descritas, não é necessário nenhum mecanismo semelhante a uma assinatura do P-TMSI para o sistema 3GPP evoluído e não há necessidade de transferir uma assinatura do P-TMSI (qualquer outro tipo de atributo ou assinatura) do MME para o UE ou para criar o material de autenticação antes da receção de umo pedido de autenticação de um SGSN cessionário. 0 equipamento do utilizador também pode gerar um atributo a pedido, o que significa que não há requisitos de armazenamento para o atributo. Acresce que, com diversas incorporações, as 8 mensagens de sinalização UMTS atuais podem ser utilizadas para transportar o material de autenticação (por exemplo, o atributo). A Figura 1 é um diagrama de blocos de uma arquitetura de roaming para a interoperação entre as primeiras Normas comunicadas e as dos 3GPP evoluídos, de acordo com pelo menos algumas incorporações. Conforme ilustrado na Figura 1, o UE 100 interage com uma rede UTRAN Evoluída (E-UTRAN) 110, que por sua vez é comunicável com um servidor Gateway (SGW) 120 e um MME 130. Além de comunicar diretamente com o SGW 120, o MME 130 também é comunicável com um SGSN 140, o qual é conectado a um UTRAN 150 e a um 16 0 GERAN. Tanto o MME 130 como o SGSN 140 interagem também com um servidor subscritor central HSS 170. Tanto o SGSN 140 como o SGW 120 comunicam com uma rede de dados privada (PDN) Gateway (PGW) 180, que por sua vez comunica com uma função reguladora de carregamento de procedimentos (PCRF) 190 e os serviços de IP do próprio operador 195. A Figura 2 é um gráfico que demonstra a troca de sinais num procedimento de atualização da área de roteamento de MME para SGSN, de acordo com pelo menos algumas incorporações. Em certas incorporações, as mensagens de e para o SGSN, bem como os elementos de informação nele contida, são os mesmos, conforme especificado na Especificação Técnica (TS) 3GPP 23.060 para o procedimento de atualização da área de roteamento SGSN. As mensagens de e para o MME 130 ou para o SGW 120, bem como os elementos de informação nele contida, são as mesmas especificadas na presente especificação técnica para o procedimento de atualização da área de roteamento da inter-RAT (Tecnologia de Acesso de Rádio).

No que concerne à Figura 2, o procedimento de atualização da área de roteamento de MME para SGSN começa em 200, onde o UE 100 envia uma "solicitação de atualização da área de roteamento" para um novo SGSN 140. O pedido de 9 atualização da área de roteamento inclui informações como a identificação da área de roteamento (RAI) antiga, um atributo NAS (um código de autenticação do estrato de não-acesso, o qual é material de autenticação calculado pelo UE e que funciona como a "antiga" assinatura do P-TMSI), o tipo de atualização, a marca classificativa, os parâmetros de receção descontinua (DRX) e a informação da capacidade da rede do UE. 0 subsistema da estação do sistema base (BSS), acrescenta a identidade global da célula incluindo o Aglomerado de Computadores de Aplicação Real (RAC) e o código de área de localização (LAC) da célula onde a mensagem foi recebida antes de passar a mensagem para o novo SGSN 140. A marca classificativa contém as capacidades GPRS multislot do UE, assim como os algoritmos de encriptação GPRS suportados, conforme definido na TS 24.008. Os parâmetros de DRX indicam quando o UE utiliza ou não receção descontinua e, em caso afirmativo, a duração do ciclo DRX. O UE 100 indica uma das suas identidades de rastreamento de área registadas (TAIs) como a RAI antiga e calcula o atributo NAS como a assinatura do P-TMSI antiga, com base na K_NASInt (uma chave de integridade NAS especifica para um utilizador) ou na K_ASME (chave Entidade de Gestão de Segurança no Acesso, , uma chave de raiz armazenada no MME e no UE após uma autenticação bem sucedida) e o respectivo valor COUNT (e contador incremental) das ligações ascendentes ou descendentes do NAS.

Em 205, na Figura 2, o SGSN 140 novo envia um "pedido de contexto do SGSN" para o antigo MME 130, a fim de obter os contextos da gestão de mobilidade (MM) e do protocolo do pacote de dados (PDP) , para o UE. O pedido de contexto do SGSN inclui o antigo RAI, uma identidade de ligação lógica temporária (TLLI) e / ou o P-TMSI, a assinatura do P-TMSI antiga e o endereço SGSN novo. Como explicado abaixo, o MME 130 antigo pode então enviar uma "resposta de contexto do 10 SGSN" de volta pelo 210 para o SGSN 140 novo. O SGSN pode direcionar o contexto de SGSN pedido para o MME de diversas formas. Se o novo SGSN fornece a funcionalidade para a ligação intra-dominio de nós de rede de acesso de rádio (RAN) , a nós de rede de múltiplos núcleos (CN) , o novo SGSN pode derivar o MME antigo do RAI e do P-TMSI (ou TLLI ) antigos e enviar a mensagem de pedido de contexto do SGSN para este MME antigo. Caso contrário, o novo SGSN deriva o MME antigo do RAI antiga. O SGSN 140 novo deriva um MME que acredita ser o antigo MME 130. Este MME derivado é o próprio MME 130 antigo, ou está associado com a mesma área pool do MME antigo real. Um MME derivado que não seja o antigo MME, determina o correto MME 130 antigo do P-TMSI (ou TLLI) e retransmite a mensagem para o MME 130 antigo real.

Após a recepção do pedido de contexto do SGSN, o MME 130 antigo valida o valor da assinatura do P-TMSI antiga, que é o atributo NAS calculado pelo equipamento do utilizador, com base no K_ASME e nos respectivos valores COUNT da ligação descendente do NAS (que são conhecidos para o MME 130) . No caso em que o MME tem teclas K_ASME múltiplas identificadas com diferentes identificadores de conjuntos de chaves (KSIs), por exemplo, devido a um procedimento de Autenticação apenas-executar e Acordo Chave (AKA), o MME pode calcular o atributo de autenticação com todas as chaves disponíveis, para determinar se uma das chaves disponíveis é coincidente. O MME antigo pode também calcular e fornecer o atributo para o SGSN novo. No entanto, por razões de protecção de repetibilidade, se o valor de COUNT é utilizado como um parâmetro na geração de um atributo de autenticação, o mesmo é reutilizado, ou seja, ele aumenta. O KSI também pode ser transferido dentro do campo de assinatura do P-TMSI, em particular no caso da opção de assinatura do P-TMSI de comprimento variável. O valor COUNT pode não ser sincronizado entre o UE e o MME, 11 devido a perdas na mensagem de sinalização NAS, por conseguinte, o MME pode calcular o atributo de autenticação com um número de valores de COUNT dentro da gama do valor de COUNT atual (por exemplo, [COUNT de ligação descendente do NAS atual -L, COUNT de ligação descendente do NAS atual]).

Se a assinatura do P-TMSI antiga é válida, então o MME 130 antigo responde com a "resposta de contexto do SGSN." A mensagem de resposta de contexto do SGSN inclui informações como o contexto do MM, contextos do PDP, o serviço de roteamento da rede (NRS) e o contexto de segurança.

Se um valor calculado pelo MME 130 antigo com base no número de sequência do NAS recebido e os K_ ASME antigos armazenados não coincide com o atributo NAC recebido do SGSN, o MME 130 responde com uma causa de erro apropriada. Isso pode iniciar funções de segurança no SGSN 140 novo. Se essas funções de segurança no SGSN 140 autenticarem o UE 100 corretamente, então o SGSN 140 novo envia outra mensagem de pedido de contexto do SGSN (o RAI antigo, o TLLI, o equipamento / estação móvel do utilizador validado, endereço SGSN novo) ao MME 130 antigo indicando que o SGSN 140 novo autenticou o UE 100. Se o SGSN 140 novo indica que foi autenticado o UE 100, então o MME 130 antigo responde com a "resposta de contexto do SGSN" como descrito acima.

Ao enviar uma mensagem de resposta de contexto do SGSN, o MME 130 antigo armazena o endereço do SGSN 140 novo de modo a permitir à antiga estação base de rede de acesso de rádio terrestre universal (eNB), ao servidor Gateway (SGW) 120 ou outras entidades, transmitir pacotes de dados para o novo SGSN 140. O antigo MME 130 inicia de seguida um temporizador, cujo propósito é analisado abaixo. 0 Sistema de Pacotes Evoluído do MME (EPS) transporta informação para os contextos do PDP. É também determinado se e como realizar algum encaminhamento de dados de um eNB 155 ou do SGW 120 para o SGSN. 12

Ao receber a resposta de contexto do SGSN, o SGSN 140 novo ignora a capacidade de rede do EU 100 contida no contexto do MM da resposta de contexto do SGSN, apenas se o SGSN 140 recebeu anteriormente uma capacidade de rede do UE no pedido de atualização da área de roteamento. O serviço de roteamento de rede (NRS), na resposta de contexto do SGSN, indica o apoio do UE 100 ao controle do portador solicitado pela rede para o novo SGSN 140. O contexto de segurança na resposta de contexto do SGSN inclui o identificador do conjunto de chaves (KSI) e chave de encriptação (CK) / chave de integridade (IK) do UTRAN, derivadas da K_ASME (uma chave entidade gestora da segurança do acesso) . Podem também ser incluídos vetores de autenticação do UMTS. Os vetores de autenticação do E-UTRAN não são transferidos fora do E-UTRAN e, portanto, não são incluídos na resposta de contexto do SGSN.

Em 215, na Figura 2, podem ser executadas várias funções de segurança. Tais procedimentos são analisados, por exemplo, na "Função Segurança" da 3GPP TS 23.060. Se é suportado um modo de encriptação, o modo de encriptação é definido neste ponto. Se a mensagem de resposta de contexto do SGSN previamente transmitida em 210, não incluiu uma identificação do equipamento de estação móvel internacional e o número de versão do software (IMEISV) e se a deteção automática de dispositivos (ADD) é suportada pelo SGSN, então o SGSN pode também recuperar o IMEISV do UE 100 neste ponto. Se as funções de segurança falharem, por exemplo porque o SGSN não pode determinar o endereço do registo de localização central HLR para estabelecer o diálogo "Enviar Informações de Autenticação", é devolvida em seguida uma mensagem de rejeição ao equipamento do utilizador 100, mencionando a causa adequada.

Em 220, na Figura 2, o SGSN 140 novo envia uma mensagem "reconhecimento de contexto do SGSN" para o MME 130 antigo. Neste ponto, o MME 130 antigo marca na sua 13 informação de contexto, que as informações nas Gateways e no HSS 170 são inválidas. Este aciona o SGW 120, a Gateway PDN 180 e o HSS 170 para serem atualizados se o EU 100 iniciar um procedimento de atualização de rastreamento de área no MME 130 antigo antes de concluir o procedimento de atualização de roteamento de área em curso. Se as funções de segurança não autenticarem o UE 100 corretamente, então o pedido de atualização de roteamento de área é rejeitado e os novos SGSN 140 enviam uma indicação de rejeição para o MME 130 antigo. O MME 130 antigo iria então continuar como se o pedido de contexto do SGSN 205 nunca fosse recebido.

Se o UE 100 é autenticado corretamente, também é, no entanto, determinado se o MME 130 antigo é informado que o SGSN 140 novo está pronto para receber pacotes de dados pertencentes aos contextos do PDP ativado e de como realizar qualquer transmissão de dados a partir do eNB 155 ou do SGW 120 para o SGSN 140 novo. Se acontecer que o UE 100 está num estado LTE_Active no MME 130 antigo, então no 225 o MME 130 antigo envia uma mensagem "comando de transmissão de dados" para o eNB 155. O comando de transmissão de dados inclui informações como o portador de acesso por rádio (RAB_ID), o endereço da camada de transporte e a informação de associação de transporte Sl.

Em 230, na Figura 2, o eNB 155 antigo duplica as unidades de dados do protocolo de rede amortecida (N-PDUs) e começa a canalizá-los para o SGSN 140 novo. N-PDUs adicionais recebidos do SGW 120 antes do temporizador do MME 130 (descrito anteriormente) expirar, são também duplicados e canalizados para o SGSN 140 novo. Nenhum N-PDU é encaminhado para o SGSN 140 novo após a expiração do temporizador.

Em 235, o SGSN 140 novo envia um "atualizar pedido de contexto do PDP" ao PGW(s) 180 respectivo. 0 pedido de contexto do PDP atualizado inclui informações como o endereço do SGSN 140 novo, o Identificador do Termo do 14 Túnel (TEID), informações relativas à qualidade de serviço (QoS) negociada, a identidade da rede servidora, informação da interface da Gateway comum (CGI) / interface da área servidora (SAI), o tipo de RAT, uma indicação de apoio à mudança CGI / SAI / indicador de disponibilidade de recurso (RAI) e informações NRS. 0 SGSN 140 novo envia a identidade de rede servidora para o PGW 180. O NRS indica o apoio do SGSN ao controle do portador solicitado pela rede. O SGSN novo 140 indica que ele apoia o procedimento e, se assim for, indica que o UE 100 também o apoia na mensagem de resposta de contexto do SGSN 210 analisada anteriormente. Se o NRS não estiver incluido na mensagem de pedido de contexto do PDP atualizado 235, o PGW 180, após este procedimento, executa uma modificação de contexto do PDP GGSN-Iniciado para alterar o modo de controlo do portador (BCM) para 'MS-Only' para todos os PDP-Address / APN-pairs para os quais o BCM atual é 'NW_Only'. O PGW(s) 180 atualiza seus campos de contexto PDP e devolve uma "resposta de atualizar contexto do PDP" no 240. A resposta de atualizar contexto do PDP inclui informações como o TEID, informação de compressão de carga proibida, informações de restrição do Nome do Ponto de Acesso (APN) e informação respeitante a se é requerida uma alteração no relatório CGI / SAI / RAI. A informação de proibição de compressão de carga indica que o SGSN 140 deve a não compressão de dados para este contexto PDP.

Em 245, na Figura 2, o SGSN 140 novo informa o registo de localização central HLR no HSS 170 da mudança de SGSN através do envio da informação "atualizar localização". Esta informação pode incluir o número do SGSN, o endereço do SGSN, a identidade de subscritor móvel internacional (IMSI) e o IMEISV. O IMEISV é enviado se a função ADD é suportada.

Em 250, o HLR no HSS 170 envia uma instrução "cancelar 15 localização" para o MME 130 antigo. Esta mensagem pode incluir informações como o IMSI e o tipo de cancelamento. Nesta mensagem, o tipo de cancelamento é definida como "Atualizar Procedimento". Caso o temporizador do MME 130 descrito anteriormente não esteja a funcionar, então o MME 130 antigo remove os contextos do MM e do portador do EPS. Caso contrário, os contextos são removidos somente quando o temporizador expirar. O MME 130 antigo também garante que os contextos do MM e do PDP são mantidos no MME 130 antigo, para o caso do UE 100 iniciar outra atualização da área de roteamento inter-SGSN antes de concluir a atualização da área de roteamento em curso para o SGSN 140 novo. O MME 130 antigo reconhece a instrução cancelar localização 250 com um "cancelar localização reconhecido", incluindo o IMSI, em 255. Também é determinado se o MME 130 antigo ou o 155 eNB necessitam de completar qualquer transmissão de N-PDUs.

Em 260, o HLR no HSS 170 envia uma mensagem "inserir dados do subscritor" para o SGSN 140 novo. Esta mensagem inclui o IMSI e dados de subscrição GPRS. O SGSN 140 novo valida a presença do UE 100 na nova área de roteamento (RA) . Se devido a restrições de subscrição regional ou restrições de acesso, o UE 100 não é autorizado para ser anexado no RA, então o SGSN 140 novo rejeita o pedido de solicitação de atualização da área de roteamento com um fundamento adequado. O SGSN 140 novo também pode devolver uma mensagem "inserir dados do subscritor reconhecido" (incluindo a informação do IMSI e da "área restrita SGSN") para o HLR em 265. Se todas as verificações forem bem-sucedidas, então o SGSN constrói um contexto MM para o UE 100 e devolve uma mensagem "inserir dados do subscritor reconhecido" para o HLR (também representado em 265), com a mensagem, incluindo o IMSI. Em 270, na Figura 2, o HLR no HSS 170 reconhece a mensagem "atualizar localização" enviando uma mensagem "atualizar localização reconhecido" incluindo o IMSI, para o SGSN 140 novo. 16

Depois do acima referido, o SGSN 140 novo valida a presença do UE 100 no RA novo. Se devido às restrições de roaming ou restrições de acesso, o UE 100 não tiver permissão para ser anexado no SGSN 140 novo, ou se a verificação da subscrição falhar, então o SGSN 140 novo rejeita a atualização da área de roteamento com um fundamento adequado. Se todas as verificações forem bem-sucedidas, então o SGSN 140 novo constrói contextos de MM e PDP para o equipamento do utilizador. A ligação lógica é estabelecida entre o SGSN 140 novo e o UE 100. O SGSN 140 novo responde então ao UE 100 com uma mensagem "aceitar atualizar área de roteamento" em 275, incluindo um novo P-TMSI, uma nova assinatura P-TMSI e um número de receção do N-PDU. Também é determinado se e como os números de N-PDU são utilizados. Por exemplo, o número de receção do N-PDU inclui os reconhecimentos para cada identificador de pontos de acesso de serviço da camada de rede modo-reconhecimento (NSAPI) utilizados pelo UE 100, confirmando assim que todos os N-PDUs originados por dispositivos móveis são transferidos com sucesso antes do inicio do procedimento de atualização.

Em 280, na Figura 2, o UE reconhece o P-TMSI 100 novo devolvendo uma mensagem de "atualização da área de roteamento completa", incluindo o número de receção do N-PDU, para o SGSN 140 novo. Neste momento, o Controle de Ligação Lógica (LLC) e o protocolo de convergência dependente da sub-rede (SNDCP) no UE 100 são repostos. Mais uma vez, é também determinado se e como os números N-PDU são utilizados. Por exemplo, o número de receção do N-PDU contém os reconhecimentos para cada NSAPI modo-reconhecimento utilizado pelo UE 100, confirmando assim todos os N-PDUs dos recetores móveis são transferidos com sucesso antes do inicio do procedimento de atualização. Se o número de receção do N-PDU confirma a receção de N-PDUs que foram encaminhados a partir do MME 130 antigo, então 17 estes N-PDUs podem ser rejeitados pelo SGSN 140 novo. Quando o temporizador no MME 130 referido anteriormente expira, o MME 130 antigo liberta qualquer recurso eNB e SGW (não apresentado).

No caso de uma operação de atualização de área roteamento ser rejeitada devido à subscrição regional, restrições de roaming, restrições de acesso, ou porque o SGSN não pode determinar o endereço do HLR para estabelecer a comunicação de atualização de localização, então o SGSN 140 novo não constrói um contexto de MM. É devolvida à UE 100 uma mensagem de rejeição com a identificação da respectiva causa. A UE 100 não tenta uma nova atualização da área de roteamento para esse RA. 0 valor do RAI é apagado quando o UE 100 é ligado. Se o SGSN 140 novo não é capaz de atualizar o contexto do PDP numa ou mais PGWs 180, então o SGSN 140 novo desativa os contextos do PDP correspondente. No entanto, isto não deve causar que o SGSN rejeite a atualização da área de roteamento.

Os contextos do PDP são enviados do MME 130 antigo para o SGSN 140 novo, com uma ordem de prioridade, ou seja, o contexto do PDP mais importante é enviado em primeiro lugar na mensagem de resposta de contexto do SGSN. E necessário ter em atenção que o método de priorização exato a ser utilizado deve ser dependente da implementação. Em certas incorporações, no entanto, a priorização é baseada na atividade atual. O SGSN 140 novo determina a restrição máxima do APN com base na restrição do APN que recebeu de cada contexto do PDP da PGW 180 e, em seguida, armazena o novo valor máximo de restrição do APN.

Se o SGSN 140 novo não é capaz de suportar o mesmo número de contextos do PDP ativos, como recebidos do MME 130 antigo, então o SGSN 140 novo deve utilizar como entrada (input) a priorização enviada pelo MME 130 antigo, para decidir quais os contextos do PDP são para manter ativos e quais devem ser eliminados. Em qualquer situação, 18 o SGSN 140 novo atualiza primeiro todos os contextos numa ou mais PGWs 180 e, em seguida, desativa o(s) contexto (s) que não pode preservar. Isto não deve causar que o SGSN rejeite a atualização da área de roteamento.

Se o temporizador no MME 130 antigo, anteriormente descrito, expira e se não tiver sido recebida do HLR nenhuma mensagem de para cancelamento da localização (incluindo o IMSI), então o MME 130 antigo para a transferência de N-PDUs para o SGSN 140 novo. Se o procedimento de atualização da área de roteamento falhar um número máximo permitido de vezes, ou se o SGSN 140 devolve uma mensagem (Causa) de rejeição da atualização da área de roteamento, então o equipamento do utilizador entra num estado de inatividade IDLE. É também exibida na Figura 2 uma representação de diversas incorporações que utilizam Aplicações Customizadas para interação com Lógica Melhorada para Redes Móveis (CAMEL). Em Cl, na Figura 2, os procedimentos CAMEL_GPRS_PDP_Context_Disconnection, CAMEL_GPRS_Detach e CAMEL_PS_Notification são invocados no MME 130 antigo. Em particular, o procedimento CAMEL_GPRS_PDP_Context_Disconnection é chamado primeiro e é invocado várias vezes - uma vez por contexto do PDP. O procedimento devolve "Continue" como resultado. O procedimento CAMEL_GPRS_Detach é então chamado uma vez. Este procedimento também devolve "Continue" como resultado. Por fim, o procedimento CAMEL_PS_Notification é chamado uma vez. Mais uma vez, o procedimento devolve "Continue" como resultado.

Em C2, na Figura 2, os procedimentos CAMEL_GPRS_Routeing_Area_Update_Session e CAMEL_PS_Notification são chamados no SGSN 140 novo. Em particular, o procedimento CAMEL_GPRS_Routeing_Area_Update_Session é chamado primeiro. 0 procedimento devolve "Continue" como resultado. O 19 procedimento CAMEL_PS_Notification é então chamado, devolvendo também "Continue" como resultado. Em C3, na Figura 2, o procedimento CAMEL_GPRS_Routeing_Area_Update_Context é chamado várias vezes - uma vez por contexto do PDP - e devolve "Continue" como resultado.

Existem várias aproximações que podem ser utilizadas para gerar o material de autenticação que pode ser integrado no campo de assinatura do P-TMSI, de acordo com várias incorporações. Em cada incorporação aqui abordada, são utilizadas chaves de NAS ou chaves dai derivadas, embora o método para gerar as chaves precisamente possa variar. Portanto, deve-se entender que os métodos de geração de materiais de autenticação aqui descritos são de natureza meramente exemplificativa. Nas abordagens aqui debatidas, o MME 130 antigo não necessita de transferir de antemão o material de autenticação para o equipamento do utilizador, como é feito após a atribuição da assinatura do P-TMSI para transferências SGSN / UMTS (SGSN / GSM) . Isto porque, nas incorporações aqui discutidas, a informação de Autenticação é baseada em chaves específicas do utilizador. Isso permite a melhoria da segurança, uma vez que a transferência em ligação descendente de material de autenticação para o equipamento do utilizador pode ser evitada.

Numa incorporação particular, é calculado um atributo com base em chaves do NAS sobre algumas ou todas as partes da mensagem do UTRAN. Nesta combinação, os elementos da informação que são enviados para o SGSN 140, são encaminhados a partir do SGSN 140 novo para o MME 130 antigo, para que este possa calcular o atributo NAS com base na mensagem recebida (isto é, o código de autenticação com base no UE identificado na mensagem) . Numa variante deste método, o conteúdo sobre o qual o atributo NAS é calculado é pré-definido e a mensagem é recebida pelos 20 pontos do MME para os valores corretos (a identificação do equipamento do utilizador pelo P-TMSI). Neste caso, o número de sequência do NAS (SN) não é transferido no interior da assinatura do (P-)TMSI, mas pode ser utilizado como um parâmetro de entrada. Isto requer que o valor do nivel NAS SN também seja incluído no campo de assinatura do P-TMSI, para que o MME 130 possa formar o valor correto de COUNT como um parâmetro de entrada, para o cálculo do atributo NAS. 0 valor de COUNT é utilizado, como na protecção normal da mensagem do NAS, por razões de proteção da resposta.

As seguintes são duas variantes dos elementos de informação da assinatura do P-TMSI. A primeira variante é de um tamanho fixo, enquanto a segunda variante é de um tamanho variável. No caso do tamanho fixo do elemento de informação da assinatura do P-TMSI, o atributo NAS com o número sequencial do NAS é truncado para o comprimento fixo de, por exemplo, 24 bits (o tamanho do P-TMSI no elemento de informação de tamanho fixo) . No caso do elemento de informação da assinatura do P-TMSI de tamanho variável, pode ser utilizada a totalidade dos 32 bits (ou mais) do atributo NAS e número sequencial (por exemplo, 4 bits ou mais) . Pode ser implementado suporte para ambas as assinaturas do P-TMSI, de tamanho fixo e variável, no transporte da informação da autenticação da transferência e contexto dentro da mensagem de sinalização legada no interior do elemento de informação da assinatura do P-TMSI.

Em algumas incorporações, as chaves do NAS são utilizadas para criar um atributo para uma única vez, no equipamento do utilizador e no MME. Um exemplo de atributo de autenticação ou função de derivação da chave de autenticação é o seguinte: NAS_Token = KDF(K_NASint||K_NASenc||S-TMSI||"Atributo de autenticação de E-UTRAN para UTRAN") 21

No exemplo acima, KDF é uma função de derivação de chaves e K_NASint e K_NASenc são chaves de encriptação e integridade do NAS. 0 símbolo "1" denota concatenação, e a cadeia de texto dentro das aspas ("") é uma constante. Num caso alternativo, onde a mudança do S-TMSI é suficiente para atualizar o atributo de autenticação, a derivação é a seguinte: NAS_Token = KDF(K_ASME||S-TMSI||"Atributo de autenticação de E-UTRAN para UTRAN")

No exemplo acima, o S-TMSI é a ID temporária, utilizada no MME e o K_ASME é uma chave de raiz a partir da qual as chaves de NAS são derivadas. As chaves de NAS são como definidas na TS 33.abc. Ainda noutra alternativa, o valor de COUNT é também considerado um parâmetro de entrada, fazendo a função de derivação da seguinte forma: NAS_Token = KDF(K_NASint||K_NASenc||S-TMSI||COUNT|| "Atributo de autenticação de E-UTRAN para UTRAN") ou NAS_Token = KDF(K_ASME||S-TMSI||COUNT||"Atributo de autenticação de E-UTRAN para UTRAN")

Na forma mais simples nem o S-TMSI nem a cadeia de texto são necessários. Isto é ilustrado da seguinte forma: NAS_Token = KDF(K_ASME||COUNT)

Todas as derivações do atributo NAS podem ainda incluir um valor constante para diferenciar a derivação NAS_Token de outras derivações.

Segue-se uma discussão sobre o momento da criação do 22 atributo de autenticação descrito acima. A sincronização dos parâmetros de entrada para a criação do atributo no equipamento do utilizador e no MME pode ser realizada, numa incorporação especifica, definindo os pontos de sincronização. Em cada registo bem-sucedido no MME nesta incorporação, o atributo é recriado utilizando os parâmetros de entrada disponíveis e armazenados em ambos os terminais para reutilização. Alternativamente, a sincronização dos parâmetros de entrada para a criação de atributos no equipamento do utilizador e no MME, pode ser realizada contando com os parâmetros mais recentes disponíveis das chaves de NAS, S-TMSI, etc. e lidando com uma possibilidade de nova tentativa no caso dos parâmetros de entrada terem sido alterados. Por exemplo, uma atualização da chave do NAS com uma nova chave no EPS, logo após a entrega do pedido ao UTRAN, pode fazer com que o MME calcule um atributo diferente. Nesta combinação, o progresso de armazenamento de atributos é evitado.

Em incorporações do tipo das analisadas acima, se a autenticação da transferência de contexto falhar, o comportamento da sinalização / rede deve ser o mesmo. 0 elemento de informação da assinatura do P-TMSI definido pelo UMTS, tem apenas significado local para o SGSN que o gera o aloca ao equipamento do utilizador. No sistema 3GPP evoluído, tanto o equipamento do utilizador como o MME calculam o atributo de autenticação. Portanto, o MME não tem de fornecer uma assinatura semelhante para o equipamento do utilizador como no UTRAN, ou seja, não existe uma transferência da "assinatura do P-TMSI" para o equipamento do utilizador a partir do MME. 0 nível de segurança das abordagens descritas acima difere, dependendo da aplicação em causa. Geralmente, quanto maior o material de autenticação, melhor a proteção contra ataques de Negação de Serviço (DoS).

As Figuras 3 e 4 mostram um dispositivo móvel típico 23 12, que pode atuar como um equipamento de utilizador (UE) com o qual diversas incorporações podem ser implementadas. Os dispositivos descritos neste documento podem incluir qualquer e / ou todas as características descritas nas Figuras 3 e 4. No entanto, deve ser entendido que a presente invenção não se destina a ficar limitada a um determinado tipo de dispositivo eletrónico. 0 dispositivo móvel 12 das Figuras 3 e 4 inclui um alojamento 30, um ecrã 32 do tipo ecrã de cristais líquidos, um teclado 34, um microfone 36, um auricular 38, uma bateria 40, uma porta de infravermelhos 42, um antena 44, um cartão SC 46 do tipo Cartão de Circuito Integrado Universal (UICC) conforme uma incorporação, um leitor de cartões 48, um circuito de interface de rádio 52, um circuito de CODEC 54, um controlador 56 e uma memória 58. Os circuitos individuais e os elementos são todos de um tipo conhecido na arte, exceto os respeitantes a programação e / ou outras instruções necessárias para realizar os métodos e procedimentos aqui descritos. Em algumas incorporações, um dispositivo pode não incluir todos os componentes representados nas Figuras 3 e 4. Por exemplo, uma chave anti cópia ou outro componente periférico conetável a um computador portátil (por exemplo, através de uma ficha Bus Série Universal), ou outro dispositivo, podem incluir uma antena, um circuito de interface de rádio, um controlador e memória, mas pode faltar um monitor, teclado, microfone e / ou porta de infravermelhos.

Certas incorporações aqui abordadas são descritas no contexto geral das etapas do método ou processos, que podem ser implementadas numa incorporação por um produto de programa de computador, incorporadas em meios de armazenamento legíveis por computador, incluindo instruções executáveis por computador, como código de programa, executado por um ou mais computadores em ambientes de rede. Geralmente, os módulos do programa podem incluir rotinas, programas, objetos, componentes, estruturas de dados, etc. que executam tarefas específicas ou implementam determinados tipos de dados abstratos. As instruções executáveis por computador, estruturas de dados associados e módulos de programas, representam exemplos de código de programa para a execução de passos dos métodos divulgados neste documento. A sequência particular destas instruções executáveis, ou estruturas de dados associados representam exemplos de atos correspondentes para implementar as funções descritas nos passos ou processos.

Podem ser implementadas incorporações da presente invenção em software, hardware, lógica de aplicações ou uma combinação de hardware, software e lógica de aplicações. 0 software, a lógica de aplicações e / ou hardware podem residir num chipset (por exemplo, um ou mais circuitos integrados (ICs) ou circuitos integrados para aplicações especificas (ASICs)), um dispositivo móvel, um computador de secretária, um computador portátil, um servidor, uma chave anti cópia ou outros componentes periféricos, etc. A lógica de aplicações, software ou um conjunto de instruções são mantidos preferencialmente em qualquer um dos vários meios legíveis por computador convencionais. No contexto deste documento, um "meio legível em computador" pode ser qualquer meio ou meios que possam conter, armazenar, comunicar, propagar ou transportar as instruções para utilização por ou em conexão com um sistema de execução de instruções, aparelho ou dispositivo.

Podem ser realizadas implementações de software e internet de diversas incorporações com técnicas de programação padrão, com lógica baseada em regras e outra lógica para realizar diversas etapas ou processos de pesquisa de banco de dados, etapas ou processos de correlação, etapas ou processos de comparação e etapas ou processos de decisão. Deve-se ter em atenção que as palavras "componente" e "módulo", conforme utilizadas neste 25 documento, destinam-se a incluir implementações utilizando uma ou mais linhas de código de software, e / ou implementações de hardware, e / ou equipamentos para a receção de entradas manuais. A Figura 5 é um diagrama de blocos que apresenta detalhes adicionais do MME 130 da Figura 2. 0 MME 130 inclui um ou mais processadores 202 e uma ou mais memórias 204, as quais podem ser voláteis (por exemplo, memória de acesso aleatório (RAM)), não-voláteis (por exemplo, uma unidade de disco magnético) ou incluir ambos os componentes voláteis e não voláteis. O MME 130 pode ser um servidor autónomo ou outro elemento de rede, ou pode residir dentro de um elemento de rede que também realiza outras funções de rede. Entradas (inputs) e saidas (outputs) do MME 130 através das várias interfaces apresentadas (isto é, as interfaces Sl-MME, S10, Sll, S6a e Gn), bem como através de outras interfaces, podem ser separados por meios físicos. Alternativamente, as comunicações ao longo de múltiplas interfaces podem ser combinadas numa única conexão física (por exemplo, como pacotes separados numa única conexão física de rede IP) . O processador 202 recebe e envia comunicações sobre as várias interfaces representadas e comunica com a memória 204 para recuperar e armazenar dados, de modo a realizar as operações do MME aqui descritas. A descrição das incorporações feita anteriormente, tem sido apresentada para fins ilustrativos e de descrição. Esta descrição não pretende ser exaustiva ou limitar incorporações da presente invenção às formas particulares divulgadas, sendo possíveis modificações e variações à luz dos ensinamentos acima ou podendo estas ser alcançadas a partir da prática de várias incorporações. As incorporações aqui discutidas foram escolhidas e descritas, com o intuito de explicar os princípios e a natureza de várias incorporações e a sua aplicação prática, para permitir os 26 habilitados na arte utilizar a presente invenção em diferentes incorporações e com várias modificações, adequadas para o uso particular contemplado. As caracteristicas das incorporações aqui descritas podem ser combinadas em todas as combinações possíveis ou métodos, equipamentos, módulos, sistemas e produtos de programas de computador. 27

DOCUMENTOS REFERIDOS NA DESCRIÇÃO

Esta lista de documentos referidos pelo autor da presente solicitação de patente foi elaborada apenas para informação do leitor. Não é parte integrante do documento de patente europeia. Não obstante o cuidado na sua elaboração, o IEP não assume qualquer responsabilidade por eventuais erros ou omissões.

Documentos de patente referidos na descrição • US 98345007 P [0001]

Claims

1 REIVINDICAÇÕES 1. Um método que compreende: ao receber um pedido de transferência de contexto de uma primeira entidade de rede (140) numa segunda entidade de rede (130), o pedido de transferência de contexto incluindo um campo de informação contendo o material de autenticação correspondente a um dispositivo móvel (100); calculando o material de validação na segunda entidade de rede (130), onde o material de validação é calculado a partir de informações conhecidas pela segunda entidade de rede (130) para ser contida no dispositivo móvel (100) e no qual o material de validação não foi previamente transferido a partir da segunda entidade de rede (130) para o dispositivo móvel (100), e determinar se o material de validação corresponde ao material de autenticação. 2. 0 método da reivindicação 1, que compreende além disso: ao determinar que o material de validação corresponde ao material de autenticação, a autenticação do pedido de transferência de contexto e a informação de transferência de contexto para a primeira entidade de rede (140) .

3. O método da reivindicação 1, que compreende além disso: ao determinar que o material de validação não coincide com o material de autenticação, o envio de uma mensagem de erro para a primeira entidade de rede (140); subsequentemente a enviar a mensagem de erro, a receção de um segundo pedido de transferência de contexto da primeira entidade de rede (140), o segundo pedido de transferência de contexto indicando a autorização do dispositivo móvel (100), e em resposta ao segundo pedido de transferência de contexto, 2 a transferência de informações de contexto para a primeira entidade de rede (140).

4. O método de qualquer uma das reivindicações 1 a 3, em que o campo de informações compreende um campo de informações da assinatura do identificador de estação temporária móvel de rede de pacotes comutados. 5. 0 método de qualquer uma das reivindicações 1 a 4, onde o material de validação é derivado de pelo menos uma chave especifica do utilizador.

6. O método da reivindicação 5, onde pelo menos uma chave específica do utilizador é uma chave de entidade de gestão de segurança no acesso. 7. 0 método da reivindicação 5, onde pelo menos uma chave específica do utilizador é derivada de pelo menos uma chave estrato de não-acesso.

8. O método de reivindicação 5, onde pelo menos uma chave especifica do utilizador é derivada de pelo menos uma chave entidade de gestão de segurança no acesso.

9. O método de qualquer uma das reivindicações 1 a 8, onde o material de autenticação compreende um atributo de uma única vez, derivado de uma chave entidade de gestão de segurança no acesso.

10. Um meio de armazenamento legível em computador, para armazenar um programa de computador que inclui instruções, as quais quando executadas por uma causa do computador, o computador executa cada uma das etapas do método da reivindicação 1. 3 11. 0 meio legível em computador da reivindicação 10, compreendendo instruções para execução do método de acordo com qualquer uma das reivindicações 2 a 9.

12. Um aparelho que compreende: pelo menos um processador configurado para receber um pedido de transferência de contexto de uma primeira rede, o pedido de transferência de contexto, incluindo um campo de informação contendo material de autenticação correspondente a um dispositivo móvel (100), calcular o material de validação, onde o material de validação é calculado a partir de informações conhecidas pelo aparelho para ser contida no dispositivo móvel (100), e no qual o material a validação não foi transferida do aparelho para o dispositivo móvel (100), e determinar se o material de validação corresponde ao material de autenticação. 13. 0 aparelho da reivindicação 12, onde pelo menos um processador está configurado para executar o método de qualquer uma das reivindicações 2 a 9.

14. Um método que compreende: a operação de um dispositivo móvel (100) dentro de uma primeira rede sem fios; o cálculo de material de autenticação no dispositivo móvel (100) com base em informações compartilhadas com um elemento da primeira rede sem fios (130); a transmissão de uma atualização de área de roteamento a partir do dispositivo móvel numa segunda rede sem fios, onde a segunda rede sem fios é diferente da primeira rede sem fios e no qual o pedido de atualização de área de roteamento inclui um campo de informação contendo o material de autenticação; e receber no dispositivo móvel, como resultado da transmissão 4 do pedido de atualização da área de roteamento, uma aceitação da atualização da área de roteamento da segunda rede sem fios.

15. Um meio de armazenamento legível em computador, para armazenar um programa de computador que inclui instruções, as quais quando executadas por uma causa do computador, o computador executa cada uma das etapas do método da reivindicação 14.

16. Um aparelho compreendendo: pelo menos um processador configurado para operar o aparelho dentro de uma primeira rede sem fios; calcular material de autenticação com base em informações compartilhadas com um elemento da primeira rede sem fios (130); transmitir uma atualização de área de roteamento numa segunda rede sem fios, onde a segunda rede sem fios é diferente da primeira rede sem fios e na qual o pedido de atualização da área de roteamento inclui um campo de informação contendo o material de autenticação; e receber, como resultado da transmissão o pedido de atualização da área de roteamento, , uma aceitação da atualização da área de roteamento da segunda rede sem fios.