ES2253101A1 - Metodo de solicitud y envio de vectores de autenticacion. - Google Patents

Metodo de solicitud y envio de vectores de autenticacion.

Info

Publication number
ES2253101A1
ES2253101A1 ES200402226A ES200402226A ES2253101A1 ES 2253101 A1 ES2253101 A1 ES 2253101A1 ES 200402226 A ES200402226 A ES 200402226A ES 200402226 A ES200402226 A ES 200402226A ES 2253101 A1 ES2253101 A1 ES 2253101A1
Authority
ES
Spain
Prior art keywords
message
hss
hlr
impi
subscriber
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
ES200402226A
Other languages
English (en)
Other versions
ES2253101B1 (es
Inventor
Jose Carlos Sendra Alcina
Susana Ochoa Gimenez
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Vodafone Espana SA
Original Assignee
Vodafone Espana SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Vodafone Espana SA filed Critical Vodafone Espana SA
Priority to ES200402226A priority Critical patent/ES2253101B1/es
Publication of ES2253101A1 publication Critical patent/ES2253101A1/es
Application granted granted Critical
Publication of ES2253101B1 publication Critical patent/ES2253101B1/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H04L29/06027
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1101Session protocols
    • H04Q7/3846

Abstract

Método de solicitud y envío de vectores de autenticación.
Método de solicitud y envío de al menos un vector de autenticación (AV) entre un HSS (10) y al menos, un HLR (21, 21', 21''), estando dicho HSS conectado a, al menos, una red de telecomunicaciones IMS, y teniendo dicho HLR un centro de autenticación (22, 22', 22'') (AuC) configurado para generar AVs, que comprende los pasos de:
- recibir el HSS a través de la red IMS un primer mensaje solicitando, al menos un AV para autenticar a un abonado X que solicita un servicio IMS, estando dicho abonado identificado por su Identidad IMPI,
- procesar el HSS dicho primer mensaje y enviar un segundo mensaje al HLR,
- determinar el HLR si la solicitud de AV proviene de un servicio IMS o de un servicio GSM/GPRS o UMTS,
- generar dicho AuC el menos un AV con una clave asociada al abonado, siendo dicha clave una Ki asociada a la identidad IMPI si es un servicio IMS o una Ki' asociada a una Identidad IMSI si es un servicio GSM/GPRS o UMTS,
- generar el HLR un tercer mensaje que contiene dicho AV y enviarlo al HSS,
- procesar el HSS dicho tercer mensaje y enviar el HSS un cuarto mensaje que contiene dicho un AV a la red IMS.

Description

Método de solicitud y envío de vectores de autenticación.
Campo de la invención
La invención se engloba dentro del campo de las telecomunicaciones móviles, y más en concreto, en obtención de información de seguridad por parte de la red IMS.
Antecedentes de la invención
El HSS (Home Subscriber Server) es un equipo que almacena toda la información relativa al abonado que es necesaria para el correcto establecimiento de una conexión multimedia. Su planteamiento inicial es ser la evolución natural de los actuales HLR (Home Location Register), incorporando las funciones que éstos tienen actualmente y añadiendo las nuevas funcionalidades necesarias en el entorno de las llamadas multimedia. Estos nuevos datos que se deben provisionar incluyen básicamente los permisos del usuario en cuanto a los servicios multimedia suscritos y los perfiles de uso de esos servicios.
Desde este punto de vista inicial, parece que hay una clara separación entre funciones "antiguas", heredadas del HLR y que siguen siendo necesarias, y funciones "nuevas", exigidas por provisión de los nuevos servicios multi-
media.
Los estándares del 3GPP (Third Generation Partnership Program) definen los interfaces del HSS con el resto de elementos de red, así como las funciones que debe realizar según las peticiones que reciba de la red.
Se ha planteado la posibilidad de implementar el HSS definido en los estándares a partir de los HLRs ya existentes en las redes de los operadores móviles y añadiendo un único HSS que contenga la información no contemplada en los HLRs de los operadores. Esta visión es coherente con la percepción de separación nítida entre funciones "antiguas" y "nuevas" y permite un claro ahorro de costes en un entorno multi-operador o en un operador con varios HLRs.
Sin embargo, esta separación no es tan nítida en algunos procesos multimedia que requieren acceso a datos de autenticación del usuario. Estos datos de autenticación necesarios se generan en el AuC (Authentication Centre), el cual es una parte tradicionalmente asociada con los HLRs. Esto plantearía la necesidad de que en el contexto de un único proceso multimedia como, por ejemplo, el Registro del usuario, se tuviera que acceder inicialmente a una entidad, el HSS, cuando se requiera acceso a datos de provisión de servicios y posteriormente a otra entidad, el HLR/AuC, cuando se necesitan datos de autenticación. Este doble acceso es, hoy por hoy, imposible de implementar sin afrontar cambios en algunas partes de la arquitectura y/o protocolos implicados en el proceso
multimedia.
Por tanto, existe la necesidad de buscar una solución a este acceso, si los HLR/AuC están separados de la entidad HSS, sin que por ello se vean reducidas ni la seguridad de la red ni la funcionalidad del HSS.
A continuación se expone un glosario de términos que son utilizados a lo largo de la presente memoria descriptiva:
- AuC: Authentication Centre, Centro de Autenticación
- AV: Authentication Vector, Vector de Autenticación
- CS: Circuit Switching, Conmutación de Circuitos
- GSM: Global System for Mobile Communications, Sistema Global de Comunicaciones Móviles
- GPRS: General Packet Radio Service, Servicio de Paquetes con Acceso Radio
- HLR: Home Location Register, Registro Local de Localización del Usuario
- HSS: Home Subscriber Server, Registro Local de Subscripción del Usuario
- IMS: IP Multimedia Subsystem, Subsistema Multimedia
- IMSI: International Mobile Subscriber Identity, Identidad Internacional Móvil Usuario
- IMPI: IP Multimedia Private Identity, Identidad Privada Multimedia del Usuario
- IMPU: IP Multimedia Public Identity, Identidad Pública Multimedia del Usuario
- ISIM: IMS Subscriber Identity Module, Módulo de Identidad IMS del Usuario
- MAP: Mobile Application Protocol/Part, Protocolo de Aplicación Móvil
- MSC: Mobile Switching Centre, Centro de Conmutación Móvil
- PS: Packet Switching, Conmutación de Paquetes
- SAI: Send Authentication Info, Mensaje de Solicitud de Información de Autenticación
- S-CSCF: Serving Call Session Control Function, Servidor Controlador de la Sesión de Llamada
- SGSN: Serving GPRS Support Node, Nodo Soporte de la Comunicación GPRS
- USIM: UMTS Services Identity Module, Módulo de Identidad UMTS del Usuario.
Descripción de la invención
La invención se refiere a un método de solicitud y envío de al menos un vector de autenticación AV entre un Registro Local de Suscripción de Usuario HSS y al menos un Registro Local de Localización de Usuario HLR de acuerdo con la reivindicación 1. Realizaciones preferidas del método se definen en las reivindicaciones dependientes.
Para solventar el problema comentado en lo anterior de comunicación entre una entidad HSS y los elementos HLR/AuC heredados de las redes GSM/UMTS, la presente invención propone un método de comunicación entre un único HSS y el/los elemento/s HLR/AuC de uno o varios operadores.
Así, la presente invención se refiere a un método de solicitud y envío de, al menos un vector de autenticación AV entre un HSS y al menos, un HLR, estando dicho HSS conectado a, al menos, una red de telecomunicaciones IMS, y teniendo cada HLR un AuC configurado para generar vectores de autenticación AVs.
El método comprende los pasos de:
- recibir el HSS a través de la red IMS un primer mensaje solicitando, al menos un vector de autenticación AV para autenticar a un abonado X que solicita un servicio IMS, estando dicho abonado identificado por su Identidad Privada Multimedia de Usuario IMPI,
- procesar el HSS dicho primer mensaje y enviar un segundo mensaje al HLR,
- determinar el HLR en base a la información contenida en dicho segundo mensaje si la solicitud de AV proviene de un servicio IMS o de un servicio GSM/GPRS o UMTS,
- generar dicho AuC del HLR dicho al menos un vector de autenticación AV con una clave asociada al abonado, siendo dicha clave una clave Ki asociada a la identidad IMPI del abonado en caso de tratarse de un servicio IMS o una clave Ki' asociada a una identidad Pública Multimedia de Usuario IMSI del abonado en caso de tratarse de un servicio GSM/GPRS o UMTS,
- generar el HLR un tercer mensaje que contiene dicho al menos un vector de autenticación AV y enviarlo al HSS,
- procesar el HSS dicho tercer mensaje y enviar el HSS un cuarto mensaje que contiene dicho al menos un vector de autenticación AV a la red IMS.
La red de telecomunicaciones puede incluir dos o más HLRs conectados a un mismo HSS, y en tal caso, dicho HSS único está configurado para identificar a cuál de dichos dos o más HLRs debe solicitar la generación del al menos un vector de autenticación AV, en base a la información contenida en la identidad IMPI o IMSI asociada al abonado
X.
De acuerdo con una realización preferida, dichos primer y segundo mensajes son iguales entre sí y dichos tercer y cuarto mensajes son iguales entre sí y y el procesado en el HSS consiste en recibirlos y redirigirlos al HLR y a la red IMS respectivamente. Más preferiblemente, dichos primer, segundo, tercer y cuarto mensajes son mensajes en DIAMETER. En esta realización, el HLR es capaz de procesar el mensaje DIAMETER recibido, y obtener el IMPI y el número m de AVs requerido, pasándole estos parámetros al AuC para la generación del al menos un vector de autenticación AV.
De acuerdo con otro aspecto de la invención, el HLR es capaz de encapsular el al menos un AV generado por el AuC en un mensaje DIAMETER, para remitírselo al HSS que lo solicita.
De acuerdo con otra realización preferente,
- dicho primer mensaje es un mensaje DIAMETER y el HSS lo procesa generando dicho segundo mensaje que es un mensaje MAP,
- y dicho tercer mensaje es un mensaje MAP y el HSS lo procesa generando dicho cuarto mensaje que es un mensaje DIAMETER,
Para ello, preferiblemente se provisiona el HSS con información relativa a la identidad IMSI asociada a dicho abonado X y el HSS realiza un mapeado entre las identidades IMPI e IMSI. En este caso, dicho segundo mensaje puede incluir un campo "requesting node type" que puede tener el valor "2", lo que indica que la solicitud de vector de autenticación procede de un nodo, por ejemplo, un nodo S-CSCF de la red IMS. Para ello preferiblemente se provisiona el HLR con información relativa a la identidad IMPI asociada a dicho abonado X, y porque el HLR puede realizar un mapeado entre las identidades IMSI e IMPI, requerido si dicho campo "requesting node type" de dicho mensaje MAP, tiene el valor "2".
En este caso, el HSS tiene capacidad para "traducir" los mensajes de solicitud y recepción de AVs entre las red IMS y el HLR/AuC; esto implica:
\bullet
por un lado, un módulo que traslade correctamente los campos adecuados del mensaje DIAMETER al mensaje MAP, y viceversa, con el fin de generar los mensajes descritos en lo anterior; y
\bullet
por otro lado, obtener la identidad IMSI del abonado a partir de su identidad IMPI.
Además, el HSS es capaz de identificar a qué HLR/AuC remitir el mensaje MAP. Tanto mediante el IMSI como mediante el IMPI del abonado puede conocer a qué HLR/AuC pertenece el usuario.
Incrementando los valores posibles del parámetro "Requesting node type" se permite que la generación de AVs en el AuC se haga a partir de la clave Ki asociada a la identidad IMPI.
Sin este cambio, el HLR/AuC, seleccionaría la Ki asociada al IMSI del usuario, generando los AVs para los dominios GSM/GPRS, UMTS e IMS con la misma clave Ki, y obligando a que la tarjeta UICC del abonado tenga la misma clave Ki almacenada en los módulos USIM e ISIM.
Mediante la presente invención se permite la posibilidad de tener diferentes provisionamientos para USIM e ISIM para los datos de identificación de abonados (diferentes Ki y diferentes algoritmos para dominios CS/PS y dominios IMS).
Breve descripción de los dibujos
A continuación se pasa a describir de manera muy breve una serie de dibujos que ayudan a comprender mejor la invención y que se relacionan expresamente con una realización de dicha invención que se presenta como un ejemplo no limitativo de ésta.
La Figura 1 muestra un esquema de una primera posible realización para la presente invención, en la que se usa protocolo MAP entre el HSS y los HLR/AuC.
La Figura 2 muestra de forma esquematizada cómo se lleva a cabo el intercambio de mensajes entre HSS y HLR/AuC para la realización mostrada en la figura 1.
La Figura 3 muestra un esquema de una segunda posible realización para la presente invención, en la que se usa Protocolo DIAMETER entre HSS y HLR/AuC.
La Figura 4 muestra de forma esquematizada cómo se lleva a cabo el intercambio de mensajes entre HSS y HLR/AuC para la realización mostrada en la figura 3.
Descripción de una realización preferida de la invención
En la figura 1 se muestra un esquema de una posible realización para la presente invención, en la que se usa protocolo MAP entre el HSS (10) y los HLR/AuC (21/22, 21'122', 21''/22'').
En este caso prácticamente todas las consultas que la red IMS (1) pudiera realizar al HSS, serían resueltas directamente por el nodo HSS, excepto una: la solicitud y recepción de vectores de autenticación AVs, para la cual, el HSS tiene que remitir el mensaje hacia el HLR/AuC y después la respuesta del HLR/AuC hacia la red.
Este desvío de mensajes entre red IMS (en concreto, el nodo S-CSCF) y HLR/AuC y a través del HSS en este caso implica un cambio de protocolo y alguna modificación en los nodos HSS y HLR/AuC respecto a como están definidos en el estándar.
La solicitud y recepción de los vectores de autenticación AVs (o quintupletas de seguridad) se realiza mediante un intercambio de mensajes que se muestra de forma esquematizada en el diagrama de la figura 2.
La red IMS, a través del nodo S-CSCF envía al HSS único para uno o varios operadores (20, 20', 20'') una solicitud de vector de autenticación AV usando el protocolo DIAMETER, indicando el número m de AVs que solicita y para qué abonado, identificándolo con su identidad privada de IMS (IMPI) (mensaje "Cx-AV-Req").
El HLR/AuC estándar no entiende de DIAMETER. En sus interacciones con las redes GSM/GPRS y UMTS, cuando la red (ya sea la MSC o el SGSN) le solicita un número de AVs nuevos para un abonado, lo hace utilizando el protocolo MAP e identificando al abonado con su identidad IMSI.
Por tanto, este cambio lo hace el HSS para que el HLR/AuC entienda la solicitud y la lleve a cabo.
El mensaje en MAP ("MAP-SAI-Req") se llama "Send Authentication Info" SAI, y los parámetros que el HSS es capaz de mapear son:
\bullet
"Number of requested vectors"m: Obtenido del número de vectores que la red IMS solicita mediante su mensaje en DIAMETER.
\bullet
"IMSI": Necesita obtener el IMSI del abonado a partir de su IMPI.
\bullet
"Requesting node type": Con valor "2".
Este último punto implica una modificación al protocolo MAP estándar. En la norma TS29.002 del 3GPP (Releases 4 y 5), este parámetro del mensaje SAI incluye solamente dos opciones:
- “0” para indicar que la solicitud viene del nodo MSC (red GSM o dominio CS de la red UMTS).
- “1” para indicar que la solicitud viene del nodo SGSN (red GPRS o dominio PS de la red UMTS).
Esta realización de la invención añade el valor “2” para indicar que la solicitud viene del nodo S-CSCF (red IMS).
Ante la recepción del mensaje MAP "Send Authentication Info", el HLR/AuC sabe procesarlo y responder adecuadamente, según el estándar, salvo por el parámetro "Requesting node type". Cuando el HLR/AuC recibe un mensaje SAI con el valor “2” en el parámetro "Requesting node type" debe realizar el siguiente proceso:
\sqbullet Obtiene el IMSI del abonado del mensaje MAP.
\sqbullet Obtiene la identidad IMPI a partir del IMSI del abonado.
\sqbullet Selecciona la Ki asociada al IMPI obtenido.
\sqbullet Genera los AVs requeridos a partir de esa Ki.
El HLR devuelve al HSS un mensaje ("MAP-SAI-Res") con los AVs generados por el centro de autenticación AuC, y el HSS realiza un cambio a DIAMETER y envía el mensaje ("Cx-AV-Req-Resp") con la identidad IMPI y los AVs generados a la red IMS.
En la figura 3 se muestra un esquema de otra posible realización para la presente invención, en la que se usa protocolo DIAMETER entre el HSS (10) y los HLR/AuC (21/22, 21'/22', 21''/22'').
En este caso también prácticamente todas las consultas que la red IMS pudiera realizar al HSS serían resueltas directamente por el nodo HSS excepto una: la solicitud y recepción de AVs, para la cual, el HSS tiene que remitir el mensaje hacia el HLR/AuC y después la respuesta del HLR/AuC hacia la red.
Este desvío de mensajes entre red IMS (S-CSCF) y HLR/AuC y a través del HSS en este escenario, implica que los nodos HLR/AuC tienen que ser capaces de procesar mensajes DIAMETER.
La red IMS, a través del nodo S-CSCF envía al HSS una solicitud de AVs usando el protocolo DIAMETER, indicando el número de AVs que solicita y para qué abonado, identificándolo con su identidad privada de IMS (IMPI). El HSS reenvía ese mensaje DIAMETER directamente al HLR/AuC adecuado.
En este escenario, el HLR/AuC debe saber procesar el mensaje DIAMETER que le solicita AVs y ser capaz de enviarle los AVs generados también mediante DIAMETER.
La solicitud y recepción de los vectores de autenticación AVs (o quintupletas de seguridad) se realiza mediante un intercambio de mensajes que se muestra de forma esquematizada en el diagrama de la figura 4.
Ante la recepción del mensaje DIAMETER "Cx-AV-Req" el HSS es capaz de reenviarlo al HLR/AuC del abonado. Para ello, es capaz de identificar con el IMPI del abonado la dirección del HLR/AuC en el que dicho abonado está subscrito.
Ante la recepción del mensaje DIAMETER "Cx-AV-Req" el HLR debe ser capaz de procesar el mensaje y obtener el IMPI del abonado y el número de AVs requerido, para pasarle esa información al AuC. Así, el AuC genera el número de AVs solicitado, a partir de la clave Ki asociada a esa identidad IMPI y los devuelve al HLR.
Una vez generados los AVs, el HLR es capaz de encapsularlos en un mensaje DIAMETER "Cx-AV-Req-Resp" para enviárselos al HSS, quien a su vez los remite a la red IMS que los ha solicitado.

Claims (10)

  1. \global\parskip0.920000\baselineskip
    1. Método de solicitud y envío de al menos un vector de autenticación (AV) entre un Registro Local de Suscripción de Usuario (10) (HSS) y al menos, un Registro Local de Localización de Usuario (21, 21', 21'') (HLR), estando dicho HSS conectado a, al menos, una red de telecomunicaciones con Subsistema Multimedia IP (IMS), y teniendo dicho HLR un centro de autenticación (22, 22', 22'') (AuC) configurado para generar vectores de autenticación (AVs),
    caracterizado porque el método comprende los pasos de:
    - recibir el HSS a través de la red IMS un primer mensaje solicitando, al menos un vector de autenticación (AV) para autenticar a un abonado X que solicita un servicio IMS, estando dicho abonado identificado por su Identidad Privada Multimedia de Usuario (IMPI),
    - procesar el HSS dicho primer mensaje y enviar un segundo mensaje al HLR,
    - determinar el HLR en base a la información contenida en dicho segundo mensaje si la solicitud de AV proviene de un servicio IMS o de un servicio GSM/GPRS o UMTS,
    - generar dicho AuC del HLR dicho al menos un vector de autenticación AV con una clave asociada al abonado, siendo dicha clave una clave Ki asociada a la identidad IMPI del abonado en caso de tratarse de un servicio IMS o una clave Ki' asociada a una Identidad Pública Multimedia de Usuario (IMSI) del abonado en caso de tratarse de un servicio GSM/GPRS o UMTS,
    - generar el HLR un tercer mensaje que contiene dicho al menos un vector de autenticación AV y enviarlo al HSS,
    - procesar el HSS dicho tercer mensaje y enviar el HSS un cuarto mensaje que contiene dicho al menos un vector de autenticación AV a la red IMS.
  2. 2. Método según la reivindicación 1, caracterizado porque dichos primer y segundo mensajes son iguales entre sí y dichos tercer y cuarto mensajes son iguales entre sí y el procesado en el HSS consiste en recibirlos y redirigirlos al HLR y a la red IMS respectivamente.
  3. 3. Método según la reivindicación 2, caracterizado porque dichos primer, segundo, tercer y cuarto mensajes son mensajes en DIAMETER.
  4. 4. Método según la reivindicación 3, caracterizado porque el HLR es capaz de procesar el mensaje DIAMETER recibido, y obtener el IMPI y el número m de AVs requerido, pasándole estos parámetros al AuC para la generación del al menos un vector de autenticación AV.
  5. 5. Método según cualquiera de las reivindicaciones 2-4, caracterizado porque el HLR es capaz de encapsular el al menos un AV generado por el AuC en un mensaje DIAMETER, para remitírselo al HSS que lo solicita.
  6. 6. Método según la reivindicación 1, caracterizado porque
    - dicho primer mensaje es un mensaje DIAMETER y el HSS lo procesa generando dicho segundo mensaje que es un mensaje MAP,
    - y porque dicho tercer mensaje es un mensaje MAP y el HSS lo procesa generando dicho cuarto mensaje que es un mensaje DIAMETER,
  7. 7. Método según la reivindicación 6, caracterizado por la provisión en el HSS con información relativa a la identidad IMSI asociada a dicho abonado X y el HSS realiza un mapeado entre las identidades IMPI e IMSI.
  8. 8. Método según cualquiera de las reivindicaciones 6-7, caracterizado porque
    - dicho segundo mensaje incluye un campo "requesting node type" que puede tener el valor “2” lo que indica que la solicitud de vector de autenticación procede de un nodo de la red IMS.
  9. 9. Método según la reivindicación 8, caracterizado por la provisión en HLR con información relativa a la identidad IMPI asociada a dicho abonado X, y porque el HLR puede realizar un mapeado entre las identidades IMSI e IMPI, requerido si dicho campo "requesting node type" de dicho mensaje MAP, tiene el valor "2".
  10. 10. Método según cualquiera de las reivindicaciones anteriores, caracterizado porque
    - la red de telecomunicaciones incluye dos o más HLRs conectados a un mismo HSS, y
    - dicho HSS está configurado para identificar a cuál de dichas dos o más HLRs debe solicitar la generación de al menos un vector de autenticación AV, en base a la información contenida en la identidad IMPI o IMSI asociada al abonado X.
ES200402226A 2004-09-17 2004-09-17 Metodo de solicitud y envio de vectores de autenticacion. Active ES2253101B1 (es)

Priority Applications (1)

Application Number Priority Date Filing Date Title
ES200402226A ES2253101B1 (es) 2004-09-17 2004-09-17 Metodo de solicitud y envio de vectores de autenticacion.

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
ES200402226A ES2253101B1 (es) 2004-09-17 2004-09-17 Metodo de solicitud y envio de vectores de autenticacion.

Publications (2)

Publication Number Publication Date
ES2253101A1 true ES2253101A1 (es) 2006-05-16
ES2253101B1 ES2253101B1 (es) 2007-07-16

Family

ID=36441073

Family Applications (1)

Application Number Title Priority Date Filing Date
ES200402226A Active ES2253101B1 (es) 2004-09-17 2004-09-17 Metodo de solicitud y envio de vectores de autenticacion.

Country Status (1)

Country Link
ES (1) ES2253101B1 (es)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1798896A1 (en) * 2005-05-31 2007-06-20 Huawei Technologies Co., Ltd. Method for im domain authentication for the terminal user identifier module

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9071620B2 (en) 2007-11-13 2015-06-30 Starhome Gmbh Method and system for enabling communication in a hybrid network

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6243581B1 (en) * 1998-12-11 2001-06-05 Nortel Networks Limited Method and system for seamless roaming between wireless communication networks with a mobile terminal
WO2002082296A1 (en) * 2001-04-07 2002-10-17 Secure Data In Motion, Inc. Federated authentication service
EP1414212A1 (en) * 2002-10-22 2004-04-28 Telefonaktiebolaget L M Ericsson (Publ) Method and system for authenticating users in a telecommunication system

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6243581B1 (en) * 1998-12-11 2001-06-05 Nortel Networks Limited Method and system for seamless roaming between wireless communication networks with a mobile terminal
WO2002082296A1 (en) * 2001-04-07 2002-10-17 Secure Data In Motion, Inc. Federated authentication service
EP1414212A1 (en) * 2002-10-22 2004-04-28 Telefonaktiebolaget L M Ericsson (Publ) Method and system for authenticating users in a telecommunication system

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
HARN et al: "On the Security of Wireless Network Access with Enhancements". Proceedings of Wise'03. Septiembre 2003; paginas 88-94. *
HARN et al: "On the Security of Wireless Network Access with Enhancements". Proceedings of Wise'03. Septiembre 2003; páginas 88-94. *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1798896A1 (en) * 2005-05-31 2007-06-20 Huawei Technologies Co., Ltd. Method for im domain authentication for the terminal user identifier module
EP1798896A4 (en) * 2005-05-31 2007-12-12 Huawei Tech Co Ltd METHOD FOR IM DOMAIN AUTHENTICATION FOR TERMINAL USER IDENTIFICATION MODULE
US8027666B2 (en) 2005-05-31 2011-09-27 Huawei Technologies Co., Ltd. Method and system for authenticating terminal subscriber identity module in IP multimedia domain

Also Published As

Publication number Publication date
ES2253101B1 (es) 2007-07-16

Similar Documents

Publication Publication Date Title
US11844014B2 (en) Service authorization for indirect communication in a communication system
US10993161B2 (en) Authenticating user equipments through relay user equipments
ES2931775T3 (es) Selección de instancia de función de red
CN113661696B (zh) 用于处理可伸缩fqdn的系统和方法
ES2645270T3 (es) Aparato y método para autenticar a un usuario cuando accede a servicios multimedia
EP2617210A1 (en) Method for context establishment in telecommunication networks
EP3662691A1 (en) Interfaces for privacy management as service or function
CN116017424A (zh) 用于控制认证请求的隐私指示符
EP1798910B1 (en) Method of requesting and sending authentification vectors
EP3622738A1 (en) Indicator for determination of key for processing message in communication system
WO2021094349A1 (en) Multi-step service authorization for indirect communication in a communication system
ES2603382T3 (es) Interfuncionamiento entre una red inteligente y un HLR/HSS
ES2821833T3 (es) Método para establecer una conexión de un terminal móvil a una red móvil de comunicación por radio y componente de red de acceso por radio
US11032699B2 (en) Privacy protection capabilities
EP3241374B1 (en) Method for accessing a roaming device and corresponding proxy network
ES2253101B1 (es) Metodo de solicitud y envio de vectores de autenticacion.
RU2738801C1 (ru) Способы и узлы для обработки подключения к сети передачи данных 5g
ES2246480T3 (es) Sistema de obtencion de servicios de valor añadido en tiempo real basandose en la red de servicio general de paquetes radio gprs.
CA2896067A1 (en) Mobile communication system, mobile station, switching station, and location registration method for mobile station
JP7277062B2 (ja) セッション管理機能選択のための方法および装置
US20240007983A1 (en) Method, device, and system for core network device re-allocation in wireless network
US20230370992A1 (en) Method, device, and system for core network device re-allocation in wireless network
WO2013127117A1 (zh) Mtc设备的漫游通信方法和系统

Legal Events

Date Code Title Description
EC2A Search report published

Date of ref document: 20060516

Kind code of ref document: A1

FG2A Definitive protection

Ref document number: 2253101B1

Country of ref document: ES