ES2787251T3 - Adquisición de identificador de servidor basada en ubicación de dispositivo - Google Patents

Adquisición de identificador de servidor basada en ubicación de dispositivo Download PDF

Info

Publication number
ES2787251T3
ES2787251T3 ES08707572T ES08707572T ES2787251T3 ES 2787251 T3 ES2787251 T3 ES 2787251T3 ES 08707572 T ES08707572 T ES 08707572T ES 08707572 T ES08707572 T ES 08707572T ES 2787251 T3 ES2787251 T3 ES 2787251T3
Authority
ES
Spain
Prior art keywords
identifier
server
node
request
network
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
ES08707572T
Other languages
English (en)
Inventor
Miguel Garcia-Martin
Jan KÅLL
Sebastien Kraufvelin
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.)
Nokia Solutions and Networks Oy
Original Assignee
Nokia Solutions and Networks Oy
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 Nokia Solutions and Networks Oy filed Critical Nokia Solutions and Networks Oy
Application granted granted Critical
Publication of ES2787251T3 publication Critical patent/ES2787251T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02Services making use of location information
    • H04W4/029Location-based management or tracking services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02Services making use of location information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04JMULTIPLEX COMMUNICATION
    • H04J11/00Orthogonal multiplex systems, e.g. using WALSH codes
    • H04J11/0069Cell search, i.e. determining cell identity [cell-ID]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004Server selection for load balancing
    • H04L67/1021Server selection for load balancing based on client or server locations
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/52Network services specially adapted for the location of the user terminal
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/90Services for handling of emergency or hazardous situations, e.g. earthquake and tsunami warning systems [ETWS]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/50Connection management for emergency connections

Landscapes

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

Abstract

Un método para un dispositivo,: a) usando el dispositivo un identificador único de un nodo (20) de una red para solicitar de un sistema de nombre de dominio (32) uno de un identificador de un servidor (38), un identificador de un servidor de traducción (34) y un identificador de un servidor de descubrimiento de ubicación (36) para el dispositivo (10) fijado a dicho nodo (20); en donde la solicitud comprende una dirección de servidor por defecto establecida en dicho dispositivo (10) usando al menos partes de dicho identificador único y la solicitud es para permitir que el sistema de nombre de dominio determine el identificador del al menos un servidor (38), (34) y (36) que dé servicio en un área en la que está situado dicho dispositivo, y b) recibiendo el dispositivo una respuesta a la solicitud del sistema de nombre de dominio que incluye el identificador del al menos un servidor (38), o el identificador del servidor de traducción (34) y/o el identificador del servidor de descubrimiento de ubicación (36).

Description

DESCRIPCIÓN
Adquisición de identificador de servidor basada en ubicación de dispositivo
Campo de la invención
La presente invención se refiere a un método y un aparato para obtener un identificador de un servidor, tal como, por ejemplo, pero sin limitación, un punto de respuesta para una llamada de emergencia.
Antecedentes de la invención
La ubicación de un dispositivo es una información útil para muchas aplicaciones. El dispositivo puede basarse en su red de acceso para proporcionar la información de ubicación. Este servicio puede proporcionarse por un servidor de configuración de ubicación (LCS), en el que el dispositivo puede solicitar que el LCS proporcione una referencia de ubicación en forma de un URI (Indicador de Recurso Uniforme) de ubicación o un conjunto de URI, que permite que el dispositivo distribuya su información de ubicación. El LCS puede accederse por un protocolo, tal como HELD (Descubrimiento de Ubicación Habilitado para HTTP), que posibilita la recuperación de la información de ubicación. Schulzrinne, H., "Location-to-URL Mapping Architecture y Framework", diciembre de 2006 describe una arquitectura de servidor de mapeo con un cliente de mapeo (buscador o resolutor) y un servidor de mapeo (resolutor u otros servidores) para descubrir direcciones de servidor. Un mensaje de consulta lleva información de ubicación y un identificador de servicio codificado como un Nombre de Recurso de Uniforme (URN) (consúltese Schulzrinne, H., "A Uniform Resource Name (URN) for Services", agosto de 2006) de un cliente de traducción de ubicación a servidor (LoST) a un servidor de LoST. El servidor de LoST usa su base de datos para mapear valores de entrada a uno o más Identificadores de Recursos Uniformes (URI) y devuelve estos URI junto con información opcional, tal como indicios acerca del límite de servicio, en un mensaje de respuesta al cliente de LoST. Si el servidor no puede resolver la misma consulta, puede a su vez consultar a otro servidor o devolver la dirección de otro servidor de LoST. Si un URL de LoST contiene un nombre de anfitrión en lugar de una dirección de Protocolo de Internet (IP), los clientes necesitan usar un puntero de autoridad de nomenclatura (por ejemplo, U-NAPTR descrito por ejemplo en Daigle, L., "Domain-based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)", octubre de 2006).
La arquitectura para llamadas de emergencia hace uso de los conceptos de servidores de LoST y servidores de HELD. El servidor de LoST es responsable de la traducción de información de ubicación en el URI de su PSAP más cercano (Punto de Respuesta de Seguridad Púbica), mientras que el servidor de HELD es responsable de entregar la ubicación del usuario. La especificación del protocolo de ubicación a LoST describe un protocolo basado en XML para mapear identificadores de servicio e información de ubicación geodésica o cívica a los URI de contacto de servicio. En particular, puede usarse para determinar el PSAP apropiado de ubicación para servicios de emergencia. Un problema común con los inconvenientes de la ubicación en llamadas de emergencia de IP está relacionado con averiguar cuál es el servidor de LoST o HELD. Esto es puesto que los servicios de LoST o HELD tienen un límite de operación. Por ejemplo, un servidor de LoST típico puede resolver la ubicación a PSAP que pertenece al país político donde pertenecen los PSAP. O en grandes países, un operador de red regional puede proporcionar un servidor de LoST que puede resolver ubicaciones donde el operador tiene cobertura. Pueden aplicarse situaciones similares a servidores de HELD también.
Esta limitación geográfica de servidores de LoST y HELD conduce a otro problema: ¿cómo un dispositivo, tal como un punto terminal, puede hallar la dirección de URI o IP del servidor de LOST o HELD que puede proporcionar al punto final con información relacionada con la ubicación?
Una solución actual consiste en el uso de protocolo de configuración dinámica del anfitrión (DHCP) para recuperar la dirección de URI o IP de un servidor de LoST, como se especifica en el borrador de Internet "A Dynamic Host Configuration Protocol (DHCP) based Location-to-Service Translation Protocol (LoST) Discovery Procedure" (consúltese http://tools.ietf.org/id/draft-ietf-ecrit-dhc-lost-discovery-02.txt). Sin embargo, mientras que esta solución es técnicamente factible para puntos terminales, que normalmente obtienen una dirección de IP con DHCP, la solución no tiene uso en redes inalámbricas (por ejemplo, en un Subsistema Multimedia de IP (IMS)).
Los dispositivos móviles (por ejemplo terminales móviles o nodos móviles) no usan normalmente DHCP para obtener una dirección de IP cuando usan las redes de acceso de servicio general de paquetes de radio (GPRS) con conectividad de IP. En su lugar, usan los procedimientos de GPRS (por ejemplo, activación de contexto de protocolo de datos de paquetes (PDP)) para obtener una dirección de IP.
Por otra parte, puesto que el dispositivo móvil puede estar moviéndose, puede atravesar el límite de operación de un PSAP. Por lo tanto, el dispositivo móvil puede necesitar descubrir su servidor de LoST/HELD local en el momento que se hace una llamada de emergencia, y no antes.
El documento US2007153984A1 desvela un método para llamadas de emergencia para un sistema de VolP a través de puntos de acceso inalámbricos, donde el sistema de VolP detecta la ubicación del dispositivo llamante y redirige la llamada a la red celular.
El documento Schulzrine et al. "Emergency Services for Internet Telephony Systems" describe la convocatoria de llamadas de emergencia en redes de telefonía, y el uso del protocolo de SIP para proporcionar servicios de emergencia avanzados para VoIP. Se usa DNS para mapear ubicaciones civiles y geoespaciales para el centro de llamadas de emergencia apropiado.
Sumario de la invención
La invención se expone en las reivindicaciones adjuntas.
Breve descripción de los dibujos
La presente invención se describirá ahora basándose en realizaciones con referencia a los dibujos adjuntos en las que:
La Figura 1 muestra un diagrama esquemático que indica una arquitectura de red en la que puede implementarse la presente invención;
La Figura 2 muestra un diagrama de señalización esquemático de acuerdo con una primera realización de la presente invención;
La Figura 3 muestra una configuración a modo de ejemplo de un registro de recurso de acuerdo con la primera realización de la presente invención;
La Figura 4 muestra un diagrama de señalización esquemático de acuerdo con una segunda realización de la presente invención;
La Figura 5 muestra una estructura esquemática de un identificador global de célula;
La Figura 6 muestra un diagrama de señalización esquemático de acuerdo con una tercera realización de la presente invención;
La Figura 7 muestra un diagrama de flujo de un procedimiento de configuración de acuerdo con la tercera realización;
La Figura 8 muestra diagramas de bloques esquemáticos de un dispositivo móvil y una base de datos de acuerdo con diversas realizaciones de la presente invención; y
La Figura 9 muestra un diagrama de bloques esquemático de una implementación basada en software de acuerdo con una cuarta realización de la presente invención.
Descripción de la realización
A continuación, se describirán realizaciones de la presente invención basándose en una función de llamada de emergencia de IP en un entorno de red celular. El entorno de red celular se usa como un ejemplo ilustrativo de un entorno de red donde puede usarse la presente invención. La invención puede aplicarse a cualquier clase de redes inalámbricas o fijas.
La Figura 1 muestra un diagrama esquemático de una arquitectura de red general en la que puede implementarse la presente invención. Una red de acceso de radio celular 300, por ejemplo, la Red de Acceso Terrestre (UTRAN) del Sistema Universal de Telecomunicaciones Móviles (UMTS) de acuerdo con la Evolución a Largo Plazo (LTE) o la norma del Proyecto de Asociación de la 3a Generación (3GPP) Versión 8, está conectada a un terminal móvil (por ejemplo, el equipo de usuario (UE)) 10 mediante un dispositivo de acceso 20, por ejemplo, un nodo de red de radio tal como un dispositivo de estación base (eNodo B o Nodo B). La red de acceso de radio 300 proporciona acceso a servidores específicos de una red basada en IP, tal como internet. Estos servidores específicos comprenden un servidor de DNS 32, un servidor de LoST asignado 34, un servidor de HELD asignado 36, un servidor de SLP 35 (Plataforma de Ubicación de Plano de Usuario Segura (SUPL)), y un PSAP 38 al han de encaminarse las llamadas de emergencia.
De acuerdo con diversas realizaciones, el UE 10 transmite una consulta de servidor de nombre de dominio (DNS) 40 para solicitar un identificador (por ejemplo, dirección de servidor o similar) de al menos uno de los servidores de HELD, LoST y SLP 36, 34, 35.
En redes celulares tales como la red de acceso de radio 300, el UE 10 puede descubrir la identidad de la célula donde está conectado. Normalmente, se difunde un identificador de célula (CI) o un identificador de célula global (Identidad Global de Célula (CGI)) y se usa en la señalización de radio entre el UE 10 y la red de acceso de radio 300. Por lo tanto el UE 10 conoce en todo el momento el CI o la CGI de la célula de radio. Además, el Proyecto Asociación de la 3a Generación (3GPP) ha especificado que un dispositivo móvil, por ejemplo el UE 10, debe incluir el CI o la CGI usados en la señalización del protocolo de iniciación de sesión (SIP).
En las realizaciones descritas a continuación, se introduce una base de datos 32, que acepta el CI o la CGI y las correspondientes identidades de célula de 3G y LTE como entrada en consultas y devuelve diversa información como salida, que incluye, pero sin limitación, el URI de los servidores de LoST y HELd 34, 36 que dan servicio de la ubicación geográfica donde está ubicada físicamente la célula.
En una implementación alternativa (no mostrada), el UE 10 puede usar también una dirección de control de acceso al medio (MAC) de una estación base inalámbrica (por ejemplo una red de área local inalámbrica (WLAN) o puntos de acceso de WIMAX) a la que está conectada el UE 10 de una manera similar para determinar los correspondientes servidores de HELD y LoST que dan servicio de la ubicación de la estación base en cuestión.
En el ejemplo de la Figura 1, la base de datos 32 se implementa como un servidor de DNS, que puede denominarse también un Servicio de Delegación de Descubrimiento Dinámico (DDDS), o introduciendo de una manera similar un nuevo tipo de DNS de servidor especializado para el descubrimiento de servidores de LoST y HELD.
En la primera realización, se usan el o los CI y CGI como un nuevo tipo de entrada en la consulta de DNS y se hace posible que la funcionalidad de DNS determine los correspondientes servidores de HELD y LoST basándose en la célula de radio donde está situado actualmente el UE 10. En otras realizaciones el o los CI y CGI se usan como entrada en la consulta de DNS y se hace posible que la funcionalidad de DNS determine los URI de cualquier servicio de telecomunicación disponible para terminal en el área que corresponde al o a los CI y CGI. Como un ejemplo de implementación específica, puede usarse el tipo de consulta establecida a U-NAPTR, como se ejemplifica en la especificación RFC 4848, sección 3 del Grupo Especial Sobre Ingeniería de Internet (IETF). La correspondiente salida de la consulta de DNS está basada en o usa elementos de protocolo existentes descritos en RFC 4848, sección 4.
Cuando el operador de acceso configura apropiadamente su Sistema de Nombre de Dominio (DNS), cualquier punto terminal de conexión (tal como el UE 10) puede consultar el DNS para averiguar cuál es el servidor de LoST o HELD apropiado o el o los URI de cualquier servicio de telecomunicación correspondiente.
La Figura 2 muestra un diagrama de señalización esquemático de acuerdo con una primera realización de la presente invención.
El UE 10 ha hallado la dirección de su servidor de DNS 32 de acuerdo con procedimientos regulares (por ejemplo, preconfigurados, mediante DHCP, o activación de contexto de PDP). El UE 10 ha aprendido también su CI. Ahora, el UE 10 necesita hallar sus servidores de LoST y HELD asignados 34, 36, pero no tiene conocimiento de la dirección de los servidores configurados por el operador de acceso.
En la etapa 101, el UE 10 envía una consulta de NAPTR de DNS que contiene el CI o la CGI actual y el protocolo de interés (por ejemplo LoST o HELD). En caso de la CGI, está formateada en un orden jerárquico, de modo que los diferentes campos que componen la CGI están separados por un punto. A continuación, en la etapa 102, el servidor de DNS 32 envía una respuesta de DNS que contiene la dirección del servidor de LoST o HELD local (o ambos), que puede haberse extraído de su configuración. El UE 10 puede a continuación iniciar en la etapa 103 una consulta de HELD regular (por ejemplo "HTTP GET") para recuperar información de ubicación detallada, que se envía en la etapa 104 en una respuesta de HELD (por ejemplo "HTTP 200" (OK)). Con esa información detallada, el UE 10 puede hacer una consulta de LoST (por ejemplo "HTTP POST") en la etapa 105 para averiguar la dirección de protocolo de iniciación de sesión (SIP) del PSAp local 38, que se devuelve en la etapa 106 en una respuesta de LoST (por ejemplo "HTTP 200" (OK)).
Finalmente, en la etapa 107 el UE 10 puede hacer una llamada de emergencia en la etapa 107 y direccionarla al PSAP local (y más cercano) 38.
Se observa que la realización y todas las realizaciones posteriores pueden usare fuera de llamadas de emergencia, donde el UE 10 puede hacer uso de cualesquiera otros servicios locales.
La Figura 3 muestra un ejemplo de configuración de un registro de recurso de NAPTR en DDDS que podría usarse en la primera realización. En primer lugar, se definen dos aplicaciones nuevas para U-NAPTR denominadas "Identidad de Célula" (CI) e "Identidad Global de Célula" (CGI) y están asociadas a continuación a los protocolos de LoST y HELD.
La Figura 5 muestra una relación entre el CI y la CGI. La CGI comprende una identificación de área de ubicación y el CI. La identificación de área de ubicación consiste en un código de país móvil (MCC), un código de red móvil (MNC) y un código de área de ubicación (LAC).
La Figura 4 muestra un diagrama de señalización esquemático de una mejora de acuerdo con una segunda realización, donde se combinan juntos tres nodos o servidores, en concreto el servidor de DNS 32, el servidor de LoST 34, y el servidor de HELD 36. En la segunda realización, el UE 10 hace una consulta de NAPTR de DNS en la etapa 201 y recibe una respuesta en la etapa 202. La respuesta contiene la dirección de PSAP local (o cualquier otra dirección local del servicio solicitado). A continuación, en la etapa 203, el UE 10 puede hacer la llamada de emergencia o cualquier otro servicio situado, por ejemplo, emitiendo un mensaje SIP INVITE.
La Figura 6 muestra un diagrama de señalización esquemático de acuerdo con una tercera realización de la presente invención, que no requiere ningún cambio a DNS. El procedimiento de obtención propuesto proporciona auto-aprovisionamiento del UE 10 con direcciones de servidor de LoST y/o HELD (por ejemplo u Ri) basándose en la CGI o para Ubicación de Plano de Usuario Segura (SUPL) cuando se auto-aprovisiona la dirección de E-SLP (Plataforma de Ubicación de SUPL Mejorada). El UE 10 puede a continuación usar los URI auto-aprovisionados en la consulta de DNS para obtener la dirección de IP de los servidores de LoST, HELD y E-SLP, respectivamente. El diagrama y etapas de la Figura 6 son similares a aquellos de la Figura 2, excepto para una etapa o proceso de construcción inicial, donde se construyen direcciones de servidor por defecto o se establecen basándose en la CGI. El mismo proceso de construcción puede aplicase cuando se construye una dirección de SLP o E-SLP, en el que se inicia una sesión de SUPL iniciada de terminal o terminales aptos para SUPL (SET) hacia un servidor de E-SLP. SUPL emplea portadoras de datos de plano de usuario para transferir información de ubicación, (por ejemplo, asistencia de Sistema de Posicionamiento Global (GPS)), y para llevar protocolos relacionados con la tecnología de posicionamiento entre un SET y la red. SUPL proporciona una manera eficaz de transferencia de información de ubicación requerida para calcular la ubicación de SET. Pueden recopilarse detalles adicionales sobre SUPL a partir de las especificaciones de la Alianza Móvil Abierta (OMA).
Sin embargo, se observa que los procedimientos y conceptos de la primera y segunda realizaciones pueden aplicarse también a la recuperación de dirección para el servidor de SLP o E-SLP.
La Figura 7 muestra un diagrama de flujo ejemplo de un procedimiento de configuración de acuerdo con la segunda y tercera realizaciones. El procedimiento o mecanismo puede usarse, por ejemplo, para configurar una dirección de servidor de LoST/HELD/E-SLP por defecto.
En la etapa 301, se usan los primeros 5 o 6 dígitos de la CGI, dependiendo de si se extrae un MNC de 2 o 3 dígitos. A continuación, en la etapa 302, se separan en MCC y MNC. Si el MNC es de 2 dígitos de longitud, entonces puede añadirse un cero al comienzo.
En la etapa 303, los MCC y MNC extraídos derivados en las etapas 301 y 302 y la LAI se usan para crear un nombre de dominio por defecto como sigue (la expresión a continuación está basada en el anexo E de la especificación del 3GPP TS 23.003): "mnc<MNC>.mcc<McC>.lai<LAI>.pub.3 gppnetwork.org".
Finalmente, en la etapa 304, se añade una etiqueta "held.", "lost." o "e-slp.", al comienzo del nombre de dominio por defecto configurado.
Como un ejemplo, si una CGI en uso es "234150999999999", donde MCC=234, MNC=15, y LAI (LAC+CI)=0999999999, se obtendrían los siguientes nombres de dominio por defecto configurados para los diferentes tipos de servidor:
Servidor de LoST: "lost.mnc015.mcc234.lai0999999999.pub.3 gppnetwork.org",
Servidor de HELD: "held.mnc015.mcc234.lai0999999999.pub.3 gppnetwork.org"
Servidor de E-SLP: "e-slp.mnc015.mcc234.lai0999999999.pub.3 gppnetwork.org".
Por lo tanto, si el UE 10 no está aprovisionado con un URI de servidor de HELD/loST/E-SLP, el UE 10 construye los URI de acuerdo con el esquema anterior. El UE 10 a continuación realiza una consulta de DNS normal usando los URI auto-aprovisionados por defecto para obtener la dirección de IP de los servidores de HELD/loST/E-SLP. El servidor de DNS 32 puede haberse aprovisionado con las direcciones por defecto para devolver las direcciones de IP a la consulta de DNS normal. El UE 10 puede a continuación entrar en contacto con los servidores de HELD/loST/E-SLP usando las direcciones de IP recibidas y el flujo de llamada continúa normal. A medida que el nombre de dominio completamente cualificado por defecto (FQDN) baja al nivel de célula, puede aprovisionarse cualquier número de servidores de LoST/HELD/E-SLP en el DNS para fines de equilibrio de carga.
La Figura 8 muestra diagramas de bloques esquemáticos de un dispositivo móvil y una base de datos, que pueden usarse en las realizaciones anteriores. La descripción está basada en una implementación a modo de ejemplo para un servicio de emergencia.
El UE 10 comprende una unidad de frecuencia de radio (RF) 21 para transmitir y recibir señales de radio a/desde la red de acceso de radio 300. Si se activa un activador de emergencia ET (por ejemplo, presionando un botón de emergencia o similares), una función o unidad de generación de dirección 23 determina un identificador único como se describe en las realizaciones anteriores y renvía el identificador único a una función o unidad de generación de mensaje 22 que genera la consulta de DNS con el identificador único determinado para que se transmita al servidor de DNS 32.
El servidor de DNS 32 comprende una funcionalidad o unidad de control de acceso (AC) 14 que proporciona acceso a la base de datos. La base de datos comprende una sección de puntero 12-1 y una sección de dirección asociada 12-2. En la sección de puntero 12-1, se almacenan los indicadores ID1-Idn que pueden corresponder a las CI anteriormente mencionadas, direcciones de MAC, direcciones por defecto como ejemplos de identificadores únicos del dispositivo de acceso 20. La sección de dirección 12-2 almacena direcciones de servidor (por ejemplo direcciones de servidor de LoST, HELD o E-SLP) asociadas con los identificadores en la sección de puntero 12-1.
Cuando se recibe la consulta de DNS con el identificador único del UE 10 mediante la red de acceso de radio 300, la unidad de control de acceso 14 accede a la sección de puntero 12-1 de la base de datos usando el identificador único como un puntero y recibe de la sección de dirección 12-2 la dirección o direcciones de servidor asociadas. La dirección o direcciones de servidor recuperadas se reenvían a continuación al UE 10 en una correspondiente respuesta de DNS, y pueden usarse para acceder al PSAP 38 para iniciar un procesamiento de llamada de emergencia.
La Figura 9 muestra un diagrama de bloques esquemático de una implementación basada en software alternativa de acuerdo con una cuarta realización. Las funcionalidades requeridas pueden implementarse en cualquier dispositivo móvil 400 con una unidad de procesamiento 410, que puede ser cualquier procesador o dispositivo informático con una unidad de control que realiza el control basándose en rutinas de software de un programa de control almacenado en una memoria 412. El programa de control puede almacenarse también de manera separada en un medio legible por ordenador. Las instrucciones de código de programa se capturan de la memoria 412 y se cargan a la unidad de control de la unidad de procesamiento 410 para realizar las etapas de procesamiento de las funcionalidades anteriores de las Figuras 7 y 8, que pueden implementarse como las rutinas de software anteriormente mencionadas. Las etapas de procesamiento pueden realizarse basándose en datos de entrada DI y pueden generar datos de salida DO. Los datos de entrada Di puede corresponder a una dirección de CGI o MAC u otro identificador único del dispositivo de acceso de radio referido y los datos de salida DO pueden corresponder a la consulta de servidor que va a transmitirse al servidor de DNS 32 o cualquier otro servidor de intermediario usado para recuperar el identificador deseado.
En consecuencia, las realizaciones anteriores pueden implementarse como un producto de programa informático que comprende medios de código para generar cada etapa individual del procedimiento de señalización cuando se ejecuta en un dispositivo informático o procesador de datos del dispositivo de recepción (por ejemplo Nodo B 20) o dispositivo de transmisión (por ejemplo, UE 10), respectivamente.
En resumen, se han descrito un método, aparato, sistema, y producto de programa informático, en los que se usa un identificador único de un nodo (tal como un nodo de acceso) de una red de radio para solicitar de una base de datos información dependiente de la ubicación para un dispositivo móvil fijado al nodo. Un identificador de al menos un servidor que sirve en un área en la que está situado el dispositivo móvil se recupera a continuación usando la información dependiente de la ubicación.
Es evidente que la invención puede ampliarse fácilmente a cualquier servicio y entorno de red (fija e inalámbrica), donde se requiere información dependiente de la ubicación para acceder a un servidor que ofrece un servicio deseado. El servidor puede proporcionar cualesquiera servicios de telecomunicación y no está limitado a los tipos de servidor mencionados en las realizaciones preferidas. Específicamente, la presente invención no se pretende que esté restringida al entorno de área anterior de las realizaciones. Puede implementarse en cualquier entorno de red (por ejemplo, la invención puede usarse en redes no inalámbricas donde un dispositivo fijo, tal como un ordenador o teléfono fijo, se une a una red). Además, cualquier tipo de identificador único de cualquier clase de nodo puede usarse para la consulta de servidor. Como un ejemplo, puede usarse un identificador de línea (ID de línea) además de, o como una alternativa a, la dirección de CI y MAC anteriores. Adicionalmente, el identificador de línea puede almacenarse en un nodo (que cubre dispositivos de red y dispositivos terminales) donde está conectado el dispositivo y por lo tanto es único para cada línea y al dispositivo conectado. Por lo tanto, la expresión "identificador único" se pretende que cubra cualquier tipo de identificador de línea que incluye un identificador específico de terminal (dispositivo). Además, puede haber más de un identificador único para un nodo, de modo que un nodo puede tener varios dispositivos conectados mediante varias líneas donde cada línea tiene un identificador de línea único. Como el identificador de línea es entonces único para cada línea, también es único para cada dispositivo conectado. El o los identificadores de línea únicos pueden almacenarse y asignarse en el nodo donde está conectado el dispositivo.
El servidor de LoST podría también entregar la dirección de PSAP (o el URI de cualquier servicio/servidor de telecomunicación) que corresponde al id de línea del dispositivo terminal. El ID de línea podría ser, por ejemplo, un número de teléfono del dispositivo terminal. La realización puede variar por lo tanto dentro del alcance de las reivindicaciones adjuntas.
De acuerdo con una realización a modo de ejemplo de la presente invención, en un primer aspecto, puede proporcionarse un método que puede usar un identificador único de un nodo de una red para solicitar de una información dependiente de la ubicación de base de datos para un dispositivo fijado al nodo; y que puede determinar un identificador de al menos un servidor que da servicio en un área en la que está situado el dispositivo, usando, por ejemplo, la información dependiente de la ubicación.

Claims (15)

REIVINDICACIONES
1. Un método para un dispositivo,:
a) usando el dispositivo un identificador único de un nodo (20) de una red para solicitar de un sistema de nombre de dominio (32) uno de un identificador de un servidor (38), un identificador de un servidor de traducción (34) y un identificador de un servidor de descubrimiento de ubicación (36) para el dispositivo (10) fijado a dicho nodo (20); en donde la solicitud comprende una dirección de servidor por defecto establecida en dicho dispositivo (10) usando al menos partes de dicho identificador único y la solicitud es para permitir que el sistema de nombre de dominio determine el identificador del al menos un servidor (38), (34) y (36) que dé servicio en un área en la que está situado dicho dispositivo, y
b) recibiendo el dispositivo una respuesta a la solicitud del sistema de nombre de dominio que incluye el identificador del al menos un servidor (38), o el identificador del servidor de traducción (34) y/o el identificador del servidor de descubrimiento de ubicación (36).
2. El método de acuerdo con la reivindicación 1, en el que dicho identificador único comprende al menos uno de un identificador de célula de un sistema de transmisión celular, una dirección de capa de control de acceso al medio de un punto de acceso de una red de área local y un identificador de línea del dispositivo.
3. El método de acuerdo con la reivindicación 2, en el que dicho identificador de célula es un identificador global de célula y en el que la dirección de servidor por defecto se establece desde al menos uno de un código de red móvil, un código de país móvil y un código de área de ubicación de dicho identificador global de célula.
4. El método de acuerdo con cualquiera de las reivindicaciones anteriores, en el que dicha dirección de servidor por defecto comprende un identificador de recurso uniforme.
5. Un aparato que comprende:
medios de acceso de servicio (23) configurados para usar un identificador de nodo de un nodo (20) de una red a la que está fijado dicho aparato, en una solicitud de sistema de nombre de dominio de un identificador de uno de un identificador de un servidor (38), un identificador de un servidor de traducción (34) y un identificador de un servidor de descubrimiento de ubicación (36) para dicho aparato, y
una función de receptor para recibir una respuesta a la solicitud del sistema de nombre de dominio del identificador del al menos un servidor (38), o el identificador del servidor de traducción (34) y/o el identificador del servidor de descubrimiento de ubicación (36),
en donde dicho al menos un servidor que da servicio a un área en la que está situado dicho aparato, y en donde dichos medios de acceso de servicio (23) están configurados adicionalmente para establecer una dirección de servidor por defecto (10) usando al menos partes de dicho identificador de nodo y la solicitud es para permitir que el sistema de nombre de dominio determine un identificador de al menos un servidor que da servicio a un área en la que está situado dicho aparato.
6. El aparato de acuerdo con la reivindicación 5, donde dicho nodo (20) es un componente de una red inalámbrica, o donde dicho nodo (20) es un componente de una red fija.
7. El aparato de acuerdo con la reivindicación 5, en el que dicho identificador único comprende al menos uno de un identificador de célula de un sistema de transmisión celular, una dirección de capa de control de acceso al medio de un punto de acceso de una red de área local y un identificador de línea.
8. El aparato de acuerdo con la reivindicación 7, en el que dicho identificador de célula es un identificador global de célula y en el que la dirección de servidor por defecto está configurada para establecer dicha dirección de servidor por defecto desde al menos uno de un código de red móvil, un código de país móvil y un código de área de ubicación de dicho identificador global de célula.
9. El aparato de acuerdo con una cualquiera de las reivindicaciones 5 a 8, en el que dichos medios de acceso de servicio (23) están configurados para solicitar dicho identificador de al menos un servidor (38) mediante una consulta a un sistema de nombre de dominio.
10. El aparato de acuerdo con cualquiera de las reivindicaciones 5 a 9, en el que dichos medios de acceso de servicio (23) están configurados para proporcionar dicha dirección de servidor por defecto con un identificador de recurso uniforme.
11. Un sistema de nombre de dominio configurado para almacenar identificadores de servidores (38) en asociación con identificadores de nodo de nodos de red, en el que dicho sistema (32) está configurado para recibir de un dispositivo una solicitud de un identificador de uno de un identificador de un servidor (38), un identificador de un servidor de traducción (34) y un identificador de un servidor de descubrimiento de ubicación (36) para el dispositivo, estando basada la solicitud en un identificador de nodo de un nodo (20) de una red a la que está fijado el dispositivo, y está configurado para emitir al dispositivo una respuesta que comprende al menos uno de dichos identificadores de servidores (38) o el identificador del servidor de traducción (34) y/o el identificador del servidor de descubrimiento de ubicación (36) en respuesta a la solicitud, en donde la solicitud comprende una dirección de servidor por defecto que incluye al menos partes de dicho identificador de nodo del nodo de red y la solicitud es para permitir que el sistema de nombre de dominio determine un identificador de al menos un servidor que da servicio a un área en la que está situado dicho dispositivo.
12. El sistema de nombre de dominio de acuerdo con la reivindicación 11, en el que dicho identificador único comprende al menos uno de un identificador de célula de un sistema de transmisión celular, una dirección de capa de control de acceso al medio de un punto de acceso de red de área local y un identificador de línea de un dispositivo conectado al nodo de red.
13. Un producto de programa informático que comprende medios de código para generar las etapas del método de la reivindicación 1 cuando se ejecuta en un dispositivo informático.
14. Un sistema para señalizar información de control, comprendiendo dicho sistema al menos un aparato de acuerdo con la reivindicación 5 y al menos un sistema de nombre de dominio de acuerdo con la reivindicación 11.
15. Un dispositivo móvil que comprende un aparato de acuerdo con la reivindicación 5.
ES08707572T 2008-02-06 2008-02-06 Adquisición de identificador de servidor basada en ubicación de dispositivo Active ES2787251T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2008/000906 WO2009097870A1 (en) 2008-02-06 2008-02-06 Server identifier acquisition based on device location

Publications (1)

Publication Number Publication Date
ES2787251T3 true ES2787251T3 (es) 2020-10-15

Family

ID=39846946

Family Applications (1)

Application Number Title Priority Date Filing Date
ES08707572T Active ES2787251T3 (es) 2008-02-06 2008-02-06 Adquisición de identificador de servidor basada en ubicación de dispositivo

Country Status (8)

Country Link
US (1) US10623900B2 (es)
EP (1) EP2250856B1 (es)
CN (1) CN101983499B (es)
BR (1) BRPI0822330B1 (es)
ES (1) ES2787251T3 (es)
PL (1) PL2250856T3 (es)
WO (1) WO2009097870A1 (es)
ZA (1) ZA201005529B (es)

Families Citing this family (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090217346A1 (en) * 2008-02-22 2009-08-27 Manring Bradley A C Dhcp centric network access management through network device access control lists
CN102210174B (zh) * 2008-11-10 2015-06-17 爱立信电话股份有限公司 通信网络中的拓扑确定
JP2012514363A (ja) * 2008-12-26 2012-06-21 テレフオンアクチーボラゲット エル エム エリクソン(パブル) 2層の(bi−level)アドレス指定スキームを用いて通信をルーティングするための方法および通信ノード
US8301160B2 (en) * 2009-03-16 2012-10-30 Andrew Llc System and method for SUPL roaming using a held client
US8391884B2 (en) * 2009-03-26 2013-03-05 Andrew Llc System and method for managing created location contexts in a location server
CN102036204B (zh) * 2009-09-24 2015-06-03 中兴通讯股份有限公司 一种实现紧急定位的方法及系统
CN102036162A (zh) * 2009-09-24 2011-04-27 中兴通讯股份有限公司 一种定位系统、方法及终端
CN102215449B (zh) * 2010-04-02 2016-05-11 中兴通讯股份有限公司 Set终端定位方法、装置和系统
US20110271005A1 (en) * 2010-04-30 2011-11-03 Sonus Networks, Inc. Load balancing among voip server groups
US8812728B2 (en) 2010-09-15 2014-08-19 Andrew Llc Routing requests for location-to-service translation (LoST) services using proxy server
EP2482525B1 (en) * 2011-01-28 2014-03-12 NTT DoCoMo, Inc. Method and apparatus for determining a server which should respond to a service request
US8811939B2 (en) 2011-02-07 2014-08-19 Qualcomm Incorporated Method and/or apparatus for location privacy via uniform resource identifier provisioning
US10009319B2 (en) * 2011-02-07 2018-06-26 Qualcomm Incorporated Methods, apparatuses and articles for identifying and authorizing location servers and location services using a proxy location server
US8738027B2 (en) 2011-02-07 2014-05-27 Qualcomm Incorporated Methods and apparatus for identifying and authorizing location servers and location services
CN103503487B (zh) * 2011-03-03 2017-05-03 交互数字专利控股公司 用于接入隶属于所发现的服务供应商的服务的方法和装置
FR2980328A1 (fr) * 2011-09-19 2013-03-22 France Telecom Procede de traitement d'une requete d'un service dependant de la localisation d'un terminal mobile
US20140059071A1 (en) * 2012-01-11 2014-02-27 Saguna Networks Ltd. Methods, circuits, devices, systems and associated computer executable code for providing domain name resolution
US20140282865A1 (en) * 2013-03-12 2014-09-18 Qualcomm Incorporated Dynamic h-slp allocation for set initiated supl services
CN109076095B (zh) * 2016-04-01 2022-03-08 诺基亚技术有限公司 用于数据分发的方法、装置和计算机可读存储介质
US9820090B1 (en) * 2016-09-15 2017-11-14 Qualcomm Incorporated Enhanced fallback mechanism for SLP connection during emergency SUPL sessions
CN109428903B (zh) * 2017-08-22 2021-08-13 佛山市顺德区顺达电脑厂有限公司 Pci装置的远程监控系统及其远程监控方法
US10833962B2 (en) * 2017-12-14 2020-11-10 International Business Machines Corporation Orchestration engine blueprint aspects for hybrid cloud composition
US11025511B2 (en) 2017-12-14 2021-06-01 International Business Machines Corporation Orchestration engine blueprint aspects for hybrid cloud composition
US10972366B2 (en) 2017-12-14 2021-04-06 International Business Machines Corporation Orchestration engine blueprint aspects for hybrid cloud composition
US10785748B2 (en) * 2018-07-26 2020-09-22 T-Mobile Usa, Inc. Mobile device assisted selection of paging location area in a wireless communication network

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU2000259818A1 (en) * 2000-07-04 2002-01-14 Nokia Corporation Method and device for attaching a user equipment to a telecommunication network
US7099677B2 (en) * 2001-11-29 2006-08-29 Bellsouth Intellectual Property Corp. Smart call delivery GIS integration
US20040198413A1 (en) * 2003-01-03 2004-10-07 Smith Gregory S. Wireless communication device with call management capability and method therefor
TR200300129A2 (tr) 2003-01-31 2004-08-23 Raks Elektron�K San. Ve Teknoloj� A.�. Bir mobil terminalin yer bilgilerinin gönderilmesi,toplanması ve takibi
US20060117020A1 (en) * 2004-12-01 2006-06-01 John Toebes Arrangement for selecting a server to provide distributed services from among multiple servers based on a location of a client device
US8301111B2 (en) * 2005-11-01 2012-10-30 Telefonaktiebolaget Lm Ericsson (Publ) Method of and system for setting up a telephone call
US20070153984A1 (en) * 2006-01-03 2007-07-05 Sony Ericsson Mobile Communications Ab Method and Apparatus for Routing Emergency Calls in a VoIP System
US20070153982A1 (en) 2006-01-03 2007-07-05 Sony Ericsson Mobile Communications Ab Method and Apparatus for Routing Emergency Calls in a VoIP System
US20080227430A1 (en) * 2007-03-15 2008-09-18 Polk James M Adding Emergency Numbers to a Mobile Address Book
US8503992B2 (en) * 2007-06-22 2013-08-06 Telefonaktiebolaget L M Ericsson (Publ) Service areas in CS domain services

Also Published As

Publication number Publication date
BRPI0822330A2 (pt) 2015-06-16
BRPI0822330B1 (pt) 2020-09-24
CN101983499B (zh) 2014-07-23
ZA201005529B (en) 2011-04-28
EP2250856A1 (en) 2010-11-17
US10623900B2 (en) 2020-04-14
BRPI0822330A8 (pt) 2015-09-29
WO2009097870A1 (en) 2009-08-13
US20110004672A1 (en) 2011-01-06
EP2250856B1 (en) 2020-03-25
PL2250856T3 (pl) 2020-08-10
CN101983499A (zh) 2011-03-02

Similar Documents

Publication Publication Date Title
ES2787251T3 (es) Adquisición de identificador de servidor basada en ubicación de dispositivo
CN108632312B (zh) 网络功能信息交互方法及装置
US9107061B2 (en) System and method for multimedia emergency access in a wireless network
EP2537323B1 (en) Machine-to-machine device triggering using session initiation protocol uniform resourse identifier
US20080065775A1 (en) Location data-URL mechanism
CA2595077C (en) A method and apparatus for handling emergency calls
US20060002308A1 (en) Apparatus and method for managing information in multimedia service providing system
EP2536171B1 (en) Location method, device and system for secure user plane location enabled terminal
US10772065B2 (en) Method and device for supplying location information to an apparatus connected to a network access point
MX2009001402A (es) Metodo y arreglo para proporcionar informacion de ubicacion en una terminal de comunicacion.
CN101635738B (zh) 获取服务信息的方法、系统、客户端和服务器
FI120227B (fi) Päätelaitteen verkko-osoitteen selvittäminen
US9560583B2 (en) Gateway selection based on geographical location
CN113382031A (zh) 一种域名查询方法及装置
US20160080313A1 (en) Discovery of network address allocations and translations in wireless communication systems
RU2467505C2 (ru) Получение идентификатора сервера на основе местоположения устройства
Schulzrinne et al. Lost: A protocol for mapping geographic locations to public safety answering points
EP3222066B1 (en) Methods and arrangements in location servers
CN116193414A (zh) 一种服务发现的方法、装置及存储介质
EP1720031A1 (en) A method for providing a service to a terminal, the corresponding system and apparatus
Ashtarifar et al. A Link Layer Solution to Location Identification of Emergency VoIP Callers
Tang et al. Serving Spatial Location Information over the