ES2427965T3 - Método y aparato para recuperar entre redes datos relativos al usuario - Google Patents

Método y aparato para recuperar entre redes datos relativos al usuario Download PDF

Info

Publication number
ES2427965T3
ES2427965T3 ES06126541T ES06126541T ES2427965T3 ES 2427965 T3 ES2427965 T3 ES 2427965T3 ES 06126541 T ES06126541 T ES 06126541T ES 06126541 T ES06126541 T ES 06126541T ES 2427965 T3 ES2427965 T3 ES 2427965T3
Authority
ES
Spain
Prior art keywords
data
gup
domain
server
request
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.)
Active
Application number
ES06126541T
Other languages
English (en)
Inventor
John Michael Walker
Jorge Hernández Vázquez
Zdravko Jukic
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.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
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 Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Application granted granted Critical
Publication of ES2427965T3 publication Critical patent/ES2427965T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/08—Mobility data transfer
    • H04W8/12—Mobility data transfer between location registers or mobility servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4588—Network directories; Name-to-address mapping containing mobile subscriber information, e.g. home subscriber server [HSS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H04L67/306—User profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4552—Lookup mechanisms between a plurality of directories; Synchronisation of directories, e.g. metadirectories

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Un método para recuperar los datos relativos a un abonado, realizado por un primer Perfil Genérico de Usuario,GUP, servidor en una red de comunicaciones (100) que tiene un primer y un segundo dominio de comunicaciones,comprendiendo dicho método las etapas de: - recibir (808) una petición de entrada de datos relativos a un abonado de un cliente de datos (102) en elprimer dominio de comunicaciones (101); - determinar (812) que al menos una parte de los datos seencuentra en el segundo dominio de comunicaciones (109); - transmitir (816) una petición de salida a un segundo servidor GUP en el segundo dominio decomunicaciones para al menos parte de los datos; - recibir (822) una respuesta de el segundo servidor GUP que contiene al menos parte de los datossolicitados; - remitir (824) los datos solicitados al cliente de datoscaracterizado porque: - antes de la etapa de determinación, realiza las etapas adicionales de: (i) suscribir las notificaciones sobre los cambios de identificación del segundo dominio decomunicaciones (800); (ii) recibir tales notificaciones sobre los cambios (802, 806); (iii) almacenar tales notificaciones sobre los cambios (803, 807); (iv) comprobar si una porción de la petición de datos es errante (810, 1020) y - la etapa de determinación incluye el uso de tales notificaciones almacenadas para establecer unadirección al segundo servidor GUP (814).

Description

Método y aparato para recuperar entre redes datos relativos al usuario
Campo de la invención
La presente invención se refiere al manejo de los datos relativos de abonado en una red de comunicaciones y más particularmente a un método y a un aparato para recuperar entre redes los datos relativos a un abonado.
Antecedentes
El objetivo de la especificación Perfil Genérico de Usuario (GUP) 3GPP es proporcionar un medio que permita el uso armonizado de la información relacionada con el usuario, originada desde diferentes entidades.
El Perfil Genérico de Usuario 3GPP es la recopilación de los datos relacionados con el Usuario que afecta a la forma en que un usuario individual aprecia los servicios en los que una comunidad de entidades comparte estos datos. El Perfil Genérico de Usuario 3GPP se puede almacenar en el entorno de la red doméstica y/o en el equipo del Proveedor de Servicios de Valor Añadido.
En un escenario GUP existen los siguientes roles: los Servidores GUP 3GPP que están desplegados por los Operadores, los usuarios finales que tienen un servidor GUP asociado a su perfil y los Clientes de Datos (por ejemplo, las aplicaciones) que necesitan manejar/utilizar los perfiles del usuario final que contactan con los Servidores GUP 3GPP.
El GUP 3GPP define dos interfaces, denominados Rg y Rp, donde el primero es el único que va a ser utilizado por los Clientes de Datos (por ejemplo, las aplicaciones), mientras que el segundo es un interfaz dentro de los operadores que va a ser utilizado por los Servidores GUP hacia los Depósitos de Datos. Ambos interfaces se basan en el protocolo DST Alianza en Libertad, véase "Liberty IDWSF Data Services Template Specification", Proyecto de Alianza en Libertad, http://www.projectliberty.org/specs/liberty-IDWSF-dst-v2.0.pdf.
La información que va a manejar los Servidores GUP 3GPP (modelo de datos lógicos) no se especifica actualmente, excepto una porción menor con respecto a los datos IMS dentro del nodo HSS.
Potencialmente cualquier dato del usuario final (estático y dinámico) que podría ser de interés para los clientes de datos podría ser decidido por los operadores, haciéndolo disponible a través de servidores GUP 3GPP.
El Perfil Genérico de Usuario (GUP) 3GPP se describe además en 3GPP TS 22.240 v6.5.0, " Perfil Genérico de Usuario (GUP) 3GPP; Etapa 1 (Publicación 6)" http://www.3gpp.org/ftp/Specs/htm1-info/22240.htm.
El GUP ayudará a superar algunos de los desafíos asociados con la introducción de sofisticados terminales de usuario con capacidades que varían ampliamente, combinaciones híbridas de dominios de la red móvil, la llegada de aplicaciones descargables y el deseo de los usuarios de personalizar los servicios potencialmente complejos según las preferencias y necesidades individuales.
Un ejemplo de componente GUP es una representación física de un componente GUP. Los ejemplos de los componentes pueden estar situados en la Red Doméstica, en el Entorno del Proveedor de Servicios de Valor Añadido y/o en el Equipo de Usuario.
El Perfil Genérico de Usuario 3GPP permite el uso dentro de la red (es decir, el intercambio de datos entre aplicaciones dentro de la red de un operador de telefonía móvil) y el uso entre redes (entre la red del operador móvil y los proveedores de servicios de valor añadido). Los Operadores Móviles Virtuales MVNO:s y las redes visitadas son tratadas como proveedores de servicio de valor añadido en términos de intercambios de datos GUP con la red del operador móvil.
Para cada usuario existe un Perfil de Usuario, que puede constar de diversos "componentes". Estos componentes pueden estar distribuidos en la red doméstica y en el entorno del proveedor de servicios de valor añadido. Los datos GUP 3GPP se distribuyen por su índole y se almacenan en consecuencia en la red doméstica y en el Equipo del Proveedor del Servicio de Valor Añadido. El documento WO-2006/066145 describe que en un servidor de perfil abstracto (APS), una vez generada una CSCF, se recibe la consulta relativa al abonado, se recoge la información del abonado en relación con la CSCF generada, se consulta en relación con el abonado de al menos una base de datos de información del abonado, usando un protocolo nativo de la base de datos de información del abonado, un mensaje de respuesta a la CSCF generada, se genera la consulta relativa al abonado basándose en la información recogida y se remite el mensaje de respuesta a una CSCF respectiva que generó la consulta relativa al abonado generada, siendo el mensaje de respuesta acorde con el protocolo de perfil abstracto.
Existe el problema de que los datos GUP3 GPP se distribuyen potencialmente en aquellos casos en los que un usuario final es un abonado a o en tránsito en una red diferente. En esta situación un servidor GUP sólo puede proporcionar datos estáticos y dinámicos que se almacenan en su propia red.
En un escenario de tránsito los clientes de datos (aplicaciones) situados en la PLMN-Doméstica (en adelante HPLMN), y dispuestos a manejar datos dinámicos del usuario final en tránsito, siempre contactarán con el servidor GUP que albergue los datos para ese usuario final. En este escenario sucede que algunas partes del perfil del usuario final sólo pueden ser recuperadas poniéndose en contacto con la PLMN visitada (en adelante VPLMN).
En tales casos los clientes de Datos (aplicaciones) podrían consultar al servidor GUP en la HPLMN (es decir, la única con la que la aplicación ha establecido una relación comercial) por estos datos, pero al servidor GUP no se le permite consultar depósitos de datos (por ejemplo, VLR o SGSN en VPLMN) en una red diferente (Rp, un interfaz entre operadores requiere altos niveles de confianza).
Por lo tanto, no existen soluciones sobre cómo acceder a los datos relativos a un perfil de usuario residentes en otro dominio diferente del servidor GUP del cliente de datos, de forma segura y eficiente.
Resumen de la invención
La presente invención se refiere al problema de proporcionar un aparato y un método mejorados para recuperar datos relativos al abonado en una red de comunicaciones evitando los inconvenientes mencionados anteriormente de la falta de soluciones sobre cómo acceder a los datos relativos al perfil del usuario residente en otro dominio diferente del servidor GUP de un cliente de datos, de una manera segura y eficiente.
Este problema se resuelve mediante un método y un aparato para recuperar datos relativos al abonado en la red de comunicaciones en la que un primer servidor GUP recibe una petición de entrada de los datos relativos a un abonado de un cliente de datos en un primer dominio de comunicaciones y determina que al menos una parte de los datos se encuentra en un segundo dominio de comunicaciones. Se transmite entonces una petición de salida para parte al menos de los datos a un segundo servidor GUP en el segundo dominio de comunicaciones. El segundo servidor GUP recupera entonces los datos relativos al abonado solicitados de al menos un depósito de la red y transmite una respuesta con los datos solicitados al primer servidor GUP. El primer servidor GUP recibe la respuesta del segundo servidor GUP que contiene al menos parte de los datos solicitados y envía los datos solicitados al cliente de datos.
El propósito de la invención es habilitar el acceso al servicio a los datos del abonado situado en otros dominios diferentes de los del Servidor GUP asociado con el cliente de datos, por ejemplo en caso de tránsito.
Una ventaja de la invención es que es posible recuperar partes del perfil de usuario de un usuario final en tránsito en aquellos casos en los que partes relevantes de tal perfil están distribuidas en el dominio doméstico, es decir, en el primer dominio de comunicaciones, y en el dominio visitado, es decir en el segundo dominio de comunicaciones.
También es una ventaja que es posible recuperar partes del perfil de usuario de un usuario final en aquellos casos en los que se distribuyen porciones relevantes de tal perfil en el dominio doméstico y en el dominio visitado de un usuario final que no está abonado al dominio de comunicaciones del GUP del cliente de datos.
Otra ventaja de la invención es que permite el intercambio de información entre servidores GUP proporcionando los mecanismos de confianza relevantes necesarios para tal comunicación.
La invención reutiliza los acuerdos de interconexión de tránsito existentes entre el dominio doméstico y el dominio visitado (es decir, los operadores) y elimina la necesidad de que los clientes de datos tengan que establecer relaciones comerciales con múltiples proveedores de datos de usuario GUP (es decir, los operadores con una infraestructura de servidores GUP).
En una realización la transmisión de la petición de salida al, y la recepción de la respuesta del, segundo servidor GUP tiene lugar en un interfaz de inter funcionamiento del servidor GUP.
Esto tiene la ventaja de proporcionar un servidor GUP más sencillo que no tiene que hacer un seguimiento del estado de las peticiones.
Se describirán ahora con más detalle las realizaciones preferidas de la invención con referencia a los dibujos adjuntos.
Breve descripción de los dibujos
La figura 1a es un diagrama de bloques que muestra una arquitectura de referencia GUP según la técnica anterior. La figura 1b es un esquema de red que muestra los casos en los que la invención es útil.
La figura 1c es un diagrama de bloques que muestra una arquitectura de referencia GUP para un inter funcionamiento del servidor GUP de acuerdo con la invención.
La figura 2 es un diagrama de la secuencia del mensaje que muestra un método de acuerdo con una primera realización de la invención.
La figura 3 es un diagrama de flujo que muestra una realización de un Servidor GUP Doméstico.
La figura 4 es un diagrama de flujo que muestra una realización de un Servidor GUP visitado.
La figura 5 es un diagrama de bloques que muestra un Servidor GUP Doméstico de acuerdo con una realización de la invención.
La figura 6a es un diagrama de bloques que muestra una realización de una Función Proxy Entre Dominios según la invención.
La figura 6b es un diagrama de bloques que muestra una realización de una Función Proxy Entre Dominios según la invención.
La figura 7 es un diagrama de la secuencia del mensaje que muestra un mecanismo para la activación IPF de acuerdo con una realización de la invención usando la comprobación del estado para los datos dinámicos relevantes.
La figura 8 es un diagrama de la secuencia del mensaje que muestra un mecanismo de activación IPF de acuerdo con una realización de la invención usando la notificación del estado del tránsito.
La figura 9 es un diagrama de la secuencia del mensaje que muestra una realización de la invención, usando la funcionalidad proxy cortafuegos.
La figura 10 es un diagrama de la secuencia del mensaje que muestra una realización de la invención, que incluye detalles del protocolo.
Descripción detallada de la invención
La figura 1a es un diagrama de bloques que muestra una arquitectura de referencia GUP. Una red de comunicaciones 100 incluye al menos un dominio doméstico 101 y un dominio visitado 109. Un servidor GUP Doméstico HGUP 104 es el servidor GUP nativo de un usuario final A situado en el dominio doméstico de tal usuario. Este HGUP es el único desplegado por el operador del dominio con el que el usuario final ha establecido una relación comercial.
Los clientes 102 de datos en el dominio doméstico están operativamente conectados al HGUP sobre un interfaz externo Rg 103.
El Servidor GUP es una entidad funcional que proporciona un único punto de acceso a los datos del Perfil Genérico de Usuario de un abonado en particular. Tales datos se encuentran en los Depósitos de Red 106 y pueden ser tanto datos estáticos 107 como datos dinámicos 108. Los servidores GUP se conectan a los depósitos de datos dentro del mismo dominio utilizando los interfaces Rp 105 entre operadores.
Los HGUP 104 pueden obtener datos del usuario, tales como información de su situación, desde una base de datos de abonado SDB 113, tales como un Servidor de Abonado Doméstico HSS, un Registro de Situación Doméstica HLR o un Registro de Situación Visitada VLR.
Con referencia a la figura 1b la invención propone la definición de nuevos mecanismos dentro de la arquitectura GUP 3GPP que permite al Cliente de Datos 102, por ejemplo, un Proveedor de Servicios de Valor Añadido, obtener datos del usuario (estáticos o dinámicos) de un perfil GUP 3GPP independientemente de la situación del usuario final. Ejemplos de casos usuales con situaciones en las que los datos del usuario se encuentran localizados fuera del dominio doméstico del servidor GUP son:
-
El primer usuario A está situado en una primera posición pos1 en su dominio público 101, que es una Red Pública Móvil Terrestre PLMN1 151, pero accede a un servicio que necesita datos acerca de un usuario B, en el que el usuario B es un abonado de otro dominio diferente de PLMN1, por ejemplo, PLMN2 152. El usuario B puede estar situado en una tercera posición pos3 en PLMN2 o transitando en una cuarta posición pos4 en PLMN3 153.
-
El primer usuario A está situado en una segunda posición pos2 transitando en un dominio visitado 109, por ejemplo PLMN2 152 y accediendo a un servicio en su dominio doméstico 101, por ejemplo, PLMN1 151, en el que el servicio necesita servicios datos dinámicos de la PLMN2 visitada.
-
El primer usuario A está situado en una segunda posición pos2 transitando en una PLMN2 visitada y accede a un servicio de un Cliente de Datos 160 en la PLMN2 visitada que necesita datos estáticos de la PLMN1 doméstica.
Ejemplos de tales datos son los datos relacionados con la SGSN no disponibles en el HLR, pero localizados en la SGSN visitada: Zona de encaminamiento, Identidad de la célula, Antigüedad de la identidad de la célula, Código de área de servicio, Capacidad de acceso por radio de la MS, Capacidad de la red de la MS, Estado PDP, APN en uso,
Dirección de la GGSN en uso, QoS negociada, Identidad de cargo, Dirección del RNC en uso, Compresión de la Carga Util Excluida, restricción de la APN. Ejemplos de datos relativos a la GGSN cuando se sitúa en la VPLMN son APN en uso, QoS negociada y dirección SGSN en uso. Otros ejemplos son los datos dinámicos relevantes en el dominio visitado (por ejemplo, QoS negociada en el v-SGSN/GGSN, identidad de cargo en el v-SGSN/GGSN, TMSI y PTMSI en el VLR, la dirección IP/SIP de contacto del usuario final en el v-P-CSCF, etc.).
La Figura 1c es un diagrama de bloques que muestra la arquitectura de referencia GUP para un servidor GUP inter funcionando de acuerdo con la invención. Como se muestra en la figura 1a la red de comunicaciones 100 incluye al menos el dominio doméstico 101 y el dominio visitado 109. Cuando un usuario está en tránsito, el Perfil de Usuario de interés para un servicio se distribuye en los diferentes dominios 101, 109. De acuerdo con la invención, un servidor GUP visitado VGUP 110 es un servidor GUP que sirve temporalmente HGUPs 104 en representación de los clientes de datos 102 (por ejemplo, aplicaciones) que deseen consultar datos dinámicos que sólo se pueden recuperar desde el dominio visitado (es decir, el operador).
Un interfaz de inter funcionamiento Ri 111 se utiliza para comunicarse con el VGUP 110 para que pueda acceder a los datos localizados en un depósito de red 112 en el dominio visitado. Un servidor GUP podría funcionar normalmente tanto como HGUP como VGUP ya que se comportará como un Servidor HGUP para su propia base de abonados, por ejemplo los clientes de datos 160 y como un Servidor VGUP para los usuarios que transitan en su dominio.
La figura 2 es un diagrama de la secuencia del mensaje que muestra el método de acuerdo con una primera realización de la invención. En la etapa 210 un cliente de datos 102, por ejemplo, un solicitante de aplicaciones/datos, está haciendo una consulta al HGUP 104 que tiene una relación comercial con él para recabar los datos del usuario. El cliente de datos está situado en el dominio doméstico 101 y se comunica usando el interfaz Rg 103, como se muestra en la figura 1c. A la recepción de la consulta, el servidor GUP comprueba en la etapa 220 si los datos del usuario consultado, por ejemplo, datos dinámicos tales como la situación del usuario, se encuentran en otra red por ejemplo debido a una situación de tránsito del usuario final o debido a que el usuario final cuyos datos se están consultando pertenece a otra red. Si los datos del usuario se encuentran en otra red, el HGUP modifica el mensaje de consulta entrante e incluye información para la respuesta, incluyendo la red originaria y la dirección para la contestación, con el fin de remitirla al VGUP. En la etapa 230 el mensaje se reenvía al VGUP manteniendo actualmente tales datos dinámicos utilizando el interfaz Ri 111.
En la etapa 240 el VGUP gestiona la consulta teniendo en cuenta que la consulta es relevante para un usuario final quién, aunque no pertenezca al dominio Visitado, pertenece a un operador de red con un acuerdo válido de tránsito. En otras palabras, el VGUP gestiona la consulta y no la ignora por el hecho de que el usuario no sea de
su propia red. El VGUP gestiona la consulta teniendo en cuenta también que la respuesta con los datos relevantes del usuario se tiene que devolver al HGUP actuando como un proxy en lugar de a la aplicación originaria en el dominio doméstico, lo que en realidad es desconocido para el VGUP tanto desde un punto de vista técnico, como comercial. En la etapa 250 el VGUP recupera los datos del usuario desde el depósito relevante utilizando el interfaz RP 105 de la figura 1c.
En la etapa 260 la respuesta con los datos de usuario se devuelve al HGUP sobre el interfaz Ri 111.
En la etapa 270 la respuesta con los datos de usuario se devuelve al cliente de datos solicitante sobre el interfaz Rg
103.
La figura 3 es un diagrama de flujo que muestra una realización del HGUP 104. El HGUP, después de haberse iniciado en la etapa 300, recibe una petición de un cliente de datos 102, es decir, un solicitante de aplicación/datos en la etapa 310. A la recepción de la consulta, el servidor GUP comprueba en la etapa 320 si los datos consultados del usuario, por ejemplo, datos dinámicos tales como la situación del usuario, si se encuentra en otra red, por ejemplo, debido a una situación de tránsito del usuario final o debido a que el usuario final cuyos datos se están consultando pertenece a otra red. El HGUP también determina la localización de los datos del usuario. Si no se encuentran en otra red, la gestión finaliza en la etapa 340. Si los datos del usuario están localizados en otra red, el HGUP modifica el mensaje de consulta entrante en la etapa 330, e incluye información para la respuesta, incluido el origen de la red y la dirección de contestación, con el fin de solicitar los datos del VGUP. En la etapa 370 la respuesta con los datos del usuario se devuelve al cliente de datos solicitante antes de terminar en la etapa 380.
La figura 4 es un diagrama de flujo que muestra una realización del VGUP 110. El VGUP, después de haberse iniciado en la etapa 400, recibe una petición de un HGUP en la etapa 430. En la etapa 440 el VGUP gestiona la petición de datos. En la etapa 450 el VGUP recupera los datos del usuario desde el depósito(s) relevante(s) y responde con los datos del usuario al HGUP en la etapa 460 antes de terminar en la etapa 470.
La figura 5 muestra el HGUP 104 de acuerdo con una realización de la invención que tiene un procesador 503 y una memoria 504 disponiendo de instrucciones accesibles desde la memoria y gestionables por dicho procesador. Una funcionalidad Proxy Entre Dominios IPF 501 es un bloque de funciones cargado en la memoria que tiene la capacidad de recibir peticiones de datos sobre datos que pertenecen a un usuario final en el que estos datos son
manejados actualmente por un servidor GUP en otro dominio diferente del HGUP, por ejemplo, el dominio visitado
109. La memoria también incluye otras funciones de servidor GUP 502.
La figura 6a es un diagrama de bloques que muestra la Función Proxy Entre Dominios 501 de la invención que tiene la capacidad de recibir peticiones de datos sobre los datos que pertenecen a un usuario final del HGUP pero en la que estos datos son actualmente manejados por un Servidor GUP desplegado sobre el dominio/red visitado en el que usuario final está en tránsito (es decir, el VGUP). Un Depósito IPF IPFR 610 es un componente interno que maneja el almacenamiento de los parámetros relevantes. Tiene que manejar, al menos, ResourceId, PLMN-Id, DataReference y Localizador de Recursos Uniformes URL VGUP. Al IPFR se accede a través de un interfaz 615 usando por ejemplo, el Lenguaje de Consulta Estructurado SQL o las bases de datos del Protocolo de Acceso al Directorio Ligero LDAP.
La IPF incluye una Función de Verificación Distante de Datos RVF 620 que es un componente de software encargado de analizar los datos solicitados para determinar si pueden ser unos parámetros asignados a otro dominio diferente que el del Servidor GUP asociado con el cliente de datos. Ejemplos son un dominio visitado por un abonado en tránsito o que los datos solicitados se refieren a un abonado que está abonado a otro dominio. La RVF también determina el usuario final objeto de la consulta. Para llevar a cabo su la funcionalidad, la RVF recurrirá a un parámetro de entrada de Datos de Referencia contenido en el mensaje de consulta original Rg, como se muestra en la etapa 710 de la figura 7. También utilizará la información contenida en el Depósito IPF, específicamente el objeto de la consulta y la Identificación PLMN actual donde está situado el usuario. El objeto de la consulta, es decir, la identificación del usuario, es por ejemplo la Identificación de Recursos de acuerdo con la terminología http://www.3gpp.org/ftp/Specs/htmlinfo/23240.htm.
La introducción de estos parámetros en el IPFR depende del mecanismo de activación IPF en el lugar y podría requerir una interacción adicional con las funcionalidades GUP normalizadas, por ejemplo, una consulta Rp a la SDB para obtener información acerca de la situación.
La IPF también incluye una Función Localizadora URL ULF 630, que es un componente de software que examina a la inversa el parámetro PLMN-Id obtenido del IPFR a una URL válida VGUP, decir, la dirección VGUP. Esta información podría también, como alternativa, ser recuperada directamente en la RVF.
La IPF incluye además un Generador de Mensajes MB 640, que es un componente de software que tiene por objeto generar los mensajes Ri entre el HGUP y el VGUP.
Como se ha puesto de manifiesto también en combinación con la figura 1b, existe una variedad de escenarios en los que los datos del usuario pueden ser distribuidos o localizados en diversos dominios/redes.
La figura 7 describe un mecanismo de activación de la IPF de acuerdo con una realización de la invención, utilizando la comprobación del estado del tránsito de los datos dinámicos relevantes. En esta realización, con referencia a las figuras 1b y 1c, el usuario A se encuentra en tránsito en una situación pos2 en el dominio visitado 109 que es aquí PLMN2 152. En la etapa 710 el HGUP 104 recibe una petición de datos desde el Cliente de Datos 102 sobre el interfaz Rg. Se realiza una comprobación mediante la IPF 501 en la etapa 720 para ver si la petición se refiere a datos dinámicos que son errantes, es decir, que pueden estar ubicados en otra red como por ejemplo, el dominio visitado 109 en la figura 1c. Si es así, el HGUP comprueba con el SDB 113 en la etapa 722 mediante el interfaz RP los mensajes ReadData o Sh-Pull (LocationInformation), y recibe una respuesta en la etapa 724 con los elementos de información relevantes. Esta puede ser, por ejemplo la Identificación del Area de Servicio SAI contenida dentro del valor LocationInformation almacenado en la SDB para conocer la identificación de la red en la que se encuentra actualmente el usuario final.
En la etapa 726 se evalúa la respuesta para ver si el usuario está en tránsito y si es así la PLMN-Id se mapea a una dirección URL para el VGUP en cuestión, en la etapa 728. En la etapa 730 se envía una consulta para datos del usuario al VGUP identificado sobre el interfaz Ri 111. En la etapa 750 el VGUP recuperará los datos solicitados del Depósito de Red 112. En la etapa 755 los datos del usuario se devuelven al VGUP que los gestionará y los enviará al HGUP en la etapa 760. En la etapa 770, los datos se remiten además al cliente de datos solicitante.
La figura 6b es un diagrama de bloques que muestra una realización alternativa de la IPF 501. Esta realización es idéntica a la de la figura 6a con la diferencia de que la RVF 620 está dispuesta para realizar suscripciones a notificaciones de cambios de localización de los datos del usuario y para recibir tales notificaciones. Además, la RVF incluye una Base de datos de Notificaciones NDB 650 dispuesta para almacenar este tipo de notificaciones.
La Figura 8 es un diagrama de la secuencia de mensajes que muestra un mecanismo para la activación de la IPF de acuerdo con una realización de la invención usando la notificación de estado del tránsito. También en esta realización, con referencia a las figuras 1b y 1c, el usuario A se encuentra en tránsito en una situación pos2 en el dominio visitado 109 siendo aquí PLMN2 152.
Una suscripción genérica se lleva a cabo por el Servidor GUP en la etapa 800 para las notificaciones sobre los cambios de los elementos de información que proporcionan información del tránsito. Esta suscripción puede ser un mensaje Rp SuscribeToData o un mensaje Sh-Subs-Notif(Id). En la etapa 802 el HGUP recibe una respuesta. El
proceso de inscripción tiene lugar sólo una vez por abonado. En la etapa 803 tal respuesta se almacena en la NDB
650. Posteriormente, cuando cambia el estado del tránsito de un usuario, esto se detecta en una etapa 804, se envía una notificación a tal efecto desde la SDB en la etapa 806 utilizando un mensaje Rp NotifyData o un mensaje ShSubs-Notif y el resultado se almacena/actualiza en la NDB en la etapa 807. Una petición de datos sobre ese usuario A, se recibe en la etapa 808 y activará automáticamente la IPF 501. En la etapa 810 se realiza una comprobación por medio de la RVF para ver si los datos son errantes y pueden ser localizados en otra red, por ejemplo, sujetos a tránsito, y si es confirmatoria, el HGUP comprobará la NDB 650 en la etapa 812 si el usuario está realmente en tránsito. Si es así, la PLMN-Id se mapea a una dirección URL para el VGUP en cuestión por la ULF 630 en la etapa
814. En la etapa 816 una consulta a los datos del usuario compilada por el MB 640 se envía al VGUP identificado sobre el interfaz Ri 111. En la etapa 818 el VGUP recuperará los datos solicitados del usuario desde el Depósito de Red 112 usando un mensaje ReadData sobre el interfaz PR. En la etapa 820 los datos del usuario se devuelven al VGUP que los gestionará y los remitirá al HGUP en la etapa 822. En la etapa 824 los datos se remiten además al cliente de datos solicitante.
La figura 9 es un diagrama de la secuencia del mensaje que describe una realización de la invención usando una funcionalidad proxy cortafuegos.
En la etapa 910 el HGUP recibe una consulta de la aplicación (solicitante de datos). En la etapa 920, el HGUP averigua, por ejemplo utilizando cualquier método descrito anteriormente, la red en la que está en tránsito el usuario final.
En la etapa 930 el HGUP almacena al menos partes de la consulta original. En la etapa 940 el HGUP elimina la información que identifica al cliente de datos como solicitante de los datos e inserta en su lugar su propio identificador de la aplicación de HGUP (esto hace suponer al HGUP que está habilitado - es decir existe una relación comercial para consultar al VGUP. También se cambia el punto de acceso VGUP (es decir, la URL) y se almacena el mapeo entre la consulta original y la nueva. La petición modificada se envía entonces al VGUP usando el interfaz Rg o el interfaz Rp.
En la etapa 950 el VGUP comprueba la identidad del cliente de datos, es decir, el HGUP, y gestionará la petición si el solicitante es un HGUP con el que existe un acuerdo. El VGUP extrae los datos solicitados en la etapa 960 y devuelve la respuesta al HGUP solicitante sobre el interfaz Rg o sobre el interfaz Rp en la etapa 970.
En la etapa 980, una vez recibida la respuesta del VGUP, el HGUP mapea la respuesta a la consulta original y la devuelve a la aplicación original con la información proporcionada por el VGUP en la etapa 990.
La figura 10 es un diagrama de la secuencia del mensaje que describe una realización de la invención con mayor detalle. También en esta realización, con referencia a las figuras 1b y 1c, el usuario A está transitando en una situación pos2 en el dominio visitado 109 que aquí es el PLMN2 152.
En la etapa 1010 una aplicación, por ejemplo, el cliente de datos 102, consulta al servidor GUP HGUP 104 con el que ha establecido una relación comercial. La consulta incluye la identidad del usuario final que es [email protected] y la identidad del cliente de datos que es http://application.com.
Tras la recepción del mensaje, el servidor HGUP comprobará en la etapa 1020, si una parte requerida del perfil de usuario es errante y pudiera estar situada en otro dominio. Para ello utilizará la RVF 620 dentro de la IPF 501.
Si el resultado de la comprobación anterior es positivo, es decir, el parámetro está potencialmente sujeto a poder ser recuperado desde otra red, se lleva a cabo una consulta a la SDB en la etapa 1022 con el fin de obtener la situación del usuario. Esta consulta se puede hacer de diferentes maneras: mediante el interfaz Rp del GUP o mediante el interfaz existente Sh (HGUP comportándose como un Servidor de Aplicación AS).
En la etapa 1024 el SDB devuelve la respuesta al HGUP proporcionando la SAI u otra información de la situación.
En la etapa 1025 el HGUP determina, basándose en la información SAI en qué dominio (PLMN Id) se encuentra el usuario actualmente, que resulta estar en tránsito en PLMN2.
En la etapa 1026 el HGUP comprueba que el PLMN identificado es aquel con el cual existe un acuerdo válido de tránsito.
Después de esto, en la etapa 1028 el HGUP utiliza la ULF 630 dentro de la IPF para mapear la PLMN-Id a un VGUP URI válido adonde enviar la consulta.
El HGUP, actuando como un proxy, utiliza el Generador de Mensajes 640 en la IPF a fin de crear una nueva consulta. La consulta incluye:
-
Los datos del solicitante, por ejemplo, http://application.com, que mapea al ProviderID los atributos del Protocolo Liberty’s DST e identifica los datos que solicita realmente la aplicación.
-
Unos atributos RequestorGUPServerID para ser incluidos en la cabecera del Proveedor según se especifica en Liberty DST. El RequestorGUPServerID identifica un sistema/proxy intermediario, es decir, el HGUP URI, actuando en nombre del solicitante original de los datos y que depositará las peticiones en el VGUP.
-
Una Identidad de Recursos, por ejemplo, [email protected] que mapea al ResourceID los atributos del protocolo Liberty’s DST e identifica al usuario final cuyos datos se están consultando.
-
El estado del tránsito de los usuarios finales en el que se basa la consulta. El elemento de información del estado del Tránsito puede ser ejecutado bien modificando el tipo actual ResourceIDType o bien introduciendo un nuevo elemento RoamingStatus como parte del QueryType en el Liberty DST. El HGUP al remitir las consultas a los dominios visitados incluirá estos nuevos atributos y fijará el valor de acuerdo con la siguiente regla: RoamingStatus = "1" indica que el usuario final cuyos datos se consultan está en tránsito. El servidor VGUP deberá gestionar la consulta entrante, incluso a pesar de que se refiera a un usuario final que no le pertenece. RoamingStatus = "0" indica que el usuario final pertenece al servidor VGUP. Esto también permite que los Operadores de Redes Virtuales con Móviles (MVNOs), con su propio servidor GUP desplegado (actuando como HGUP) envíen consultas al servidor GUP desplegado por el operador de la red (actuando como VGUP). En este caso el atributo del RoamingStatus de uso se fija a "1" para indicar que el usuario final cuyos datos se están consultando se encuentra en tránsito.
La nueva consulta de los datos del usuario distante se envía al VGUP 110 sobre el interfaz Ri 111 en la etapa 1030.En la etapa 1031 el VGUP recibe el mensaje y comprueba la presencia del parámetro RoamingStatus para distinguir la forma en que debe gestionar la consulta entrante. Su presencia indica que aunque la consulta sea relevante para un usuario final que, en principio, no pertenece a esa red, la consulta debe ser gestionada debido a una situación de tránsito. El VGUP también comprueba la RequestorGUPServerID con el fin de conocer a qué URI se debe devolver la respuesta relevante.
En la etapa 1050 el VGUP recupera los datos del usuario del depósito de la red relevante 112 usando el interfaz GUP Rp 105.
En la etapa 1055 el correspondiente depósito de la red responde al VGUP con los datos del usuario.
El VGUP devuelve la respuesta con los datos del usuario al HGUP en la etapa 1060, basándose en la información proporcionada en el RequestorGUPServerID, con los datos relevantes.
En la etapa 1065 el HGUP gestiona la respuesta del VGUP y borra el RequestorGUPServerID y el RoamingStatus de la cabecera del mensaje.
En la etapa 1070 el HGUP devuelve la respuesta al cliente de datos 102 (es decir, a la aplicación).

Claims (14)

  1. REIVINDICACIONES
    1. Un método para recuperar los datos relativos a un abonado, realizado por un primer Perfil Genérico de Usuario, GUP, servidor en una red de comunicaciones (100) que tiene un primer y un segundo dominio de comunicaciones, comprendiendo dicho método las etapas de:
    -
    recibir (808) una petición de entrada de datos relativos a un abonado de un cliente de datos (102) en el primer dominio de comunicaciones (101); - determinar (812) que al menos una parte de los datos se encuentra en el segundo dominio de comunicaciones (109);
    -
    transmitir (816) una petición de salida a un segundo servidor GUP en el segundo dominio de comunicaciones para al menos parte de los datos;
    -
    recibir (822) una respuesta de el segundo servidor GUP que contiene al menos parte de los datos solicitados; - remitir (824) los datos solicitados al cliente de datos
    caracterizado porque:
    -
    antes de la etapa de determinación, realiza las etapas adicionales de:
    (i)
    suscribir las notificaciones sobre los cambios de identificación del segundo dominio de comunicaciones (800);
    (ii)
    recibir tales notificaciones sobre los cambios (802, 806);
    (iii) almacenar tales notificaciones sobre los cambios (803, 807);
    (iv) comprobar si una porción de la petición de datos es errante (810, 1020) y
    -
    la etapa de determinación incluye el uso de tales notificaciones almacenadas para establecer una dirección al segundo servidor GUP (814).
  2. 2.
    Un método según la reivindicación 1 en el que las etapas de transmitir la petición de salida al, y recibir la respuesta del, segundo servidor GUP tiene lugar sobre un interfaz de inter funcionamiento del servidor GUP (111).
  3. 3.
    Un método según las reivindicaciones 1-2, en el que la identificación del segundo dominio de comunicaciones sebasa en la Identidad del Área de Servicio almacenada en una base de datos del abonado (113) del primer dominio de comunicaciones.
  4. 4.
    Un método según cualquiera de las reivindicaciones precedentes en el que antes de la etapa de transmitir una petición de salida al segundo servidor GUP realiza las etapas adicionales de:
    -
    almacenar (930) un mapeo entre la petición de entrada (910) y la petición de salida (940);
    -
    insertar en la petición de salida (940) la identidad del primer GUP; y después de la etapa de recibir la respuesta (970) realiza la etapa adicional de:
    -
    mapear los datos en la respuesta a la petición de entrada recibida (980).
  5. 5.
    Un método según las reivindicaciones 1-3 en el que la etapa de transmitir una petición de salida al segundo servidor GUP (1030) incluye enviar un identificador del cliente de datos.
  6. 6.
    Un método según cualquiera de las reivindicaciones precedentes en el que la etapa de transmitir una petición de salida al segundo servidor de GUP incluye enviar un indicador del estado del tránsito para indicar si el usuario final cuyos datos se están consultando se encuentra en tránsito.
  7. 7.
    Un método según cualquiera de las reivindicaciones precedentes en el que la etapa de transmitir una petición de salida al segundo servidor de GUP se lleva a cabo sobre un Rg (103) GUP 3GPP o sobre un Rp (105) GUP 3GPP o sobre un interfaz de inter funcionamiento Ri (111).
  8. 8.
    Un método según cualquiera de las reivindicaciones precedentes en el que el abonado se encuentra en tránsito en una primera o en una segunda red.
  9. 9.
    Un método según cualquiera de las reivindicaciones precedentes en el que el abonado es un abonado de otra red de comunicaciones diferente del HGUP.
  10. 10. Un servidor GUP Doméstico (104) para recuperar datos relativos a un abonado, que comprende un procesador
    (503) y una memoria (504) que tiene instrucciones accesibles desde dicha memoria y gestionables por dicho procesador, que comprende además:
    -
    un interfaz (103) para recibir (808) una petición de entrada de los datos relativos del abonado desde un cliente de datos (102) en un primer dominio de comunicaciones(101);
    -
    un interfaz (103, 105, 111) para transmitir (816) una petición de salida a un segundo servidor GUP en un segundo dominio de comunicaciones para al menos parte de los datos;
    -
    un interfaz (103, 105, 111) para recibir (822) una respuesta desde el segundo servidor GUP que contiene al menos parte de los datos solicitados y
    -
    un interfaz (103) para remitir (824) los datos solicitados al cliente de datos; caracterizado porque la memoria comprende una función proxy inter dominios (501) adaptada para:
    (i)
    suscribirse a las notificaciones sobre los cambios de una identificación del segundo dominio de comunicaciones (800);
    (ii) recibir estas notificaciones sobre los cambios (802, 806);
    (iii) almacenar estas notificaciones sobre los cambios (803, 807),
    (iv)
    analizar la petición de entrada para determinar si los datos pueden estar situados en otro dominio diferente del dominio del servidor GUP del cliente de datos (810);
    (v)
    establecer (812) que al menos una parte de los datos se encuentra en el segundo dominio de comunicaciones (109); y
    (vi) usar tales notificaciones almacenadas para indicar una dirección al segundo servidor GUP (814).
  11. 11.
    Un servidor GUP Doméstico según la reivindicación 10 caracterizado por un interfaz de inter funcionamiento del Servidor GUP (111) dispuesto para transmitir la petición de salida al, y para recibir la respuesta del, segundo servidor GUP.
  12. 12.
    Un servidor GUP Doméstico según la reivindicación 10 caracterizado porque la función de verificación distante de los datos (620) comprende una base de datos de notificaciones (650) para almacenar las notificaciones de los cambios en la localización de los datos del usuario.
  13. 13.
    Un servidor GUP Doméstico según las reivindicaciones 10-12 caracterizado porque la función proxy entre dominios comprende un depósito (610) para el almacenamiento de los parámetros y una función de búsqueda de direcciones (630) para mapear un parámetro de identidad de dominios a una dirección GUP distante válida.
  14. 14.
    Un servidor GUP Doméstico según las reivindicaciones 10-13 caracterizado porque está dispuesto para antes de la etapa de transmitir una petición de salida al segundo servidor GUP, realizar las etapas adicionales de:
    -
    almacenar (930) un mapeo entre la petición de entrada (910) y la petición de salida (940);
    - insertar en la petición de salida (940) la identidad del primer GUP; y después de la etapa de recibir la respuesta (970) realizar la etapa adicional de:
    -
    mapear los datos en la respuesta a la petición de entrada recibida (980).
ES06126541T 2006-12-19 2006-12-19 Método y aparato para recuperar entre redes datos relativos al usuario Active ES2427965T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP06126541.9A EP1936860B1 (en) 2006-12-19 2006-12-19 Method and apparatus for inter network retrieval of user related data

Publications (1)

Publication Number Publication Date
ES2427965T3 true ES2427965T3 (es) 2013-11-05

Family

ID=38169511

Family Applications (1)

Application Number Title Priority Date Filing Date
ES06126541T Active ES2427965T3 (es) 2006-12-19 2006-12-19 Método y aparato para recuperar entre redes datos relativos al usuario

Country Status (6)

Country Link
US (1) US8532673B2 (es)
EP (1) EP1936860B1 (es)
CN (1) CN101589601B (es)
ES (1) ES2427965T3 (es)
RU (1) RU2454010C2 (es)
WO (1) WO2008076068A1 (es)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008108717A1 (en) * 2007-03-08 2008-09-12 Telefonaktiebolaget Lm Ericsson (Publ) A method and apparatus for selecting a service area identifier for a user equipment in a wireless system
EP2109292A1 (en) * 2008-04-08 2009-10-14 Alcatel Lucent Proxy device and associated server for GUP architecture
US8239632B2 (en) * 2009-03-12 2012-08-07 At&T Mobility Ii Llc Data caching in consolidated network repository
CN101771693B (zh) * 2010-01-15 2012-10-03 华为技术有限公司 一种传递虚拟运营商数据的方法、装置及***
US20130276072A1 (en) * 2010-12-21 2013-10-17 Telefonaktiebolaget L M Ericsson (Publ) Method for Enabling Exchange of User Profiles Between a Visited Network and a Home Network
CN104579914A (zh) * 2013-10-17 2015-04-29 中兴通讯股份有限公司 一种***之间订阅状态的方法及装置
US10223385B2 (en) 2013-12-19 2019-03-05 At&T Intellectual Property I, L.P. Systems, methods, and computer storage devices for providing third party application service providers with access to subscriber information
US9270815B2 (en) 2014-06-24 2016-02-23 At&T Intellectual Property I, Lp Method and apparatus for data management of third party services
RU2740637C1 (ru) * 2017-08-14 2021-01-19 Телефонактиеболагет Лм Эрикссон (Пабл) Способ исполнения услуги для потребителя услуги, а также соответствующий сетевой узел и компьютерный программный продукт
MA48055A1 (fr) 2017-08-14 2020-11-30 Ericsson Telefon Ab L M Procédé de découverte de services fournis par une fonction de référentiel de réseau

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI104397B (fi) 1997-03-04 2000-01-14 Nokia Networks Oy Puhelunohjausmenetelmä
US6996072B1 (en) * 2000-01-19 2006-02-07 The Phonepages Of Sweden Ab Method and apparatus for exchange of information in a communication network
CN1167231C (zh) 2001-04-06 2004-09-15 华为技术有限公司 在智能网中实现节点位置和状态信息查询的方法和***
EP1551144A1 (en) * 2003-12-31 2005-07-06 France Telecom System, method and apparatus for providing multimedia communications services
US20060003766A1 (en) 2004-06-30 2006-01-05 Sriram Parameswar Providing temporal information for roaming mobiles
KR100823128B1 (ko) * 2004-06-30 2008-04-21 삼성전자주식회사 통합 서비스 제공 시스템의 정보 관리 방법 및 장치
US7583646B2 (en) * 2004-10-14 2009-09-01 Alcatel-Lucent Usa Inc. Method and apparatus for facilitating interaction between a home subscriber server (HSS) and a home location register (HLR) in a legacy network
ATE553584T1 (de) * 2004-12-17 2012-04-15 Tekelec Us Verfahren, systeme und computerprogrammprodukte zum clustern und kommunizieren zwischen entitäten des internet-protokoll-multimediasubsystems (ims)

Also Published As

Publication number Publication date
EP1936860B1 (en) 2013-07-03
RU2454010C2 (ru) 2012-06-20
EP1936860A1 (en) 2008-06-25
CN101589601B (zh) 2012-06-13
WO2008076068A1 (en) 2008-06-26
US8532673B2 (en) 2013-09-10
RU2009127716A (ru) 2011-01-27
CN101589601A (zh) 2009-11-25
US20120238292A1 (en) 2012-09-20

Similar Documents

Publication Publication Date Title
ES2427965T3 (es) Método y aparato para recuperar entre redes datos relativos al usuario
JP6891223B2 (ja) モバイル端末に無線ローカルエリアネットワークへのローミングを可能にするネットワークアーキテクチャ
CN116018798B (zh) Nf发现和路由的方法、***和计算机可读介质
JP4160619B2 (ja) 位置情報を提供する装置と方法
CN102656845B (zh) 用于向直径信令路由器提供集成的监控和/或防火墙功能的方法、***和计算机可读介质
ES2886833T3 (es) Un método de ejecución de un servicio para un consumidor de servicios, así como un nodo de red correspondiente y un producto de programa informático
US9467341B2 (en) Policy decision function addressing method, network element and network system
US20120322412A1 (en) Roaming selection of a v-epdg
US9313759B2 (en) Methods, systems, and computer readable media for providing triggerless equipment identity register (EIR) service in a diameter network
JP6751844B2 (ja) 訪問国におけるｅＰＤＧの選択処理の機能強化
JP2024502607A (ja) 加入者識別子の漏洩を防止するための方法、システム、およびコンピュータ可読媒体
WO2018112759A1 (zh) 访问资源的方法、装置和***
KR101261358B1 (ko) 가입자 데이터베이스에 대한 방법 및 장치
US11895080B2 (en) Methods, systems, and computer readable media for resolution of inter-network domain names
WO2024073921A1 (en) Method and apparatus of supporting edge sharing
CN117939454A (zh) 信息传输方法、设备及存储介质